idnits 2.17.1 draft-ietf-isis-traffic-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 541 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 6 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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 a LSP. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2002) is 7775 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1142 (ref. '1') (Obsoleted by RFC 7142) ** Obsolete normative reference: RFC 2966 (ref. '2') (Obsoleted by RFC 5302) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Henk Smit 2 INTERNET DRAFT Tony Li 3 Procket Networks 4 December 2002 6 IS-IS extensions for Traffic Engineering 8 10 Status 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026 except that the right to 14 produce derivative works is not granted. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119. 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document describes extensions to the IS-IS protocol to support 39 Traffic Engineering. 41 This document extends the IS-IS protocol by specifying new 42 information that an Intermediate System [router] can place in Link 43 State Protocol Data Units. This information describes additional 44 details of the state of the network that are useful for traffic 45 engineering computations. 47 1.0 Introduction 49 The IS-IS protocol is specified in ISO 10589 [1], with extensions for 50 supporting IPv4 specified in RFC 1195 [3]. Each Intermediate System 51 (IS) [router] advertises one or more IS-IS Link State Protocol Data 52 Units (LSPs) with routing information. Each LSP is composed of a 53 fixed header and a number of tuples, each consisting of a Type, a 54 Length, and a Value. Such tuples are commonly known as TLVs, and are 55 a good way of encoding information in a flexible and extensible 56 format. 58 The changes in this document include the design of new TLVs to 59 replace the existing IS Neighbor TLV, IP Reachability TLV and add 60 additional information. Mechanisms and procedures to migrate to the 61 new TLVs are not discussed in this document. 63 The primary goal of these extensions is to add more information about 64 the characteristics of a particular link to an IS-IS's LSP. The 65 characteristics described in this document are needed for Traffic 66 Engineering [4] (TE). Secondary goals include increasing the dynamic 67 range of the IS-IS metric and improving the encoding of IP prefixes. 68 The router id is useful for traffic engineering purposes because it 69 describes a single address that can always be used to reference a 70 particular router. 72 This document is a publication of the IS-IS Working Group within the 73 IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual 74 inclusion with ISO 10589 [1]. 76 2.0 Introducing Sub-TLVs 78 This document introduces a new way to encode routing information in 79 IS-IS. The new object is called a sub-TLV. Sub-TLVs are similar to 80 regular TLVs. They use the same concepts as regular TLVs. The 81 difference is that TLVs exist inside IS-IS packets, while sub-TLVs 82 exist inside TLVs. TLVs are used to add extra information to IS-IS 83 packets. Sub-TLVs are used to add extra information to particular 84 TLVs. Each sub-TLV consists of three fields. A one-octet Type field, 85 a one-octet Length field, and zero or more octets of Value. The Type 86 field indicates the type of items in the Value field. The Length 87 field indicates the length of the Value field in octets. Each sub- 88 TLV can potentially hold multiple items. The number of items in a 89 sub-TLV can be computed from the length of the whole sub-TLV, when 90 the length of each item is known. Unknown sub-TLVs are to be ignored 91 and skipped on receipt. 93 The Sub-TLV type space is managed by the IETF IS-IS WG 94 (http://www.ietf.org/html.charters/isis-charter.html). New type 95 values are allocated following review on the IETF IS-IS mailing list. 96 This will normally require publication of additional documentation 97 describing how the new type is used. In the event that the IS-IS 98 working group has disbanded the review shall be performed by a 99 Designated Expert assigned by the responsible Area Director. 101 3.0 The extended IS reachability TLV 103 The extended IS reachability TLV is TLV type 22. 105 The existing IS reachability (TLV type 2, defined in ISO 10589 [1]) 106 contains information about a series of IS neighbors. For each 107 neighbor, there is a structure that contains the default metric, the 108 delay, the monetary cost, the reliability, and the 7-octet ID of the 109 adjacent neighbor. Of this information, the default metric is 110 commonly used. The default metric is currently one octet, with one 111 bit used to indicate that the metric is present and one bit used to 112 indicate whether the metric is internal or external. The remaining 6 113 bits are used to store the actual metric, resulting a possible metric 114 range of 0-63. This limitation is one of the restrictions that we 115 would like to lift. 117 The remaining three metrics (delay, monetary cost, and reliability) 118 are not commonly implemented and reflect unused overhead in the TLV. 119 The neighbor is identified by its system Id (typically 6-octets), 120 plus one octet to indicate the pseudonode number if the neighbor is 121 on a LAN interface. Thus, the existing TLV consumes 11 octets per 122 neighbor, with 4 octets for metric and 7 octets for neighbor 123 identification. To indicate multiple adjacencies, this structure is 124 repeated within the IS reachability TLV. Because the TLV is limited 125 to 255 octets of content, a single TLV can describe up to 23 126 neighbors. The IS reachability TLV can be repeated within the LSP 127 fragments to describe further neighbors. 129 The proposed extended IS reachability TLV contains a new data 130 structure, consisting of: 132 7 octets of system Id and pseudonode number 133 3 octets of default metric 134 1 octet of length of sub-TLVs 135 0-244 octets of sub-TLVs, 136 where each sub-TLV consists of a sequence of 137 1 octet of sub-type 138 1 octet of length of the value field of the sub-TLV 139 0-242 octets of value 141 Thus, if no sub-TLVs are used, the new encoding requires 11 octets 142 and can contain up to 23 neighbors. Please note that while the 143 encoding allows for 255 octets of sub-TLVs, the maximum value cannot 144 fit in the overall IS reachability TLV. The practical maximum is 255 145 octets minus the 11 octets described above, or 244 octets. Further, 146 there is no defined mechanism for extending the sub-TLV space for a 147 particular neighbor. Thus, wasting sub-TLV space is discouraged. 149 The metric octets are encoded as a 24-bit unsigned integer. Note that 150 the metric field in the new extended IP reachability TLV is encoded 151 as a 32-bit unsigned integer. These different sizes were chosen so 152 that it is very unlikely that the cost of an intra-area route has to 153 be chopped off to fit in the metric field of an inter-area route. 155 To preclude overflow within a SPF implementation, all metrics greater 156 than or equal to MAX_PATH_METRIC SHALL be considered to have a metric 157 of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such 158 that MAX_PATH_METRIC plus a single link metric does not overflow the 159 number of bits for internal metric calculation. We assume that this 160 is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 161 - 2^25). 163 If a link is advertised with the maximum link metric (2^24 - 1), this 164 link MUST NOT be considered during the normal SPF computation. This 165 will allow advertisement of a link for other purposes than building 166 the normal Shortest Path Tree. An example is a link that is available 167 for traffic engineering, but not for hop-by-hop routing. 169 Certain sub-TLVs are proposed here: 171 Sub-TLV type Length (octets) Name 172 3 4 Administrative group (color) 173 6 4 IPv4 interface address 174 8 4 IPv4 neighbor address 175 9 4 Maximum link bandwidth 176 10 4 Reservable link bandwidth 177 11 32 Unreserved bandwidth 178 18 3 TE Default metric 179 250-254 Reserved for cisco specific extensions 180 255 Reserved for future expansion 182 Each of these sub-TLVs is described below. Unless stated otherwise, 183 multiple occurrences of the information are supported by multiple 184 inclusions of the sub-TLV. 186 3.1 Sub-TLV 3: Administrative group (color, resource class) 188 The administrative group sub-TLV contains a 4-octet bit mask assigned 189 by the network administrator. Each set bit corresponds to one 190 administrative group assigned to the interface. 192 By convention the least significant bit is referred to as 'group 0', 193 and the most significant bit is referred to as 'group 31'. 195 This sub-TLV is OPTIONAL. This sub-TLV SHOULD appear at most once in 196 each extended IS reachability TLV. 198 3.2 Sub-TLV 6: IPv4 interface address 200 This sub-TLV contains a 4-octet IPv4 address for the interface 201 described by the (main) TLV. This sub-TLV can occur multiple times. 203 Implementations MUST NOT inject a /32 prefix for the interface 204 address into their routing or forwarding table, because this can lead 205 to forwarding loops when interacting with systems that do not support 206 this sub-TLV. 208 If a router implements the basic TLV extensions in this document, it 209 MAY add or omit this sub-TLV to the description of an adjacency. If 210 a router implements traffic engineering, it MUST include this sub- 211 TLV. 213 3.3 Sub-TLV 8: IPv4 neighbor address 215 This sub-TLV contains a single IPv4 address for a neighboring router 216 on this link. This sub-TLV can occur multiple times. 218 Implementations MUST NOT inject a /32 prefix for the neighbor address 219 into their routing or forwarding table, because this can lead to 220 forwarding loops when interacting with systems that do not support 221 this sub-TLV. 223 If a router implements the basic TLV extensions in this document, it 224 MAY add or omit this sub-TLV to the description of an adjacency. If 225 a router implements traffic engineering, it MUST include this sub-TLV 226 on point-to-point adjacencies. 228 3.4 Sub-TLV 9: Maximum link bandwidth 230 This sub-TLV contains the maximum bandwidth that can be used on this 231 link in this direction (from the system originating the LSP to its 232 neighbors). This is useful for traffic engineering. 234 The maximum link bandwidth is encoded in 32 bits in IEEE floating 235 point format. The units are bytes (not bits!) per second. 237 This sub-TLV is optional. This sub-TLV SHOULD appear at most once in 238 each extended IS reachability TLV. 240 3.5 Sub-TLV 10: Maximum reservable link bandwidth 242 This sub-TLV contains the maximum amount of bandwidth that can be 243 reserved in this direction on this link. Note that for 244 oversubscription purposes, this can be greater than the bandwidth of 245 the link. 247 The maximum reservable link bandwidth is encoded in 32 bits in IEEE 248 floating point format. The units are bytes (not bits!) per second. 250 This sub-TLV is optional. This sub-TLV SHOULD appear at most once in 251 each extended IS reachability TLV. 253 3.6 Sub-TLV 11: Unreserved bandwidth 255 This sub-TLV contains the amount of bandwidth reservable in this 256 direction on this link. Note that for oversubscription purposes, 257 this can be greater than the bandwidth of the link. 259 Because of the need for priority and preemption, each head end needs 260 to know the amount of reserved bandwidth at each priority level. 261 Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers. 262 The units are bytes (not bits!) per second. The values correspond to 263 the bandwidth that can be reserved with a setup priority 0 through 7, 264 arranged in increasing order with priority 0 occurring at the start 265 of the sub-TLV, and priority 7 at the end of the sub-TLV. 267 For stability reasons, rapid changes in the values in this sub-TLV 268 SHOULD NOT cause rapid generation of LSPs. 270 This sub-TLV is optional. This sub-TLV SHOULD appear at most once in 271 each extended IS reachability TLV. 273 3.7 Sub-TLV 18: Traffic Engineering Default metric 275 This sub-TLV contains a 24-bit unsigned integer. This metric is 276 administratively assigned and can be used to present a differently 277 weighted topology to traffic engineering SPF calculations. 279 To preclude overflow within a SPF implementation, all metrics greater 280 than or equal to MAX_PATH_METRIC SHALL be considered to have a metric 281 of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such 282 that MAX_PATH_METRIC plus a single link metric does not overflow the 283 number of bits for internal metric calculation. We assume that this 284 is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 285 - 2^25). 287 This sub-TLV is optional. This sub-TLV SHOULD appear at most once in 288 each extended IS reachability TLV. If a link is advertised without 289 this sub-TLV, traffic engineering SPF calculations MUST use the 290 normal default metric of this link, which is advertised in the fixed 291 part of the extended IS reachability TLV. 293 4.0 The extended IP reachability TLV 295 The extended IP reachability TLV is TLV type 135. 297 The existing IP reachability TLVs (TLV type 128 and TLV type 130, 298 defined in RFC 1195 [3]) carry IP prefixes in a format that is 299 analogous to the IS neighbor TLV from ISO 10589 [1]. They carry four 300 metrics, of which only the default metric is commonly used. Of this, 301 the default metric has a possible range of 0-63. This limitation is 302 one of the restrictions that we would like to lift. 304 In addition, route redistribution (a.k.a. route leaking) has a key 305 problem that was not fully addressed by the existing IP reachability 306 TLVs. RFC 1195 [3] allows a router to advertise prefixes upwards in 307 the level hierarchy. Unfortunately there were no mechanisms defined 308 to advertise prefixes downwards in the level hierarchy. 310 To address these two issues, the proposed extended IP reachability 311 TLV provides for a 32 bit metric and adds one bit to indicate that a 312 prefix has been redistributed 'down' in the hierarchy. 314 The proposed extended IP reachability TLV contains a new data 315 structure, consisting of: 317 4 octets of metric information 318 1 octet of control information, consisting of 319 1 bit of up/down information 320 1 bit indicating the presence of sub-TLVs 321 6 bits of prefix length 322 0-4 octet of IPv4 prefix 323 0-250 optional octets of sub-TVLs, if present consisting of 324 1 octet of length of sub-TLVs 325 0-249 octets of sub-TLVs, 326 where each sub-TLV consists of a sequence of 327 1 octet of sub-type 328 1 octet of length of the value field of the sub-TLV 329 0-247 octets of value 331 This data structure can be replicated within the TLV, not to exceed 332 the maximum length of the TLV. 334 The 6 bits of prefix length can have the values 0-32 and indicate the 335 number of significant bits in the prefix. The prefix is encoded in 336 the minimal number of octets for the given number of significant 337 bits. This implies: 339 Significant bits Octets 340 0 0 341 1-8 1 342 9-16 2 343 17-24 3 344 25-32 4 346 The remaining bits of prefix are transmitted as zero and ignored upon 347 receipt. 349 If a prefix is advertised with a metric larger then MAX_PATH_METRIC 350 (0xFE000000, see paragraph 4.0), this prefix MUST NOT be considered 351 during the normal SPF computation. This allows advertisement of a 352 prefix for other purposes than building the normal IP routing table. 354 4.1 The up/down bit 356 Without any additional mechanisms, if routers were allowed to 357 redistribute IP prefixes freely in both directions between level 1 358 and level 2, those routers can not determine looping of routing 359 information. A problem occurs when a router learns a prefix via 360 level 2 routing and advertises that prefix down into a level 1 area, 361 where another router might pick up the route and advertise the prefix 362 back up into the level 2 backbone. If the original source withdraws 363 the prefix, those two routers might end up having a routing loop 364 between them, where part of the looped path is via level 1 routing 365 and the other part of the looped path is via level 2 routing. The 366 solution that RFC 1195 [3] poses is to allow only advertising 367 prefixes upward in the level hierarchy, and to disallow the 368 advertising of prefixes downward in the hierarchy. 370 To prevent this looping of prefixes between levels, a new bit of 371 information is defined in the new extended IP reachability TLV. This 372 bit is called the up/down bit. The up/down bit SHALL be set to 0 373 when a prefix is first injected into IS-IS. If a prefix is 374 advertised from a higher level to a lower level (e.g. level two to 375 level one), the bit SHALL be set to 1, to indicate that the prefix 376 has traveled down the hierarchy. Prefixes that have the up/down bit 377 set to 1 may only be advertised down the hierarchy, i.e. to lower 378 levels. 380 These semantics apply even if IS-IS is extended in the future to have 381 additional levels. By insuring that prefixes follow only the IS-IS 382 hierarchy, we have insured that the information does not loop, 383 thereby insuring that there are no persistent forwarding loops. 385 If a prefix is advertised from an area to another area at the same 386 level, then the up/down bit SHALL be set to 1. This situation can 387 arise when a router implements multiple virtual routers at the same 388 level, but in different areas. 390 The semantics of the up/down bit in the new extended IP reachability 391 TLV are identical to the semantics of the up/down bit defined in RFC 392 2966 [2]. 394 4.2 Expandability of the extended IP reachability TLV with sub-TLVs 396 The extended IP reachability TLV can hold sub-TLVs that apply to a 397 particular prefix. This allows for easy future extensions. If there 398 are no sub-TLVs associated with a prefix, the bit indicating the 399 presence of sub-TLVs SHALL be set to 0. If this bit is set to 1, the 400 first octet after the prefix will be interpreted as the length of all 401 sub-TLVs associated with this IPv4 prefix. Please note that while 402 the encoding allows for 255 octets of sub-TLVs, the maximum value 403 cannot fit in the overall extended IP reachability TLV. The practical 404 maximum is 255 octets minus the 5-9 octets described above, or 250 405 octets. 407 This document does not define any sub-TLVs yet for the extended IP 408 reachability TLV. 410 5.0 The Traffic Engineering router ID TLV 412 The Traffic Engineering router ID TLV is TLV type 134. 414 The router ID TLV contains the 4-octet router ID of the router 415 originating the LSP. This is useful in several regards: 417 For traffic engineering, it guarantees that we have a single stable 418 address that can always be referenced in a path that will be 419 reachable from multiple hops away, regardless of the state of the 420 node's interfaces. 422 If OSPF is also active in the domain, traffic engineering can compute 423 the mapping between the OSPF and IS-IS topologies. 425 If a router does not implement traffic engineering it MAY add or omit 426 the Traffic Engineering router ID TLV. If a router implements 427 traffic engineering, it MUST include this TLV in its LSP. This TLV 428 SHOULD not be included more than once in a LSP. 430 If a router advertises the Traffic Engineering router ID TLV in its 431 LSP, and if it advertises prefixes via the Border Gateway Protocol 432 (BGP) with the BGP next hop attribute set to the BGP router ID, in 433 that case the Traffic Engineering router ID SHOULD be the same as the 434 BGP router ID. 436 Implementations MUST NOT inject a /32 prefix for the router ID into 437 their forwarding table, because this can lead to forwarding loops 438 when interacting with systems that do not support this TLV. 440 Normative References 442 [1] ISO 10589, "Intermediate System to Intermediate System Intra- 443 Domain Routeing Exchange Protocol for use in Conjunction with the 444 Protocol for Providing the Connectionless-mode Network Service (ISO 445 8473)" [Also republished as RFC 1142] 447 [2] RFC 2966, "Domain-wide Prefix Distribution with Two-Level IS-IS", 448 T. Li, T. Przygienda, H. Smit, October 2000. 450 Informative References 452 [3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual 453 environments", R.W. Callon, December 1990 455 [4] RFC 2702, "Requirements for Traffic Engineering Over MPLS," D. 456 Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, September 457 1999. 459 Security Considerations 461 This document raises no new security issues for IS-IS. 463 Acknowledgments 465 The authors would like to thank Yakov Rekhter and Dave Katz for their 466 comments on this work. 468 Authors' Addresses 470 Tony Li 471 Procket Networks, Inc. 472 1100 Cadillac Court 473 Milpitas, CA 95035 474 Email: tli@procket.com 475 Voice: +1 408 6357900 476 Fax: +1 408 6356166 478 Henk Smit 479 Email: hhwsmit@freeler.nl