idnits 2.17.1 draft-katz-yeung-ospf-traffic-00.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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 128: '... implementations MUST be able to accep...' 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) == Outdated reference: A later version (-01) exists of draft-ietf-mpls-traffic-eng-00 ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-traffic-eng (ref. '2') == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-00 ** 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: 9 errors (**), 0 flaws (~~), 4 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: October 1999 Derek Yeung 4 Cisco Systems, Inc. 6 Traffic Engineering Extensions to OSPF 8 draft-katz-yeung-ospf-traffic-00.txt 10 Status 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes extensions to the OSPF protocol to support 34 Traffic Engineering, using opaque LSAs. 36 1. Introduction 38 This document specifies a method of adding traffic engineering 39 capabilities to OSPF [1]. The architecture of traffic engineering is 40 described in [2]. The semantic content of the extensions is 41 essentially identical to the corresponding extensions to IS-IS [3]. 42 It is expected that the traffic engineering extensions to OSPF will 43 continue to mirror those in IS-IS. 45 The extensions provide a way of describing the traffic engineering 46 topology (including bandwidth and administrative constraints). This 47 topology does not necessarily match the regular routed topology, 48 though this proposal depends on Network LSAs to describe multiaccess 49 links. 51 2. LSA Format 53 2.1 LSA type 55 As the baseline OSPF Router LSA is essentially non-extensible, this 56 extension makes use of the Opaque LSA [4]. h Three types of Opaque 57 LSAs exist, each of which has different flooding scope. This 58 proposal uses only Type 10 LSAs, which have area flooding scope. 60 One new LSA is defined, the Traffic Engineering LSA. This LSA 61 describes routers and point-to-point links (similar to a Router LSA). 62 For traffic engineering purposes, the existing Network LSA suffices 63 for describing multiaccess links, so no additional LSA is defined for 64 this purpose. 66 2.2 LSA ID 68 The LSA ID of an Opaque LSA is defined as having eight bits of type 69 and 24 bits of type-specific data. The Traffic Engineering LSA uses 70 type (TBD). The remaining 24 bits are broken up into eight bits of 71 reserved space (which must be zero) and sixteen bits of instance: 73 0 1 2 3 74 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 75 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 76 | TBD | Reserved | Instance | 77 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 79 The Instance field is an arbitrary value used to maintain multiple 80 Traffic Engineering LSAs. A maximum of 65536 Traffic Engineering 81 LSAs may be sourced by a single system. The LSA ID has no 82 topological significance. 84 2.3 LSA Format Overview 86 2.3.1 LSA Header 88 The Traffic Engineering LSA starts with the standard LSA header: 90 0 1 2 3 91 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 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | LS age | Options | 10 | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | TBD | Reserved | Instance | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Advertising Router | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | LS sequence number | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | LS checksum | length | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 2.3.2 TLV Header 106 The LSA payload consists of one or more nested Type/Length/Value 107 (TLV) triplets for extensibility. The format of each TLV is: 109 0 1 2 3 110 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 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Type | length | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Value... | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 The length field defines the length of the value portion in bytes 118 (thus a TLV with no value portion would have a length of zero). The 119 TLV is padded to four-byte alignment; padding is not included in the 120 length field (so a three byte value would have a length of three, but 121 the total size of the TLV would be eight bytes). Unrecognized types 122 are ignored. 124 2.4 LSA payload details 126 An LSA contains one or more top-level TLVs. As it is desirable for 127 LSAs to be small, most LSAs will contain only a single top-level TLV. 128 However, implementations MUST be able to accept an arbitrary number 129 of TLVs in each LSA. 131 There are two top-level TLVs defined: 133 1 - Router Address 134 2 - Link 136 2.4.1 Router Address TLV 138 The Router Address TLV specifies a stable IP address of the 139 advertising router that is always reachable if there is any 140 connectivity to it. This is typically implemented as a "loopback 141 address"; the key attribute is that the address does not become 142 unusable if an interface is down. In other protocols this is known 143 as the "router ID," but for obvious reasons this nomenclature is 144 avoided here. 146 This TLV has a length of 4, and the value is the four octet IP 147 address. It must appear in exactly one Traffic Engineering LSA 148 originated by a router. 150 2.4.2 Link TLV 152 The Link TLV describes a single link. It is constructed of a set of 153 sub-TLVs. There are no ordering requirements for the sub-TLVs. 155 Only one Link TLV shall be carried in each LSA, allowing for fine 156 granularity changes in topology. 158 Only numbered links are described, as traffic engineering is not 159 supported on unnumbered links. 161 The following sub-TLVs are defined: 163 1 - Link type (1 octet) 164 2 - Link ID (4 octets) 165 3 - Local interface IP address (4 octets) 166 4 - Remote interface IP address (4 octets) 167 5 - Traffic engineering metric (4 octets) 168 6 - Maximum bandwidth (4 octets) 169 7 - Maximum reservable bandwidth (4 octets) 170 8 - Unreserved bandwidth (32 octets) 171 9 - Resource class/color (4 octets) 173 Each sub-TLV may occur only once. Unrecognized types are ignored. 174 All of the defined sub-TLVs are mandatory (though future sub-TLVs may 175 not necessarily be mandatory.) 177 2.5 Sub-TLV Details 179 2.5.1 Link Type 181 The Link Type sub-TLV defines the type of the link: 183 1 - Point-to-point 184 2 - Multiaccess 186 The Link Type sub-TLV is TLV type 1, and is one octet in length. 188 2.5.2 Link ID 190 The Link ID sub-TLV identifies the other end of the link. For point- 191 to-point links, this is the Router ID of the neighbor. For 192 multiaccess links, this is the interface address of the designated 193 router. The Link ID is identical to the contents of the Link ID 194 field in the Router LSA for these link types. 196 The Link ID sub-TLV is TLV type 2, and is four octets in length. 198 2.5.3 Local Interface IP Address 200 The Local Interface IP Address sub-TLV specifies the IP address of 201 the interface corresponding to this link. Note that at the moment, 202 only numbered point-to-point links are supported for traffic 203 engineering. 205 The Local Interface IP Address sub-TLV is TLV type 3, and is four 206 octets in length. 208 2.5.4 Remote Interface IP Address 210 The Remote Interface IP Address sub-TLV specifies the IP address of 211 the neighbor's interface corresponding to this link. This and the 212 local address are used to discern multiple parallel links between 213 systems. 215 The Remote Interface IP Address sub-TLV is TLV type 4, and is four 216 octets in length. 218 2.5.5 Traffic Engineering Metric 220 The Traffic Engineering Metric sub-TLV specifies the link metric for 221 traffic engineering purposes. This metric may be different than the 222 standard OSPF link metric. 224 The Traffic Engineering Metric sub-TLV is TLV type 5, and is four 225 octets in length. 227 2.5.6 Maximum Bandwidth 229 The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that 230 can be used on this link in this direction (from the system 231 originating the LSA to its neighbor), in IEEE floating point format. 232 This is the true link capacity. The units are *bytes* per second. 234 The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in 235 length. 237 2.5.7 Maximum Reservable Bandwidth 239 The Maximum Reservable Bandwidth sub-TLV specifies the maximum 240 bandwidth that may be reserved on this link in this direction, in 241 IEEE floating point format. Note that this may be greater than the 242 maximum bandwidth (in which case the link may be oversubscribed). 243 The units are bytes per second. 245 The Maximum Reservable Bandwidth sub-TLV is TLV type 7, and is four 246 octets in length. 248 2.5.8 Unreserved Bandwidth 250 The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth 251 not yet reserved at each of the eight priority levels, in IEEE 252 floating point format. Each value will be less than or equal to the 253 reservable bandwidth. The units are bytes per second. 255 The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets in 256 length. 258 2.5.9 Resource Class/Color 260 The Resource Class/Color sub-TLV specifies administrative group 261 membership for this link, in terms of a bit mask. A link that is a 262 member of multiple groups will have multiple bits set. 264 The Resource Class/Color sub-TLV is TLV type 9, and is four octets in 265 length. 267 3. Elements of Procedure 269 Routers shall originate Traffic Engineering LSAs whenever the LSA 270 contents change, and whenever otherwise required by OSPF (an LSA 271 refresh, for example). 273 Upon receipt of a changed Traffic Engineering LSA or Network LSA 274 (since these are used in traffic engineering calculations), the 275 router should update its traffic engineering database. No SPF or 276 other route calculations are necessary. 278 4. Compatibility Issues 280 There should be no interoperability issues with routers that do not 281 implement these extensions, as the Opaque LSAs will be silently 282 ignored. Note, however, that the DR on a multiaccess network must 283 implement Opaque LSAs if any of the systems on that network do; this 284 is a requirement of Opaque LSAs that is not spelled out in the 285 document. 287 The result of having routers that do not implement these extensions 288 is that the traffic engineering topology will be missing pieces; 289 however, if the topology is connected, TE paths can still be 290 calculated and ought to work. 292 5. Security Considerations 294 This document raises no new security issues for OSPF. 296 6. References 298 [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 300 [2] Awduche, D., et al, "Requirements for Traffic Engineering Over 301 MPLS," draft-ietf-mpls-traffic-eng-00.txt, work in progress. 303 [3] Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering," 304 draft-ietf-isis-traffic-00.txt, work in progress. 306 [4] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998. 308 7. Authors' Addresses 310 Dave Katz 311 Juniper Networks 312 385 Ravendale Drive 313 Mountain View, CA 94043 USA 315 Phone: +1 650 526 8073 316 Email: dkatz@juniper.net 318 Derek M. Yeung 319 Cisco Systems, Inc. 320 210 West Tasman Dr. 321 San Jose, CA 95134 323 Phone: +1 408 526 8019 324 Email: myeung@cisco.com 326 ------- End of Forwarded Message