tech-invite   World Map     

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

RFC 3036

 
 
 

LDP Specification

Part 2 of 4, p. 31 to 63
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 31 
3. Protocol Specification

   Previous sections that describe LDP operation have discussed
   scenarios that involve the exchange of messages among LDP peers.
   This section specifies the message encodings and procedures for
   processing the messages.

   LDP message exchanges are accomplished by sending LDP protocol data
   units (PDUs) over LDP session TCP connections.

   Each LDP PDU can carry one or more LDP messages.  Note that the
   messages in an LDP PDU need not be related to one another.  For
   example, a single PDU could carry a message advertising FEC-label
   bindings for several FECs, another message requesting label bindings
   for several other FECs, and a third notification message signaling
   some event.

3.1. LDP PDUs

   Each LDP PDU is an LDP header followed by one or more LDP messages.
   The LDP header 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Version                      |         PDU Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         LDP Identifier                        |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   PDU Length
      Two octet integer specifying the total length of this PDU in
      octets, excluding the Version and PDU Length fields.

      The maximum allowable PDU Length is negotiable when an LDP session
      is initialized.  Prior to completion of the negotiation the maximum
      allowable length is 4096 bytes.

Top      Up      ToC       Page 32 
   LDP Identifier
      Six octet field that uniquely identifies the label space of the
      sending LSR for which this PDU applies.  The first four octets
      identify the LSR and must be a globally unique value.  It should be
      a 32-bit router Id assigned to the LSR and also used to identify it
      in loop detection Path Vectors.  The last two octets identify a
      label space within the LSR.  For a platform-wide label space, these
      should both be zero.

   Note that there is no alignment requirement for the first octet of an
   LDP PDU.

3.2. LDP Procedures

   LDP defines messages, TLVs and procedures in the following areas:

      -  Peer discovery;
      -  Session management;
      -  Label distribution;
      -  Notification of errors and advisory information.

   The sections that follow describe the message and TLV encodings for
   these areas and the procedures that apply to them.

   The label distribution procedures are complex and are difficult to
   describe fully, coherently and unambiguously as a collection of
   separate message and TLV specifications.

   Appendix A, "LDP Label Distribution Procedures", describes the label
   distribution procedures in terms of label distribution events that
   may occur at an LSR and how the LSR must respond.  Appendix A is the
   specification of LDP label distribution procedures.  If a procedure
   described elsewhere in this document conflicts with Appendix A,
   Appendix A specifies LDP behavior.

3.3. Type-Length-Value Encoding

   LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of
   the information carried in LDP messages.

   An LDP TLV is encoded as a 2 octet field that uses 14 bits to specify
   a Type and 2 bits to specify behavior when an LSR doesn't recognize
   the Type, followed by a 2 octet Length Field, followed by a variable
   length Value field.

Top      Up      ToC       Page 33 
    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|F|        Type               |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                             Value                             |
   ~                                                               ~
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U bit
      Unknown TLV bit.  Upon receipt of an unknown TLV, if U is clear
      (=0), a notification must be returned to the message originator
      and the entire message must be ignored; if U is set (=1), the
      unknown TLV is silently ignored and the rest of the message is
      processed as if the unknown TLV did not exist.  The sections
      following that define TLVs specify a value for the U-bit.

   F bit
      Forward unknown TLV bit.  This bit applies only when the U bit is
      set and the LDP message containing the unknown TLV is to be
      forwarded.  If F is clear (=0), the unknown TLV is not forwarded
      with the containing message; if F is set (=1), the unknown TLV is
      forwarded with the containing message.  The sections following
      that define TLVs specify a value for the F-bit.

   Type
      Encodes how the Value field is to be interpreted.

   Length
      Specifies the length of the Value field in octets.

   Value
      Octet string of Length octets that encodes information to be
      interpreted as specified by the Type field.

   Note that there is no alignment requirement for the first octet of a
   TLV.

   Note that the Value field itself may contain TLV encodings.  That is,
   TLVs may be nested.

   The TLV encoding scheme is very general.  In principle, everything
   appearing in an LDP PDU could be encoded as a TLV.  This
   specification does not use the TLV scheme to its full generality.  It

Top      Up      ToC       Page 34 
   is not used where its generality is unnecessary and its use would
   waste space unnecessarily.  These are usually places where the type
   of a value to be encoded is known, for example by its position in a
   message or an enclosing TLV, and the length of the value is fixed or
   readily derivable from the value encoding itself.

   Some of the TLVs defined for LDP are similar to one another.  For
   example, there is a Generic Label TLV, an ATM Label TLV, and a Frame
   Relay TLV; see Sections "Generic Label TLV", "ATM Label TLV", and
   "Frame Relay TLV".

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

   The specification assigns type values for related TLVs, such as the
   label TLVs, from a contiguous block in the 16-bit TLV type number
   space.

   Section "TLV Summary" lists the TLVs defined in this version of the
   protocol and the section in this document that describes each.

3.4. TLV Encodings for Commonly Used Parameters

   There are several parameters used by more than one LDP message.  The
   TLV encodings for these commonly used parameters are specified in
   this section.

3.4.1. FEC TLV

   Labels are bound to Forwarding Equivalence Classes (FECs).  A FEC is
   a list of one or more FEC elements.  The FEC TLV encodes FEC items.

Top      Up      ToC       Page 35 
   Its encoding 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| FEC (0x0100)              |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        FEC Element 1                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        FEC Element n                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   FEC Element 1 to FEC Element n
      There are several types of FEC elements; see Section "FECs".  The
      FEC element encoding depends on the type of FEC element.

      A FEC Element value is encoded as a 1 octet field that specifies
      the element type, and a variable length field that is the type-
      dependent element value.  Note that while the representation of
      the FEC element value is type-dependent, the FEC element encoding
      itself is one where standard LDP TLV encoding is not used.

      The FEC Element value encoding is:

         FEC Element       Type      Value
         type name

           Wildcard        0x01      No value; i.e., 0 value octets;
                                         see below.
           Prefix          0x02      See below.
           Host Address    0x03      Full host address; see below.

      Note that this version of LDP supports the use of multiple FEC
      Elements per FEC for the Label Mapping message only.  The use of
      multiple FEC Elements in other messages is not permitted in this
      version, and is a subject for future study.

      Wildcard FEC Element
         To be used only in the Label Withdraw and Label Release
         Messages.  Indicates the withdraw/release is to be applied to
         all FECs associated with the label within the following label
         TLV.  Must be the only FEC Element in the FEC TLV.

Top      Up      ToC       Page 36 
      Prefix FEC Element value encoding:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Prefix (2)   |     Address Family            |     PreLen    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Prefix                                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Address Family
         Two octet quantity containing a value from ADDRESS FAMILY
         NUMBERS in [RFC1700] that encodes the address family for the
         address prefix in the Prefix field.

      PreLen
         One octet unsigned integer containing the length in bits of the
         address prefix that follows.  A length of zero indicates a
         prefix that matches all addresses (the default destination); in
         this case the Prefix itself is zero octets).

      Prefix
         An address prefix encoded according to the Address Family
         field, whose length, in bits, was specified in the PreLen
         field, padded to a byte boundary.

      Host Address FEC Element encoding:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Host Addr (3) |     Address Family            | Host Addr Len |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                     Host Addr                                 |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Address Family
         Two octet quantity containing a value from ADDRESS FAMILY
         NUMBERS in [RFC1700] that encodes the address family for the
         address prefix in the Prefix field.

      Host Addr Len
         Length of the Host address in octets.

      Host Addr
         An address encoded according to the Address Family field.

Top      Up      ToC       Page 37 
3.4.1.1. FEC Procedures

   If in decoding a FEC TLV an LSR encounters a FEC Element with an
   Address Family it does not support, it should stop decoding the FEC
   TLV, abort processing the message containing the TLV, and send an
   "Unsupported Address Family" Notification message to its LDP peer
   signaling an error.

   If it encounters a FEC Element type it cannot decode, it should stop
   decoding the FEC TLV, abort processing the message containing the
   TLV, and send an "Unknown FEC" Notification message to its LDP peer
   signaling an error.

3.4.2. Label TLVs

   Label TLVs encode labels.  Label TLVs are carried by the messages
   used to advertise, request, release and withdraw label mappings.

   There are several different kinds of Label TLVs which can appear in
   situations that require a Label TLV.

3.4.2.1. Generic Label TLV

   An LSR uses Generic Label TLVs to encode labels for use on links for
   which label values are independent of the underlying link technology.
   Examples of such links are PPP and Ethernet.

    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| Generic Label (0x0200)    |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Label                                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Label
      This is a 20-bit label value as specified in [RFC3032] represented
      as a 20-bit number in a 4 octet field.

Top      Up      ToC       Page 38 
3.4.2.2. ATM Label TLV

   An LSR uses ATM Label TLVs to encode labels for use on ATM links.

    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 Label (0x0201)        |         Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Res| V |          VPI          |         VCI                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Res
      This field is reserved.  It must be set to zero on transmission
      and must be ignored on receipt.

   V-bits
      Two-bit switching indicator.  If V-bits is 00, both the VPI and
      VCI are significant.  If V-bits is 01, only the VPI field is
      significant.  If V-bit is 10, only the VCI is significant.

   VPI
      Virtual Path Identifier.  If VPI is less than 12-bits it should be
      right justified in this field and preceding bits should be set to
      0.

   VCI
      Virtual Channel Identifier.  If the VCI is less than 16- bits, it
      should be right justified in the field and the preceding bits must
      be set to 0.  If Virtual Path switching is indicated in the V-bits
      field, then this field must be ignored by the receiver and set to
      0 by the sender.

3.4.2.3. Frame Relay Label TLV

   An LSR uses Frame Relay Label TLVs to encode labels for use on Frame
   Relay links.

    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| Frame Relay Label (0x0202)|       Length                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved    |Len|                     DLCI                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 39 
   Res
      This field is reserved.  It must be set to zero on transmission
      and must be ignored on receipt.

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

         0 = 10 bits DLCI
         2 = 23 bits DLCI

      Len values 1 and 3 are reserved.

   DLCI
      The Data Link Connection Identifier.  Refer to [RFC3034] for the
      label values and formats.

3.4.3. Address List TLV

   The Address List TLV appears in Address and Address Withdraw
   messages.

   Its encoding 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| Address List (0x0101)     |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Address Family            |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |                        Addresses                              |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Address Family
      Two octet quantity containing a value from ADDRESS FAMILY NUMBERS
      in [RFC1700] that encodes the addresses contained in the Addresses
      field.

   Addresses
      A list of addresses from the specified Address Family.  The
      encoding of the individual addresses depends on the Address Family.

Top      Up      ToC       Page 40 
      The following address encodings are defined by this version of the
      protocol:

         Address Family      Address Encoding

         IPv4                4 octet full IPv4 address
         IPv6                16 octet full IPv6 address

3.4.4. Hop Count TLV

   The Hop Count TLV appears as an optional field in messages that set
   up LSPs.  It calculates the number of LSR hops along an LSP as the
   LSP is being setup.

   Note that setup procedures for LSPs that traverse ATM and Frame Relay
   links require use of the Hop Count TLV (see [RFC3035] and [RFC3034]).

    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| Hop Count (0x0103)        |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     HC Value  |
   +-+-+-+-+-+-+-+-+

   HC Value
      1 octet unsigned integer hop count value.

3.4.4.1. Hop Count Procedures

   During setup of an LSP an LSR R may receive a Label Mapping or Label
   Request message for the LSP that contains the Hop Count TLV.  If it
   does, it should record the hop count value.

   If LSR R then propagates the Label Mapping message for the LSP to an
   upstream peer or the Label Request message to a downstream peer to
   continue the LSP setup, it must must determine a hop count to include
   in the propagated message as follows:

   -  If the message is a Label Request message, R must increment the
      received hop count;

   -  If the message is a Label Mapping message, R determines the hop
      count as follows:

Top      Up      ToC       Page 41 
      o  If R is a member of the edge set of an LSR domain whose LSRs do
         not perform 'TTL-decrement' and the upstream peer is within
         that domain, R must reset the hop count to 1 before propagating
         the message.

      o  Otherwise, R must increment the received hop count.

   The first LSR in the LSP (ingress for a Label Request message, egress
   for a Label Mapping message) should set the hop count value to 1.

   By convention a value of 0 indicates an unknown hop count.  The
   result of incrementing an unknown hop count is itself an unknown hop
   count (0).

   Use of the unknown hop count value greatly reduces the signaling
   overhead when independent control is used.  When a new LSP is
   established, each LSR starts with unknown hop count.  Addition of a
   new LSR whose hop count is also unknown does not cause a hop count
   update to be propagated upstream since the hop count remains unknown.
   When the egress is finally added to the LSP, then the LSRs propagate
   hop count updates upstream via Label Mapping messages.

   Without use of the unknown hop count, each time a new LSR is added to
   the LSP a hop count update would need to be propagated upstream if
   the new LSR is closer to the egress than any of the other LSRs.
   These updates are useless overhead since they don't reflect the hop
   count to the egress.

   From the perspective of the ingress node, the fact that the hop count
   is unknown implies nothing about whether a packet sent on the LSP
   will actually make it to the egress.  All it implies is that the hop
   count update from the egress has not yet reached the ingress.

   If an LSR receives a message containing a Hop Count TLV, it must
   check the hop count value to determine whether the hop count has
   exceeded its configured maximum allowable value.  If so, it must
   behave as if the containing message has traversed a loop by sending a
   Notification message signaling Loop Detected in reply to the sender
   of the message.

   If Loop Detection is configured, the LSR must follow the procedures
   specified in Section "Loop Detection".

3.4.5. Path Vector TLV

   The Path Vector TLV is used with the Hop Count TLV in Label Request
   and Label Mapping messages to implement the optional LDP loop
   detection mechanism.  See Section "Loop Detection".  Its use in the

Top      Up      ToC       Page 42 
   Label Request message records the path of LSRs the request has
   traversed.  Its use in the Label Mapping message records the path of
   LSRs a label advertisement has traversed to setup an LSP.

   Its encoding 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| Path Vector (0x0104)      |        Length                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            LSR Id 1                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            LSR Id n                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   One or more LSR Ids
      A list of router-ids indicating the path of LSRs the message has
      traversed.  Each LSR Id is the first four octets (router-id) of
      the LDP identifier for the corresponding LSR.  This ensures it is
      unique within the LSR network.

3.4.5.1. Path Vector Procedures

   The Path Vector TLV is carried in Label Mapping and Label Request
   messages when loop detection is configured.

3.4.5.1.1. Label Request Path Vector

   Section "Loop Detection" specifies situations when an LSR must
   include a Path Vector TLV in a Label Request message.

   An LSR that receives a Path Vector in a Label Request message must
   perform the procedures described in Section "Loop Detection".

   If the LSR detects a loop, it must reject the Label Request message.

   The LSR must:

      1. Transmit a Notification message to the sending LSR signaling
         "Loop Detected".

Top      Up      ToC       Page 43 
      2. Not propagate the Label Request message further.

   Note that a Label Request message with Path Vector TLV is forwarded
   until:

      1. A loop is found,

      2. The LSP egress is reached,

      3. The maximum Path Vector limit or maximum Hop Count limit is
         reached.  This is treated as if a loop had been detected.

3.4.5.1.2. Label Mapping Path Vector

   Section "Loop Detection" specifies the situations when an LSR must
   include a Path Vector TLV in a Label Mapping message.

   An LSR that receives a Path Vector in a Label Mapping message must
   perform the procedures described in Section "Loop Detection".

   If the LSR detects a loop, it must reject the Label Mapping message
   in order to prevent a forwarding loop.  The LSR must:

      1. Transmit a Label Release message carrying a Status TLV to the
         sending LSR to signal "Loop Detected".

      2. Not propagate the message further.

      3. Check whether the Label Mapping message is for an existing LSP.
         If so, the LSR must unsplice any upstream labels which are
         spliced to the downstream label for the FEC.

   Note that a Label Mapping message with a Path Vector TLV is forwarded
   until:

      1. A loop is found,

      2. An LSP ingress is reached, or

      3. The maximum Path Vector or maximum Hop Count limit is reached.
         This is treated as if a loop had been detected.

3.4.6. Status TLV

   Notification messages carry Status TLVs to specify events being
   signaled.

Top      Up      ToC       Page 44 
   The encoding for the Status 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F| Status (0x0300)           |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Status Code                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Message Type             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U bit
      Should be 0 when the Status TLV is sent in a Notification message.
      Should be 1 when the Status TLV is sent in some other message.

   F bit
      Should be the same as the setting of the F-bit in the Status Code
      field.

   Status Code
      32-bit unsigned integer encoding the event being signaled.  The
      structure of a Status Code 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |E|F|                 Status Data                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      E bit
         Fatal error bit.  If set (=1), this is a fatal error
         notification.  If clear (=0), this is an advisory notification.

      F bit
         Forward bit.  If set (=1), the notification should be forwarded
         to the LSR for the next-hop or previous-hop for the LSP, if
         any, associated with the event being signaled.  If clear (=0),
         the notification should not be forwarded.

      Status Data
         30-bit unsigned integer which specifies the status information.

      This specification defines Status Codes (32-bit unsigned integers
      with the above encoding).

Top      Up      ToC       Page 45 
      A Status Code of 0 signals success.

   Message ID
      If non-zero, 32-bit value that identifies the peer message to
      which the Status TLV refers.  If zero, no specific peer message is
      being identified.

   Message Type
      If non-zero, the type of the peer message to which the Status TLV
      refers.  If zero, the Status TLV does not refer to any specific
      message type.

   Note that use of the Status TLV is not limited to Notification
   messages.  A message other than a Notification message may carry a
   Status TLV as an Optional Parameter.  When a message other than a
   Notification carries a Status TLV the U-bit of the Status TLV should
   be set to 1 to indicate that the receiver should silently discard the
   TLV if unprepared to handle it.

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

   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"

Top      Up      ToC       Page 47 
      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.

   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.

Top      Up      ToC       Page 48 
   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.

      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

Top      Up      ToC       Page 49 
   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.

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:

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

Top      Up      ToC       Page 50 
         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 is missing one or more Mandatory Parameters.  This
         is a non-fatal error signalled 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:

      -  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.  Section "Unknown TLV in Known Message Type"
         elaborates on this behavior.

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

Top      Up      ToC       Page 51 
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.

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:

Top      Up      ToC       Page 52 
    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                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      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.

Top      Up      ToC       Page 53 
      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 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

      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.

Top      Up      ToC       Page 54 
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).

      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:

Top      Up      ToC       Page 55 
      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".

   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:

Top      Up      ToC       Page 56 
       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
         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

Top      Up      ToC       Page 57 
         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 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.

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

Top      Up      ToC       Page 58 
         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

      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:

Top      Up      ToC       Page 59 
         -  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 (see [ATM-VP]).

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

      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 which 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:

Top      Up      ToC       Page 60 
       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.

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

         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.

      See [ATM-VP] for specification of the fields for ATM Label Range
      Components to be used with VP merge LSRs.

Top      Up      ToC       Page 61 
      Frame Relay Session Parameters
         Used when an LDP session manages label exchange for a Frame
         Relay link to specify Frame Relay-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|   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

Top      Up      ToC       Page 62 
         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.

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

Top      Up      ToC       Page 63 
         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.

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



(page 63 continued on part 3)

Next RFC Part