idnits 2.17.1 draft-ietf-isis-traffic-03.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** 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 10 longer pages, the longest (page 2) being 60 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 181: '... Implementations MUST NOT inject a /32...' RFC 2119 keyword, line 196: '... Implementations MUST NOT inject a /32...' RFC 2119 keyword, line 393: '... Implementations MUST NOT inject a /32...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 2001) is 8350 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) ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. '1') ** Obsolete normative reference: RFC 1142 (ref. '2') (Obsoleted by RFC 7142) ** Obsolete normative reference: RFC 2966 (ref. '4') (Obsoleted by RFC 5302) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tony Li 2 INTERNET DRAFT Procket Networks 3 Henk Smit 4 Procket Networks 5 June 2001 7 IS-IS extensions for Traffic Engineering 9 11 Status 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026 except that the right to 15 produce derivative works is not granted. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 1.0 Abstract 35 This document describes extensions to the IS-IS protocol to support 36 Traffic Engineering [1]. The IS-IS protocol is specified in [2], 37 with extensions for supporting IPv4 specified in [3]. 39 This document extends the IS-IS protocol by specifying new 40 information that a Intermediate System (IS) [router] can place in 41 Link State Protocol Data Units (LSPs). This information describes 42 additional information about the state of the network that is useful 43 for traffic engineering computations. 45 2.0 Introduction 47 An IS-IS LSP is composed of a fixed header and a number of tuples, 48 each consisting of a Type, a Length, and a Value. Such tuples are 49 commonly known as TLVs, and are a good way of encoding information in 50 a flexible and extensible format. 52 The changes in this document include the design of new TLVs to 53 replace the existing IS Neighbor TLV, IP Reachability TLV and add 54 additional information. Mechanisms and procedures to migrate to the 55 new TLVs are not discussed in this document. 57 The primary goal of these extensions is to add more information about 58 the characteristics of a particular link to an IS-IS's LSP. 59 Secondary goals include increasing the dynamic range of the IS-IS 60 metric and improving the encoding of IP prefixes. The router id is 61 useful for traffic engineering purposes because it describes a single 62 address that can always be used to reference a particular router. 64 This document is a publication of the IS-IS Working Group within the 65 IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual 66 inclusion with ISO 10589 [2]. 68 3.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 4.0 The extended IS reachability TLV 87 The extended IS reachability TLV is TLV type 22. 88 The existing IS reachability (TLV type 2, defined in ISO 10589 [2]) 89 contains information about a series of IS neighbors. For each 90 neighbor, there is a structure that contains the default metric, the 91 delay, the monetary cost, the reliability, and the 7-octet ID of the 92 adjacent neighbor. Of this information, the default metric is 93 commonly used. The default metric is currently one octet, with one 94 bit used to indicate that the metric is present and one bit used to 95 indicate whether the metric is internal or external. The remaining 6 96 bits are used to store the actual metric, resulting a possible metric 97 range of 0-63. This limitation is one of the restrictions that we 98 would like to lift. 100 The remaining three metrics (delay, monetary cost, and reliability) 101 are not commonly implemented and reflect unused overhead in the TLV. 102 The neighbor is identified by its system Id (typically 6-octets), 103 plus one octet to indicate the pseudonode number if the neighbor is 104 on a LAN interface. Thus, the existing TLV consumes 11 octets per 105 neighbor, with 4 octets for metric and 7 octets for neighbor 106 identification. To indicate multiple adjacencies, this structure is 107 repeated within the IS reachability TLV. Because the TLV is limited 108 to 255 octets of content, a single TLV can describe up to 23 109 neighbors. The IS reachability TLV can be repeated within the LSP 110 fragments to describe further neighbors. 112 The proposed extended IS reachability TLV contains a new data 113 structure, consisting of 114 7 octets of system Id and pseudonode number 115 3 octets of default metric 116 1 octet of length of sub-TLVs 117 0-244 octets of sub-TLVs, 118 where each sub-TLV consists of a sequence of 119 1 octet of sub-type 120 1 octet of length 121 0-242 octets of value 123 Thus, if no sub-TLVs are used, the new encoding requires 11 octets 124 and can contain up to 23 neighbors. Please note that while the 125 encoding allows for 255 octets of sub-TLVs, the maximum value cannot 126 fit in the overall IS reachability TLV. The practical maximum is 255 127 octets minus the 11 octets described above, or 244 octets. Further, 128 there is no defined mechanism for extending the sub-TLV space for a 129 particular neighbor. Thus, wasting sub-TLV space is discouraged. 131 The metric octets are encoded as a 24-bit unsigned integer. Note that 132 the metric field in the new extended IP reachability TLV is encoded 133 as a 32-bit unsigned integer. These different sizes were chosen so 134 that it is very unlikely that the cost of an intra-area route has to 135 be chopped off to fit in the metric field of an inter-area route. 137 To preclude overflow within an SPF implementation, all metrics 138 greater than or equal to MAX_PATH_METRIC shall be considered to have 139 a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC 140 such that MAX_PATH_METRIC plus a single link metric does not overflow 141 the number of bits for internal metric calculation. We assume that 142 this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 143 2^32 - 2^25). 145 If a link is advertised with the maximum link metric (2^24 - 1), this 146 link should not be considered during the normal SPF computation. 147 This will allow advertisement of a link for other purposes than 148 building the normal Shortest Path Tree. An example is a link that is 149 available for traffic engineering, but not for hop-by-hop routing. 151 Certain sub-TLVs are proposed here: 152 Sub-TLV type Length (octets) Name 153 3 4 Administrative group (color) 154 6 4 IPv4 interface address 155 8 4 IPv4 neighbor address 156 9 4 Maximum link bandwidth 157 10 4 Reservable link bandwidth 158 11 32 Unreserved bandwidth 159 18 3 TE Default metric 160 250-254 Reserved for cisco specific extensions 161 255 Reserved for future expansion 163 Each of these sub-TLVs is described below. Unless stated otherwise, 164 multiple occurrences of the information are supported by multiple 165 inclusions of the sub-TLV. 167 4.1 Sub-TLV 3: Administrative group (color, resource class) 169 The administrative group sub-TLV contains a 4-octet bit mask assigned 170 by the network administrator. Each set bit corresponds to one 171 administrative group assigned to the interface. 173 By convention the least significant bit is referred to as 'group 0', 174 and the most significant bit is referred to as 'group 31'. 176 4.2 Sub-TLV 6: IPv4 interface address 178 This sub-TLV contains a 4-octet IPv4 address for the interface 179 described by the (main) TLV. This sub-TLV can occur multiple times. 181 Implementations MUST NOT inject a /32 prefix for the interface 182 address into their routing or forwarding table, because this can lead 183 to forwarding loops when interacting with systems that do not support 184 this sub-TLV. 186 If a router implements the basic TLV extensions in this document, it 187 is free to add or omit this sub-TLV to the description of an 188 adjacency. If a router implements traffic engineering, it must 189 include this sub-TLV. 191 4.3 Sub-TLV 8: IPv4 neighbor address 193 This sub-TLV contains a single IPv4 address for a neighboring router 194 on this link. This sub-TLV can occur multiple times. 196 Implementations MUST NOT inject a /32 prefix for the neighbor address 197 into their routing or forwarding table, because this can lead to 198 forwarding loops when interacting with systems that do not support 199 this sub-TLV. 201 If a router implements the basic TLV extensions in this document, it 202 is free to add or omit this sub-TLV to the description of an 203 adjacency. If a router implements traffic engineering, it must 204 include this sub-TLV on point-to-point adjacencies. 206 4.4 Sub-TLV 9: Maximum link bandwidth 208 This sub-TLV contains the maximum bandwidth that can be used on this 209 link in this direction (from the system originating the LSP to its 210 neighbors). This is useful for traffic engineering. 212 The maximum link bandwidth is encoded in 32 bits in IEEE floating 213 point format. The units are bytes (not bits!) per second. 215 4.5 Sub-TLV 10: Maximum reservable link bandwidth 217 This sub-TLV contains the maximum amount of bandwidth that can be 218 reserved in this direction on this link. Note that for 219 oversubscription purposes, this can be greater than the bandwidth of 220 the link. 221 The maximum reservable link bandwidth is encoded in 32 bits in IEEE 222 floating point format. The units are bytes (not bits!) per second. 224 4.6 Sub-TLV 11: Unreserved bandwidth 226 This sub-TLV contains the amount of bandwidth reservable on this 227 direction on this link. Note that for oversubscription purposes, 228 this can be greater than the bandwidth of the link. 230 Because of the need for priority and preemption, each head end needs 231 to know the amount of reserved bandwidth at each priority level. 232 Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers. 233 The units are bytes (not bits!) per second. The values correspond to 234 the bandwidth that can be reserved with a setup priority 0 through 7, 235 arranged in increasing order with priority 0 occurring at the start 236 of the sub-TLV, and priority 7 at the end of the sub-TLV. 238 For stability reasons, rapid changes in the values in this sub-TLV 239 should not cause rapid generation of LSPs. 241 4.7 Sub-TLV 18: Traffic Engineering Default metric 243 This sub-TLV contains a 24-bit unsigned integer. This metric is 244 administratively assigned and can be used to present a differently 245 weighted topology to traffic engineering SPF calculations. 247 To preclude overflow within an SPF implementation, all metrics 248 greater than or equal to MAX_PATH_METRIC shall be considered to have 249 a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC 250 such that MAX_PATH_METRIC plus a single link metric does not overflow 251 the number of bits for internal metric calculation. We assume that 252 this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 253 2^32 - 2^25). 255 If a link is advertised without this sub-TLV, traffic engineering SPF 256 calculations must use the normal default metric of this link, which 257 is advertised in the fixed part of the extended IS reachability TLV. 259 5.0 The extended IP reachability TLV 261 The extended IP reachability TLV is TLV type 135. 262 The existing IP reachability TLVs (TLV type 128 and TLV type 130, 263 defined in RFC 1195 [3]) carry IP prefixes in a format that is 264 analogous to the IS neighbor TLV from ISO 10589 [2]. They carry four 265 metrics, of which only the default metric is commonly used. Of this, 266 the default metric has a possible range of 0-63. This limitation is 267 one of the restrictions that we would like to lift. 269 In addition, route redistribution (a.k.a. route leaking) has a key 270 problem that was not fully addressed by the existing IP reachability 271 TLVs. RFC 1195 [3] allows a router to advertise prefixes upwards in 272 the level hierarchy. Unfortunately there were no mechanisms defined 273 to advertise prefixes downwards in the level hierarchy. 275 To address these two issues, the proposed extended IP reachability 276 TLV provides for a 32 bit metric and adds one bit to indicate that a 277 prefix has been redistributed 'down' in the hierarchy. 279 The proposed extended IP reachability TLV contains a new data 280 structure, consisting of: 281 4 octets of metric information 282 1 octet of control information, consisting of 283 1 bit of up/down information 284 1 bit indicating the existence of sub-TLVs 285 6 bits of prefix length 286 0-4 octet of IPv4 prefix 287 0-250 optional octets of sub-TVLs, if present consisting of 288 1 octet of length of sub-TLVs 289 0-249 octets of sub-TLVs, 290 where each sub-TLV consists of a sequence of 291 1 octet of sub-type 292 1 octet of length 293 0-247 octets of value 295 This data structure can be replicated within the TLV, not to exceed 296 the maximum length of the TLV. 298 The 6 bits of prefix length can have the values 0-32 and indicate the 299 number of significant bits in the prefix. The prefix is encoded in 300 the minimal number of octets for the given number of significant 301 bits. This implies: 303 Significant bits Octets 304 0 0 305 1-8 1 306 9-16 2 307 17-24 3 308 25-32 4 310 The remaining bits of prefix are transmitted as zero and ignored upon 311 receipt. 313 If a prefix is advertised with a metric larger then MAX_PATH_METRIC 314 (0xFE000000, see paragraph 4.0), this prefix should not be considered 315 during the normal SPF computation. This will allow advertisement of a 316 prefix for other purposes than building the normal IP routing table. 318 5.1 The up/down bit 320 Without any additional mechanisms, if routers were allowed to 321 redistribute IP prefixes freely in both directions between level 1 322 and level 2, those routers can not determine looping of routing 323 information. A problem occurs when a router learns an prefix via 324 level 2 routing and advertises that prefix down into a level 1 area, 325 where another router might pick up the route and advertise the prefix 326 back up into the level 2 backbone. If the original source withdraws 327 the prefix, those two routers might end up having a routing loop 328 between them, where part of the looped path is via level 1 routing 329 and the other part of the looped path is via level 2 routing. The 330 solution that RFC 1195 [3] poses is to allow only advertising 331 prefixes upward in the level hierarchy, and to disallow the 332 advertising of prefixes downward in the hierarchy. 334 To prevent this looping of prefixes between levels, a new bit of 335 information is defined in the new extended IP reachability TLV. This 336 bit is called the up/down bit. The up/down bit shall be set to 0 337 when a prefix is first injected into IS-IS. If a prefix is 338 advertised from a higher level to a lower level (e.g. level two to 339 level one), the bit shall be set to 1, to indicate that the prefix 340 has traveled down the hierarchy. Prefixes that have the up/down bit 341 set to 1 may only be advertised down the hierarchy, i.e. to lower 342 levels. 344 These semantics apply even if IS-IS is extended in the future to have 345 additional levels. By insuring that prefixes follow only the IS-IS 346 hierarchy, we have insured that the information does not loop, 347 thereby insuring that there are no persistent forwarding loops. 349 If a prefix is advertised from an area to another area at the same 350 level, then the up/down bit shall be set to 1. This situation can 351 arise when a router implements multiple virtual routers at the same 352 level, but in different areas. 354 The semantics of the up/down bit in the new extended IP reachability 355 TLV are identical to the semantics of the up/down bit defined in 356 RFC 2966 [4]. 358 5.2 Expandability of the extended IP reachability TLV with sub-TLVs 360 The extended IP reachability TLV can hold sub-TLVs that apply to a 361 particular prefix. This allows for easy future extensions. If there 362 are no sub-TLVs associated with a prefix, the bit indicating the 363 presence of sub-TLVs shall be set to 0. If this bit is set to 1, the 364 first octet after the prefix will be interpreted as the length of 365 sub-TLVs. Please note that while the encoding allows for 255 octets 366 of sub-TLVs, the maximum value cannot fit in the overall extended IP 367 reachability TLV. The practical maximum is 255 octets minus the 5-9 368 octets described above, or 250 octets. 370 This document does not define any sub-TLVs yet for the extended IP 371 reachability TLV. 373 6.0 The Traffic Engineering router ID TLV 375 The Traffic Engineering router ID TLV is TLV type 134. 377 The router ID TLV contains the 4-octet router ID of the router 378 originating the LSP. This is useful in several regards: 380 For traffic engineering, it guarantees that we have a single stable 381 address that can always be referenced in a path that will be 382 reachable from multiple hops away, regardless of the state of the 383 node's interfaces. 385 If OSPF is also active in the domain, traffic engineering can compute 386 the mapping between the OSPF and IS-IS topologies. 388 If a router advertises the Traffic Engineering router ID TLV in its 389 LSP, and if it advertises BGP routes with the BGP next hop attribute 390 set to the BGP router ID, in that case the Traffic Engineering router 391 ID should be the same as the BGP router ID. 393 Implementations MUST NOT inject a /32 prefix for the router ID into 394 their forwarding table, because this can lead to forwarding loops 395 when interacting with systems that do not support this TLV. 397 7.0 Security Considerations 399 This document raises no new security issues for IS-IS. 401 8.0 Acknowledgments 403 The authors would like to thank Yakov Rekhter and Dave Katz for their 404 comments on this work. 406 9.0 References 408 [1] RFC 2702, "Requirements for Traffic Engineering Over MPLS," D. 409 Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, September 410 1999. 412 [2] ISO 10589, "Intermediate System to Intermediate System Intra- 413 Domain Routeing Exchange Protocol for use in Conjunction with the 414 Protocol for Providing the Connectionless-mode Network Service (ISO 415 8473)" [Also republished as RFC 1142] 417 [3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual 418 environments", R.W. Callon, December 1990 420 [4] RFC 2966, "Domain-wide Prefix Distribution with Two-Level IS-IS", 421 T. Li, T. Przygienda, H. Smit, October 2000. 423 10.0 Authors' Addresses 425 Tony Li 426 Procket Networks, Inc. 427 1100 Cadillac Court 428 Milpitas, CA 95035 429 Email: tli@procket.com 430 Voice: +1 408 6357900 431 Fax: +1 408 6356166 433 Henk Smit 434 Procket Networks, Inc. 435 1100 Cadillac Court 436 Milpitas, CA 95035 437 Email: henk@procket.com 438 Voice: +1 408 6357900 439 Fax: +1 408 6356166