GB2359445A - High availability label distribution protocol for label switched networks - Google Patents

Abstract

The Label Distribution Protocol (LDP) specified by the IETF for the distribution of labels between Label-Switched Routers (LSRs) in a label-switched network uses a TCP session between LSR peers in order to distribute labels. TCP is notoriously difficult and inefficient to implement in a fault-tolerant manner, which means that LDP is not suitable for to use in a system that requires high-availability of the label distribution service. This also applies to the constraint-based variant of LDP, CR-LDP, also specified by the IETF, as it inherits the use of TCP sessions between LSR peers from the base LDP specification. The present invention enhances the LDP specification to allow LSR peers to recover from hardware or software faults that cause a failure of the TCP session between the LSR peers without the need for either peer to implement a fault-tolerant version of TCP.

Description

2359445

TITLE OF THE INVENTION:

HIGH-AVAILABILITY LABEL DISTRIBUTION PROTOCOL FOR LABEL-SWITCHED NETWORKS BACKGROUND OF THE INVENTION

Field Of The Invention

The present invention relates to the field of label-switched networks. More specifically, the present invention relates to the problem of providing a high-availability service for label distribution between peer label-switched routers (LSRs) using an enhanced version of the Label Distribution Protocol (LDP) specified by the IETR

Description of Prior Art

The LDP specification enables peer LSRs to exchange labels that can subsequently be used to forward traffic across the label-switched network. CR-LDP extends the base LDP specification to allow the provision of label switched paths (LSPs) that are routed across the label-switched network subject to various constraints imposed by the LSR that initiates an LSP.

LDP uses TCP to provide the transport connection between peer LSRs. However, LDP requires that an LSR immediately cease to use any labels obtained from a peer to which the TCP session has failed. Unfortunately many TCP implementations are unable to preserve TCP sessions across the following events or failures:

0 Swapping the running copy of a component that uses TCP, such as the label distribution component of an LSR, for a different version of that component.

2 Fail-over of the primary copy of a component that uses TCP to the backup copy of that component after a hardware or software fault renders the primary copy unusable.

& Fail-over or upgrade of the TCP component itself.

These restrictions on TCP implementations mean that LDP is currently unsuited to the provision of a highly available label distribution service. Since CR-LDP inherits the use of a TCP session between LSR peers from the base LDP specification, it is also unsuited to the provision of a highly available constraint-based LSP provision service. The LDP and CRLDP availability issues could be solved using a TCP implementation that is fully fault-tolerant, but such support is notoriously difficult and inefficient to provide owning to the need to duplicate all traffic on the TCP sessions to the backup instance of WP in case it needs to be retransmitted. In some operating systems it may also be impossible to transparently swap a TCP session from the primary copy of a component to the backup copy of that component.

References US patents 4726027, Nakarnura et al., 1988.

5027269, Grant et al, 1991.

5881239, Desgrousilliers, 1999.

5235597, Himwich et al, 1993.

5768256, Allen et al, 1998.

Other References Corner, 1nternetworking with TCP/IP Vol 1: Principles, Protocols and Architecture", 3 d edition, pp 19 1 227, Prentice Hall, 1995.

Andersson et al, "LDP Specification", Internet draft: draft-ietf-mpls-ldp06, Oct 1999 (work in progress).

Janioussi, "Constraint-Based LSP Setup using LW', Internet draft: draftietf-mpls-cT-Idp-03, Sep 1999 (work in progress).

Kauffflan et al, "Network Security: PRIVATE communication in a PUBLIC world", pp 129-162, Prentice Hall, 1995.

3 BRIEF SUMMARY OF THE INVENTION

The present invention enhances LDP to allow peer LSRs to recover from the failure and subsequent reconnection of the TCP session. This allows LIDP to be deployed in environments with a requirement for high availability systems, such as telecommunications systems and Intemet service provider backbone networks.

The present invention has the following advantages over prior art:

0 The present invention allows the label distribution service between two peer LSRs, and all LSPs established between two peer LSRs, to survive across hardware or software faults or across a software upgrade on one or both of the LSRs.

0 The present invention does not require that the TCP implementation be tolerant of hardware or software faults or that it be capable of transparently switching a TCP session from the primary copy of LDP to the backup copy of LDR 0 The present invention does not require the provision of protection switching or re-routing within the network for the TCP session traffic between the LSRs as the label distribution state can be recovered when the session is reconnected after a failure.

4 BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows the components of the preferred embodiment of a system that can provide a highly available label distribution service between two peer LSRs.

FIG.2 shows additional details of how high availability of the label distribution service is achieved across a software upgrade to the TCP stack.

Reference Numerals in the Drawings System Components:

LSR 1:

LSR 2:

110:

120:

121:

130:

141:

142:

143:

210:

220:

230:

241:

242:

243:

300:

First label-switched router node within a label-switched network. Second label-switched router node within a label-switched network. Label distribution component within LSR 1. TCP Stack within LSR 1. Replacement version of TCP stack within LSR 1. Label data forwarding component within LSR 1.

network port connecting LSR 1 to the label-switched network.

network port connecting LSR 1 to the label-switched network.

network port connecting LSR 1 to the label-switched network. Label distribution component within LSR 2. TCP Stack within LSR 2. Label data forwarding component within LSR 2.

network port connecting LSR 2 to the label-switched network.

network port connecting LSR 2 to the label-switched network.

network port connecting LSR 2 to the label-switched network. The labelswitched network. Message Flows: 101: Sockets interface giving 110 access to TCP sessions via 120. 102: Message-based interface allowing 110 to program the behavior of 130.

103: Sockets interface giving 110 access to TCP sessions via 12 1.

201: Sockets interface giving 210 access to TCP sessions via 220.

202: Message-based interface allowing 210 to program the behavior of 230.

400: TCP session carrying LDP traffic between 120 and 220.

401: TCP Session carrying LDP traffic between 121 and 220.

DETAILED DESCRIPTION OF THE INVENTION

This description covers a method for providing a highly available label distribution service between peer LSRs. In the description, there are set forth, for purposes of explanation, many specific details, to provide the reader with a thorough understanding of the invention. It will be obvious to one sUled in the art that the invention may be practiced without these details. Furthermore, certain devices and orders of processing are given in the diagrams and the description, to make understanding the invention easier. It will, again, be apparent to one skilled in the art that the specific devices and sequences are merely illustrative and may be varied whilst remaining within the spirit and scope of the present invention.

Description of the Preferred Embodiment

What follows is a description of the preferred embodiment of the present invention. Other possible embodiments will be discussed later.

All system components shown in FIG. 1 may support fault tolerant operation via use of primary and backup instances of the component. For clarity, FIG. 1 shows only one instance of each system component. FIG.2 shows two instances of the TCP stack in LSR 1, and is used later in this section to show how the present invention handles a failure of the TCP session between peer LSRs caused by a software upgrade to the TCP stack.

With reference to FIG. 1, the preferred embodiment of a highly available label distribution system between two peer LSRs comprises the following components listed below.

0 The peer LSRs, LSR 1 and LSR 2.

0 The label distribution software component, 110, on LSR 1.

0 The label distribution software component, 210, on LSR 2.

6 The TCP stack, 120, on LSR 1. This component exposes a Sockets interface, 101, through which 110 exchanges LDP message flows with 210.

The TCP stack, 220, on LSR2. 220 exposes a Sockets interface, 201, through which 210 exchanges LDP message flows with 110.

0 The label data forwarding component, 130, on LSR 1. 130 exposes an interface, 102, through which programs the behavi or of 13 0.

0 The label data forwarding component, 230, on LSR 1. 230 exposes an interface, 202, through which 210 programs the behavior of 230.

0 The label-switched network, 300, to which LSR 1 is connected via a plurality of network interfaces of which 141, 142 and 143 are shown, and to which LSR 2 is connected via a plurality of network interfaces, of which 241, 242 and 243 are shown.

0 Th e TCP session, 400, between 120 and 220 that carries the LDP message traffic between LSR 1 and LSR 2.

Enhancements to the LDP specification

The preferred embodiment of the present invention makes the following enhancements to the LIDP specification. Collectively, these enhancements are referred to below as the LDP FT enhancements.

FT Labels The LDP FT enhancements introduce the concept of a fault-tolerant label for which the LSR peers retain state information beyond the lifetime of a particular instantiation of the TCP session between the LSR peers. Such labels are referred to below as FT labels. Labels for which this behavior is not available, or not used for a particular label, are referred to below as non-FT labels.

Preservation of FT Label state information A LSR that determines that the LDP FT enhancements are to be used on the TCP session to a peer LSR must ensure that the state information for FT labels exchanged with the peer LSR is not automatically released when the TCP session fails.

The LIDP FT extensions require that a LSR release the label state information for labels that were exchanged with a peer to which the TCP session has failed, and releases all resources associated with that label state information, in the following circumstances:

7 The TCP session is reconnected but the exchange of LDP initialization messages on the new session indicates that the LDP FT enhancements cannot be used on the new TCP session.

The TCP session is reconnected but the exchange of LDP initialization messages on the new session indicates that, although the LDP FT enhancements may be used on the new TCP session, the peer LSR has not preserved state for FT labels exchanged on the previous instantiation of the TCP session.

The TCP session to the peer LSR is not successfully reconnected within an implementationdefined timeout period.

FT Session Flag and FT State Flag These two flags are carried in the LDP initialization message sent by an LSR and have the following meanings. The FT Session Flag identifies that the sending LSR supports the LDP FT enhancements. The FT State Flag indicates that the sending LSR has preserved state for FT labels exchanged with the receiving LSR since the TCP session between them was last initialized correctly. The FT State Flag is ignored if the FT Session Flag is not set (= 1).

The base LDP specification defines active and passive roles for peer LSRs during initialization of the LDP session between the peers. LDP initialization is commenced by the active LSR sending a LDP initialization message to the passive LSR.

If the passive LSR receives a LDP initialization message in which the FT Session Flag is set, but the LSR does not support use of the LDP FT enhancements, the LSR must reject the LDP initialization message using the unrecognized/unsupported TLV response code in a Notification message, as specified in the base LDP specification. The active LSR may subsequently retry the TCP session connection omitting the unsupported TLV, as specified in the base LDP specification.

If the passive LSR receives an LDP initialization message in which the FT Session Flag is not set (= 0), or is omitted, the passive LSR must make no further use of the LDP FT enhancements even if it supports use of the LDP FT enhancements. Any FT label state information that the passive LSR has retained from previous instantiations of the TCP session to the active LSR must be released.

If both active and passive LSRs support use of the LDP FT enhancements, the passive LSR may only set the FT State Flag in its LDP initialization message if the FT State Flag was set (= 1) in the LDP initialization message sent by the active LSR. If either LSR does not set the FT State Flag, both LSR peers must release and FT label state information retained from previous instantiations of the TCP session between the LSR peers.

8 0 FT Default Flag The FT Default flag is carried in the LDP initialization message sent by a LSR and indicates whether the LSR wishes labels exchanged between the LSR peers on this TCP session to be treated as FT labels by default. If the FT Default Flag is set (= 1), all new labels must be treated as FT labels unless specifically overridden for a specific label by the Label FT flag (see below). If the FT Default Flag is not set (= 0), all new labels must be treated as non-FT labels unless specifically overridden for a specific label by the Label FT flag (see below).

The value of the FT Default Flag determined during LDP initialization of a new instantiation of the TCP session between peer LSRs does not affect the FT/non-FT nature of labels that were exchanged between the peer LSRs on previous instantiations of the TCP session between the same peer LSRs.

The value of FT Default Flag for the TCP session between LSR peers is determined by the setting of the FT Default Flag in the LDP initialization message sent by the active LSR.

0 FT Session Timeout The FT Session Timeout is the maximum period of time for which an LSR using the LDP FT enhancements preserves state information for FT labels that were exchanged on previous incarnations of a failed TCP session. If the TCP session to the peer LSR is not reconnected within the FT Session Timeout period, an LSR must release all state information for FT labels that were exchanged on previous instantiations of the TCP session.

FT Session TLV A new TLV, the FT Session TLV, is carried on LDP initialization messages. This TLV has a new type value, 0x0503, and carries 4 bytes of data.

The first two bytes of data contain flags for the session and have the following encoding. The mostsignificant bit (0x8000) of this data carries the FT Session Flag, the second most-si gnifi cant bit (0x4000) carries the FT State Flag, and the third most-signifi cant bit (0x2000) carries the FT State Flag. All other bits in this TLV are currently reserved for future expansion The second two bytes of this data contain the FT Session Timeout, represented as a 16-bit unsigned integer indicating the number of seconds.

FT Label Qperation If a label exchanged between two peer LSRs is a FT label, either because this is explicitly requested using the Label FT flag (see below) or because the FT Default Flag is set for the TCP session, the LSR 9 peers must ensure they are able to complete any operation on the label that is interrupted by the failure and subsequent reconnection of the TCP session between them. This is achieved by requiring each LSR to preserve enough state information about any message it has sent to the peer LSR that has not been appropriately acknowledged so as to be able to reissue the message to complete the label operation if it is interrupted by a TCP session failure.

The type of acknowledgement used for each message is given below.

A Label Request message is acknowledged using a Label Mapping message, to successfully return a label, or a Notification message giving the reason for the failure of the Label Request.

A Label Mapping messages that is sent in response to a Label Request in ordered label distribution mode has no response as it forms the response to the Label Request.

A Label Mapping message that is sent in downstream unsolicited label distribution mode is acknowledged using a Notification message containing an OK response code or giving the reason for the failure of the Label Mapping. The peer LSR is not required to make use of use the label specified in a downstream unsolicited Label Mapping message, but it must acknowledge the Label Mapping message if it is an FT label.

A Label Withdraw message is acknowledged using a Label Release message, as specified in the base LIDIP specification.

A Label Release message that is sent in response to a Label Withdraw has no response as it forms the response to the Label Withdraw.

A Label Release messages that is sent other than in response to a Label Withdraw message is acknowledged using a Notification message containing an OK response code or giving the reason for the failure of the Label Release.

When the TCIP session between two LSR peers is reconnected, any Label Request, Label Mapping, Label Release or Label Withdraw message that was unacknowledged and needed to be acknowledged before the TCP session failed must be reissued by the LSR that sent the original message.

The LSR that receives a reissued message may have previously sent an acknowledgement to the original message, but that acknowledgement was lost during the TCP session failure. When a LSR receives a reissued message, it either returns a duplicate of the acknowledgement it had sent previously, or it processes the request as normal if it had not received the original message.

0 Label FT Flag The Label FT Flag indicates whether a label is to be protected using FT operation. If the Label FT Flag is set (= 1), the label is a FT label and all operations on the label must be protected using the FT Label Operation mechanism specified above. If the Label FT Flag is not set (= 0), the label is a nonFT label.

If the LDP FT enhancements are in use on a TCP session, this flag is optionally carried on all Label Request messages or downstream unsolicited Label Mapping messages. If the Label FT flag is not present on the original Label Request or downstream unsolicited Label Mapping message for a given label or LSP, both LSRs use the value of the FT Default Flag for the TCP session to determine whether the label is an FT label.

0 FT Duplicate Flag When a message is reissued, or an acknowledgement is sent in response to a reissued message, the FT Duplicate Flag must be set (= 1) on the reissued message or acknowledgement. This enables the receiving LSR to determine that the message is a correctly issued duplicate required for FT operation as opposed to an incorrect duplicate message. The FT Duplicate Flag, if present, must be set to 0 on messages that are not reissued.

Label FT TLV The Label FT TLV carries FT options for a label. This is a new TLV of type 0x0304 and carries 4 bytes of data. The most-significant bit (0x80000000) carries the Label FT Flag and the second mostsignificant bit (0x40000000) carries the FT Duplicate Flag. All other bits in this TLV are reserved.

The Label FT TLV may be optionally present on the original Label Request or downstream unsolicited Label Mapping message for a given label or LSP. The Label FT TLV must be present on any reissued message or acknowledgement.

Example Use of Label FT Enhancements With reference to FIG. 2, the present invention enables two peer LSRS to provide continuous operation across the upgrade of the TCP Stack in LSR 1, even when the TCP Stack implementation in LSR 1 does not allow for software upgrades to occur transparently to users of the TCP Stack. The LDP FT enhancements allow LSR 1 and LSR 2 to continue to provide an uninterrupted label data forwarding service and to recover the state of all labels exchanged between the peer LSRs, as listed in the example below:

LSR 1 is the active LSR. The label distribution component on LSR 1, 110, brings up the first instantiation of the TCP session, 400, between LSR 1 and LSR 2, using the Sockets interface 10 1, and 11 0 0 0 0 0 sends an LDP initialization message on the new TCP session. 110 sets theFT Session Flagin theLDP initialization message. 110 does not set the FT State flag because it has no preserved state as this isthe first instantiation of the TCP session with LSR 2. 110 sets the FT Default Flag to request that all labels exchanged between LSR 1 and LSR 2 are treated as FT labels.

The label distribution component on LSR2, 210, receives notification of the new TCP session via the Sockets interface, 201. 210 supports the LDP FT enhancements and replies tothe LDP initialization message sent by LSR 1 with an LDP initialization message with the FT Session Flag set. 210 does not set the FT State Flag in the LDP initialization message it sends as, like 110, it has no preserved state for the new TCP session. 210 sets the FT Default flag to the same value as it received from 110. The LDP session between LSR 1 and LSR 2 has now been initialized successfully and uses the LDP FT enhancements.

issues a Label Request to 2 10 via 10 1. This is transported via 400 and received by 210 via 20 1. 2 10 assigns label A to satisfy this request and uses 202 to program the label data forwarding component, 230, on LSR 2 to use the new label. 210 then returns a Label Mapping message, via the same route, specifying that the label has been assigned to have value A.

Similarly, when 2 10 subsequently issues a Label Request to 110, 110 assigns label B to satisfy this request and uses 102 to program the label data forwarding component, 130, on LSR 1 to use the new label. 110 then returns a Label Mapping message, via 101, 400 and 201, specifying that the label has been assigned to have value B. then issues an unsolicited Label Mapping message for a new label, label C, to 210 via 101, 400 and 201. 210 receives this message and sends a Notification message via 201 to acknowledge the Label Mapping to 110. However before 220 can send this message, a software upgrade of the TCP stack on LSR 1, 120, is started in order to replace it with an updated version, 12 1. Since 120 does not support transparent software upgrade, it must bring down the TCP session, 400, in order to allow the upgrade to complete. The failure of 400 is notified to 110 and 2 10 by 101 and 201 respectively. 110 and 210 preserve state for labels A, Band C because these labels were assigned as FT labels. 110and 210 start a timer using the FT Session Timeout value awaiting reconnection of the TCP session.

Label data forwarding by 130 and 230 for the installed labels A and B continues unaffected by the software upgrade to 120.

attempts to reconnect to 210. 110 uses the sockets interface, 103, to the new TCP stack, 121, to request a TCP session to 210. 121 brings up the new instantiation of the TCP session, 401, to 220, which informs 210 of the new session, via 20 1.

12 LDP initialization proceeds as for the previous instantiation of the TCP session, except that this time both 110 and 210 set the FT State Flag because they have preserved state.

and 210 do not need to exchange any messages for labels A and B because no label operations for these labels were in progress at the time of the TCP session failure. Label data forwarding by 130 and 230 for the installed labels A and B continues unaffected.

0 0 a 0 0 detects from the preserved state information that it was awaiting an acknowledgement from 210 on the Label Mapping for label C. It reissues the Label Mapping request for label C to 210, via 103, 401 and 201, marking the Label Mapping with the FT Duplicate Flag because this is a reissued message, 2 10 receives the reissued Label Mapping request and matches this to the state information it has preserved for Label C. Since the FT Duplicate Flag is set in the Label Mapping, 210 does not reject the Label Mapping as an erroneous duplicate but returns a Notification message to 110 with the FT Duplicate Flag set as acknowledgement of the Label Mapping. This completes the Label Mapping exchange between 110 and 210 that was interrupted by the failure of the TCP session between LSR 1 and LSR 2.

If the TCP session had failed before the Label Mapping for label C was received by 210, 2 10 would have no preserved state information for label C and hence would treat the reissued Label Mapping as if it were a new request and process it normally. The FT Duplicate Flag is ignored if the receiving LSR has no preserved state for the requested operation.

If multiple label operations were outstanding between LSR 1 and LSR 2 at the time of the failure of the TCP session, each operation would be completed separately using the appropriate reissued messages and acknowledgements sent in response to these reissued messages.

If the upgrade of 120 to 121 did not complete within a reasonable time, and the session could not be reconnected within the FT Session Timeout, both 110 and 210 would release the state information and resources associated with labels A, B and C on expiry of the FT Session Timer. When the FT Session Timer expires, 110 and 2 10 use 102 and 202 to deprograrn 130 and 230, respectively, and release any label data forwarding resources associated with these labels.

The LDP FT enhancements can also provide fault-tolerance for FT labels across other forms of failure or fault on the TCP session, or failures or software upgrades to the label distribution components in LSR 1 and LSR 2, provided that the label state information held by 110 and 120 for FT labels is preserved across the failure or upgrade.

Description of Alternative Embodiments

What follows is a description of some alternative embodiments of the present invention. One skilled in the art will easily be able to envisage other alternative embodiments of the invention.

It should be noted that the section titled "Detailed Description of the Invention" is simply a description of the preferred and some additional embodiments of the invention; the full scope of the invention is determined by the claims. A systems engineer skilled in the art of developing fault-tolerant distributed computing systems, based on the claims and the detailed description, should be able to implement a wide variety of systems for high-availability label distribution systems that are significantly advanced compared with the current state of the art.

Encoding of Flags and TLVs The encoding of the following flags, timeouts and TLV type values given in the description of the preferred embodiment above, and the assignment of flags and timeouts to specific TLV types may vary in alternative embodiments of the present invention. The values and TLV assignments given in the preferred embodiment are just one example of suitable values that would allow correct interoperation of LSRs supporting the Label FT enhancements and back-compatible operation with LSRs that support the base LDP specification only.

Fault Tolerance of System Components The components of the preferred embodiment of the present invention can be implemented with varying degrees of fault tolerance according to the requirements and capabilities of the hardware and operating system. The present invention does not require that all components are implemented with the same degree of fault tolerance or that LSR peers are implemented using the same fault tolerance strategy.

Some alternative embodiments, and the faults that each can recover from, include the following variations:

0 0 If no system components are implemented using fault-tolerance techniques, the LDP FT enhancement can still provide the ability for LSR peers to recover from network or TCP faults or TCP software upgrades that cause a failure of the TCP session between the LSRs provided that both peer label distribution components continue running until the TCP session is restored.

If the label distribution component of an LSR is implemented using primary and backup copies to provide fault-tolerance, but the TCP stack in this LSR is not faulttolerant, the LDP FT enhancements enable the peers to this LSR to recover from faults in, or upgrades to, the label distribution component in this LSR in addition to network and TCP failures or TCP software upgrades.

14 Even if the label distribution components and the TCP stacks in two LSRpeers all employ primary and backup copies to provide fault tolerance, the LDP FT enhancements can still be used to recover from network faults that would cause the base LDP specification to release all state information for labels exchanged between the peer LSRs.

Interfaces Between Components The preferred embodiment uses Sockets for the interface between the label distribution component and the TCP stack, as this is a widely deployed TCP interface, and an asynchronous message-passing interface between label distribution and label data forwarding. Some alternative embodiments may use interfaces with different syntax or semantics.

Acknowledgement Strategy The preferred embodiment uses an acknowledgement strategy that minimizes the number of message exchanges required to complete a label operation. Some alternative embodiments may use a different acknowledgement strategy, such as any combination of the following.

0 0 Acknowledgements may be sent to all Label Mapping messages, including those Label Mapping messages that are sent in response to a Label Request. This would mean that all Label Mapping messages are acknowledged, which may ease the implementation of the LDP FT enhancements in some systems at the expense of introducing some unnecessary additional acknowledgements.

Similarly, acknowledgements could be issued for all Label Release messages, including those that are sent in response to a Label Withdraw message.

State Synchronization The preferred embodiment of the present invention allows a LSR to assume after reconnection of the TCP session to a peer LSR that the state information it has preserved for a label for which no label operation was in progress at the time of a TCP session failure is correctly synchronized with the state information on the peer LSR, provided that both LSRs set the FT State Flag during LDP initialization. Some alternative embodiments may provide additional mechanisms for verifying that this assumption is valid, including the following possible techniques:

Explicitly reissuing Label Mapping messages on a regular, timed basis to ensure that the attributes of each label are synchronized between LSR peers.

Use of digital certificates and signatures to authenticate that the TCP session has been reconnected to the correct LSR peer.

Choice of FT Session Timeout The value of the FT session Timeout chosen by an LSR may be determined in different ways by some alternative embodiments. Some alternative strategies for determining the value of this timeout include the following:

The value of the FT session Timeout can be chosen independently by the peer LSRs provided that they both correctly set the FT State Flag during LDP initialization. If the value of the FT Session Timeout is chosen independently by each LSR peer, it need not be carried in the FT Session TLV.

0 The FT Session Timeout may be obtained from local configuration information.

The FT Session Timeout may be determined algorithmically from locally configured characteristics of the network that connects two peer LSRs, such as the data rate of the connection between the peers across the network.

The FT Session Timeout may be determined dynamically from observations of the characteristics, in particular the round-trip time, of the connection between peer LSRs.

0 The FT Session Timeout may be obtained from a store of network configuration information, such as a X.500 directory server.

16

Claims (12)

CLAIMS We claim:

1. A method for enhancing the Label Distribution Protocol, specified by the IETF and hereafter referred to as the base LDP specification, to allow high-availability operation of the logical connection between the label distribution component on a pair of peer nodes in a label switched network, said method referred to hereafter as the LDP FT extensions and said method comprising of the steps of a. first means of negotiating the use of said LDP FT extensions on said logical connection between said peer nodes, with automatic fall-back to the use of said base LDP specification on said logical connection if said label distribution component on either of said peer nodes does not support said LDP FT extensions second means of preserving state information and resources for the labels exchanged by said peer nodes across a failure of said logical connection so that the forwarding of data according to the labels exchanged between said peer nodes is not automatically discontinued when said logical connection fails c. third means of said label distribution component of first said peer node identifying to said label distribution component on second said peer node whether first said peer node has preserved said state information and resources for said labels after a failure and the subsequent reconnection of said logical connection fourth means of ensuring that said label distribution component of said peer nodes can complete a plurality of operations, each said operation affecting one of said labels, that were interrupted by said failure and said subsequent reconnection of said logical connection or that could not be exchanged between said peer nodes during said failure whereby said label distribution component of said peer nodes can recover from said failure and said subsequent reconnection of said logical connection without the need to re-exchange said state information for all said labels, whether said failure was caused by a hardware or software fault that affected said logical connection or by a hardware or software upgrade that necessitated the temporary disconnection of said logical connection, and without risk that said resources reserved for said labels, such as bandwidth allocated to said labels, is lost as a result of incomplete recovery of said state information.

2. The method as set forth in claim 1, wherein said first means is achieved by use a FT Session flag on the LDP initialization message to indicate whether first said peer supports said LDP FT enhancements, 17 said FT Session flag being encoded such that second said peer that does not support the LDP FT enhancements will reject said LDIP initialization message with a notification of an unsupported or unrecognized option in order that first said peer can retry said LDP initialization message omitting said FT Session flag.

The method as set forth in claim 1, wherein said second means is achieved by removing the requirement in said base LDP specification that first said peer immediately release all said state information and resources for said labels exchanged on said logical connection when said logical connection fails, and mandating that first said peer release all said state information and resources if said logical connection is not reconnected within a timeout period or if said logical connection is reconnected within said timeout period but said first means indicates that second said peer no longer supports said LDP FT enhancements or said third means indicates that second said peer has not preserved said state information and resources.

4. The method as set forth in claim 3, wherein said timeout period is carried in the LDP initialization message issued by first said peer in order that second said peer can extract said timeout period from said LDP initialization message and use the same said timeout period or a timeout period related to said timeout period.

5. The method as set forth in claim 1, wherein said third means is achieved by use of a FT State flag on the LDIP initialization message to indicate whether first said peer has preserved said state information and resources for said labels.

6. The method as set forth in claim 1, wherein said fourth means is achieved by first said peer acknowledging all said operations issued to it by second said peer, and second said peer reissuing all said operations for which second said peer has not received said acknowledgement when said logical connection is reconnected after said failure, said reissued operations being marked with a FT Duplicate flag to indicate that to first said peer that they are duplicates of said operations that first said peer may have already received and processed, though first said peer issues acknowledgements to all reissued said operations even if it has previously received and processed said operations in order that second said peer can learn that said operations are complete.

7. The method as set forth in claim 1, wherein a fifth means is used to synchronize the view of said state information and resources associated with said labels held by said peers whereby mismatches that may have been introduced into said state information and resources preserved by said second means as a result of hardware of software errors can be identified and corrected.

8. The method as set forth in claim 7, wherein said fifth means is achieved by first said peer commencing on a regular basis to reissue the Label Mapping messages for all said labels first said peer considers 18 still to be active, and for which first said peer originally issued said Label Mapping messages, in order that second said peer can correct any mismatch in said state information and resources second said peer has preserved for said labels associated with said Label Mapping messages and the information contained in said Label Mapping messages.

9. The method as set forth in claim 1, wherein a sixth means is used to identify a set of said labels, known as non-FT labels, for which faulttolerant operation is not required, whereby said peers do not employ said second means, said third means or said fourth means for said non-FT labels and hence may be able to conserve resources on said peers.

10. The method as set forth in claim 9, wherein said sixth means is achieved by use a FT Default flag on the LDP initialization message to indicate whether the default for all said labels exchanged on said logical connection is that said labels are non-FT labels, but with an optional FT Label flag on the Label Request or Label Mapping message that first references one said label to specifically identify whether said label is a non-FT label regardless of the setting of said FT Default flag.

11. The method as set forth in claim 1, wherein a seventh means is used authenticate the identity of said peers connected by said logical connection.

12. The method as set forth in claim 11, wherein said seventh means is achieved by each said peer including a digital signature in the LDP initialization message, said digital signature being generated using a public key encryption algorithm, said peers having access to a network infrastructure for the distribution of said public keys.