--- 1/draft-ietf-mpls-ldp-capabilities-02.txt 2009-03-07 01:12:17.000000000 +0100 +++ 2/draft-ietf-mpls-ldp-capabilities-03.txt 2009-03-07 01:12:17.000000000 +0100 @@ -1,213 +1,240 @@ - Network Working Group Bob Thomas Internet Draft Cisco Systems, Inc. -Expiration Date: October 2008 -Intended Status: Proposed Standard S. Aggarwal +Intended Status: Proposed Standard +Expiration Date: September 05, 2009 S. Aggarwal Juniper Networks R. Aggarwal Juniper Networks J.L. Le Roux France Telecom + + Syed Kamran Raza + Cisco Systems, Inc. + + March 06, 2009 + LDP Capabilities - draft-ietf-mpls-ldp-capabilities-02.txt + draft-ietf-mpls-ldp-capabilities-03.txt Status of this Memo - By submitting this Internet-Draft, each author represents that any - 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 - aware will be disclosed, in accordance with Section 6 of BCP 79. + This Internet-Draft is submitted to IETF in full conformance + with the provisions of BCP 78 and BCP 79. This document may + contain material from IETF Documents or IETF Contributions + published or made publicly available before November 10, + 2008. The person(s) controlling the copyright in some of + this material may not have granted the IETF Trust the right + to allow modifications of such material outside the IETF + Standards Process. Without obtaining an adequate license + from the person(s) controlling the copyright in such + materials, this document may not be modified outside the + IETF Standards Process, and derivative works of it may not + be created outside the IETF Standards Process, except to + format it for publication as an RFC or to translate it into + languages other than English. - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. + Internet-Drafts are working documents of the Internet + Engineering Task Force (IETF), its areas, and its working + groups. Note that other groups may also distribute working + documents as Internet-Drafts. - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." + Internet-Drafts are draft documents valid for a maximum of + six months and may be updated, replaced, or obsoleted by + other documents at any time. It is inappropriate to use + Internet-Drafts as reference material or to cite them other + than as "work in progress." The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. + http://www.ietf.org/ietf/1id-abstracts.txt. -Copyright Notice + The list of Internet-Draft Shadow Directories can be + accessed at http://www.ietf.org/shadow.html. - Copyright (C) The IETF TRUST (2008). + This Internet-Draft will expire on September 05, 2009. Abstract A number of enhancements to the Label Distribution Protocol (LDP) have been proposed. Some have been implemented, and some are advancing toward standardization. It is likely that additional - enhancements will be proposed in the future. At present LDP has no - guidelines for advertising such enhancements at LDP session + enhancements will be proposed in the future. At present, LDP has no + mechanism for advertising such enhancements at LDP session initialization time. There is also no mechanism to enable and disable enhancements after the session is established. This document - provides guidelines for advertising LDP enhancements at session - initialization time. It also defines a mechanism to enable and - disable enhancements after LDP session establishment. + defines a mechanism for advertising LDP enhancements at session + initialization time, as well as a mechanism to enable and disable + enhancements after LDP session establishment. + +Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + This document uses the terms "LDP speaker" and "speaker" + interchangably. Table of Contents - 1 Introduction .................................................. 3 - 2 Specification Language ........................................ 3 - 3 The LDP Capability Mechanism .................................. 3 - 4 Specifying Capabilities in LDP Messages ....................... 5 - 5 Capability Message ............................................ 6 - 6 Note on Terminology ........................................... 7 - 7 Procedures for Capability Parameters in Initialization Messages 7 - 8 Procedures for Capability Parameters in Capability Messages ... 8 - 9 Extensions to Error Handling ................................. 9 - 10 Dynamic Capability Announcement TLV ......................... 9 - 11 Backward Compatibility ...................................... 10 - 12 Security Considerations ..................................... 10 - 13 IANA Considerations ......................................... 10 - 14 Acknowledgements ............................................ 11 - 15 References .................................................. 11 - 16 Author Information .......................................... 12 - 17 Intellectual Property Statement ............................. 12 - 18 Full Copyright Statement .................................... 13 + 1. Introduction...................................................3 + 2. The LDP Capability Mechanism...................................4 + 2.1. Capability Document.......................................5 + 3. Specifying Capabilities in LDP Messages........................5 + 3.1. Backward Compatibility TLVs...............................7 + 4. Capability Message.............................................7 + 5. Note on Terminology............................................8 + 6. Procedures for Capability Parameters in Initialization Messages8 + 7. Procedures for Capability Parameters in Capability Messages....9 + 8. Extensions to Error Handling..................................10 + 9. Dynamic Capability Announcement TLV...........................10 + 10. Backward Compatibility.......................................11 + 11. Security Considerations......................................11 + 12. IANA Considerations..........................................11 + 13. Acknowledgments..............................................12 + 14. References...................................................12 + 14.1. Normative References....................................12 + 14.2. Informative References..................................12 + 15. Author's Addresses...........................................13 1. Introduction A number of enhancements to LDP as specified in [RFC5036] have been proposed. These include LDP Graceful Restart [RFC3478], Fault Tolerant LDP [RFC3479], multicast extensions [MLDP], signaling for 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 signaling inter-area LSPs [IALDP]. Some have been implemented, and - some are advancing toward standardization. It is likely that - additional enhancements will be proposed in the future. + some are advancing toward standardization. It is also likely that + additional enhancements will be implemented and deployed in the + future. - At present LDP has no guidelines for advertising such enhancements at - LDP session initialization time. There is also no mechanism to - enable and disable enhancements after the session is established. + At present, LDP does not have a mechanism for advertising such + enhancements at LDP session initialization time. There is also no + mechanism to enable and disable these enhancements after the session + is established. - This document provides guidelines for advertising LDP enhancements at - session initialization time. It also defines a mechanism to enable - and disable enhancements after LDP session establishment. + This document proposes and defines a mechanism for advertising LDP + enhancements at session initialization time. It also defines a + mechanism to enable and disable these enhancements after LDP session + establishment. LDP capability advertisement provides means for an LDP speaker to announce what it can receive and process. It also provides means for a speaker to inform peers of deviations from behavior specified by [RFC5036]. An example of such a deviation is LDP graceful restart where a speaker retains MPLS forwarding state for LDP-signaled LSPs when its LDP control plane goes down. It is important to point out that not all LDP enhancements require capability advertisement. For example, upstream label allocation does but inbound label filtering, where a speaker installs forwarding state for only certain FECs, does not. -2. Specification Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - -3. The LDP Capability Mechanism +2. The LDP Capability Mechanism Enhancements are likely to be announced during LDP session establishment as each LDP speaker advertises capabilities corresponding to the enhancements it desires. Beyond that, capability advertisements may be used to dynamically - modify the characteristics of the session to suit changing + modify the characteristics of the session to suit the changing conditions. For example, an LSR capable of a particular enhancement in support of some "feature" may not have advertised the corresponding capability to its peers at session establishment time - because the feature was disabled at that time. Later an operator may - enable the feature, at which time the LSR would react by advertising - the corresponding capability to its peers. Similarly, when an - operator disables a feature associated with a capability the LSR - reacts by withdrawing the capability advertisement from its peers. + because the feature was disabled at that time. Later, an operator + may enable the feature, at which time the LSR would react by + advertising the corresponding capability to its peers. Similarly, + when an operator disables a feature associated with a capability, the + LSR reacts by withdrawing the capability advertisement from its + peers. The LDP capability advertisement mechanism operates as follows: - - Each LDP speaker is assumed to implement a set of enhancements - each of which has an associated capability. At any time a - speaker may have none, one or more of those enhancements - "enabled". When an enhancement is enabled the speaker advertises - the associated capability to its peers. By advertising the - capability to a peer the speaker asserts that it shall perform - the protocol actions specified for the associated enhancement. - For example, the actions may involve receiving and processing - messages from a peer that the enhancement requires. Unless the - capability has been advertised the speaker will not perform - protocol actions specified for the corresponding enhancement. + - Each LDP speaker is assumed to implement a set of enhancements, + each of which has an associated capability. At any time, a + speaker may have none, one, or more of those enhancements + "enabled". When an enhancement is enabled, the speaker + advertises the associated capability to its peers. By + advertising the capability to a peer, the speaker asserts that it + shall perform the protocol actions specified for the associated + enhancement. For example, the actions may require the LDP speaker + to receive and process enhancement-specific messages from its + peer. Unless the capability has been advertised, the speaker will + not perform protocol actions specified for the corresponding + enhancement. - At session establishment time an LDP speaker MAY advertise a particular capability by including an optional parameter associated with the capability in its Initialization message. - - There is a well-known capability called Dynamic Capability - Announcement which an LDP speaker MAY advertise in its + - There is a well-known capability called "Dynamic Capability + Announcement" which an LDP speaker MAY advertise in its Initialization message to indicate that it is capable of - processing capability announcements following session + processing capability announcements following a session establishment. - If a peer had advertised the Dynamic Capability Announcement - capability in its Initialization message then at any time + If a peer had advertised the "Dynamic Capability Announcement" + capability in its Initialization message, then at any time following session establishment an LDP speaker MAY announce - changes in its advertised capabilities to that peer. To do this - the LDP speaker sends the peer a Capability message that + changes in its advertised capabilities to that peer. To do this, + the LDP speaker sends the peer a "Capability" message that specifies the capabilities being advertised or withdrawn. - When the capability advertisement mechanism is in place an LDP +2.1. Capability Document + + When the capability advertisement mechanism is in place, an LDP enhancement requiring LDP capability advertisement will be specified by a document that: - Describes the motivation for the enhancement; + - Specifies the behavior of LDP when the enhancement is enabled. This includes the procedures, parameters, messages, and TLVs required by the enhancement; - - Includes an IANA considerations section that notes that an IANA- - assigned code point for the optional parameter corresponding to - the enhancement is required. + - Includes an IANA considerations section that requests IANA for + assignment of code point for the optional parameter corresponding + to the enhancement. -4. Specifying Capabilities in LDP Messages +3. Specifying Capabilities in LDP Messages This document uses the term "Capability Parameter" to refer to an optional parameter that may be included in Initialization and Capability messages to advertise a capability. - The format of a TLV that is a Capability Parameter is: + The format of "Capability Parameter" 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| TLV Code Point | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | | +-+-+-+-+-+-+-+-+ Capability Data | | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: - U-bit - SHOULD be 1 (ignore if not understood). + U-bit: + The value could be either 0 or 1 as specified in Capability + document associated with given capability. F-bit: - SHOULD be 0 (don't forward if not understood). + MUST be 0 (i.e. don't forward if not understood). 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 [RFC5036] specifies the assignment of code points for LDP TLVs. S-bit: The State Bit indicates whether the sender is advertising or withdrawing the capability corresponding to the TLV Code Point. The State bit is used as follows: 1 - The TLV is advertising the capability specified by the TLV Code Point. @@ -204,340 +231,336 @@ Considerations" section of [RFC5036] specifies the assignment of code points for LDP TLVs. S-bit: The State Bit indicates whether the sender is advertising or withdrawing the capability corresponding to the TLV Code Point. The State bit is used as follows: 1 - The TLV is advertising the capability specified by the TLV Code Point. - 0 - The TLV is withdrawing the capability specified by the TLV Code Point. Capability Data: Information, if any, about the capability in addition to the TLV Code Point required to fully specify the capability. + The method for interpreting and processing this data is specific + to the TLV Code Point and MUST be described in the document + specifying the capability. - An LDP speaker MAY include more than one instance of a Capability - Parameter (as identified by the TLV Code Point) with different non- - empty Capability Data in an Initialization or Capability message. - The method for processing such Capability Parameters is specific to - the TLV Code Point and MUST be described in the document specifying - the capability. - - To ensure backward compatibility with existing implementations the - following TLVs play the role of a Capability Parameter when included - in Initialization messages: + An LDP speaker MUST NOT include more than one instance of a + Capability Parameter (as identified by the same TLV code point) in an + Initialization or Capability message. If an LDP speaker receives more + than one instance of the same Capability Parameter type in a message, + it SHOULD send a Notification message to peer before terminating the + session with peer. The Status Code in the Status TLV of the + Notification message MUST be "Malformed TLV" and the message SHOULD + contain the second "Capability Parameter TLV" of the same type (Code + point) that is received in the message. - - FT Session TLV [RFC3479] +3.1. Backward Compatibility TLVs - This document refers to such TLVs as Backward Compatibility TLVs. + Few LDP protocol extensions have been made in past to advertise and + negotiate some capability or extension at session establishment time. + These extensions usually define a new TLV which is directly included + in an Initialization message. One example of such extension is "FT + Session TLV" which is exchanged in Initialization message between + peers to announce LDP Fault Tolerance [RFC3479] capability. To + ensure backward compatibility with existing implementations, such + TLVs play the role of a "Capability Parameter" when included in + Initialization messages, and this document refers to such TLVs as + "Backward Compatibility TLVs". -5. Capability Message +4. Capability Message - The LDP Capability message is used by an LDP speaker subsequent to - session establishment to announce changes in the state for one or - more of its capabilities. + The LDP Capability message is used by an LDP speaker to announce + changes in the state of one or more of its capabilities subsequent to + session establishment. The format of the Capability message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Capability (IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV_1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV_N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - where TLV_1 through TLV_N are Capability Parameters. The S-bit of - each of the TLVs specifies the new state for the corresponding + where TLV_1 through TLV_N are "Capability Parameter" TLVs. The S-bit + of each of the TLVs specifies the new state for the corresponding capability. - Note that Backward Compatibility TLVs (see Section 4) MUST NOT be + Note that Backward Compatibility TLVs (see Section 3.1) MUST NOT be included in Capability messages. -6. Note on Terminology - - The sections that follow talk of enabling and disabling capabilities. - The terminology "enabling (or disabling) a capability" is short hand - for "advertising (or withdrawing) a capability associated with an - enhancement". Bear in mind that it is an LDP enhancement that is - enabled or disabled and that it is the corresponding capability that - is advertisted or withdrawn. +5. Note on Terminology -7. Procedures for Capability Parameters in Initialization Messages + The following sections in this document talk about enabling and + disabling capabilities. The terminology "enabling (or disabling) a + capability" is short hand for "advertising (or withdrawing) a + capability associated with an enhancement". Bear in mind that it is + an LDP enhancement that is being enabled or disabled, and that it is + the corresponding capability that is being advertisted or withdrawn. - An LDP speaker SHOULD NOT include more than one instance of a - Capability Parameter with the same type and value in an - Initialization message. Note, however, that processing multiple - instances of such a parameter does not require special handling, as - additional instances do not change the meaning of an announced - capability. +6. Procedures for Capability Parameters in Initialization Messages The S-bit of a Capability Parameter in an Initialization message MUST be 1 and SHOULD be ignored on receipt. This ensures that any Capability Parameter in an Initialization message enables the corresponding capability. - An LDP speaker determines the capabilities enabled by a peer by - examining the set of of Capability Parameters present in the - Initialization message received from the peer. + An LDP speaker determines the capabilities of a peer by examining the + set of of Capability Parameters present in the Initialization message + received from the peer. An LDP speaker MAY use a particular capability with its peer after the speaker determines that the peer has enabled that capability. - These procedures enable an LDP speaker A that advertises a specific - LDP capability C to establish an LDP session with speaker B that does - not advertise C. In this situation whether or not capability C may - be used for the session depends on the semantics of the enhancement - associated with C. If the semantics do not require both A and B - advertise C to one another then B could use it; that is, A's - advertisement of C permits B to send messages to A used by the + These procedures enable an LDP speaker S1, that advertises a specific + LDP capability C, to establish an LDP session with speaker S2 that + does not advertise C. In this situation whether or not capability C + may be used for the session depends on the semantics of the + enhancement associated with C. If the semantics do not require both + S1 and S2 advertise C to one another, then S2 could use it; i.e. S1's + advertisement of C permits S2 to send messages to S1 used by the enhancement. It is the responsibility of the capability designer to specify the behavior of an LDP speaker that has enabled a certain enhancement, advertised its capability and determines that its peer has not advertised the corresponding capability. The document specifying procedures for the capability MUST describe the behavior in this - situation. If the specified procedure is to terminate the session - the LDP speaker SHOULD send a Notification message to the peer before - terminating the session. The Status Code in the Status TLV of the - Notification message SHOULD be Unsupported Capability, and the - message SHOULD contain the unsupported capabilities (see Section 9 - for more details). In this case the session SHOULD NOT be re- - established automatically. How the session is re-established is - beyond the scope of this document. It depends on the LDP capability - and MUST be specified along with the procedures specifying the - capability. + situation. If the specified procedure is to terminate the session, + then the LDP speaker SHOULD send a Notification message to the peer + before terminating the session. The Status Code in the Status TLV of + the Notification message MUST be "Unsupported Capability" and the + message SHOULD contain the unsupported capability (see Section 8 for + more details). An LDP speaker that supports capability advertisement and includes a - Capability Parameter in its Initialization message SHOULD set the TLV - U bit to 1. This ensures that an [RFC5036] compliant peer that does - not support the capability mechanism will ignore the Capability - Parameter and allow the session to be established. + Capability Parameter in its Initialization message MUST set the TLV + U-bit to 0 or 1, as specified by "Capability" document. LDP speaker + should set U-bit to 1 if the capability document allows to continue + with a peer that does not understand the enhancement, and set U-bit + to 0 otherwise. If a speaker receives a message containng unsupported + capability, it responds according to U-bit setting in the TLV. If U- + bit is 1, then speaker MUST silently ignore the Capability Parameter + and allow the session to be established. However, if U-bit is 0, then + speaker SHOULD send a Notification message to the peer before + terminating the session. The Status Code in the Status TLV of the + Notification message MUST be "Unsupported Capability" and the + message SHOULD contain the unsupported capability (see Section 8 for + more details). -8. Procedures for Capability Parameters in Capability Messages +7. Procedures for Capability Parameters in Capability Messages An LDP speaker MUST NOT send a Capability message to a peer unless its peer had advertised the Dynamic Capability Announcement - capability in its session Initialization message (see Section 10). - - An LDP speaker MAY send a Capability message to a peer if its peer - had advertised the Dynamic Capability Announcement capability in its - session Initialization message (see Section 10). + capability in its session Initialization message. An LDP speaker MAY + send a Capability message to a peer if its peer had advertised the + Dynamic Capability Announcement capability in its session + Initialization message (see Section 9). An LDP speaker determines the capabilities enabled by a peer by determining the set of capabilities enabled at session initialization - (as specified in Section 7) and tracking changes to that set made by - Capability messages from the peer. + (as specified in Section 6) and tracking changes to that set made + by Capability messages from the peer. An LDP speaker that has enabled a particular capability MAY use the enhancement corresponding to the capability with a peer after the speaker determines that the peer has enabled the capability. -9. Extensions to Error Handling +8. Extensions to Error Handling - This document defines a new LDP status code named Unsupported - Capability. The E bit of the Status TLV carried in a Notification - message that includes this status code SHOULD be set to 0. + This document defines a new LDP status code named "Unsupported + Capability". The E-bit of the Status TLV carried in a Notification + message that includes this status code MUST be set to 0. - In addition, this document defines a new LDP TLV named Returned TLVs - TLV that MAY be carried in a Notification message. The U-bit setting - for a Returned TLVs TLV in a Notification message SHOULD be 1 and the - F-bit setting SHOULD be 0. + In addition, this document defines a new LDP TLV, named "Returned + TLVs" that MAY be carried in a Notification message. The U-bit + setting for a Returned TLVs TLV in a Notification message SHOULD be 1 + and the F-bit setting SHOULD be 0. - When the Status Code in a Notification message is Unsupported - Capability the message SHOULD specify the capabilities that are + When the Status Code in a Notification message is "Unsupported + Capability", the message SHOULD specify the capabilities that are unsupported. When the Notification message specifies the unsupported - capabilities it MUST include a Returned TLVs TLV which includes each - unsupported Capability Parameter. The Returned TLVs TLV MUST include - only the Capability Parameters for unsupported capabilities. In - addition, the Capability Parameter for each such capability SHOULD be - encoded as received from the peer. + capabilities, it MUST include a Returned TLVs TLV. The Returned TLVs + TLV MUST include only the Capability Parameters for unsupported + capabilities, and the Capability Parameter for each such capability + SHOULD be encoded as received from the peer. - When the Status Code in a Notification Message is Unknown TLV the + When the Status Code in a Notification Message is "Unknown TLV", the message SHOULD specify the TLV that was unknown. When the - Notification message specifies the TLV that was unknown it MUST + Notification message specifies the TLV that was unknown, it MUST include the unknown TLV in a Returned TLVs TLV. -10. Dynamic Capability Announcement TLV +9. Dynamic Capability Announcement TLV - The Dynamic Capability Announcement TLV is a Capability Parameter. - Its format is: + The Dynamic Capability Announcement TLV is a Capability Parameter + defined by this document with following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| DynCap Announcement (IANA)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |S| Reserved | + |1| Reserved | +-+-+-+-+-+-+-+-+ The Dynamic Capability Announcement Parameter MAY be included by an LDP speaker in an Initialization message to signal its peer that the speaker is capable of processing Capability messages. An LDP speaker MUST NOT include the Dynamic Capability Announcement Parameter in Capability messages sent to its peers. Once enabled - during session initialization the Dynamic Capability Announcement - capability cannot be disabled. + during session initialization, the Dynamic Capability Announcement + capability cannot be disabled. This implies that S-bit is always 1 + for Dynamic Capability Announcement. An LDP speaker that receives a Capability message from a peer that includes the Dynamic Capability Announcement Parameter SHOULD silently ignore the parameter and process any other Capability Parameters in the message. -11. Backward Compatibility +10. 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 [RFC5036] compliant peer has label distribution for IPv4 enabled - by default. To ensure compatibility with an [RFC5036] compliant peer - LDP implementations that support capability advertisement have label - distribution for IPv4 enabled until it is explicitly disabled and - MUST assume that their peers do as well. + by default. To ensure compatibility with an [RFC5036] compliant + peer, LDP implementations that support capability advertisement have + label distribution for IPv4 enabled until it is explicitly disabled + and MUST assume that their peers do as well. - Section 3 identifies a set of Backward Compatibility TLVs that may - appear in Initialization messages in the role of a Capability + Section 3.1 identifies a set of Backward Compatibility TLVs that + may appear in Initialization messages in the role of a Capability Parameter. This permits existing LDP enhancements that use an ad hoc mechanism for enabling capabilities at sesssion initialization time to continue to do so. -12. Security Considerations +11. Security Considerations The security considerations described in [RFC5036] that apply to the base LDP specification apply to the capability mechanism described in this document. -13. IANA Considerations +12. IANA Considerations This document specifies the following which require code points assigned by IANA: - LDP message code point for the Capability message. The authors request message type 0x0202 for the Capability message. - LDP TLV code point for the Dynamic Capability Announcemnt TLV. The authors request TLV type code 0x0506. - LDP TLV code point for the Returned TLVs TLV. The authors request TLV type 0x304. - - LDP Status Code code point for the Unsupported Capability - Status Code. The authors request Status Code 0x0000002C. + - LDP Status Code code point for the Unsupported Capability Status + Code. The authors request Status Code 0x0000002C. -14. Acknowledgements +13. Acknowledgments The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo, Yakov Rekhter, and Eric Rosen for their comments. -15. References + This document was prepared using 2-Word-v2.0.template.dot. - Normative References +14. References + +14.1. Normative References [RFC5036] Andersson, L., Menei, I., and Thomas, B., Editors, "LDP Specification", RFC 5036, September 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. [RFC3479] Farrel, A., Editor, "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003. - Informative References +14.2. Informative References [IALDP] Decraene, B., Le Roux, JL., Minei, I, "LDP Extensions for - Inter-Area LSPs", draft-decraene-mpls-ldp-interarea-04.txt, Work in - [MLDP] Minei, I., Wijnamds, I., Editors, "Label Distribution Protocol - Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label - Switched Paths", draft-minei-wijnands-mpls-ldp-p2mp-00.txt, Work in - Progress, September 2005 + Inter-Area LSPs", draft-decraene-mpls-ldp-interarea-04.txt, + [MLDP] Minei, I., Wijnamds, I., Editors, "Label Distribution + Protocol Extensions for Point-to-Multipoint and Multipoint- + to-Multipoint Label Switched Paths", draft-minei-wijnands- + mpls-ldp-p2mp-00.txt, Work in Progress, September 2005 [NNHOP] Shen, N., Chen, E., Tian, A. "Discovery LDP Next-Nexthop - Labels", draft-shen-mpls-ldp-nnhop-label-02.txt, Work in Progress, + Labels", draft-shen-mpls-ldp-nnhop-label-02.txt, Work in [RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. Heron, - "Pseudowire Setup and Maintenance using the Label Distribution - Protocol", RFC 4447, April 2006. + "Pseudowire Setup and Maintenance using the Label + Distribution Protocol", RFC 4447, April 2006. [RFC3478] Leelanivas, M., Rekhter, Y, Aggarwal, R., "Graceful Restart - Mechanism for Label Distribution Protocol (LDP)", RFC 3478, February - 2003. + Mechanism for Label Distribution Protocol (LDP)", RFC 3478, + February 2003. [UPSTREAM_LDP] Aggarwal R., Le Roux, J.L., "MPLS Upstream Label - Assignment for LDP" draft-ietf-mpls-ldp-upstream-00.txt, Work in - Progress, February 2006. + Assignment for LDP" draft-ietf-mpls-ldp-upstream-00.txt, + Work in Progress, February 2006. -16. Author Information +15. Author's Addresses + + Bob Thomas + Cisco Systems, Inc. + 1414 Massachusetts Ave. + Boxborough, MA 01719 + E-mail: rhthomas@cisco.com Shivani Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: shivani@juniper.net Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net Jean-Louis Le Roux France Telecom - 2, avenue Pierre-Marzin - 22307 Lannion Cedex - France - E-mail: jeanlouis.leroux@orange_ftgroup.com + 2, Avenue Pierre-Marzin + 22307 Lannion Cedex, France + E-mail: jeanlouis.leroux@orange-ftgroup.com - Bob Thomas + Syed Kamran Raza Cisco Systems, Inc. - 1414 Massachusetts Ave. - Boxborough MA 01719 - E-mail: rhthomas@cisco.com - -17. Intellectual Property Statement - - 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. + 2000 Innovation Dr. + Kanata, ON K2K-3E8, Canada + E-mail: skraza@cisco.com - 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. +Copyright Notice -18. Full Copyright Statement + Copyright (c) 2009 IETF Trust and the persons identified as + the document authors. All rights reserved. - Copyright (C) The IETF Trust (2008). + This document is subject to BCP 78 and the IETF Trust's + Legal Provisions Relating to IETF Documents in effect on the + date of publication of this document + (http://trustee.ietf.org/license-info). Please review these + documents carefully, as they describe your rights and + restrictions with respect to this document. - 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. +Legal - 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. + This documents and the information contained therein 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 THEREIN WILL NOT INFRINGE + ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS + FOR A PARTICULAR PURPOSE.