Network Working Group H. Smit Request for Comments: 3784 Procket Networks Category: Informational T. Li June 2004 Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004).
AbstractThis document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations. 1], with extensions for supporting IPv4 specified in RFC 1195 . Each Intermediate System (IS) (router) advertises one or more IS-IS Link State Protocol Data Units (LSPs) with routing information. Each LSP is composed of a fixed header and a number of tuples, each consisting of a Type, a Length, and a Value. Such tuples are commonly known as TLVs, and are a good way of encoding information in a flexible and extensible format. This document contains the design of new TLVs to replace the existing IS Neighbor TLV, IP Reachability TLV, and to include additional information about the characteristics of a particular link to an IS- IS LSP. The characteristics described in this document are needed for Traffic Engineering  (TE). Secondary goals include increasing the dynamic range of the IS-IS metric and improving the encoding of IP prefixes.
The router id is useful for traffic engineering purposes because it describes a single address that can always be used to reference a particular router. Mechanisms and procedures to migrate to the new TLVs are not discussed in this document. 1]) contains information about a series of IS neighbors. For each neighbor, there is a structure that contains the default metric, the delay, the monetary cost, the reliability, and the 7-octet ID of the adjacent neighbor. Of this information, the default metric is commonly used. The default metric is currently one octet, with one bit used to indicate whether the metric is internal or external, and one bit that was originally unused, but which was later defined by RFC 2966 to be the up/down bit. The remaining 6 bits are used to store the actual metric, resulting in a possible metric range of 0- 63. This limitation is one of the restrictions that we would like to lift.
The remaining three metrics (delay, monetary cost, and reliability) are not commonly implemented and reflect unused overhead in the TLV. The neighbor is identified by its system ID, typically 6-octets, plus one octet indicating the pseudonode number. Thus, the existing TLV consumes 11 octets per neighbor, with 4 octets for metric and 7 octets for neighbor identification. To indicate multiple adjacencies, this structure is repeated within the IS reachability TLV. Because the TLV is limited to 255 octets of content, a single TLV can describe up to 23 neighbors. The IS reachability TLV can be repeated within the LSP fragments to describe further neighbors. The proposed extended IS reachability TLV contains a new data structure, consisting of: 7 octets of system Id and pseudonode number 3 octets of default metric 1 octet of length of sub-TLVs 0-244 octets of sub-TLVs, where each sub-TLV consists of a sequence of 1 octet of sub-type 1 octet of length of the value field of the sub-TLV 0-242 octets of value Thus, if no sub-TLVs are used, the new encoding requires 11 octets and can contain up to 23 neighbors. Please note that while the encoding allows for 255 octets of sub-TLVs, the maximum value cannot fit in the overall IS reachability TLV. The practical maximum is 255 octets minus the 11 octets described above, or 244 octets. Further, there is no defined mechanism for extending the sub-TLV space for a particular neighbor. Thus, wasting sub-TLV space is discouraged. The metric octets are encoded as a 24-bit unsigned integer. Note that the metric field in the new extended IP reachability TLV is encoded as a 32-bit unsigned integer. These different sizes were chosen so that it is very unlikely that the cost of an intra-area route has to be chopped off to fit in the metric field of an inter- area route. To preclude overflow within a traffic engineering SPF implementation, all metrics greater than or equal to MAX_PATH_METRIC SHALL be considered to have a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link metric does not overflow the number of bits for internal metric calculation. We assume that this is 32 bits. Therefore, we have chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25).
If a link is advertised with the maximum link metric (2^24 - 1), this link MUST NOT be considered during the normal SPF computation. This will allow advertisement of a link for purposes other than building the normal Shortest Path Tree. An example is a link that is available for traffic engineering, but not for hop-by-hop routing. Certain sub-TLVs are proposed here: Sub-TLV type Length (octets) Name 3 4 Administrative group (color) 6 4 IPv4 interface address 8 4 IPv4 neighbor address 9 4 Maximum link bandwidth 10 4 Reservable link bandwidth 11 32 Unreserved bandwidth 18 3 TE Default metric 250-254 Reserved for cisco specific extensions 255 Reserved for future expansion Each of these sub-TLVs is described below. Unless stated otherwise, multiple occurrences of the information are supported by multiple inclusions of the sub-TLV.
If a router implements the basic TLV extensions in this document, it MAY add or omit this sub-TLV from the description of an adjacency. If a router implements traffic engineering, it MUST include this sub-TLV.
default metric has a possible range of 0-63. We would like to remove this restriction. In addition, route redistribution (a.k.a. route leaking) has a key problem that was not fully addressed by the existing IP reachability TLVs. RFC 1195  allows a router to advertise prefixes upwards in the level hierarchy. Unfortunately there were no mechanisms defined to advertise prefixes downwards in the level hierarchy. To address these two issues, the proposed extended IP reachability TLV provides for a 32 bit metric and adds one bit to indicate that a prefix has been redistributed 'down' in the hierarchy. The proposed extended IP reachability TLV contains a new data structure, consisting of: 4 octets of metric information 1 octet of control information, consisting of 1 bit of up/down information 1 bit indicating the presence of sub-TLVs 6 bits of prefix length 0-4 octet of IPv4 prefix 0-250 optional octets of sub-TLVs, if present consisting of 1 octet of length of sub-TLVs 0-249 octets of sub-TLVs, where each sub-TLV consists of a sequence of 1 octet of sub-type 1 octet of length of the value field of the sub-TLV 0-247 octets of value This data structure can be replicated within the TLV, without exceeding the maximum length of the TLV. The 6 bits of prefix length can have the values 0-32 and indicate the number of significant bits in the prefix. The prefix is encoded in the minimal number of octets for the given number of significant bits. This implies: Significant bits Octets 0 0 1-8 1 9-16 2 17-24 3 25-32 4 The remaining bits of prefix are transmitted as zero and ignored upon receipt.
If a prefix is advertised with a metric larger then MAX_PATH_METRIC (0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered during the normal SPF computation. This allows advertisement of a prefix for purposes other than building the normal IP routing table. RFC 1195  poses is to allow only advertising prefixes upward in the level hierarchy, and to disallow the advertising of prefixes downward in the hierarchy. To prevent this looping of prefixes between levels, a new bit of information is defined in the new extended IP reachability TLV. This bit is called the up/down bit. The up/down bit SHALL be set to 0 when a prefix is first injected into IS-IS. If a prefix is advertised from a higher level to a lower level (e.g. level 2 to level 1), the bit MUST be set to 1, indicating that the prefix has traveled down the hierarchy. Prefixes that have the up/down bit set to 1 may only be advertised down the hierarchy, i.e. to lower levels. These semantics apply even if IS-IS is extended in the future to have additional levels. By insuring that prefixes follow only the IS-IS hierarchy, we have insured that the information does not loop, thereby insuring that there are no persistent forwarding loops. If a prefix is advertised from one area to another at the same level, then the up/down bit SHALL be set to 1. This situation can arise when a router implements multiple virtual routers at the same level, but in different areas. The semantics of the up/down bit in the new extended IP reachability TLV are identical to the semantics of the up/down bit defined in RFC 2966 .
5]). Taking into consideration allocations specified in this document, the registry has been initialized as follows: Type Description ---- ----------------------------------- 0-2 unassigned 3 Administrative group (color) 4-5 unassigned 6 IPv4 interface address 7 unassigned 8 IPv4 neighbor address 9 Maximum link bandwidth 10 Reservable link bandwidth 11 Unreserved bandwidth 12-17 unassigned 18 TE Default metric 19-254 unassigned 255 Reserved for future expansion
5]). No codepoints are defined in this document.  ISO, "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", International Standard 10589:2002, Second Edition  Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.  Callon, R.W., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
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. Intellectual Property 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- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.