Main Menu

Project Life Cycle

Developers Menu

Home

Multidomain Circuit Monitoring System (CMon)

Users are requiring data services that can provide higher and guaranteed bandwidth with less jitter than traditional IP connections, and greater flexibility than static dedicated layer 2 (L2) point-to-point connections (circuits). CMon is a distributed multidomain circuit monitoring system. CMon fetches monitoring data from domains and splices different segment performances to show for the whole connection. CMon is able to provide end-to-end circuit monitoring services with great flexibility, extensibility, and vendor independency, regardless of the underlying circuit provisioning systems (CPSs).

1. Overview

Static Circuits & Dynamic Circuits Monitoring

Dynamic circuits are provisioned according to the demands from the users, e.g. service duration, reserved bandwidth, maximum transmission unit (MTU) and etc. After the service period, the provisioned circuits are torn down and the reserved resources are freed. Static circuits can be seen as special dynamic circuits with a very long service period. The monitoring of static circuits is relatively easier than the dynamic circuits provisioned on-demand. This is because that the configuration information of static circuits requires little modification while such information of dynamic circuits needs to be updated dynamically in cooperation with the provisioning system. CMon is built to monitor both circuit types.

Layer 2 Monitoring

CMon is built for L2 connection monitoring and therefore only focuses on L2 monitoring. Future work will consider monitoring higher layers.

Measurement Metrics

Measurement metrics are significant for the operators to monitor the provisioned circuits and take action accordingly. These metrics are highly related to the QoS metrics, such as delay, jitter, and frame loss ratio. In addition, the up/down status, utilization, and actual bandwidth are also desired. However, measurement metrics on different layers are to be collected differently. Currently, only passive measurements are included in CMon, and therefore the metrics considered are:

  • Interface up/down status
  • Interface error counts
  • Interface traffic volume
  • Interface utilization

2. Architecture

Circuit Description

CMon adopts Global Lambda Integrated Facility (GLIF) universal resource name (URN) format for naming circuits, segment, ports, node, etc. Circuit naming and description is an important issue in a multidomain environment because identification uniqueness must be ensured. The principle naming rules are as follows:

Note that the local part is domain specific. It means that different domains can assign different strings to this part and they should all be valid as long as they comply with the rules above. There are four elements involved in a describing circuit:

Circuit Identifier:

A circuit identifier (CID) uniquely identifies a circuit. With the CID, clients can look up information about the circuit in a circuit registration database. The format of this identifier is a GLIF URN naming format containing a domain name part and a domain-specific (local) part, shown as follows:

for static circuits, the local part is:

for dynamic circuits, the local part is:

Circuit Descriptor:

A circuit descriptor is an XML file. It contains information of the high-level topology of a circuit, such as the source domain, destination domain, intermediate domains, duration (for dynamic circuits).

Segment Identifier:

A segment identifier (SID) uniquely identifies a circuit segment, which is usually provisioned by a domain. Like the CID, clients can look up information about the segment in a circuit registration database. The format of this identifier is also a URN of the GLIF naming format containing a domain name part and a domain-specific part, shown as follows:

for static circuits, the local part is:

for dynamic circuits, the local part is:

Segment Descriptor:

A segment descriptor is an XML file. It contains a sequence of network elements selected for the reservation within a domain, including ports, nodes, etc.

  • Node Identifier
  • Port Identifier

Circuit Monitoring Architecture

For static circuits, where the configuration rarely or never changes, a simple static monitoring architecture will be enough. However, when circuits are provisioned dynamically, the topology or resources of a circuit connecting two end nodes may not always be the same after being reestablished. Different ports or even different network nodes may be used, even if the two ends remain unchanged. As a result, the addresses of corresponding measuring probes and databases will be different. The architecture, therefore, should be able to handle the changes dynamically.

The holistic view of the CMon architecture is shown below, consisting of three groups of functions: circuit provisioning functions from CPS, network monitoring functions from perfSONAR, and circuit monitoring functions from CMon.

Circuit Provisioning Functions:

A domain can have a different circuit provisioning system from the others (e.g. OSCARS, [AutoBAHN], and [OpenNSA]), using the Network Service Interface (NSI) protocol. However, regardless of the differences between provisioning systems, three elements are crucial from the circuit monitoring perspective:

  • The interdomain provider agent (IPA) provides interdomain- technology-agnostic functionality. It receives and processes high-level BoD reservation requests from users and other IPAs.
  • The provider agent (PA) is responsible for intra-domain functionality. It receives the BoD reservation requests from the IPA, searches for a proper path within the domain and handles signaling to/from the data plane.
  • The network resource manager (NRM) owns a particular set of transport resources and is responsible for authorizing and managing the use of these resources.
Network Monitoring Functions:

perfSONAR has several functions that can be used by CMon, i.e. MA and lookup service (LS)

Circuit Monitoring Functions:

For circuit monitoring, additional functions are required that focus on binding the monitoring service to the underlying circuit provisioning system to ensure that data measurements, as well as circuit reservation and termination information is collected. These tasks are provided by:

  • CMon Headquarter (HQ) is the function responsible for gluing the circuit provisioning system and the network monitoring system, and gathering the measurement data of circuits. As mentioned previously, an extra layer CMon-CPS is introduced between CMon and the CPS. Although such cross-layer architecture limits the flexibility of the system, it is a relatively quick way to implement circuit monitoring. Considering the future evolution, two sub-functions are created so that they can be separated easily, and it will allow the system to convert to a layered structure in the future. These two sub-functions are:
    • HQ-monitoring manager (HQ-MM) is responsible for collecting and storing measurement data from either CMon Agents (AGTs) or MAs.
    • HQ-integration function (HQ-IF) is responsible for interfacing with the CPS to fetch the circuits establishment and teardown information. Also, this function registers itself in the LS so that it can be searched by other perfSONAR parties.
  • AGT is responsible for gathering monitoring data from either MA or already-existing monitoring proxies and sending the data in a formatted extensible markup language (XML) file to HQ periodically. SNMP traps from the data plane should also be handled directly by the AGT.

Communications Protocol

Based on the architecture described, the communication workflow of different functions is further presented in this section.
The whole circuit monitoring process is divided into three phases: circuit notification phase, circuit monitoring phase, and circuit termination phase. In addition to the monitoring procedures, all services, e.g. MA and AGT should constantly maintain their registrations in the hLS in their own domain.

Circuit Notification Phase:

Circuit notification phase starts from the time when a circuit request is initiated until the circuit is successfully established and ready to carry traffic. In this phase, the circuit metadata (circuit descriptor and segment descriptor), described in Section 3, are generated and the HQ must receive it in order to fetch the measurement data later on in the circuit monitoring phase.

Each IPA sends the circuit descriptor and the segment descriptor in a circuit request message (CRM) to the HQ with establishment information. (Information is pushed to the HQ by the IPA). The HQ contacts the hLS and uses the information contained in the segment descriptor to obtain the addresses of the AGT that is available in the domain and relevant to the monitored circuit and its parameters. Upon receiving the addresses of the AGTs, the HQ sends begin commands to the AGTs in each domain and each AGT responds with a 200 OK message.

Circuit Monitoring Phase:

Circuit monitoring phase starts from the time when the circuit is successfully established and the AGT in each domain is ready to collect measurement data until a circuit termination command is initiated either manually or automatically in the CPS. In this phase, live and history measurement data are provided.

After confirming the successful reception of the begin command, each AGT begins to periodically fetch monitoring data from the local system, i.e. either the third-party monitoring proxy or the local MA or directly from the devices. Alternatively, SNMP traps can be set up in the data plane so that a network failure event can immediately be reported to the AGT and further forwarded to the HQ to raise alarms.

Circuit Termination Phase:

An established circuit should be able to be terminated manually or automatically when the reservation time is passed. In either way, the IPA should send a circuit termination message (CTM) to the HQ, indicating that the circuit is no longer valid or active.
Each IPA sends a CTM containing necessary circuit and segment descriptors information to the HQ with termination information. (Information is pushed to the HQ by the IPA). The HQ responds to each IPA with a 200 OK message. The HQ sends an end command to each AGT related to the circuit to stop fetching the monitoring data of this circuit.

Skip to end of metadata
Go to start of metadata
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.