tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5036

 
 
 

LDP Specification

Part 3 of 5, p. 44 to 78
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 44 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part