Internet Draft draft-bitar-zhang-interaS-pcecp-reqs-00 February 2006 Network Working Group Nabil Bitar (Editor) Verizon Internet Draft Raymond Zhang (Editor) BT Infonet Kenji Kumaki (Editor) KDDI Corporation Expires: August 2006 February 2006 Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) draft-bitar-zhang-interas-pcecp-reqs-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 discusses requirements for the support of the Path Computation Element Communication Protocol (PCECP) 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. Bitar et al. Inter-AS Requirements for PCECP [Page 1] Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006 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.....................................................2 2. Definitions......................................................3 3. Reference Model..................................................4 4. Application Scenarios............................................6 4.1. Inter-AS Path Computation for Virtual PoP (VPOP) or Sub-regional Networks............................................................6 4.2. Inter-AS Path Computation over a GMPLS Transport Core..........8 5. Detailed PCECP Requirements for Inter-AS (G)MPLS-TE..............8 5.1. Requirements within one SP Administrative Domain...............9 5.1.1. PCC/PCE-PCE Communication Protocol Requirements..............9 5.1.1.1. Requirements on path computation requests.................10 5.1.1.2. Requirements on path computation responses................11 5.1.2. Scalability and Performance Requirements....................12 5.1.3. Complexity and Risks........................................12 5.1.4. Management, Aliveness Detection and Recovery Requirements...12 5.2. Requirements Across SP Administrative Domains.................13 5.2.1. Confidentiality.............................................13 5.2.2. Policy Controls Effecting inter-AS PCECP....................13 5.2.2.1. Inter-AS PCE Peering Policy Controls......................13 5.2.2.2. Inter-AS PCE Reinterpretation Polices.....................14 6. Security Considerations.........................................14 7. Authors' Addresses..............................................15 8. Normative References............................................16 9. Informative References..........................................16 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. A (G)MPLS-TE optimum path for an LSP is one that has the smallest cost, according to a normalized TE metric Bitar, Zhang et al. [Page 2] Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006 (based upon a TE-metric or IGP metric adopted in each transit AS), among all possible paths that satisfy the LSP TE-constraints. The requirements for a PCE have risen from SP needs to compute a more optimum path than that can be achieved by mechanisms provided in[INTERD-TE-PDPC], and be able 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 PCECP requirements that are specific to (G)MPLS-TE inter-AS path computation using a PCE-based approach. 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 PCECP requirements when the ASes are under a single SP administrative domain. 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 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 networks 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/(G)MPLS 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 Paths (LSP), Head-end Label Switching Routers (LSRs), and Tail-end LSRs reside in the same AS for traffic engineering purposes. Bitar, Zhang et al. [Page 3] Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006 Inter-AS MPLS-TE: An MPLS-Traffic Engineering mechanism where its TE LSPs, Head-end LSRs and Tail-end LSRs do not reside within the same AS ASBR Routers: Border routers used to connect one AS to another AS of a different or the same SP via one or more links between the ASes. Inter-AS TE Path: A TE path traversing multiple ASes and ASBRs, e.g. AS1-ASBR1-inter-AS link(s)-ASBR2-AS2-ASBRn-ASn. 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 and other inter-AS PCEs, across one or more AS(es). 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),known as composite PCE, as described in [PCE-ARCH]). Inter-AS Inter-AS Inter AS Bitar, Zhang et al. [Page 4] Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006 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 Defines 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 ASes 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 selection 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(es) 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 "downstream" neighbor inter-AS PCE that it progresses the path request to. In determining the "downstream" 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 ASes when there is not sufficient bandwidth on the paths to these ASBRs or ASes to sastisfy the LSP bandwidth constraints). Before an inter-AS PCE decides to send a path Bitar, Zhang et al. [Page 5] Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006 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. What could be returned in the path computation response can be 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 affiliated with the responding PCE. This process proceeds recursively 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 [INTERD-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. 4. 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, a similar inter-AS TE application scenario using PCEs with inter-AS scope to compute optimum paths across AS boundaries is presented. Bitar, Zhang et al. [Page 6] Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006 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 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 example diagram depicted in Figure 2, ASBRs R13 and R14 as PCCs, dynamically or statically discover their corresponding PCEs R16 and R18 which in turn maintain meshed peering with AS2 PCEs R26 and R27. R13 and R14 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 require building a separate inter-TE tunnel (T3) to R113 directly to support a customer voice-trunk, for example. With per-domain path computation, the three tunnels (T1, T2, and T3) would be built with paths as shown below, assuming all links have a metric value of 1 and all inter-AS links between ASes have the same maximum reservable bandwidth: - T1's path: (R13,R15) expanding at R21 to have the path R13-R21-R23- R26-R15; - T2's path: (R14,R17) expanding at R22 to have the path R14-R22-R27- R17; - T3's path: (R11,R113) expanding at R21 to have the path R11-R13- R21-R23-R26-R15-R17-R113 Bitar, Zhang et al. [Page 7] Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006 For T1 and T2, the requirement for diversification is paramount where R26 and R27 (as PCEs) will need to maintain synchronized states of both T1 and T2 in order to compute two diverse routes for these two inter-AS TE LSPs. For T3, a more optimum path should be R11-R14-R22-R27-R17-R113 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 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. It is also worth noting that the reachability between R13 and R14 and their primary PCEs (R16 and R18) will be required via, for example either static or BGP routing in the global space across inter-ASBR links. 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 to compute an inter-As TE LSP between R1 and R2. ASBR1 in turns requests path computation from its downstream peering PCE, ASBR2, for this LSP 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 PCECP Requirements for Inter-AS (G)MPLS-TE Bitar, Zhang et al. [Page 8] Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006 This section discusses detailed PCECP requirements in two principal areas for inter-AS (G)MPLS-TE path computtion 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). 5.1. Requirements within one SP Administrative Domain This section presents detailed PCECP 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. PCC/PCE-PCE Communication Protocol Requirements Requirements specific to requests or responses are discussed in the next subsections. Following are additional 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-type 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 arise when ASes become part of one service provider domain as a result of mergers and acquisitions. - In inter-AS operation, an inter-AS PCE must be able to silently 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 by silently droping messages when a pre-configured rate threshold is exceeded. Bitar, Zhang et al. [Page 9] Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006 5.1.1.1. Requirements on path computation requests Following are inter-AS specific requirements on PCECP requests for path computation - 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/or 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 and reach the destination through that AS. - An inter-AS PCE must be able to specify in its request a list of ASes and/or ASBRs to be excluded in the path computation. It must also be able to include links with specific affinity in the exclude/include list. Boundary policies can be deployed to interpret and translate incoming affinity to one significant to the local AS. - 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-to-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 path with protection against node and/or link, and/or SRLG 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) its 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 valid request attributes, including class-types for packet LSPs, bandwidth that exceeds a preset threshold per LSP or AS, preemption priorities, setup priorities, restriction on links with certain Bitar, Zhang et al. [Page 10] Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006 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 in subsequent requests. 5.1.1.2. Requirements on path computation responses Following are inter-AS specific requirements on PCECP responses for path computation: - 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. - In a path computation response, 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 of the path. The PCC/PCE-PCE PCECP must be able to carry this information. - In its response, an inter-AS PCE must identify diversified paths, when it is requested to compute such paths. End-to-end diversified paths are paths that do not share nodes, links or SRLGs except for the LSP head-end and tail-end. In cases, where diversified path segments are desired within one or more ASes, the diversified 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 requesting inter-AS PCE if there is one. Bitar, Zhang et al. [Page 11] Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006 5.1.2. Scalability and Performance Requirements When evaluating a PCECP for inter-AS case, the following scalability and performance criteria SHOULD be considered: - Message load on the inter-AS PCEs and intra-AS PCEs. - Scalability with network size, number of inter-AS PCEs, number of intra-AS PCEs and the effect of these parameters on PCC/PCE-PCE sessions - Added complexity and features to the PCC/PCE-PCE communication protocol 5.1.3. 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.4. 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. 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 communicating with for inter-AS (G)MPLS-TE path computation. Basic PCC/PCE failure response is described in [PCECP-REQ]. But, an inter-AS PCE must address inter-AS PCE to 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 serves the same AS 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 of this document. Bitar, Zhang et al. [Page 12] Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006 5.2. Requirements Across SP Administrative Domains The inter-AS PCECP requirements in the inter-provider case include all requirements discussed in section 5.1 in addition to those discussed in this section. 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 designate some PCEs for inter-AS (G)MPLS- TE path computation within its own administrative domain and some other PCEs for inter-provider inter-As (G)MPLS-TE 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 a specific set of ASes of different peer SPs. PCECP should allow an SP to hide from other SPs the set of hops, within its own AS(es,) traversed by an inter-AS inter-provider (G)MPLS-TE LSP (c.f., Section 5.2.1 of [INTERAS-TE-REQ]). In a multi-SP administrative domain environment, SPs want to hide their network topologies for security reasons. In addition, SPs do not want to reveal the path traversed by an LSP segment within their domains to other SPs' domains. Thus, 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(es) without detailing the explicit intra-AS hops plus partial paths with an aggregated TE LSP cost it receives from its downstream PCE. A 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. 5.2.2. Policy Controls Effecting inter-AS PCECP 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 for PCECP. 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 A PCE SHOULD have the ability to enforce policies, defined for a set of parameters listed in section 5.2.2.1 of [INTERAS-TE-REQ], on the incoming PCECP path computation requests. Bitar, Zhang et al. [Page 13] Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006 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 with some parameters 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. These policies may include rewriting some of the parameters' values or rejecting requests based on some parameters' values. Inter-AS PCEs should also have the ability to exclude and/or filter internally-scoped information and capability information based on policies. Such policies may also be applied in the case of multiple ASes within a single SP administrative domain. For path computation requests that are not compliant with configured policies, the policy enforcing PCE SHOULD generate an error message to the requesting PCC or PCE indicating the cause of errors or a reject message with a reason. 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 the attributes and adapt them to the native environment in their 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). 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 as among inter-AS PCEs under different SP administrative domains. Following are requirements that apply to inter-AS PCECP messages: - Authentication, permission and rejection for path computation requests: Bitar, Zhang et al. [Page 14] Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006 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 it should trust the requests or not, depending on SP policy. An inter-AS PCE may allow or deny the requests after it authenticates them. Inter-AS PCEs should also be able to authenticate inter-AS PCECP path computation responses. Inter-AS PCEs should be able to authenticate inter-AS path computation requests and confirm whether they should allow or deny them. Inter-AS PCEs should be able to authenticate all PCECP messages. - 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 (i.e., resulting in a high path-computation-request rate). Inter-AS PCEs should be able to limit the amount of PCE requests. - Protection from DoS attacks: In multi-SP administrative domain environment, inter-AS PCEs may be subject to malicious DoS attacks using PCECP. Inter-AS PCEs should be able protect themselves from such attacks. - PCC/PCE spoofing: In multi-SP administrative domain environment, inter-AS PCEs have the possibility of spoofing the PCC/PCE-PCE communication. Inter-AS PCEs should have functions to avoid spoofing PCC/PCE-PCE communication. 7. Authors' Addresses Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02451 Email: nabil.n.bitar@verizon.com Kenji Kumaki KDDI Corporation Bitar, Zhang et al. [Page 15] Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006 Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Phone: +81-3-6678-3103 Email: ke-kumaki@kddi.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 [INTERAS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic Engineering Requirements", RFC4216, November 2005. [PCE-ARCH] Farrel, Vasseur & Ash, "A Path Computation Element (PCE)Based Architecture", draft-ietf-pce-architecture-04.txt, January 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- 04.txt(work in progress). [PCEDP-REQ] J.L. Le Roux et al., "Requirements for Path Computation Element (PCE) Discovery", draft-ietf-pce-discovery-reqs-03 (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-02.txt, February 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) [ISP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching-02.txt, September 2005, (work in progress). Bitar, Zhang et al. [Page 16] Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006 [LSP-HIERARCHY] Kompella K., Rekhter Y., "Label switched Paths (LSP) Hierarchy with Generalized MPLS TE", RFC4206, October 2005. [GMPLS-ROUT] Kompella, et. al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions, RFC 3473, January 2003. 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. 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. 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, Zhang et al. [Page 17] Internet Draft draft-bitar-zhang-interas-pcecp-reqs-00 February 2006 Bitar, Zhang et al. [Page 18]