|Publication number||US7975180 B2|
|Application number||US 12/655,108|
|Publication date||Jul 5, 2011|
|Filing date||Dec 23, 2009|
|Priority date||Jun 2, 2004|
|Also published as||US7644317, US20100146324|
|Publication number||12655108, 655108, US 7975180 B2, US 7975180B2, US-B2-7975180, US7975180 B2, US7975180B2|
|Inventors||Ali Sajassi, Norman W. Finn|
|Original Assignee||Cisco Technology, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (4), Referenced by (6), Classifications (10), Legal Events (1)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application is a continuation of application Ser. No. 10/858,810, filed Jun. 2, 2004, now U.S. Pat. No. 7,644,317 entitled, “Method and Apparatus for Fault Detection/Isolation in Metro Ethernet Service”, which is assigned to the assignee of the present application.
The present invention relates generally to the fields of digital communications systems and distributed computing. More specifically, the present invention relates to fault management (FM) for distributed computing systems and networks.
Fault detection deals with mechanisms that can detect both hard failures, such as link and node failures, and soft failures, such as software failures, memory corruption, mis-configuration, etc. Typically, a lightweight protocol is desirable to detect the fault and to verify the fault along the data path before taking steps to isolate the fault to a given node or link (e.g., diagnose the fault). Therefore, a fault isolation mechanism is also needed for fault management.
The problem of detecting hardware and software failures in a multipoint communications network, or in a distributed computing system, is very difficult to solve. By way of background, failure mechanisms for various network topologies and a proposed solution for a communications network are described in U.S. Pat. No. 6,732,189 entitled “Method and Apparatus for Fault Tolerant Tunneling of Multicast Datagrams”. U.S. Pat. No. 6,668,282 entitled “System and Method to Monitor and Determine if an Active IPSec Tunnel Has Become Disabled” teaches a technique for determining when communications through an Internet Protocol Security (IPSec) tunnel has failed, and steps for isolating the problem so it can be resolved.
Fault detection schemes for traditional wide area networks (WANs) such as Frame Relay (FR) and asynchronous transfer mode (ATM) networks are known in the prior art. For example, ATM networks commonly utilize a standard continuity check mechanism to detect hardware failures in the communications network with point-to-point connectivity. More difficult is the problem of resolving hardware and software failures in a multipoint communication network that allows each customer edge (CE) device or node to communicate directly and independently with all other CE devices in the same service instance via a single Attachment Circuit (AC) to the network. In a multipoint network, there are many paths that packet data units (PDUs) can travel.
Ethernet is a Media Access Control (MAC) layer network communications protocol specified by the Institute of Electrical and Electronics Engineers (IEEE) in IEEE specification 802.3 (the “802.3 specification”). Ethernet switched campus networks are an example of a multipoint service architecture. In the past Ethernet has been widely deployed in Local Area Networks (LANs). Today, Ethernet is migrating from LANs to metropolitan-area networks (MANs) and is becoming increasingly attractive to metro service providers (MSPs) because of its simplicity, flexibility, low cost, and quick time to service. From the standpoint of fault management, however, an Ethernet network poses an especially difficult problem because the MAC addresses that indicate the path that data packets travel gets “aged out” after a predetermined time interval (e.g., five minutes). In other words, the very information that is most useful for isolating faults in a multipoint network is transient by nature of the Ethernet protocol. Further complicating the problem is the fact that Ethernet services can be offered over a variety of transport mechanisms such as Ethernet PHY (802.3), SONET, ATM, FR, and multi-protocol label switching (MPLS)/Internet Protocol (IP)—e.g., an end-to-end Ethernet service for a customer can be offered over an Ethernet access network (an 802.1ad provider bridge network) on one side and a MPLS/IP access network on the other side.
Despite the problems inherent in providing a fault management mechanism (including fault detection) in carrier-class Ethernet services, MSPs still demand that Ethernet Virtual Connections (EVCs)—either point-to-point or multipoint—be protected by the same degree of fault management as existing ATM or FR virtual connections. Therefore, it is important to be able to detect and accurately isolate faults for any given Ethernet VC (or Service Instance) over any given transport type. Unfortunately, there are no existing solutions to the problem of fault management for Metro Ethernet (multi-point) services.
The present invention will be understood more fully from the detailed description that follows and from the accompanying drawings, which however, should not be taken to limit the invention to the specific embodiments shown, but are for explanation and understanding only.
A method and apparatus for both detecting and isolating hard and soft failures in Ethernet networks and services is described. In the following description specific details are set forth, such as device types, protocols, configurations, etc., in order to provide a thorough understanding of the present invention. However, persons having ordinary skill in the networking arts will appreciate that these specific details may not be needed to practice the present invention.
A computer network is a geographically distributed collection of interconnected subnetworks for transporting data between nodes, such as intermediate nodes and end nodes. A local area network (LAN) is an example of such a subnetwork; a plurality of LANs may be further interconnected by an intermediate network node, such as a router or switch, to extend the effective “size” of the computer network and increase the number of communicating nodes. Examples of the end nodes may include servers and personal computers. The nodes typically communicate by exchanging discrete frames or packets of data according to predefined protocols. In this context, a protocol consists of a set of rules defining how the nodes interact with each other.
Each node typically comprises a number of basic subsystems including a processor, a main memory and an input/output (I/O) subsystem. Data is transferred between the main memory (“system memory”) and processor subsystem over a memory bus, and between the processor and I/O subsystems over a system bus. Examples of the system bus may include the conventional lightning data transport (or hyper transport) bus and the conventional peripheral component [computer] interconnect (PCI) bus. The processor subsystem may comprise a single-chip processor and system controller device that incorporates a set of functions including a system memory controller, support for one or more system buses and direct memory access (DMA) engines. In general, the single-chip device is designed for general-purpose use and is not heavily optimized for networking applications. Additional memory devices, such as VRAM, flash memory, etc., may also be included in each node.
In a typical networking application, packets are received from a framer, such as an Ethernet media access control (MAC) controller, of the I/O subsystem attached to the system bus. A DMA engine in the MAC controller is provided a list of addresses (e.g., in the form of a descriptor ring in a system memory) for buffers it may access in the system memory. As each packet is received at the MAC controller, the DMA engine obtains ownership of (“masters”) the system bus to access a next descriptor ring to obtain a next buffer address in the system memory at which it may, e.g., store (“write”) data contained in the packet. The DMA engine may need to issue many write operations over the system bus to transfer all of the packet data.
Virtual Private Network (VPN) services provide secure network connections between different locations. A company, for example, can use a VPN to provide secure connections between geographically dispersed sites that need to access the corporate network. A Virtual Private LAN service (VPLS) is a bridged LAN service provided to a set of CEs that are members of a VPN. In a VPLS, the CEs that are members of the same VPN (e.g., the same VPLS service instance) communicate with each other as if they are connected via a bridged LAN. VPLS architecture thus delivers Layer 2 service that in all respects emulates an Ethernet LAN across a Wide Area Network (WAN) and inherits the scaling characteristics of a LAN.
The bridged LAN functionality of a VPLS is emulated by a network of Provider Edge (PE) devices or Provider Bridges (PB) to which the CEs are connected. This network of PEs (or PBs) can belong to a single network operator or can span across multiple network operators. A service provider (SP) is the entity responsible for providing Ethernet/VPLS service to its customers; whereas a network operator (or facility provider) provides the necessary facilities to the SP(s) in support of their services. A network provider and a service provider can be the same entity or they can be associated with different administrative organizations.
The four PE devices 20-23 act as a gateway between the Service Provider (SP) network 12 (e.g., MPLS/IP) and the customer domain. Pseudowires (PWs) 13-15 are shown connecting the VSIs of PEs 20, 21 & 23 so as to provide a full mesh of connections associated with the first service instance. Similarly, PWs 15-18 connect the VSIs of PEs 21-23 associated with the second service instance. A PW is a virtual connection that is bi-directional in nature and, in this example, may consist of a pair of unidirectional MPLS Virtual Circuits (VCs).
In accordance with the present invention, each maintenance end point (in this example, a PE edge device) broadcasts a message (referred to as a continuity check (CC) or heartbeat (HB) message) to the other edge PEs associated with a particular service instance at regular, periodic intervals. Accordingly, each edge device also receives the HB messages sent by the other edge PEs associated with that service instance. In the example of
Upon receiving the HB messages, the receiving Maintenance End Point (e.g., edge PE) compiles the received information in a catalogue table (typically a location in RAM) that is indexed by the MEP identification (ID). An example of such a catalogue table 72 is shown in
Note that each remote MEP of a given service instance is represented by an entry in catalogue table 72. Entries are initially created upon receiving the first HB message from the corresponding MEP or via configuration. In one implementation, a validity timer of 2.5 transmission intervals is maintained for each table entry. If the timer expires, then a fault for that remote maintenance end point is detected and subsequent fault verification and isolation procedures may be exercised.
It is also appreciated that table 72 may be updated dynamically in accordance with each new HB message received. By way of example, in the event that a particular network segment becomes unreachable, the Spanning Tree Protocol (STP) algorithm running on the Ethernet network may reconfigure the data path tree topology and re-establish the link by activating an appropriate standby path. In such a case, the ingress/egress port information associated with a particular node in the data path will change upon receiving the next HB message to reflect re-routing by the STP algorithm.
After a failure, the information stored in the catalogue table is not lost, as is normally the case with MAC addresses associated with an ordinary Ethernet VC. In other words, the catalogue table information does not get “aged-out” as is the case with the MAC Filtering Database (L2 forwarding table). Rather, each transient point (e.g., PE or Provider Bridge node) snoops the received HB message and stores the source MAC address along with the interface (i.e., ingress/egress) address information into a table in memory that is separate from the MAC Filtering Database. The information in the catalogue table may be used later during the fault isolation process, which aspect of the invention is described in more detail below.
It should be understood that the fault management mechanism of the present invention is applicable to cases in which the end-to-end service spans across different types of VPLS networks. For example,
As shown in
By way of further example,
With continued reference to
According to the present invention, fault detection is accomplished in this example by means of HB messaging from u-PE device 61 to u-PE device 51, and from u-PE device 51 to u-PE device 61. In other words, each of the u-PE devices 51 & 61 comprise maintenance end points that are responsible for origination and termination of periodic HB messages for that service instance. It is appreciated that these maintenance end points are located at the edge of their corresponding domains (i.e., domains 59 & 50). The HB messages use a multicast address that traverses through the data-plane (for data-plane integrity check).
Additionally, the HB messages can be snooped by the control plane (e.g., by the device's processor) of the Maintenance Intermediate Points (e.g., Agg-PEs & n-PEs) for building catalogue tables not impacted by the age-out feature of the conventional MAC Filtering Database. In the embodiment of
Practitioners in the art will appreciate that maintenance end and intermediate points correspond to a PE device, or to an interface of a PE device. For example, a HB message may be considered to originate from the u-PE processor or from an ingress interface of a u-PE device.
In an alternative embodiment, the concept of a network domain may be embedded in a field of the multicast MAC address of the HB messages. The domain field may be used to enable only the intermediate nodes that are part of the same domain to snoop and process the HB messages. The other intermediate nodes that are not part of the domain either pass or block the HB messages transparently depending on the domain hierarchy. In the embodiment of
In a domain hierarchy, each domain has its own set of Maintenance End Points (MEPs) and Maintenance Intermediate Points (MIPs). A MEP shall block (filter) fault management messages from a lower-level domain to enter its domain or conversely to let these messages to leak from its domain into a higher-level domain. Since domains are hierarchical as described above, the maintenance end and intermediate points that are associated with the domains become hierarchical as well. A MEP of a higher-level domain is always a MEP of a lower-level domain but the converse is not always true since the MEP of lower-level domain can either be MIP or a MEP of a higher-level domain. Furthermore, the MIPs of a lower-level domain are always transparent to the higher-level domain (e.g., OAM/FM messages of a higher-level domain are not seen by MIPs of a lower-level domain and get passed through them transparently).
By way of example,
According to one embodiment of the present invention faults associated with a given VPLS service instance are isolated utilizing a TraceRoute message or function. The TraceRoute message is a multicast message that is transmitted to all adjacent intermediate nodes on a hop-by-hop basis (see block 85 in
Each intermediate node also sends a response back to the originating maintenance point acknowledging that it was received and to report that a valid or “good” connection is established through that node. This step is shown occurring in block 86 of
It should be noted that in the above-described embodiment the source maintenance end point sends a single TraceRoute message to the next hop along the trace data path; however, it may receive many responses from different intermediate points along the trace path as a result of the message traversing hop-by-hop.
The concept of a domain ID may also be incorporated into the TraceRoute message (in addition to the HB message) to limit the scope or extent of these messages. In other words, a domain ID field in the TraceRoute message can be used to limit the extent over which the message may operate, not only on a per service instance basis, but also on a per network or localized basis.
Practitioners will appreciate that a variety of alternative implementations and embodiments may be realized in accordance with the present invention. For example, the TraceRoute message may be issued immediately (within a few minutes) following fault detection such that it gets exercised within the age-out window of MAC addresses in the Filtering database. That is, the TraceRoute message may traverse the data path by accessing the MAC address Filtering database, so long as the information in that database has not yet been aged out, i.e., erased. Another possibility is to maintain information about the destination maintenance end point at the intermediate points along the data path. This approach can be facilitated by the HB messages. In yet another implementation, visibility of the data path can be maintained at the source maintenance end point through the issuance of periodic TraceRoute messages prior to the occurrence or detection of a fault.
It should also be understood that elements of the present invention may also be provided as a computer program product which may include a machine-readable medium having stored thereon instructions which may be used to program a computer (or other electronic device) to perform a process. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnet or optical cards, or other type of machine-readable medium suitable for storing electronic instructions.
Additionally, although the present invention has been described in conjunction with specific embodiments, numerous modifications and alterations are well within the scope of the present invention. For instance, in yet another alternative embodiment, the TraceRoute message may include an additional field to indicate which intermediate node should respond (e.g., only nodes having a hop count of three or more should report or respond). This approach may be useful to more quickly isolate the fault location. It should also be understood that the Ethernet fault management scheme described above is not limited to VPLS system and can be applied to any general Ethernet bridged networks (e.g., a network that consists of bridge nodes—regardless whether the bridge nodes are u-PE/n-PE or PB). Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US7380154 *||Oct 12, 2004||May 27, 2008||Invensys Systems, Inc.||Method and apparatus for network fault correction via adaptive fault router|
|US7644317 *||Jan 5, 2010||Cisco Technology, Inc.||Method and apparatus for fault detection/isolation in metro Ethernet service|
|US7835265 *||Oct 31, 2002||Nov 16, 2010||Conexant Systems, Inc.||High availability Ethernet backplane architecture|
|US20030067871 *||Oct 8, 2002||Apr 10, 2003||Alcatel||Method for propagating the fault information in a RPR network and corresponding RPR packet|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8670299 *||Dec 29, 2010||Mar 11, 2014||Juniper Networks, Inc.||Enhanced service status detection and fault isolation within layer two networks|
|US8683275 *||Nov 16, 2011||Mar 25, 2014||International Business Machines Corporation||Controlling IPSec offload enablement during hardware failures|
|US8793542 *||Apr 11, 2013||Jul 29, 2014||International Business Machines Corporation||Controlling IPSec offload enablement during hardware failures|
|US9083613||Oct 16, 2012||Jul 14, 2015||Cisco Technology, Inc.||Detection of cabling error in communication network|
|US9143408||Jul 30, 2012||Sep 22, 2015||Hewlett-Packard Development Company, L.P.||Interprovider virtual private network path identification|
|US20130124930 *||May 16, 2013||International Business Machines Corporation||Controlling ipsec offload enablement during hardware failures|
|Cooperative Classification||H04L41/0659, H04L12/2852, H04L12/462, H04L43/10|
|European Classification||H04L12/46B7, H04L12/28M, H04L43/10, H04L41/06C1|