Network Working Group Xuerong Wang Internet-Draft Muliu Tao Intended status: Informational Xihua Fu Expires: January 12, 2012 Qilei Wang Kexin Tang ZTE Corporation July 11, 2011 Extensions of Backward-Recursive PCE-Based Computation (BRPC) to Support Inter-Autonomous System (AS) Bidirectional LSP Path Computation draft-wang-pce-inter-as-extentions-01.txt Abstract This document provides extensions for the Backward-Recursive PCE- Based Computation (BRPC) to support bidirection LSP path computation. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 12, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Xuerong Wang, et al. Expires January 12, 2012 [Page 1] Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Inter-AS Information Advertised by IGP . . . . . . . . . . 4 3.2. Backward Recursive Path Computation . . . . . . . . . . . 5 3.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 5 4. Solutions of Inter-AS bidirectional path computation . . . . . 7 4.1. Extensions of Backward-Recursive PCE-Based Computation (BRPC) . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Extensions of PCEP . . . . . . . . . . . . . . . . . . . . 9 4.2.1. IVSPT flag . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. BRPC Procedure Completion Failure . . . . . . . . . . 10 4.2.3. Inter-AS TE links carried in PCEP message . . . . . . 11 4.2.3.1. Definition of IVSPT(i) . . . . . . . . . . . . . . 11 4.2.3.2. Constrain Route Object(CRO) . . . . . . . . . . . 13 4.2.3.3. IVSPT Encoding . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Xuerong Wang, et al. Expires January 12, 2012 [Page 2] Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011 1. Introduction Requirements for establishing Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs) that cross multiple Autonomous Systems (ASes) are described in [RFC4216]. As described in [RFC4216], a method SHOULD provide the ability to compute a path spanning multiple ASes. So a path computation entity that may be the head-end Label Switching Router (LSR), an AS Border Router (ASBR), or a Path Computation Element [PCE] needs to know the TE information not only of the links within an AS, but also of the links that connect to other ASes. As described in [RFC5392], two new LSAs are defined to advertise inter-AS TE information for OSPFv2 and OSPFv3 separately, and three new sub-TLVs are added to the existing Link TLV to carry the information about the neighboring AS and the remote ASBR. [RFC5316] defines similar extensions for [ISIS]. In order for bidirection path computation, PCE needs to get bidirection Inter-AS TE link information. [RFC5392] introduces a "proxy" for the ASBR at the edge of the other AS and generate a bidirection TE link. This document extends BRPC in order to support the bidirection path computation within single procedure. Based on the mechanism in this document, we don't need to introduce the 'proxy'. It shows how the Backward-Recursive PCE-Based Computation (BRPC) - procedures for Inter-AS TE Links can be extended in order for deriving the optimum end-to-end bidirection path. This document does not propose or define any mechanisms to advertise any other extra-AS TE information within IGP. 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Terminology o ASBR: Autonomous System Border Router. Router used to connect together ASes of the same or different service providers via one or more inter-AS links. o Boundary Node (BN): a boundary node is either an ABR in the context of inter-area Traffic Engineering or an ASBR in the Xuerong Wang, et al. Expires January 12, 2012 [Page 3] Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011 context of inter-AS Traffic Engineering. o Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along a determined sequence of domains. o Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along a determined sequence of domains. o PCC: Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element. o PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. o PCE(i) is a PCE with the scope of domain(i).d o TED: Traffic Engineering Database. o VSPT: Virtual Shortest Path Tree. o IVSPT: Inter-AS Virtual Shortest Path Tree. 3. Introduction 3.1. Inter-AS Information Advertised by IGP As mentioned in [RFC5392] and [RFC5316], Hellos MUST NOT be exchanged over the Inter-AS TE link, and consequently, an IGP adjacency MUST NOT be formed. In the current operation of TE IGP, the LSRs at each end of a TE link emit LSAs describing the link. The databases in the LSRs then have two entries (one locally generated, the other from the peer) that describe the different 'directions' of the link. This enables Constrained Shortest Path First (CSPF) to do a two-way check on the link when performing path computation and eliminate it from consideration unless both directions of the link satisfy the required constraints. In the case we are considering here (i.e., of a TE link to another AS), there is, by definition, no IGP peering and hence no bidirection TE link information. The information advertised comes from the ASBR's knowledge of the unidirection TE capabilities of the link, the ASBR's knowledge of the Xuerong Wang, et al. Expires January 12, 2012 [Page 4] Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011 unidirection current status and usage of the link, and configuration at the ASBR of the remote AS number and remote ASBR TE Router ID. For other properties, e.g., bandwidth and metrics, an ASBR is difficult or impossible to get the latest value of these properties about reverse directional of Inter-AS TE links timely. In order for the CSPF route computation entity to include the link as a candidate path, we have to find a way to solve this problem. 3.2. Backward Recursive Path Computation The Backward Recursive Path Computation (BRPC) [RFC5441] procedure involves cooperation and communication between PCEs in order to compute an optimal end-to-end path across multiple domains. Each PCE creates a tree of potential paths from every entry BN to the LSP destination (the Virtual Shortest Path Tree - VSPT) and passes this back to the previous PCE in a PCRep. Each PCE in turn adds to the VSPT and passes it back until the PCE in the source domain uses the VSPT to select an end-to-end path . In the case of inter-domain LSP computation, PCE(i)(i=n-1 to 2) also requires adding the inter-AS TE links that connect the domain(i) and the domain(i+1). 3.3. Problem Statement Following scenarios illustrate the problem. Case 1: Inter-AS link failed in only one direction A---B1---- C1---Z \ | | / \ | | / \ | | / B2---- C2 : <--AS1-->:<-- AS2--> Figure 1: multi-AS network Considering multi-AS network shown in Figure 1,PCE1 responsible for the computation of AS1, and PCE2 responsible for the computation of AS2 . Bidirection Inter-AS link between B1 and C1 consists of two unidirectional inter-AS links, one is from B1 to C1,another is from C1 to B1. For the inter-AS links do not exchange IGP information, PCE1 and PCE2 seperately have the TE properties of one direction of a bidirection inter-AS link. Xuerong Wang, et al. Expires January 12, 2012 [Page 5] Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011 As described in RFC5441: In the case of inter-domain LSP computation, PCE(i)(i=n-1 to 2) also requires adding the inter-AS TE links that connect the domain(i) and the domain(i+1). For unidirection LSP computation from A to Z: Because PCE1 has the TE properties in one direction (i.e.,B1-->C1, B2-->C2) of the inter-AS links, PCE1 knows which inter-AS link can be added. So PCE1 can compute LSP within AS1 attached add the unidirectional inter-AS links that connect AS1 to AS2 (i.e., B1-->C1, B2-->C2). For bidirection LSP computation from A to Z : Suppose the inter-AS link fails in one direction( e.g. ,from C1 to B1), Which inter-AS link should be selected for the bidirectional path? Obviously, PCE1 can't select proper inter-AS TE links without any enough information. Case 2: bandwidth of bidirection inter-AS link is different in two directions Z1 A1 \ / B------C / \ A2 Z2 : <--AS1-->:<--AS2--> Figure 2: multi-AS MPLS-TP network Figure 2 shows a multi-AS MPLS-TP network, where AS1 and AS2 are MPLS-TP networks. PCE1 and PCE2 are responsible for the computation of corresponding AS. Suppose unidirection LSP along A1-C-B-Z1 have already been setup, and bandwidth has been reserved for the LSP. For the inter-AS link between B and C, bandwidth of link that is from B to C is not the same as that is from C to B. If we want to create a co-routed bidirection LSP from A2 to Z2, suppose bandwidth of inter-AS link only satisfy the constraints in one direction. Neither PCE1 nor PCE2 knows which bidirectional inter-AS link could be select. Case 3: multi-inter-AS links connect to one ASBR Xuerong Wang, et al. Expires January 12, 2012 [Page 6] Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011 A----B1----C1----Z \ | \ / | / \ | X | / \ | / \ | / B2----C2 : <-- AS1 -->:<---- AS2 ---> Figure 3: multi-inter-AS links connect to one ASBR Suppose unidirectional inter-AS link from C1 to B1 doesn't satisfy the constraints. As previous case shown in figure1, there is only one inter-AS link connect to each ASBR node. PCE2 has the ability to check that unidirectional inter-AS link from C1 to B1 does not satisfy the constraints, and then it can simply delete the path C1 to Z from VSPT and only passes path C2 to Z in PCRep to PCE2 . But if there are more than one inter-AS links connected to one ASBR, and not all of the unidirectional inter-AS links don't satisfy the constraints, there still be some problem: In figure 3, there are more than one inter-AS links connected to one ASBRs. Suppose a bidirectional LSP from A to Z is going to be created and only unidirectional inter-AS link from C1 to B1 doesn't satisfy the constraints.VSPT computed by PCE2 consists of two paths: C1 to Z and C2 to Z. So in figure 3, PCE1 can not delete the path C1 to Z from VSPT. Similarly,How can PCE1 or PCE2 know which inter-AS links to select? 4. Solutions of Inter-AS bidirectional path computation 4.1. Extensions of Backward-Recursive PCE-Based Computation (BRPC) As described in RFC5441: In the case of inter-domain LSP computation, PCE(i)(i=n-1 to 2) also requires adding the inter-AS TE links that connect the domain(i) and the domain(i+1).The problem about Inter-AS TE links described in previous section focus on : In the case of bidirection LSP computation, if PCE adds the inter-AS TE links ,it must know which of the inter-AS links that can be added. In our solution, PCE can select inter-AS links that satisfy the constraints and carry them in the computing reply message(Specially in case3 shown in previous section, PCE2 must let PCE1 know which unidirection inter-AS link satisfy the constraints). With the following extensions of BRPC procedure we can get these proper inter-AS TE links for the bidirection LSP: Xuerong Wang, et al. Expires January 12, 2012 [Page 7] Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011 o After computing the shortest constrained paths(i.e., VSPT) between every entry BN and the TE LSP destination, PCE(i+1) selects the Inter-AS TE links from AS(i+1) to AS(i) that satisfy the constraints and passes them back to the PCE(i) in a PCRep. o Then, the PCE(i) can choose among the Inter-AS TE links carried in received PCRep message that satisfy the constraints in the reverse direction ,and compute the shortest constrained paths between every exit BN and the TE LSP destination. Following is the extended BRPC procedure: o Step 1: First, the PCC needs to determine the PCE capable of serving its path computation request (this can be done with local configuration or via IGP discovery (see [RFC5088] and [RFC5089])). The path computation request is then relayed until reaching a PCE(n) such that the TE LSP destination resides in the domain(n). This step is the same as described in [RFC5441]. o Step 2: 2.1. PCE(n) computes the list of shortest constrained paths between every BN-en(j,n) and the TE LSP destination; 2.2. PCE(n) selects the Inter-AS TE links that satisfy the constraints from all of the Inter-AS TE links that provide connectivity from domain (n) to domain(n-1); 2.3. PCE(n) returns PCRep (including result of 2.1 and 2.2) to PCE(n-1). Note that for unidirection LSP computation, step 2.2 may not be performed. o Step i: For i=n-1 to 2: { i.1. With the Inter-AS TE links returned from PCE(i+1), PCE(i) chooses the links that satisfy the constraints in the reverse direction(i.e., the selected Inter-AS TE links satisfy the required constraints in both of the directions.) i.2. PCE(i) computes the shortest constrained paths between each BN-en(j,i) and the TE LSP destination; PCE(i)(i=n-1 to 2) requires adding the inter-AS TE links that concluded by i.1. Xuerong Wang, et al. Expires January 12, 2012 [Page 8] Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011 i.3. PCE(i) selects the Inter-AS TE links that unidirectionally satisfy the constraints from all of the Inter-AS TE links that provide connectivity from domain (i) to domain(i-1); i.4. PCE(i) returns PCRep (including result of i.2 and i.3) to PCE(i-1). } Note that for unidirection LSP computation, step i.1, and i.3 may not be performed. o Step n: n.1. With the Inter-AS TE links returned from PCE(2), PCE(1) chooses the links that satisfy the constraints in the reverse direction (i.e., the selected Inter-AS TE links satisfy the required constraints in both of the directions.); n.2. PCE(1) computes the end-to-end shortest constrained path. PCE(1) requires adding the inter-AS TE links that concluded by n.1. Note that for unidirection LSP computation, step n.1. may not be performed. Note that uni-direction represents the direction from entry BNs of local domain i to exit BNs of domain i-1, the reverse direction represents the direction from exit BNs of local domain i to entry BNs of domain i+1. 4.2. Extensions of PCEP As described in RFC5440, if the path computation request can be satisfied, the set of computed paths specified by means of Explicit Route Objects (EROs) is inserted in the PCRep message.In the scenario of inter-domain path computation using BRPC procedure,the ERO represents the VSPT, i.e.,the paths satisfy the constraints between every entry BN and the LSP destination. For the following reasons, a new object CRO (see 4.2.3) is introdued to represent the inter-AS links: o l For the bidirection LSP solution introduced in this document, the inter-AS links carried in PCRep satisfy the constraints only in one direction. These inter-AS links only partially satisfy the constraints, and wait for neighbor PCE to confirm the constraints in reverse direction. These partially confirmed inter-AS links are not the compute results and only used to notify neighbor PCE to confirm. So the inter-AS links carried in PCRep need to Xuerong Wang, et al. Expires January 12, 2012 [Page 9] Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011 differentiate from ERO that represents the computation result. o To include inter-AS links by ERO needs to stitch VSPT and inter-AS links. In the case there are more than one inter-AS links connect to one ASBR, e.g., in figure 3, ERO C1--Z represent the path from the ASBR C1 to the destination Z. Suppose both of the two inter-AS links C1--B1 and C1--B2 satisfy the constraints, then maybe we need to copy C1--Z to two EROs, one stitchs inter-AS link B1--C1, the other stitchs inter-AS link B2--C1. So there maybe some repeated information. 4.2.1. IVSPT flag PCEP needs to be introduced a new flag in RP object carried within the PCReq message (defined in [RFC5440]). The PCE(i) set this flag in PCReq to indicates that the Inter-AS TE links from AS(i+1) to AS(i) satisfying the constraints must be return. In other words, the PCE(i) requests the computation of an inter-domain TE LSP using the new BRPC procedure defined in this document, and Inter-AS TE links from AS(i+1) to AS(i) satisfying the constraints must be included in PCRep. The following new flag of the RP object is defined: IVSPT Flag Bit Number Name Flag ------- ------ TBD IVSPT 4.2.2. BRPC Procedure Completion Failure If PCE(i) send IVSPT flag to PCE(i+1) who doesn't recognizes the IVSPT flag of RP object, PCE(i+1) MUST generate PCErr message with an Error-Type=4 (Not supported object), Error-value=4 (Unsupported parameter). The PCE may include the parent object (RP object) up to and including (but no further than) the unknown or unsupported parameter. In this case where the unknown or unsupported parameter is a bit flag (IVSPT flag), the included RP object should contain the whole bit flag field with all bits after the parameter at issue set to zero. The corresponding path computation request is then cancelled by the PCE without further notification. If PCE(i) send IVSPT flag to PCE(i+1) who recognizes IVSPT flag of RP object but does not support the new BRPC procedure extended in this document, it MUST return a PCErr message to the upstream PCE with an Error-Type " Enhanced BRPC procedure unsupported". Xuerong Wang, et al. Expires January 12, 2012 [Page 10] Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011 The PCErr message MUST be relayed to the requesting PCC. PCEP-ERROR objects are used to report a PCEP protocol error and are characterized by an Error-Type that specifies the type of error and an Error-value that provides additional information about the error type. Both the Error-Type and the Error-value are managed by IANA. A new Error-Type is defined that relates to the BRPC procedure. Error-Type Meaning -------- ------- TBD Enhanced BRPC procedure unsupported Error-value 1 Enhanced BRPC procedure not supported by one or more PCEs along the domain path 4.2.3. Inter-AS TE links carried in PCEP message For the bidirection Inter-AS TE LSP BRPC procedure referenced in this document, PCE(n) should select the unidirection Inter-AS TE links that satisfy the constraints from all of the Inter-AS TE links that provide connectivity from domain (n) to domain(n-1),and then PCE(n) should return the selected Inter-AS TE links in PCRep message. We introduce a new object (Inter-AS Virtual Shortest Path Tree -IVSPT) to carry the selected Inter-AS TE links (see 4.2.3.1.). 4.2.3.1. Definition of IVSPT(i) Mode of BRPC Operation is introduced in [RFC 5441]: Definition of VSPT(i) In each domain i: o Step 1: There is a set of X-en(i) entry BNs noted BN-en(k,i) where BN-en(k,i) is the kth entry BN of domain(i). o There is a set of X-ex(i) exit BNs noted BN-ex(k,i) where BN- ex(k,i) is the kth exit BN of domain(i). VSPT(i): MP2P (multipoint-to-point) tree returned by PCE(i) to PCE(i-1): Xuerong Wang, et al. Expires January 12, 2012 [Page 11] Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011 Root (TE LSP destination) / | \ BN-en(1,i) BN-en(2,i) ... BN-en(j,i). where [X-en(i)] is the number of entry BNs in domain i and j<= [X-en(i)] Figure 4: MP2P VSPT Each link of tree VSPT(i) represents the shortest constrained path between BN-en(j,i) and the TE LSP destination that satisfies the set of required constraints for the TE LSP (bandwidth, affinities, etc.).These are path segments to reach the TE LSP destination from BN-en(j,i). Note that PCE(i) only considers the entry BNs of domain(i), i.e., only the BNs that provide connectivity from domain(i-1). Besides VSPT, this document defines Inter-AS Virtual Shortest Path Tree (IVSPT) used for describing unidirection Inter-AS paths whose direction is from AS(i) to AS(i-1). Definition of IVSPT(j,i) : IVSPT(j,i): jth MP2P (multipoint-to-point) tree returned by PCE(i) to PCE(i-1) Xuerong Wang, et al. Expires January 12, 2012 [Page 12] Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011 IVSPT(1,i): BN-en(1,i) / | \ BN-ex(1,i-1) BN-ex(2,i-1) ... BN-ex(k1,i-1). IVSPT(2,i): BN-en(2,i) / | \ BN-ex(1,i-1) BN-ex(2,i-1) ... BN-ex(k2,i-1). IVSPT(j,i): BN-en(j,i) / | \ BN-ex(1,i-1) BN-ex(2,i-1) ... BN-ex(kj,i-1). where [X-en(i)] is the number of entry BNs in domain i and j<= [X-en(i)], [Y-ex(i-1)] is the number of exit BNs in domain i-1 and k1,k2,...,kj<= [X-ex(i-1)] Figure 5: IVSPT IVSPT(j,i) represents the Inter-AS paths from BN-en(j,i) of domain i to exit BNs of domain i-1 that satisfies the set of required constraints for the TE LSP (bandwidth, affinities, etc.). 4.2.3.2. Constrain Route Object(CRO) The CRO is used to encode the Inter-AS paths that satisfies the set of required constraints for the TE LSP. The CRO is carried within a PCRep message to provide the selected Inter-AS links if the path computation was successful. The contents of this object are identical to the contents of the RSVP-TE ERO defined in [RFC3209], [RFC3473], and [RFC3477]. That is, the object is constructed from a series of sub-objects. Any RSVP-TE ERO sub-object already defined or that could be defined in the future for use in the RSVP-TE ERO is acceptable in this object. Xuerong Wang, et al. Expires January 12, 2012 [Page 13] Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Sub-objects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-objects: Type Sub-object 1 IPv4 prefix 2 IPv6 prefix 4 Unnumbered Interface ID Figure 6: Format of CRO The format of the PCRep message is updated as follows : ::= where: ::=[] ::= [] [] [] ::=[][] ::= where: ::=[] [] [] [] ::=[] ::=< CRO >[< CRO -list>] Xuerong Wang, et al. Expires January 12, 2012 [Page 14] Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011 4.2.3.3. IVSPT Encoding The IVSPT is returned within a PCRep message. The encoding consists of a non-ordered list of Constrain Route Objects (CROs) where each CRO represents an Inter-AS link that satisfy the required constraint from domain i to domain i+1. Example: R1------R3----R5-----R7------R9-----R11---- R13 | \ | \ | / | / | \ | \ | ---- | ---------- | \ | \ | / | / R2------R4----R6-----R8------R10----R12 : : <-- AS1 -->:<---- AS2 --->:<------- AS3 ---------> Figure 7: An Example of Inter-AS path computation In the example shown in Figure 7, if we make the assumption that a constrained path exists between each ABR and the destination R13, the VSPT computed by a PCE(3) serving AS 3 consists of the following non- ordered set of EROs: o ERO1: R9(TE Router ID)-R11(Interface IP address)-R13(TE Router ID) o ERO2: R10(TE Router ID)-R13(TE Router ID) If we make the assumption that Inter-AS links R9-->R7 ,R9-->R8 and R10-->R8 satisfy the required constraints, the IVSPT selected by a PCE(3) serving AS 3 consists of the following non-ordered set of CROs: o CRO1: R9(Interface IP address),R7(TE Router ID) o CRO2: R9(Interface IP address),R8(TE Router ID) o CRO3: R10(Interface IP address),R8(TE Router ID) 5. Security Considerations TBD. 6. IANA considerations TBD. Xuerong Wang, et al. Expires January 12, 2012 [Page 15] Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011 7. Acknowledgments TBD. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006. [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008. [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008. [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, December 2008. [RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, November 2008. [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, January 2009. Xuerong Wang, et al. Expires January 12, 2012 [Page 16] Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009. 8.2. Informative References [H-PCE] D. King, "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS & GMPLS", draft-king-pce-hierarchy-fwk-03.txt . Authors' Addresses Xuerong Wang ZTE Corporation 6F, R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road, Nanshan District, Shenzhen 518055 P.R.China Phone: +86 755 26773609 Email: wang.xuerong@zte.com.cn URI: http://www.zte.com.cn/ Muliu Tao ZTE Corporation 4F, R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road, Nanshan District, Shenzhen 518055 P.R.China Phone: +86 755 26773609 Email: tao.muliu@zte.com.cn URI: http://www.zte.com.cn/ Xuerong Wang, et al. Expires January 12, 2012 [Page 17] Internet-Draft BRPC Ext. for Inter-AS Bidir. LSP July 2011 Xihua Fu ZTE Corporation ZTE Plaza, No.10, Tangyan South Road, Gaoxin District,Xi'An 710065 P.R.China Phone: +86 29 85458058 Email: fu.xihua@zte.com.cn URI: http://www.zte.com.cn/ Qilei Wang ZTE Corporation No.50 Software Avenue, Yuhuatai District, Nanjing 210012 P.R.China Phone: +86 25 88014224 Email: wang.qilei@zte.com.cn URI: http://www.zte.com.cn/ Kexin Tang ZTE Corporation No.50 Software Avenue, Yuhuatai District, Nanjing 210012 P.R.China Phone: +86 25 88014224 Email: tang.kexin@zte.com.cn URI: http://www.zte.com.cn/ Xuerong Wang, et al. Expires January 12, 2012 [Page 18]