Internet DRAFT - draft-farrel-mpls-ldp-ft

draft-farrel-mpls-ldp-ft




MPLS WG                                                        A. Farrel
Internet Draft                                               P. Brittain
Document: draft-farrel-mpls-ldp-ft-00.txt            Data Connection Ltd
Expiration Date: August 2000                               February 2000 
   
               
                  Fault Tolerance for LDP and CR-LDP


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."
   
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.
   
   NOTE: The new TLV type numbers, bit values for flags specified in 
   this draft, and new LDP status code values are preliminary suggested 
   values and have yet to be approved by IANA or the MPLS WG.  See the 
   section "IANA Considerations" for further details.
   

Abstract

   MPLS systems will be used in core networks where system downtime 
   must be kept to an absolute minimum.  Many MPLS LSRs may, therefore, 
   exploit Fault Tolerant (FT) hardware or software to provide 
   high-availability of the core networks.  
   
   The details of how FT is achieved for the various components of an FT 
   LSR, including LDP, CR-LDP, the switching hardware and TCP, are 
   implementation specific.  This document identifies issues in the 
   CR-LDP specification [2] and the LDP specification [4] that make it 
   difficult to implement an FT LSR using the current LDP and CR-LDP 
   protocols, and proposes enhancements to the LDP specification to ease 
   such FT LSR implementations.  
   
   The extensions described here are equally applicable to CR-LDP.


Farrel et al.          Expires: August 2000                     [Page 1]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000

Contents

   1. Conventions and Terminology used in this document................3
   2. Introduction.....................................................3
   2.1 Fault-tolerance for MPLS........................................4
   2.2 Issues with LDP and CR-LDP......................................4
   2.3 Data Forwarding During TCP Connection Failure...................5
   2.4 FT Recovery Support on Non-FT LSRs..............................5
   3. Overview of LDP FT Enhancements..................................6
   3.1 Establishing an FT LDP Session..................................6
   3.1.1  Interoperation with Non-FT LSRs..............................7
   3.2 LDP Session Failure.............................................7
   3.3 LDP Session Re-initialization...................................8
   3.4 Operations on FT Labels.........................................8
   3.5 Notes on an Alternate Solution..................................9
   4. Use of FT Labels.................................................9
   4.1 Identifying FT Labels...........................................9
   4.1.1 Defaulting FT Label Status...................................10
   4.1.2 Scope of FT Labels...........................................10
   4.2 Label Operation Handshaking....................................10
   4.3 Preservation of Label State....................................11
   4.4 Procedure After TCP Failure....................................13
   4.4.1 Label Operations During TCP Failure..........................13
   4.5 Procedure After TCP Re-connection..............................14
   4.5.1 Issuing FT Duplicate Messages................................14
   4.5.2 Receiving FT Duplicate Messages..............................15
   4.5.3 Forwarding FT Duplicate Messages.............................16
   4.5.4 Error Cases..................................................16
   4.5.5 Interaction with CR-LDP LSP Modification.....................17
   5. Changes to Existing Messages....................................17
   5.1 LDP Initialization Message.....................................17
   5.2 Label Request Message..........................................18
   5.3 Label Mapping Message..........................................18
   5.4 Label Release Message..........................................18
   5.5 Label Withdraw Message.........................................19
   5.6 Label Abort Message............................................19
   5.7 Notification Request Message...................................19
   6. New Fields and Values...........................................20
   6.1 Status Codes...................................................20
   6.2 FT Session TLV.................................................20
   6.3 FT Protection TLV..............................................22
   7. Example Use.....................................................23
   8. Security Considerations.........................................25
   9. Acknowledgments.................................................26
   10. Intellectual Property Consideration............................26
   11. References.....................................................26
   12. Authors' Addresses.............................................27
   13. Full Copyright Statement.......................................27
   14. IANA Considerations............................................27
   





Farrel et al.          Expires: August 2000                     [Page 2]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
                  
1. Conventions and Terminology used in this document

   Definitions of key words and terms applicable to LDP and CR-LDP are
   inherited from [2] and [4].

   The term "FT label" is introduced in this document to 
   indicated a label for which fault-tolerant operation is used.  A  
   "non-FT label" is not fault-tolerant and is handled as specified in 
   [2] and [4].
   
   The extensions to LDP specified in this document are collectively 
   referred to as the "LDP FT enhancements".
   
   In the examples quoted, the following notation is used.

   Ln : An LSP. For example L1.
   Pn : An LDP peer. For example P1.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [3].


2. Introduction

   High Availability (HA) is typically claimed by equipment vendors
   when their hardware achieves availability levels of at least 99.999%
   (five 9s). To implement this, the equipment must be capable of
   recovering from local hardware and software failures through a
   process called Fault Tolerance (FT).

   The usual approach to FT involves provisioning backup copies of
   hardware and software. When a primary copy fails, processing is
   switched to the backup copy. This process, called failover, should
   result in minimal disruption in both the Data and the Control
   Planes.

   In an FT system, backup resources are sometimes provisioned on a
   one-to-one basis (1:1), sometimes as many-to-one (1:n), and
   occasionally as many-to-many (m:n). Whatever backup provisioning is
   made, the system must switch to the backup automatically on failure
   of the primary, and the software and hardware state in the backup
   must be set up to replicate the state in the primary at the point
   of failure.

   FT systems are well placed to facilitate hot-swaps of hardware. A
   card can be simply removed from the system and replaced with a new
   one. The removal of a card is treated as hardware failure.

   Similarly, an FT system can implement online software upgrades by
   swapping from primary to backup under management control.




Farrel et al.          Expires: August 2000                     [Page 3]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000

2.1 Fault-tolerance for MPLS

   MPLS systems will be used in core networks where system downtime must 
   be kept to an absolute minimum.  Many MPLS LSRs may, therefore, 
   exploit Fault Tolerant (FT) hardware or software to provide 
   high-availability of core networks.  
      
   An FT MPLS system should be capable of failing over
   - with minimal disruption to the data flow using established labels
   - without loss of control information for established labels
   - in a way that allows recovery of control information for labels
     that are being established or torn down.

   It may be acceptable for some data to be lost, especially if failover
   involves swapping between two sets of switching hardware.

   It is not acceptable for there to be a significant loss of service on 
   any established label or LSP during failover.  The target of at most 
   50ms disruption applied during discussions of LSP protection, should 
   apply here too, for established LSPs.  

   It is, therefore, clearly unacceptable for established labels or LSPs 
   transitting an LSR or a card within an LSR to be torn down during 
   failover or upgrade processing.

   Finally, it is not acceptable that resources (such as bandwidth
   allocation) should be lost during failover. This might arise if
   MPLS CR-LSP setup or tear-down are not completed correctly.
   

2.2 Issues with LDP and CR-LDP

   LDP and CR-LDP use TCP to provide reliable connections between LSRs
   over which to exchange protocol messages to distribute labels and to
   set up LSPs. A pair of LSRs which have such a connection are referred
   to as LDP peers.

   TCP enables LDP and CR-LDP to assume reliable transfer of protocol
   messages. This means that some of the messages do not need to be
   acknowledged (for example, Label Release).

   LDP and CR-LDP are defined such that if the TCP connection fails, the 
   LSR should immediately tear down the LSPs associated with the session 
   between the LDP peers, and release any labels and resources assigned 
   to those LSPs.  

   It is notoriously hard to provide a fault tolerant implementation of
   TCP. To do so might involve making copies of all data sent and
   received. This is an issue familiar to implementers of other TCP
   applications such as BGP.





Farrel et al.          Expires: August 2000                     [Page 4]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000

   During failover affecting the TCP or LDP stacks, therefore, the TCP 
   connection may be lost.  Recovery from this position is made worse by 
   the fact that LDP or CR-LDP control messages may have been lost 
   during the connection failure.  Since these messages are unconfirmed, 
   it is possible that LSP or label state information will be lost. 
    
   This draft describes a solution which involves
   - negotiation between LDP peers of the intent to support extensions
     to LDP that facilitate recovery from failover without loss of LSPs
   - selection of FT survival on a per LSP/label basis
   - acknowledgement messages to ensure that a full handshake is
     performed on label distribution and LSP setup/teardown of FT labels
   - sending duplicate messages after failover to ensure that LSP/label
     state is correctly reflected at the peer for FT labels.

   Other objectives of this draft are to
   - offer back-compatability with LSRs that do not implement these
     proposals
   - preserve existing protocol rules described in [2] and [4] for
     handling unexpected duplicate messages and for processing
     unexpected messages referring to unknown LSPs/labels
   - integrate with the LSP modification function described in [5]
   - avoid full state refresh solutions (such as those present in RSVP:
     see [6], [7] and [8]) whether they be full-time, or limited to post-
     failover recovery.

   This draft does not attempt to describe how to modify the routing of 
   an LSP or the resources allocated to a label or LSP, which is covered 
   by [5].
   
   This draft also does not address how to provide automatic layer 2/3 
   protection switching for a label or LSP, which is a separate 
   area for study. 
   
   
2.3 Data Forwarding During TCP Connection Failure

   An LSR that implements the LDP FT enhancements SHOULD preserve the 
   programming of the switching hardware across a failover.  This 
   ensures that data forwarding is unaffected by the state of the TCP 
   connection between LSRs.  
   
   It is an integral part of FT failover processing in some hardware 
   configurations that some data packets might be lost. If data loss is 
   not acceptable to the applications using the MPLS network, the LDP FT 
   enhancements described in this draft SHOULD NOT be used.
 
   
2.4 FT Recovery Support on Non-FT LSRs

   In order to take full advantage of the FT capabilities of LSRs in the
   network, it may be that an LSR that does not itself contain the
   ability to recover from local hardware or software faults still needs
   to support the LDP FT enhancements described in this draft.

Farrel et al.          Expires: August 2000                     [Page 5]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000

   Consider an LSR, P1, that is an LDP peer of a fully fault tolerant 
   LSR, P2.  If P2 experiences a fault in the hardware or software that 
   serves an LDP session between P1 and P2, it may fail the TCP 
   connection between the peers.  When the connection is recovered, the 
   LSPs/labels between P1 and P2 can only be recovered if both LSRs were 
   applying the FT recovery procedures to the LDP session.  

   
3. Overview of LDP FT Enhancements

   The LDP FT enhancements consist of the following main elements, which 
   are described in more detail in the sections that follow.
   
   -  An FT Session Flag on the LDP Initialization message that 
      indicates whether an LSR supports the LDP FT enhancements on this 
      session.
      
   -  An FT State Flag on the LDP Initialization message that indicates 
      whether an LSR has preserved FT label state across a failure of 
      the TCP connection.
      
   -  An FT Reconnection Timeout, exchanged on the LDP Initialization 
      message, that indicates the maximum time peer LSRs will preserve 
      FT label state after a failure of the TCP connection.  
      
   -  An FT Default Flag for each TCP connection, exchanged on the LDP 
      initialization message, plus an optional FT Label Flag for an 
      individual label, to indicate whether labels should be treated as 
      FT labels or non-FT labels.
      
   -  Enhanced handshaking on label operations affecting FT labels to 
      enable peer LSRs to correctly complete any operations on FT labels 
      that are interrupted by a failure of the TCP connection.


3.1 Establishing an FT LDP Session

   In order that the extensions to LDP [4] and CR-LDP [2] described in
   this draft can be used successfully on an LDP session between a pair
   of LDP peers, they MUST negotiate that the LDP FT enhancements 
   are to be used on the LDP session.

   This is done on the LDP Initialization message exchange using a new
   FT Session Flag, that indicates whether the peer wants to support the 
   LDP FT enhancements on this LDP session.  This flag is carried in 
   a new FT Session TLV (see section "FT Session TLV").

   If the FT Session Flag is not set by the active LSR in the LDP 
   initialization message, the LDP FT enhancements MUST NOT be used on 
   this LDP session.  





Farrel et al.          Expires: August 2000                     [Page 6]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
   
   If the active LSR sets the FT Session Flag, but the passive LSR does 
   not set the FT Session Flag in the LDP Initialization message, the 
   LDP FT enhancements MUST NOT be used on this LDP session.
   
   If both LDP peers on an LDP session indicate support for the LDP FT 
   enhancements in the LDP Initialization messages, each peer MUST use 
   the FT label operation procedures indicated in this draft for FT
   labels.
   
   
3.1.1  Interoperation with Non-FT LSRs

   If the active LSR does not include the FT Session TLV in its LDP 
   Initialization message, the passive LSR MUST NOT include the FT 
   Session TLV in its LDP Initialization message.  
      
   If the passive LSR does not support the LDP FT enhancements, for 
   example because it implements the base LSP specification in [4], it 
   MUST reject the LDP Initialization message sent by the active LSR 
   using a Notification message indicating an unknown TLV.  The 
   Notification message MUST contain the Unknown TLV status code, as 
   specified in [4].  In such cases, the active LSR SHOULD retry LDP 
   initialization omitting the FT Session TLV, as specified in [4].  

   An LSR MAY present different FT/non-FT behavior through different 
   values for the FT Session Flag on different LDP sessions, even if 
   those sessions are successive instantiations of the LDP session 
   between the same LDP peers.  
   

3.2 LDP Session Failure

   If the LDP FT session enhancements are not in use on an LDP session, 
   the action of the LDP peers on failure of the LDP session is as 
   specified in [2] and [4].
   
   All state information and resources associated with non-FT labels 
   MUST be released on the failure of the LDP session, including 
   deprogramming the non-FT label from the switching hardware.  This is 
   equivalent to the behaviour specified in [4].

   If the LDP FT enhancements are in use on an LDP session, both LDP 
   peers SHOULD preserve state information and resources associated with 
   FT labels exchanged on the LDP session.  Both LDP peers SHOULD use a 
   timer to release the preserved state information and resources 
   associated with FT-labels if the LDP session is not reconnected 
   within a reasonable period.  The behavior when this timer expires is 
   equivalent to the LDP session failure behavior described in [4].
   
   The FT Reconnection Timeout each LDP peer intends to apply to the LDP 
   session is carried in the FT Session TLV on the LDP Initialization 
   messages.  It is RECOMMENDED that both LDP peers use the lower 
   timeout value from the LDP Initialization exchange when setting their 
   reconnection timer after a TCP connection failure.
   
Farrel et al.          Expires: August 2000                     [Page 7]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000

   
3.3 LDP Session Re-initialization

   When a TCP connection is recovered after FT failure, the LDP peers
   MUST re-exchange LDP Initialization messages. 
   
   If an LDP peer sets the FT Session Flag in the LDP Initialization 
   message for the new instantiation of the LDP session, it MUST also 
   set the FT State Flag if the peer has preserved state for all FT 
   labels exchanged on previous instantiations of the TCP connection. The 
   FT State Flag is carried in the FT Session TLV (see below).
   
   If an LDP peer has been unable to preserve state for all FT labels 
   exchanged on previous instantiations of the LDP session, it MUST NOT 
   set the FT State Flag on the LDP Initialization message.
   
   If either LDP peer does not set the FT State Flag in the LDP 
   Initialization message, both LDP peers MUST release any state 
   information and resources associated with all FT labels preserved 
   from previous instantiations of the LDP session between the same LDP 
   peers.  This ensures that network resources are not permanently lost 
   if one of the LDP peers is forced to undergo a cold start.
   
   If both LDP peers set the FT State Flag, both LDP peers MUST use the 
   FT label operation procedures indicated in this draft to complete any 
   label operations on FT labels that were interrupted by the LDP 
   session failure.  
   
 
3.4 Operations on FT Labels

   Label operations on FT labels are made fault-tolerant by enhancing 
   the handshaking information available to each LDP peer in order that 
   the LDP peers can recover from an interruption to the LDP session 
   while one or more label operations are in progress.  This is achieved 
   by a combination of adding acknowledgements to label operations that 
   are not acknowledged in [2] or [4], and procedures for reissuing 
   unacknowledged label operations after re-connection of the LDP 
   session between two LDP peers that are using the LDP FT enhancements.
   
   Using these acknowledgements and procedures, it is not necessary for 
   LDP peers to perform a complete re-synchronization of state for all 
   FT labels, either on re-connection of the LDP session between the LDP 
   peers or on a timed basis.
   
   The message exchanges used to achieve acknowledgement of label 
   operations and the procedures used to complete interrupted label 
   operations are detailed in the section "Use of FT Labels". 
   






Farrel et al.          Expires: August 2000                     [Page 8]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000

3.5 Notes on an Alternate Solution

   An alternate solution to this issue does not require retransmission
   of unacknowledged state changes. Instead it says that any LSP/label
   with unacknowledged state on TCP connection recovery MUST be torn
   down.

   This appears to be a relatively small saving in processing and some
   loss of function. It also changes the recovery model in Downstream
   Unsolicited label distribution mode.

 
4. Use of FT Labels

   Once an LDP session has been established as supporting the LFP FT 
   enhancements FT recovery using the procedures described in section 
   "Establishing an FT LDP Session", both LDP peers MUST apply the 
   procedures described in this section for FT labels.  

   If the LDP session has been negotiated to not use the LDP FT 
   enhancements, these procedures MUST NOT be used.
          

4.1 Identifying FT Labels

   A label is identified as being an FT label if the initial Label 
   Request or Label Mapping message relating to that label carries the 
   FT Label Flag.  This flag is carried in a new FT Protection TLV 
   (see section "FT Protection TLV) optionally present on Label Request 
   and Label Mapping messages.
   
   If the FT Protection TLV is present on the initial Label Request 
   or Label Mapping message for a label, but the FT Label Flag is not 
   set, the label MUST be treated as a non-FT label.
   
   If the FT Protection TLV is present on the initial Label Request 
   or Label Mapping message for a label, and the FT Label Flag is set, 
   the label MUST be treated as an FT label.
   
   The setting of the FT Label Flag in subsequent message exchanges 
   between the LDP peers MUST be ignored once the label has been 
   identified as an FT/non-FT label.
   
   
4.1.1 Defaulting FT Label Status
   
   If the FT Protection TLV is not present on the initial Label Request 
   or Label Mapping message for a label, the FT/non-FT status of the 
   label MUST be determined from the FT Default Flag, which is carried 
   on the FT Session TLV.
   
   The FT Default Flag value for an FT LDP session is determined by both 
   LDP peers from the setting of the FT Default Flag in the LDP 
   initialization message sent by the active LSR.

Farrel et al.          Expires: August 2000                     [Page 9]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
   
   If the active LSR includes an FT Session TLV in its LDP 
   Initialization message with the FT Default Flag set, all labels 
   exchanged between the LDP peers MUST be treated as FT labels unless 
   specifically overridden by the FT Label Flag for an individual label.  
   
   If the active LSR does not set the FT Default Flag in its LDP 
   Initialization message, or if it omits the FT Session TLV altogether, 
   all labels exchanged between the LDP peers MUST be treated as non-FT 
   labels.  
   
   The setting of the FT Default Flag on re-connection of an LDP session 
   MUST NOT change the FT/non-FT status of any labels for which state 
   information and resources have been preserved since previous 
   instantiations of the LDP session between the same LDP peers. 
   
   
4.1.2 Scope of FT Labels   
   
   The scope of the FT/non-FT status of a label is limited to the 
   LDP message exchanges between a pair of LDP peers. In Ordered 
   Control, when the message is forwarded downstream or upstream, the 
   TLV may be present or absent according to the requirements of the LSR 
   sending the message.   


4.2 Label Operation Handshaking

   Once a label is identified as an FT label, both LSRs MUST apply the 
   following handshaking procedure.  This handshaking procedure MUST 
   also be applied to the Label Request or Label Mapping message that 
   identified the label as an FT label.

   The message exchanges described in [2] and [4] do not provide for 
   full handshaking of the allocation or deallocation of a label 
   exchanged between LDP peers as the current LDP specification assumes 
   that all labels and associated resources are torn down if the TCP 
   connection fails.  
   
   Additional handshaking is required to ensure that both peers can 
   synchronize on the result of a label operation even if that operation 
   is interrupted by a TCP connection failure.
   
   The LDP FT enhancements achieve handshaking of label operations by 
   use of additional LDP messages to explicitly acknowledge the 
   completion of a label operation between the LDP peers.
 
   The type of acknowledgement used for each message that relates to 
   label exchange or LSP setup is given below.
   
   -  A Label Request message MUST be 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, as 
      specified in [4].


Farrel et al.          Expires: August 2000                    [Page 10]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
      
   -  A Label Mapping message that is sent in response to a Label 
      Request in Downstream On Demand Label Advertisement mode SHOULD 
      NOT be acknowledged as it forms the response to the Label Request.
      
   -  A Label Mapping message that is sent in Downstream Unsolicited 
      Label Advertisement mode MUST be acknowledged using a Notification 
      message containing an OK status 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 relates to an FT label.
      
   -  A Label Withdraw message MUST be acknowledged using a Label 
      Release message, as specified in [4].
      
   -  A Label Release message that is sent in response to a Label 
      Withdraw SHOULD NOT be acknowledged as it forms the response to 
      the Label Withdraw.
      
   -  A Label Release message that is sent other than in response to a 
      Label Withdraw message MUST be acknowledged using a Notification 
      message containing an OK response code or giving the reason for 
      the failure of the Label Release.
 
   -  A Label Abort message MUST NOT be explicitly acknowledged if it 
      crosses with the Label Mapping message sent in response to the 
      aborted Label Request, as specified in [4], or a Label Withdraw 
      message for the same FEC. In such cases, the upstream LDP peer 
      MUST issue a Label Release message on receipt of the Label Mapping 
      or Label Withdraw message.  See section "Procedure after TCP 
      Re-connection" for further details of how a Label Abort may cross 
      with a Label Withdraw message.
            
   -  A Label Abort message that does not cross with the associated 
      Label Mapping message MUST be acknowledged using a Notification 
      message specifying the Label Request Aborted status code, as 
      specified in [4].
      
   -  Notification messages relating to a label operation MUST NOT be 
      acknowledged, as they form the response handshake to a previous 
      label operation.
      

4.3 Preservation of Label State

   If the LDP FT enhancements are in use on an LDP session, each LDP 
   peer MUST NOT release the state information and resources associated 
   with FT labels exchanged on that LDP session when the TCP connection 
   fails.  This is contrary to [2] and [4], but allows label operations 
   on FT labels to be completed after re-connection of the TCP 
   connection.  




Farrel et al.          Expires: August 2000                    [Page 11]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
   
   Both LDP peers on a LDP session that is using the LDP FT enhancements 
   MUST preserve the state information and resources it holds for an 
   FT label exchanged between the LDP peers until one of the following 
   occurs:
   
   -  An upstream LDP peer SHOULD release the resources (in 
      particular bandwidth) associated with an FT label when it 
      initiates a Label Release or Label Abort message for the label.  
      The upstream LDP peer MUST preserve state information for 
      the label, even if it releases the resources associated with the 
      label, as it may have to reissue the label operation if the 
      TCP connection is interrupted.
   
   -  An upstream LDP peer MUST release the state information 
      and resources associated with an FT label when it receives an 
      explicit acknowledgement to a Label Release or Label Abort message 
      that it sent for the label, or when it sends a Label Release 
      message in response to a Label Withdraw message received from the 
      downstream LDP peer.
      
   -  A downstream LDP peer SHOULD NOT release the resources 
      associated with an FT label when it sends a Label Withdraw message 
      for the label as it has not yet received confirmation that the 
      upstream LDP peer has ceased to send data using the label.  The 
      downstream LDP peer MUST NOT release the state information it 
      holds for the label as it may yet have to reissue the label 
      operation if the TCP connection is interrupted.
      
   -  A downstream LDP peer MUST release the resources and state 
      information associated with an FT label when receives an 
      acknowledgement to a Label Withdraw message for the label.
      
   -  When the FT Reconnection Timeout expires, an LSR SHOULD release 
      all state information and resources preserved for FT labels from 
      previous instantiations of the (permanently) failed LDP session.   
      If an LDP peer does release state information and resources in 
      this situation, it MUST NOT set the FT State Flag (see section 
      "LDP Session Re-initialization") on the next instantiation of the 
      TCP connection between the same LDP peers.  Otherwise it MUST set 
      the FT State Flag on the next instantiation of the TCP connection 
      between the same LDP peers.
      
   -  When an LSR receives a Status TLV with the E-bit set in 
      the status code, which causes it to close the TCP connection, the 
      LSR SHOULD release all state information and resources preserved 
      for FT labels if it is not immediately going to try to 
      re-establish the TCP connection.  See section "Error Cases" for 
      further discussion of the handling of the E-bit in Status TLVs. 
         
   The release of state information and resources associated with non-FT 
   labels is as described in [2] and [4].  




Farrel et al.          Expires: August 2000                    [Page 12]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
   

4.4 Procedure After TCP Failure

   TCP connection failure may be notified to an LDP or CR-LDP 
   implementation in an implementation-specific way.  It may also be 
   discovered by failure to receive any LDP message (including a 
   KeepAlive message) on the connection within the life of the KeepAlive 
   Timer.

   When an LSR discovers or is notified of a TCP connection failure it 
   SHOULD start an FT Reconnection Timer to allow a period for 
   re-connection of the TCP connection between the LDP peers.  

   Once the TCP connection between LDP peers has failed, the active LSR 
   SHOULD attempt to re-establish the TCP connection. The mechanisms, 
   timers and retry counts to re-establish the TCP connection are an 
   implementation choice.  It is RECOMMENDED that any attempt to 
   re-establish the connection take account of the failover processing 
   necessary on the peer LSR, the nature of the network between the 
   LDP peers, and the FT Reconnection Timeout chosen on the previous 
   instantiation of the TCP connection (if any).

   If the TCP connection cannot be re-established within the FT 
   Reconnection Timeout period, the LDP session between the peers 
   SHOULD be deemed to have failed permanently.  The LDP
   implementation SHOULD fail all FT labels exchanged between the LDP 
   peers, as described in the previous section.

   If the TCP connection is successfully re-established within the FT 
   Reconnection Timeout, both peers MUST re-synchronize the state of the 
   label operations that were interrupted by the TCP connection 
   failure.  This procedure is described below.
   
4.4.1 Label Operations During TCP Failure
   
   If an LSR determines that it needs to issue a new operation on an 
   existing FT Label to an LDP peer to which the TCP connection has 
   currently failed, it MUST complete that operation with the LDP peer 
   when the TCP connection is restored, unless the label operation is 
   overridden by a subsequent additional label operation during the TCP 
   connection failure.  For example, an LSR SHOULD NOT issue a queued 
   Label Mapping message for a new downstream unsolicited FT label on 
   re-establishment of the TCP connection to the upstream LDP peer if it 
   also queues a Label Withdraw operation for the same FT label before 
   the TCP connection is re-established.  
   
   FT label operations that cannot be correctly forwarded because of a 
   TCP connection failure MAY be processed immediately (provided 
   sufficient state is kept to forward the label operation) or queued 
   for processing when the onward TCP connection is restored.  





Farrel et al.          Expires: August 2000                    [Page 13]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
   
   Consider the case when an upstream LSR has sent a Label Release 
   for a label in ordered distribution mode.  An LSR receiving the 
   Label Release that also needs to forward it downstream MAY queue
   the Label Release and process it when the TCP connection is restored.  
   Alternatively, the LSR MAY action the Label Release immediately, 
   freeing up the label resources, provided that it retains sufficient 
   state information to forward the Label Release downstream when the 
   TCP connection is restored.  
      
   It is RECOMMENDED that Label Request operations for new FT labels are 
   not queued awaiting the re-establishment of TCP connection that is 
   awaiting recovery at the time the LSR determines that it needs to 
   issue the Label Request message.  Instead, such Label Request 
   operations SHOULD be failed and, if necessary, a notification message 
   containing the No LDP Connection status code sent upstream.  
   
   Label Requests for new non-FT labels MUST be rejected during TCP 
   connection failure, as specified in [2] and [4].

   
4.5 Procedure After TCP Re-connection

   The label operation handshaking described above means that all state 
   changes for FT labels are confirmed or reproducible at each LSR.

   If the TCP connection between LDP peers fails but is re-connected 
   within the FT Reconnection Timeout, both LDP peers on the connection 
   MUST complete any label operations for FT labels that were 
   interrupted by the failure and re-connection of the TCP connection.  
   Label operation are completed using the procedure described below.


4.5.1 Issuing FT Duplicate Messages

   On restoration of the TCP connection between LDP peers, any label 
   operations on FT labels that were interrupted by the TCP connection 
   failure are completed by each LDP peer re-issuing any messages that 
   were unacknowledged at the time of the TCP failure.  The LDP peer 
   that receives a re-issued message either processes the message from 
   scratch (if the previous copy of the message was lost), or returns 
   the same result for the label operation as it had previously returned 
   (if the acknowledgement was lost).  
   
   Re-issued messages MUST carry the FT Duplicate Flag to indicate that 
   they contain a message that has been re-issued to complete an 
   outstanding label operation on an FT label.
       
   The messages that may or may not need to be re-issued on 
   re-establishment of the TCP connection between LDP peers are as 
   follows: 
   
   -  A Label Request message MUST be re-issued if an acknowledgement 
      had not previously been received, unless a Label Abort will be 
      re-issued for the same Label Request.

Farrel et al.          Expires: August 2000                    [Page 14]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
   
   -  A Label Mapping message MUST NOT be re-issued if it was 
      originally sent in response to a Label Request message.
         
   -  A Label Mapping message that was previously sent other than in 
      response to a Label Request message MUST be re-issued if the 
      acknowledgement to the Label Mapping had not previously been 
      received, unless a Label Withdraw message will be issued for 
      the same FT label.
      
   -  A Label Withdraw message MUST be re-issued if an acknowledgement 
      had not previously been received.
      
   -  A Label Release message MUST NOT be re-issued if it was 
      originally sent in response to a Label Withdraw message.
         
   -  A Label Release message that was previously sent other than 
      in response to a Label Withdraw message MUST be re-issued 
      if the acknowledgement to the Label Release had not previously 
      been received.
      
   -  A Label Abort message MUST be re-issued if an acknowledgement 
      or crossing Label Mapping message had not previously been 
      received.
      
   Re-issued messages SHOULD NOT contain the same Message ID as the 
   orignal message.

   Any FT label operations that were queued (see section "Label 
   Operations During TCP Failure") during the TCP connection failure 
   MUST be issued on re-establishment of the LDP session.  Queued Label 
   Request or Label Mapping messages SHOULD NOT be issued if a Label 
   Abort or Label Withdraw message is also queued for the same FT label.  


4.5.2 Receiving FT Duplicate Messages

   If an LSR receives a re-issued message marked with the FT Duplicate 
   Flag on an LDP session for which both the FT Session Flag and FT 
   State Flag were set during LDP Initialization, it MUST process the 
   message according to the following procedure: 
    
   -  All re-issued messages received by an LSR that it can match to a 
      previously received message for the same FT Label MUST be 
      acknowledged using the same message/status code as the LSR 
      previously sent in response to the original copy of the message.
   
   -  If an LSR receives a re-issued Label Withdraw of which it has no 
      record (because it has already released the state information when 
      it received the original request), it MUST return a 
      Label Release message for the same label.





Farrel et al.          Expires: August 2000                    [Page 15]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
    
   -  If an LSR receives a re-issued Label Release of which it has no 
      record (because it has already released the state information when 
      it received the original request), it MUST return a Notification 
      message containing an OK status code.
    
   -  If an LSR receives a re-issued Label Abort message for a label of 
      which it has no record, it MUST return a Notification message 
      containing a Label Request Aborted status code.
      
   -  If an LSR receives a re-issued Label Mapping message for an FT 
      label of which it has no record, it MUST process the Label Mapping 
      from scratch. (This is most likely to happen in Downstream 
      Unsolicited Label Advertisement mode, especially if the upstream 
      LSR does not retain all such labels).
         
   -  If an LSR receives a re-issued Label Request message for a 
      FT label of which it has no record, it MUST process the Label 
      Request from scratch.

   
4.5.3 Forwarding FT Duplicate Messages   
   
   When forwarding a re-issued message upstream or downstream, an LSR 
   must follows the procedure described below:
   
   -  If an LDP peer operating in ordered distribution mode receives a 
      re-issued message for an FT label, it MUST NOT forward the 
      message upstream or downstream (as appropriate to the message 
      type) if it had previously forwarded the original message upstream 
      or downstream.  
      
   -  If an LDP peer receives a re-issued message, but it had not 
      received the original message, the LDP peer MUST process the 
      re-issued message from scratch and forward the message upstream or 
      downstream as required.
   
   -  If an LDP peer forwards a re-issued message upstream or downstream 
      it MUST NOT set the FT Duplicate Flag in the forwarded messages. 

         
4.5.4 Error Cases   

   If an LSR receives an apparent duplicate message that is not marked 
   with the FT Duplicate Flag, it MUST reject the message using a 
   Notification message containing the Unexpected Duplicate/Duplicate 
   Not Marked status code.
   
   If an LSR that supports the LDP FT enhancements receives a message 
   marked with the LDP Duplicate Flag, but the LDP Initialization 
   for the LDP session did not set both the FT Session Flag or the 
   FT State Flag, the LSR MUST reject the message using a 
   Notification Message containing the  Unexpected Duplicate/Session Not 
   FT status code.


Farrel et al.          Expires: August 2000                    [Page 16]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
   
   If an LSR is using the LDP FT enhancements on an LDP session and 
   receives a message on that session that relates to a non-FT label but 
   that is marked with the FT Duplicate Flag, it SHOULD reject the 
   message using a Notification message containing the Unexpected 
   Duplicate/Non-FT Label status code.  The LSR MAY ignore the FT 
   Duplicate Flag if it is set on Label Release, Label Abort or Label
   Withdraw message for a non-FT label provided that it releases the 
   state information and resources associated with that label. 
   
   If an LSR receives a Status TLV message containing the Unexpected 
   Duplicate/Non-FT Label status code, but for a label that it believes 
   to be an FT label, it SHOULD Release/Withdraw the label (without 
   setting the FT Duplicate Flag) and issue a new Label Request/Label 
   Mapping message to request an FT label.
   
   If an LSR receives a Status TLV with the E-bit set, it SHOULD NOT, on 
   re-establishment of the TCP connection, immediately re-issue the 
   message (if any) indicated in the Status TLV as being in error.  In 
   particular, if an LSR receives the Unexpected Duplicate/Session Not 
   FT status code, it should release all state and resources held for FT 
   labels associated with this session before attempting to 
   re-establish the TCP connection.
   
   Receipt of duplicate messages on an LDP session that does not support 
   the LDP FT enhancements is outside the scope of this draft and MUST 
   be handled as described in [5], [2] and [4], regardless of the 
   setting of the FT Duplicate flag on the message. 
   
   
4.5.5 Interaction with CR-LDP LSP Modification    
   
   Re-issuing LDP messages for FT operation is orthogonal to the use of 
   duplicate messages marked with the Modify ActFlg, as specified in 
   [5].  Each time an LSR uses the modification procedure for an LSP to 
   issue a new Label Request message, the FT label operation procedures 
   MUST be separately applied to the new Label Request message.  
   
   

5. Changes to Existing Messages
   
5.1 LDP Initialization Message

   The LDP FT enhancements add the following optional parameter to a 
   LDP Initialization message

         Optional Parameter    Length       Value

         FT Session TLV        4            See below

   The encoding for FT Session TLV is found in Section "FT Session TLV".

       FT Session
         If present, specifies the FT behavior of the LDP session. 

Farrel et al.          Expires: August 2000                    [Page 17]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
   
5.2 Label Request Message

   The LDP FT enhancements add the following optional parameter to a 
   Label Request message

         Optional Parameter    Length       Value

         FT Protection TLV     4            See below

   The encoding for FT Protection TLV is found in Section "FT Protection 
   TLV".  

       FT Protection
         If present, specifies the FT/non-FT characteristics for the 
         label and whether the message has been re-issued for FT 
         recovery.


5.3 Label Mapping Message

   The LDP FT enhancements add the following optional parameter to a 
   Label Mapping message

         Optional Parameter    Length       Value

         FT Protection TLV     4            See below

   The encoding for FT Protection TLV is found in Section "FT Protection 
   TLV".  

       FT Protection
         If present, specifies the FT/non-FT characteristics for the 
         label and whether the message has been re-issued for FT 
         recovery.
 
   
5.4 Label Release Message

   The LDP FT enhancements add the following optional parameter to a 
   Label Release message

         Optional Parameter    Length       Value
                             
         FT Protection TLV     4            See below

   The encoding for FT Protection TLV is found in Section "FT Protection 
   TLV".  

       FT Protection
         If present, specifies whether the Label Release message has 
         been re-issued for FT recovery.




Farrel et al.          Expires: August 2000                    [Page 18]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
         
   
5.5 Label Withdraw Message

   The LDP FT enhancements add the following optional parameter to a 
   Label Withdraw message

         Optional Parameter    Length       Value

         FT Protection TLV     4            See below

   The encoding for FT Protection TLV is found in Section "FT Protection 
   TLV".  

       FT Protection
         If present, specifies whether the Label Withdraw message has 
         been re-issued for FT recovery.
         
              
5.6 Label Abort Message

   The LDP FT enhancements add the following optional parameter to a 
   Label Abort message

         Optional Parameter    Length       Value

         FT Protection TLV     4            See below

   The encoding for FT Protection TLV is found in Section "FT Protection 
   TLV".  

       FT Protection
         If present, specifies whether the Label Abort message has 
         been re-issued for FT recovery.
   

5.7 Notification Request Message

   The LDP FT enhancements add the following optional parameter to a 
   Notification message

         Optional Parameter    Length       Value

         FT Protection TLV     4            See below

   The encoding for FT Protection TLV is found in Section "FT Protection 
   TLV".  

       FT Protection
         If present, specifies whether the Label Release message has 
         been issued in response to an FT Duplicate LDP message.
         for FT 




Farrel et al.          Expires: August 2000                    [Page 19]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000

    
6. New Fields and Values

6.1 Status Codes
        
   The following new status codes are defined to indicate various error 
   conditions specific to the LDP FT enhancements.  These status codes 
   are carried in the Status TLV of a Notification message.

   The "E" column is the required setting of the Status Code E-bit; the
   "Status Data" column is the value of the 30-bit Status Data field in
   the Status Code TLV.

   Note that the setting of the Status Code F-bit is at the discretion 
   of the LSR originating the Status TLV.  However, it is RECOMMENDED 
   that the F-bit is not set on Notification messages containing  
   status codes 0x00000017 - 0x00000019 because the duplication of 
   messages SHOULD be restricted to being a per-hop behavior.  

       Status Code                 E   Status Data
       
       No LDP Session              0   0x00000016
       Unexpected Duplicate /      1   0x00000017
          Duplicate Not Marked
       Unexpected Duplicate /      1   0x00000018
          Session Not FT
       Unexpected Duplicate /      0   0x00000019
          Non-FT Label   
       Temporary Shutdown          0   0x0000001A
       
   The Temporary Shutdown status code SHOULD be used in place of 
   the Shutdown status code (which carries the E-bit) if the LSR that is 
   shutting down wishes to inform its LDP peer that it expects to be 
   able to preserve FT label state and to return to service before the 
   FT Reconnection Timer expires.
        
   
6.2 FT Session TLV

   LDP peers can negotiate whether the LDP session between them supports
   FT extensions by using a new OPTIONAL parameter, the FT Session
   TLV, on LDP Initialization Messages.


   The FT Session TLV is encoded as follows.










Farrel et al.          Expires: August 2000                    [Page 20]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
    
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0| FT Session TLV (0x0503)   |      Length (= 4)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     FT Flags                  |      FT Session Timeout       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   FT Flags
     FT Flags: A 16 bit field that indicates various attributes the 
     FT support on this LDP session.  This fields is formatted as 
     follows:
     
     
          0                   1           
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |F|S|D|      Reserved           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
         F:    FT Session Flag.  
               Set to 1 if this LDP session is to use the LDP FT 
               Enhancements defined in this draft, and set to 0 
               otherwise. See the section "Establishing an FT LDP 
               Session" for details on how this flag is used.
               
         S:    FT State Flag.  
               Set to 1 if the sending LSR has preserved state and 
               resources for all FT-labels since the previous LDP 
               session between the same LDP peers, and set to 0 
               otherwise. See the section "LDP Session 
               Re-initialization" for details of how this flag is used.
               
         D:    FT Default Flag.
               Set to 1 if all labels exchanged on this LDP session are 
               to be treated as FT labels, or set to 0 if labels are to 
               default to non-FT labels. See the section "Identifying FT 
               Labels" for details of how this flag is used.
               
         All other bits in this field are currently reserved and SHOULD 
         be set to zero on transmission and ignored on receipt.
         
   
   FT Session Timeout
     The period of time the sending LSR will preserve state and 
     resources for FT labels exchanged on the previous instantiation of 
     an FT LDP session that has currently failed.  The timeout is 
     encoded as a 16-bit unsigned integer number of seconds.
     
     The value of 0 for this field is reserved and MUST NOT be used.
     
     See the section "LDP Session Failure" for details of how this field 
     is used.


Farrel et al.          Expires: August 2000                    [Page 21]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
   


6.3 FT Protection TLV

   LDP peers use the FT Protection TLV to override the FT Default Flag 
   (see section "FT Session TLV") for a specific label and to identify 
   LDP messages that have been reissued as part of the FT recovery 
   procedures.
   
   The FT Protection TLV MUST NOT be used in messages flowing on an LDP 
   session that does not support the LDP FT enhancements. 
   
   The FT Protection TLV is encoded as follows.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0| FT Protection (0x0203)    |      Length (= 4)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     FT Flags                  |      Reserved                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   FT Protection
     FT Protection: A 16 bit field that indicates various attributes of 
     the label and the LDP message.  This field is formatted as follows:
     
     
          0                   1           
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |L|R|        Reserved           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
         L:    FT Label Flag.  
               Set to 1 if this label is an FT label, and set to 0 
               otherwise. See the section "Identifying FT Labels" for 
               details on how this flag is used.  This field MUST be 
               ignored on all messages other than the initial Label 
               Request or Label Mapping message for a new label.
               
         R:    FT Duplicate Flag.  
               Set to 1 if the LDP message has been re-issued for 
               FT recovery, and set to 0 otherwise. See the section 
               "Procedure after TCP Re-connection" for details of how 
               this flag is used.


               
         All other bits in this field are currently reserved and SHOULD 
         be set to zero on transmission and ignored on receipt.
         
   Reserved
     A 16-bit field that is currently reserved.  This field SHOULD be 
     set to zero on transmission and ignored on receipt.

Farrel et al.          Expires: August 2000                    [Page 22]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
   
      
7. Example Use

   Consider two LDP peers, P1 and P2, implementing CR-LDP over a TCP
   connection that connects them.

   Let there be eleven LSPs in the following states when the TCP 
   connection fails and is recovered.

   L1: P1 has received a Label Request message from upstream and has
       sent a Label Request message to P2.  This request has not been
       received by P2.

   L2: P1 has received a Label Request message from upstream and has
       sent a Label Request message to P2. This request has been
       received at P2 which has sent a Label Request message on
       downstream. No Label Mapping message has been received by P2.

   L3: P1 has received a Label Request from upstream and has sent a
       Label Request to P2. This has been rejected by P2 which has
       sent a Notification message to P1. This Notification has not
       been received by P1.

   L4: P1 has received a Label Request message from upstream and has
       sent a Label Request message to P2. This request has been
       received at P2 which has sent a Label Request message on
       downstream.
       P2 has received a Label Mapping message from down stream and has
       forwarded it to P1. The Label Mapping message has not been
       received by P1.

   L5: P1 has received a Label Request message from upstream and has
       sent a Label Request message to P2. This request has been
       received at P2 which has sent a Label Request message on
       downstream.
       P2 has received a Label Mapping message from down stream and has
       forwarded it to P1. P1 has received the Label Mapping message
       and has forwarded it upstream.

   L6: This LSP was previously successfully established. P1 has received
       a Label Release message from upstream and has sent a Label
       Release message to P2.  This request has not been received by
       P2.

   L7: This LSP was previously successfully established. P1 has received
       a Label Release message from upstream and has sent a Label
       Release message to P2.  This request has been received by P2
       which forwarded it downstream and sent a Notification 
       acknowledgement (with OK status code) upstream to P1.
       The Notification has not been received by P1.

   L8: P2 sent a unsolicited Label Mapping to P1.  P1 has 
       sent a Notification acknowledgement, but this has not been 
       received by P2.

Farrel et al.          Expires: August 2000                    [Page 23]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
   
   L9: P1 has received a Label Request message from upstream and has
       sent a Label Request message to P2. This request has been
       received at P2 which has sent a Label Request message on
       downstream.
       P1 has received a Label Abort from Upstream and has sent the 
       Label Abort to P2, but this has not been received by P2.       

   L10: As L9, but P2 has received a Label Mapping from downstream and 
        sent it on to P1, though this has not been received by P1.
               
   L11: As 9, but P2 also receives a Label Withdraw from downstream 
        while the TCP connection is down.
      
   On recovery of the TCP connection, the processing of each LSP at
   each LSR is as follows.

   L1:  P1: Resend Label Request message to P2.
        P2: Treat duplicate Label Request message as new.
            Forward Label Request downstream.

   L1:  P1: Resend Label Request message to P2.
        P2: Ignore duplicate Label Request message.

   L3:  P1: Resend Label Request message to P2.
        P2: Treat duplicate Label Request message as new.
            If failure reason persists, send new Notification to P1
            Otherwise, forward Label Request downstream.

   L4:  P1: Resend Label Request message to P2.
        P2: Respond to duplicate Label Request message with duplicate
              Label Mapping message.

   L5:  P1: No work required. LSP is preserved.
        P2: No work required. LSP is preserved.

   L6:  P1: Resend Label Release message to P2.
        P2: Treat duplicate Label Release message as new.
            Forward Label Release message downstream.
            Send Notification (OK) to P1.

   L7:  P1: Resend Label Release message to P2.
        P2: Fail to match duplicate Label Release message to LSP.
            Send Notification (OK) to P1.
   
   L8:  P2: Resend Label Mapping
        P1: Respond to duplicate Label Mapping with duplicate 
              Notification (OK) to P2.
              
   L9:  P1: Send duplicate Label Abort
        P2: Treat Label Abort message as new.
            Forward Label Abort downstream.


Farrel et al.          Expires: August 2000                    [Page 24]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
            
   L10: P1: Resend Label Abort.
        P2: Resend Label Mapping
        P1: Receive duplicate Label Mapping and treat it as new.
            Send Label Release to P2 to tear down label.
        P2: Ignore duplicate Label Abort.
            Process Label Release as new when it is received.
            
   L11: P1: Resend Label Abort.
        P2: Send Label Withdraw.
            Ignore duplicate Label Abort.    
        P1: Receive Label Withdraw and process it as new.

   
8. Security Considerations

   The LDP FT enhancements inherit similar security considerations to 
   those discussed in [2] and [4].
   
   The LDP FT enhancements allow the re-establishment of a TCP 
   connection between LDP peers without a full re-exchange of the 
   attributes of established labels, which renders LSRs that implement 
   the extensions specified in this draft vulnerable to additional 
   denial-of-service attacks as follows:
   
   -  An intruder may impersonate an LDP peer in order to force a 
      failure and reconnection of the TCP connection, but where the 
      intruder does not set the FT State Flag on re-connection.  This 
      forces all FT labels to be released.
      
   -  Similarly, an intruder could set the FT State Flag on 
      re-establishment of the TCP session without preserving the state 
      and resources for FT labels.
   
   -  An intruder could intercept the traffic between LDP peers and 
      override the setting of the FT Label Flag to be set to 0 for 
      all labels.
      
   All of these attacks may be countered by use of an authentication 
   scheme between LDP peers, such as the scheme outlined in [4].
   
   
   Alternative authentication schemes for LDP peers are outside the 
   scope of this draft, but could be deployed to provide enhanced 
   security to implementations of LDP, CR-LDP and the LDP FT 
   enhancements.
   
   The RECOMMENDED use of new message IDs for re-issued messages (see 
   section "Issuing FT Duplicate Messages") is intended to help 
   counter replay attacks, when used in conjunction with encryption or 
   signing of the LDP session traffic. See [4] for details of how to 
   apply MD5 signatures to LDP session traffic.






Farrel et al.          Expires: August 2000                    [Page 25]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
   
   
9. Acknowledgments

   The work in this draft is based on the LDP and CR-LSP ideas
   expressed by the authors of [2] and [4].

   The authors would also like to acknowledge the careful review and
   comments of Nick Weeds, Piers Finlayson, Tim Harrison and Duncan 
   Archer at Data Connection Ltd.

   
10. Intellectual Property Consideration
   
   Data Connection may seek patent or other intellectual property 
   protection for some of the technologies disclosed in this document.  
   If any standards arising from this document are or become protected 
   by one or more patents assigned to Data Connection, Data Connection 
   intends to make a license available to any qualified applicant under 
   reasonable and non-discriminatory terms.  


11. References

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Jamoussi, B., et. al., Constraint-Based LSP Setup using LDP,
      draft-ietf-mpls-cr-ldp-03.txt, September 1999,(work in progress).

   3  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

   4  Andersson, L., et. al., LDP Specification, draft-ietf-mpls-ldp-
      06.txt, October 1999 (work in progress).

   5  Ash, G., et al., LSP Modification Using CR-LDP, draft-ietf-mpls-
      crlsp-modify-00.txt, December 1999 (work in progress).

   6  Braden, R., et al., Resource ReSerVation Protocol (RSVP) --
      Version 1, Functional Specification, RFC 2205, September 1997.

   7  Berger, L., et al., RSVP Refresh Reduction Extensions, draft-
      ietf-rsvp-refresh-reduct-02.txt, February 2000 (work in progress).

   8  Swallow, G., et al,. Extensions to RSVP for LSP Tunnels, draft-
      ietf-mpls-rsvp-lsp-tunnel-04.txt, September 1999 (work in
      progress).








Farrel et al.          Expires: August 2000                    [Page 26]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
   

12. Authors' Addresses

   Adrian Farrel                           Paul Brittain             
   Data Connection Ltd.                    Data Connection Ltd.      
   Windsor House                           Windsor House             
   Pepper Street                           Pepper Street             
   Chester                                 Chester                   
   Cheshire                                Cheshire                  
   CH1 1DF                                 CH1 1DF                   
   UK                                      UK                        
   Phone: +44-(0)-1244-313440              Phone: +44-(0)-1244-313440
   Fax:   +44-(0)-1244-312422              Fax:   +44-(0)-1244-312422
   Email: af@datcon.co.uk                  Email: pjb@datcon.co.uk    


13. Full Copyright Statement

   Copyright (c) The Internet Society (2000). All Rights Reserved. This
   document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.  


14. IANA Considerations

   This draft requires the use of a number of new TLVs and status codes 
   from the number spaces within the LDP protocol.  This section 
   explains the logic used by the authors to choose the most appropriate 
   number space for each new entity, and is intended to assist in the 
   determination of any final values assigned by IANA or the MPLS WG in 
   the event that the MPLS WG chooses to advance this draft on the 
   standards track.  


Farrel et al.          Expires: August 2000                    [Page 27]

draft-farrel-mpls-ldp-ft-00.txt                            February 2000
   
   
14.1 FT Session TLV   
   
   The FT Session TLV carries attributes that affect the entire LDP 
   session between LDP peers.  It is suggested that the type for this 
   TLV should be chosen from the 0x05xx range for TLVs that is used in 
   [4] by other TLVs carrying session-wide attributes.  At the time of 
   this writing, the next available number in this range is 0x0503.
    

14.2 FT Protection TLV   
   
   The FT Protection TLV carries attributes that affect a single label 
   exchanged between LDP peers.  It is suggested that the type for this 
   TLV should be chosen from the 0x02xx range for TLVs that is used in 
   [4] by other TLVs carrying label attributes.  At the time of this 
   writing, the next available number in this range is 0x0203.
   
   Consideration was given to carrying the FT Label Flag and FT 
   Duplicate Flag in the ActFlg field within the LSPID TLV [2].  The 
   authors felt that this would be inappropriate as the LSPID TLV is not 
   used on a "pure LDP" (as opposed to CR-LDP) session.  
    
   Consideration was also given to modifying the existing Label TLVs to 
   carry these flags.  The authors felt this would be too great a change 
   to the use of the existing Label TLVs to introduce at this stage in 
   the development of [4].
   
   
14.3 Status Codes

   The authors' current understanding is that MPLS status codes are not 
   sub-divided into specific ranges for different types of error.  
   Hence, the numeric status code values suggested in this draft are 
   simply the next available values at the time of writing and may be 
   substituted for other numeric values. 
   
   See section "Status Codes" for details of the status codes defined in 
   this draft.  
   
    

    



Farrel et al.          Expires: August 2000                    [Page 28]