Network Working Group Naiming Shen Internet Draft Albert Jining Tian Expiration Date: January 2005 Redback Networks July 2004 IS-IS Extended TLV For Code and Length Size Beyond One Octet draft-shen-isis-extended-tlv-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes an extension to IS-IS protocol that extends the code and length fields of IS-IS TLV to two octets each. The extension is backwards compatible to existing IS-IS implementation. A transition mechanism for the deployment of the new extension is also described. 1. Introduction The IS-IS protocol defined in [1] uses TLV-encoded variable length fields to carry IS-IS routing and other protocol information in the IS-IS packets. The code and length fields are both one octet in size. Thus the maximum code space is only 255 Shen & Tian Expires January 2005 [Page 1] Internet Draft IS-IS Extended TLV July 2004 and each TLV can only have the maximum of 253 octets for the value field. With more functionalities being introduced into IS-IS and with new extensions may require new TLV codes to be assigned, it is likely the IS-IS TLV code space will deplete in the near future. Certain IS-IS TLVs, such as the extended IS reachability TLV [2], already has large number of sub-TLV defined. With increasingly more sub-TLVs to be defined for different applications, it may cause those TLVs to exceed the 255 octet in length. Some other IS-IS TLVs, such as the extended IP reachability TLV, must repeat itself multiple times in order to accommodate large number of TLV elements such as IP prefixes. If we can remove the 255 TLV size limit, we may simplify the generation and processing of such TLVs. In this document, a backwards compatible mechanism is proposed to extend the IS-IS TLV code and length size limit beyond the one octet. A network transition mechanism is also described. 2. Terminology 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 RFC 2119 [3]. 3. IS-IS Extended TLV 3.1 Encoding The IS-IS Extended TLV is defined as TLV type 255 (to be assigned by IANA). The Extended 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (255) | Length (Lo) | Length (Hi) | Extended Type // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Extended Type | Value // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type An 8 bit field. The code is 255, and needs to be allocated by IANA. Shen & Tian Expires January 2005 [Page 2] Internet Draft IS-IS Extended TLV July 2004 Length (Lo) An 8 bit field. It is the lower order octet of the 16 bit length for the Extended TLV. Length (Hi) An 8 bit field. It is the higher order octet of the 16 bit length for the Extended TLV. The length of the Extended TLV is 16 bits by combining the Length (Lo) and Length (Hi) fields. The Extended TLV length does not include the Type and Length (Lo) fields. The Extended TLV length is the length of the Value field plus 3. Extended Type An 16 bit field. It can be any number in the range of 0 to 65535 except for the number 255. This Extended Type includes the existing TLV type values other than 255. Value A variable length field. The length of the Value field is the Extended TLV length minus 3 octets. 3.2 Mechanism The IS-IS system advertising the Extended TLV needs to encode the real type value in the 16 bit Extended Type field. This Extended Type values inherit the traditional IS-IS TLV code values which is in the range of 0-254. The number 255 is the Extended TLV code itself and it can not be used for the Extended Type value. The Length fields have two 8 bit fields. The two fields combination makes the 16 bit in size. When using the Extended TLV to advertise the traditional IS-IS TLV information, the length is 3 octets larger than the traditional TLV length. In other words, the maximum size of the Value field is 3 octets smaller. The reason Extended TLV length encoded as Length (Lo) and Length (Hi) two parts is for backwards compatible to the existing IS-IS systems. As long as the Length (Hi) number is zero, this Extended TLV is compatible to the normal IS-IS TLV. The systems not recognizing this Extended TLV extension are able to skip this TLV. This is important for the network transition as described in the next section. This is the same reason for the Extended TLV length to include the length of the Value file plus the length of the Length (Hi) and the length of the Extended Type. Even when the Extended Type code is in the range of 0-254, it is Shen & Tian Expires January 2005 [Page 3] Internet Draft IS-IS Extended TLV July 2004 able to use the length larger than 255 as long as all the systems in the network recognize this Extended TLV extension. The Extended TLV length is bounded by the IS-IS packet size. 4. Backwards Compatibility and Network Transition When this Extended TLV is used in LSP packet, all the systems within the same area/level MUST understand this extension. When it is used in other IS-IS packets, all the neighbors of this system MUST understand this extension. Thus the backwards compatibility to the existing systems and network transition needs to be addressed. This is similar to the IS-IS TE [2] metric style transition in an IS-IS network. 4.1 TLV Modes An IS-IS system can be in one of the three modes in terms of TLV style. The traditional TLV mode, the transitional TLV mode, and the Extended TLV mode. The traditional TLV mode and the Extended TLV mode are mutual exclusive in a network. - A system in the traditional TLV mode does not generate any Extended TLV nor does it recognize them. - A system in the transitional TLV mode understands the Extended TLV format in received IS-IS packets. If the system needs to generate an Extended TLV in the IS-IS packets, it MUST also generate its correspondent normal IS-IS TLV. The value in both TLVs Must be the same. The system will advertise the same information twice. One uses the Extended TLV and the other uses the normal TLV. In this mode, the extended TLV Length(Hi) field MUST be zero. The Extended Type number Must be the same as the Type number in the normal TLV. The Length (Lo) field has the number which is the number in the Length field of the normal TLV plus 3. - A system in Extended TLV mode MAY generate Extended TLV without its correspondent normal Extended TLV. In this mode when there exists Extended TLV in the network, all the systems in the network has to be either in the transitional TLV mode or in the Extended TLV mode. 4.2 TLV Style Network Transition When a network start to introduce the IS-IS Extended TLVs, each system being converted needs to be configured as in the transitional TLV mode. Thus all the TLVs, traditional and extended ones can be recognized by all the systems in the network. After all the systems in the network are converted to the transitional Shen & Tian Expires January 2005 [Page 4] Internet Draft IS-IS Extended TLV July 2004 TLV mode, the systems can be changed one by one into the Extended TLV mode. After every system is converted into the Extended TLV mode, the network transition is accomplished. 4.3 Operation A system is configured as the Extended TLV mode or the transitional TLV mode does not mean any or all the TLVs should be encoded in the Extended TLV style. It SHOULD advertise using the Extended TLV only if it can use the benefit of the Extended TLV, and it will understand the Extended TLV format when other systems advertise them. Since a system in the Extended TLV mode does not have to advertise any Extended TLV in the packets it generates, it will be useful from operation and troubleshooting point of view for a system to advertise the Extended TLV capability to the network. The exact mechanism of advertising this capability is outside the scope of this document. The transition scheme in section 4.2 assumes some IS-IS systems advertise the Extended TLVs during the transition. If none of the system in the network advertise the Extended TLV during the transition, then each system can be converted from the traditional TLV mode directly into the Extended TLV mode directly without going through the transitional TLV mode. 5. IANA Considerations This Extended TLV extension uses the IS-IS TLV type 255. This Extended TLV code needs to be assigned. 6. Security Considerations This document does not change the security aspects of IS-IS. Security considerations for the protocol still apply. For more information see [4]. 7. Acknowledgments The authors would like to thank Enke Chen and Acee Lindem for their comments to this document. 8. References [1] ISO. Information Technology - Telecommunications and Shen & Tian Expires January 2005 [Page 5] Internet Draft IS-IS Extended TLV July 2004 Information Exchange between Systems - Intermediate System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service. ISO, 1990. [2] Smit, H., Li, T., "IS-IS Extensions for Traffic Engineering", RFC 3784, May 2004. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] T. Li, R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003. 9. Authors' Addresses Naiming Shen Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 Email: naiming@redback.com Albert Jining Tian Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 Email: tian@redback.com Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary Shen & Tian Expires January 2005 [Page 6] Internet Draft IS-IS Extended TLV July 2004 rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Notice Copyright (C) The Internet Society (2004). 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 is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Shen & Tian Expires January 2005 [Page 7]