idnits 2.17.1 draft-fuxh-pce-drpc-03.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 (August 31, 2011) is 4622 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4655' is mentioned on line 93, but not defined == Missing Reference: 'RFC 5441' is mentioned on line 190, but not defined == Missing Reference: 'RFC4105' is mentioned on line 196, but not defined == Missing Reference: 'RFC4216' is mentioned on line 196, but not defined == Missing Reference: 'RFC5440' is mentioned on line 578, but not defined -- Looks like a reference, but probably isn't: '1' on line 754 -- Looks like a reference, but probably isn't: '2' on line 757 -- Looks like a reference, but probably isn't: '3' on line 760 -- Looks like a reference, but probably isn't: '4' on line 763 == Missing Reference: 'RFC3209' is mentioned on line 769, but not defined == Unused Reference: 'RFC4665' is defined on line 882, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group XH. Fu 3 Internet-Draft YL. Bao 4 Intended status: Informational ZTE Corporation 5 Expires: March 3, 2012 YL. Zhao 6 J. Zhang 7 Y. G 8 BUPT 9 August 31, 2011 11 A Dual-end Recursive PCE-Based Computation (DRPC) Procedure to Compute 12 Shortest Constrained Inter-domain Traffic Engineering Label Switched 13 Paths 14 draft-fuxh-pce-drpc-03 16 Abstract 18 A dual-end recursive PCE-based computation procedure (DRPC) is 19 proposed to compute shortest constrained inter-domain traffic 20 engineering label switched paths based on BRPC in Multi-protocol 21 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. By 22 recursively performing shortest path algorithm and transferring the 23 segmental path computation result from both ends bi-directionally, 24 they meet at one of the Middle PCEs, generating a directional 25 shortest path graph into which the two shortest path trees are 26 stitched together. Therefore, the end-to-end constrained inter- 27 domain traffic engineering label switched path, even k shortest paths 28 can be gained from the directional shortest path graph directly. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 3, 2012. 47 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 65 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. General Assumptions . . . . . . . . . . . . . . . . . . . . . 5 67 4. DRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. PCE Sequence Selection Approaches . . . . . . . . . . . . 5 69 4.2. DRPC Procedure . . . . . . . . . . . . . . . . . . . . . . 6 70 4.3. Stitching PCE Selection . . . . . . . . . . . . . . . . . 10 71 4.3.1. Case(1): Mode of Operation in PCE Designation . . . . 10 72 4.3.2. Case(2): Mode of Operation in PCEP Signaling 73 Procedure . . . . . . . . . . . . . . . . . . . . . . 11 74 4.4. An Example of PCE Collaboration . . . . . . . . . . . . . 13 75 5. PCEP Protocol Extension Requirements . . . . . . . . . . . . . 15 76 6. VSPG Encoding . . . . . . . . . . . . . . . . . . . . . . . . 16 77 7. DRPC Procedure Failures . . . . . . . . . . . . . . . . . . . 17 78 8. Path Computation Failures . . . . . . . . . . . . . . . . . . 18 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 10. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 18 81 10.1. New Flags Of The RP Object . . . . . . . . . . . . . . . . 19 82 10.2. New Error-Type and Error-Value . . . . . . . . . . . . . . 19 83 10.3. New Flag Of The NO-PATH-VECTOR TLV . . . . . . . . . . . . 19 84 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 85 12. Normative References . . . . . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 With regards to the constraint-based shortest path computation in 91 Multi-protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 92 multi-layer and multi-domain networks, IETF groups propose the 93 architecture of Path Computation Element (PCE) [RFC4655]. As an 94 important approach of path computation in PCE architecture, backward 95 recursive PCE-based computation (BRPC) procedure can gain a shortest 96 path tree along the direction from the destination node to the source 97 node, and then get an end-to-end optimal path [RFC5441]. During the 98 procedure of BRPC, a sequence of PCEs should be pre-determined. 99 However, when the number of PCEs in the predetermined PCE sequence 100 are very large, the path computation time may be long for the 101 customer, and the long PCE chain will be vulnerable. A dual-end 102 recursive PCE-based computation (DRPC) procedure is proposed to 103 compute shortest constrained inter-domain traffic engineering label 104 switched paths. DRPC procedure aims to provide a further improvement 105 of the existing BRPC procedure by computing and transferring the 106 shortest path tree bi-directionally, which doubles the pace of inter- 107 domain path computation.In DRPC procedure, path computation is 108 launched at the source PCE and the destination PCE simultaneously. 109 By recursively performing shortest path algorithm and transferring 110 the segmental path computation result from both ends bi- 111 directionally, they meet at one of the Middle PCEs, generating a 112 directional shortest path graph into which the two shortest path 113 trees are stitched together. Therefore, the end-to-end constrained 114 inter-domain traffic engineering label switched path, even the k 115 shortest paths can be gained from the directional shortest path graph 116 directly. Only the differences from [RFC5441] are listed here, the 117 overlapped comments all inherit the corresponding terms in [RFC5441], 118 such as section 7, 8, 10, 11, 13, 14, 16, and so on. 120 1.1. Conventions Used in This Document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 2. Terminologies 128 ABR: Area Border Routers. Routers used to connect two IGP areas 129 (areas in OSPF or levels in IS-IS). 131 ASBR: Autonomous System Border Routers. Routers used to connect 132 together ASes of the same or different Service Providers via one or 133 more Inter-AS links. 135 Boundary Node (BN): a boundary node is either an ABR in the context 136 of inter-area Traffic Engineering or an ASBR in the context of 137 inter-AS Traffic Engineering. 139 Entry BN of domain (n): a BN connecting domain (n-1) to domain (n) 140 along a determined sequence of domains. 142 Exit BN of domain (n): a BN connecting domain (n) to domain (n+1) 143 along a determined sequence of domains. 145 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. Inter-area TE 146 LSP: A TE LSP that crosses an IGP area boundary. 148 LSR: Label Switching Router. 150 LSP: Label Switched Path. 152 PCC: Path Computation Client. Any client application requesting a 153 path computation to be performed by the Path Computation Element. 155 PCE (Path Computation Element): an entity (component, application or 156 network node) that is capable of computing a network path or route 157 based on a network graph and applying computational constraints. 159 PCE(i): a PCE with the scope of domain (i). 161 TED: Traffic Engineering Database. 163 VSPT: Virtual Shortest Path Tree. 165 VSPG: Virtual Shortest Path Graph. 167 Source PCE: the PCE in the source domain to launch the DRPC procedure 168 and transfer the calculated VSPT forward. 170 Destination PCE: the PCE in the destination domain to launch the DRPC 171 procedure and transfer the calculated VSPT backward. 173 Middle PCE: a PCE which is a relative concept ,that is one of the 174 PCEs in the PCE sequence(the direction from the Destination PCE to 175 the Source PCE or from the Source PCE to the Destination PCE 176 relatively).And the Middle PCE must not be the source PCE or the 177 destination PCE. 179 Stitching PCE: a PCE which is determined to stitch the two VSPTs from 180 both source and destination sides of PCEs into a VSPG. 182 Downstream: In forward direction, from Source PCE to Destination PCE. 184 Upstream: In backward direction, from Destination PCE to Source PCE. 186 3. General Assumptions 188 In the rest of this document, we make the following set of 189 assumptions common to inter-area and inter-AS MPLS TE, which are same 190 to the assumptions of [RFC 5441]. 192 o Each IGP area or Autonomous System (AS) is assumed to be Traffic 193 Engineering enabled. 195 o No topology or resource information is distributed between domains 196 (as mandated per [RFC4105] and [RFC4216]), which is critical to 197 preserve IGP/BGP scalability and confidentiality. 199 o while certain constraints like bandwidth can be used across 200 different domains, other TE constraints like resource affinity, 201 color, metric, etc. as listed in RFC2702 could be translated at 202 domain boundaries. If required, it is assumed that, at the domain 203 boundary nodes, there will exist some sort of local mapping based 204 on policy agreement, in order to translate such constraints across 205 domain boundaries during the inter-PCE communication process. 207 o Each AS can be made of several IGP areas. The path computation 208 procedure described in this document applies to the case of a 209 single AS made of multiple IGP areas, multiple ASes made of a 210 single IGP area or any combination of the above. For the sake of 211 simplicity, each AS will be considered to be made of a single area 212 in this document. The case of an Inter-AS TE LSP spanning 213 multiple ASes where some of those ASes are themselves made of 214 multiple IGP areas can be easily derived from this case by 215 applying the DRPC procedure described in this document, 216 recursively. 218 o The domain path (set of domains traversed to reach the destination 219 domain) is either administratively pre-determined or discovered by 220 some means that is outside of the scope of this document. 222 4. DRPC Procedure 224 4.1. PCE Sequence Selection Approaches 226 A PCE sequence has to be predetermined before DRPC procedure is 227 launched, which corresponds to the domain path selection. The PCE/ 228 domain path may be either administratively predetermined or 229 discovered by some means outside of the scope of this document. 231 A hierarchical PCE architecture is highly recommended which is 232 proposed in [I-D.ietf-pce-hierarchy-fwk]. In the hierarchical PCE 233 architecture, there are concepts of Parent (hierarchical) PCE and 234 child PCE. 236 The Parent PCE is responsible for selecting a PCE/domian path across 237 its domain map.The Parent PCE maintains the domain topology map that 238 contains the child domains and their interconnections and the traffic 239 engineering (TE) capabilities of domain interconnections. But The 240 Parent PCE has no information about the contents of the child 241 domains.And it learns those from configuration or information 242 received from each Child PCE. 244 Each domain has has at least one PCE capable of computing paths 245 across it. These PCEs are known as Child PCEs and have a 246 relationship with the Parent PCE. A child PCE is responsible for 247 computing the path across one or more specific (child) domains. Each 248 Child PCE knows the identity of the border nodes and links of its own 249 adjacent domains. But a child PCE only knows the topology of the 250 domain it serves and does not know the topology of other domains.And 251 it is also not aware of the general domain mesh connectivity beyond 252 the connectivity to the immediate neighbordomains of the domain it 253 serves. 255 When the ingress PCE responsible for the ingress domain receives a 256 path computation request from the source node, and the destination is 257 outside of this domain, the ingress PCE will send a path computation 258 request(PCReq Message) to the parent PCE. The parent PCE determines 259 which domian the destination node belongs to.And then the parent PCE 260 selects the sequence of candidate domain PCEs based on its domain 261 topology map. It then sends the selected candidate PCE sequence 262 within the computation requests (PCRep Message) to the ingress PCE . 264 Each selected candidate PCE that in the selected sequence computes a 265 set of candidate path segments across its own domain and then use 266 some methods(e.g. BRPC, etc.) to gain an optimal end-to-end optimal 267 path from the source node to the destination node. 269 The communication with Parent PCE is unnecessary within the context 270 of non-hierarchical PCE architecture and PCE/domain path can be 271 obtained by other means. 273 4.2. DRPC Procedure 275 Definition of VSPG(i), VSPT(0,i) and VSPT(1,i): 277 VSPG(i) consists of multi shortest paths from the same node to other 278 multi nodes. 280 In each domain i, 282 o There is a set of X-en(i) entry BNs noted BN-en(k,i) where BN- 283 en(k,i) is the kth entry BN of domain(i). 285 o There is a set of X-ex(i) exit BNs noted BN-ex(k,i) where BN- 286 ex(k,i) is the kth exit BN of domain(i). 288 The definition of VSPT(1,i) is the same as that of VSPT(i) in BRPC 289 (see [RFC5441]). 291 VSPT(1,i): MP2P (multipoint-to-point) tree returned by PCE(i) to 292 PCE(i-1): 294 --------------------------------------------- 295 | | 296 | ------------------------- | 297 | |Root (TE LSP destination)| | 298 | ------------------------- | 299 | / | \ | 300 | / | \ | 301 | / | \ | 302 | ---------- ---------- ---------- | 303 | |BN-en(1,i)| |BN-en(2,i)| ...|BN-en(j,i)| | 304 | ---------- ---------- ---------- | 305 | | 306 --------------------------------------------- 307 where [X-en(i)] is the number of entry BNs in 308 domain (i), and j is no larger than [X-en(i)] 310 Figure 1: VSPT(1,i) Backward Shortest Path MP2P Tree 312 Each link of tree VSPT(1,i) represents the shortest constrained path 313 between BN-en(j,i) and the TE LSP destination that satisfies the set 314 of required constraints for the TE LSP (bandwidth, resource affinity, 315 metrics, etc.). These are path segments to reach the TE LSP 316 destination from BN-en(j,i). 318 The definition of VSPT(0,i) is vary similar to the VSPT(1,i). 320 VSPT(0,i): P2MP (point-to-multipoint) tree returned by PCE(i) to 321 PCE(i+1): 323 ----------------------------------------------------- 324 | | 325 | --------------------- | 326 | | Root (TE LSP source)| | 327 | --------------------- | 328 | / | \ | 329 | / | \ | 330 | / | \ | 331 | ------------ ------------ ------------ | 332 | |BN-en(1,i+1)| |BN-en(2,i+1)| ... |BN-en(j,i+1)| | 333 | ------------ ------------ ------------ | 334 | | 335 ----------------------------------------------------- 336 where [X-en(i)] is the number of entry BNs in 337 domain (i), and j is no larger than [X-en(i)] 339 Figure 2: VSPT(0,i) Forward Shortest Path P2MP Tree 341 Each link of tree VSPT(0,i) represents the shortest constrained path 342 between BN-en(j,i+1) and the TE LSP source that satisfies the set of 343 required constraints for the TE LSP (bandwidth, resource affinity, 344 metrics, etc.). These are path segments to reach BN-en(j,i+1) from 345 the TE LSP source. 347 Different from BRPC, when a path computation request arriving and the 348 PCE sequence to be traversed has been predetermined, DRPC will launch 349 the path computation from dual-end PCEs to the Middle PCEs bi- 350 directionally. It is worth noting that the Middle PCE may not be the 351 PCE in the middle of the PCE sequence but the PCE receiving the two 352 path computation requests from two directions. And the domian that 353 servered by the Middle PCE is called as Stitching Domain,and this 354 Middle PCE is also called as stitching PCE. According to the path 355 computation request, the source PCE sparks the path computaion to the 356 Entry BN of the stitching domain. While, the destination PCE sparks 357 the path computation to the the Entry BN of the domain next to the 358 stitching domain. When the stitching PCE receives the two messages 359 which contain the two virtual shortest path trees (VSPT) at the root 360 of the source node and the destination node respectively, the 361 stitching PCE will stitch the two VSPTs into one complete directional 362 shortest path graph. At last, the shortest path or k shortest paths 363 will be selected from the directional shortest path graph by the 364 stitching PCE according to some strategies and transferred to the 365 source node through the Source PCE. Similar with BRPC procedure, a 366 predetermined PCE sequence should also be designated before DRPC 367 procedure. 369 PCE(i+1) computes VSPT(1,i+1) by using its own topology map without 370 considerating any cross-domain links. VSPT(1,i+1) is returned by 371 PCE(i+1) to PCE(i) along the direction from the Destination PCE to 372 the Source PCE, which consists of multi shortest paths from the multi 373 BN-en(j,i+1)s to the destination node, as is shown in Fig.1. 375 PCE(i-1) computes VSPT(0,i-1) by using its own topology map together 376 with the cross-domain links between domain(i-1) and domain(i). 377 VSPT(0, i-1) is returned by PCE(i-1) to PCE (i) along the direction 378 from the Source PCE to the Destination PCE, which consists of multi 379 shortest paths from the source node to multi BN-en(j,i), as is shown 380 in Fig.2. 382 VSPG(i)=VSPT(0,i)+VSPT(1,i+1) is the directional shortest path graph 383 from the source node to the destination node which is stitched by the 384 two directional shortest path trees that gained above. As the 385 Stitching PCE, PCE(i) computes VSPT(0,i) and then stitches the two 386 directional shortest path graphs together where VSPT(0,i) represents 387 the directional shortest path tree computed from source node to the 388 Entry BN of domain(i+1) and VSPT(1,i+1) represents the directional 389 shortest path graph computed from destination node to the Entry BN of 390 domain(i+1). At last, the directional shortest path graph from the 391 source node to the destination node is generated as shown in Fig.3. 393 ---------------------------------------------------- 394 | | 395 | ------------------- | 396 | |Root (TE LSP source)| | 397 | ------------------- | 398 | / | \ | 399 | / | \ | 400 | ------------ ------------ ------------ | 401 | |BN-en(1,i+1)| |BN-en(2,i+1)| ... |BN-en(j,i+1)| | 402 | ------------ ------------ ------------ | 403 | \ | / | 404 | \ | / | 405 | ------------------------- | 406 | |Root (TE LSP destination)| | 407 | ------------------------- | 408 | | 409 ---------------------------------------------------- 411 Figure 3: VSPG(i) Shortest Path Graph 413 The Stitching PCE can be either designated before DRPC procedure or 414 dynamic selected in PCEP signaling procedure automatically. 416 Two path selection strategies are permitted to return the shortest 417 path back to PCC. 419 o The Stitching PCE transfers the computed optimal end-to-end path 420 to the Source PCE through PCReq message and the Source PCE returns 421 the path back to PCC. The non-optimal paths are deleted at the 422 Stitching PCE. 424 o The Stitching PCE transfers the newly stitched directional 425 shortest path graph to the Source PCE through PCRep message. 426 Source PCE generates the shortest path and returns it back to PCC. 427 The non-shortest paths are deleted at the Source PCE. 429 4.3. Stitching PCE Selection 431 The Stitching PCE is an ordinary PCE. It acts as the role of 432 stitching the two VSPTs from both source and destination sides of 433 PCEs into a VSPG. The Stitching PCE can be designated by several 434 means before DRPC procedure, such as Parent PCE computation, Network 435 Management System(NMS) designation, administrative configuration and 436 etc. These can be regarded as Designation Case and Section 4.3.1 437 describes the DRPC operation in this case. By utilizing the 438 characteristics of the PCEP signaling, the stitching role can be 439 dynamically determined. Section 4.3.2 elaborates the details of PCEP 440 signaling procedure in Stitching PCE Selection. 442 4.3.1. Case(1): Mode of Operation in PCE Designation 444 Denoting that PCE(1) is the Source PCE, PCE(m) is the Stitching PCE, 445 and PCE(n) is the Destination PCE. 447 Step 1: 449 PCE(1) computes VSPT(0,1), the tree made of the list of shortest 450 constrained paths between the TE LSP source and every BN-en(j,2) by 451 using a suitable path computation algorithm (e.g. CSPF, etc.) and 452 returns the computed VSPT(0,1) to PCE(2). This can be triggered by 453 Parent PCE, PCC or spontaneously. 455 Simultaneously, PCE(n) computes VSPT(1,n), the tree made of the list 456 of shortest constrained paths between every BN-en(j,n) and the TE LSP 457 destination using a suitable path computation algorithm (e.g. CSPF, 458 etc.) and returns the computed VSPT(n) to PCE(n-1). This can be 459 triggered by Parent PCE, PCE(n-1) or PCE(1) directly. It is highly 460 recommended to drive PCE(n) to compute VSPT(1,n) by PCE chain and to 461 relay PCReq message PCE-by-PCE downstream from PCE(1). An example of 462 specific PCEP message flow is shown in section 4.4. 464 Step i: (Downstream) 466 For i=2 to m-1: PCE(i) computes VSPT(0,i), the tree made of the 467 shortest constrained paths between the TE LSP source and each BN- 468 en(j,i+1). It does this by considering the information in 469 VSPT(0,i-1) and its own TED including the links that provide 470 connectivity from domain(i) to domain(i+1). PCE(i) returns the 471 computed VSPT(0,i) to PCE(i+1). 473 Step i: (Upstream) 475 For i=n-1 to m+1: PCE(i) computes VSPT(1,i), the tree made of the 476 shortest constrained paths between each BN-en(j,i) and the TE LSP 477 destination. It does this by considering the information in 478 VSPT(1,i+1) and its own TED. PCE(i) returns the computed VSPT(1,i) 479 to PCE(i-1). 481 Step m: 483 The Stitching PCE(m) computes VSPT(0,m), the tree made of the 484 shortest constrained paths between the TE LSP source and each BN- 485 en(j,m+1). It does this by considering the information in 486 VSPT(0,m-1) and its own TED including the links that provide 487 connectivity from domain(m) to domain(m+1). PCE(m) stitches the 488 computed VSPT(0,m) and VSPT(1,m+1) which is returned from PCE(m+1) 489 into a VSPG. 491 If n=2, the source domain and the destination domain are directly 492 interconnected with each other. The Stitching PCE is recommended to 493 be specified as the Source PCE where step i is omitted. 495 The PCRep message which carries VSPG(m) or final Explicit Route 496 Objects (EROs) should be relayed from PCE(m) to PCE(1) upstream PCE- 497 by-PCE. PCE(1) returns the final path computation result to PCC. 498 The optimal path can be selected from VSPG(m) either by PCE(m) or 499 PCE(1). For the sake of topology confidentialality, PCE(m) is 500 recommended to select the final explicit route rather than PCE(1). 502 4.3.2. Case(2): Mode of Operation in PCEP Signaling Procedure 504 Denoting that PCE(1) is the Source PCE and PCE(n) is the Destination 505 PCE. In case(2), every PCE transfers VSPT to the next PCE without 506 knowing a predefined Stitching PCE. So, the Stitching PCE is 507 selected automatically in PCEP signaling procedure where VSPT request 508 messages upstream and downstream meet each other and there are three 509 scenarios. 511 Scenario (1): PCE(i) and PCE(i+1) receive messages request for 512 VSPT(1,i+1) and VSPT(0,i) respectively after these two messages have 513 been sent. Thus, PCE(i) stitches VSPT(0,i) and VSPT(1,i+1) into 514 VSPG(i), whereas PCE(i+1) discards the message. 516 Scenario (2): PCE(i) receives a message carrying VSPT(1,i+1) after it 517 has received a message carrying VSPT(0,i), and it is unable to stop 518 sending PCReq with computed VSPT(0,i) to PCE(i+1) immediately or the 519 message has already been sent. Thus, PCE(i) stitches VSPT(0,i) and 520 VSPT(1,i+1) into VSPG(i), whereas PCE(i+1) discards VSPT(0,i). 522 Scenario (3): PCE(i+1) receives a message carrying VSPT(0,i) after it 523 has received a message carrying VSPT(1,i+2), and it is unable to stop 524 sending message carrying a computed VSPT(1,i+1) to PCE(i) 525 immediately. Thus, PCE(i) stitches VSPT(0,i) and VSPT(1,i+1) into 526 VSPG(i), whereas PCE(i+1) discards VSPT(0,i). 528 The following steps are described to deal with these three situations 529 in a uniform procedure. Denoting that PCE(m) is the Stitching PCE 530 and it is the intersection of the two VSPTs. 532 Step 1: 534 PCE(1) computes VSPT(0,1), the tree made of the list of shortest 535 constrained paths between the TE LSP source and every BN-en(j,2) by 536 using a suitable path computation algorithm (e.g., CSPF) and returns 537 the computed VSPT(0,1) to PCE(2). This can be triggered by Parent 538 PCE, PCC or spontaneously. 540 Simultaneously, PCE(n) computes VSPT(1,n), the tree made of the list 541 of shortest constrained paths between every BN-en(j,n) and the TE LSP 542 destination using a suitable path computation algorithm (e.g., CSPF) 543 and returns the computed VSPT(n) to PCE(n-1). This can be triggered 544 by Parent PCE, PCE(n-1) or PCE(1) directly. It is highly recommended 545 to drive PCE(n) to compute VSPT(1,n) by PCE chain and to relay PCReq 546 message PCE-by-PCE downstream from PCE(1). This step is identical 547 with that of Case (1). 549 Step i: (Downstream) 551 For i=2 to m: PCE(i) computes VSPT(0,i), the tree made of the 552 shortest constrained paths between the TE LSP source and each BN- 553 en(j,i+1). It does this by considering the information in 554 VSPT(0,i-1) and its own TED including the links that provide 555 connectivity from domain(i) to domain(i+1). If PCE(i) has already 556 received a valid message request for VSPT(0,i) from PCE(i+1) which 557 carries VSPT(1,i+1), it ignores the message once received from 558 PCE(i-1) downstream. Otherwise PCE(i) returns the computed VSPT(0,i) 559 to PCE(i+1). 561 Step i: (Upstream) 563 For i=n to m+1: PCE(i) computes VSPT(1,i), the tree made of the 564 shortest constrained paths between each BN-en(j,i) and the TE LSP 565 destination. It does this by considering the information in 566 VSPT(1,i+1) and its own TED. PCE(i) returns the computed VSPT(1,i) 567 to PCE(i-1). If PCE(i) has already received a valid message request 568 for VSPT(1,i-1) from PCE(i-1) which carries VSPT(0,i-1), it computes 569 VSPT(0,i+1) and transfers the VSPT(0,i) to PCE(i+1). Once a valid 570 message carrying VSPT(1, i+1) received from PCE(i+1) after receiving 571 VSPT(0, i-1) from PCE(i-1), PCE(i) stitches these two VSPTs into a 572 VSPG(i). 574 Both PCReq and PCRep message are permitted to trigger VSPT 575 computation. It is recommended to use PCRep message to trigger the 576 VSPT computation on the Middle PCE, and PCReq on the Source and 577 Destination PCE. VSPT(0, i), VSPT(1, i) and VSPG(i) MUST be encoded 578 in ERO, IRO, RRO, or XRO Objects (see [RFC5440] and [RFC5521]). 580 The PCRep message which carries VSPG(m) or final ERO should be 581 relayed from PCE(m) to PCE(1) upstream PCE-by-PCE. PCE(1) returns 582 the final path computation result to PCC. The shortest path can be 583 selected from VSPG(m) either by PCE(m) or PCE(1). These are 584 identical with case (1). 586 4.4. An Example of PCE Collaboration 588 The following example is used for demonstrating PCE collaboration of 589 DRPC procedure in this document. It uses the recommended PCEP 590 message flow. 592 Notes: 594 - Only three domains are depicted in the diagram below for the 595 sake of simplicity. 597 - We assume that the Stitching PCE is in the middle of the PCE 598 sequence, which may be determined by either of the two cases 599 described in Section 4.3. 601 (1.1)PCReq ------------ 602 +----------------->| Parent PCE | 603 | (1.2)PCRep ------------ 604 | 605 -----+------ ------------ ------------ 606 | | | | Domain 2 | | Domain 3 | 607 | v | | (Stitcher) | | | 608 | ------ | (2a)PCReq | ------ | (3a)PCReq | ------ | 609 | | PCE1 |<-+-----------+->| PCE2 |<-+-----------+->| PCE3 | | 610 | ------ | (2b)PCRep | ------ | (3b)PCRep | ------ | 611 | ^ | (4)PCRep | | | | 612 | (1)|PCReq | ------------ ------------ 613 | (5)|PCRep | 614 | v | 615 | ----- | 616 | | PCC | | 617 | ----- | 618 | | 619 | Domain 1 | 620 ------------ 622 Figure 4: An Example of DRPC Procedure 624 Workflows: 626 (1) PCC sends a PCReq message to the Source PCE, requesting an 627 end-to-end explicit route. 629 (1.1) Source PCE sends a PCReq message to Parent PCE, requesting a 630 PCE Sequence. 632 (1.2) Parent PCE sends a PCReq message to Source PCE, replying the 633 PCE Sequence. 635 (2a) Once PCE(1) obtained the PCE Sequence by some means, it sends 636 a PCReq message to PCE(2), asking for PCE(2) to relay this message 637 to the Destination PCE. It expects the Destination PCE to compute 638 VSPT(1, 3). 640 (2b) Once PCE(1) obtained the PCE Sequence by some means, it 641 computes VSPT(0, 1) and encapsulate this VSPT into a PCRep 642 message. Then it sends this PCRep message to PCE(2) to launch a 643 VSPT(0, 2) computation. 645 (3a) Having received a PCReq message from PCE(1), PCE(2) sends a 646 PCReq message to PCE(3), asking for PCE(3) to relay this message 647 to the Destination PCE. 649 (3b) Having received a PCReq message from PCE(2) and checked that 650 the Destination PCE is itself, PCE(3) computes VSPT(1, 3) and 651 encapsulate this VSPT into a PCRep message. Then it sends this 652 PCRep message to PCE(2) to launch a VSPT(1, 2) computation. 654 (4) The Stiching PCE stitches VSPT(0, 2) and VSPT(1, 2) into a 655 VSPG(2). It may either select a shortest path from this VSPG and 656 encapsulate it into a PCRep message or it may encapsulate the VSPG 657 into a PCRep message. No matter which strategy is chosen, it 658 sends back the PCRep message to PCE(1), the neighbor PCE along the 659 upstream direction, expecting that PCE to relay this PCReq message 660 to the Source PCE. 662 (5) Having received a PCRep message from PCE(2) and checked that 663 the Source PCE is itself, PCE(1) returns the final ERO to PCC by 664 sending a PCRep message. If the received PCRep message contains a 665 VSPG, PCE(1) selects the shortest path from the VSPG, or else 666 PCE(1) relays the received PCRep message to PCC directly. 668 If the parent PCE which maintains the domain topology map of the 669 child domains and their interconnectivity does not exist, the PCE 670 sequence can be predetermined by other means such as administrative 671 configuration, Network Management System(NMS)designated, non-shortest 672 path computation without regard to detailed TE attributes, and etc. 673 This way, the (1.1) and (1.2) steps are skipped. 675 5. PCEP Protocol Extension Requirements 677 The two different DRPC procedures require the specification of new 678 flags of the RP object carried within the PCReq message to specify 679 that the shortest paths satisfying the constraints from the 680 destination to the set of entry boundary nodes or from the source to 681 the set of entry boundary nodes are requested. 683 Note that IANA has already defined Bit 25 of the flags in RP Object 684 for VSPT. 686 The following new flags of the RP object is defined: 688 Bit Number Name Flag 690 16 VSPG 692 When Bit 16 is set, it enables VSPG encoding in ERO, IRO, RRO, or XRO 693 Object. In PCReq message, when Bit 16 is set, it indicates that the 694 Source PCE is response for path selection from VSPG rather than the 695 Stitching PCE, which is defined in this document. Bit 16 is valid 696 under the assumption that bit 17 is valid. 698 Bit Number Name Flag 700 17 DRPC VSPT Extension 702 In PCReq Message: 704 17 1: Request for DRPC Procedure 706 In PCRep Message: 708 17 0: from source PCE to Middle PCE for VSPT Extension 710 1: from destination PCE to Middle PCE for VSPT 711 Extension 713 In PCReq message, when Bit 17 is set, it indicates that the PCC 714 requests the computation of an inter-domain TE LSP using the DRPC 715 procedure defined in this document. In PCRep message Bit 17 is valid 716 under the assumption that bit 25 is valid. 718 Because path segments computed by the two end PCEs in the context of 719 the DRPC procedure must be provided along with their respective path 720 costs, the C flag of the METRIC object carried within the PCReq 721 message must be set. It is the choice of the requester to 722 appropriately set the O bit of the RP object. 724 6. VSPG Encoding 726 The VSPG encoding objects must be returned within a PCRep message. 727 The encoding consists of a non-ordered list of Explicit Route Objects 728 (EROs) where each ERO represents a path from the source node to the 729 destination node specified in the END-POINT object of the 730 corresponding PCReq message from PCC to Source PCE. 732 Example: 734 <---- area 1 -----><-------- area 2 ---------><----- area 3 ------> 735 +--A--B---BNex1-1--BNen2-1---E---F---BNex2-1--BNen3-1---K----L--+ 736 | | 737 | | 738 S----C----BNex1-2--BNen2-2---G---H---BNex2-2--BNen3-2-----M-----D 739 | | 740 | | 741 +---J---BNex2-3--BNen3-3---N----P--+ 742 | | 743 | | 744 +------BNen3-4---Q----+ 746 Figure 5: An Example of VSPG Encoding Using a Set of EROs 748 In the example shown in Figure 5, along the direction from the source 749 node S to the destination node D, when the Stitching PCE completes 750 the path computation and the Source PCE expects a VSPG to select the 751 optimal path in it, four non-ordered EROs are transferred to PCE(1). 752 The four EROs are as follows: 754 ERO[1]: S---A---B---BN-ex(1,1)---BN-en(2,1)---E---F---BN-ex(2,1)--- 755 BN-en(3,1)---K---L---D 757 ERO[2]: S---C---BN-ex(1,2)---BN-en(2,2)---G---H---BN-ex(2,2)---BN- 758 en(3,2)---M---D 760 ERO[3]: S---C---BN-ex(1,2)---BN-en(2,2)---G---J---BN-ex(2,3)---BN- 761 en(3,3)---N---P---D 763 ERO[4]: S---C---BN-ex(1,2)---BN-en(2,2)---G---J---BN-ex(2,3)---BN- 764 en(3,4)---Q---P---D 766 Note that the (BN-ex, BN-en) pair can either be a pair of interfaces 767 on a single ABR or two detached TE-Routers in different domains. In 768 both cases they should be encoded to ERO sub-object specified in 769 [RFC3209]. 771 7. DRPC Procedure Failures 773 If the DRPC procedure cannot be completed because a PCE along the 774 domain does not recognize the procedure (VSPG flag of the RP object), 775 the PCE sends a PCErr message to the parent PCE with an Error-Type=4 776 (not supported object), Error-value-4 (Unsupported parameter). Then 777 the parent PCE sends the failure message to the other PCEs along the 778 PCE chain. The corresponding path computation request is then 779 cancelled by the PCE without further notification. The PCErr message 780 must be relayed to the requesting PCC by the source PCE. 782 PCEP-ERROR objects are used to report a PCEP protocol error and are 783 characterized by an Error-Type which specifies the type of error and 784 an Error-value that provides additional information about the error 785 type. Both the Error-Type and the Error-Value are managed by IANA. 786 A new Error-Type and the corresponding error value are defined here. 788 Error-type Meaning 790 14 DRPC procedure completion failure 792 Error-value Meaning 794 1 DRPC procedure not supported by one or more PCEs 795 along the domain path 797 8. Path Computation Failures 799 If a PCE requires to relay a path computation request according to 800 the DRPC procedure defined in this document to a downstream PCE and 801 no such PCE is available, the PCE MUST cancel all the procedures of 802 path computation on all the other PCEs along the PCE chain through 803 the Source PCE, and send a path computation reply to the PCC using a 804 PCRep message that contains a NO-PATH object. In such case, the NO- 805 PATH object MUST carry a NO-PATH-VECTOR TLV with the newly defined 806 bit named "DRPC Path Computation chain unavailable" set. 808 Different from BRPC using bit 28, Bit 23 is defined here. 810 Bit Number Name Flag 812 23 DRPC Path computation chain unavailable 814 9. Security Considerations 816 TBD. 818 10. IANA Consideration 819 10.1. New Flags Of The RP Object 821 New flags Of The RP Object is defined in this document (VSPG and 822 VSPT-DRPC-Extension to be assigned by IANA). 824 Bit Number Name Flag 826 16 VSPG 828 17 DRPC VSPT Extension 830 In PCReq Message: 832 17 1: Request for DRPC Procedure 834 In PCRep Message: 836 17 0: from source PCE to Middle PCE for VSPT Extension 838 1: from destination PCE to Middle PCE for VSPT 839 Extension 841 Bit 16 is valid under the assumption that bit 17 is valid. 843 Bit 17 is valid under the assumption that bit 25 is valid in PCRep 844 message. 846 10.2. New Error-Type and Error-Value 848 A new Error-Type is defined in this document (Error-Type and Error- 849 value to be assigned by IANA). 851 Error-type Meaning 853 14 DRPC procedure completion failure 855 Error-value Meaning 857 1 DRPC procedure not supported by one or more PCEs 858 along the domain path 860 10.3. New Flag Of The NO-PATH-VECTOR TLV 862 A new flag of the NO-PATH-VECTOR TLV defined in is specified in this 863 document.(Bit 23 to be assigned by IANA) 864 Bit number Name Flag 866 23 DRPC Path computation chain unavailable 868 11. Acknowledgments 870 The RFC text was produced using Marshall Rose's xml2rfc tool. 872 12. Normative References 874 [I-D.ietf-pce-hierarchy-fwk] 875 King, D. and A. Farrel, "The Application of the Path 876 Computation Element Architecture to the Determination of a 877 Sequence of Domains in MPLS & GMPLS", December 2009. 879 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 880 Requirement Levels", RFC 2119, March 1997. 882 [RFC4665] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 883 Element (PCE)-Based Architecture", RFC 4655, August 2006. 885 [RFC5441] Vasseur, J., Zhang, R., Bitar, N., and JL. Le Roux, "A 886 Path Computation Element (PCE)-Based Architecture", 887 RFC 5441, April 2009. 889 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 890 Path Computation Element Communication Protocol (PCEP) for 891 Route Exclusions", RFC 5521, April 2009. 893 Authors' Addresses 895 Xihua Fu 896 ZTE Corporation 897 West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District 898 Xi'an 710065 899 P.R.China 901 Phone: +8613798412242 902 Email: fu.xihua@zte.com.cn 903 URI: http://www.zte.com.cn/ 904 Yuanlin Bao 905 ZTE Corporation 906 5F,R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road 907 Nanshan District 908 Shen Zhen 518055 909 P.R.China 911 Phone: +86 755 26773731 912 Email: bao.yuanlin@zte.com.cn 913 URI: http://www.zte.com.cn/ 915 Yongli Zhao 916 BUPT 917 No.10,Xitucheng Road,Haidian District 918 Beijing 100876 919 P.R.China 921 Phone: +8613811761857 922 Email: yonglizhao@bupt.edu.cn 923 URI: http://www.bupt.edu.cn/ 925 Jie Zhang 926 BUPT 927 No.10,Xitucheng Road,Haidian District 928 Beijing 100876 929 P.R.China 931 Phone: +8613911060930 932 Email: lgr24@bupt.edu.cn 933 URI: http://www.bupt.edu.cn/ 935 Yuan Gu 936 BUPT 937 No.10,Xitucheng Road,Haidian District 938 Beijing 100876 939 P.R.China 941 Phone: +8613466734941 942 Email: josephstrauss@yahoo.com.cn 943 URI: http://www.bupt.edu.cn/