idnits 2.17.1 draft-katz-yeung-ospf-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: ---------------------------------------------------------------------------- ** 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. 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') == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-03 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. '3') ** Obsolete normative reference: RFC 2370 (ref. '4') (Obsoleted by RFC 5250) Summary: 7 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 Dave Katz 2 Internet Draft Juniper Networks, Inc. 3 Expiration Date: August 2001 Derek Yeung 4 Procket Networks, Inc. 5 Kireeti Kompella 6 Juniper Networks, Inc. 8 Traffic Engineering Extensions to OSPF 10 draft-katz-yeung-ospf-traffic-04.txt 12 Status 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 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 Abstract 35 This document describes extensions to the OSPF protocol to support 36 Traffic Engineering, using opaque LSAs. 38 1. Introduction 40 This document specifies a method of adding traffic engineering 41 capabilities to OSPF [1]. The architecture of traffic engineering is 42 described in [2]. The semantic content of the extensions is 43 essentially identical to the corresponding extensions to IS-IS [3]. 44 It is expected that the traffic engineering extensions to OSPF will 45 continue to mirror those in IS-IS. 47 The extensions provide a way of describing the traffic engineering 48 topology (including bandwidth and administrative constraints). This 49 topology does not necessarily match the regular routed topology, 50 though this proposal depends on Network LSAs to describe multiaccess 51 links. 53 2. LSA Format 55 2.1. LSA type 57 This extension makes use of the Opaque LSA [4]. 59 Three types of Opaque LSAs exist, each of which has different 60 flooding scope. This proposal uses only Type 10 LSAs, which have 61 area flooding scope. 63 One new LSA is defined, the Traffic Engineering LSA. This LSA 64 describes routers, point-to-point links, and connections to 65 multiaccess networks (similar to a Router LSA). For traffic 66 engineering purposes, the existing Network LSA suffices for 67 describing multiaccess links, so no additional LSA is defined for 68 this purpose. 70 2.2. LSA ID 72 The LSA ID of an Opaque LSA is defined as having eight bits of type 73 and 24 bits of type-specific data. The Traffic Engineering LSA uses 74 type 1. The remaining 24 bits are broken up into eight bits of 75 reserved space (which must be zero) and sixteen bits of instance: 77 0 1 2 3 78 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 79 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 80 | 1 | Reserved | Instance | 81 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 The Instance field is an arbitrary value used to maintain multiple 84 Traffic Engineering LSAs. A maximum of 65536 Traffic Engineering 85 LSAs may be sourced by a single system. The LSA ID has no 86 topological significance. 88 2.3. LSA Format Overview 90 2.3.1. LSA Header 92 The Traffic Engineering LSA starts with the standard LSA header: 94 0 1 2 3 95 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 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | LS age | Options | 10 | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | TBD | Reserved | Instance | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | Advertising Router | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | LS sequence number | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | LS checksum | length | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 2.3.2. TLV Header 110 The LSA payload consists of one or more nested Type/Length/Value 111 (TLV) triplets for extensibility. The format of each TLV is: 113 0 1 2 3 114 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 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Type | length | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Value... | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 The length field defines the length of the value portion in bytes 122 (thus a TLV with no value portion would have a length of zero). The 123 TLV is padded to four-byte alignment; padding is not included in the 124 length field (so a three byte value would have a length of three, but 125 the total size of the TLV would be eight bytes). Nested TLVs are 126 also 32-bit aligned. Unrecognized types are ignored. All types 127 between 32768 and 65535 are reserved for vendor-specific extensions. 129 All other undefined type codes are reserved for future assignment by 130 IANA. 132 2.4. LSA payload details 134 An LSA contains one top-level TLV. 136 There are two top-level TLVs defined: 138 1 - Router Address 139 2 - Link 141 2.4.1. Router Address TLV 143 The Router Address TLV specifies a stable IP address of the 144 advertising router that is always reachable if there is any 145 connectivity to it. This is typically implemented as a "loopback 146 address"; the key attribute is that the address does not become 147 unusable if an interface is down. In other protocols this is known 148 as the "router ID," but for obvious reasons this nomenclature is 149 avoided here. 151 The router address TLV is type 1, and has a length of 4, and the 152 value is the four octet IP address. It must appear in exactly one 153 Traffic Engineering LSA originated by a router. 155 2.4.2. Link TLV 157 The Link TLV describes a single link. It is constructed of a set of 158 sub-TLVs. There are no ordering requirements for the sub-TLVs. 160 Only one Link TLV shall be carried in each LSA, allowing for fine 161 granularity changes in topology. 163 The Link TLV is type 2, and the length is variable. 165 The following sub-TLVs are defined: 167 1 - Link type (1 octet) 168 2 - Link ID (4 octets) 169 3 - Local interface IP address (4 octets) 170 4 - Remote interface IP address (4 octets) 171 5 - Traffic engineering metric (4 octets) 172 6 - Maximum bandwidth (4 octets) 173 7 - Maximum reservable bandwidth (4 octets) 174 8 - Unreserved bandwidth (32 octets) 175 9 - Resource class/color (4 octets) 177 32768-32772 - Reserved for Cisco-specific extensions 179 The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear 180 exactly once. All other sub-TLVs defined here may occur at most 181 once. These restrictions need not apply to future sub-TLVs. 182 Unrecognized sub-TLVs are ignored. 184 2.5. Sub-TLV Details 186 2.5.1. Link Type 188 The Link Type sub-TLV defines the type of the link: 190 1 - Point-to-point 191 2 - Multiaccess 193 The Link Type sub-TLV is TLV type 1, and is one octet in length. 195 2.5.2. Link ID 197 The Link ID sub-TLV identifies the other end of the link. For point- 198 to-point links, this is the Router ID of the neighbor. For 199 multiaccess links, this is the interface address of the designated 200 router. The Link ID is identical to the contents of the Link ID 201 field in the Router LSA for these link types. 203 The Link ID sub-TLV is TLV type 2, and is four octets in length. 205 2.5.3. Local Interface IP Address 207 The Local Interface IP Address sub-TLV specifies the IP address(es) 208 of the interface corresponding to this link. If there are multiple 209 local addresses on the link, they are all listed in this sub-TLV. 211 The Local Interface IP Address sub-TLV is TLV type 3, and is 4N 212 octets in length, where N is the number of local addresses. 214 2.5.4. Remote Interface IP Address 216 The Remote Interface IP Address sub-TLV specifies the IP address(es) 217 of the neighbor's interface corresponding to this link. This and the 218 local address are used to discern multiple parallel links between 219 systems. 221 The Remote Interface IP Address sub-TLV is TLV type 4, and is 4N 222 octets in length, where N is the number of neighbor addresses. 224 2.5.5. Traffic Engineering Metric 226 The Traffic Engineering Metric sub-TLV specifies the link metric for 227 traffic engineering purposes. This metric may be different than the 228 standard OSPF link metric. 230 The Traffic Engineering Metric sub-TLV is TLV type 5, and is four 231 octets in length. 233 2.5.6. Maximum Bandwidth 235 The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that 236 can be used on this link in this direction (from the system 237 originating the LSA to its neighbor), in IEEE floating point format. 238 This is the true link capacity. The units are *bytes* per second. 240 The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in 241 length. 243 2.5.7. Maximum Reservable Bandwidth 245 The Maximum Reservable Bandwidth sub-TLV specifies the maximum 246 bandwidth that may be reserved on this link in this direction, in 247 IEEE floating point format. Note that this may be greater than the 248 maximum bandwidth (in which case the link may be oversubscribed). 249 The units are bytes per second. 251 The Maximum Reservable Bandwidth sub-TLV is TLV type 7, and is four 252 octets in length. 254 2.5.8. Unreserved Bandwidth 256 The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth 257 not yet reserved at each of the eight priority levels, in IEEE 258 floating point format. Each value will be less than or equal to the 259 maximum reservable bandwidth. The units are bytes per second. 261 The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets in 262 length. 264 2.5.9. Resource Class/Color 266 The Resource Class/Color sub-TLV specifies administrative group 267 membership for this link, in terms of a bit mask. A link that is a 268 member of multiple groups will have multiple bits set. 270 The Resource Class/Color sub-TLV is TLV type 9, and is four octets in 271 length. 273 3. Elements of Procedure 275 Routers shall originate Traffic Engineering LSAs whenever the LSA 276 contents change, and whenever otherwise required by OSPF (an LSA 277 refresh, for example). 279 Upon receipt of a changed Traffic Engineering LSA or Network LSA 280 (since these are used in traffic engineering calculations), the 281 router should update its traffic engineering database. No SPF or 282 other route calculations are necessary. 284 4. Compatibility Issues 286 There should be no interoperability issues with routers that do not 287 implement these extensions, as the Opaque LSAs will be silently 288 ignored. 290 The result of having routers that do not implement these extensions 291 is that the traffic engineering topology will be missing pieces; 292 however, if the topology is connected, TE paths can still be 293 calculated and ought to work. 295 5. Security Considerations 297 This document raises no new security issues for OSPF. 299 6. References 301 [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 303 [2] Awduche, D., et al, "Requirements for Traffic Engineering Over 304 MPLS," RFC 2702, September 1999. 306 [3] Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering," 307 draft-ietf-isis-traffic-03.txt, work in progress. 309 [4] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998. 311 7. Authors' Addresses 313 Dave Katz 314 Juniper Networks 315 1194 N. Mathilda Ave. 316 Sunnyvale, CA 94089 USA 318 Phone: +1 408 745 2000 319 Email: dkatz@juniper.net 321 Derek M. Yeung 322 Procket Networks, Inc. 323 1100 Cadillac Court 324 Milpitas, CA 95035 USA 326 Phone: +1 408 635-7900 327 Fax: +1 408 987-6166 329 Kireeti Kompella 330 Juniper Networks 331 1194 N. Mathilda Ave. 332 Sunnyvale, CA 94089 USA 334 Phone: +1 408 745 2000 335 Email: kireeti@juniper.net