idnits 2.17.1 draft-ietf-ccamp-inter-domain-rsvp-te-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 885. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 862. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 875. 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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3209, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 710 has weird spacing: '...message mess...' (Using the creation date from RFC3209, updated by this document, for RFC5378 checks: 1998-11-20) -- 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 2007) is 6311 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4420 (Obsoleted by RFC 5420) ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-loose-path-reopt (ref. 'LOOSE-REOPT') Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Farrel 2 Proposed Status: Standards Track Old Dog Consulting 3 Updates: RFC 3209, RFC 3473 4 Expires: July 2007 A. Ayyangar 5 Nuova Systems 7 JP. Vasseur 8 Cisco Systems, Inc. 10 January 2007 12 Inter domain MPLS and GMPLS Traffic Engineering - RSVP-TE extensions 14 draft-ietf-ccamp-inter-domain-rsvp-te-04.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document describes procedures and protocol extensions for the 42 use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE) 43 signaling in Multiprotocol Label Switching Traffic Engineering 44 (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and 45 non-packet networks to support the establishment and maintenance of 46 Label Switched Paths that cross domain boundaries. 48 For the purpose of this document, a domain is considered to be any 49 collection of network elements within a common realm of address space 50 or path computation responsibility. Examples of such domains include 51 Autonomous Systems, IGP routing areas, and GMPLS overlay networks. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1 Conventions Used In This Document . . . . . . . . . . . . 3 57 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Signaling Overview . . . . . . . . . . . . . . . . . . . . . 4 59 2.1 Signaling Options . . . . . . . . . . . . . . . . . . . . 4 60 3. Procedures on the Domain Border Node . . . . . . . . . . . . . 5 61 3.1 Rules on ERO Processing . . . . . . . . . . . . . . . . . 6 62 3.2 LSP Setup Failure and Crankback . . . . . . . . . . . . . 8 63 3.3 RRO Processing Across Domains . . . . . . . . . . . . . . 8 64 3.4 Notify Message Processing . . . . . . . . . . . . . . . . 9 65 4. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . . . 9 66 4.1 Control of Downstream Choice of Signaling Method . . . . . 9 67 5. Protection and Recovery of Inter-Domain TE LSPs . . . . . . . 10 68 5.1 Fast Recovery Support Using MPLS-TE Fast Reroute . . . . . 11 69 5.1.1 Failure Within a Domain (Link or Node Failure) . . . . 11 70 5.1.2 Failure of Link at Domain Borders . . . . . . . . . . 11 71 5.1.3 Failure of a Border Node . . . . . . . . . . . . . . . 12 72 5.2 Protection and Recovery of GMPLS LSPs . . . . . . . . . . 12 73 6. Re-Optimization of Inter-Domain TE LSPs . . . . . . . . . . . 13 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 8.1 Attribute Flags for LSP_Attributes Object . . . . . . . . 15 77 8.2 New Error Codes . . . . . . . . . . . . . . . . . . . . . 15 78 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 10.1 Normative References . . . . . . . . . . . . . . . . . . 15 81 10.2 Informative References . . . . . . . . . . . . . . . . . 16 82 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 The requirements for inter-area and inter-AS Multiprotocol Label 87 Switching (MPLS) Traffic Engineering (TE) are stated in [RFC4105] and 88 [RFC4216] respectively. Many of these requirements also apply to 89 Generalized MPLS (GMPLS) networks. The framework for inter-domain 90 MPLS-TE is provided in [INTER-DOMAIN-FRAMEWORK]. 92 This document presents procedures and extensions to Resource 93 Reservation Protocol Traffic Engineering (RSVP-TE) signaling for the 94 setup and maintenance of traffic engineered Label Switched Paths (TE 95 LSPs) that span multiple domains in MPLS-TE or GMPLS networks. The 96 signaling procedures described in this document are applicable to 97 MPLS-TE packet LSPs established using RSVP-TE ([RFC3209]) and all 98 LSPs (packet and non-packet) that use RSVP-TE GMPLS extensions as 99 described in [RFC3473]. 101 Three different signaling methods for inter-domain RSVP-TE signaling 102 are identified in [INTER-DOMAIN-FRAMEWORK]. Contiguous LSPs are 103 achieved using the procedures of [RFC3209] and [RFC3473] to create a 104 single end-to-end LSP that spans all domains. Nested LSPs are 105 established using the techniques described in [RFC4206] to carry the 106 end-to-end LSP in a separate tunnel across each domain. Stitched LSPs 107 are established using the procedures of [LSP-STITCHING] to construct 108 an end-to-end LSP from the concatenation of separate LSPs each 109 spanning a domain. 111 This document defines the RSVP-TE protocol extensions necessary to 112 control and select which of the three signaling mechanisms is used 113 for any one end-to-end inter-domain TE LSP. 115 For the purpose of this document, a domain is considered to be any 116 collection of network elements within a common realm of address space 117 or path computation responsibility. Examples of such domains include 118 Autonomous Systems, IGP areas, and GMPLS overlay networks 119 ([RFC4208]). 121 1.1. Conventions Used In This Document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 1.2. Terminology 129 AS: Autonomous System. 131 ASBR: routers used to connect together ASes of a different or the 132 same Service Provider via one or more Inter-AS links. 134 Bypass Tunnel: an LSP that is used to protect a set of LSPs passing 135 over a common facility. 137 ERO: Explicit Route Object. 139 FA: Forwarding Adjacency. 141 LSR: Label Switching Router. 143 MP: Merge Point. The node where bypass tunnels meet the protected 144 LSP. 146 NHOP bypass tunnel: Next-Hop Bypass Tunnel. A backup tunnel, which 147 bypasses a single link of the protected LSP. 149 NNHOP bypass tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel, 150 which bypasses a single node of the protected LSP. 152 PLR: Point of Local Repair. The ingress of a bypass tunnel. 154 RRO: Record Route Object. 156 TE link: Traffic Engineering link. 158 2. Signaling Overview 160 The RSVP-TE signaling of a TE LSP within a single domain is described 161 in [RFC3209] and [RFC3473]. Inter-domain TE LSPs can be supported by 162 one of three options as described in the next section: 163 - contiguous LSPs 164 - nested LSPs 165 - stitched LSPs. 167 This document describes the RSVP-TE signaling extensions required to 168 control and select which of the three signaling mechanisms is used 169 for any one end-to-end inter-domain TE LSP. 171 The specific protocol extensions required to signal each LSP type are 172 described in other documents and are out of scope for this document. 173 Similarly, the routing extensions and path computation techniques 174 necessary for the establishment of inter-domain LSPs are out of 175 scope. 177 2.1. Signaling Options 179 There are three ways in which an RSVP-TE LSP could be signaled across 180 multiple domains: 182 Contiguous 183 A contiguous TE LSP is a single end-to-end TE LSP that is set up 184 across multiple domains using RSVP-TE signaling procedures 185 described in [RFC3209] and [RFC3473]. No additional TE LSPs are 186 required to create a contiguous TE LSP and the same RSVP-TE 187 information for the TE LSP is maintained along the entire LSP 188 path. In particular, the TE LSP has the same RSVP-TE session and 189 LSP ID at every LSR along its path. 191 Nesting 192 One or more TE LSPs may be nested within another TE LSP as 193 described in [RFC4206]. This technique can be used to nest one 194 or more inter-domain TE LSPs into an intra-domain hierarchical LSP 195 (H-LSP). The label stacking construct is used to achieve nesting 196 in packet networks. In the rest of this document, the term H-LSP 197 is used to refer to an LSP that allows other LSPs to be nested 198 within it. An H-LSP may be advertised as a TE link within the same 199 instance of the routing protocol as was used to advertise the TE 200 links from which it was created, in which case it is a Forwarding 201 Adjacency (FA) [RFC4206]. 203 Stitching 204 The concept of LSP stitching as well as the required signaling 205 procedures is described in [LSP-STITCHING]. This technique can be 206 used to stitch together shorter LSPs (LSP segments) to create a 207 single, longer LSP. The LSP segments of an inter-domain LSP may be 208 intra-domain LSPs or inter-domain LSPs. 210 The process of stitching in the data plane results in a single, 211 end-to-end contiguous LSP. But in the control plane each segment is 212 signaled as a separate LSP (with distinct RSVP sessions) and the 213 end-to-end LSP is signaled as yet another LSP with its own RSVP 214 session. Thus the control plane operation for LSP stitching is very 215 similar to that for nesting. 217 An end-to-end inter-domain TE LSP may be achieved using one or more 218 of the signaling techniques described. The choice is a matter of 219 policy for the node requesting LSP setup (the ingress) and policy for 220 each successive domain border node. On receipt of an LSP setup 221 request (RSVP-TE Path message) for an inter-domain TE LSP, the 222 decision of whether to signal the LSP contiguously or whether to nest 223 or stitch it to another TE LSP, depends on the parameters signaled 224 from the ingress node and on the configuration of the local node. 226 The stitching segment LSP or H-LSP used to cross a domain may be 227 pre-established or signaled dynamically based on the demand caused by 228 the arrival of the inter-domain TE LSP setup request. 230 3. Procedures on the Domain Border Node 232 Whether an inter-domain TE LSP is contiguous, nested, or stitched is 233 limited by the signaling methods supported by or configured on the 234 intermediate nodes, and it is usually the domain border nodes where 235 this restriction applies since other transit nodes are oblivious to 236 the mechanism in use. The ingress of the LSP may further restrict the 237 choice by setting parameters in the Path message when it is signaled. 239 When a domain border node receives the RSVP Path message for an 240 inter-domain TE LSP setup, it MUST carry out the following procedures 241 before it can forward the Path message to the next node along the 242 path: 244 1. Apply policies for the domain and the domain border node. These 245 policies may restrict the establishment of inter-domain TE LSPs. 246 In case of a policy failure, the node SHOULD fail the setup and 247 send a PathErr message with error code "Policy control failure"/ 248 "Inter-domain policy failure". 250 2. Determine the signaling method to be used to cross the domain. 251 If the ingress node of the inter-domain TE LSP has specified 252 restrictions on the methods to be used, these MUST be adhered 253 to. Within the freedom allowed by the ingress node, the domain 254 border node MAY choose any method according to local 255 configuration and policies. If no resultant signaling method is 256 available or allowed, the domain border node MUST send a PathErr 257 message an error code as described in Section 4.1. 259 3. Carry out ERO procedures as described in the Section 3 in 260 addition to the procedures in [RFC3209] and [RFC3473]. 262 4. Perform any path computations as required to determine the path 263 across the domain and potentially to select the exit point from 264 the domain. 266 The path computation procedure is outside the scope of this 267 document. A path computation option is supplied in 268 [INTER-DOMAIN-PD-PATH-COMP], and another option is to use a 269 Path Computation Element (PCE) [RFC4655]. 271 4a. In the case of nesting or stitching, either find an existing 272 intra-domain TE LSP to carry the inter-domain TE LSP or 273 signal a new one, depending on local policy. 275 In event of a path computation failure, a PathErr message SHOULD 276 be sent with error code "Routing Problem" using an error value 277 selected according to the reason for computation failure. 279 In the event of the receipt of a PathErr message reporting 280 signaling failure from within the domain or reported from a 281 downstream domain, the domain border node MAY apply crankback 282 procedures as described in Section 3.2. If crankback is not 283 applied, or is exhausted, the border node MUST continue with 284 PathErr processing as described in [RFC3209] and [RFC3473]. 286 In the event of successful processing of a Path or Resv message, 287 the domain border node MUST carry out RRO procedures as described 288 in Section 3.3. 290 3.1. Rules on ERO Processing 292 The ERO that a domain border node receives in the Path message was 293 supplied by the ingress node of the TE LSP and may have been updated 294 by other nodes (for example, other domain border nodes) as the Path 295 message was propagated. The content of the ERO depends on several 296 factors including: 298 - the path computation techniques used 299 - the degree of TE visibility available to the nodes performing 300 path computation 301 - policy at the nodes creating/modifying the ERO. 303 In general, H-LSPs and LSP segments are used between domain border 304 nodes, but there is no restriction on the use of such LSPs to span 305 multiple hops entirely within a domain. Therefore, the discussion 306 that follows may be equally applied to any node within a domain 307 although the term 'domain border node' continues to be used for 308 clarity. 310 When a Path message reaches the domain border node, the following 311 rules SHOULD be used for ERO processing and for further signaling. 313 1. If there are any policies related to ERO processing for the 314 LSP, they SHOULD be applied and corresponding actions taken. For 315 example, there might be a policy to reject EROs that identify 316 nodes within the domain. In case of inter-domain LSP setup 317 failures due to policy failures related to ERO processing, the 318 node SHOULD issue a PathErr with error code "Policy control 319 failure"/"Inter-domain explicit route rejected". 321 2. Section 8.2 of [RFC4206] describes how a node at the edge of a 322 region processes the ERO in the incoming Path message and uses 323 this ERO, to either find an existing H-LSP or signal a new H-LSP 324 using the ERO hops. This process includes adjusting the ERO 325 before sending the Path message to the next hop. These 326 procedures SHOULD be followed for nesting or stitching of 327 inter-domain TE LSPs. 329 3. If an ERO subobject identifies a TE link formed by the 330 advertisement of an H-LSP or LSP segment (whether numbered or 331 unnumbered), contiguous signaling MUST NOT be used. The node MUST 332 either use nesting or stitching according to the capabilities of 333 the LSP that forms the TE link, the parameters signaled in the 334 Path message, and local policy. If there is a conflict between the 335 capabilities of the LSP that forms the TE link indicated in the 336 ERO and the parameters on the Path message, the domain border node 337 SHOULD send a PathErr with error code "Routing Problem"/"ERO 338 conflicts with inter-domain signaling method". 340 4. An ERO in a Path message received by a domain border node may 341 have a loose hop as the next hop. This may be an IP address or 342 an AS number. In such cases, the ERO MUST be expanded to 343 determine the path to the next hop using some form of path 344 computation that may, itself, generate loose hops. 346 5. In the absence of any ERO subobjects beyond the local domain 347 border node, the LSP egress (the destination encoded in the RSVP 348 Session object) MUST be considered as the next loose hop and 349 rule 4 applied. 351 6. In the event of any other failures processing the ERO, a PathErr 352 message SHOULD be sent as described in [RFC3209] or [RFC3473]. 354 3.2. LSP Setup Failure and Crankback 356 When an error occurs during LSP setup a PathErr message is sent back 357 towards the LSP ingress node to report the problem. If the LSP 358 traverses multiple domains, this PathErr will be seen successively by 359 each domain border node. 361 Domain border nodes MAY apply local policies to restrict the 362 propagation of information about the contents of the domain. For 363 example, a domain border node MAY replace the information in a 364 PathErr message that indicates a specific failure at a specific node 365 with information that report a more general error with the entire 366 domain. These procedures are similar to those described for the 367 borders of overlay networks in [RFC4208]. 369 However: 370 - A domain border node MUST NOT suppress the propagation of a PathErr 371 message 372 - Nodes other than domain border nodes SHOULD NOT modify the contents 373 of a PathErr message 374 - Domain border nodes SHOULD NOT modify the contents of a PathErr 375 message unless domain confidentiality is a specific requirement. 377 Domain border nodes provide an opportunity for crankback rerouting 378 [CRANKBACK]. On receipt of a PathErr message generated because of an 379 LSP setup failure, a domain border node MAY hold the PathErr and make 380 further attempts to establish the LSP if allowed by local policy and 381 by the parameters signaled on the Path message for the LSP. Such 382 attempts might involve the computation of alternate routes through 383 the domain, or the selection of different downstream domains. If a 384 subsequent attempt is successful, the domain border router MUST 385 discard the held PathErr message, but if all subsequent attempts are 386 unsuccessful, the domain border router MUST send the PathErr upstream 387 toward the ingress node. In this latter case, the domain border 388 router MAY change the information in the PathErr message to provide 389 further crankback details and information aggregation as described 390 in [CRANKBACK]. 392 Crankback rerouting MAY also be used to handle the failure of LSPs 393 after they have been established [CRANKBACK]. 395 3.3. RRO Processing Across Domains 397 [RFC3209] defines the RRO as an optional used for loop detection and 398 for providing information about the hops traversed by LSPs. 400 As described for overlay networks in [RFC4208], a domain border node 401 MAY filter or modify the information provided in an RRO for 402 confidentiality reasons according to local policy. For example, a 403 series of identifiers of hops within a domain MAY be replaced with 404 the domain identifier (such as the AS number) or be removed entirely 405 leaving just the domain border nodes. 407 Note that a domain border router MUST NOT mask its own presence, and 408 MUST include itself in the RRO. 410 Such filtering of RRO information does not hamper the working of the 411 signaling protocol, but the subsequent information loss may render 412 management diagnostic procedures inoperable or at least make them 413 more complicated requiring the coordination of administrators of 414 multiple domains. 416 Similarly protocol procedures that depend on the presence of RRO 417 information may become inefficient. For example, the fast reroute 418 procedures defined in [RFC4090] use information in the RRO to 419 determine the labels to use and the downstream MP. 421 3.4. Notify Message Processing 423 Notify messages are introduced in [RFC3473]. They may be sent direct 424 rather than hop-by-hop, and so may speed the propagation of error 425 information. If a domain border router is interested in seeing 426 such messages (for example, to enable it to provide protection 427 switching), it is RECOMMENDED that the domain border router update 428 the Notify Request objects in the Path and Resv messages to show its 429 own address following the procedures of [RFC3473]. 431 4. RSVP-TE Signaling Extensions 433 The following RSVP-TE signaling extensions are defined to enable 434 inter-domain LSP setup. 436 4.1. Control of Choice of Signaling Method 438 In many network environments there may be a network-wide policy that 439 determines which one of the three inter-domain LSP techniques is 440 used. In these cases, no protocol extensions are required. 442 However, in environments that support more than one technique, an 443 ingress node may wish to constrain the choice made by domain border 444 nodes for each inter-domain TE LSP that it originates. 446 [RFC4420] defines the LSP_Attributes object that can be used to 447 signal required attributes of an LSP. The Attributes Flags TLV 448 includes Boolean flags that define individual attributes. 450 This document defines a new bit in the TLV that can be set by the 451 ingress node of an inter-domain TE LSP to restrict the intermediate 452 nodes to using contiguous signaling. 454 Contiguous LSP bit (bit number assignment in Section 8.1). 456 This flag is set by the ingress node that originates a Path message 457 to set up an inter-domain TE LSP if it requires that the contiguous 458 LSP technique is used. This flag bit is only to be used in the 459 Attributes Flags TLV. 461 When an LSR receives a Path message containing this bit set (one), 462 the node MUST NOT perform stitching or nesting in support of the TE 463 LSP being set up. When this bit is clear (zero), an intermediate node 464 MAY perform stitching or nesting according to local policy. 466 This bit MUST NOT be modified by any transit node. 468 An intermediate node that supports the LSP_Attributes object and the 469 Attributes Flags TLV, and also recognizes the "Contiguous LSP" bit, 470 but cannot support contiguous TE LSPs, MUST send a Path Error message 471 with an error code "Routing Problem"/"Contiguous LSP type not 472 supported" if it receives a Path message with this bit set. 474 If an intermediate node receiving a Path message with the "Contiguous 475 LSP" bit set in the Flags field of the LSP_Attributes, recognizes the 476 object, the TLV and the bit and also supports the desired contiguous 477 LSP behavior, then it MUST signal a contiguous LSP. If the node is a 478 domain border node, or if the node expands a loose hop in the ERO, it 479 SHOULD include an RRO Attributes subobject in the RRO of the 480 corresponding Resv message with the "Contiguous LSP" bit set to 481 report its behavior. 483 However, if the intermediate node supports the LSP_Attributes object 484 but does not recognize the Attributes Flags TLV, or supports the TLV 485 but does not recognize this "Contiguous LSP" bit, then it MUST reject 486 the Path message with a PathErr message as described in [RFC4420]. 488 The choice of action by an ingress node that receives a PathErr when 489 requesting the use of a contiguous LSP is out of the scope of this 490 document, but may include the computation of an alternate path. 492 5. Protection and Recovery of Inter-Domain TE LSPs 494 The procedures described in Sections 3 and 4 MUST be applied to all 495 inter-domain TE LSPs, including bypass tunnels, detour LSPs 496 [RFC4090], and segment recovery LSPs [SEGMENT-PROTECTION]. This means 497 that these LSPs will also be subjected to ERO processing, policies, 498 path computation, etc. 500 Note also that the paths for these backup LSPs needs to be either 501 pre-configured, computed and signaled with the protected LSP, or 502 computed on-demand at the PLR. Just as with any inter-domain TE LSP, 503 the ERO may comprise of strict or loose hops, and will depend on the 504 TE visibility of the computation point into the subsequent domain. 506 If loose hops are required created in the path of the backup LSP, ERO 507 expansion will be required at some point along the path: probably at 508 a domain border node. In order that the backup path remains disjoint 509 from the protected LSP(s) the node performing the ERO expansion must 510 be provided with the path of the protected LSPs between the PLR and 511 the MP. This information can be gathered from the RROs of the 512 protected LSPs and is signaled in the DETOUR object for Fast Reroute 513 [RFC4090], and using route exclusion [EXCLUDE-ROUTE] for other 514 protection schemes. 516 5.1. Fast Recovery Support Using MPLS-TE Fast Reroute (FRR) 518 [RFC4090] describes two methods for local protection for a 519 packet TE LSP in case of link, SRLG, or node failure. This section 520 describes how these mechanisms work with the proposed signaling 521 solutions for inter-domain TE LSP setup. 523 5.1.1. Failure Within a Domain (Link or Node Failure) 525 The mode of operation of MPLS-TE Fast Reroute to protect a 526 contiguous, stitched or nested TE LSP within a domain is identical to 527 the existing procedures described in [RFC4090]. Note that, in the 528 case of nesting or stitching, the end-to-end LSP is automatically 529 protected by the protection operation performed on the H-LSP or 530 stitching segment LSP. 532 No protocol extensions are required. 534 5.1.2. Failure of a Link at a Domain Borders 536 This cases arises where two domains are connected by a TE link. In 537 this case each domain has its own domain border node, and these two 538 nodes are connected by the TE link. An example of this case is where 539 the ASBRs of two ASes are connected by a TE link. 541 A contiguous LSP can be backed up using any PLR and MP, but if the 542 LSP uses stitching or nesting in either of the connected domains, the 543 PLR and MP MUST be domain border nodes for those domains. It will be 544 usual to attempt to use the local (connected by the filed link) 545 domain border nodes as the PLR and MP. 547 To protect an inter-domain link with MPLS-TE Fast Reroute, a set of 548 backup tunnels must be configured or dynamically computed between the 549 PLR and MP such that they are diversely routed from the protected 550 inter-domain link and the protected inter-domain LSPs. 552 Each protected inter-domain LSP using the protected inter-domain TE 553 link must be assigned to an NHOP bypass tunnel that is diverse from 554 the protected LSP. Such an NHOP bypass tunnel can be selected by 555 analyzing the RROs in the Resv messages of the available bypass 556 tunnels and the protected TE LSP. It may be helpful to this process 557 if the extensions defined in [NODE-ID] are used to clearly 558 distinguish nodes and links in the RROs. 560 5.1.3. Failure of a Border Node 562 Two border node failure cases exist. If the domain border falls on a 563 link as described in the previous section, the border node at either 564 end of the link may fail. Alternatively, if the border falls on a 565 border node (as is the case with IGP areas) that single border node 566 may fail. 568 It can be seen that if stitching or nesting are used, the failed node 569 will be the start or end (or both) or a stitching segment LSP or 570 H-LSP in which case, protection must be provided to the far end of 571 stitching segment or H-LSP. Thus, where one of these two techniques 572 is in use, the PLR will be the upstream domain entry point in the 573 case of the failure of the domain exit point, and the MP will be the 574 downstream domain exit point in the case of the failure of the 575 domian entry point. Where the domain border falls at a single domain 576 border node, both cases will apply. 578 If the contiguous LSP mechanism is in use, normal selection of the 579 PLR and MP can be applied and any node within the domains may be used 580 to fill these roles. 582 As before, selection of a suitable backup tunnel (in this case an 583 NNHOP backup) must consider the paths of the backed up LSPs and the 584 available NNHOP tunnels by examination of their RROs. 586 Note that where the PLR is not immediately upstream of the failed 587 node, error propagation time may be delayed unless some mechanism 588 such as [BFD-MPLS] is implemented, or unless direct reporting, such 589 as through the GMPLS Notify message [RFC3473] is employed. 591 5.2. Protection and Recovery of GMPLS LSPs 593 [SEGMENT-PROTECTION] describes GMPLS based segment recovery. This 594 allows protection against a span failure, a node failure, or failure 595 over any particular portion of a network used by an LSP. 597 The domain border failure cases described in Section 5.1 may also 598 occur in GMPLS networks (including packet networks) and can be 599 protected against using segment protection without any additional 600 protocol extensions. 602 Note that if loose hops are used in the construction of the working 603 and protection paths signaled for segment protection then care is 604 required to keep these paths disjoint. If the paths are signaled 605 incrementally then route exclusion [EXCLUDE-ROUTE] may be used to 606 ensure that the paths are disjoint. Otherwise a coordinated path 607 computation technique such as that offered by cooperating Path 608 Computation Elements [RFC4655] can provide suitable paths. 610 6. Re-Optimization of Inter-Domain TE LSPs 612 Re-optimization of a TE LSP is the process of moving the LSP from the 613 current path to a preferable path. This involves the determination of 614 the preferred path and make-before-break signaling procedures 615 [RFC3209] to minimize traffic disruption. 617 Re-optimization of an inter-domain TE LSP may require a new path in 618 more than one domain. 620 The nature of the inter-domain LSP setup mechanism defines how 621 re-optimization can be applied. If the LSP is contiguous then the 622 signaling of the make-before-break process MUST be initiated by the 623 ingress node as defined in [RFC3209]. But if the re-optimization is 624 limited to a change in path within one domain (that is, if there is 625 no change to the domain border nodes) and nesting or stitching are in 626 use, the H-LSP or stitching segment may be independently re-optimized 627 within the domain without impacting the end-to-end LSP. 629 In all cases, however, the ingress LSP may wish to exert control and 630 coordination over the re-optimization process. 632 [LOOSE-REOPT] describes mechanisms that allow: 634 - The ingress node to request each node with a loose next hop to 635 re-evaluate the current path in order search for a more optimal 636 path. 638 - A node with a loose next hop to inform the ingress node that a 639 better path exists. 641 These mechanisms SHOULD be used for re-optimization of a contiguous 642 inter-domain TE LSP. 644 7. Security Considerations 646 A separate document is being prepared to examine the security aspects 647 of RSVP-TE signaling with special reference to multi-domain 648 scenarios. [INTER-DOMAIN-FRAMEWORK] provides an overview of the 649 requirements for security in an MPLS-TE or GMPLS multi-domain 650 environment. 652 When signaling an inter-domain RSVP-TE LSP, an operator may make use 653 of the security features already defined for RSVP-TE [RFC3209]. This 654 may require some coordination between the domains to share the keys 655 (see [RFC2747] and [RFC3097]), and care is required to ensure that 656 the keys are changed sufficiently frequently. Note that this may 657 involve additional synchronization, should the domain border nodes 658 be protected with FRR, since the MP and PLR should also share the 659 key. 661 For an inter-domain TE LSP, especially when it traverses different 662 administrative or trust domains, the following mechanisms SHOULD be 663 provided to an operator (also see [RFC4216]): 665 1) A way to enforce policies and filters at the domain borders 666 to process the incoming inter-domain TE LSP setup requests 667 (Path messages) based on certain agreed trust and service 668 levels/contracts between domains. Various LSP attributes 669 such as bandwidth, priority, etc. could be part of such a 670 contract. 672 2) A way for the operator to rate-limit LSP setup requests 673 or error notifications from a particular domain. 675 3) A mechanism to allow policy-based outbound RSVP message 676 processing at the domain border node, which may involve 677 filtering or modification of certain addresses in RSVP 678 objects and messages. 680 Some examples of the policies described above are:- 682 A) An operator may choose to implement some kind of ERO filtering 683 policy on the domain border node to disallow or ignore hops 684 within the domain from being identified in the ERO of an 685 incoming Path message. 687 B) In order to preserve confidentiality of network topology, an 688 operator may choose to disallow recording of hops within the 689 domain in the RRO or may choose to filter out certain recorded 690 RRO addresses at the domain border node. 692 C) An operator may require the border node to modify the addresses 693 of certain messages like PathErr or Notify originated from hops 694 within the domain. 696 Note that the detailed specification of such policies and their 697 implementation are outside the scope of this document. 699 8. IANA Considerations 701 IANA is requested to make the codepoint allocations described in the 702 following sections. 704 8.1. Attribute Flags for LSP_Attributes Object 706 A new bit is to be allocated from the "Attributes Flags" sub-registry 707 of the "RSVP TE Parameters" registry. 709 Path Resv RRO 710 Bit Name message message sub-object 711 ---- ------------------------------- -------- -------- ---------- 712 XX Contiguous LSP Yes No Yes 714 The value XX is to be defined by IANA. A value of 4 is suggested. 716 8.2. New Error Codes 718 New RSVP error codes/values are required to be allocated from the 719 "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry 720 of the "RSVP Parameters" registry. 722 For the existing error code "Policy control failure" (value 2), two 723 new error values are suggested as follows. The values are suggested 724 and are for IANA determination. 726 103 = Inter-domain policy failure 727 104 = Inter-domain explicit route rejected 729 For the existing error code "Routing Problem" (value 24), two new 730 error values are suggested as follows. The values are suggested and 731 are for IANA determination. 733 21 = Contiguous LSP type not supported 734 22 = ERO conflicts with inter-domain signaling method 736 9. Acknowledgements 738 The authors would like to acknowledge the input and helpful comments 739 from Kireeti Kompella on various aspects discussed in the document. 741 10. References 743 10.1. Normative References 745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, March 1997. 748 [RFC3209] Awduche, D., et al, "Extensions to RSVP for LSP Tunnels", 749 RFC 3209, December 2001. 751 [RFC3473] Berger, L., et al, "Generalized Multi-Protocol Label 752 Switching (GMPLS) Signaling Resource ReserVation Protocol - 753 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 754 January 2003. 756 [RFC4206] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized 757 MPLS TE", RFC 4206, October 2005. 759 [RFC4420] Farrel, A., et al, "Encoding of Attributes for 760 Multiprotocol Label Switching (MPLS) Label Switched Path 761 (LSP) Establishment Using RSVP-TE", RFC 4420, February 762 2006. 764 [LOOSE-REOPT] Vasseur, JP., et al, "Reoptimization of Multiprotocol 765 Label Switching (MPLS) Traffic Engineering (TE) loosely 766 routed Label Switch Path (LSP)", 767 draft-ietf-ccamp-loose-path-reopt, (work in progress). 769 [LSP-STITCHING] Ayyangar, A., Kompella, K., and Vasseur, JP., "Label 770 Switched Path Stitching with Generalized MPLS Traffic 771 Engineering", draft-ietf-ccamp-lsp-stitching, (work in 772 progress). 774 10.2. Informative References 776 [RFC2747] Baker, F., Lindell, B., and Talwar, B., "RSVP Cryptographic 777 Authentication", RFC 2747, January 2000. 779 [RFC3097] Braden, R., and Zhang, L., "RSVP Cryptographic 780 Authentication -- Updated Message Type Value", RFC 3097, 781 April 2001. 783 [RFC4090] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE 784 for LSP Tunnels", RFC 4090, May 2005. 786 [RFC4105] LeRoux, JL., Vasseur, JP., Boyle, J., et al, "Requirements 787 for Inter-Area MPLS Traffic Engineering", RFC 4105, June 788 2005. 790 [RFC4208] G. Swallow et al, "GMPLS UNI: RSVP-TE Support for the 791 Overlay Model", RFC 4208, October 2005. 793 [RFC4216] Zhang, R., et al, "MPLS Inter-Autonomous System (AS) 794 Traffic Engineering (TE) Requirements", RFC 4216, November 795 2005. 797 [RFC4655] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation 798 Element (PCE)-Based Architecture", RFC 4655, August 2006. 800 [BFD-MPLS] Aggarwal, R., et al, "BFD For MPLS LSPs", 801 draft-ietf-bfd-mpls, (work in progress). 803 [CRANKBACK] Farrel, A., et al, "Crankback Signaling Extensions for 804 MPLS and GMPLS RSVP-TE", draft-ietf-ccamp-crankback, (work 805 in progress). 807 [EXCLUDE-ROUTE] Lee, CY., Farrel, A., and De Cnodder, S., "Exclude 808 Routes - Extension to RSVP-TE", 809 draft-ietf-ccamp-rsvp-te-exclude-route, (work in progress). 811 [INTER-DOMAIN-FRAMEWORK] Farrel, A., et al, "A Framework for 812 Inter-Domain MPLS Traffic Engineering", 813 draft-ietf-ccamp-inter-domain-framework, (work in 814 progress). 816 [INTER-DOMAIN-PD-PATH-COMP] Vasseur, JP., Ayyangar, A., and 817 Zhang, R., "A Per-domain path computation method for 818 computing Inter-domain Traffic Engineering (TE) Label 819 Switched Paths (LSPs)", 820 draft-ietf-ccamp-inter-domain-pd-path-comp, (work in 821 progress). 823 [NODE-ID] Vasseur, JP., Ali, Z., and Sivabalan, S., "Definition of an 824 RRO node-id subobject", draft-ietf-mpls-nodeid-subobject, 825 (work in progress). 827 [SEGMENT-PROTECTION] Berger, L., et al, "GMPLS Based Segment 828 Recovery", draft-ietf-ccamp-gmpls-segment-recovery, (work 829 in progress). 831 11. Authors' Addresses 833 Adrian Farrel 834 Old Dog Consulting 836 E-mail: adrian@olddog.co.uk 838 Arthi Ayyangar 839 Nuova Systems 840 2600 San Tomas Expressway 841 Santa Clara, CA 95051 842 US 844 Email: arthi@nuovasystems.com 845 Jean Philippe Vasseur 846 Cisco Systems, Inc. 847 300 Beaver Brook Road 848 Boxborough , MA - 01719 849 USA 851 Email: jpv@cisco.com 853 Intellectual Property Statement 855 The IETF takes no position regarding the validity or scope of any 856 Intellectual Property Rights or other rights that might be claimed to 857 pertain to the implementation or use of the technology described in 858 this document or the extent to which any license under such rights 859 might or might not be available; nor does it represent that it has 860 made any independent effort to identify any such rights. Information 861 on the procedures with respect to rights in RFC documents can be 862 found in BCP 78 and BCP 79. 864 Copies of IPR disclosures made to the IETF Secretariat and any 865 assurances of licenses to be made available, or the result of an 866 attempt made to obtain a general license or permission for the use of 867 such proprietary rights by implementers or users of this 868 specification can be obtained from the IETF on-line IPR repository at 869 http://www.ietf.org/ipr. 871 The IETF invites any interested party to bring to its attention any 872 copyrights, patents or patent applications, or other proprietary 873 rights that may cover technology that may be required to implement 874 this standard. Please address the information to the IETF at ietf- 875 ipr@ietf.org. 877 Disclaimer of Validity 879 This document and the information contained herein are provided on an 880 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 881 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 882 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 883 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 884 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 885 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 887 Copyright Statement 889 Copyright (C) The IETF Trust (2007). 891 This document is subject to the rights, licenses and restrictions 892 contained in BCP 78, and except as set forth therein, the authors 893 retain all their rights.