draft-ietf-mpls-ldp-capabilities-00.txt   draft-ietf-mpls-ldp-capabilities-01.txt 
Network Working Group Bob Thomas Network Working Group Bob Thomas
Internet Draft Cisco Systems, Inc. Internet Draft Cisco Systems, Inc.
Expiration Date: November 2007 Expiration Date: August 2008
S. Aggarwal Intended Status: Proposed Standard S. Aggarwal
Juniper Networks Juniper Networks
R. Aggarwal R. Aggarwal
Juniper Networks Juniper Networks
J.L. Le Roux J.L. Le Roux
France Telecom France Telecom
February 2008
LDP Capabilities LDP Capabilities
draft-ietf-mpls-ldp-capabilities-00.txt draft-ietf-mpls-ldp-capabilities-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 7 skipping to change at page 2, line 7
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The IETF TRUST (2007). Copyright (C) The IETF TRUST (2008).
Abstract Abstract
A number of enhancements to the Label Distribution Protocol (LDP) A number of enhancements to the Label Distribution Protocol (LDP)
have been proposed. Some have been implemented, and some are have been proposed. Some have been implemented, and some are
advancing toward standardization. It is likely that additional advancing toward standardization. It is likely that additional
enhancements will be proposed in the future. At present LDP has no enhancements will be proposed in the future. At present LDP has no
guidelines for advertising such enhancements at LDP session guidelines for advertising such enhancements at LDP session
initialization time. There is also no mechanism to enable and initialization time. There is also no mechanism to enable and
disable enhancements after the session is established. This document disable enhancements after the session is established. This document
skipping to change at page 3, line 7 skipping to change at page 3, line 7
12 Security Considerations ....................................... 10 12 Security Considerations ....................................... 10
13 IANA Considerations ........................................... 10 13 IANA Considerations ........................................... 10
14 Acknowledgements .............................................. 11 14 Acknowledgements .............................................. 11
15 References .................................................... 11 15 References .................................................... 11
16 Author Information ............................................ 12 16 Author Information ............................................ 12
17 Intellectual Property Statement ............................... 12 17 Intellectual Property Statement ............................... 12
18 Full Copyright Statement ...................................... 13 18 Full Copyright Statement ...................................... 13
1. Introduction 1. Introduction
A number of enhancements to LDP as specified in [RFC3036] have been A number of enhancements to LDP as specified in [RFC5036] have been
proposed. These include LDP Graceful Restart [RFC3478], Fault proposed. These include LDP Graceful Restart [RFC3478], Fault
Tolerant LDP [RFC3479], multicast extensions [MLDP], signaling for Tolerant LDP [RFC3479], multicast extensions [MLDP], signaling for
layer 2 circuits [RFC4447], a method for learning labels advertised layer 2 circuits [RFC4447], a method for learning labels advertised
by next next hop routers in support of fast reroute node protection by next next hop routers in support of fast reroute node protection
[NNHOP], upstream label allocation [UPSTREAM_LDP], and extensions for [NNHOP], upstream label allocation [UPSTREAM_LDP], and extensions for
signaling inter-area LSPs [IALDP]. Some have been implemented, and signaling inter-area LSPs [IALDP]. Some have been implemented, and
some are advancing toward standardization. It is likely that some are advancing toward standardization. It is likely that
additional enhancements will be proposed in the future. additional enhancements will be proposed in the future.
At present LDP has no guidelines for advertising such enhancements at At present LDP has no guidelines for advertising such enhancements at
LDP session initialization time. There is also no mechanism to LDP session initialization time. There is also no mechanism to
enable and disable enhancements after the session is established. enable and disable enhancements after the session is established.
This document provides guidelines for advertising LDP enhancements at This document provides guidelines for advertising LDP enhancements at
session initialization time. It also defines a mechanism to enable session initialization time. It also defines a mechanism to enable
and disable enhancements after LDP session establishment. and disable enhancements after LDP session establishment.
LDP capability advertisement provides means for an LDP speaker to LDP capability advertisement provides means for an LDP speaker to
announce what it can receive and process. It also provides means for announce what it can receive and process. It also provides means for
a speaker to inform peers of deviations from behavior specified by a speaker to inform peers of deviations from behavior specified by
[RFC3036]. An example of such a deviation is LDP graceful restart [RFC5036]. An example of such a deviation is LDP graceful restart
where a speaker retains MPLS forwarding state for LDP-signaled LSPs where a speaker retains MPLS forwarding state for LDP-signaled LSPs
when its LDP control plane goes down. It is important to point out when its LDP control plane goes down. It is important to point out
that not all LDP enhancements require capability advertisement. For that not all LDP enhancements require capability advertisement. For
example, upstream label allocation does but inbound label filtering, example, upstream label allocation does but inbound label filtering,
where a speaker installs forwarding state for only certain FECs, does where a speaker installs forwarding state for only certain FECs, does
not. not.
2. Specification Language 2. Specification Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 5, line 33 skipping to change at page 5, line 33
|U|F| TLV Code Point | Length | |U|F| TLV Code Point | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | | |S| Reserved | |
+-+-+-+-+-+-+-+-+ Capability Data | +-+-+-+-+-+-+-+-+ Capability Data |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
U and F bits: U and F bits:
As specified in [RFC3036]. As specified in [RFC5036].
TLV Code Point: TLV Code Point:
The TLV type which identifies a specific capability. The "IANA The TLV type, which identifies a specific capability. The "IANA
Considerations" section of [RFC3036] specifies the assignment of Considerations" section of [RFC5036] specifies the assignment of
code points for LDP TLVs. code points for LDP TLVs.
S-bit: S-bit:
The State Bit indicates whether the sender is advertising or The State Bit indicates whether the sender is advertising or
withdrawing the capability corresponding to the TLV Code Point. withdrawing the capability corresponding to the TLV Code Point.
The State bit is used as follows: The State bit is used as follows:
1 - The TLV is advertising the capability specified by the 1 - The TLV is advertising the capability specified by the
TLV Code Point. TLV Code Point.
0 - The TLV is withdrawing the capability specified by the 0 - The TLV is withdrawing the capability specified by the
skipping to change at page 8, line 14 skipping to change at page 8, line 14
Notification message SHOULD be Unsupported Capability, and the Notification message SHOULD be Unsupported Capability, and the
message SHOULD contain the unsupported capabilities (see Section 9 message SHOULD contain the unsupported capabilities (see Section 9
for more details). In this case the session SHOULD NOT be re- for more details). In this case the session SHOULD NOT be re-
established automatically. How the session is re-established is established automatically. How the session is re-established is
beyond the scope of this document. It depends on the LDP capability beyond the scope of this document. It depends on the LDP capability
and MUST be specified along with the procedures specifying the and MUST be specified along with the procedures specifying the
capability. capability.
An LDP speaker that supports capability advertisement and includes a An LDP speaker that supports capability advertisement and includes a
Capability Parameter in its Initialization message SHOULD set the TLV Capability Parameter in its Initialization message SHOULD set the TLV
U bit to 1. This ensures that an [RFC3036] compliant peer that does U bit to 1. This ensures that an [RFC5036] compliant peer that does
not support the capability mechanism will ignore the Capability not support the capability mechanism will ignore the Capability
Parameter and allow the session to be established. Parameter and allow the session to be established.
8. Procedures for Capability Parameters in Capability Messages 8. Procedures for Capability Parameters in Capability Messages
An LDP speaker MUST NOT send a Capability message to a peer unless An LDP speaker MUST NOT send a Capability message to a peer unless
its peer had advertised the Dynamic Capability Announcement its peer had advertised the Dynamic Capability Announcement
capability in its session Initialization message (see Section 10). capability in its session Initialization message (see Section 10).
An LDP speaker MAY send a Capability message to a peer if its peer An LDP speaker MAY send a Capability message to a peer if its peer
skipping to change at page 10, line 8 skipping to change at page 10, line 8
capability cannot be disabled. capability cannot be disabled.
An LDP speaker that receives a Capability message from a peer that An LDP speaker that receives a Capability message from a peer that
includes the Dynamic Capability Announcement Parameter SHOULD includes the Dynamic Capability Announcement Parameter SHOULD
silently ignore the parameter and process any other Capability silently ignore the parameter and process any other Capability
Parameters in the message. Parameters in the message.
11. Backward Compatibility 11. Backward Compatibility
From the point of view of the LDP capability advertisement mechanism From the point of view of the LDP capability advertisement mechanism
an [RFC3036] compliant peer has label distribution for IPv4 enabled an [RFC5036] compliant peer has label distribution for IPv4 enabled
by default. To ensure compatibility with an [RFC3036] compliant peer by default. To ensure compatibility with an [RFC5036] compliant peer
LDP implementations that support capability advertisement have label LDP implementations that support capability advertisement have label
distribution for IPv4 enabled until it is explicitly disabled and distribution for IPv4 enabled until it is explicitly disabled and
MUST assume that their peers do as well. MUST assume that their peers do as well.
Section 3 identifies a set of Backward Compatibility TLVs that may Section 3 identifies a set of Backward Compatibility TLVs that may
appear in Initialization messages in the role of a Capability appear in Initialization messages in the role of a Capability
Parameter. This permits existing LDP enhancements that use an ad hoc Parameter. This permits existing LDP enhancements that use an ad hoc
mechanism for enabling capabilities at sesssion initialization time mechanism for enabling capabilities at sesssion initialization time
to continue to do so. to continue to do so.
12. Security Considerations 12. Security Considerations
The security considerations described in [RFC3036] that apply to the The security considerations described in [RFC5036] that apply to the
base LDP specification apply to the capability mechanism described in base LDP specification apply to the capability mechanism described in
this document. this document.
13. IANA Considerations 13. IANA Considerations
This document specifies the following which require code points This document specifies the following which require code points
assigned by IANA: assigned by IANA:
- LDP message code point for the Capability message. The authors - LDP message code point for the Capability message. The authors
request message type 0x0202 for the Capability message. request message type 0x0202 for the Capability message.
skipping to change at page 11, line 14 skipping to change at page 11, line 14
14. Acknowledgements 14. Acknowledgements
The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo, The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo,
Yakov Rekhter, and Eric Rosen for their comments. Yakov Rekhter, and Eric Rosen for their comments.
15. References 15. References
Normative References Normative References
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and [RFC5036] Andersson, L., Menei, I., and Thomas, B., Editors, "LDP
Thomas, B., "LDP Specification", RFC 3036, January 2001. Specification", RFC 5036, September 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997. Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC3479] Farrel, A., Editor, "Fault Tolerance for the Label [RFC3479] Farrel, A., Editor, "Fault Tolerance for the Label
Distribution Protocol (LDP)", RFC 3479, February 2003. Distribution Protocol (LDP)", RFC 3479, February 2003.
Informative References Informative References
[IALDP] Decraene, B., Le Roux, JL., Minei, I, "LDP Extensions for [IALDP] Decraene, B., Le Roux, JL., Minei, I, "LDP Extensions for
skipping to change at page 13, line 13 skipping to change at page 13, line 13
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
18. Full Copyright Statement 18. Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
 End of changes. 14 change blocks. 
17 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/