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]