Control plane failure recovery in a network

Label information used by a downstream LSR is mirrored on an upstream LSR. In particular, a copy of the label information database in the downstream LSR from LDP sessions is stored on the upstream LSR. The label information database and corresponding mirror are synchronized. The mirror is employed to facilitate recovery from control plane failure through comparison of the label information database with the mirror. For example, the intersection of the label information database and the mirror may be calculated and employed as the updated label information database and mirror.

FIELD OF THE INVENTION

The present invention relates generally to network communications, and more particularly to recovery from control plane failure in a communications network.

BACKGROUND OF THE INVENTION

Techniques for protecting and restoring services from network failures are well known. The techniques typically focus on failures in the data plane, although in some conventional networks the distinction makes little difference. SONET/SDH network failures, for example, necessarily imply simultaneous control plane and data plane failure because control messages and user information are transmitted together in frames. However, recently developed optical network architectures having separate control and data planes present difficulties. Known protection and restoration techniques may be employed with such optical networks to recover from faults in the data plane. However, these techniques appear to be less useful against control plane failure. It would therefore be desirable to have protection and restoration capability for the control plane.

SUMMARY OF THE INVENTION

In accordance with the present invention, selected control plane information is mirrored. The mirrored control plane information may be employed to facilitate restoration of the control plane in the event of failure. In one embodiment, connectivity resource information used by a first device is mirrored on a second device. For example, the information reflects the available channels of the link between the first device and the second device. The devices may be Label Switched Routers (“LSRs”), and the label information may be label tables employed in Multi Protocol Label Switching (“MPLS”). In particular, a copy of the label information database in a downstream LSR is stored on an upstream LSR. Label information that is lost to the downstream LSR can then be recovered from the upstream LSR in the event of control plane failure.

The present invention is advantageously scalable. The label information in each mirror includes only information regarding a specific link. In particular, a mirror in an upstream LSR includes label information only from a downstream LSR label database, although the upstream LSR may maintain multiple mirrors in order to support multiple downstream LSRs. Redundant storage of label information for the network is therefore distributed, thus enabling the network to be more easily scaled than would be possible with a dedicated label information storage device.

The present invention will now be described in more detail with reference to exemplary embodiments thereof as shown in the appended drawings. While the present invention is described below with reference to preferred embodiments, it should be understood that the present invention is not limited thereto. Those of ordinary skill in the art having access to the teachings herein will recognize additional implementations, modifications, and embodiments, as well as other fields of use, which are within the scope of the present invention as disclosed and claimed herein, and with respect to which the present invention could be of significant utility.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

FIG. 1illustrates a portion of an optical network. The network includes nodes such as Label Switched Routers (“LSRs”)10,12,14,16, and links38,40,41, containing one or multiple channels. The LSRs employ Multi-Protocol Label Switching (“MPLS”) to facilitate routing of traffic in Label Switched Paths (“LSPs”). Labels are distributed among the LSRs by employing a Label Distribution Protocol (“LDP”), such as constraint based routing LDP (“CR-LDP”). The LDP runs in the control plane of the network, which is physically separate from the data plane. In the illustrated example, the control plane runs over an Ethernet network18, while the data plane runs over a wavelength routed Dense Wavelength Division Multiplexing (“DWDM”) network (not illustrated).

Logically adjacent LSRs, such as LSR12and LSR14, communicate to establish common label information for transmitting traffic between them. Label information is exchanged between logically adjacent LSRs in LDP sessions20,22,24. For example, label information is exchanged between LSR12and LSR14in LDP session22. Each LDP session may include a plurality of LDP messages selected from four general types: Discovery messages, Advertisement messages, Session messages, and Notification messages. Discovery messages provide a mechanism whereby LSRs indicate their presence in a network, such as by periodically sending a “Hello” message. “Hello” messages are transmitted via UDP to the LDP port at the “all routers on this subnet” group multicast address. An LDP initialization procedure is employed via TCP transport to establish an LDP session with an LSR discovered via a “Hello” type discovery message. Upon successful completion of the initialization procedure, the two LSRs become LDP peers, and may exchange advertisement messages. Advertisement messages, such as requesting a label or advertising a label mapping to a peer, are transmitted by an LSR based on local decisions made by that LSR. In general, an LSR requests a label mapping from a neighboring LSR when needed, and advertises a label mapping to a neighboring LSR when it is determined that use of the label by the neighbor may be advantageous. Session messages are employed for the actual exchange of label information. Notification messages are employed to notify network events. For example, they are to notify peers about newly available/unavailable channels in the data plane.

Each LSR maintains a label information database (“LID”) containing the label information employed by that LSR. In the illustrated example, LSR12includes label information database26, LSR14includes label information database28, and LSR16includes label information database30. Each label information database includes mappings of labels associated with particular Label Switched Paths (“LSPs”).

Label Information Mirrors (“LIMs”)32,34,36are created in upstream LSRs to facilitate LDP recovery in the event of control plane failure. Each LIM is a copy of a label information database in a logically adjacent downstream LSR made via an LDP session. For example, LIM32in LSR10contains the label information from database26, LIM34in LSR12contains the label information from database28, and LIM36in LSR14contains the label information from database30. The LIMs may be employed to restore label information that is lost or corrupted in the corresponding label information database.

The LIMs are initialized contemporaneous with LDP session initialization. Type-Length-Value objects (“TLVs”) may be employed in the LDP Session Initialization message to facilitate initialization. In particular, an Advertisement of Mirror of Label Information TLV, and an Advertisement of Label Information Database TLV may be employed. The Advertisement of Mirror of Label Information TLV is operative to notify the downstream LSR peer about the contents of the LIM stored in the upstream LSR. The Advertisement of Label Information database TLV is operative to notify the upstream LSR peer about the contents of the label information database stored in the downstream LSR.

Following initialization, each LIM is synchronized with the corresponding downstream label information database. When LSR14assigns a label, upstream LSR12updates its corresponding LIM34after receiving a LDP Label Mapping message from the downstream LSR peer14. Consequently, both the LIM34and the label information database28are synchronized after the LSP setting up phase. In the LSP tearing down phase, the upstream LSR12updates its LIM34when it sends an LDP Label Release message to the downstream LSR peer14. In this way, both the LIM34and the label information database28are synchronized after the LSP tearing down phase. The upstream LSR12also maintains the LIM34when it receives an LDP Notification message from the downstream LSR peer14. Consequently, in any stable state of the LDP operation, the LIM34and the label information database28are synchronized.

FIG. 2illustrates control plane failure and recovery from link failure. When the control channel failure occurs between LSR12and LSR14, the LDP session20closes. Neither the LIM34(FIG. 1) residing in LSR12nor the label information database28(FIG. 1) residing in LSR14are emptied. After the failure of the control channel is repaired, LSR12re-initializes the LDP session with LSR14. The contents of the LIM in LSR12are transmitted to LSR14in an LDP Session Initialization message. LSR14compares the contents of the LIM to its own label information database and calculates the intersection. LSR14then updates its label information database as the intersection calculated. LSR14then transmits the calculated intersection back to LSR12in an Advertisement of Label Information Database TLV. Upon receiving the Advertisement of Label Information Database TLV in the LDP Session Initialization message from LSR14, LSR12updates its LIM as the TLV indicates. Hence, the label information is recovered and the user data communication is not be interrupted.

Generally, the mirror in LSR12and the label information database in LSR14are synchronized in any stable state of LDP operation prior to control channel failure. When LSR14calculates the intersection of its own label information database and the advertised mirror of label information of LSR12, the result is identical to either of them. However, when the control channel failure happens before the LDP operation reaches a stable state, their contents could be slightly different.

Referring toFIGS. 1 and 3, when a LSR is reset and re-initialized, the LIM and the label information database stored in it are set according to actual network configuration. After a single control node failure at LSR12, the following recovery steps facilitate reset and re-initialized:1. LSR12initializes both its LIM34and its label information database26according to actual network configuration.2. LSR12sends an LDP Session Discovery message (“Hello” message) to LSR10through the link38between them.3. LSR10advises LSR12about the contents of its mirror32in the LDP Session Initialization message.4. LSR12compares the contents of the mirror32with its own label information database26and calculates the intersection.5. LSR12updates its label information database26as the calculated intersection.6. LSR12sends the intersection back to LSR10in an Advertisement of Label Information Database TLV.7. Upon receiving the Advertisement of Label Information Database TLV in the LDP Session Initialization message from LSR12, LSR10updates its LIM32as the TLV indicates, at which point the label information database26in LSR12is recovered and synchronized with its mirror32.

In parallel with steps2–7, LSR12also recovers its LIM34corresponding to its outgoing links. In particular:1. LSR12sends an LDP Session Discovery message (“Hello” message) to the LSR14through the link40between them.2. LSR12advised LSR14about the contents of its LIM34in the LDP Session Initialization message. (The contents of its mirror of label information matches the actual link configuration between them.)3. LSR14compares the contents of the LIM34with its own label information database28and calculates the intersection.4. LSR14updates its label information database28as the calculated intersection. (This should not affect the contents of its label information database, because the advertised LIM34is a superset of its label information database.)5. LSR14sends the intersection back to LSR12in an Advertisement of Label Information Database TLV.6. Upon receiving the Advertisement of Label Information Database TLV in the LDP Session Initialization message from LSR14, LSR12updates its mirror of label information as the TLV indicates. (Now the mirror of label information in LSR12is recovered and synchronized with its counterpart.)

FIG. 4illustrates LSR12(FIG. 1) in greater detail. LSR12has one incoming link42and one outgoing link44. There is one downstream side LDP entity46corresponding to each incoming link. And each downstream side LDP entity46has a private label information database48. Consequently, label information is stored on a per link basis. Similarly, there is one upstream side LDP entity50corresponding to each outgoing link44. And each upstream side LDP entity50has it own mirror of label information (LIM)52. Consequently, the label information database48has meaning with respect to only one LDP entity46and one link42. Similarly, the mirror of label information52has meaning with respect to only one LDP entity50and one link44. Different LDP entities in one LSR may employ different TCP/UDP port numbers to communicate with peers.

In an alternative embodiment, the present invention could be employed with a centralized recovery mechanism. The centralized recovery mechanism could be beneficial for inter-domain recovery. More particularly, if the control plane of a whole domain fails, and some kind of centralized control plane backup is provided for that domain, the control information can be recovered through a centralized method.

The present invention may also be employed to facilitate protection and restoration of control channels by using backup control channels. If recovery from failures in the control plane can be accomplished by using backup control channels, LDP sessions will not sense the failures and will not take any recovery action. Recovery by backup control channels may be preferable, in general. If the control plane cannot be recovered within a time bound, the TCP and LDP layer would then take action.

The present invention is not to be limited in scope by the specific embodiments described herein. Indeed, various modifications of the present invention, in addition to those described herein, will be apparent to those of ordinary skill in the art from the foregoing description and accompanying drawings. Thus, such modifications are intended to fall within the scope of the following appended claims. Further, although the present invention has been described herein in the context of a particular implementation in a particular environment for a particular purpose, those of ordinary skill in the art will recognize that its usefulness is not limited thereto and that the present invention can be beneficially implemented in any number of environments for any number of purposes. Accordingly, the claims set forth below should be construed in view of the full breadth and spirit of the present invention as disclosed herein.