idnits 2.17.1 draft-chen-pce-protection-applicability-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 29, 2021) is 1091 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'R3' is mentioned on line 556, but not defined == Unused Reference: 'RFC6805' is defined on line 815, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) -- Obsolete informational reference (is this intentional?): RFC 6006 (Obsoleted by RFC 8306) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group H. Chen 3 Internet-Draft Futurewei 4 Intended status: Informational April 29, 2021 5 Expires: October 31, 2021 7 The Applicability of the PCE to Computing Protection and Recovery Paths 8 for Single Domain and Multi-Domain Networks. 9 draft-chen-pce-protection-applicability-16 11 Abstract 13 The Path Computation Element (PCE) provides path computation 14 functions in support of traffic engineering in Multiprotocol Label 15 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 17 A link or node failure can significantly impact network services in 18 large-scale networks. Therefore it is important to ensure the 19 survivability of large scale networks which consist of various 20 connections provided over multiple interconnected networks with 21 varying technologies. 23 This document examines the applicability of the PCE architecture, 24 protocols, and procedures for computing protection paths and 25 restoration services, for single and multi-domain networks. 27 This document also explains the mechanism of Fast Re-Route (FRR) 28 where a point of local repair (PLR) needs to find the appropriate 29 merge point (MP) to do bypass path computation using PCE. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 31, 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1.1. Inter-domain LSPs . . . . . . . . . . . . . . . . . . 4 68 1.2. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Path Computation Element Architecture Considerations . . . . 6 72 3.1. Online Path Computation . . . . . . . . . . . . . . . . . 7 73 3.2. Offline Path Computation . . . . . . . . . . . . . . . . 7 74 4. Protection Service Traffic Engineering . . . . . . . . . . . 7 75 4.1. Path Computation . . . . . . . . . . . . . . . . . . . . 7 76 4.2. Bandwidth Reservation . . . . . . . . . . . . . . . . . . 7 77 4.3. Disjoint Path . . . . . . . . . . . . . . . . . . . . . . 7 78 4.4. Service Preemption . . . . . . . . . . . . . . . . . . . 8 79 4.5. Share Risk Link Groups . . . . . . . . . . . . . . . . . 8 80 4.6. Multi-Homing . . . . . . . . . . . . . . . . . . . . . . 8 81 4.6.1. Ingress and Egress Protection . . . . . . . . . . . . 8 82 5. Packet Protection Applications . . . . . . . . . . . . . . . 8 83 5.1. Single Domain Service Protection . . . . . . . . . . . . 9 84 5.2. Multi-domain Service Protection . . . . . . . . . . . . . 9 85 5.3. Backup Path Computation . . . . . . . . . . . . . . . . . 9 86 5.4. Fast Reroute (FRR) Path Computation . . . . . . . . . . . 10 87 5.4.1. Methods to find MP and calculate the optimal backup 88 path . . . . . . . . . . . . . . . . . . . . . . . . 10 89 5.4.1.1. Intra-domain node protection . . . . . . . . . . 11 90 5.4.1.2. Boundary node protection . . . . . . . . . . . . 11 91 5.5. Point-to-Multipoint Path Protection . . . . . . . . . . . 15 92 6. Optical Protection Applications . . . . . . . . . . . . . . . 15 93 6.1. ASON Applicability . . . . . . . . . . . . . . . . . . . 15 94 6.2. Multi-domain Restoration . . . . . . . . . . . . . . . . 15 95 7. Path and Service Protection Gaps . . . . . . . . . . . . . . 15 96 8. Manageability Considerations . . . . . . . . . . . . . . . . 15 97 8.1. Control of Function and Policy . . . . . . . . . . . . . 15 98 8.2. Information and Data Models . . . . . . . . . . . . . . . 15 99 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 15 100 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 15 101 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 16 102 8.6. Impact On Network Operations . . . . . . . . . . . . . . 16 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 104 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 105 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 106 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 107 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 108 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 109 13.2. Informative References . . . . . . . . . . . . . . . . . 17 110 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 112 1. Introduction 114 Network survivability remains a major concern for network operators 115 and service providers, particularly as expanding applications such as 116 private and Public Cloud drive increasingly more traffic across 117 longer ranges, to a wider number of users. A variety of well-known 118 pre-planned protection and post-fault recovery schemes have been 119 developed for IP, MPLS and GMPLS networks. 121 The Path Computation Element (PCE) [RFC4655] can be used to perform 122 complex path computation in large single domain, multi-domain and 123 multi-layered networks. The PCE can also be used to compute a 124 variety of restoration and protection paths and services. 126 This document examines the applicability of the PCE architecture, 127 protocols, and protocol extensions for computing protection paths and 128 restoration services. 130 1.1. Domains 132 A domain can be defined as a separate administrative, geographic, or 133 switching environment within the network. A domain may be further 134 defined as a zone of routing or computational ability. Under these 135 definitions a domain might be categorized as an Antonymous System 136 (AS) or an Interior Gateway Protocol (IGP) area (as per [RFC4726] and 137 [RFC4655]), or specific switching environment. 139 In the context of GMPLS, a particularly important example of a domain 140 is the Automatically Switched Optical Network (ASON) subnetwork 141 [G-8080]. In this case, computation of an end-to-end path requires 142 the selection of nodes and links within a parent domain where some 143 nodes may, in fact, be subnetworks. Furthermore, a domain might be 144 an ASON routing area [G-7715]. A PCE may perform the path 145 computation function of an ASON routing controller as described in 146 [G-7715-2]. 148 It is assumed that the PCE architecture should be applied to small 149 inter-domain topologies and not to solve route computation issues 150 across large groups of domains, I.E. the entire Internet. 152 Most existing protocol mechanisms for network survivability have 153 focused on single-domain scenarios. Multi-domain scenarios are much 154 more complex and challenging as domain topology information is 155 typically not shared outside each specific domain. 157 Therefore multi-domain survivability is a key requirement for today's 158 complex networks. It is important to develop more adaptive multi- 159 domain recovery solutions for various failure scenarios. 161 1.1.1. Inter-domain LSPs 163 Three signaling options are defined for setting up an inter-area or 164 inter-AS LSP [RFC4726]: 166 o Contiguous LSP 168 o Stitched LSP 170 o Nested LSP 172 1.2. Recovery 174 Typically traffic-engineered networks such as MPLS-TE and GMPLS, use 175 protection and recovery mechanisms based on the pre-established use 176 of a packet or optical LSP and/or the availability of spare resources 177 and the network topology. 179 1.3. Requirements Language 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119]. 185 In this document, these words will appear with that interpretation 186 only when in ALL CAPS. Lower case uses of these words are not to be 187 interpreted as carrying [RFC2119] significance. 189 2. Terminology 191 The following terminology is used in this document. 193 ABR: Area Border Router. Router used to connect two IGP areas 194 (Areas in OSPF or levels in IS-IS). 196 ASBR: Autonomous System Border Router. Router used to connect 197 together ASes of the same or different service providers via one 198 or more inter-AS links. 200 BN: Boundary Node (BN). A boundary node is either an ABR in the 201 context of inter-area Traffic Engineering or an ASBR in the 202 context of inter-AS Traffic Engineering. 204 CPS: Confidential Path Segment. A segment of a path that contains 205 nodes and links that the AS policy requires not to be disclosed 206 outside the AS. 208 CSP: Communication Service Provide. 210 CSPF: Constrained Shorted Path First Algorithm. 212 ERO: Explicit Route Object. 214 FRR: Fast Re-Route. 216 IGP: Interior Gateway Protocol. Either of the two routing 217 protocols, Open Shortest Path First (OSPF) or Intermediate System 218 to Intermediate System (IS-IS). 220 Inter-area TE LSP: A TE LSP whose path transits through two or more 221 IGP areas. 223 Inter-AS TE LSP: A TE LSP whose path transits through two or more 224 ASs or sub-ASs (BGP confederations). 226 IS-IS: Intermediate System to Intermediate System. 228 LSP: Label Switched Path. 230 LSR: Label Switching Router. 232 MP: Merge Point. The LSR where one or more backup tunnels rejoin 233 the path of the protected LSP downstream of the potential failure. 235 OSPF: Open Shortest Path First. 237 PCC: Path Computation Client. Any client application requesting a 238 path computation to be performed by a Path Computation Element. 240 PCE: Path Computation Element. An entity (component, application, 241 or network node) that is capable of computing a network path or 242 route based on a network graph and applying computational 243 constraints. 245 PKS: Path Key Subobject. A subobject of an Explicit Route Object or 246 Record Route Object that encodes a CPS so as to preserve 247 confidentiality. 249 PLR: Point of Local Repair. The head-end LSR of a backup tunnel or 250 a detour LSP. 252 RRO: Record Route Object. 254 RSVP: Resource Reservation Protocol. 256 SRLG: Shared Risk Link Group. 258 TE: Traffic Engineering. 260 TED: Traffic Engineering Database, which contains the topology and 261 resource information of the domain. The TED may be fed by 262 Interior Gateway Protocol (IGP) extensions or potentially by other 263 means. 265 This document also uses the terminology defined in [RFC4655] and 266 [RFC5440]. 268 3. Path Computation Element Architecture Considerations 270 For the purpose of this document it is assumed that the path 271 computation is the sole responsibility of the PCE as per the 272 architecture defined in [RFC4655]. When a path is required the Path 273 Computation Client (PCC) will send a request to the PCE. The PCE 274 will apply the required constraints and compute a path and return a 275 response to the PCC. In the context of this document it may be 276 necessary for the PCE to co-operate with other PCEs in adjacent 277 domains (as per BRPC [RFC5441]) or cooperate with the Parent PCE (as 278 per RFC 6805). 280 A PCE may be used to compute end-to-end paths across single or 281 multiple domains. Multiple PCEs may be dedicated to each area to 282 provide sufficient path computation capacity and redundancy for each 283 domain. 285 During path computation [RFC5440], a PCC request may contain backup 286 LSP requirements in order to setup in the same time the primary and 287 backup LSPs. This request is known as dependent path computations. 288 A typical dependent request for a primary and backup service would 289 request that the computation assign a set of diverse paths, so both 290 services are disjointed from each other. 292 3.1. Online Path Computation 294 Online path computation is performed on-demand as nodes in the 295 network determine that they need to know the paths to use for 296 services. 298 3.2. Offline Path Computation 300 Offline path computation is performed ahead of time, before the LSP 301 setup is requested. That means that it is requested by, or performed 302 as part of, a management application. 304 This method of computation allows the optimal placement of services 305 and explicit control of services. A Communication Service Provide 306 (CSP) can plan where new protection services will be placed ahead of 307 time. Furthermore by computing paths offline specific scenarios can 308 be considered and a global view of network resources is available. 310 Finally, offline path computation provides a method to compute 311 protection paths in the event of a single, or multiple, link 312 failures. This allows the placement of backup services in the event 313 of catastrophic network failures. 315 4. Protection Service Traffic Engineering 317 4.1. Path Computation 319 This document describes how the PCE architecture defined in [RFC4655] 320 may be utilized to compute protection and recovery paths for critical 321 network services. In the context of this document (inter-domain) it 322 may be necessary for the PCE to co-operate with other PCEs in 323 adjacent domains (as per BRPC [RFC5441]) or cooperate with the Parent 324 PCE (as per RFC 6805). 326 4.2. Bandwidth Reservation 328 4.3. Disjoint Path 330 Disjoint paths are required for end-to-end protection services. A 331 backup service may be required to be fully disjoint from the primary 332 service, link disjoint (allowing common nodes on the paths), or best- 333 effort disjoint (allowing shared links or nodes when no other path 334 can be found). 336 4.4. Service Preemption 338 4.5. Share Risk Link Groups 340 4.6. Multi-Homing 342 Networks constructed from multi-areas or multi-AS environments may 343 have multiple interconnect points (multi-homing). End-to-end path 344 computations may need to use different interconnect points to avoid 345 single point failures disrupting primary and backup services. 347 Domain and path diversity may also be required when computing end-to- 348 end paths. Domain diversity should facilitate the selection of paths 349 that share ingress and egress domains, but do not share transit 350 domains. Therefore, there must be a method allowing the inclusion or 351 exclusion of specific domains when computing end-to-end paths. 353 4.6.1. Ingress and Egress Protection 355 An end-to-end primary service carried by a primary TE LSP from a 356 primary ingress node to a primary egress node may need to be 357 protected against the failures in the ingress and the egress. In 358 this case, a backup ingress and a backup egress are required, which 359 are different from the primary ingress and the primary egress 360 respectively. The backup ingress should be in the same domain as the 361 primary ingress, and the backup egress should be in the same domain 362 as the primary egress. 364 A source of the service traffic may be sent to both the primary 365 ingress and the backup ingress (dual-homing). The source may not be 366 in the same domain as the primary ingress and the backup ingress. 367 When the primary ingress fails, the service traffic is delivered 368 through the backup ingress. 370 A receiver of the service traffic may be connected to both the 371 primary egress and the backup egress (dual-homing). The receiver may 372 not be in the same domain as the primary egress and the backup 373 egress. When the primary egress fails, the receiver gets the service 374 traffic from the backup egress. 376 5. Packet Protection Applications 378 Network survivability is a key objective for CSPs, particularly as 379 expanding revenue services (cloud and data center applications) are 380 increasing exponentially. 382 Pre-fault paths are pre-computed and protection resources are 383 reserved a priory for rapid recovery. In the event of a network 384 failure on the primary path, the traffic is fast switched to the 385 backup path. These pre-provisioned mechanisms are capable of 386 ensuring protection against single link failures. 388 Post-fault restoration schemes are reactive and require a reactive 389 routing procedure to set up new working paths in the event of a 390 failure. Post fault restoration can significantly impact network 391 services as they are typically impacted by longer restoration delays 392 and cannot guarantee recovery of a service. However, they are much 393 more network resource efficient and are capable of handling multi- 394 failure situations. 396 5.1. Single Domain Service Protection 398 A variety of pre-planned protection and post-fault restoration 399 recovery schemes are available for single domain MPLS and GMPLS 400 networks, these include: 402 o Path Recovery 404 o Path Segment Recovery 406 o Local Recovery (Fast Reroute) 408 5.2. Multi-domain Service Protection 410 Typically network survivability has focused on single-domain 411 scenarios. By contrast, broader multi-domain scenarios are much more 412 challenging as no single entity has a global view of topology 413 information. As a result, multi-domain survivability is very 414 important. 416 A PCE may be used to compute end-to-end paths across multi-domain 417 environments using a per-domain path computation technique [RFC5152]. 418 The so called backward recursive path computation (BRPC) mechanism 419 [RFC5441] defines a PCE-based path computation procedure to compute 420 inter-domain constrained LSPs. 422 5.3. Backup Path Computation 424 A PCE can be used to compute backup paths in the context of fast 425 reroute protection of TE LSPs. In this model, all backup TE LSPs 426 protecting a given facility are computed in a coordinated manner by a 427 PCE. This allows complete bandwidth sharing between backup tunnels 428 protecting independent elements, while avoiding any extensions to TE 429 LSP signaling. Both centralized and distributed computation models 430 are applicable. In the distributed case each LSR can be a PCE to 431 compute the paths of backup tunnels to protect against the failure of 432 adjacent network links or nodes. 434 5.4. Fast Reroute (FRR) Path Computation 436 As stated in [RFC4090], there are two independent methods (one-to-one 437 backup and facility backup) of doing fast reroute (FRR). PCE can be 438 used to compute backup path for both of the methods. Cooperating 439 PCEs may be used to compute inter-domain backup path. 441 In case of one to one backup method, the destination MUST be the 442 tail-end of the protected LSP. Whereas for facility backup, 443 destination MUST be the address of the merge point (MP) from the 444 corresponding point of local repair (PLR). The problem of finding 445 the MP using the interface addresses or node-ids present in Record 446 Route Object (RRO) of protected path can be easily solved in the case 447 of a single Interior Gateway Protocol (IGP) area because the PLR has 448 the complete Traffic Engineering Database (TED). Thus, the PLR can 449 unambiguously determine - 451 o The MP address regardless of RRO IPv4 or IPv6 sub-objects 452 (interface address or LSR ID). 454 o Does a backup tunnel intersecting a protected TE LSP on MP node 455 exist? This is the case where facility backup tunnel already 456 exists either due to another protected TE LSP or it is pre- 457 configured. 459 It is complex for a PLR to find the MP in case of boundary node 460 protection for computing a bypass path because the PLR doesn't have 461 the full TED visibility. When confidentiality (via path key) 462 [RFC5520] is enabled, finding MP is very complex. 464 This document describes the mechanism to find MP and to setup bypass 465 tunnel to protect a boundary node. 467 5.4.1. Methods to find MP and calculate the optimal backup path 469 The Merge Point (MP) address is required at the PLR in order to 470 select a bypass tunnel intersecting a protected Traffic Engineering 471 Label Switched Path (TE LSP) on a downstream LSR. 473 Some implementations may choose to pre-configure a bypass tunnel on 474 PLR with destination address as MP. MP's Domain to be traversed by 475 bypass path can be administratively configured or learned via some 476 other means (ex Hierarchical PCE (HPCE) RFC 6805). Path Computation 477 Client (PCC) on PLR can request its local PCE to compute bypass path 478 from PLR to MP, excluding links and node between PLR and MP. At PLR 479 once primary tunnel is up, a pre-configured bypass tunnel is bound to 480 the primary tunnel, note that multiple bypass tunnels can also exist. 482 Most implementations may choose to create a bypass tunnel on PLR 483 after primary tunnel is signaled with Record Route Object (RRO) being 484 present in primary path's Resource Reservation Protocol (RSVP) Path 485 Reserve message. MP address has to be determined (described below) 486 to create a bypass tunnel. PCC on PLR can request its local PCE to 487 compute bypass path from PLR to MP, excluding links and node between 488 PLR and MP. 490 5.4.1.1. Intra-domain node protection 492 [R1]----[R2]----[R3]----[R4]---[R5] 493 \ / 494 [R6]--[R7]--[R8] 496 Protected LSP Path: [R1->R2->R3->R4->R5] 497 Bypass LSP Path: [R2->R6->R7->R8->R4] 499 Figure 1: Node Protection for R3 501 In Figure 1, R2 has to build a bypass tunnel that protects against 502 the failure of link [R2->R3] and node [R3]. R2 is PLR and R4 is MP 503 in this case. Since, both PLR and MP belong to the same area. The 504 problem of finding the MP using the interface addresses or node-ids 505 can be easily solved. Thus, the PLR can unambiguously find the MP 506 address regardless of RRO IPv4 or IPv6 sub-objects (interface address 507 or LSR ID) and also determine whether a backup tunnel intersecting a 508 protected TE LSP on a downstream node (MP) already exists. 510 TED on PLR will have the information of both R2 and R4, which can be 511 used to find MP's TE router IP address and compute optimal backup 512 path from R2 to R4, excluding link [R2->R3] and node [R3]. 514 Thus, RSVP-TE can signal bypass tunnel along the computed path. 516 5.4.1.2. Boundary node protection 518 5.4.1.2.1. Area Boundary Router (ABR) node protection 519 | 520 PCE-1 | PCE-2 521 | 522 IGP area 0 | IGP area 1 523 | 524 | 525 [R1]----[R2]----[R3]----[R4]---[R5] 526 \ | / 527 [R6]--[R7]--[R8] 528 | 529 | 530 | 532 Protected LSP Path: [R1->R2->R3->R4->R5] 533 Bypass LSP Path: [R2->R6->R7->R8->R4] 535 Figure 2: Node Protection for R3 (ABR) 537 In Figure 2, cooperating PCE(s) (PCE-1 and PCE-2) have computed the 538 primary LSP Path [R1->R2->R3->R4->R5] and provided to R1 (PCC). 540 R2 has to build a bypass tunnel that protects against the failure of 541 link [R2->R3] and node [R3]. R2 is PLR and R4 is MP. Both PLR and 542 MP are in different area. TED on PLR doesn't have the information of 543 R4. 545 The problem of finding the MP address in a network with inter-domain 546 TE LSP is solved by inserting a node-id sub-object [RFC4561] in the 547 RRO object carried in the RSVP Path Reserve message. PLR can find 548 out the MP from the RRO it has received in Path Reserve message from 549 its downstream LSR. 551 But the computation of optimal backup path from R2 to R4, excluding 552 link [R2->R3] and node [R3] is not possible with running of 553 Constrained Shortest Path First (CSPF) algorithm locally at R2. PCE 554 can be used to compute backup path in this case. R2 acting as PCC on 555 PLR can request PCE-1 to compute bypass path from PLR(R2) to MP(R4), 556 excluding link [R2->R3] and node [R3]. PCE MAY use inter-domain path 557 computation mechanism (like HPCE (RFC 6805) etc) when the domain 558 information of MP is unknown at PLR. Further, RSVP-TE can signal 559 bypass tunnel along the computed path. 561 5.4.1.2.2. Autonomous System Border Router (ASBR) node protection 562 | | 563 PCE-1 | | PCE-2 564 | | 565 AS 100 | | AS 200 566 | | 567 | | 568 [R1]----[R2]-------[R3]---------[R4]---[R5] 569 |\ | / 570 | +-----[R6]--[R7]--[R8] 571 | | 572 | | 574 Protected LSP Path: [R1->R2->R3->R4->R5] 575 Bypass LSP Path: [R2->R6->R7->R8->R4] 577 Figure 3: Node Protection for R3 (ASBR) 579 In Figure 3, Links [R2->R3] and [R2->R6] are inter-AS links. IGP 580 extensions ([RFC5316] and [RFC5392]) describe the flooding of inter- 581 AS TE information for inter-AS path computation. Cooperating PCE(s) 582 (PCE-1 and PCE-2) have computed the primary LSP Path 583 [R1->R2->R3->R4->R5] and provided to R1 (PCC). 585 R2 is PLR and R4 is MP. Both PLR and MP are in different AS. TED on 586 PLR doesn't have the information of R4. 588 The address of MP can be found using node-id sub-object [RFC4561] in 589 the RRO object carried in the RSVP Path Reserve message. And 590 Cooperating PCEs could be used to compute the inter-AS bypass path. 591 Thus ASBR boundary node protection is similar to ABR protection. 593 5.4.1.2.3. Boundary node protection with Path-Key Confidentiality 595 [RFC5520] defines a mechanism to hide the contents of a segment of a 596 path, called the Confidential Path Segment (CPS). The CPS may be 597 replaced by a path-key that can be conveyed in the PCE Communication 598 Protocol (PCEP) and signaled within in a Resource Reservation 599 Protocol TE (RSVP-TE) explicit route object. 601 [RFC5553] states that, when the signaling message crosses a domain 602 boundary, the path segment that needs to be hidden (that is, a CPS) 603 MAY be replaced in the RRO with a PKS. Note that RRO in Resv message 604 carries the same PKS as originally signaled in the ERO of the Path 605 message. 607 5.4.1.2.3.1. Area Boundary Router (ABR) node protection 609 | 610 PCE-1 | PCE-2 611 | 612 IGP area 0 | IGP area 1 613 | 614 | 615 [R1]----[R2]----[R3]----[R4]---[R5]---[R9] 616 \ | / 617 [R6]--[R7]--[R8] 618 | 619 | 620 | 622 Figure 4: Node Protection for R3 (ABR) and Path-Key 624 In Figure 4, when path-key is enabled, cooperating PCE(s) (PCE-1 and 625 PCE-2) have computed the primary LSP Path [R1->R2->R3->PKS->R9] and 626 provided to R1 (PCC). 628 When the ABR node (R3) replaces the CPS with PKS (as originally 629 signaled) during the Reserve message handling, it MAY also add the 630 immediate downstream node-id (R4) (so that the PLR (R2) can identify 631 the MP (R4)). Further the PLR (R2) SHOULD remove the MP node-id (R4) 632 before sending the Reserve message upstream to head end router. 634 Once MP is identified, the backup path computation using PCE is as 635 described earlier. (Section 5.4.1.2.1) 637 5.4.1.2.3.2. Autonomous System Border Router (ASBR) node protection 639 | | 640 PCE-1 | | PCE-2 641 | | 642 AS 100 | | AS 200 643 | | 644 | | 645 [R1]----[R2]-------[R3]---------[R4]---[R5] 646 |\ | / 647 | +-----[R6]--[R7]--[R8] 648 | | 649 | | 651 Figure 5: Node Protection for R3 (ASBR) 653 The address of MP can be found using the same mechanism as explained 654 above. Thus ASBR boundary node protection is similar to ABR 655 protection. 657 5.5. Point-to-Multipoint Path Protection 659 A PCE utilizing the extensions outlined in [RFC6006] (Extensions to 660 PCEP for Point-to-Multipoint Traffic Engineering Label Switched 661 Paths), can be used to compute point-to-multipoint (P2MP) paths. A 662 PCC requesting path computation for a primary and backup path can 663 request that these dependent computations use diverse paths. 664 Furthermore, the specification also defines two new options for P2MP 665 path dependent computation requests. The first option allows the PCC 666 to request that the PCE should compute a secondary P2MP path tree 667 with partial path diversity for specific leaves or a specific source- 668 to-leaf (sub-path to the primary P2MP path tree. The second option, 669 allows the PCC to request that partial paths should be link direction 670 diverse. 672 6. Optical Protection Applications 674 6.1. ASON Applicability 676 6.2. Multi-domain Restoration 678 7. Path and Service Protection Gaps 680 8. Manageability Considerations 682 8.1. Control of Function and Policy 684 TBD 686 8.2. Information and Data Models 688 TBD 690 8.3. Liveness Detection and Monitoring 692 TBD 694 8.4. Verify Correct Operations 696 TBD 698 8.5. Requirements On Other Protocols 700 TBD 702 8.6. Impact On Network Operations 704 TBD 706 9. Security Considerations 708 This document does not introduce new security issues. However, MP's 709 node-id is carried as subobject in RRO across domain. This 710 relaxation is required to find MP in case of BN protection. The 711 security considerations pertaining to the [RFC3209], [RFC4090] and 712 [RFC5440] protocols remain relevant. 714 10. IANA Considerations 716 This document makes no requests for IANA action. 718 11. Contributors 720 Venugopal Reddy Kondreddy 721 Huawei Technologies 722 Leela Palace 723 Bangalore, Karnataka 560008 724 INDIA 726 EMail: venugopalreddyk@huawei.com 728 12. Acknowledgement 730 We would like to thank Daniel King, Udayashree Palle, Sandeep Boina 731 and Reeja Paul for their useful comments and suggestions. 733 13. References 735 13.1. Normative References 737 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 738 Requirement Levels", BCP 14, RFC 2119, 739 DOI 10.17487/RFC2119, March 1997, 740 . 742 13.2. Informative References 744 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 745 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 746 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 747 . 749 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 750 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 751 DOI 10.17487/RFC4090, May 2005, 752 . 754 [RFC4561] Vasseur, J., Ed., Ali, Z., and S. Sivabalan, "Definition 755 of a Record Route Object (RRO) Node-Id Sub-Object", 756 RFC 4561, DOI 10.17487/RFC4561, June 2006, 757 . 759 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 760 Element (PCE)-Based Architecture", RFC 4655, 761 DOI 10.17487/RFC4655, August 2006, 762 . 764 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 765 Inter-Domain Multiprotocol Label Switching Traffic 766 Engineering", RFC 4726, DOI 10.17487/RFC4726, November 767 2006, . 769 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 770 Per-Domain Path Computation Method for Establishing Inter- 771 Domain Traffic Engineering (TE) Label Switched Paths 772 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 773 . 775 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 776 Support of Inter-Autonomous System (AS) MPLS and GMPLS 777 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 778 December 2008, . 780 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 781 Support of Inter-Autonomous System (AS) MPLS and GMPLS 782 Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, 783 January 2009, . 785 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 786 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 787 DOI 10.17487/RFC5440, March 2009, 788 . 790 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 791 "A Backward-Recursive PCE-Based Computation (BRPC) 792 Procedure to Compute Shortest Constrained Inter-Domain 793 Traffic Engineering Label Switched Paths", RFC 5441, 794 DOI 10.17487/RFC5441, April 2009, 795 . 797 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 798 "Preserving Topology Confidentiality in Inter-Domain Path 799 Computation Using a Path-Key-Based Mechanism", RFC 5520, 800 DOI 10.17487/RFC5520, April 2009, 801 . 803 [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, "Resource 804 Reservation Protocol (RSVP) Extensions for Path Key 805 Support", RFC 5553, DOI 10.17487/RFC5553, May 2009, 806 . 808 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 809 Ali, Z., and J. Meuric, "Extensions to the Path 810 Computation Element Communication Protocol (PCEP) for 811 Point-to-Multipoint Traffic Engineering Label Switched 812 Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, 813 . 815 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 816 Path Computation Element Architecture to the Determination 817 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 818 DOI 10.17487/RFC6805, November 2012, 819 . 821 [G-7715] ITU-T, "ITU-T Recommendation G.7715 (2002), Architecture 822 and Requirements for the Automatically Switched Optical 823 Network (ASON).", 2002. 825 [G-7715-2] 826 ITU-T, "ITU-T Recommendation G.7715.2 (2007), ASON routing 827 architecture and requirements for remote route query.", 828 2007. 830 [G-8080] ITU-T, "ITU-T Recommendation G.8080/Y.1304, Architecture 831 for the automatically switched optical network (ASON).", 832 2012. 834 Author's Address 836 Huaimo Chen 837 Futurewei 838 Boston, MA 839 USA 841 EMail: huaimo.chen@futurewei.com