idnits 2.17.1 draft-ietf-ccamp-inter-domain-rsvp-te-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1048. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1025. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1032. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1038. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1054), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == 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 -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2006) is 6616 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 115, but not defined == Missing Reference: 'EXCLUDE-ROUTE' is mentioned on line 477, 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-STITCHING' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRANKBACK' ** Obsolete normative reference: RFC 4420 (ref. 'LSP-ATTRIBUTES') (Obsoleted by RFC 5420) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 9 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: September 2006 5 Jean-Philippe Vasseur(Editor) 6 Cisco Systems, Inc. 8 March 2006 10 Inter domain GMPLS Traffic Engineering - RSVP-TE extensions 12 draft-ietf-ccamp-inter-domain-rsvp-te-03.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 6, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). All Rights Reserved. 43 Abstract 45 This document describes extensions to Generalized Multi-Protocol Label 46 Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering 47 (RSVP-TE) signaling required to support mechanisms for the establishment 48 and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths 49 (LSPs), both packet and non-packet, that traverse multiple domains. For 50 the purpose of this document, a domain is considered to be any 51 collection of network elements within a common realm of address space or 52 path computation responsibility. Examples of such domains include 53 Autonomous Systems, IGP areas and GMPLS overlay networks. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 Conventions used in this document . . . . . . . . . . . . 3 59 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Signaling overview . . . . . . . . . . . . . . . . . . . . . 4 61 2.1 Signaling options . . . . . . . . . . . . . . . . . . . . 4 62 3. Procedures on the domain boundary node . . . . . . . . . . . . 5 63 3.1 Rules on ERO processing . . . . . . . . . . . . . . . . . 6 64 3.2 LSP setup failure and crankback . . . . . . . . . . . . . 8 65 3.3 RRO processing across domains . . . . . . . . . . . . . . 9 66 4. RSVP-TE signaling extensions . . . . . . . . . . . . . . . . . 9 67 4.1 Control of downstream choice of signaling method . . . . . 9 68 5. Protection and recovery of inter-domain TE LSPs . . . . . . . 11 69 5.1 Fast Recovery support using MPLS TE Fast Reroute . . . . . 11 70 5.1.1 Failure within a domain (link or node failure) . . . . 11 71 5.1.2 Failure of link at domain boundaries . . . . . . . . . 11 72 5.1.3 Failure of a boundary node . . . . . . . . . . . . . . 12 73 5.2 Protection and recovery of GMPLS LSPs . . . . . . . . . . 13 74 6. Re-optimization of inter-domain TE LSPs . . . . . . . . . . . 13 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 8.1 Attribute Flags for LSP_ATTRIBUTES object . . . . . . . . 15 78 8.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 16 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 10.1 Normative References . . . . . . . . . . . . . . . . . . 16 82 10.2 Informative References . . . . . . . . . . . . . . . . . 17 83 Appendix 1: Examples . . . . . . . . . . . . . . . . . . . . . . 18 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 85 Intellectual Property and Copyright Statements . . . . . . . . 23 87 1. Introduction 89 The requirements for inter-area and inter-AS MPLS Traffic Engineering 90 have been developed by the Traffic Engineering Working Group and have 91 been stated in [INTER-AREA-TE-REQS] and [INTER-AS-TE-REQS] 92 respectively. Many of these requirements also apply to GMPLS 93 networks. The framework for inter-domain GMPLS Traffic Engineering 94 has been provided in [INTER-DOMAIN-FRAMEWORK]. 96 This document presents the RSVP-TE signaling extensions for the setup 97 and maintenance of TE LSPs that span multiple domains. The signaling 98 procedures described in this document are applicable to both MPLS 99 packet LSPs ([RSVP-TE]) and all LSPs that use RSVP-TE GMPLS 100 extensions as described in [RSVP-GMPLS]. Three different signaling 101 methods along with the corresponding RSVP-TE extensions and 102 procedures are proposed in this document. 104 For the purpose of this document, a domain is considered to be any 105 collection of network elements within a common realm of address space 106 or path computation responsibility. Examples of such domains include 107 Autonomous Systems, IGP areas and GMPLS overlay networks ([GMPLS- 108 OVERLAY]). 110 1.1. Conventions used in this document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 1.2. Terminology 118 ASBR: routers used to connect together ASes of a different or the 119 same Service Provider via one or more Inter-AS links. 121 Bypass Tunnel: an LSP that is used to protect a set of LSPs passing 122 over a common facility. 124 ERO: Explicit Route Object 126 H-LSP: Hierarchical LSP 128 FA-LSP: Forwarding Adjacency LSP 130 LSP: MPLS Label Switched Path 132 MP: Merge Point. The node where bypass tunnels meet the protected 133 LSP. 135 NHOP bypass tunnel: Next-Hop Bypass Tunnel. A backup tunnel, which 136 bypasses a single link of the protected LSP. 138 NNHOP bypass tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel, 139 which bypasses a single node of the protected LSP. 141 PLR: Point of Local Repair. The head-end of a bypass tunnel. 143 Protected LSP: an LSP is said to be protected at a given hop if it 144 has one or multiple associated backup tunnels originating at that 145 hop. 147 RRO - Record Route Object 149 TE: Traffic Engineering 151 TE LSP: Traffic Engineering Label Switched Path 153 TE link: Traffic Engineering link 155 TED: MPLS Traffic Engineering Database 157 2. Signaling overview 159 The RSVP-TE signaling of a TE LSP within a single domain is described 160 in [RSVP-TE] and [RSVP-GMPLS]. This document focuses on the RSVP-TE 161 signaling extensions required for inter-domain TE LSP setup and 162 maintenance. Any other extensions that may be needed for routing or 163 path computation are outside the scope of this document. 165 2.1. Signaling options 167 There are three ways in which an RSVP-TE LSP could be signaled across 168 multiple domains: 170 Contiguous - A contiguous TE LSP is a single end-to-end TE LSP that 171 is setup across multiple domains using RSVP-TE signaling procedures 172 described in [RSVP-TE] and [RSVP-GMPLS]. No additional TE LSPs are 173 required to signal a contiguous TE LSP and the same RSVP-TE 174 information for the TE LSP is maintained along the entire LSP path. 176 Nesting - Nesting one or more TE LSPs into another TE LSP is 177 described in [LSP-HIERARCHY]. This technique can be used to nest one 178 or more inter-domain TE LSPs into an intra-domain hierarchical LSP 179 (H-LSP). Label stacking construct may be used to achieve nesting, 180 when appropriate, say in packet networks. In the rest of this 181 document, the term H-LSP is used to refer to an LSP that allows 182 nesting of other LSPs into it and that may or may not be advertised 183 as a TE link. Furthermore, an H-LSP may or may not be an FA-LSP [LSP- 184 HIERARCHY]. 186 Stitching - The concept of LSP stitching as well as the required 187 signaling procedures is described in [LSP-STITCHING]. This technique 188 can be used to stitch an inter-domain TE LSP to an intra-domain LSP 189 segment. A inter-domain stitched TE LSP is a TE LSP made up of 190 different TE LSP segments within each domain which are "stitched" 191 together in the data plane so that an end-to-end LSP is achieved in 192 the data plane. In the control plane, however, the different LSP 193 segments are signaled as distinct RSVP sessions which are independent 194 from the RSVP session for the inter-domain LSP. While stitching is 195 similar to nesting in the control plane, in the data plane, stitching 196 allows for only one inter-domain LSP to be associated with any one 197 intra-domain LSP, and does not require the use of label stacks. 199 On receipt of an LSP setup request for an inter-domain TE LSP, the 200 decision of whether to signal the LSP contiguously or whether to nest 201 or stitch it to another TE LSP, depends on the signaled TE LSP 202 characteristics from the head-end node or the local node 203 configuration, when not explicitly signaled. Also, the TE LSP segment 204 or H-LSP within the domain may either be pre-configured or signaled 205 dynamically based on the arrival of the inter-domain TE LSP setup 206 request. 208 3. Procedures on the domain boundary node 210 Whether an inter-domain TE LSP is contiguous, nested or stitched is 211 determined mostly by the signaling method supported by or configured 212 on the intermediate nodes, usually the domain boundary nodes that the 213 inter-domain TE LSP traverses. It also depends on certain parameters 214 that may be signaled by the head-end node for the inter-domain TE 215 LSP. 217 When a domain boundary node receives the RSVP Path message for an 218 inter-domain TE LSP setup, it MUST carry out the following procedures 219 before it can forward the Path message to the next node along the 220 path: 222 1. Apply any locally configured policies. In case of a policy 223 failure, the node SHOULD fail the setup of the LSP and 224 originate a PathErr with error code=2 ("Policy control 225 failure") and error sub-code="Inter-domain policy failure" 226 (TBD). 228 2. Determine the signaling method to be used. The head-end node 229 of the inter-domain TE LSP may have explicitly specified a 230 signaling method or if the signaling method is not explicitly 231 signaled, then the node MAY determine the signaling method 232 based on local configuration and policies. If the desired 233 signaling method signaled by the head-end cannot be supported 234 at this node for some reason, then a PathErr message as 235 described in Section 4.1 MUST be generated. 237 3. Carry out ERO procedures as described in the next section in 238 addition to the procedures in [RSVP-TE] and [RSVP-GMPLS]. 240 4. Perform any path computations as required (say for ERO 241 expansion). The path computation procedure itself is outside 242 the scope of this document. One such path computation option is 243 addressed in [INTER-DOMAIN-PD-PATH-COMP]. Another option is to 244 use a Path Computation Element (PCE) ([PCE]) for path 245 computation. Path computation may itself involve determining the 246 exit point from the TE domain ([INTER-DOMAIN-PD-PATH-COMP]). 248 4a. In case of nesting or stitching, either find an existing 249 intra-domain TE LSP to carry the inter-domain TE LSP or 250 signal a new one, depending on local policy. 252 4b. In case of a path computation failure, a PathErr SHOULD be 253 generated as described in [INTER-DOMAIN-PD-PATH-COMP]. 255 5. In case of any other RSVP signaling failures, procedures as 256 described in [RSVP-TE] and [RSVP-GMPLS] SHOULD be followed. 257 Follow procedures related to LSP setup failure and crankback 258 as described in Section 3.2, where applicable. 260 6. Carry out RRO procedures as described in Section 3.3, if 261 applicable. 263 3.1. Rules on ERO processing 265 The ERO that a domain boundary node receives in the Path message for 266 an inter-domain TE LSP will be dependent on several factors such as 267 the level of visibility that the head-end node of the inter-domain TE 268 LSP has into other domains, the path computation techniques applied 269 at the head-end node, policy agreements between two domains; etc. 270 Eventually, when the ERO reaches a domain boundary node, the 271 following rules SHOULD be used for ERO processing and signaling. 272 Within a domain, there may be no H-LSPs or LSP segments. If they are 273 present, then they may originate and terminate on domain boundary 274 nodes. There could also be H-LSPs and LSP segments that may originate 275 and terminate at other nodes in the domain. In general, these ERO 276 processing rules are also applicable to non-boundary nodes that may 277 participate in signaling the inter-domain TE LSP. 279 1. If there are any policies related to ERO processing for the 280 LSP, they SHOULD be applied and corresponding actions should be 281 taken. E.g. there could exist a policy to reject inter-domain 282 LSP setup request containing an ERO with subobjects identifying 283 nodes within the domain. In case of inter-domain LSP setup 284 failures due to policy failures related to ERO processing, the 285 node SHOULD issue a PathErr with error code=2 ("Policy control 286 failure") and error sub-code="Inter-domain explicit route 287 rejected" (TBD). 289 2. Section 8.2 of [LSP-HIERARCHY] describes how a node at the 290 edge of a region (domain) processes the ERO in the incoming 291 Path message and uses this ERO, to either find an existing H-LSP 292 or signal a new H-LSP using the ERO hops. This also includes 293 adjusting the ERO before sending the Path message to the next 294 hop node. These procedures SHOULD also be followed for nesting 295 or stitching of inter-domain TE LSPs to H-LSPs or LSP segments 296 respectively. While the domain boundaries are tied to link 297 switching capabilities in [LSP-HIERARCHY], these procedures are 298 also applicable to other domain boundary nodes in the context 299 of this document. 301 3. If the ERO subobject identifies a TE link formed by a H-LSP or 302 LSP segment within the domain, either numbered or unnumbered, 303 then a contiguous LSP MUST NOT be signaled. The node MUST either 304 nest or stitch the inter-domain TE LSP to the local H-LSP or LSP 305 segment. If, however, the head-end node for the inter-domain LSP 306 has requested that the inter-domain TE LSP be contiguous, then 307 this is a conflict and a PathErr with error code=24 ("Routing 308 Problem") and error sub-code="ERO conflicts with inter-domain 309 signaling method" (TBD) SHOULD be issued. 311 4. In the absence of any ERO subobjects, the LSP destination in 312 the SESSION object SHOULD be considered as the next loose hop. 313 A node may also receive an ERO with explicit IPv4, IPv6 or AS 314 number loose hops. In such cases, a path computation to expand 315 this loose hop SHOULD be carried out. Path computation as 316 described in [INTER-DOMAIN-PD-PATH-COMP] or using a PCE should 317 be used to expand the ERO in these cases and to determine the 318 intermediate hops. 320 5. In case of any other failures in processing the ERO hop(s), a 321 PathErr message with appropriate error codes as described in 322 [RSVP-TE] or [RSVP-GMPLS] SHOULD be generated. 324 3.2. LSP setup failure and crankback 326 In case of any setup failures along the path due to policy or 327 admission control or other reasons, a corresponding 328 PathErr/ResvErr/Notify is generated and sent upstream and/or 329 downstream. An ERROR_SPEC comprises of information regarding the 330 point of failure (network element) and details about the failure 331 itself. When an LSP traverses multiple domains, a failure could be 332 generated in any domain along the path and an error notification may 333 need to be propagated across multiple domains. So, an error 334 notification message itself may be subjected to policies as it 335 traverses domain boundaries and a boundary node MAY modify domain 336 specific information carried in the error message. E.g. the error 337 node address in the RSVP ERROR_SPEC or IF_ID ERROR_SPEC or the 338 Interface Identifier in IF_ID ERROR_SPEC may be modified at the 339 boundary node for confidentiality reasons. Nodes other than domain 340 boundary nodes SHOULD NOT modify ERROR_SPEC contents. It is also 341 RECOMMENDED that such a policy be implemented only on domain boundary 342 nodes for inter-domain LSPs where preserving confidentiality is a 343 requirement. 345 Also, in case of an inter-domain LSP setup failure, there may be 346 cases when the error is not propagated all the way upstream to the 347 head-end node. A PathErr may be intercepted by a boundary node in the 348 domain in which the error is generated (or any other node along the 349 path) and this node may attempt to find an alternate path. Finding 350 an alternate path means finding a new path downstream to the node 351 performing re-routing and avoiding the failed network elements. This 352 may involve finding a path within the domain experiencing the failure 353 or it may mean finding new boundary node(s) or new downstream domain. 355 Crankback re-routing depends not only on local configuration and 356 ability of a boundary node to do local crankback re-routing, but also 357 on any specific parameters requested by the head-end node itself for 358 that LSP. In certain cases, it may be desirable for the head-end node 359 to exert some control on whether crankback re-routing at intermediate 360 nodes is desirable or not. Procedures and extensions described in 361 [CRANKBACK] should be followed for crankback re-routing. When 362 crankback re-routing is allowed, a node along the TE LSP path may 363 either decide to forward the PathErr message upstream towards the 364 head-end node of the inter-domain TE LSP or try to determine an 365 alternate path around the failure. When crankback re-routing is not 366 allowed or if the node cannot perform crankback re-routing, then, on 367 receiving a PathErr message, the node should propagate the PathErr 368 message upstream. 370 [RSVP-GMPLS] allows nodes to generate a targeted Notify message in 371 addition to a PathErr/ResvErr message, to expedite error 372 notification, if a Notify Request has been received in the 373 corresponding Path/Resv message. This is also applicable to inter- 374 domain TE LSPs which implement [RSVP-GMPLS]. However, since PathErr 375 and Notify need not follow the same path, their recepient nodes could 376 be different. This has certain implications on crankback re-routing. 377 Procedures and recommendations in [CRANKBACK] should be followed for 378 Notify message processing for crankback re-routing. 380 3.3. RRO processing across domains 382 [RSVP-TE] defines the RECORD_ROUTE object (RRO) as an optional 383 object, which is primarily used for loop detection and for providing 384 information about the hops traversed by LSPs. [FAST-REROUTE] also 385 uses the RRO to record labels and determine MP. The address or ID 386 recorded in the RRO usually represents a link/interface. This 387 information by itself may not be useful enough when LSPs traverse 388 domains. [NODE-ID] defines extensions which allows a node to record 389 its node ID in the RRO, to provide an additional context for the link 390 address/ID. 392 Note that there may also be cases while traversing administrative 393 domain boundaries, where a network may not wish to expose its 394 internal addresses/IDs to preserve confidentiality. In such cases RRO 395 MAY be subjected to policies, filtering and modifications at domain 396 boundaries. Internal network element identities may be masked off and 397 replaced with boundary information or AS information, by domain 398 boundary entities. This is not expected to hamper the working of the 399 signaling protocol. This does, however, result in information loss, 400 thereby leading to inefficient paths or procedures that depend on RRO 401 information. 403 4. RSVP-TE signaling extensions 405 The following RSVP-TE signaling extensions are introduced in this 406 document. 408 4.1. Control of downstream choice of signaling method 410 In certain mixed environments with different techniques (contiguous, 411 stitched or nested TE LSPs), a head-end node of the inter-domain TE 412 LSP may wish to signal its requirement regarding the signaling method 413 used at an intermediate node along the path. 415 [LSP-ATTRIBUTES] defines the format of the Attributes Flags TLV 416 included in the LSP_ATTRIBUTES object carried in an RSVP Path 417 message. The following bit in the Flags TLV is used by the head-end 418 node of the inter-domain TE LSP to restrict the signaling method used 419 by the intermediate nodes to be contiguous. 421 Bit Number 4 (TBD): Contiguous LSP bit - this flag is set by the 422 head-end node that originates the inter-domain TE LSP if it desires a 423 contiguous end-to-end TE LSP (in the control & data plane). When set, 424 this indicates that an intermediate node MUST NOT perform any 425 stitching or nesting on the TE LSP and the TE LSP MUST be routed as 426 any other TE LSP (it must be contiguous end to end). When this bit is 427 cleared, an intermediate node MAY decide to perform stitching or 428 nesting. This bit MUST NOT be modified by any downstream node. 430 An intermdediate node that supports the LSP_ATTRIBUTES object and the 431 Attributes Flags TLV, and also recognizes the "Contiguous LSP" bit, 432 but cannot support contiguous TE LSP MUST send a Path Error message 433 upstream with an error code=24 ("Routing Problem") and error sub- 434 code="Contiguous LSP type not supported" (TBD). 436 If an intermediate node receiving a Path message with the "Contiguous 437 LSP" bit set in the Flags field of the LSP_ATTRIBUTES, recognizes the 438 object, the TLV and the bit and also supports the desired contiguous 439 LSP behavior, then it MUST signal a contiguous LSP and MUST set the 440 "Contiguous LSP signaled" bit in the Flags field of the RRO 441 Attributes subobject in the corresponding Resv message. 443 However, if the intermediate node supports the LSP_ATTRIBUTES object 444 but does not recognize the Attributes Flags TLV, or supports the TLV 445 as well, but does not recognize this particular bit, then it SHOULD 446 simply ignore the above request. It MAY signal any type of LSP in 447 this case. The "Contiguous LSP signaled" bit in the Flags field of 448 the RRO Attributes SHOULD NOT be set. 450 An ingress node for an inter-domain LSP requesting a contiguous LSP 451 SHOULD examine the RRO Attributes subobject Flags to determine if the 452 LSP was indeed signaled contiguous end to end. If the "Contiguous LSP 453 signaled" bit is cleared, the head end may take appropriate actions 454 such as restricting the type of traffic that gets mapped to this LSP, 455 tearing down the LSP, or rerouting the LSP around the nodes that do 456 not support the contiguous signaling; etc. Choice of action to be 457 taken is upto the implementation on the ingress node and it is out of 458 the scope of this document to recommend any particular action. 460 5. Protection and recovery of inter-domain TE LSPs 462 The procedures described in Section 3 MUST be applied to all inter- 463 domain TE LSPs, including bypass tunnels, detour LSPs [FAST-REROUTE] 464 or segment recovery LSPs [SEGMENT-PROTECTION] that may cross domains. 465 This means that these LSPs will also be subjected to ERO processing, 466 policies, path computation; etc. Also, note that the explicit route 467 for these backup LSPs needs to be either configured or computed at 468 the PLR. Just like any inter-domain TE LSP, depending on the 469 visibility into the subsequent domain, the ERO may comprise of strict 470 and/or loose hops. So, if there are loose hops, backup LSPs would 471 also need to undergo loose hop expansion at nodes other than the PLR. 472 So, the PLR in this case needs to signal the node or link that needs 473 to be excluded for backup computation to other downstream nodes along 474 the backup path. It is also possible that some protection schemes 475 already signal this information in the DETOUR object([FAST-REROUTE]). 476 However, the mechanisms for signaling this are out of scope of this 477 document. [EXCLUDE-ROUTE] discusses one such solution to achieve 478 this. 480 5.1. Fast Recovery support using MPLS TE Fast Reroute (FRR) 482 [FAST-REROUTE] describes two methods for local protection for a 483 packet TE LSP in case of link, SRLG or node failure. This section 484 describes how these mechanisms work with the proposed signaling 485 solutions for inter-domain TE LSP setup. 487 5.1.1. Failure within a domain (link or node failure) 489 The mode of operation of MPLS TE Fast Reroute to protect a 490 contiguous, stitched or nested TE LSP within a domain is identical to 491 the existing procedures described in [FAST-REROUTE]. In case of 492 nested or stitched inter-domain TE LSPs, protecting the intra-domain 493 TE H-LSP or LSP segment will automatically protect the traffic on the 494 inter-domain TE LSP. No new extensions are required for any of the 495 signaling methods. 497 5.1.2. Failure of link at domain boundaries 499 The procedures for doing link protection of the link at domain 500 boundaries is the same for contiguous, nested and stitched TE LSPs. 502 To protect an inter-domain link with MPLS TE Fast Reroute, a set of 503 backup tunnels must be configured or dynamically computed between the 504 two domain boundary nodes diversely routed from the protected inter- 505 domain link. The region connecting two domains may not be TE enabled. 506 In this case, an implementation will have to support the set up of TE 507 LSP over a non-TE enabled region. 509 For each protected inter-domain TE LSP traversing the protected link, 510 a NHOP backup must be selected by a PLR (i.e domain exit boundary 511 router), when the TE LSP is first set up. This requires for the PLR 512 to select a bypass tunnel terminating at the NHOP. Finding the NHOP 513 bypass tunnel of an inter-AS LSP can be achieved by analyzing the 514 content of the RRO object received in the RSVP Resv message of both 515 the bypass tunnel and the protected TE LSP(s). As defined in [RSVP- 516 TE], the addresses specified in the RRO IPv4 subobjects can be node- 517 ids and/or interface addresses (with specific recommendation to use 518 the interface address of the outgoing Path messages). The PLR may or 519 may not have sufficient topology information to find where the backup 520 tunnel intersects the protected TE LSP based on the RRO. [NODE-ID] 521 proposes a solution to this issue, defining an additional RRO IPv4 522 suboject that specifies a node-id address. 524 5.1.3. Failure of a boundary node 526 For each protected inter-domain TE LSP traversing the boundary node 527 to be protected, a NNHOP backup must be selected by the PLR. This 528 requires the PLR to setup a bypass tunnel terminating at the NNHOP. 529 Finding the NNHOP bypass tunnel of an inter-domain TE LSP can be 530 achieved by analyzing the content of the RRO object received in the 531 RSVP Resv message of both the bypass tunnel and the protected TE 532 LSP(s) (see [NODE-ID]). The main difference with node protection, 533 between a protected contiguous inter-domain TE LSP and a protected 534 nested or stitched inter-domain TE LSP is that the PLR and NNHOP (MP) 535 in case of a contiguous TE-LSP could be any node within the domain. 536 However, in case of a nested or stitched TE-LSP the PLR and MP can 537 only be the end-points of the H-LSP or LSP segment. The consequence 538 is that the backup path is likely to be longer and if bandwidth 539 protection is desired, for instance, ([FAST-REROUTE]) more resources 540 may be reserved in the domain than necessary. Note, however, that 541 even for a contiguous LSP, there may be cases where the addresses 542 within the domain could have been masked in the RRO for 543 confidentiality reasons, in which case, the RRO for the contiguous 544 LSP may only contain boundary nodes, and so the MP can only be a 545 boundary node. 547 Also, while a contiguous LSP does allow backup LSPs to terminate 548 inside the domain, there could be policies which may reject an LSP 549 that originates in another domain from carrying addresses in ERO that 550 are local to this domain. In these cases, the backup LSP cannot 551 terminate inside the domain and must terminate only at the boundary 552 node. 554 In case of stitching or nesting, when the node to be protected is the 555 H-LSP/S-LSP tail-end node, the PLR is not immediately upstream of 556 this node. Hence, the failure detection time on failure of H-LSP/S- 557 LSP tail-end node is bound to be longer than that in the case where 558 PLR is immediately upstream of the node to be protected. In such 559 cases, it is RECOMMENDED that the PLR rely on methods proposed in 560 [BFD-MPLS] to rapidly detect H-LSP/S-LSP tail-end node failure. This 561 would help in fast recovery. 563 5.2. Protection and recovery of GMPLS LSPs 565 [SEGMENT-PROTECTION] describes GMPLS based segment recovery. This 566 allows protection against a span failure, a node failure, or failure 567 over any particular portion of a network used by an LSP. The 568 scenarios described above for MPLS Fast reroute also apply to segment 569 protection. No new extensions are needed for segment protection of 570 LSPs that span multiple domains. However, in the inter-domain LSP 571 case, it may not always be possible for the upstream node (outside a 572 domain) to identify end-points of segment recovery LSP in another 573 domain. Even if this was somehow determined, SERO and SRRO in the 574 recovery LSP MUST be subjected to ERO and RRO processing rules as 575 described above, so policy could disallow explicit control of LSP 576 segment recovery inside the domain by a node outside the domain. 577 This is treated as a Segment Protection failure and error handling as 578 described in Section 4.2.1 of [SEGMENT-PROTECTION]. 580 6. Re-optimization of inter-domain TE LSPs 582 Re-optimization of a TE LSP is the process of moving the LSP from the 583 current path to a more prefered path. This usually involves 584 computation of the new prefered path and make-before-break signaling 585 procedures [RSVP-TE], to minimize traffic disruption. The path 586 computation procedures involved in re-optimization of an inter-domain 587 TE LSP are covered in [INTER-DOMAIN-PD-PATH-COMP]. Another option is 588 to use PCE-based mechanisms ([PCE]) for re-optimization. 590 In the context of an inter-domain TE LSP, since the LSP traverses 591 multiple domains, re-optimization may be required in one or more 592 domains at a time. Again, depending on the nature of the LSP and/or 593 policies and configuration at domain boundaries (or other nodes), one 594 may either always want the head-end node of the inter-domain TE LSP 595 to be notified of any local need for re-optimizations and let the 596 head-end initiate the make-before-break process or one may want to 597 restrict local re-optimizations with the domain. 599 [LOOSE-REOPT] describes mechanisms that allow, 601 o The head-end node to trigger on every node whose next hop is 602 a loose hop the re-evaluation of the current path in order to 603 detect a potentially more optimal path. This is done via 604 explicit signaling request: the head-end node sets the 605 "ERO Expansion request" bit of the SESSION-ATTRIBUTE object 606 carried in the RSVP Path message. 608 o A node whose next hop is a loose-hop to signal to the head-end 609 node that a better path exists. This is performed by sending an 610 RSVP PathErr Notify message (error-code = 25), sub-code=6 (Better 611 path exists). This indication may either be sent in response to 612 a query sent by the head-end node or spontaneously by any node 613 having detected a more optimal path. 615 The above mechanisms SHOULD be used for a contiguous inter-domain TE 616 LSP to allow the head-end node of the inter-domain TE LSP to initiate 617 make-before-break procedures. For nested or stitched TE LSPs, it is 618 possible to re-optimize the local H-LSP or LSP segment without 619 involving the head-end node of the inter-domain TE LSP. This will 620 automatically re-route the traffic for the inter-domain TE LSP along 621 the new path, within the domain. Such local re-optimizations, 622 including parameters for re-optimization can be controlled by local 623 policy or configuration in that domain. 625 7. Security Considerations 627 When signaling an inter-domain RSVP-TE LSP, an operator may make use 628 of the already defined security features related to RSVP-TE 629 (authentication). This may require some coordination between the 630 domains to share the keys (see RFC 2747 and RFC 3097). Note that this 631 may involve additional synchronization, should the domain boundary 632 LSR be protected with MPLS TE Fast Reroute, since the merge point 633 should also share the key. 635 For an inter-domain TE LSP, especially when it traverses different 636 administrative or trust domains, the following mechanisms (also see 637 [INTER-AS-TE-REQS]) SHOULD be provided to an operator :- 639 1) a way to enforce policies and filters at the domain boundaries 640 to process the incoming inter-domain TE LSP setup requests 641 (Path messages) based on certain agreed trust and service 642 levels/contracts between domains. Various LSP attributes 643 such as bandwidth, priority; etc could be part of such a 644 contract. 646 2) a way for the operator to rate limit LSP setup requests 647 or error notifications from a particular domain. 649 3) a mechanism to allow policy-based outbound RSVP message 650 processing at the domain boundary LSR, which may involve 651 filtering or modification of certain addresses in RSVP 652 objects and messages. 654 Some examples of the policies described above are:- 656 1) An operator may choose to implement some kind of ERO filtering 657 policy on the domain boundary LSR to disallow or ignore hops 658 within the domain being identified in the ERO of an incoming 659 Path message. 661 2) In order to preserve confidentiality, an operator may choose 662 to disallow recording of hops within the domain in the RRO or 663 may choose to filter out certain recorded RRO addresses at the 664 domain boundary LSR. 666 3) An operator may require the boundary LSR to modify the addresses 667 of certain messages like PathErr or Notify originated from hops 668 within the domain. 670 Note that the detailed specification of such mechanisms (local 671 implementation) is outside the scope of this document. 673 8. IANA Considerations 675 The following values have to be defined by IANA for this document. 676 The registry is, http://www.iana.org/assignments/rsvp-parameters. 678 8.1. Attribute Flags for LSP_ATTRIBUTES object 680 The following new flag bit is being defined for the Attributes Flags 681 TLV in the LSP_ATTRIBUTES object. The numeric value should be 682 assigned by IANA. 684 Contiguous LSP bit - Bit Number 4 (Suggested value) 686 This flag bit is only to be used in the Attributes Flags TLV on a 687 Path message. 689 The "Contiguous LSP" bit has a corresponding "Contiguous LSP 690 signaled" bit (Bit Number 4) to be used in the RRO Attributes sub- 691 object. 693 8.2. New Error Codes 695 The following new error sub-codes are being defined under the RSVP 696 error-code "Routing Problem" (24). The numeric error sub-code value 697 should be assigned by IANA. Suggested values are, 699 1. Contiguous LSP type not supported - sub-code 21 701 2. ERO conflicts with inter-domain signaling method - sub-code 22 703 These error codes are to be used only in a RSVP PathErr. 705 The following new error sub-codes are being defined under the RSVP 706 error-code "Policy control failure" (2). The numeric error sub-code 707 value should be assigned by IANA. Suggested values are, 709 1. Inter-domain policy failure - sub-code 102 711 2. Inter-domain explicit route rejected - sub-code 103 713 9. Acknowledgements 715 The authors would like to acknowledge the input and helpful comments 716 from Adrian Farrel on various aspects discussed in the document. 718 10. References 720 10.1. Normative References 722 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 723 Extensions to OSPF", RFC 3630 (Updates RFC 2370), September 2003. 725 [ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic 726 Engineering", RFC 3784 728 [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 729 3209, December 2001. 731 [RSVP-GMPLS] L. Berger, et al, "Generalized Multi-Protocol Label 732 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 733 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 735 [LSP-HIERARCHY] Kompella K., Rekhter Y., "LSP Hierarchy with 736 Generalized MPLS TE", RFC 4206, October 2005. 738 [LSP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with 739 Generalized MPLS TE", (work in progress). 741 [CRANKBACK] Farrel A. et al, "Crankback Signaling Extensions for MPLS 742 Signaling", (work in progress). 744 [LSP-ATTRIBUTES] Farrel A. et al, "Encoding of Attributes for 745 Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) 746 Establishment Using RSVP-TE", RFC 4420, February 2006. 748 10.2. Informative References 750 [INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering 751 requirements", RFC 4216, November 2005. 753 [INTER-AREA-TE-REQS] LeRoux JL, Vasseur JP, Boyle J. et al, 754 "Requirements for support of Inter-Area MPLS Traffic Engineering", 755 RFC 4105, June 2005. 757 [INTER-DOMAIN-FRAMEWORK] Farrel A. et al, "A Framework for Inter- 758 Domain MPLS Traffic Engineering", (work in progress). 760 [INTER-DOMAIN-PD-PATH-COMP] Vasseur JP., Ayyangar A., Zhang R., "A 761 Per-domain path computation method for computing Inter-domain Traffic 762 Engineering Label Switched Path", (work in progress). 764 [PCE] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation 765 Element (PCE) Architecture", draft-ietf-pce-architecture, work in 766 progress. 768 [GMPLS-OVERLAY] G. Swallow et al, "GMPLS UNI: RSVP-TE Support for the 769 Overlay Model", RFC 4208, October 2005. 771 [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE 772 for LSP Tunnels", RFC 4090, May 2005. 774 [NODE-ID] Vasseur, Ali and Sivabalan, "Definition of an RRO node-id 775 subobject", (work in progress). 777 [SEGMENT-PROTECTION] L. Berger et al, "GMPLS Based Segment Recovery", 778 (work in progress). 780 [BFD-MPLS] R. Aggarwal et al, "BFD For MPLS LSPs", (work in 781 progress). 783 [LOOSE-REOPT] Vasseur JP. et al, "Reoptimization of an explicit 784 loosely routed MPLS TE paths", (work in progress). 786 Appendix 1: Examples 788 This Appendix provides some examples to illustrate the inter-domain 789 signaling procedures described in this document. We consider one 790 example topology which covers inter-domain TE LSP signaling across 791 Autonomous systems. Inter-domain TE LSP signaling across other 792 domains covered by this document are also meant to follow similar 793 signaling procedures, but are not covered here. 795 <-- AS-1 ---> <--- AS-2 ---> <-- AS-3 --> 797 <---BGP---> <---BGP--> 798 CE1---R0----X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 799 | | | | / | / | / | | | 800 | | +-ASBR2----/ ASBR5 | / | | | 801 | | | | | / | | | 802 R1--R2----ASBR3------ASBR6--R4---ASBR8----ASBR10----R7---CE2 804 <================ Inter-AS TE LSP ================> 806 1.1 Assumptions 808 - Three interconnected ASes, respectively AS-1, AS-2, and AS-3. 809 Note that AS3 might be AS1 in some scenarios described in 810 [INTER-AS-TE-REQS]. 812 - The various ASBRs are BGP peers, without any IGP running on the 813 single hop link interconnecting the ASBRs 815 - Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE 816 extensions (see [OSPF-TE] and [ISIS-TE]). In other words, the ASes 817 are TE enabled. Note that each AS can run a different IGP. 819 - Each AS can be made of several areas. In this case, the TE LSP will 820 rely on the inter-area TE techniques to compute and set up a TE LSP 821 traversing multiple IGP areas. For the sake of simplicity, each 822 routing domain will be considered as single area in this document, 823 but the solutions described in this document does not prevent the 824 use of multi-area techniques. In fact, these inter-domain solutions 825 are equally applicable to inter-area TE. 827 - An inter-AS TE LSP T1 originated at R0 in AS1 and terminating 828 at R7 in AS3 with following possible explicit paths: 830 o p1 - path defined by ERO with a set of loose node hops crossing 831 AS-2, ASBR1(loose)-ASBR4(loose)-ASBR7(loose)-ASBR9(loose)-R7(loose) 833 o p2 - path defined by ERO containing a set of strict interface hops 834 crossing AS-2, 835 ASBR1(loose)-link[ASBR1-ASBR4](strict)-link[ASBR4-R3](strict) 836 -link[R3-ASBR7](strict)-link[ASBR7-ASBR9](strict)-R7(loose) 838 o p3 - path defined by ERO containing a set of AS number hops 839 crossing AS-2, 840 ASBR1(loose)-link[ASBR1-ASBR4](strict)-AS3(loose)-R7(loose) 842 - The explicit paths (EROs) may have been configured and/or computed 843 at the head-end node using any of the path computation schemes. 845 1.2 ERO processing 847 Let us consider an inter-AS TE LSP setup from R0 to R7, with example 848 paths p1, p2. In this example, we will examine the behavior on node 849 ASBR4 which is the boundary node for AS-2, for the different 850 signaling methods. 852 Contiguous:- 854 The head-end node, R0, that desires to setup an end-to-end contiguous 855 TE LSP, MAY originate a Path message with LSP_ATTRIBUTES object with 856 the "Contiguous LSP" bit set in the Attributes Flags TLV. 858 For path p1, additional computation to expand the loose hops may be 859 required at various hops along the LSP path. When the Path message 860 arrives at ASBR4, it may carry out a path computation or use some 861 other means to find the intermediate hops to reach ASBR7. It may then 862 adjust the outgoing ERO and forward the Path message through the 863 intermediate hops in AS-2 to ASBR7. 865 For path p2, the ERO next hop points to a node within the domain. 866 ASBR4 will then directly forward the Path message to the next hop in 867 the ERO. 869 For path p3, the ERO nexthop is a loose hop pointing to the 870 subsequent AS number. In this case, ASBR4 will perform path 871 computation to determine the intermediate hops to reach AS-3. It may 872 adjust the ERO based on the computation results. In this case either 873 ASBR7 or ASBR8 may be chosen as the exit points from AS-2. 874 Similarly, either ASBR9 or ASBR10 may be chosen as entry points into 875 AS-3. 877 Nesting and Stitching:- 879 When the Path message for the inter-AS TE LSP from R0 to R7, reaches 880 ASBR4, ASBR4 SHOULD first determine from the ERO hops, the boundary 881 node to the domain along the path. In this example, the domain 882 boundary node for all paths is ASBR7. It SHOULD then use the ERO hops 883 up to ASBR7 to find an existing H-LSP in case of nesting or LSP 884 segment in case of stitching, that satisfies the TE constraints. If 885 there are no existing H-LSPs or LSP segments and ASBR4 is capable of 886 setting up the H-LSP or LSP segment on demand, it SHOULD do so using 887 the ERO hops in the Path message of the inter-domain TE LSP. In 888 either case, ASBR4 will adjust the ERO in the inter-domain TE LSP and 889 will forward the Path message directly to the end-point of the H-LSP 890 or LSP segment using the procedures described in [LSP-HIERARCHY]. 892 In case of path p1, since there are no ERO hops between ASBR4 and 893 ASBR7, and ASBR7 hop is loose, ASBR4 may select any existing H-LSP 894 (nesting) or LSP segment (stitching) that satisfies the constraints 895 or it may compute a path for the H-LSP or LSP segment up to ASBR7 or 896 some other intermediate node in AS-2. 898 In case of path p2, ASBR4 may either select an existing H-LSP or LSP 899 segment with ERO hops link[ASBR4-R3](strict)-link[R3-ASBR7](strict) 900 or it may compute a new path for the H-LSP or LSP segment using the 901 above hops. In either case, the ERO hops for the H-LSP or LSP segment 902 MUST be the same as the signaled strict hops in that domain. 904 Processing of path p3 is similar to p1 except that exit points from 905 AS-2 and entry points into AS-3 are determined as part of path 906 computation. 908 Now, suppose, we have a path p4, defined by an ERO comprising a set 909 of strict node hops crossing AS-2 as shown below, 911 ASBR1(loose)-ASBR4(loose)-ASBR7(strict)-ASBR9(loose)-R7(loose) 913 In this case, the ERO nexthop at ASBR4 is ASBR7(strict). In this 914 case, ASBR4 will try to find or compute a H-LSP or LSP segment 915 directly to ASBR7. 917 The main difference between processing of p1 and p4 for nesting or 918 stitching is that in case of p1, since the ERO nexthop is a loose 919 hop, ASBR4 need not find a H-LSP or LSP segment directly from ASBR4 920 to ASBR7. So, there could be multiple H-LSPs or LSP segments between 921 ASBR4 and ASBR7 terminating and originating on other nodes. On the 922 other hand, for path p4, since the ERO hop to ASBR7 is a strict hop, 923 ASBR4 MUST find or signal a H-LSP or LSP segment that directly 924 connects ASBR4 and ASBR7. 926 1.3 Examples of local protection with MPLS FRR - 928 Let us again consider the example topology above and assume that the 929 TE LSP is now protected. Let us consider the following backup tunnels 930 in the above example, 932 o B1 from ASBR1 to ASBR4 following the path 933 link[ASBR1-ASBR2](strict)-link[ASBR2-ASBR4](strict) and 934 protecting against a failure of the ASBR1-ASBR4 link 936 o B2 from ASBR1 to R3 following the path defined by ERO, 937 link[ASBR1-ASBR2](strict)-link[ASBR2-ASBR3](strict)- 938 link[ASBR3-ASBR6](strict)-link[ASBR6-ASBR5](strict)-R3(strict) 939 and protecting against a failure of the ASBR4 node. 941 o B3 from ASBR1 to ASBR7 following the path defined by ERO, 942 link[ASBR1-ASBR2](strict)-link[ASBR2-ASBR3](strict)- 943 link[ASBR3-ASBR6](strict)-ASBR7(loose) and protecting against 944 a failure of the ASBR4 node. In this case B3 will need additional 945 path computation (loose hop expansion) on ASBR6. 947 o B4 from R3 to ASBR9 following the path defined by ERO, 948 link[R3-R4](strict)-link[R4-ASBR8](strict)-ASBR9(loose) and 949 protecting against a failure of the ASBR7 node. B4 may involve 950 loose hop expansion on ASBR8. 952 o B5 from ASBR4 to ASBR9 following the path defined by ERO, 953 ASBR4-ASBR8(loose)-ASBR9(loose) and protecting against a 954 failure of the ASBR7 node. B5 may involve loose hop expansion 955 on ASBR8. 957 Note that in addition to the ERO for backup tunnels, additional 958 information regarding node/link to exclude may need to be signaled as 959 well if backup tunnel setup involves path computation at nodes other 960 than PLR (say for loose hop expansion). 962 The protected inter-domain TE LSP is an inter-AS TE LSP from R0 to R7 963 with path p1. Also, for nesting or stitching, let us assume that the 964 end-points of the H-LSP or LSP segment in AS-2 are ASBR4 and ASBR7. 965 This gives rise to the following two scenarios for node protection: 967 Protecting the boundary node at the entry to a domain :- 969 Example: protecting against the failure of ASBR4 971 If the inter-AS TE LSP in this example, is a contiguous LSP, then the 972 PLR is ASBR1 and the NNHOP (MP) could be R3 or any other intermediate 973 node along the LSP path, if this information can be gleaned from the 974 RRO. A backup tunnel B2 may be used to protect the inter-AS TE LSP 975 against failure of ASBR4. However, as explained in Section 5.1.3 if 976 RRO information related to R3 has been masked off or if there are 977 restrictions on terminating the backup tunnel inside AS-2, then B2 978 cannot be used. In this case B3 may be used to protect the LSP 979 against failure of ASBR4. 981 If the inter-AS TE LSP in this example, is nested or stitched at 982 ASBR4 into an intra-domain TE H-LSP or LSP segment between ASBR4 and 983 ASBR7, then the PLR is ASBR1 and the NNHOP (MP) is ASBR7. A backup 984 tunnel B3 may be used to protect the inter-AS TE LSP against failure 985 of ASBR4. 987 Protecting the boundary node at the exit of a domain :- 989 Example: protecting against failure of ASBR7. 991 If the inter-AS TE LSP in this example, is a contiguous LSP, then the 992 PLR could be R3 and the NNHOP (MP) is ASBR9. A backup tunnel B4 may 993 be used to protect the inter-AS TE LSP against failure of ASBR7. 995 If the inter-AS TE LSP in this example, is nested or stitched at 996 ASBR4 into an intra-domain TE H-LSP or LSP segment between ASBR4 and 997 ASBR7, then the PLR is ASBR4 and the NNHOP (MP) is ASBR9. A backup 998 tunnel B5 may be used to protect the inter-AS TE LSP against failure 999 of ASBR7. 1001 Author's addresses 1003 Arthi Ayyangar 1004 Juniper Networks, Inc. 1005 1194 N.Mathilda Ave 1006 Sunnyvale, CA 94089 1007 USA 1008 e-mail: arthi@juniper.net 1010 Jean Philippe Vasseur 1011 Cisco Systems, Inc. 1012 300 Beaver Brook Road 1013 Boxborough , MA - 01719 1014 USA 1015 e-mail: jpv@cisco.com 1016 Intellectual Property Statement 1018 The IETF takes no position regarding the validity or scope of any 1019 Intellectual Property Rights or other rights that might be claimed to 1020 pertain to the implementation or use of the technology described in 1021 this document or the extent to which any license under such rights 1022 might or might not be available; nor does it represent that it has 1023 made any independent effort to identify any such rights. Information 1024 on the procedures with respect to rights in RFC documents can be 1025 found in BCP 78 and BCP 79. 1027 Copies of IPR disclosures made to the IETF Secretariat and any 1028 assurances of licenses to be made available, or the result of an 1029 attempt made to obtain a general license or permission for the use of 1030 such proprietary rights by implementers or users of this 1031 specification can be obtained from the IETF on-line IPR repository at 1032 http://www.ietf.org/ipr. 1034 The IETF invites any interested party to bring to its attention any 1035 copyrights, patents or patent applications, or other proprietary 1036 rights that may cover technology that may be required to implement 1037 this standard. Please address the information to the IETF at ietf- 1038 ipr@ietf.org. 1040 Disclaimer of Validity 1042 This document and the information contained herein are provided on an 1043 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1044 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1045 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1046 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1047 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1048 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1050 Copyright Statement 1052 Copyright (C) The Internet Society (2006). This document is subject 1053 to the rights, licenses and restrictions contained in BCP 78, and 1054 except as set forth therein, the authors retain all their rights. 1056 Acknowledgment 1058 Funding for the RFC Editor function is currently provided by the 1059 Internet Society.