released for all FECs to which it is bound. If there is not an
optional Label TLV in the Label Release message, then the sending LSR
is releasing all label mappings previously learned from the receiving
LSR.
See Appendix A "LDP Label Distribution Procedures" for more details.
3.6. Messages and TLVs for Extensibility
Support for LDP extensibility includes the rules for the U and F bits
that specify how an LSR should handle unknown TLVs and messages.
This section specifies TLVs and messages for vendor-private and
experimental use.
3.6.1. LDP Vendor-private Extensions
Vendor-private TLVs and messages are used to convey vendor-private
information between LSRs.
3.6.1.1. LDP Vendor-private TLVs
The Type range 0x3E00 through 0x3EFF is reserved for vendor-private
TLVs.
The encoding for a vendor-private TLV is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (0x3E00-0x3EFF) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data.... |
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit
Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear
(=0), a notification must be returned to the message originator
and the entire message must be ignored; if U is set (=1), the
unknown TLV is silently ignored and the rest of the message is
processed as if the unknown TLV did not exist.
The determination as to whether a vendor-private message is
understood is based on the Type and the mandatory Vendor ID field.
F bit
Forward unknown TLV bit. This bit only applies when the U bit is
set and the LDP message containing the unknown TLV is is to be
forwarded. If F is clear (=0), the unknown TLV is not forwarded
with the containing message; if F is set (=1), the unknown TLV is
forwarded with the containing message.
Type
Type value in the range 0x3E00 through 0x3EFF. Together, the Type
and Vendor Id field specify how the Data field is to be
interpreted.
Length
Specifies the cumulative length in octets of the Vendor ID and
Data fields.
Vendor Id
802 Vendor ID as assigned by the IEEE.
Data
The remaining octets after the Vendor ID in the Value field are
optional vendor-dependent data.
3.6.1.2. LDP Vendor-private Messages
The Message Type range 0x3E00 through 0x3EFF is reserved for vendor-
private Messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Msg Type (0x3E00-0x3EFF) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +
| Remaining Mandatory Parameters |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Optional Parameters |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit
Unknown message bit. Upon receipt of an unknown message, if U is
clear (=0), a notification is returned to the message originator;
if U is set (=1), the unknown message is silently ignored.
The determination as to whether a vendor-private message is
understood is based on the Msg Type and the Vendor ID parameter.
Msg Type
Message type value in the range 0x3E00 through 0x3EFF. Together,
the Msg Type and the Vendor ID specify how the message is to be
interpreted.
Message Length
Specifies the cumulative length in octets of the Message ID,
Vendor ID, Remaining Mandatory Parameters and Optional Parameters.
Message ID
32-bit integer used to identify this message. Used by the sending
LSR to facilitate identifying notification messages that may apply
to this message. An LSR sending a notification message in
response to this message will include this Message Id in the
notification message; see Section "Notification Message".
Vendor ID
802 Vendor ID as assigned by the IEEE.
Remaining Mandatory Parameters
Variable length set of remaining required message parameters.
Optional Parameters
Variable length set of optional message parameters.
3.6.2. LDP Experimental Extensions
LDP support for experimentation is similar to support for vendor-
private extensions with the following differences:
- The Type range 0x3F00 through 0x3FFF is reserved for
experimental TLVs.
- The Message Type range 0x3F00 through 0x3FFF is reserved for
experimental messages.
- The encodings for experimental TLVs and messages are similar to
the vendor-private encodings with the following difference.
Experimental TLVs and messages use an Experiment ID field in
place of a Vendor ID field. The Experiment ID field is used
with the Type or Message Type field to specify the
interpretation of the experimental TLV or Message.
Administration of Experiment IDs is the responsibility of the
experimenters.
3.7. Message Summary
The following are the LDP messages defined in this version of the
protocol.
Message Name Type Section Title
Notification 0x0001 "Notification Message"
Hello 0x0100 "Hello Message"
Initialization 0x0200 "Initialization Message"
KeepAlive 0x0201 "KeepAlive Message"
Address 0x0300 "Address Message"
Address Withdraw 0x0301 "Address Withdraw Message"
Label Mapping 0x0400 "Label Mapping Message"
Label Request 0x0401 "Label Request Message"
Label Withdraw 0x0402 "Label Withdraw Message"
Label Release 0x0403 "Label Release Message"
Label Abort Request 0x0404 "Label Abort Request Message"
Vendor-Private 0x3E00- "LDP Vendor-private Extensions"
0x3EFF
Experimental 0x3F00- "LDP Experimental Extensions"
0x3FFF
3.8. TLV Summary
The following are the TLVs defined in this version of the protocol.
TLV Type Section Title
FEC 0x0100 "FEC TLV"
Address List 0x0101 "Address List TLV"
Hop Count 0x0103 "Hop Count TLV"
Path Vector 0x0104 "Path Vector TLV"
Generic Label 0x0200 "Generic Label TLV"
ATM Label 0x0201 "ATM Label TLV"
Frame Relay Label 0x0202 "Frame Relay Label TLV"
Status 0x0300 "Status TLV"
Extended Status 0x0301 "Notification Message"
Returned PDU 0x0302 "Notification Message"
Returned Message 0x0303 "Notification Message"
Common Hello 0x0400 "Hello Message"
Parameters
IPv4 Transport Address 0x0401 "Hello Message"
Configuration 0x0402 "Hello Message"
Sequence Number
IPv6 Transport Address 0x0403 "Hello Message"
Common Session 0x0500 "Initialization Message"
Parameters
ATM Session Parameters 0x0501 "Initialization Message"
Frame Relay Session 0x0502 "Initialization Message"
Parameters
Label Request 0x0600 "Label Mapping Message"
Message ID
Vendor-Private 0x3E00- "LDP Vendor-private Extensions"
0x3EFF
Experimental 0x3F00- "LDP Experimental Extensions"
0x3FFF
3.9. Status Code Summary
The following are the Status Codes defined in this version of the
protocol.
The "E" column is the required setting of the Status Code E-bit; the
"Status Data" column is the value of the 30-bit Status Data field in
the Status Code TLV.
Note that the setting of the Status Code F-bit is at the discretion
of the LSR originating the Status TLV.
Status Code E Status Data Section Title
Success 0 0x00000000 "Status TLV"
Bad LDP Identifier 1 0x00000001 "Events Signaled by ..."
Bad Protocol Version 1 0x00000002 "Events Signaled by ..."
Bad PDU Length 1 0x00000003 "Events Signaled by ..."
Unknown Message Type 0 0x00000004 "Events Signaled by ..."
Bad Message Length 1 0x00000005 "Events Signaled by ..."
Unknown TLV 0 0x00000006 "Events Signaled by ..."
Bad TLV length 1 0x00000007 "Events Signaled by ..."
Malformed TLV Value 1 0x00000008 "Events Signaled by ..."
Hold Timer Expired 1 0x00000009 "Events Signaled by ..."
Shutdown 1 0x0000000A "Events Signaled by ..."
Loop Detected 0 0x0000000B "Loop Detection"
Unknown FEC 0 0x0000000C "FEC Procedures"
No Route 0 0x0000000D "Label Request Mess ..."
No Label Resources 0 0x0000000E "Label Request Mess ..."
Label Resources / 0 0x0000000F "Label Request Mess ..."
Available
Session Rejected/ 1 0x00000010 "Session Initialization"
No Hello
Session Rejected/ 1 0x00000011 "Session Initialization"
Parameters Advertisement Mode
Session Rejected/ 1 0x00000012 "Session Initialization"
Parameters Max PDU Length
Session Rejected/ 1 0x00000013 "Session Initialization"
Parameters Label Range
KeepAlive Timer 1 0x00000014 "Events Signaled by ..."
Expired
Label Request Aborted 0 0x00000015 "Label Request Abort ..."
Missing Message 0 0x00000016 "Events Signaled by ..."
Parameters
Unsupported Address 0 0x00000017 "FEC Procedures"
Family "Address Message Proc ..."
Session Rejected/ 1 0x00000018 "Session Initialization"
Bad KeepAlive Time
Internal Error 1 0x00000019 "Events Signaled by ..."
3.10. Well-known Numbers
3.10.1. UDP and TCP Ports
The UDP port for LDP Hello messages is 646.
The TCP port for establishing LDP session connections is 646.
3.10.2. Implicit NULL Label
The Implicit NULL label (see [RFC3031]) is represented as a Generic
Label TLV with a Label field value as specified by [RFC3032].
4. IANA Considerations
LDP defines the following name spaces which require management:
- Message Type Name Space.
- TLV Type Name Space.
- FEC Type Name Space.
- Status Code Name Space.
- Experiment ID Name Space.
The following sections provide guidelines for managing these name
spaces.
4.1. Message Type Name Space
LDP divides the name space for message types into three ranges. The
following are the guidelines for managing these ranges:
- Message Types 0x0000 - 0x3DFF. Message types in this range are
part of the LDP base protocol. Following the policies outlined
in [IANA], Message types in this range are allocated through an
IETF Consensus action.
- Message Types 0x3E00 - 0x3EFF. Message types in this range are
reserved for Vendor Private extensions and are the
responsibility of the individual vendors (see Section "LDP
Vendor-private Messages"). IANA management of this range of
the Message Type Name Space is unnecessary.
- Message Types 0x3F00 - 0x3FFF. Message types in this range are
reserved for Experimental extensions and are the responsibility
of the individual experimenters (see Sections "LDP Experimental
Extensions" and "Experiment ID Name Space"). IANA management
of this range of the Message Type Name Space is unnecessary;
however, IANA is responsible for managing part of the
Experiment ID Name Space (see below).
4.2. TLV Type Name Space
LDP divides the name space for TLV types into three ranges. The
following are the guidelines for managing these ranges:
- TLV Types 0x0000 - 0x3DFF. TLV types in this range are part of
the LDP base protocol. Following the policies outlined in
[IANA], TLV types in this range are allocated through an IETF
Consensus action.
- TLV Types 0x3E00 - 0x3EFF. TLV types in this range are
reserved for Vendor Private extensions and are the
responsibility of the individual vendors (see Section "LDP
Vendor-private TLVs"). IANA management of this range of the
TLV Type Name Space is unnecessary.
- TLV Types 0x3F00 - 0x3FFF. TLV types in this range are
reserved for Experimental extensions and are the responsibility
of the individual experimenters (see Sections "LDP Experimental
Extensions" and "Experiment ID Name Space"). IANA management
of this range of the TLV Name Space is unnecessary; however,
IANA is responsible for managing part of the Experiment ID Name
Space (see below).
4.3. FEC Type Name Space
The range for FEC types is 0 - 255.
Following the policies outlined in [IANA], FEC types in the range 0 -
127 are allocated through an IETF Consensus action, types in the
range 128 - 191 are allocated as First Come First Served, and types
in the range 192 - 255 are reserved for Private Use.
4.4. Status Code Name Space
The range for Status Codes is 0x00000000 - 0x3FFFFFFF.
Following the policies outlined in [IANA], Status Codes in the range
0x00000000 - 0x1FFFFFFF are allocated through an IETF Consensus
action, codes in the range 0x20000000 - 0x3EFFFFFF are allocated as
First Come First Served, and codes in the range 0x3F000000 -
0x3FFFFFFF are reserved for Private Use.
4.5. Experiment ID Name Space
The range for Experiment Ids is 0x00000000 - 0xffffffff.
Following the policies outlined in [IANA], Experiment Ids in the
range 0x00000000 - 0xefffffff are allocated as First Come First
Served and Experiment Ids in the range 0xf0000000 - 0xffffffff are
reserved for Private Use.
5. Security Considerations
This section identifies threats to which LDP may be vulnerable and
discusses means by which those threats might be mitigated.
5.1. Spoofing
There are two types of LDP communication that could be the target of
a spoofing attack.
1. Discovery exchanges carried by UDP.
LSRs directly connected at the link level exchange Basic Hello
messages over the link. The threat of spoofed Basic Hellos can be
reduced by:
o Accepting Basic Hellos only on interfaces to which LSRs that
can be trusted are directly connected.
o Ignoring Basic Hellos not addressed to the All Routers on
this Subnet multicast group.
LSRs not directly connected at the link level may use Extended
Hello messages to indicate willingness to establish an LDP
session. An LSR can reduce the threat of spoofed Extended Hellos
by filtering them and accepting only those originating at sources
permitted by an access list.
2. Session communication carried by TCP.
LDP specifies use of the TCP MD5 Signature Option to provide for
the authenticity and integrity of session messages.
[RFC2385] asserts that MD5 authentication is now considered by
some to be too weak for this application. It also points out that
a similar TCP option with a stronger hashing algorithm (it cites
SHA-1 as an example) could be deployed. To our knowledge no such
TCP option has been defined and deployed. However, we note that
LDP can use whatever TCP message digest techniques are available,
and when one stronger than MD5 is specified and implemented,
upgrading LDP to use it would be relatively straightforward.
5.2. Privacy
LDP provides no mechanism for protecting the privacy of label
distribution.
The security requirements of label distribution protocols are
essentially identical to those of the protocols which distribute
routing information. By providing a mechanism to ensure the
authenticity and integrity of its messages LDP provides a level of
security which is at least as good as, though no better than, that
which can be provided by the routing protocols themselves. The more
general issue of whether privacy should be required for routing
protocols is beyond the scope of this document.
One might argue that label distribution requires privacy to address
the threat of label spoofing. However, that privacy would not
protect against label spoofing attacks since data packets carry
labels in the clear. Furthermore, label spoofing attacks can be made
without knowledge of the FEC bound to a label.
To avoid label spoofing attacks, it is necessary to ensure that
labeled data packets are labeled by trusted LSRs and that the labels
placed on the packets are properly learned by the labeling LSRs.
5.3. Denial of Service
LDP provides two potential targets for denial of service (DoS)
attacks:
1. Well known UDP Port for LDP Discovery
An LSR administrator can address the threat of DoS attacks via
Basic Hellos by ensuring that the LSR is directly connected only
to peers which can be trusted to not initiate such an attack.
Interfaces to peers interior to the administrator's domain should
not represent a threat since interior peers are under the
administrator's control. Interfaces to peers exterior to the
domain represent a potential threat since exterior peers are not.
An administrator can reduce that threat by connecting the LSR only
to exterior peers that can be trusted to not initiate a Basic
Hello attack.
DoS attacks via Extended Hellos are potentially a more serious
threat. This threat can be addressed by filtering Extended Hellos
using access lists that define addresses with which extended
discovery is permitted. However, performing the filtering
requires LSR resource.
In an environment where a trusted MPLS cloud can be identified,
LSRs at the edge of the cloud can be used to protect interior LSRs
against DoS attacks via Extended Hellos by filtering out Extended
Hellos originating outside of the trusted MPLS cloud, accepting
only those originating at addresses permitted by access lists.
This filtering protects LSRs in the interior of the cloud but
consumes resources at the edges.
2. Well known TCP port for LDP Session Establishment
Like other control plane protocols that use TCP, LDP may be the
target of DoS attacks, such a SYN attacks. LDP is no more or less
vulnerable to such attacks than other control plane protocols that
use TCP.
The threat of such attacks can be mitigated somewhat by the
following:
o An LSR should avoid promiscuous TCP listens for LDP session
establishment. It should use only listens that are specific
to discovered peers. This enables it to drop attack packets
early in their processing since they are less likely to
match existing or in-progress connections.
o The use of the MD5 option helps somewhat since it prevents a
SYN from being accepted unless the MD5 segment checksum is
valid. However, the receiver must compute the checksum
before it can decide to discard an otherwise acceptable SYN
segment.
o The use of access list mechanisms applied at the boundary of
the MPLS cloud in a manner similar to that suggested above
for Extended Hellos can protect the interior against attacks
originating from outside the cloud.
6. Areas for Future Study
The following topics not addressed in this version of LDP are
possible areas for future study:
- Section 2.16 of the MPLS architecture [RFC3031] requires that
the initial label distribution protocol negotiation between
peer LSRs enable each LSR to determine whether its peer is
capable of popping the label stack. This version of LDP
assumes that LSRs support label popping for all link types
except ATM and Frame Relay. A future version may specify means
to make this determination part of the session initiation
negotiation.
- LDP support for CoS is not specified in this version. CoS
support may be addressed in a future version.
- LDP support for multicast is not specified in this version.
Multicast support may be addressed in a future version.
- LDP support for multipath label switching is not specified in
this version. Multipath support may be addressed in a future
version.
7. Intellectual Property Considerations
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
8. Acknowledgments
The ideas and text in this document have been collected from a number
of sources. We would like to thank Rick Boivie, Ross Callon, Alex
Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov
Rekhter, and Arun Viswanathan.
9. References
[ATM-VP] N. Feldman, B. Jamoussi, S. Komandur, A, Viswanathan, T
Worster, "MPLS using ATM VP Switching", Work in Progress.
[CRLDP] L. Andersson, A. Fredette, B. Jamoussi, R. Callon, P.
Doolan, N. Feldman, E. Gray, J. Halpern, J. Heinanen T.
E. Kilty, A. G. Malis, M. Girish, K. Sundell, P.
Vaananen, T. Worster, L. Wu, R. Dantu, "Constraint-Based
LSP Setup using LDP", Work in Progress.
[DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC2475, December 1998.
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC2434,
October 1998.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC1321,
April 1992.
[RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM
Adaptation Layer 5", RFC1483, July 1993.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC2328, April 1998.
[RFC1700] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2,
RFC1700, October 1994.
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC1771, March 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC2205, September 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC2385, August 1998.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
McManus, "Requirements for Traffic Engineering over
MPLS", RFC2702, September 1999.
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
Label Switching Architecture", RFC3031, January 2001.
[RFC3032] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D.,
Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack
Encoding", RFC3032, January 2001.
[RFC3034] Conta, A., Doolan, P. and A. Malis, "Use of Label
Switching on Frame Relay Networks Specification", RFC
3034, January 2001.
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y.,
Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and
ATM VC Switching", RFC3035, January 2001.
[RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC3037,
January 2001.
10. Authors' Addresses
Loa Andersson
Nortel Networks Inc
St Eriksgatan 115, PO Box 6701
113 85 Stockholm
Sweden
Phone: +46 8 5088 36 34
Mobile: +46 70 522 78 34
EMail: loa.andersson@nortelnetworks.com
Paul Doolan
Ennovate Networks
60 Codman Hill Rd
Marlborough MA 01719
Phone: 978-263-2002
EMail: pdoolan@ennovatenetworks.com
Nancy Feldman
IBM Research
30 Saw Mill River Road
Hawthorne, NY 10532
Phone: 914-784-3254
EMail: nkf@us.ibm.com
Andre Fredette
PhotonEx Corporation
8C Preston Court
Bedford, MA 01730
Phone: 781-301-4655
EMail: fredette@photonex.com
Bob Thomas
Cisco Systems, Inc.
250 Apollo Dr.
Chelmsford, MA 01824
Phone: 978-244-8078
EMail: rhthomas@cisco.com
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 Release On Change in
[RFC3031].
. Liberal label retention, called No Release On Change 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 Label Not Available 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 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 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.13.
LRq.2 Is there a Next Hop for FEC?
If not, goto LRq.5.
LRq.3 Is MsgSource the Next Hop?
Ifnot, 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 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 FEC, if any, previously advertised
to an upstream peer.
- 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 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.)
Goto LMp.33.
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.)
If not, goto LMp.32. (See Note 4.)
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).
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 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 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) 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 LSR is operating in Downstream Unsolicited ordered
control mode. Ordered control prevents LSR from advertising a
label for FEC until it has received a label mapping from its
next hop (MsgSource) for FEC.
8. If LSR is merging the LSP it may have previously sent label
mappings for the FEC LSP to one or more peers. If 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.
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 upstream peers other than MsgSource that have
requested a label for 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