previously received label request from MsgSource.
2. 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 Remove MsgSource from record of peers that hold Label for
FEC. (See Note 1.)
LRl.2 Does message match an outstanding label withdraw for FEC
previously sent to MsgSource?
If not, goto LRl.4
LRl.3 Delete record of outstanding label withdraw for FEC
previously sent to MsgSource.
LRl.4 Is LSR merging labels for this FEC?
If not, goto LRl.6. (See Note 2.)
LRl.5 Has LSR previously advertised a label for this FEC to
other peers?
If so, goto LRl.10.
LRl.6 Is LSR egress for the FEC?
If so, goto LRl.10
LRl.7 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.10.
LRl.8 Is LSR configured to propagate releases?
If not, goto LRl.10. (See Note 3.)
LRl.9 Execute procedure Send_Message (Next Hop, Label Release,
FEC, Label from Next Hop).
LRl.10 Remove Label from forwarding/switching use for traffic
from MsgSource.
LRl.11 Do any peers still hold Label for FEC?
If so, goto LRl.13.
LRl.12 Free the Label.
LRl.13 DONE.
Notes:
1. If LSR is using Downstream Unsolicited label distribution, it
should not re-advertise a label mapping for FEC to MsgSource
until MsgSource requests it.
2. LRl.4 through LRl.8 deal with determining whether where the LSR
should propagate the label release to a downstream peer
(LRl.9).
3. If LRl.8 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; 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:
1. If Label is not in forwarding/switching use, LWd.1 has no
effect.
2. 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.
3. 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:
1. An example of an attribute that might be part of InitAttributes
is one which 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.
2. 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
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 Label 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 a label abort request is pending for FEC with Old
Next Hop.
NH.10 Is there a New Next Hop for the 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:
1. If Label is not in forwarding/switching use, NH.2 has no
effect.
2. 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.
3. 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 the FEC next hop had
changed.
4. Regardless of the Label Request procedure in use by the LSR, it
must send a label request if the conditions in NH.8 hold.
Therefore it executes the Send_Label_Request procedure directly
rather than perform 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
Notes:
1. 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 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"
Notes:
1. 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 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 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.
Notes:
1. 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 FEC previously advertised to Peer.
Algorithm:
NoLS.1 Execute procedure Send_Label_Withdraw (Peer, FEC,
PrevAdvLabel). (See Note 1.)
NoLS.2 DONE.
Notes:
1. 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.
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 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.2. Common Label Distribution Procedures
This section specifies utility procedures used by the algorithms
that handle label distribution events.
A.2.1. Send_Label
Summary:
The Send_Label procedure allocates a label for a FEC for an LDP
peer, if possible, and sends a label mapping for the FEC to the
peer. If the LSR is unable to allocate the label and if it has a
pending label request from the peer, it sends the LDP peer a No
Label Resources notification.
Parameters:
- Peer. The LDP peer to which the label mapping is to be sent.
- FEC. The FEC for which a label mapping is to be sent.
- Attributes. The attributes to be included with the label
mapping.
Additional Context:
- LSR. The LSR executing the procedure.
- Label. The label allocated and sent to Peer.
Algorithm:
SL.1 Does LSR have a label to allocate?
If not, goto SL.9.
SL.2 Allocate Label and bind it to the FEC.
SL.3 Install Label for forwarding/switching use.
SL.4 Execute procedure Send_Message (Peer, Label Mapping, FEC,
Label, Attributes).
SL.5 Record label mapping for FEC with Label and Attributes has
been sent to Peer.
SL.6 Does LSR have a record of a FEC label request from Peer
marked as pending?
If not, goto SL.8.
SL.7 Delete record of pending label request for FEC from Peer.
SL.8 Return success.
SL.9 Does LSR have a label request for FEC from Peer marked as
pending?
If not, goto SL.13.
SL.10 Execute procedure Send_Notification (Peer, No Label
Resources).
SL.11 Delete record of pending label request for FEC from Peer.
SL.12 Record No Label Resources notification has been sent to
Peer.
Goto SL.14.
SL.13 Record label mapping needed for FEC and Attributes for
Peer, but no-label-resources. (See Note 1.)
SL.14 Return failure.
Notes:
1. SL.13 handles the case of Downstream Unsolicited label
distribution when the LSR is unable to allocate a label for a
FEC to send to a Peer.
A.2.2. Send_Label_Request
Summary:
An LSR uses the Send_Label_Request procedure to send a request for
a label for a FEC to an LDP peer if currently permitted to do so.
Parameters:
- Peer. The LDP peer to which the label request is to be sent.
- FEC. The FEC for which a label request is to be sent.
- Attributes. Attributes to be included in the label request.
E.g., Hop Count, Path Vector.
Additional Context:
- LSR. The LSR executing the procedure.
Algorithm:
SLRq.1 Has a label request for FEC previously been sent to Peer
and is it marked as outstanding?
If so, Return success. (See Note 1.)
SLRq.2 Is status record indicating it is OK to send label
requests to Peer set?
If not, goto SLRq.6
SLRq.3 Execute procedure Send_Message (Peer, Label Request, FEC,
Attributes).
SLRq.4 Record label request for FEC has been sent to Peer and
mark it as outstanding.
SLRq.5 Return success.
SLRq.6 Postpone the label request by recording label mapping for
FEC and Attributes from Peer is needed but that no label
resources are available.
SLRq.7 Return failure.
Notes:
1. If the LSR is a non-merging LSR it must distinguish between
attempts to send label requests for a FEC triggered by
different upstream LDP peers from duplicate requests. This
procedure will not send a duplicate label request.
A.2.3. Send_Label_Withdraw
Summary:
An LSR uses the Send_Label_Withdraw procedure to withdraw a label
for a FEC from an LDP peer. To do this the LSR sends a Label
Withdraw message to the peer.
Parameters:
- Peer. The LDP peer to which the label withdraw is to be sent.
- FEC. The FEC for which a label is being withdrawn.
- Label. The label being withdrawn
Additional Context:
- LSR. The LSR executing the procedure.
Algorithm:
SWd.1 Execute procedure Send_Message (Peer, Label Withdraw, FEC,
Label)
SWd.2 Record label withdraw for FEC has been sent to Peer and
mark it as outstanding.
A.2.4. Send_Notification
Summary:
An LSR uses the Send_Notification procedure to send an LDP peer a
notification message.
Parameters:
- Peer. The LDP peer to which the Notification message is to be
sent.
- Status. Status code to be included in the Notification
message.
Additional Context:
None.
Algorithm:
SNt.1 Execute procedure Send_Message (Peer, Notification, Status)
A.2.5. Send_Message
Summary:
An LSR uses the Send_Message procedure to send an LDP peer an LDP
message.
Parameters:
- Peer. The LDP peer to which the message is to be sent.
- Message Type. The type of message to be sent.
- Additional message contents . . . .
Additional Context:
None.
Algorithm:
This procedure is the means by which an LSR sends an LDP message
of the specified type to the specified LDP peer.
A.2.6. Check_Received_Attributes
Summary:
Check the attributes received in a Label Mapping or Label Request
message. If the attributes include a Hop Count or Path Vector,
perform a loop detection check. If a loop is detected, cause a
Loop Detected Notification message to be sent to MsgSource.
Parameters:
- MsgSource. The LDP peer that sent the message.
- MsgType. The type of message received.
- RAttributes. The attributes in the message.
Additional Context:
- LSR Id. The unique LSR Id of this LSR.
- Hop Count. The Hop Count, if any, in the received attributes.
- Path Vector. The Path Vector, if any in the received
attributes.
Algorithm:
CRa.1 Do RAttributes include Hop Count?
If not, goto CRa.5.
CRa.2 Does Hop Count exceed Max allowable hop count?
If so, goto CRa.6.
CRa.3 Do RAttributes include Path Vector?
If not, goto CRa.5.
CRa.4 Does Path Vector Include LSR Id? OR
Does length of Path Vector exceed Max allowable length?
If so, goto CRa.6
CRa.5 Return No Loop Detected.
CRa.6 Is MsgType LabelMapping?
If so, goto CRa.8. (See Note 1.)
CRa.7 Execute procedure Send_Notification (MsgSource, Loop
Detected)
CRa.8 Return Loop Detected.
CRa.9 DONE
Notes:
1. When the attributes being checked were received in a Label
Mapping message, the LSR sends the Loop Detected notification
in a Status Code TLV in a Label Release message. (See Section
"Receive Label Mapping").
A.2.7. Prepare_Label_Request_Attributes
Summary:
This procedure is used whenever a Label Request is to be sent to a
Peer to compute the Hop Count and Path Vector, if any, to include
in the message.
Parameters:
- Peer. The LDP peer to which the message is to be sent.
- FEC. The FEC for which a label request is to be sent.
- RAttributes. The attributes this LSR associates with the LSP
for FEC.
- SAttributes. The attributes to be included in the Label
Request message.
Additional Context:
- LSR Id. The unique LSR Id of this LSR.
Algorithm:
PRqA.1 Is Hop Count required for this Peer (see Note 1.) ? OR
Do RAttributes include a Hop Count? OR
Is Loop Detection configured on LSR?
If not, goto PRqA.14.
PRqA.2 Is LSR ingress for FEC?
If not, goto PRqA.6.
PRqA.3 Include Hop Count of 1 in SAttributes.
PRqA.4 Is Loop Detection configured on LSR?
If not, goto PRqA.14.
PRqA.5 Is LSR merge-capable?
If so, goto PRqA.14.
If not, goto PRqA.13.
PRqA.6 Do RAttributes include a Hop Count?
If not, goto PRqA.8.
PRqA.7 Increment RAttributes Hop Count and copy the resulting Hop
Count to SAttributes. (See Note 2.)
Goto PRqA.9.
PRqA.8 Include Hop Count of unknown (0) in SAttributes.
PRqA.9 Is Loop Detection configured on LSR?
If not, goto PRqA.14.
PRqA.10 Do RAttributes have a Path Vector?
If so, goto PRqA.12.
PRqA.11 Is LSR merge-capable?
If so, goto PRqA.14.
If not, goto PRqA.13.
PRqA.12 Add LSR Id to beginning of Path Vector from RAttributes
and copy the resulting Path Vector into SAttributes.
Goto PRqA.14.
PRqA.13 Include Path Vector of length 1 containing LSR Id in
SAttributes.
PRqA.14 DONE.
Notes:
1. The link with Peer may require that Hop Count be included in
Label Request messages; for example, see [RFC3035] and
[RFC3034].
2. For hop count arithmetic, unknown + 1 = unknown.
A.2.8. Prepare_Label_Mapping_Attributes
Summary:
This procedure is used whenever a Label Mapping is to be sent to a
Peer to compute the Hop Count and Path Vector, if any, to include
in the message.
Parameters:
- Peer. The LDP peer to which the message is to be sent.
- FEC. The FEC for which a label request is to be sent.
- RAttributes. The attributes this LSR associates with the LSP
for FEC.
- SAttributes. The attributes to be included in the Label
Mapping message.
- IsPropagating. The LSR is sending the Label Mapping message to
propagate one received from the FEC next hop.
- PrevHopCount. The Hop Count, if any, this LSR associates with
the LSP for the FEC.
Additional Context:
- LSR Id. The unique LSR Id of this LSR.
Algorithm:
PMpA.1 Is Hop Count required for this Peer (see Note 1.) ? OR
Do RAttributes include a Hop Count? OR
Is Loop Detection configured on LSR?
If not, goto PMpA.21.
PMpA.2 Is LSR egress for FEC?
If not, goto PMpA.4.
PMpA.3 Include Hop Count of 1 in SAttributes. Goto PMpA.21.
PMpA.4 Do RAttributes have a Hop Count?
If not, goto PMpA.8.
PMpA.5 Is LSR member of edge set for an LSR domain whose LSRs do
not perform TTL decrement AND
Is Peer in that domain (See Note 2.).
If not, goto PMpA.7.
PMpA.6 Include Hop Count of 1 in SAttributes. Goto PMpA.9.
PMpA.7 Increment RAttributes Hop Count and copy the resulting
Hop Count to SAttributes. See Note 2. Goto PMpA.9.
PMpA.8 Include Hop Count of unknown (0) in SAttributes.
PMpA.9 Is Loop Detection configured on LSR?
If not, goto PMpA.21.
PMpA.10 Do RAttributes have a Path Vector?
If so, goto PMpA.19.
PMpA.11 Is LSR propagating a received Label Mapping?
If not, goto PMpA.20.
PMpA.12 Does LSR support merging?
If not, goto PMpA.14.
PMpA.13 Has LSR previously sent a Label Mapping for FEC to Peer?
If not, goto PMpA.20.
PMpA.14 Do RAttributes include a Hop Count?
If not, goto PMpA.21.
PMpA.15 Is Hop Count in Rattributes unknown(0)?
If so, goto PMpA.20.
PMpA.16 Has LSR previously sent a Label Mapping for FEC to Peer?
If not goto PMpA.21.
PMpA.17 Is Hop Count in RAttributes different from PrevHopCount ?
If not goto PMpA.21.
PMpA.18 Is the Hop Count in RAttributes > PrevHopCount? OR
Is PrevHopCount unknown(0)
If not, goto PMpA.21.
PMpA.19 Add LSR Id to beginning of Path Vector from RAttributes
and copy the resulting Path Vector into SAttributes.
Goto PMpA.21.
PMpA.20 Include Path Vector of length 1 containing LSR Id in
SAttributes.
PMpA.21 DONE.
Notes:
1. The link with Peer may require that Hop Count be included in
Label Mapping messages; for example, see [RFC3035] and
[RFC3034].
2. If the LSR is at the edge of a cloud of LSRs that do not
perform TTL-decrement and it is propagating the Label Mapping
message upstream into the cloud, it sets the Hop Count to 1 so
that Hop Count across the cloud is calculated properly. This
ensures proper TTL management for packets forwarded across the
part of the LSP that passes through the cloud.
3. For hop count arithmetic, unknown + 1 = unknown.
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.