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