Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5036

LDP Specification

Pages: 135
Draft Standard
Errata
Obsoletes:  3036
Updated by:  6720679073587552
Part 1 of 5 – Pages 1 to 19
None   None   Next

Top   ToC   RFC5036 - Page 1
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
Top   ToC   RFC5036 - Page 2
      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
Top   ToC   RFC5036 - Page 3
      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
Top   ToC   RFC5036 - Page 4
      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
Top   ToC   RFC5036 - Page 5

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.
Top   ToC   RFC5036 - Page 6

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.
Top   ToC   RFC5036 - 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 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].
Top   ToC   RFC5036 - 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 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.
Top   ToC   RFC5036 - Page 9
      -  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:
Top   ToC   RFC5036 - Page 10
         <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.

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.
Top   ToC   RFC5036 - Page 11
   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.

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.
Top   ToC   RFC5036 - Page 12
   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.

   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.
Top   ToC   RFC5036 - Page 13
         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
            Hellos 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.

      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 that appears
            earliest in the message is the most significant byte of the
            integer and the byte that 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.
Top   ToC   RFC5036 - Page 14
   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 (Virtual Path Identifier / Virtual Channel Identifier) ranges for label controlled ATM, DLCI (Data Link Connection Identifier) ranges for label controlled Frame Relay, etc. 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.
Top   ToC   RFC5036 - Page 15
      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.

         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.
Top   ToC   RFC5036 - Page 16
            Until the LDP session is established, no other messages
            except those listed in the procedures above may be
            exchanged, and the rules for processing the U-bit in LDP
            messages are overridden.  If a message other than those
            listed in the procedures above is received, a Shutdown msg
            MUST be transmitted and the transport connection MUST be
            closed.

   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.

   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. Note that a Shutdown message is implemented as a Notification message with a Status TLV indicating a fatal error.
Top   ToC   RFC5036 - Page 17
               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   RFC5036 - Page 18
              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   RFC5036 - Page 19

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


(next page on part 2)

Next Section