RFC 5036
LDP Specification
Pages: 135
Draft Standard
→ Errata
Obsoletes: 3036
Updated by: 6720 6790 7358 7552
Draft Standard
→ Errata
Obsoletes: 3036
Updated by: 6720 6790 7358 7552
Part 5 of 5 – Pages 95 to 135
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.
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:
1. 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.
2. 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.
3. 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)?
4. 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.
5. If the Label is not in forwarding/switching use, LMp.7 has no
effect.
6. 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.
7. 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.
8. 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.
9. 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.
10. 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.
11. 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.
12. As determined by step LMp.1.
13. 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:
1. 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.
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 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:
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.5 through LRl.9 deal with determining whether where the LSR
should propagate the Label Release to a downstream peer
(LRl.9).
3. 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:
1. If the 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 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.
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 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:
1. If the 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 that 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.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:
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 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:
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 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: 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 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: 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. 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.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. 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.
Note:
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 that 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 that label mapping
for FEC and Attributes from Peer is needed but that no
label resources are available.
SLRq.7 Return failure.
Note:
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 that 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.
Note:
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 Do the RAttributes include any unknown TLVs?
If not, goto PMpA.4.
PMpA.2 Do the settings of the U- and F-bits require forwarding of
these TLVs?
If not, goto PMpA.4.
PMpA.3 Copy the unknown TLVs in SAttributes.
PMpA.4 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.24.
PMpA.5 Is LSR egress for FEC?
If not, goto PMpA.7.
PMpA.6 Include Hop Count of 1 in SAttributes. Goto PMpA.24.
PMpA.7 Do RAttributes have a Hop Count?
If not, goto PMpA.11.
PMpA.8 Is LSR a member of the 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.10.
PMpA.9 Include Hop Count of 1 in SAttributes. Goto PMpA.12.
PMpA.10 Increment RAttributes Hop Count and copy the resulting Hop
Count to SAttributes. (See Note 2.) Goto PMpA.12.
PMpA.11 Include Hop Count of unknown (0) in SAttributes.
PMpA.12 Is Loop Detection configured on LSR?
If not, goto PMpA.24.
PMpA.13 Do RAttributes have a Path Vector?
If so, goto PMpA.22.
PMpA.14 Is LSR propagating a received Label Mapping?
If not, goto PMpA.23.
PMpA.15 Does LSR support merging?
If not, goto PMpA.17.
PMpA.16 Has LSR previously sent a Label Mapping for FEC to Peer?
If not, goto PMpA.23.
PMpA.17 Do RAttributes include a Hop Count?
If not, goto PMpA.24.
PMpA.18 Is Hop Count in RAttributes unknown(0)?
If so, goto PMpA.23.
PMpA.19 Has LSR previously sent a Label Mapping for FEC to Peer?
If not, goto PMpA.24.
PMpA.20 Is Hop Count in RAttributes different from PrevHopCount?
If not, goto PMpA.24.
PMpA.21 Is the Hop Count in RAttributes > PrevHopCount? OR Is
PrevHopCount unknown(0)?
If not, goto PMpA.24.
PMpA.22 Add LSR Id to beginning of Path Vector from RAttributes
and copy the resulting Path Vector into SAttributes.
Goto PMpA.24.
PMpA.23 Include Path Vector of length 1 containing LSR Id in
SAttributes.
PMpA.24 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.
Editors' Addresses
Loa Andersson Acreo AB Isafjordsgatan 22 Kista, Sweden EMail: loa.andersson@acreo.se loa@pi.se Ina Minei Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 EMail: ina@juniper.net Bob Thomas Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 EMail: rhthomas@cisco.com
Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.