Network Working Group Nabil Bitar Internet Draft Verizon Jean-Louis Le Roux France Telecom Category: Informational Raymond Zhang BT Infonet Expires: December 2006 June 2006 Framework for PCE based inter-domain path computation draft-bitar-pce-inter-domain-frwk-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document represents a framework for computing G)MPLS-TE paths across IGP-areas in a single AS, and across multiple ASes using a path computation element (PCE). 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 RFC-2119. Bitar et al. Inter-domain PCE Framework [Page 1] Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006 Table of Contents 1. Introduction 2 2. Definitions and Requirements Statement 3 3. Reference Model for PCE-based inter-domain path computation 3 4. Inter-IGP-Area Operation 6 4.1 Inter-Area PCE Discovery 6 4.2 Inter-area Path Computation 6 4.2.1 Single PCE Computation 7 4.2.2 Multiple PCE path computation with inter-PCE communication 8 4.3 PCE Inter-area TED 9 4.4 Inter-Area PCECP 10 4.5 Optimality 10 4.6 Reoptimization 12 4.7 Diversepath computation 12 4.8.Considerations on PCE location 13 5. Inter-AS Operation13 5.1 PCE-based Inter-AS Routing 13 5.2 Inter-AS PCE Location 14 5.3 Inter-AS PCE Discovery 14 5.4 Inter-AS Path Computation 14 5.5 Path Diversity 14 5.6 Inter-AS (G)MPLS-TE Operations and Interoperability 15 5.7 Optimality 16 5.8 Reoptimization 16 6. Security Considerations 16 7. Author’s Addresses 17 8. Normative References 17 9. Informative References 17 10. Full Copyright Statement 17 11. Intellectual Property 17 1. Introduction This document represents a framework for Path Computation Element (PCE) based computation of(G)MPLS-TE paths across IGP-areas in one Autonomous System (AS) and across multiple ASes. In addition, this document identifies areas where additional protocol extensions or mechanisms are needed to satisfy inter-AS and inter-area path computations. In particular, this document defines a reference model for inter-domain (inter-area and inter-AS) path computation. It describes how elements of the PCE architecture, including: (1) PCE Communication Protocol (PCECP), (2) PCE Discovery, (3) Policies, (4) Inter-domain Path Computation Algorithms, and (5) Inter-Domain (G) MPLS-TE Signaling, cooperate in path computation. Bitar et al. Inter-domain PCE Framework [Page 2] Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006 2.Definitions and Requirements Statement This document uses terminologies defined in [RFC3031], [RFC4105], [RFC4216] and [PCE-ARCH]. It defines the following new terms: PCECP: PCE Communication Protocol PCEDP: PCE Discovery Protocol Intra-Area PCE: A PCE responsible for computing (G)MPLS-TE paths traversing a single area. Intra-Domain PCE: Intra-Area or intra-AS PCE Intra-AS PCE: A PCE responsible for computing (G)MPLS-TE paths traversing a single AS. Inter-Area PCE: A PCE responsible for computing or taking part into the computation of inter-area TE-LSPs, by possibly cooperating with intra-area PCEs or other inter-area PCEs. Inter-AS PCE: A PCE responsible for computing or taking part into the computation of inter-AS TE-LSPs, by possibly cooperating with intra-AS PCEs or other inter-AS PCEs. Inter-Domain PCE: Inter-Area or Inter-AS PCE 3. Reference Model for PCE-based inter-domain path computation An intra-domain PCE is responsible for path computation within a single domain. An inter-domain PCE is responsible for path computation across multiple domains. An inter-domain PCE is associated with one or more domains that define its scope of visibility. It serves paths computation request for inter-domain paths, from PCCs or other inter-domain PCEs. When it has topology visibility in all domains along the path it can directly compute the inter-domain path. When it doesn't have topology visibility in all domains along the path it needs to collaborate with other inter- domain PCEs so as to compute an end-to-end path. An inter-domain PCE may require the services of one or more intra-domain PCEs within domains of its scope to compute intra-domain segments of an inter- domain path. An inter-domain PCE can be an intermediate-PCE or a terminating-PCE for a given LSP. An intermediate-PCE is associated with transit domains whereas a terminating-PCE is associated with the domain originating or terminating the path computation request. Bitar et al. Inter-domain PCE Framework [Page 3] Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006 In this document, we define an inter-domain PCE is an inter-area or inter-AS PCE and An intra-domain PCE is an intra-AS PCE or intra-area PCE. An intra-AS PCE can be either an intra-area PCE or inter-area PCE. It should be emphasized that the differentiation between these PCE types is functional as they can be implemented and enabled on the same physical device. Depending on the location and use of there different PCE types there are various options for PCE-based inter- domain path computation. An inter-area PCE may consult intra-area PCEs for computing intra- area path segments within areas of its scope. Similarly an inter-AS PCE may consult intra-AS PCEs (i.e. intra/inter area PCE) for computing intra-AS path segments within ASes of its scope. Figure 1 depicts an example for PCEs in an inter-domain application, including both inter-area and inter-AS. In this example computation rely on inter-AS and inter-area PCEs. As discussed above,an intra-AS PCE can be either an inter-area or intra-area PCE, but for the sake of simplicity, in this example we only use inter-area PCE to illustrate the concept which covers both cases. Figure 1 shows the case where there are three ASes, each having an inter-AS PCE. Each inter-AS PCE communicates with inter-AS PCEs of neighboring-AS to compute inter-AS (G)MPLS-TE paths. An inter-AS PCE may also communicate with inter-area PCEs compute a path segment within its AS. An inter-AS PCE can be an external server that is not part of the routing topology or an LSR (e.g., ASBR), known as External PCE, as described in [PCE-ARCH]). <======================inter-AS TE LSP R1-R7============> Inter-AS Inter-AS Inter AS PCC PCE1<------------->PCE2<------------------>PCE3 :: :: :: :: R1---ASBR1====ASBR3-ABR1-R3-ABR2-ASBR5====ASBR7---R5---R7 | | | | | | | | | | | | | | | | R2---ASBR2====ASBR4-ABR4-R4-ABR3-ASBR6====ASBR8---R6---R8 :: :: (Intra-AS Inter-area) PCE4 PCE5 <==AS1=> <=========AS2========> <=====AS3===> Figure 1 Inter-AS and Inter-area PCE Application Scenario As shown from the diagram above, the LSR R1 at the head-end of an LSP or a proxy on its behalf (either being a PCC) sends a path Bitar et al. Inter-domain PCE Framework [Page 4] Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006 computation request to one of its inter-AS PCEs PCE1 upon determining, via configuration or dynamic routing, that the tail-end R7 is an AS-external destination. There could be one or more inter-AS PCEs associated with a given LSR AS. The choice of an inter-AS PCE among many can be based on the corresponding destination AS, configuration, and/or load-balancing criteria. An inter-AS PCE PCE1 in the originating AS sends a path computation request to one or more neighboring AS-PCEs based on the AS through which it learned reachability (maybe the best path) to the destination tail-end and/or based on policy. In our example, PCE1 sends the request to PCE2. Each neighboring inter-AS PCE that receives the request determines its neighbor inter-AS PCE(s) that it progresses the path request to. In determining the inter-AS PCE to which the path request must be sent, an inter-AS PCE may first qualify the path to an ASBR associated with that inter-AS PCE and may exclude paths that do not satisfy the constraints of the LSP e.g., by excluding ASBRs and inter-AS links between the two neighboring ASs when there is not sufficient bandwidth on the paths to these ASBRs or ASes to satisfy the LSP bandwidth constraints). Before an intermediate inter-AS PCE PCE2 decides to send a path computation request to a neighbor inter-AS PCE, it may also qualify the paths to the neighbor AS by consulting its inter-area PCE(s) PCE4 and/or PCE5 in its own AS. When setting up a bi-directional LSP using GMPLS signaling, a PCE may qualify the path in both directions according to the LSP constraints. In an all-PCE enabled environment, the last inter-AS PCE, serving the AS of the LSP tail-end computes one or more path in the AS(es) within its scope potentially by cooperating with inter-area PCEs if any. If the immediate requestor (e.g., the previous inter-AS PCE) is under another SP administrative domain, the inter-AS PCE may not return a path with strict hops (i.e., it may return an ASBR as a strict hop and the LSP tail-end as a loose node). What could be returned in the path computation response is generally controlled by policy configuration. The inter-AS PCE PCE2 may return one or more paths, each of which is composed of a list of one or more ASBRs and/or ASes as loose hops and a cost associated with each path. The returned path(s) must at least include ASBRs connected to the ASes affiliatied with the responding PCE. This process recurses until the inter-AS PCE serving the LSP head-end receives a response to its request(s) from the immediate inter-AS PCE(s) it sent requests to. Every time an inter-AS PCE responds to a requestor it concatenates each path it computes with a path it received from the next immediate PCE, composes a cost for the total path and returns the concatenated path(s) to the previous immediate requestor as per defined in [BRPC]. It should be noted that the path(s) computed by a Bitar et al. Inter-domain PCE Framework [Page 5] nternet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006 PCE will be constrained by the path(s) received from the next inter- AS PCE(s) and any other constraints in the received request. If the original PCC (LSR at the head-end of the LSP or proxy) selects a path out of the received ones and the path is composed of all strict hops, the head-end LSR will use the signaling procedures defined in [ITERD-TESIG] to signal the LSP with an explicit route object (ERO) consisting of these strict hops. There will be no need for computing path segments to loose hops at intermediate nodes. If the path selected by the head-end LSR is composed of strict and loose hops. an intermediate node would expand the path between that node and the next loose hop with strict hops in its own AS. 4.Inter-IGP-Area Operation 4.1. Inter-Area-PCE Discovery A PCC must first discover the inter-area PCEs that serve its area and the domain scope of that PCE. Similarly, an inter-area PCE must discover other inter-area PCEs and their domain scopes. A PCC selects a PCE from a set of discovered PCEs based on the discovered PCE information and the destination of the (G)MPLS-TE LSP. Inter-area PCE discovery is provided by a PCE discovery protocol [Inter-area-PCE- Discovery] or via static configuration on the PCC. In multi-PCE path computation, a PCE can learn with the PCECP request message, in which area a destination is located. This requires for the PCC to know the area in which the destination lies and to include it in the request message. This may rely on configuration on the PCC but may not be flexible. When the PCC does not know in which area the destination lies it will not include this information in the request message, and a PCE will not learn in which area a destination is located if that area is not within its scope. From IGP advertisements, it can only learn which ABR can be used to reach the destination. Thus, it must use that information to determine which PCE is serving the destination area. This requires that an IGP discovery protocol identifies the ABRs that are within its scope. Most often, an inter-AS PCE could be selected to be an ABR that has visibility into the topology and TE database of two or more attached areas. When the PCE is an ABR, the PCE learns the necessary topology information as part of normal IGP operations. 4.2. Inter-area path Computation Bitar et al. Inter-domain PCE Framework [Page 6] Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006 There are various possible modes for PCE-Based inter-area path computation. The computation of an inter-area optimal path can rely on: - a single PCE, that has enough topology visibility and can alone compute an end-to-end optimal path, - multiple PCEs, that have partial topology visibility and collaborate with each other so as to arrive at an end-to-end optimal path. These two modes are referred as to "Single PCE computation" and "Multiple PCE computation with inter-PCE communication" in [PCE- ARCH]. Note that these two modes may co-exist in a given multi-area network. Note that the per-area path computation mode relying on route expansion performed directly by ABRs on the path (which function has composite PCEs), or on external PCEs contacted by the ABRs on the path, consists in fact of a simple concatenation of intra area paths. It actually only implies intra-area path computations and does not allow computing inter-area optimal paths. Hence this mode is not discussed in this document. 4.2.1. Single PCE Computation In this mode the inter-area path computation is directly performed by a single PCE that has enough topology information to compute an end- to-end optimal path. No inter-PCE communication is required in this mode. This mode requires that the PCE have at least the Traffic Engineering Database (TED) of all the crossed areas for a given LSP. The actual distribution of PCEs may vary, i.e., a PCE may have a TE database base from two, three or more IGP areas. If the head-end and tail-end LSRs are located in two peripheral areas, the PCE must have the TED of the source, backbone, and destination areas. In the particular case where the head-end/tail-End LSR is located in the backbone area and the tail-end/head-end LSR is located in a peripheral area, the PCE only needs the TED of the backbone area and the peripheral area to compute the path. Figure 2 below illustrates an example of single PCE inter-area computation. ------ | PCE0 | / ------ \ / | \ / | \ / | \ / | \ ------------------------------------------ | | | | | ABR2 ABR3 | R1 area1 | area0 | area2 R2 | ABR1 ABR4 | | | | | ------------------------------------------ Figure 2: Example of single PCE computation. Bitar et al. Inter-domain PCE Framework [Page 7] Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006 In this multi area network PCE0 has topology visibility in area1, area0 and area2 and can compute and end-to-end path from area 1 to area 2. To setup an inter-area LSP from R1 in area 1 to R2 in area 2, R1 has to directly contact PCE0. Note that this mode may rely on PCEs that have knowledge of topology in all areas. Such a PCE is called an "all-areas" PCE. Particular attention should be given to the potential limitations of this "all-areas" PCE approach, in terms of scalability. Such all-area PCEs may have to maintain a large topology and this raises scalability issues both in terms of memory to maintain the TED and processing to synchronize TED information. Also such all-area PCEs would potentially serve a large number of PCCs, and hence may face a huge path computation request overload during a network event such as link or node failure (that may impact a large number of TE-LSPs on a large number of head-end LSRs). This may significantly delay the TE-LSP recovery, and thus may diminish the benefits of such an approach. 4.2.2. Multiple PCE path computation with inter-PCE communication In this mode the computation of an optimal inter-area TE-LSP path is distributed across multiple PCEs. There is at least one PCE per area, and those PCEs do not have enough topology visibility to compute and inter-area optimal path. PCEs in each area compute path segments in their respective areas and collaborate together to arrive at an end-to-end inter-area optimal path. Such collaboration is carried using inter-PCE communication protocol (PCEP). The actual distribution of PCEs may vary, i.e. a PCE may have TE database from one, two, or more IGP areas, and the important thing is that the collection of topology and TE information maintained by a set of PCEs, collectively, must cover all the IGP areasthat all inter-area LSPs traverse. Figure 2 and 3 below illustrate two examples of multiple PCE inter- area computation ------ ------ ------ | PCE1 |<------>| PCE0 |<---->| PCE2 | ------ ------ ------ | | | | | | -------------------------------------------- | | | | | ABR2 ABR3 | R1 area1 | area0 | area2 R2 | ABR1 ABR4 | | | | | -------------------------------------------- Figure 3: Cooperation between single-area PCEs Bitar et al. Inter-domain PCE Framework [Page 8] Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006 Figure 3 above illustrates a multi-area network with 3 areas. PCE0, PCE1 and PCE2 are PCEs responsible for path computation respectively in area 0, 1 and 2. These PCEs have topology visibility limited to one area and are called single-area PCEs. To setup an inter-area LSP from R1 in area 1 to R2 in area 2, R1 has to contact PCE1. PCE1 then collaborates with PCE0, and PCE0 with PCE2 so as to compute an end-to-end shortest constrained path. ------ ------ | PCE1 | <----> | PCE2 | ------ ------ / \ / \ / \ / \ -------------------------------------------- | | | | | ABR2 ABR3 | R1 area1 | area0 | area2 R2 | ABR1 ABR4 | | | | | -------------------------------------------- Figure 4: Cooperation between multi-area PCEs Figure 4 above illustrates a multi-area network with 3 areas. PCE1, and PCE2 are PCEs responsible for path computation respectively in area 0+1 and in area 0+2. This means that PCE1 and PCE2 have topology visibility in area0+area1 and area0+area2, respectively. To setup an inter-area LSP from R1 in area 1 to R2 in area 2, R1 has to contact PCE1. PCE1 then collaborates with PCE to compute an end- to-end shortest constrained path. 4.3. PCE Inter-area TED Bitar et al. Inter-domain PCE Framework [Page 10] Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006 The topology visibility of an inter-area PCE depends on the path computation mode: - A mono-area-seeing PCE has topology visibility within a single area - A multi-area-seeing PCE has topology visibility into two or more areas. In particular, an all-area-seeing PCE has topology visibility within the entire AS. There are various means for a PCE to discover the TED of a given area. In order to ensure path computation accuracy, PCE TEDs should be as far as possible synchronized with the network TED. A mono-area-seeing PCE would have to get the TED of a single area. If the PCE is an LSR, it directly gets the TED from the IGP. If the PCE is a server it may discover the TED by running the IGP and maintaining an IGP adjacency with one or more LSRs of the area, called "seed LSRs". Note that in this case the link between the PCE and the see-LSR must not be part of the LSDB. Note that the PCE and seed LSR may not be directly connected, in which case the IGP adjacency may be built on top of a tunnel connecting the two elements (e.g. a GRE tunnel). A multi-area-seeing PCE would have to get the TED of multiple areas. If the PCE is an ABR, it directly gets from the IGP the TED of the backbone area and its attached peripheral areas. If the PCE is a server, it may run the IGP and maintain IGP adjacencies with seed LSRs Located in each area of its scope. In this case the use of ABRs as seed LSR would reduce the amount of adjacencies required. Note that this may raise scalability issues as the number of areas within the PCE scope increases. In particular the all-area-seeing PCE approach may face some limitations regarding the amount of information to be stored, the processing required to keep the TED synchronized, and to maintain IGP adjacencies with all seed LSRs. An inter-area PCE may also discover the TED by other means (SNMP TE- Link MIB, proprietary interface…) 4.4.Inter-Area PCECP PCECP is used to communicate path computation requests and responses between PCC and inter-area PCE, between inter-area PCEs and potentially between inter-area PCEs and intra-area PCEs. 4.5. Optimality In a single IGP domain, it is expected that the link costs will be assigned with the same semantics (e.g., delay). In that case, the costs of links in different areas could be added without the need for any normalization. It will be guaranteed that the computed path for Bitar et al. Inter-domain PCE Framework [Page 10] Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006 an LSP will be the shortest path that satisfies the TE constraints of the LSP. In order to illustrate the optimality of the resulting path, consider the case of path computation using per domain path computation illustrated in Figure 5 as show below: <======inter-area TE LSP t0======> (PCC) (PCE) (PCE) R1-------ABR1---------ABR3-------R2 \ | / | / \ | ------- | / \ | / | / -----ABR2---------ABR4----- <-area1-><--area0----><--area2-> Figure 5: inter-area path computation A TE-LSP is being placed with head-end R1 in area1 and tail-end R2 in area2. R1 has summary reachability information to R2 advertised by ABR1 with cost 2 and by ABR2 with cost 2. In per-domain path computation, R1 computes the cost to get to R2 via ABR1 and it finds to be 3 which is a tie with that of going through ABR2, but as a tie- breaker it selects ABR1. In addition, the local path segment R1-ABR1 satisfies the LSP TE constraints. R1 signals the TE-LSP with ABR1 as a strict hop and R2 as a loose hop. When the RSVP-TE path message gets to ABR1, ABR1 performs another lookup to determine the path segment within the backbone. While ABR1-ABR3 results in the shortest path, that path does not satisfy the TE constraints. ABR1 is forced t0 select path ABR1-ABR2-ABR3 with cost 2. ABR3 in turns performs its per domain path computation and selects the direct link to R2 on the path. The resulting path is R1-ABR1-ABR2-ABR3-R2 with cost 4. Using the PCE-based approach, and assuming ABR1 and ABR3 are PCEs for area1-area0 and area0-area2 respectively, R1 sends a path computation request to ABR1 as a PCE. ABR1 determines the PCE it needs to contact to compute a path to the destination is ABR3. ABR1 sends a path computation request to ABR3. ABR3 computes a path to the destination R2 and returns ABR1-ABR2-ABR4-R2 and ABR2-ABR4-R2 as possible paths with costs of 3 and 2, respectively. ABR1 then computes a path within area1 with strict hops being ABR1 and ABR2. The first path when R1- ABR1 when concatenated with ABR1-ABR2-ABR3-R2 has a cost of 4 and the second path R1-ABR2 when concatenated with path ABR2-ABR4-R2 has a cost of 3. Thus, ABR1 selects path R1-ABR2-ABR4-R2 and returns to R1. Contrary to the per-domaon based approach, the PCE-based approach results in the optimum path computation as the full topology and link resources are known to the collective set of PCEs that collaborate to perform the path computation while the per domain path computation is blinded to global optimization by local optimization within an area. Bitar et al. Inter-domain PCE Framework [Page 11] Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006 4.6. Reoptimization Note that here we focus on end-to-end inter-area path reoptimization and not on per-area path reoptimization. Per-area path reoptimization does not allow global reoptimization of an inter-area TE-LSP. When there are resource changes within any area on the path of an already established LSP, a more optimal end-to-end path may have become available. An end-to-end path reoptimization is under control of the head-end LSR. Once a head-end LSR desire to perform an end-to-end reoptimization its sends a request message to its PCE, indicating that this is a request for a reoptimization. The request message may include the previously computed path so as to avoid double bandwidth accounting. Note that an head-end LSR may not be aware of a change in another area. A reoptimization may be triggered: -Via management action, in reaction to a network event. -Periodically, on a timer driven basis, the head-end LSR send a requests for re-optimization to the inter-area PCE, and if the returned path is distinct from the current path may decide to reroute the LSP in a make-before-break manner. This decision is driven by local policies. -Dynamically, on an event driven basis. A head-end LSR may be aware of a change in another area thanks to IGP advertisements (IGP metric change) or thanks to signaling notification [LOOSE- REOPT]. When a change is detected the head-end LSR sends a request for re-optimization to its inter-area PCE. If re-optimization is triggered dynamically by network events, a large number of LSP head-ends may simultaneously attempt to initiate path re-optimization for many LSPs, potentially overloading PCEs, specifically, inter-area PCEs. Similarly, if path re-optimization is attempted periodically and if PCC timers are synchronized PCEs could become overloaded. Therefore, as discussed in [PCE-COM-REQ] PCCs that initiate requests for path computation should implement mechanisms that pace path re- optimization requests and avoid network activity synchronization. 4.7. Diverse path computation To compute two diverse paths, a PCC or transit inter-area PCE must include in the PCECP request message multiple correlated requests and indicate the desired level of intra-area diversity (link, node, SRLG) on a per-area basis as well as the level of inter-area diversity (ABR disjointness). Bitar et al. Inter-domain PCE Framework [Page 12] Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006 4.8. Considerations on PCE location As explained in [PCE-ARCH] a PCE can be a LSR or a network server. But note that in the inter-area context, it may be quite efficient for the ABRs to act as PCEs. Indeed, ABRs have topology information of the backbone area and at least one peripheral area. An inter-area TE-LSP optimal path computation could rely on a single ABR, if the path crosses only two IGP areas, or on collaboration between two ABRs in case the path crosses three IGP areas. For instance, in figure 4 above, ABR1 or ABR2 can play PCE1 role, and similarly ABR3 or ABR4 can play PCE2 role. Note that such ABRs are not necessarily transit LSRs on the computed inter-area TE LSP. With such PCE distribution on ABRs, the PCECP would run directly between LSRs. Note that if N peripheral areas are connected to one backbone area, with at least N ABRs, inter-area path computation would potentially require a full mesh of N^2 PCE-PCE communications between ABRs. 5. Inter-AS Operation 5.1. PCE-based Inter-AS Routing Inter-AS PCE-based path computation does not impose any additional requirements on inter-AS routing. Particularly, there are no inter-AS TE information exchanged using BGP. Thus, the TE information of a given AS is confined to that AS. Path computation procedures for inter-AS paths rely on intra-AS (intra or inter-area) path computation as explained in the previous section to compute an intra-AS path computation with an extended AS TED that includesinter-AS TE links. An inter-AS PCE could be a LSR or a standalone server. In either case, an inter-AS PCE must have reachability information to the LSP tail-end and head-end. At minimum, this reachability information must include the AS in which the tail-end and head-end of the LSP reside and it may also have the AS path to the LSP tail-end. In addition, it needs to have knowledge of the ASBRs that interconnect the ASes within its scope to each other and to other ASes outside of its scope and the various attributes associated with the routes advertised by these ASBRs. One simple way to obtain this information is to have an iBGP session with each ASBR in the ASes it is serving. Alternatively, the PCE itself could be an ASBR with BGP peering relationship with other ASes. One or more of these ASBRs could be within the scope of the PCE. Using this information, an inter-AS PCE can determine whether it can itself fully handle the path computation request. Otherwise, the inter-AS PCE determines the next inter-AS PCE it needs to send a request to in order to complete Bitar et al. Inter-domain PCE Framework [Page 13] Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006 the path computation to the tail-end. The inter-AS PCE may have to interact with intra-area PCEs and potentially inter-area PCEs in the ASes within its scope to compute a path segment between the head-end and tail-end of the LSP. The separation between inter-AS (inter- provider and intra-provider), inter-area, and intra-area PCEs is a functional separation. A single physical element may have all the functions and therefore the interaction will be platform-internal or there may be no interaction at all, if the inter-AS PCE process includes intra-area CSPF for example. Thus, a PCE LSR or PCE server can implement all PCE functions and acquire topological information, including the TED, for ASes within its scope. For an inter-AS PCE to compute multiple paths, especially between two ASes for instance that peer at two or more ASBRs, it must be able to maintain all the BGP advertisements from each ASBR and use this raw information to compute a path. The exact procedure(s) that govern the interaction between an inter-AS PCE and intra/inter-area PCEs in the ASes within its scope for the purpose of path computation should be well defined to avoid interoperability issues. Optimality measures are discussed in the next section. The procedures could depend on who triggers the initial path computation request and could vary between the AS of the LSP head-end, a transit AS and the AS of the LSP tail-end. 5.2. Inter-AS PCE Location TBC (may be merged with section 5.1) 5.3. Inter-AS-PCE Discovery Inter-AS PCE Discovery can be done via static configuration or dynamically. PCE discovery allows one inter-AS PCE to discover capabilities and scope (which ASes they operate in) of other inter- AS PCEs. During path computation, one inter-AS PCE selects which of the discovered PCEs it needs to send requests to based on reachability information, which AS it learns that information, and which PCE covers that AS. 5.4. Inter-AS Path Computation TCB 5.5. Path Diversity The head of the LSP or a proxy (either being a PCC) on its behalf may desire to setup two or more LSPs with diversified paths between the same or different pairs of tail-end and head-end. A diversified path avoids the sharing of nodes and links along the path between the two LSPs and optionally seeks to minimize the number of shared ASes across the two paths. The level of diversity should be specified by the PCC, one may want to request for link/node/SRLG diversity on a Bitar et al. Inter-domain PCE Framework [Page 14] Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006 per AS basis, and also ASBR diversity and AS diversity, etc.. The head-end of an LSP or a proxy (PCC) on its behalf may desire to setup a hot-standby path for an LSP that is diversified from the primary path. 5.6. Inter-AS (G)MPLS-TE Operations and Interoperability Operations in an all-PCE-enabled environment are described in [PCE- ARCH] and, in the case of inter-AS PCE-based path computation, in section 3. There are cases, as stated in section 3, where the environment may not be an all-PCE environment. Figure 6 depicts such a case where AS1 does not have PCEs, whereas AS2 and AS3 do. Thus, when a TE-LSP is being signaled from an originating node (R1) in AS1 and terminating in AS3, R1 uses mechanisms described in [INTERD-TE-PDPC] and [INTERD-TESIG] to compute and signal a path to the AS1 ASBR connecting to AS2 (ASBR1). ASBR1 will send a path message to the connected ASBR n AS2 (ASBR3). ASBR3 makes a request to its serving inter-AS PCE_AS2 for a path that satisfies the LSP constraints to the destination. PCE_AS2 determines that the destination is reachable via AS3 and subsequently sends a path computation request to PCE_AS3 (the serving inter-AS PCE for AS3 which serves connection setup requests between AS2 and AS3). PCE_AS3 computes a path within its domain and returns to PCE_AS2 which in turns computes a path from ASBR3 to the ASBR connected to the returned path from PCE_AS3 and returns the concatenated path to ASBR3. ASBR3 can then setup the TE-LSP along this path. Non PCE PCE_AS2 PCE_AS3 Inter-AS Path Inter-AS Path Inter-AS Path Computation Computation Scope: AS2/AS3 Scope: AS3/AS2 <------> <--------------> <-----------> Inter-AS Inter AS PCE<------------------>PCE :: :: R1---ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7 | | | | | | | | | | | | R2---ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8 :: Intra-AS PCE <===AS1=> <=====AS2=====> <======AS3==> Figure 6.Non-PCE and PCE path computation scopes Bitar et al. Inter-domain PCE Framework [Page 15] Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006 5.7. Optimality TBC 5.8. Reoptimization When there are resource changes within any AS on the path of an already-established LSP, a more optimal path may have become available. In this case, the head-end of an LSP in another AS may not be able to detect these changes unless they affect the BGP announcements that include reachability to the LSP-tail end. Triggering path re-optimization for an inter-AS LSP can be done via a management action in reaction to the network event or via a periodic re-optimization attempt by the LSP head-end. Alternatively, this trigger can be dynamic in reaction to network events. If solutions allow relaying a re-optimization trigger via PCEs, and specifically inter-AS PCEs, using the PCC/PCE communication protocol messaging, such solutions must be designed with scalability in mind as multiple LSPs could become eligible for re-optimization at the same time. If re-optimization is triggered dynamically by network events, a large number of LSP head-ends may simultaneously attempt to initiate path re-optimization for many LSPs, potentially overloading PCCs and PCEs, specifically, inter-AS PCEs. Similarly, if path re-optimization is attempted periodically at the head-end of an LSP or a proxy to the LSP head-end that launches path computation requests on its behalf (i.e., a PCC), PCCs and PCEs could become overloaded. Therefore, PCCs that initiate requests for path computation should implement mechanisms that pace path re- optimization requests and avoid network activity synchronization. This should be a generic requirement on PCC behavior. For instance, when periodic re-optimization is used for re-optimization attempt, the number of LSPs that could be re-optimized in a given period should be configurable. In addition, the re-optimization period itself should be configurable. A re-optimization request to a PCE must be identified as such. Policies on the PCE must be configurable to allow or prevent re-optimization to/from certain ASes, or based upon {class type, preemption} in the case of DS-TE, where a policy exists, to give priority to certain TE LSPs when re- optimization is identified. Re-optimization should be configurable to be enabled/disabled on a PCC basis, PCE-basis, and per-LSP. 6. Security Considerations TBC Bitar et al. Inter-domain PCE Framework [Page 15] Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006 7. Author’s Addresses Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 Email: nabil.bitar@verizon.com Jean-Louis Le Roux (Editor) France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: jeanlouis.leroux@francetelecom.com Raymond Zhang BT INFONET Services Corporation 2160 E. Grand Ave. El Segundo, CA 90245 USA Email: Raymond_zhang@bt.infonet.com 8.Normative References [PCE-ARCH] Farrel, Vasseur & Ash, “Path Computation Element (PCE) Architecture”, draft-ietf-pce-architecture-02.txt, March 2006 (Work in Progress) [INTERD-TE-PDPC] Vasseur, Ayyangar and Zhang, “A Per-domain path computation method for computing Inter-domain Traffic Engineering (TE) Label Switched Path (LSP)”, draft-ietf-ccamp-inter-domain-pd- path-comp-00.txt , October 2005, (Work in Progress) [BRPC], Vasseur, etc., “A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Paths, draft-vasseur-pce-brpc-01.txt, December 2006, (work in progress) 9. Informative References [INTERD-TESIG] Ayyangar and Vasseur, “Inter domain GMPLS Traffic Engineering - RSVP-TE extensions”, draft-ietf-ccamp-inter-domain- rsvp-te-02.txt, April 2006 (Work in Progress) 10. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Bitar et al. Inter-domain PCE Framework [Page 17] Internet Draft draft-nabil-pce-inter-domain-frwk-00.txt June 2006 This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 11. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.