idnits 2.17.1 draft-wang-pce-inter-as-extentions-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2011) is 4673 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4216' is mentioned on line 83, but not defined == Missing Reference: 'PCE' is mentioned on line 86, but not defined == Missing Reference: 'ISIS' is mentioned on line 94, but not defined == Missing Reference: 'RFC 5441' is mentioned on line 483, but not defined == Missing Reference: 'RFC3209' is mentioned on line 562, but not defined == Missing Reference: 'RFC3473' is mentioned on line 562, but not defined == Missing Reference: 'RFC3477' is mentioned on line 562, but not defined == Unused Reference: 'RFC4655' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'RFC4726' is defined on line 672, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 676, but no explicit reference was found in the text == Unused Reference: 'RFC5152' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'RFC5376' is defined on line 698, but no explicit reference was found in the text == Unused Reference: 'RFC5394' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'H-PCE' is defined on line 721, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5316 (Obsoleted by RFC 9346) == Outdated reference: A later version (-06) exists of draft-king-pce-hierarchy-fwk-03 Summary: 1 error (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Xuerong Wang 3 Internet-Draft Muliu Tao 4 Intended status: Informational Xihua Fu 5 Expires: January 12, 2012 Qilei Wang 6 Kexin Tang 7 ZTE Corporation 8 July 11, 2011 10 Extensions of Backward-Recursive PCE-Based Computation (BRPC) to Support 11 Inter-Autonomous System (AS) Bidirectional LSP Path Computation 12 draft-wang-pce-inter-as-extentions-01.txt 14 Abstract 16 This document provides extensions for the Backward-Recursive PCE- 17 Based Computation (BRPC) to support bidirection LSP path computation. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 12, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Conventions used in this document . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Inter-AS Information Advertised by IGP . . . . . . . . . . 4 58 3.2. Backward Recursive Path Computation . . . . . . . . . . . 5 59 3.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 5 60 4. Solutions of Inter-AS bidirectional path computation . . . . . 7 61 4.1. Extensions of Backward-Recursive PCE-Based Computation 62 (BRPC) . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2. Extensions of PCEP . . . . . . . . . . . . . . . . . . . . 9 64 4.2.1. IVSPT flag . . . . . . . . . . . . . . . . . . . . . . 10 65 4.2.2. BRPC Procedure Completion Failure . . . . . . . . . . 10 66 4.2.3. Inter-AS TE links carried in PCEP message . . . . . . 11 67 4.2.3.1. Definition of IVSPT(i) . . . . . . . . . . . . . . 11 68 4.2.3.2. Constrain Route Object(CRO) . . . . . . . . . . . 13 69 4.2.3.3. IVSPT Encoding . . . . . . . . . . . . . . . . . . 15 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 78 1. Introduction 80 Requirements for establishing Multiprotocol Label Switching Traffic 81 Engineering (MPLS-TE) Label Switched Paths (LSPs) that cross multiple 82 Autonomous Systems (ASes) are described in [RFC4216]. As described 83 in [RFC4216], a method SHOULD provide the ability to compute a path 84 spanning multiple ASes. So a path computation entity that may be the 85 head-end Label Switching Router (LSR), an AS Border Router (ASBR), or 86 a Path Computation Element [PCE] needs to know the TE information not 87 only of the links within an AS, but also of the links that connect to 88 other ASes. 90 As described in [RFC5392], two new LSAs are defined to advertise 91 inter-AS TE information for OSPFv2 and OSPFv3 separately, and three 92 new sub-TLVs are added to the existing Link TLV to carry the 93 information about the neighboring AS and the remote ASBR. [RFC5316] 94 defines similar extensions for [ISIS]. 96 In order for bidirection path computation, PCE needs to get 97 bidirection Inter-AS TE link information. [RFC5392] introduces a 98 "proxy" for the ASBR at the edge of the other AS and generate a 99 bidirection TE link. 101 This document extends BRPC in order to support the bidirection path 102 computation within single procedure. Based on the mechanism in this 103 document, we don't need to introduce the 'proxy'. It shows how the 104 Backward-Recursive PCE-Based Computation (BRPC) - procedures for 105 Inter-AS TE Links can be extended in order for deriving the optimum 106 end-to-end bidirection path. 108 This document does not propose or define any mechanisms to advertise 109 any other extra-AS TE information within IGP. 111 1.1. Conventions used in this document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2. Terminology 119 o ASBR: Autonomous System Border Router. Router used to connect 120 together ASes of the same or different service providers via one 121 or more inter-AS links. 123 o Boundary Node (BN): a boundary node is either an ABR in the 124 context of inter-area Traffic Engineering or an ASBR in the 125 context of inter-AS Traffic Engineering. 127 o Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) 128 along a determined sequence of domains. 130 o Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) 131 along a determined sequence of domains. 133 o PCC: Path Computation Client. Any client application requesting a 134 path computation to be performed by a Path Computation Element. 136 o PCE: Path Computation Element. An entity (component, application, 137 or network node) that is capable of computing a network path or 138 route based on a network graph and applying computational 139 constraints. 141 o PCE(i) is a PCE with the scope of domain(i).d 143 o TED: Traffic Engineering Database. 145 o VSPT: Virtual Shortest Path Tree. 147 o IVSPT: Inter-AS Virtual Shortest Path Tree. 149 3. Introduction 151 3.1. Inter-AS Information Advertised by IGP 153 As mentioned in [RFC5392] and [RFC5316], Hellos MUST NOT be exchanged 154 over the Inter-AS TE link, and consequently, an IGP adjacency MUST 155 NOT be formed. 157 In the current operation of TE IGP, the LSRs at each end of a TE link 158 emit LSAs describing the link. The databases in the LSRs then have 159 two entries (one locally generated, the other from the peer) that 160 describe the different 'directions' of the link. This enables 161 Constrained Shortest Path First (CSPF) to do a two-way check on the 162 link when performing path computation and eliminate it from 163 consideration unless both directions of the link satisfy the required 164 constraints. 166 In the case we are considering here (i.e., of a TE link to another 167 AS), there is, by definition, no IGP peering and hence no bidirection 168 TE link information. 170 The information advertised comes from the ASBR's knowledge of the 171 unidirection TE capabilities of the link, the ASBR's knowledge of the 172 unidirection current status and usage of the link, and configuration 173 at the ASBR of the remote AS number and remote ASBR TE Router ID. 175 For other properties, e.g., bandwidth and metrics, an ASBR is 176 difficult or impossible to get the latest value of these properties 177 about reverse directional of Inter-AS TE links timely. In order for 178 the CSPF route computation entity to include the link as a candidate 179 path, we have to find a way to solve this problem. 181 3.2. Backward Recursive Path Computation 183 The Backward Recursive Path Computation (BRPC) [RFC5441] procedure 184 involves cooperation and communication between PCEs in order to 185 compute an optimal end-to-end path across multiple domains. Each PCE 186 creates a tree of potential paths from every entry BN to the LSP 187 destination (the Virtual Shortest Path Tree - VSPT) and passes this 188 back to the previous PCE in a PCRep. Each PCE in turn adds to the 189 VSPT and passes it back until the PCE in the source domain uses the 190 VSPT to select an end-to-end path . 192 In the case of inter-domain LSP computation, PCE(i)(i=n-1 to 2) also 193 requires adding the inter-AS TE links that connect the domain(i) and 194 the domain(i+1). 196 3.3. Problem Statement 198 Following scenarios illustrate the problem. 200 Case 1: Inter-AS link failed in only one direction 202 A---B1---- C1---Z 203 \ | | / 204 \ | | / 205 \ | | / 206 B2---- C2 207 : 208 <--AS1-->:<-- AS2--> 210 Figure 1: multi-AS network 212 Considering multi-AS network shown in Figure 1,PCE1 responsible for 213 the computation of AS1, and PCE2 responsible for the computation of 214 AS2 . Bidirection Inter-AS link between B1 and C1 consists of two 215 unidirectional inter-AS links, one is from B1 to C1,another is from 216 C1 to B1. For the inter-AS links do not exchange IGP information, 217 PCE1 and PCE2 seperately have the TE properties of one direction of a 218 bidirection inter-AS link. 220 As described in RFC5441: In the case of inter-domain LSP computation, 221 PCE(i)(i=n-1 to 2) also requires adding the inter-AS TE links that 222 connect the domain(i) and the domain(i+1). 224 For unidirection LSP computation from A to Z: Because PCE1 has the TE 225 properties in one direction (i.e.,B1-->C1, B2-->C2) of the inter-AS 226 links, PCE1 knows which inter-AS link can be added. So PCE1 can 227 compute LSP within AS1 attached add the unidirectional inter-AS links 228 that connect AS1 to AS2 (i.e., B1-->C1, B2-->C2). 230 For bidirection LSP computation from A to Z : Suppose the inter-AS 231 link fails in one direction( e.g. ,from C1 to B1), Which inter-AS 232 link should be selected for the bidirectional path? Obviously, PCE1 233 can't select proper inter-AS TE links without any enough information. 235 Case 2: bandwidth of bidirection inter-AS link is different in two 236 directions 238 Z1 A1 239 \ / 240 B------C 241 / \ 242 A2 Z2 243 : 244 <--AS1-->:<--AS2--> 246 Figure 2: multi-AS MPLS-TP network 248 Figure 2 shows a multi-AS MPLS-TP network, where AS1 and AS2 are 249 MPLS-TP networks. PCE1 and PCE2 are responsible for the computation 250 of corresponding AS. 252 Suppose unidirection LSP along A1-C-B-Z1 have already been setup, and 253 bandwidth has been reserved for the LSP. For the inter-AS link 254 between B and C, bandwidth of link that is from B to C is not the 255 same as that is from C to B. If we want to create a co-routed 256 bidirection LSP from A2 to Z2, suppose bandwidth of inter-AS link 257 only satisfy the constraints in one direction. Neither PCE1 nor PCE2 258 knows which bidirectional inter-AS link could be select. 260 Case 3: multi-inter-AS links connect to one ASBR 261 A----B1----C1----Z 262 \ | \ / | / 263 \ | X | / 264 \ | / \ | / 265 B2----C2 266 : 267 <-- AS1 -->:<---- AS2 ---> 269 Figure 3: multi-inter-AS links connect to one ASBR 271 Suppose unidirectional inter-AS link from C1 to B1 doesn't satisfy 272 the constraints. As previous case shown in figure1, there is only 273 one inter-AS link connect to each ASBR node. PCE2 has the ability to 274 check that unidirectional inter-AS link from C1 to B1 does not 275 satisfy the constraints, and then it can simply delete the path C1 to 276 Z from VSPT and only passes path C2 to Z in PCRep to PCE2 . But if 277 there are more than one inter-AS links connected to one ASBR, and not 278 all of the unidirectional inter-AS links don't satisfy the 279 constraints, there still be some problem: 281 In figure 3, there are more than one inter-AS links connected to one 282 ASBRs. Suppose a bidirectional LSP from A to Z is going to be 283 created and only unidirectional inter-AS link from C1 to B1 doesn't 284 satisfy the constraints.VSPT computed by PCE2 consists of two paths: 285 C1 to Z and C2 to Z. So in figure 3, PCE1 can not delete the path C1 286 to Z from VSPT. Similarly,How can PCE1 or PCE2 know which inter-AS 287 links to select? 289 4. Solutions of Inter-AS bidirectional path computation 291 4.1. Extensions of Backward-Recursive PCE-Based Computation (BRPC) 293 As described in RFC5441: In the case of inter-domain LSP computation, 294 PCE(i)(i=n-1 to 2) also requires adding the inter-AS TE links that 295 connect the domain(i) and the domain(i+1).The problem about Inter-AS 296 TE links described in previous section focus on : In the case of 297 bidirection LSP computation, if PCE adds the inter-AS TE links ,it 298 must know which of the inter-AS links that can be added. 300 In our solution, PCE can select inter-AS links that satisfy the 301 constraints and carry them in the computing reply message(Specially 302 in case3 shown in previous section, PCE2 must let PCE1 know which 303 unidirection inter-AS link satisfy the constraints). 305 With the following extensions of BRPC procedure we can get these 306 proper inter-AS TE links for the bidirection LSP: 308 o After computing the shortest constrained paths(i.e., VSPT) between 309 every entry BN and the TE LSP destination, PCE(i+1) selects the 310 Inter-AS TE links from AS(i+1) to AS(i) that satisfy the 311 constraints and passes them back to the PCE(i) in a PCRep. 313 o Then, the PCE(i) can choose among the Inter-AS TE links carried in 314 received PCRep message that satisfy the constraints in the reverse 315 direction ,and compute the shortest constrained paths between 316 every exit BN and the TE LSP destination. 318 Following is the extended BRPC procedure: 320 o Step 1: 322 First, the PCC needs to determine the PCE capable of serving its 323 path computation request (this can be done with local 324 configuration or via IGP discovery (see [RFC5088] and [RFC5089])). 325 The path computation request is then relayed until reaching a 326 PCE(n) such that the TE LSP destination resides in the domain(n). 327 This step is the same as described in [RFC5441]. 329 o Step 2: 331 2.1. PCE(n) computes the list of shortest constrained paths 332 between every BN-en(j,n) and the TE LSP destination; 334 2.2. PCE(n) selects the Inter-AS TE links that satisfy the 335 constraints from all of the Inter-AS TE links that provide 336 connectivity from domain (n) to domain(n-1); 338 2.3. PCE(n) returns PCRep (including result of 2.1 and 2.2) to 339 PCE(n-1). 341 Note that for unidirection LSP computation, step 2.2 may not be 342 performed. 344 o Step i: 346 For i=n-1 to 2: { 348 i.1. With the Inter-AS TE links returned from PCE(i+1), PCE(i) 349 chooses the links that satisfy the constraints in the reverse 350 direction(i.e., the selected Inter-AS TE links satisfy the 351 required constraints in both of the directions.) 353 i.2. PCE(i) computes the shortest constrained paths between each 354 BN-en(j,i) and the TE LSP destination; PCE(i)(i=n-1 to 2) requires 355 adding the inter-AS TE links that concluded by i.1. 357 i.3. PCE(i) selects the Inter-AS TE links that unidirectionally 358 satisfy the constraints from all of the Inter-AS TE links that 359 provide connectivity from domain (i) to domain(i-1); 361 i.4. PCE(i) returns PCRep (including result of i.2 and i.3) to 362 PCE(i-1). } 364 Note that for unidirection LSP computation, step i.1, and i.3 may 365 not be performed. 367 o Step n: 369 n.1. With the Inter-AS TE links returned from PCE(2), PCE(1) 370 chooses the links that satisfy the constraints in the reverse 371 direction (i.e., the selected Inter-AS TE links satisfy the 372 required constraints in both of the directions.); 374 n.2. PCE(1) computes the end-to-end shortest constrained path. 375 PCE(1) requires adding the inter-AS TE links that concluded by 376 n.1. 378 Note that for unidirection LSP computation, step n.1. may not be 379 performed. 381 Note that uni-direction represents the direction from entry BNs of 382 local domain i to exit BNs of domain i-1, the reverse direction 383 represents the direction from exit BNs of local domain i to entry BNs 384 of domain i+1. 386 4.2. Extensions of PCEP 388 As described in RFC5440, if the path computation request can be 389 satisfied, the set of computed paths specified by means of Explicit 390 Route Objects (EROs) is inserted in the PCRep message.In the scenario 391 of inter-domain path computation using BRPC procedure,the ERO 392 represents the VSPT, i.e.,the paths satisfy the constraints between 393 every entry BN and the LSP destination. 395 For the following reasons, a new object CRO (see 4.2.3) is introdued 396 to represent the inter-AS links: 398 o l For the bidirection LSP solution introduced in this document, 399 the inter-AS links carried in PCRep satisfy the constraints only 400 in one direction. These inter-AS links only partially satisfy the 401 constraints, and wait for neighbor PCE to confirm the constraints 402 in reverse direction. These partially confirmed inter-AS links 403 are not the compute results and only used to notify neighbor PCE 404 to confirm. So the inter-AS links carried in PCRep need to 405 differentiate from ERO that represents the computation result. 407 o To include inter-AS links by ERO needs to stitch VSPT and inter-AS 408 links. In the case there are more than one inter-AS links connect 409 to one ASBR, e.g., in figure 3, ERO C1--Z represent the path from 410 the ASBR C1 to the destination Z. Suppose both of the two inter-AS 411 links C1--B1 and C1--B2 satisfy the constraints, then maybe we 412 need to copy C1--Z to two EROs, one stitchs inter-AS link B1--C1, 413 the other stitchs inter-AS link B2--C1. So there maybe some 414 repeated information. 416 4.2.1. IVSPT flag 418 PCEP needs to be introduced a new flag in RP object carried within 419 the PCReq message (defined in [RFC5440]). The PCE(i) set this flag 420 in PCReq to indicates that the Inter-AS TE links from AS(i+1) to 421 AS(i) satisfying the constraints must be return. In other words, the 422 PCE(i) requests the computation of an inter-domain TE LSP using the 423 new BRPC procedure defined in this document, and Inter-AS TE links 424 from AS(i+1) to AS(i) satisfying the constraints must be included in 425 PCRep. 427 The following new flag of the RP object is defined: 429 IVSPT Flag 431 Bit Number Name Flag 432 ------- ------ 433 TBD IVSPT 435 4.2.2. BRPC Procedure Completion Failure 437 If PCE(i) send IVSPT flag to PCE(i+1) who doesn't recognizes the 438 IVSPT flag of RP object, PCE(i+1) MUST generate PCErr message with an 439 Error-Type=4 (Not supported object), Error-value=4 (Unsupported 440 parameter). The PCE may include the parent object (RP object) up to 441 and including (but no further than) the unknown or unsupported 442 parameter. In this case where the unknown or unsupported parameter 443 is a bit flag (IVSPT flag), the included RP object should contain the 444 whole bit flag field with all bits after the parameter at issue set 445 to zero. The corresponding path computation request is then 446 cancelled by the PCE without further notification. 448 If PCE(i) send IVSPT flag to PCE(i+1) who recognizes IVSPT flag of RP 449 object but does not support the new BRPC procedure extended in this 450 document, it MUST return a PCErr message to the upstream PCE with an 451 Error-Type " Enhanced BRPC procedure unsupported". 453 The PCErr message MUST be relayed to the requesting PCC. 455 PCEP-ERROR objects are used to report a PCEP protocol error and are 456 characterized by an Error-Type that specifies the type of error and 457 an Error-value that provides additional information about the error 458 type. Both the Error-Type and the Error-value are managed by IANA. 460 A new Error-Type is defined that relates to the BRPC procedure. 462 Error-Type Meaning 463 -------- ------- 464 TBD Enhanced BRPC procedure unsupported 466 Error-value 467 1 Enhanced BRPC procedure not supported 468 by one or more PCEs along the domain path 470 4.2.3. Inter-AS TE links carried in PCEP message 472 For the bidirection Inter-AS TE LSP BRPC procedure referenced in this 473 document, PCE(n) should select the unidirection Inter-AS TE links 474 that satisfy the constraints from all of the Inter-AS TE links that 475 provide connectivity from domain (n) to domain(n-1),and then PCE(n) 476 should return the selected Inter-AS TE links in PCRep message. 478 We introduce a new object (Inter-AS Virtual Shortest Path Tree 479 -IVSPT) to carry the selected Inter-AS TE links (see 4.2.3.1.). 481 4.2.3.1. Definition of IVSPT(i) 483 Mode of BRPC Operation is introduced in [RFC 5441]: 485 Definition of VSPT(i) 487 In each domain i: 489 o Step 1: There is a set of X-en(i) entry BNs noted BN-en(k,i) where 490 BN-en(k,i) is the kth entry BN of domain(i). 492 o There is a set of X-ex(i) exit BNs noted BN-ex(k,i) where BN- 493 ex(k,i) is the kth exit BN of domain(i). 495 VSPT(i): MP2P (multipoint-to-point) tree returned by PCE(i) to 496 PCE(i-1): 498 Root (TE LSP destination) 499 / | \ 500 BN-en(1,i) BN-en(2,i) ... BN-en(j,i). 502 where [X-en(i)] is the number of 503 entry BNs in domain i and j<= [X-en(i)] 505 Figure 4: MP2P VSPT 507 Each link of tree VSPT(i) represents the shortest constrained path 508 between BN-en(j,i) and the TE LSP destination that satisfies the set 509 of required constraints for the TE LSP (bandwidth, affinities, 510 etc.).These are path segments to reach the TE LSP destination from 511 BN-en(j,i). 513 Note that PCE(i) only considers the entry BNs of domain(i), i.e., 514 only the BNs that provide connectivity from domain(i-1). 516 Besides VSPT, this document defines Inter-AS Virtual Shortest Path 517 Tree (IVSPT) used for describing unidirection Inter-AS paths whose 518 direction is from AS(i) to AS(i-1). 520 Definition of IVSPT(j,i) : 522 IVSPT(j,i): jth MP2P (multipoint-to-point) tree returned by PCE(i) to 523 PCE(i-1) 524 IVSPT(1,i): 526 BN-en(1,i) 527 / | \ 528 BN-ex(1,i-1) BN-ex(2,i-1) ... BN-ex(k1,i-1). 530 IVSPT(2,i): 532 BN-en(2,i) 533 / | \ 534 BN-ex(1,i-1) BN-ex(2,i-1) ... BN-ex(k2,i-1). 536 IVSPT(j,i): 538 BN-en(j,i) 539 / | \ 540 BN-ex(1,i-1) BN-ex(2,i-1) ... BN-ex(kj,i-1). 542 where 543 [X-en(i)] is the number of entry BNs in domain i and j<= [X-en(i)], 544 [Y-ex(i-1)] is the number of exit BNs in domain i-1 545 and k1,k2,...,kj<= [X-ex(i-1)] 547 Figure 5: IVSPT 549 IVSPT(j,i) represents the Inter-AS paths from BN-en(j,i) of domain i 550 to exit BNs of domain i-1 that satisfies the set of required 551 constraints for the TE LSP (bandwidth, affinities, etc.). 553 4.2.3.2. Constrain Route Object(CRO) 555 The CRO is used to encode the Inter-AS paths that satisfies the set 556 of required constraints for the TE LSP. 558 The CRO is carried within a PCRep message to provide the selected 559 Inter-AS links if the path computation was successful. 561 The contents of this object are identical to the contents of the 562 RSVP-TE ERO defined in [RFC3209], [RFC3473], and [RFC3477]. That is, 563 the object is constructed from a series of sub-objects. Any RSVP-TE 564 ERO sub-object already defined or that could be defined in the future 565 for use in the RSVP-TE ERO is acceptable in this object. 567 0 1 2 3 568 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | | 571 // (Sub-objects) // 572 | | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Sub-objects: 575 Type Sub-object 576 1 IPv4 prefix 577 2 IPv6 prefix 578 4 Unnumbered Interface ID 580 Figure 6: Format of CRO 582 The format of the PCRep message is updated as follows : 584 ::= 585 587 where: 589 ::=[] 591 ::= 592 [] 593 [] 594 [] 596 ::=[][] 598 ::= 600 where: 602 ::=[] 603 [] 604 [] 605 [] 607 ::=[] 609 ::=< CRO >[< CRO -list>] 611 4.2.3.3. IVSPT Encoding 613 The IVSPT is returned within a PCRep message. The encoding consists 614 of a non-ordered list of Constrain Route Objects (CROs) where each 615 CRO represents an Inter-AS link that satisfy the required constraint 616 from domain i to domain i+1. 618 Example: 620 R1------R3----R5-----R7------R9-----R11---- R13 621 | \ | \ | / | / 622 | \ | \ | ---- | ---------- 623 | \ | \ | / | / 624 R2------R4----R6-----R8------R10----R12 625 : : 626 <-- AS1 -->:<---- AS2 --->:<------- AS3 ---------> 628 Figure 7: An Example of Inter-AS path computation 630 In the example shown in Figure 7, if we make the assumption that a 631 constrained path exists between each ABR and the destination R13, the 632 VSPT computed by a PCE(3) serving AS 3 consists of the following non- 633 ordered set of EROs: 635 o ERO1: R9(TE Router ID)-R11(Interface IP address)-R13(TE Router ID) 637 o ERO2: R10(TE Router ID)-R13(TE Router ID) 639 If we make the assumption that Inter-AS links R9-->R7 ,R9-->R8 and 640 R10-->R8 satisfy the required constraints, the IVSPT selected by a 641 PCE(3) serving AS 3 consists of the following non-ordered set of 642 CROs: 644 o CRO1: R9(Interface IP address),R7(TE Router ID) 646 o CRO2: R9(Interface IP address),R8(TE Router ID) 648 o CRO3: R10(Interface IP address),R8(TE Router ID) 650 5. Security Considerations 652 TBD. 654 6. IANA considerations 656 TBD. 658 7. Acknowledgments 660 TBD. 662 8. References 664 8.1. Normative References 666 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 667 Requirement Levels", BCP 14, RFC 2119, March 1997. 669 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 670 Element (PCE)-Based Architecture", RFC 4655, August 2006. 672 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 673 Inter-Domain Multiprotocol Label Switching Traffic 674 Engineering", RFC 4726, November 2006. 676 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 677 "Extensions to Resource Reservation Protocol - Traffic 678 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 679 Switched Paths (LSPs)", RFC 4875, May 2007. 681 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 682 "OSPF Protocol Extensions for Path Computation Element 683 (PCE) Discovery", RFC 5088, January 2008. 685 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 686 "IS-IS Protocol Extensions for Path Computation Element 687 (PCE) Discovery", RFC 5089, January 2008. 689 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 690 Path Computation Method for Establishing Inter-Domain 691 Traffic Engineering (TE) Label Switched Paths (LSPs)", 692 RFC 5152, February 2008. 694 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 695 Support of Inter-Autonomous System (AS) MPLS and GMPLS 696 Traffic Engineering", RFC 5316, December 2008. 698 [RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS 699 Requirements for the Path Computation Element 700 Communication Protocol (PCECP)", RFC 5376, November 2008. 702 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 703 Support of Inter-Autonomous System (AS) MPLS and GMPLS 704 Traffic Engineering", RFC 5392, January 2009. 706 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 707 "Policy-Enabled Path Computation Framework", RFC 5394, 708 December 2008. 710 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 711 (PCE) Communication Protocol (PCEP)", RFC 5440, 712 March 2009. 714 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 715 Backward-Recursive PCE-Based Computation (BRPC) Procedure 716 to Compute Shortest Constrained Inter-Domain Traffic 717 Engineering Label Switched Paths", RFC 5441, April 2009. 719 8.2. Informative References 721 [H-PCE] D. King, "The Application of the Path Computation Element 722 Architecture to the Determination of a Sequence of Domains 723 in MPLS & GMPLS", draft-king-pce-hierarchy-fwk-03.txt . 725 Authors' Addresses 727 Xuerong Wang 728 ZTE Corporation 729 6F, R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road, 730 Nanshan District, Shenzhen 518055 731 P.R.China 733 Phone: +86 755 26773609 734 Email: wang.xuerong@zte.com.cn 735 URI: http://www.zte.com.cn/ 737 Muliu Tao 738 ZTE Corporation 739 4F, R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road, 740 Nanshan District, Shenzhen 518055 741 P.R.China 743 Phone: +86 755 26773609 744 Email: tao.muliu@zte.com.cn 745 URI: http://www.zte.com.cn/ 746 Xihua Fu 747 ZTE Corporation 748 ZTE Plaza, No.10, Tangyan South Road, 749 Gaoxin District,Xi'An 710065 750 P.R.China 752 Phone: +86 29 85458058 753 Email: fu.xihua@zte.com.cn 754 URI: http://www.zte.com.cn/ 756 Qilei Wang 757 ZTE Corporation 758 No.50 Software Avenue, 759 Yuhuatai District, Nanjing 210012 760 P.R.China 762 Phone: +86 25 88014224 763 Email: wang.qilei@zte.com.cn 764 URI: http://www.zte.com.cn/ 766 Kexin Tang 767 ZTE Corporation 768 No.50 Software Avenue, 769 Yuhuatai District, Nanjing 210012 770 P.R.China 772 Phone: +86 25 88014224 773 Email: tang.kexin@zte.com.cn 774 URI: http://www.zte.com.cn/