tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5036

 
 
 

LDP Specification

Part 2 of 5, p. 20 to 44
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 20 
2.6.  Label Distribution and Management

   The MPLS architecture [RFC3031] allows an LSR to distribute a FEC
   label binding in response to an explicit request from another LSR.
   This is known as Downstream On Demand label distribution.  It also
   allows an LSR to distribute label bindings to LSRs that have not
   explicitly requested them.  [RFC3031] calls this method of label
   distribution Unsolicited Downstream; this document uses the term
   Downstream Unsolicited.

   Both of these label distribution techniques may be used in the same
   network at the same time.  However, for any given LDP session, each
   LSR must be aware of the label distribution method used by its peer
   in order to avoid situations where one peer using Downstream
   Unsolicited label distribution assumes its peer is also.  See Section
   "Downstream on Demand Label Advertisement".

2.6.1.  Label Distribution Control Mode

   The behavior of the initial setup of LSPs is determined by whether
   the LSR is operating with independent or Ordered LSP Control.  An LSR
   may support both types of control as a configurable option.

2.6.1.1.  Independent Label Distribution Control

   When using independent LSP control, each LSR may advertise label
   mappings to its neighbors at any time it desires.  For example, when
   operating in independent Downstream on Demand mode, an LSR may answer
   requests for label mappings immediately, without waiting for a label
   mapping from the next hop.  When operating in independent Downstream
   Unsolicited mode, an LSR may advertise a label mapping for a FEC to
   its neighbors whenever it is prepared to label-switch that FEC.

   A consequence of using independent mode is that an upstream label can
   be advertised before a downstream label is received.

2.6.1.2.  Ordered Label Distribution Control

   When using LSP Ordered Control, an LSR may initiate the transmission
   of a label mapping only for a FEC for which it has a label mapping
   for the FEC next hop, or for which the LSR is the egress.  For each
   FEC for which the LSR is not the egress and no mapping exists, the
   LSR MUST wait until a label from a downstream LSR is received before
   mapping the FEC and passing corresponding labels to upstream LSRs.
   An LSR may be an egress for some FECs and a non-egress for others.

   An LSR may act as an egress LSR, with respect to a particular FEC,
   under any of the following conditions:

Top      Up      ToC       Page 21 
      1. The FEC refers to the LSR itself (including one of its directly
         attached interfaces).

      2. The next hop router for the FEC is outside of the Label
         Switching Network.

      3. FEC elements are reachable by crossing a routing domain
         boundary, such as another area for OSPF summary networks, or
         another autonomous system for OSPF AS externals and BGP routes
         [RFC2328] [RFC4271].

   Note that whether an LSR is an egress for a given FEC may change over
   time, depending on the state of the network and LSR configuration
   settings.

2.6.2.  Label Retention Mode

   The MPLS architecture [RFC3031] introduces the notion of label
   retention mode which specifies whether an LSR maintains a label
   binding for a FEC learned from a neighbor that is not its next hop
   for the FEC.

2.6.2.1.  Conservative Label Retention Mode

   In Downstream Unsolicited advertisement mode, label mapping
   advertisements for all routes may be received from all peer LSRs.
   When using Conservative Label retention, advertised label mappings
   are retained only if they will be used to forward packets (i.e., if
   they are received from a valid next hop according to routing).  If
   operating in Downstream on Demand mode, an LSR will request label
   mappings only from the next hop LSR according to routing.  Since
   Downstream on Demand mode is primarily used when label conservation
   is desired (e.g., an ATM switch with limited cross connect space), it
   is typically used with the Conservative Label retention mode.

   The main advantage of the conservative mode is that only the labels
   that are required for the forwarding of data are allocated and
   maintained.  This is particularly important in LSRs where the label
   space is inherently limited, such as in an ATM switch.  A
   disadvantage of the conservative mode is that if routing changes the
   next hop for a given destination, a new label must be obtained from
   the new next hop before labeled packets can be forwarded.

2.6.2.2.  Liberal Label Retention Mode

   In Downstream Unsolicited advertisement mode, label mapping
   advertisements for all routes may be received from all LDP peers.
   When using Liberal Label retention, every label mappings received

Top      Up      ToC       Page 22 
   from a peer LSR is retained regardless of whether the LSR is the next
   hop for the advertised mapping.  When operating in Downstream on
   Demand mode with Liberal Label retention, an LSR might choose to
   request label mappings for all known prefixes from all peer LSRs.
   Note, however, that Downstream on Demand mode is typically used by
   devices such as ATM switch-based LSRs for which the conservative
   approach is recommended.

   The main advantage of the Liberal Label retention mode is that
   reaction to routing changes can be quick because labels already
   exist.  The main disadvantage of the liberal mode is that unneeded
   label mappings are distributed and maintained.

2.6.3.  Label Advertisement Mode

   Each interface on an LSR is configured to operate in either
   Downstream Unsolicited or Downstream on Demand advertisement mode.
   LSRs exchange advertisement modes during initialization.  The major
   difference between Downstream Unsolicited and Downstream on Demand
   modes is in which LSR takes responsibility for initiating mapping
   requests and mapping advertisements.

2.7.  LDP Identifiers and Next Hop Addresses

   An LSR maintains learned labels in a Label Information Base (LIB).
   When operating in Downstream Unsolicited mode, the LIB entry for an
   address prefix associates a collection of (LDP Identifier, label)
   pairs with the prefix, one such pair for each peer advertising a
   label for the prefix.

   When the next hop for a prefix changes, the LSR must retrieve the
   label advertised by the new next hop from the LIB for use in
   forwarding.  To retrieve the label, the LSR must be able to map the
   next hop address for the prefix to an LDP Identifier.

   Similarly, when the LSR learns a label for a prefix from an LDP peer,
   it must be able to determine whether that peer is currently a next
   hop for the prefix to determine whether it needs to start using the
   newly learned label when forwarding packets that match the prefix.
   To make that decision, the LSR must be able to map an LDP Identifier
   to the peer's addresses to check whether any are a next hop for the
   prefix.

   To enable LSRs to map between a peer LDP Identifier and the peer's
   addresses, LSRs advertise their addresses using LDP Address and
   Withdraw Address messages.

Top      Up      ToC       Page 23 
   An LSR sends an Address message to advertise its addresses to a peer.
   An LSR sends a Withdraw Address message to withdraw previously
   advertised addresses from a peer.

2.8.  Loop Detection

   Loop Detection is a configurable option that provides a mechanism for
   finding looping LSPs and for preventing Label Request messages from
   looping in the presence of non-merge capable LSRs.

   The mechanism makes use of Path Vector and Hop Count TLVs carried by
   Label Request and Label Mapping messages.  It builds on the following
   basic properties of these TLVs:

      -  A Path Vector TLV contains a list of the LSRs that its
         containing message has traversed.  An LSR is identified in a
         Path Vector list by its unique LSR Identifier (Id), which is
         the first four octets of its LDP Identifier.  When an LSR
         propagates a message containing a Path Vector TLV, it adds its
         LSR Id to the Path Vector list.  An LSR that receives a message
         with a Path Vector that contains its LSR Id detects that the
         message has traversed a loop.  LDP supports the notion of a
         maximum allowable Path Vector length; an LSR that detects a
         Path Vector has reached the maximum length behaves as if the
         containing message has traversed a loop.

      -  A Hop Count TLV contains a count of the LSRS that the
         containing message has traversed.  When an LSR propagates a
         message containing a Hop Count TLV, it increments the count.
         An LSR that detects a Hop Count has reached a configured
         maximum value behaves as if the containing message has
         traversed a loop.  By convention, a count of 0 is interpreted
         to mean the hop count is unknown.  Incrementing an unknown hop
         count value results in an unknown hop count value (0).

   The following paragraphs describe LDP Loop Detection procedures.  For
   these paragraphs, and only these paragraphs, "MUST" is redefined to
   mean "MUST if configured for Loop Detection".  The paragraphs specify
   messages that MUST carry Path Vector and Hop Count TLVs.  Note that
   the Hop Count TLV and its procedures are used without the Path Vector
   TLV in situations when Loop Detection is not configured (see
   [RFC3035] and [RFC3034]).

2.8.1.  Label Request Message

   The use of the Path Vector TLV and Hop Count TLV prevent Label
   Request messages from looping in environments that include non-merge
   capable LSRs.

Top      Up      ToC       Page 24 
   The rules that govern use of the Hop Count TLV in Label Request
   messages by LSR R when Loop Detection is enabled are the following:

   -  The Label Request message MUST include a Hop Count TLV.

   -  If R is sending the Label Request because it is a FEC ingress, it
      MUST include a Hop Count TLV with hop count value 1.

   -  If R is sending the Label Request as a result of having received a
      Label Request from an upstream LSR, and if the received Label
      Request contains a Hop Count TLV, R MUST increment the received
      hop count value by 1 and MUST pass the resulting value in a Hop
      Count TLV to its next hop along with the Label Request message.

   The rules that govern use of the Path Vector TLV in Label Request
   messages by LSR R when Loop Detection is enabled are the following:

   -  If R is sending the Label Request because it is a FEC ingress,
      then if R is non-merge capable, it MUST include a Path Vector TLV
      of length 1 containing its own LSR Id.

   -  If R is sending the Label Request as a result of having received a
      Label Request from an upstream LSR, then if the received Label
      Request contains a Path Vector TLV or if R is non-merge capable:

         R MUST add its own LSR Id to the Path Vector, and MUST pass the
         resulting Path Vector to its next hop along with the Label
         Request message.  If the Label Request contains no Path Vector
         TLV, R MUST include a Path Vector TLV of length 1 containing
         its own LSR Id.

   Note that if R receives a Label Request message for a particular FEC,
   and R has previously sent a Label Request message for that FEC to its
   next hop and has not yet received a reply, and if R intends to merge
   the newly received Label Request with the existing outstanding Label
   Request, then R does not propagate the Label Request to the next hop.

   If R receives a Label Request message from its next hop with a Hop
   Count TLV that exceeds the configured maximum value, or with a Path
   Vector TLV containing its own LSR Id or which exceeds the maximum
   allowable length, then R detects that the Label Request message has
   traveled in a loop.

   When R detects a loop, it MUST send a Loop Detected Notification
   message to the source of the Label Request message and drop the Label
   Request message.

Top      Up      ToC       Page 25 
2.8.2.  Label Mapping Message

   The use of the Path Vector TLV and Hop Count TLV in the Label Mapping
   message provide a mechanism to find and terminate looping LSPs.  When
   an LSR receives a Label Mapping message from a next hop, the message
   is propagated upstream as specified below until an ingress LSR is
   reached or a loop is found.

   The rules that govern the use of the Hop Count TLV in Label Mapping
   messages sent by an LSR R when Loop Detection is enabled are the
   following:

   -  R MUST include a Hop Count TLV.

   -  If R is the egress, the hop count value MUST be 1.

   -  If the Label Mapping message is being sent to propagate a Label
      Mapping message received from the next hop to an upstream peer,
      the hop count value MUST be determined as follows:

      o  If R is a member of the edge set of an LSR domain whose LSRs do
         not perform 'TTL-decrement' (e.g., an ATM LSR domain or a Frame
         Relay LSR domain) 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 hop count received from the
         next hop before propagating the message.

   -  If the Label Mapping message is not being sent to propagate a
      Label Mapping message, the hop count value MUST be the result of
      incrementing R's current knowledge of the hop count learned from
      previous Label Mapping messages.  Note that this hop count value
      will be unknown if R has not received a Label Mapping message from
      the next hop.

   Any Label Mapping message MAY contain a Path Vector TLV.  The rules
   that govern the mandatory use of the Path Vector TLV in Label Mapping
   messages sent by LSR R when Loop Detection is enabled are the
   following:

   -  If R is the egress, the Label Mapping message need not include a
      Path Vector TLV.

   -  If R is sending the Label Mapping message to propagate a Label
      Mapping message received from the next hop to an upstream peer,
      then:

Top      Up      ToC       Page 26 
      o  If R is merge capable and if R has not previously sent a Label
         Mapping message to the upstream peer, then it MUST include a
         Path Vector TLV.

      o  If the received message contains an unknown hop count, then R
         MUST include a Path Vector TLV.

      o  If R has previously sent a Label Mapping message to the
         upstream peer, then it MUST include a Path Vector TLV if the
         received message reports an LSP hop count increase, a change in
         hop count from unknown to known, or a change from known to
         unknown.

   If the above rules require R include a Path Vector TLV in the Label
   Mapping message, R computes it as follows:

      o  If the received Label Mapping message included a Path Vector,
         the Path Vector sent upstream MUST be the result of adding R's
         LSR Id to the received Path Vector.

      o  If the received message had no Path Vector, the Path Vector
         sent upstream MUST be a Path Vector of length 1 containing R's
         LSR Id.

   -  If the Label Mapping message is not being sent to propagate a
      received message upstream, the Label Mapping message MUST include
      a Path Vector of length 1 containing R's LSR Id.

      If R receives a Label Mapping message from its next hop with a Hop
      Count TLV that exceeds the configured maximum value, or with a
      Path Vector TLV containing its own LSR Id or that exceeds the
      maximum allowable length, then R detects that the corresponding
      LSP contains a loop.

      When R detects a loop, it MUST stop using the label for
      forwarding, drop the Label Mapping message, and signal Loop
      Detected status to the source of the Label Mapping message.

2.8.3.  Discussion

   If Loop Detection is desired in an MPLS domain, then it should be
   turned on in ALL LSRs within that MPLS domain, else Loop Detection
   will not operate properly and may result in undetected loops or in
   falsely detected loops.

   LSRs that are configured for Loop Detection are NOT expected to store
   the Path Vectors as part of the LSP state.

Top      Up      ToC       Page 27 
   Note that in a network where only non-merge capable LSRs are present,
   Path Vectors are passed downstream from ingress to egress, and are
   not passed upstream.  Even when merge is supported, Path Vectors need
   not be passed upstream along an LSP that is known to reach the
   egress.  When an LSR experiences a change of next hop, it need pass
   Path Vectors upstream only when it cannot tell from the hop count
   that the change of next hop does not result in a loop.

   In the case of ordered label distribution, Label Mapping messages are
   propagated from egress toward ingress, naturally creating the Path
   Vector along the way.  In the case of independent label distribution,
   an LSR may originate a Label Mapping message for a FEC before
   receiving a Label Mapping message from its downstream peer for that
   FEC.  In this case, the subsequent Label Mapping message for the FEC
   received from the downstream peer is treated as an update to LSP
   attributes, and the Label Mapping message must be propagated
   upstream.  Thus, it is recommended that Loop Detection be configured
   in conjunction with ordered label distribution, to minimize the
   number of Label Mapping update messages.

2.9.  Authenticity and Integrity of LDP Messages

   This section specifies a mechanism to protect against the
   introduction of spoofed TCP segments into LDP session connection
   streams.  The use of this mechanism MUST be supported as a
   configurable option.

   The mechanism is based on use of the TCP MD5 Signature Option
   specified in [RFC2385] for use by BGP [RFC4271].  See [RFC1321] for a
   specification of the MD5 hash function.  From a standards maturity
   point of view, the current document relates to [RFC2385] the same way
   as [RFC4271] relates to [RFC2385].  This is explained in [RFC4278].

2.9.1.  TCP MD5 Signature Option

   The following quotes from [RFC2385] outline the security properties
   achieved by using the TCP MD5 Signature Option and summarize its
   operation:

      "IESG Note

         This document describes current existing practice for securing
         BGP against certain simple attacks.  It is understood to have
         security weaknesses against concerted attacks."

Top      Up      ToC       Page 28 
      "Abstract

         This memo describes a TCP extension to enhance security for
         BGP.  It defines a new TCP option for carrying an MD5 [RFC1321]
         digest in a TCP segment.  This digest acts like a signature for
         that segment, incorporating information known only to the
         connection end points.  Since BGP uses TCP as its transport,
         using this option in the way described in this paper
         significantly reduces the danger from certain security attacks
         on BGP."

      "Introduction

         The primary motivation for this option is to allow BGP to
         protect itself against the introduction of spoofed TCP segments
         into the connection stream.  Of particular concern are TCP
         resets.

         To spoof a connection using the scheme described in this paper,
         an attacker would not only have to guess TCP sequence numbers,
         but would also have had to obtain the password included in the
         MD5 digest.  This password never appears in the connection
         stream, and the actual form of the password is up to the
         application.  It could even change during the lifetime of a
         particular connection so long as this change was synchronized
         on both ends (although retransmission can become problematical
         in some TCP implementations with changing passwords).

         Finally, there is no negotiation for the use of this option in
         a connection, rather it is purely a matter of site policy
         whether or not its connections use the option."

      "MD5 as a Hashing Algorithm

         Since this memo was first issued (under a different title), the
         MD5 algorithm has been found to be vulnerable to collision
         search attacks [Dobb], and is considered by some to be
         insufficiently strong for this type of application.

         This memo still specifies the MD5 algorithm, however, since the
         option has already been deployed operationally, and there was
         no "algorithm type" field defined to allow an upgrade using the
         same option number.  The original document did not specify a
         type field since this would require at least one more byte, and
         it was felt at the time that taking 19 bytes for the complete
         option (which would probably be padded to 20 bytes in TCP
         implementations) would be too much of a waste of the already
         limited option space.

Top      Up      ToC       Page 29 
         This does not prevent the deployment of another similar option
         which uses another hashing algorithm (like SHA-1).  Also, if
         most implementations pad the 18 byte option as defined to 20
         bytes anyway, it would be just as well to define a new option
         which contains an algorithm type field.

         This would need to be addressed in another document, however."

   End of quotes from [RFC2385].

2.9.2.  LDP Use of TCP MD5 Signature Option

   LDP uses the TCP MD5 Signature Option as follows:

      -  Use of the MD5 Signature Option for LDP TCP connections is a
         configurable LSR option.

      -  An LSR that uses the MD5 Signature Option is configured with a
         password (shared secret) for each potential LDP peer.

      -  The LSR applies the MD5 algorithm as specified in [RFC2385] to
         compute the MD5 digest for a TCP segment to be sent to a peer.
         This computation makes use of the peer password as well as the
         TCP segment.

      -  When the LSR receives a TCP segment with an MD5 digest, it
         validates the segment by calculating the MD5 digest (using its
         own record of the password) and compares the computed digest
         with the received digest.  If the comparison fails, the segment
         is dropped without any response to the sender.

      -  The LSR ignores LDP Hellos from any LSR for which a password
         has not been configured.  This ensures that the LSR establishes
         LDP TCP connections only with LSRs for which a password has
         been configured.

2.10.  Label Distribution for Explicitly Routed LSPs

   Traffic Engineering [RFC2702] is expected to be an important MPLS
   application.  MPLS support for Traffic Engineering uses explicitly
   routed LSPs, which need not follow normally-routed (hop-by-hop) paths
   as determined by destination-based routing protocols.  CR-LDP [CRLDP]
   defines extensions to LDP to use LDP to set up explicitly routed
   LSPs.

Top      Up      ToC       Page 30 
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 31 
   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 32 
    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 MUST be silently ignored and the rest of the message
      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.  By setting both
      the U- and F-bits, a TLV can be propagated as opaque data through
      nodes that do not recognize the TLV.

   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.

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

      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 35 
      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 [ASSIGNED_AF] 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.

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 that can appear in
   situations that require a Label TLV.

Top      Up      ToC       Page 36 
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 represented as a 20-bit number in a 4
      octet field as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Label                             |                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      For further information, see [RFC3032].

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.

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

   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 of DLCI
         2 = 23 bits of DLCI

      Len values 1 and 3 are reserved.

   DLCI
      The Data Link Connection Identifier

Top      Up      ToC       Page 38 
      For a 10-bit DLCI, the 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| Frame Relay Label (0x0202)|       Length                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Reserved    |Len|            0            |    10-bit DLCI    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      For a 23-bit DLCI, the 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| Frame Relay Label (0x0202)|       Length                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Reserved    |Len|              23-bit DLCI                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      For further information, see [RFC3034].

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 [ASSIGNED_AF] that encodes the addresses contained in the
      Addresses field.

Top      Up      ToC       Page 39 
   Addresses
      A list of addresses from the specified Address Family.  The
      encoding of the individual addresses depends on the Address
      Family.

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

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

Top      Up      ToC       Page 40 
   -  If the message is a Label Mapping message, R determines the hop
      count as follows:

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

Top      Up      ToC       Page 41 
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
   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 set up 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.

Top      Up      ToC       Page 42 
   The LSR MUST:

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

      2. Not propagate the Label Request message further.

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

      1. A loop is found,

      2. The LSP egress is reached, or

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

Top      Up      ToC       Page 43 
3.4.6.  Status TLV

   Notification messages carry Status TLVs to specify events being
   signaled.

   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.

Top      Up      ToC       Page 44 
      Status Data
         30-bit unsigned integer that specifies the status information.

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

         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.



(page 44 continued on part 3)

Next RFC Part