idnits 2.17.1 draft-ayyangar-ccamp-inter-domain-rsvp-te-01.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 882. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 859. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 866. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 872. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 888), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 17) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 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 local intra-domain LSP segment by the head-end node of the LSP segment (boundary node) that desires LSP stitching. This flag MUST not be modified by any other nodes in that domain. == 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 inter-domain TE LSP. Similarly, in case of bidirectional inter-domain TE LSP, no Upstream Label is allocated over the LSP segment in the corresponding Path message. An ingress node stitching an inter-domain LSP to an LSP segment MUST ignore any Label object received in the Resv for the inter-domain 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: 0x01 (TBD): Contiguous LSP bit - this flag is set by the head-end node that originates the inter-domain TE LSP if it desires a contiguous end-to-end TE LSP (in the control & data plane). When set, this indicates that a boundary node MUST not perform any stitching or nesting on the TE LSP and the TE LSP MUST be routed as any other TE LSP (it must be contiguous end to end). When this bit is cleared, a boundary node may decide to perform stitching or nesting. A mid-point node not supporting contiguous TE LSP MUST send a Path Error message upstream with an error code of "Routing Problem" and error sub-code=17 (TBD) (Contiguous LSP type not supported). This bit MUST not be modified by any downstream node. -- 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 (October 2004) is 7130 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: 'RFC2119' is mentioned on line 80, but not defined ** Obsolete normative reference: RFC 2370 (ref. 'OSPF-TE') (Obsoleted by RFC 5250) ** Obsolete normative reference: RFC 3784 (ref. 'ISIS-TE') (Obsoleted by RFC 5305) -- Possible downref: Non-RFC (?) normative reference: ref. 'LSP-HIERARCHY' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRANKBACK' -- Possible downref: Non-RFC (?) normative reference: ref. 'LSP-ATTRIBUTES' -- Possible downref: Non-RFC (?) normative reference: ref. 'FAST-REROUTE' -- Possible downref: Non-RFC (?) normative reference: ref. 'NODE-ID' -- Possible downref: Non-RFC (?) normative reference: ref. 'E2E-RECOVERY' Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Internet Draft Arthi Ayyangar(Editor) 2 Proposed Status: Standards Track Juniper Networks 3 Expires: April 2005 4 Jean-Philippe Vasseur(Editor) 5 Cisco Systems, Inc. 7 October 2004 9 Inter domain GMPLS Traffic Engineering - RSVP-TE extensions 11 draft-ayyangar-ccamp-inter-domain-rsvp-te-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions of 16 section 3 of RFC 3667. By submitting this Internet-Draft, each author 17 represents that any applicable patent or other IPR claims of which he or 18 she is aware have been or will be disclosed, and any of which he or she 19 become aware will be disclosed, in accordance with RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other groups 23 may also distribute working documents as Internet-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 material 28 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 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document describes extensions to Generalized Multi-Protocol Label 43 Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering 44 (RSVP-TE) signaling required to support mechanisms for the establishment 45 and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths 46 (LSPs), both packet and non-packet, that traverse multiple domains. For 47 the purpose of this document, a domain is considered to be any 48 collection of network elements within a common realm of address space or 49 path computation responsibility. Examples of such domains include 50 Autonomous Systems, IGP areas and GMPLS overlay networks. 52 1. Introduction 54 The requirements for inter-area and inter-AS MPLS Traffic Engineering 55 have been developed by the Traffic Engineering Working Group and have 56 been stated in [INTER-AREA-TE-REQS] and [INTER-AS-TE-REQS] 57 respectively. Many of these requirements also apply to GMPLS 58 networks. The framework for inter-domain GMPLS Traffic Engineering 59 has been provided in [INTER-DOMAIN-FRAMEWORK]. 61 This document presents the RSVP-TE signaling extensions for the setup 62 and maintenance of TE LSPs that span multiple domains. The signaling 63 procedures described in this document are applicable to both packet 64 LSPs ([RSVP-TE]) and non-packet LSPs that use RSVP-TE GMPLS 65 extensions as described in [RSVP-GMPLS]. Three different signaling 66 methods along with the corresponding RSVP-TE extensions and 67 procedures are proposed in this document. 69 For the purpose of this document, a domain is considered to be any 70 collection of network elements within a common realm of address space 71 or path computation responsibility. Examples of such domains include 72 Autonomous Systems, IGP areas and GMPLS overlay networks ([GMPLS- 73 OVERLAY]). 75 1.1. Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [RFC2119]. 81 1.2. Terminology 83 ASBR: routers used to connect together ASes of a different or the 84 same Service Provider via one or more Inter-AS links. 86 Bypass Tunnel: an LSP that is used to protect a set of LSPs passing 87 over a common facility. 89 ERO: Explicit Route Object 91 FA: Forwarding Adjacency 93 FA-LSP: Forwarding Adjacency LSP 95 LSP: MPLS Label Switched Path 96 MP: Merge Point. The node where bypass tunnels meet the protected 97 LSP. 99 NHOP bypass tunnel: Next-Hop Bypass Tunnel. A backup tunnel, which 100 bypasses a single link of the protected LSP. 102 NNHOP bypass tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel, 103 which bypasses a single node of the protected LSP. 105 PLR: Point of Local Repair. The head-end of a bypass tunnel. 107 Protected LSP: an LSP is said to be protected at a given hop if it 108 has one or multiple associated backup tunnels originating at that 109 hop. 111 RRO - Record Route Object 113 TE: Traffic Engineering 115 TE LSP: Traffic Engineering Label Switched Path 117 TE-link: Traffic Engineering link 119 TED: MPLS Traffic Engineering Database 121 2. Signaling overview 123 The RSVP-TE signaling of a TE LSP within a single domain is described 124 in [RSVP-TE] and [RSVP-GMPLS]. This document focuses on the RSVP-TE 125 signaling extensions required for inter-domain TE LSP setup and 126 maintenance. Any other extensions that may be needed for routing or 127 path computation are outside the scope of this document. 129 2.1. Signaling options 131 There are three ways in which an RSVP-TE LSP could be signaled across 132 multiple domains: 134 Contiguous - A contiguous TE LSP is a single end-to-end TE LSP that 135 is setup across multiple domains using RSVP-TE signaling procedures 136 described in [RSVP-TE]and [RSVP-GMPLS]. No additional TE LSPs are 137 required to signal a contiguous TE LSP and the same RSVP-TE 138 information for the TE LSP is maintained along the entire LSP path. 140 Nesting - Nesting one or more TE LSPs into another TE LSP is 141 described in [LSP-HIERARCHY]. This technique can also be used to nest 142 one or more inter-domain TE LSPs into an intra-domain FA-LSP. While 143 similar to stitching in the control plane, in the data plane, nesting 144 allows for one or more inter-domain LSPs to be transported over a 145 single intra-domain FA-LSP using the label stacking construct. 147 Stitching - A stitched TE LSP is a TE LSP made up of different TE LSP 148 segments within each domain which are "stitched" together in the data 149 plane so that an end-to-end LSP is achieved in the data plane. In the 150 control plane, however, the different LSP segments are signaled as 151 distinct RSVP sessions which are independent from the RSVP session 152 for the inter-domain LSP. Signaling procedures described in [LSP- 153 HIERARCHY] are used to stitch an inter-domain TE LSP to a local LSP 154 segment. The concept of LSP stitching and additional signaling 155 extensions needed are described in detail in the following section. 157 On receipt of an LSP setup request for an inter-domain TE LSP, the 158 decision of whether to signal the LSP contiguously or whether to nest 159 or stitch it to another TE LSP, depends on the signaled TE LSP 160 characteristics or the local node configuration, when not explicitly 161 signaled. Also, the TE LSP segment or FA-LSP within the domain may 162 either be pre-configured or signaled dynamically based on the arrival 163 of the inter-domain TE LSP setup request. 165 3. LSP Stitching 167 LSP stitching is a special case of LSP hierarchy ([LSP-HIERARCHY]) 168 where the desired switching type of the LSP and the switching 169 capability of the LSP segment are such that exactly one LSP may be 170 admitted into an LSP segment. E.g. an inter-domain lambda LSP may be 171 stitched into an intra-domain lambda LSP, an MPLS LSP (PSC) can be 172 stitched into another MPLS LSP (PSC). The following sections analyze 173 the similarities and differences of various aspects associated with 174 nesting and stitching and describe additional signaling extensions 175 required for LSP stitching. 177 3.1. Routing aspects 179 An LSP segment is similar to an FA-LSP in that an LSP segment like an 180 FA-LSP is created and treated like a Traffic Engineering link (TE- 181 link) between two GMPLS nodes whose path transits zero or more GMPLS 182 nodes in the same instance of the GMPLS control plane. These TE-links 183 may be numbered or unnumbered. For an unnumbered LSP segment, the 184 assignment and handling of the local and remote link identifiers is 185 specified in [RSVP-UNNUM]. Like in the case of Forwarding Adjacency 186 (FA), a routing adjacency will not usually be established over an LSP 187 segment. ISIS/OSPF would, however, flood the TE information 188 associated with an LSP segment which will exist in the TE database 189 (TED) and can be used for path computation. The TE parameters defined 190 for an FA in [LSP-HIERARCHY] are also applicable to an LSP segment 191 TE-link. 193 Note that, while an FA-LSP TE-link can admit one or more LSPs over 194 it, an LSP segment can admit exactly one LSP over it. So, once an LSP 195 is stitched into an LSP segment, the Unreserved bandwidth on the LSP 196 segment is set to and advertised to be zero. This prevents any more 197 LSPs from being computed and admitted over the LSP segment TE-link. 198 Multiple LSP segments between the same pair of nodes may be bundled 199 using the concept of Link Bundling ([BUNDLING]) into a single TE- 200 link. When any component LSP segment is allocated for an LSP, its 201 Unreserved bandwidth MUST be set to zero and the Minimum and Maximum 202 LSP bandwidth of the TE-link SHOULD be recalculated. 204 3.2. Signaling aspects 206 Like any TE-link or FA, a signaling adjacency would be established 207 between the end nodes of the LSP segment and this will be used to 208 signal an LSP over the LSP segment. When an RSVP-TE LSP is signaled 209 over an LSP segment, the Path message MUST contain an IF_ID RSVP_HOP 210 object [RSVP-GMPLS] and the data interface identification MUST 211 identify the LSP segment. For the purpose of ERO and RRO as well, an 212 LSP segment is treated exactly like an FA. 214 The main difference between signaling an LSP over an LSP segment 215 instead of over an FA-LSP is that no Labels are allocated and 216 exchanged for the end-to-end LSP (inter-domain LSP) over the LSP 217 segment hop. So, exactly one end-to-end LSP is associated with one 218 LSP segment. If a node at the head-end of an LSP segment receives a 219 Path Msg for an LSP that identifies the LSP segment in the ERO and 220 the LSP segment bandwidth has already been allocated to some other 221 LSP, then regular rules of RSVP-TE pre-emption apply. If the LSP 222 request over the LSP segment cannot be satisfied, then the node 223 SHOULD send back a PathErr with the error codes as described in 224 [RSVP-TE]. 226 Additional signaling extensions for stitching are described in the 227 next section. 229 3.3. RSVP-TE signaling extensions 231 The signaling extensions described here MUST be used if a packet LSP 232 is being stitched to another packet LSP. These extensions are 233 optional for non-packet LSPs and SHOULD be used if no other local 234 mechanisms exist to automatically detect a requirement for stitching 235 at both the ingress and egress nodes of the LSP segment. Also, these 236 extensions are applicable to the local LSP segment and not for the 237 inter-domain TE LSP. 239 If a domain boundary node (or any other node) desires to perform LSP 240 stitching of an LSP, then it MUST indicate this in the Path message 241 for the intra-domain LSP segment. This signaling explicitly informs 242 the egress node for the LSP segment that the ingress node is planning 243 to perform stitching over the LSP segment. This will allow the egress 244 of the LSP segment to allocate the correct label(s) as explained 245 below. Also, so that the head-end node can ensure that correct 246 stitching actions were carried out at the egress node, a new flag is 247 defined below in the RRO subobject to indicate that the LSP segment 248 can be used for stitching. 250 In order to request LSP stitching on the LSP segment, we define a new 251 flag bit in the Attributes Flags TLV of the LSP_ATTRIBUTES object 252 defined in [LSP-ATTRIBUTES]: 254 0x02 (TBD): LSP stitching desired bit - This flag will be set in the 255 Attributes Flags TLV of the LSP_ATTRIBUTES object in the Path message 256 for the local intra-domain LSP segment by the head-end node of the 257 LSP segment (boundary node) that desires LSP stitching. This flag 258 MUST not be modified by any other nodes in that domain. 260 An intra-domain LSP segment can only be used for stitching if 261 appropriate label actions were carried out at the egress node of the 262 LSP segment. In order to indicate this to the head-end node of the 263 LSP segment, the following new flag bit is defined in the RRO 264 Attributes sub-object: 0x02 (TBD): LSP segment stitching ready. 266 If an egress node receiving a Path message, supports the 267 LSP_ATTRIBUTES object and the Attributes Flags TLV, and also 268 recognizes the "LSP stitching desired" flag bit, but cannot support 269 the requested stitching behavior, then it MUST send back a PathErr 270 message with an error code of "Routing Problem" and an error sub- 271 code=16 (TBD) "Stitching unsupported" to the head-end node of the 272 intra-domain LSP segment. 274 If an egress node receiving a Path message with the "LSP stitching 275 desired" flag set, recognizes the object, the TLV and the flag and 276 also supports the desired stitching behavior, then it MUST allocate a 277 non-NULL label for that LSP segment in the corresponding Resv 278 message. Now, so that the head-end node can ensure that the correct 279 label actions will be carried out by the egress node and that the LSP 280 segment can be used for stitching, the egress node MUST set the "LSP 281 segment stitching ready" bit defined in the RRO Attribute sub-object. 282 Also, when the egress node for the LSP segment receives a Path 283 message for an inter-domain LSP using this LSP segment, it SHOULD 284 first check if it is also the egress for the inter-domain TE LSP. If 285 the egress node is the egress for both the intra-domain LSP segment 286 as well as the inter-domain TE LSP, and this is a packet LSP which 287 requires Penultimate Hop Popping (PHP), then the node MUST send back 288 a Resv refresh for the intra-domain LSP segment with a new label 289 corresponding to the NULL label. 291 Finally, if the egress node for the intra-domain LSP segment supports 292 the LSP_ATTRIBUTES object but does not recognize the Attributes Flags 293 TLV, or supports the TLV as well but does not recognize this 294 particular flag bit, then it SHOULD simply ignore the above request. 296 An ingress node requesting stitching MUST examine the RRO Attributes 297 sub-object flag corresponding to the egress node for the intra-domain 298 LSP segment, to make sure that stitching actions were carried out at 299 the egress node. It MUST NOT use the LSP segment for stitching if the 300 "LSP segment stitching ready" flag is cleared. 302 The egress node MUST not allocate any Label in the Resv message for 303 the inter-domain TE LSP. Similarly, in case of bidirectional inter- 304 domain TE LSP, no Upstream Label is allocated over the LSP segment in 305 the corresponding Path message. An ingress node stitching an inter- 306 domain LSP to an LSP segment MUST ignore any Label object received in 307 the Resv for the inter-domain TE LSP. 309 4. Procedures on the domain boundary node 311 Whether an inter-domain TE LSP is contiguous, nested or stitched is 312 determined mostly by the signaling method supported by or configured 313 on the intermediate nodes, usually the domain boundary nodes that the 314 inter-domain TE LSP traverses through. It may also depend on certain 315 parameters signaled by the head-end node for the inter-domain TE LSP. 316 When a domain boundary node receives the RSVP Path message for an 317 inter-domain TE LSP setup, it MUST carry out the following procedures 318 before it can forward the Path message to the next hop node, 319 - apply any locally configured policies 320 - determine the signaling method to be used based on any desired 321 characteristics signaled by the head-end node of the inter-domain TE 322 LSP or if the signaling method is not explicitly signaled, then 323 determine the signaling method based on local configuration and 324 policies 325 - depending on the signaling method, carry out any specific ERO 326 procedures, as applicable, as described in the next section 327 - based on the signaling method to be used, determine the next 328 hop node to forward the RSVP Path message 329 - in case of nesting or stitching, either find an existing intra- 330 domain TE LSP to carry the inter-domain TE LSP or signal a new one, 331 depending on local policy 332 - perform any path computations if required. The path computation 334 procedure itself is outside the scope of this document. The various 335 path computation options are addressed in [INTER-DOMAIN-PATH-COMP] 336 - in case of any failures (admission control, policy, signaling; 337 etc), originate corresponding error notifications 339 4.1. Rules on ERO processing 341 The ERO that a domain boundary node receives in the Path message for 342 an inter-domain TE LSP will be dependent on several factors such as 343 the level of visibility that the head-end node of the inter-domain TE 344 LSP has into other domains, the path computation techniques applied 345 at the head-end node, policy agreements between two domains; etc. 346 Eventually, when the ERO reaches a domain boundary node, the 347 following rules SHOULD be used for ERO processing and signaling. 348 Within a domain, there may be no FA-LSPs or LSP segments. If they are 349 present, then they may originate and terminate on domain boundary 350 nodes. There could also be FA-LSPs and LSP segments that may 351 originate and terminate at other nodes in the domain. In general, 352 these ERO processing rules are also applicable to non-boundary nodes 353 that may participate in signaling the inter-domain TE LSP. 354 - If there are any policies related to ERO processing for 355 certain LSPs, they SHOULD be applied and corresponding actions should 356 be taken. E.g. if there exists a policy to reject LSP setup request 357 containing ERO with sub-objects identifying nodes within the domain, 358 then a PathErr with the appropriate error code should be sent back 359 - Section 8.2 of [LSP-HIERARCHY] describes how a node at the 360 edge of a region (domain) processes the ERO in the incoming Path 361 message and uses this ERO, to either find an existing FA-LSP or 362 signal a new FA-LSP using the ERO hops. This also includes adjusting 363 the ERO before sending the Path message to the next hop node. These 364 procedures SHOULD also be followed for nesting or stitching of inter- 365 domain TE LSPs to FA-LSPs or LSP segments respectively. While the 366 domain boundaries are tied to link switching capabilities in [LSP- 367 HIERARCHY], these procedures are also applicable to other domain 368 boundary nodes in the context of this document. E.g. in case of a 369 path computation domain, you have reached the boundary when the ERO 370 hop is no longer reachable via the TE database (TED). 371 - In case of any failure in processing the ERO hop(s), a Path 372 Error message with appropriate error code ([RSVP-TE]) SHOULD be 373 generated. 375 4.2. LSP setup failure and crankback 377 In case of any setup failures along the path due to policy or 378 admission control or other reasons, a corresponding Path Error SHOULD 379 be generated and sent upstream. The propagation of Path Error 380 upstream may be limited to within the domain or it may be sent all 381 the way upstream to the head-end node of the inter-domain TE LSP. 383 This depends not only on local configuration and ability of a 384 boundary node to do local crankback, but also on any specific 385 parameters requested by the head-end node itself for that LSP. In 386 certain cases, it may be desirable for the head-end node to exert 387 some control on the ability for the boundary nodes to make use of 388 crankback. See [CRANKBACK] for the definition of those bits. When 389 crankback is allowed, the domain boundary node can either decide to 390 forward the Path Error message upstream to the head-end node of the 391 inter-domain TE LSP or try to select another egress boundary node. 392 When crankback is not allowed or if the node has not been configured 393 to do a crankback, then a boundary node, when receiving a Path Error 394 message from a downstream boundary node MUST propagate the Path Error 395 message up to the head-end node of the inter-domain TE LSP. 397 5. RSVP-TE signaling extensions 399 The following RSVP-TE signaling extensions are introduced in this 400 document. 402 5.1. Control of downstream choice of signaling method 404 In certain mixed environments with different techniques (contiguous, 405 stitched or nested TE LSPs), a head-end node of the inter-domain TE 406 LSP may wish to signal its requirement regarding the signaling method 407 used at the domain boundaries. 409 [LSP-ATTRIBUTES] defines the format of the Attributes Flags TLV 410 included in the LSP_ATTRIBUTES object carried in an RSVP Path 411 message. The following bit in the Flags TLV is used by the head-end 412 node of the inter-domain TE LSP to restrict the signaling method used 413 by the domain boundary nodes to be contiguous. 415 0x01 (TBD): Contiguous LSP bit - this flag is set by the head-end 416 node that originates the inter-domain TE LSP if it desires a 417 contiguous end-to-end TE LSP (in the control & data plane). When set, 418 this indicates that a boundary node MUST not perform any stitching or 419 nesting on the TE LSP and the TE LSP MUST be routed as any other TE 420 LSP (it must be contiguous end to end). When this bit is cleared, a 421 boundary node may decide to perform stitching or nesting. A mid-point 422 node not supporting contiguous TE LSP MUST send a Path Error message 423 upstream with an error code of "Routing Problem" and error sub- 424 code=17 (TBD) (Contiguous LSP type not supported). This bit MUST not 425 be modified by any downstream node. 427 5.2. LSP stitching 429 RSVP-TE signaling extensions for LSP stitching have been described in 430 section 3. A new flag bit, "LSP stitching desired bit" is defined in 431 the Attributes Flags TLV of the LSP_ATTRIBUTES object defined in 432 [LSP-ATTRIBUTES], to request stitching over the LSP segment. 434 6. Example 436 6.1. Example topology 438 In this document, we will consider the following example topology for 439 inter-domain TE LSPs setup and maintenance. In this example, a domain 440 is an Autonomous system (AS). 442 <-- AS-1 ---> <--- AS-2 ---> <-- AS-3 --> 444 <---BGP---> <---BGP--> 445 CE1---R0----X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 446 | | | | / | / | / | | | 447 | | +-ASBR2----/ ASBR5 | / | | | 448 | | | | | / | | | 449 R1--R2----ASBR3------ASBR6--R4---ASBR8----ASBR10----R7---CE2 451 <================ Inter-AS TE LSP ================> 453 6.1.1. Assumptions 455 - Three interconnected ASes, respectively AS1, AS2, and AS3. Note 456 that AS3 might be AS1 in some scenarios described in [INTER-AS-TE- 457 REQS]. 459 - The various ASBRs are BGP peers, without any IGP running on the 460 single hop link interconnecting the ASBRs 462 - Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE 463 extensions (see [OSPF-TE] and [ISIS-TE]). In other words, the ASes 464 are TE enabled. Note that each AS can run a different IGP. 466 - Each AS can be made of several areas. In this case, the TE LSP will 467 rely on the inter-area TE techniques to compute and set up a TE LSP 468 traversing multiple IGP areas. For the sake of simplicity, each 469 routing domain will be considered as single area in this document, 470 but the solutions described in this document does not prevent the use 471 of multi-area techniques. In fact, these inter-domain solutions are 472 equally applicable to inter-area TE. 474 - A protected inter-AS TE LSP T1 originated at R0 in AS1 and 475 terminating at R6 in AS3 with following possible paths: 477 LSP hops: R0-X1-ASBR1-ASBR4-R3-ASBR7-ASBR9-R6 479 o p1 - a set of loose node hops crossing AS-2 480 R0-X1-ASBR1(loose)-ASBR4(loose)-ASBR7(loose)-ASBR9(loose)-R6 482 o p2 - a set of strict interface hops crossing AS-2 483 R0-X1-ASBR1(loose)-link[ASBR1-ASBR4](strict)-link[ASBR4-R3](strict) 484 -link[R3-ASBR7](strict)-link[ASBR7-ASBR9](strict)-R6 486 - A set of backup tunnels: 488 o B1 from ASBR1 to ASBR4 following the path ASBR1-ASBR2-ASBR4 and 489 protecting against a failure of the ASBR1-ASBR4 link 491 o B2 from ASBR1 to R3 following the path 492 ASBR1-ASBR2-ASBR3-ASBR6-ASBR5-R3 and protecting against a failure of 493 the ASBR4 node. 495 o B3 from ASBR1 to ASBR7 following the path 496 ASBR1-ASBR2-ASBR3-ASBR6-ASBR7 and protecting against a failure of the 497 ASBR4 node. 499 o B4 from R3 to ASBR9 following the path R3-R4-ASBR8-ASBR10-ASBR9 and 500 protecting against a failure of the ASBR7 node. 502 o B5 from ASBR4 to ASBR9 following the path ASBR4-ASBR8-ASBR10-ASBR9 503 and protecting against a failure of the ASBR7 node. 505 6.2. Setup Operation 507 Let us consider an inter-AS TE LSP setup from R0 to R6, with example 508 paths p1, p2 each. In this example, we will examine the behavior on 509 node ASBR4 which is the boundary node for AS-2, for the different 510 signaling methods. 512 Contiguous:- 514 The head-end node, R0, that desires to setup an end-to-end contiguous 515 TE LSP, MAY originate a Path message with LSP_ATTRIBUTES object with 516 the "Contiguous LSP" bit set in the Attributes Flags TLV. 518 For path p1, additional computation to expand the loose hops may be 519 required at various hops along the LSP path. When the Path message 520 arrives at ASBR4, it may carry out a path computation or use some 521 other means to find the intermediate hops to reach ASBR7. It may then 522 adjust the outgoing ERO and forward the Path message through the 523 intermediate hops in AS-2 to ASBR7. 525 For path p2, the ERO next hop points to a node within the domain. 526 ASBR4 may then directly forward the Path message to the next hop in 527 the ERO. 529 Nesting and Stitching:- 531 When the Path message for the inter-AS TE LSP from R0 to R6, reaches 532 ASBR4, ASBR4 SHOULD first determine from the ERO hops, the boundary 533 node to the domain along the path. In this example, the domain 534 boundary node for all paths is ASBR7. It SHOULD then use the ERO hops 535 upto ASBR7 to find an existing FA-LSP in case of nesting or LSP 536 segment in case of stitching, that satisfies the TE constraints. If 537 there are no existing FA-LSPs or LSP segments and ASBR4 is capable of 538 seting up the FA-LSP or LSP segment on demand, it SHOULD do so using 539 the ERO hops in the Path message of the inter-domain TE LSP. In 540 either case, ASBR4 will adjust the ERO in the inter-domain TE LSP and 541 will forward the Path message directly to the end-point of the FA-LSP 542 or LSP segment using the procedures described in [LSP-HIERARCHY]. 544 In case of path p1, since there are no ERO hops between ASBR4 and 545 ASBR7, and ASBR7 hop is loose, ASBR4 may select any existing FA-LSP 546 (nesting) or LSP segment (stitching) that satisfies the constraints 547 or it may compute a path for the FA-LSP or LSP segment upto ASBR7 or 548 some other intermediate node in AS-2. 550 In case of path p2, ASBR4 may either select an existing FA-LSP or LSP 551 segment with ERO hops link[ASBR4-R3](strict)-link[R3-ASBR7](strict) 552 or it may compute a new path for the FA-LSP or LSP segment using the 553 above hops. In either case, the ERO hops for the FA-LSP or LSP 554 segment MUST be the same as the signaled strict hops in that domain. 556 Now, suppose, we have a path p3, as a set of strict node hops 557 crossing AS-2 as defined below, 559 R0-X1-ASBR1(loose)-ASBR4(strict)-ASBR7(strict)-ASBR9(loose)-R6 561 In this case, the ERO nexthop at ASBR4 is ASBR7(strict). In this 562 case, ASBR4 will try to find or compute a FA-LSP or LSP segment 563 directly to ASBR7. 565 The main difference between processing of p1 and p3 for nesting or 566 stitching is that in case of p1, since the ERO nexthop is a loose 567 hop, ASBR4 need not find a FA-LSP or LSP segment directly from ASBR4 568 to ASBR7. So, there could be multiple FA-LSPs or LSP segments between 569 ASBR4 and ASBR7. On the other hand, for path p3, since ASBR7 is a 570 strict hop, ASBR4 MUST find or signal a FA-LSP or LSP segment that 571 connects ASBR4 and ASBR7. 573 7. Protection and recovery of inter-domain TE LSPs 575 7.1. Fast Recovery support using MPLS TE Fast Reroute 577 [FAST-REROUTE] describes two methods for local protection for a 578 packet TE LSP in case of link, SRLG or node failure. This section 579 describes how these mechanisms work with the proposed signaling 580 solutions for inter-domain TE LSP setup. 582 7.1.1. Failure within a domain (link or node failure) 584 The mode of operation of MPLS TE Fast Reroute to protect a 585 contiguous, stitched or nested TE LSP within a domain is identical to 586 the existing procedures described in [FAST-REROUTE]. In case of 587 nested or stitched inter-domain TE LSPs, protecting the intra-domain 588 TE FA-LSP or LSP segment will automatically protect the traffic on 589 the inter-domain TE LSP. No new extensions are required for any of 590 the signaling methods. 592 7.1.2. Failure of link at domain boundaries 594 The procedures for doing link protection of the link at domain 595 boundaries is the same for contiguous, nested and stitched TE LSPs. 597 To protect an inter-domain link with MPLS TE Fast Reroute, a set of 598 backup tunnels must be configured or dynamically computed between the 599 two domain boundary nodes diversely routed from the protected inter- 600 domain link. The region connecting two domains may not be TE enabled. 601 In this case, an implementation will have to support the set up of TE 602 LSP over a non-TE enabled region. 604 For each protected inter-domain TE LSP traversing the protected link, 605 a NHOP backup must be selected by a PLR (i.e domain exit boundary 606 router), when the TE LSP is first set up. This requires for the PLR 607 to select a bypass tunnel terminating at the NHOP. Finding the NHOP 608 bypass tunnel of an inter-AS LSP can be achieved by analyzing the 609 content of the RRO object received in the RSVP Resv message of both 610 the bypass tunnel and the protected TE LSP(s). As defined in [RSVP- 611 TE], the addresses specified in the RRO IPv4 subobjects can be node- 612 ids and/or interface addresses (with specific recommendation to use 613 the interface address of the outgoing Path messages). The PLR may or 614 may not have sufficient topology information to find where the backup 615 tunnel intersects the protected TE LSP based on the RRO. [NODE-ID] 616 proposes a solution to this issue, defining an additional RRO IPv4 617 suboject that specifies a node-id address. 619 Example: The ASBR1-ASBR4 link is protected by the backup tunnel B1 620 that follows the ASBR1-ASBR2-ASBR4 path 622 7.1.3. Failure of a boundary node 624 For each protected inter-domain TE LSP traversing the boundary node 625 to be protected, a NNHOP backup must be selected by the PLR. This 626 requires the PLR to setup a bypass tunnel terminating at the NNHOP. 627 Finding the NNHOP bypass tunnel of an inter-domain TE LSP can be 628 achieved by analyzing the content of the RRO object received in the 629 RSVP Resv message of both the bypass tunnel and the protected TE 630 LSP(s) (see [NODE-ID]). The main difference with node protection, 631 between a protected contiguous inter-domain TE LSP and a protected 632 nested or stitched inter-domain TE LSP is that the PLR and NNHOP (MP) 633 in case of a contiguous TE-LSP could be any node within the domain. 634 However, in case of a nested or stitched TE-LSP the PLR and MP can 635 only be the end-points of the FA-LSP or LSP segment. The consequence 636 is that the backup path is likely to be longer and if bandwidth 637 protection is desired, for instance, ([FAST-REROUTE]) more resources 638 may be reserved in the domain than necessary. 640 Let us again consider the example topology of section 4.1. The 641 protected inter-domain TE LSP is an inter-AS TE LSP from R0 to R6 642 with path p1. Also, for nesting or stitching, let us assume that the 643 end-points of the FA-LSP or LSP segment in AS-2 are ASBR4 and ASBR7. 644 This gives rise to the following two scenarios for node protection: 646 Protecting the boundary node at the entry to a domain :- 648 Example: protecting against the failure of ASBR4 650 If the inter-AS TE LSP in this example, is a contiguous LSP, then the 651 PLR is ASBR1 and the NNHOP (MP) could be R3 or any other intermediate 652 node along the LSP path. A backup tunnel B2 may be used to protect 653 the inter-AS TE LSP against failure of ASBR4. 655 If the inter-AS TE LSP in this example, is nested or sticthed at 656 ASBR4 into an intra-domain TE FA-LSP or LSP segment between ASBR4 and 657 ASBR7, then the PLR is ASBR1 and the NNHOP (MP) is ASBR7. A backup 658 tunnel B3 may be used to protect the inter-AS TE LSP against failure 659 of ASBR4. 661 Protecting the boundary node at the exit of a domain :- 663 Example: protecting against failure of ASBR7. 665 If the inter-AS TE LSP in this example, is a contiguous LSP, then the 666 PLR could be R3 and the NNHOP (MP) is ASBR9. A backup tunnel B4 may 667 be used to protect the inter-AS TE LSP against failure of ASBR7. 669 If the inter-AS TE LSP in this example, is nested or sticthed at 670 ASBR4 into an intra-domain TE FA-LSP or LSP segment between ASBR4 and 671 ASBR7, then the PLR is ASBR4 and the NNHOP (MP) is ASBR9. A backup 672 tunnel B5 may be used to protect the inter-AS TE LSP against failure 673 of ASBR7. 675 7.2. Protection and recovery of GMPLS LSPs 677 [E2E-RECOVERY] describes the signaling extensions to support end-to- 678 end GMPLS LSP recovery. Signaling methods defined above for inter- 679 domain RSVP-TE LSPs also apply to recovery LSPs signaled for end-to- 680 end protection of inter-domain GMPLS LSPs. Any other protection 681 mechanisms that are developed for GMPLS LSPs SHOULD also take into 682 account inter-domain considerations. 684 8. Re-optimization of inter-domain TE LSPs 686 Re-optimization of a TE LSP is the process of moving the LSP from the 687 current path to a more prefered path. This usually involves 688 computation of the new prefered path and make-before-break signaling 689 procedures [RSVP-TE], to minimize traffic disruption. The path 690 computation procedures involved in re-optimization of an inter-domain 691 TE LSP are covered in [INTER-DOMAIN-PATH-COMP]. 693 In the context of an inter-domain TE LSP, since the LSP traverses 694 multiple domains, re-optimization may be required in one or more 695 domains at a time. Again, depending on the nature of the LSP and/or 696 policies and configuration at domain boundaries (or other nodes), one 697 may either always want the head-end node of the inter-domain TE LSP 698 to be notified of any local need for re-optimizations and let the 699 head-end initiate the make-before-break process or one may want to 700 restrict local re-optimizations with the domain. 702 [LOOSE-REOPT] describes mechanisms that allow, 703 - The head-end node to trigger on every node whose next hop 704 is a loose hop the re-evaluation of the current path in order to 705 detect a potentially more optimal path. This is done via explicit 706 signaling request: the head-end node sets the "ERO Expansion request" 707 bit of the SESSION-ATTRIBUTE object carried in the RSVP Path message. 708 - A node whose next hop is a loose-hop to signal to the head- 709 end node that a better path exists. This is performed by sending an 710 RSVP Path Error Notify message (ERROR-CODE = 25), sub-code 6 (Better 711 path exists). This indication may either be sent in response to a 712 query sent by the head-end node or spontaneously by any node having 713 detected a more optimal path. 715 The above mechanisms SHOULD be used for a contiguous inter-domain TE 716 LSP to allow the head-end node of the inter-domain TE LSP to initiate 717 make-before-break procedures. For nested or stitched TE LSPs, it is 718 possible to re-optimize the local FA-LSP or LSP segment without 719 involving the head-end node of the inter-domain TE LSP. This will 720 automatically re-route the traffic for the inter-domain TE LSP along 721 the new path, within the domain. Such local re-optimizations, 722 including parameters for re-optimization can be controlled by local 723 policy or configuration in that domain. 725 9. Security Considerations 727 When signaling an inter-domain RSVP-TE LSP, an operator may make use 728 of the already defined security features related to RSVP-TE 729 (authentication). This may require some coordination between the 730 domains to share the keys (see RFC 2747 and RFC 3097). 732 10. IANA Considerations 734 The following values have to be defined by IANA for this document. 735 The registry is, http://www.iana.org/assignments/rsvp-parameters. 737 10.1. Attribute Flags for LSP_ATTRIBUTES object 739 The following two new flag bits are being defined for the Attributes 740 Flags TLV in the LSP_ATTRIBUTES object. The numeric values should be 741 assigned by IANA. 743 Contiguous LSP bit - 0x01 (Suggested value) 745 LSP stitching desired bit - 0x02 (Suggested value) 747 Both these flag bits are only to be used in the Attributes Flags TLV 748 on a Path message. 750 The 'LSP stitching desired bit' has a corresponding 'LSP segment 751 stitching ready' bit to be used in the RRO Attributes sub-object. 753 10.2. New Error Codes 755 The following two new error sub-codes are being defined under the 756 RSVP error-code "Routing Problem" (24). The numeric error sub-code 757 values should be assigned by IANA. 759 Contiguous LSP type not supported - sub-code 17 (Suggested value) 761 Stitching unsupported - sub-code 16 (Suggested value) 763 These error codes are to be used only in a RSVP PathErr. 765 11. Acknowledgements 767 The authors would like to acknowledge the input and helpful comments 768 from Adrian Farrel on various aspects discussed in the document. 770 12. References 772 12.1. Normative References 774 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 775 Extensions to OSPF", RFC 3630 (Updates RFC 2370), September 2003. 777 [ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic 778 Engineering", RFC 3784 780 [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 781 3209, December 2001. 783 [RSVP-GMPLS] L. Berger, et al, "Generalized Multi-Protocol Label 784 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 785 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 787 [LSP-HIERARCHY] Kompella K., Rekhter Y., "LSP Hierarchy with 788 Generalized MPLS TE", (work in progress). 790 [CRANKBACK] Farrel A. et al, "Crankback Signaling Extensions for MPLS 791 Signaling", (work in progress). 793 [LSP-ATTRIBUTES] Farrel A. et al, "Encoding of Attributes for 794 Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) 795 Establishment Using RSVP-TE", (work in progress). 797 [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE 798 for LSP Tunnels", (work in progress) 800 [NODE-ID] Vasseur, Ali and Sivabalan, "Definition of an RRO node-id 801 subobject", (work in progress). 803 [E2E-RECOVERY] J.P. Lang et al, "RSVP-TE Extensions in support of 804 End-to-End GMPLS-based Recovery", (work in progress). 806 12.2. Informative References 808 [INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering 809 requirements", (work in progress). 811 [INTER-AREA-TE-REQS] LeRoux JL, Vasseur JP, Boyle J. et al, 812 "Requirements for support of Inter-Area MPLS Traffic Engineering", 813 (work in progress). 815 [INTER-DOMAIN-FRAMEWORK] Farrel A. et al, "A Framework for Inter- 816 Domain MPLS Traffic Engineering", (work in progress). 818 [INTER-DOMAIN-PATH-COMP] Vasseur JP., Ayyangar A., Zhang R., "Inter- 819 domain MPLS Traffic Engineering LSP path computation methods", (work 820 in progress). 822 [GMPLS-OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay 823 Model", (work in progress). 825 [RSVP-UNNUM] Kompella K., Rekhter Y., "Signalling Unnumbered Links in 826 Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 827 3477, January 2003. 829 [BUNDLING] Kompella K., Rekhter Y., "Link Bundling in MPLS Traffic 830 Engineering", (work in progress). 832 [LOOSE-REOPT] Vasseur JP. et al, "Reoptimization of an explicit 833 loosely routed MPLS TE paths", (work in progress). 835 Author's addresses 836 Arthi Ayyangar 837 Juniper Networks, Inc. 838 1194 N.Mathilda Ave 839 Sunnyvale, CA 94089 840 USA 841 e-mail: arthi@juniper.net 843 Jean Philippe Vasseur 844 Cisco Systems, Inc. 845 300 Beaver Brook Road 846 Boxborough , MA - 01719 847 USA 848 e-mail: jpv@cisco.com 850 Intellectual Property Statement 852 The IETF takes no position regarding the validity or scope of any 853 Intellectual Property Rights or other rights that might be claimed to 854 pertain to the implementation or use of the technology described in 855 this document or the extent to which any license under such rights 856 might or might not be available; nor does it represent that it has 857 made any independent effort to identify any such rights. Information 858 on the procedures with respect to rights in RFC documents can be 859 found in BCP 78 and BCP 79. 861 Copies of IPR disclosures made to the IETF Secretariat and any 862 assurances of licenses to be made available, or the result of an 863 attempt made to obtain a general license or permission for the use of 864 such proprietary rights by implementers or users of this 865 specification can be obtained from the IETF on-line IPR repository at 866 http://www.ietf.org/ipr. 868 The IETF invites any interested party to bring to its attention any 869 copyrights, patents or patent applications, or other proprietary 870 rights that may cover technology that may be required to implement 871 this standard. Please address the information to the IETF at ietf- 872 ipr@ietf.org. 874 Disclaimer of Validity 876 This document and the information contained herein are provided on an 877 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 878 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 879 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 880 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 881 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 882 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 884 Copyright Statement 886 Copyright (C) The Internet Society (2004). This document is subject 887 to the rights, licenses and restrictions contained in BCP 78, and 888 except as set forth therein, the authors retain all their rights. 890 Acknowledgment 892 Funding for the RFC Editor function is currently provided by the 893 Internet Society.