idnits 2.17.1 draft-ietf-mpls-lsp-hierarchy-01.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 == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 61 lines 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 98: '... MAY be configured for the FA-LSP: t...' RFC 2119 keyword, line 136: '... link (see [UNNUM]). The interface identifier MUST be unique within...' RFC 2119 keyword, line 199: '...s a Path TLV, it MUST be the case that...' RFC 2119 keyword, line 345: '...the tunneled LSP MUST be tunneled over...' RFC 2119 keyword, line 354: '...uding IP header, MAY also be encapsula...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 402 has weird spacing: '...itiates a new...' -- 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) == Missing Reference: '1-4' is mentioned on line 351, but not defined == Outdated reference: A later version (-05) exists of draft-kompella-mpls-bundle-02 -- Possible downref: Normative reference to a draft: ref. 'BUNDLE' == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-01 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-01 == Outdated reference: A later version (-02) exists of draft-kompella-mpls-unnum-01 -- Possible downref: Normative reference to a draft: ref. 'UNNUM' Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Kireeti Kompella 2 Internet Draft Juniper Networks 3 Expiration Date: March 2001 Yakov Rekhter 4 Cisco Systems 6 LSP Hierarchy with MPLS TE 8 draft-ietf-mpls-lsp-hierarchy-01.txt 10 1. Status of this Memo 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 2. Abstract 33 To improve scalability of MPLS TE it may be useful to aggregate TE 34 LSPs. The aggregation is accomplished by (a) an LSR creating a TE 35 LSP, (b) the LSR forming a forwarding adjacency out of that LSP 36 (advertising this LSP as a link into ISIS/OSPF), (c) allowing other 37 LSRs to use forwarding adjacencies for their path computation, and 38 (d) nesting of LSPs originated by other LSRs into that LSP (by using 39 the label stack construct). 41 This document describes the mechanisms to accomplish this. 43 3. Overview 45 An LSR uses MPLS TE procedures to create and maintain an LSP. The 46 LSR then may (under its local configuration control) announce this 47 LSP as a link into ISIS/OSPF. When this link is advertised into the 48 same instance of ISIS/OSPF as the one that determines the route taken 49 by the LSP, we call such a link a "forwarding adjacency". We refer 50 to the LSP as the "forwarding adjacency LSP", or just FA-LSP. Note 51 that since the advertised entity is a link in ISIS/OSPF, both the end 52 point LSRs of the FA-LSP must belong to the same ISIS level/OSPF 53 area. 55 In general, creation/termination of a forwarding adjacency and its 56 FA-LSP could be driven either by mechanisms outside of MPLS (e.g., 57 via configuration control on the LSR at the head-end of the 58 adjacency), or by mechanisms within MPLS (e.g., as a result of the 59 LSR at the head-end of the adjacency receiving LSP setup requests 60 originated by some other LSRs). 62 ISIS/OSPF floods the information about forwarding adjacencies just as 63 it floods the information about any other links. As a result of this 64 flooding, an LSR has in its link state database the information about 65 not just conventional links, but forwarding adjacencies as well. 67 An LSR, when performing path computation, uses not just conventional 68 links, but forwarding adjacencies as well. Once a path is computed, 69 the LSR uses RSVP/CR-LDP for establishing label binding along the 70 path. 72 In this document we define mechanisms/procedures to accomplish the 73 above. These mechanisms/procedures cover both the routing 74 (ISIS/OSPF) and the signalling (RSVP/CR-LDP) aspects. 76 4. Routing aspects 78 In this section we describe procedures for constructing forwarding 79 adjacencies out of LSPs, and handling of forwarding adjacencies by 80 ISIS/OSPF. Specifically, this section describes how to construct the 81 information needed to advertise LSPs as links into ISIS/OSPF. 82 Procedures for creation/termination of such LSPs are defined in 83 Section 6. 85 Forwarding adjacencies may be represented as either unnumbered or 86 numbered links. 88 If there are multiple LSPs that all originate on one LSR and all 89 terminate on another LSR, then at one end of the spectrum all these 90 LSPs could be merged (under control of the head-end LSR) into a 91 single forwarding adjacency using the concept of Link Bundling (see 92 [BUNDLE], while at the other end of the spectrum each such LSP could 93 be advertised as its own adjacency. 95 When a forwarding adjacency is created under administrative control 96 (static provisioning), the attributes of this adjacency have to be 97 provided via configuration. Specifically, the following attributes 98 MAY be configured for the FA-LSP: the head-end address (if left 99 unconfigured, this defaults to the head-end LSR's Router ID); the 100 tail-end address (if left unconfigured, the FA will be unnumbered); 101 bandwidth and resource colors constraints. The path taken by the 102 FA-LSP may be either computed by the LSR at the head-end of the FA- 103 LSP, or specified by explicit configuration; this choice is 104 determined by configuration. 106 When a forwarding adjacency is created dynamically, its attributes 107 are inherited from the LSP which induced its creation. Note that the 108 bandwidth of the FA-LSP must be at least as big as the LSP that 109 induced it, but may be bigger if only discrete bandwidths are 110 available for the FA-LSP. In general, for dynamically provisioned 111 forwarding adjacencies, a policy-based mechanism may be needed to 112 associate attributes to forwarding adjacencies. 114 4.1. Traffic Engineering parameters 116 In this section, the Traffic Engineering parameters (see [OSPF-TE] 117 and [ISIS-TE]) for forwarding adjacencies are described. 119 4.1.1. Link type (OSPF only) 121 The Link Type of a forwarding adjacency is set to "point-to-point". 123 4.1.2. Link ID (OSPF only) 125 The Link ID is set to the Router ID of the tail end of FA-LSP. 127 4.1.3. Local and remote interface IP address 129 If the FA is to be numbered, the local interface IP address (OSPF) or 130 IPv4 interface address (ISIS) is set to the head-end address of the 131 FA-LSP. The remote interface IP address (OSPF) or IPv4 neighbor 132 address (ISIS) is set to the tail-end address of the FA-LSP. 134 If the FA is to be unnumbered, the advertising LSR must assign an 135 interface identifier to the FA, just like to any other unnumbered 136 link (see [UNNUM]). The interface identifier MUST be unique within 137 the scope of the advertising LSR. The local interface IP address 138 (OSPF) or IPv4 interface address (ISIS) is set to the router ID of 139 the head end of the FA-LSP. The first two octets of the remote 140 interface IP address (OSPF) or IPv4 neighbor address (ISIS) are set 141 to zero; the remaining two octets are set to the assigned interface 142 identifier. 144 If an FA-LSP does not have a tail-end address, the advertised FA is 145 unnumbered. However, one may configure an FA to be unnumbered even 146 if the corresponding FA-LSP has a tail-end address, for example in 147 the case that there are multiple FA-LSPs to the same tail-end 148 address. 150 4.1.4. Traffic Engineering metric 152 By default the TE metric on the forwarding adjacency is set to max(1, 153 (the TE metric of the FA-LSP path) - 1) so that it attracts traffic 154 in preference to setting up a new LSP. This may be overridden via 155 configuration at the head-end of the forwarding adjacency. 157 4.1.5. Maximum bandwidth 159 By default the maximum reservable bandwidth and the initial maximum 160 LSP bandwidth for all priorities of the forwarding adjacency is set 161 to the bandwidth of the FA-LSP. These may be overridden via 162 configuration at the head-end of the forwarding adjacency (note that 163 the maximum LSP bandwidth at any one priority should be no more than 164 the bandwidth of the FA-LSP). 166 4.1.6. Unreserved bandwidth 168 By default, the initial unreserved bandwidth for all priority levels 169 of the forwarding adjacency is set to the bandwidth of the FA-LSP. 171 4.1.7. Resource class/color 173 By default, a forwarding adjacency does not have resource colors 174 (administrative groups). This may be overridden by configuration at 175 the head-end of the forwarding adjacency. 177 4.1.8. Link Mux Capability 179 The Link Mux Capability (see Section 7.1) associated with the 180 forwarding adjacency is the Link Mux Capability of the last link in 181 the FA-LSP. 183 4.1.9. Path information 185 A forwarding adjacency advertisement could contain the information 186 about the path taken by the FA-LSP associated with that forwarding 187 adjacency. This information may be used for path calculation by other 188 LSRs. This information is carried in the Path TLV. In both IS-IS and 189 OSPF, this TLV is encoded as follows: the type is TBD, the length is 190 4 times the path length, and the value is a list of 4 octet IPv4 191 addresses identifying the links in the order that they form the path 192 of the forwarding adjacency. 194 It is possible that the underlying Path information might change over 195 time, via configuration updates, or dynamic route modifications, 196 resulting in the change of the Path TLV. 198 If forwarding adjacencies are bundled (via link bundling), and if the 199 resulting bundled link carries a Path TLV, it MUST be the case that 200 the underlying path followed by each of the FA-LSPs that form the 201 component links is the same. 203 5. Other considerations 205 It is expected that forwarding adjacencies will not be used for 206 establishing ISIS/OSPF peering relation between the routers at the 207 ends of the adjacency. 209 It may be desired in some cases that forwarding adjacencies only be 210 used in Traffic Engineering path computations. In IS-IS, this can be 211 accomplished by setting the default metric of the extended IS 212 reachability TLV for the FA to the maximum link metric (2^24 - 1). 213 In OSPF, this can be accomplished by not advertising the link as a 214 regular LSA, but only as a TE opaque LSA. 216 Since LSPs are in general unidirectional, it follows that forwarding 217 adjacencies are (by definition) unidirectional links. Therefore, the 218 TE path computation procedures should not perform two-way 219 connectivity check on the links used by the procedures. 221 6. Controlling FA-LSPs boundaries 223 To facilitate controlling the boundaries of FA-LSPs this document 224 introduces two new mechanisms: Link Mux Capability, and "LSP region" 225 (or just "region"). 227 6.1. Link Mux Capability sub-TLV 229 Associated with each link (including forwarding adjacencies) is a new 230 attribute - Link Mux Capability. In this section we define the Link 231 Mux Capability sub-TLV and describe the various values it can take. 233 A network may have links with different multiplexing/demultiplexing 234 capabilities. For example, a node may not be able to demultiplex 235 individual packets on a given link, but it may be able to multiplex/ 236 demultiplex channels within a SONET payload. The Link Mux Capability 237 sub-TLV identifies the associated multiplexing/demultiplexing 238 capability of a link. If there is no Link Mux Capability attribute 239 for a link, the link is assumed to be packet-switch capable (PSC-1). 241 In ISIS the Link Mux Capability is a sub-TLV of the extended IS 242 reachability TLV (type 22) as defined in [ISIS-TE]. The type of the 243 Link Mux Capability sub-TLV is 19. The length of the TLV is one 244 octet. The value field of the sub-TLV contains the Link Mux 245 Capability, encoded as follows: 247 Value Link Mux Capabilities 248 1 Packet-Switch Capable-1 (PSC-1) 249 2 Packet-Switch Capable-2 (PSC-2) 250 3 Packet-Switch Capable-3 (PSC-3) 251 4 Packet-Switch Capable-4 (PSC-4) 252 51 Layer-2 Switch Capable (L2SC) 253 100 Time-Division-Multiplex Capable (TDM) 254 150 Lambda-Switch Capable (LSC) 255 200 Fiber-Switch Capable (FSC) 257 In the OSPF Traffic Engineering LSA, the Link Mux Capability is a 258 sub-TLV of the Link TLV as defined in [OSPF-TE], with type 11 and 259 length of four octets. The value field is taken from the above list. 260 The format of the Link Mux Capability sub-TLV is as shown in the next 261 figure. 263 If a link is of type L2SC, that means that the node receiving layer 2 264 frames over this link can switch the received frames based on the 265 layer 2 address. For example, a link terminating on an ATM switch 266 would be considered L2SC. 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | 11 | Length | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Link Mux Cap. | Reserved | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 If a link is of type PSC-1 through PSC-4, that means that the node 277 receiving data over this link can demultiplex (switch) the received 278 data on a packet-by-packet basis. The various levels of PSC 279 establish a hierarchy of LSPs tunneled within LSPs. 281 If a link is of type TDM, that means that the node receiving data 282 over this link can multiplex or demultiplex channels within a 283 SONET/SDH payload. 285 If a link is of type LSC, that means that the node receiving data 286 over this link can recognize and switch individual lambdas within the 287 link (fiber). 289 If a link is of type FSC, that means that the node receiving data 290 over this link (fiber) can switch the entire contents to another link 291 (fiber) (without distinguishing lambdas, channels or packets). 293 Note that the node that is advertising a given link (i.e., the node 294 that is transmitting) needs to know the multiplex/demultiplex 295 capabilities at the other end of the link (i.e., the receiving end of 296 the link). One way to accomplish this is through configuration. 297 Other options to accomplish this are outside the scope of this 298 document. 300 6.2. LSP regions 302 The information carried in the Link Mux Capabilities is used to 303 construct LSP regions, and determine regions' boundaries as follows. 305 Define an ordering among link mux capabilities as follows: PSC-1 < 306 PSC-2 < PSC-3 < PSC-4 < TDM < LSC < FSC. Given two links link-1 and 307 link-2 with link mux capabilities lmc-1 and lmc-2 respectively, say 308 that link-1 < link-2 iff lmc-1 < lmc-2 or lmc-1 == lmc-2 == TDM, and 309 link-1's bandwidth is less than link-2's switching granularity. 311 Suppose an LSP's path is as follows: node-0, link-1, node-1, link-2, 312 node-2, ..., link-n, node-n. If link-i < link-(i+1), we say that the 313 LSP has crossed a region boundary at node-i; with respect to that LSP 314 path, the LSR at node-i is an edge LSR. The 'other edge' of the 315 region with respect to the LSP path is node-k, where k is the 316 smallest number greater than i+1 such that link-k <= link-i. 318 Path computation may take into account region boundaries when 319 computing a path for an LSP. For example, path computation may 320 restrict the path taken by an LSP to only the links whose Link Mux 321 Capability is PSC-1. 323 7. Signalling aspects 325 In this section we describe procedures that an LSR at the head-end of 326 a forwarding adjacency uses for handling LSP setup originated by 327 other LSR. 329 As we mentioned before, establishment/termination of FA-LSPs may 330 triggered either by mechanisms outside of MPLS (e.g., via 331 administrative control), or by mechanisms within MPLS (e.g., as a 332 result of the LSR at the edge of an aggregate LSP receiving LSP setup 333 requests originated by some other LSRs beyond LSP aggregate and its 334 edges). Procedures described in Section 7.1 applied to both cases. 335 Procedures described in Section 7.2 apply only to the latter case. 337 7.1. Common procedures 339 For the purpose of processing the ERO in a Path/Request message of an 340 LSP that is to be tunneled over a forwarding adjacency, an LSR at the 341 head-end of the FA-LSP views the LSR at the tail of that FA-LSP as 342 adjacent (one IP hop away). 344 If the Link Mux Capability of the FA-LSP is PSC[1-4], the 345 Path/Request message for the tunneled LSP MUST be tunneled over the 346 FA-LSP. If the encapsulation on the carrier LSP can distinguish IP 347 from MPLS, the Path/Request message is sent as a plain IP packet. 348 Otherwise, the Path/Request message is sent with a label of 0, 349 meaning "pop the label and treat as IP". 351 If the Link Mux Capability of the FA-LSP is not PSC[1-4], the Path 352 message is unicast over the control plane to the tail of the carrier 353 LSP, without the Router Alert option. The whole Path message, 354 including IP header, MAY also be encapsulated in another IP header 355 whose destination IP address matches the tail's IP address. 357 The Resv/Mapping message back to the head-end of the FA-LSP (PHOP) 358 cannot be sent over the same FA-LSP as it is unidirectional. The 359 Resv/Mapping message can either take any packet-switch capable LSP 360 whose end-point is the head-end of the FA-LSP, or be unicast over the 361 control plane to the head-end. RSVP Resv Messages MAY be 362 encapsulated in another IP header whose destination IP address 363 matches the head-end's IP address. 365 When an LSP is tunneled through an FA-LSP, the LSR at the head-end of 366 the FA-LSP subtracts the LSP's bandwidth from the unreserved 367 bandwidth of the forwarding adjacency. 369 In the presence of link bundling (when link bundling is applied to 370 forwarding adjacencies), when an LSP is tunneled through an FA-LSP, 371 the LSR at the head-end of the FA-LSP also need to adjust Max LSP 372 bandwidth of the forwarding adjacency. 374 7.2. Specific procedures 376 When an LSR receives a Path/Request message, the LSR determines 377 whether it is at the edge of a region with respect to the ERO carried 378 in the message. The LSR does this by looking up the link mux 379 capabilities of the previous hop and the next hop in its IGP 380 database, and comparing them using the relation defined in Section 381 7.2. If the LSR is not at the edge of a region, the procedures in 382 this section do not apply. 384 If the LSR is at the edge of a region, it must then determine the 385 other edge of the region with respect to the ERO, again using the IGP 386 database. The LSR then extracts the strict hop subsequence from 387 itself to the other end of the region. 389 The LSR then compares the strict hop subsequence with all existing 390 FA-LSPs originated by the LSR; if a match is found, that FA-LSP has 391 enough unreserved bandwidth for the LSP being signaled, and the L3PID 392 of the FA-LSP is compatible with the L3PID of the LSP being signaled, 393 the LSR uses that FA-LSP as follows. The Path/Request message for 394 the original LSP is sent to the egress of the FA-LSP, not to the next 395 hop along the FA- LSP's path. The PHOP in the message is the address 396 of the LSR at the head-end of the FA-LSP. Before sending the 397 Path/Request message, the ERO in that message is adjusted by removing 398 the subsequence of the ERO that lies in the FA-LSP, and replacing it 399 with just the end point of the FA-LSP. 401 Otherwise (if no existing FA-LSP is found), the LSR sets up a new FA- 402 LSP. That is, it initiates a new LSP setup just for the FA-LSP. 404 After the LSR establishes the new FA-LSP, the LSR announces this LSP 405 into IS-IS/OSPF as a forwarding adjacency. 407 The unreserved bandwidth of the forwarding adjacency is computed by 408 subtracting the bandwidth of sessions pending the establishment of 409 the FA-LSP associated from the bandwidth of the FA-LSP. 411 An FA-LSP could be torn down by the LSR at the head-end of the FA-LSP 412 as a matter of policy local to the LSR. It is expected that the FA- 413 LSP would be torn down once there are no more LSPs carried by the 414 FA-LSP. When the FA-LSP is torn down, the forwarding adjacency 415 associated with the FA-LSP is no longer advertised into IS-IS/OSPF. 417 7.3. FA-LSP Holding Priority 419 The value of the holding priority of an FA-LSP must be the minimum of 420 the configured holding priority of the FA-LSP and the holding 421 priorities of the LSPs tunneling through the FA-LSP (note that 422 smaller priority values denote higher priority). Thus, if an LSP of 423 higher priority than the FA-LSP tunnels through the FA-LSP, the FA- 424 LSP is itself promoted to the higher priority. However, if the 425 tunneled LSP is torn down, the FA-LSP need not drop its priority to 426 its old value right away; it may be advisable to apply hysteresis in 427 this case. 429 If the holding priority of an FA-LSP is configured, this document 430 restricts it to 0. 432 8. Security Considerations 434 Security issues are not discussed in this document. 436 9. Acknowledgements 438 Many thanks to Alan Hannan, whose early discussions with Yakov 439 Rekhter contributed greatly to the notion of Forwarding Adjacencies. 440 We would also like to thank George Swallow, Quaizar Vohra and Ayan 441 Banerjee. 443 10. References 445 [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 446 MPLS Traffic Engineering", draft-kompella-mpls-bundle-02.txt (work in 447 progress) 449 [ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic 450 Engineering", draft-ietf-isis-traffic-01.txt (work in progress) 452 [OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to 453 OSPF", draft-katz-yeung-ospf-traffic-01.txt (work in progress) 455 [UNNUM] Kompella, K., Rekhter, Y., "Traffic Engineering with 456 Unnumbered Links", draft-kompella-mpls-unnum-01.txt (work in 457 progress) 459 11. Author Information 461 Kireeti Kompella 462 Juniper Networks, Inc. 463 385 Ravendale Drive 464 Mountain View, CA 94043 465 e-mail: kireeti@juniper.net 467 Yakov Rekhter 468 Cisco Systems, Inc. 469 170 West Tasman Drive 470 San Jose, CA 95134 471 e-mail: yakov@cisco.com