Connectivity Fault Management (CFM) was first introduced in IEEE 802.1ag, which has been superseded by IEEE 802.1Q-2011 and subsequently by IEEE 802.1Q-2014 - the IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks.
It defines protocols and practices for OAM (Operations, Administration, and Maintenance) for paths through 802.1 bridges and local area networks (LANs).
It is an amendment to IEEE 802.1Q-2005 and was approved in 2007.
IEEE 802.1ag is largely identical with ITU-T Recommendation Y.1731, which additionally addresses performance monitoring.
In addition the Metro Ethernet Forum (MEF) has defined SOAM (Service Operations Administration and Management) in MEF-17 on top of these standards to build a framework for monitoring in conjunction with MEF services. This and other MEF standards are available in their technical documentation section.
Working these combined standards into a unified model is a complex task an inevitably requires some compromises. For instance while 802.1Q talks about Maintenance Domains and Maintenance Associations the MEF 17 standard uses the name Maintenance Entity (ME) and Maintenance Entity Group (MEG). MEF 38 and 39 defines a model that encompasses all of the concepts as a set of YANG modules, that separate out the Monitoring aspects of MEF 17 from MEF Carrier Ethernet Services. In this way a loose coupling exists between the CFM and MEF Services linked together only through VLAN ids.
MEF 38 defines a root object mef-cfm which represents 802.1Q and Y.1731 CFM entities, which is augmented by mef-soam-fm which adds on additional attributes and operations from SOAM related to fault management.
MEF 39 augments mef-cfm further with the performance management aspects of SOAM as mef-soam-pm including monitoring of delay, jitter and loss measurements.
These YANG models act as a unified definition of these standards that it makes practical sense to reuse in ONOS.
Direct translation of the MEF 38 and MEF 39 YANG models into ONOS does not provide a completely clean way to define the models in ONOS, because of the complication brought by the augments. Instead the models have been defined independently in ONOS as a new structure under reusing common ONOS classes such as DeviceId, PortNumber, NetworkResource, Identifier, MacAddress etc.
These immutable objects are defined as Java POJOs with little dependencies on outside elements, and built the familiar builder pattern.
As with 802.1Q the model’s top level starts with the Maintenance Domain - an abstract reference object defining the span of the domain of activity for maintenance in the network. Maintenance Domains are defined at 8 different levels to indicate the scope of their span.
Beneath the Maintenance Domain is the Maintenance Association, another abstract object specific to a VLAN that contains common parameters for a group of MEPs (Maintenance Association Endpoints). It is these MEPs that are created on devices in the network and can be thought of as monitoring points. Devices must support the CfmMepProgrammable behaviour to support the creation of MEPs.
The MEP is the key item then that allows specific actions to be taken on devices such as
In addition these MEPs allow the creation of
The Java Doc for this model is available at http://api.onosproject.org/1.10.8/org/onosproject/incubator/net/l2monitoring/cfm/MaintenanceDomain.html and is summarized in the following L2 Monitoring hierarchy:
|-Maintenance-Domain*
|-MdId (MdIdCharStr or MdIdDomainName or MdIdMacUint or MdIdNone)
|-Maintenance-Association*
|-MaIdShort (MaIdCharStr or MaIdPrimaryVid or MaId2Octet or MaIdRfc2685VpnId or MaIdIccY1731)
|-Component*
|-Mep* (Maintenance-Association-EndPoint) and MepEntry*
| |-MepId
| |-MepLbEntry
| |-MepLtEntry
| | |-MepLtTransactionEntry*
| | |-MepLtReply*
| | |-SenderIdTlv
| |-DelayMeasurementCreate (SOAM)* and DelayMeasurementEntry
| | |-DmId
| | |-DelayMeasurementStatCurrent
| | |-DelayMeasurementStatHistory*
| |-LossMeasurementCreate (SOAM)* and LossMeasurementEntry
| | |-LmId
| | |-LossMeasurementStatCurrent
| | |-LossMeasurementStatHistory*
| |-RemoteMepEntry*
| | |-RemoteMepId
|-RemoteMepId*
The classes and interfaces can be broken down into 4 main categories:
A set of services are defined for managing the object model
This is an interface that manages only the configuration of Maintenance Domain and Maintenance Association. It acts as a standalone service in ONOS that manages only these 2 levels of the model. The Maintenance Domain contains a list of Maintenance Associations does not contain Meps - these are left to the CfmMepService.
These objects are persisted in ONOS in a distributed data store by this service.
There are CLI commands (when org.onosproject.cfm app is activated) for creating, deleting and modifying these objects.
They can also be modified through a REST interface at http://localhost:8181/onos/cfm/md
This is an interface that manages the MEP and objects and commands below it. A MEP managed under this service has a reference to the Maintenance Domain and Maintenance Association above it, and hence depends on the CFM MD Service.
MEPs are identified by a combination of MdId, MaID and MepId.
To create a MEP a device ID must be specified. This device's driver must support the CFM Programmable behavior.
The service has the following actions associated with it
These objects can be modified through a REST interface at http://localhost:8181/onos/cfm/md/<md-id>/ma/<ma-id>/mep
At the moment the MEP object is only maintained in memory and not persisted in the ONOS data store. The objects Loopback, Linktrace, Test Signal, Loss Measurement and Delay Measurement are not maintained in ONOS at all as they are not really configuration objects. They are called on the fly and are passed down as a collection of method parameters to the device implementing the MEP. This device will operate on them and their results can be obtained by querying the responsible MEP on the device. For instance the results of LinkTrace, Loopback and Test Signal will appear in the MepLbEntry, MepLbEntry and MepTsEntry under the MepEntry when the “Get Individual Mep” method is called.
See in
for some JSON examples that can be used to activate this functionality.
This is an interface that manages the Delay and Loss Measurement functions of a MEP. It depends on the CFM MEP Service being active.
To create a Delay or Loss Measurement test the driver of the device associated with the MEP must support the SOAM Programmable behavior.
The service has the following actions associated with it:
These objects can be modified through a REST interface at http://localhost:8181/onos/cfm/md/<md-id>/ma/<ma-id>/mep/<med-id>/dm or http://localhost:8181/onos/cfm/md/<md-id>/ma/<ma-id>/mep/<med-id>/lm