idnits 2.17.1 draft-ietf-isis-traffic-05.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 148: '... MAX_PATH_METRIC SHALL be considered t...' RFC 2119 keyword, line 156: '... link MUST NOT be considered during ...' RFC 2119 keyword, line 187: '... This sub-TLV is OPTIONAL. This sub-TL...' RFC 2119 keyword, line 195: '... Implementations MUST NOT inject a /32...' RFC 2119 keyword, line 201: '... MAY add or omit this sub-TLV to the...' (21 more instances...) 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 (August 2003) is 7552 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2966 (ref. '2') (Obsoleted by RFC 5302) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '5') (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Henk Smit 3 INTERNET DRAFT Tony Li 4 Procket Networks 5 August 2003 7 IS-IS extensions for Traffic Engineering 9 11 Status 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 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 list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes extensions to the IS-IS protocol to support 35 Traffic Engineering. 37 This document extends the IS-IS protocol by specifying new 38 information that an Intermediate System [router] can place in Link 39 State Protocol Data Units. This information describes additional 40 details of the state of the network that are useful for traffic 41 engineering computations. 43 1.0 Introduction 45 The IS-IS protocol is specified in ISO 10589 [1], with extensions for 46 supporting IPv4 specified in RFC 1195 [3]. Each Intermediate System 47 (IS) [router] advertises one or more IS-IS Link State Protocol Data 48 Units (LSPs) with routing information. Each LSP is composed of a 49 fixed header and a number of tuples, each consisting of a Type, a 50 Length, and a Value. Such tuples are commonly known as TLVs, and are 51 a good way of encoding information in a flexible and extensible 52 format. 54 The changes in this document include the design of new TLVs to 55 replace the existing IS Neighbor TLV, IP Reachability TLV and add 56 additional information. Mechanisms and procedures to migrate to the 57 new TLVs are not discussed in this document. 59 The primary goal of these extensions is to add more information about 60 the characteristics of a particular link to an IS-IS's LSP. The 61 characteristics described in this document are needed for Traffic 62 Engineering [4] (TE). Secondary goals include increasing the dynamic 63 range of the IS-IS metric and improving the encoding of IP prefixes. 64 The router id is useful for traffic engineering purposes because it 65 describes a single address that can always be used to reference a 66 particular router. 68 2.0 Introducing Sub-TLVs 70 This document introduces a new way to encode routing information in 71 IS-IS. The new object is called a sub-TLV. Sub-TLVs are similar to 72 regular TLVs. They use the same concepts as regular TLVs. The 73 difference is that TLVs exist inside IS-IS packets, while sub-TLVs 74 exist inside TLVs. TLVs are used to add extra information to IS-IS 75 packets. Sub-TLVs are used to add extra information to particular 76 TLVs. Each sub-TLV consists of three fields. A one-octet Type field, 77 a one-octet Length field, and zero or more octets of Value. The Type 78 field indicates the type of items in the Value field. The Length 79 field indicates the length of the Value field in octets. Each sub- 80 TLV can potentially hold multiple items. The number of items in a 81 sub-TLV can be computed from the length of the whole sub-TLV, when 82 the length of each item is known. Unknown sub-TLVs are to be ignored 83 and skipped on receipt. 85 The Sub-TLV type space is managed by the IETF IS-IS WG 86 (http://www.ietf.org/html.charters/isis-charter.html). New type 87 values are allocated following review on the IETF IS-IS mailing list. 88 This will normally require publication of additional documentation 89 describing how the new type is used. In the event that the IS-IS 90 working group has disbanded the review shall be performed by a 91 Designated Expert assigned by the responsible Area Director. 93 3.0 The extended IS reachability TLV 95 The extended IS reachability TLV is TLV type 22. 97 The existing IS reachability (TLV type 2, defined in ISO 10589 [1]) 98 contains information about a series of IS neighbors. For each 99 neighbor, there is a structure that contains the default metric, the 100 delay, the monetary cost, the reliability, and the 7-octet ID of the 101 adjacent neighbor. Of this information, the default metric is 102 commonly used. The default metric is currently one octet, with one 103 bit used to indicate that the metric is present and one bit used to 104 indicate whether the metric is internal or external. The remaining 6 105 bits are used to store the actual metric, resulting a possible metric 106 range of 0-63. This limitation is one of the restrictions that we 107 would like to lift. 109 The remaining three metrics (delay, monetary cost, and reliability) 110 are not commonly implemented and reflect unused overhead in the TLV. 111 The neighbor is identified by its system Id (typically 6-octets), 112 plus one octet to indicate the pseudonode number if the neighbor is 113 on a LAN interface. Thus, the existing TLV consumes 11 octets per 114 neighbor, with 4 octets for metric and 7 octets for neighbor 115 identification. To indicate multiple adjacencies, this structure is 116 repeated within the IS reachability TLV. Because the TLV is limited 117 to 255 octets of content, a single TLV can describe up to 23 118 neighbors. The IS reachability TLV can be repeated within the LSP 119 fragments to describe further neighbors. 121 The proposed extended IS reachability TLV contains a new data 122 structure, consisting of: 124 7 octets of system Id and pseudonode number 125 3 octets of default metric 126 1 octet of length of sub-TLVs 127 0-244 octets of sub-TLVs, 128 where each sub-TLV consists of a sequence of 129 1 octet of sub-type 130 1 octet of length of the value field of the sub-TLV 131 0-242 octets of value 133 Thus, if no sub-TLVs are used, the new encoding requires 11 octets 134 and can contain up to 23 neighbors. Please note that while the 135 encoding allows for 255 octets of sub-TLVs, the maximum value cannot 136 fit in the overall IS reachability TLV. The practical maximum is 255 137 octets minus the 11 octets described above, or 244 octets. Further, 138 there is no defined mechanism for extending the sub-TLV space for a 139 particular neighbor. Thus, wasting sub-TLV space is discouraged. 141 The metric octets are encoded as a 24-bit unsigned integer. Note that 142 the metric field in the new extended IP reachability TLV is encoded 143 as a 32-bit unsigned integer. These different sizes were chosen so 144 that it is very unlikely that the cost of an intra-area route has to 145 be chopped off to fit in the metric field of an inter-area route. 147 To preclude overflow within a SPF implementation, all metrics greater 148 than or equal to MAX_PATH_METRIC SHALL be considered to have a metric 149 of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such 150 that MAX_PATH_METRIC plus a single link metric does not overflow the 151 number of bits for internal metric calculation. We assume that this 152 is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 153 - 2^25). 155 If a link is advertised with the maximum link metric (2^24 - 1), this 156 link MUST NOT be considered during the normal SPF computation. This 157 will allow advertisement of a link for other purposes than building 158 the normal Shortest Path Tree. An example is a link that is available 159 for traffic engineering, but not for hop-by-hop routing. 161 Certain sub-TLVs are proposed here: 163 Sub-TLV type Length (octets) Name 164 3 4 Administrative group (color) 165 6 4 IPv4 interface address 166 8 4 IPv4 neighbor address 167 9 4 Maximum link bandwidth 168 10 4 Reservable link bandwidth 169 11 32 Unreserved bandwidth 170 18 3 TE Default metric 171 250-254 Reserved for cisco specific extensions 172 255 Reserved for future expansion 174 Each of these sub-TLVs is described below. Unless stated otherwise, 175 multiple occurrences of the information are supported by multiple 176 inclusions of the sub-TLV. 178 3.1 Sub-TLV 3: Administrative group (color, resource class) 180 The administrative group sub-TLV contains a 4-octet bit mask assigned 181 by the network administrator. Each set bit corresponds to one 182 administrative group assigned to the interface. 184 By convention the least significant bit is referred to as 'group 0', 185 and the most significant bit is referred to as 'group 31'. 187 This sub-TLV is OPTIONAL. This sub-TLV SHOULD appear at most once in 188 each extended IS reachability TLV. 190 3.2 Sub-TLV 6: IPv4 interface address 192 This sub-TLV contains a 4-octet IPv4 address for the interface 193 described by the (main) TLV. This sub-TLV can occur multiple times. 195 Implementations MUST NOT inject a /32 prefix for the interface 196 address into their routing or forwarding table, because this can lead 197 to forwarding loops when interacting with systems that do not support 198 this sub-TLV. 200 If a router implements the basic TLV extensions in this document, it 201 MAY add or omit this sub-TLV to the description of an adjacency. If 202 a router implements traffic engineering, it MUST include this sub- 203 TLV. 205 3.3 Sub-TLV 8: IPv4 neighbor address 207 This sub-TLV contains a single IPv4 address for a neighboring router 208 on this link. This sub-TLV can occur multiple times. 210 Implementations MUST NOT inject a /32 prefix for the neighbor address 211 into their routing or forwarding table, because this can lead to 212 forwarding loops when interacting with systems that do not support 213 this sub-TLV. 215 If a router implements the basic TLV extensions in this document, it 216 MAY add or omit this sub-TLV to the description of an adjacency. If 217 a router implements traffic engineering, it MUST include this sub-TLV 218 on point-to-point adjacencies. 220 3.4 Sub-TLV 9: Maximum link bandwidth 222 This sub-TLV contains the maximum bandwidth that can be used on this 223 link in this direction (from the system originating the LSP to its 224 neighbors). This is useful for traffic engineering. 226 The maximum link bandwidth is encoded in 32 bits in IEEE floating 227 point format. The units are bytes (not bits!) per second. 229 This sub-TLV is optional. This sub-TLV SHOULD appear at most once in 230 each extended IS reachability TLV. 232 3.5 Sub-TLV 10: Maximum reservable link bandwidth 234 This sub-TLV contains the maximum amount of bandwidth that can be 235 reserved in this direction on this link. Note that for 236 oversubscription purposes, this can be greater than the bandwidth of 237 the link. 239 The maximum reservable link bandwidth is encoded in 32 bits in IEEE 240 floating point format. The units are bytes (not bits!) per second. 242 This sub-TLV is optional. This sub-TLV SHOULD appear at most once in 243 each extended IS reachability TLV. 245 3.6 Sub-TLV 11: Unreserved bandwidth 247 This sub-TLV contains the amount of bandwidth reservable in this 248 direction on this link. Note that for oversubscription purposes, 249 this can be greater than the bandwidth of the link. 251 Because of the need for priority and preemption, each head end needs 252 to know the amount of reserved bandwidth at each priority level. 253 Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers. 254 The units are bytes (not bits!) per second. The values correspond to 255 the bandwidth that can be reserved with a setup priority 0 through 7, 256 arranged in increasing order with priority 0 occurring at the start 257 of the sub-TLV, and priority 7 at the end of the sub-TLV. 259 For stability reasons, rapid changes in the values in this sub-TLV 260 SHOULD NOT cause rapid generation of LSPs. 262 This sub-TLV is optional. This sub-TLV SHOULD appear at most once in 263 each extended IS reachability TLV. 265 3.7 Sub-TLV 18: Traffic Engineering Default metric 267 This sub-TLV contains a 24-bit unsigned integer. This metric is 268 administratively assigned and can be used to present a differently 269 weighted topology to traffic engineering SPF calculations. 271 To preclude overflow within a SPF implementation, all metrics greater 272 than or equal to MAX_PATH_METRIC SHALL be considered to have a metric 273 of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such 274 that MAX_PATH_METRIC plus a single link metric does not overflow the 275 number of bits for internal metric calculation. We assume that this 276 is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 277 - 2^25). 279 This sub-TLV is optional. This sub-TLV SHOULD appear at most once in 280 each extended IS reachability TLV. If a link is advertised without 281 this sub-TLV, traffic engineering SPF calculations MUST use the 282 normal default metric of this link, which is advertised in the fixed 283 part of the extended IS reachability TLV. 285 4.0 The extended IP reachability TLV 287 The extended IP reachability TLV is TLV type 135. 289 The existing IP reachability TLVs (TLV type 128 and TLV type 130, 290 defined in RFC 1195 [3]) carry IP prefixes in a format that is 291 analogous to the IS neighbor TLV from ISO 10589 [1]. They carry four 292 metrics, of which only the default metric is commonly used. Of this, 293 the default metric has a possible range of 0-63. This limitation is 294 one of the restrictions that we would like to lift. 296 In addition, route redistribution (a.k.a. route leaking) has a key 297 problem that was not fully addressed by the existing IP reachability 298 TLVs. RFC 1195 [3] allows a router to advertise prefixes upwards in 299 the level hierarchy. Unfortunately there were no mechanisms defined 300 to advertise prefixes downwards in the level hierarchy. 302 To address these two issues, the proposed extended IP reachability 303 TLV provides for a 32 bit metric and adds one bit to indicate that a 304 prefix has been redistributed 'down' in the hierarchy. 306 The proposed extended IP reachability TLV contains a new data 307 structure, consisting of: 309 4 octets of metric information 310 1 octet of control information, consisting of 311 1 bit of up/down information 312 1 bit indicating the presence of sub-TLVs 313 6 bits of prefix length 314 0-4 octet of IPv4 prefix 315 0-250 optional octets of sub-TVLs, if present consisting of 316 1 octet of length of sub-TLVs 317 0-249 octets of sub-TLVs, 318 where each sub-TLV consists of a sequence of 319 1 octet of sub-type 320 1 octet of length of the value field of the sub-TLV 321 0-247 octets of value 323 This data structure can be replicated within the TLV, not to exceed 324 the maximum length of the TLV. 326 The 6 bits of prefix length can have the values 0-32 and indicate the 327 number of significant bits in the prefix. The prefix is encoded in 328 the minimal number of octets for the given number of significant 329 bits. This implies: 331 Significant bits Octets 332 0 0 333 1-8 1 334 9-16 2 335 17-24 3 336 25-32 4 338 The remaining bits of prefix are transmitted as zero and ignored upon 339 receipt. 341 If a prefix is advertised with a metric larger then MAX_PATH_METRIC 342 (0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered 343 during the normal SPF computation. This allows advertisement of a 344 prefix for other purposes than building the normal IP routing table. 346 4.1 The up/down bit 348 Without any additional mechanisms, if routers were allowed to 349 redistribute IP prefixes freely in both directions between level 1 350 and level 2, those routers can not determine looping of routing 351 information. A problem occurs when a router learns a prefix via 352 level 2 routing and advertises that prefix down into a level 1 area, 353 where another router might pick up the route and advertise the prefix 354 back up into the level 2 backbone. If the original source withdraws 355 the prefix, those two routers might end up having a routing loop 356 between them, where part of the looped path is via level 1 routing 357 and the other part of the looped path is via level 2 routing. The 358 solution that RFC 1195 [3] poses is to allow only advertising 359 prefixes upward in the level hierarchy, and to disallow the 360 advertising of prefixes downward in the hierarchy. 362 To prevent this looping of prefixes between levels, a new bit of 363 information is defined in the new extended IP reachability TLV. This 364 bit is called the up/down bit. The up/down bit SHALL be set to 0 365 when a prefix is first injected into IS-IS. If a prefix is 366 advertised from a higher level to a lower level (e.g. level two to 367 level one), the bit SHALL be set to 1, to indicate that the prefix 368 has traveled down the hierarchy. Prefixes that have the up/down bit 369 set to 1 may only be advertised down the hierarchy, i.e. to lower 370 levels. 372 These semantics apply even if IS-IS is extended in the future to have 373 additional levels. By insuring that prefixes follow only the IS-IS 374 hierarchy, we have insured that the information does not loop, 375 thereby insuring that there are no persistent forwarding loops. 377 If a prefix is advertised from an area to another area at the same 378 level, then the up/down bit SHALL be set to 1. This situation can 379 arise when a router implements multiple virtual routers at the same 380 level, but in different areas. 382 The semantics of the up/down bit in the new extended IP reachability 383 TLV are identical to the semantics of the up/down bit defined in RFC 384 2966 [2]. 386 4.2 Expandability of the extended IP reachability TLV with sub-TLVs 388 The extended IP reachability TLV can hold sub-TLVs that apply to a 389 particular prefix. This allows for easy future extensions. If there 390 are no sub-TLVs associated with a prefix, the bit indicating the 391 presence of sub-TLVs SHALL be set to 0. If this bit is set to 1, the 392 first octet after the prefix will be interpreted as the length of all 393 sub-TLVs associated with this IPv4 prefix. Please note that while 394 the encoding allows for 255 octets of sub-TLVs, the maximum value 395 cannot fit in the overall extended IP reachability TLV. The practical 396 maximum is 255 octets minus the 5-9 octets described above, or 250 397 octets. 399 This document does not define any sub-TLVs yet for the extended IP 400 reachability TLV. 402 5.0 The Traffic Engineering router ID TLV 404 The Traffic Engineering router ID TLV is TLV type 134. 406 The router ID TLV contains the 4-octet router ID of the router 407 originating the LSP. This is useful in several regards: 409 For traffic engineering, it guarantees that we have a single stable 410 address that can always be referenced in a path that will be 411 reachable from multiple hops away, regardless of the state of the 412 node's interfaces. 414 If OSPF is also active in the domain, traffic engineering can compute 415 the mapping between the OSPF and IS-IS topologies. 417 If a router does not implement traffic engineering it MAY add or omit 418 the Traffic Engineering router ID TLV. If a router implements 419 traffic engineering, it MUST include this TLV in its LSP. This TLV 420 SHOULD not be included more than once in a LSP. 422 If a router advertises the Traffic Engineering router ID TLV in its 423 LSP, and if it advertises prefixes via the Border Gateway Protocol 424 (BGP) with the BGP next hop attribute set to the BGP router ID, in 425 that case the Traffic Engineering router ID SHOULD be the same as the 426 BGP router ID. 428 Implementations MUST NOT inject a /32 prefix for the router ID into 429 their forwarding table, because this can lead to forwarding loops 430 when interacting with systems that do not support this TLV. 432 6. IANA Considerations 434 6.1 TLV codepoint allocations 436 This document defines the following new ISIS TLV types that need to 437 be reflected in the ISIS TLV code-point registry: 438 Type Description IIH LSP SNP 439 ---- ----------------------------------- --- --- --- 440 22 The extended IS reachability TLV n y n 441 134 The Traffic Engineering router ID TLV n y n 442 135 The extended IP reachability TLV n y n 444 6.2 New registries 446 IANA is requested to create the following new registries. 448 6.2.1 Sub-TLVs for TLV 22 450 This registry contains codepoints for Sub-TLVs of TLV 22. The range 451 of values is 0-255. Allocations within the registry require 452 documentation of the use of the allocated value and approval by the 453 Designated Expert assigned by the IESG (see [5]). 455 Taking into consideration allocations specified in this document, the 456 registry should be initialized as follows: 458 Type Description 459 ---- ----------------------------------- 460 0-2 unassigned 461 3 Administrative group (color) 462 4-5 unassiged 463 6 IPv4 interface address 464 7 unassigned 465 8 IPv4 neighbor address 466 9 Maximum link bandwidth 467 10 Reservable link bandwidth 468 11 Unreserved bandwidth 469 12-17 unassigned 470 18 TE Default metric 471 19-254 unassigned 472 255 Reserved for future expansion 474 To be removed by the RFC editor at the time of publication 476 At the time of registry creation, please perform the following 477 allocations in this registry: 479 Type Description 480 ---- ----------------------------------- 481 250 Reserved for Cisco-proprietary extensions 482 251 Reserved for Cisco-proprietary extensions 484 486 6.2.2 Sub-TLVs for TLV 135 488 This registry contains codepoints for Sub-TLVs of TLV 135. The range 489 of values is 0-255. Allocations within the registry require 490 documentation of the use of the allocated value and approval by the 491 Designated Expert assigned by the IESG (see [5]). 493 No codepoints are defined in this document. 495 Normative References 497 [1] ISO, "Intermediate System to Intermediate System Intra-Domain 498 Routeing Exchange Protocol for use in Conjunction with the Protocol 499 for Providing the Connectionless-mode Network Service (ISO 8473)", 500 International Standard 10589:2002, Second Edition 502 [2] RFC 2966, "Domain-wide Prefix Distribution with Two-Level IS-IS", 503 T. Li, T. Przygienda, H. Smit, October 2000. 505 Informative References 507 [3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual 508 environments", R.W. Callon, December 1990 510 [4] RFC 2702, "Requirements for Traffic Engineering Over MPLS," D. 511 Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, September 512 1999 514 [5] RFC 2434, "Guidelines for Writing an IANA Considerations Section 515 in RFCs", Narten, T., and H. Alvestrand, BCP 26, October 1998 517 Security Considerations 519 This document raises no new security issues for IS-IS. 521 Acknowledgments 523 The authors would like to thank Yakov Rekhter and Dave Katz for their 524 comments on this work. 526 Authors' Addresses 528 Tony Li 529 Procket Networks, Inc. 530 1100 Cadillac Court 531 Milpitas, CA 95035 532 Email: tli@procket.com 533 Voice: +1 408 6357900 534 Fax: +1 408 6356166 536 Henk Smit 537 Email: hhwsmit@xs4all.nl