With the advent of connection-oriented forwarding technologies such as Provider Backbone Transport (PBT) and Provider Backbone Bridge (PBB), Ethernet is rapidly becoming a dominant broadband technology, particularly in metro networks and wide-area networks. With PBT, service providers are able to establish point-to-point and point-to-multipoint Ethernet tunnels and to specify paths that service traffic will take through their Ethernet networks. With PBB, service providers are able to separate a communications network into customer domains and service provider domains. The separation is achieved by encapsulating the customer packets within a backbone (i.e., service provider) MAC (Media Access Control) header. Network elements in the service provider domain forward packets based on the service provider MAC header while the customer header remains invisible except at the edge of the service provider domain.
As Ethernet services proliferate, service providers require a robust set of operation, administration, and maintenance (OAM) tools to manage their Ethernet networks and to adapt the Ethernet technology to a carrier-grade service environment. To this end, the IEEE (Institute of Electrical and Electronics Engineers) organization has formalized a standards document for connection fault management in Ethernet networks, referred to as IEEE 802.1ag (also known as Connectivity Fault Management or CFM). The ITU-T Recommendation Y.1731 also defines OAM functions and mechanisms for Ethernet-based networks much like the 802.1ag standard. In general, such standards specify managed objects, protocols, and procedures for, among other things, detecting and diagnosing connectivity faults in end-to-end Ethernet networks. Defined CFM mechanisms for fault detection include continuity check, linktrace (traceroute), loopback (ping), and alarm indication at different levels or domains (e.g., customer level, service provider level, and operator level).
The IEEE 802.1ag standard also defines various CFM entities and concepts, including maintenance domains, maintenance associations, and maintenance association end points. According to IEEE 802.1ag, a maintenance domain (MD) is “the network or the part of the network for which faults in connectivity can be managed”, a maintenance association end point (MEP) is “an actively managed CFM entity” that “can generate and receive CFM PDUs” (protocol data units or frames), a maintenance association (MA) is “a set of MEPs, each configured with the same MAID (maintenance association identifier) and MD Level, established to verify the integrity of a single service instance”, and a maintenance entity (ME) is “a point-to-point relationship between two MEPs within a single MA”. Additional details regarding such CFM entities are available in the IEEE 802.1ag/D8.1 draft standard, the entirety of which is incorporated by reference herein.
In metro Ethernet applications, connectivity across tunnels (also called connections) between MEPs is verified continuously through continuity check (CC) messages. A network element transmits such CC messages periodically at a variable interval, which can occur as often as once every 3 milliseconds. Typically, the generating and processing of such CC messages occurs centrally, that is, by a general-purpose central processing unit on a processor card in the network element. The line cards extract the frames of the CC messages from the data path and send them to the processor card. In effect, this frame extraction and forwarding concentrates the CC messages from all line cards at this central point.
Because many connections (e.g., PBB/PBT tunnels) can terminate on a given physical interface on the network element, the central processor can become overwhelmed by the real-time processing requirements for generating and checking these CC messages. For example, a network element that supports 640 G of service traffic and has a scaling requirement of 1000 MEs per 10 G lane can thus have 64000 MEs to manage, with the corresponding CC messages converging on the single central processor. With a minimum interval for a CC message being 3.1 ms, the central processor can conceivably need to generate a CC message every 48 ns. Even the fastest of today's CPUs would not measure up to the task. Consequently, the CPU would eventually lag behind with CC message generation and checking, thus eventually leading to false indicators of lost connectivity. Alternatively, multiple general-purpose CPUs can be used in parallel, but this configuration can be impractical with respect to area, power consumption, and cost.