Ethernet Service OAM IEEE 802.1ag

Overview

Ethernet service OAM (Operations, Administration, and Maintenance) provides maintenance features for detecting, isolating, and reporting connectivity faults for Ethernet services. This release implements IEEE Std 802.1ag™ -2007 Connectivity Fault Management for the VLNC40/42/42B circuit packs. Three basic features are currently specified: Continuity Check, Link Trace, and Loopback.

For each service, generally three types of players are involved: the customer, the service provider, and operators. For this reason Service OAM is defined at multiple levels, as shown in Figure 5-6, Service OAM reference model.

Figure 5-6: Service OAM reference model

Note:

Service OAM also applies to more complex networks than are represented in Figure 5-6, Service OAM reference model, including multipoint and ring networks.

Each player can establish their own Maintenance Associations (MA), consisting of Maintenance Endpoints (MEP’s, shown as triangles), which allows them to exchange OAM messages over their domain of the service. MEPs can perform fault detection using keep-alive messages called Continuity Check Messages (CCM). Maintenance Intermediate Points (MIPs, shown as circles) may be created to facilitate fault isolation. They can respond to, but do not initiate, certain OAM functions. For example, loopbacks may be initiated from a MEP which has detected a CC fault and targeted successively to each MIP at its level. A provider can isolate a fault to one operator, and an operator can isolate to a single NE.

Connectivity fault management

Connectivity fault management (CFM) supports concepts to support multiple independent operators, services, and customers.

Maintenance domains

A Maintenance domain (MD) is a part of the network controlled by a single player (owner) to support connectivity between maintenance end points (MEPs) that bound the maintenance domain.

Maintenance domain levels

Maintenance domain levels allow customers, service providers, and operators to run independent OAMs on their own level. Up to eight OAM levels are defined (0–7), with seven (7) being the highest. Customers are allocated up to three levels (5, 6, 7), service providers two levels (3, 4), and operators three levels (0, 1, 2).

Maintenance associations

Maintenance associations (MA) are associated with a single service instance (identified by the service VLAN identifier) within a maintenance domain (identified by the maintenance domain name). The combination of the maintenance domain name (if MD name format is not null) and the maintenance association name is called maintenance Association Identifier (MAID).

Maintenance end points

Maintenance End Points (MEP) are established on interfaces at each end of a maintenance domain. MEPs are configured for a specific MA within a maintenance domain to generate and receive Connectivity Fault Management (CFM) PDUs. Each individual MEP is configured with a MEPID that is unique within its MA. MEPs may be configured as Up MEPs or Down MEPs. MEPs may be addressed by the MEPID or by their port’s MAC address for Down-MEPs or by the shared bridge CPU MAC address for Up-MEPs.

Each individual MEP is configured with a MEPID that is unique within a given MA. MEPs may be configured as Up MEPs or Down MEPs. MEPs may be addressed by the MEPID or by their port’s MAC address for Down-MEPs or by the shared bridge CPU MAC address for Up-MEPs.

Maintenance intermediate points

Maintenance Intermediate Points (MIPs) may are not individually created by the user like MEPs are. When allowed, MIPs are automatically created on a port at the MD level above the highest level MEP (or in the lowest configured MD level if there is no MEP on the port). When an MA is created, it is provisioned to either enable or disable automatic creation of MIPs on that MA based on lower level MEPs. A MIP consists of two MIP Half Functions (MHFs) on a single bridge port; an Up MHF and a Down MHF. MIPs facilitate fault isolation. They can respond to, but do not initiate, certain OAM functions. For example, loopbacks may be initiated from a MEP which has detected a CC fault and targeted successively to each MIP at its level. MIPs may be addressed by their port’s MAC address for Down-MHFs or by the shared bridge CPU MAC address for Up-MHFs.

Service OAM configurations

An example application is a VLNC40/42/42B provider-owned demarcation point between customers and the provider’s network. This is Node 2 or Node 7 in Figure 5-6, Service OAM reference model. Each customer port may be provisioned to support a customer MIP and at least a provider Up-MEP, and if applicable an operator Up-MEP, for each Ethernet Virtual Connection (EVC). A link-level Down-MEP may be configured on both customer and network ports, with no VID, to protect the entire link.

Provider bridging (double tagging) is typically used. In that case, a customer MIP can only function if the customer supplies untagged Ethernet OAM frames, see MIP support, which get tagged with S-VLAN, otherwise the customer’s OAM traffic is tunneled. Refer to Table 5-8, Double tagging – All to one bundling and Table 5-9, Double tagging – Service multiplexed for more information. In Release 5.1, no VLAN translation of a customer’s tagged OAM traffic is supported, which would allow a customer’s OAM VLAN to be translated to the SVLAN. OAM for multiple EVCs (service multiplexing) is supported. Similarly, in that case only one of the EVCs on a port can support a customer MIP, the one which includes untagged traffic, see Table 5-9, Double tagging – Service multiplexed.

If double tagging is not used then a customer MIP may be supported in the default VLAN if the customer supplies untagged Ethernet OAM frames, or by agreement with the customer on a specific VLAN for OAM. See Table 5-7, No double tagging. The provider’s OAM also uses that same VLAN, representing the “service.”

MIP support

Whether and how a customer MIP can be supported depends on the tagging mode, and whether the customer OAM frames (only levels 5, 6 and 7 are designated for customer use) are tagged. Table 5-7, No double tagging through Table 5-9, Double tagging – Service multiplexed show, for the provider edge , the relation between customer OAM tagging and the Service VLAN to be used for configuring the MA. For example, Node 2 in Figure 5-6, Service OAM reference model. A customer MIP can only be supported (be accessible) in the provider’s equipment when the customer’s OAM frames have a single tag when forwarded to the CPU. When double-tagged, they are tunneled.

In the no double tagging (single tag) case Table 5-7, No double tagging, untagged customer traffic, including OAM, may be configured to be dropped or not. If not dropped, then certain untagged customer OAM traffic is tagged with the Port VID (which is the Service VLAN ID). This enables customer MIP support. The OAM traffic tagged this way includes traffic with a unicast DA, and with the OAM multicast DA at the customer levels.

Untagged customer OAM traffic at lower levels (0–4) may be destined to a no-VLAN Down-MEP there. Only OAM frames that encode the level in the DA are available to such a Down-MEP. This includes CCM, which is the only function needed by a Down-MEP on a customer port. This same consideration applies in the case of a LAG. Untagged customer-level OAM may address a customer MIP on the LAG port while at lower levels it can only belong to a no-VLAN Down-MEP on a member port.

Tagged customer OAM traffic in a particular VLAN can address a MIP on the port, and that VLAN is used by agreement for the provider’s Service VLAN ID. When there is no customer OAM, the Service VLAN ID for provider OAM can be any value to represent the customer’s service.

In the double tagging cases, the situation for untagged customer OAM traffic is the same as for the single tagging case when untagged traffic is not dropped. When Service Multiplexing is enabled, the Service VLAN ID is according to the Customer VLAN to Service VLAN mapping.

Tagging

Table 5-7: No double tagging

Customer OAM VLAN	Customer MIP supported?	Service VLAN ID
Untagged (untagged not accepted)	No	N/A
Untagged (untagged accepted)	Yes, in pvid	pvid
VLAN=X	Yes	X
No OAM	No	Any

Table 5-8: Double tagging – All to one bundling

Customer OAM VLAN	Customer MIP supported?	Service VLAN ID
Untagged	Yes, in default VLAN (pvid)	pvid
VID=X	No, tunneled	pvid

Table 5-9: Double tagging – Service multiplexed

Customer OAM VLAN	Customer MIP supported?	Service VLAN ID
Untagged	Yes, in only one EVC	As mapped with SVLAN
VID=X	No, tunneled	As mapped with SVLAN