idnits 2.17.1 draft-ietf-ccamp-inter-domain-recovery-analysis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1104. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1074. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1081. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1087. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 IETF Trust 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 (September 2007) is 6066 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Tomonori Takeda, Ed. 3 Internet Draft NTT 4 Intended Status: Informational Yuichi Ikejiri 5 Expires: March 2008 NTT Communications 6 Adrian Farrel 7 Old Dog Consulting 8 Jean-Philippe Vasseur 9 Cisco Systems, Inc. 11 September 2007 13 Analysis of Inter-domain Label Switched Path (LSP) Recovery 14 draft-ietf-ccamp-inter-domain-recovery-analysis-02.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. Introduction...................................................2 54 1.1 Terminology...................................................3 55 1.2 Domain........................................................4 56 1.3 Document Scope................................................4 57 1.4 Note on Other Recovery Techniques.............................5 58 1.5 Signaling Options.............................................6 59 2. Diversity in Multi-domain Networks.............................6 60 2.1 Multi-domain Network Topology.................................6 61 2.2 Note on Domain Diversity......................................8 62 3. Factors to Consider............................................8 63 3.1 Scalability versus Optimality.................................8 64 3.2 Key Concepts..................................................9 65 4. Diverse LSP Setup Schemes without Confidentiality.............11 66 4.1 Management Configuration.....................................11 67 4.2 Head-end Path Computation (with multi-domain visibility).....11 68 4.3 Per-domain Path Computation..................................11 69 4.3.1 Sequential Path Computation................................12 70 4.3.2 Simultaneous Path Computation..............................12 71 4.4 Inter-domain Collaborative Path Computation..................13 72 4.4.1 Sequential Path Computation................................14 73 4.4.2 Simultaneous Path Computation..............................14 74 5. Diverse LSP Setup Schemes with Confidentiality................15 75 5.1 Management Configuration.....................................16 76 5.2 Head-end Path Computation (with multi-domain visibility).....16 77 5.3 Per-Domain Path Computation..................................16 78 5.3.1 Sequential Path Computation................................16 79 5.3.2 Simultaneous Path Computation..............................17 80 5.4 Inter-domain Collaborative Path Computation..................17 81 5.4.1 Sequential Path Computation................................17 82 5.4.2 Simultaneous Path Computation..............................18 83 6. Network Topology Specific Considerations......................18 84 7. Addressing Considerations.....................................19 85 8. Note on SRLG Diversity........................................19 86 9. Security Considerations.......................................19 87 10. References...................................................20 88 10.1 Normative References........................................20 89 10.2 Informative References......................................20 90 11. Acknowledgments..............................................22 91 12. Authors' Addresses...........................................22 92 Intellectual Property Consideration..............................23 93 Full Copyright Statement.........................................23 95 1. Introduction 97 This document analyzes various schemes to realize Multiprotocol Label 98 Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path 99 (LSP) recovery in multi-domain networks based on the existing 100 framework for multi-domain LSPs. 102 The main focus for this document is on establishing end-to-end 103 diverse Traffic Engineering (TE) LSPs in multi-domain networks. It 104 presents various diverse LSP setup schemes based on existing 105 functional elements. 107 1.1 Terminology 109 The reader is assumed to be familiar with the terminology in 110 [RFC4726] that provides a framework for inter-domain Label Switched 111 Path (LSP) setup, and [RFC4427] that provides terminology for LSP 112 recovery. 114 The following are several key terminologies used within this 115 document. 117 - Domain: See [RFC4726]. A domain is considered to be any 118 collection of network elements within a common sphere of address 119 management or path computational responsibility. Note that nested 120 domains continue to be out of scope. Section 1.2 provides some more 121 details. 123 - Working LSP: See [RFC4427]. The working LSP transports normal user 124 traffic. Note that the term LSP and TE LSP will be used 125 interchangeably. 127 - Recovery LSP: See [RFC4427]. The recovery LSP transports normal 128 user traffic when the working LSP fails. The recovery LSP may 129 transport user traffic even when the working LSP is transporting 130 normal user traffic (e.g., 1+1 protection). In such a scenario, 131 the recovery LSP is sometimes referred to as a protecting LSP. 133 - Diversity: See [RFC4726]. Diversity means the relationship 134 of multiple LSPs, where those LSPs do not share some specific type 135 of resource (e.g., link, node, or shared risk link group (SRLG)). 136 Diverse LSPs may be used for various purposes, such as load- 137 balancing and recovery. In this document, the recovery aspect of 138 diversity, specifically the end-to-end diversity of two traffic 139 engineering (TE) LSPs, is the focus. Those two diverse LSPs are 140 referred to as the working LSP and recovery LSP hereafter. 141 Sometimes, diversity is referred to as disjointness. 143 - Confidentiality: See [RFC4216]. The term confidentiality applies 144 to the protection of information about the topology and resources 145 present within one domain from visibility by people or 146 applications outside that domain. 148 1.2 Domain 150 As defined in [RFC4726], a domain is considered to be any collection 151 of network elements within a common sphere of address management or 152 path computational responsibility. Examples of such domains include 153 IGP areas and Autonomous Systems. A network accessed over the 154 Generalized Multiprotocol Label Switching (GMPLS) User-to-Network 155 Interface (UNI) [RFC4208] and a Layer One Virtual Private Network 156 (L1VPN) [RFC4847] are special cases of multi-domain networks. 158 Example objectives of domain usage include administrative separation, 159 scalability, and forming protection domains. 161 As described in [RFC4726], there could be TE parameters (such as 162 color and priority) whose meanings are specific to each domain. In 163 such scenarios, mapping functions could be performed based on policy 164 agreements between domain administrators. 166 1.3 Document Scope 168 This document analyzes various schemes to realize Multiprotocol Label 169 Switching (MPLS) and Generalized MPLS (GMPLS) LSP recovery in multi- 170 domain networks based on the existing framework for multi-domain LSP 171 setup [RFC4726]. Note that this document does not intend to prevent 172 development of additional techniques where appropriate (i.e., 173 additional to ones described in this document, which are based on the 174 existing framework described in [RFC4726]). In other words, this 175 document is informational and intends to show how the existing 176 framework can be applied with specific procedures described in this 177 document and the documents referred to by this document. 179 There are various recovery techniques for LSPs. For TE LSPs, major 180 techniques are end-to-end recovery [RFC4872], local protection such 181 as Fast Reroute (FRR) [RFC4090] (in packet switching environments), 182 and segment recovery [RFC4873] (in GMPLS). 184 In this document the main focus is the analysis of diverse TE LSP 185 (hereafter LSP) setup schemes (path computation and signaling 186 aspects), which can advantageously be used in the context of end-to- 187 end recovery. This document presents various diverse LSP setup 188 schemes by combining various functional elements. In particular, 189 Section 5.5 of [RFC4726] describes some analysis of diverse LSPs in 190 multi-domain networks, and this document provides more detailed 191 analysis based on that content. 193 [RFC4105] and [RFC4216] describe requirements for diverse LSPs. There 194 could be various types of diversity, and this document focuses on 195 node/link/SRLG diversity. 197 Based on the service grade, both the working LSP and the recovery LSP 198 may be established at the time of service establishment (e.g., 199 service requiring high resiliency). Alternatively, the recovery LSP 200 may be added later due to a change in the grade of the service. This 201 document covers both scenarios. Also, there may or may not be 202 confidentiality requirements among domains. This document covers both 203 scenarios. Section 3.2 describes more details on confidentiality. 205 Specific assumptions made in this problem space are described in 206 Section 2. 208 Note that the recovery LSP may be used for 1+1 protection, 1:1 209 protection, or shared mesh restoration. However, ways to compute 210 diverse paths, and the signaling of these TE LSPs are common across 211 all uses, and these topics are the main scope of this document. 213 Also, note that diverse LSPs may be used for various purposes, in 214 addition to recovery. An example is for load-balancing, so as to 215 limit the traffic disruption to a portion of the traffic flow in case 216 of a single network element failure. This document does not preclude 217 use of diverse LSP setup schemes for those purposes. 219 The following are beyond the scope of this document. 221 - Analysis of recovery techniques other than link/node/SRLG diverse 222 LSPs (see Section 1.4). 223 - Details of maintenance of diverse LSPs, such as re-optimization and 224 OAM. 225 - Comparative evaluation of various diverse LSP setup schemes 226 mentioned in this document. 228 1.4 Note on Other Recovery Techniques 230 Fast Reroute and segment recovery in multi-domain networks are 231 described in Section 5.4 of [RFC4726], and a more detailed analysis 232 is provided in Section 5 of [inter-domain-rsvp]. This document does 233 not cover any additional analysis for Fast ReRoute and segment 234 recovery in multi-domain networks. 236 Also, the recovery type of an LSP or service may change at a domain 237 boundary. That is, the recovery type could remain the same within one 238 domain, but might be different in the next domain. This may be due to 239 the capabilities of each domain, administrative policies, or to 240 topology limitations. An example is where protection at the domain 241 boundary is provided by link protection on the inter-domain link(s), 242 but where protection within each domain is achieved through segment 243 recovery. This mixture of protection techniques is beyond the scope 244 of this document. 246 Domain diversity (that is, the selection of paths that have only the 247 ingress and egress domains in common) may be considered as one form 248 of diversity in multi-domain networks, but this is beyond the scope 249 of this document (see Section 2.2). 251 1.5 Signaling Options 253 There are three signaling options for establishing inter-domain TE 254 LSPs: nesting, contiguous LSPs, and stitching [RFC4726]. The 255 description in this document of diverse LSP setup is agnostic in 256 relation to the signaling option used, unless otherwise specified. 258 Note that signaling option-specific considerations for Fast Reroute 259 and segment recovery are described in Section 5 of [inter-domain- 260 rsvp]. 262 2. Diversity in Multi-domain Networks 264 As described in Section 1.3, analysis of diverse LSP setup schemes in 265 multi-domain networks is the main focus of this document. This 266 section describes some assumptions in this problem space made in this 267 document. 269 2.1 Multi-domain Network Topology 271 Figures 1 and 2 show example multi-domain network topologies. In 272 Figure 1, domains are connected in a linear topology. There are 273 multiple paths between nodes A and L, but all of them cross domain#1- 274 domain#2-domain#3 in that order. 276 +--Domain#1--+ +--Domain#2--+ +--Domain#3--+ 277 | | | | | | 278 | B------+---+---D-----E--+---+------J | 279 | / | | \ / | | \ | 280 | / | | \ / | | \ | 281 | A | | H | | L | 282 | \ | | / \ | | / | 283 | \ | | / \ | | / | 284 | C------+---+---F-----G--+---+------K | 285 | | | | | | 286 +------------+ +------------+ +------------+ 288 Figure 1: Linear Connectivity 289 +-----Domain#2-----+ 290 | | 291 | E--------------F | 292 | | | | 293 | | | | 294 +-+--------------+-+ 295 | | 296 | | 297 +--Domain#1-+--+ +-------+------+ 298 | | | | | | 299 | | | | | | 300 | A----B--+---+--C----D | 301 | | | | | | 302 | | | | | | 303 +------+-------+ +--+-Domain#4--+ 304 | | 305 +-+--------------+-+ 306 | | | | 307 | | | | 308 | G--------------H | 309 | | 310 +-----Domain#3-----+ 312 Figure 2: Mesh Connectivity 314 In Figure 2, domains are connected in a mesh topology. There are 315 multiple paths between nodes A and D, and these paths do not 316 necessarily follow the same set of domains. 318 Indeed, if inter-domain connectivity forms a mesh, domain level 319 routing is required (even for the unprotected case). This is tightly 320 coupled with the next hop domain resolution/discovery mechanisms. 322 In this document, we assume that domain level routing is given via 323 configuration, policy, or some external mechanism, and that this is 324 not part of the path computation process described later in this 325 document. 327 In addition, domain level routing may perform "domain re-entry", 328 where a path enters a domain after the path exits that domain (e.g., 329 domain#X-domain#Y-domain#X). This requires specific considerations 330 when confidentiality is required (described in Section 3.2), and is 331 beyond the scope of this document. 333 Furthermore, the working LSP and the recovery LSP may or may not be 334 routed along the same set of domains in the same order. In this 335 document, we assume that the working LSP and recovery LSP follow the 336 same set of domains in the same order (via configuration, policy or 337 some external mechanism). That is, we assume that the domain mesh 338 topology is reduced to a linear domain topology for each pair of 339 working and recovery LSPs. 341 In summary, 343 - There is no assumption about the multi-domain network topology. For 344 example, there could be more than two domain boundary nodes or 345 inter-domain links (links connecting a pair of domain boundary 346 nodes belonging to different domains). 347 - However, there is an assumption that under such a network topology, 348 the set of domains that the working LSP and the recovery LSP follow 349 must be the same and pre-configured. 350 - Domain re-entry is not considered. 352 2.2 Note on Domain Diversity 354 As described in Section 1.4, domain diversity means the selection of 355 paths that have only the ingress and egress domains in common. This 356 may provide enhanced resilience against failures, and is a way to 357 ensure path diversity for most of the path of the LSP. 359 In Section 2.1 we assumed that the working LSP and the recovery LSP 360 follow the same set of domains in the same order. Under this 361 assumption, domain diversity cannot be achieved. However, by relaxing 362 this assumption, domain diversity could be achieved, e.g., by either 363 of the following schemes. 365 - Consider domain diversity as a special case of SRLG diversity 366 (i.e., assign an SRLG ID to each domain). 367 - Configure domain level routing to provide domain diverse paths 368 (e.g., by means of AS_PATH in BGP). 370 Details are beyond the scope of this document. 372 3. Factors to Consider 374 3.1 Scalability versus Optimality 376 As described in [RFC4726], scalability and optimality are two 377 conflicting objectives. Note that the meaning of optimality differs 378 depending on each network operation. Some examples of optimality in 379 the context of diverse LSPs are: 381 - Minimizing the sum of their cost while maintaining diversity. 382 - Restricting the difference of their cost (so as to minimize delay 383 difference after switch-over) while maintaining diversity. 385 By restricting TE information distribution to only within each domain 386 (and not across domain boundaries) as required by RFC4105 and 387 RFC4216, it may not be possible to compute an optimal path. As such, 388 it may not be possible to compute diverse paths, even if they exist. 389 However, if we assume domain level routing is given (as discussed in 390 Section 2), it is possible to compute diverse paths using specific 391 computation schemes, if such paths exist. This is discussed in 392 Section 4. 394 3.2 Key Concepts 396 Three key concepts to classify various diverse LSP computation and 397 setup schemes are presented below. 399 o With or without confidentiality 401 - Without confidentiality 403 Under this network configuration, it is possible to specify (by 404 means of the Explicit Route Object - ERO - comprising a list of 405 strict hops) or obtain record of (by means of the Record Route 406 Object - RRO) a route across other domains. 408 Examples of this configuration are multi-area networks, and some 409 forms of multi-AS networks (especially within the same provider). 411 - With confidentiality 413 Under this network configuration, it is not possible to specify 414 or obtain a full and strict route (by means of ERO/RRO) across 415 other domains, although paths may be specified/obtained in the 416 form of an ERO/RRO containing loose hops. Therefore, it is not 417 possible to specify or obtain a full route at the head-end of a 418 multi-domain LSP. 420 Examples of this configuration are some forms of multi-AS 421 networks (especially inter-provider networks), GMPLS-UNI 422 networks, and L1VPNs. 424 o Per domain path computation or inter-domain collaborative path 425 computation 427 - Per domain path computation 429 In this scheme, a path is computed domain by domain as LSP 430 signaling progresses through the network. This scheme requires 431 ERO expansion in each domain. The case for unprotected LSPs under 432 this scheme is covered in [inter-domain-pd]. 434 - Inter-domain collaborative path computation 435 In this scheme, path computation is typically done before 436 signaling. This scheme typically uses communication between 437 cooperating path computation elements (PCEs) [RFC4655]. An 438 example of such a scheme is Backward Recursive Path Computation 439 (BRPC) [brpc]. The use of BRPC for unprotected LSPs under this 440 scheme is covered in [brpc]. 442 Note that these are path computation techniques. It is also 443 possible to obtain a path via management configuration, or head-end 444 path computation (with multi-domain visibility). This is discussed 445 in Sections 4 and 5. 447 Note also that it is possible to combine multiple path computation 448 techniques (including using a different technique for the working 449 and recovery LSPs), but details are beyond the scope of this 450 document. 452 o Sequential path computation or simultaneous path computation 454 - Sequential path computation 456 The path of the working LSP is computed (without considering the 457 recovery LSP), and then the path of the recovery LSP is computed. 458 Typically, this scheme is applicable when the recovery LSP is 459 added later as change of the service grade. But this scheme can 460 also be applicable when both of the working and recovery LSPs are 461 established from the start. In this scheme, diverse LSPs may not 462 be correctly computed (without some form of re-optimization or 463 recomputation technique) in "trap" topologies. Furthermore, such 464 sequential path computation approaches may prevent the selection 465 of an "optimal" solution with regards to a specific objective 466 function. 468 - Simultaneous path computation 470 The path of the working LSP and the path of the recovery LSP are 471 computed simultaneously. Typically, this scheme is applicable 472 when both the working LSP and the recovery LSP are established 473 together. In this scheme, it is possible to avoid trap 474 topologies. Furthermore it may allow for achieving more optimal 475 results. 477 Note that LSP setup with or without confidentiality is given as a 478 per-domain configuration, while the choices of per-domain path 479 computation or inter-domain collaborative path computation, and 480 sequential path computation or simultaneous path computation may be a 481 matter of choice for each individual pair of working/recovery LSPs. 483 The analysis of various diverse LSP setup schemes is described in 484 Sections 4 and 5, based on above criteria. 486 Some other considerations, such as network topology-specific 487 considerations, addressing considerations, and SRLG diversity are 488 described in Sections 6, 7, and 8. 490 4. Diverse LSP Setup Schemes without Confidentiality 492 In the following, various schemes for diverse LSP setup are presented 493 based on different path computation techniques assuming that there is 494 no requirement for confidentiality between domains. Section 5 makes a 495 similar examination of schemes where inter-domain confidentiality is 496 required. 498 4.1 Management Configuration 500 Section 3.1 of [RFC4726] describes this path computation technique. 501 The full explicit paths for the working and recovery LSPs are 502 specified by a management application at the head-end, and no further 503 computation or signaling considerations are needed. 505 4.2 Head-end Path Computation (with multi-domain visibility) 507 Section 3.2.1 of [RFC4726] describes this path computation technique. 508 The full explicit paths for the working and recovery LSPs are 509 computed at the head-end either by the head-end itself or by a PCE. 510 In either case the computing entity has full TE visibility across 511 multiple domains and no further computation or signaling 512 considerations are needed. 514 4.3 Per-domain Path Computation 516 Sections 3.2.2, 3.2.3 and 3.3 of [RFC4726] describe this path 517 computation technique. More detailed procedures are described in 518 [inter-domain-pd]. 520 In this scheme, the explicit paths of the working and recovery LSPs 521 are specified as the complete strict path in the source domain 522 followed by one of the following: 524 - The complete list of boundary LSRs (or domain identifiers, e.g., AS 525 numbers) along the path. 527 - The boundary LSR for the source domain and the LSP destination. 529 Thus, ERO expansion is needed at domain boundaries. Path computation 530 is performed by, or by a PCE on behalf of, each domain boundary LSR. 532 For establishing diverse LSPs using per-domain computation, there are 533 two specific schemes, which are described in Sections 4.3.1 and 4.3.2 534 respectively. 536 4.3.1 Sequential Path Computation 538 The RSVP-TE EXCLUDE_ROUTE Object (XRO) [RFC4874] can be used. Details 539 are as follows. It should be noted that the PRIMARY_PATH_ROUTE Object 540 defined in [RFC4872] for end-to-end protection is not intended as a 541 path exclusion mechanism. 543 Assume that the working LSP is established as described in [inter- 544 domain-pd]. Also, assume that the route of the working LSP (full 545 route) is available at the head-end through the RRO. 547 o Path computation aspect 549 When performing path computation (ERO expansion) for the recovery 550 LSP as it crosses each domain boundary a path is selected that 551 avoids the nodes/links/SRLGs used by the working path so that a 552 diverse path is obtained. When path computation is performed by a 553 PCE on behalf of each domain boundary LSR, the resources to avoid 554 can be communicated to a PCE using the XRO extension [PCEP-XRO] to 555 the PCE Protocol (PCEP) [PCEP]. 557 o Signaling aspect 559 In order that the computation noted above can be performed, each 560 computation point must be aware of the path of the working LSP. 561 This information can be supplied in the XRO included in the Path 562 message for recovery LSP. The XRO lists nodes, links and SRLGs that 563 must be avoided by the LSP being signaled, and its contents are 564 copied from the RRO of the working LSP. 566 This scheme cannot guarantee to establish diverse LSPs (even if they 567 could exist) because the first LSP is established without 568 consideration of the need for a diverse recovery LSP. Crankback 569 [RFC4920] may be used in combination with this scheme in order to 570 improve the possibility of successful diverse LSP setup. Furthermore, 571 re-optimization of the working LSP and the recovery LSP may be used 572 to achieve fully diverse paths. 574 Note that even if a solution is found, the degree of optimality of 575 the solution (i.e., of the set of diverse TE LSPs) might not be 576 maximal. 578 4.3.2 Simultaneous Path Computation 580 o Path computation aspect 581 When signaling the working LSP, the path of not only the working 582 LSP, but also the recovery LSP is computed. For example, in 583 Figure 1, when node D receives a Path message for the working LSP 584 between nodes A and L, node D expands the ERO to reach domain#3. At 585 the same time, node D computes a path for the recovery LSP across 586 the same domain from node F to reach domain#3. The entry boundary 587 node for the recovery LSP (node F) needs to be known by the entry 588 boundary node for the working LSP (node D). In this example the 589 path for the working LSP may be computed by node D as D-E-domain#3, 590 and the path for recovery LSP as F-G-domain#3. 592 o Signaling aspect 594 Two signaling features are needed in order to make this scheme 595 work. 597 - A mechanism is needed to signal, during working LSP setup, the 598 entry boundary node to be used by the recovery LSP. This 599 mechanism may grow in complexity as the length of the chain of 600 domains grows, and as the interconnectivity of the domains 601 becomes more complex. But it may be perfectly feasible in simpler 602 topologies. 604 - There must be a mechanism to force the recovery LSP to follow the 605 route computed above. One way to realize this is to have a 606 specific object (with the same format as the ERO) to collect the 607 route of the recovery LSP in the Path message for the working LSP 608 and to return is to the head-end in the Resv message. When 609 signaling the recovery LSP, the content of the ERO is copied from 610 this object. 612 Protocol mechanisms to achieve these signaling features are not 613 currently available. The definition of protocol extensions is 614 beyond the scope of this document. 616 This scheme also cannot guarantee to establish diverse LSPs (even if 617 they could exist) if there are more than two domain boundary nodes 618 out of each domain. Crankback [RFC4920] may also be used in 619 combination with this scheme to improve the chances of success. 621 Note that even if a solution is found, the degree of optimality of 622 the solution (i.e., of the set of diverse TE LSPs) might not be 623 maximal. 625 4.4 Inter-domain Collaborative Path Computation 627 Section 3.4 of [RFC4726] describes this approach, and [brpc] provides 628 detail of Backward Recursive Path Computation which is a 629 collaborative path computation technique. Path computation is 630 performed for each of the working and recovery LSPs by the use of 631 inter-PCE communication before each LSP is signaled. 633 There are two specific schemes for establishing diverse LSPs using 634 this scheme, which are described in Sections 4.4.1 and 4.4.2. 636 4.4.1 Sequential Path Computation 638 Route exclusion using the XRO [PCEP-XRO] can be requested in PCEP 639 [PCEP], and this can be used to compute the path of a recovery LSP 640 after the path of the working LSP has been determined. Details are as 641 follows. 643 The working LSP is computed using a collaborative PCE approach such 644 as that described in [brpc], and the LSP may be immediately 645 established. Assume that the path of the working LSP (full route) is 646 available from the computation request or from the RRO. 648 o Path computation aspect 650 When requesting path computation for the recovery LSP, an XRO is 651 included in the PCEP path computation request message (see 652 [PCEP-XRO]). The content of the XRO is copied from the RRO of the 653 working LSP. Alternatively, the content of the XRO is copied from 654 the ERO of the path computation reply for the working LSP. The 655 latter case is useful when the working LSP is not established at 656 the time of the path computation request for the recovery LSP. The 657 computation request specifies that the full route must be returned. 658 Per-domain PCEs may need to be invoked by the first PCE that is 659 consulted in order to collaboratively determine the correct path 660 for the recovery LSP (just as described in [RFC4655] and [RFC4726] 661 for the computation of a single inter-domain LSP by collaborating 662 PCEs), and these PCEs exchange the XRO information to ensure that 663 the computed path is diverse from the working LSP. 665 o Signaling aspect 667 The recovery LSP is signaled by including an ERO whose content is 668 copied from the result returned by the PCE. 670 This scheme cannot guarantee to establish diverse LSPs (even if they 671 exist) because the working LSP may block the recovery LSP. In such a 672 scenario, re-optimization of the working and recovery LSPs may be 673 used to achieve fully diverse paths. 675 4.4.2 Simultaneous Path Computation 677 o Path computation aspect 678 The PCEP SVEC Object [PCEP] allows diverse path computation to be 679 requested. It would be possible to extend BRPC [brpc] to compute 680 diverse paths through the definition of a specific process. Such 681 extensions are beyond the scope of this document. 683 o Signaling aspect 685 In this scheme the PCE returns the full routes for the working and 686 recovery LSPs and they are signaled accordingly. 688 This scheme can guarantee to establish diverse LSPs (if they exist), 689 assuming domain level routing is given as described in Section 2. 691 Furthermore, the computed set of TE LSPs can be guaranteed to be 692 optimal with respect to some objective functions. 694 5. Diverse LSP Setup Schemes with Confidentiality 696 In the context of this section, the term confidentiality applies to 697 the protection of information about the topology and resources 698 present within one domain from visibility by people or applications 699 outside that domain. This includes, but is not limited to, recording 700 of LSP routes, in addition to advertisements of TE information. The 701 confidentiality does not apply to the protection of user traffic. 703 Diverse LSP setup schemes with confidentiality are similar to ones 704 without confidentiality. However, several additional mechanisms are 705 needed to preserve confidentiality. Examples of such mechanisms are: 707 - Path key: Provide each per-domain segment of the path in advance to 708 the domain boundary nodes or to the PCE that computed the path for 709 a limited period of time (temporary caching) and identify it in the 710 signaled ERO using a path key. When path computation is done by 711 PCE, the identify of the PCE containing state for the path may be 712 required as well (e.g., PCE I-D). The path key is provided by the 713 PCE to the head-end for inclusion in the ERO [conf-segment]. 715 - LSP segment: Pre-establish each per-domain segments of the path 716 using hierarchical LSPs [RFC4206] or LSP stitching segments 717 [LSP-stitch] and signal the end-to-end LSP to use these per-domain 718 LSPs. This scheme might need additional identifiers (such as LSP 719 IDs) in the Path message so that the domain boundary node can 720 identify which LSP segment or tunnel to use for the end-to-end LSP. 721 Furthermore, this scheme may require additional communication to 722 pre-establish the LSP segments. 724 These techniques may be directly applied, or may be applied with 725 extensions, depending on specific diverse LSP setup schemes described 726 below. 728 Note that in the schemes below, the paths of the working and recovery 729 LSPs are not impacted by the confidentiality requirements. 731 5.1 Management Configuration 733 It is not possible to obtain or specify the full explicit route for 734 either LSP at the head-end due to confidentiality restrictions. 735 Therefore, this information cannot be provided to signaling for LSP 736 setup. 738 Confidentiality does not prevent the full computation of inter-domain 739 paths and signaling of sufficient information to distinguish the 740 paths. However the path information for each domain must be provided 741 in a way that does not have meaning to other domains. Example 742 mechanisms to preserve confidentiality as described above, include: 744 - Path key 745 - LSP segment 747 5.2 Head-end Path Computation (with multi-domain visibility) 749 This scheme is not applicable since multi-domain visibility violates 750 confidentiality. 752 5.3 Per-Domain Path Computation 754 5.3.1 Sequential Path Computation 756 Assume the working LSP is established as described in [inter-domain- 757 pd]. 759 It is not possible to obtain the route of the working LSP from the 760 RRO at the head-end due to confidentiality restrictions. In order to 761 provide the path of the working LSP through each domain to the 762 computation point responsible for computing the path of the 763 protection LSP through each domain additional mechanisms are needed. 764 Examples of such mechanisms are: 766 - Information identifying the working LSP is included in the Path 767 message for the recovery LSP, and the domain boundary node consults 768 the entity which computed the path of the working LSP (i.e., domain 769 boundary node or PCE), so that the diverse path can be computed. 770 When the entity which computed the path of the working LSP is the 771 PCE, PCE needs to be temporarily stateful. An example of such 772 information is the Association Object [RFC4872]. 774 5.3.2 Simultaneous Path Computation 776 In this scheme the intention is to compute the path of the recovery 777 LSP at the same time as the working LSP. In order to force the 778 recovery LSP to follow the computed path as well as to preserve 779 confidentiality, additional mechanisms are needed to communicate the 780 computed recovery path from the path of the working LSP (where it was 781 computed) to the recovery LSP. Examples of such mechanisms, that must 782 continue to preserve confidentiality, are as follows. 784 - LSP segment: As described before. The LSP segment for the recovery 785 LSP is established domain-by-domain as the working LSP setup 786 progresses. How to initiate such LSP segments for the recovery LSP 787 is beyond the scope of this document. 789 - Alternatively, information identifying the working LSP is included 790 in the Path message for the recovery LSP, and the domain boundary 791 node consults the entity which computed the path of the recovery 792 LSP (i.e., domain boundary node or PCE), so as to obtain the path 793 of the recovery LSP. This requires that the entity which computed 794 the path of the recovery LSP is temporarily stateful. An example of 795 such information is the Association Object [RFC4872]. Detailed 796 protocol specifications are beyond the scope of this document. 798 5.4 Inter-domain Collaborative Path Computation 800 5.4.1 Sequential Path Computation 802 Route exclusion using the XRO [PCEP-XRO] in combination with the path 803 key [conf-segment] can be requested in PCEP [PCEP] and this can be 804 used to compute the path of a recovery LSP after the path of the 805 working LSP has been determined. Details are as follows. 807 The working LSP is computed as described in [brpc] with the help of 808 path key [conf-segment], and may be immediately established. It is 809 not possible to obtain the RRO of the working LSP (full route) at the 810 head-end due to confidentiality restrictions. 812 o Path computation aspect 814 This is similar to the case without confidentiality (Section 815 4.4.1), but in order to preserve confidentiality, additional 816 mechanisms are needed. 818 In the PCEP path computation request for the recovery LSP, an XRO 819 is included. The content of the XRO is copied from the ERO of the 820 path computation reply for the working LSP, which is given in the 821 form of strict hops for the local domain, domain boundaries or 822 domain identifiers, and path keys. When a PCE receives XRO 823 containing one or more path keys, it needs to retrieve the original 824 content and perform path computation for the recovery LSP excluding 825 certain nodes/links/SRLGs. It is likely that the content (i.e., 826 expansion) of the path key cannot be directly retrieved by a PCE in 827 one domain from a PCE in another domain since that act would 828 violate the intended confidentiality. Thus, path key expansion and 829 the computation of a path across a domain must both be performed 830 within that domain. 832 o Signaling aspect 834 The full route for the recovery LSP can not be returned to the 835 head-end by PCE because it cannot be collected from the other PCEs 836 owing to confidentiality restrictions. In order to force the 837 recovery LSP to follow the path computed above, additional 838 mechanisms are needed. Examples of such mechanisms are as described 839 before: 841 - Path key 842 - LSP segment 844 5.4.2 Simultaneous Path Computation 846 As described in Section 4.4.2, diverse path computation can be 847 requested by PCEP SVEC Object [PCEP], and [brpc] can be extended for 848 inter-domain diverse path computation. However, it is not possible 849 for PCE to return the full route of the working LSP and recovery LSP 850 to the head-end due to confidentiality. In order to force the working 851 and recovery LSPs to follow the paths computed, additional mechanisms 852 are needed. Examples of such mechanisms are as described before: 854 - Path key: Use this for the working and recovery LSPs. 856 Note that the LSP segment approach in Section 5 may not be applicable 857 here because a path cannot be determined until BRPC procedures are 858 completed. 860 6. Network Topology Specific Considerations 862 In some specific network topologies, diverse LSP setup schemes 863 mentioned above could be drastically simplified. 865 For example, assume there are only three domains connected linearly, 866 and the first and the last domain contain only a single node. Assume 867 that we need to establish diverse LSPs from the node in the first 868 domain to the node in the last domain. In such a scenario, no BRPC 869 procedures are needed, because there is no need for path computation 870 in the first and last domains. 872 7. Addressing Considerations 874 All of the above-mentioned schemes are applicable when a single 875 address space is used across all domains. 877 However, there could be cases where private addresses are used within 878 some of the domains. This case is similar to the one with 879 confidentiality, since the ERO and RRO are meaningless even if they 880 are available. This document does not exclude other schemes, but 881 details are beyond the scope of this document. 883 8. Note on SRLG Diversity 885 The above-mentioned schemes are applicable when the nodes and links 886 in different domains belong to different SRLGs. 888 However, there could be cases where the nodes and links in different 889 domains belong to the same SRLG. That is, where SRLGs span domain 890 boundaries. In such cases, in order to establish SRLG diverse LSPs, 891 several considerations are needed, such as: 893 - Record of the SRLGs used by the working LSP. 894 - Indication of a set of SRLGs to exclude in the computation of the 895 recovery LSP's path. 897 Furthermore, SRLG IDs may be assigned independently in each domain, 898 and might not have global meaning. In such a scenario, some mapping 899 functions are necessary, similar to the mapping of other TE 900 parameters mentioned in Section 1.2. 902 9. Security Considerations 904 This document does not require additional security considerations 905 mentioned in [RFC4726], which is the basis of this document. That is, 906 LSP path computation and setup across domain boundaries is 907 necessarily a security concern and will be subject to operational 908 policies. In particular, the trust model across domain boundaries for 909 computation and signaling must be carefully considered since LSP 910 setup (whether successful or not) can consume domain network data 911 resources (bandwidth), and signaling or computation requests can 912 consume network processing resources (CPU and control channel 913 bandwidth). 915 RSVP-TE [RFC3209] and PCEP [PCEP] include policy and authentication 916 capabilities, and these should be seriously considered in all inter- 917 domain deployments. 919 More discussion on security considerations in MPLG/GMPLS networks is 920 found in a specific document [security-fw]. 922 10. References 924 10.1 Normative References 926 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 927 Srinivasan, V., and G. Swallow, "RSVP-TE: 928 Extensions to RSVP for LSP Tunnels", RFC 3209, 929 December 2001. 931 [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A 932 Framework for Inter-Domain MPLS Traffic 933 Engineering", RFC 4726, November 2006. 935 [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., 936 "Recovery (Protection and Restoration) 937 Terminology for Generalized Multi-Protocol Label 938 Switching (GMPLS)", RFC 4427, March 2006. 940 10.2 Informative References 942 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. 943 Rekhter, "Generalized Multiprotocol Label 944 Switching (GMPLS) User-Network Interface (UNI): 945 Resource ReserVation Protocol-Traffic Engineering 946 (RSVP-TE) Support for the Overlay Model", 947 RFC 4208, October 2005. 949 [RFC4847] Takeda, T., Ed., "Framework and Requirements for 950 Layer 1 Virtual Private Networks", RFC 4847, 951 April 2007. 953 [RFC4655] Farrel, A., Vasseur, JP., and J. Ash, "Path 954 Computation Element (PCE) Architecture", 955 RFC 4655, August 2006. 957 [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D. 958 (Eds.), "RSVP-TE Extensions in support of End-to- 959 End Generalized Multi-Protocol Label Switching 960 (GMPLS)-based Recovery", RFC 4872, May 2007. 962 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast 963 Reroute Extensions to RSVP-TE for LSP Tunnels", 964 RFC 4090, May 2005. 966 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and 967 A. Farrel, "GMPLS Based Segment Recovery", 968 RFC 4873, May 2007. 970 [RFC4105] Le Roux, J.-L. , Vasseur, J.-P., and J. Boyle, 971 "Requirements for Inter-Area MPLS Traffic 972 Engineering", RFC 4105, June 2005. 974 [RFC4216] Zhang, R., and Vasseur, J.-P., "MPLS Inter- 975 Autonomous System (AS) Traffic Engineering (TE) 976 Requirements", RFC 4216, November 2005 978 [inter-domain-rsvp] Farrel, A., Ed., "Inter domain Multiprotocol 979 Label Switching (MPLS) and Generalized MPLS 980 (GMPLS) Traffic Engineering - RSVP-TE 981 extensions", draft-ietf-ccamp-inter-domain-rsvp- 982 te, work in progress. 984 [RFC4874] Lee, C.Y., Farrel, A., and De Cnodder, S., 985 "Exclude Routes - Extension to Resource 986 ReserVation Protocol-Traffic Engineering 987 (RSVP-TE)", RFC 4874, April 2007. 989 [inter-domain-pd] Vasseur JP., Ed., and Ayyangar A., Ed., "A Per- 990 domain path computation method for establishing 991 Inter-domain Traffic Engineering (TE) Label 992 Switched Paths (LSPs)", draft-ietf-ccamp-inter- 993 domain-pd-path-comp, work in progress. 995 [brpc] Vasseur, JP., Ed., "A Backward Recursive 996 PCE-based Computation (BRPC) procedure to compute 997 shortest inter-domain Traffic Engineering Label 998 Switched Paths", draft-ietf-pce-brpc, work in 999 progress. 1001 [PCEP-XRO] Oki, E., and A. Farrel, "Extensions to the Path 1002 Computation Element Communication Protocol (PCEP) 1003 for Route Exclusions", draft-ietf-pce-pcep-xro, 1004 work in progress. 1006 [PCEP] Vasseur, JP., Ed., and Le Roux, JL., Ed., "Path 1007 Computation Element (PCE) communication Protocol 1008 (PCEP)", draft-ietf-pce-pcep, work in progress. 1010 [conf-segment] Bradford, R., Ed., "Preserving Topology 1011 Confidentiality in Inter-Domain Path Computation 1012 using a key based mechanism ", draft-ietf-pce- 1013 path-key, work in progress. 1015 [RFC4920] Farrel, A., Ed., "Crankback Signaling Extensions 1016 for MPLS and GMPLS RSVP-TE ", RFC 4920, 1017 July 2007. 1019 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched 1020 Paths (LSP) Hierarchy with Generalized Multi- 1021 Protocol Label Switching (GMPLS) Traffic 1022 Engineering (TE)", RFC 4206, October 2005. 1024 [LSP-stitch] Ayyangar, A., Kompella, K., Vasseur, JP., and 1025 A. Farrel, "Label Switched Path Stitching with 1026 Generalized Multiprotocol Label Switching Traffic 1027 Engineering (GMPLS TE)", draft-ietf-ccamp-lsp- 1028 stitching, work in progress. 1030 [security-fw] Fang, L., " Security Framework for MPLS and GMPLS 1031 Networks", draft-fang-mpls-gmpls-security- 1032 Framework, work in progress. 1034 11. Acknowledgments 1036 Authors would like to thank Eiji Oki, Ichiro Inoue, Kazuhiro 1037 Fujihara, Dimitri Papadimitriou and Meral Shirazipour for valuable 1038 comments. 1040 12. Authors' Addresses 1042 Tomonori Takeda 1043 NTT Network Service Systems Laboratories, NTT Corporation 1044 3-9-11, Midori-Cho 1045 Musashino-Shi, Tokyo 180-8585 Japan 1046 Email : takeda.tomonori@lab.ntt.co.jp 1048 Yuichi Ikejiri 1049 NTT Communications Corporation 1050 Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku 1051 Tokyo 163-1421, Japan 1052 Email: y.ikejiri@ntt.com 1054 Adrian Farrel 1055 Old Dog Consulting 1056 Email: adrian@olddog.co.uk 1058 Jean-Philippe Vasseur 1059 Cisco Systems, Inc. 1060 300 Beaver Brook Road 1061 Boxborough , MA - 01719 1062 USA 1063 Email: jpv@cisco.com 1065 Intellectual Property Consideration 1067 The IETF takes no position regarding the validity or scope of any 1068 Intellectual Property Rights or other rights that might be claimed 1069 to pertain to the implementation or use of the technology 1070 described in this document or the extent to which any license 1071 under such rights might or might not be available; nor does it 1072 represent that it has made any independent effort to identify any 1073 such rights. Information on the procedures with respect to 1074 rights in RFC documents can be found in BCP 78 and BCP 79. 1076 Copies of IPR disclosures made to the IETF Secretariat and any 1077 assurances of licenses to be made available, or the result of an 1078 attempt made to obtain a general license or permission for the use 1079 of such proprietary rights by implementers or users of this 1080 specification can be obtained from the IETF on-line IPR repository 1081 at http://www.ietf.org/ipr. 1083 The IETF invites any interested party to bring to its attention 1084 any copyrights, patents or patent applications, or other 1085 proprietary rights that may cover technology that may be required 1086 to implement this standard. Please address the information to the 1087 IETF at ietf-ipr@ietf.org. 1089 Full Copyright Statement 1091 Copyright (C) The IETF Trust (2007). 1093 This document is subject to the rights, licenses and 1094 restrictions contained in BCP 78, and except as set 1095 forth therein, the authors retain all their rights. 1097 This document and the information contained herein are provided 1098 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1099 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 1100 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE 1101 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1102 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1103 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 1104 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.