idnits 2.17.1 draft-katz-yeung-ospf-traffic-06.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: ---------------------------------------------------------------------------- ** 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 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. ** 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 318: '... This SHOULD be user-configurable; t...' 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2370 (ref. '7') (Obsoleted by RFC 5250) Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Dave Katz 3 Internet Draft Juniper Networks, Inc. 4 Expiration Date: April 2002 Derek Yeung 5 Procket Networks, Inc. 6 Kireeti Kompella 7 Juniper Networks, Inc. 9 Traffic Engineering Extensions to OSPF 11 draft-katz-yeung-ospf-traffic-06.txt 13 Status 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes extensions to the OSPF protocol to support 37 Traffic Engineering, using opaque LSAs. 39 1. Introduction 41 This document specifies a method of adding traffic engineering 42 capabilities to OSPF [1]. The architecture of traffic engineering is 43 described in [2]. The semantic content of the extensions is 44 essentially identical to the corresponding extensions to IS-IS [3]. 45 It is expected that the traffic engineering extensions to OSPF will 46 continue to mirror those in IS-IS. 48 The extensions provide a way of describing the traffic engineering 49 topology (including bandwidth and administrative constraints). This 50 topology does not necessarily match the regular routed topology, 51 though this proposal depends on Network LSAs to describe multiaccess 52 links. 54 1.1. Applicability 56 Many of the extensions specified in this document are in response to 57 the requirements stated in [2], and thus are referred to as "traffic 58 engineering extensions", and are also commonly associated with MPLS 59 Traffic Engineering. A more accurate (albeit bland) designation is 60 "extended link attributes", as what is proposed is simply to add more 61 attributes to links in OSPF advertisements. 63 The information made available by these extensions can be used to 64 build an extended link state database just as router LSAs are used to 65 build a "regular" link state database; the difference is that the 66 extended link state database (referred to below as the traffic 67 engineering database) has additional link attributes. Uses of the 68 traffic engineering database include: 70 o monitoring the extended link attributes; 71 o local constraint-based source routing; and 72 o global traffic engineering. 74 For example, an OSPF-speaking device can participate in an OSPF area, 75 build a traffic engineering database, and thereby report on the 76 reservation state of links in that area. 78 In "local constraint-based source routing", a router R can compute a 79 path from a source node A to a destination node B; typically, A is R 80 itself, and B is specified by a "router address" (see below). This 81 path may be subject to various constraints on the attributes of the 82 links and nodes that the path traverses, e.g., use green links that 83 have unreserved bandwidth of at least 10Mbps. This path could then 84 be used to carry some subset of the traffic from A to B, forming a 85 simple but effective means of traffic engineering. How the subset of 86 traffic is determined, and how the path is instantiated is beyond the 87 scope of this document; suffice it to say that one means of defining 88 the subset of traffic is "those packets whose IP destinations were 89 learned from B", and one means of instantiating paths is using MPLS 90 tunnels. As an aside, note that constraint-based routing can be NP- 91 hard, or even unsolvable, depending on the nature of the attributes 92 and constraints and thus many implementations will use heuristics. 93 Consequently, we don't attempt to sketch an algorithm here. 95 Finally, for "global traffic engineering", a device can build a 96 traffic engineering database, input a traffic matrix and an 97 optimization function, crunch on the information, and thus compute 98 optimal or near-optimal routing for the entire network. The device 99 can subsequently monitor the traffic engineering topology and react 100 to changes by recomputing the optimal routes. 102 1.2. Limitations 104 The extensions specified in this document capture the reservation 105 state of point-to-point links. The reservation state of multiaccess 106 links is not accurately reflected, except in the special case that 107 there are only two devices in the multiaccess subnetwork. 109 This document also does not support unnumbered links. This 110 deficiency is addressed in [4]; see also [5] and [6]. 112 2. LSA Format 114 2.1. LSA type 116 This extension makes use of the Opaque LSA [7]. 118 Three types of Opaque LSAs exist, each of which has different 119 flooding scope. This proposal uses only Type 10 LSAs, which have 120 area flooding scope. 122 One new LSA is defined, the Traffic Engineering LSA. This LSA 123 describes routers, point-to-point links, and connections to 124 multiaccess networks (similar to a Router LSA). For traffic 125 engineering purposes, the existing Network LSA suffices for 126 describing multiaccess links, so no additional LSA is defined for 127 this purpose. 129 2.2. LSA ID 131 The LSA ID of an Opaque LSA is defined as having eight bits of type 132 and 24 bits of type-specific data. The Traffic Engineering LSA uses 133 type 1. The remaining 24 bits are broken up into eight bits of 134 reserved space (which must be zero) and sixteen bits of instance: 136 0 1 2 3 137 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | 1 | Reserved | Instance | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 The Instance field is an arbitrary value used to maintain multiple 143 Traffic Engineering LSAs. A maximum of 65536 Traffic Engineering 144 LSAs may be sourced by a single system. The LSA ID has no 145 topological significance. 147 2.3. LSA Format Overview 149 2.3.1. LSA Header 151 The Traffic Engineering LSA starts with the standard LSA header: 153 0 1 2 3 154 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | LS age | Options | 10 | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | 1 | Reserved | Instance | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Advertising Router | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | LS sequence number | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | LS checksum | Length | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 2.3.2. TLV Header 169 The LSA payload consists of one or more nested Type/Length/Value 170 (TLV) triplets for extensibility. The format of each TLV is: 172 0 1 2 3 173 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Type | Length | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Value... | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 The Length field defines the length of the value portion in octets 181 (thus a TLV with no value portion would have a length of zero). The 182 TLV is padded to four-octet alignment; padding is not included in 183 the length field (so a three octet value would have a length of 184 three, but the total size of the TLV would be eight octets). Nested 185 TLVs are also 32-bit aligned. Unrecognized types are ignored. All 186 types between 32768 and 65535 are reserved for vendor-specific 187 extensions. All other undefined type codes are reserved for future 188 assignment by IANA. 190 2.4. LSA payload details 192 An LSA contains one top-level TLV. 194 There are two top-level TLVs defined: 196 1 - Router Address 197 2 - Link 199 2.4.1. Router Address TLV 201 The Router Address TLV specifies a stable IP address of the 202 advertising router that is always reachable if there is any 203 connectivity to it. This is typically implemented as a "loopback 204 address"; the key attribute is that the address does not become 205 unusable if an interface is down. In other protocols this is known 206 as the "router ID," but for obvious reasons this nomenclature is 207 avoided here. 209 If IS-IS is also active in the domain, this address can also be used 210 to compute the mapping between the OSPF and IS-IS topologies. For 211 example, suppose a router R is advertising both IS-IS and OSPF 212 Traffic Engineering LSAs, and suppose further that some router S is 213 building a single Traffic Engineering Database (TED) based on both 214 IS-IS and OSPF TE information. R may then appear as two separate 215 nodes in S's TED; however, if both the IS-IS and OSPF LSAs generated 216 by R contain the same Router Address, then S can determine that the 217 IS-IS TE LSA and the OSPF TE LSA from R are indeed from a single 218 router. 220 The router address TLV is type 1, and has a length of 4, and the 221 value is the four octet IP address. It must appear in exactly one 222 Traffic Engineering LSA originated by a router. 224 2.4.2. Link TLV 226 The Link TLV describes a single link. It is constructed of a set of 227 sub-TLVs. There are no ordering requirements for the sub-TLVs. 229 Only one Link TLV shall be carried in each LSA, allowing for fine 230 granularity changes in topology. 232 The Link TLV is type 2, and the length is variable. 234 The following sub-TLVs are defined: 236 1 - Link type (1 octet) 237 2 - Link ID (4 octets) 238 3 - Local interface IP address (4 octets) 239 4 - Remote interface IP address (4 octets) 240 5 - Traffic engineering metric (4 octets) 241 6 - Maximum bandwidth (4 octets) 242 7 - Maximum reservable bandwidth (4 octets) 243 8 - Unreserved bandwidth (32 octets) 244 9 - Resource class/color (4 octets) 246 32768-32772 - Reserved for Cisco-specific extensions 248 The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear 249 exactly once. All other sub-TLVs defined here may occur at most 250 once. These restrictions need not apply to future sub-TLVs. 251 Unrecognized sub-TLVs are ignored. 253 2.5. Sub-TLV Details 255 2.5.1. Link Type 257 The Link Type sub-TLV defines the type of the link: 259 1 - Point-to-point 260 2 - Multiaccess 262 The Link Type sub-TLV is TLV type 1, and is one octet in length. 264 2.5.2. Link ID 266 The Link ID sub-TLV identifies the other end of the link. For point- 267 to-point links, this is the Router ID of the neighbor. For 268 multiaccess links, this is the interface address of the designated 269 router. The Link ID is identical to the contents of the Link ID 270 field in the Router LSA for these link types. 272 The Link ID sub-TLV is TLV type 2, and is four octets in length. 274 2.5.3. Local Interface IP Address 276 The Local Interface IP Address sub-TLV specifies the IP address(es) 277 of the interface corresponding to this link. If there are multiple 278 local addresses on the link, they are all listed in this sub-TLV. 280 The Local Interface IP Address sub-TLV is TLV type 3, and is 4N 281 octets in length, where N is the number of local addresses. 283 2.5.4. Remote Interface IP Address 285 The Remote Interface IP Address sub-TLV specifies the IP address(es) 286 of the neighbor's interface corresponding to this link. This and the 287 local address are used to discern multiple parallel links between 288 systems. 290 The Remote Interface IP Address sub-TLV is TLV type 4, and is 4N 291 octets in length, where N is the number of neighbor addresses. 293 2.5.5. Traffic Engineering Metric 295 The Traffic Engineering Metric sub-TLV specifies the link metric for 296 traffic engineering purposes. This metric may be different than the 297 standard OSPF link metric. 299 The Traffic Engineering Metric sub-TLV is TLV type 5, and is four 300 octets in length. 302 2.5.6. Maximum Bandwidth 304 The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that 305 can be used on this link in this direction (from the system 306 originating the LSA to its neighbor), in IEEE floating point format. 307 This is the true link capacity. The units are bytes per second. 309 The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in 310 length. 312 2.5.7. Maximum Reservable Bandwidth 314 The Maximum Reservable Bandwidth sub-TLV specifies the maximum 315 bandwidth that may be reserved on this link in this direction, in 316 IEEE floating point format. Note that this may be greater than the 317 maximum bandwidth (in which case the link may be oversubscribed). 318 This SHOULD be user-configurable; the default value should be the 319 Maximum Bandwidth. The units are bytes per second. 321 The Maximum Reservable Bandwidth sub-TLV is TLV type 7, and is four 322 octets in length. 324 2.5.8. Unreserved Bandwidth 326 The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth 327 not yet reserved at each of the eight priority levels, in IEEE 328 floating point format. The values correspond to the bandwidth that 329 can be reserved with a setup priority of 0 through 7, arranged in 330 increasing order with priority 0 occurring at the start of the sub- 331 TLV, and priority 7 at the end of the sub-TLV. The initial values 332 (before any bandwidth is reserved) are all set to the Maximum 333 Reservable Bandwidth. Each value will be less than or equal to the 334 Maximum Reservable Bandwidth. The units are bytes per second. 336 The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets in 337 length. 339 2.5.9. Resource Class/Color 341 The Resource Class/Color sub-TLV specifies administrative group 342 membership for this link, in terms of a bit mask. A link that is a 343 member of multiple groups will have multiple bits set. 345 The Resource Class/Color sub-TLV is TLV type 9, and is four octets in 346 length. 348 3. Elements of Procedure 350 Routers shall originate Traffic Engineering LSAs whenever the LSA 351 contents change, and whenever otherwise required by OSPF (an LSA 352 refresh, for example). 354 Upon receipt of a changed Traffic Engineering LSA or Network LSA 355 (since these are used in traffic engineering calculations), the 356 router should update its traffic engineering database. No SPF or 357 other route calculations are necessary. 359 4. Compatibility Issues 361 There should be no interoperability issues with routers that do not 362 implement these extensions, as the Opaque LSAs will be silently 363 ignored. 365 The result of having routers that do not implement these extensions 366 is that the traffic engineering topology will be missing pieces; 367 however, if the topology is connected, TE paths can still be 368 calculated and ought to work. 370 5. Security Considerations 372 This document raises no new security issues for OSPF. 374 6. References 376 [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 378 [2] Awduche, D., et al, "Requirements for Traffic Engineering Over 379 MPLS," RFC 2702, September 1999. 381 [3] Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering," 382 work in progress. 384 [4] Kompella, K., Rekhter, Y., et al, "OSPF Extensions in Support of 385 Generalized MPLS," work in progress. 387 [5] Kompella, K., Rekhter, Y., and Kullberg, A., "Signalling 388 Unnumbered Links in CR-LDP," work in progress. 390 [6] Kompella, K., and Rekhter, Y., "Signalling Unnumbered Links in 391 RSVP-TE," work in progress. 393 [7] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998. 395 7. Authors' Addresses 397 Dave Katz 398 Juniper Networks 399 1194 N. Mathilda Ave. 400 Sunnyvale, CA 94089 USA 402 Phone: +1 408 745 2000 403 Email: dkatz@juniper.net 405 Derek M. Yeung 406 Procket Networks, Inc. 407 1100 Cadillac Court 408 Milpitas, CA 95035 USA 410 Phone: +1 408 635-7900 411 Fax: +1 408 987-6166 413 Kireeti Kompella 414 Juniper Networks 415 1194 N. Mathilda Ave. 416 Sunnyvale, CA 94089 USA 418 Phone: +1 408 745 2000 419 Email: kireeti@juniper.net