Network Working Group S. Aggarwal Internet Draft Juniper Networks Expiration Date: December 2006 R. Aggarwal Juniper Networks J. L. Le Roux France Telecom June 2006 Capabilities Advertisement with LDP draft-shivani-mpls-ldp-capability-00.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. 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." 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. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Shivani, Raggarwa & Le Roux [Page 1] Internet Draft draft-shivani-mpls-ldp-capability-00.txt June 2006 Abstract This document defines a new Optional Parameter, called Capabilities TLV, that is expected to facilitate the introduction of new capabilities in the Label Distribution Protocol (LDP) by providing graceful capability advertisement without requiring that LDP peering be terminated. The "LDP peering" in this document refers to the TCP connection between the 2 routers and not the actual session. The "LDP session" refers to the connection after the initialization message has been successfully processed and the session is marked operational. Table of Contents 1 Specification of requirements ......................... 2 2 Overview of Operations ................................ 3 3 Capabilities TLV ...................................... 4 4 Extensions to Error Handling .......................... 5 5 IANA Considerations ................................... 6 6 Security Considerations ............................... 6 7 Acknowledgements ...................................... 6 8 References ............................................ 6 9 Author Information .................................... 7 10 Intellectual Property Statement ....................... 7 11 Full Copyright Statement .............................. 8 1. Specification of requirements 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]. Shivani, Raggarwa & Le Roux [Page 2] Internet Draft draft-shivani-mpls-ldp-capability-00.txt June 2006 2. Overview of Operations When a LDP speaker that supports capabilities advertisement sends an INITIALIZATION message to its LDP peer, the message MAY include an Optional Parameter, called Capabilities TLV. The parameter lists the capabilities supported by the speaker. A LDP speaker determines the capabilities supported by its peer by examining the list of capabilities present in the Capabilities TLV Optional Parameter carried by the INITIALIZATION message that the speaker receives from the peer. A LDP speaker that supports a particular capability may use this capability with its peer after the speaker determines (as described above) that the peer supports this capability. A LDP speaker determines that its peer doesn't support capabilities advertisement, if in response to an INITIALIZATION message that carries the Capabilities TLV Optional Parameter, the speaker receives a NOTIFICATION message with the Status Code of the Status TLV set to Unknown TLV. This assumes that the speaker knows which TLV was considered as an Unknown TLV by its peer. In this case, the speaker SHOULD attempt to re-establish a LDP connection with the peer without sending to the peer the Capabilities TLV Optional Parameter. If a LDP speaker that supports a certain capability determines that its peer doesn't support this capability, the speaker MAY send a NOTIFICATION message to the peer, and terminate peering (see Section "Extensions to Error Handling" for more details). The Status Code in the Status TLV of the NOTIFICATION message is set to Unsupported Capability. The message SHOULD contain the capability (capabilities) that caused the speaker to send the message. The decision to send the message and terminate peering is local to the speaker. If terminated, such peering SHOULD NOT be re-established automatically. How the session is re-established is beyond the scope of this document. It is dependent on the capability and MUST be specified along with the procedures specifying the LDP capability. These procedures enable a LDP speaker A, that supports the LDP Capabilities TLV to establish a LDP session with a LDP speaker B, that does not support the LDP Capabilities TLV. However the capabilities that LDP speaker A advertises in the Capabilities TLV, can not be used between LDP speakers A and B, in this case. These procedures also enable a LDP speaker C, that supports a specific LDP capability, to establish a LDP session with a LDP speaker D, that does not support this specific capability, though LDP speaker D may support the LDP Capabilities TLV. However this specific capability supported by LDP speaker C, can not be used between LDP Shivani, Raggarwa & Le Roux [Page 3] Internet Draft draft-shivani-mpls-ldp-capability-00.txt June 2006 speakers C and D in this case. Further these procedures provide the choice to LDP speakers A and C to terminate the LDP session with LDP speakers B and D respectively. Whether LDP speakers A and C decide to do this or not is dependent on the LDP capability that is not supported by LDP speakers B and D and MUST be specified along with the procedures specifying the LDP capability. 3. Capabilities TLV This is an Optional Parameter that is used by a LDP speaker to convey to its LDP peer the list of capabilities supported by the speaker. This new optional paramter is called the Capabilities TLV and it contains one or more sub-TLVs, each to signal a specific capability. Following is the format of the LDP Capability TLV: 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|0| Capability TLV (0x0504) | Length (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type : To be assigned by IANA. Suggested value is 0x0504 Length: Variable Each capability sub-TLV is encoded as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Capability Code | Capability Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capability Value (variable) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The use and meaning of these fields are as follows: Capability Code: Capability Code is a two octets field that unambiguously identifies individual capabilities. Capability codes are to be assigned by IANA. Shivani, Raggarwa & Le Roux [Page 4] Internet Draft draft-shivani-mpls-ldp-capability-00.txt June 2006 Capability Length: Capability Length is a two octets field that contains the length of the Capability Value field in octets. Capability Value: Capability Value is a variable length field that is interpreted according to the value of the Capability Code field. LDP speakers SHOULD NOT include more than one instance of a capability with the same Capability Code, Capability Length, and Capability Value. Note however, that processing of multiple instances of such capability does not require special handling, as additional instances do not change the meaning of announced capability. 4. Extensions to Error Handling This document defines new Status Code - Unsupported Capability. The value of this Subcode is to be assigned by IANA. The 'E' bit of the Status TLV in the NOTIFICATION message SHOULD be set to 0. The NOTIFICATION message SHOULD list the set of capabilities that caused the speaker to send the message. For this purpose, a new Optional Parameter, Returned TLV is added to the NOTIFICATION message. The value of this Optional Parameter, Returned TLV, is to be assigned by IANA. The suggested value is 0x0505. The 'U' and 'F' bit of the Returned TLV in the NOTIFICATION message is TBD and will be specified when the value of the Returned TLV is defined. If the Status Subcode is UNKNOWN TLV, the Returned TLV MUST contain the Capability TLV that wasn't understood. If the Status Subcode is Unsupported Capability, the Capability TLV MUST be encoded in the Returned TLV Optional Paramter of the NOTIFICATION message with only the capabilities that aren't supported. Each such capability is encoded the same way as it would be encoded in the INITIALIZATION Shivani, Raggarwa & Le Roux [Page 5] Internet Draft draft-shivani-mpls-ldp-capability-00.txt June 2006 message. 5. IANA Considerations This document defines a Capability TLV. We would like to request type 0x0504, to be assigned by IANA to this TLV. IANA maintains the registry for Capability Code values. Capability Code value 0 is reserved. Capability Code values 1 through 63 are to be assigned by IANA using the "IETF Consensus" policy defined in RFC 2434. Capability Code values 64 through 127 are to be assigned by IANA, using the "First Come First Served" policy defined in RFC 2434. Capability Code values 128 through 255 are for "Private Use" as defined in RFC 2434. This document also defines a Returned TLV and we would like to request type 0x0505, to be assigned by IANA to this TLV. This document defines new Status Code for the LDP Status TLV: Unsupported Capability. The value of this subcode is to be assigned by IANA. 6. Security Considerations This extension to LDP does not change the underlying security issues inherent in the existing LDP [RFC3036]. 7. Acknowledgements This extension to LDP is modelled after a similar extension to the Border Gateway Protocol for capability advertisement [RFC3392]. Thanks to Ina Minei for her comments. 8. References [RFC3036] L. Andersson, et. al., "LDP Specification", January 2001. [RFC3392] R. Chandra, et. al., "Capabilities Advertisement with BGP-4", November 2002 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels.", Bradner, March 1997 Shivani, Raggarwa & Le Roux [Page 6] Internet Draft draft-shivani-mpls-ldp-capability-00.txt June 2006 9. Author Information 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@francetelecom.com 10. 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. 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. Shivani, Raggarwa & Le Roux [Page 7] Internet Draft draft-shivani-mpls-ldp-capability-00.txt June 2006 11. Full Copyright Statement Copyright (C) The Internet Society (2006). All Rights Reserved. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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. Shivani, Raggarwa & Le Roux [Page 8]