idnits 2.17.1 draft-ietf-ccamp-lsp-stitching-00.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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 502. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 15) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 0x02 (TBD): LSP stitching desired bit - This flag will be set in the Attributes Flags TLV of the LSP_ATTRIBUTES object in the Path message for the LSP segment by the head-end of the LSP segment, that desires LSP stitching. This flag MUST not be modified by any other nodes in the network. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The egress node MUST not allocate any Label in the Resv message for the e2e TE LSP. Similarly, in case of bidirectional e2e TE LSP, no Upstream Label is allocated over the LSP segment in the corresponding Path message. An ingress node stitching an e2e TE LSP to an LSP segment MUST ignore any Label object received in the Resv for the e2e TE LSP. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When the Path message for an e2e LSP arrives at the GMPLS stitching node, the LSP segment to stitch the e2e LSP to is determined. The Path message for the e2e LSP is then sent directly to the LSP segment end node with the destination IP address of the Path message set to the address of the LSP segment end node. The Router Alert option MUST not be set in this case. Furthermore, when the message arrives at the end node, RSVP TTL checks MUST be disabled. The LSP segment MUST be identified in the IF_ID RSVP_HOP (PHOP) object of the Path message. It is assumed that the receiver of this Path message can identify the LSP segment based on the data interface identification in the IF_ID RSVP_HOP. When the Resv is sent back for the e2e LSP, no Label is allocated on the LSP segment hop. E.g. When the Path message for the e2e LSP LSP1-2 arrives at node A, and the LSP segment LSP-AB to stitch LSP1-2 to has been identified (either based on explicit hop in ERO or due to local decision), then Path message for LSP1-2 is sent directly to node B with the IF_ID RSVP_HOP identifying the LSP segment LSP-AB. When B receives this Path message for LSP1-2, if B is also the egress for LSP1-2, and if this is a packet LSP requiring PHP, then B will send a Resv refresh for LSP-AB with the NULL Label. If B is not the egress, then Path message for LSP1-2 is propagated to R2. The Resv for LSP1-2 is sent back from B directly to A with no Label in it. Node A then propagates the Resv to R1. This stitches an e2e LSP LSP1-2 to an LSP segment LSP-AB between nodes A and B. In the data plane, this yields a series of label swaps from R1 to R2 along LSP LSP1-2. -- 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 2005) is 6949 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) == Outdated reference: A later version (-05) exists of draft-ietf-mpls-rsvpte-attributes-04 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-te-p2mp-01 == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-inter-domain-rsvp-te-00 Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 7 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 Juniper Networks 4 Expires: October 3, 2005 JP. Vasseur 5 Cisco Systems, Inc. 6 April 2005 8 Label Switched Path Stitching with Generalized MPLS Traffic 9 Engineering 10 draft-ietf-ccamp-lsp-stitching-00 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on October 3, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 In certain scenarios, there may be a need to combine together two 46 different Generalized Multi-Protocol Label Switching (GMPLS) Label 47 Switched Paths (LSPs) such that in the data plane, a single 48 end-to-end (e2e) LSP is achieved and all traffic from one LSP is 49 switched onto the other LSP. We will refer to this as "LSP 50 stitching". This document covers cases where: a) the node performing 51 the stitching does not require configuration of every LSP pair to be 52 stitched together b) the node performing the stitching is not the 53 egress of any of the LSPs c) LSP stitching not only results in an 54 end-to-end LSP in the data plane, but there is also a corresponding 55 end-to-end LSP (RSVP session) in the control plane. It might be 56 possible to configure a GMPLS node to switch the traffic from an LSP 57 for which it is the egress, to another LSP for which it is the 58 ingress, without requiring any signaling or routing extensions 59 whatsoever, completely transparent to other nodes. This will also 60 result in LSP stitching in the data plane. However, this document 61 does not cover this scenario of LSP stitching. 63 This document describes the mechanisms to accomplish LSP stitching in 64 the scenarios described above. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1 Conventions used in this document . . . . . . . . . . . . 5 70 2. Routing aspects . . . . . . . . . . . . . . . . . . . . . . . 6 71 3. Signaling aspects . . . . . . . . . . . . . . . . . . . . . . 7 72 3.1 RSVP-TE signaling extensions . . . . . . . . . . . . . . . 7 73 4. Summary of LSP Stitching procedures . . . . . . . . . . . . . 10 74 4.1 LSP segment setup . . . . . . . . . . . . . . . . . . . . 10 75 4.2 Setup of e2e LSP . . . . . . . . . . . . . . . . . . . . . 10 76 4.3 Stitching of e2e LSP into an LSP segment . . . . . . . . . 10 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 6.1 Attribute Flags for LSP_ATTRIBUTES object . . . . . . . . 13 80 6.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 13 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 8.1 Normative References . . . . . . . . . . . . . . . . . . . 15 84 8.2 Informative References . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 86 Intellectual Property and Copyright Statements . . . . . . . . 17 88 1. Introduction 90 LSP hierarchy ([2]) provides signaling and routing procedures so 91 that: 92 a. a GMPLS node can form a forwarding adjacency (FA) over the FA LSP 93 b. other Label Switching Routers (LSRs) can see this FA LSP as a 94 Traffic Engineering (TE) link 95 c. the GMPLS node can nest one or more LSPs over the FA LSP. This 96 covers intra-domain LSPs only. 97 d. RSVP signaling for LSP setup can occur between nodes that do not 98 have routing adjacency. 100 LSP stitching is a special case of LSP hierarchy. In case of LSP 101 stitching, instead of an FA LSP, we will create an "LSP segment" 102 between two GMPLS nodes. So an LSP segment for stitching is 103 considered to be the moral equivalent of an FA LSP for nesting. 104 While LSP hierarchy allows more that one LSP to be admitted into the 105 FA-LSP, in case of LSP stitching, the desired switching type of the 106 LSP and the switching capability of the LSP segment are such that at 107 most one LSP may be admitted into an LSP segment. E.g. if LSP-AB is 108 an FA-LSP between nodes A and B, then multiple LSPs, say LSP1, LSP2, 109 LSP3 could potentially be 'nested into' LSP-AB. This is achieved by 110 exchanging a unique label for each of LSP1..3 over the LSP-AB hop 111 thereby permitting LSP1..3 to share the FA-LSP LSP-AB. Each of 112 LSP1..3 may reserve some bandwidth on LSP-AB. On the other hand, if 113 LSP-AB is an LSP segment, then at most one LSP, say LSP1 may be 114 'stitched to' the LSP segment LSP-AB. No labels are exchanged for 115 LSP1 over the LSP-AB hop (i.e. between A and B directly). 116 Therefore, LSP-AB is dedicated to LSP1 and no other LSPs can be 117 associated with LSP-AB. The LSPs LSP1..3 which are either nested or 118 stitched into another LSP are termed as end-to-end (e2e) LSPs in the 119 rest of this document. 121 Signaling and routing procedures for LSP stitching are basically 122 similar to that described in [2]). The LSP segment will be seen seen 123 as a TE link by all nodes in the network. Also, non-adjacent RSVP 124 signaling defined in [2]) will still be required to stitch an LSP to 125 an LSP segment. So, in the control plane, there is one RSVP session 126 corresponding to the e2e LSP as well as one for each LSP segment that 127 the e2e LSP is being stitched to. An LSP segment may be created 128 either via a configuration trigger or dynamically due to an incoming 129 LSP request. In this document we will highlight, where applicable, 130 similarities and differences in the routing and signaling procedures 131 between LSP hierarchy and LSP stitching. Additional signaling 132 extensions required for LSP stitching are also described here. 134 LSP stitching SHOULD be used when the switching types (capabilities) 135 of the LSP and the LSP segment are such that LSP hierarchy as 136 described in [2]) is not possible. E.g. if the e2e LSP is a lambda 137 LSP and the LSP segment is also a lambda LSP, then in this case LSP 138 hierarchy is not possible. LSP stitching could also be useful in 139 networks to bypass legacy nodes which may not have certain new 140 capabilities in the control plane and/or data plane. E.g. one 141 suggested usage in case of P2MP RSVP LSPs ([7]) is the use of LSP 142 stitching to stitch a P2MP RSVP LSP to an LSP segment between P2MP 143 capable LSRs in the network. The LSP segment would traverse legacy 144 LSRs that may be incapable of acting as P2MP branch points, thereby 145 shielding them from the P2MP control and data path. LSP stitching 146 procedures could also be used for inter-domain TE LSP signaling to 147 stitch an inter-domain LSP to a local intra-domain TE LSP segment 148 ([8]). 150 1.1 Conventions used in this document 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [1]. 156 2. Routing aspects 158 An LSP segment is similar to an FA-LSP in that, an LSP segment like 159 an FA-LSP is created and treated like a TE link between two GMPLS 160 nodes whose path transits zero or more GMPLS nodes in the same 161 instance of the GMPLS control plane. These TE links may be numbered 162 or unnumbered. For an unnumbered LSP segment, the assignment and 163 handling of the local and remote link identifiers is specified in 164 [9]. Unlike an FA-LSP, a GMPLS node does not have a data plane 165 adjacency with the end point of the LSP segment. This implies that 166 the traffic that arrives at the GMPLS node will be switched into the 167 LSP segment contiguously with a label swap and no label is exchanged 168 directly between the end nodes of the LSP segment itself. Also, a 169 routing adjacency will not be established over an LSP segment. 170 ISIS/OSPF may, however, flood the TE information associated with an 171 LSP segment, which will exist in the TE database (TED) and can then 172 be used for path computation by other GMPLS nodes in the network. 173 The TE parameters defined for an FA in [2]) are also applicable to an 174 LSP segment TE link. 176 Note that, while an FA-LSP TE link can admit zero or more LSPs over 177 it, an LSP segment can admit at most one LSP over it. So, once an 178 LSP is stitched into an LSP segment, the unreserved bandwidth on the 179 LSP segment is set to zero. This prevents any more LSPs from being 180 computed and admitted over the LSP segment TE link. Multiple LSP 181 segments between the same pair of nodes may be bundled using the 182 concept of Link Bundling ([10]) into a single TE link. When any 183 component LSP segment is allocated for an LSP, the component's 184 unreserved bandwidth MUST be set to zero and the Minimum and Maximum 185 LSP bandwidth of the TE link SHOULD be recalculated. 187 3. Signaling aspects 189 In general, the trigger for the creation or termination of an LSP 190 segment may be either mechanisms which are outside of GMPLS 191 (configuration of LSP segment on the stitching node) or mechanisms 192 within GMPLS (arrival of an LSP setup request with appropriate 193 switching type on the stitching node). 195 Although not adjacent in routing, the end nodes of the LSP segment 196 will have a signaling adjacency and will exchange RSVP messages 197 directly between each other. When an RSVP-TE LSP is signaled over an 198 LSP segment, the Path message MUST contain an IF_ID RSVP_HOP object 199 [4] and the data interface identification MUST identify the LSP 200 segment. For the purpose of ERO and RRO as well, an LSP segment is 201 treated exactly like an FA. 203 The main difference between signaling an LSP over an LSP segment 204 instead of over an FA-LSP is that no Labels are allocated and 205 exchanged for the e2e LSP over the LSP segment hop. So, at most one 206 e2e LSP is associated with one LSP segment. If a node at the 207 head-end of an LSP segment receives a Path Msg for an LSP that 208 identifies the LSP segment in the ERO and the LSP segment bandwidth 209 has already been allocated to some other LSP, then regular rules of 210 RSVP-TE pre-emption apply. If the LSP request over the LSP segment 211 cannot be satisfied, then the node SHOULD send back a PathErr with 212 the error codes as described in [5]. 214 Additional signaling extensions for stitching are described in the 215 next section. 217 3.1 RSVP-TE signaling extensions 219 The signaling extensions described here MUST be used if the LSP 220 segment is a packet LSP and an e2e packet LSP may be stitched to it. 221 These extensions are optional for non-packet LSPs and SHOULD be used 222 if no other local mechanisms exist to automatically detect a 223 requirement for stitching at both the ingress and egress nodes of the 224 LSP segment. 226 If a GMPLS node desires to perform LSP stitching, then it MUST 227 indicate this in the Path message for the LSP segment that it plans 228 to use for stitching. This signaling explicitly informs the egress 229 node for the LSP segment that the ingress node is planning to perform 230 stitching over the LSP segment. This will allow the egress of the 231 LSP segment to allocate the correct label(s) as explained below. 232 Also, so that the head-end node can ensure that correct stitching 233 actions were carried out at the egress node, a new flag is defined 234 below in the RRO subobject to indicate that the LSP segment can be 235 used for stitching. 237 In order to request LSP stitching on the LSP segment, we define a new 238 flag bit in the Attributes Flags TLV of the LSP_ATTRIBUTES object 239 defined in [3]: 241 0x02 (TBD): LSP stitching desired bit - This flag will be set in the 242 Attributes Flags TLV of the LSP_ATTRIBUTES object in the Path message 243 for the LSP segment by the head-end of the LSP segment, that desires 244 LSP stitching. This flag MUST not be modified by any other nodes in 245 the network. 247 An LSP segment can only be used for stitching if appropriate label 248 actions were carried out at the egress node of the LSP segment. In 249 order to indicate this to the head-end node of the LSP segment, the 250 following new flag bit is defined in the RRO Attributes sub-object: 251 0x02 (TBD): LSP segment stitching ready. 253 If an egress node receiving a Path message, supports the 254 LSP_ATTRIBUTES object and the Attributes Flags TLV, and also 255 recognizes the "LSP stitching desired" flag bit, but cannot support 256 the requested stitching behavior, then it MUST send back a PathErr 257 message with an error code of "Routing Problem" and an error 258 sub-code=16 (TBD) "Stitching unsupported" to the head-end node of the 259 LSP segment. 261 If an egress node receiving a Path message with the "LSP stitching 262 desired" flag set, recognizes the object, the TLV and the flag and 263 also supports the desired stitching behavior, then it MUST allocate a 264 non-NULL label for that LSP segment in the corresponding Resv 265 message. Now, so that the head-end node can ensure that the correct 266 label actions will be carried out by the egress node and that the LSP 267 segment can be used for stitching, the egress node MUST set the "LSP 268 segment stitching ready" bit defined in the RRO Attribute sub-object. 269 Also, when the egress node for the LSP segment receives a Path 270 message for an e2e LSP using this LSP segment, it SHOULD first check 271 if it is also the egress for the e2e LSP. If the egress node is the 272 egress for both the LSP segment as well as the e2e TE LSP, and this 273 is a packet LSP which requires Penultimate Hop Popping (PHP), then 274 the node MUST send back a Resv refresh for the LSP segment with a new 275 label corresponding to the NULL label. 277 Finally, if the egress node for the LSP segment supports the 278 LSP_ATTRIBUTES object but does not recognize the Attributes Flags 279 TLV, or supports the TLV as well but does not recognize this 280 particular flag bit, then it SHOULD simply ignore the above request. 282 An ingress node requesting LSP stitching MUST examine the RRO 283 Attributes sub-object flag corresponding to the egress node for the 284 LSP segment, to make sure that stitching actions were carried out at 285 the egress node. It MUST NOT use the LSP segment for stitching if 286 the "LSP segment stitching ready" flag is cleared. 288 The egress node MUST not allocate any Label in the Resv message for 289 the e2e TE LSP. Similarly, in case of bidirectional e2e TE LSP, no 290 Upstream Label is allocated over the LSP segment in the corresponding 291 Path message. An ingress node stitching an e2e TE LSP to an LSP 292 segment MUST ignore any Label object received in the Resv for the e2e 293 TE LSP. 295 4. Summary of LSP Stitching procedures 297 4.1 LSP segment setup 299 A GMPLS node that originates an LSP segment may decide to use this 300 LSP segment for stitching. The creation of this LSP segment and its 301 use for stitching may be dictated either by configuration or 302 dynamically on arrival of an LSP setup request at the GMPLS node. 303 Successful completion of signaling procedures for the LSP segment as 304 described in Section 3.1 will allow the GMPLS node to : a) advertise 305 this LSP segment as a TE link with the bandwidth of the LSP as the 306 unreserved bandwidth in the IGP and b) carry out stitching procedures 307 to actually stitch an e2e LSP to the LSP segment. Similar to setup, 308 tearing down the LSP segment may also be decided either via local 309 configuration or due to the fact that there is no longer an e2e LSP 310 stitched to the LSP segment. E.g. Let us consider an LSP segment 311 LSP-AB being setup between two nodes A and B. A sends a Path message 312 for the LSP-AB with "LSP stitching desired". If on the egress node 313 B, stitching procedures are successfully carried out, then B will set 314 the "LSP segment stitching ready" in the RRO sent in the Resv. Once 315 A receives the Resv for LSP-AB and sees this bit set in the RRO, it 316 can then use LSP-AB for stitching. 318 4.2 Setup of e2e LSP 320 Other nodes in the network (in the same domain) trying to setup an 321 e2e LSP across the network may see the LSP segment as a TE link in 322 their TE databases and may compute a path over this TE link. In case 323 of an inter-domain e2e LSP, however, the LSP segment TE link, like 324 any other basic TE link in the domain will probably not be advertised 325 outside the domain. In this case, either per-domain path computation 326 ([11]) or PCE based computation will permit setting up e2e LSPs over 327 LSP segments in other domains. The LSP segment TE link may be 328 identified as an ERO hop in the Path message of the e2e LSP message. 329 E.g. Let us consider an e2e LSP LSP1-2 starting one hop before A on 330 R1 and ending on node R2. R1 may compute a path for LSP1-2 over the 331 LSP segment LSP-AB and identify the LSP-AB hop in the ERO. 333 4.3 Stitching of e2e LSP into an LSP segment 335 When the Path message for an e2e LSP arrives at the GMPLS stitching 336 node, the LSP segment to stitch the e2e LSP to is determined. The 337 Path message for the e2e LSP is then sent directly to the LSP segment 338 end node with the destination IP address of the Path message set to 339 the address of the LSP segment end node. The Router Alert option 340 MUST not be set in this case. Furthermore, when the message arrives 341 at the end node, RSVP TTL checks MUST be disabled. The LSP segment 342 MUST be identified in the IF_ID RSVP_HOP (PHOP) object of the Path 343 message. It is assumed that the receiver of this Path message can 344 identify the LSP segment based on the data interface identification 345 in the IF_ID RSVP_HOP. When the Resv is sent back for the e2e LSP, 346 no Label is allocated on the LSP segment hop. E.g. When the Path 347 message for the e2e LSP LSP1-2 arrives at node A, and the LSP segment 348 LSP-AB to stitch LSP1-2 to has been identified (either based on 349 explicit hop in ERO or due to local decision), then Path message for 350 LSP1-2 is sent directly to node B with the IF_ID RSVP_HOP identifying 351 the LSP segment LSP-AB. When B receives this Path message for 352 LSP1-2, if B is also the egress for LSP1-2, and if this is a packet 353 LSP requiring PHP, then B will send a Resv refresh for LSP-AB with 354 the NULL Label. If B is not the egress, then Path message for LSP1-2 355 is propagated to R2. The Resv for LSP1-2 is sent back from B 356 directly to A with no Label in it. Node A then propagates the Resv 357 to R1. This stitches an e2e LSP LSP1-2 to an LSP segment LSP-AB 358 between nodes A and B. In the data plane, this yields a series of 359 label swaps from R1 to R2 along LSP LSP1-2. 361 5. Security Considerations 363 Similar to [2]), this document permits that the control interface 364 over which RSVP messages are sent or received need not be the same as 365 the data interface which the message identifies for switching 366 traffic. Also, the 'sending interface' and 'receiving interface' may 367 change as routing changes. So, these cannot be used to establish 368 security association between neighbors. Mechanisms described in [6] 369 should be re-examined and may need to be altered to define new 370 security associations based on receiver's IP address instead of the 371 sending and receiving interfaces. Also, this document allows the IP 372 destination address of Path and PathTear messages to be the IP 373 address of a nexthop node (receiver's address) instead of the RSVP 374 session destination address. So, [6] should be revisited to check if 375 IPSec AH is now a viable means of securing RSVP-TE messages. 377 6. IANA Considerations 379 The following values have to be defined by IANA for this document. 380 The registry is http://www.iana.org/assignments/rsvp-parameters. 382 6.1 Attribute Flags for LSP_ATTRIBUTES object 384 The following new flag bit is being defined for the Attributes Flags 385 TLV in the LSP_ATTRIBUTES object. The numeric value should be 386 assigned by IANA. 388 LSP stitching desired bit - 0x02 (Suggested value) 390 This flag bit is only to be used in the Attributes Flags TLV on a 391 Path message. 393 The 'LSP stitching desired bit' has a corresponding 'LSP segment 394 stitching ready' bit to be used in the RRO Attributes sub-object. 396 6.2 New Error Codes 398 The following new error sub-code is being defined under the RSVP 399 error-code "Routing Problem" (24). The numeric error sub-code value 400 should be assigned by IANA. 402 Stitching unsupported - sub-code 16 (Suggested value) 404 This error code is to be used only in a RSVP PathErr. 406 7. Acknowledgments 408 The authors would like to thank Adrian Farrel and Kireeti Kompella 409 for their comments and suggestions. 411 8. References 413 8.1 Normative References 415 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 416 Levels", BCP 14, RFC 2119, March 1997. 418 [2] Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized 419 MPLS TE", Internet-Draft draft-ietf-mpls-lsp-hierarchy-08, 420 September 2002. 422 [3] Farrel, A., Papadimitriou, D. and J. Vasseur, "Encoding of 423 Attributes for Multiprotocol Label Switching (MPLS) Label 424 Switched Path (LSP) Establishment Using RSVP-TE", 425 Internet-Draft draft-ietf-mpls-rsvpte-attributes-04, July 2004. 427 [4] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) 428 Signaling Resource ReserVation Protocol-Traffic Engineering 429 (RSVP-TE) Extensions", RFC 3473, January 2003. 431 [5] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. 432 Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", 433 RFC 3209, December 2001. 435 [6] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic 436 Authentication", RFC 2747, January 2000. 438 8.2 Informative References 440 [7] Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE 441 LSPs", Internet-Draft draft-ietf-mpls-rsvp-te-p2mp-01, January 442 2005. 444 [8] Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic 445 Engineering - RSVP-TE extensions", 446 Internet-Draft draft-ietf-ccamp-inter-domain-rsvp-te-00, 447 February 2005. 449 [9] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in 450 Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", 451 RFC 3477, January 2003. 453 [10] Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in MPLS 454 Traffic Engineering", Internet-Draft draft-ietf-mpls-bundle-06, 455 December 2004. 457 [11] Vasseur, J., "A Per-domain path computation method for 458 computing Inter-domain Traffic Engineering (TE) Label Switched 459 Path (LSP)", 460 . 462 Authors' Addresses 464 Arthi Ayyangar (editor) 465 Juniper Networks 466 1194 N. Mathilda Ave. 467 Sunnyvale, CA 94089 468 US 470 Email: arthi@juniper.net 472 Jean Philippe Vasseur 473 Cisco Systems, Inc. 474 300 Beaver Brook Road 475 Boxborough, MA 01719 476 US 478 Email: jpv@cisco.com 480 Intellectual Property Statement 482 The IETF takes no position regarding the validity or scope of any 483 Intellectual Property Rights or other rights that might be claimed to 484 pertain to the implementation or use of the technology described in 485 this document or the extent to which any license under such rights 486 might or might not be available; nor does it represent that it has 487 made any independent effort to identify any such rights. Information 488 on the procedures with respect to rights in RFC documents can be 489 found in BCP 78 and BCP 79. 491 Copies of IPR disclosures made to the IETF Secretariat and any 492 assurances of licenses to be made available, or the result of an 493 attempt made to obtain a general license or permission for the use of 494 such proprietary rights by implementers or users of this 495 specification can be obtained from the IETF on-line IPR repository at 496 http://www.ietf.org/ipr. 498 The IETF invites any interested party to bring to its attention any 499 copyrights, patents or patent applications, or other proprietary 500 rights that may cover technology that may be required to implement 501 this standard. Please address the information to the IETF at 502 ietf-ipr@ietf.org. 504 Disclaimer of Validity 506 This document and the information contained herein are provided on an 507 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 508 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 509 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 510 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 511 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 512 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 514 Copyright Statement 516 Copyright (C) The Internet Society (2005). This document is subject 517 to the rights, licenses and restrictions contained in BCP 78, and 518 except as set forth therein, the authors retain all their rights. 520 Acknowledgment 522 Funding for the RFC Editor function is currently provided by the 523 Internet Society.