idnits 2.17.00 (12 Aug 2021) /tmp/idnits3580/draft-kompella-ospf-ompls-extensions-00.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 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 an Authors' Addresses Section. ** 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 174: '...lly, the protection bearer channel MAY...' 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 (-03) exists of draft-awduche-mpls-te-optical-01 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-01) exists of draft-basak-mpls-oxc-issues-00 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: draft-katz-yeung-ospf-traffic has been published as RFC 3630 == Outdated reference: A later version (-05) exists of draft-kompella-mpls-bundle-02 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: draft-ietf-mpls-lsp-hierarchy has been published as RFC 4206 -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: A later version (-02) exists of draft-lang-mpls-lmp-00 -- Possible downref: Normative reference to a draft: ref. '7' Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Kompella (Juniper Networks) 2 Internet Draft Y. Rekhter (Cisco Systems) 3 Expiration Date: January 2001 A. Banerjee (Calient Networks) 4 J. Drake (Calient Networks) 5 G. Bernstein (Ciena) 6 D. Fedyk (Nortel Networks) 7 E. Mannie (GTS Network) 8 D. Saha (Tellium) 9 V. Sharma (Tellabs) 11 OSPF Extensions in Support of MPL(ambda)S 13 draft-kompella-ospf-ompls-extensions-00.txt 15 1. Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 2. Abstract 38 This document specifies extensions to the OSPF routing protocol in 39 support of Multiprotocol Lambda Switching (MPL(ambda)S). 41 3. Introduction 43 This document specifies extensions to the OSPF routing protocol in 44 support of carrying link state information for Multiprotocol Lambda 45 Switching (MPL(ambda)S). For motivations and overall architecture of 46 MPL(ambda)S see [1]. The set of required enhancements to OSPF are 47 outlined in [2]. This document enhances the routing extensions [3] 48 required to support MPLS Traffic Engineering. Some of these 49 enhancements also need to be carried in the signaling protocols [6]. 51 The organization of the remainder of the document is as follows. In 52 Section 4, we describe the types of links that may be advertised in 53 OSPF TE LSAs. In Section 5, we define a new set of Type/Length/Value 54 (TLV) triplets, and describe their formats. 56 4. MPL(ambda)S Links 58 In this section we describe the various types of links that can be 59 announced in OSPF TE LSAs, namely, normal links, non-packet links, 60 and forwarding adjacencies. 62 4.1. Normal links 64 If the nodes on both ends of a link can send and receive on a packet- 65 by-packet basis, this link is a normal link. Control packets (OSPF 66 protocol packets and signaling packets) and data packets can be sent 67 over the link, so nothing special needs to be done. 69 4.2. Non-packet links 71 If either node on the end of a bi-directional link cannot 72 multiplex/demultiplex individual packets on that link (see [5]) then 73 that link cannot be used for sending OSPF hellos and LSAs. In this 74 case, a proxy control channel is needed for sending and receiving 75 control packets. From OSPF's point of view, the combination of the 76 data link (in the context of this document, a non-packet link is also 77 called a bearer channel) and the control channel is a single link; 78 the TE attributes associated with this link are those of the bearer 79 channel, but are sent over the control channel. 81 The association of a bearer channel with a control channel is by 82 configuration. Note that for a bearer channel D to be associated 83 with a control channel C, D and C should have the same end points, 84 and that the same association must be made at both ends. The means 85 by which it is verified that the two ends have the same associations 86 is outside the scope of this document, however, see [7]. 88 If there are several non-packet links between the same pair of nodes, 89 the associated control channels may be logical interfaces over the 90 same physical control link. 92 4.2.1. Excluding data traffic from control channels 94 The control channels between nodes in an MPL(ambda)S network, such as 95 optical cross-connects (OXCs) (see [1], [2]), SONET cross-connects 96 and/or routers, are generally meant for control and administrative 97 traffic. These control channels are advertised into OSPF as normal 98 IP links as mentioned in the previous section; this allows the 99 routing of (for example) RSVP messages and telnet sessions. However, 100 if routers on the edge of the optical domain attempt to forward data 101 traffic over these channels, the channel capacity will quickly be 102 exhausted. 104 If one assumes that data traffic is sent to BGP destinations, and 105 control traffic to IGP destinations, then one can exclude data 106 traffic from the control plane by restricting BGP nexthop resolution. 107 (It is assumed that OXCs are not BGP speakers.) Suppose that a 108 router R is attempting to install a route to a BGP destination D. R 109 looks up the BGP nexthop for D in its IGP's routing table. Say R 110 finds that the path to the nexthop is over interface I. R then 111 checks if it has an entry in its Link State database associated with 112 the interface I. If it does, and the link is not packet-switch 113 capable (see [5]), R installs a discard route for destination D. 114 Otherwise, R installs (as usual) a route for destination D with 115 nexthop I. Note that R need only do this check if it has packet- 116 switch incapable links; if all of its links are packet-switch 117 capable, then clearly this check is redundant. 119 Other techniques for excluding data traffic from control channels may 120 also be needed. 122 4.3. Forwarding Adjacency 124 An LSR uses MPLS TE procedures to create and maintain an LSP. The 125 LSR then may (under its local configuration control) to announce this 126 LSP as a link into OSPF. When this link is advertised into the same 127 instance of OSPF as the one that determines the route taken by the 128 LSP, we call such a link a "forwarding adjacency" (FA). For details 129 about FAs (for example, their TE properties, the methodology for 130 their use in constrained SPF path computation, etc) see [5]. 132 4.4. Link Bundling 134 For each type of link just described, it is possible to "bundle" 135 several links together, i.e., treat them as a single link from OSPF's 136 point of view. For example, several normal links can be advertised 137 as a single normal link. 139 The mechanisms for bundling, including the restrictions on when links 140 can be bundled and the TE attributes of the bundle are described in 141 [4]. 143 5. OSPF Routing Enhancements 145 In this section we define the routing enhancements on the various 146 types of links that can be announced in OSPF TE LSAs, namely, normal 147 links, non-packet links, and forwarding adjacencies. The Traffic 148 Engineering (TE) LSA, which is an opaque LSA with area flooding scope 149 [3], has only one top-level Type/Length/Value (TLV) triplet and has 150 one or more nested TLVs for extensibility. The top-level TLV can 151 take one of two values (1) Router Address or (2) Link. In this 152 document, we enhance the sub-TLVs for the Link TLV in support of 153 MPL(ambda)S. Specifically, we add the following sub-TLVs: 155 1. Link Protection Type, 156 2. Link Descriptor, and 157 3. Shared Risk Link Group. 159 5.1. Link Protection Type sub-TLV 161 The Link Protection Type sub-TLV represents the protection capability 162 that exists on a link. It is desirable to carry this information so 163 that it may be used by the path computation algorithm to set up LSPs 164 with appropriate protection characteristics. 166 If the link has 1+1 protection, it means that a disjoint backup 167 bearer channel is reserved and dedicated for protecting the primary 168 bearer channel. This backup bearer channel is not shared by any 169 other connection, and traffic is duplicated and carried 170 simultaneously over both channels. 172 If the link has 1:N protection, it means that for N primary bearer 173 channels, there is one disjoint backup bearer channel reserved to 174 carry the traffic. Additionally, the protection bearer channel MAY 175 carry low-priority preemptable traffic. The bandwidth of backup 176 bearer channels will be announced in the unreserved bandwidth sub-TLV 177 at the appropriate priority. 179 If the link has ring protection, it means that the primary bearer 180 channel is protected by the presence of an alternate link possibly 181 using other links and nodes in the network. 183 In the Traffic Engineering LSA, the Link Protection Type sub-TLV is a 184 sub-TLV of the Link TLV, with type 14, and length of four octets, the 185 first of which can take one of the following values: 187 Value Link Protection Type 188 0 Reserved (see signaling draft [6]) 189 1 None 190 2 1+1 191 3 1:N 192 4 Ring 194 The second octet gives a priority value, such that a new connection 195 with a priority value higher than this value is guaranteed to be 196 setup on a primary (or working) channel, and not on a secondary (or 197 protect) channel. 199 The format of the Link Protection Type sub-TLV is as shown below : 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | 14 | Length | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 |Link Prot. Type| Working Pri | Reserved | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 The Link Protection Type sub-TLV is optional and if an LSA does not 210 carry the TLV, then the Link Protection Type is unknown. 212 5.2. Link Descriptor sub-TLV 214 The Link Descriptor TLV represents the characteristics of the link, 215 in particular the link type and the bit transmission rate. These 216 characteristics represent one of the constraints on the type of LSPs 217 that could be carried over the link. 219 These characteristics should not be confused with the physical link 220 encoding or multiplex structure (if any). For example there are 221 systems where four OC-48s are switched and transported over a single 222 fiber via wavelength division multiplexing (WDM) technology. There 223 are systems where four OC-48s are transported in a transparent OC-192 224 time division multiplex (TDM) structure, i.e., all the overheads of 225 the OC-48's are persevered. In both these cases the essential 226 information from a routing perspective is that both of the links can 227 transport media of type OC-48. 229 In the Traffic Engineering LSA, the Link Descriptor sub-TLV is a sub- 230 TLV of the Link TLV, with type 12. The length is the length of the 231 list of Link Descriptors in octets. Each Link descriptor element 232 consists of the following fields: the first field is a one-octet 233 value which defines the link encoding type, the second field is a 234 one-octet value which defines the lowest priority at which that link 235 encoding type is available, the next two-octets are reserved, the 236 next field is four-octets and specifies the minimum reservable 237 bandwidth (in IEEE floating point format, the unit being bytes per 238 second) for this link encoding type, and the last four-octets 239 specifies the maximum reservable bandwidth (in IEEE floating point 240 format, the unit being bytes per second) for this link encoding type. 241 Link encoding type values are taken from the following list: 243 Value Link Encoding Type 244 1 Standard SONET 245 2 Arbitrary SONET 246 3 Standard SDH 247 4 Arbitrary SDH 248 5 Clear 249 6 GigE 250 7 10GigE 252 The format of the Link Descriptors is shown in the next figure. 254 A link having Standard SONET (or Standard SDH) link encoding type can 255 switch data at a minimum rate, which is given by the Minimum 256 Reservable Bandwidth on that link, and the maximum rate is given by 257 the Maximum Reservable Bandwidth on that link. In other words, the 258 Minimum and Maximum Reservable Bandwidth represents the leaf and the 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Link Type | Pri | Reserved | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Minimum Reservable Bandwidth | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Maximum Reservable Bandwidth | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 root of one branch within the structure of the SONET (or SDH) 270 hierarchy. An LSP on that link may reserve any bit transmission rate 271 that is allowed by the SONET (or SDH) hierarchy between the minimum 272 and maximum reservable values (the spectrum is discrete). For 273 example, consider a branch of SONET multiplexing tree : VT-1.5, 274 STS-1, STS-3c, STS-12c, STS-48c, STS-192c. If it is possible to 275 establish all these connections on a OC-192 link, it can be 276 advertised as follows: Minimum Reservable Bandwidth VT-1.5 and 277 Maximum Reservable Bandwidth STS-192. 279 A link having Arbitrary SONET (or Arbitrary SDH) link encoding type 280 can switch data at a minimum rate, which is given by the Minimum 281 Reservable Bandwidth on that link, and the maximum rate is given by 282 the Maximum Reservable Bandwidth on that link. An LSP on that link 283 may reserve any bit transmission rate that is a multiple of the 284 Minimum Reservable Bandwidth between the minimum and maximum 285 reservable values (the spectrum is discrete). 287 To handle the case where a link could support multiple branches of 288 the SONET (or SDH) multiplexing hierarchy, one could use multiple LSP 289 descriptors. For example, if a link supports VT-1.5 and VT-2 (which 290 are not part of same branch of SONET multiplexing tree), then it 291 could advertise two LSP descriptors one for each one. 293 For a link with Clear encoding, the minimum and maximum reservable 294 bandwidth will imply that the optical path is tuned to carry traffic 295 within those range of values. (Note that it should be possible to 296 carry OC-x as well as GigE or any other encoding format, as long as 297 the bit transmission rate of the data to be carried is within this 298 range). 300 For other encoding types, the minimum and maximum reservable 301 bandwidth should be set to have the same values. 303 Link Descriptors present a new constraint for LSP path computation. 305 On a bundled link we assume that either the whole link is configured 306 with the Link Descriptor Types, or each of its component links are 307 configured with the Link Descriptor Types. In the latter case, the 308 Link Descriptor Type of the bundled link is set to the set union of 309 the Link Descriptor Types for all the component links. 311 It is possible that Link Descriptor TLV will change over time, 312 reflecting the allocation/deallocation of component links. In 313 general, creation/deletion of an LSP on a link doesn't necessarily 314 result in changing the Link Descriptor of that link. For example, 315 assume that STS-1, STS-3c, STS-12c, STS-48c and STS-192c LSPs can be 316 established on a OC-192 link whose Link Type is SONET. Thus, 317 initially in the Link Descriptor the minimum reservable bandwidth is 318 set to STS-1, and the maximum reservable bandwidth is set of STS-192. 319 As soon as an LSP of STS-1 size is established on the link, it is no 320 longer capable of STS-192c. Therefore, the node advertises a 321 modified Link Descriptor indicating that the maximum reservable 322 bandwidth is no longer STS-192, but STS-48. If subsequently there is 323 another STS-1 LSP, there is no change in the Link Descriptor. The 324 Link Descriptor remains the same until the node can no longer 325 establish a STS-48c LSP over the link (which means that at this point 326 more than 144 time slots are taken by LSPs on the link). Once this 327 happened, the Link Descriptor is modified again, and the modified 328 Link Descriptor is advertised to other nodes. 330 Note that changes to the Link Descriptor TLV will also affect the 331 Unreserved Bandwidth sub-TLV with respect to bandwidth available on 332 the link. 334 5.3. Shared Risk Link Group TLV 336 A set of links may constitute a 'shared risk link group' (SRLG) if 337 they share a resource whose failure may affect all links in the set. 338 For example, two fibers in the same conduit would be in the same 339 SRLG. A link may belong to multiple SRLGs. Thus the SRLG TLV 340 describes a list of SRLGs that the link belongs to. An SRLG is 341 identified by a 32 bit number that is unique within an IGP domain. 343 The SRLG of a LSP is the union of the SRLGs of the links in the LSP. 344 The SRLG of a bundled link is the union of the SRLGs of all the 345 component links. The SRLG values are an unordered list of 4 octet 346 numbers that the link belongs to. 348 If an LSR is required to have multiple diversely routed LSPs to 349 another LSR, the path computation should attempt to route the paths 350 so that they do not have any links in common, and such that the path 351 SRLGs are disjoint. 353 The SRLG sub-TLV is a sub-TLV of the Link TLV with type 13. The 354 length is the length of the list in octets. The value is an 355 unordered list of 32 bit numbers that are the SRLGs that the link 356 belongs to. The format is as shown below: 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | 13 | 4 * No. of SRLGs in link | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Shared Risk Link Group Value | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | ............ | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Shared Risk Link Group Value | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 The SRLG TLV starts with a configured value and does not change over 371 time, unless manually reconfigured. The SRLG TLV is optional and if 372 an LSA doesn't carry the SRLG TLV, then it means that SRLG of that 373 link is unknown. 375 6. Security Considerations 377 The sub-TLVs proposed in this document does not raise any new 378 security concerns. 380 7. Acknowledgements 382 The authors would like to thank Suresh Katukam, Jonathan Lang and 383 Quaizar Vohra for their comments on the draft. 385 8. References 387 [1] Awduche, D., Rekhter, Y., Drake, J., Coltun, R., "Multi- 388 Protocol Lambda Switching: Combining MPLS Traffic Engineering 389 Control With Optical Crossconnects", 390 draft-awduche-mpls-te-optical-01.txt (work in progress) 392 [2] Basak, D., Awduche, D., Drake, J., Rekhter, Y., "Multi- 393 protocol Lambda Switching: Issues in Combining MPLS Traffic 394 Engineering Control With Optical Crossconnects", 395 draft-basak-mpls-oxc-issues-00.txt (work in progress) 397 [3] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF", 398 draft-katz-yeung-ospf-traffic-01.txt (work in progress) 400 [4] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in MPLS 401 Traffic Engineering", draft-kompella-mpls-bundle-02.txt (work 402 in progress) 404 [5] Kompella, K., Rekhter, Y., "LSP Hierarchy with MPLS TE", 405 draft-ietf-mpls-lsp-hierarchy-00.txt (work in progress) 407 [6] Optical MPLS Group, "MPLS Optical/Switching Signaling Functional 408 Description" (work in progress) 410 [7] Lang J., Mitra K., Drake J., Kompella K., Rekhter Y., Saha 411 D., Berger L., and Basak D., "Link Management Protocol", 412 draft-lang-mpls-lmp-00.txt (work in progress) 414 9. Authors' Information 416 Kireeti Kompella 417 Juniper Networks, Inc. 418 1194 N. Mathilda Ave 419 Sunnyvale, CA 94089 420 Email: kireeti@juniper.net 422 Yakov Rekhter 423 Cisco Systems, Inc. 424 170 West Tasman Drive 425 San Jose, CA 95134 426 Email: yakov@cisco.com 427 Ayan Banerjee 428 Calient Networks 429 5853 Rue Ferrari 430 San Jose, CA 95138 431 Phone: +1.408.972.3645 432 Email: abanerjee@calient.net 434 John Drake 435 Calient Networks 436 5853 Rue Ferrari 437 San Jose, CA 95138 438 Phone: (408) 972-3720 439 Email: jdrake@calient.net 441 Greg Bernstein 442 Ciena Corporation 443 10480 Ridgeview Court 444 Cupertino, CA 94014 445 Phone: (408) 366-4713 446 Email: greg@ciena.com 448 Don Fedyk 449 Nortel Networks Corp. 450 600 Technology Park Drive 451 Billerica, MA 01821 452 Phone: +1-978-288-4506 453 Email: dwfedyk@nortelnetworks.com 455 Eric Mannie 456 GTS Network Services 457 RDI Department, Core Network Technology Group 458 Terhulpsesteenweg, 6A 459 1560 Hoeilaart, Belgium 460 Phone: +32-2-658.56.52 461 E-mail: eric.mannie@gtsgroup.com 462 Debanjan Saha 463 Tellium Optical Systems 464 2 Crescent Place 465 P.O. Box 901 466 Ocean Port, NJ 07757 467 Phone: (732) 923-4264 468 Email: dsaha@tellium.com 470 Vishal Sharma 471 Tellabs Research Center 472 One Kendall Square 473 Bldg. 100, Ste. 121 474 Cambridge, MA 02139-1562 475 Phone: (617) 577-8760 476 Email: Vishal.Sharma@tellabs.com