Home   A   B   C   D   E   F   G   H   I   J   K   L   M   N   O   P   Q   R   S   T   U   V   W   X   Y   Z  

LDP Specification :: RFC5036








Network Working Group                                  L. Andersson, Ed.
Request for Comments: 5036                                      Acreo AB
Obsoletes: 3036                                            I. Minei, Ed.
Category: Standards Track                               Juniper Networks
                                                          B. Thomas, Ed.
                                                     Cisco Systems, Inc.
                                                            October 2007


                           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.

Abstract

   The architecture for Multiprotocol 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.

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 .....................................9
           2.2.3. LDP Sessions .......................................10
           2.2.4. LDP Transport ......................................10



Andersson, et al.           Standards Track                     [Page 1]

RFC 5036                   LDP Specification                October 2007


      2.3. LDP Sessions between Non-Directly Connected LSRs ..........10
      2.4. LDP Discovery .............................................11
           2.4.1. Basic Discovery Mechanism ..........................11
           2.4.2. Extended Discovery Mechanism .......................11
      2.5. Establishing and Maintaining LDP Sessions .................12
           2.5.1. LDP Session Establishment ..........................12
           2.5.2. Transport Connection Establishment .................12
           2.5.3. Session Initialization .............................14
           2.5.4. Initialization State Machine .......................16
           2.5.5. Maintaining Hello Adjacencies ......................19
           2.5.6. Maintaining LDP Sessions ...........................19
      2.6. Label Distribution and Management .........................20
           2.6.1. Label Distribution Control Mode ....................20
                  2.6.1.1. Independent Label Distribution Control ....20
                  2.6.1.2. Ordered Label Distribution Control ........20
           2.6.2. Label Retention Mode ...............................21
                  2.6.2.1. Conservative Label Retention Mode .........21
                  2.6.2.2. Liberal Label Retention Mode ..............21
           2.6.3. Label Advertisement Mode ...........................22
      2.7. LDP Identifiers and Next Hop Addresses ....................22
      2.8. Loop Detection ............................................23
           2.8.1. Label Request Message ..............................23
           2.8.2. Label Mapping Message ..............................25
           2.8.3. Discussion .........................................26
      2.9. Authenticity and Integrity of LDP Messages ................27
           2.9.1. TCP MD5 Signature Option ...........................27
           2.9.2. LDP Use of TCP MD5 Signature Option ................29
      2.10. Label Distribution for Explicitly Routed LSPs ............29
   3. Protocol Specification .........................................30
      3.1. LDP PDUs ..................................................30
      3.2. LDP Procedures ............................................31
      3.3. Type-Length-Value Encoding ................................31
      3.4. TLV Encodings for Commonly Used Parameters ................33
           3.4.1. FEC TLV ............................................33
                  3.4.1.1. FEC Procedures ............................35
           3.4.2. Label TLVs .........................................35
                  3.4.2.1. Generic Label TLV .........................36
                  3.4.2.2. ATM Label TLV .............................36
                  3.4.2.3. Frame Relay Label TLV .....................37
           3.4.3. Address List TLV ...................................38
           3.4.4. Hop Count TLV ......................................39
                  3.4.4.1. Hop Count Procedures ......................39
           3.4.5. Path Vector TLV ....................................41
                  3.4.5.1. Path Vector Procedures ....................41
                           3.4.5.1.1. Label Request Path Vector ......41
                           3.4.5.1.2. Label Mapping Path Vector ......42
           3.4.6. Status TLV .........................................43




Andersson, et al.           Standards Track                     [Page 2]

RFC 5036                   LDP Specification                October 2007


      3.5. LDP Messages ..............................................44
           3.5.1. Notification Message ...............................46
                  3.5.1.1. Notification Message Procedures ...........48
                  3.5.1.2. Events Signaled by Notification Messages ..48
                           3.5.1.2.1. Malformed PDU or Message .......48
                           3.5.1.2.2. Unknown or Malformed TLV .......49
                           3.5.1.2.3. Session KeepAlive Timer
                                      Expiration .....................50
                           3.5.1.2.4. Unilateral Session Shutdown ....50
                           3.5.1.2.5. Initialization Message Events ..50
                           3.5.1.2.6. Events Resulting from
                                      Other Messages .................50
                           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 ..................53
           3.5.3. Initialization Message .............................54
                  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 ..............................70
                  3.5.8.1. Label Request Message Procedures ..........71
           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
                  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



Andersson, et al.           Standards Track                     [Page 3]

RFC 5036                   LDP Specification                October 2007


      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 .........................................88
   6. Areas for Future Study .........................................89
   7. Changes from RFC 3036 ..........................................90
   8. Acknowledgments ................................................93
   9. References .....................................................93
      9.1. Normative References ......................................93
      9.2. Informative References ....................................94
   Appendix A. LDP Label Distribution Procedures  ....................95
      A.1. Handling Label Distribution Events  .......................97
           A.1.1. Receive Label Request  .............................98
           A.1.2.  Receive Label Mapping  ...........................101
           A.1.3.  Receive Label Abort Request  .....................107
           A.1.4.  Receive Label Release  ...........................109
           A.1.5.  Receive Label Withdraw  ..........................111
           A.1.6.  Recognize New FEC  ...............................113
           A.1.7.  Detect Change in FEC Next Hop  ...................115
           A.1.8.  Receive Notification / Label Request Aborted  ....118
           A.1.9.  Receive Notification / No Label Resources  .......119
           A.1.10.  Receive Notification / No Route  ................119
           A.1.11.  Receive Notification / Loop Detected  ...........120
           A.1.12.  Receive Notification / Label Resources Available 121
           A.1.13.  Detect Local Label Resources Have Become
                    Available  ......................................122
           A.1.14.  LSR Decides to No Longer Label Switch a FEC  ....123
           A.1.15.  Timeout of Deferred Label Request  ..............123
      A.2. Common Label Distribution Procedures  ....................124
           A.2.1.  Send_Label  ......................................124
           A.2.2.  Send_Label_Request  ..............................125
           A.2.3.  Send_Label_Withdraw  .............................127
           A.2.4.  Send_Notification  ...............................127
           A.2.5.  Send_Message  ....................................128
           A.2.6.  Check_Received_Attributes  .......................128
           A.2.7.  Prepare_Label_Request_Attributes  ................129
           A.2.8.  Prepare_Label_Mapping_Attributes  ................131





Andersson, et al.           Standards Track                     [Page 4]

RFC 5036                   LDP Specification                October 2007


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) is a protocol defined for
   distributing labels.  It was originally published as RFC 3036 in
   January 2001.  It was produced by the MPLS Working Group of the IETF
   and was jointly authored by Loa Andersson, Paul Doolan, Nancy
   Feldman, Andre Fredette, and Bob Thomas.

   LDP is a 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 (but does not require) familiarity with the
   MPLS architecture [RFC3031].  Note that [RFC3031] includes a glossary
   of MPLS terminology, such as ingress, label switched path, etc.








Andersson, et al.           Standards Track                     [Page 5]

RFC 5036                   LDP Specification                October 2007


1.1.  LDP Peers

   Two LSRs that 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 bidirectional.

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.








Andersson, et al.           Standards Track                     [Page 6]

RFC 5036                   LDP Specification                October 2007


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 on 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].











Andersson, et al.           Standards Track                     [Page 7]

RFC 5036                   LDP Specification                October 2007


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 that 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 that 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.

   This specification defines a single type of FEC element, the "Address
   Prefix FEC element".  This element is an address prefix of any length
   from 0 to a full address, inclusive.

   Additional FEC elements may be defined, as needed, by other
   specifications.

   In the remainder of this section, we give the rules to be used for
   mapping packets to LSPs that have been set up using an Address Prefix
   FEC element.

   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 that matches the packet's
   destination address.  With respect to a particular packet and a
   particular LSP, we refer to any Address Prefix FEC element that
   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 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.




Andersson, et al.           Standards Track                     [Page 8]

RFC 5036                   LDP Specification                October 2007


      -  If it is known that a packet must traverse a particular egress
         router, and there is an LSP that has an Address Prefix FEC
         element that is a /32 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.)

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:

      -  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 (Virtual Channel Identifiers) as
         labels, or a Frame Relay interface that uses DLCIs (Data Link
         Connection Identifiers) 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:






Andersson, et al.           Standards Track                     [Page 9]

RFC 5036                   LDP Specification                October 2007


          : 

 

RFC, FYI, BCP