From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3784.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc3784.txt (limited to 'doc/rfc/rfc3784.txt') diff --git a/doc/rfc/rfc3784.txt b/doc/rfc/rfc3784.txt new file mode 100644 index 0000000..208fa97 --- /dev/null +++ b/doc/rfc/rfc3784.txt @@ -0,0 +1,731 @@ + + + + + + +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). + +Abstract + + This 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. Introduction + + The IS-IS protocol is specified in ISO 10589 [1], with extensions for + supporting IPv4 specified in RFC 1195 [3]. 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 [4] (TE). Secondary goals include increasing + the dynamic range of the IS-IS metric and improving the encoding of + IP prefixes. + + + + +Smit & Li Informational [Page 1] + +RFC 3784 IS-IS extensions for Traffic Engineering June 2004 + + + 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. + +2. Introducing Sub-TLVs + + This document introduces a new way to encode routing information in + IS-IS. The new object is called a sub-TLV. Sub-TLVs are similar to + regular TLVs. They use the same concepts as regular TLVs. The + difference is that TLVs exist inside IS-IS packets, while sub-TLVs + exist inside TLVs. TLVs are used to add extra information to IS-IS + packets. Sub-TLVs are used to add extra information to particular + TLVs. Each sub-TLV consists of three fields, a one-octet Type field, + a one-octet Length field, and zero or more octets of Value. The Type + field indicates the type of items in the Value field. The Length + field indicates the length of the Value field in octets. Each sub- + TLV can potentially hold multiple items. The number of items in a + sub-TLV can be computed from the length of the whole sub-TLV, when + the length of each item is known. Unknown sub-TLVs are to be ignored + and skipped upon receipt. + + The Sub-TLV type space is managed by the IETF IS-IS WG + (http://www.ietf.org/html.charters/isis-charter.html). New type + values are allocated following review on the IETF IS-IS mailing list. + This will normally require publication of additional documentation + describing how the new type is used. In the event that the IS-IS + working group has disbanded the review shall be performed by a + Designated Expert assigned by the responsible Area Director. + +3. The Extended IS Reachability TLV + + The extended IS reachability TLV is TLV type 22. + + The existing IS reachability (TLV type 2, defined in ISO 10589 [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. + + + +Smit & Li Informational [Page 2] + +RFC 3784 IS-IS extensions for Traffic Engineering June 2004 + + + 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). + + + + + + +Smit & Li Informational [Page 3] + +RFC 3784 IS-IS extensions for Traffic Engineering June 2004 + + + 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. + +3.1. Sub-TLV 3: Administrative group (color, resource class) + + The administrative group sub-TLV contains a 4-octet bit mask assigned + by the network administrator. Each set bit corresponds to one + administrative group assigned to the interface. + + By convention, the least significant bit is referred to as 'group 0', + and the most significant bit is referred to as 'group 31'. + + This sub-TLV is OPTIONAL. This sub-TLV SHOULD appear once at most in + each extended IS reachability TLV. + +3.2. Sub-TLV 6: IPv4 interface address + + This sub-TLV contains a 4-octet IPv4 address for the interface + described by the (main) TLV. This sub-TLV can occur multiple times. + + Implementations MUST NOT inject a /32 prefix for the interface + address into their routing or forwarding table because this can lead + to forwarding loops when interacting with systems that do not support + this sub-TLV. + + + + + + + +Smit & Li Informational [Page 4] + +RFC 3784 IS-IS extensions for Traffic Engineering June 2004 + + + 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. + +3.3. Sub-TLV 8: IPv4 neighbor address + + This sub-TLV contains a single IPv4 address for a neighboring router + on this link. This sub-TLV can occur multiple times. + + Implementations MUST NOT inject a /32 prefix for the neighbor address + into their routing or forwarding table because this can lead to + forwarding loops when interacting with systems that do not support + this 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 on point-to-point adjacencies. + +3.4. Sub-TLV 9: Maximum link bandwidth + + This sub-TLV contains the maximum bandwidth that can be used on this + link in this direction (from the system originating the LSP to its + neighbors). This is useful for traffic engineering. + + The maximum link bandwidth is encoded in 32 bits in IEEE floating + point format. The units are bytes (not bits!) per second. + + This sub-TLV is optional. This sub-TLV SHOULD appear once at most in + each extended IS reachability TLV. + +3.5. Sub-TLV 10: Maximum reservable link bandwidth + + This sub-TLV contains the maximum amount of bandwidth that can be + reserved in this direction on this link. Note that for + oversubscription purposes, this can be greater than the bandwidth of + the link. + + The maximum reservable link bandwidth is encoded in 32 bits in IEEE + floating point format. The units are bytes (not bits!) per second. + + This sub-TLV is optional. This sub-TLV SHOULD appear once at most in + each extended IS reachability TLV. + + + + + + + +Smit & Li Informational [Page 5] + +RFC 3784 IS-IS extensions for Traffic Engineering June 2004 + + +3.6. Sub-TLV 11: Unreserved bandwidth + + This sub-TLV contains the amount of bandwidth reservable in this + direction on this link. Note that for oversubscription purposes, + this can be greater than the bandwidth of the link. + + Because of the need for priority and preemption, each head end needs + to know the amount of reserved bandwidth at each priority level. + Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers. + The units are bytes (not bits!) per second. The values correspond to + the bandwidth that can be reserved with a setup priority of 0 through + 7, arranged in increasing order with priority 0 occurring at the + start of the sub-TLV, and priority 7 at the end of the sub-TLV. + + For stability reasons, rapid changes in the values in this sub-TLV + SHOULD NOT cause rapid generation of LSPs. + + This sub-TLV is optional. This sub-TLV SHOULD appear once at most in + each extended IS reachability TLV. + +3.7. Sub-TLV 18: Traffic Engineering Default Metric + + This sub-TLV contains a 24-bit unsigned integer. This metric is + administratively assigned and can be used to present a differently + weighted topology to traffic engineering SPF calculations. + + 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). + + This sub-TLV is optional. This sub-TLV SHOULD appear once at most in + each extended IS reachability TLV. If a link is advertised without + this sub-TLV, traffic engineering SPF calculations MUST use the + normal default metric of this link, which is advertised in the fixed + part of the extended IS reachability TLV. + +4. The Extended IP Reachability TLV + + The extended IP reachability TLV is TLV type 135. + + The existing IP reachability TLVs (TLV type 128 and TLV type 130, + defined in RFC 1195 [3]) carry IP prefixes in a format that is + analogous to the IS neighbor TLV from ISO 10589 [1]. They carry four + metrics, of which only the default metric is commonly used. The + + + +Smit & Li Informational [Page 6] + +RFC 3784 IS-IS extensions for Traffic Engineering June 2004 + + + 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 [3] 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. + + + + +Smit & Li Informational [Page 7] + +RFC 3784 IS-IS extensions for Traffic Engineering June 2004 + + + 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. + +4.1. The up/down Bit + + If routers were allowed to redistribute IP prefixes freely in both + directions between level 1 and level 2 without any additional + mechanisms, those routers would not be able to determine looping of + routing information. A problem occurs when a router learns a prefix + via level 2 routing and advertises that prefix down into a level 1 + area, where another router might pick up the route and advertise the + prefix back up into the level 2 backbone. If the original source + withdraws the prefix, those two routers might end up having a routing + loop between them, where part of the looped path is via level 1 + routing and the other part of the looped path is via level 2 routing. + The solution that RFC 1195 [3] 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 [2]. + + + + + + + + +Smit & Li Informational [Page 8] + +RFC 3784 IS-IS extensions for Traffic Engineering June 2004 + + +4.2. Expandability of the Extended IP Reachability TLV with Sub-TLVs + + The extended IP reachability TLV can hold sub-TLVs that apply to a + particular prefix. This allows for easy future extensions. If there + are no sub-TLVs associated with a prefix, the bit indicating the + presence of sub-TLVs SHALL be set to 0. If this bit is set to 1, the + first octet after the prefix will be interpreted as the length of all + sub-TLVs associated with this IPv4 prefix. Please note that while + the encoding allows for 255 octets of sub-TLVs, the maximum value + cannot fit in the overall extended IP reachability TLV. The + practical maximum is 255 octets minus the 5-9 octets described above, + or 250 octets. + + This document does not define any sub-TLVs for the extended IP + reachability TLV. + +5. The Traffic Engineering Router ID TLV + + The Traffic Engineering router ID TLV is TLV type 134. + + The router ID TLV contains the 4-octet router ID of the router + originating the LSP. This is useful in several regards: + + For traffic engineering, it guarantees that we have a single stable + address that can always be referenced in a path that will be + reachable from multiple hops away, regardless of the state of the + node's interfaces. + + If OSPF is also active in the domain, traffic engineering can compute + the mapping between the OSPF and IS-IS topologies. + + If a router does not implement traffic engineering, it MAY add or + omit the Traffic Engineering router ID TLV. If a router implements + traffic engineering, it MUST include this TLV in its LSP. This TLV + SHOULD not be included more than once in an LSP. + + If a router advertises the Traffic Engineering router ID TLV in its + LSP, and if it advertises prefixes via the Border Gateway Protocol + (BGP) with the BGP next hop attribute set to the BGP router ID, the + Traffic Engineering router ID SHOULD be the same as the BGP router + ID. + + Implementations MUST NOT inject a /32 prefix for the router ID into + their forwarding table because this can lead to forwarding loops when + interacting with systems that do not support this TLV. + + + + + + +Smit & Li Informational [Page 9] + +RFC 3784 IS-IS extensions for Traffic Engineering June 2004 + + +6. IANA Considerations + +6.1. TLV Codepoint Allocations + + This document defines the following new IS-IS TLV types, which have + been reflected in the ISIS TLV code-point registry: + + Type Description IIH LSP SNP + ---- ----------------------------------- --- --- --- + 22 The extended IS reachability TLV n y n + 134 The Traffic Engineering router ID TLV n y n + 135 The extended IP reachability TLV n y n + +6.2. New Registries + + IANA has created the following new registries. + +6.2.1. Sub-TLVs for the Extended IS Reachability TLV + + This registry contains codepoints for Sub-TLVs of TLV 22. The range + of values is 0-255. Allocations within the registry require + documentation of the proposed use of the allocated value and approval + by the Designated Expert assigned by the IESG (see [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 + + + + + + + + + +Smit & Li Informational [Page 10] + +RFC 3784 IS-IS extensions for Traffic Engineering June 2004 + + +6.2.2. Sub-TLVs for the Extended IP Reachability TLV + + This registry contains codepoints for Sub-TLVs of TLV 135. The range + of values is 0-255. Allocations within the registry require + documentation of the use of the allocated value and approval by the + Designated Expert assigned by the IESG (see [5]). + + No codepoints are defined in this document. + +7. References + +7.1. Normative References + + [1] 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 + + [2] Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix + Distribution with Two-Level IS-IS", RFC 2966, October 2000. + +7.2. Informative References + + [3] Callon, R.W., "Use of OSI IS-IS for routing in TCP/IP and dual + environments", RFC 1195, December 1990 + + [4] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, + "Requirements for Traffic Engineering Over MPLS", RFC 2702, + September 1999. + + [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + +8. Security Considerations + + This document raises no new security issues for IS-IS. + +9. Acknowledgments + + The authors would like to thank Yakov Rekhter and Dave Katz for their + comments on this work. + + + + + + + + + + +Smit & Li Informational [Page 11] + +RFC 3784 IS-IS extensions for Traffic Engineering June 2004 + + +10. Authors' Addresses + + Henk Smit + + EMail: hhwsmit@xs4all.nl + + + Tony Li + + EMail: tony.li@tony.li + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Smit & Li Informational [Page 12] + +RFC 3784 IS-IS extensions for Traffic Engineering June 2004 + + +11. Full Copyright Statement + + 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 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- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Smit & Li Informational [Page 13] + -- cgit v1.2.3