A.1. Handling Label Distribution Events

This section defines LDP label distribution procedures by specifying an algorithm for each label distribution event. The requirement on an LDP implementation is that its event handling must have the effect specified by the algorithms. That is, an implementation need not follow exactly the steps specified by the algorithms as long as the effect is identical.

The algorithms for handling label distribution events share common actions. The specifications below package these common actions into procedure units. Specifications for these common procedures are in their own Section, "Common Label Distribution Procedures", which follows this.

An implementation would use data structures to store information about protocol activity. This appendix specifies the information to be stored in sufficient detail to describe the algorithms, and assumes the ability to retrieve the information as needed. It does not specify the details of the data structures.

A.1.1. Receive Label Request

Summary:

The response by an LSR to receipt of a FEC label request from an LDP peer may involve one or more of the following actions:

Transmission of a notification message to the requesting LSR indicating why a label mapping for the FEC cannot be provided;
Transmission of a FEC label mapping to the requesting LSR;
Transmission of a FEC label request to the FEC next hop;
Installation of labels for forwarding/switching use by the LSR.

Context:

LSR. The LSR handling the event.
MsgSource. The LDP peer that sent the message.
FEC. The FEC specified in the message.
RAttributes. Attributes received with the message, e.g., Hop Count, Path Vector.
SAttributes. Attributes to be included in the Label Request message, if any, propagated to FEC Next Hop.
StoredHopCount. The hop count, if any, previously recorded for the FEC.

Algorithm:

LRq.1 Execute procedure Check_Received_Attributes (MsgSource, LabelRequest, RAttributes). If Loop Detected, goto LRq.4.

LRq.2 Is there a Next Hop for FEC? If not, goto LRq.5.

LRq.3 Is MsgSource the Next Hop? If not, goto LRq.6.

LRq.4 Execute procedure Send_Notification (MsgSource, Loop Detected). Goto LRq.13

LRq.5 Execute procedure Send_Notification (MsgSource, No Route). Goto LRq.13.

LRq.6 Has LSR previously received a label request for FEC from MsgSource? If not, goto LRq.8. (See Note 1.)

LRq.7 Is the label request a duplicate request? If so, goto LRq.13. (See Note 2.)

LRq.8 Record label request for FEC received from MsgSource and mark it pending.

LRq.9 Perform LSR Label Distribution procedure:

     For Downstream Unsolicited Independent Control OR For
     Downstream On Demand Independent Control

        1. Has LSR previously received and retained a label
           mapping for FEC from Next Hop?
           Is so, set Propagating to IsPropagating.
           If not, set Propagating to NotPropagating.

        2. Execute procedure
           Prepare_Label_Mapping_Attributes(MsgSource, FEC,
           RAttributes, SAttributes, Propagating,
           StoredHopCount).

        3. Execute procedure Send_Label (MsgSource, FEC,
           SAttributes).

        4. Is LSR egress for FEC? OR Has LSR previously received
           and retained a label mapping for FEC from Next Hop?
           If so, goto LRq.11.
           If not, goto LRq.10.

        For Downstream Unsolicited Ordered Control OR For
        Downstream On Demand Ordered Control

        1. Is LSR egress for FEC? OR Has LSR previously received
           and retained a label mapping for FEC from Next Hop?
           (See Note 3.)
           If not, goto LRq.10.

        2. Execute procedure
           Prepare_Label_Mapping_Attributes(MsgSource, FEC,
           RAttributes, SAttributes, IsPropagating,
           StoredHopCount)

        3. Execute procedure Send_Label (MsgSource, FEC,
           SAttributes).
           Goto LRq.11.

LRq.10 Perform LSR Label Request procedure:

  For Request Never

           1. Goto LRq.13.

  For Request When Needed OR
  For Request On Request

        1.  Execute procedure Prepare_Label_Request_Attributes
           (Next Hop, FEC, RAttributes, SAttributes);

        2. Execute procedure Send_Label_Request (Next Hop, FEC,
           SAttributes).
           Goto LRq.13.

LRq.11 Has LSR successfully sent a label for FEC to MsgSource? If not, goto LRq.13. (See Note 4.)

LRq.12 Perform LSR Label Use procedure.

       For Use Immediate OR For Use If Loop Not Detected

        1. Install label sent to MsgSource and label from Next
           Hop (if LSR is not egress) for forwarding/switching
           use.

LRq.13 DONE.

Notes:

  1. In the case where MsgSource is a non-label merging LSR, it
     will send a label request for each upstream LDP peer that
     has requested a label for FEC from it.  The LSR must be able
     to distinguish such requests from a non-label merging
     MsgSource from duplicate label requests.

     The LSR uses the message ID of received Label Request
     messages to detect duplicate requests.  This means that an
     LSR (the upstream peer) may not reuse the message ID used
     for a Label Request until the Label Request transaction has
     completed.

  2. When an LSR sends a label request to a peer, it records that
     the request has been sent and marks it as outstanding.  As
     long as the request is marked outstanding, the LSR SHOULD
     NOT send another request for the same label to the peer.
     Such a second request would be a duplicate.  The
     Send_Label_Request procedure described below obeys this
     rule.

     A duplicate label request is considered a protocol error and
     SHOULD be dropped by the receiving LSR (perhaps with a
     suitable notification returned to MsgSource).

  3. If the LSR is not merge-capable, this test will fail.

  4. The Send_Label procedure may fail due to lack of label
     resources, in which case the LSR SHOULD NOT perform the
     Label Use procedure.

A.1.2. Receive Label Mapping

Summary:

The response by an LSR to receipt of a FEC label mapping from an LDP peer may involve one or more of the following actions:

Transmission of a Label Release message for the FEC label to the LDP peer;
Transmission of Label Mapping messages for the FEC to one or more LDP peers;
Installation of the newly learned label for forwarding/switching use by the LSR.

Context:

LSR. The LSR handling the event.
MsgSource. The LDP peer that sent the message.
FEC. The FEC specified in the message.
Label. The label specified in the message.
PrevAdvLabel. The label for the FEC, if any, previously advertised to an upstream peer. Assuming no label was previously advertised, this is the same label as the one in the Label Mapping message being processed.
StoredHopCount. The hop count previously recorded for the FEC.
RAttributes. Attributes received with the message, e.g., Hop Count, Path Vector.
SAttributes to be included in the Label Mapping message, if any, propagated to upstream peers.

Algorithm:

LMp.1 Does the received label mapping match an outstanding label request for FEC previously sent to MsgSource? If not, goto LMp.3.

LMp.2 Delete record of outstanding FEC label request.

LMp.3 Execute procedure Check_Received_Attributes (MsgSource, LabelMapping, RAttributes). If No Loop Detected, goto LMp.9.

LMp.4 Does the LSR have a previously received label mapping for FEC from MsgSource? (See Note 1.) If not, goto LMp.8. (See Note 2.)

LMp.5 Does the label previously received from MsgSource match Label (i.e., the label received in the message)? (See Note 3.) If not, goto LMp.8. (See Note 4.)

       LMp.6   Delete matching label mapping for FEC previously
       received from MsgSource.

LMp.7 Remove Label from forwarding/switching use. (See Note 5.)

LMp.8 Execute procedure Send_Message (MsgSource, Label Release, FEC, Label, Loop Detected Status code). Goto LMp.33.

LMp.9 Does LSR have a previously received label mapping for FEC from MsgSource for the LSP in question? (See Note 6.) If not, goto LMp.11.

LMp.10 Does the label previously received from MsgSource match Label (i.e., the label received in the message)? (See Note 3.) OR Is the received label mapping in response to a previously outstanding label request sent to MsgSource? (See Note 12.) If so, goto LMp.11.

LMp.10a Is LSR operating in Downstream Unsolicited mode? If so, delete the label mapping for the label previously received from MsgSource and remove it from forwarding/switching use. Execute procedure Send_Message (MsgSource, Label Release, FEC, label previously received from MsgSource).

LMp.11 Determine the Next Hop for FEC.

LMp.12 Is MsgSource the Next Hop for FEC? If so, goto LMp.14.

LMp.13 Perform LSR Label Release procedure:

             For Conservative Label retention:

                1. Goto LMp.32.

             For Liberal Label retention:

                1. Record label mapping for FEC with Label and
                   RAttributes has been received from MsgSource.
                   Goto LMp.33.

LMp.14 Is LSR an ingress for FEC? If not, goto LMp.16.

LMp.15 Install Label for forwarding/switching use.

LMp.16 Record label mapping for FEC with Label and RAttributes has been received from MsgSource.

LMp.17 Iterate through LMp.31 for each Peer. (See Note 7).

LMp.18 Has LSR previously sent a label mapping for FEC to Peer for the LSP in question? (See Note 8.) If so, goto LMp.22.

LMp.19 Is the Downstream Unsolicited Ordered Control Label Distribution procedure being used by LSR? If not, goto LMp.28.

LMp.20 Execute procedure Prepare_Label_Mapping_Attributes (Peer, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount).

LMp.21 Execute procedure Send_Message (Peer, Label Mapping, FEC, PrevAdvLabel, SAttributes). (See Note 13.) Goto LMp.28.

LMp.22 Iterate through LMp.27 for each label mapping for FEC previously sent to Peer.

LMp.23 Are RAttributes in the received label mapping consistent with those previously sent to Peer? If so, continue iteration from LMp.22 for next label mapping. (See Note 9.)

LMp.24 Execute procedure Prepare_Label_Mapping_Attributes (Peer, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount).

LMp.25 Execute procedure Send_Message (Peer, Label Mapping, FEC, PrevAdvLabel, SAttributes). (See Note 10.)

LMp.26 Update record of label mapping for FEC previously sent to Peer to include the new attributes sent.

LMp.27 End iteration from LMp.22.

LMp.28 Does LSR have any label requests for FEC from Peer marked as pending? If not, goto LMp.30.

LMp.29 Perform LSR Label Distribution procedure:

     For Downstream Unsolicited Independent Control OR For
     Downstream Unsolicited Ordered Control

        1. Execute procedure
           Prepare_Label_Mapping_Attributes (Peer, FEC,
           RAttributes, SAttributes, IsPropagating,
           UnknownHopCount).

        2. Execute procedure Send_Label (Peer, FEC, SAttributes).
           If the procedure fails, continue iteration for next
           Peer at LMp.17.

        3. If no pending requests exist for Peer, goto LMp.30.
           (See Note 11.)

     For Downstream On Demand Independent Control OR For
     Downstream On Demand Ordered Control

        1. Iterate through Step 5 for each pending label request
           for FEC from Peer marked as pending.

        2. Execute procedure
           Prepare_Label_Mapping_Attributes (Peer, FEC,
           RAttributes, SAttributes, IsPropagating,
           UnknownHopCount)

        3. Execute procedure Send_Label (Peer, FEC, SAttributes).
           If the procedure fails, continue iteration for next
           Peer at LMp.17.

        4. Delete record of pending request.

        5. End iteration from Step 1.

        6. Goto LMp.30.

LMp.30 Perform LSR Label Use procedure:

     For Use Immediate OR For Use If Loop Not Detected

        1. Iterate through Step 3 for each label mapping for FEC
           previously sent to Peer.

        2. Install label received and label sent to Peer for
           forwarding/switching use.

        3. End iteration from Step 1.

        4. Goto LMp.31.

LMp.31 End iteration from LMp.17. Go to LMp.33.

LMp.32 Execute procedure Send_Message (MsgSource, Label Release, FEC, Label).

LMp.33 DONE.

Notes:

If the LSR is merging, there should be at most 1 received mapping for the FEC for the LSP in question. In the non- merging case, there could be multiple received mappings for the FEC for the LSP in question.
If the LSR has detected a loop and it has not previously received a label mapping from MsgSource for the FEC, it simply releases the label.
Does the Label received in the message match any of the 1 or more label mappings identified in the previous step (LMp.4 or LMp.9)?
An unsolicited mapping with a different label from the same peer would be an attempt to establish multipath label switching, which is not supported in this version of LDP.
If the Label is not in forwarding/switching use, LMp.7 has no effect.
If the received label mapping message matched an outstanding label request in LMp.1, then (by definition) the LSR has not previously received a label mapping for FEC for the LSP in question. If the LSR is merging upstream labels for the LSP in question, there should be at most 1 received mapping. In the non-merging case, there could be multiple received label mappings for the same FEC, one for each resulting LSP.
The LMp.17 iteration includes MsgSource in order to handle the case where the LSR is operating in Downstream Unsolicited Ordered Control mode. Ordered Control prevents the LSR from advertising a label for the FEC until it has received a label mapping from its next hop (MsgSource) for the FEC.
If the LSR is merging the LSP, it may have previously sent label mappings for the FEC LSP to one or more peers. If the

LSR is not merging, it may have sent a label mapping for the LSP in question to at most one LSR.
The Loop Detection Path Vector attribute is considered in this check. If the received RAttributes include a Path Vector and no Path Vector had been previously sent to the Peer, or if the received Path Vector is inconsistent with the Path Vector previously sent to the Peer, then the attributes are considered to be inconsistent. Note that an LSR is not required to store a received Path Vector after it propagates the Path Vector in a mapping message. If an LSR does not store the Path Vector, it has no way to check the consistency of a newly received Path Vector. This means that whenever such an LSR receives a mapping message carrying a Path Vector it must always propagate the Path Vector.
LMp.22 through LMp.27 deal with a situation that can arise when the LSR is using independent control and it receives a mapping from the downstream peer after it has sent a mapping to an upstream peer. In this situation, the LSR needs to propagate any changed attributes, such as Hop Count, upstream. If Loop Detection is configured on, the propagated attributes must include the Path Vector.
An LSR operating in Downstream Unsolicited mode MUST process any Label Request messages it receives. If there are pending label requests, fall through into the Downstream on Demand procedures in order to satisfy the pending requests.
As determined by step LMp.1.
An LSR operating in Ordered Control mode may choose to skip at this stage the peer from which it received the advertisement that caused it to generate the label-map message. Doing so will in effect provide a form of split-horizon.

A.1.3. Receive Label Abort Request

Summary:

When an LSR receives a Label Abort Request message from a peer, it checks whether it has already responded to the label request in question. If it has, it silently ignores the message. If it has not, it sends the peer a Label Request Aborted Notification. In addition, if it has a label request outstanding for the LSP in question to a downstream peer, it sends a Label Abort Request to the downstream peer to abort the LSP.

Context:

LSR. The LSR handling the event.
MsgSource. The LDP peer that sent the message.
FEC. The FEC specified in the message.
RequestMessageID. The message ID of the label request message to be aborted.
Next Hop. The next hop for the FEC.

Algorithm:

LAbR.1 Does the message match a previously received Label Request message from MsgSource? (See Note 1.) If not, goto LAbR.12.

LAbR.2 Has LSR responded to the previously received label request? If so, goto LAbR.12.

LAbR.3 Execute procedure Send_Message (MsgSource, Notification, Label Request Aborted, TLV), where TLV is the Label Request Message ID TLV received in the Label Abort Request message.

LAbR.4 Does LSR have a Label Request message outstanding for FEC? If so, goto LAbR.7.

LAbR.5 Does LSR have a label mapping for FEC? If not, goto LAbR.11.

LAbR.6 Generate Event: Received Label Release message for FEC from MsgSource. (See Note 2.) Goto LAbR.11.

LAbR.7 Is LSR merging the LSP for FEC? If not, goto LAbR.9.

LAbR.8 Are there outstanding label requests for this FEC? If so, goto LAbR.11.

LAbR.9 Execute procedure Send_Message (Next Hop, Label Abort Request, FEC, TLV), where TLV is a Label Request message ID TLV containing the Message ID used by the LSR in the outstanding Label Request message.

LAbR.10 Record that a label abort request for FEC is pending.

LAbR.11 Delete record of label request for FEC from MsgSource.

LAbR.12 DONE.

Notes:

LSR uses FEC and the Label Request message ID TLV carried by the label abort request to locate its record (if any) for the previously received label request from MsgSource.
If LSR has received a label mapping from NextHop, it should behave as if it had advertised a label mapping to MsgSource and MsgSource has released it.

A.1.4. Receive Label Release

Summary:

When an LSR receives a Label Release message for a FEC from a peer, it checks whether other peers hold the released label. If none do, the LSR removes the label from forwarding/switching use, if it has not already done so, and if the LSR holds a label mapping from the FEC next hop, it releases the label mapping.

Context:

LSR. The LSR handling the event.
MsgSource. The LDP peer that sent the message.
Label. The label specified in the message.
FEC. The FEC specified in the message.

Algorithm:

LRl.1 Does FEC match a known FEC? If not, goto LRl.14.

LRl.2 Remove MsgSource from record of peers that hold Label for FEC. (See Note 1.)

LRl.3 Does message match an outstanding label withdraw for FEC previously sent to MsgSource? If not, goto LRl.5

LRl.4 Delete record of outstanding label withdraw for FEC previously sent to MsgSource.

LRl.5 Is LSR merging labels for this FEC? If not, goto LRl.7. (See Note 2.)

LRl.6 Does LSR have outstanding label advertisements for this FEC? If so, goto LRl.11.

LRl.7 Is LSR egress for the FEC? If so, goto LRl.11.

LRl.8 Is there a Next Hop for FEC? AND Does LSR have a previously received label mapping for FEC from Next Hop? If not, goto LRl.11.

LRl.9 Is LSR configured to propagate releases? If not, goto LRl.11. (See Note 3.)

LRl.10 Execute procedure Send_Message (Next Hop, Label Release, FEC, Label from Next Hop).

LRl.11 Remove Label from forwarding/switching use for traffic from MsgSource.

LRl.12 Do any peers still hold Label for FEC? If so, goto LRl.14.

LRl.13 Free the Label.

LRl.14 DONE.

Notes:

If LSR is using Downstream Unsolicited label distribution, it SHOULD NOT re-advertise a label mapping for FEC to MsgSource until MsgSource requests it.
LRl.5 through LRl.9 deal with determining whether where the LSR should propagate the Label Release to a downstream peer (LRl.9).
If LRl.9 is reached, no upstream LSR holds a label for the FEC, and the LSR holds a label for the FEC from the FEC Next Hop. The LSR could propagate the Label Release to the Next Hop. By propagating the Label Release, the LSR releases a potentially scarce label resource. In doing so, it also increases the

latency for re-establishing the LSP should MsgSource or some other upstream LSR send it a new Label Request for FEC.

Whether or not to propagate the release is not a protocol issue. Label distribution will operate properly whether or not the release is propagated. The decision to propagate or not should take into consideration factors such as, whether labels are a scarce resource in the operating environment, the importance of keeping LSP setup latency low by keeping the amount of signaling required small, and whether LSP setup is ingress-controlled or egress-controlled in the operating environment.

A.1.5. Receive Label Withdraw

Summary:

When an LSR receives a Label Withdraw message for a FEC from an LDP peer, it responds with a Label Release message and it removes the label from any forwarding/switching use. If Ordered Control is in use, the LSR sends a Label Withdraw message to each LDP peer to which it had previously sent a label mapping for the FEC. If the LSR is using Downstream on Demand label advertisement with independent control, it then acts as if it had just recognized the FEC.

Context:

LSR. The LSR handling the event.
MsgSource. The LDP peer that sent the message.
Label. The label specified in the message.
FEC. The FEC specified in the message.

Algorithm:

LWd.1 Remove Label from forwarding/switching use. (See Note 1.)

LWd.2 Execute procedure Send_Message (MsgSource, Label Release, FEC, Label).

LWd.3 Has LSR previously received and retained a matching label mapping for FEC from MsgSource? If not, goto LWd.13.

LWd.4 Delete matching label mapping for FEC previously received from MsgSource.

LWd.5 Is LSR using Ordered Control? If so, goto LWd.8.

LWd.6 Is MsgSource using Downstream On Demand label advertisement? If not, goto LWd.13.

LWd.7 Generate Event: Recognize New FEC for FEC. Goto LWd.13. (See Note 2.)

LWd.8 Iterate through LWd.12 for each Peer, other than MsgSource.

LWd.9 Has LSR previously sent a label mapping for FEC to Peer? If not, continue iteration for next Peer at LWd.8.

LWd.10 Does the label previously sent to Peer "map" to the withdrawn Label? If not, continue iteration for next Peer at LWd.8. (See Note 3.)

LWd.11 Execute procedure Send_Label_Withdraw (Peer, FEC, Label previously sent to Peer).

LWd.12 End iteration from LWd.8.

LWd.13 DONE.

Notes:

If the Label is not in forwarding/switching use, LWd.1 has no effect.
LWd.7 handles the case where the LSR is using Downstream On Demand label distribution with independent control. In this situation, the LSR should send a label request to the FEC next hop as if it had just recognized the FEC.
LWd.10 handles both label merging (one or more incoming labels map to the same outgoing label) and no label merging (one label maps to the outgoing label) cases.

A.1.6. Recognize New FEC

Summary:

The response by an LSR to learning a new FEC via the routing table may involve one or more of the following actions:

Transmission of label mappings for the FEC to one or more LDP peers;
Transmission of a label request for the FEC to the FEC next hop;
Any of the actions that can occur when the LSR receives a label mapping for the FEC from the FEC next hop.

Context:

LSR. The LSR handling the event.
FEC. The newly recognized FEC.
Next Hop. The next hop for the FEC.
InitAttributes. Attributes to be associated with the new FEC. (See Note 1.)
SAttributes. Attributes to be included in Label Mapping or Label Request messages, if any, sent to peers.
StoredHopCount. Hop count associated with FEC label mapping, if any, previously received from Next Hop.

Algorithm:

FEC.1 Perform LSR Label Distribution procedure:

     For Downstream Unsolicited Independent Control

        1. Iterate through 5 for each Peer.

        2. Has LSR previously received and retained a label
           mapping for FEC from Next Hop?
           If so, set Propagating to IsPropagating.
           If not, set Propagating to NotPropagating.

        3. Execute procedure Prepare_Label_Mapping_Attributes
           (Peer, FEC, InitAttributes, SAttributes, Propagating,
           Unknown hop count(0)).

        4. Execute procedure Send_Label (Peer, FEC, SAttributes).

        5. End iteration from 1.
           Goto FEC.2.

     For Downstream Unsolicited Ordered Control

        1. Iterate through 5 for each Peer.

        2. Is LSR egress for the FEC? OR Has LSR previously
           received and retained a label mapping for FEC from
           Next Hop?
           If not, continue iteration for next Peer.

        3. Execute procedure Prepare_Label_Mapping_Attributes
           (Peer, FEC, InitAttributes, SAttributes, Propagating,
           StoredHopCount).

        4. Execute procedure Send_Label (Peer, FEC, SAttributes).

        5. End iteration from 1.
           Goto FEC.2.

     For Downstream On Demand Independent Control OR
     For Downstream On Demand Ordered Control

        1. Goto FEC.2.  (See Note 2.)

FEC.2 Has LSR previously received and retained a label mapping for FEC from Next Hop? If so, goto FEC.5

FEC.3 Is Next Hop an LDP peer? If not, Goto FEC.6

FEC.4 Perform LSR Label Request procedure:

     For Request Never

        1. Goto FEC.6

     For Request When Needed OR
     For Request On Request

        1. Execute procedure
           Prepare_Label_Request_Attributes (Next Hop, FEC,
           InitAttributes, SAttributes);

        2. Execute procedure Send_Label_Request (Next Hop, FEC,
           SAttributes).
           Goto FEC.6.

FEC.5 Generate Event: Received Label Mapping from Next Hop. (See Note 3.)

FEC.6 DONE.

Notes:

An example of an attribute that might be part of InitAttributes is one that specifies desired LSP characteristics, such as Class of Service (CoS). (Note that while the current version of LDP does not specify a CoS attribute, LDP extensions may.)

The means by which FEC InitAttributes, if any, are specified is beyond the scope of LDP. Note that the InitAttributes will not include a known Hop Count or a Path Vector.
An LSR using Downstream On Demand label distribution would send a label only if it had a previously received label request marked as pending. The LSR would have no such pending requests because it responds to any label request for an unknown FEC by sending the requesting LSR a No Route notification and discarding the label request; see LRq.3
If the LSR has a label for the FEC from the Next Hop, it should behave as if it had just received the label from the Next Hop. This occurs in the case of Liberal Label retention mode.

A.1.7. Detect Change in FEC Next Hop

Summary:

The response by an LSR to a change in the next hop for a FEC may involve one or more of the following actions:

Removal of the label from the FEC's old next hop from forwarding/switching use;
Transmission of label mapping messages for the FEC to one or more LDP peers;
Transmission of a label request to the FEC's new next hop;
Any of the actions that can occur when the LSR receives a label mapping from the FEC's new next hop.

Context:

LSR. The LSR handling the event.
FEC. The FEC whose next hop changed.
New Next Hop. The current next hop for the FEC.
Old Next Hop. The previous next hop for the FEC.
OldLabel. Label, if any, previously received from Old Next Hop.
CurAttributes. The attributes, if any, currently associated with the FEC.
SAttributes. Attributes to be included in the Label Request message, if any, sent to New Next Hop.

Algorithm:

NH.1 Has LSR previously received and retained a label mapping for FEC from Old Next Hop? If not, goto NH.6.

NH.2 Remove label from forwarding/switching use. (See Note 1.)

NH.3 Is LSR using Liberal Label retention? If so, goto NH.6.

NH.4 Execute procedure Send_Message (Old Next Hop, Label Release, OldLabel).

NH.5 Delete label mapping for FEC previously received from Old Next Hop.

NH.6 Does LSR have a label request pending with Old Next Hop? If not, goto NH.10.

NH.7 Is LSR using Conservative Label retention? If not, goto NH.10.

NH.8 Execute procedure Send_Message (Old Next Hop, Label Abort Request, FEC, TLV), where TLV is a Label Request Message ID TLV that carries the message ID of the pending label request.

NH.9 Record that a label abort request is pending for FEC with Old Next Hop.

NH.10 Is there a New Next Hop for FEC? If not, goto NH.16.

NH.11 Has LSR previously received and retained a label mapping for FEC from New Next Hop? If not, goto NH.13.

NH.12 Generate Event: Received Label Mapping from New Next Hop. Goto NH.20. (See Note 2.)

NH.13 Is LSR using Downstream on Demand advertisement? OR Is Next Hop using Downstream on Demand advertisement? OR Is LSR using Conservative Label retention? (See Note 3.) If so, goto NH.14. If not, goto NH.20.

NH.14 Execute procedure Prepare_Label_Request_Attributes (Next Hop, FEC, CurAttributes, SAttributes).

NH.15 Execute procedure Send_Label_Request (New Next Hop, FEC, SAttributes). (See Note 4.) Goto NH.20.

NH.16 Iterate through NH.19 for each Peer.

NH.17 Has LSR previously sent a label mapping for FEC to Peer? If not, continue iteration for next Peer at NH.16.

NH.18 Execute procedure Send_Label_Withdraw (Peer, FEC, Label previously sent to Peer).

NH.19 End iteration from NH.16.

NH.20 DONE.

Notes:

If the Label is not in forwarding/switching use, NH.2 has no effect.
If the LSR has a label for the FEC from the New Next Hop, it should behave as if it had just received the label from the New Next Hop.
The purpose of the check on label retention mode is to avoid a race with steps LMp.12-LMp.13 of the procedure for handling a Label Mapping message where the LSR operating in Conservative Label retention mode may have released a label mapping received from the New Next Hop before it detected that the FEC next hop had changed.
Regardless of the Label Request procedure in use by the LSR, it MUST send a label request if the conditions in NH.13 hold. Therefore, it executes the Send_Label_Request procedure directly rather than perform the LSR Label Request procedure.

A.1.8. Receive Notification / Label Request Aborted

Summary:

When an LSR receives a Label Request Aborted notification from an LDP peer, it records that the corresponding label request transaction, if any, has completed.

Context:

LSR. The LSR handling the event.
FEC. The FEC for which a label was requested.
RequestMessageID. The message ID of the label request message to be aborted.
MsgSource. The LDP peer that sent the Notification message.

Algorithm:

LRqA.1 Does the notification correspond to an outstanding label request abort for FEC? (See Note 1.) If not, goto LRqA.3.

LRqA.2 Record that the label request for FEC has been aborted.

LRqA.3 DONE.

Note:

The LSR uses the FEC and RequestMessageID to locate its record, if any, of the outstanding label request abort.

A.1.9. Receive Notification / No Label Resources

Summary:

When an LSR receives a No Label Resources notification from an LDP peer, it stops sending label request messages to the peer until it receives a Label Resources Available Notification from the peer.

Context:

LSR. The LSR handling the event.
FEC. The FEC for which a label was requested.
MsgSource. The LDP peer that sent the Notification message.

Algorithm:

NoRes.1 Delete record of outstanding label request for FEC sent to MsgSource.

NoRes.2 Record that label mapping for FEC from MsgSource is needed but that no label resources are available.

NoRes.3 Set status record indicating it is not OK to send label requests to MsgSource.

NoRes.4 DONE.

A.1.10. Receive Notification / No Route

Summary:

When an LSR receives a No Route notification from an LDP peer in response to a Label Request message, the Label No Route procedure in use dictates its response. The LSR either will take no further action, or it will defer the label request by starting a timer and send another Label Request message to the peer when the timer later expires.

Context:

LSR. The LSR handling the event.
FEC. The FEC for which a label was requested.
Attributes. The attributes associated with the label request.
MsgSource. The LDP peer that sent the Notification message.

Algorithm:

NoNH.1 Delete record of outstanding label request for FEC sent to MsgSource.

NoNH.2 Perform LSR Label No Route procedure.

     For Request No Retry

        1. Goto NoNH.3.

     For Request Retry

        1. Record deferred label request for FEC and Attributes
           to be sent to MsgSource.

        2. Start timeout.  Goto NoNH.3.

NoNH.3 DONE.

A.1.11. Receive Notification / Loop Detected

Summary:

When an LSR receives a Loop Detected Status Code from an LDP peer in response to a Label Request message or a Label Mapping message, it behaves as if it had received a No Route notification.

Context:

See "Receive Notification / No Route".

Algorithm:

See "Receive Notification / No Route".

Note:

When the Loop Detected notification is in response to a Label Request message, it arrives in a Status Code TLV in a Notification message. When it is in response to a Label Mapping message, it arrives in a Status Code TLV in a Label Release message.

A.1.12. Receive Notification / Label Resources Available

Summary:

When an LSR receives a Label Resources Available notification from an LDP peer, it resumes sending label requests to the peer.

Context:

LSR. The LSR handling the event.
MsgSource. The LDP peer that sent the Notification message.
SAttributes. Attributes stored with the postponed Label Request message.

Algorithm:

Res.1 Set status record indicating it is OK to send label requests to MsgSource.

Res.2 Iterate through Res.6 for each record of a FEC label mapping needed from MsgSource for which no label resources are available.

Res.3 Is MsgSource the next hop for FEC? If not, goto Res.5.

Res.4 Execute procedure Send_Label_Request (MsgSource, FEC, SAttributes). If the procedure fails, terminate iteration.

Res.5 Delete record that no resources are available for a label mapping for FEC needed from MsgSource.

Res.6 End iteration from Res.2.

Res.7 DONE.

A.1.13. Detect Local Label Resources Have Become Available

Summary:

After an LSR has sent a No Label Resources notification to an LDP peer, when label resources later become available it sends a Label Resources Available notification to each such peer.

Context:

LSR. The LSR handling the event.
Attributes. Attributes stored with the postponed Label Mapping message.

Algorithm:

ResA.1 Iterate through ResA.4 for each Peer to which LSR has previously sent a No Label Resources notification.

ResA.2 Execute procedure Send_Notification (Peer, Label Resources Available).

ResA.3 Delete record that No Label Resources notification was previously sent to Peer.

ResA.4 End iteration from ResA.1.

ResA.5 Iterate through ResA.8 for each record of a label mapping needed for FEC for Peer but no-label-resources. (See Note 1.)

ResA.6 Execute procedure Send_Label (Peer, FEC, Attributes). If the procedure fails, terminate iteration.

ResA.7 Clear record of FEC label mapping needed for peer but no- label-resources.

ResA.8 End iteration from ResA.5

ResA.9 DONE.

Note:

Iteration ResA.5 through ResA.8 handles the situation where the LSR is using Downstream Unsolicited label distribution and was previously unable to allocate a label for a FEC.

A.1.14. LSR Decides to No Longer Label Switch a FEC

Summary:

An LSR may unilaterally decide to no longer label switch a FEC for an LDP peer. An LSR that does so MUST send a Label Withdraw message for the FEC to the peer.

Context:

Peer. The peer.
FEC. The FEC.
PrevAdvLabel. The label for the FEC previously advertised to the Peer.

Algorithm:

NoLS.1 Execute procedure Send_Label_Withdraw (Peer, FEC, PrevAdvLabel). (See Note 1.)

NoLS.2 DONE.

Note:

The LSR may remove the label from forwarding/switching use as part of this event or as part of processing the Label Release from the peer in response to the label withdraw. If the LSR doesn't wait for the Label Release message from the peer, it SHOULD NOT reuse the label until it receives the Label Release.

A.1.15. Timeout of Deferred Label Request

Summary:

Label requests are deferred in response to No Route and Loop Detected notifications. When a deferred FEC label request for a peer times out, the LSR sends the label request.

Context:

LSR. The LSR handling the event.
FEC. The FEC associated with the timeout event.
Peer. The LDP peer associated with the timeout event.
Attributes. Attributes stored with the deferred Label Request message.

Algorithm:

TO.1 Retrieve the record of the deferred label request.

TO.2 Is Peer the next hop for FEC? If not, goto TO.4.

TO.3 Execute procedure Send_Label_Request (Peer, FEC).

TO.4 DONE.

A.1.1. Receive Label Request​

A.1.2. Receive Label Mapping​

A.1.3. Receive Label Abort Request​

A.1.4. Receive Label Release​

A.1.5. Receive Label Withdraw​

A.1.6. Recognize New FEC​

A.1.7. Detect Change in FEC Next Hop​

A.1.8. Receive Notification / Label Request Aborted​

A.1.9. Receive Notification / No Label Resources​

A.1.10. Receive Notification / No Route​

A.1.11. Receive Notification / Loop Detected​

A.1.12. Receive Notification / Label Resources Available​

A.1.13. Detect Local Label Resources Have Become Available​

A.1.14. LSR Decides to No Longer Label Switch a FEC​

A.1.15. Timeout of Deferred Label Request​

A.1.1. Receive Label Request

A.1.2. Receive Label Mapping

A.1.3. Receive Label Abort Request

A.1.4. Receive Label Release

A.1.5. Receive Label Withdraw

A.1.6. Recognize New FEC

A.1.7. Detect Change in FEC Next Hop

A.1.8. Receive Notification / Label Request Aborted

A.1.9. Receive Notification / No Label Resources

A.1.10. Receive Notification / No Route

A.1.11. Receive Notification / Loop Detected

A.1.12. Receive Notification / Label Resources Available

A.1.13. Detect Local Label Resources Have Become Available

A.1.14. LSR Decides to No Longer Label Switch a FEC

A.1.15. Timeout of Deferred Label Request