Ethernet CFM

Ethernet CFM

Ethernet Connectivity Fault Management (CFM, IEEE 802.1ag) is an end-to-end Ethernet OAM that can cross multiple domains to monitor the health of the entire service instance. A service instance can be a native Ethernet VLAN, an EoMPLS (aka E-Pipe) or a VPLS instance. End-to-end can be PE to PE, or CE to CE. CFM is a connectivity checking mechanism that uses its own Ethernet frames (its Ethertype is 0x8902 and it has its own MAC address) to validate the health of the service instance.

CFM Terminology

Maintenance Domain (MD)

In Ethernet CFM, an MD is a management space for monitoring and administering of a network. An MD is owned by a Maintenance Entity (ME). Figure 1 shows different MDs, each owned by a single entity.

A unique maintenance level from 0 to 7 is assigned to each domain. The larger the domain, the higher the value. For instance, the customer domain in figure 1 would be assigned the highest value, 7, while the operator domain would be assigned the lowest value, 0. The MDs are defined to have hierarchical relationships with other domains. Domains cannot intersect, however, they can be touching &/or nested.

Ethernet CFM exchanges messages and performs operations on a per-domain basis. For instance, in figure 1, CFM running at Operator 1 level does not allow discovery of the network by Provider or Customer level.

Maintenance Point

A Maintenance Point is a demarcation point for the CFM frames. It is an interface (physical port or logical interface) that participates in an MD. A maintenance point filters the CFM frames by dropping frames that do not belong in the correct MD. The maintenance points must be configured manually. There are two types of maintenance points-

Maintenance Endpoint (MEP): MEPs initiate and terminate CFM messages. MEPs define the boundary of an MD.

Maintenance Intermediate Point (MIP): MIPs receive CFM messages and respond to originating MEPs. A MIP never initiates messages and does not expect any CFM messages.

Maintenance Association (MA)

A set of MEPs that have the same MA identifier and MD level within one service instance to verify the integrity of the service. It is represented by the solid line in figure 2.

The following rules apply to CFM message processing-

    1. If the MD level of the CFM message is higher than the MD level of the MEP/MIP, the MEP/MIP transparently passes the CFM message.
    2. If the MD level of the CFM message is lower than the MD level of the MEP/MIP, the MEP/MIP discards the CFM message.
    3. If the MD level of the CFM message is equal to the MD level of the MEP/MIP, the MEP/MIP processes the CFM message. Depending on the type of CFM message, the MEP/MIP responds to, transports to or accepts the message.

A MEP/MIP with a particular MD level generates a CFM message only at that level. In figure 2, the customer is interested in only the health of the end-to-end connection. Therefore, the MA has a high MD level (for example, MD=7). The MEPs/MIPs in provider and operator networks transparently pass customers CFM messages. The Provider is interested in the health of the service it provides. Therefore, the MA has a higher MD level (for example, MD=5) than the operators MD level but lower than the customer MD level. So, the MEPs/MIPs in operator network transparently pass the provider's CFM messages. The operators are interested only in the health of their own networks. Therefore, their MAs have lowest MD level (for example, MD=0). So, the CFM messages are confined to their own network.

CFM Messages

A CFM message has its own frame format. All CFM messages are Ethernet frame with an etherype of 0x8902. Figure 3 shows a CFM frame format.

    • MD Level - An MD of the CFM message from 0 to 7
    • CFM Version - Currently, it is set to 0
    • CFM OpCode - This indicates the type of CFM messages (discussed next)
    • CFM PDU - Each CFM message type is associated with a different CFM PDU. Each PDU contains one or more informational TLVs

All CFM messages end with an empty End TLV.

There are 5 different types of CFM messages-

1. Continuity Check Message (CCM): A MEP generates CCM messages to announce its local port and interface status. If CCM is enabled, an MA tracks CCM messages from all MEPs, and is performed at a defined interval. CCM messages always use multicast destination MAC address and has the format of 01-80-C2-00-00-3x where 'x' relates to value of MD level (0-7).

2. Loopback Message (LBM): A MEP generates a CFM LBM message when the CFM loopback test is performed. The packet is destined to the MAC address the loopback test intends to reach. On an Alcatel-Lucent device, this can be done as follows-

CFM Loopback Test

A:SW1# oam eth-cfm loopback 0c:a4:02:05:cc:01 mep 1 domain 3 association 3

Eth-Cfm Loopback Test Initiated: Mac-Address: 0c:a4:02:05:cc:01, out service: 35

Sent 1 packets, received 1 packets [0 out-of-order, 0 Bad Msdu]

A:SW1#

The packet capture of an LBM message is as follows-

3. Loopback Reply message (LBR): A MEP/MIP responds with LBR message when it receives an LBM destined to its own MAC address. The packet destination MAC address is the source MAC address of the LBM message. The packet capture of an LBR message is as follows-

4. Linktrace message (LTM): A MEP generates LTM message when link trace is performed. The packet is destined to multicast MAC address 01-80-C2-00-00-3y where 'y' corresponds to MD level as below:

On an Alcatel-Lucent device, link trace test can be performed as follows-

Link Trace test

A:SW1# oam eth-cfm linktrace 0c:a4:02:05:cc:01 mep 1 domain 3 association 3

Index Ingress Mac Egress Mac Relay Action

----- -------------------- -------------------- ---------- ----------

1 00:00:00:00:00:00 0C:A4:02:05:CC:01 rlyHit terminate

----- -------------------- -------------------- ---------- ----------

No more responses received in the last 6 seconds.

The packet capture of an LTM message is as follows-

5. Linktrace Reply message (LTR): A MEP responds with an LTR message when it receives an LTM message destined to its own MAC address. The destination MAC address is the source MAC address of LTM message. The packet capture of LTR message is as follows-

Configuring CFM

Figure 4 shows a sample network with Provider and Customer MAs. Two steps are required to configure CFM in VPLS network - 1) The MD and MA need to be created first, then 2) the MEP/MIP can be created in the VPLS service instance and added to the defined MD and MA.

When defining an MD, the level of the MD must be specified. One MD can contain one or more MAs. Figure 4 illustrates an example of CFM in provider and customer domains. VPLS instance 50 is deployed in all 3 provider network's PE routers. Customer routers connect to PE routers through an attachment circuit. In this example, the customer uses the MD name Customer_Domain with level 7, and the provider uses the MD name Provider_Domain with level 3. The customer and provider have their own MAs. With this configuration, the customer's MD level is higher than the provider's MD level and hence the VPLS network will transparently pass customer CFM messages.

When deploying MEPs in a VPLS service, the direction of flow must be specified. In VPLS, the traffic coming to a PE router from an interface connecting to the CE router is considered to be in up direction. While the traffic coming to the PE router on a Pseudowire exiting to a CE router is considered to be in down direction.

In an Alcatel-Lucent 7x50 device, the first step to enable CFM is to create an MD. Each MD has an index, a name and an MD level. Many MAs can be defined under the same MD. After the MD is created, the MA can be created under the MD.

Enabling CFM CCM on ALU 7x50 PE1 router

#--------------------------------------------------

echo "Eth-CFM Configuration"

#--------------------------------------------------

eth-cfm

domain 1 name "Provider_Domain" level 3

association 1 format string name "MA_VPLS_50"

bridge-identifier 50

exit

ccm-interval 1

remote-mepid 2

remote-mepid 3

exit

exit

exit

In above example, bridge-identifier identifies the service in which the MA is deployed. The remote-mepid represents the list of IDs for all remote MEPs that belong to this MA.

After MD and MA are created, the MEP can be created under the VPLS or E-pipe service instance.

Creating MEP under VPLS 50 on PE1 router

#--------------------------------------------------

echo "Service Configuration"

#--------------------------------------------------

service

customer 1 create

description "Default customer"

exit

vpls 11 customer 1 create

sap lag-1:4093 create

description "To CE1 Router"

eth-cfm

mep 1 domain 1 association 1 direction up

ccm-enable

no shutdown

exit

exit

exit

mesh-sdp 12:11 create

exit

mesh-sdp 13:11 create

exit

no shutdown

exit

exit

The following example shows enabling CFM for a Customer domain for VLAN 100 on Cisco devices.

Configuring CFM CC on Cisco device

ethernet cfm domain Customer_Domain level 7

!

ethernet cfm enable

ethernet cfm cc level 7 vlan 100 interval 20 loss-threshold 3

!

interface gigabitethernet 3/1

ethernet cfm mep level 7 outward mpid 111 vlan 100

!

MIPs in CFM

MIPs are intermediate points in the CFM architecture. A MIP responds to an LBM message with an LBR message if its own MAC address is the destination address of the LBM message. A MIP forwards upon receiving LTM messages based on FDB lookup, and responds with an LTR message. A MIP is transparent to CCM messages.

In ALU device, a MIP is automatically created with a MEP using the command mhf-creation explicit.

Adding a MIP to a VPLS service in ALU device

#--------------------------------------------------

echo "Eth-CFM Configuration"

#--------------------------------------------------

eth-cfm

domain 1 name "Provider_Domain" level 3

association 1 format string name "MA_VPLS_50"

bridge-identifier 50

mhf-creation explicit

exit

ccm-interval 1

remote-mepid 2

remote-mepid 3

exit

exit

exit

In a Cisco device, a MIP is created under the interface as below:

Adding a MIP in Cisco device

interface gigabitethernet 3/1

ethernet cfm mip level 7

!