[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/