Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3036

LDP Specification

Pages: 132
Obsoleted by:  5036
Part 3 of 4 – Pages 63 to 88
First   Prev   Next

ToP   noToC   RFC3036 - Page 63   prevText

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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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   noToC   RFC3036 - 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 page on part 4)

Next Section