Network Working Group Nabil Bitar (Editor) Internet Draft Verizon Raymond Zhang (Editor) BT Infornet Kenji Kumaki (Editor) KDDI Corporation Category: Informational Expires: April 2006 October 2005 Inter-AS PCE Requirements draft-bitar-zhang-interas-PCE-req-01.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. Bitar et al. [Page 1] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 Abstract This document discusses requirements for the support of the Path Computation Element (PCE) in inter-AS applications. Its main objective is to present a set of requirements which would result in guidelines for the definition, selection and specification development for any technical solution(s) meeting these requirements. 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. Table of Contents 1. Introduction.....................................................3 2. Definitions and Requirements Statement...........................4 2.1. Definitions....................................................4 2.2. Objectives and Requirements of Inter-AS Traffic Engineering using PCE...........................................................5 3. Reference Model..................................................5 4. Example Application Scenarios....................................8 4.1. Inter-AS Path Computation for Virtual PoP (VPOP) or Sub- regional Networks...................................................8 4.2. Inter-AS Path Computation over a GMPLS Transport Core.........10 5. Detailed PCE Requirements for Inter-AS (G)MPLS-TE...............10 5.1. Requirements within one SP Administrative Domain..............11 5.1.1. Inter-AS (G)MPLS-TE Operations and Interoperability.........11 5.1.2. PCC/PCE-PCE Communication Protocol Requirements.............11 5.1.2.1. Path computation requests: PCC/PCE-PCE PCECP..............13 5.1.2.2. PCE responses.............................................14 5.1.3. PCE Discovery...............................................15 5.1.3.1. Static configuration......................................15 5.1.3.2. Dynamic Discovery.........................................16 5.1.4. PCE: Path Computation.......................................17 5.1.4.1. Routing...................................................17 5.1.4.2. Optimality................................................18 5.1.4.3. Path Re-optimization......................................18 5.1.4.4. Support of diversely routed inter-AS TE LSP...............19 5.1.5. Hierarchical MPLS...........................................19 5.1.6. Scalability and Performance Requirements....................19 5.1.7. Complexity and Risks........................................20 5.1.8. Management, Aliveness Detection and Recovery Requirements...20 5.2. Requirements Across SP Administrative Domains.................21 5.2.1. Confidentiality.............................................21 5.2.2. Policy Controls.............................................22 5.2.2.1. Inter-AS PCE Peering Policy Controls......................22 5.2.2.2. Inter-AS PCE Reinterpretation Polices.....................23 Bitar et al. [Page 2] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 6. Security Considerations.........................................24 7. Author's Addresses..............................................25 8. Normative References............................................25 9. Informative References..........................................26 10. Full Copyright Statement.......................................26 11. Intellectual Property..........................................27 1. Introduction MPLS Inter-AS traffic engineering requirements [INTERAS-TE-REQ] defined the scenarios motivating the deployment of inter-AS MPLS traffic engineering. [INTERAS-TE-REQ] also specified the requirements for inter-AS MPLS traffic engineering when the ASes are under one Service Provider (SP) administration or the administration of different SPs. Today there are three signaling options in setting up an inter-AS TE LSP: 1) contiguous TE LSP as documented in [INTERD-TESIG]; 2) Stitched inter-AS TE LSP discussed in [LSP-STITCHING]; 3) nested TE LSP as in [LSP-HIERARCHY]. In addition, [INTERD-TE-PDPC] defines mechanisms for inter-domain path computation using network elements along the signaling and data paths. The mechanisms in [INTERD-TE- PDPC] do not provide the capability to guarantee an optimum TE path across multiple ASes. An G)MPLS-TE optimum path for an LSP is one that has the smallest cost, according to a normalized TE metric (based upon a TE-metric or IGP metric adopted in each transit AS), among all possible paths that satisfy the LSP TE constraints. This document extends on the requirements defined in [INTERAS-TE- REQ] as applied to the PCE [PCE-ARCH], providing an approach for a more optimum inter-AS TE path computation and potentially minimizing signaling crankbacks. The requirements for a PCE have risen from SP needs to compute a more optimum path than that can be achieved by those provided in [INTERD-TE-PDPC] and the capability to separate the path computation elements from the forwarding elements. Generic requirements for the PCE discovery protocol (PCEDP) and PCC/PCE-PCE communication protocol (PCECP) are discussed in [PCEDP- REQ] and [PCECP-REQ] respectively. Complementary to these already defined generic requirements, this document provides a set of requirements that are specific for inter-AS path computation using a PCE-based approach. Some of these requirements will become generic requirements if they apply to other PCE applications. Section 2 of this document states some definitions. Section 3 defines a reference model, while section 4 describes use cases of inter-AS path computation using a PCE-based approach. Section 5 states inter-AS PCE requirements when the ASes are under a single SP administrative domain. Specifically, the requirements on PCECP, Bitar et al. [Page 3] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 PCEDP, path optimization and re-optimization, routing, hierarchical MPLS, scalability, backward compatibility and management for a single SP inter-AS PCE applications are described. Section 5 also discusses additional requirements for inter-AS multi-SP PCE applications related to confidentiality and policies. Section 6 discusses security issues. 2. Definitions and Requirements Statement 2.1. Definitions The following provides a list of abbreviations or acronyms specifically pertaining to this document: SP: Service Providers including regional or global providers SP Administrative Domain: a single SP administration over a network or networks that may consist of one AS or multiple ASes. IP/MPLS networks: SP's network where MPLS switching capabilities and signaling controls are activated in addition to IP routing protocols. Intra-AS TE: A generic definition for traffic engineering mechanisms operating over IP-only and/ or IP/(GMPLS network within an AS. Inter-AS TE: A generic definition for traffic engineering mechanisms operating over IP-only and/or IP/(G)MPLS network across one or multiple ASes. Since this document only addresses IP/(G)MPLS networks, any reference to Inter-AS TE in this document refers only to IP/(G)MPLS networks and is not intended to address IP-only TE requirements. TE LSP: MPLS Traffic Engineering Label Switched Path. Intra-AS MPLS-TE: An MPLS Traffic Engineering mechanism where its Label Switched Path (LSP), Head-end Label Switching Router (LSR), and Tail-end LSR reside in the same AS for traffic engineering purposes. Inter-AS MPLS-TE: An MPLS-Traffic Engineering mechanism where its TE LSPs, Head-end LSR and Tail-end LSR do not reside within the same AS ASBR Routers: Border routers used to connect to another AS of a different or the same Service Provider via one or more links between the ASes. Inter-AS TE Path: An TE path traversing multiple ASes and ASBRs, e.g. AS1-ASBR1-inter-AS link(s)-ASBR2-AS2-ASBRn-ASn. Bitar et al. [Page 4] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 Inter-AS TE Path Segment: A portion of the Inter-AS TE path. Inter-AS DS-TE: Diffserv-aware Inter-AS TE. SRLG: A set of links may constitute a 'shared risk link group' (SRLG) if they share a resource whose failure may affect all links in the set as defined in [GMPLS-ROUT]. PCE: Path computation element PCC: Path computation client PCECP: PCE communication protocol PCEDP: PCE Discovery Protocol Intra-AS PCE: A PCE responsible for computing (G)MPLS-TE paths traversing a single AS. Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS- TE and/or intra-AS(G)MPLS-TE paths, by possibly cooperating with intra-AS PCEs, across one or more AS(es) 2.2. Objectives and Requirements of Inter-AS Traffic Engineering using PCE All applications and associated requirements cited in sections 3.2 and 4 in [INTERAS-TE-REQ] for inter-AS traffic engineering hold for inter-AS PCE. The following key areas must be addressed in inter-AS PCE solutions: 1) Inter-AS bandwidth guarantees; 2)Inter-AS Resource Optimization, 3) Fast Recovery across ASes, i.e. Recovery in presence of Inter-AS Link/SRLG and ASBR Node failures, and (4) path optimality. The detailed requirements for PCE-based Inter-AS (G)MPLS-TE path computation are discussed in section 5. 3. Reference Model Figure 1 depicts the reference model for PCEs in an inter-AS application. In this document, we define two types of PCE functions: inter-AS PCEs and intra-AS PCEs. 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 ASes to compute inter-AS (G)MPLS-TE paths. An inter-AS PCE may also communicate with intra-AS PCEs within the scope of its AS to 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), know as composite PCE, as described in [PCE-ARCH]). Bitar et al. [Page 5] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 Inter-AS Inter-AS Inter AS PCE1<---------->PCE2<--------------> PCE3 :: :: :: R1---ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7 | | | | | | | | | | | | R2---ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8 :: Intra-AS PCE <==AS1=> <====AS2======> <=====AS3===> Figure 1 Inter and Intra-AS PCE Reference Model In general, an inter-AS PCE is associated with one ore more ASes that define its scope. It receives path computation requests for (G)MPLS-TE LSPs from PCCs or other inter-AS PCEs and responds to these requests. An intra-AS PCE (e.g., inter-area PCE) is one responsible for path computation within a single AS. It should be emphasized that the differentiation between these two PCE types is functional as both can be implemented and enabled on the same physical device, but scalability requirements and/or security considerations may require their separation. An inter-AS PCE can be an intermediate-PCE or a terminating-PCE for a given LSP. An intermediate-PCE is associated with transit ASes whereas a terminating-PCE is associated with the AS originating or terminating the path computation request. If the head-end and tail- end of an LSP are in ASes within the scope of a single inter-AS PCE, the full path computation can be solely done by that inter-AS PCE, possibly cooperating with other intra-AS PCEs if it does not have the full topological and TE knowledge of the ASs within its scope. Otherwise, multiple inter-AS PCEs need to cooperate to compute the LSP path as described in [PCE-ARCH]. The LSR at the head-end of an LSP or a proxy on its behalf (either being a PCC) sends a path computation request to one of its inter- AS PCEs upon determining, via configuration or dynamic routing, that the tail-end 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 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. Each neighboring inter-AS PCE that receives the request determines its neighbor inter-AS PCE 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 Bitar et al. [Page 6] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 to these ASBRs or ASes to sastisfy the LSP bandwidth constraints). Before an inter-AS PCE 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 intra-AS PCE(s). 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 by cooperating with intra-AS PCEs. 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., LSP tail-end). What could be returned in the path computation response is generally controlled by policy configuration. The inter-AS PCE 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 recourses 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. It should be noted that the path(s) computed by a 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, there needs to be a way for an intermediate node to complete the path between that node and the next loose hop with strict hops. How this is most efficiently done SHOULD be subject for further study. Some possible mechanisms include: (1) A node that needs to acquire a path of strict hops to reach a loose hop specified in the ERO, requests an inter-AS PCE or intra- AS PCE, depending on the situation, to compute that path. In this case, the original path computation triggered by the head-end LSR would have computed that path and the path gets recomputed again during the (G)MPLS-TE signaling phase. (2) In order to avoid the path-segment re-computation in option (1), an inter-AS PCE involved in the LSP path computation may store the LSP path-segment it computes for a limited time. Signaling may carry a PCE identifier (in case there is more than one PCE serving Bitar et al. [Page 7] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 the ASBR), and another path-identifier to enable an ASBR to retrieve the path segment from the PCE. The path-identifier can be an LSP identifier that when coupled with the requesting ASBR and the next hop in the ERO can uniquely identify the path-segment. This approach may require a signaling extension. When a path is retrieved, all other path(s) associated with that LSP at the PCE could be deleted immediately. In order to avoid permanent storage of path-segment(s) at the PCE, there could be a timer associated with each path-segment or with the LSP at the PCE that causes deletion of these path(s) when the timer expires. (3) Alternatively, the inter-AS PCE may communicate to an ASBR the path segment(s) rooted at that ASBR along with the associated LSP identifier. When the ASBR receives a (G)MPLS-TE path message, it performs a lookup based on the LSP identifier to identify the path segment between itself and the next hop in the received ERO. Unused path segments at the ASBR could be deleted immediately. The path- segment(s) associated with a given LSP could have a timer associated with them so that when the ASBR does not get a path message for that LSP within a timeout interval, the timer expires and all the associated path segments are deleted. Please note that this ASBR may or may the inter-AS PCE itself, in other words, a LSR selected as a PCE does not necessarily have to be on the TE LSP Path it computes. Other mechanisms may also exist. Each of these mechanisms will have associated tradeoffs and may drive requirements on PCECP and/or signaling. Those types of requirements driven by specific solutions are not defined in this document. In certain operating environments, PCEs may not be available end to end. Added to that, inter-AS traffic engineering capabilities may not be available end-end. This document addresses requirements to deal with these situations. 4. Example Application Scenarios 4.1. Inter-AS Path Computation for Virtual PoP (VPOP) or Sub-regional Networks A number of application scenarios are discussed in section 4 of [INTERAS-TE-REQ] where computing an inter-AS TE LSP path could rely on per-domain path computation using procedures documented in [INTERD-TE-PDPC]. However, as noted above, a per-domain computing method does not always yield optimum paths. In this section, we present a similar inter-AS TE application scenario using PCEs with inter-AS scope to compute optimum paths across AS boundaries. Section 4.1.1 and section 4.2.2 of [INTERAS-TE-REQ] have presented two cases where a global service provider (SP1) would like to extend its reach into a region using a regional network (SP2) as MPLS transport. SP1 in these cases would either co-locate its Bitar et al. [Page 8] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 regional POP as a virtual PoP within SP2's POP or link its own sub- regional network back to SP1's main backbone over SP2's network. This is further illustrated in the diagram of Figure 2: <=Inter-AS MPLS TE Tunnel T1(R13,R15)=> R16(PCE) | R11(PCC)-R13(PCC)<===>R21-R23-R26(PCE)<===>R15(PCC)-R19-R112 \ /| \ |\ / | \ / | \ / | \ / | \ | \ / | \ / | \_R110 | \/ | \ | \ / | \ | \/ | /\ | \ | R24(PCE)| / \ | _ R111 | / \ | \ | / \R25 | / \ | / \ | / \| || / \ | / \ | / \ | R12(PCC)-R14(PCC)<===>R22----R27(PCE)<===>R17(PCC)----R113(PCC) | R18(PCE) <=Inter-AS MPLS TE Tunnel T2(R14,R17)=> <=============Inter-ASS TE Tunnel T3(R11,R113)============> +=SP1 VPOP/sub=+ +===SP2 As2===+ +=SP1 backbone AS1=+ network AS1 Figure 2: SP1 extended reach linking vPOP or Sub-regional network over SP2 MPLS Transport In the above example diagram, ASBR R13 and R14 as PCCs, dynamically or statically discover their corresponding PCE R16 and R18 which maintain meshed peering with AS2 PCE R26 and R27, respectively. They then send PCC/PCE path requests to their own primary PCEs (R16 or R18) for two optimum yet diversified inter-AS paths for T1(R13,R15) and T2(R14,R17) across AS2. In addition, R11 would require to build a separate inter-TE tunnel to R113 directly to support a customer voice trunk, for example. With per-domain path computation, the three tunnels would be built with paths as shown below assuming all links with metric value of 1 and inter-AS links between ASes with the same maximum reservable bandwidth: - T1's path: (R21,R15) expanding at R21 to have the path R13-R21- R23-R26-R15; - T2's path: (R22,R17) expanding at R22 to have the path R14-R22- R27-R17; - T3's path: (R21,R113) expanding at R21 to have the path R11-R13- R21-R23-R26-R15-R17-R113 For T1 and T2, the requirement for diversifications is paramount where R26 and R27 will need to maintain both synchronized states of both T1 and T2 in order to compute two diverse routes between these two inter-AS TE LSPs where their HEAD-ENDs and TAIL-ENDs are terminated on the same pair of ASes (exactly the same ASN in this case). Bitar et al. [Page 9] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 For T3, a more optimum path should be R11-R14-R22-R27-R17-R114 which can be obtained through AS1 PCEs (R16 or R17) where R22 and R17 are selected as better exits for neighbor ASes. In this environment, PCE R24 in AS2 is only for intra-AS TE path computation while R26 and R27 are intra-AS PCEs as well as inter-AS PCEs for AS1 among others. R16 and R17 are dedicated routers running PCE process for AS2. Please note that we could also configure R13 and R14 as PCEs as well with direct peering to R26 and R27. In this case, the ASBR routers function as the PCE, PCC and the inter-AS tunnel-head end or tail-end at the same time. 4.2. Inter-AS Path Computation over a GMPLS Transport Core This section illustrates a simplified case where inter-AS scoped PCEs are used for path computations across a GMPLS transport core. (PCC) (PCC) R1--ASBR1(PCE)<==>ASBR2(PCE)-GMPLS-ASBR3(PCE)<==>ASBR4(PCE)--R2 MPLS(PSC) GMPLS(PSC) GMPLS(PSC) MPLS(PSC) +===SP1 AS1===+ +=======SP2 As2=============+ +===SP3 AS3===+ Figure 3 Inter-AS TE LSP over a GMPLS Transport Core In Figure 3, R1, a PCC sends an MPLS-TE based request message to its own PCE ASBR1 for an inter-As TE LSP between R1 and R2. ASBR1 in turns requests a path computation from its downstream peering PCE ASBR2 for this path to AS3 via AS2. This would require ASBR2 to have the ability to receive MPLS-TE based request messages and reinterpret the portion corresponding to GMPLS specific attributes (if any) for carrying out path computations. In this application scenario, AS2 is a pure GMPLS core. It is worth noting that AS2 could have outer MPLS edge where the inter-AS TE LSPs may get aggregated onto the GMPLS TE LSP on the core GMPLS PSC. 5. Detailed PCE Requirements for Inter-AS (G)MPLS-TE This section discusses detailed requirements in two principal areas for inter-AS (G)MPLS-TE using a PCE-based approach: 1) requirements for inter-AS (G)MPLS-TE in the same SP administrative domain (i.e., intra-provider) and 2) requirements for inter-AS (G)MPLS-TE/ across different SP administrative domains (i.e., inter-provider). Bitar et al. [Page 10] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 .5.1. Requirements within one SP Administrative Domain This section presents detailed PCE requirements for inter-AS (G)MPLS-TE within the same SP administrative domain. It should be noted that ASes in a single SP administrative domain can have various restrictions and policies among the ASes, as in the inter- provider case. The additional PCE requirements for the inter- provider case are documented in section 5.2. 5.1.1. Inter-AS (G)MPLS-TE Operations and Interoperability The PCE solution for inter-AS applications SHOULD be consistent with the requirements discussed in [TE-REQ] and [INTERAS-TE-REQ]. The derived solution MUST be such that it will interoperate seamlessly with current intra-area and inter-domain (inter-area and inter-AS)(G)MPLS-TE mechanisms. The inter-AS PCE-based solutions MUST interoperate with other mechanisms for path computation to ensure that a path for an LSP with TE constraints can be set up across ASes with and without PCE capabilities. The proposed solution SHOULD allow the setup of an inter-AS TE-LSP by provisioning the TE LSP at the head-end and using (G)MPLS-TE signaling to signal the LSP to the tail-end residing in another AS traversing, without any further provisioning requirement, intermediate points along the transit path. 5.1.2. PCC/PCE-PCE Communication Protocol Requirements 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 4 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 in AS2 (ASBR3). ASBR3 can make a request to an inter-AS PCE for a path that satisfies the LSP Constraints to the destination. In this case, Bitar et al. [Page 11] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 Non PCE PCE PCE Inter-AS Path Inter-AS Path Inter-AS Path Computaion Computation Computation Scope 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 4. Non-PCE and PCE path computation scopes This diagram illustrates an inter-AS (G)MPLS-TE environment composed of ASs with PCE capability and ASes without PCE capability. Specifically, AS1 has no PCEs while AS2 and AS3 have inter-AS and intra-AS PCEs. ASBR3 will be a PCC to the inter-AS PCE .. serving AS2. Requirements specific to requests or responses are discussed in the next subsections. Following are additional generic requirements to those described in [PCECP-REQ] for PCC/PCE-PCE communication. Some of these requirements apply to the process handling PCC/PCE-PCE communication and not the protocol itself: - An inter-AS PCE must be able to locally prioritize messages on an AS basis in addition to message-level priority. - An inter-AS PCE must be able to change the message priority when sending a path computation request from the priority it received for the same LSP. A notification message should be sent to the requestor indicating that change. Such notification must be suppressed by configuration action on a neighboring inter-AS PCE basis. - An inter-AS PCE must be able to perform translation on class of service identifiers carried in a request/response for a DS-TE packet LSP when the two ASes attempting to set an LSP or LSP segment between them use different class type identifier values. Such a situation may rrise when ASes become part of one service provider domain as a result of mergers and acquisitions. - A PCE must be able to protect itself against DOS attacks initiated by malicious (could be pretender) PCEs/PCCs who attempt to initiate these attacks via PCE communication protocol messages. Bitar et al. [Page 12] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 The aversion of such attacks could also be achieved via a network- wide set of policies that extend beyond the PCE and are out of the scope of this document. In inter-AS operation, an inter-AS PCE must be able to drop PCECP messages arriving from an AS that it does not wish to communicate with. It must also be able to limit the aggregate rate of PCECP requests/responses arriving from PCEs affiliated with one ore more ASes or from a group of one or more ASes. 5.1.2.1. Path computation requests: PCC/PCE-PCE PCECP Path computation requests must be able to carry all constraint attributes necessary for setting up an LSP via (G)MPLS-TE signaling as stated in [PCECP-REQ]. A path computation request to an inter-AS PCE must be able to specify ASBRs and ASes as strict and loose nodes in the path of the LSP to the destination. A PCE must also be able to specify a preferred ASBR for exiting to the next AS for reaching the destination through a neighboring AS. An inter-AS PCE must also be able specify in its request a list of ASes and/or ASBRs to be excluded in the path computation. In the intra-provider case, it may also include links with specific affinity in the exclude list. If an inter-AS PCE learns reachability to a destination from different ASes, it should be able to send simultaneous requests to the inter-AS PCEs associated with these ASes. The maximum number of inter-AS PCEs, an inter-AS PCE may send simultaneous requests to, SHOULD be configurable. The choice of inter-AS PCEs could be influenced by policies which prefer some paths over others or some PCEs over others. When sending simultaneous requests, the tradeoff between signaling and path computation activity on one hand and the likelihood of setting an end-end optimum path should be considered. The PCC/PCE-PCE communication protocol must enable an inter-AS PCE to specify the AS on whose behalf it is sending the request. This is specifically important when the inter-AS PCE has identified many ASes within its scope to the other inter-AS PCE at the other end of the communication. A PCC or PCE (including inter-AS PCE) must be able to specify in its request the need for computing an end-end inter-AS path with protection against node and/or link failure using 1:1 detours or facility backup. An inter-AS PCE may itself ask for a similarly protected path. In addition, it may ask for protection across all ASes the path can traverse or across specific ASes. A path computation client must also be able to ask for a minimum of two paths that are diversified (i.e., do not share common nodes, links or SRLGs) it is request to an inter-AS PCE. An inter-AS PCE must be able to reject a request based on policies applied at a neighboring AS basis. Such policies may include any Bitar et al. [Page 13] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 valid request attributes, including class-types for packet LSPs, bandwidth that exceeds a preset threshold per LSP, preemption priorities, setup priorities, restriction on links with certain affinities, and desired protection. When a path request is rejected, the requestor must be informed of the rejection reason along with any information that may help the requestor avoid the points and/or reasons of rejections. 5.1.2.2. PCE responses A path computation response must be able to include nodes (e.g., ASBRs), abstract nodes such as ASes, and links as described in [PCE-ARCH]. In inter-AS intra-provider path computation, there may not be any confidentiality issues or restrictions that prevent one AS from returning a path with strict hops and no loose hops (i.e., nodes and links) within its AS to the requesting inter-AS PCE. In this case, the head-end of an LSP could receive, as a result of the work of multiple cooperating intra-AS and inter-AS PCEs, a path that contains nodes and links as strict hops from LSP head-end to tail-end. An inter-AS PCE, when it finds more than one path that satisfies the constraints for an LSP, must be able to return a number of these paths to the requestor. This requirement presumes that the path computation algorithm can compute and return more than one path. The number of returned paths must be configurable at the requesting PCE and the responding PCE to limit the amount of computation and total returned paths to the original PCC as computation recourses toward the AS of that PCC at the expense of possibly not computing the shortest path. Each path must contain the ASBR that connects to the requestor AS at a minimum. In addition, a cost associated with each path should be returned to enable selection of an optimum end-end path. The cost could reflect the cumulative administrative cost within a path. The PCC/PCE-PCE communication protocol must be able to carry this information. In its response, an inter-AS PCE must identify disjoint paths, when it is requested to compute such paths. End-end disjoint paths are paths that do not share nodes, links or SRLGs except for the LSP head-end and tail-end. In cases, where disjoint path segments are desired within one or more ASs, the disjoint path segments may share only the ASBRs of the first AS and the ASBR of the last AS across these ASes. If an inter-AS PCE cannot find a path to the destination or it cannot find a path that satisfies the LSP constraints, it must send a reject-type message to the requestor with a reject reason. Upon receiving this reject message, an inter-AS PCE or a PCC SHOULD attempt an alternative path by sending a request to an alternative AS-PCE. If it exhausted all AS-PCEs it SHOULD send a reject message to the previous requestion inter-AS PCE. Bitar et al. [Page 14] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 5.1.2.2. PCE Discovery In this section the requirement for PCE discovery are discussed. There are two types of PCE discovery that SHOULD be supported: (1) static via manual configuration, and (2) dynamic. In each case, the discovery of an inter-AS PCE within an AS and across ASes is addressed. 5.1.2.3. Static configuration An intra-AS inter-area PCE or a PCC MUST be configurable with one or more inter-AS PCEs that serve the respective PCE/PCC AS. An inter-AS PCE MUST also be configurable with the set of other inter- AS PCEs that it can have a session with and the ASes that these inter-AS PCEs cover. For simplicity, each inter-AS PCE should have a relationship with at least one inter-AS PCE that serves an AS it connects directly or indirectly at some cases with and not under its own jurisdiction. Each PCECP relationship between two inter-AS PCEs MUST be configurable with the ASes that the inter-AS PCE at the other end serves. In addition, other attributes for PCECP between two PCEs must be configurable. Such attributes include: - The IP address of the inter-AS PCE at the other end of the session and the locally used IP address to exchange IP address with inter-AS PCE. This IP address may differ from the one used for communicating with other PCEs/PCCs. - The type of the PCE at the other end of the session (e.g., inter- area intra-AS, intra-area intra-AS, or inter-AS). - The authentication policy for that session and key when authentication is required. This assumes that the transport protocol supports authentication. Alternatively, the session should be configurable over an IPsec tunnel with null encryption but with packet authentication. The IPsec tunnel can be in tunnel mode or transport mode. - A map for the class type (CT) and TE-class translation when the inter-AS PCE computes paths for packet LSPs. - The priority that a given inter-AS PCE serves the messages from the inter-AS PCE at the other end of the session as a matter of policy. - The message priorities that it can accept, and whether messages related to the path computation requests it receives from an inter- AS PCE should be initiated/progressed with a different locally defined priority map. The priority map must be configurable. In addition, enabling the notification of a requestor that the priority for a given message was changed should be enabled/disabled by configuration. Bitar et al. [Page 15] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 - The capability of the inter-AS PCE at the other end of the session to compute multiple paths and the maximum number of paths it can return. The maximum number of paths that a local inter-AS PCE can accept and specify in a path computation request - The total number of inter-AS messages that an inter-AS PCE can simultaneously accept from the inter-AS PCE at the other end should be configurable. An inter-AS PCE should be able to send a backpressure message via the PCC/PCE-PCE communication protocol to another inter-AS PCE to hold off the transmission of new requests. This should be triggered by the threshold set on PCE-PCE pair basis or the overall overload condition on the system, whatever triggers first. In addition the request rate should be configurable and enforceable. 5.1.2.4. Dynamic Discovery [PCEDP-REQ] states generic requirements for the PCE dynamic discovery protocol. In this section, additional dynamic PCE discovery requirements specific to inter-AS operations are discussed. An inter-AS PCE must be able to dynamically discover other types of PCEs in the ASes that fall within its scope. In addition other PCCs or PCEs must be able to discover an inter-AS PCE that serves them. The dynamic discovery protocol must also enable the detection and advertisement of the failure or non- reachability of an inter-AS PCE as well other PCEs within an AS and across ASs. The dynamic discovery protocol must allow an inter-AS PCE to identify itself as an inter-AS PCE and to identify the ASes that it supports. In addition, it must be able to identify its capabilities to the degree necessary for another PCE or PCC to decide to initiate a PCECP session to it. More detailed capabilities could be negotiated in PCC/PCE-PCE communication protocol messages. An inter-AS PCE may not be an inter-provider inter-AS PCE. In addition, it may be desired for an inter-AS PCE not to be discovered by a set of ASes or some of its capabilities not be known by a set of ASes. Thus, the capability to limit the scope of an inter-AS PCE advertisement for the purpose of dynamic discovery by other PCCs/PCEs must be provided. Furthermore, the ability to define the capabilities of an inter-AS PCE that can be advertised to another inter-AS PCE must be provided. A PCC/PCE must allow the configuration of local policies that control which inter-AS PCE it can communicate with when it discovers PCEs. Such policies may be based on PCE capabilities, specific PCEs or ASes that the PCE is affiliated with. The inter-AS PCE discovery mechanisms must commonly apply to both intra-provider and inter-provider cases. Bitar et al. [Page 16] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 5.1.3. PCE: Path Computation This section discusses the path computation requirements, including the requirements on routing, optimality, and path re-optimization. 5.1.3.1. Routing An inter-AS PCE could be a composite PCE 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 path to the LSP tail-end, and the AS in which the tail-end and head-end of the LSP reside. 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. 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 the path computation to the tail-end. The inter-AS PCE needs to interact with intra-area PCEs and 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. Thus, a composite PCE or a server can implement all PCE functions and acquire inter-AS information as well as topological information, including the TED, for ASes within its scope. Similarly a PCE server can acquire this information in many ways. 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 shall be specified and shall result in an optimum way of computing an inter-AS TE-LSP path. 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. These procedures shall also take into account the scalability of the overall solution (i.e., number of PCC and PCE relationships from the point of view of the PCC/PCE-PCE PCECP, the amount of information that need to be stored at an inter-AS PCE, etc.) Bitar et al. [Page 17] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 5.1.3.2. Optimality The inter-AS PCE solution SHOULD allow the set-up of an inter-AS (G)MPLS-TE LSP that complies with a set of TE constraints defined in [TE-REQ]), respectively, and follows an optimal path. The definition of “optimal path” for a TE LSP path can be found in section 5.1.3 of [INTERAS-TE-REQ] and Section 1 of this document. An optimal solution is also one that results in the fastest computation of an LSP path when compared to other solutions under the same PCE topologies, network topologies, and PCC/PCE topology. 5.1.3.3. Path Re-optimization 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. Bitar et al. [Page 18] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 5.1.3.4. Support of diversely routed inter-AS TE LSP 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 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 solution shall provide ways for computing such diversified paths. 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. The inter-AS PCE solution should provide for this capability. Inter-AS MPLS Fast Reroute The inter-AS PCE-based solution SHOULD provide the capability of MPLS fast reroute around a link or node failure. The link or node could be internal to an AS or at an AS boundary. 5.1.4. Hierarchical MPLS The inter-AS PCE solution SHOULD allow for tunneling inter-AS LSPs within other intra-AS and inter-AS LSPs. Such tunneling is expected to be transparent to an inter-AS PCE when it happens within an AS. In other cases, an inter-AS LSP may be configured between two ASBRs separated by one or more ASes. If such an LSP is made available to the inter-AS PCE, serving the AS of the head-end, along with available resource information the inter-AS PCE SHOULD be able to consider this LSP as shortcut between the ASes of the head-end and tail-end ASBRs and consider it a link between the two ASes for path computation purposes. If this tunnel is used as an IP link and the two nodes at the head-end and tail-end of that LSP are direct BGP peers over that tunnel, then normal procedures for inter-AS path computation are used. Such tunnels may exists between any ASes, including intermediate ASes and terminating ASes. The need for supporting hierarchical MPLS in a single provider environment could stem from the need to provide a scalable solution, by reducing the number of LSPs exposed in intermediate ASes and the associated state and dynamism. 5.1.5. Scalability and Performance Requirements When evaluating a particular solution or comparing solutions that address aspects of inter-AS PCE, the following scalability and performance criteria SHOULD be considered: - Message load on the inter-AS PCEs and intra-AS PCEs. Bitar et al. [Page 19] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 - Resulting optimality of the computed end-end LSP path under stated network conditions and constraints and comparison to [INTERD-TE-PDPC] mechanisms - Inter-AS (G)MPLS-TE LSP setup time - Minimization of the need for crankback - Ensuring that the LSP will be setup if there is a path that satisfies the constraints set for that LSP - Node and link protection capability including ASBR and inter-ASBR link failures using MPLS fast reroute mechanisms, end-end path protection via paths with disjoint routes, segment-based protection via disjoint path segments across one or more ASs. - The capability to operate in a PCE-enabled and PCE-free environment and interworking with existing(G)MPLS-TE mechanisms - No added complexity to network routing by the inter-AS PCE - Scalability with network size and its effect on PCC/PCE-PCE sessions - Added complexity and features to the PCC/PCE-PCE communication protocol - Added complexity and features to the inter-AS PCE discovery protocol Added complexity and features on signaling 5.1.6. Complexity and Risks The proposed solution(s) SHOULD NOT introduce unnecessary complexity to the current operating network to such a degree that it would affect the stability and diminish the benefits of deploying such a solution over SP networks. 5.1.7. Management, Aliveness Detection and Recovery Requirements Especially, in terms of MIB, inter-AS PCEs should support a specific inter-AS traffic engineering MIB as specified in section 5.1.10.1 of [INTERAS-TE-REQ]. This MIB relates to security consideration in this document. The new MIB module must provide trap functions when thresholds are crossed or when important events occur for inter-AS PCEs. The built-in diagnostic tools must detect failures of PCC/PCE-PCE PCECP and allow checking the status of PCECP related to inter-AS PCEs. The new MIB module should support the status of PCECP related to inter-AS PCEs. Here, it is assumed that inter-AS PCEs exist in different AS or different SP administrative domains. Bitar et al. [Page 20] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 Basic aliveness detection for PCC/PCE-PCE communication is described in [PCECP-REQ]. Specifically, the PCECP must allow an inter-AS PCE to check the liveliness of the neighboring inter-AS PCE(s) it is using for an inter-AS TE path computation, and a neighboring inter-AS PCE(s) to check the liveliness of an inter-AS PCE it is serving. Basic PCC/PCE failure response is described in [PCECP-REQ]. But, an inter-AS PCE must address inter-AS PCE-inter-AS PCE communication failure response. It must be defined how an inter-AS PCE deals with the failures of neighboring inter-AS PCEs. It is recommended that an inter-AS PCE selects another neighboring inter-AS PCE that serve the same or group of ASes so that to obtain equivalent coverage, on detection of an inter-AS PCE failure or non-rechability of an inter-AS PCE. But note that inter-AS PCE selection procedure is out of the scope in this document. Basic protocol recovery is described in [PCECP-REQ]. PCC/PCE-PCE communication protocol must support resynchronization of information and requests between inter-AS PCEs, and this should be arranged in order to minimize repeated data transfer. 5.2. Requirements Across SP Administrative Domains The inter-AS PCE requirements for PCECP for inter-providers case SHOULD include all requirements discussed in section 6.1 above in addition to those discussed in this section here. Please also note that the SP with multiple ASes may choose not to include inter-provider inter-AS PCE requirements presented here in its inter-AS TE implementation within its own administrative domain. 5.2.1. Confidentiality Each SP will in most cases maintain its own PCEs, some scoped for intra-provider inter-AS within its own administrative domain and some are specifically designated for inter-provider inter-As TE LSP path computation. Among the inter-provider scoped inter-AS PCEs in each SP domain, there may also be a subset of the PCEs specifically enabled for path computation across one or specific set of ASes of different SPs. In addition to the generic requirement of limiting discovery scope and inter-domain path computation capability for both PCCs and PCEs covered in section 5.1 and 5.2 of [PCEDP-REQ], and specifically to the inter-provider inter-AS application, the PCE discovery mechanism SHOULD have the ability to support the following requirements: Bitar et al. [Page 21] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 - Hiding all intra-AS PCEs or PCEs with internal scope and capability information not required for inter-AS path computation for one or a set of peering AS(es). This requirement may be enforced in conjunction with the inter-PCE policies across the AS boundaries as detailed in the next section, Policy Controls. - Also as required in section 5.2.1 of [INTERAS-TE-REQ], the PCE solutions SHOULD include the ability to carry out path computations for an optimum inter-AS TE LSP across AS boundaries while preserving the path confidentiality in its own AS. In other words, the PCE should be able to compute the inter-AS TE LSP across AS boundaries without detailed knowledge of the list of hops, TE link metrics and paths within each transit AS. For each partial inter-AS LSP path a PCE computes, it should return to its peering PCE in the upstream neighbor AS(es) an inter-AS TE LSP segment from its own AS without detailing the explicit intra-AS hops plus partial paths with an aggregated TE LSP cost it receives from its downstream PCE. 5.2.2. Policy Controls Section 5.2.2. of [INTERAS-TE-REQ] discusses the policy control requirements on the inter-AS RSVP-TE signaling at the AS boundaries for the enforcement of interconnect agreements, attribute/parameter translation and security hardening. This section discusses those policy control requirements specifically for PCECP at the PCE control plane level. Please note that SPs may still require ingress policy controls on the actual signaling paths mentioned above to enforce their bilateral or multi-lateral agreements at the AS boundaries. 5.2.2.1. Inter-AS PCE Peering Policy Controls As mentioned in section 5.2.1 above, the PCE discovery protocol SHOULD have the ability to control PCE scope and inter-AS computation capabilities to be discovered by PCCs or PCEs from other AS(es). The following provides some parameters which could be controlled during discovery for PCCs or PCEs from upstream neighboring AS(es): - PCE scope and path computation domains: one or a set of ASNs for which it can compute inter-AS TE LSP paths - The capability to compute inter-AS TE paths with other ASes that are not part of the originating AS transit path; for example, AS1 has requested AS2 to be the transit to AS3 but not AS4, therefore AS2 will exclude the path computation capability to AS4 during the PCE discovery between AS1 and AS2. Bitar et al. [Page 22] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 - Certain type of link and path constraints; for example, AS2 only agrees to allow its PCEs scoped for AS1 only considering bandwidth with certain sets of affinities and DS-TE class types - then all other capabilities of AS2's PCE will be excluded during the discovery between AS1 and AS2 - Re-optimization capabilities: for example, if the inter-AS TE segment is a statically stitched or nested LSP-segments which would not allow for re-optimization. - FRR capabilities for inter-AS paths: link, node or bandwidth protection for inter-AS TE LSP paths DS-TE TE class : SPs may have their own class-type and preemption definitions. Thus, advertised TE class capability should be translated to ones native to the requesting ASes. This is discussed in previous sections The PCE communications protocol SHOULD have the ability to enforce on the incoming PCE requests policies on a set of parameters listed in section 5.2.2.1 of [INTERAS-TE-REQ] in addition to the PCE scope and path computation domains. Please note that the PCEDP and PCECP SHOULD provide the ability to allow the discovery and enforcement of different information sets for PCCs and PCEs from different AS(es). For path computation requests that are not compliant with configured policies, the policy enforcing PCE SHOULD generate a path error message to the requesting PCC or PCE indicating the cause of errors. 5.2.2.2. Inter-AS PCE Reinterpretation Polices Each SP may have different definitions in its use of for example, RSVP-TE session attributes, DS-TE TE classes, etc. The PCEs receiving these path requests need to be able to reinterpret some of attributes and adapt them to the native environment in its own AS for path computation. A list of such parameters subject to policy reinterpretation can be found in section 5.2.2.2 of [INTERAS-TE-REQ]. Also the transit SPs along the inter-AS TE path may be a GMPLS transport provider which may require reinterpretation of MPLS specific PCE path request message for path computation over a GMPLS network. The PCECP implementation SHOULD allow for the policy enforcing PCEs to reinterpret some of these parameters in the incoming PCC or PCE requests from other AS(es) for its own AS TE implementations or to signal to PCEs in the downstream AS(es). Bitar et al. [Page 23] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 6. Security Considerations Security concerns arise between any two communicating elements especially when the elements belong to different administrative entities. In this case, there are security concerns that need to be addressed for communication among inter-AS PCEs and other PCEs in a single SP administrative domain as well among inter-AS PCEs under different SP administrative domains. To address these security conerns, Inter-AS PCEs should have the following means for setting up inter-AS traffic engineering LSPs: authentication, permission and rejection for path computation requests: In a multi-SP administrative domain environment, SPs want to authenticate inter-AS path computation requests to confirm whether they should trust the requests or not. They also want to allow or deny the requests after inter-AS PCEs authenticate them. In case multiple ASes exist within a single SP administrative domain, the SP may authenticate inter-AS path computation requests to confirm whether they should trust the requests or not depending on SP's policy. And they may allow or deny the requests after inter-AS PCEs authenticate them. Inter-AS PCEs should be able to authenticate inter-AS path computation requests and confirm whether they should allow or deny them. - Confidentiality: in a multi-SP administrative domain environment, SPs want to hide their network topologies for security reasons. Inter-AS PCEs should be able to hide the set of the hops within an AS. See the section 5.2.1 in this document and section 5.2.1 of [INTERAS-TE-REQ]. - Policy control: In a multi-SP administrative domain environment, each SP itself has some policies for a (G)MPLS-TE enabled network. An inter-AS PCE sends path computation requests which with some parameter to its neighboring inter-AS PCEs. In terms of parameters, see section 5.2.2.1 of [INTERAS-TE-REQ]. In this case, an inter-AS PCE enforces some policies applied to its neighboring inter-AS PCEs that may include rewriting some of the parameter values or rejecting requests based on some parameters’ values. Inter-AS PCEs should have the ability to exclude and/or filter internal scope and capability information. In case multiple ASes exist within a SP administrative domain, the above may be applied. - Traffic policing: In multi-SP administrative domain environment or in case multiple ASes exist within a single SP administrative domain, inter-AS PCEs may receive a large number of PCE requests within a short time. inter-AS PCEs should be able to limit the amount of PCE requests. Bitar et al. [Page 24] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 - Protection from DoS attacks: In multi-SP administrative domain environment, inter-AS PCEs may be subject to malicious DoS attacks. They should have functions to protect from such attacks. - PCC/PCE spoofing: In multi-SP administrative domain enviornmrnt, inter-AS PCEs have the possibility of spoofing the PCE-PCE communication. Inter-AS PCEs should have functions to avoid spoofing a PCE-PCE communication. 7. Author’s Addresses Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 Email: nabil.bitar@verizon.com Dean Cheng Cisco Systems Inc. 3700 Cisco Way San Jose CA 95134 USA Phone: +1 408 527 0677 Email: dcheng@cisco.com Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Phone: +81-3-6678-3103 Email: ke-kumaki@kddi.com Eiji Oki NTT Midori-cho 3-9-11 Musashino-shi, Tokyo 180-8585, JAPAN Email: oki.eiji@lab.ntt.co.jp Raymond Zhang BT INFONET Services Corporation 2160 E. Grand Ave. El Segundo, CA 90245 USA Email: Raymond_zhang@bt.infonet.com 8. Normative References [INTERAS-TE-REQ] Zhang and Vasseur, “MPLS Inter-AS Traffic Engineering requirements”, draft-ietf-tewg-interas-mpls-te-req- 09.txt, March 2005 (Work in Progress; RFC Editor’s Queue) Bitar et al. [Page 25] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 [PCE-ARCH] Farrel, Vasseur & Ash, “Path Computation Element (PCE) Architecture”, draft-ietf-pce-architecture-02.txt, March 2006 (Work in Progress) [PCECP-REQ] J. Ash, J.L Le Roux et al., “PCE Communication Protocol Generic Requirements”, draft-ietf-pce-comm-protocol-gen-reqs (work in progress). [PCEDP-REQ] J.L. Le Roux et al., “Requirements for Path Computation Element (PCE) Discovery”, draft-ietf-pce-discovery-reqs (work in progress). [TE-REQ] Awduche et. al., "Requirements for Traffic Engineering over MPLS", RFC2702, September 1999. [TE-RSVP] Awduche et. al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001 [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) 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) [ISP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with Generalized MPLS TE", (work in progress). [LSP-HIERARCHY] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized MPLS TE", (work in progress)) [GMPLS-ROUT] Kompella, et. al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions, RFC 3473, January 2003. 10. Full Copyright Statement Copyright (C) The Internet Society (2005). 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. 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 Bitar et al. [Page 26] Internet Draft draft-bitar-zhangr-interas-pce-req-01.txt October 2005 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. Bitar et al. [Page 27]