Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5036

LDP Specification

Pages: 135
Draft Standard
Errata
Obsoletes:  3036
Updated by:  6720679073587552
Part 3 of 5 – Pages 44 to 78
First   Prev   Next

Top   ToC   RFC5036 - Page 44   prevText

3.5. LDP Messages

All LDP messages have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Mandatory Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Optional Parameters | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC5036 - Page 45
   U-bit
      Unknown message bit.  Upon receipt of an unknown message, if U is
      clear (=0), a notification is returned to the message originator;
      if U is set (=1), the unknown message is silently ignored.  The
      sections following that define messages specify a value for the
      U-bit.

   Message Type
      Identifies the type of message.

   Message Length
      Specifies the cumulative length in octets of the Message ID,
      Mandatory Parameters, and Optional Parameters.

   Message ID
      32-bit value used to identify this message.  Used by the sending
      LSR to facilitate identifying Notification messages that may apply
      to this message.  An LSR sending a Notification message in
      response to this message SHOULD include this Message ID in the
      Status TLV carried by the Notification message; see Section
      "Notification Message".

   Mandatory Parameters
      Variable length set of required message parameters.  Some messages
      have no required parameters.

      For messages that have required parameters, the required
      parameters MUST appear in the order specified by the individual
      message specifications in the sections that follow.

   Optional Parameters
      Variable length set of optional message parameters.  Many messages
      have no optional parameters.

      For messages that have optional parameters, the optional
      parameters may appear in any order.

   Note that there is no alignment requirement for the first octet of an
   LDP message and that there is no padding at the end of a message;
   that is, parameters can end at odd-byte boundaries.
Top   ToC   RFC5036 - Page 46
   The following message types are defined in this version of LDP:

      Message Name            Section Title

      Notification            "Notification Message"
      Hello                   "Hello Message"
      Initialization          "Initialization Message"
      KeepAlive               "KeepAlive Message"
      Address                 "Address Message"
      Address Withdraw        "Address Withdraw Message"
      Label Mapping           "Label Mapping Message"
      Label Request           "Label Request Message"
      Label Abort Request     "Label Abort Request Message"
      Label Withdraw          "Label Withdraw Message"
      Label Release           "Label Release Message"

   The sections that follow specify the encodings and procedures for
   these messages.

   Some of the above messages are related to one another, for example
   the Label Mapping, Label Request, Label Withdraw, and Label Release
   messages.

   While it is possible to think about messages related in this way in
   terms of a message type that specifies a message class and a message
   subtype that specifies a particular kind of message within that
   class, this specification does not formalize the notion of a message
   subtype.

   The specification assigns type values for related messages, such as
   the Label messages, from of a contiguous block in the 16-bit message
   type number space.

3.5.1. Notification Message

An LSR sends a Notification message to inform an LDP peer of a significant event. A Notification message signals a fatal error or provides advisory information such as the outcome of processing an LDP message or the state of the LDP session.
Top   ToC   RFC5036 - Page 47
   The encoding for the Notification message is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Notification (0x0001)     |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Status (TLV)                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message ID
      32-bit value used to identify this message.

   Status TLV
      Indicates the event being signaled.  The encoding for the Status
      TLV is specified in Section "Status TLV".

   Optional Parameters
      This variable length field contains 0 or more parameters, each
      encoded as a TLV.  The following Optional Parameters are generic
      and may appear in any Notification message:

         Optional Parameter     Type     Length  Value

         Extended Status        0x0301    4      See below
         Returned PDU           0x0302    var    See below
         Returned Message       0x0303    var    See below

      Other Optional Parameters, specific to the particular event being
      signaled by the Notification messages, may appear.  These are
      described elsewhere.

   Extended Status
      The 4 octet value is an Extended Status Code that encodes
      additional information that supplements the status information
      contained in the Notification Status Code.

   Returned PDU
      An LSR uses this parameter to return part of an LDP PDU to the LSR
      that sent it.  The value of this TLV is the PDU header and as much
      PDU data following the header as appropriate for the condition
      being signaled by the Notification message.
Top   ToC   RFC5036 - Page 48
   Returned Message
      An LSR uses this parameter to return part of an LDP message to the
      LSR that sent it.  The value of this TLV is the message type and
      length fields and as much message data following the type and
      length fields as appropriate for the condition being signaled by
      the Notification message.

3.5.1.1. Notification Message Procedures
If an LSR encounters a condition requiring it to notify its peer with advisory or error information, it sends the peer a Notification message containing a Status TLV that encodes the information and optionally additional TLVs that provide more information about the condition. If the condition is one that is a fatal error, the Status Code carried in the Notification will indicate that. In this case, after sending the Notification message the LSR SHOULD terminate the LDP session by closing the session TCP connection and discard all state associated with the session, including all label-FEC bindings learned via the session. When an LSR receives a Notification message that carries a Status Code that indicates a fatal error, it SHOULD terminate the LDP session immediately by closing the session TCP connection and discard all state associated with the session, including all label-FEC bindings learned via the session. The above statement does not apply to the processing of the Shutdown message in the session initialization procedure. When an LSR receives a Shutdown message during session initialization, it SHOULD transmit a Shutdown message and then close the transport connection.
3.5.1.2. Events Signaled by Notification Messages
It is useful for descriptive purpose to classify events signaled by Notification messages into the following categories.
3.5.1.2.1. Malformed PDU or Message
Malformed LDP PDUs or messages that are part of the LDP Discovery mechanism are handled by silently discarding them. An LDP PDU received on a TCP connection for an LDP session is malformed if:
Top   ToC   RFC5036 - Page 49
      -  The LDP Identifier in the PDU header is unknown to the
         receiver, or it is known but is not the LDP Identifier
         associated by the receiver with the LDP peer for this LDP
         session.  This is a fatal error signaled by the Bad LDP
         Identifier Status Code.

      -  The LDP protocol version is not supported by the receiver, d or
         it is supported but is not the version negotiated for the
         session during session establishment.  This is a fatal error
         signaled by the Bad Protocol Version Status Code.

      -  The PDU Length field is too small (< 14) or too large (>
         maximum PDU length).  This is a fatal error signaled by the Bad
         PDU Length Status Code.  Section "Initialization Message"
         describes how the maximum PDU length for a session is
         determined.

   An LDP message is malformed if:

      -  The Message Type is unknown.

         If the Message Type is < 0x8000 (high order bit = 0), it is an
         error signaled by the Unknown Message Type Status Code.

         If the Message Type is >= 0x8000 (high order bit = 1), it is
         silently discarded.

      -  The Message Length is too large, that is, indicates that the
         message extends beyond the end of the containing LDP PDU.  This
         is a fatal error signaled by the Bad Message Length Status
         Code.

      -  The Message Length is too small, that is, smaller than the
         smallest possible value component.  This is a fatal error
         signaled by the Bad Message Length Status Code.

      -  The message is missing one or more Mandatory Parameters.  This
         is a non-fatal error signaled by the Missing Message Parameters
         Status Code.

3.5.1.2.2. Unknown or Malformed TLV
Malformed TLVs contained in LDP messages that are part of the LDP Discovery mechanism are handled by silently discarding the containing message. A TLV contained in an LDP message received on a TCP connection of an LDP is malformed if:
Top   ToC   RFC5036 - Page 50
      -  The TLV Length is too large, that is, indicates that the TLV
         extends beyond the end of the containing message.  This is a
         fatal error signaled by the Bad TLV Length Status Code.

      -  The TLV type is unknown.

         If the TLV type is < 0x8000 (high order bit = 0), it is an
         error signaled by the Unknown TLV Status Code.

         If the TLV type is >= 0x8000 (high order bit = 1), the TLV is
         silently dropped.

      -  The TLV Value is malformed.  This occurs when the receiver
         handles the TLV but cannot decode the TLV Value.  This is
         interpreted as indicative of a bug in either the sending or
         receiving LSR.  It is a fatal error signaled by the Malformed
         TLV Value Status Code.

3.5.1.2.3. Session KeepAlive Timer Expiration
This is a fatal error signaled by the KeepAlive Timer Expired Status Code.
3.5.1.2.4. Unilateral Session Shutdown
This is a fatal event signaled by the Shutdown Status Code. The Notification message may optionally include an Extended Status TLV to provide a reason for the Shutdown. The sending LSR terminates the session immediately after sending the Notification.
3.5.1.2.5. Initialization Message Events
The session initialization negotiation (see Section "Session Initialization") may fail if the session parameters received in the Initialization message are unacceptable. This is a fatal error. The specific Status Code depends on the parameter deemed unacceptable, and is defined in Sections "Initialization Message".
3.5.1.2.6. Events Resulting from Other Messages
Messages other than the Initialization message may result in events that must be signaled to LDP peers via Notification messages. These events and the Status Codes used in the Notification messages to signal them are described in the sections that describe these messages.
Top   ToC   RFC5036 - Page 51
3.5.1.2.7. Internal Errors
An LDP implementation may be capable of detecting problem conditions specific to its implementation. When such a condition prevents an implementation from interacting correctly with a peer, the implementation should, when capable of doing so, use the Internal Error Status Code to signal the peer. This is a fatal error.
3.5.1.2.8. Miscellaneous Events
These are events that fall into none of the categories above. There are no miscellaneous events defined in this version of the protocol.

3.5.2. Hello Message

LDP Hello messages are exchanged as part of the LDP Discovery Mechanism; see Section "LDP Discovery". The encoding for the Hello message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Hello (0x0100) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Common Hello Parameters TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message ID 32-bit value used to identify this message. Common Hello Parameters TLV Specifies parameters common to all Hello messages. The encoding for the Common Hello Parameters TLV is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Common Hello Parms(0x0400)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hold Time |T|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC5036 - Page 52
      Hold Time
         Hello hold time in seconds.  An LSR maintains a record of
         Hellos received from potential peers (see Section "Hello
         Message Procedures").  Hello Hold Time specifies the time the
         sending LSR will maintain its record of Hellos from the
         receiving LSR without receipt of another Hello.

         A pair of LSRs negotiates the hold times they use for Hellos
         from each other.  Each proposes a hold time.  The hold time
         used is the minimum of the hold times proposed in their Hellos.

         A value of 0 means use the default, which is 15 seconds for
         Link Hellos and 45 seconds for Targeted Hellos.  A value of
         0xffff means infinite.

      T, Targeted Hello
         A value of 1 specifies that this Hello is a Targeted Hello.  A
         value of 0 specifies that this Hello is a Link Hello.

      R, Request Send Targeted Hellos
         A value of 1 requests the receiver to send periodic Targeted
         Hellos to the source of this Hello.  A value of 0 makes no
         request.

         An LSR initiating Extended Discovery sets R to 1.  If R is 1,
         the receiving LSR checks whether it has been configured to send
         Targeted Hellos to the Hello source in response to Hellos with
         this request.  If not, it ignores the request.  If so, it
         initiates periodic transmission of Targeted Hellos to the Hello
         source.

      Reserved
         This field is reserved.  It MUST be set to zero on transmission
         and ignored on receipt.

   Optional Parameters
      This variable length field of the Hello message contains 0 or more
      parameters, each encoded as a TLV.  The optional parameters
      defined by this version of the protocol are

      Optional Parameter         Type     Length  Value

      IPv4 Transport Address     0x0401     4     See below
      Configuration              0x0402     4     See below
         Sequence Number
      IPv6 Transport Address     0x0403    16     See below
Top   ToC   RFC5036 - Page 53
      IPv4 Transport Address
         Specifies the IPv4 address to be used for the sending LSR when
         opening the LDP session TCP connection.  If this optional TLV
         is not present, the IPv4 source address for the UDP packet
         carrying the Hello SHOULD be used.

      Configuration Sequence Number
         Specifies a 4 octet unsigned configuration sequence number that
         identifies the configuration state of the sending LSR.  Used by
         the receiving LSR to detect configuration changes on the
         sending LSR.

      IPv6 Transport Address
         Specifies the IPv6 address to be used for the sending LSR when
         opening the LDP session TCP connection.  If this optional TLV
         is not present the IPv6 source address for the UDP packet
         carrying the Hello SHOULD be used.

3.5.2.1. Hello Message Procedures
An LSR receiving Hellos from another LSR maintains a Hello adjacency corresponding to the Hellos. The LSR maintains a hold timer with the Hello adjacency, which it restarts whenever it receives a Hello that matches the Hello adjacency. If the hold timer for a Hello adjacency expires the LSR discards the Hello adjacency: see Sections "Maintaining Hello Adjacencies" and "Maintaining LDP Sessions". We recommend that the interval between Hello transmissions be at most one third of the Hello hold time. An LSR processes a received LDP Hello as follows: 1. The LSR checks whether the Hello is acceptable. The criteria for determining whether a Hello is acceptable are implementation dependent (see below for example criteria). 2. If the Hello is not acceptable, the LSR ignores it. 3. If the Hello is acceptable, the LSR checks whether it has a Hello adjacency for the Hello source. If so, it restarts the hold timer for the Hello adjacency. If not, it creates a Hello adjacency for the Hello source and starts its hold timer. 4. If the Hello carries any optional TLVs, the LSR processes them (see below).
Top   ToC   RFC5036 - Page 54
      5. Finally, if the LSR has no LDP session for the label space
         specified by the LDP Identifier in the PDU header for the
         Hello, it follows the procedures of Section "LDP Session
         Establishment".

   The following are examples of acceptability criteria for Link and
   Targeted Hellos:

      A Link Hello is acceptable if the interface on which it was
      received has been configured for label switching.

      A Targeted Hello from source address A is acceptable if either:

      -  The LSR has been configured to accept Targeted Hellos, or

      -  The LSR has been configured to send Targeted Hellos to A.

      The following describes how an LSR processes Hello optional TLVs:

      Transport Address
         The LSR associates the specified transport address with the
         Hello adjacency.

      Configuration Sequence Number
         The Configuration Sequence Number optional parameter is used by
         the sending LSR to signal configuration changes to the
         receiving LSR.  When a receiving LSR playing the active role in
         LDP session establishment detects a change in the sending LSR
         configuration, it may clear the session setup backoff delay, if
         any, associated with the sending LSR (see Section "Session
         Initialization").

         A sending LSR using this optional parameter is responsible for
         maintaining the configuration sequence number it transmits in
         Hello messages.  Whenever there is a configuration change on
         the sending LSR, it increments the configuration sequence
         number.

3.5.3. Initialization Message

The LDP Initialization message is exchanged as part of the LDP session establishment procedure; see Section "LDP Session Establishment".
Top   ToC   RFC5036 - Page 55
   The encoding for the Initialization message is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Initialization (0x0200)   |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Common Session Parameters TLV             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message ID
      32-bit value used to identify this message.

   Common Session Parameters TLV
      Specifies values proposed by the sending LSR for parameters that
      must be negotiated for every LDP session.

      The encoding for the Common Session Parameters TLV is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0| Common Sess Parms (0x0500)|      Length                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Protocol Version              |      KeepAlive Time           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |A|D|  Reserved |     PVLim     |      Max PDU Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Receiver LDP Identifier                       |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |
      -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++

      Protocol Version
         Two octet unsigned integer containing the version number of the
         protocol.  This version of the specification specifies LDP
         protocol version 1.

      KeepAlive Time
         Two octet unsigned non zero integer that indicates the number
         of seconds that the sending LSR proposes for the value of the
         KeepAlive Time.  The receiving LSR MUST calculate the value of
         the KeepAlive Timer by using the smaller of its proposed
         KeepAlive Time and the KeepAlive Time received in the PDU.  The
Top   ToC   RFC5036 - Page 56
         value chosen for KeepAlive Time indicates the maximum number of
         seconds that may elapse between the receipt of successive PDUs
         from the LDP peer on the session TCP connection.  The KeepAlive
         Timer is reset each time a PDU arrives.

      A, Label Advertisement Discipline
         Indicates the type of Label advertisement.  A value of 0 means
         Downstream Unsolicited advertisement; a value of 1 means
         Downstream On Demand.

         If one LSR proposes Downstream Unsolicited and the other
         proposes Downstream on Demand, the rules for resolving this
         difference is:

         -  If the session is for a label-controlled ATM link or a
            label-controlled Frame Relay link, then Downstream on Demand
            MUST be used.

         -  Otherwise, Downstream Unsolicited MUST be used.

            If the label advertisement discipline determined in this way
            is unacceptable to an LSR, it MUST send a Session
            Rejected/Parameters Advertisement Mode Notification message
            in response to the Initialization message and not establish
            the session.

      D, Loop Detection
         Indicates whether Loop Detection based on Path Vectors is
         enabled.  A value of 0 means that Loop Detection is disabled; a
         value of 1 means that Loop Detection is enabled.

      PVLim, Path Vector Limit
         The configured maximum Path Vector length.  MUST be 0 if Loop
         Detection is disabled (D = 0).  If the Loop Detection
         procedures would require the LSR to send a Path Vector that
         exceeds this limit, the LSR will behave as if a loop had been
         detected for the FEC in question.

         When Loop Detection is enabled in a portion of a network, it is
         recommended that all LSRs in that portion of the network be
         configured with the same Path Vector limit.  Although knowledge
         of a peer's Path Vector limit will not change an LSR's
         behavior, it does enable the LSR to alert an operator to a
         possible misconfiguration.

      Reserved
         This field is reserved.  It MUST be set to zero on transmission
         and ignored on receipt.
Top   ToC   RFC5036 - Page 57
      Max PDU Length
         Two octet unsigned integer that proposes the maximum allowable
         length for LDP PDUs for the session.  A value of 255 or less
         specifies the default maximum length of 4096 octets.

         The receiving LSR MUST calculate the maximum PDU length for the
         session by using the smaller of its and its peer's proposals
         for Max PDU Length.  The default maximum PDU length applies
         before session initialization completes.

         If the maximum PDU length determined this way is unacceptable
         to an LSR, it MUST send a Session Rejected/Parameters Max PDU
         Length Notification message in response to the Initialization
         message and not establish the session.

      Receiver LDP Identifier
         Identifies the receiver's label space.  This LDP Identifier,
         together with the sender's LDP Identifier in the PDU header,
         enables the receiver to match the Initialization message with
         one of its Hello adjacencies; see Section "Hello Message
         Procedures".

         If there is no matching Hello adjacency, the LSR MUST send a
         Session Rejected/No Hello Notification message in response to
         the Initialization message and not establish the session.

   Optional Parameters
      This variable length field contains 0 or more parameters, each
      encoded as a TLV.  The optional parameters are:

      Optional Parameter       Type     Length  Value

      ATM Session Parameters   0x0501   var     See below
      Frame Relay Session      0x0502   var     See below
        Parameters
Top   ToC   RFC5036 - Page 58
      ATM Session Parameters
         Used when an LDP session manages label exchange for an ATM link
         to specify ATM-specific session parameters.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0|   ATM Sess Parms (0x0501) |      Length                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | M |   N   |D|                        Reserved                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 ATM Label Range Component 1                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                                                               ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 ATM Label Range Component N                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      M, ATM Merge Capabilities
         Specifies the merge capabilities of an ATM switch.  The
         following values are supported in this version of the
         specification:

               Value          Meaning

                 0            Merge not supported
                 1            VP Merge supported
                 2            VC Merge supported
                 3            VP & VC Merge supported

         If the merge capabilities of the LSRs differ, then:

         -  Non-merge and VC-merge LSRs may freely interoperate.

         -  The interoperability of VP-merge-capable switches with non-
            VP-merge-capable switches is a subject for future study.
            When the LSRs differ on the use of VP merge, the session is
            established, but VP merge is not used.

         Note that if VP merge is used, it is the responsibility of the
         ingress node to ensure that the chosen VCI is unique within the
         LSR domain.

      N, Number of label range components
         Specifies the number of ATM Label Range Components included in
         the TLV.
Top   ToC   RFC5036 - Page 59
      D, VC Directionality
         A value of 0 specifies bidirectional VC capability, meaning the
         LSR can (within a given VPI) support the use of a given VCI as
         a label for both link directions independently.  A value of 1
         specifies unidirectional VC capability, meaning (within a given
         VPI) a given VCI may appear in a label mapping for one
         direction on the link only.  When either or both of the peers
         specifies unidirectional VC capability, both LSRs use
         unidirectional VC label assignment for the link as follows.
         The LSRs compare their LDP Identifiers as unsigned integers.
         The LSR with the larger LDP Identifier may assign only odd-
         numbered VCIs in the VPI/VCI range as labels.  The system with
         the smaller LDP Identifier may assign only even-numbered VCIs
         in the VPI/VCI range as labels.

      Reserved
         This field is reserved.  It MUST be set to zero on transmission
         and ignored on receipt.

      One or more ATM Label Range Components
         A list of ATM Label Range Components that together specify the
         Label range supported by the transmitting LSR.

         A receiving LSR MUST calculate the intersection between the
         received range and its own supported label range.  The
         intersection is the range in which the LSR may allocate and
         accept labels.  LSRs MUST NOT establish a session with
         neighbors for which the intersection of ranges is NULL.  In
         this case, the LSR MUST send a Session Rejected/Parameters
         Label Range Notification message in response to the
         Initialization message and not establish the session.

         The encoding for an ATM Label Range Component is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Res  |    Minimum VPI        |      Minimum VCI              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Res  |    Maximum VPI        |      Maximum VCI              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Res
            This field is reserved.  It MUST be set to zero on
            transmission and MUST be ignored on receipt.
Top   ToC   RFC5036 - Page 60
         Minimum VPI (12 bits)
            This 12-bit field specifies the lower bound of a block of
            Virtual Path Identifiers that is supported on the
            originating switch.  If the VPI is less than 12 bits, it
            SHOULD be right justified in this field and preceding bits
            SHOULD be set to 0.

         Minimum VCI (16 bits)
            This 16-bit field specifies the lower bound of a block of
            Virtual Channel Identifiers that is supported on the
            originating switch.  If the VCI is less than 16 bits, it
            SHOULD be right justified in this field and preceding bits
            SHOULD be set to 0.

         Maximum VPI (12 bits)
            This 12-bit field specifies the upper bound of a block of
            Virtual Path Identifiers that is supported on the
            originating switch.  If the VPI is less than 12 bits, it
            SHOULD be right justified in this field and preceding bits
            SHOULD be set to 0.

         Maximum VCI (16 bits)
            This 16-bit field specifies the upper bound of a block of
            Virtual Connection Identifiers that is supported on the
            originating switch.  If the VCI is less than 16 bits, it
            SHOULD be right justified in this field and preceding bits
            SHOULD be set to 0.

      When peer LSRs are connected indirectly by means of an ATM VP, the
      sending LSR SHOULD set the Minimum and Maximum VPI fields to 0,
      and the receiving LSR MUST ignore the Minimum and Maximum VPI
      fields.

      Frame Relay Session Parameters
         Used when an LDP session manages label exchange for a Frame
         Relay link to specify Frame Relay-specific session parameters.
Top   ToC   RFC5036 - Page 61
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0|   FR Sess Parms (0x0502)  |      Length                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | M |   N   |D|                        Reserved                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Frame Relay Label Range Component 1               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                                                               ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Frame Relay Label Range Component N               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      M, Frame Relay Merge Capabilities
         Specifies the merge capabilities of a Frame Relay switch.  The
         following values are supported in this version of the
         specification:

               Value          Meaning

                 0            Merge not supported
                 1            Merge supported

         Non-merge and merge Frame Relay LSRs may freely interoperate.

      N, Number of label range components
         Specifies the number of Frame Relay Label Range Components
         included in the TLV.

      D, VC Directionality
         A value of 0 specifies bidirectional VC capability, meaning the
         LSR can support the use of a given DLCI as a label for both
         link directions independently.  A value of 1 specifies
         unidirectional VC capability, meaning a given DLCI may appear
         in a label mapping for one direction on the link only.  When
         either or both of the peers specifies unidirectional VC
         capability, both LSRs use unidirectional VC label assignment
         for the link as follows.  The LSRs compare their LDP
         Identifiers as unsigned integers.  The LSR with the larger LDP
         Identifier may assign only odd-numbered DLCIs in the range as
         labels.  The system with the smaller LDP Identifier may assign
         only even-numbered DLCIs in the range as labels.
Top   ToC   RFC5036 - Page 62
      Reserved
         This field is reserved.  It MUST be set to zero on transmission
         and ignored on receipt.

      One or more Frame Relay Label Range Components
         A list of Frame Relay Label Range Components that together
         specify the Label range supported by the transmitting LSR.

         A receiving LSR MUST calculate the intersection between the
         received range and its own supported label range.  The
         intersection is the range in which the LSR may allocate and
         accept labels.  LSRs MUST NOT establish a session with
         neighbors for which the intersection of ranges is NULL.  In
         this case, the LSR MUST send a Session Rejected/Parameters
         Label Range Notification message in response to the
         Initialization message and not establish the session.

         The encoding for a Frame Relay Label Range Component is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Reserved    |Len|                     Minimum DLCI            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Reserved        |                     Maximum DLCI            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Reserved
         This field is reserved.  It MUST be set to zero on transmission
         and ignored on receipt.

      Len
         This field specifies the number of bits of the DLCI.  The
         following values are supported:

               Len    DLCI Bits

               0       10
               2       23

         Len values 1 and 3 are reserved.

      Minimum DLCI
         This 23-bit field specifies the lower bound of a block of Data
         Link Connection Identifiers (DLCIs) that is supported on the
         originating switch.  The DLCI SHOULD be right justified in this
         field and unused bits SHOULD be set to 0.
Top   ToC   RFC5036 - Page 63
      Maximum DLCI
         This 23-bit field specifies the upper bound of a block of Data
         Link Connection Identifiers (DLCIs) that is supported on the
         originating switch.  The DLCI SHOULD be right justified in this
         field and unused bits SHOULD be set to 0.

   Note that there is no Generic Session Parameters TLV for sessions
   that advertise Generic Labels.

3.5.3.1. Initialization Message Procedures
See Section "LDP Session Establishment" and particularly Section "Session Initialization" for general procedures for handling the Initialization message.

3.5.4. KeepAlive Message

An LSR sends KeepAlive messages as part of a mechanism that monitors the integrity of the LDP session transport connection. The encoding for the KeepAlive message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| KeepAlive (0x0201) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message ID 32-bit value used to identify this message. Optional Parameters No optional parameters are defined for the KeepAlive message.
3.5.4.1. KeepAlive Message Procedures
The KeepAlive Timer mechanism described in Section "Maintaining LDP Sessions" resets a session KeepAlive Timer every time an LDP PDU is received on the session TCP connection. The KeepAlive message is provided to allow reset of the KeepAlive Timer in circumstances where an LSR has no other information to communicate to an LDP peer. An LSR MUST arrange that its peer receive an LDP message from it at least every KeepAlive Time period. Any LDP protocol message will do
Top   ToC   RFC5036 - Page 64
   but, in circumstances where no other LDP protocol messages have been
   sent within the period, a KeepAlive message MUST be sent.

3.5.5. Address Message

An LSR sends the Address message to an LDP peer to advertise its interface addresses. The encoding for the Address message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Address (0x0300) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address List TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message ID 32-bit value used to identify this message. Address List TLV The list of interface addresses being advertised by the sending LSR. The encoding for the Address List TLV is specified in Section "Address List TLV". Optional Parameters No optional parameters are defined for the Address message.
3.5.5.1. Address Message Procedures
An LSR that receives an Address message uses the addresses it learns to maintain a database for mapping between peer LDP Identifiers and next hop addresses; see Section "LDP Identifiers and Next Hop Addresses". When a new LDP session is initialized and before sending Label Mapping or Label Request messages, an LSR SHOULD advertise its interface addresses with one or more Address messages. Whenever an LSR "activates" a new interface address, it SHOULD advertise the new address with an Address message.
Top   ToC   RFC5036 - Page 65
   Whenever an LSR "de-activates" a previously advertised address, it
   SHOULD withdraw the address with an Address Withdraw message; see
   Section "Address Withdraw Message".

   If an LSR does not support the Address Family specified in the
   Address List TLV, it SHOULD send an Unsupported Address Family
   Notification to its LDP signaling an error and abort processing the
   message.

   An LSR may re-advertise an address (A) that it has previously
   advertised without explicitly withdrawing the address.  If the
   receiver already has address binding (LSR, A), it SHOULD take no
   further action.

   An LSR may withdraw an address (A) without having previously
   advertised it.  If the receiver has no address binding (LSR, A), it
   SHOULD take no further action.

3.5.6. Address Withdraw Message

An LSR sends the Address Withdraw message to an LDP peer to withdraw previously advertised interface addresses. The encoding for the Address Withdraw message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Address Withdraw (0x0301) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address List TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message ID 32-bit value used to identify this message. Address List TLV The list of interface addresses being withdrawn by the sending LSR. The encoding for the Address List TLV is specified in Section "Address List TLV".
Top   ToC   RFC5036 - Page 66
   Optional Parameters
      No optional parameters are defined for the Address Withdraw
      message.

3.5.6.1. Address Withdraw Message Procedures
See Section "Address Message Procedures".

3.5.7. Label Mapping Message

An LSR sends a Label Mapping message to an LDP peer to advertise FEC-label bindings to the peer. The encoding for the Label Mapping message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Mapping (0x0400) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message ID 32-bit value used to identify this message. FEC TLV Specifies the FEC component of the FEC-Label mapping being advertised. See Section "FEC TLVs" for encoding. Label TLV Specifies the Label component of the FEC-Label mapping. See Section "Label TLV" for encoding. Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are:
Top   ToC   RFC5036 - Page 67
         Optional Parameter    Length       Value

         Label Request         4            See below
             Message ID TLV
         Hop Count TLV         1            See below
         Path Vector TLV       variable     See below

      The encodings for the Hop Count and Path Vector TLVs can be found
      in Section "TLV Encodings for Commonly Used Parameters".

      Label Request Message ID
         If this Label Mapping message is a response to a Label Request
         message, it MUST include the Label Request Message ID optional
         parameter.  The value of this optional parameter is the Message
         ID of the corresponding Label Request message.

      Hop Count
         Specifies the running total of the number of LSR hops along the
         LSP being set up by the Label message.  Section "Hop Count
         Procedures" describes how to handle this TLV.

      Path Vector
         Specifies the LSRs along the LSP being set up by the Label
         message.  Section "Path Vector Procedures" describes how to
         handle this TLV.

3.5.7.1. Label Mapping Message Procedures
The Mapping message is used by an LSR to distribute a label mapping for a FEC to an LDP peer. If an LSR distributes a mapping for a FEC to multiple LDP peers, it is a local matter whether it maps a single label to the FEC, and distributes that mapping to all its peers, or whether it uses a different mapping for each of its peers. An LSR is responsible for the consistency of the label mappings it has distributed and that its peers have these mappings. An LSR receiving a Label Mapping message from a downstream LSR for a Prefix SHOULD NOT use the label for forwarding unless its routing table contains an entry that exactly matches the FEC Element. See Appendix A, "LDP Label Distribution Procedures", for more details.
3.5.7.1.1. Independent Control Mapping
If an LSR is configured for independent control, a mapping message is transmitted by the LSR upon any of the following conditions:
Top   ToC   RFC5036 - Page 68
      1. The LSR recognizes a new FEC via the forwarding table, and the
         label advertisement mode is Downstream Unsolicited
         advertisement.

      2. The LSR receives a Request message from an upstream peer for a
         FEC present in the LSR's forwarding table.

      3. The next hop for a FEC changes to another LDP peer, and Loop
         detection is configured.

      4. The attributes of a mapping change.

      5. The receipt of a mapping from the downstream next hop  AND

            a) no upstream mapping has been created  OR
            b) loop detection is configured  OR
            c) the attributes of the mapping have changed.

3.5.7.1.2. Ordered Control Mapping
If an LSR is doing Ordered Control, a Mapping message is transmitted by downstream LSRs upon any of the following conditions: 1. The LSR recognizes a new FEC via the forwarding table and is the egress for that FEC. 2. The LSR receives a Request message from an upstream peer for a FEC present in the LSR's forwarding table, and the LSR is the egress for that FEC OR has a downstream mapping for that FEC. 3. The next hop for a FEC changes to another LDP peer, and Loop Detection is configured. 4. The attributes of a mapping change. 5. The receipt of a mapping from the downstream next hop AND a) no upstream mapping has been created OR b) Loop Detection is configured OR c) the attributes of the mapping have changed.
3.5.7.1.3. Downstream on Demand Label Advertisement
In general, the upstream LSR is responsible for requesting label mappings when operating in Downstream on Demand mode. However, unless some rules are followed, it is possible for neighboring LSRs with different advertisement modes to get into a livelock situation where everything is functioning properly, but no labels are
Top   ToC   RFC5036 - Page 69
   distributed.  For example, consider two LSRs Ru and Rd where Ru is
   the upstream LSR and Rd is the downstream LSR for a particular FEC.
   In this example, Ru is using Downstream Unsolicited advertisement
   mode and Rd is using Downstream on Demand mode.  In this case, Rd may
   assume that Ru will request a label mapping when it wants one and Ru
   may assume that Rd will advertise a label if it wants Ru to use one.
   If Rd and Ru operate as suggested, no labels will be distributed from
   Rd to Ru.

   This livelock situation can be avoided if the following rule is
   observed: an LSR operating in Downstream on Demand mode SHOULD NOT be
   expected to send unsolicited mapping advertisements.  Therefore, if
   the downstream LSR is operating in Downstream on Demand mode, the
   upstream LSR is responsible for requesting label mappings as needed.

3.5.7.1.4. Downstream Unsolicited Label Advertisement
In general, the downstream LSR is responsible for advertising a label mapping when it wants an upstream LSR to use the label. An upstream LSR may issue a mapping request if it so desires. The combination of Downstream Unsolicited mode and Conservative Label retention can lead to a situation where an LSR releases the label for a FEC that it later needs. For example, if LSR Rd advertises to LSR Ru the label for a FEC for which it is not Ru's next hop, Ru will release the label. If Ru's next hop for the FEC later changes to Rd, it needs the previously released label. To deal with this situation, either Ru can explicitly request the label when it needs it, or Rd can periodically re-advertise it to Ru. In many situations Ru will know when it needs the label from Rd. For example, when its next hop for the FEC changes to Rd. However, there could be situations when Ru does not. For example, Rd may be attempting to establish an LSP with non-standard properties. Forcing Ru to explicitly request the label in this situation would require it to maintain state about a potential LSP with non-standard properties. In situations where Ru knows it needs the label, it is responsible for explicitly requesting the label by means of a Label Request message. In situations where Ru may not know that it needs the label, Rd is responsible for periodically re-advertising the label to Ru. For this version of LDP, the only situation where Ru knows it needs a label for a FEC from Rd is when Rd is its next hop for the FEC, Ru does not have a label from Rd, and the LSP for the FEC is one that can be established with TLVs defined in this document.
Top   ToC   RFC5036 - Page 70

3.5.8. Label Request Message

An LSR sends the Label Request message to an LDP peer to request a binding (mapping) for a FEC. The encoding for the Label Request message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Request (0x0401) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message ID 32-bit value used to identify this message. FEC TLV The FEC for which a label is being requested. See Section "FEC TLV" for encoding. Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are: Optional Parameter Length Value Hop Count TLV 1 See below Path Vector TLV variable See below The encodings for the Hop Count and Path Vector TLVs can be found in Section "TLV Encodings for Commonly Used Parameters". Hop Count Specifies the running total of the number of LSR hops along the LSP being set up by the Label Request message. Section "Hop Count Procedures" describes how to handle this TLV. Path Vector Specifies the LSRs along the LSR being set up by the Label Request message. Section "Path Vector Procedures" describes how to handle this TLV.
Top   ToC   RFC5036 - Page 71
3.5.8.1. Label Request Message Procedures
The Request message is used by an upstream LSR to explicitly request that the downstream LSR assign and advertise a label for a FEC. An LSR may transmit a Request message under any of the following conditions: 1. The LSR recognizes a new FEC via the forwarding table, and the next hop is an LDP peer, and the LSR doesn't already have a mapping from the next hop for the given FEC. 2. The next hop to the FEC changes, and the LSR doesn't already have a mapping from that next hop for the given FEC. Note that if the LSR already has a pending Label Request message for the new next hop, it SHOULD NOT issue an additional Label Request in response to the next hop change. 3. The LSR receives a Label Request for a FEC from an upstream LDP peer, the FEC next hop is an LDP peer, and the LSR doesn't already have a mapping from the next hop. Note that since a non-merge LSR must set up a separate LSP for each upstream peer requesting a label, it must send a separate Label Request for each such peer. A consequence of this is that a non-merge LSR may have multiple Label Request messages for a given FEC outstanding at the same time. The receiving LSR SHOULD respond to a Label Request message with a Label Mapping for the requested label or with a Notification message indicating why it cannot satisfy the request. When the FEC for which a label is requested is a Prefix FEC Element, the receiving LSR uses its routing table to determine its response. Unless its routing table includes an entry that exactly matches the requested Prefix, the LSR MUST respond with a No Route Notification message. The message ID of the Label Request message serves as an identifier for the Label Request transaction. When the receiving LSR responds with a Label Mapping message, the mapping message MUST include a Label Request/Returned Message ID TLV optional parameter that includes the message ID of the Label Request message. Note that since LSRs use Label Request message IDs as transaction identifiers, an LSR SHOULD NOT reuse the message ID of a Label Request message until the corresponding transaction completes.
Top   ToC   RFC5036 - Page 72
   This version of the protocol defines the following Status Codes for
   the Notification message that signals a request cannot be satisfied:

      No Route
         The FEC for which a label was requested includes a FEC Element
         for which the LSR does not have a route.

      No Label Resources
         The LSR cannot provide a label because of resource limitations.
         When resources become available, the LSR MUST notify the
         requesting LSR by sending a Notification message with the Label
         Resources Available Status Code.

         An LSR that receives a No Label Resources response to a Label
         Request message MUST NOT issue further Label Request messages
         until it receives a Notification message with the Label
         Resources Available Status Code.

      Loop Detected
         The LSR has detected a looping Label Request message.

   See Appendix A, "LDP Label Distribution Procedures", for more
   details.

3.5.9. Label Abort Request Message

The Label Abort Request message may be used to abort an outstanding Label Request message. The encoding for the Label Abort Request message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Abort Req (0x0404) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Request Message ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message ID 32-bit value used to identify this message.
Top   ToC   RFC5036 - Page 73
   FEC TLV
      Identifies the FEC for which the Label Request is being aborted.

   Label Request Message ID TLV
      Specifies the message ID of the Label Request message to be
      aborted.

   Optional Parameters
      No optional parameters are defined for the Label Abort Req
      message.

3.5.9.1. Label Abort Request Message Procedures
An LSR Ru may send a Label Abort Request message to abort an outstanding Label Request message for a FEC sent to an LSR Rd in the following circumstances: 1. Ru's next hop for the FEC has changed from LSR Rd to LSR X; or 2. Ru is a non-merge, non-ingress LSR and has received a Label Abort Request for the FEC from an upstream peer Y. 3. Ru is a merge, non-ingress LSR and has received a Label Abort Request for the FEC from an upstream peer Y and Y is the only (last) upstream LSR requesting a label for the FEC. There may be other situations where an LSR may choose to abort an outstanding Label Request message in order to reclaim resource associated with the pending LSP. However, specification of general strategies for using the abort mechanism is beyond the scope of LDP. When an LSR receives a Label Abort Request message, if it has not previously responded to the Label Request being aborted with a Label Mapping message or some other Notification message, it MUST acknowledge the abort by responding with a Label Request Aborted Notification message. The Notification MUST include a Label Request Message ID TLV that carries the message ID of the aborted Label Request message. If an LSR receives a Label Abort Request Message after it has responded to the Label Request in question with a Label Mapping message or a Notification message, it ignores the abort request. If an LSR receives a Label Mapping message in response to a Label Request message after it has sent a Label Abort Request message to abort the Label Request, the label in the Label Mapping message is valid. The LSR may choose to use the label or to release it with a Label Release message.
Top   ToC   RFC5036 - Page 74
   An LSR aborting a Label Request message may not reuse the Message ID
   for the Label Request message until it receives one of the following
   from its peer:

      -  A Label Request Aborted Notification message acknowledging the
         abort;

      -  A Label Mapping message in response to the Label Request
         message being aborted;

      -  A Notification message in response to the Label Request message
         being aborted (e.g., Loop Detected, No Label Resources, etc.).

   To protect itself against tardy peers or faulty peer implementations
   an LSR may choose to time out receipt of the above.  The timeout
   period should be relatively long (several minutes).  If the timeout
   period elapses with no reply from the peer, the LSR may reuse the
   Message ID of the Label Request message; if it does so, it should
   also discard any record of the outstanding Label Request and Label
   Abort messages.

   Note that the response to a Label Abort Request message is never
   "ordered".  That is, the response does not depend on the downstream
   state of the LSP setup being aborted.  An LSR receiving a Label Abort
   Request message MUST process it immediately, regardless of the
   downstream state of the LSP, responding with a Label Request Aborted
   Notification or ignoring it, as appropriate.

3.5.10. Label Withdraw Message

An LSR sends a Label Withdraw Message to an LDP peer to signal the peer that the peer may not continue to use specific FEC-label mappings the LSR had previously advertised. This breaks the mapping between the FECs and the labels.
Top   ToC   RFC5036 - Page 75
   The encoding for the Label Withdraw Message is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Label Withdraw (0x0402)   |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Label TLV (optional)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message ID
      32-bit value used to identify this message.

   FEC TLV
      Identifies the FEC for which the FEC-label mapping is being
      withdrawn.

   Optional Parameters
      This variable length field contains 0 or more parameters, each
      encoded as a TLV.  The optional parameters are:

         Optional Parameter    Length       Value

         Label TLV             variable     See below

      The encoding for Label TLVs are found in Section "Label TLVs".

      Label
         If present, specifies the label being withdrawn (see procedures
         below).

3.5.10.1. Label Withdraw Message Procedures
An LSR transmits a Label Withdraw message under the following conditions: 1. The LSR no longer recognizes a previously known FEC for which it has advertised a label. 2. The LSR has decided unilaterally (e.g., via configuration) to no longer label switch a FEC (or FECs) with the label mapping being withdrawn.
Top   ToC   RFC5036 - Page 76
   The FEC TLV specifies the FEC for which labels are to be withdrawn.
   If no Label TLV follows the FEC, all labels associated with the FEC
   are to be withdrawn; otherwise, only the label specified in the
   optional Label TLV is to be withdrawn.

   The FEC TLV may contain the Wildcard FEC Element; if so, it may
   contain no other FEC Elements.  In this case, if the Label Withdraw
   message contains an optional Label TLV, then the label is to be
   withdrawn from all FECs to which it is bound.  If there is not an
   optional Label TLV in the Label Withdraw message, then the sending
   LSR is withdrawing all label mappings previously advertised to the
   receiving LSR.

   An LSR that receives a Label Withdraw message MUST respond with a
   Label Release message.

   See Appendix A, "LDP Label Distribution Procedures", for more
   details.

3.5.11. Label Release Message

An LSR sends a Label Release message to an LDP peer to signal the peer that the LSR no longer needs specific FEC-label mappings previously requested of and/or advertised by the peer. The encoding for the Label Release Message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Release (0x0403) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message ID 32-bit value used to identify this message. FEC TLV Identifies the FEC for which the FEC-label mapping is being released.
Top   ToC   RFC5036 - Page 77
   Optional Parameters
      This variable length field contains 0 or more parameters, each
      encoded as a TLV.  The optional parameters are:

         Optional Parameter    Length       Value

         Label TLV             variable     See below

      The encodings for Label TLVs are found in Section "Label TLVs".

      Label
         If present, the label being released (see procedures below).

3.5.11.1. Label Release Message Procedures
An LSR transmits a Label Release message to a peer when it no longer needs a label previously received from or requested of that peer. An LSR MUST transmit a Label Release message under any of the following conditions: 1. The LSR that sent the label mapping is no longer the next hop for the mapped FEC, and the LSR is configured for conservative operation. 2. The LSR receives a label mapping from an LSR that is not the next hop for the FEC, and the LSR is configured for conservative operation. 3. The LSR receives a Label Withdraw message. Note that if an LSR is configured for "liberal mode", a release message will never be transmitted in the case of conditions (1) and (2) as specified above. In this case, the upstream LSR keeps each unused label, so that it can immediately be used later if the downstream peer becomes the next hop for the FEC. The FEC TLV specifies the FEC for which labels are to be released. If no Label TLV follows the FEC, all labels associated with the FEC are to be released; otherwise, only the label specified in the optional Label TLV is to be released. The FEC TLV may contain the Wildcard FEC Element; if so, it may contain no other FEC Elements. In this case, if the Label Release message contains an optional Label TLV, then the label is to be released for all FECs to which it is bound. If there is not an optional Label TLV in the Label Release message, then the sending LSR
Top   ToC   RFC5036 - Page 78
   is releasing all label mappings previously learned from the receiving
   LSR.

   See Appendix A, "LDP Label Distribution Procedures", for more
   details.



(page 78 continued on part 4)

Next Section