Internet Draft draft-ietf-pce-interas-pcecp-reqs-00 August 2006 Network Working Group Nabil Bitar (Editor) Verizon Internet Draft Raymond Zhang (Editor) BT Infonet Kenji Kumaki (Editor) KDDI Corporation Expires: January 2007 August 2006 Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) draft-ietf-pce-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. This Internet-Draft will expire in December 2006. Copyright Notice Copyright (C) The Internet Society (2006). Bitar et al. Inter-AS Requirements for PCECP [Page 1]
Internet Draft draft-ietf-pce-interas-pcecp-reqs-00 August 2006 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. 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. Detailed PCECP Requirements for Inter-AS (G)MPLS-TE..............4 4.1.1. PCC/PCE-PCE Communication Protocol Requirements..............4 4.1.1.1. Requirements on path computation requests..................4 4.1.1.2. Requirements on path computation responses.................6 4.1.2. Scalability and Performance Requirements.....................6 4.1.3. Management, Aliveness Detection and Recovery Requirements....7 4.1.4. Confidentiality..............................................8 4.1.5. Policy Controls Effecting inter-AS PCECP.....................8 4.1.5.1. Inter-AS PCE Peering Policy Controls.......................8 4.1.5.2. Inter-AS PCE Reinterpretation Polices......................9 5. Security Considerations..........................................9 6. IANA Considerations..............................................9 7. Acknowledgments..................................................9 8. Authors' Addresses...............................................9 9. Normative References............................................10 10. Informative References.........................................10 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- Bitar, Zhang et al. [Page 2]
Internet Draft draft-ietf-pce-interas-pcecp-reqs-00 August 2006 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 (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. Section 4 states inter-AS PCECP requirements. Section 5 discusses security issues. 2. Definitions This document adopts the definitions and acronyms defined in [INTERAS-TE-REQ] Section 3.1 and [PCE-ARCH] Section 2. In addition, we use the following terminology: PCECP: PCE Communication Protocol PCEDP: PCE Discovery Protocol Inter-AS (G)MPLS-TE path: A (G)MPLS-TE path that traverses two or more ASes Intra-AS (G)MPLS-TE path: A (G)MPLS-TE path that is confined to a single AS. It may traverse on or more IGP areas. Inter-area PCE: A PCE responsible for computing (G)MPLS-TE paths or path segments traversing across multi-IGP areas. 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 paths or path segments, by possibly cooperating with intra-AS PCEs, across one or more ASes. Bitar, Zhang et al. [Page 3]
Internet Draft draft-ietf-pce-interas-pcecp-reqs-00 August 2006 3. Reference Model Figure 1 depicts the reference model for PCEs in an inter-AS application. We refer to two types of PCE functions in this document: inter-AS PCEs and intra-AS PCEs. Inter-AS PCEs perform the procedures needed for inter-AS (G)MPLS-TE path computation while intra-AS PCEs perform the functions needed for intra-AS (G)MPLS-TE path computation. This document focuses on the PCE Communication Protocol requirements used by inter-AS PCEs to communicate path requests/responses to other inter-AS PCEs and by intra-AS PCEs to communicate path requests/responses to inter-AS PCEs and vice versa. 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 4. Detailed PCECP Requirements for Inter-AS (G)MPLS-TE This section discusses detailed PCECP requirements for inter-AS (G)MPLS-TE applications using a PCE-based approach. Depending on the operation environment, service providers may use some or all of the capabilities of a PCECP that satisfies these requirements. Specifically, some requirements are more applicable to inter-AS inter-provider (G)MPLS-TE operation than intra-provider operations. 4.1.1. PCC/PCE-PCE Communication Protocol Requirements Requirements specific to inter-AS PCECP path computation requests and responses are discussed in section 4.1.1.1 and 4.1.1.2, respectively. 4.1.1.1. Requirements on path computation requests Bitar, Zhang et al. [Page 4]
Internet Draft draft-ietf-pce-interas-pcecp-reqs-00 August 2006 Following are inter-AS specific requirements on PCECP requests for path computation - PCECP MUST allow the specification of a path computation request priority as specified in [PCECP-REQ]. Priority-based message processing is a local decision to a PCE and is out of the scope of this document. However, in inter-AS operation, a policy may be enforced on a path computation request so that the path computation request priority is altered when progressing the request within the same AS or across other ASes. PCECP SHOULD allow the notification of the requester of such a change when it happens. Such notification MAY be suppressed by configuration action on a neighboring inter-AS PCE basis. - 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 for reaching the destination through a neighboring AS. If such a constraint cannot be satisfied at a PCE, PCECP SHOULD allow a PCE to notify the requestor of that fact in the path error message. - PCECP MUST enable enlisting a list of ASes and/or ASBRs to be excluded in the path computation. - PCECP 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 PCECP path computation request the need for computing an end-to- end path with protection against node, 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 PCC or PCE MUST be able to specify in its path request to an inter-AS PCE the retturn of a minimum of two diversified paths (i.e., paths that do not share common nodes, links and/or SRLGs). - A PCECP path computation request message MUST enable the specification of AS-only diversified path computation. - A PCECP path computation request message MUST be able to identify the scope of diversified path computation to be end-to-end (i.e., between the endpoints of the (G)MPLS-TE tunnel) or to be limited to a specific AS. Bitar, Zhang et al. [Page 5]
Internet Draft draft-ietf-pce-interas-pcecp-reqs-00 August 2006 4.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 ASBRs and ASes on the computed path. 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 the inter-provider case, confidentially and security considerations may require only the return of AS numbers and/or ASBRs in path computation response messages. - A PCECP response message MUST be able to carry an identifier for a path segment computed by the responding PCE. Such an identifier could be used in a (G)MPLS-TE path setup message for path expansion at an ASBR. - A PCECP response message MUST be able to carry an inter-AS path cost. Path cost normalization across ASes is out of the scope of this document and it is expected to be addressed in other work on path computation. - A PCECP response message SHOULD be able to carry an intra-AS cost for a path segment separately from an inter-AS path segment cost. Best path selection procedures based on these costs are out of the scope of this document. - A PCECP response message MUST be able to identify diversified paths for the same(G)MPLS-TE LSP when the responding PCE is requested to compute such paths. End-to-end (i.e., between the two endpoints of the (G)MPLS-TE tunnel) disjoint 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. 4.1.2. Scalability and Performance Requirements When evaluating a PCECP for the inter-AS case, the following scalability and performance criteria SHOULD be considered: - Message Processing load on the inter-AS PCEs and intra-AS PCEs. - Scalability as a function of the following parameters: Bitar, Zhang et al. [Page 6]
Internet Draft draft-ietf-pce-interas-pcecp-reqs-00 August 2006 - number of PCCs within the scope of an inter-AS PCE - number of intra-area PCEs within the scope of an inter-AS PCE - number of peering inter-AS PCEs - Added complexity and features to the PCC/PCE-PCE communication protocol 4.1.3. Management, Aliveness Detection and Recovery Requirements [PCECP-REQ] specifies generic requirements for PCECP management. This document addresses new requirements that apply to inter-AS operations. The PCECP MIB module MUST provide objects to control the behavior of PCECP in inter-AS applications, including the ASes within its scope, the ASes the PCE cannot communicate with via PCECP, the ASes that the PCE can communicate with, confidentiality policies, and traffic engineering policies. Each of these two latter requirements SHOULD apply per inter-AS PCE and/or AS peer. The built-in diagnostic tools MUST enable failure detection and status checking of PCC/PCE-PCE PCECP. Diagnotic tools include statistics collection on the historical behavior of PCECP as specified in [PCECP-REQ]. For inter-AS operations, this statistics SHOULD be collected on per inter-AS PCE peer basis and per AS. For instance, the following statistics SHOULD be collected: - number of successfully satisfied requests - number of rejected requests per reason - number of PCE requests - number of malformed PCECP messages - number of unauthenticated PCECP messages The MIB module MUST support trap functions when thresholds are crossed or when important events occur for inter-AS PCEs. These thresholds SHOULD be specifiable per peer AS as well as per peer inter-AS PCE and traps should be accordingly generated. Basic liveliness 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. The inter-AS PCECP MIB module SHOULD allow control of liveliness check behavior by providing a liveliness message frequency MIB object. This frequency SHOULD be specified per inter-AS PCE peer. In addition, there SHOULD a MIB object that specifies the dead-interval as a multiplier of the liveliness message frequency so that if no liveliness message is received within that time from an inter-A PCE, the inter-AS PCE is declared unreachable. Bitar, Zhang et al. [Page 7]
Internet Draft draft-ietf-pce-interas-pcecp-reqs-00 August 2006 4.1.4. Confidentiality Confidentiality mainly applies to inter-provider PCE communication. However, confidentiality rules may also apply among ASes under a single provider. 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 may 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. As stated earlier, PCECP responses SHOULD be able to carry path-segment identifiers without the details of that path segment. An ASBR that receives an RSVP-TE path message with an identifier object (new object), it can use that object to contact the PCE keyed by that identifier and extract the identified path segment as well. 4.1.5. 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. 4.1.5.1. Inter-AS PCE Peering Policy Controls 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. An inter-AS PCE that receives such requests enforces some policies applied to its neighboring inter-AS PCEs. These policies may include rewriting some of the parameters' values and rejecting requests based on some parameters' values. Such policies may also be applied in the case of multiple ASes within a single SP Bitar, Zhang et al. [Page 8]
Internet Draft draft-ietf-pce-interas-pcecp-reqs-00 August 2006 administrative domain. Parameters subject to policy include bandwidth, setup/holding priority, Fast Reroute request, Differentiated Services Traffic Engineering (DS-TE) Class Type (CT), and others as specified in section 5.2.2.1 of [INTERAS-TE-REQ]. For path computation requests that are not compliant with configured policies, PCECP SHOULD enable a PCE to send an error message to the requesting PCC or PCE indicating the cause of errors. 4.1.5.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. A PCE receiving path computation requests needs to be able to reinterpret some of the 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]. In addition, the transit SPs along the inter-AS TE path may be GMPLS transport providers which may require reinterpretation of MPLS specific PCECP path request messages for path computation over a GMPLS network. These interpretation policies must be specifiable on a per-peer inter-AS PCE or AS basis as part of PCECP MIBs discussed earlier. 5. 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. [PCECP-REQ] specifies requirements on PCECP to protect against spoofing, snooping and DoS attacks. These requirements become especially important in the multi- AS case. 6. IANA Considerations This document makes no requests for IANA action. 7. Acknowledgments We would like to thank Adrian Farrel, Jean-Philippe Vasseur, and Jean Louis Le Roux for their useful comments and suggestions. 8. Authors' Addresses Nabil Bitar Bitar, Zhang et al. [Page 9]
Internet Draft draft-ietf-pce-interas-pcecp-reqs-00 August 2006 Verizon 40 Sylvan Road Waltham, MA 02451 Email: nabil.n.bitar@verizon.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 Raymond Zhang BT INFONET Services Corporation 2160 E. Grand Ave. El Segundo, CA 90245 USA Email: Raymond_zhang@bt.infonet.com 9. 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-05.txt (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- 06.txt (work in progress). 10. 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) [LSP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching-02.txt, September 2005, (work in progress). [LSP-HIERARCHY] Kompella K., Rekhter Y., "Label switched Paths (LSP) Hierarchy with Generalized MPLS TE", RFC4206, October 2005. [PCEDP-REQ] J.L. Le Roux et al., "Requirements for Path Computation Element(PCE) Discovery", draft-ietf-pce-discovery-reqs-03 (work in progress). Bitar, Zhang et al. [Page 10]
Internet Draft draft-ietf-pce-interas-pcecp-reqs-00 August 2006 [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). Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Bitar, Zhang et al. [Page 11]
