tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3036


Pages: 132
Top     in Index     Prev     Next
 

LDP Specification

Part 1 of 4, p. 1 to 30
None       Next RFC Part

Obsoleted by:    5036


Top       ToC       Page 1 
Network Working Group                                        L. Andersson
Request for Comments: 3036                           Nortel Networks Inc.
Category: Standards Track                                       P. Doolan
                                                        Ennovate Networks
                                                               N. Feldman
                                                                 IBM Corp
                                                              A. Fredette
                                                            PhotonEx Corp
                                                                B. Thomas
                                                      Cisco Systems, Inc.
                                                             January 2001


                           LDP Specification

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   The architecture for Multi Protocol Label Switching (MPLS) is
   described in RFC 3031.  A fundamental concept in MPLS is that two
   Label Switching Routers (LSRs) must agree on the meaning of the
   labels used to forward traffic between and through them.  This common
   understanding is achieved by using a set of procedures, called a
   label distribution protocol, by which one LSR informs another of
   label bindings it has made.  This document defines a set of such
   procedures called LDP (for Label Distribution Protocol) by which LSRs
   distribute labels to support MPLS forwarding along normally routed
   paths.

Top       Page 2 
Table of Contents

   1          LDP Overview  .......................................   5
   1.1        LDP Peers  ..........................................   6
   1.2        LDP Message Exchange  ...............................   6
   1.3        LDP Message Structure  ..............................   7
   1.4        LDP Error Handling  .................................   7
   1.5        LDP Extensibility and Future Compatibility  .........   7
   1.6        Specification Language  .............................   7
   2          LDP Operation  ......................................   8
   2.1        FECs  ...............................................   8
   2.2        Label Spaces, Identifiers, Sessions and Transport  ..   9
   2.2.1      Label Spaces  .......................................   9
   2.2.2      LDP Identifiers  ....................................  10
   2.2.3      LDP Sessions  .......................................  10
   2.2.4      LDP Transport  ......................................  11
   2.3        LDP Sessions between non-Directly Connected LSRs  ...  11
   2.4        LDP Discovery   .....................................  11
   2.4.1      Basic Discovery Mechanism  ..........................  12
   2.4.2      Extended Discovery Mechanism  .......................  12
   2.5        Establishing and Maintaining LDP Sessions  ..........  13
   2.5.1      LDP Session Establishment  ..........................  13
   2.5.2      Transport Connection Establishment  .................  13
   2.5.3      Session Initialization  .............................  14
   2.5.4      Initialization State Machine  .......................  17
   2.5.5      Maintaining Hello Adjacencies  ......................  20
   2.5.6      Maintaining LDP Sessions  ...........................  20
   2.6        Label Distribution and Management  ..................  21
   2.6.1      Label Distribution Control Mode  ....................  21
   2.6.1.1    Independent Label Distribution Control  .............  21
   2.6.1.2    Ordered Label Distribution Control  .................  21
   2.6.2      Label Retention Mode  ...............................  22
   2.6.2.1    Conservative Label Retention Mode  ..................  22
   2.6.2.2    Liberal Label Retention Mode  .......................  22
   2.6.3      Label Advertisement Mode  ...........................  23
   2.7        LDP Identifiers and Next Hop Addresses  .............  23
   2.8        Loop Detection  .....................................  24
   2.8.1      Label Request Message  ..............................  24
   2.8.2      Label Mapping Message  ..............................  26
   2.8.3      Discussion  .........................................  27
   2.9        Authenticity and Integrity of LDP Messages  .........  28
   2.9.1      TCP MD5 Signature Option  ...........................  28
   2.9.2      LDP Use of TCP MD5 Signature Option  ................  30
   2.10       Label Distribution for Explicitly Routed LSPs  ......  30
   3          Protocol Specification  .............................  31
   3.1        LDP PDUs  ...........................................  31
   3.2        LDP Procedures  .....................................  32
   3.3        Type-Length-Value Encoding  .........................  32

Top      ToC       Page 3 
   3.4        TLV Encodings for Commonly Used Parameters  .........  34
   3.4.1      FEC TLV  ............................................  34
   3.4.1.1    FEC Procedures  .....................................  37
   3.4.2      Label TLVs  .........................................  37
   3.4.2.1    Generic Label TLV  ..................................  37
   3.4.2.2    ATM Label TLV  ......................................  38
   3.4.2.3    Frame Relay Label TLV  ..............................  38
   3.4.3      Address List TLV  ...................................  39
   3.4.4      Hop Count TLV  ......................................  40
   3.4.4.1    Hop Count Procedures  ...............................  40
   3.4.5      Path Vector TLV  ....................................  41
   3.4.5.1    Path Vector Procedures  .............................  42
   3.4.5.1.1  Label Request Path Vector  ..........................  42
   3.4.5.1.2  Label Mapping Path Vector  ..........................  43
   3.4.6      Status TLV  .........................................  43
   3.5        LDP Messages  .......................................  45
   3.5.1      Notification Message  ...............................  47
   3.5.1.1    Notification Message Procedures  ....................  48
   3.5.1.2    Events Signaled by Notification Messages  ...........  49
   3.5.1.2.1  Malformed PDU or Message  ...........................  49
   3.5.1.2.2  Unknown or Malformed TLV  ...........................  50
   3.5.1.2.3  Session KeepAlive Timer Expiration  .................  50
   3.5.1.2.4  Unilateral Session Shutdown  ........................  51
   3.5.1.2.5  Initialization Message Events  ......................  51
   3.5.1.2.6  Events Resulting From Other Messages  ...............  51
   3.5.1.2.7  Internal Errors  ....................................  51
   3.5.1.2.8  Miscellaneous Events  ...............................  51
   3.5.2      Hello Message  ......................................  51
   3.5.2.1    Hello Message Procedures  ...........................  54
   3.5.3      Initialization Message  .............................  55
   3.5.3.1    Initialization Message Procedures  ..................  63
   3.5.4      KeepAlive Message  ..................................  63
   3.5.4.1    KeepAlive Message Procedures  .......................  63
   3.5.5      Address Message  ....................................  64
   3.5.5.1    Address Message Procedures  .........................  64
   3.5.6      Address Withdraw Message  ...........................  65
   3.5.6.1    Address Withdraw Message Procedures  ................  66
   3.5.7      Label Mapping Message  ..............................  66
   3.5.7.1    Label Mapping Message Procedures  ...................  67
   3.5.7.1.1  Independent Control Mapping  ........................  67
   3.5.7.1.2  Ordered Control Mapping  ............................  68
   3.5.7.1.3  Downstream on Demand Label Advertisement  ...........  68
   3.5.7.1.4  Downstream Unsolicited Label Advertisement  .........  69
   3.5.8      Label Request Message  ..............................  69
   3.5.8.1    Label Request Message Procedures  ...................  70
   3.5.9      Label Abort Request Message  ........................  72
   3.5.9.1    Label Abort Request Message Procedures  .............  73
   3.5.10     Label Withdraw Message  .............................  74

Top      ToC       Page 4 
   3.5.10.1   Label Withdraw Message Procedures  ..................  75
   3.5.11     Label Release Message  ..............................  76
   3.5.11.1   Label Release Message Procedures  ...................  77
   3.6        Messages and TLVs for Extensibility  ................  78
   3.6.1      LDP Vendor-private Extensions  ......................  78
   3.6.1.1    LDP Vendor-private TLVs  ............................  78
   3.6.1.2    LDP Vendor-private Messages  ........................  80
   3.6.2      LDP Experimental Extensions  ........................  81
   3.7        Message Summary  ....................................  81
   3.8        TLV Summary  ........................................  82
   3.9        Status Code Summary  ................................  83
   3.10       Well-known Numbers  .................................  84
   3.10.1     UDP and TCP Ports  ..................................  84
   3.10.2     Implicit NULL Label  ................................  84
   4          IANA Considerations  ................................  84
   4.1        Message Type Name Space  ............................  84
   4.2        TLV Type Name Space  ................................  85
   4.3        FEC Type Name Space  ................................  85
   4.4        Status Code Name Space  .............................  86
   4.5        Experiment ID Name Space  ...........................  86
   5          Security Considerations  ............................  86
   5.1        Spoofing  ...........................................  86
   5.2        Privacy  ............................................  87
   5.3        Denial of Service  ..................................  87
   6          Areas for Future Study  .............................  89
   7          Intellectual Property Considerations  ...............  89
   8          Acknowledgments  ....................................  89
   9          References  .........................................  89
   10         Authors' Addresses  .................................  92
   Appendix A LDP Label Distribution Procedures  ..................  93
   A.1        Handling Label Distribution Events  .................  95
   A.1.1      Receive Label Request  ..............................  96
   A.1.2      Receive Label Mapping  ..............................  99
   A.1.3      Receive Label Abort Request  ........................ 105
   A.1.4      Receive Label Release  .............................. 107
   A.1.5      Receive Label Withdraw  ............................. 109
   A.1.6      Recognize New FEC  .................................. 110
   A.1.7      Detect Change in FEC Next Hop  ...................... 113
   A.1.8      Receive Notification / Label Request Aborted  ....... 116
   A.1.9      Receive Notification / No Label Resources  .......... 116
   A.1.10     Receive Notification / No Route  .................... 117
   A.1.11     Receive Notification / Loop Detected  ............... 118
   A.1.12     Receive Notification / Label Resources Available  ... 118
   A.1.13     Detect local label resources have become available  . 119
   A.1.14     LSR decides to no longer label switch a FEC  ........ 120
   A.1.15     Timeout of deferred label request  .................. 121
   A.2        Common Label Distribution Procedures  ............... 121
   A.2.1      Send_Label  ......................................... 121

Top      ToC       Page 5 
   A.2.2      Send_Label_Request  ................................. 123
   A.2.3      Send_Label_Withdraw  ................................ 124
   A.2.4      Send_Notification  .................................. 125
   A.2.5      Send_Message  ....................................... 125
   A.2.6      Check_Received_Attributes  .......................... 126
   A.2.7      Prepare_Label_Request_Attributes  ................... 127
   A.2.8      Prepare_Label_Mapping_Attributes  ................... 129
   Full Copyright Statement  ...................................... 132

1. LDP Overview

   The MPLS architecture [RFC3031] defines a label distribution protocol
   as a set of procedures by which one Label Switched Router (LSR)
   informs another of the meaning of labels used to forward traffic
   between and through them.

   The MPLS architecture does not assume a single label distribution
   protocol.  In fact, a number of different label distribution
   protocols are being standardized.  Existing protocols have been
   extended so that label distribution can be piggybacked on them.  New
   protocols have also been defined for the explicit purpose of
   distributing labels.  The MPLS architecture discusses some of the
   considerations when choosing a label distribution protocol for use in
   particular MPLS applications such as Traffic Engineering [RFC2702].

   The Label Distribution Protocol (LDP) defined in this document is a
   new protocol defined for distributing labels.  It is the set of
   procedures and messages by which Label Switched Routers (LSRs)
   establish Label Switched Paths (LSPs) through a network by mapping
   network-layer routing information directly to data-link layer
   switched paths.  These LSPs may have an endpoint at a directly
   attached neighbor (comparable to IP hop-by-hop forwarding), or may
   have an endpoint at a network egress node, enabling switching via all
   intermediary nodes.

   LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] with
   each LSP it creates.  The FEC associated with an LSP specifies which
   packets are "mapped" to that LSP.  LSPs are extended through a
   network as each LSR "splices" incoming labels for a FEC to the
   outgoing label assigned to the next hop for the given FEC.

   More information about the applicability of LDP can be found in
   [RFC3037].

   This document assumes familiarity with the MPLS architecture
   [RFC3031].  Note that [RFC3031] includes a glossary of MPLS
   terminology, such as ingress, label switched path, etc.

Top      ToC       Page 6 
1.1. LDP Peers

   Two LSRs which use LDP to exchange label/FEC mapping information are
   known as "LDP Peers" with respect to that information and we speak of
   there being an "LDP Session" between them.  A single LDP session
   allows each peer to learn the other's label mappings; i.e., the
   protocol is bi-directional.

1.2. LDP Message Exchange

   There are four categories of LDP messages:

      1. Discovery messages, used to announce and maintain the presence
         of an LSR in a network.

      2. Session messages, used to establish, maintain, and terminate
         sessions between LDP peers.

      3. Advertisement messages, used to create, change, and delete
         label mappings for FECs.

      4. Notification messages, used to provide advisory information and
         to signal error information.

   Discovery messages provide a mechanism whereby LSRs indicate their
   presence in a network by sending a Hello message periodically.  This
   is transmitted as a UDP packet to the LDP port at the `all routers on
   this subnet' group multicast address.  When an LSR chooses to
   establish a session with another LSR learned via the Hello message,
   it uses the LDP initialization procedure over TCP transport.  Upon
   successful completion of the initialization procedure, the two LSRs
   are LDP peers, and may exchange advertisement messages.

   When to request a label or advertise a label mapping to a peer is
   largely a local decision made by an LSR.  In general, the LSR
   requests a label mapping from a neighboring LSR when it needs one,
   and advertises a label mapping to a neighboring LSR when it wishes
   the neighbor to use a label.

   Correct operation of LDP requires reliable and in order delivery of
   messages.  To satisfy these requirements LDP uses the TCP transport
   for session, advertisement and notification messages; i.e., for
   everything but the UDP-based discovery mechanism.

Top      ToC       Page 7 
1.3. LDP Message Structure

   All LDP messages have a common structure that uses a Type-Length-
   Value (TLV) encoding scheme; see Section "Type-Length-Value"
   encoding.  The Value part of a TLV-encoded object, or TLV for short,
   may itself contain one or more TLVs.

1.4. LDP Error Handling

   LDP errors and other events of interest are signaled to an LDP peer
   by notification messages.

   There are two kinds of LDP notification messages:

      1. Error notifications, used to signal fatal errors.  If an LSR
         receives an error notification from a peer for an LDP session,
         it terminates the LDP session by closing the TCP transport
         connection for the session and discarding all label mappings
         learned via the session.

      2. Advisory notifications, used to pass an LSR information about
         the LDP session or the status of some previous message received
         from the peer.

1.5. LDP Extensibility and Future Compatibility

   Functionality may be added to LDP in the future.  It is likely that
   future functionality will utilize new messages and object types
   (TLVs).  It may be desirable to employ such new messages and TLVs
   within a network using older implementations that do not recognize
   them.  While it is not possible to make every future enhancement
   backwards compatible, some prior planning can ease the introduction
   of new capabilities.  This specification defines rules for handling
   unknown message types and unknown TLVs for this purpose.

1.6. Specification Language

   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 [RFC2119].

Top      ToC       Page 8 
2. LDP Operation

2.1. FECs

   It is necessary to precisely specify which packets may be mapped to
   each LSP.  This is done by providing a FEC specification for each
   LSP.  The FEC identifies the set of IP packets which may be mapped to
   that LSP.

   Each FEC is specified as a set of one or more FEC elements.  Each FEC
   element identifies a set of packets which may be mapped to the
   corresponding LSP.  When an LSP is shared by multiple FEC elements,
   that LSP is terminated at (or before) the node where the FEC elements
   can no longer share the same path.

   Following are the currently defined types of FEC elements.  New
   element types may be added as needed:

      1. Address Prefix.  This element is an address prefix of any
         length from 0 to a full address, inclusive.

      2. Host Address.  This element is a full host address.

   (We will see below that an Address Prefix FEC element which is a full
   address has a different effect than a Host Address FEC element which
   has the same address.)

   We say that a particular address "matches" a particular address
   prefix if and only if that address begins with that prefix.  We also
   say that a particular packet matches a particular LSP if and only if
   that LSP has an Address Prefix FEC element which matches the packet's
   destination address.  With respect to a particular packet and a
   particular LSP, we refer to any Address Prefix FEC element which
   matches the packet as the "matching prefix".

   The procedure for mapping a particular packet to a particular LSP
   uses the following rules.  Each rule is applied in turn until the
   packet can be mapped to an LSP.

      -  If there is exactly one LSP which has a Host Address FEC
         element that is identical to the packet's destination address,
         then the packet is mapped to that LSP.

      -  If there are multiple LSPs, each containing a Host Address FEC
         element that is identical to the packet's destination address,
         then the packet is mapped to one of those LSPs.  The procedure
         for selecting one of those LSPs is beyond the scope of this
         document.

Top      ToC       Page 9 
      -  If a packet matches exactly one LSP, the packet is mapped to
         that LSP.

      -  If a packet matches multiple LSPs, it is mapped to the LSP
         whose matching prefix is the longest.  If there is no one LSP
         whose matching prefix is longest, the packet is mapped to one
         from the set of LSPs whose matching prefix is longer than the
         others.  The procedure for selecting one of those LSPs is
         beyond the scope of this document.

      -  If it is known that a packet must traverse a particular egress
         router, and there is an LSP which has an Address Prefix FEC
         element which is an address of that router, then the packet is
         mapped to that LSP.  The procedure for obtaining this knowledge
         is beyond the scope of this document.

   The procedure for determining that a packet must traverse a
   particular egress router is beyond the scope of this document.  (As
   an example, if one is running a link state routing algorithm, it may
   be possible to obtain this information from the link state data base.
   As another example, if one is running BGP, it may be possible to
   obtain this information from the BGP next hop attribute of the
   packet's route.)

   It is worth pointing out a few consequences of these rules:

      -  A packet may be sent on the LSP whose Address Prefix FEC
         element is the address of the packet's egress router ONLY if
         there is no LSP matching the packet's destination address.

      -  A packet may match two LSPs, one with a Host Address FEC
         element and one with an Address Prefix FEC element.  In this
         case, the packet is always assigned to the former.

      -  A packet which does not match a particular Host Address FEC
         element may not be sent on the corresponding LSP, even if the
         Host Address FEC element identifies the packet's egress router.

2.2. Label Spaces, Identifiers, Sessions and Transport

2.2.1. Label Spaces

   The notion of "label space" is useful for discussing the assignment
   and distribution of labels.  There are two types of label spaces:

Top      ToC       Page 10 
      -  Per interface label space.  Interface-specific incoming labels
         are used for interfaces that use interface resources for
         labels.  An example of such an interface is a label-controlled
         ATM interface that uses VCIs as labels, or a Frame Relay
         interface that uses DLCIs as labels.

         Note that the use of a per interface label space only makes
         sense when the LDP peers are "directly connected" over an
         interface, and the label is only going to be used for traffic
         sent over that interface.

      -  Per platform label space.  Platform-wide incoming labels are
         used for interfaces that can share the same labels.

2.2.2. LDP Identifiers

   An LDP identifier is a six octet quantity used to identify an LSR
   label space.  The first four octets identify the LSR and must be a
   globally unique value, such as a 32-bit router Id assigned to the
   LSR.  The last two octets identify a specific label space within the
   LSR.  The last two octets of LDP Identifiers for platform-wide label
   spaces are always both zero.  This document uses the following print
   representation for LDP Identifiers:

             <LSR Id> : <label space id>

   e.g., lsr171:0, lsr19:2.

   Note that an LSR that manages and advertises multiple label spaces
   uses a different LDP Identifier for each such label space.

   A situation where an LSR would need to advertise more than one label
   space to a peer and hence use more than one LDP Identifier occurs
   when the LSR has two links to the peer and both are ATM (and use per
   interface labels).  Another situation would be where the LSR had two
   links to the peer, one of which is ethernet (and uses per platform
   labels) and the other of which is ATM.

2.2.3. LDP Sessions

   LDP sessions exist between LSRs to support label exchange between
   them.

      When an LSR uses LDP to advertise more than one label space to
      another LSR it uses a separate LDP session for each label space.

Top      ToC       Page 11 
2.2.4. LDP Transport

   LDP uses TCP as a reliable transport for sessions.

      When multiple LDP sessions are required between two LSRs there is
      one TCP session for each LDP session.

2.3. LDP Sessions between non-Directly Connected LSRs

   LDP sessions between LSRs that are not directly connected at the link
   level may be desirable in some situations.

   For example, consider a "traffic engineering" application where LSRa
   sends traffic matching some criteria via an LSP to non-directly
   connected LSRb rather than forwarding the traffic along its normally
   routed path.

   The path between LSRa and LSRb would include one or more intermediate
   LSRs (LSR1,...LSRn).  An LDP session between LSRa and LSRb would
   enable LSRb to label switch traffic arriving on the LSP from LSRa by
   providing LSRb means to advertise labels for this purpose to LSRa.

   In this situation LSRa would apply two labels to traffic it forwards
   on the LSP to LSRb: a label learned from LSR1 to forward traffic
   along the LSP path from LSRa to LSRb; and a label learned from LSRb
   to enable LSRb to label switch traffic arriving on the LSP.

   LSRa first adds the label learned via its LDP session with LSRb to
   the packet label stack (either by replacing the label on top of the
   packet label stack with it if the packet arrives labeled or by
   pushing it if the packet arrives unlabeled).  Next, it pushes the
   label for the LSP learned from LSR1 onto the label stack.

2.4. LDP Discovery

   LDP discovery is a mechanism that enables an LSR to discover
   potential LDP peers.  Discovery makes it unnecessary to explicitly
   configure an LSR's label switching peers.

   There are two variants of the discovery mechanism:

      -  A basic discovery mechanism used to discover LSR neighbors that
         are directly connected at the link level.

      -  An extended discovery mechanism used to locate LSRs that are
         not directly connected at the link level.

Top      ToC       Page 12 
2.4.1. Basic Discovery Mechanism

   To engage in LDP Basic Discovery on an interface an LSR periodically
   sends LDP Link Hellos out the interface.  LDP Link Hellos are sent as
   UDP packets addressed to the well-known LDP discovery port for the
   "all routers on this subnet" group multicast address.

   An LDP Link Hello sent by an LSR carries the LDP Identifier for the
   label space the LSR intends to use for the interface and possibly
   additional information.

   Receipt of an LDP Link Hello on an interface identifies a "Hello
   adjacency" with a potential LDP peer reachable at the link level on
   the interface as well as the label space the peer intends to use for
   the interface.

2.4.2. Extended Discovery Mechanism

   LDP sessions between non-directly connected LSRs are supported by LDP
   Extended Discovery.

   To engage in LDP Extended Discovery an LSR periodically sends LDP
   Targeted Hellos to a specific address.  LDP Targeted Hellos are sent
   as UDP packets addressed to the well-known LDP discovery port at the
   specific address.

   An LDP Targeted Hello sent by an LSR carries the LDP Identifier for
   the label space the LSR intends to use and possibly additional
   optional information.

   Extended Discovery differs from Basic Discovery in the following
   ways:

      -  A Targeted Hello is sent to a specific address rather than to
         the "all routers" group multicast address for the outgoing
         interface.

      -  Unlike Basic Discovery, which is symmetric, Extended Discovery
         is asymmetric.

         One LSR initiates Extended Discovery with another targeted LSR,
         and the targeted LSR decides whether to respond to or ignore
         the Targeted Hello.  A targeted LSR that chooses to respond
         does so by periodically sending Targeted Hellos to the
         initiating LSR.

Top      ToC       Page 13 
   Receipt of an LDP Targeted Hello identifies a "Hello adjacency" with
   a potential LDP peer reachable at the network level and the label
   space the peer intends to use.

2.5. Establishing and Maintaining LDP Sessions

2.5.1. LDP Session Establishment

   The exchange of LDP Discovery Hellos between two LSRs triggers LDP
   session establishment.  Session establishment is a two step process:

            -  Transport connection establishment.
            -  Session initialization

   The following describes establishment of an LDP session between LSRs
   LSR1 and LSR2 from LSR1's point of view.  It assumes the exchange of
   Hellos specifying label space LSR1:a for LSR1 and label space LSR2:b
   for LSR2.

2.5.2. Transport Connection Establishment

   The exchange of Hellos results in the creation of a Hello adjacency
   at LSR1 that serves to bind the link (L) and the label spaces LSR1:a
   and LSR2:b.

      1. If LSR1 does not already have an LDP session for the exchange
         of label spaces LSR1:a and LSR2:b it attempts to open a TCP
         connection for a new LDP session with LSR2.

         LSR1 determines the transport addresses to be used at its end
         (A1) and LSR2's end (A2) of the LDP TCP connection.  Address A1
         is determined as follows:

         a. If LSR1 uses the Transport Address optional object (TLV) in
            Hello's it sends to LSR2 to advertise an address, A1 is the
            address LSR1 advertises via the optional object;

         b. If LSR1 does not use the Transport Address optional object,
            A1 is the source address used in Hellos it sends to LSR2.

         Similarly, address A2 is determined as follows:

         a. If LSR2 uses the Transport Address optional object, A2 is
            the address LSR2 advertises via the optional object;

         b. If LSR2 does not use the Transport Address optional object,
            A2 is the source address in Hellos received from LSR2.

Top      ToC       Page 14 
      2. LSR1 determines whether it will play the active or passive role
         in session establishment by comparing addresses A1 and A2 as
         unsigned integers.  If A1 > A2, LSR1 plays the active role;
         otherwise it is passive.

         The procedure for comparing A1 and A2 as unsigned integers is:

         -  If A1 and A2 are not in the same address family, they are
            incomparable, and no session can be established.

         -  Let U1 be the abstract unsigned integer obtained by treating
            A1 as a sequence of bytes, where the byte which appears
            earliest in the message is the most significant byte of the
            integer and the byte which appears latest in the message is
            the least significant byte of the integer.

            Let U2 be the abstract unsigned integer obtained from A2 in
            a similar manner.

         -  Compare U1 with U2.  If U1 > U2, then A1 > A2; if U1 < U2,
            then A1 < A2.

      3. If LSR1 is active, it attempts to establish the LDP TCP
         connection by connecting to the well-known LDP port at address
         A2.  If LSR1 is passive, it waits for LSR2 to establish the LDP
         TCP connection to its well-known LDP port.

   Note that when an LSR sends a Hello it selects the transport address
   for its end of the session connection and uses the Hello to advertise
   the address, either explicitly by including it in an optional
   Transport Address TLV or implicitly by omitting the TLV and using it
   as the Hello source address.

   An LSR MUST advertise the same transport address in all Hellos that
   advertise the same label space.  This requirement ensures that two
   LSRs linked by multiple Hello adjacencies using the same label spaces
   play the same connection establishment role for each adjacency.

2.5.3. Session Initialization

   After LSR1 and LSR2 establish a transport connection they negotiate
   session parameters by exchanging LDP Initialization messages.  The
   parameters negotiated include LDP protocol version, label
   distribution method, timer values, VPI/VCI ranges for label
   controlled ATM, DLCI ranges for label controlled Frame Relay, etc.

Top      ToC       Page 15 
   Successful negotiation completes establishment of an LDP session
   between LSR1 and LSR2 for the advertisement of label spaces LSR1:a
   and LSR2:b.

   The following describes the session initialization from LSR1's point
   of view.

   After the connection is established, if LSR1 is playing the active
   role, it initiates negotiation of session parameters by sending an
   Initialization message to LSR2.  If LSR1 is passive, it waits for
   LSR2 to initiate the parameter negotiation.

   In general when there are multiple links between LSR1 and LSR2 and
   multiple label spaces to be advertised by each, the passive LSR
   cannot know which label space to advertise over a newly established
   TCP connection until it receives the LDP Initialization message on
   the connection.  The Initialization message carries both the LDP
   Identifier for the sender's (active LSR's) label space and the LDP
   Identifier for the receiver's (passive LSR's) label space.

   By waiting for the Initialization message from its peer the passive
   LSR can match the label space to be advertised by the peer (as
   determined from the LDP Identifier in the PDU header for the
   Initialization message) with a Hello adjacency previously created
   when Hellos were exchanged.

      1. When LSR1 plays the passive role:

         a. If LSR1 receives an Initialization message it attempts to
            match the LDP Identifier carried by the message PDU with a
            Hello adjacency.

         b. If there is a matching Hello adjacency, the adjacency
            specifies the local label space for the session.

            Next LSR1 checks whether the session parameters proposed in
            the message are acceptable.  If they are, LSR1 replies with
            an Initialization message of its own to propose the
            parameters it wishes to use and a KeepAlive message to
            signal acceptance of LSR2's parameters.  If the parameters
            are not acceptable, LSR1 responds by sending a Session
            Rejected/Parameters Error Notification message and closing
            the TCP connection.

         c. If LSR1 cannot find a matching Hello adjacency it sends a
            Session Rejected/No Hello Error Notification message and
            closes the TCP connection.

Top      ToC       Page 16 
         d. If LSR1 receives a KeepAlive in response to its
            Initialization message, the session is operational from
            LSR1's point of view.

         e. If LSR1 receives an Error Notification message, LSR2 has
            rejected its proposed session and LSR1 closes the TCP
            connection.

      2. When LSR1 plays the active role:

         a. If LSR1 receives an Error Notification message, LSR2 has
            rejected its proposed session and LSR1 closes the TCP
            connection.

         b. If LSR1 receives an Initialization message, it checks
            whether the session parameters are acceptable.  If so, it
            replies with a KeepAlive message.  If the session parameters
            are unacceptable, LSR1 sends a Session Rejected/Parameters
            Error Notification message and closes the connection.

         c. If LSR1 receives a KeepAlive message, LSR2 has accepted its
            proposed session parameters.

         d. When LSR1 has received both an acceptable Initialization
            message and a KeepAlive message the session is operational
            from LSR1's point of view.

      It is possible for a pair of incompatibly configured LSRs that
      disagree on session parameters to engage in an endless sequence of
      messages as each NAKs the other's Initialization messages with
      Error Notification messages.

      An LSR must throttle its session setup retry attempts with an
      exponential backoff in situations where Initialization messages
      are being NAK'd.  It is also recommended that an LSR detecting
      such a situation take action to notify an operator.

      The session establishment setup attempt following a NAK'd
      Initialization message must be delayed no less than 15 seconds,
      and subsequent delays must grow to a maximum delay of no less than
      2 minutes.  The specific session establishment action that must be
      delayed is the attempt to open the session transport connection by
      the LSR playing the active role.

Top      ToC       Page 17 
      The throttled sequence of Initialization NAKs is unlikely to cease
      until operator intervention reconfigures one of the LSRs.  After
      such a configuration action there is no further need to throttle
      subsequent session establishment attempts (until their
      initialization messages are NAK'd).

      Due to the asymmetric nature of session establishment,
      reconfiguration of the passive LSR will go unnoticed by the active
      LSR without some further action.  Section "Hello Message"
      describes an optional mechanism an LSR can use to signal potential
      LDP peers that it has been reconfigured.

2.5.4. Initialization State Machine

   It is convenient to describe LDP session negotiation behavior in
   terms of a state machine.  We define the LDP state machine to have
   five possible states and present the behavior as a state transition
   table and as a state transition diagram.

Top      ToC       Page 18 
               Session Initialization State Transition Table

      STATE         EVENT                               NEW STATE

      NON EXISTENT  Session TCP connection established  INITIALIZED
                    established

      INITIALIZED   Transmit Initialization msg         OPENSENT
                          (Active Role)

                    Receive acceptable                  OPENREC
                          Initialization msg
                          (Passive Role )
                      Action: Transmit Initialization
                              msg and KeepAlive msg

                    Receive Any other LDP msg           NON EXISTENT
                      Action: Transmit Error Notification msg
                              (NAK) and close transport connection

      OPENREC       Receive KeepAlive msg               OPERATIONAL

                    Receive Any other LDP msg           NON EXISTENT
                      Action: Transmit Error Notification msg
                              (NAK) and close transport connection

      OPENSENT      Receive acceptable                  OPENREC
                          Initialization msg
                      Action: Transmit KeepAlive msg

                    Receive Any other LDP msg           NON EXISTENT
                      Action: Transmit Error Notification msg
                              (NAK) and close transport connection

      OPERATIONAL   Receive Shutdown msg                NON EXISTENT
                      Action: Transmit Shutdown msg and
                              close transport connection

                    Receive other LDP msgs              OPERATIONAL

                    Timeout                             NON EXISTENT
                      Action: Transmit Shutdown msg and
                              close transport connection

Top      ToC       Page 19 
               Session Initialization State Transition Diagram

                                 +------------+
                                 |            |
                   +------------>|NON EXISTENT|<--------------------+
                   |             |            |                     |
                   |             +------------+                     |
                   | Session        |    ^                          |
                   |   connection   |    |                          |
                   |   established  |    | Rx any LDP msg except    |
                   |                V    |   Init msg or Timeout    |
                   |            +-----------+                       |
      Rx Any other |            |           |                       |
         msg or    |            |INITIALIZED|                       |
         Timeout / |        +---|           |-+                     |
      Tx NAK msg   |        |   +-----------+ |                     |
                   |        | (Passive Role)  | (Active Role)       |
                   |        | Rx Acceptable   | Tx Init msg         |
                   |        |    Init msg /   |                     |
                   |        | Tx Init msg     |                     |
                   |        |    Tx KeepAlive |                     |
                   |        V    msg          V                     |
                   |   +-------+        +--------+                  |
                   |   |       |        |        |                  |
                   +---|OPENREC|        |OPENSENT|----------------->|
                   +---|       |        |        | Rx Any other msg |
                   |   +-------+        +--------+    or Timeout    |
      Rx KeepAlive |        ^                |     Tx NAK msg       |
         msg       |        |                |                      |
                   |        |                | Rx Acceptable        |
                   |        |                |    Init msg /        |
                   |        +----------------+ Tx KeepAlive msg     |
                   |                                                |
                   |      +-----------+                             |
                   +----->|           |                             |
                          |OPERATIONAL|                             |
                          |           |---------------------------->+
                          +-----------+     Rx Shutdown msg
                   All other  |   ^            or Timeout /
                     LDP msgs |   |         Tx Shutdown msg
                              |   |
                              +---+

Top      ToC       Page 20 
2.5.5. Maintaining Hello Adjacencies

   An LDP session with a peer has one or more Hello adjacencies.

   An LDP session has multiple Hello adjacencies when a pair of LSRs is
   connected by multiple links that share the same label space; for
   example, multiple PPP links between a pair of routers.  In this
   situation the Hellos an LSR sends on each such link carry the same
   LDP Identifier.

   LDP includes mechanisms to monitor the necessity of an LDP session
   and its Hello adjacencies.

   LDP uses the regular receipt of LDP Discovery Hellos to indicate a
   peer's intent to use the label space identified by the Hello.  An LSR
   maintains a hold timer with each Hello adjacency which it restarts
   when it receives a Hello that matches the adjacency.  If the timer
   expires without receipt of a matching Hello from the peer, LDP
   concludes that the peer no longer wishes to label switch using that
   label space for that link (or target, in the case of Targeted Hellos)
   or that the peer has failed.  The LSR then deletes the Hello
   adjacency.  When the last Hello adjacency for a LDP session is
   deleted, the LSR terminates the LDP session by sending a Notification
   message and closing the transport connection.

2.5.6. Maintaining LDP Sessions

   LDP includes mechanisms to monitor the integrity of the LDP session.

   LDP uses the regular receipt of LDP PDUs on the session transport
   connection to monitor the integrity of the session.  An LSR maintains
   a KeepAlive timer for each peer session which it resets whenever it
   receives an LDP PDU from the session peer.  If the KeepAlive timer
   expires without receipt of an LDP PDU from the peer the LSR concludes
   that the transport connection is bad or that the peer has failed, and
   it terminates the LDP session by closing the transport connection.

   After an LDP session has been established, an LSR must arrange that
   its peer receive an LDP PDU from it at least every KeepAlive time
   period to ensure the peer restarts the session KeepAlive timer.  The
   LSR may send any protocol message to meet this requirement.  In
   circumstances where an LSR has no other information to communicate to
   its peer, it sends a KeepAlive message.

   An LSR may choose to terminate an LDP session with a peer at any
   time.  Should it choose to do so, it informs the peer with a Shutdown
   message.

Top      ToC       Page 21 
2.6. Label Distribution and Management

   The MPLS architecture [RF3031] allows an LSR to distribute a FEC
   label binding in response to an explicit request from another LSR.
   This is known as Downstream On Demand label distribution.  It also
   allows an LSR to distribute label bindings to LSRs that have not
   explicitly requested them.  [RFC3031] calls this method of label
   distribution Unsolicited Downstream; this document uses the term
   Downstream Unsolicited.

   Both of these label distribution techniques may be used in the same
   network at the same time.  However, for any given LDP session, each
   LSR must be aware of the label distribution method used by its peer
   in order to avoid situations where one peer using Downstream
   Unsolicited label distribution assumes its peer is also.  See Section
   "Downstream on Demand label Advertisement".

2.6.1. Label Distribution Control Mode

   The behavior of the initial setup of LSPs is determined by whether
   the LSR is operating with independent or ordered LSP control.  An LSR
   may support both types of control as a configurable option.

2.6.1.1. Independent Label Distribution Control

   When using independent LSP control, each LSR may advertise label
   mappings to its neighbors at any time it desires.  For example, when
   operating in independent Downstream on Demand mode, an LSR may answer
   requests for label mappings immediately, without waiting for a label
   mapping from the next hop.  When operating in independent Downstream
   Unsolicited mode, an LSR may advertise a label mapping for a FEC to
   its neighbors whenever it is prepared to label-switch that FEC.

   A consequence of using independent mode is that an upstream label can
   be advertised before a downstream label is received.

2.6.1.2. Ordered Label Distribution Control

   When using LSP ordered control, an LSR may initiate the transmission
   of a label mapping only for a FEC for which it has a label mapping
   for the FEC next hop, or for which the LSR is the egress.  For each
   FEC for which the LSR is not the egress and no mapping exists, the
   LSR MUST wait until a label from a downstream LSR is received before
   mapping the FEC and passing corresponding labels to upstream LSRs.
   An LSR may be an egress for some FECs and a non-egress for others.
   An LSR may act as an egress LSR, with respect to a particular FEC,
   under any of the following conditions:

Top      ToC       Page 22 
      1. The FEC refers to the LSR itself (including one of its directly
         attached interfaces).

      2. The next hop router for the FEC is outside of the Label
         Switching Network.

      3. FEC elements are reachable by crossing a routing domain
         boundary, such as another area for OSPF summary networks, or
         another autonomous system for OSPF AS externals and BGP routes
         [RFC2328] [RFC1771].

   Note that whether an LSR is an egress for a given FEC may change over
   time, depending on the state of the network and LSR configuration
   settings.

2.6.2. Label Retention Mode

   The MPLS architecture [RFC3031] introduces the notion of label
   retention mode which specifies whether an LSR maintains a label
   binding for a FEC learned from a neighbor that is not its next hop
   for the FEC.

2.6.2.1. Conservative Label Retention Mode

   In Downstream Unsolicited advertisement mode, label mapping
   advertisements for all routes may be received from all peer LSRs.
   When using conservative label retention, advertised label mappings
   are retained only if they will be used to forward packets (i.e., if
   they are received from a valid next hop according to routing).  If
   operating in Downstream on Demand mode, an LSR will request label
   mappings only from the next hop LSR according to routing.  Since
   Downstream on Demand mode is primarily used when label conservation
   is desired (e.g., an ATM switch with limited cross connect space), it
   is typically used with the conservative label retention mode.

   The main advantage of the conservative mode is that only the labels
   that are required for the forwarding of data are allocated and
   maintained.  This is particularly important in LSRs where the label
   space is inherently limited, such as in an ATM switch.  A
   disadvantage of the conservative mode is that if routing changes the
   next hop for a given destination, a new label must be obtained from
   the new next hop before labeled packets can be forwarded.

2.6.2.2. Liberal Label Retention Mode

   In Downstream Unsolicited advertisement mode, label mapping
   advertisements for all routes may be received from all LDP peers.
   When using liberal label retention, every label mappings received

Top      ToC       Page 23 
   from a peer LSR is retained regardless of whether the LSR is the next
   hop for the advertised mapping.  When operating in Downstream on
   Demand mode with liberal label retention, an LSR might choose to
   request label mappings for all known prefixes from all peer LSRs.
   Note, however, that Downstream on Demand mode is typically used by
   devices such as ATM switch-based LSRs for which the conservative
   approach is recommended.

   The main advantage of the liberal label retention mode is that
   reaction to routing changes can be quick because labels already
   exist.  The main disadvantage of the liberal mode is that unneeded
   label mappings are distributed and maintained.

2.6.3. Label Advertisement Mode

   Each interface on an LSR is configured to operate in either
   Downstream Unsolicited or Downstream on Demand advertisement mode.
   LSRs exchange advertisement modes during initialization.  The major
   difference between Downstream Unsolicited and Downstream on Demand
   modes is in which LSR takes responsibility for initiating mapping
   requests and mapping advertisements.

2.7. LDP Identifiers and Next Hop Addresses

   An LSR maintains learned labels in a Label Information Base (LIB).
   When operating in Downstream Unsolicited mode, the LIB entry for an
   address prefix associates a collection of (LDP Identifier, label)
   pairs with the prefix, one such pair for each peer advertising a
   label for the prefix.

   When the next hop for a prefix changes the LSR must retrieve the
   label advertised by the new next hop from the LIB for use in
   forwarding.  To retrieve the label the LSR must be able to map the
   next hop address for the prefix to an LDP Identifier.

   Similarly, when the LSR learns a label for a prefix from an LDP peer,
   it must be able to determine whether that peer is currently a next
   hop for the prefix to determine whether it needs to start using the
   newly learned label when forwarding packets that match the prefix.
   To make that decision the LSR must be able to map an LDP Identifier
   to the peer's addresses to check whether any are a next hop for the
   prefix.

   To enable LSRs to map between a peer LDP identifier and the peer's
   addresses, LSRs advertise their addresses using LDP Address and
   Withdraw Address messages.

Top      ToC       Page 24 
   An LSR sends an Address message to advertise its addresses to a peer.
   An LSR sends a Withdraw Address message to withdraw previously
   advertised addresses from a peer

2.8. Loop Detection

   Loop detection is a configurable option which provides a mechanism
   for finding looping LSPs and for preventing Label Request messages
   from looping in the presence of non-merge capable LSRs.

   The mechanism makes use of Path Vector and Hop Count TLVs carried by
   Label Request and Label Mapping messages.  It builds on the following
   basic properties of these TLVs:

      -  A Path Vector TLV contains a list of the LSRs that its
         containing message has traversed.  An LSR is identified in a
         Path Vector list by its unique LSR Identifier (Id), which is
         the first four octets of its LDP Identifier.  When an LSR
         propagates a message containing a Path Vector TLV it adds its
         LSR Id to the Path Vector list.  An LSR that receives a message
         with a Path Vector that contains its LSR Id detects that the
         message has traversed a loop.  LDP supports the notion of a
         maximum allowable Path Vector length; an LSR that detects a
         Path Vector has reached the maximum length behaves as if the
         containing message has traversed a loop.

      -  A Hop Count TLV contains a count of the LSRS that the
         containing message has traversed.  When an LSR propagates a
         message containing a Hop Count TLV it increments the count.  An
         LSR that detects a Hop Count has reached a configured maximum
         value behaves as if the containing message has traversed a
         loop.  By convention a count of 0 is interpreted to mean the
         hop count is unknown.  Incrementing an unknown hop count value
         results in an unknown hop count value (0).

   The following paragraphs describes LDP loop detection procedures.
   For these paragraphs, and only these paragraphs, "MUST" is redefined
   to mean "MUST if configured for loop detection".  The paragraphs
   specify messages that must carry Path Vector and Hop Count TLVs.
   Note that the Hop Count TLV and its procedures are used without the
   Path Vector TLV in situations when loop detection is not configured
   (see [RFC3035] and [RFC3034]).

2.8.1. Label Request Message

   The use of the Path Vector TLV and Hop Count TLV prevent Label
   Request messages from looping in environments that include non-merge
   capable LSRs.

Top      ToC       Page 25 
   The rules that govern use of the Hop Count TLV in Label Request
   messages by LSR R when Loop Detection is enabled are the following:

   -  The Label Request message MUST include a Hop Count TLV.

   -  If R is sending the Label Request because it is a FEC ingress, it
      MUST include a Hop Count TLV with hop count value 1.

   -  If R is sending the Label Request as a result of having received a
      Label Request from an upstream LSR, and if the received Label
      Request contains a Hop Count TLV, R MUST increment the received
      hop count value by 1 and MUST pass the resulting value in a Hop
      Count TLV to its next hop along with the Label Request message;

   The rules that govern use of the Path Vector TLV in Label Request
   messages by LSR R when Loop Detection is enabled are the following:

   -  If R is sending the Label Request because it is a FEC ingress,
      then if R is non-merge capable, it MUST include a Path Vector TLV
      of length 1 containing its own LSR Id.

   -  If R is sending the Label Request as a result of having received a
      Label Request from an upstream LSR, then if the received Label
      Request contains a Path Vector TLV or if R is non-merge capable:

         R MUST add its own LSR Id to the Path Vector, and MUST pass the
         resulting Path Vector to its next hop along with the Label
         Request message.  If the Label Request contains no Path Vector
         TLV, R MUST include a Path Vector TLV of length 1 containing
         its own LSR Id.

   Note that if R receives a Label Request message for a particular FEC,
   and R has previously sent a Label Request message for that FEC to its
   next hop and has not yet received a reply, and if R intends to merge
   the newly received Label Request with the existing outstanding Label
   Request, then R does not propagate the Label Request to the next hop.

   If R receives a Label Request message from its next hop with a Hop
   Count TLV which exceeds the configured maximum value, or with a Path
   Vector TLV containing its own LSR Id or which exceeds the maximum
   allowable length, then R detects that the Label Request message has
   traveled in a loop.

   When R detects a loop, it MUST send a Loop Detected Notification
   message to the source of the Label Request message and drop the Label
   Request message.

Top      ToC       Page 26 
2.8.2. Label Mapping Message

   The use of the Path Vector TLV and Hop Count TLV in the Label Mapping
   message provide a mechanism to find and terminate looping LSPs.  When
   an LSR receives a Label Mapping message from a next hop, the message
   is propagated upstream as specified below until an ingress LSR is
   reached or a loop is found.

   The rules that govern the use of the Hop Count TLV in Label Mapping
   messages sent by an LSR R when Loop Detection is enabled are the
   following:

   -  R MUST include a Hop Count TLV.

   -  If R is the egress, the hop count value MUST be 1.

   -  If the Label Mapping message is being sent to propagate a Label
      Mapping message received from the next hop to an upstream peer,
      the hop count value MUST be determined as follows:

      o  If R is a member of the edge set of an LSR domain whose LSRs do
         not perform 'TTL-decrement' (e.g., an ATM LSR domain or a Frame
         Relay LSR domain) and the upstream peer is within that domain,
         R MUST reset the hop count to 1 before propagating the message.

      o  Otherwise, R MUST increment the hop count received from the
         next hop before propagating the message.

   -  If the Label Mapping message is not being sent to propagate a
      Label Mapping message, the hop count value MUST be the result of
      incrementing R's current knowledge of the hop count learned from
      previous Label Mapping messages.  Note that this hop count value
      will be unknown if R has not received a Label Mapping message from
      the next hop.

   Any Label Mapping message MAY contain a Path Vector TLV.  The rules
   that govern the mandatory use of the Path Vector TLV in Label Mapping
   messages sent by LSR R when Loop Detection is enabled are the
   following:

   -  If R is the egress, the Label Mapping message need not include a
      Path Vector TLV.

   -  If R is sending the Label Mapping message to propagate a Label
      Mapping message received from the next hop to an upstream peer,
      then:

Top      ToC       Page 27 
      o  If R is merge capable and if R has not previously sent a Label
         Mapping message to the upstream peer, then it MUST include a
         Path Vector TLV.

      o  If the received message contains an unknown hop count, then R
         MUST include a Path Vector TLV.

      o  If R has previously sent a Label Mapping message to the
         upstream peer, then it MUST include a Path Vector TLV if the
         received message reports an LSP hop count increase, a change in
         hop count from unknown to known, or a change from known to
         unknown.

      If the above rules require R include a Path Vector TLV in the
      Label Mapping message, R computes it as follows:

      o  If the received Label Mapping message included a Path Vector,
         the Path Vector sent upstream MUST be the result of adding R's
         LSR Id to the received Path Vector.

      o  If the received message had no Path Vector, the Path Vector
         sent upstream MUST be a path vector of length 1 containing R's
         LSR Id.

   -  If the Label Mapping message is not being sent to propagate a
      received message upstream, the Label Mapping message MUST include
      a Path Vector of length 1 containing R's LSR Id.

   If R receives a Label Mapping message from its next hop with a Hop
   Count TLV which exceeds the configured maximum value, or with a Path
   Vector TLV containing its own LSR Id or which exceeds the maximum
   allowable length, then R detects that the corresponding LSP contains
   a loop.

   When R detects a loop, it MUST stop using the label for forwarding,
   drop the Label Mapping message, and signal Loop Detected status to
   the source of the Label Mapping message.

2.8.3. Discussion

   If loop detection is desired in an MPLS domain, then it should be
   turned on in ALL LSRs within that MPLS domain, else loop detection
   will not operate properly and may result in undetected loops or in
   falsely detected loops.

   LSRs which are configured for loop detection are NOT expected to
   store the path vectors as part of the LSP state.

Top      ToC       Page 28 
   Note that in a network where only non-merge capable LSRs are present,
   Path Vectors are passed downstream from ingress to egress, and are
   not passed upstream.  Even when merge is supported, Path Vectors need
   not be passed upstream along an LSP which is known to reach the
   egress.  When an LSR experiences a change of next hop, it need pass
   Path Vectors upstream only when it cannot tell from the hop count
   that the change of next hop does not result in a loop.

   In the case of ordered label distribution, Label Mapping messages are
   propagated from egress toward ingress, naturally creating the Path
   Vector along the way.  In the case of independent label distribution,
   an LSR may originate a Label Mapping message for an FEC before
   receiving a Label Mapping message from its downstream peer for that
   FEC.  In this case, the subsequent Label Mapping message for the FEC
   received from the downstream peer is treated as an update to LSP
   attributes, and the Label Mapping message must be propagated
   upstream.  Thus, it is recommended that loop detection be configured
   in conjunction with ordered label distribution, to minimize the
   number of Label Mapping update messages.

2.9. Authenticity and Integrity of LDP Messages

   This section specifies a mechanism to protect against the
   introduction of spoofed TCP segments into LDP session connection
   streams.  The use of this mechanism MUST be supported as a
   configurable option.

   The mechanism is based on use of the TCP MD5 Signature Option
   specified in [RFC2385] for use by BGP.  See [RFC1321] for a
   specification of the MD5 hash function.

2.9.1. TCP MD5 Signature Option

   The following quotes from [RFC2385] outline the security properties
   achieved by using the TCP MD5 Signature Option and summarizes its
   operation:

      "IESG Note

         This document describes current existing practice for securing
         BGP against certain simple attacks.  It is understood to have
         security weaknesses against concerted attacks."

Top      ToC       Page 29 
      "Abstract

         This memo describes a TCP extension to enhance security for
         BGP.  It defines a new TCP option for carrying an MD5 [RFC1321]
         digest in a TCP segment.  This digest acts like a signature for
         that segment, incorporating information known only to the
         connection end points.  Since BGP uses TCP as its transport,
         using this option in the way described in this paper
         significantly reduces the danger from certain security attacks
         on BGP."

      "Introduction

         The primary motivation for this option is to allow BGP to
         protect itself against the introduction of spoofed TCP segments
         into the connection stream.  Of particular concern are TCP
         resets.

         To spoof a connection using the scheme described in this paper,
         an attacker would not only have to guess TCP sequence numbers,
         but would also have had to obtain the password included in the
         MD5 digest.  This password never appears in the connection
         stream, and the actual form of the password is up to the
         application.  It could even change during the lifetime of a
         particular connection so long as this change was synchronized
         on both ends (although retransmission can become problematical
         in some TCP implementations with changing passwords).

         Finally, there is no negotiation for the use of this option in
         a connection, rather it is purely a matter of site policy
         whether or not its connections use the option."

      "MD5 as a Hashing Algorithm

         Since this memo was first issued (under a different title), the
         MD5 algorithm has been found to be vulnerable to collision
         search attacks [Dobb], and is considered by some to be
         insufficiently strong for this type of application.

         This memo still specifies the MD5 algorithm, however, since the
         option has already been deployed operationally, and there was
         no "algorithm type" field defined to allow an upgrade using the
         same option number.  The original document did not specify a
         type field since this would require at least one more byte, and
         it was felt at the time that taking 19 bytes for the complete
         option (which would probably be padded to 20 bytes in TCP
         implementations) would be too much of a waste of the already
         limited option space.

Top      ToC       Page 30 
         This does not prevent the deployment of another similar option
         which uses another hashing algorithm (like SHA-1).  Also, if
         most implementations pad the 18 byte option as defined to 20
         bytes anyway, it would be just as well to define a new option
         which contains an algorithm type field.

         This would need to be addressed in another document, however."

   End of quotes from [RFC2385].

2.9.2. LDP Use of TCP MD5 Signature Option

   LDP uses the TCP MD5 Signature Option as follows:

      -  Use of the MD5 Signature Option for LDP TCP connections is a
         configurable LSR option.

      -  An LSR that uses the MD5 Signature Option is configured with a
         password (shared secret) for each potential LDP peer.

      -  The LSR applies the MD5 algorithm as specified in [RFC2385] to
         compute the MD5 digest for a TCP segment to be sent to a peer.
         This computation makes use of the peer password as well as the
         TCP segment.

      -  When the LSR receives a TCP segment with an MD5 digest, it
         validates the segment by calculating the MD5 digest (using its
         own record of the password) and compares the computed digest
         with the received digest.  If the comparison fails, the segment
         is dropped without any response to the sender.

      -  The LSR ignores LDP Hellos from any LSR for which a password
         has not been configured.  This ensures that the LSR establishes
         LDP TCP connections only with LSRs for which a password has
         been configured.

2.10. Label Distribution for Explicitly Routed LSPs

   Traffic Engineering [RFC2702] is expected to be an important MPLS
   application.  MPLS support for Traffic Engineering uses explicitly
   routed LSPs, which need not follow normally-routed (hop-by-hop) paths
   as determined by destination-based routing protocols.  CR-LDP [CRLDP]
   defines extensions to LDP to use LDP to set up explicitly routed
   LSPs.


Next RFC Part