idnits 2.17.1 draft-ayyangar-ccamp-inter-domain-rsvp-te-02.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 760. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 737. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 744. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 750. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 766), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** 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 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: 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 (January 2005) is 7031 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 81, but not defined == Unused Reference: 'RSVP-UNNUM' is defined on line 702, but no explicit reference was found in the text == Unused Reference: 'BUNDLING' is defined on line 706, but no explicit reference was found in the text ** 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. 'LSP-STITCHING' -- 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 (~~), 6 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Internet Draft Arthi Ayyangar(Editor) 3 Proposed Status: Standards Track Juniper Networks 4 Expires: July 2005 5 Jean-Philippe Vasseur(Editor) 6 Cisco Systems, Inc. 8 January 2005 10 Inter domain GMPLS Traffic Engineering - RSVP-TE extensions 12 draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions of 17 section 3 of RFC 3667. By submitting this Internet-Draft, each author 18 represents that any applicable patent or other IPR claims of which he or 19 she is aware have been or will be disclosed, and any of which he or she 20 become aware will be disclosed, in accordance with RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering Task 23 Force (IETF), its areas, and its working groups. Note that other groups 24 may also distribute working documents as 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 material 29 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 Copyright Notice 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Abstract 43 This document describes extensions to Generalized Multi-Protocol Label 44 Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering 45 (RSVP-TE) signaling required to support mechanisms for the establishment 46 and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths 47 (LSPs), both packet and non-packet, that traverse multiple domains. For 48 the purpose of this document, a domain is considered to be any 49 collection of network elements within a common realm of address space or 50 path computation responsibility. Examples of such domains include 51 Autonomous Systems, IGP areas and GMPLS overlay networks. 53 1. Introduction 55 The requirements for inter-area and inter-AS MPLS Traffic Engineering 56 have been developed by the Traffic Engineering Working Group and have 57 been stated in [INTER-AREA-TE-REQS] and [INTER-AS-TE-REQS] 58 respectively. Many of these requirements also apply to GMPLS 59 networks. The framework for inter-domain GMPLS Traffic Engineering 60 has been provided in [INTER-DOMAIN-FRAMEWORK]. 62 This document presents the RSVP-TE signaling extensions for the setup 63 and maintenance of TE LSPs that span multiple domains. The signaling 64 procedures described in this document are applicable to both packet 65 LSPs ([RSVP-TE]) and non-packet LSPs that use RSVP-TE GMPLS 66 extensions as described in [RSVP-GMPLS]. Three different signaling 67 methods along with the corresponding RSVP-TE extensions and 68 procedures are proposed in this document. 70 For the purpose of this document, a domain is considered to be any 71 collection of network elements within a common realm of address space 72 or path computation responsibility. Examples of such domains include 73 Autonomous Systems, IGP areas and GMPLS overlay networks ([GMPLS- 74 OVERLAY]). 76 1.1. Conventions used in this document 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [RFC2119]. 82 1.2. Terminology 84 ASBR: routers used to connect together ASes of a different or the 85 same Service Provider via one or more Inter-AS links. 87 Bypass Tunnel: an LSP that is used to protect a set of LSPs passing 88 over a common facility. 90 ERO: Explicit Route Object 92 FA: Forwarding Adjacency 94 FA-LSP: Forwarding Adjacency LSP 96 LSP: MPLS Label Switched Path 97 MP: Merge Point. The node where bypass tunnels meet the protected 98 LSP. 100 NHOP bypass tunnel: Next-Hop Bypass Tunnel. A backup tunnel, which 101 bypasses a single link of the protected LSP. 103 NNHOP bypass tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel, 104 which bypasses a single node of the protected LSP. 106 PLR: Point of Local Repair. The head-end of a bypass tunnel. 108 Protected LSP: an LSP is said to be protected at a given hop if it 109 has one or multiple associated backup tunnels originating at that 110 hop. 112 RRO - Record Route Object 114 TE: Traffic Engineering 116 TE LSP: Traffic Engineering Label Switched Path 118 TE-link: Traffic Engineering link 120 TED: MPLS Traffic Engineering Database 122 2. Signaling overview 124 The RSVP-TE signaling of a TE LSP within a single domain is described 125 in [RSVP-TE] and [RSVP-GMPLS]. This document focuses on the RSVP-TE 126 signaling extensions required for inter-domain TE LSP setup and 127 maintenance. Any other extensions that may be needed for routing or 128 path computation are outside the scope of this document. 130 2.1. Signaling options 132 There are three ways in which an RSVP-TE LSP could be signaled across 133 multiple domains: 135 Contiguous - A contiguous TE LSP is a single end-to-end TE LSP that 136 is setup across multiple domains using RSVP-TE signaling procedures 137 described in [RSVP-TE]and [RSVP-GMPLS]. No additional TE LSPs are 138 required to signal a contiguous TE LSP and the same RSVP-TE 139 information for the TE LSP is maintained along the entire LSP path. 141 Nesting - Nesting one or more TE LSPs into another TE LSP is 142 described in [LSP-HIERARCHY]. This technique can also be used to nest 143 one or more inter-domain TE LSPs into an intra-domain FA-LSP. While 144 similar to stitching in the control plane, in the data plane, nesting 145 allows for one or more inter-domain LSPs to be transported over a 146 single intra-domain FA-LSP using the label stacking construct. 148 Stitching - The concept of LSP stitching as well as the required 149 signaling procedures are described in [LSP-STITCHING]. This technique 150 can be used to stitch an inter-domain TE LSP to an intra-domain LSP 151 segment. A inter-domain stitched TE LSP is a TE LSP made up of 152 different TE LSP segments within each domain which are "stitched" 153 together in the data plane so that an end-to-end LSP is achieved in 154 the data plane. In the control plane, however, the different LSP 155 segments are signaled as distinct RSVP sessions which are independent 156 from the RSVP session for the inter-domain LSP. 158 On receipt of an LSP setup request for an inter-domain TE LSP, the 159 decision of whether to signal the LSP contiguously or whether to nest 160 or stitch it to another TE LSP, depends on the signaled TE LSP 161 characteristics or the local node configuration, when not explicitly 162 signaled. Also, the TE LSP segment or FA-LSP within the domain may 163 either be pre-configured or signaled dynamically based on the arrival 164 of the inter-domain TE LSP setup request. 166 3. Procedures on the domain boundary node 168 Whether an inter-domain TE LSP is contiguous, nested or stitched is 169 determined mostly by the signaling method supported by or configured 170 on the intermediate nodes, usually the domain boundary nodes that the 171 inter-domain TE LSP traverses through. It may also depend on certain 172 parameters signaled by the head-end node for the inter-domain TE LSP. 173 When a domain boundary node receives the RSVP Path message for an 174 inter-domain TE LSP setup, it MUST carry out the following procedures 175 before it can forward the Path message to the next hop node, 176 - apply any locally configured policies 177 - determine the signaling method to be used based on any desired 178 characteristics signaled by the head-end node of the inter-domain TE 179 LSP or if the signaling method is not explicitly signaled, then 180 determine the signaling method based on local configuration and 181 policies 182 - depending on the signaling method, carry out any specific ERO 183 procedures, as applicable, as described in the next section 184 - based on the signaling method to be used, determine the next 185 hop node to forward the RSVP Path message 186 - in case of nesting or stitching, either find an existing intra- 187 domain TE LSP to carry the inter-domain TE LSP or signal a new one, 188 depending on local policy 189 - perform any path computations if required. The path computation 191 procedure itself is outside the scope of this document. The various 192 path computation options are addressed in [INTER-DOMAIN-PATH-COMP] 193 - in case of any failures (admission control, policy, signaling; 194 etc), originate corresponding error notifications 196 3.1. Rules on ERO processing 198 The ERO that a domain boundary node receives in the Path message for 199 an inter-domain TE LSP will be dependent on several factors such as 200 the level of visibility that the head-end node of the inter-domain TE 201 LSP has into other domains, the path computation techniques applied 202 at the head-end node, policy agreements between two domains; etc. 203 Eventually, when the ERO reaches a domain boundary node, the 204 following rules SHOULD be used for ERO processing and signaling. 205 Within a domain, there may be no FA-LSPs or LSP segments. If they are 206 present, then they may originate and terminate on domain boundary 207 nodes. There could also be FA-LSPs and LSP segments that may 208 originate and terminate at other nodes in the domain. In general, 209 these ERO processing rules are also applicable to non-boundary nodes 210 that may participate in signaling the inter-domain TE LSP. 211 - If there are any policies related to ERO processing for 212 certain LSPs, they SHOULD be applied and corresponding actions should 213 be taken. E.g. if there exists a policy to reject LSP setup request 214 containing ERO with sub-objects identifying nodes within the domain, 215 then a PathErr with the appropriate error code should be sent back 216 - Section 8.2 of [LSP-HIERARCHY] describes how a node at the 217 edge of a region (domain) processes the ERO in the incoming Path 218 message and uses this ERO, to either find an existing FA-LSP or 219 signal a new FA-LSP using the ERO hops. This also includes adjusting 220 the ERO before sending the Path message to the next hop node. These 221 procedures SHOULD also be followed for nesting or stitching of inter- 222 domain TE LSPs to FA-LSPs or LSP segments respectively. While the 223 domain boundaries are tied to link switching capabilities in [LSP- 224 HIERARCHY], these procedures are also applicable to other domain 225 boundary nodes in the context of this document. E.g. in case of a 226 path computation domain, you have reached the boundary when the ERO 227 hop is no longer reachable via the TE database (TED). 228 - In case of any failure in processing the ERO hop(s), a Path 229 Error message with appropriate error code ([RSVP-TE]) SHOULD be 230 generated. 232 3.2. LSP setup failure and crankback 234 In case of any setup failures along the path due to policy or 235 admission control or other reasons, a corresponding Path Error SHOULD 236 be generated and sent upstream. The propagation of Path Error 237 upstream may be limited to within the domain or it may be sent all 238 the way upstream to the head-end node of the inter-domain TE LSP. 240 This depends not only on local configuration and ability of a 241 boundary node to do local crankback, but also on any specific 242 parameters requested by the head-end node itself for that LSP. In 243 certain cases, it may be desirable for the head-end node to exert 244 some control on the ability for the boundary nodes to make use of 245 crankback. See [CRANKBACK] for the definition of those bits. When 246 crankback is allowed, the domain boundary node can either decide to 247 forward the Path Error message upstream to the head-end node of the 248 inter-domain TE LSP or try to select another egress boundary node. 249 When crankback is not allowed or if the node has not been configured 250 to do a crankback, then a boundary node, when receiving a Path Error 251 message from a downstream boundary node MUST propagate the Path Error 252 message up to the head-end node of the inter-domain TE LSP. 254 4. RSVP-TE signaling extensions 256 The following RSVP-TE signaling extensions are introduced in this 257 document. 259 4.1. Control of downstream choice of signaling method 261 In certain mixed environments with different techniques (contiguous, 262 stitched or nested TE LSPs), a head-end node of the inter-domain TE 263 LSP may wish to signal its requirement regarding the signaling method 264 used at the domain boundaries. 266 [LSP-ATTRIBUTES] defines the format of the Attributes Flags TLV 267 included in the LSP_ATTRIBUTES object carried in an RSVP Path 268 message. The following bit in the Flags TLV is used by the head-end 269 node of the inter-domain TE LSP to restrict the signaling method used 270 by the domain boundary nodes to be contiguous. 272 0x01 (TBD): Contiguous LSP bit - this flag is set by the head-end 273 node that originates the inter-domain TE LSP if it desires a 274 contiguous end-to-end TE LSP (in the control & data plane). When set, 275 this indicates that a boundary node MUST not perform any stitching or 276 nesting on the TE LSP and the TE LSP MUST be routed as any other TE 277 LSP (it must be contiguous end to end). When this bit is cleared, a 278 boundary node may decide to perform stitching or nesting. A mid-point 279 node not supporting contiguous TE LSP MUST send a Path Error message 280 upstream with an error code of "Routing Problem" and error sub- 281 code=17 (TBD) (Contiguous LSP type not supported). This bit MUST not 282 be modified by any downstream node. 284 5. Example 286 5.1. Example topology 288 In this document, we will consider the following example topology for 289 inter-domain TE LSPs setup and maintenance. Note, however, that 290 inter-domain TE LSP setup across other domains covered by this 291 document will also follow similar signaling procedures. In this 292 example, a domain is an Autonomous system (AS). 294 <-- AS-1 ---> <--- AS-2 ---> <-- AS-3 --> c 296 <---BGP---> <---BGP--> 297 CE1---R0----X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 298 | | | | / | / | / | | | 299 | | +-ASBR2----/ ASBR5 | / | | | 300 | | | | | / | | | 301 R1--R2----ASBR3------ASBR6--R4---ASBR8----ASBR10----R7---CE2 303 <================ Inter-AS TE LSP ================> 305 5.1.1. Assumptions 307 - Three interconnected ASes, respectively AS1, AS2, and AS3. Note 308 that AS3 might be AS1 in some scenarios described in [INTER-AS-TE- 309 REQS]. 311 - The various ASBRs are BGP peers, without any IGP running on the 312 single hop link interconnecting the ASBRs 314 - Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE 315 extensions (see [OSPF-TE] and [ISIS-TE]). In other words, the ASes 316 are TE enabled. Note that each AS can run a different IGP. 318 - Each AS can be made of several areas. In this case, the TE LSP will 319 rely on the inter-area TE techniques to compute and set up a TE LSP 320 traversing multiple IGP areas. For the sake of simplicity, each 321 routing domain will be considered as single area in this document, 322 but the solutions described in this document does not prevent the use 323 of multi-area techniques. In fact, these inter-domain solutions are 324 equally applicable to inter-area TE. 326 - A protected inter-AS TE LSP T1 originated at R0 in AS1 and 327 terminating at R6 in AS3 with following possible paths: 329 LSP hops: R0-X1-ASBR1-ASBR4-R3-ASBR7-ASBR9-R6 331 o p1 - a set of loose node hops crossing AS-2 332 R0-X1-ASBR1(loose)-ASBR4(loose)-ASBR7(loose)-ASBR9(loose)-R6 334 o p2 - a set of strict interface hops crossing AS-2 335 R0-X1-ASBR1(loose)-link[ASBR1-ASBR4](strict)-link[ASBR4-R3](strict) 336 -link[R3-ASBR7](strict)-link[ASBR7-ASBR9](strict)-R6 338 - A set of backup tunnels: 340 o B1 from ASBR1 to ASBR4 following the path ASBR1-ASBR2-ASBR4 and 341 protecting against a failure of the ASBR1-ASBR4 link 343 o B2 from ASBR1 to R3 following the path 344 ASBR1-ASBR2-ASBR3-ASBR6-ASBR5-R3 and protecting against a failure of 345 the ASBR4 node. 347 o B3 from ASBR1 to ASBR7 following the path 348 ASBR1-ASBR2-ASBR3-ASBR6-ASBR7 and protecting against a failure of the 349 ASBR4 node. 351 o B4 from R3 to ASBR9 following the path R3-R4-ASBR8-ASBR10-ASBR9 and 352 protecting against a failure of the ASBR7 node. 354 o B5 from ASBR4 to ASBR9 following the path ASBR4-ASBR8-ASBR10-ASBR9 355 and protecting against a failure of the ASBR7 node. 357 5.2. Setup Operation 359 Let us consider an inter-AS TE LSP setup from R0 to R6, with example 360 paths p1, p2 each. In this example, we will examine the behavior on 361 node ASBR4 which is the boundary node for AS-2, for the different 362 signaling methods. 364 Contiguous:- 366 The head-end node, R0, that desires to setup an end-to-end contiguous 367 TE LSP, MAY originate a Path message with LSP_ATTRIBUTES object with 368 the "Contiguous LSP" bit set in the Attributes Flags TLV. 370 For path p1, additional computation to expand the loose hops may be 371 required at various hops along the LSP path. When the Path message 372 arrives at ASBR4, it may carry out a path computation or use some 373 other means to find the intermediate hops to reach ASBR7. It may then 374 adjust the outgoing ERO and forward the Path message through the 375 intermediate hops in AS-2 to ASBR7. 377 For path p2, the ERO next hop points to a node within the domain. 378 ASBR4 may then directly forward the Path message to the next hop in 379 the ERO. 381 Nesting and Stitching:- 383 When the Path message for the inter-AS TE LSP from R0 to R6, reaches 384 ASBR4, ASBR4 SHOULD first determine from the ERO hops, the boundary 385 node to the domain along the path. In this example, the domain 386 boundary node for all paths is ASBR7. It SHOULD then use the ERO hops 387 upto ASBR7 to find an existing FA-LSP in case of nesting or LSP 388 segment in case of stitching, that satisfies the TE constraints. If 389 there are no existing FA-LSPs or LSP segments and ASBR4 is capable of 390 seting up the FA-LSP or LSP segment on demand, it SHOULD do so using 391 the ERO hops in the Path message of the inter-domain TE LSP. In 392 either case, ASBR4 will adjust the ERO in the inter-domain TE LSP and 393 will forward the Path message directly to the end-point of the FA-LSP 394 or LSP segment using the procedures described in [LSP-HIERARCHY]. 396 In case of path p1, since there are no ERO hops between ASBR4 and 397 ASBR7, and ASBR7 hop is loose, ASBR4 may select any existing FA-LSP 398 (nesting) or LSP segment (stitching) that satisfies the constraints 399 or it may compute a path for the FA-LSP or LSP segment upto ASBR7 or 400 some other intermediate node in AS-2. 402 In case of path p2, ASBR4 may either select an existing FA-LSP or LSP 403 segment with ERO hops link[ASBR4-R3](strict)-link[R3-ASBR7](strict) 404 or it may compute a new path for the FA-LSP or LSP segment using the 405 above hops. In either case, the ERO hops for the FA-LSP or LSP 406 segment MUST be the same as the signaled strict hops in that domain. 408 Now, suppose, we have a path p3, as a set of strict node hops 409 crossing AS-2 as defined below, 411 R0-X1-ASBR1(loose)-ASBR4(strict)-ASBR7(strict)-ASBR9(loose)-R6 413 In this case, the ERO nexthop at ASBR4 is ASBR7(strict). In this 414 case, ASBR4 will try to find or compute a FA-LSP or LSP segment 415 directly to ASBR7. 417 The main difference between processing of p1 and p3 for nesting or 418 stitching is that in case of p1, since the ERO nexthop is a loose 419 hop, ASBR4 need not find a FA-LSP or LSP segment directly from ASBR4 420 to ASBR7. So, there could be multiple FA-LSPs or LSP segments between 421 ASBR4 and ASBR7. On the other hand, for path p3, since ASBR7 is a 422 strict hop, ASBR4 MUST find or signal a FA-LSP or LSP segment that 423 connects ASBR4 and ASBR7. 425 6. Protection and recovery of inter-domain TE LSPs 427 6.1. Fast Recovery support using MPLS TE Fast Reroute 429 [FAST-REROUTE] describes two methods for local protection for a 430 packet TE LSP in case of link, SRLG or node failure. This section 431 describes how these mechanisms work with the proposed signaling 432 solutions for inter-domain TE LSP setup. 434 6.1.1. Failure within a domain (link or node failure) 436 The mode of operation of MPLS TE Fast Reroute to protect a 437 contiguous, stitched or nested TE LSP within a domain is identical to 438 the existing procedures described in [FAST-REROUTE]. In case of 439 nested or stitched inter-domain TE LSPs, protecting the intra-domain 440 TE FA-LSP or LSP segment will automatically protect the traffic on 441 the inter-domain TE LSP. No new extensions are required for any of 442 the signaling methods. 444 6.1.2. Failure of link at domain boundaries 446 The procedures for doing link protection of the link at domain 447 boundaries is the same for contiguous, nested and stitched TE LSPs. 449 To protect an inter-domain link with MPLS TE Fast Reroute, a set of 450 backup tunnels must be configured or dynamically computed between the 451 two domain boundary nodes diversely routed from the protected inter- 452 domain link. The region connecting two domains may not be TE enabled. 453 In this case, an implementation will have to support the set up of TE 454 LSP over a non-TE enabled region. 456 For each protected inter-domain TE LSP traversing the protected link, 457 a NHOP backup must be selected by a PLR (i.e domain exit boundary 458 router), when the TE LSP is first set up. This requires for the PLR 459 to select a bypass tunnel terminating at the NHOP. Finding the NHOP 460 bypass tunnel of an inter-AS LSP can be achieved by analyzing the 461 content of the RRO object received in the RSVP Resv message of both 462 the bypass tunnel and the protected TE LSP(s). As defined in [RSVP- 463 TE], the addresses specified in the RRO IPv4 subobjects can be node- 464 ids and/or interface addresses (with specific recommendation to use 465 the interface address of the outgoing Path messages). The PLR may or 466 may not have sufficient topology information to find where the backup 467 tunnel intersects the protected TE LSP based on the RRO. [NODE-ID] 468 proposes a solution to this issue, defining an additional RRO IPv4 469 suboject that specifies a node-id address. 471 Example: The ASBR1-ASBR4 link is protected by the backup tunnel B1 472 that follows the ASBR1-ASBR2-ASBR4 path 474 6.1.3. Failure of a boundary node 476 For each protected inter-domain TE LSP traversing the boundary node 477 to be protected, a NNHOP backup must be selected by the PLR. This 478 requires the PLR to setup a bypass tunnel terminating at the NNHOP. 479 Finding the NNHOP bypass tunnel of an inter-domain TE LSP can be 480 achieved by analyzing the content of the RRO object received in the 481 RSVP Resv message of both the bypass tunnel and the protected TE 482 LSP(s) (see [NODE-ID]). The main difference with node protection, 483 between a protected contiguous inter-domain TE LSP and a protected 484 nested or stitched inter-domain TE LSP is that the PLR and NNHOP (MP) 485 in case of a contiguous TE-LSP could be any node within the domain. 486 However, in case of a nested or stitched TE-LSP the PLR and MP can 487 only be the end-points of the FA-LSP or LSP segment. The consequence 488 is that the backup path is likely to be longer and if bandwidth 489 protection is desired, for instance, ([FAST-REROUTE]) more resources 490 may be reserved in the domain than necessary. 492 Let us again consider the example topology of section 4.1. The 493 protected inter-domain TE LSP is an inter-AS TE LSP from R0 to R6 494 with path p1. Also, for nesting or stitching, let us assume that the 495 end-points of the FA-LSP or LSP segment in AS-2 are ASBR4 and ASBR7. 496 This gives rise to the following two scenarios for node protection: 498 Protecting the boundary node at the entry to a domain :- 500 Example: protecting against the failure of ASBR4 502 If the inter-AS TE LSP in this example, is a contiguous LSP, then the 503 PLR is ASBR1 and the NNHOP (MP) could be R3 or any other intermediate 504 node along the LSP path. A backup tunnel B2 may be used to protect 505 the inter-AS TE LSP against failure of ASBR4. 507 If the inter-AS TE LSP in this example, is nested or sticthed at 508 ASBR4 into an intra-domain TE FA-LSP or LSP segment between ASBR4 and 509 ASBR7, then the PLR is ASBR1 and the NNHOP (MP) is ASBR7. A backup 510 tunnel B3 may be used to protect the inter-AS TE LSP against failure 511 of ASBR4. 513 Protecting the boundary node at the exit of a domain :- 515 Example: protecting against failure of ASBR7. 517 If the inter-AS TE LSP in this example, is a contiguous LSP, then the 518 PLR could be R3 and the NNHOP (MP) is ASBR9. A backup tunnel B4 may 519 be used to protect the inter-AS TE LSP against failure of ASBR7. 521 If the inter-AS TE LSP in this example, is nested or sticthed at 522 ASBR4 into an intra-domain TE FA-LSP or LSP segment between ASBR4 and 523 ASBR7, then the PLR is ASBR4 and the NNHOP (MP) is ASBR9. A backup 524 tunnel B5 may be used to protect the inter-AS TE LSP against failure 525 of ASBR7. 527 6.2. Protection and recovery of GMPLS LSPs 529 [E2E-RECOVERY] describes the signaling extensions to support end-to- 530 end GMPLS LSP recovery. Signaling methods defined above for inter- 531 domain RSVP-TE LSPs also apply to recovery LSPs signaled for end-to- 532 end protection of inter-domain GMPLS LSPs. Any other protection 533 mechanisms that are developed for GMPLS LSPs SHOULD also take into 534 account inter-domain considerations. 536 7. Re-optimization of inter-domain TE LSPs 538 Re-optimization of a TE LSP is the process of moving the LSP from the 539 current path to a more prefered path. This usually involves 540 computation of the new prefered path and make-before-break signaling 541 procedures [RSVP-TE], to minimize traffic disruption. The path 542 computation procedures involved in re-optimization of an inter-domain 543 TE LSP are covered in [INTER-DOMAIN-PATH-COMP]. 545 In the context of an inter-domain TE LSP, since the LSP traverses 546 multiple domains, re-optimization may be required in one or more 547 domains at a time. Again, depending on the nature of the LSP and/or 548 policies and configuration at domain boundaries (or other nodes), one 549 may either always want the head-end node of the inter-domain TE LSP 550 to be notified of any local need for re-optimizations and let the 551 head-end initiate the make-before-break process or one may want to 552 restrict local re-optimizations with the domain. 554 [LOOSE-REOPT] describes mechanisms that allow, 555 - The head-end node to trigger on every node whose next hop 556 is a loose hop the re-evaluation of the current path in order to 557 detect a potentially more optimal path. This is done via explicit 558 signaling request: the head-end node sets the "ERO Expansion request" 559 bit of the SESSION-ATTRIBUTE object carried in the RSVP Path message. 560 - A node whose next hop is a loose-hop to signal to the head- 561 end node that a better path exists. This is performed by sending an 562 RSVP Path Error Notify message (ERROR-CODE = 25), sub-code 6 (Better 563 path exists). This indication may either be sent in response to a 564 query sent by the head-end node or spontaneously by any node having 565 detected a more optimal path. 567 The above mechanisms SHOULD be used for a contiguous inter-domain TE 568 LSP to allow the head-end node of the inter-domain TE LSP to initiate 569 make-before-break procedures. For nested or stitched TE LSPs, it is 570 possible to re-optimize the local FA-LSP or LSP segment without 571 involving the head-end node of the inter-domain TE LSP. This will 572 automatically re-route the traffic for the inter-domain TE LSP along 573 the new path, within the domain. Such local re-optimizations, 574 including parameters for re-optimization can be controlled by local 575 policy or configuration in that domain. 577 8. Security Considerations 579 When signaling an inter-domain RSVP-TE LSP, an operator may make use 580 of the already defined security features related to RSVP-TE 581 (authentication). This may require some coordination between the 582 domains to share the keys (see RFC 2747 and RFC 3097). Note that this 583 may involve additional synchronization, should the domain boundary 584 LSR be protected with MPLS TE Fast Reroute, since the merge point 585 should also share the key. 587 For an inter-domain TE LSP, especially when it traverses different 588 administrative or trust domains, the following mechanisms (also see 589 [INTER-AREA-TE-REQS]) SHOULD be provided to an operator :- 1) a way 590 to enforce policies and filters at the domain boundaries to process 591 the incoming LSP setup requests (Path messages) based on certain 592 agreed trust and service levels between domains. 2) a way for the 593 operator to rate limit LSP setup requests or error notifications from 594 a particular domain. 3) a mechanism to allow policy-based outbound 595 RSVP message processing at the domain boundary LSR, which may involve 596 filtering or modification of certain addresses in RSVP objects and 597 messages. 599 Some examples of the policies described above are:- 1) An operator 600 may choose to implement some kind of ERO filtering policy on the 601 domain boundary LSR to disallow or ignore hops within the domain 602 being identified in the ERO of an incoming Path message. 2) In order 603 to preserve confidentiality, an operator may choose to disallow 604 recording of hops within the domain in the RRO or may choose to 605 filter out certain recorded RRO addresses at the domain boundary LSR. 606 3) An operator may require the boundary LSR to modify the addresses 607 of certain messages like PathErr or Notify originated from hops 608 within the domain. 610 Note that the detailed specification of such mechanisms (local 611 implementation) is outside the scope of this document. 613 9. IANA Considerations 615 The following values have to be defined by IANA for this document. 616 The registry is, http://www.iana.org/assignments/rsvp-parameters. 618 9.1. Attribute Flags for LSP_ATTRIBUTES object 620 The following new flag bit is being defined for the Attributes Flags 621 TLV in the LSP_ATTRIBUTES object. The numeric value should be 622 assigned by IANA. 624 Contiguous LSP bit - 0x01 (Suggested value) 626 This flag bit is only to be used in the Attributes Flags TLV on a 627 Path message. 629 9.2. New Error Codes 631 The following new error sub-code is being defined under the RSVP 632 error-code "Routing Problem" (24). The numeric error sub-code value 633 should be assigned by IANA. 635 Contiguous LSP type not supported - sub-code 17 (Suggested value) 637 This error code is to be used only in a RSVP PathErr. 639 10. Acknowledgements 641 The authors would like to acknowledge the input and helpful comments 642 from Adrian Farrel on various aspects discussed in the document. 644 11. References 646 11.1. Normative References 648 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 649 Extensions to OSPF", RFC 3630 (Updates RFC 2370), September 2003. 651 [ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic 652 Engineering", RFC 3784 654 [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 655 3209, December 2001. 657 [RSVP-GMPLS] L. Berger, et al, "Generalized Multi-Protocol Label 658 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 659 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 661 [LSP-HIERARCHY] Kompella K., Rekhter Y., "LSP Hierarchy with 662 Generalized MPLS TE", (work in progress). 664 [LSP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with 665 Generalized MPLS TE", (work in progress). 667 [CRANKBACK] Farrel A. et al, "Crankback Signaling Extensions for MPLS 668 Signaling", (work in progress). 670 [LSP-ATTRIBUTES] Farrel A. et al, "Encoding of Attributes for 671 Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) 672 Establishment Using RSVP-TE", (work in progress). 674 [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE 675 for LSP Tunnels", (work in progress) 677 [NODE-ID] Vasseur, Ali and Sivabalan, "Definition of an RRO node-id 678 subobject", (work in progress). 680 [E2E-RECOVERY] J.P. Lang et al, "RSVP-TE Extensions in support of 681 End-to-End GMPLS-based Recovery", (work in progress). 683 11.2. Informative References 685 [INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering 686 requirements", (work in progress). 688 [INTER-AREA-TE-REQS] LeRoux JL, Vasseur JP, Boyle J. et al, 689 "Requirements for support of Inter-Area MPLS Traffic Engineering", 690 (work in progress). 692 [INTER-DOMAIN-FRAMEWORK] Farrel A. et al, "A Framework for Inter- 693 Domain MPLS Traffic Engineering", (work in progress). 695 [INTER-DOMAIN-PATH-COMP] Vasseur JP., Ayyangar A., Zhang R., "Inter- 696 domain MPLS Traffic Engineering LSP path computation methods", (work 697 in progress). 699 [GMPLS-OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay 700 Model", (work in progress). 702 [RSVP-UNNUM] Kompella K., Rekhter Y., "Signalling Unnumbered Links in 703 Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 704 3477, January 2003. 706 [BUNDLING] Kompella K., Rekhter Y., "Link Bundling in MPLS Traffic 707 Engineering", (work in progress). 709 [LOOSE-REOPT] Vasseur JP. et al, "Reoptimization of an explicit 710 loosely routed MPLS TE paths", (work in progress). 712 Author's addresses 714 Arthi Ayyangar 715 Juniper Networks, Inc. 716 1194 N.Mathilda Ave 717 Sunnyvale, CA 94089 718 USA 719 e-mail: arthi@juniper.net 721 Jean Philippe Vasseur 722 Cisco Systems, Inc. 723 300 Beaver Brook Road 724 Boxborough , MA - 01719 725 USA 726 e-mail: jpv@cisco.com 728 Intellectual Property Statement 730 The IETF takes no position regarding the validity or scope of any 731 Intellectual Property Rights or other rights that might be claimed to 732 pertain to the implementation or use of the technology described in 733 this document or the extent to which any license under such rights 734 might or might not be available; nor does it represent that it has 735 made any independent effort to identify any such rights. Information 736 on the procedures with respect to rights in RFC documents can be 737 found in BCP 78 and BCP 79. 739 Copies of IPR disclosures made to the IETF Secretariat and any 740 assurances of licenses to be made available, or the result of an 741 attempt made to obtain a general license or permission for the use of 742 such proprietary rights by implementers or users of this 743 specification can be obtained from the IETF on-line IPR repository at 744 http://www.ietf.org/ipr. 746 The IETF invites any interested party to bring to its attention any 747 copyrights, patents or patent applications, or other proprietary 748 rights that may cover technology that may be required to implement 749 this standard. Please address the information to the IETF at ietf- 750 ipr@ietf.org. 752 Disclaimer of Validity 754 This document and the information contained herein are provided on an 755 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 756 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 757 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 758 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 759 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 760 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 762 Copyright Statement 764 Copyright (C) The Internet Society (2005). This document is subject 765 to the rights, licenses and restrictions contained in BCP 78, and 766 except as set forth therein, the authors retain all their rights. 768 Acknowledgment 770 Funding for the RFC Editor function is currently provided by the 771 Internet Society.