idnits 2.17.1 draft-takeda-ccamp-inter-domain-recovery-analysis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 999. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 970. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 977. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 983. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (October 2006) is 6402 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) ** Downref: Normative reference to an Informational RFC: RFC 4427 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Tomonori Takeda 3 Internet Draft NTT 4 Proposed Status: Informational Yuichi Ikejiri 5 Expires: April 2007 NTT Communications 6 Adrian Farrel 7 Old Dog Consulting 8 Jean-Philippe Vasseur 9 Cisco Systems, Inc. 11 October 2006 13 Analysis of Inter-domain Label Switched Path (LSP) Recovery 14 draft-takeda-ccamp-inter-domain-recovery-analysis-01.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 analyzes various schemes to realize Multiprotocol Label 42 Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path 43 (LSP) recovery in multi-domain networks based on the existing 44 framework for multi-domain LSPs. 46 The main focus for this document is on establishing end-to-end 47 diverse Traffic Engineering (TE) LSPs in multi-domain networks. It 48 presents various diverse LSP setup schemes based on existing 49 functional elements. 51 Table of Contents 53 1. Terminology....................................................2 54 2. Introduction...................................................3 55 2.1 Domain........................................................3 56 2.2 Document Scope................................................4 57 2.3 Note on Other Recovery Techniques.............................5 58 2.4 Signaling Options.............................................5 59 3. Diversity in Multi-domain Networks.............................5 60 3.1 Multi-domain Network Topology.................................6 61 3.2 Note on Domain Diversity......................................7 62 4. Factors to Consider............................................7 63 4.1 Scalability versus Optimality.................................7 64 4.2 Key Concepts..................................................8 65 5. Diverse LSP Setup Schemes without Confidentiality.............10 66 5.1 Management Configuration.....................................10 67 5.2 Head-end Path Computation (with multi-domain visibility).....10 68 5.3 Per-domain Path Computation..................................10 69 5.3.1 Sequential Path Computation................................11 70 5.3.2 Simultaneous Path Computation..............................11 71 5.4 Inter-domain Collaborative Path Computation..................12 72 5.4.1 Sequential Path Computation................................12 73 5.4.2 Simultaneous Path Computation..............................13 74 6. Diverse LSP Setup Schemes with Confidentiality................13 75 6.1 Management Configuration.....................................14 76 6.2 Head-end Path Computation (with multi-domain visibility).....14 77 6.3 Per-Domain Path Computation..................................15 78 6.3.1 Sequential Path Computation................................15 79 6.3.2 Simultaneous Path Computation..............................15 80 6.4 Inter-domain Collaborate Path Computation....................16 81 6.4.1 Sequential Path Computation................................16 82 6.4.2 Simultaneous Path Computation..............................16 83 7. Network Topology Specific Considerations......................17 84 8. Addressing Considerations.....................................17 85 9. Note on SRLG Diversity........................................17 86 10. Manageability Considerations.................................17 87 11. Security Considerations......................................18 88 12. References...................................................18 89 12.1 Normative References........................................18 90 12.2 Informative References......................................18 91 13. Acknowledgments..............................................20 92 14. Author's Addresses...........................................20 93 15. Intellectual Property Consideration..........................20 94 16. Full Copyright Statement.....................................21 96 1. Terminology 97 The reader is assumed to be familiar with the terminology in [inter- 98 domain-fw] that provides a framework for inter-domain Label Switched 99 Path (LSP) setup, and [RFC4427] that provides terminology for LSP 100 recovery. 102 The following are several key terminologies used within this 103 document. 105 - Domain: See [inter-domain-fw]. A domain is considered to be any 106 collection of network elements within a common sphere of address 107 management or path computational responsibility. Note that nested 108 domains continue to be out of scope. 110 - Working LSP: See [RFC4427]. The working LSP transports normal user 111 traffic. Note that the term LSP and TE LSP will be used 112 interchangeably. 114 - Recovery LSP: See [RFC4427]. The recovery LSP transports normal 115 user traffic when the working LSP fails. The recovery LSP may 116 transport user traffic even when the working LSP is transporting 117 normal user traffic (e.g., 1+1 protection). In such a scenario, 118 the recovery LSP is sometimes referred to as a protecting LSP. 120 - Diversity: See [inter-domain-fw]. Diversity means the relationship 121 of multiple LSPs, where those LSPs do not share some specific type 122 of resource (e.g., link, node, or shared risk link group (SRLG)). 123 Diverse LSPs may be used for various purposes, such as load- 124 balancing and recovery. In this document, the recovery aspect of 125 diversity, specifically the end-to-end diversity of two traffic 126 engineering (TE) LSPs, is the focus. Those two diverse LSPs are 127 referred to as the working LSP and recovery LSP hereafter. 128 Sometimes, diversity is referred to as disjointness. 130 - Confidentiality: See [RFC4216]. The term confidentiality applies 131 to the protection of information about the topology and resources 132 present within one domain from visibility by people or 133 applications outside that domain. 135 2. Introduction 137 2.1 Domain 139 As defined in [inter-domain-fw], a domain is considered to be any 140 collection of network elements within a common sphere of address 141 management or path computational responsibility. Examples of such 142 domains include IGP areas and Autonomous Systems. A network accessed 143 over the Generalized Multiprotocol Label Switching (GMPLS) User-to- 144 Network Interface (UNI) [RFC4208] and a Layer One Virtual Private 145 Network (L1VPNs) [L1VPN-FW] are special cases of multi-domain 146 networks. 148 Example objectives of domain usage include administrative separation, 149 scalability, and forming protection domains. 151 As described in [inter-domain-fw], there could be TE parameters (such 152 as color and priority) whose meanings are specific to each domain. In 153 such a scenarios, mapping functions could be performed based on 154 policy agreements between domain administrators. 156 2.2 Document Scope 158 This document analyzes various schemes to realize Multiprotocol Label 159 Switching (MPLS) and Generalized MPLS (GMPLS) LSP recovery in multi- 160 domain networks based on the existing framework for multi-domain LSP 161 setup [inter-domain-fw]. 163 There are various recovery techniques for LSPs. For TE LSPs, major 164 techniques are end-to-end recovery [e2e-recovery], local protection 165 such as Fast Reroute (FRR) [RFC4090] (in packet switching 166 environments), and segment recovery [seg-recovery] (in GMPLS). 168 In this version of the document the main focus is the analysis of 169 diverse TE LSP (hereafter LSP) setup schemes, which can 170 advantageously used in the context of end-to-end recovery. This 171 document presents various diverse LSP setup schemes by combining 172 various functional elements. Analysis of other recovery techniques 173 could be added in a later revision of this document if necessary. 174 Furthermore, details of maintenance of diverse LSPs, such as re- 175 optimization and OAM, are for further study. 177 Note that the comparative evaluation of these various schemes is out 178 of scope for this document, and should be described in separate 179 applicability documents. 181 [RFC4105] and [RFC4216] describe requirements for diverse LSPs. There 182 could be various types of diversity, and this document focuses on 183 node/link/SRLG diversity. Note that domain diversity (that is, the 184 selection of paths that have only the ingress and egress domains in 185 common) is discussed in section 3.2. 187 Based on the service grade, both the working LSP and the recovery LSP 188 may be established at the time of service establishment (e.g., 189 service requiring high resiliency). Alternatively, the recovery LSP 190 may be added later due to a change in the grade of the service. 192 Also, the recovery LSP may be used for 1+1 protection, 1:1 193 protection, or shared mesh restoration. However, ways to compute 194 diverse paths, and the signaling of these TE LSPs are common across 195 all uses, and these topics are the main scope of this document. 197 Section 5 of [inter-domain-fw] describes some analysis of diverse 198 LSPs in multi-domain networks, and this document provides more 199 detailed analysis based on that content. 201 Note that diverse LSPs may be used for various purposes, in addition 202 to recovery. An example is for load-balancing, so as to limit the 203 traffic disruption to a portion of the traffic flow in case of a 204 single network element failure. This document does not preclude use 205 of diverse LSP setup schemes for those purposes. 207 2.3 Note on Other Recovery Techniques 209 Fast Reroute and segment recovery in multi-domain networks are 210 described in section 5.4 of [inter-domain-fw], and a more detailed 211 analysis is provided in section 5 of [inter-domain-rsvp]. Additional 212 analysis may be added in a future revision of this document if 213 necessary. 215 Also, the recovery type of an LSP or service may change at a domain 216 boundary. That is, the recovery type would remain the same within one 217 domain, but might be different in the next domain. This may be due to 218 the capabilities of each domain, administrative policies, or to 219 topology limitations. An example is where protection at the domain 220 boundary is provided by link protection on the inter-domain link(s), 221 but where protection within each domain is achieved through segment 222 recovery. This mixture of protection techniques is for further study. 224 2.4 Signaling Options 226 There are three signaling options for establishing inter-domain TE 227 LSPs: nesting, contiguous LSPs, and stitching [inter-domain-fw]. The 228 description in this document of diverse LSP setup is agnostic in 229 relation to the signaling option used, unless otherwise specified. 231 Note that signaling option specific considerations for Fast Reroute 232 and segment recovery are described in section 5 of [inter-domain- 233 rsvp]. Also note that if the recovery type changes at the domain 234 boundary, the nesting and stitching options may be more suitable. 235 Details are for further study. 237 3. Diversity in Multi-domain Networks 239 As described in section 2.2, analysis of diverse LSP setup schemes in 240 multi-domain networks is the main focus of this document. This 241 section describes some assumptions in this problem space made in this 242 document. 244 3.1 Multi-domain Network Topology 246 Figures 1 and 2 show example multi-domain network topologies. In 247 Figure 1, domains are connected in a linear topology. There are 248 multiple paths between nodes A and L, but all of them cross domain#1- 249 domain#2-domain#3 in that order. 251 +--Domain#1--+ +--Domain#2--+ +--Domain#3--+ 252 | | | | | | 253 | B------+---+---D-----E--+---+------J | 254 | / | | \ / | | \ | 255 | / | | \ / | | \ | 256 | A | | H | | L | 257 | \ | | / \ | | / | 258 | \ | | / \ | | / | 259 | C------+---+---F-----G--+---+------K | 260 | | | | | | 261 +------------+ +------------+ +------------+ 263 Figure 1: Linear Connectivity 265 +-----Domain#2-----+ 266 | | 267 | E--------------F | 268 | | | | 269 +-+--------------+-+ 270 | | 271 +-Domain#1-+-+ +---------+--+ 272 | | | | | | 273 | A-------B-+--+-C-------D | 274 | | | | | | 275 +--+---------+ +-+-Domain#4-+ 276 | | 277 +-+--------------+-+ 278 | | | | 279 | G--------------H | 280 | | 281 +-----Domain#3-----+ 283 Figure 2: Mesh Connectivity 285 In Figure 2, domains are connected in a mesh topology. There are 286 multiple paths between nodes A and D, and these paths do not 287 necessarily follow the same set of domains. 289 Indeed, if inter-domain connectivity forms a mesh, domain level 290 routing is required (even for the unprotected case). This is tightly 291 coupled with the next hop domain resolution/discovery mechanisms. 293 In this version of the document, we assume that domain level routing 294 is given via configuration or policy, and this is not part of path 295 computation process described later in this document. Details on more 296 advanced domain level routing are for further study. 298 In addition, domain level routing may perform "domain re-entry", 299 where a path enters a domain after the path exits that domain (e.g., 300 domain#X-domain#Y-domain#X). This requires specific considerations 301 when confidentiality is required (described in section 4.2), and is 302 for further study. 304 Furthermore, the working LSP and the recovery LSP may or may not be 305 routed along the same set of domains in the same order. In this 306 version of the document, we assume that the working LSP and recovery 307 LSP follow the same set of domains in the same order (via 308 configuration or policy). Details on other scenarios are for further 309 study. 311 3.2 Note on Domain Diversity 313 As described in section 2.2, domain diversity means the selection of 314 paths that have only the ingress and egress domains in common. This 315 may provide enhanced resilience against failures, and is a way to 316 ensure path diversity for most of the path of the LSP. 318 In section 3.1 we assumed that the working LSP and the recovery LSP 319 follow the same set of domains in the same order. Under this 320 assumption, domain diversity cannot be achieved. However, by relaxing 321 this assumption, domain diversity could be achieved, e.g., by either 322 of the following schemes. 324 - Consider domain diversity as a special case of SRLG diversity 325 (i.e., assign an SRLG ID to each domain) 326 - Configure domain level routing to provide domain diverse paths 327 (e.g., by means of AS_PATH in BGP) 329 Details are for further study, should it been considered as a 330 requirement. 332 4. Factors to Consider 334 4.1 Scalability versus Optimality 336 As described in [inter-domain-fw], scalability and optimality are two 337 conflicting objectives. Note that the meaning of optimality differs 338 depending on each network operation. Some examples of optimality in 339 the context of diverse LSPs are: 341 - Minimizing the sum of their cost while maintaining diversity 342 - Restricting the difference of their cost (so as to minimize delay 343 difference after switch-over) while maintaining diversity 345 By restricting TE information distribution to only within each domain 346 (and not across domain boundaries) as required by RFC4105 and 347 RFC4216, it may not be possible to compute an optimal path. As such, 348 it may not be possible to compute diverse paths, even if they exist. 349 However, if we assume domain level routing is given (as discussed in 350 section 3), it is possible to compute diverse paths in some schemes 351 if such paths exist. This is discussed in section 5. 353 4.2 Key Concepts 355 Three key concepts to classify various diverse LSP setup schemes are 356 presented below. 358 o With or without confidentiality 360 - Without confidentiality 362 Under this network configuration, it is possible to specify (by 363 means of the Explicit Route Object - ERO comprising a list of 364 strict hops) or obtain (by means of the recorded Route Object - 365 RRO) a route across other domains. 367 Examples of this configuration are multi-area networks, and some 368 forms of multi-AS networks (especially within the same provider). 370 - With confidentiality 372 Under this network configuration, it is not possible to specify 373 or obtain a route (by means of ERO/RRO) across other domains. 374 Paths may be specified/obtained in the form of ERO/RRO containing 375 loose hops. Therefore, it is not possible to specify or obtain a 376 full route at the head-end of a multi-domain LSP. 378 Examples of this configuration are some forms of multi-AS 379 networks (especially inter-provider networks), GMPLS-UNI 380 networks, and L1VPNs. 382 o Per domain path computation or inter-domain collaborative path 383 computation 385 - Per domain path computation 387 In this scheme, a path is computed domain by domain as LSP 388 signaling progresses through the network. This scheme requires 389 ERO expansion in each domain. The case for unprotected LSPs under 390 this scheme is covered in [inter-domain-pd]. 392 - Inter-domain collaborative path computation 394 In this scheme, path computation is typically done before 395 signaling. This scheme typically uses communication between 396 cooperating path computation elements (PCEs) [PCE-arch]. The case 397 for unprotected LSP under this scheme is covered in [brpc]. 399 Note that these are path computation techniques. It is also 400 possible to obtain a path via management configuration, or head-end 401 path computation (with multi-domain visibility). This is also 402 discussed in sections 5 and 6. 404 Note also that it is possible to combine multiple path computation 405 techniques (including using a different technique for the working 406 and recovery LSPs), but this is for further study and is likely 407 to require sequential path computation (see below). 409 o Sequential path computation or simultaneous path computation 411 - Sequential path computation 413 The path of the working LSP is computed (without considering the 414 recovery LSP), and then the path of the recovery LSP is computed. 415 Typically, this scheme is applicable when the recovery LSP is 416 added later as change of the service grade. But this scheme can 417 also be applicable when both of the working and recovery LSPs are 418 established from the start. In this scheme, diverse LSPs may not 419 be correctly computed (without some form of re-optimization or 420 recomputation technique) in "trap" topologies. Furthermore, such 421 sequential path computation approach may prevent from finding an 422 "optimal" solution with regards to a specific objective function. 424 - Simultaneous path computation 426 The path of the working LSP and the path of the recovery LSP are 427 computed simultaneously. Typically, this scheme is applicable 428 when both the working LSP and the recovery LSP are established 429 together. In this scheme, it is possible to avoid trap 430 topologies. Furthermore it may allow for achieving more optimal 431 results. 433 Note that LSP setup with or without confidentiality is given as a 434 per-domain configuration, while the choices of per-domain path 435 computation or inter-domain collaborative path computation, and 436 sequential path computation or simultaneous path computation may be a 437 matter of choice for each individual pair of working/recovery LSPs. 439 The analysis of various diverse LSP setup schemes is described in 440 sections 5 and 6, based on above criteria. 442 Some other considerations, such as network topology specific 443 considerations, addressing considerations, and SRLG diversity are 444 described in sections 7, 8 and 9. 446 5. Diverse LSP Setup Schemes without Confidentiality 448 In the following, various schemes for diverse LSP setup are presented 449 based on different path computation techniques assuming that there is 450 no requirement for confidentiality between domains. Section 6 makes a 451 similar examination of schemes where inter-domain confidentiality is 452 required. 454 5.1 Management Configuration 456 Section 3.1 of [inter-domain-fw] describes this path computation 457 technique. The full explicit paths for the working and recovery LSPs 458 are specified by a management application at the head-end, and no 459 further computation or signaling specific considerations are needed. 461 5.2 Head-end Path Computation (with multi-domain visibility) 463 Section 3.2.1 of [inter-domain-fw] describes this path computation 464 technique. The full explicit paths for the working and recovery LSPs 465 are computed at the head-end either by the head-end itself or by a 466 PCE. In either case the computing entity has full TE visibility 467 across multiple domains and no further computation or signaling 468 specific considerations are needed. 470 5.3 Per-domain Path Computation 472 Sections 3.2.2, 3.2.3 and 3.3 of [inter-domain-fw] describe this path 473 computation technique. More detailed procedures are described in 474 [inter-domain-pd]. 476 In this scheme, the explicit paths of the working and recovery LSPs 477 are specified as the complete strict path in the source domain 478 followed by one of the following: 480 - The complete list of boundary LSRs (or domain identifiers, e.g., AS 481 numbers) along the path. 483 - The boundary LSR for the source domain and the LSP destination. 485 Thus, ERO expansion is needed at domain boundaries. Path computation 486 is performed by, or by a PCE on behalf of, each domain boundary LSR. 488 For establishing diverse LSPs using per-domain computation, there are 489 two specific schemes, which are described in sections 5.3.1 and 5.3.2 490 respectively. 492 5.3.1 Sequential Path Computation 494 The Exclude Route Object (XRO) [XRO] can be used. Details are as 495 follows. 497 Assume that the working LSP is established as described in [inter- 498 domain-pd]. Also, assume that the route of the working LSP (full 499 route) is available at the head-end through the RRO. 501 o Path computation aspect 503 When performing path computation (ERO expansion) for the recovery 504 LSP as it crosses each domain boundary a path is selected that 505 avoids the nodes/links/SRLGs used by the working path so that a 506 diverse path is obtained. 508 o Signaling aspect 510 In order that the computation noted above can be performed, each 511 computation point must be aware of the path of the working LSP. 512 This information can be supplied in the XRO included in the Path 513 message for recovery LSP. The XRO lists nodes, links and SRLGs that 514 must be avoided by the LSP being signaled, and its contents are 515 copied from the RRO of the working LSP. 517 This scheme cannot guarantee to establish diverse LSPs (even if they 518 could exist) because the first LSP is established without 519 consideration of the need for a diverse recovery LSP. Crankback 520 [crankback] may be used in combination with this scheme in order to 521 improve the possibility of successful diverse LSP setup. Furthermore, 522 re-optimization of the working LSP and the recovery LSP may be used 523 to achieve fully diverse paths. 525 Note that even if a solution is found, the degree of optimality of 526 the solution (set of diverse TE LSP) might not be maximized. 528 5.3.2 Simultaneous Path Computation 530 o Path computation aspect 532 When signaling the working LSP, the path of not only the working 533 LSP, but also the recovery LSP is computed. For example, in 534 Figure 1, when node D receives a Path message for the working LSP 535 between nodes A and L, node D expands the ERO to reach domain#3. At 536 the same time, node D computes a path for the recovery LSP across 537 the same domain from node F to reach domain#3. The entry boundary 538 node for the recovery LSP (node F) needs to be specified in the 539 Path message for the working LSP. In this example the path for the 540 working LSP may be computed by node D as D-E-domain#3, and the path 541 for recovery LSP as F-G-domain#3. 543 o Signaling aspect 545 There must be a mechanism to force the recovery LSP to follow the 546 route computed above. One way to realize this is to have a specific 547 object (with the same format as the ERO) to collect the route of 548 the recovery LSP in the Path message for the working LSP and to 549 return is to the head-end in the Resv message. When signaling the 550 recovery LSP, the content of the ERO is copied from this object. 552 This scheme also cannot guarantee to establish diverse LSPs (even if 553 they could exist) if there are more than two domain boundary nodes 554 out of each domain. Crankback [crankback] may also be used in 555 combination with this scheme to improve the chances of success. 557 Note that even if a solution is found, the degree of optimality of 558 the solution (set of diverse TE LSP) might not be maximized. 560 5.4 Inter-domain Collaborative Path Computation 562 Section 3.4 of [inter-domain-fw] describes this approach. [brpc] 563 provides some more detail. Path computation is performed for each of 564 the working and recovery LSPs by the use of inter-PCE communication 565 before each LSP is signaled. 567 There are two specific schemes for establishing diverse LSPs using 568 this scheme, which are described in sections 5.4.1 and 5.4.2. 570 5.4.1 Sequential Path Computation 572 Route exclusion using the XRO [XRO] can be requested in the PCE 573 communication protocol (PCEP) [PCEP] and this can be used to compute 574 the path of a recovery LSP after the path of the working LSP has been 575 determined. Details are as follows. 577 The working LSP is computed and may be immediately established as 578 described in [brpc]. Assume that the path of the working LSP (full 579 route) is available from the RRO. 581 o Path computation aspect 583 When requesting path computation for the recovery LSP, an XRO is 584 included in the PCEP path computation request message (see [PCEP]). 585 The content of the XRO is copied from the RRO of the working LSP. 587 The computation request specifies that the full route must be 588 returned. Per-domain PCEs may need to be invoked by the first PCE 589 that is consulted in order to collaboratively determine the correct 590 path for the recovery LSP (just as described in [PCE-arch] and 591 [inter-domain-fw] for the computation of a single inter-domain LSP 592 by collaborating PCEs), and these PCEs exchange the XRO information 593 to ensure that the computed path is diverse from the working LSP. 595 o Signaling aspect 597 The recovery LSP is signaled by including an ERO whose content is 598 copied from the result returned by the PCE. 600 This scheme cannot guarantee to establish diverse LSPs (even if they 601 exist) because the working LSP may be blocking. In such a scenario, 602 re-optimization of the working and recovery LSPs may be used to 603 achieve fully diverse paths. 605 Note that PCEP [PCEP] does not currently include support for the XRO, 606 but that this is planned to be added in a future version. 608 5.4.2 Simultaneous Path Computation 610 o Path computation aspect 612 The PCEP SVEC Object allows diverse path computation to be 613 requested. It would be possible to extend [brpc] to compute diverse 614 paths. Details are for further study. 616 o Signaling aspect 618 In this scheme the PCE returns the full routes for the working and 619 recovery LSPs and they are signaled accordingly. 621 This scheme can guarantee to establish diverse LSPs (if they exist), 622 assuming domain level routing is given as described in section 3. 624 Furthermore, the computed set of TE LSPs may be optimal with respect 625 to some objective functions. 627 6. Diverse LSP Setup Schemes with Confidentiality 629 In the context of this section, the term confidentiality applies to 630 the protection of information about the topology and resources 631 present within one domain from visibility by people or applications 632 outside that domain. This includes, but is not limited to, recording 633 of LSP routes, in addition to advertisements of TE information. The 634 confidentiality does not apply to the protection of user traffic. 636 Diverse LSP setup schemes with confidentiality are similar to ones 637 without confidentiality. However, several additional mechanisms are 638 needed to preserve confidentiality. Examples of such mechanisms are: 640 - Path key: Provide each per-domain segment of the path in advance to 641 the domain boundary nodes or to the PCE that computed the path for 642 a limited period of time (temporary caching) and identify it in the 643 signaled ERO using a path key. When path computation is done by 644 PCE, the identify of the PCE containing state for the path may be 645 required as well (e.g., PCE I-D). The path key is provided by the 646 PCE to the head-end for inclusion in the ERO [conf-segment]. 648 - LSP segment: Pre-establish each per-domain segments of the path 649 using hierarchical LSPs [RFC4206] or LSP stitching segments 650 [LSP-stitch] and signal the end-to-end LSP to use these per-domain 651 LSPs. This scheme may need additional identifiers (such as LSP IDs) 652 in the Path message so that the domain boundary node can identify 653 which LSP segment or tunnel to use for the end-to-end LSP. 654 Furthermore, this scheme may require communication to pre-establish 655 the LSP segments. 657 These techniques may be directly applied, or may be applied with 658 extensions, depending on specific diverse LSP setup schemes described 659 below. 661 Note that in the schemes below, the paths of the working and recovery 662 LSPs are not impacted by the confidentiality requirements. 664 6.1 Management Configuration 666 It is not possible to obtain or specify the full explicit route for 667 either LSP at the head-end due to confidentiality restrictions. 668 Therefore, this information cannot be provided to signaling for LSP 669 setup. 671 Confidentially need not prevent the full computation of inter-domain 672 paths and signaling of sufficient information to distinguish the 673 paths. However the path information for each domain must be provided 674 in a way that does not have meaning to other domains. Example 675 mechanisms to preserve confidentiality as described above, include: 677 - Path key 678 - LSP segment 680 Details are for further study. 682 6.2 Head-end Path Computation (with multi-domain visibility) 683 This scheme is not applicable since multi-domain visibility violates 684 confidentiality. 686 6.3 Per-Domain Path Computation 688 6.3.1 Sequential Path Computation 690 Assume the working LSP is established as described in [inter-domain- 691 pd]. 693 It is not possible to obtain the route of the working LSP from the 694 RRO at the head-end due to confidentiality. In order to provide the 695 path of the working LSP through each domain to the computation point 696 responsible for computing the path of the protection LSP through each 697 domain additional mechanisms are needed. Examples of such mechanisms 698 are: 700 - Information identifying the working LSP is included in the Path 701 message for the recovery LSP, and the domain boundary node consults 702 the entity which computed the path of the working LSP (i.e., domain 703 boundary node or PCE), so that the diverse path can be computed. 704 When the entity which computed the path of the working LSP is the 705 PCE, PCE needs to be temporarily stateful. An example of such 706 information is the Association Object [e2e-recovery]. 708 Details are for further study. 710 6.3.2 Simultaneous Path Computation 712 In this scheme the intention is to compute the path of the recovery 713 LSP at the same time as the working LSP. In order to force the 714 recovery LSP to follow the computed path as well as to preserve 715 confidentiality, additional mechanisms are needed to communicate the 716 computed recovery path from the path of the working LSP (where it was 717 computed) to the recovery LSP. Examples of such mechanisms, that must 718 continue to preserve confidentiality, are as follows. 720 - LSP segment: As described before. The LSP segment for the recovery 721 LSP is established domain-by-domain as the working LSP setup 722 progresses. 724 - Alternatively, information identifying the working LSP is included 725 in the Path message for the recovery LSP, and the domain boundary 726 node consults the entity which computed the path of the recovery 727 LSP (i.e., domain boundary node or PCE), so as to obtain the path 728 of the recovery LSP. This requires that the entity which computed 729 the path of the recovery LSP is temporarily stateful. An example of 730 such information is the Association Object [e2e-recovery]. 732 Details are for further study. 734 6.4 Inter-domain Collaborate Path Computation 736 6.4.1 Sequential Path Computation 738 Assume working LSP is established as described in [brpc]. 740 It is not possible to obtain RRO of working LSP (full route) at the 741 head-end due to confidentiality. 743 o Path computation aspect 745 In order to obtain the path of the working LSP when computing the 746 path of the recovery LSP, additional mechanisms are needed. 747 Examples of such mechanisms are: 749 - Information identifying the working LSP is included in the PCEP 750 message when requesting path computation of the recovery LSP 751 should the PCE stateful (temporarily). An example of such 752 information is the Association Object [e2e-recovery]. 754 o Signaling aspect 756 The full route for the recovery LSP can not be returned to the 757 head-end by PCE because it cannot be collected from the other PCEs 758 owing to confidentiality restrictions. In order to force the 759 recovery LSP to follow the path computed above, additional 760 mechanisms are needed. Examples of such mechanisms are as described 761 before: 763 - Path key 764 - LSP segment 766 Details are for further study. 768 6.4.2 Simultaneous Path Computation 770 It is not possible for PCE to return the full route of the working 771 LSP and recovery LSP to the head-end due to confidentiality. In order 772 to force the working and recovery LSPs to follow the paths computed, 773 additional mechanisms are needed. Examples of such mechanisms are as 774 described before: 776 - Path key: Use this for the working and recovery LSPs. 778 Note that the LSP segment approach in section 6 may not be applicable 779 here since a path cannot be determined until BRPC procedures are 780 completed. 782 Details are for further study. 784 7. Network Topology Specific Considerations 786 In some specific network topologies, diverse LSP setup schemes 787 mentioned above could be drastically simplified. 789 For example, assume there are only three domains connected linearly, 790 and the first and the last domain contain only a single node. Assume 791 that we need to establish diverse LSPs from the node in the first 792 domain to the node in the last domain. In such a scenario, no BRPC 793 procedures are needed, because there is no need for path computation 794 in the first and last domains. 796 8. Addressing Considerations 798 All of the above-mentioned schemes are applicable when a single 799 address space is used across all domains. 801 However, there could be several cases where private addresses are 802 used within some of the domains. This case is similar to the one with 803 confidentiality, since the ERO and RRO are meaningless even if they 804 are available. Details are for further study. 806 9. Note on SRLG Diversity 808 The above-mentioned schemes are applicable when the nodes and links 809 in different domain belong to different SRLGs. 811 However, there could be several cases where the nodes and links in 812 different domain belong to the same SRLG. That is, where SRLGs span 813 domain boundaries. In such cases, in order to establish SRLG diverse 814 LSPs, several considerations are needed, such as: 816 - Record of the SRLGs used by the working LSP 817 - Indication of a set of SRLGs to exclude in the computation of the 818 recovery LSP's path. 820 Furthermore, SRLG IDs may be assigned independently in each domain, 821 and might not have global meaning. In such a scenario, some mapping 822 functions are necessary, similar to the mapping of other TE 823 parameters mentioned in section 2.1. 825 Details are for further study. 827 10. Manageability Considerations 829 TBD 831 11. Security Considerations 833 TBD 835 12. References 837 12.1 Normative References 839 [inter-domain-fw] Farrel, A., et al., "A Framework for Inter-Domain 840 MPLS Traffic Engineering", draft-ietf-ccamp- 841 inter-domain-framework, work in progress. 843 [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., 844 "Recovery (Protection and Restoration) 845 Terminology for Generalized Multi-Protocol Label 846 Switching (GMPLS)", RFC 4427, March 2006. 848 12.2 Informative References 850 [RFC4208] Swallow, G., et al., "Generalized Multiprotocol 851 Label Switching (GMPLS) User-Network Interface 852 (UNI): Resource ReserVation Protocol-Traffic 853 Engineering (RSVP-TE) Support for the Overlay 854 Model", RFC 4208, October 2005. 856 [L1VPN-FW] Takeda, T., Editor "Framework and Requirements 857 for Layer 1 Virtual Private Networks", draft- 858 ietf-l1vpn-framework, work in progress. 860 [PCE-arch] A. Farrel, JP. Vasseur and J. Ash, "Path 861 Computation Element (PCE) Architecture", draft- 862 ietf-pce-architecture, work in progress. 864 [e2e-recovery] Lang, J., Rekhter, Y., and Papadimitriou, D. 865 (Eds.), "RSVP-TE Extensions in support of End-to- 866 End Generalized Multi-Protocol Label Switching 867 (GMPLS)-based Recovery", 868 draft-ietf-ccamp-gmpls-recovery-e2e-signaling, 869 work in progress. 871 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 872 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 873 May 2005. 875 [seg-recovery] Berger, L., Bryskin, I., Papadimitriou, D., and 876 Farrel, A., "GMPLS Based Segment Recovery", 877 draft-ietf-ccamp-gmpls-segment-recovery, work in 878 progress. 880 [RFC4105] Le Roux, J.-L. , Vasseur, J.-P., and J. Boyle, 881 "Requirements for Inter-Area MPLS Traffic 882 Engineering", RFC 4105, June 2005. 884 [RFC4216] Zhang, R., and Vasseur, J.-P., "MPLS Inter- 885 Autonomous System (AS) Traffic Engineering (TE) 886 Requirements", RFC 4216, November 2005 888 [inter-domain-rsvp] Ayyangar, A., Vasseur, JP. "Inter-domain MPLS 889 Traffic Engineering - RSVP extensions", draft- 890 ietf-ccamp-inter-domain-rsvp-te, work in 891 progress. 893 [XRO] Lee et al., "Exclude Routes - Extension to 894 RSVP-TE", draft-ietf-ccamp-rsvp-te-exclude-route, 895 work in progress. 897 [inter-domain-pd] Vasseur JP., Ayyangar A., Zhang R., "A 898 per-domain path computation method for computing 899 Inter-domain Traffic Engineering Label Switched 900 Path", draft-ietf-ccamp-inter-domain-pd-path- 901 comp, work in progress. 903 [brpc] Vasseur, JP., Zhang, R., and Bitar, N., "A 904 Backward Recursive PCE-based Computation (BRPC) 905 procedure to compute shortest inter-domain 906 Traffic Engineering Label Switched Path", draft- 907 vasseur-ccamp-brpc, work in progress. 909 [PCEP] Vasseur, J., "Path Computation Element (PCE) 910 communication Protocol (PCEP) - Version 1 -", 911 draft-ietf-pce-pcep, work in progress. 913 [conf-segment] Bradford, R., Vasseur, JP., and Farrel, A., 914 "Preserving Topology Confidentiality in Inter- 915 Domain Path Computation and Signaling", draft- 916 bradford-pce-path-key, work in progress. 918 [crankback] Farrel, A., et al., "Crankback Signaling 919 Extensions for MPLS Signaling", draft-ietf- 920 ccamp-crankback, work in progress. 922 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched 923 Paths (LSP) Hierarchy with Generalized Multi- 924 Protocol Label Switching (GMPLS) Traffic 925 Engineering (TE)", RFC 4206, October 2005. 927 [LSP-stitch] Ayyangar, A., and Vasseur, JP., "LSP Stitching 928 with Generalized MPLS TE", draft-ietf-ccamp-lsp- 929 stitching, work in progress. 931 13. Acknowledgments 933 Authors would like to thank Eiji Oki, Ichiro Inoue and Kazuhiro 934 Fujihara for valuable comments. 936 14. Author's Addresses 938 Tomonori Takeda 939 NTT Network Service Systems Laboratories, NTT Corporation 940 3-9-11, Midori-Cho 941 Musashino-Shi, Tokyo 180-8585 Japan 942 Email : takeda.tomonori@lab.ntt.co.jp 944 Yuichi Ikejiri 945 NTT Communications Corporation 946 Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku 947 Tokyo 163-1421, Japan 948 Email: y.ikejiri@ntt.com 950 Adrian Farrel 951 Old Dog Consulting 952 Email: adrian@olddog.co.uk 954 Jean-Philippe Vasseur 955 Cisco Systems, Inc. 956 300 Beaver Brook Road 957 Boxborough , MA - 01719 958 USA 959 Email: jpv@cisco.com 961 15. Intellectual Property Consideration 963 The IETF takes no position regarding the validity or scope of any 964 Intellectual Property Rights or other rights that might be claimed 965 to pertain to the implementation or use of the technology 966 described in this document or the extent to which any license 967 under such rights might or might not be available; nor does it 968 represent that it has made any independent effort to identify any 969 such rights. Information on the procedures with respect to 970 rights in RFC documents can be found in BCP 78 and BCP 79. 972 Copies of IPR disclosures made to the IETF Secretariat and any 973 assurances of licenses to be made available, or the result of an 974 attempt made to obtain a general license or permission for the use 975 of such proprietary rights by implementers or users of this 976 specification can be obtained from the IETF on-line IPR repository 977 at http://www.ietf.org/ipr. 979 The IETF invites any interested party to bring to its attention 980 any copyrights, patents or patent applications, or other 981 proprietary rights that may cover technology that may be required 982 to implement this standard. Please address the information to the 983 IETF at ietf-ipr@ietf.org. 985 16. Full Copyright Statement 987 Copyright (C) The Internet Society (2006). 989 This document is subject to the rights, licenses and restrictions 990 contained in BCP 78, and except as set forth therein, the authors 991 retain all their rights. 993 This document and the information contained herein are provided on an 994 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 995 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 996 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 997 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 998 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 999 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.