idnits 2.17.00 (12 Aug 2021) /tmp/idnits64220/draft-kompella-isis-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 180: '...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-ietf-isis-traffic has been published as RFC 3784 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. '3') == 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: 8 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 IS-IS Extensions in Support of MPL(ambda)S 13 draft-kompella-isis-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 IS-IS routing protocol in 39 support of Multiprotocol Lambda Switching (MPL(ambda)S). 41 3. Introduction 43 This document specifies extensions to the IS-IS 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 IS-IS 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 IS-IS TE LSAs (we call Link State PDUs LSAs to avoid confusion with 54 Label Switched Paths). In Section 5, we define a new set of 55 Type/Length/Value (TLV) triplets, as well as extend a proposed TLV, 56 and describe their formats. 58 4. MPL(ambda)S Links 60 In this section we describe the various types of links that can be 61 announced in IS-IS TE LSAs, namely, normal links, non-packet links, 62 and forwarding adjacencies. 64 4.1. Normal links 66 If the nodes on both ends of a link can send and receive on a packet- 67 by-packet basis, this link is a normal link. Control packets (IS-IS 68 protocol packets and signaling packets) and data packets can be sent 69 over the link, so nothing special needs to be done. 71 4.2. Non-packet links 73 If either node on the end of a bi-directional link cannot 74 multiplex/demultiplex individual packets on that link (see [5]) then 75 that link cannot be used for sending IS-IS hellos and LSAs. In this 76 case, a proxy control channel is needed for sending and receiving 77 control packets. From IS-IS's point of view, the combination of the 78 data link (in the context of this document, a non-packet link is also 79 called a bearer channel) and the control channel is a single link; 80 the TE attributes associated with this link are those of the bearer 81 channel, but are sent over the control channel. 83 The association of a bearer channel with a control channel is by 84 configuration. Note that for a bearer channel D to be associated 85 with a control channel C, D and C should have the same end points, 86 and that the same association must be made at both ends. The means 87 by which it is verified that the two ends have the same associations 88 is outside the scope of this document, however, see [7]. 90 If there are several non-packet links between the same pair of nodes, 91 the associated control channels may be logical interfaces over the 92 same physical control link. 94 4.2.1. Excluding data traffic from control channels 96 The control channels between nodes in an MPL(ambda)S network, such as 97 optical cross-connects (OXCs) (see [1], [2]), SONET cross-connects 98 and/or routers, are generally meant for control and administrative 99 traffic. These control channels are advertised into IS-IS as normal 100 IS links as mentioned in the previous section; this allows the 101 routing of (for example) RSVP messages and telnet sessions. However, 102 if routers on the edge of the optical domain attempt to forward data 103 traffic over these channels, the channel capacity will quickly be 104 exhausted. 106 If one assumes that data traffic is sent to BGP destinations, and 107 control traffic to IGP destinations, then one can exclude data 108 traffic from the control plane by restricting BGP nexthop resolution. 109 (It is assumed that OXCs are not BGP speakers.) Suppose that a 110 router R is attempting to install a route to a BGP destination D. R 111 looks up the BGP nexthop for D in its IGP's routing table. Say R 112 finds that the path to the nexthop is over interface I. R then 113 checks if it has an entry in its Link State database associated with 114 the interface I. If it does, and the link is not packet-switch 115 capable (see [5]), R installs a discard route for destination D. 116 Otherwise, R installs (as usual) a route for destination D with 117 nexthop I. Note that R need only do this check if it has packet- 118 switch incapable links; if all of its links are packet-switch 119 capable, then clearly this check is redundant. 121 Other techniques for excluding data traffic from control channels may 122 also be needed. 124 4.3. Forwarding Adjacency 126 An LSR uses MPLS TE procedures to create and maintain an LSP. The 127 LSR then may (under its local configuration control) to announce this 128 LSP as a link into IS-IS. When this link is advertised into the same 129 instance of IS-IS as the one that determines the route taken by the 130 LSP, we call such a link a "forwarding adjacency" (FA). For details 131 about FAs (for example, their TE properties, the methodology for 132 their use in constrained SPF path computation, etc) see [5]. 134 4.4. Link Bundling 136 For each type of link just described, it is possible to "bundle" 137 several links together, i.e., treat them as a single link from IS- 138 IS's point of view. For example, several normal links can be 139 advertised as a single normal link. 141 The mechanisms for bundling, including the restrictions on when links 142 can be bundled and the TE attributes of the bundle are described in 143 [4]. 145 5. IS-IS Routing Enhancements 147 In this section we define the routing enhancements on the various 148 types of links that can be announced in IS-IS TE LSAs, namely, normal 149 links, non-packet links, and forwarding adjacencies. In this 150 document, we enhance the sub-TLVs for the extended IS reachability 151 TLV (see [3]) in support of MPL(ambda)S. Specifically, we add the 152 following sub-TLV: 154 Sub-TLV Type Length Name 155 20 1 Link Protection Type 157 We further add two new TLVs. 159 TLV Type Length Name 160 136 (TBD) variable Link Descriptor 161 138 (TBD) variable Shared Risk Link Group 163 5.1. Link Protection Type sub-TLV 165 The Link Protection Type sub-TLV represents the protection capability 166 that exists on a link. It is desirable to carry this information so 167 that it may be used by the path computation algorithm to set up LSPs 168 with appropriate protection characteristics. This is a sub-TLV (of 169 type 20) of the extended IS reachability TLV (type 22) as defined in 170 [3]. 172 If the link has 1+1 protection, it means that a disjoint backup 173 bearer channel is reserved and dedicated for protecting the primary 174 bearer channel. This backup bearer channel is not shared by any 175 other connection, and traffic is duplicated and carried 176 simultaneously over both channels. 178 If the link has 1:N protection, it means that for N primary bearer 179 channels, there is one disjoint backup bearer channel reserved to 180 carry the traffic. Additionally, the protection bearer channel MAY 181 carry low-priority preemptable traffic. The bandwidth of backup 182 bearer channels will be announced in the unreserved bandwidth sub-TLV 183 at the appropriate priority. 185 If the link has ring protection, it means that the primary bearer 186 channel is protected by the presence of an alternate link possibly 187 using other links and nodes in the network. 189 The Link Protection Type sub-TLV has a length of two octets, the 190 first of which can take one of the following values: 192 Value Link Protection Type 193 0 Reserved (see signaling draft [6]) 194 1 None 195 2 1+1 196 3 1:N 197 4 Ring 199 The second octet gives a priority value, such that a new connection 200 with a priority value higher than this value is guaranteed to be 201 setup on a primary (or working) channel, and not on a secondary (or 202 protect) channel. 204 The Link Protection Type sub-TLV is optional and if an LSA does not 205 carry the TLV, then the Link Protection Type is unknown. 207 5.2. Link Descriptor TLV 209 The Link Descriptor TLV represents the characteristics of the link, 210 in particular the link type and the bit transmission rate. These 211 characteristics represent one of the constraints on the type of LSPs 212 that could be carried over a link. 214 These characteristics should not be confused with the physical link 215 encoding or multiplex structure (if any). For example there are 216 systems where four OC-48s are switched and transported over a single 217 fiber via wavelength division multiplexing (WDM) technology. There 218 are systems where four OC-48s are transported in a transparent OC-192 219 time division multiplex (TDM) structure, i.e., all the overheads of 220 the OC-48's are persevered. In both these cases the essential 221 information from a routing perspective is that both of the links can 222 transport media of type OC-48. 224 The proposed Link Descriptor TLV (of type 136 TBD) contains a new 225 data structure consisting of: 226 7 octets of System ID and Pseudonode Number 227 4 octets of IPv4 interface address 228 4 octets of IPv4 neighbor address 229 and a list of Link Descriptors, where each element in the list has 10 230 octets. The length of the TLV is thus 15+10*n octets, where n is the 231 number of elements in the list. 233 Each Link descriptor element consists of the following fields: the 234 first field is a one-octet value which defines the link encoding 235 type, the second field is a one-octet value which defines the lowest 236 priority at which that link encoding type is available, the third 237 field is four-octets and specifies the minimum reservable bandwidth 238 (in IEEE floating point format, the units being bytes per second) for 239 this link encoding type, and the last field is four-octets and 240 specifies the maximum reservable bandwidth (in IEEE floating point 241 format, the units being bytes per second) for this link encoding 242 type. Link encoding type values are taken from the following list: 244 Value Link Encoding Type 245 1 Standard SONET 246 2 Arbitrary SONET 247 3 Standard SDH 248 4 Arbitrary SDH 249 5 Clear 250 6 GigE 251 7 10GigE 253 A link having Standard SONET (or Standard SDH) link encoding type can 254 switch data at a minimum rate, which is given by the Minimum 255 Reservable Bandwidth on that link, and the maximum rate is given by 256 the Maximum Reservable Bandwidth on that link. In other words, the 257 Minimum and Maximum Reservable Bandwidth represents the leaf and the 258 root of one branch within the structure of the SONET (or SDH) 259 hierarchy. An LSP on that link may reserve any bit transmission rate 260 that is allowed by the SONET (or SDH) hierarchy between the minimum 261 and maximum reservable values (the spectrum is discrete). For 262 example, consider a branch of SONET multiplexing tree : VT-1.5, 263 STS-1, STS-3c, STS-12c, STS-48c, STS-192c. If it is possible to 264 establish all these connections on a OC-192 link, it can be 265 advertised as follows: Minimum Reservable Bandwidth VT-1.5 and 266 Maximum Reservable Bandwidth STS-192. 268 A link having Arbitrary SONET (or Arbitrary SDH) link encoding type 269 can switch data at a minimum rate, which is given by the Minimum 270 Reservable Bandwidth on that link, and the maximum rate is given by 271 the Maximum Reservable Bandwidth on that link. An LSP on that link 272 may reserve any bit transmission rate that is a multiple of the 273 Minimum Reservable Bandwidth between the minimum and maximum 274 reservable values (the spectrum is discrete). 276 To handle the case where a link could support multiple branches of 277 the SONET (or SDH) multiplexing hierarchy, one could use multiple LSP 278 descriptors. For example, if a link supports VT-1.5 and VT-2 (which 279 are not part of same branch of SONET multiplexing tree), then it 280 could advertise two LSP descriptors one for each one. 282 For a link with Clear encoding, the minimum and maximum reservable 283 bandwidth will imply that the optical path is tuned to carry traffic 284 within those range of values. (Note that it should be possible to 285 carry OC-x as well as GigE or any other encoding format, as long as 286 the bit transmission rate of the data to be carried is within this 287 range). 289 For other encoding types, the minimum and maximum reservable 290 bandwidth should be set to have the same values. 292 Link Descriptors present a new constraint for LSP path computation. 294 On a bundled link we assume that either the whole link is configured 295 with the Link Descriptor Types, or each of its component links are 296 configured with the Link Descriptor Types. In the latter case, the 297 Link Descriptor Type of the bundled link is set to the set union of 298 the Link Descriptor Types for all the component links. 300 It is possible that Link Descriptor TLV will change over time, 301 reflecting the allocation/deallocation of component links. In 302 general, creation/deletion of an LSP on a link doesn't necessarily 303 result in changing the Link Descriptor of that link. For example, 304 assume that STS-1, STS-3c, STS-12c, STS-48c and STS-192c LSPs can be 305 established on a OC-192 link whose Link Type is SONET. Thus, 306 initially in the Link Descriptor the minimum reservable bandwidth is 307 set to STS-1, and the maximum reservable bandwidth is set of STS-192. 308 As soon as an LSP of STS-1 size is established on the link, it is no 309 longer capable of STS-192c. Therefore, the node advertises a 310 modified Link Descriptor indicating that the maximum reservable 311 bandwidth is no longer STS-192, but STS-48. If subsequently there is 312 another STS-1 LSP, there is no change in the Link Descriptor. The 313 Link Descriptor remains the same until the node can no longer 314 establish a STS-48c LSP over the link (which means that at this point 315 more than 144 time slots are taken by LSPs on the link). Once this 316 happened, the Link Descriptor is modified again, and the modified 317 Link Descriptor is advertised to other nodes. 319 Note that changes to the Link Descriptor TLV will also affect the 320 Unreserved Bandwidth sub-TLV with respect to bandwidth available on 321 the link. 323 5.3. Shared Risk Link Group TLV 325 A set of links may constitute a 'shared risk link group' (SRLG) if 326 they share a resource whose failure may affect all links in the set. 327 For example, two fibers in the same conduit would be in the same 328 SRLG. A link may belong to multiple SRLGs. Thus the SRLG TLV 329 describes a list of SRLGs that the link belongs to. An SRLG is 330 identified by a 32 bit number that is unique within an IGP domain. 332 The SRLG of a LSP is the union of the SRLGs of the links in the LSP. 333 The SRLG of a bundled link is the union of the SRLGs of all the 334 component links. The SRLG values are an unordered list of 4 octet 335 numbers that the link belongs to. 337 If an LSR is required to have multiple diversely routed LSPs to 338 another LSR, the path computation should attempt to route the paths 339 so that they do not have any links in common, and such that the path 340 SRLGs are disjoint. 342 The proposed SRLG (of type 138 TBD) contains a new data structure 343 consisting of: 344 7 octets of System ID and Pseudonode Number 345 4 octets of IPv4 interface address 346 4 octets of IPv4 neighbor address 347 and a list of SRLG values, where each element in the list has 4 348 octets. The length of the TLV is thus 15+4*n octets, where n is the 349 number of elements in the list. 351 The SRLG TLV starts with a configured value and does not change over 352 time, unless manually reconfigured. The SRLG TLV is optional and if 353 an LSA doesn't carry the SRLG TLV, then it means that SRLG of that 354 link is unknown. 356 6. Security Considerations 358 The sub-TLVs proposed in this document does not raise any new 359 security concerns. 361 7. Acknowledgements 363 The authors would like to thank Suresh Katukam, Jonathan Lang and 364 Quaizar Vohra for their comments on the draft. 366 8. References 368 [1] Awduche, D., Rekhter, Y., Drake, J., Coltun, R., "Multi- 369 Protocol Lambda Switching: Combining MPLS Traffic Engineering 370 Control With Optical Crossconnects", 371 draft-awduche-mpls-te-optical-01.txt (work in progress) 373 [2] Basak, D., Awduche, D., Drake, J., Rekhter, Y., "Multi- 374 protocol Lambda Switching: Issues in Combining MPLS Traffic 375 Engineering Control With Optical Crossconnects", 376 draft-basak-mpls-oxc-issues-00.txt (work in progress) 378 [3] Smit, H., Li, T., "IS-IS Extensions for Traffic Engineering", 379 draft-ietf-isis-traffic-01.txt (work in progress) 381 [4] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in MPLS 382 Traffic Engineering", draft-kompella-mpls-bundle-02.txt (work 383 in progress) 385 [5] Kompella, K., Rekhter, Y., "LSP Hierarchy with MPLS TE", 386 draft-ietf-mpls-lsp-hierarchy-00.txt (work in progress) 388 [6] Optical MPLS Group, "MPLS Optical/Switching Signaling Functional 389 Description" (work in progress) 391 [7] Lang J., Mitra K., Drake J., Kompella K., Rekhter Y., Saha 392 D., Berger L., and Basak D., "Link Management Protocol", 393 draft-lang-mpls-lmp-00.txt (work in progress) 395 9. Authors' Information 397 Kireeti Kompella 398 Juniper Networks, Inc. 399 1194 N. Mathilda Ave 400 Sunnyvale, CA 94089 401 Email: kireeti@juniper.net 403 Yakov Rekhter 404 Cisco Systems, Inc. 405 170 West Tasman Drive 406 San Jose, CA 95134 407 Email: yakov@cisco.com 409 Ayan Banerjee 410 Calient Networks 411 5853 Rue Ferrari 412 San Jose, CA 95138 413 Phone: +1.408.972.3645 414 Email: abanerjee@calient.net 416 John Drake 417 Calient Networks 418 5853 Rue Ferrari 419 San Jose, CA 95138 420 Phone: (408) 972-3720 421 Email: jdrake@calient.net 423 Greg Bernstein 424 Ciena Corporation 425 10480 Ridgeview Court 426 Cupertino, CA 94014 427 Phone: (408) 366-4713 428 Email: greg@ciena.com 429 Don Fedyk 430 Nortel Networks Corp. 431 600 Technology Park Drive 432 Billerica, MA 01821 433 Phone: +1-978-288-4506 434 Email: dwfedyk@nortelnetworks.com 436 Eric Mannie 437 GTS Network Services 438 RDI Department, Core Network Technology Group 439 Terhulpsesteenweg, 6A 440 1560 Hoeilaart, Belgium 441 Phone: +32-2-658.56.52 442 E-mail: eric.mannie@gtsgroup.com 444 Debanjan Saha 445 Tellium Optical Systems 446 2 Crescent Place 447 P.O. Box 901 448 Ocean Port, NJ 07757 449 Phone: (732) 923-4264 450 Email: dsaha@tellium.com 452 Vishal Sharma 453 Tellabs Research Center 454 One Kendall Square 455 Bldg. 100, Ste. 121 456 Cambridge, MA 02139-1562 457 Phone: (617) 577-8760 458 Email: Vishal.Sharma@tellabs.com