idnits 2.17.1 draft-ietf-ccamp-lsp-stitching-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 854. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 865. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 872. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 878. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 713 has weird spacing: '...message mess...' -- 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.) -- The document date (April 2007) is 6214 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4420 (Obsoleted by RFC 5420) -- Obsolete informational reference (is this intentional?): RFC 4205 (Obsoleted by RFC 5307) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Ayyangar 3 Internet-Draft Nuova Systems 4 Intended status: Standards Track K. Kompella 5 Expires: October 2007 Juniper Networks 6 JP. Vasseur 7 Cisco Systems, Inc. 8 A. Farrel 9 Old Dog Consulting 10 April 2007 12 Label Switched Path Stitching with Generalized Multiprotocol 13 Label Switching Traffic Engineering (GMPLS TE) 15 draft-ietf-ccamp-lsp-stitching-06.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 1, 2007. 42 Abstract 44 In certain scenarios, there may be a need to combine together several 45 Generalized Multi-Protocol Label Switching (GMPLS) Label Switched 46 Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and 47 all traffic from one constituent LSP is switched onto the next LSP. 48 We will refer to this as "LSP stitching", the key requirement being 49 that a constituent LSP not be allocated to more than one e2e LSP. 50 The constituent LSPs will be referred to as "LSP segments" (S-LSPs). 52 This document describes extensions to the existing GMPLS signaling 53 protocol (RSVP-TE) to establish e2e LSPs created from from S-LSPs, 54 and describes how the LSPs can be managed using the GMPLS signaling 55 and routing protocols. 57 It may be possible to configure a GMPLS node to switch the traffic 58 from an LSP for which it is the egress, to another LSP for which it 59 is the ingress, without requiring any signaling or routing extensions 60 whatsoever, completely transparent to other nodes. This will also 61 result in LSP stitching in the data plane. However, this document 62 does not cover this scenario of LSP stitching. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 68 2. Comparison with LSP Hierarchy . . . . . . . . . . . . . . . . 4 69 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1. Triggers for LSP Segment Setup . . . . . . . . . . . . . . 6 71 3.2. Applications . . . . . . . . . . . . . . . . . . . . . . . 6 72 4. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 7 73 5. Signaling Aspects . . . . . . . . . . . . . . . . . . . . . . 8 74 5.1. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . 8 75 5.1.1. Creating and Preparing an LSP Segment for Stitching . 8 76 5.1.2. Stitching the e2e LSP to the LSP Segment . . . . . . . 10 77 5.1.3. RRO Processing for e2e LSPs . . . . . . . . . . . . . 11 78 5.1.4. Teardown of LSP Segments . . . . . . . . . . . . . . . 12 79 5.1.5. Teardown of e2e LSPs . . . . . . . . . . . . . . . . . 12 80 5.2. Summary of LSP Stitching Procedures . . . . . . . . . . . 13 81 5.2.1. Example Topology . . . . . . . . . . . . . . . . . . . 13 82 5.2.2. LSP Segment Setup . . . . . . . . . . . . . . . . . . 13 83 5.2.3. Setup of an e2e LSP . . . . . . . . . . . . . . . . . 14 84 5.2.4. Stitching of an e2e LSP into an LSP Segment . . . . . 14 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 7.1. Attribute Flags for LSP_ATTRIBUTES Object . . . . . . . . 15 88 7.2. New Error Code . . . . . . . . . . . . . . . . . . . . . . 16 89 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 92 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 93 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 94 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 95 12. Intellectual Property . . . . . . . . . . . . . . . . . . . 19 97 1. Introduction 99 A stitched Generalized Multiprotocol Label Switching (GMPLS) Traffic 100 Engineering (TE) Label Switched Path (LSP) is built from a set of 101 different LSP segments (S-LSPs) that are connected together in the 102 data plane in such a way that a single end-to-end LSP is realized in 103 the data plane. In this document, we define the concept of LSP 104 stitching and detail the control plane mechanisms and procedures 105 (routing and signaling) to accomplish this. Where applicable, 106 similarities and differences between LSP hierarchy [RFC4206] and LSP 107 stitching are highlighted. Signaling extensions required for LSP 108 stitching are also described here. 110 It may be possible to configure a GMPLS node to switch the traffic 111 from an LSP for which it is the egress, to another LSP for which it 112 is the ingress, without requiring any signaling or routing extensions 113 whatsoever, and such that the operation is completely transparent to 114 other nodes. This results in LSP stitching in the data plane, but 115 requires management intervention at the node where the stitching is 116 performed. With the mechanism described in this document, the node 117 performing the stitching does not require configuration of the pair 118 of S-LSPs to be stitched together. Also, LSP stitching as defined 119 here results in an end-to-end LSP both in the control and data 120 planes. 122 1.1. Conventions Used in this Document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 2. Comparison with LSP Hierarchy 130 LSP hierarchy ([RFC4206]) provides signaling and routing procedures 131 so that: 133 a. A Hierarchical LSP (H-LSP) can be created. Such an LSP created 134 in one layer can appear as a data link to LSPs in higher layers. 135 As such, one or more LSPs in a higher layer can traverse this 136 H-LSP as a single hop; we call this "nesting". 138 b. An H-LSP may be managed and advertised (although this is not a 139 requirement) as a Traffic Engineering (TE) link. Advertising an 140 H-LSP as a TE link allows other nodes in the TE domain in which 141 it is advertised to use this H-LSP in path computation. If the 142 H-LSP TE link is advertised in the same instance of control plane 143 (TE domain) in which the H-LSP was provisioned, it is then 144 defined as a forwarding adjacency LSP (FA-LSP) and GMPLS nodes 145 can form a forwarding adjacency (FA) over this FA-LSP. There is 146 usually no routing adjacency between end points of an FA. An 147 H-LSP may also be advertised as a TE link in a different TE 148 domain. In this case, the end points of the H-LSP are required 149 have a routing adjacency between them. 151 c. RSVP signaling ([RFC3473], [RFC3209]) for LSP setup can occur 152 between nodes that do not have a routing adjacency. 154 In case of LSP stitching, instead of an H-LSP, an "LSP segment" 155 (S-LSP) is created between two GMPLS nodes. An S-LSP for stitching 156 is considered to be the moral equivalent of an H-LSP for nesting. An 157 S-LSP created in one layer, unlike an H-LSP, provides a data link to 158 other LSPs in the same layer. Similar to an H-LSP, an S-LSP could be 159 managed and advertised, although it is not required, as a TE link, 160 either in the same TE domain as it was provisioned or a different 161 one. If so advertised, other Generalized Multiprotocol Label 162 Switching (GMPLS) nodes can use the corresponding S-LSP TE link in 163 path computation. While there is a forwarding adjacency between end 164 points of an H-LSP TE link, there is no forwarding adjacency between 165 end points of an S-LSP TE link. In this aspect, an H-LSP TE link 166 more closely resembles a 'basic' TE link as compared to an S-LSP TE 167 link. 169 While LSP hierarchy allows more than one LSP to be mapped to an 170 H-LSP, in case of LSP stitching, at most one LSP may be associated 171 with an S-LSP. Thus, if LSP-AB is an H-LSP between nodes A and B, 172 then multiple LSPs, say LSP1, LSP2, and LSP3 can potentially be 173 'nested into' LSP-AB. This is achieved by exchanging a unique label 174 for each of LSP1..3 over the LSP-AB hop, thereby separating the data 175 corresponding to each of LSP1..3 while traversing the H-LSP LSP-AB. 176 Each of LSP1..3 may reserve some bandwidth on LSP-AB. On the other 177 hand, if LSP-AB is an S-LSP, then at most one LSP, say LSP1, may be 178 stitched to the S-LSP LSP-AB. LSP-AB is then dedicated to LSP1 and 179 no other LSPs can be associated with LSP-AB. The entire bandwith on 180 S-LSP LSP-AB is allocated to LSP1. However, similar to H-LSPs, 181 several S-LSPs may be bundled into a TE link ([RFC4201]). 183 The LSPs LSP1..3 which are either nested or stitched into another LSP 184 are termed as e2e LSPs in the rest of this document. Routing 185 procedures specific to LSP stitching are detailed in Section 4. 187 Targetted (non-adjacent) RSVP signaling defined in [RFC4206] is 188 required for LSP stitching of an e2e LSP to an S-LSP. Specific 189 extensions for LSP stitching are described later in Section 5.1. 190 Therefore, in the control plane, there is one RSVP session 191 corresponding to the e2e LSP as well as one for each S-LSP. The 192 creation and termination of an S-LSP may be dictated by 193 administrative control (statically provisioned) or due to another 194 incoming LSP request (dynamic). Triggers for dynamic creation of an 195 S-LSP may be different from that of an H-LSP and will be described in 196 detail later. 198 3. Usage 200 3.1. Triggers for LSP Segment Setup 202 An S-LSP may be created either by administrative control 203 (configuration trigger) or dynamically due to an incoming LSP 204 request. LSP Hierarchy ([RFC4206]) defines one possible trigger for 205 dynamic creation of FA-LSP by introducing the notion of LSP regions 206 based on Interface Switching Capabilities. As per [RFC4206], dynamic 207 FA-LSP creation may be triggered on a node when an incoming LSP 208 request crosses region boundaries. However, this trigger MUST NOT be 209 used for creation of S-LSP for LSP stitching as described in this 210 document. In case of LSP stitching, the switching capabilities of 211 the previous hop and the next hop TE links MUST be the same. 212 Therefore, local policies configured on the node SHOULD be used for 213 dynamic creation of LSP segments. 215 Other possible triggers for dynamic creation of both H-LSPs and 216 S-LSPs include cases where an e2e LSP may cross domain boundaries or 217 satisfy locally configured policies on the node as described in 218 [RSVP-INTER]. 220 3.2. Applications 222 LSP stitching procedures described in this document are applicable to 223 GMPLS nodes that need to associate an e2e LSP with another S-LSP of 224 the same switching type and LSP hierarchy procedures do not apply. 225 E.g., if an e2e lambda LSP traverses an LSP segment TE link which is 226 also lambda switch capable, then LSP hierarchy is not possible; in 227 this case, LSP switching may be an option. 229 LSP stitching procedures can be used for inter-domain TE LSP 230 signaling to stitch an inter-domain e2e LSP to a local intra-domain 231 TE S-LSP ([RFC4726] and [RSVP-INTER]). 233 LSP stitching may also be useful in networks to bypass legacy nodes 234 which may not have certain new capabilities in the control plane 235 and/or data plane. E.g., one suggested usage in the case of 236 point-to-multipoint (P2MP) RSVP LSPs ([RSVP-P2MP]) is the use of LSP 237 stitching to stitch a P2MP RSVP LSP to an LSP segment between P2MP 238 capable Label Switching Routers (LSRs) in the network. The LSP 239 segment would traverse legacy LSRs that may be incapable of acting as 240 P2MP branch points, thereby shielding them from the P2MP control and 241 data path. Note, however, that such configuration may limit the 242 attractiveness of RSVP P2MP and should carefully be examined before 243 deployment. 245 4. Routing Aspects 247 An S-LSP is created between two GMPLS nodes and it may traverse zero 248 or more intermediate GMPLS nodes. There is no forwarding adjacency 249 between the end points of an S-LSP TE link. So, although in the TE 250 topology, the end points of an S-LSP TE link are adjacent, in the 251 data plane, these nodes do not have an adjacency. Hence any data 252 plane resource identifier between these nodes is also meaningless. 253 The traffic that arrives at the head end of the S-LSP is switched 254 into the S-LSP contiguously with a label swap and no label is 255 associated directly between the end nodes of the S-LSP itself. 257 An S-LSP MAY be treated and managed as a TE link. This TE link MAY 258 be numbered or unnumbered. For an unnumbered S-LSP TE link, the 259 schemes for assignment and handling of the local and remote link 260 identifiers as specified in [RFC3477] SHOULD be used. When 261 appropriate, the TE information associated with an S-LSP TE link MAY 262 be flooded via ISIS-TE [RFC4205] or OSPF-TE [RFC4203]. Mechanisms 263 similar to that for regular (basic) TE links SHOULD be used to flood 264 S-LSP TE links. Advertising or flooding the S-LSP TE link is not a 265 requirement for LSP stitching. If advertised, this TE information 266 will exist in the TE database (TED) and can then be used for path 267 computation by other GMPLS nodes in the TE domain in which it is 268 advertised. When so advertising S-LSPs, one should keep in mind that 269 these add to the size and complexity of the link-state database. 271 If an S-LSP is advertised as a TE link in the same TE domain in which 272 it was provisioned, there is no need for a routing adjacency between 273 end points of this S-LSP TE link. If an S-LSP TE link is advertised 274 in a different TE domain, the end points of that TE link SHOULD have 275 a routing adjacency between them. 277 The TE parameters defined for an FA in [RFC4206] SHOULD be used for 278 an S-LSP TE link as well. The switching capability of an S-LSP TE 279 link MUST be equal to the switching type of the underlying S-LSP; 280 i.e. an S-LSP TE link provides a data link to other LSPs in the same 281 layer, so no hierarchy is possible. 283 An S-LSP MUST NOT admit more than one e2e LSP into it. If an S-LSP 284 is allocated to an e2e LSP, the unreserved bandwidth SHOULD be set to 285 zero to prevent further e2e LSPs being admitted into the S-LSP. 287 Multiple S-LSPs between the same pair of nodes MAY be bundled using 288 the concept of Link Bundling ([RFC4201]) into a single TE link. In 289 this case, each component S-LSP may be allocated to at most one e2e 290 LSP. When any component S-LSP is allocated for an e2e LSP, the 291 component's unreserved bandwidth SHOULD be set to zero and the 292 Minimum and Maximum LSP bandwidth of the TE link SHOULD be 293 recalculated. This will prevent more than one LSP from being 294 computed and admitted over an S-LSP. 296 5. Signaling Aspects 298 The end nodes of an S-LSP may or may not have a routing adjacency. 299 However, they SHOULD have a signaling adjacency (RSVP neighbor 300 relationship) and will exchange RSVP messages with each other. It 301 may, in fact, be desirable to exchange RSVP Hellos directly between 302 the LSP segment end points to allow support for state recovery during 303 Graceful Restart procedures as described in [RFC3473]. 305 In order to signal an e2e LSP over an LSP segment, signaling 306 procedures described in section 8.1.1 of [RFC4206] MUST be used. 307 Additional signaling extensions for stitching are described in the 308 next section. 310 5.1. RSVP-TE Signaling Extensions 312 The signaling extensions described here MUST be used for stitching an 313 e2e packet or non-packet GMPLS LSP ([RFC3473]), to an S-LSP. 315 Stitching an e2e LSP to an LSP segment involves the following two 316 step process: 318 1. Creating and preparing the S-LSP for stitching by signaling the 319 desire to stitch between end points of the S-LSP; and 321 2. stitching the e2e LSP to the S-LSP. 323 5.1.1. Creating and Preparing an LSP Segment for Stitching 325 If a GMPLS node desires to create an S-LSP, i.e., one to be used for 326 stitching, then it MUST indicate this in the Path message for the 327 S-LSP. This signaling explicitly informs the S-LSP egress node that 328 the ingress node is planning to perform stitching over the S-LSP. 329 Since an S-LSP is not conceptually different from any other LSP, 330 explicitly signaling 'LSP stitching desired' helps clarify the data 331 plane actions to be carried out when the S-LSP is used by some other 332 e2e LSP. Also, in case of packet LSPs, this is what allows the 333 egress of the S-LSP to carry out label allocation as explained below. 334 Also, so that the head-end node can ensure that correct stitching 335 actions will be carried out at the egress node, the egress node MUST 336 signal this information back to the head-end node in the Resv, as 337 explained below. 339 In order to request LSP stitching on the S-LSP, we define a new bit 340 in the Attributes Flags TLV of the LSP_ATTRIBUTES object defined in 341 [RFC4420]: 343 LSP stitching desired bit - This bit SHOULD be set in the Attributes 344 Flags TLV of the LSP_ATTRIBUTES object in the Path message for the 345 S-LSP by the head-end of the S-LSP, that desires LSP stitching. This 346 bit MUST NOT be modified by any other nodes in the network. Nodes 347 other than the egress of the S-LSP SHOULD ignore this bit. The bit 348 number for this flag is defined in Section 7.1. 350 An LSP segment can be used for stitching only if the egress node of 351 the S-LSP is also ready to participate in stitching. In order to 352 indicate this to the head-end node of the S-LSP, the following new 353 bit is defined in the Flags field of the Record Route object (RRO) 354 Attributes subobject: "LSP segment stitching ready". The bit number 355 for this flag is defined in Section 7.1. 357 If an egress node of the S-LSP receiving the Path message, supports 358 the LSP_ATTRIBUTES object and the Attributes Flags TLV, and also 359 recognizes the "LSP stitching desired" bit, but cannot support the 360 requested stitching behavior, then it MUST send back a PathErr 361 message with an error code of "Routing Problem" and an error value 362 of "Stitching unsupported" to the head-end node of the S-LSP. The 363 new error value is defined in Section 7.2. 365 If an egress node receiving a Path message with the "LSP stitching 366 desired" bit set in the Flags field of received LSP_ATTRIBUTES, 367 recognizes the object, the TLV and the bit and also supports the 368 desired stitching behavior, then it MUST allocate a non-NULL label 369 for that S-LSP in the corresponding Resv message. Also, so that the 370 head-end node can ensure that the correct label (forwarding) actions 371 will be carried out by the egress node and that the S-LSP can be used 372 for stitching, the egress node MUST set the "LSP segment stitching 373 ready" bit defined in the Flags field of the RRO Attribute sub- 374 object. 376 Finally, if the egress node for the S-LSP supports the LSP_ATTRIBUTES 377 object but does not recognize the Attributes Flags TLV, or supports 378 the TLV as well but does not recognize this particular bit, then it 379 SHOULD simply ignore the above request. 381 An ingress node requesting LSP stitching MUST examine the RRO 382 Attributes sub-object Flags corresponding to the egress node for the 383 S-LSP, to make sure that stitching actions are carried out at the 384 egress node. It MUST NOT use the S-LSP for stitching if the "LSP 385 segment stitching ready" bit is cleared. 387 5.1.1.1. Steps to Support Penultimate Hop Popping 389 Note that this section is only applicable to packet LSPs that use 390 Penultimate Hop Popping (PHP) at the last hop, where the egress node 391 distributes the Implicit NULL Label ([RFC3032]) in the Resv Label. 392 These steps MUST NOT be used for a non-packet LSP and for packet LSPs 393 where PHP is not desired. 395 When the egress node of an S-LSP receives a Path message for an e2e 396 LSP using this S-LSP and this is a packet LSP, it SHOULD first check 397 if it is also the egress for the e2e LSP. If the egress node is the 398 egress for both the S-LSP as well as the e2e TE LSP, and this is a 399 packet LSP which requires PHP, then the node MUST send back a Resv 400 trigger message for the S-LSP with a new label corresponding to the 401 Implicit or Explicit NULL label. Note that this operation does not 402 cause any traffic disruption since the S-LSP is not carrying any 403 traffic at this time, since the e2e LSP has not yet been established. 405 If the e2e LSP and the S-LSP are bidirectional, the ingress of the 406 e2e LSP SHOULD first check whether it is also the ingress of the 407 S-LSP. If so, it SHOULD re-issue the Path message for the S-LSP with 408 an implicit or explicit NULL upstream label; and only then proceed 409 with the signaling of the e2e LSP. 411 5.1.2. Stitching the e2e LSP to the LSP segment 413 When a GMPLS node receives an e2e LSP request, depending on the 414 applicable trigger, it may either dynamically create an S-LSP based 415 on procedures described above or it may map an e2e LSP to an existing 416 S-LSP. The switching type in the Generalized Label Request of the 417 e2e LSP MUST be equal to the switching type of the S-LSP. Other 418 constraints like the explicit path encoded in the Explicit Route 419 object (ERO), bandwidth, local TE policies MUST also be used for 420 S-LSP selection or signaling. In either case, once an S-LSP has been 421 selected for an e2e LSP, the following procedures MUST be followed in 422 order to stitch an e2e LSP to an S-LSP. 424 The GMPLS node receiving the e2e LSP setup Path message MUST use the 425 signaling procedures described in [RFC4206] to send the Path message 426 to the end point of the S-LSP. In this Path message, the node MUST 427 identify the S-LSP in the RSVP_HOP. An egress node receiving this 428 RSVP_HOP should also be able to identify the S-LSP TE link based on 429 the information signaled in the RSVP_HOP. If the S-LSP TE link is 430 numbered, then the addressing scheme as proposed in [RFC4206] SHOULD 431 be used to number the S-LSP TE link. If the S-LSP TE link is 432 unnumbered, then any of the schemes proposed in [RFC3477] SHOULD be 433 used to exchange S-LSP TE link identifiers between the S-LSP end 434 points. If the TE link is bundled, the RSVP_HOP SHOULD identify the 435 component link as defined in [RFC4201]. 437 In case of a bidirectional e2e TE LSP, an Upstream Label MUST be 438 signaled in the Path message for the e2e LSP over the S-LSP hop. 439 However, since there is no forwarding adjacency between the S-LSP end 440 points, any label exchanged between them has no significance. So the 441 node MAY chose any label value for the Upstream Label. The label 442 value chosen and signaled by the node in the Upstream Label is out of 443 the scope of this document and is specific to the implementation on 444 that node. The egress node receiving this Path message MUST ignore 445 the Upstream Label in the Path message over the S-LSP hop. 447 The egress node receiving this Path message MUST signal a Label in 448 the Resv message for the e2e TE LSP over the S-LSP hop. Again, since 449 there is no forwarding adjacency between the egress and ingress S-LSP 450 nodes, any label exchanged between them is meaningless. So, the 451 egress node MAY choose any label value for the Label. The label 452 value chosen and signaled by the egress node is out of the scope of 453 this document and is specific to the implementation on the egress 454 node. The egress S-LSP node SHOULD also carry out data plane 455 operations so that traffic coming in on the S-LSP is switched over to 456 the e2e LSP downstream, if the egress of the e2e LSP is some other 457 node downstream. If the e2e LSP is bidirectional, this means setting 458 up label switching in both directions. The Resv message from the 459 egress S-LSP node is IP routed back to the previous hop (ingress of 460 the S-LSP). The ingress node stitching an e2e TE LSP to an S-LSP 461 MUST ignore the Label object received in the Resv for the e2e TE LSP 462 over the S-LSP hop. The S-LSP ingress node SHOULD also carry out 463 data plane operations so that traffic coming in on the e2e LSP is 464 switched into the S-LSP. It should also carry out actions to handle 465 traffic in the opposite direction if the e2e LSP is bidirectional. 467 Note that the label exchange procedure for LSP stitching on the S-LSP 468 hop, is similar to that for LSP hierarchy over the H-LSP hop. The 469 difference is the lack of the significance of this label between the 470 S-LSP end points in case of stitching. Therefore, in case of 471 stitching the recepients of the Label/Upstream Label MUST NOT process 472 these labels. Also, at most one e2e LSP is associated with one 473 S-LSP. If a node at the head-end of an S-LSP receives a Path Msg for 474 an e2e LSP that identifies the S-LSP in the ERO and the S-LSP 475 bandwidth has already been allocated to some other LSP, then regular 476 rules of RSVP-TE pre-emption apply to resolve contention for S-LSP 477 bandwidth. If the LSP request over the S-LSP cannot be satisfied, 478 then the node SHOULD send back a PathErr with the error codes as 479 described in [RFC3209]. 481 5.1.3. RRO Processing for e2e LSPs 483 RRO procedures for the S-LSP specific to LSP stitching are already 484 described in Section 5.1.1. In this section we will look at the RRO 485 processing for the e2e LSP over the S-LSP hop. 487 An e2e LSP traversing an S-LSP, SHOULD record in the RRO for that 488 hop, an identifier corresponding to the S-LSP TE link. This is 489 applicable to both Path and Resv messages over the S-LSP hop. If the 490 S-LSP is numbered, then the IPv4 or IPv6 address subobject 491 ([RFC3209]) SHOULD be used to record the S-LSP TE link address. If 492 the S-LSP is unnumbered, then the Unnumbered Interface ID subobject 493 as described in [RFC3477] SHOULD be used to record the node's Router 494 ID and Interface ID of the S-LSP TE link. In either case, the RRO 495 subobject SHOULD identify the S-LSP TE link end point. Intermediate 496 links or nodes traversed by the S-LSP itself SHOULD NOT be recorded 497 in the RRO for the e2e LSP over the S-LSP hop. 499 5.1.4. Teardown of LSP Segments 501 S-LSP teardown follows the standard procedures defined in [RFC3209] 502 and [RFC3473]. This includes procedures without and with setting the 503 administrative status. Teardown of S-LSP may be initiated by either 504 the ingress, egress or any other node along the S-LSP path. 505 Deletion/teardown of the S-LSP SHOULD be treated as a failure event 506 for the e2e LSP associated with it and corresponding teardown or 507 recovery procedures SHOULD be triggered for the e2e LSP. In case of 508 S-LSP teardown for maintenance purpose, the S-LSP ingress node MAY 509 treat this to be equivalent to administratively shutting down a TE 510 link along the e2e LSP path and take corresponding actions to notify 511 the ingress of this event. The actual signaling procedures to handle 512 this event is out of the scope of this document. 514 5.1.5. Teardown of e2e LSPs 516 e2e LSP teardown also follows standard procedures defined in 517 [RFC3209] and [RFC3473] either without or with the administrative 518 status. Note, however, that teardown procedures of e2e LSP and of 519 S-LSP are independent of each other. So, it is possible that while 520 one LSP follows graceful teardown with adminstrative status, the 521 other LSP is torn down without administrative status (using 522 PathTear/ResvTear/PathErr with state removal). 524 When an e2e LSP teardown is initiated from the head-end, and a 525 PathTear arrives at the GMPLS stitching node, the PathTear message 526 like the Path message MUST be IP routed to the LSP segment egress 527 node with the destination IP address of the Path message set to the 528 address of the S-LSP end node. Router Alert MUST be off and RSVP TTL 529 check MUST be disabled on the receiving node. PathTear will result 530 in deletion of RSVP states corresponding to the e2e LSP and freeing 531 of label allocations and bandwidth reservations on the S-LSP. The 532 unreserved bandwidth on the S-LSP TE link SHOULD be re-adjusted. 534 Similarly, a teardown of the e2e LSP may be initiated from the tail- 535 end either using a ResvTear or a PathErr with state removal. The 536 egress of the S-LSP MUST propagate the ResvTear/PathErr upstream, IP 537 routed to the ingress of the LSP segment. 539 Graceful LSP teardown using ADMIN_STATUS as described in [RFC3473] is 540 also applicable to stitched LSPs. 542 If the S-LSP was statically provisioned, tearing down of an e2e LSP 543 MAY not result in tearing down of the S-LSP. If, however, the S-LSP 544 was dynamically setup due to the e2e LSP setup request, then 545 depending on local policy, the S-LSP MAY be torn down if no e2e LSP 546 is utilizing the S-LSP. Although the S-LSP may be torn down while 547 the e2e LSP is being torn down, it is RECOMMENDED that a delay be 548 introduced in tearing down the S-LSP once the e2e LSP teardown is 549 complete, in order to reduce the simultaneous generation of RSVP 550 errors and teardown messages due to multiple events. The delay 551 interval may be set based on local implementation. The RECOMMENDED 552 interval is 30 seconds. 554 5.2. Summary of LSP Stitching Procedures 556 5.2.1. Example Topology 558 The following topology will be used for the purpose of examples 559 quoted in the following sections. 561 e2e LSP 562 +++++++++++++++++++++++++++++++++++> (LSP1-2) 564 LSP segment (S-LSP) 565 ====================> (LSP-AB) 566 C --- E --- G 567 /|\ | / |\ 568 / | \ | / | \ 569 R1 ---- A \ | \ | / | / B --- R2 570 \| \ |/ |/ 571 D --- F --- H 573 PATH 574 ====================> (LSP stitching desired) 575 RESV 576 <==================== (LSP segment stitching ready) 578 PATH (Upstream Label) 579 +++++++++++++++++++++ 580 +++++++ ++++++> 581 <++++++ +++++++ 582 +++++++++++++++++++++ 583 RESV (Label) 585 5.2.2. LSP Segment Setup 587 Let us consider an S-LSP LSP-AB being setup between two nodes A and B 588 which are more than one hop away. Node A sends a Path message for 589 the LSP-AB with "LSP stitching desired" set in Flags field of 590 LSP_ATTRIBUTES object. If the egress node B is ready to carry out 591 stitching procedures, then B will respond with "LSP segment stitching 592 ready" set in the Flags field of the RRO Attributes subobject, in the 593 RRO sent in the Resv for the S-LSP. Once A receives the Resv for 594 LSP-AB and sees this bit set in the RRO, it can then use LSP-AB for 595 stitching. A cannot use LSP-AB for stitching if the bit is cleared 596 in the RRO. 598 5.2.3. Setup of an e2e LSP 600 Let us consider an e2e LSP LSP1-2 starting one hop before A on R1 and 601 ending on node R2, as shown above. If the S-LSP has been advertised 602 as a TE link in the TE domain, and R1 and A are in the same domain, 603 then R1 may compute a path for LSP1-2 over the S-LSP LSP-AB and 604 identify the LSP-AB hop in the ERO. If not, R1 may compute hops 605 between A and B and A may use these ERO hops for S-LSP selection or 606 signaling a new S-LSP. If R1 and A are in different domains, then 607 LSP1-2 is an inter-domain LSP. In this case, S-LSP LSP-AB, similar 608 to any other basic TE link in the domain will not be advertised 609 outside the domain. R1 would use either per-domain path computation 610 ([PD-PATH]) or PCE based computation ([RFC4655]) for LSP1-2. 612 5.2.4. Stitching of an e2e LSP into an LSP Segment 614 When the Path message for the e2e LSP LSP1-2 arrives at node A, A 615 matches the switching type of LSP1-2 with the S-LSP LSP-AB. If the 616 switching types are not equal, then LSP-AB cannot be used to stitch 617 LSP1-2. Once the S-LSP LSP-AB to which LSP1-2 will be stitched has 618 been determined, the Path message for LSP1-2 is sent (via IP routing, 619 if needed) to node B with the IF_ID RSVP_HOP identifying the S-LSP 620 LSP-AB. When B receives this Path message for LSP1-2, if B is also 621 the egress for LSP1-2, and if this is a packet LSP requiring PHP, 622 then B will send a Resv refresh for LSP-AB with the NULL Label. In 623 this case, since B is not the egress, the Path message for LSP1-2 is 624 propagated to R2. The Resv for LSP1-2 from B is sent back to A with 625 a Label value chosen by B. B also sets up its data plane to swap the 626 Label sent to either G or H on the S-LSP with the Label received from 627 R2. Node A ignores the Label on receipt of the Resv message and then 628 propagates the Resv to R1. A also sets up its data plane to swap the 629 Label sent to R1 with the Label received on the S-LSP from C or D. 630 This stitches the e2e LSP LSP1-2 to an S-LSP LSP-AB between nodes A 631 and B. In the data plane, this yields a series of label swaps from R1 632 to R2 along e2e LSP LSP1-2. 634 6. Security Considerations 636 From a security point of view, the changes introduced in this 637 document model the changes introduced by [RFC4206]. That is, the 638 control interface over which RSVP messages are sent or received need 639 not be the same as the data interface which the message identifies 640 for switching traffic. But the capability for this function was 641 introduced in [RFC3473] to support the concept of out-of-fiber 642 control channels, so there is nothing new in this concept for 643 signaling or security. 645 The application of this facility means that the "sending interface" 646 or "receiving interface" may change as routing changes. So, these 647 interfaces cannot be used to establish security association between 648 neighbors, and security associations MUST be bound to the 649 communicating neighbors themselves. 651 [RFC2747] provides a solution to this issue: in Section 2.1, under 652 "Key Identifier", an IP address is a valid identifier for the sending 653 (and by analogy, receiving) interface. Since RSVP messages for a 654 given LSP are sent to an IP address that identifies the next/previous 655 hop for the LSP, one can replace all occurrences of 'sending 656 [receiving] interface' with 'receiver's [sender's] IP address' 657 (respectively). For example, in Section 4, third paragraph, instead 658 of: 660 "Each sender SHOULD have distinct security associations (and keys) 661 per secured sending interface (or LIH). ... At the sender, 662 security association selection is based on the interface through 663 which the message is sent." 665 it should read: 667 "Each sender SHOULD have distinct security associations (and keys) 668 per secured receiver's IP address. ... At the sender, security 669 association selection is based on the IP address to which the 670 message is sent." 672 Thus the mechanisms of [RFC2747] can be used unchanged to establish 673 security associations between control plane neighbors. 675 This document allows the IP destination address of Path and PathTear 676 messages to be the IP address of a nexthop node (receiver's address) 677 instead of the RSVP session destination address. This means that the 678 use of the IPsec Authentication Header (AH) (ruled out in [RFC2747] 679 because RSVP messages were encapsulated in IP packets addressed to 680 the ultimate destination of the Path or PathTear messages) is now 681 perfectly applicable, and standard IPsec procedures can be used to 682 secure the message exchanges. 684 An analysis of GMPLS security issues can be found in [MPLS-SEC]. 686 7. IANA Considerations 688 IANA is requested to make the following codepoint allocations for 689 this document. 691 7.1. Attribute Flags for LSP_ATTRIBUTES Object 693 The "RSVP TE Parameters" registry includes the "Attributes Flags" 694 sub-registry. 696 IANA is requested to make an allocation for the following new bit 697 defined for the Attributes Flags TLV in the LSP_ATTRIBUTES object. 698 The numeric value should be assigned by IANA. The value 5 is 699 suggested. 701 LSP stitching desired bit - Bit Number 5 (Suggested value) 703 This bit is only to be used in the Attributes Flags TLV on a Path 704 message. 706 The 'LSP stitching desired bit' has a corresponding 'LSP segment 707 stitching ready' bit (Bit Number 5) to be used in the RRO Attributes 708 sub-object. 710 The following text is suggested for inclusion in the registry: 712 Path Resv RRO 713 Bit Name message message sub-object Reference 714 --- --------------------- ------- ------- ---------- ---------- 715 5 LSP stitching desired Yes No Yes [This doc] 717 7.2. New Error Codes 719 The "Resource ReSerVation Protocol (RSVP) Parameters" registry 720 includes the "Error Codes and Globally-Defined Error Value Sub-Codes" 721 sub-registry. 723 IANA is requested to assign a new error sub-code under the RSVP 724 error-code "Routing Problem" (24). The numeric error sub-code value 725 should be assigned by IANA. A value of 23 is suggested. 727 This error code is to be used only in an RSVP PathErr. 729 The following text is suggested for inclusion in the registry: 731 24 Routing Problem [RFC3209] 733 23 = Stitching unsupported [This doc] 735 8. Acknowledgments 737 The authors would like to thank Dimitri Papadimitriou and Igor 738 Bryskin for their thorough review of the document and discussions 739 regarding the same. 741 9. References 743 9.1. Normative References 745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, March 1997. 748 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 749 Authentication", RFC 2747, January 2000. 751 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 752 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 753 Tunnels", RFC 3209, December 2001. 755 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 756 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 757 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 759 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 760 Hierarchy with Generalized Multi-Protocol Label Switching 761 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 763 [RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J., and 764 A. Ayyangar, "Encoding of Attributes for Multiprotocol 765 Label Switching (MPLS) Label Switched Path (LSP) 766 Establishment Using Resource ReserVation Protocol-Traffic 767 Engineering (RSVP-TE)", RFC 4420, February 2006. 769 9.2. Informative References 771 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 772 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 773 Encoding", RFC 3032, January 2001. 775 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered 776 Links in Resource ReSerVation Protocol - Traffic 777 Engineering (RSVP-TE)", RFC 3477, January 2003. 779 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 780 in MPLS Traffic Engineering (TE)", RFC 4201, October 781 2005. 783 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 784 of Generalized Multi-Protocol Label Switching (GMPLS)", 785 RFC 4203, October 2005. 787 [RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to 788 Intermediate System (IS-IS) Extensions in Support of 789 Generalized Multi-Protocol Label Switching (GMPLS)", 790 RFC 4205, October 2005. 792 [RFC4655] Farrel, A., "A Path Computation Element (PCE)-Based 793 Architecture", RFC 4655, August 2006. 795 [RFC4726] Farrel, A., Vasseur, J.P., and Ayyangar, Arthi, "A 796 Framework for Inter-Domain Multiprotocol Label Switching 797 Traffic Engineering", RFC 4726, November 2006. 799 [RSVP-P2MP] Aggarwal, R., "Extensions to RSVP-TE for Point-to- 800 Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp, work 801 in progress. 803 [RSVP-INTER] Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic 804 Engineering - RSVP-TE extensions", draft-ietf-ccamp- 805 inter-domain-rsvp-te, work in progress. 807 [PD-PATH] Vasseur, J., "A Per-domain path computation method for 808 establishing Inter-domain Traffic Engineering (TE) 809 Label Switched Paths (LSPs)", draft-ietf-ccamp-inter- 810 domain-pd-path-comp, work in progress. 812 [MPLS-SEC] Fang, L., et al., "Security Framework for MPLS and GMPLS 813 Networks", draft-fang-mpls-gmpls-security-framework, 814 work in progress. 816 10. Authors' Addresses 818 Arthi Ayyangar 819 Nuova Systems 820 2600 San Tomas Expressway 821 Santa Clara, CA 95051 822 Email: arthi@nuovasystems.com 824 Kireeti Kompella 825 Juniper Networks 826 1194 N. Mathilda Ave. 827 Sunnyvale, CA 94089 828 Email: kireeti@juniper.net 830 Jean Philippe Vasseur 831 Cisco Systems, Inc. 832 300 Beaver Brook Road 833 Boxborough, MA 01719 834 Email: jpv@cisco.com 836 Adrian Farrel 837 Old Dog Consulting 838 Email: adrian@olddog.co.uk 840 11. Full Copyright Statement 842 Copyright (C) The IETF Trust (2007). 844 This document is subject to the rights, licenses and restrictions 845 contained in BCP 78, and except as set forth therein, the authors 846 retain all their rights. 848 This document and the information contained herein are provided on an 849 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 850 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 851 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 852 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 853 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 854 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 856 12. Intellectual Property 858 The IETF takes no position regarding the validity or scope of any 859 Intellectual Property Rights or other rights that might be claimed to 860 pertain to the implementation or use of the technology described in 861 this document or the extent to which any license under such rights 862 might or might not be available; nor does it represent that it has 863 made any independent effort to identify any such rights. Information 864 on the procedures with respect to rights in RFC documents can be 865 found in BCP 78 and BCP 79. 867 Copies of IPR disclosures made to the IETF Secretariat and any 868 assurances of licenses to be made available, or the result of an 869 attempt made to obtain a general license or permission for the use of 870 such proprietary rights by implementers or users of this 871 specification can be obtained from the IETF on-line IPR repository at 872 http://www.ietf.org/ipr. 874 The IETF invites any interested party to bring to its attention any 875 copyrights, patents or patent applications, or other proprietary 876 rights that may cover technology that may be required to implement 877 this standard. Please address the information to the IETF at 878 ietf-ipr@ietf.org. 880 Acknowledgment 882 Funding for the RFC Editor function is provided by the IETF 883 Administrative Support Activity (IASA).