idnits 2.17.1 draft-ietf-ccamp-lsp-stitching-04.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 778. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 796. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 802. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 101 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (December 2, 2006) is 6354 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 (ref. '3') (Obsoleted by RFC 5420) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-te-p2mp-06 == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-inter-domain-rsvp-te-03 -- Obsolete informational reference (is this intentional?): RFC 4205 (ref. '13') (Obsoleted by RFC 5307) == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-inter-domain-pd-path-comp-03 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Ayyangar, Ed. 3 Internet-Draft Nuova Systems 4 Intended status: Standards Track K. Kompella, Ed. 5 Expires: June 5, 2007 Juniper Networks 6 JP. Vasseur 7 Cisco Systems, Inc. 8 December 2, 2006 10 Label Switched Path Stitching with Generalized MPLS Traffic Engineering 11 draft-ietf-ccamp-lsp-stitching-04.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on June 5, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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 It may be possible to configure a GMPLS node to switch the traffic 53 from an LSP for which it is the egress, to another LSP for which it 54 is the ingress, without requiring any signaling or routing extensions 55 whatsoever, completely transparent to other nodes. This will also 56 result in LSP stitching in the data plane. However, this document 57 does not cover this scenario of LSP stitching. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Conventions used in this document . . . . . . . . . . . . 4 63 2. Comparison with LSP Hierarchy . . . . . . . . . . . . . . . . 5 64 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. Triggers for LSP segment setup . . . . . . . . . . . . . . 6 66 3.2. Applications . . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Routing aspects . . . . . . . . . . . . . . . . . . . . . . . 7 68 5. Signaling aspects . . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. RSVP-TE signaling extensions . . . . . . . . . . . . . . . 9 70 5.1.1. Creating and preparing LSP segment for stitching . . . 9 71 5.1.2. Stitching the e2e LSP to the LSP segment . . . . . . . 11 72 5.1.3. RRO Processing for e2e LSP . . . . . . . . . . . . . . 12 73 5.1.4. Teardown of LSP segment . . . . . . . . . . . . . . . 13 74 5.1.5. Teardown of e2e LSP . . . . . . . . . . . . . . . . . 13 75 5.2. Summary of LSP Stitching procedures . . . . . . . . . . . 14 76 5.2.1. Example topology . . . . . . . . . . . . . . . . . . . 14 77 5.2.2. LSP segment setup . . . . . . . . . . . . . . . . . . 15 78 5.2.3. Setup of e2e LSP . . . . . . . . . . . . . . . . . . . 15 79 5.2.4. Stitching of e2e LSP into an LSP segment . . . . . . . 15 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 82 7.1. Attribute Flags for LSP_ATTRIBUTES object . . . . . . . . 17 83 7.2. New Error Codes . . . . . . . . . . . . . . . . . . . . . 17 84 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 89 Intellectual Property and Copyright Statements . . . . . . . . . . 22 91 1. Introduction 93 This document describes the mechanisms to accomplish LSP stitching in 94 the control (routing and signaling) and data planes, contrasting 95 stitching with LSP hierarchy ([2]) as is meaningful. With the 96 mechanism described here, the node performing the stitching does not 97 require configuration of the pair of LSPs to be stitched together. 98 Also, LSP stitching as defined here results in an end-to-end LSP both 99 in the control and data planes. 101 LSP hierarchy ([2]) provides signaling and routing procedures so 102 that: 104 a. A Hierarchical LSP (H-LSP) can be created. Such an LSP created 105 in one layer can appear as a data link to LSPs in higher layers. 106 As such, one or more LSPs in a higher layer can traverse this 107 H-LSP as a single hop; we call this "nesting". 109 b. An H-LSP may be managed and advertised (although this is not a 110 requirement) as a Traffic Engineering (TE) link. Advertising an 111 H-LSP as a TE link allows other nodes in the TE domain in which 112 it is advertised to use this H-LSP in path computation. If the 113 H-LSP TE link is advertised in the same instance of control plane 114 (TE domain) in which the H-LSP was provisioned, it is then 115 defined as a forwarding adjacency LSP (FA-LSP) and GMPLS nodes 116 can form a forwarding adjacency (FA) over this FA-LSP. There is 117 usually no routing adjacency between end points of an FA. An 118 H-LSP may also be advertised as a TE link in a different TE 119 domain. In this case, the end points of the H-LSP are required 120 have a routing adjacency between them. 122 c. RSVP signaling for LSP setup can occur between nodes that do not 123 have a routing adjacency. 125 A stitched TE LSP comprises of different LSP segments (S-LSPs) that 126 are connected together in the data plane in such a way that a single 127 end-to-end LSP is realized in the data plane. In this document, we 128 define the concept of LSP stitching and detail the control plane 129 mechanisms and procedures to accomplish this. Where applicable, 130 similarities and differences between LSP hierarchy and LSP stitching 131 are highlighted. Signaling extensions required for LSP stitching are 132 also described here. 134 1.1. Conventions used in this document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [1]. 140 2. Comparison with LSP Hierarchy 142 In case of LSP stitching, instead of an H-LSP, an "LSP segment" 143 (S-LSP) is created between two GMPLS nodes. An S-LSP for stitching 144 is considered to be the moral equivalent of an H-LSP for nesting. An 145 S-LSP created in one layer, unlike an H-LSP, provides a data link to 146 other LSPs in the same layer. Similar to an H-LSP, an S-LSP could be 147 managed and advertised, although it is not required, as a TE link, 148 either in the same TE domain as it was provisioned or a different 149 one. If so advertised, other GMPLS nodes can use the corresponding 150 S-LSP TE link in path computation. While there is a forwarding 151 adjacency between end points of an H-LSP TE link, there is no 152 forwarding adjacency between end points of an S-LSP TE link. In this 153 aspect, an H-LSP TE link more closely resembles a 'basic' TE link as 154 compared to an S-LSP TE link. 156 While LSP hierarchy allows more than one LSP to be mapped to an 157 H-LSP, in case of LSP stitching, at most one LSP may be associated 158 with an S-LSP. Thus, if LSP-AB is an H-LSP between nodes A and B, 159 then multiple LSPs, say LSP1, LSP2, and LSP3 can potentially be 160 'nested into' LSP-AB. This is achieved by exchanging a unique label 161 for each of LSP1..3 over the LSP-AB hop, thereby separating the data 162 corresponding to each of LSP1..3 while traversing the H-LSP LSP-AB. 163 Each of LSP1..3 may reserve some bandwidth on LSP-AB. On the other 164 hand, if LSP-AB is an S-LSP, then at most one LSP, say LSP1, may be 165 stitched to the S-LSP LSP-AB. LSP-AB is then dedicated to LSP1 and 166 no other LSPs can be associated with LSP-AB. The entire bandwith on 167 S-LSP LSP-AB is allocated to LSP1. However, similar to H-LSPs, 168 several S-LSPs may be bundled into a TE link ([11]). 170 The LSPs LSP1..3 which are either nested or stitched into another LSP 171 are termed as end-to-end (e2e) LSPs in the rest of this document. 172 Routing procedures specific to LSP stitching are detailed in 173 Section 4. 175 Targetted (non-adjacent) RSVP signaling defined in [2] is required 176 for LSP stitching of an e2e LSP to an S-LSP. Specific extensions for 177 LSP stitching are described later in Section 5.1. Therefore, in the 178 control plane, there is one RSVP session corresponding to the e2e LSP 179 as well as one for each S-LSP. The creation and termination of an 180 S-LSP may be dictated by administrative control (statically 181 provisioned) or due to another incoming LSP request (dynamic). 182 Triggers for dynamic creation of an S-LSP may be different from that 183 of an H-LSP and will be described in detail later. 185 3. Usage 187 3.1. Triggers for LSP segment setup 189 An S-LSP may be created either by administrative control 190 (configuration trigger) or dynamically due to an incoming LSP 191 request. LSP Hierarchy ([2]) defines one possible trigger for 192 dynamic creation of FA-LSP by introducing the notion of LSP regions 193 based on Interface Switching Capabilities. As per [2], dynamic FA- 194 LSP creation may be triggered on a node when an incoming LSP request 195 crosses region boundaries. However, this trigger MUST NOT be used 196 for creation of S-LSP for LSP stitching as described in this 197 document. In case of LSP stitching, the switching capabilities of 198 the previous hop and the next hop TE links MUST be the same. 199 Therefore, local policies configured on the node SHOULD be used for 200 dynamic creation of LSP segments. 202 Other possible triggers for dynamic creation of both H-LSPs and 203 S-LSPs include cases where an e2e LSP may cross domain boundaries or 204 satisfy locally configured policies on the node as described in [8]. 206 3.2. Applications 208 LSP stitching procedures described in this document are applicable to 209 GMPLS nodes that need to associate an e2e LSP with another S-LSP of 210 the same switching type and LSP hierarchy procedures do not apply. 211 E.g., if an e2e lambda LSP traverses an LSP segment TE link which is 212 also lambda switch capable, then LSP hierarchy is not possible; in 213 this case, LSP switching may be an option. 215 LSP stitching procedures can be used for inter-domain TE LSP 216 signaling to stitch an inter-domain e2e LSP to a local intra-domain 217 TE S-LSP ([8]). 219 LSP stitching may also be useful in networks to bypass legacy nodes 220 which may not have certain new capabilities in the control plane 221 and/or data plane. E.g., one suggested usage in case of P2MP RSVP 222 LSPs ([7]) is the use of LSP stitching to stitch a P2MP RSVP LSP to 223 an LSP segment between P2MP capable LSRs in the network. The LSP 224 segment would traverse legacy LSRs that may be incapable of acting as 225 P2MP branch points, thereby shielding them from the P2MP control and 226 data path. Note, however, that such configuration may limit the 227 attractiveness of RSVP P2MP and should carefully be examined before 228 deployment. 230 4. Routing aspects 232 An S-LSP is created between two GMPLS nodes and it may traverse zero 233 or more intermediate GMPLS nodes. There is no forwarding adjacency 234 between the end points of an S-LSP TE link. So, although in the TE 235 topology, the end points of an S-LSP TE link are adjacent, in the 236 data plane, these nodes do not have an adjacency. Hence any data 237 plane resource identifier between these nodes is also meaningless. 238 The traffic that arrives at the head end of the S-LSP is switched 239 into the S-LSP contiguously with a label swap and no label is 240 associated directly between the end nodes of the S-LSP itself. 242 An S-LSP MAY be treated and managed as a TE link. This TE link MAY 243 be numbered or unnumbered. For an unnumbered S-LSP TE link, the 244 schemes for assignment and handling of the local and remote link 245 identifiers as specified in [10] SHOULD be used. When appropriate, 246 the TE information associated with an S-LSP TE link MAY be flooded 247 via ISIS-TE [13] or OSPF-TE [12]. Mechanisms similar to that for 248 regular (basic) TE links SHOULD be used to flood S-LSP TE links. 249 Advertising or flooding the S-LSP TE link is not a requirement for 250 LSP stitching. If advertised, this TE information will exist in the 251 TE database (TED) and can then be used for path computation by other 252 GMPLS nodes in the TE domain in which it is advertised. When so 253 advertising S-LSPs, one should keep in mind that these add to the 254 size and complexity of the link-state database. 256 If an S-LSP is advertised as a TE link in the same TE domain in which 257 it was provisioned, there is no need for a routing adjacency between 258 end points of this S-LSP TE link. If an S-LSP TE link is advertised 259 in a different TE domain, the end points of that TE link SHOULD have 260 a routing adjacency between them. 262 The TE parameters defined for an FA in [2] SHOULD be used for an 263 S-LSP TE link as well. The switching capability of an S-LSP TE link 264 MUST be equal to the switching type of the underlying S-LSP; i.e. an 265 S-LSP TE link provides a data link to other LSPs in the same layer, 266 so no hierarchy is possible. 268 An S-LSP MUST NOT admit more than one e2e LSP into it. If an S-LSP 269 is allocated to an e2e LSP, the unreserved bandwidth SHOULD be set to 270 zero to prevent further e2e LSPs being admitted into the S-LSP. 272 Multiple S-LSPs between the same pair of nodes MAY be bundled using 273 the concept of Link Bundling ([11]) into a single TE link. In this 274 case, each component S-LSP may be allocated to at most one e2e LSP. 275 When any component S-LSP is allocated for an e2e LSP, the component's 276 unreserved bandwidth SHOULD be set to zero and the Minimum and 277 Maximum LSP bandwidth of the TE link SHOULD be recalculated. This 278 will prevent more than one LSP from being computed and admitted over 279 an S-LSP. 281 5. Signaling aspects 283 The end nodes of an S-LSP may or may not have a routing adjacency. 284 However, they SHOULD have a signaling adjacency (RSVP neighbor 285 relationship) and will exchange RSVP messages with each other. It 286 may, in fact, be desirable to exchange RSVP Hellos directly between 287 the LSP segment end points to allow support for state recovery during 288 Graceful Restart procedures as described in [4]. 290 In order to signal an e2e LSP over an LSP segment, signaling 291 procedures described in section 8.1.1 of [2] MUST be used. 292 Additional signaling extensions for stitching are described in the 293 next section. 295 5.1. RSVP-TE signaling extensions 297 The signaling extensions described here MUST be used for stitching an 298 e2e packet or non-packet GMPLS LSP ([4]), to an S-LSP. 300 Stitching an e2e LSP to an LSP segment involves the following two 301 step process: 303 1. Creating and preparing the S-LSP for stitching by signaling the 304 desire to stitch between end points of the S-LSP; and 306 2. stitching the e2e LSP to the S-LSP. 308 5.1.1. Creating and preparing LSP segment for stitching 310 If a GMPLS node desires to create an S-LSP, i.e., one to be used for 311 stitching, then it MUST indicate this in the Path message for the 312 S-LSP. This signaling explicitly informs the S-LSP egress node that 313 the ingress node is planning to perform stitching over the S-LSP. 314 Since an S-LSP is not conceptually different from any other LSP, 315 explicitly signaling 'LSP stitching desired' helps clarify the data 316 plane actions to be carried out when the S-LSP is used by some other 317 e2e LSP. Also, in case of packet LSPs, this is what allows the 318 egress of the S-LSP to carry out label allocation as explained below. 319 Also, so that the head-end node can ensure that correct stitching 320 actions will be carried out at the egress node, the egress node MUST 321 signal this information back to the head-end node in the Resv, as 322 explained below. 324 In order to request LSP stitching on the S-LSP, we define a new bit 325 in the Attributes Flags TLV of the LSP_ATTRIBUTES object defined in 326 [3]: 328 Bit Number 5 (TBD): LSP stitching desired bit - This bit SHOULD be 329 set in the Attributes Flags TLV of the LSP_ATTRIBUTES object in the 330 Path message for the S-LSP by the head-end of the S-LSP, that desires 331 LSP stitching. This bit MUST NOT be modified by any other nodes in 332 the network. Nodes other than the egress of the S-LSP SHOULD ignore 333 this bit. 335 An LSP segment can be used for stitching only if the egress node of 336 the S-LSP is also ready to participate in stitching. In order to 337 indicate this to the head-end node of the S-LSP, the following new 338 bit is defined in the Flags field of the RRO Attributes subobject: 339 Bit Number 5 (TBD): LSP segment stitching ready. 341 If an egress node of the S-LSP receiving the Path message, supports 342 the LSP_ATTRIBUTES object and the Attributes Flags TLV, and also 343 recognizes the "LSP stitching desired" bit, but cannot support the 344 requested stitching behavior, then it MUST send back a PathErr 345 message with an error code of "Routing Problem" and an error sub- 346 code="Stitching unsupported" (TBD) to the head-end node of the S-LSP. 348 If an egress node receiving a Path message with the "LSP stitching 349 desired" bit set in the Flags field of received LSP_ATTRIBUTES, 350 recognizes the object, the TLV and the bit and also supports the 351 desired stitching behavior, then it MUST allocate a non-NULL label 352 for that S-LSP in the corresponding Resv message. Also, so that the 353 head-end node can ensure that the correct label (forwarding) actions 354 will be carried out by the egress node and that the S-LSP can be used 355 for stitching, the egress node MUST set the "LSP segment stitching 356 ready" bit defined in the Flags field of the RRO Attribute sub- 357 object. 359 Finally, if the egress node for the S-LSP supports the LSP_ATTRIBUTES 360 object but does not recognize the Attributes Flags TLV, or supports 361 the TLV as well but does not recognize this particular bit, then it 362 SHOULD simply ignore the above request. 364 An ingress node requesting LSP stitching MUST examine the RRO 365 Attributes sub-object Flags corresponding to the egress node for the 366 S-LSP, to make sure that stitching actions are carried out at the 367 egress node. It MUST NOT use the S-LSP for stitching if the "LSP 368 segment stitching ready" bit is cleared. 370 5.1.1.1. Steps to support Penultimate Hop Popping 372 Note that this section is only applicable to packet LSPs that use 373 Penultimate Hop Popping (PHP) at the last hop, where the egress node 374 distributes the Implicit NULL Label ([9]) in the Resv Label. These 375 steps MUST NOT be used for a non-packet LSP and for packet LSPs where 376 PHP is not desired. 378 When the egress node of an S-LSP receives a Path message for an e2e 379 LSP using this S-LSP and this is a packet LSP, it SHOULD first check 380 if it is also the egress for the e2e LSP. If the egress node is the 381 egress for both the S-LSP as well as the e2e TE LSP, and this is a 382 packet LSP which requires PHP, then the node MUST send back a Resv 383 trigger message for the S-LSP with a new label corresponding to the 384 Implicit or Explicit NULL label. Note that this operation does not 385 cause any traffic disruption since the S-LSP is not carrying any 386 traffic at this time, since the e2e LSP has not yet been established. 388 If the e2e LSP and the S-LSP are bidirectional, the ingress of the 389 e2e LSP SHOULD first check whether it is also the ingress of the 390 S-LSP. If so, it SHOULD re-issue the Path message for the S-LSP with 391 an implicit or explicit NULL upstream label; and only then proceed 392 with the signaling of the e2e LSP. 394 5.1.2. Stitching the e2e LSP to the LSP segment 396 When a GMPLS node receives an e2e LSP request, depending on the 397 applicable trigger, it may either dynamically create an S-LSP based 398 on procedures described above or it may map an e2e LSP to an existing 399 S-LSP. The switching type in the Generalized Label Request of the 400 e2e LSP MUST be equal to the switching type of the S-LSP. Other 401 constraints like ERO, bandwidth, local TE policies MUST also be used 402 for S-LSP selection or signaling. In either case, once an S-LSP has 403 been selected for an e2e LSP, the following procedures MUST be 404 followed in order to stitch an e2e LSP to an S-LSP. 406 The GMPLS node receiving the e2e LSP setup Path message MUST use the 407 signaling procedures described in [2] to send the Path message to the 408 end point of the S-LSP. In this Path message, the node MUST identify 409 the S-LSP in the RSVP_HOP. An egress node receiving this RSVP_HOP 410 should also be able to identify the S-LSP TE link based on the 411 information signaled in the RSVP_HOP. If the S-LSP TE link is 412 numbered, then the addressing scheme as proposed in [2] SHOULD be 413 used to number the S-LSP TE link. If the S-LSP TE link is 414 unnumbered, then any of the schemes proposed in [10] SHOULD be used 415 to exchange S-LSP TE link identifiers between the S-LSP end points. 416 If the TE link is bundled, the RSVP_HOP SHOULD identify the component 417 link as defined in [11]. 419 In case of a bidirectional e2e TE LSP, an Upstream Label MUST be 420 signaled in the Path message for the e2e LSP over the S-LSP hop. 421 However, since there is no forwarding adjacency between the S-LSP end 422 points, any label exchanged between them has no significance. So the 423 node MAY chose any label value for the Upstream Label. The label 424 value chosen and signaled by the node in the Upstream Label is out of 425 the scope of this document and is specific to the implementation on 426 that node. The egress node receiving this Path message MUST ignore 427 the Upstream Label in the Path message over the S-LSP hop. 429 The egress node receiving this Path message MUST signal a Label in 430 the Resv message for the e2e TE LSP over the S-LSP hop. Again, since 431 there is no forwarding adjacency between the egress and ingress S-LSP 432 nodes, any label exchanged between them is meaningless. So, the 433 egress node MAY choose any label value for the Label. The label 434 value chosen and signaled by the egress node is out of the scope of 435 this document and is specific to the implementation on the egress 436 node. The egress S-LSP node SHOULD also carry out data plane 437 operations so that traffic coming in on the S-LSP is switched over to 438 the e2e LSP downstream, if the egress of the e2e LSP is some other 439 node downstream. If the e2e LSP is bidirectional, this means setting 440 up label switching in both directions. The Resv message from the 441 egress S-LSP node is IP routed back to the previous hop (ingress of 442 the S-LSP). The ingress node stitching an e2e TE LSP to an S-LSP 443 MUST ignore the Label object received in the Resv for the e2e TE LSP 444 over the S-LSP hop. The S-LSP ingress node SHOULD also carry out 445 data plane operations so that traffic coming in on the e2e LSP is 446 switched into the S-LSP. It should also carry out actions to handle 447 traffic in the opposite direction if the e2e LSP is bidirectional. 449 Note that the label exchange procedure for LSP stitching on the S-LSP 450 hop, is similar to that for LSP hierarchy over the H-LSP hop. The 451 difference is the lack of the significance of this label between the 452 S-LSP end points in case of stitching. Therefore, in case of 453 stitching the recepients of the Label/Upstream Label MUST NOT process 454 these labels. Also, at most one e2e LSP is associated with one 455 S-LSP. If a node at the head-end of an S-LSP receives a Path Msg for 456 an e2e LSP that identifies the S-LSP in the ERO and the S-LSP 457 bandwidth has already been allocated to some other LSP, then regular 458 rules of RSVP-TE pre-emption apply to resolve contention for S-LSP 459 bandwidth. If the LSP request over the S-LSP cannot be satisfied, 460 then the node SHOULD send back a PathErr with the error codes as 461 described in [5]. 463 5.1.3. RRO Processing for e2e LSP 465 RRO procedures for the S-LSP specific to LSP stitching are already 466 described in Section 5.1.1. In this section we will look at the RRO 467 processing for the e2e LSP over the S-LSP hop. 469 An e2e LSP traversing an S-LSP, SHOULD record in the RRO for that 470 hop, an identifier corresponding to the S-LSP TE link. This is 471 applicable to both Path and Resv messages over the S-LSP hop. If the 472 S-LSP is numbered, then the IPv4 or IPv6 address subobject ([5]) 473 SHOULD be used to record the S-LSP TE link address. If the S-LSP is 474 unnumbered, then the Unnumbered Interface ID subobject as described 475 in [10] SHOULD be used to record the node's Router ID and Interface 476 ID of the S-LSP TE link. In either case, the RRO subobject SHOULD 477 identify the S-LSP TE link end point. Intermediate links or nodes 478 traversed by the S-LSP itself SHOULD NOT be recorded in the RRO for 479 the e2e LSP over the S-LSP hop. 481 5.1.4. Teardown of LSP segment 483 S-LSP teardown follows the standard procedures defined in [5] and 484 [4]. This includes procedures without and with setting the 485 administrative status. Teardown of S-LSP may be initiated by either 486 the ingress, egress or any other node along the S-LSP path. 487 Deletion/teardown of the S-LSP SHOULD be treated as a failure event 488 for the e2e LSP associated with it and corresponding teardown or 489 recovery procedures SHOULD be triggered for the e2e LSP. In case of 490 S-LSP teardown for maintenance purpose, the S-LSP ingress node MAY 491 treat this to be equivalent to administratively shutting down a TE 492 link along the e2e LSP path and take corresponding actions to notify 493 the ingress of this event. The actual signaling procedures to handle 494 this event is out of the scope of this document. 496 5.1.5. Teardown of e2e LSP 498 e2e LSP teardown also follows standard procedures defined in [5] and 499 [4] either without or with the administrative status. Note, however, 500 that teardown procedures of e2e LSP and of S-LSP are independent of 501 each other. So, it is possible that while one LSP follows graceful 502 teardown with adminstrative status, the other LSP is torn down 503 without administrative status (using PathTear/ResvTear/PathErr with 504 state removal). 506 When an e2e LSP teardown is initiated from the head-end, and a 507 PathTear arrives at the GMPLS stitching node, the PathTear message 508 like the Path message MUST be IP routed to the LSP segment egress 509 node with the destination IP address of the Path message set to the 510 address of the S-LSP end node. Router Alert MUST be off and RSVP TTL 511 check MUST be disabled on the receiving node. PathTear will result 512 in deletion of RSVP states corresponding to the e2e LSP and freeing 513 of label allocations and bandwidth reservations on the S-LSP. The 514 unreserved bandwidth on the S-LSP TE link SHOULD be re-adjusted. 516 Similarly, a teardown of the e2e LSP may be initiated from the tail- 517 end either using a ResvTear or a PathErr with state removal. The 518 egress of the S-LSP MUST propagate the ResvTear/PathErr upstream, IP 519 routed to the ingress of the LSP segment. 521 Graceful LSP teardown using ADMIN_STATUS as described in [4] is also 522 applicable to stitched LSPs. 524 If the S-LSP was statically provisioned, tearing down of an e2e LSP 525 MAY not result in tearing down of the S-LSP. If, however, the S-LSP 526 was dynamically setup due to the e2e LSP setup request, then 527 depending on local policy, the S-LSP MAY be torn down if no e2e LSP 528 is utilizing the S-LSP. Although the S-LSP may be torn down while 529 the e2e LSP is being torn down, it is RECOMMENDED that a delay be 530 introduced in tearing down the S-LSP once the e2e LSP teardown is 531 complete, in order to reduce the simultaneous generation of RSVP 532 errors and teardown messages due to multiple events. The delay 533 interval may be set based on local implementation. The RECOMMENDED 534 interval is 30 seconds. 536 5.2. Summary of LSP Stitching procedures 538 5.2.1. Example topology 540 The following topology will be used for the purpose of examples 541 quoted in the following sections. 543 e2e LSP 544 +++++++++++++++++++++++++++++++++++> (LSP1-2) 546 LSP segment (S-LSP) 547 ====================> (LSP-AB) 548 C --- E --- G 549 /|\ | / |\ 550 / | \ | / | \ 551 R1 ---- A \ | \ | / | / B --- R2 552 \| \ |/ |/ 553 D --- F --- H 555 PATH 556 ====================> (LSP stitching desired) 557 RESV 558 <==================== (LSP segment stitching ready) 560 PATH (Upstream Label) 561 +++++++++++++++++++++ 562 +++++++ ++++++> 563 <++++++ +++++++ 564 +++++++++++++++++++++ 565 RESV (Label) 567 5.2.2. LSP segment setup 569 Let us consider an S-LSP LSP-AB being setup between two nodes A and B 570 which are more than one hop away. Node A sends a Path message for 571 the LSP-AB with "LSP stitching desired" set in Flags field of 572 LSP_ATTRIBUTES object. If the egress node B is ready to carry out 573 stitching procedures, then B will respond with "LSP segment stitching 574 ready" set in the Flags field of the RRO Attributes subobject, in the 575 RRO sent in the Resv for the S-LSP. Once A receives the Resv for 576 LSP-AB and sees this bit set in the RRO, it can then use LSP-AB for 577 stitching. A cannot use LSP-AB for stitching if the bit is cleared 578 in the RRO. 580 5.2.3. Setup of e2e LSP 582 Let us consider an e2e LSP LSP1-2 starting one hop before A on R1 and 583 ending on node R2, as shown above. If the S-LSP has been advertised 584 as a TE link in the TE domain, and R1 and A are in the same domain, 585 then R1 may compute a path for LSP1-2 over the S-LSP LSP-AB and 586 identify the LSP-AB hop in the ERO. If not, R1 may compute hops 587 between A and B and A may use these ERO hops for S-LSP selection or 588 signaling a new S-LSP. If R1 and A are in different domains, then 589 LSP1-2 is an inter-domain LSP. In this case, S-LSP LSP-AB, similar 590 to any other basic TE link in the domain will not be advertised 591 outside the domain. R1 would use either per-domain path computation 592 ([14]) or PCE based computation ([15]) for LSP1-2. 594 5.2.4. Stitching of e2e LSP into an LSP segment 596 When the Path message for the e2e LSP LSP1-2 arrives at node A, A 597 matches the switching type of LSP1-2 with the S-LSP LSP-AB. If the 598 switching types are not equal, then LSP-AB cannot be used to stitch 599 LSP1-2. Once the S-LSP LSP-AB to which LSP1-2 will be stitched has 600 been determined, the Path message for LSP1-2 is sent (via IP routing, 601 if needed) to node B with the IF_ID RSVP_HOP identifying the S-LSP 602 LSP-AB. When B receives this Path message for LSP1-2, if B is also 603 the egress for LSP1-2, and if this is a packet LSP requiring PHP, 604 then B will send a Resv refresh for LSP-AB with the NULL Label. In 605 this case, since B is not the egress, the Path message for LSP1-2 is 606 propagated to R2. The Resv for LSP1-2 from B is sent back to A with 607 a Label value chosen by B. B also sets up its data plane to swap the 608 Label sent to either G or H on the S-LSP with the Label received from 609 R2. Node A ignores the Label on receipt of the Resv message and then 610 propagates the Resv to R1. A also sets up its data plane to swap the 611 Label sent to R1 with the Label received on the S-LSP from C or D. 612 This stitches the e2e LSP LSP1-2 to an S-LSP LSP-AB between nodes A 613 and B. In the data plane, this yields a series of label swaps from R1 614 to R2 along e2e LSP LSP1-2. 616 6. Security Considerations 618 Similar to [2], this document permits that the control interface over 619 which RSVP messages are sent or received need not be the same as the 620 data interface which the message identifies for switching traffic. 621 Also, the 'sending interface' and 'receiving interface' may change as 622 routing changes. So, these cannot be used to establish security 623 association between neighbors. Mechanisms described in [6] should be 624 re-examined and may need to be altered to define new security 625 associations based on receiver's IP address instead of the sending 626 and receiving interfaces. Also, this document allows the IP 627 destination address of Path and PathTear messages to be the IP 628 address of a nexthop node (receiver's address) instead of the RSVP 629 session destination address. So, [6] should be revisited to check if 630 IPSec AH is now a viable means of securing RSVP-TE messages. 632 7. IANA Considerations 634 The following values have to be defined by IANA for this document. 635 The registry is http://www.iana.org/assignments/rsvp-parameters. 637 7.1. Attribute Flags for LSP_ATTRIBUTES object 639 The following new bit is being defined for the Attributes Flags TLV 640 in the LSP_ATTRIBUTES object. The numeric value should be assigned 641 by IANA. 643 LSP stitching desired bit - Bit Number 5 (Suggested value) 645 This bit is only to be used in the Attributes Flags TLV on a Path 646 message. 648 The 'LSP stitching desired bit' has a corresponding 'LSP segment 649 stitching ready' bit (Bit Number 5) to be used in the RRO Attributes 650 sub-object. 652 7.2. New Error Codes 654 The following new error sub-code is being defined under the RSVP 655 error-code "Routing Problem" (24). The numeric error sub-code value 656 should be assigned by IANA. 658 Stitching unsupported - sub-code 23 (Suggested value) 660 This error code is to be used only in an RSVP PathErr. 662 8. Acknowledgments 664 The authors would like to thank Adrian Farrel for his comments and 665 suggestions. The authors would also like to thank Dimitri 666 Papadimitriou and Igor Bryskin for their thorough review of the 667 document and discussions regarding the same. 669 9. References 671 9.1. Normative References 673 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 674 Levels", BCP 14, RFC 2119, March 1997. 676 [2] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 677 Hierarchy with Generalized Multi-Protocol Label Switching 678 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 680 [3] Farrel, A., Papadimitriou, D., Vasseur, J., and A. Ayyangar, 681 "Encoding of Attributes for Multiprotocol Label Switching (MPLS) 682 Label Switched Path (LSP) Establishment Using Resource 683 ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, 684 February 2006. 686 [4] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) 687 Signaling Resource ReserVation Protocol-Traffic Engineering 688 (RSVP-TE) Extensions", RFC 3473, January 2003. 690 [5] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. 691 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", 692 RFC 3209, December 2001. 694 [6] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 695 Authentication", RFC 2747, January 2000. 697 9.2. Informative References 699 [7] Aggarwal, R., "Extensions to RSVP-TE for Point-to-Multipoint TE 700 LSPs", draft-ietf-mpls-rsvp-te-p2mp-06 (work in progress), 701 August 2006. 703 [8] Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic 704 Engineering - RSVP-TE extensions", 705 draft-ietf-ccamp-inter-domain-rsvp-te-03 (work in progress), 706 March 2006. 708 [9] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, 709 D., Li, T., and A. Conta, "MPLS Label Stack Encoding", 710 RFC 3032, January 2001. 712 [10] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in 713 Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", 714 RFC 3477, January 2003. 716 [11] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in 717 MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 719 [12] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of 720 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, 721 October 2005. 723 [13] Kompella, K. and Y. Rekhter, "Intermediate System to 724 Intermediate System (IS-IS) Extensions in Support of 725 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, 726 October 2005. 728 [14] Vasseur, J., "A Per-domain path computation method for 729 establishing Inter-domain Traffic Engineering (TE) Label 730 Switched Paths (LSPs)", 731 draft-ietf-ccamp-inter-domain-pd-path-comp-03 (work in 732 progress), August 2006. 734 [15] Farrel, A., "A Path Computation Element (PCE) Based 735 Architecture", draft-ietf-pce-architecture-05 (work in 736 progress), April 2006. 738 Authors' Addresses 740 Arthi Ayyangar (editor) 741 Nuova Systems 742 2600 San Tomas Expressway 743 Santa Clara, CA 95051 744 US 746 Email: arthi@nuovasystems.com 748 Kireeti Kompella (editor) 749 Juniper Networks 750 1194 N. Mathilda Ave. 751 Sunnyvale, CA 94089 752 US 754 Email: kireeti@juniper.net 756 Jean Philippe Vasseur 757 Cisco Systems, Inc. 758 300 Beaver Brook Road 759 Boxborough, MA 01719 760 US 762 Email: jpv@cisco.com 764 Full Copyright Statement 766 Copyright (C) The Internet Society (2006). 768 This document is subject to the rights, licenses and restrictions 769 contained in BCP 78, and except as set forth therein, the authors 770 retain all their rights. 772 This document and the information contained herein are provided on an 773 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 774 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 775 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 776 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 777 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 778 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 780 Intellectual Property 782 The IETF takes no position regarding the validity or scope of any 783 Intellectual Property Rights or other rights that might be claimed to 784 pertain to the implementation or use of the technology described in 785 this document or the extent to which any license under such rights 786 might or might not be available; nor does it represent that it has 787 made any independent effort to identify any such rights. Information 788 on the procedures with respect to rights in RFC documents can be 789 found in BCP 78 and BCP 79. 791 Copies of IPR disclosures made to the IETF Secretariat and any 792 assurances of licenses to be made available, or the result of an 793 attempt made to obtain a general license or permission for the use of 794 such proprietary rights by implementers or users of this 795 specification can be obtained from the IETF on-line IPR repository at 796 http://www.ietf.org/ipr. 798 The IETF invites any interested party to bring to its attention any 799 copyrights, patents or patent applications, or other proprietary 800 rights that may cover technology that may be required to implement 801 this standard. Please address the information to the IETF at 802 ietf-ipr@ietf.org. 804 Acknowledgment 806 Funding for the RFC Editor function is provided by the IETF 807 Administrative Support Activity (IASA).