tech-invite   World Map     

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

RFC 3036

 
 
 

LDP Specification

Part 3 of 4, p. 63 to 88
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 63 
3.5.4. KeepAlive Message

   An LSR sends KeepAlive Messages as part of a mechanism that monitors
   the integrity of the LDP session transport connection.

   The encoding for the KeepAlive Message is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   KeepAlive (0x0201)        |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Optional Parameters
      No optional parameters are defined for the KeepAlive message.

3.5.4.1. KeepAlive Message Procedures

   The KeepAlive Timer mechanism described in Section "Maintaining LDP
   Sessions" resets a session KeepAlive timer every time an LDP PDU is

Top      Up      ToC       Page 64 
   received on the session TCP connection.  The KeepAlive Message is
   provided to allow reset of the KeepAlive Timer in circumstances where
   an LSR has no other information to communicate to an LDP peer.

   An LSR must arrange that its peer receive an LDP Message from it at
   least every KeepAlive Time period.  Any LDP protocol message will do
   but, in circumstances where no other LDP protocol messages have been
   sent within the period, a KeepAlive message must be sent.

3.5.5. Address Message

   An LSR sends the Address Message to an LDP peer to advertise its
   interface addresses.

   The encoding for the Address Message is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Address (0x0300)          |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Address List TLV                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Address List TLV
      The list of interface addresses being advertised by the sending
      LSR.  The encoding for the Address List TLV is specified in Section
      "Address List TLV".

   Optional Parameters
      No optional parameters are defined for the Address message.

3.5.5.1. Address Message Procedures

   An LSR that receives an Address Message message uses the addresses it
   learns to maintain a database for mapping between peer LDP
   Identifiers and next hop addresses; see Section "LDP Identifiers and
   Next Hop Addresses".

Top      Up      ToC       Page 65 
   When a new LDP session is initialized and before sending Label
   Mapping or Label Request messages an LSR should advertise its
   interface addresses with one or more Address messages.

   Whenever an LSR "activates" a new interface address, it should
   advertise the new address with an Address message.

   Whenever an LSR "de-activates" a previously advertised address, it
   should withdraw the address with an Address Withdraw message; see
   Section "Address Withdraw Message".

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

3.5.6. Address Withdraw Message

   An LSR sends the Address Withdraw Message to an LDP peer to withdraw
   previously advertised interface addresses.

   The encoding for the Address Withdraw Message is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Address Withdraw (0x0301) |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Address List TLV                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Address list TLV
      The list of interface addresses being withdrawn by the sending
      LSR.  The encoding for the Address list TLV is specified in
      Section "Address List TLV".

   Optional Parameters
      No optional parameters are defined for the Address Withdraw
      message.

Top      Up      ToC       Page 66 
3.5.6.1. Address Withdraw Message Procedures

   See Section "Address Message Procedures"

3.5.7. Label Mapping Message

   An LSR sends a Label Mapping message to an LDP peer to advertise
   FEC-label bindings to the peer.

   The encoding for the Label Mapping Message is:

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

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

   FEC TLV
      Specifies the FEC component of the FEC-Label mapping being
      advertised.  See Section "FEC TLV" for encoding.

   Label TLV
      Specifies the Label component of the FEC-Label mapping.  See
      Section "Label TLV" for encoding.

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

         Optional Parameter    Length       Value

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

Top      Up      ToC       Page 67 
      The encodings for the Hop Count, and Path Vector TLVs can be found
      in Section "TLV Encodings for Commonly Used Parameters".

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

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

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

3.5.7.1. Label Mapping Message Procedures

   The Mapping message is used by an LSR to distribute a label mapping
   for a FEC to an LDP peer.  If an LSR distributes a mapping for a FEC
   to multiple LDP peers, it is a local matter whether it maps a single
   label to the FEC, and distributes that mapping to all its peers, or
   whether it uses a different mapping for each of its peers.

   An LSR is responsible for the consistency of the label mappings it
   has distributed, and that its peers have these mappings.

   An LSR receiving a Label Mapping message from a downstream LSR for a
   Prefix or Host Address FEC Element should not use the label for
   forwarding unless its routing table contains an entry that exactly
   matches the FEC Element.

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

3.5.7.1.1. Independent Control Mapping

   If an LSR is configured for independent control, a mapping message is
   transmitted by the LSR upon any of the following conditions:

      1. The LSR recognizes a new FEC via the forwarding table, and the
         label advertisement mode is Downstream Unsolicited
         advertisement.

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

Top      Up      ToC       Page 68 
      3. The next hop for a FEC changes to another LDP peer, and loop
         detection is configured.

      4. The attributes of a mapping change.

      5. The receipt of a mapping from the downstream next hop  AND
            a) no upstream mapping has been created  OR
            b) loop detection is configured  OR
            c) the attributes of the mapping have changed.

3.5.7.1.2. Ordered Control Mapping

   If an LSR is doing ordered control, a Mapping message is transmitted
   by downstream LSRs upon any of the following conditions:

      1. The LSR recognizes a new FEC via the forwarding table, and is
         the egress for that FEC.

      2. The LSR receives a Request message from an upstream peer for a
         FEC present in the LSR's forwarding table, and the LSR is the
         egress for that FEC OR has a downstream mapping for that FEC.

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

      4. The attributes of a mapping change.

      5. The receipt of a mapping from the downstream next hop  AND
            a) no upstream mapping has been created   OR
            b) loop detection is configured   OR
            c) the attributes of the mapping have changed.

3.5.7.1.3. Downstream on Demand Label Advertisement

   In general, the upstream LSR is responsible for requesting label
   mappings when operating in Downstream on Demand mode.  However,
   unless some rules are followed, it is possible for neighboring LSRs
   with different advertisement modes to get into a livelock situation
   where everything is functioning properly, but no labels are
   distributed.  For example, consider two LSRs Ru and Rd where Ru is
   the upstream LSR and Rd is the downstream LSR for a particular FEC.
   In this example, Ru is using Downstream Unsolicited advertisement
   mode and Rd is using Downstream on Demand mode.  In this case, Rd may
   assume that Ru will request a label mapping when it wants one and Ru
   may assume that Rd will advertise a label if it wants Ru to use one.
   If Rd and Ru operate as suggested, no labels will be distributed from
   Rd to Ru.

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

3.5.7.1.4. Downstream Unsolicited Label Advertisement

   In general, the downstream LSR is responsible for advertising a label
   mapping when it wants an upstream LSR to use the label.  An upstream
   LSR may issue a mapping request if it so desires.

   The combination of Downstream Unsolicited mode and conservative label
   retention can lead to a situation where an LSR releases the label for
   a FEC that it later needs.  For example, if LSR Rd advertises to LSR
   Ru the label for a FEC for which it is not Ru's next hop, Ru will
   release the label.  If Ru's next hop for the FEC later changes to Rd,
   it needs the previously released label.

   To deal with this situation either Ru can explicitly request the
   label when it needs it, or Rd can periodically readvertise it to Ru.
   In many situations Ru will know when it needs the label from Rd.  For
   example, when its next hop for the FEC changes to Rd.  However, there
   could be situations when Ru does not.  For example, Rd may be
   attempting to establish an LSP with non-standard properties.  Forcing
   Ru to explicitly request the label in this situation would require it
   to maintain state about a potential LSP with non-standard properties.

   In situations where Ru knows it needs the label, it is responsible
   for explicitly requesting the label by means of a Label Request
   message.  In situations where Ru may not know that it needs the
   label, Rd is responsible for periodically readvertising the label to
   Ru.

   For this version of LDP, the only situation where Ru knows it needs a
   label for a FEC from Rd is when Rd is its next hop for the FEC, Ru
   does not have a label from Rd, and the LSP for the FEC is one that
   can be established with TLVs defined in this document.

3.5.8. Label Request Message

   An LSR sends the Label Request Message to an LDP peer to request a
   binding (mapping) for a FEC.

Top      Up      ToC       Page 70 
   The encoding for the Label Request Message is:

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

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

   FEC TLV
      The FEC for which a label is being requested.  See Section "FEC
      TLV" for encoding.

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

         Optional Parameter     Length       Value

         Hop Count TLV          1            See below
         Path Vector TLV        variable     See below

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

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

      Path Vector
         Specifies the LSRs along the LSR being setup by the Label
         Request Message.  Section "Path Vector Procedures" describes
         how to handle this TLV.

3.5.8.1. Label Request Message Procedures

   The Request message is used by an upstream LSR to explicitly request
   that the downstream LSR assign and advertise a label for a FEC.

Top      Up      ToC       Page 71 
   An LSR may transmit a Request message under any of the following
   conditions:

      1. The LSR recognizes a new FEC via the forwarding table, and the
         next hop is an LDP peer, and the LSR doesn't already have a
         mapping from the next hop for the given FEC.

      2. The next hop to the FEC changes, and the LSR doesn't already
         have a mapping from that next hop for the given FEC.

         Note that if the LSR already has a pending Label Request
         message for the new next hop it should not issue an additional
         Label Request in response to the next hop change.

      3. The LSR receives a Label Request for a FEC from an upstream LDP
         peer, the FEC next hop is an LDP peer, and the LSR doesn't
         already have a mapping from the next hop.

         Note that since a non-merge LSR must setup a separate LSP for
         each upstream peer requesting a label, it must send a separate
         Label Request for each such peer.  A consequence of this is
         that a non-merge LSR may have multiple Label Request messages
         for a given FEC outstanding at the same time.

   The receiving LSR should respond to a Label Request message with a
   Label Mapping for the requested label or with a Notification message
   indicating why it cannot satisfy the request.

   When the FEC for which a label is requested is a Prefix FEC Element
   or a Host Address FEC Element, the receiving LSR uses its routing
   table to determine its response.  Unless its routing table includes
   an entry that exactly matches the requested Prefix or Host Address,
   the LSR must respond with a No Route Notification message.

   The message ID of the Label Request message serves as an identifier
   for the Label Request transaction.  When the receiving LSR responds
   with a Label Mapping message, the mapping message must include a
   Label Request/Returned Message ID TLV optional parameter which
   includes the message ID of the Label Request message.  Note that
   since LSRs use Label Request message IDs as transaction identifiers
   an LSR should not reuse the message ID of a Label Request message
   until the corresponding transaction completes.

   This version of the protocol defines the following Status Codes for
   the Notification message that signals a request cannot be satisfied:

Top      Up      ToC       Page 72 
      No Route
         The FEC for which a label was requested includes a FEC Element
         for which the LSR does not have a route.

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

         An LSR that receives a No Label Resources response to a Label
         Request message must not issue further Label Request messages
         until it receives a Notification message with the Label
         Resources Available Status code.

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

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

3.5.9. Label Abort Request Message

   The Label Abort Request message may be used to abort an outstanding
   Label Request message.

   The encoding for the Label Abort Request Message is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Label Abort Req (0x0404)  |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Label Request Message ID TLV              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   FEC TLV
      Identifies the FEC for which the Label Request is being aborted.

Top      Up      ToC       Page 73 
   Label Request Message ID TLV
      Specifies the message ID of the Label Request message to be
      aborted.

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

3.5.9.1. Label Abort Request Message Procedures

   An LSR Ru may send a Label Abort Request message to abort an
   outstanding Label Request message for FEC sent to LSR Rd in the
   following circumstances:

      1. Ru's next hop for FEC has changed from LSR Rd to LSR X; or

      2. Ru is a non-merge, non-ingress LSR and has received a Label
         Abort Request for FEC from an upstream peer Y.

      3. Ru is a merge, non-ingress LSR and has received a Label Abort
         Request for FEC from an upstream peer Y and Y is the only
         (last) upstream LSR requesting a label for FEC.

   There may be other situations where an LSR may choose to abort an
   outstanding Label Request message in order to reclaim resource
   associated with the pending LSP.  However, specification of general
   strategies for using the abort mechanism is beyond the scope of LDP.

   When an LSR receives a Label Abort Request message, if it has not
   previously responded to the Label Request being aborted with a Label
   Mapping message or some other Notification message, it must
   acknowledge the abort by responding with a Label Request Aborted
   Notification message.  The Notification must include a Label Request
   Message ID TLV that carries the message ID of the aborted Label
   Request message.

   If an LSR receives a Label Abort Request Message after it has
   responded to the Label Request in question with a Label Mapping
   message or a Notification message, it ignores the abort request.

   If an LSR receives a Label Mapping message in response to a Label
   Request message after it has sent a Label Abort Request message to
   abort the Label Request, the label in the Label Mapping message is
   valid.  The LSR may choose to use the label or to release it with a
   Label Release message.

Top      Up      ToC       Page 74 
   An LSR aborting a Label Request message may not reuse the Message ID
   for the Label Request message until it receives one of the following
   from its peer:

      -  A Label Request Aborted Notification message acknowledging the
         abort;

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

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

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

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

3.5.10. Label Withdraw Message

   An LSR sends a Label Withdraw Message to an LDP peer to signal the
   peer that the peer may not continue to use specific FEC-label
   mappings the LSR had previously advertised.  This breaks the mapping
   between the FECs and the labels.

Top      Up      ToC       Page 75 
   The encoding for the Label Withdraw Message is:

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

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

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

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

         Optional Parameter    Length       Value

         Label TLV             variable     See below

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

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

3.5.10.1. Label Withdraw Message Procedures

   An LSR transmits a Label Withdraw message under the following
   conditions:

      1. The LSR no longer recognizes a previously known FEC for which
         it has advertised a label.

      2. The LSR has decided unilaterally (e.g., via configuration) to
         no longer label switch a FEC (or FECs) with the label mapping
         being withdrawn.

Top      Up      ToC       Page 76 
   The FEC TLV specifies the FEC for which labels are to be withdrawn.
   If no Label TLV follows the FEC, all labels associated with the FEC
   are to be withdrawn; otherwise only the label specified in the
   optional Label TLV is to be withdrawn.

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

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

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

3.5.11. Label Release Message

   An LSR sends a Label Release message to an LDP peer to signal the
   peer that the LSR no longer needs specific FEC-label mappings
   previously requested of and/or advertised by the peer.

   The encoding for the Label Release Message is:

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

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

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

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

         Optional Parameter    Length       Value

         Label TLV             variable     See below

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

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

3.5.11.1. Label Release Message Procedures

   An LSR transmits a Label Release message to a peer when it is no
   longer needs a label previously received from or requested of that
   peer.

   An LSR must transmit a Label Release message under any of the
   following conditions:

      1. The LSR which sent the label mapping is no longer the next hop
         for the mapped FEC, and the LSR is configured for conservative
         operation.

      2. The LSR receives a label mapping from an LSR which is not the
         next hop for the FEC, and the LSR is configured for
         conservative operation.

      3. The LSR receives a Label Withdraw message.

   Note that if an LSR is configured for "liberal mode", a release
   message will never be transmitted in the case of conditions (1) and
   (2) as specified above.  In this case, the upstream LSR keeps each
   unused label, so that it can immediately be used later if the
   downstream peer becomes the next hop for the FEC.

   The FEC TLV specifies the FEC for which labels are to be released.
   If no Label TLV follows the FEC, all labels associated with the FEC
   are to be released; otherwise only the label specified in the
   optional Label TLV is to be released.

   The FEC TLV may contain the Wildcard FEC Element; if so, it may
   contain no other FEC Elements.  In this case, if the Label Release
   message contains an optional Label TLV, then the label is to be
   released for all FECs to which it is bound.  If there is not an

Top      Up      ToC       Page 78 
   optional Label TLV in the Label Release message, then the sending LSR
   is releasing all label mappings previously learned from the receiving
   LSR.

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

3.6. Messages and TLVs for Extensibility

   Support for LDP extensibility includes the rules for the U and F bits
   that specify how an LSR should handle unknown TLVs and messages.

   This section specifies TLVs and messages for vendor-private and
   experimental use.

3.6.1. LDP Vendor-private Extensions

   Vendor-private TLVs and messages are used to convey vendor-private
   information between LSRs.

3.6.1.1. LDP Vendor-private TLVs

   The Type range 0x3E00 through 0x3EFF is reserved for vendor-private
   TLVs.

   The encoding for a vendor-private 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|    Type (0x3E00-0x3EFF)   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Vendor ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           Data....                            |
   ~                                                               ~
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.

Top      Up      ToC       Page 79 
      The determination as to whether a vendor-private message is
      understood is based on the Type and the mandatory Vendor ID field.

   F bit
      Forward unknown TLV bit.  This bit only applies when the U bit is
      set and the LDP message containing the unknown TLV is 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.

   Type
      Type value in the range 0x3E00 through 0x3EFF.  Together, the Type
      and Vendor Id field specify how the Data field is to be
      interpreted.

   Length
      Specifies the cumulative length in octets of the Vendor ID and
      Data fields.

   Vendor Id
      802 Vendor ID as assigned by the IEEE.

   Data
      The remaining octets after the Vendor ID in the Value field are
      optional vendor-dependent data.

Top      Up      ToC       Page 80 
3.6.1.2. LDP Vendor-private Messages

   The Message Type range 0x3E00 through 0x3EFF is reserved for vendor-
   private Messages.

    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|    Msg Type (0x3E00-0x3EFF) |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Vendor ID                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +                                                               +
   |                     Remaining Mandatory Parameters            |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                     Optional Parameters                       |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 determination as to whether a vendor-private message is
      understood is based on the Msg Type and the Vendor ID parameter.

   Msg Type
      Message type value in the range 0x3E00 through 0x3EFF.  Together,
      the Msg Type and the Vendor ID specify how the message is to be
      interpreted.

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

Top      Up      ToC       Page 81 
   Message ID
      32-bit integer 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 will include this Message Id in the
      notification message; see Section "Notification Message".

   Vendor ID
      802 Vendor ID as assigned by the IEEE.

   Remaining Mandatory Parameters
      Variable length set of remaining required message parameters.

   Optional Parameters
      Variable length set of optional message parameters.

3.6.2. LDP Experimental Extensions

   LDP support for experimentation is similar to support for vendor-
   private extensions with the following differences:

      -  The Type range 0x3F00 through 0x3FFF is reserved for
         experimental TLVs.

      -  The Message Type range 0x3F00 through 0x3FFF is reserved for
         experimental messages.

      -  The encodings for experimental TLVs and messages are similar to
         the vendor-private encodings with the following difference.

         Experimental TLVs and messages use an Experiment ID field in
         place of a Vendor ID field.  The Experiment ID field is used
         with the Type or Message Type field to specify the
         interpretation of the experimental TLV or Message.

         Administration of Experiment IDs is the responsibility of the
         experimenters.

3.7. Message Summary

   The following are the LDP messages defined in this version of the
   protocol.

      Message Name            Type     Section Title

      Notification            0x0001   "Notification Message"
      Hello                   0x0100   "Hello Message"
      Initialization          0x0200   "Initialization Message"

Top      Up      ToC       Page 82 
      KeepAlive               0x0201   "KeepAlive Message"
      Address                 0x0300   "Address Message"
      Address Withdraw        0x0301   "Address Withdraw Message"
      Label Mapping           0x0400   "Label Mapping Message"
      Label Request           0x0401   "Label Request Message"
      Label Withdraw          0x0402   "Label Withdraw Message"
      Label Release           0x0403   "Label Release Message"
      Label Abort Request     0x0404   "Label Abort Request Message"
      Vendor-Private          0x3E00-  "LDP Vendor-private Extensions"
                              0x3EFF
      Experimental            0x3F00-  "LDP Experimental Extensions"
                              0x3FFF

3.8. TLV Summary

   The following are the TLVs defined in this version of the protocol.

      TLV                      Type      Section Title

      FEC                      0x0100    "FEC TLV"
      Address List             0x0101    "Address List TLV"
      Hop Count                0x0103    "Hop Count TLV"
      Path Vector              0x0104    "Path Vector TLV"
      Generic Label            0x0200    "Generic Label TLV"
      ATM Label                0x0201    "ATM Label TLV"
      Frame Relay Label        0x0202    "Frame Relay Label TLV"
      Status                   0x0300    "Status TLV"
      Extended Status          0x0301    "Notification Message"
      Returned PDU             0x0302    "Notification Message"
      Returned Message         0x0303    "Notification Message"
      Common Hello             0x0400    "Hello Message"
         Parameters
      IPv4 Transport Address   0x0401    "Hello Message"
      Configuration            0x0402    "Hello Message"
         Sequence Number
      IPv6 Transport Address   0x0403    "Hello Message"
      Common Session           0x0500    "Initialization Message"
         Parameters
      ATM Session Parameters   0x0501    "Initialization Message"
      Frame Relay Session      0x0502    "Initialization Message"
         Parameters
      Label Request            0x0600    "Label Mapping Message"
          Message ID
      Vendor-Private           0x3E00-   "LDP Vendor-private Extensions"
                               0x3EFF
      Experimental             0x3F00-   "LDP Experimental Extensions"
                               0x3FFF

Top      Up      ToC       Page 83 
3.9. Status Code Summary

   The following are the Status Codes defined in this version of the
   protocol.

   The "E" column is the required setting of the Status Code E-bit; the
   "Status Data" column is the value of the 30-bit Status Data field in
   the Status Code TLV.

   Note that the setting of the Status Code F-bit is at the discretion
   of the LSR originating the Status TLV.

      Status Code           E   Status Data   Section Title

      Success               0   0x00000000    "Status TLV"
      Bad LDP Identifier    1   0x00000001    "Events Signaled by ..."
      Bad Protocol Version  1   0x00000002    "Events Signaled by ..."
      Bad PDU Length        1   0x00000003    "Events Signaled by ..."
      Unknown Message Type  0   0x00000004    "Events Signaled by ..."
      Bad Message Length    1   0x00000005    "Events Signaled by ..."
      Unknown TLV           0   0x00000006    "Events Signaled by ..."
      Bad TLV length        1   0x00000007    "Events Signaled by ..."
      Malformed TLV Value   1   0x00000008    "Events Signaled by ..."
      Hold Timer Expired    1   0x00000009    "Events Signaled by ..."
      Shutdown              1   0x0000000A    "Events Signaled by ..."
      Loop Detected         0   0x0000000B    "Loop Detection"
      Unknown FEC           0   0x0000000C    "FEC Procedures"
      No Route              0   0x0000000D    "Label Request Mess ..."
      No Label Resources    0   0x0000000E    "Label Request Mess ..."
      Label Resources /     0   0x0000000F    "Label Request Mess ..."
          Available
      Session Rejected/     1   0x00000010    "Session Initialization"
         No Hello
      Session Rejected/     1   0x00000011    "Session Initialization"
         Parameters Advertisement Mode
      Session Rejected/     1   0x00000012    "Session Initialization"
         Parameters Max PDU Length
      Session Rejected/     1   0x00000013    "Session Initialization"
         Parameters Label Range
      KeepAlive Timer       1   0x00000014    "Events Signaled by ..."
          Expired
      Label Request Aborted 0   0x00000015    "Label Request Abort ..."
      Missing Message       0   0x00000016    "Events Signaled by ..."
          Parameters
      Unsupported Address   0   0x00000017    "FEC Procedures"
          Family                              "Address Message Proc ..."

Top      Up      ToC       Page 84 
      Session Rejected/     1   0x00000018    "Session Initialization"
         Bad KeepAlive Time
      Internal Error        1   0x00000019    "Events Signaled by ..."

3.10. Well-known Numbers

3.10.1. UDP and TCP Ports

   The UDP port for LDP Hello messages is 646.

   The TCP port for establishing LDP session connections is 646.

3.10.2. Implicit NULL Label

   The Implicit NULL label (see [RFC3031]) is represented as a Generic
   Label TLV with a Label field value as specified by [RFC3032].

4. IANA Considerations

   LDP defines the following name spaces which require management:

      -  Message Type Name Space.
      -  TLV Type Name Space.
      -  FEC Type Name Space.
      -  Status Code Name Space.
      -  Experiment ID Name Space.

   The following sections provide guidelines for managing these name
   spaces.

4.1. Message Type Name Space

   LDP divides the name space for message types into three ranges.  The
   following are the guidelines for managing these ranges:

      -  Message Types 0x0000 - 0x3DFF.  Message types in this range are
         part of the LDP base protocol.  Following the policies outlined
         in [IANA], Message types in this range are allocated through an
         IETF Consensus action.

      -  Message Types 0x3E00 - 0x3EFF.  Message types in this range are
         reserved for Vendor Private extensions and are the
         responsibility of the individual vendors (see Section "LDP
         Vendor-private Messages").  IANA management of this range of
         the Message Type Name Space is unnecessary.

Top      Up      ToC       Page 85 
      -  Message Types 0x3F00 - 0x3FFF.  Message types in this range are
         reserved for Experimental extensions and are the responsibility
         of the individual experimenters (see Sections "LDP Experimental
         Extensions" and "Experiment ID Name Space").  IANA management
         of this range of the Message Type Name Space is unnecessary;
         however, IANA is responsible for managing part of the
         Experiment ID Name Space (see below).

4.2. TLV Type Name Space

   LDP divides the name space for TLV types into three ranges.  The
   following are the guidelines for managing these ranges:

      -  TLV Types 0x0000 - 0x3DFF.  TLV types in this range are part of
         the LDP base protocol.  Following the policies outlined in
         [IANA], TLV types in this range are allocated through an IETF
         Consensus action.

      -  TLV Types 0x3E00 - 0x3EFF.  TLV types in this range are
         reserved for Vendor Private extensions and are the
         responsibility of the individual vendors (see Section "LDP
         Vendor-private TLVs").  IANA management of this range of the
         TLV Type Name Space is unnecessary.

      -  TLV Types 0x3F00 - 0x3FFF.  TLV types in this range are
         reserved for Experimental extensions and are the responsibility
         of the individual experimenters (see Sections "LDP Experimental
         Extensions" and "Experiment ID Name Space").  IANA management
         of this range of the TLV Name Space is unnecessary; however,
         IANA is responsible for managing part of the Experiment ID Name
         Space (see below).

4.3. FEC Type Name Space

   The range for FEC types is 0 - 255.

   Following the policies outlined in [IANA], FEC types in the range 0 -
   127 are allocated through an IETF Consensus action, types in the
   range 128 - 191 are allocated as First Come First Served, and types
   in the range 192 - 255 are reserved for Private Use.

Top      Up      ToC       Page 86 
4.4. Status Code Name Space

   The range for Status Codes is 0x00000000 - 0x3FFFFFFF.

   Following the policies outlined in [IANA], Status Codes in the range
   0x00000000 - 0x1FFFFFFF are allocated through an IETF Consensus
   action, codes in the range 0x20000000 - 0x3EFFFFFF are allocated as
   First Come First Served, and codes in the range 0x3F000000 -
   0x3FFFFFFF are reserved for Private Use.

4.5. Experiment ID Name Space

   The range for Experiment Ids is 0x00000000 - 0xffffffff.

   Following the policies outlined in [IANA], Experiment Ids in the
   range 0x00000000 - 0xefffffff are allocated as First Come First
   Served and Experiment Ids in the range 0xf0000000 - 0xffffffff are
   reserved for Private Use.

5. Security Considerations

   This section identifies threats to which LDP may be vulnerable and
   discusses means by which those threats might be mitigated.

5.1. Spoofing

   There are two types of LDP communication that could be the target of
   a spoofing attack.

   1. Discovery exchanges carried by UDP.

      LSRs directly connected at the link level exchange Basic Hello
      messages over the link.  The threat of spoofed Basic Hellos can be
      reduced by:

         o  Accepting Basic Hellos only on interfaces to which LSRs that
            can be trusted are directly connected.

         o  Ignoring Basic Hellos not addressed to the All Routers on
            this Subnet multicast group.

      LSRs not directly connected at the link level may use Extended
      Hello messages to indicate willingness to establish an LDP
      session.  An LSR can reduce the threat of spoofed Extended Hellos
      by filtering them and accepting only those originating at sources
      permitted by an access list.

Top      Up      ToC       Page 87 
   2. Session communication carried by TCP.

      LDP specifies use of the TCP MD5 Signature Option to provide for
      the authenticity and integrity of session messages.

      [RFC2385] asserts that MD5 authentication is now considered by
      some to be too weak for this application.  It also points out that
      a similar TCP option with a stronger hashing algorithm (it cites
      SHA-1 as an example) could be deployed.  To our knowledge no such
      TCP option has been defined and deployed.  However, we note that
      LDP can use whatever TCP message digest techniques are available,
      and when one stronger than MD5 is specified and implemented,
      upgrading LDP to use it would be relatively straightforward.

5.2. Privacy

   LDP provides no mechanism for protecting the privacy of label
   distribution.

   The security requirements of label distribution protocols are
   essentially identical to those of the protocols which distribute
   routing information.  By providing a mechanism to ensure the
   authenticity and integrity of its messages LDP provides a level of
   security which is at least as good as, though no better than, that
   which can be provided by the routing protocols themselves.  The more
   general issue of whether privacy should be required for routing
   protocols is beyond the scope of this document.

   One might argue that label distribution requires privacy to address
   the threat of label spoofing.  However, that privacy would not
   protect against label spoofing attacks since data packets carry
   labels in the clear.  Furthermore, label spoofing attacks can be made
   without knowledge of the FEC bound to a label.

   To avoid label spoofing attacks, it is necessary to ensure that
   labeled data packets are labeled by trusted LSRs and that the labels
   placed on the packets are properly learned by the labeling LSRs.

5.3. Denial of Service

   LDP provides two potential targets for denial of service (DoS)
   attacks:

   1. Well known UDP Port for LDP Discovery

      An LSR administrator can address the threat of DoS attacks via
      Basic Hellos by ensuring that the LSR is directly connected only
      to peers which can be trusted to not initiate such an attack.

Top      Up      ToC       Page 88 
      Interfaces to peers interior to the administrator's domain should
      not represent a threat since interior peers are under the
      administrator's control.  Interfaces to peers exterior to the
      domain represent a potential threat since exterior peers are not.
      An administrator can reduce that threat by connecting the LSR only
      to exterior peers that can be trusted to not initiate a Basic
      Hello attack.

      DoS attacks via Extended Hellos are potentially a more serious
      threat.  This threat can be addressed by filtering Extended Hellos
      using access lists that define addresses with which extended
      discovery is permitted.  However, performing the filtering
      requires LSR resource.

      In an environment where a trusted MPLS cloud can be identified,
      LSRs at the edge of the cloud can be used to protect interior LSRs
      against DoS attacks via Extended Hellos by filtering out Extended
      Hellos originating outside of the trusted MPLS cloud, accepting
      only those originating at addresses permitted by access lists.
      This filtering protects LSRs in the interior of the cloud but
      consumes resources at the edges.

   2. Well known TCP port for LDP Session Establishment

      Like other control plane protocols that use TCP, LDP may be the
      target of DoS attacks, such a SYN attacks.  LDP is no more or less
      vulnerable to such attacks than other control plane protocols that
      use TCP.

      The threat of such attacks can be mitigated somewhat by the
      following:

         o  An LSR should avoid promiscuous TCP listens for LDP session
            establishment.  It should use only listens that are specific
            to discovered peers.  This enables it to drop attack packets
            early in their processing since they are less likely to
            match existing or in-progress connections.

         o  The use of the MD5 option helps somewhat since it prevents a
            SYN from being accepted unless the MD5 segment checksum is
            valid.  However, the receiver must compute the checksum
            before it can decide to discard an otherwise acceptable SYN
            segment.

         o  The use of access list mechanisms applied at the boundary of
            the MPLS cloud in a manner similar to that suggested above
            for Extended Hellos can protect the interior against attacks
            originating from outside the cloud.


Next RFC Part