Network Working Group Nabil Bitar (Editor)
VerizonInternet Draft Verizon Raymond Zhang (Editor) BT Infonet Intended Status: Informational Kenji Kumaki (Editor) KDDI Corporation Expires: JanuaryApril 2007 AugustOctober 2006 Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) draft-ietf-pce-interas-pcecp-reqs-00.txtdraft-ietf-pce-interas-pcecp-reqs-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. 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 asa "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). Abstract This document discusses requirements for the support of theMultiprotocol Label Switching Traffic Engineered (MPLS-TE) LabelSwitched Paths (LSPs) may be established wholly within an Autonomous System (AS) or may cross AS boundaries. The Path Computation Element Communication Protocol (PCECP) in inter-AS applications. Its main objective(PCE) is to presenta setcomponent that is capable of requirements which would result in guidelinescomputing paths for the definition, selectionMPLS-TE LSPs. The PCE Communication Protocol(PCECP) is defined to allow communication between Path Computation Clients (PCCs) and specification developmentPCEs, and between PCEs. The PCECP is used to request paths and to supply computed paths in responses. Generic requirements for any technical solution(s) meeting these requirements.the PCECP are set out in "Path Computation Element(PCE) Communication Protocol Generic Requirements", RFC 4657. This document extends those requirements to cover the use of PCECP in support of inter-AS MPLS-TE. 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.....................................................2Introduction.....................................................3 2. Definitions......................................................3 3. Reference Model..................................................4 4. Detailed PCECP Requirements for Inter-AS (G)MPLS-TE..............4 4.1.1. PCC/PCE-PCEComputation.............5 4.1. PCE Communication Protocol Requirements..............4 220.127.116.11.Requirements........................5 4.1.1. Requirements onfor path computation requests..................4 18.104.22.168.requests...................5 4.1.2. Requirements onfor path computation responses.................6 4.1.2.responses..................6 4.2. Scalability and Performance Requirements.....................6 4.1.3.Requirements.......................7 4.3. Management, Aliveness DetectionDetection, and Recovery Requirements....7 4.1.4. Confidentiality..............................................8 4.1.5.Requirements.....8 4.4. Confidentiality................................................8 4.5. Policy Controls EffectingAffecting inter-AS PCECP.....................8 22.214.171.124.PCECP.......................9 4.5.1. Inter-AS PCE Peering Policy Controls.......................8 126.96.36.199.Controls.........................9 4.5.2. Inter-AS PCE Reinterpretation Polices......................9Policies......................10 5. Security Considerations..........................................9Considerations.........................................10 6. IANA Considerations..............................................9Considerations.............................................11 7. Acknowledgments..................................................9Acknowledgments.................................................11 8. Authors' Addresses...............................................9Addresses..............................................11 9. Normative References............................................10References............................................11 10. Informative References.........................................10References.........................................12 1. Introduction MPLS Inter-AS traffic engineering requirements [INTERAS-TE-REQ] defined[RFC4216] defines the scenarios motivating the deployment of inter-AS MPLS traffic engineering. [INTERAS-TE-REQ] also specifiedinter- AS Multiprotocol Label Switching Traffic Engineering (MPLS-TE). [RFC4216] specifies the requirements for inter-AS MPLS traffic engineeringMPLS-TE when the ASesASs are under the administration of one Service Provider (SP) administrationor the administration of different SPs. Today, there are threeThree signaling options inare defined for 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,[RFC4206]. [INTERD-TE-PDPC] defines mechanisms for inter-domain paththe computation of inter- domain TE LSPs using network elements along the signaling and data paths.paths to compute per-domain path segments. The mechanisms in [INTERD-TE- PDPC][INTERD-TE-PDPC] do not provide the capability toguarantee an optimum TEpath across multiple ASes. A (G)MPLS-TEASs where an 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),AS) among all possible paths that satisfy the LSP TE-constraints. The Path Computation Element (PCE) [RFC4655] is a component that is capable of computing paths for MPLS-TE LSPs. The requirements for a PCE have risencome from SP needsService Provider (SP) demands to compute a moreoptimum path than that can be achieved by mechanisms provided in [INTERD-TE-PDPC],paths across multiple domains, and to be able to separate the path computation elements from the forwarding elements. The PCE Communication Protocol (PCECP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, and between PCEs. The PCECP is used to request paths and to supply computed paths in responses. Generic requirements for the PCE discovery protocol (PCEDP) and PCC/PCE-PCE communication protocol (PCECP)PCECP are discussed in [PCEDP- REQ] and [PCECP-REQ], respectively. Complementary to these already- defined generic requirements, this[RFC4657]. This document provides a set of PCECP requirements that are specific to (G)MPLS-TEMPLS-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.computation. 2. Definitions This document adopts the definitions and acronyms defined in [INTERAS-TE-REQ]Section 3.13 of [RFC4216] and [PCE-ARCH]Section 2.2 of [RFC4655]. In addition, we use the following terminology: PCECP: PCE Communication Protocol PCEDP: PCE Discovery ProtocolInter-AS (G)MPLS-TE path: A (G)MPLS-TEAn MPLS-TE or Generalized MPLS (GMPLS) path that traverses two or more ASesASs. Intra-AS (G)MPLS-TE path: A (G)MPLS-TEAn MPLS-TE or GMPLS path that is confined to a single AS. It may traverse onone 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-TEMPLS-TE or GMPLS paths traversingremaining within a single AS. Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS- TEMPLS-TE or GMPLS paths or path segments, bypossibly by cooperating with intra-AS PCEs, across one or more ASes.PCEs. 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-TEMPLS-TE or GMPLS path computation while intra-AS PCEs perform the functions needed for intra-AS (G)MPLS-TEMPLS- TE or GMPLS path computation. This document focuses onFollowing is a scenario that depicts the PCE Communication Protocol requirements used by inter-AS PCEs to communicate path requests/responses to otherinteraction among PCCs, inter-AS PCEs and by intra-ASintra-area PCEs based on Figure 1. R1 in AS1 wants to communicatesetup a TE-LSP or a GMPLS path requests/responseswith certain constraints 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 applicationsR7 in AS3. R1 determines, using a PCE-based approach. Depending on the operation environment, service providers may use some or allmechanisms out of the capabilitiesscope of a PCECPthis document, that satisfies these requirements. Specifically, some requirements are more applicableR7 is an AS-external route and that it needs to inter-AS inter-provider (G)MPLS-TE operation than intra-provider operations. 4.1.1. PCC/PCE-PCE Communication Protocol Requirements Requirements specificcontact Inter-AS PCE1 to inter-AScompute the path. R1, as a PCC, sends a PCECP path computation requests and responses are discussed in section 188.8.131.52request to PCE1. PCE1 determines that R7 is reachable via AS2 and 184.108.40.206, respectively. 220.127.116.11. Requirements on path computation requests Following are inter-AS specific requirements on PCECP requeststhat PCE2 is the PCE to ask for path computation -across AS2. PCE1 sends a PCECP MUST allow the specification ofpath request to PCE2. Inter-AS PCE2 in turn sends a PCECP path computationrequest priorityto Intra-AS PCE R4 to compute a path within AS2 (In certain cases, the same router such R3 can assume both inter-AS and intra-AS path computation functions). R4 returns a PCECP path response to PCE2 with ASBR3 as specified in [PCECP-REQ]. Priority-based message processing isthe entry point to AS2 from AS1 and ASBR7 as the exit point to AS3. PCE2 then sends a local decisionPCECP path request to PCE3 to compute the path segment across AS3, starting at ASBR7 and terminating at R7. PCE3 returns a PCECP path response to PCE2 with the path segment ASBR7-R7. PCE2 then return path ASBR3-ASBR7-R7 to PCE1 which in turn returns path ASBR1-ASBR3-ASBR7-R7 to PCC R1. As described in the above scenario, in general, a PCC may contact an inter-AS PCE to request an inter-AS path, and is out ofthat PCE may supply the scopepath itself, or may solicit the services of this document. However, inother PCEs which may, themselves be inter-AS operation, a policyPCEs, or may be enforced on aintra-AS PCEs with the responsibility for computing path computation request so thatsegments within just one AS. This document describes the PCE Communication Protocol requirements for inter-AS path computation request priority is altered when progressingcomputation. That is, for PCCs to communicate path requests for inter-AS paths to a PCE, and for the request withinPCE to respond. It also includes the samerequirements for PCEs to communicate inter-AS path requests and responses. Inter-AS Inter-AS Inter AS or across other ASes.PCC <->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 SHOULD allowRequirements for Inter-AS Computation This section discusses detailed PCECP requirements for inter-AS MPLS-TE and GMPLS. Depending on the notificationdeployment environment, some or all of the requester of suchrequirements described here may be utilized. Specifically, some requirements are more applicable to inter- provider inter-AS MPLS-TE and GMPLS operations than to intra- provider operations. 4.1. PCE Communication Protocol Requirements Requirements specific to inter-AS PCECP path computation requests and responses are discussed in Sections 4.1.1 and 4.1.2, respectively. 4.1.1. Requirements for path computation requests The following are inter-AS specific requirements for PCECP requests for path computation: 1. [RFC4657] states the requirement for a priority level to be associated with each path computation request. This document does not change whenthat requirement, but in addition it happens. Such notification MAYMUST be suppressed by configuration action onpossible for an inter-AS PCE to apply local policy to vary the priority of path computation requests received across AS borders. PCECP MAY include a neighboringmechanism to inform the requesting inter-AS PCE basis. -of the change in priority that was applied. 2. A path computation request toby an inter-AS PCE or a PCC to another inter-AS PCE MUST be able to specify the sequence of ASs and/or ASBRs across the network by providing ASBRs and/or ASesASs as strict and loose nodeshops in the desired path of the LSP to the destination. AFor instance, an inter-AS PCE MUST alsobe be able to specify to the inter-AS PCE serving the neighboring AS a preferred ASBR for exiting to the nextthat AS for reachingand reach the destination through a neighboring AS. If such a constraint cannotdestination. That is, where multiple ASBRs exist, the requester MUST be satisfied atable to indicate a PCE,non-mandatory preference for one of them. 3. PCECP SHOULDMUST allow a PCErequester to notify the requestor of that fact in the path error message. - PCECP MUST enable enlistingprovide a list of ASesAss and/or ASBRs to be excluded infrom the path computation. -computed path. 4. A PCECP MUST enable anpath request from one inter-AS PCE to specifyanother MUST include the previous AS on whose behalf it is sendingnumber in the request. This is specifically important whenpath of the inter-AS PCE has identified many ASes within its scopeLSP to enable the other inter-AS PCE at the other endcorrect application of local policy at the communication. -second inter-AS PCE. 5. A path computation request from a PCC orto an inter-AS PCE (includingor an inter-AS PCE)PCE to another MUST be able to specify in its PCECP path computation requestthe need for computing an end-to- end path withprotection against node, link, and/oror 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 forIt MUST be possible to request protection across all ASes the path can traverseASs or across specific ASes. - A PCC or PCEASs. 6. The disjoint path requirements specified in [RFC4657] are extended such that it MUST be ablepossible to specifyapply a constraint of AS- diversity in its path request to an inter-AS PCEthe retturncomputation of a minimumset 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. -or more paths. 7. 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. 18.104.22.168.4.1.2. Requirements onfor path computation responses FollowingThe following are inter-AS specific requirements on PCECP responsesfor PCECresponses for path computation: -1. A PCECP 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 ASfrom 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 andone inter-AS PCEs, a path that contains nodes and links as strict hops from LSP head-endPCE to another MUST be able to tail-end. In the inter-provider case, confidentially and security considerations may require only the return of AS numbers and/orinclude ASBRs and ASs in the computed path computation response messages. -to maintain path segment and topology confidentiality. 2. A PCECP path computation response messagefrom one inter-AS PCE to the requesting inter-AS PCE MUST be able to carry an identifier for a path segment computed byit computes to preserve path segment and topology confidentiality. The objective of the responding PCE. Such anidentifier couldis to be usedincluded in a (G)MPLS-TE path setup messagethe LSP signaling, out of scope of this document, to be used for path expansion at an ASBR. -during LSP signaling. 3. If a constraint for a desired ASBR (see Section 4.1.1, requirement 3) cannot be satisfied by a PCE, PCECP SHOULD allow the PCE to notify the requester of that fact in a positive path computation response. 4. A PCECP response messagepath computation request from an inter-AS PCE to a requesting inter-AS PCE or a PCC MUST be able to carry ana cumulative inter-AS path cost. Path cost normalization across ASesASs is out of the scope of this document and it is expected to be addressed in other work on path computation. -document. 5. A PCECP path computation response messagefrom an inter-AS PCE to a PCC SHOULD be able to carry anthe intra-AS cost for a path segment separately from an inter-ASof the path segment cost. Best path selection procedures based on these costs are out ofwithin the scope of this document. -PCC AS. 6. A PCECP path computation response messageMUST be able to identify diversified paths for the same(G)MPLS-TE LSP when the responding PCE is requested to compute such paths.same (G)MPLS-TE LSP. End-to-end (i.e., between the two endpoints of the (G)MPLS-TE tunnel) disjoint diversifiedpaths are paths that do not share nodes, links or SRLGs except for the LSP head-endhead- end and tail- end.tail-end. In cases where diversified path segments are desired within one or more ASes, the diversifieddisjoint path segments may share only the ASBRs of the first AS and the ASBR of the last AS across these ASes. 22.214.171.124.2. Scalability and Performance Requirements When evaluating aPCECP design for use in the inter-AS case,case SHOULD consider the following scalability and performance criteria SHOULD be considered:criteria: - Message Processing load on the inter-AS PCEs and intra-AS PCEs.PCE message processing load. - Scalability as a function of the following parameters: - number of PCCs within the scope of an inter-AS PCE - number of intra-areaintra-AS PCEs within the scope of an inter-AS PCE - number of peering inter-AS PCEs per inter-AS PCE - Added complexity and features to the PCC/PCE-PCE communication protocol 4.1.3.caused by inter-AS features. 4.3. Management, Aliveness DetectionDetection, and Recovery Requirements [PCECP-REQ][RFC4657] 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 ASesASs within its scope,the ASesscope of an inter-AS PCE, neighboring ASs with whose inter-AS PCE(s) the inter-AS PCE cannot communicateMUST not communicate, neighboring ASs with via PCECP, the ASes thatwhose inter-AS PCEs the inter-AS PCE can communicate with,communicate, confidentiality policies, and traffic engineering policies. Each of these two latter requirements SHOULD apply perbe applicable on inter-AS PCE and/orPCE-pair basis or neighboring AS peer.basis (i.e., apply to all inter- AS PCEs that belong to a neighboring AS). The built-in diagnostic tools MUST enable failure detection and status checking of PCC/PCE-PCE PCECP. DiagnoticDiagnostic tools include statistics collection on the historical behavior of PCECP as specified in [PCECP-REQ]. For inter-AS operations,[RFC4657], but additionally it MUST be possible to analyze this statistics SHOULD be collectedon per inter-AS PCE peera neighboring AS basis and per AS. For instance,(i.e., across 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 messagesinter-AS PCEs that belong to a neighboring AS). The MIB module MUST support trap functions when thresholds are crossed or when important events occur for inter-AS PCEs.as stated in [RFC4657]. These thresholds SHOULD be specifiable per peerneighbor 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.[RFC4657]. The inter-ASPCECP MIB module SHOULD allow control of liveliness check behavior by providing a liveliness message frequency MIB object. Thisobject and this frequency object SHOULD be specified per inter-AS PCE peer. In addition, there SHOULD be 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-Ainter-AS PCE, the inter-AS PCE is declared unreachable. 126.96.36.199.4. Confidentiality Confidentiality mainly applies to inter-provider (inter-AS) PCE communication. However, confidentialityIt is about protecting the information exchanged between PCEs and about protecting the topology information within a provider's network. Confidentiality rules may also apply among ASesASs under a single provider. Each SP will in most cases designate some PCEs for inter-AS (G)MPLS-TEMPLS-TE or GMPLS path computation within its own administrative domain and some other PCEs for inter-provider inter-As (G)MPLS-TEinter- provider inter-AS MPLS-TE or GMPLS 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 ASesASs of different peer SPs. PCECP SHOULD allow an SP to hide from other SPs the set of hops,hops within its own AS(es,)ASs that are traversed by an inter-AS inter-provider (G)MPLS-TEinter- provider LSP (c.f., Section 5.2.1 of [INTERAS-TE-REQ]).[RFC4216]). In a multi-SP administrative domain environment, SPs may want to hide their network topologies for security or commercial 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 partialinter-AS LSP path asegment an inter-AS PCE computes, it may return to its peering PCE inthe upstream neighbor AS(es)requesting inter-AS PCE an inter-AS TE LSP path segment from its own AS(es)ASs without detailing the explicit intra-AS hops plus partial paths with an aggregated TE LSP cost it receives from its downstream PCE.hops. As stated earlier, PCECP responses SHOULD be able to carry path-segment identifiers withoutthat replace the details of that path segment. An ASBR that receives an RSVP-TE path message with an identifier object (new object), it canThe potential use that object to contact the PCE keyed byof that identifier and extract the identifiedfor path segment as well. 4.1.5.expansion, for instance, during LSP signaling is out of the scope of this document. 4.5. Policy Controls EffectingAffecting inter-AS PCECP Section 5.2.2 of [INTERAS-TE-REQ][RFC4216] discusses the policy control requirements on thefor 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 that are similar to what are discussed in section 5.2.2 of [RFC4216], for PCECP. Please note that SPs may still require ingresspolicy controls on the actual signaling paths mentioned aboveduring signaling of LSPs to enforce their bilateral or multi-lateralmulti- lateral agreements at theAS boundaries. 188.8.131.52.boundaries, but signaling is out of scope for this document. 4.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 parametersto its neighboring inter-AS PCEs. AnPCEs, and an inter-AS PCE that receives such requestsa request enforces somepolicies appliedapplicable to its neighboring inter-AS PCEs.the sender of the request. These policies may include rewriting some of the parameters' values andparameters, or rejecting requests based on some parameters'parameter values. Such policies may alsobe applied in the case of multiple ASesfor PCEs belonging to different SPs or to PCEs responsible for ASs within a single SP administrative domain. Parameters that might be 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 184.108.40.206 of [INTERAS-TE-REQ].[RFC4216]. For path computation requests that are not compliant with locally configured policies, PCECP SHOULD enable a PCE to send an error message to the requesting PCC or PCE indicating that the cause of errors. 220.127.116.11.request has been rejected because a specific parameter did not satisfy the local policy. 4.5.2. Inter-AS PCE Reinterpretation PolicesPolicies Each SP may have different definitions in its use ofof, for example, RSVP-TE session attributes,DS-TE TE classes, etc. Aclasses. An inter-AS PCE receiving a path computation requestsrequest needs to be able to reinterpret some ofinterpret the attributesparameters and constraints and adapt them to the native environmentlocal environment. Specifically, a request constructed by a PCC or PCE in its ownone AS for path computation.may have parameters and constraints that should be interpreted differently by the receiving PCE that is in a different AS. A list of suchsignaling parameters subject to policy reinterpretation at AS borders can be found in section 18.104.22.168 of [INTERAS-TE-REQ].[RFC4216], and the list for patch computation request parameters and constraints is the same. 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 forobjects to enable 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-ASinter- AS PCEs under different SP administrative domains. [PCECP-REQ][RFC4657] specifies requirements on PCECP to protect against spoofing, snooping and DoS attacks. These requirements become especially important in the multi- ASmulti-AS case. An inter-AS PCE MUST be able to authenticate a peering inter-AS PCE as a legitimate peer. Since inter-AS PCEs can be auto-discovered by an inter-AS PCE and peering sessions are formed dynamically, mechanisms for securely exchanging authentication keys across SP boundaries MUST be defined. The autodiscovery process itself MUST also be authenticated. 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 Verizon 40 Sylvan Road Waltham, MA 02451 Email: firstname.lastname@example.org Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Phone: +81-3-6678-3103 Email: email@example.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][RFC4216] Zhang and Vasseur, "MPLS Inter-AS Traffic Engineering Requirements", RFC4216,RFC 4216, November 2005. [PCE-ARCH][RFC4655] Farrel, VasseurA., Vasseur, J.P, & Ash, J., "A Path Computation Element (PCE) Based(PCE)-Based Architecture", draft-ietf-pce-architecture-05.txt (Work in Progress). [PCECP-REQ] J.RFC 4655, August 2006. [RFC4657] Ash, J.LJ., Le RouxRoux, J.L, et al., "PCE Communication Protocol Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs- 06.txt (work in progress).RFC 4657, September 2006. 10. Informative References [INTERD-TESIG] AyyangarAyyangar, A., and Vasseur, J.P, "Inter domain GMPLS Traffic Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter-domain- rsvp-te-02.txt, Aprildraft-ietf-ccamp-inter- domain-rsvp-te-03.txt, March 2006 (Work in Progress) [LSP-STITCHING] Ayyangar A., Vasseur JP., "LSPJ,P., "Label Switched Path Stitching with Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching-02.txt, September 2005,Traffic Engineering", draft-ietf- ccamp-lsp-stitching-03.txt, March 2006, (work in progress). [LSP-HIERARCHY] Kompella[RFC4206] Kompella, K., RekhterRekhter, Y., "Label switched Paths (LSP)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).[INTERD-TE-PDPC] Vasseur, AyyangarVasseur,J.P, Ayyangar, A., and Zhang, R., "A Per-domainPer- domain path computation method for computingestablishing Inter-domain Traffic Engineering (TE) Label Switched Path (LSP)", draft-ietf-ccamp-inter-domain-pd- path-comp-02.txt, FebruaryPaths (LSPs)", draft-ietf-ccamp-inter -domain-pd-path-comp-03.txt, August 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- firstname.lastname@example.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.