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 4 of 5 – Pages 78 to 94
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 handles 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.
Implementations that support vendor-private TLVs MUST support a
user-accessible configuration interface that causes the U-bit to
be set on all transmitted vendor-private TLVs; this requirement
MAY be satisfied by a user-accessible configuration interface that
prevents transmission of all vendor-private TLVs for which the U-
bit is clear.
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 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. Implementations that support Vendor-Private messages MUST support a user-accessible configuration interface that causes the U-bit to be set on all transmitted Vendor-Private messages; this requirement MAY be satisfied by a user-accessible configuration interface that prevents transmission of all Vendor-Private messages for which the U-bit is clear. 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 Abort Request ..."
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 is defined in [RFC3031] as follows:
"The Implicit NULL label is a label with special semantics which an
LSR can bind to an address prefix. If LSR Ru, by consulting its ILM
(Incoming Label Map) sees that labeled packet P must be forwarded
next to Rd, but that Rd has distributed a binding of Implicit NULL to
the corresponding address prefix, then instead of replacing the value
of the label on top of the label stack, Ru pops the label stack, and
then forwards the resulting packet to Rd."
The implicit NULL label is represented in LDP as a Generic Label TLV
with a Label field value of 3, as defined in [RFC3032].
4. IANA Considerations
LDP defines the following name spaces that 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 indicate their willingness to establish and maintain LDP sessions by periodically sending Hello messages. Receipt of a Hello serves to create a new "Hello adjacency", if one does not already exist, or to refresh an existing one. Spoofing a Hello packet for an existing adjacency can cause the adjacency to time out and that can result in termination of the associated session. This can occur when the spoofed Hello specifies a small Hold Time, causing the receiver to expect Hellos within this interval, while the true neighbor continues sending Hellos at the lower, previously agreed to, frequency.
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 that distribute
routing information. By providing a mechanism to ensure the
authenticity and integrity of its messages, LDP provides a level of
security that 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 that 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 as 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 (Class of Service) 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.
- LDP support for signaling the maximum transmission unit is not
specified in this version. It is discussed in the experimental
document [LDP-MTU].
- The current specification does not address basic peer discovery
on Non-Broadcast Multi-Access (NBMA) media. The solution
available in the current specification is to use extended peer
discovery in such setups. The issue of defining a mechanism
semantically similar to Basic Discovery (1 hop limit, bind the
hello adjacency to an interface) that uses preconfigured
neighbor addresses is left for further study.
- The current specification does not support shutting down an
adjacency. The motivation for doing it and the mechanisms for
achieving it are left for further study.
- The current specification does not include a method for
securing Hello messages, to detect spoofing of Hellos. The
scenarios where this is necessary, as well as the mechanism for
achieving it are left for future study.
- The current specification does not have the ability to detect a
stateless fast control plane restart. The method for achieving
this, possibly through an "incarnation/instance" number carried
in the Hello message, is left for future study.
- The current specification does not support an "end of LIB"
message, analogous to BGP's "end of RIB" message that an LDP
LSR (operating in DU mode) would use following session
establishment. The discussion on the need for such a mechanism
and its implementation is left for future study.
- The current specification does not deal with situations where
different LSRs advertise the same address. Such situations
typically occur as the result of configuration errors, and the
goal in this case is to provide the LSRs advertising the same
address with enough information to enable operators to take
corrective action. The specification of this mechanism is left
for a separate document.
7. Changes from RFC 3036
Here is a list of changes from RFC 3036
1. Removed the Host Address FEC and references to it, since it is
not used by any implementation.
2. Split the reference list into normative and informative
references
3. Removed "MPLS using ATM VP Switching" from the list of
normative references, and references to it.
4. Removed reference to RFC 1700 and replaced it with a link to
http://www.iana.org/assignments/address-family-numbers.
5. Removed reference to RFC 1771 and replaced it with a reference
to RFC 4271.
6. Clarified the use of the F-bit.
7. Added option to allow split horizon when doing Ordered
Control.
8. Clarified the processing of messages with the U-bit set during
the session initialization procedures
9. Clarified the processing of the E-bit during session
initialization procedures.
10. Added text explaining that the Shutdown message in the state
transition diagram is implemented as a notification message
with a Status TLV indicating a fatal error.
11. Added case for TLV length too short in the specification for
handling malformed TLVs.
12. Explained the security threat posed by hello spoofing.
13. Added reference to 4271 and 4278 and text for standards
maturity variance with regards to the MD5 option.
14. Added text from 3031 explaining the handling of implicit NULL
label.
15. Included the encoding of DLCIs to remove normative reference
to 3034.
16. Moved references to 3031, 3032, and 3034 to informative.
17. In the section describing handling of unknown TLV, removed
reference to inexistent section (errata in original document).
18. Added text clarifying how to achieve interoperability when
sending vendor-private TLVs and messages.
19. In the "receive label request" procedures, if a loop is
detected, changed the procedure to send a notification before
aborting the rest of the processing.
20. In "receive label release" procedures, clarified the behavior
for merge-capable LSRs.
21. In "receive label release" procedures, clarified the behavior
for receipt of an unknown FEC.
22. In note 4 of "Detect Change in FEC Next Hop", modified the
text to reference the correct set of conditions for sending a
label request procedure (typo in the original document).
23. In the procedures for "LSR decides to no longer label switch a
FEC", clarified the fact that the label must not be reused
until a label release is received.
24. In the routine "Prepare_Label_Mapping_Attributes", added a
note regarding the treatment of unknown TLVs according to
their U and F-bits.
25. In the Address message processing procedures, clarified the
behavior for the case where an LSR receives re-advertisement
of an address previously advertised it, or withdrawal of an
address from an LSR that has not previously advertised that
address.
26. In the routine "Receive Label Mapping", clarified the meaning
of PrevAdvLabel when no label advertisement message has been
sent previously.
27. In the "Receive Label Mapping" procedures, if a loop is
detected, modified the procedure to send a notification before
aborting the rest of the processing.
28. In the "Receive Label Mapping" procedures, corrected step
LMp.10 to handle label mapping messages for additional (non-
merged) LSPs for the FEC.
29. In the "Receive Label Mapping" procedures, clarified behavior
when receiving a duplicate label for the same FEC.
30. In the routine "Receive Label Abort Request", clarified the
behavior for non-merging LSRs.
31. Added the following items to the section discussing areas for
future study:
o extensions for communicating the maximum transmission unit
o basic peer discovery on NBMA media
o option of shutting down an adjacency
o mechanisms for securing Hello messages
o detection of a stateless fast control plane restart
o support of "end of LIB" message
o mechanisms for dealing with the case where different LSRs
advertise the same address
8. Acknowledgments
This document is produced as part of advancing the LDP specification
to draft standard status. This document was originally published as
RFC 3036 in January 2001. It was produced by the MPLS Working Group
of the IETF and was jointly authored by Loa Andersson, Paul Doolan,
Nancy Feldman, Andre Fredette, and Bob Thomas.
The ideas and text in RFC 3036 were 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 for their input for RFC 3036.
The editors would like to thank Eric Gray, David Black, and Sam
Hartman for their input to and review of the current document.
In addition, the editors would like to thank the members of the MPLS
Working Group for their ideas and the support they have given to this
document, and in particular, to Eric Rosen, Luca Martini, Markus
Jork, Mark Duffy, Vach Kompella, Kishore Tiruveedhula, Rama
Ramakrishnan, Nick Weeds, Adrian Farrel, and Andy Malis.
9. References
9.1. Normative References
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[ASSIGNED_AF] http://www.iana.org/assignments/address-family-numbers
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998.
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E.,
Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using
LDP and ATM VC Switching", RFC 3035, January 2001.
[RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037, January 2001.9.2. Informative References
[CRLDP] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002. [LDP-MTU] Black, B. and K. Kompella, "Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol", RFC 3988, January 2005. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4278] Bellovin, S. and A. Zinin, "Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification", RFC 4278, January 2006.
(next page on part 5)