Skip to main content

Appendix A. LDP Label Distribution Procedures

This section specifies label distribution behavior in terms of LSR response to the following events:

  • Receive Label Request Message;
  • Receive Label Mapping Message;
  • Receive Label Abort Request Message;
  • Receive Label Release Message;
  • Receive Label Withdraw Message;
  • Recognize new FEC;
  • Detect change in FEC next hop;
  • Receive Notification Message / Label Request Aborted;
  • Receive Notification Message / No Label Resources;
  • Receive Notification Message / No Route;
  • Receive Notification Message / Loop Detected;
  • Receive Notification Message / Label Resources Available;
  • Detect local label resources have become available;
  • LSR decides to no longer label switch a FEC;
  • Timeout of deferred label request.

The specification of LSR behavior in response to an event has three parts:

  1. Summary. Prose that describes LSR response to the event in overview.

  2. Context. A list of elements referred to by the Algorithm part of the specification. (See 3.)

  3. Algorithm. An algorithm for LSR response to the event.

The summary may omit details of the LSR response, such as bookkeeping action or behavior dependent on the LSR label advertisement mode, control mode, or label retention mode in use. The intent is that the Algorithm fully and unambiguously specify the LSR response.

The algorithms in this section use procedures defined in the MPLS architecture specification [RFC3031] for hop-by-hop routed traffic. These procedures are:

  • Label Distribution procedure, which is performed by a downstream LSR to determine when to distribute a label for a FEC to LDP peers. The architecture defines four Label Distribution procedures:

    . Downstream Unsolicited Independent Control, called PushUnconditional in [RFC3031].

    . Downstream Unsolicited Ordered Control, called PushConditional in [RFC3031].

    . Downstream On Demand Independent Control, called PulledUnconditional in [RFC3031].

    . Downstream On Demand Ordered Control, called PulledConditional in [RFC3031].

  • Label Withdrawal procedure, which is performed by a downstream LSR to determine when to withdraw a FEC label mapping previously distributed to LDP peers. The architecture defines a single Label Withdrawal procedure. Whenever an LSR breaks the binding between a label and a FEC, it MUST withdraw the FEC label mapping from all LDP peers to which it has previously sent the mapping.

  • Label Request procedure, which is performed by an upstream LSR to determine when to explicitly request that a downstream LSR bind a label to a FEC and send it the corresponding label mapping. The architecture defines three Label Request procedures:

    . Request Never. The LSR never requests a label.

    . Request When Needed. The LSR requests a label whenever it needs one.

    . Request On Request. This procedure is used by non-label merging LSRs. The LSR requests a label when it receives a request for one, in addition to whenever it needs one.

  • Label Release procedure, which is performed by an upstream LSR to determine when to release a previously received label mapping for a FEC. The architecture defines two Label Release procedures:

    . Conservative Label retention, called ReleaseOnChange in [RFC3031].

    . Liberal Label retention, called NoReleaseOnChange in [RFC3031].

  • Label Use procedure, which is performed by an LSR to determine when to start using a FEC label for forwarding/switching. The architecture defines three Label Use procedures:

    . Use Immediate. The LSR immediately uses a label received from a FEC next hop for forwarding/switching.

    . Use If Loop Free. The LSR uses a FEC label received from a FEC next hop for forwarding/switching only if it has determined that by doing so it will not cause a forwarding loop.

    . Use If Loop Not Detected. This procedure is the same as Use Immediate unless the LSR has detected a loop in the FEC LSP. Use of the FEC label for forwarding/switching will continue until the next hop for the FEC changes or the loop is no longer detected.

    This version of LDP does not include a loop prevention mechanism; therefore, the procedures below do not make use of the Use If Loop Free procedure.

  • Label No Route procedure (called the NotAvailable procedure in [RFC3031]), which is performed by an upstream LSR to determine how to respond to a No Route notification from a downstream LSR in response to a request for a FEC label mapping. The architecture specification defines two Label No Route procedures:

    . Request Retry. The LSR should issue the label request at a later time.

    . No Request Retry. The LSR should assume that the downstream LSR will provide a label mapping when the downstream LSR has a next hop, and it should not reissue the request.