Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)
The information below is for an old version of the document that is already published as an RFC.
This is an older version of an Internet-Draft that was ultimately published as RFC 5376.
|Authors||Kenji Kumaki , Raymond Zhang , Dr. Nabil N. Bitar|
|Last updated||2018-12-20 (Latest revision 2008-05-07)|
|RFC stream||Internet Engineering Task Force (IETF)|
|Additional resources||Mailing list discussion|
|IESG||IESG state||RFC 5376 (Informational)|
|Responsible AD||Ross Callon|
|Send notices to||(None)|
Network Working Group Nabil Bitar Internet Draft Verizon Intended Status: Informational Raymond Zhang Created: May 7, 2008 BT Expires: October 7, 2008 Kenji Kumaki KDDI Corporation Inter-AS Requirements for the Path Computation Element Communication Protocol (PCEP) draft-ietf-pce-interas-pcecp-reqs-06.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 October 2008. Abstract Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label Switched Paths (LSPs) may be established wholly within an Autonomous System (AS) or may cross AS boundaries. The Path Computation Element (PCE) is a component that is capable of computing constrained paths for (G)MPLS TE LSPs. The PCE Communication Protocol(PCEP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, and between PCEs. The PCEP is used to request constrained paths and to supply computed paths in response. Generic requirements for the PCEP are set out in "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657. This document extends those requirements to cover the use of PCEP in support of inter-AS MPLS TE. Bitar, Zhang and Kumaki.Inter-AS Requirements for PCEP [Page 1] Internet Draft draft-ietf-pce-interas-pecp-reqs-06 April 2008 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. Terminology.....................................................3 3. Reference Model.................................................4 3.1 Scope of Deployment Model......................................5 4. Detailed PCEP Requirements for Inter-AS Computation.............6 4.1 PCE Communication Protocol Requirements........................6 4.1.1 Requirements for Path Computation Requests...................6 4.1.2 Requirements for Path Computation Responses..................7 4.2 Scalability and Performance Considerations.....................8 4.3 Management Considerations......................................8 4.4 Confidentiality................................................9 4.5 Policy Controls Affecting Inter-AS PCEP........................9 4.5.1 Inter-AS PCE Peering Policy Controls.........................9 4.5.2 Inter-AS PCE Re-interpretation Policies.....................10 5. Security Considerations........................................10 5.1 Use and Distribution of Keys..................................11 5.2 Application of Policy.........................................11 5.3 Confidentiality...............................................11 5.4 Falsification of Information..................................12 6. IANA Considerations............................................12 7. Acknowledgments................................................12 8. Authors' Addresses.............................................12 9. Normative References...........................................13 10. Informative References........................................13 1. Introduction [RFC4216] defines the scenarios motivating the deployment of inter-AS Multiprotocol Label Switching Traffic Engineering (MPLS TE) and specifies the requirements for inter-AS MPLS TE when the ASes are under the administration of one Service Provider (SP) or the administration of different SPs. Three signaling options are defined for setting up an inter-AS TE LSP: 1) contiguous TE LSP as documented in [RFC5151]; 2) stitched inter-AS TE LSP discussed in [RFC5150]; 3) nested TE LSP as in [RFC4206]. [RFC5152] defines mechanisms for the computation of inter-domain TE Label Switched Paths (LSPs) using network elements along the signaling paths to compute per-domain constrained path segments. The Bitar, Zhang, and Kumaki Inter-AS Requirements for PCEP [Page 2] Internet Draft draft-ietf-pce-interas-pecp-reqs-06 May 2008 mechanisms in [RFC5152] do not guarantee an optimum constrained path across multiple ASes where an optimum path for an TE LSP is one that has the smallest cost, according to a normalized TE metric (based upon a TE metric or Interior Gateway Protocol (IGP) metric adopted in each transit 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 and Generalized Multiprotcol Label Switching Protocol ((G)MPLS TE) LSPs. The requirements for a PCE have come from SP demands to compute optimum constrained paths across multiple areas and/or domains, and to be able to separate the path computation elements from the forwarding elements. The PCE Communication Protocol (PCEP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, and between PCEs. The PCEP is used to request (G)MPLS TE paths and to supply computed paths in response. Generic requirements for the PCEP are discussed in [RFC4657]. This document provides a set of PCEP requirements that are specific to inter-AS (G)MPLS TE path computation. 2. Terminology This document adopts the definitions and acronyms defined in Section 3 of [RFC4216] and Section 2 of [RFC4655]. In addition, we use the following terminology: PCEP: PCE Communication Protocol Inter-AS (G)MPLS TE: MPLS or Generalized MPLS Traffic Engineering Inter-AS (G)MPLS TE path: An MPLS TE or Generalized MPLS (GMPLS) path that traverses two or more ASes. Intra-AS (G)MPLS TE path: An MPLS TE or GMPLS path that is confined to a single AS. It may traverse one or more IGP areas. Intra-AS PCE: A PCE responsible for computing (G)MPLS TE paths remaining within a single AS. Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS paths or path segments, possibly by cooperating with intra-AS PCEs. Bitar, Zhang, and Kumaki Inter-AS Requirements for PCEP [Page 3] Internet Draft draft-ietf-pce-interas-pecp-reqs-06 May 2008 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. Let's follow a scenario that illustrates the interaction among PCCs, inter-AS PCEs and intra-AS PCEs as shown Figure 1. R1 in AS1 wants to setup a (G)MPLS TE path, call it LSP1, with certain constraints to R7 in AS3. R1 determines, using mechanisms out of the scope of this document, that R7 is an inter-AS route and that it needs to contact its Inter-AS PCE1 to compute the path. R1, as a PCC, sends a PCEP path computation request to PCE1. PCE1 determines that R7 is reachable via AS2 and that PCE2 is the PCE to ask for path computation across AS2. PCE1 sends a PCEP path computation request to PCE2. Inter-AS PCE2, in turn, sends a PCEP path computation request to Intra-AS PCE R4 to compute a path within AS2 (in certain cases, the same router such as R3 can assume both inter-AS and intra-AS path computation functions). R4 may for instance return a PCEP path computation response to PCE2 with ASBR3 as the entry point to AS2 from AS1 and ASBR7 as the exit point to AS3. PCE2 then sends a PCEP path computation request to PCE3 to compute the path segment across AS3, starting at ASBR7 and terminating at R7. PCE3 returns a PCEP path computation response to PCE2 with the path segment ASBR7-R7. PCE2 then return path ASBR3-ASBR5-ASBR7-R7 to PCE1 which, in turn, returns path ASBR1-ASBR3-ASBR5-ASBR7-R7 to PCC R1. As described in the above scenario, in general, a PCC may contact an inter-AS PCE to request the computation of an inter-AS path, and that PCE may supply the path itself, or may solicit the services of other PCEs which may, themselves be inter-AS PCEs, or may be intra- AS PCEs with the responsibility for computing path segments within just one AS. This document describes the PCE Communication Protocol requirements for inter-AS path computation. That is, for PCCs to communicate path computation requests for inter-AS (G)MPLS TE path to a PCE, and for the PCE to respond. It also includes the requirements for PCEs to communicate inter-AS path computation requests and responses. Bitar, Zhang, and Kumaki Inter-AS Requirements for PCEP [Page 4] Internet Draft draft-ietf-pce-interas-pecp-reqs-06 May 2008 Inter-AS Inter-AS Inter-AS 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 3.1. Scope of Deployment Model All attempts to predict future deployment scopes within the Internet have proven fruitless. Nevertheless, it may be helpful to provide some discussion of the scope of the inter-AS deployment model as envisioned at the time of writing. It is expected that most, if not all, inter-AS PCEP-based communications will be between PCEs operating in the cooperative PCE model described in [RFC4655]. Clearly, in this model, the requesting PCE acts as a PCC for the purpose of issuing a path computation request, but nevertheless, the requesting node fills the wider role of a PCE in its own AS. It is currently considered unlikely that a PCC (for example, a normal Label Switching Router) will make a path computation request to a PCE outside its own AS. This means that the PCEP relationships between ASes are limited to at most n-squared where n is the number of peering PCEs in the various ASes (considered to be no greater than 100 in [RFC4657]). In practice, however, it is likely that only a few PCEs in one AS will be designated for PCEP communications with a PCE in an adjacent AS, and each of these will only have a few PCEs in the adjacent AS to choose from. A deployment model might place the PCEs as co-resident with the ASBRs, resulting in a manageable scaling of the PCE-PCE relationships. Scaling considerations (Section 4.2), manageability considerations (Section 4.3), and security considerations (Section 5) should be examined in the light of these deployment expectations. Bitar, Zhang, and Kumaki Inter-AS Requirements for PCEP [Page 5] Internet Draft draft-ietf-pce-interas-pecp-reqs-06 May 2008 4. Detailed PCEP Requirements for Inter-AS Computation This section discusses detailed PCEP requirements for inter-AS (G)MPLS TE LSPs. Depending on the deployment environment, some or all of the requirements described here may be utilized. Specifically, some requirements are more applicable to inter- provider inter-AS (G)MPLS TE perations than to intra-provider operations. 4.1. PCE Communication Protocol Requirements Requirements specific to inter-AS PCEP path computation requests and responses are discussed in the following sections. 4.1.1. Requirements for Path Computation Requests The following are inter-AS specific requirements for PCEP 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 that requirement. However, PCEP should include a mechanism that enables an inter-AS PCE to inform the requesting inter-AS PCE of a change in the request priority level that may have resulted from the application of a local policy. 2. A path computation request by an inter-AS PCE or a PCC to another inter-AS PCE MUST be able to specify the sequence of ASes and/or ASBRs across the network by providing ASBRs and/or ASes as hops in the desired path of the TE LSP to the destination. For instance, an inter-AS PCE MUST be able to specify to the inter-AS PCE serving the neighboring AS a preferred ASBR for exiting to that AS and reach the destination. That is, where multiple ASBRs exist, the requester MUST be able to indicate a preference for one of them. The PCE must be able to indicate whether the specified ASBR or AS as mandatory or non-mandatory to be on the (G)MPLS TE path. 3. PCEP MUST allow a requester to provide a list of ASes and/or ASBRs to be excluded from the computed path. 4. A PCEP path computation request from one inter-AS PCE to another MUST include the AS number of the requesting AS to enable the correct application of local policy at the second inter-AS PCE. 5. A path computation request from a PCC to an inter-AS PCE or an inter-AS PCE to another MUST be able to specify the need for protection against node, link, or SRLG failure using 1:1 detours or facility backup. It MUST be possible to request protection across all ASes or across specific ASes. Bitar, Zhang, and Kumaki Inter-AS Requirements for PCEP [Page 6] Internet Draft draft-ietf-pce-interas-pecp-reqs-06 May 2008 6. PCEP MUST support the disjoint path requirements as specified in [RFC4657]. In addition, it MUST allow the specification of AS- diversity for the computation of a set of two or more paths. 7. A PCEP 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. 4.1.2. Requirements for Path Computation Responses The following are inter-AS specific requirements for PCEP responses for path computation: 1. A PCEP path computation response from one inter-AS PCE to another MUST be able to include both ASBRs and ASes in the computed path while preserving path segment and topology confidentiality. 2. A PCEP path computation response from one inter-AS PCE to the requesting inter-AS PCE MUST be able to carry an identifier for a path segment it computes to preserve path segment and topology confidentiality. The objective of the identifier is to be included in the TE LSP signaling, whose mechanism is out of scope of this document, to be used for path expansion during LSP signaling. 3. If a constraint for a desired ASBR (see Section 4.1.1, requirement 2) cannot be satisfied by a PCE, PCEP SHOULD allow the PCE to notify the requester of that fact as an error in a path computation response. 4. A PCEP path computation from an inter-AS PCE to a requesting inter-AS PCE or a PCC MUST be able to carry a cumulative inter-AS path cost. Path cost normalization across ASes is out of scope of this document. 5. A PCEP path computation response from an inter-AS PCE to a PCC SHOULD be able to carry the intra-AS cost of the path segment within the PCC AS. 6. A PCEP path computation response MUST be able to identify diversified paths for the same (G)MPLS TE LSP. End-to-end (i.e., between the two endpoints of the (G)MPLS TE tunnel) disjoint 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 disjoint path segments may share only the ASBRs of the first AS and the ASBR of the last AS across these ASes. Bitar, Zhang, and Kumaki Inter-AS Requirements for PCEP [Page 7] Internet Draft draft-ietf-pce-interas-pecp-reqs-06 May 2008 4.2. Scalability and Performance Considerations PCEP design for use in the inter-AS case SHOULD consider the following criteria: - 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-AS PCEs within the scope of an inter-AS PCE - number of peering inter-AS PCEs per inter-AS PCE - Added complexity caused by inter-AS features. 4.3. Management Considerations [RFC4657] specifies generic requirements for PCEP management. This document addresses new requirements that apply to inter-AS operations. The PCEP MIB module MUST provide objects to control the behavior of PCEP in inter-AS applications. They include the ASes within the scope of an inter-AS PCE, Inter-AS PCEs in neighboring ASes to which the requesting PCE will or will not communicate, confidentiality and policies. The built-in diagnostic tools MUST enable failure detection and status checking of PCC/PCE-PCE PCEP. Diagnostic tools include statistics collection on the historical behavior of PCEP as specified in [RFC4657], but additionally it MUST be possible to analyze this statistics on a neighboring AS basis (i.e., across the inter-AS PCEs that belong to a neighboring AS). The MIB module MUST support trap functions when thresholds are crossed or when important events occur as stated in [RFC4657]. These thresholds SHOULD be specifiable per neighbor AS as well as per peer inter-AS PCE, and traps should be accordingly generated. Basic liveliness detection for PCC/PCE-PCE PCEP is described in [RFC4657]. The PCEP MIB module SHOULD allow control of liveliness check behavior by providing a liveliness message frequency MIB object 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-AS PCE, the inter-AS PCE is declared unreachable. Bitar, Zhang, and Kumaki Inter-AS Requirements for PCEP [Page 8] Internet Draft draft-ietf-pce-interas-pecp-reqs-06 May 2008 4.4. Confidentiality Confidentiality mainly applies to inter-provider (inter-AS) PCE communication. It is about protecting the information exchanged between PCEs and about protecting the topology information within an SP's network. Confidentiality rules may also apply among ASes owned by a single SP. 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. PCEP MUST allow an SP to hide from other SPs the set of hops within its own ASes that are traversed by an inter-AS inter-provider TE LSP (c.f., Section 5.2.1 of [RFC4216]). In a multi-SP administrative domain environment, SPs may want to hide their network topologies for security or commercial reasons. Thus, for each inter-AS TE LSP path segment an inter-AS PCE computes, it may return to the requesting inter-AS PCE an inter-AS TE LSP path segment from its own ASes without detailing the explicit intra-AS hops. As stated earlier, PCEP responses SHOULD be able to carry path-segment identifiers that replace the details of that path segment. The potential use of that identifier for path expansion, for instance, during LSP signaling is out of scope of this document. 4.5. Policy Controls Affecting Inter-AS PCEP Section 5.2.2 of [RFC4216] discusses the policy control requirements for 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 PCEP. Please note that SPs may still require policy controls during signaling of TE LSPs to enforce their bilateral or multi-lateral agreements at AS boundaries, but signaling is out of scope for this document. 4.5.1. Inter-AS PCE Peering Policy Controls An inter-AS PCE sends path computation requests to its neighboring inter-AS PCEs, and an inter-AS PCE that receives such a request enforces policies applicable to the sender of the request. These policies may include rewriting some of the parameters, or rejecting requests based on parameter values. Such policies may be applied for PCEs belonging to different SPs or to PCEs responsible for ASes within a single SP administrative domain. Parameters that might be Bitar, Zhang, and Kumaki Inter-AS Requirements for PCEP [Page 9] Internet Draft draft-ietf-pce-interas-pecp-reqs-06 May 2008 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 188.8.131.52 of [RFC4216]. For path computation requests that are not compliant with locally configured policies, PCEP SHOULD enable a PCE to send an error message to the requesting PCC or PCE indicating that the request has been rejected because a specific parameter did not satisfy the local policy. 4.5.2. Inter-AS PCE Re-interpretation Policies Each SP may have different definitions in its use of, for example, DS-TE TE classes. An inter-AS PCE receiving a path computation request needs to interpret the parameters and constraints and adapt them to the local environment. Specifically, a request constructed by a PCC or PCE in one AS may have parameters and constraints that should be interpreted differently or translated by the receiving PCE that is in a different AS. A list of signaling parameters subject to policy re-interpretation at AS borders can be found in section 184.108.40.206 of [RFC4216], and the list for path 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 re-interpretation of MPLS specific PCEP path computation request objects to enable path computation over a GMPLS network or vice versa. 5. Security Considerations The PCEP is a communications protocol for use between potentially remote entities (PCCs and PCEs) over an IP network. Security concerns arise in order to protect the PCC and PCE, and the information they exchange. [RFC4758] specifies requirements on the PCEP to protect against spoofing, snooping, and DoS attacks. That document is concerned with general protocol requirements applicable to the basic use of the PCEP. This document is specific to the application of the PCE architecture in an inter-AS environment, and so it is appropriate to highlight the security considerations that apply in that environment. Security requirements that exist within a single administrative domain become critical in the multi-AS case when the control of IP traffic and access to the network may leave the authority of a single administration. Bitar, Zhang, and Kumaki Inter-AS Requirements for PCEP [Page 10] Internet Draft draft-ietf-pce-interas-pecp-reqs-06 May 2008 5.1. Use and Distribution of Keys How the participants in a PCEP session discover each other and the need for the session is out of scope of this document. It may be through configuration or automatic discovery. However, when a PCEP session is established, the PCEP speakers MUST have mechanisms to authenticate each other's identities and validate the data the exchange. They also SHOULD have mechanisms protect the data that they exchange via encryption. Such mechanisms usually require the use of keys, and so the PCEP MUST describe techniques for the exchange and use of security keys. Where inter-AS PCE discovery is used, and PCEP security is required, automated key distribution mechanisms MUST also be used. Since such key exchange must (necessarily) operate over an AS boundary, proper consideration needs to be given to how inter-AS key exchanges may be carried out and how the key exchange, itself, may be secured. Key distribution mechanisms MUST be defined with consideration of [RFC4107]. Where a PCEP session is configured between a pair of inter-AS PCEs, a security key may be manually set for that session. 5.2. Application of Policy Policy forms an important part of the operation of PCEs in an inter-AS environment as described in Section 4.5, especially when ASes are administrated by different SPs. A wider discussion of the application of policy to the PCE architecture can be found in [PCE-POLICY]. Policy may also form part of the security model for the PCEP and may be particularly applicable to inter-AS path computation requests. A fundamental element of the application of policy at a PCE is the identity of the requesting PCC/PCE. This makes the use of authentication described in Section 5.1 particularly important. Where policy information is exchanged as part of the computation request and/or response, the policy object is transparent to the PCEP being delivered un-inspected and unmodified to the policy component of a PCE or PCC. Therefore, the policy components are responsible for protecting (for example, encrypting) the policy information and using additional identification and authentication if a higher level of validation is required than is provided by the base protocol elements of the PCEP. 5.3. Confidentiality The PCEP MUST provide a mechanism to preserve the confidentiality of path segments computed by a PCE in one AS and provided in a computation response to another AS. Furthermore, a PCE SHOULD be provided with a mechanism to mask its identity such that its presence in the path computation chain in a Bitar, Zhang, and Kumaki Inter-AS Requirements for PCEP [Page 11] Internet Draft draft-ietf-pce-interas-pecp-reqs-06 May 2008 cooperative PCE model (such as described in [BRPC]) cannot be derived from the computed path. This will help to protect the PCE from targeted attacks. Clearly, such confidentiality does not extend to the PCEP peer (i.e., a PCC or another PCE) that invokes the PCE with a path computation request. 5.4. Falsification of Information In the PCE architecture, when PCEs cooperate, one PCE may return a path computation result that is composed of multiple path segments each computed by a different PCE. In the inter-AS case, each PCE may belong to a different administrative domain, and the source PCC might not know about the downstream PCEs, nor fully trust them. Although it is possible and RECOMMENDED to establish a chain of trust between PCEs, this might not always be possible. In this case, it becomes necessary to guard against a PCE changing the information provided by another downstream PCE. Some mechanism MUST be available in the PCEP, and echoed in the corresponding signaling, that allows an AS to verify that the signaled path conforms to the path segment computed by the local PCE and returned on the path computation request. 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. Pasi Eronen and Sandy Murphy provided valuable early Security Directorate reviews. Adrian Farrel re-wrote the Security Considerations section. 8. Authors' Addresses Nabil Bitar Verizon 117 West Street 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 Bitar, Zhang, and Kumaki Inter-AS Requirements for PCEP [Page 12] Internet Draft draft-ietf-pce-interas-pecp-reqs-06 May 2008 Raymond Zhang BT 2160 E. Grand Ave. El Segundo, CA 90245 USA Email: Raymond_zhang@bt.com 9. Normative References [RFC4107] Bellovin, S., and Housley, R., "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005. [RFC4216] Zhang. R., and Vasseur, JP., "MPLS Inter-AS Traffic Engineering Requirements", RFC 4216, November 2005. [RFC4655] Farrel, A.. Vasseur, JP., and Ash, J., "A Path Computation Element (PCE)-Based Architecture", RFC 4755, August 2006. [RFC4657] Ash, J., Le Roux, JL., et al., "PCE Communication Protocol Generic Requirements", RFC 4657, September 2006. 10. Informative References [BRPC] Vasseur, JP., et. al, "A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched paths", draft-ietf-pce-brpc, work in progress. [RFC4206] Kompella, K., and Rekhter, Y., "Label switched Paths(LSP) Hierarchy with Generalized MPLS TE", RFC4206, October 2005. [RFC4758] Mystroem, M., "Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1", RFC 4758, November 2006. [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and Farrel, A., "Label Switched Path Stitching with Generalized MPLS Traffic Engineering (GMPLS TE)", RFC 5150, February 2008. [RFC5151] Farrel, A., Ayyangar, A., and Vasseur, JP., "Inter domain MPLS and GMPLS Traffic Engineering Resource Reservation Protocol-Traffic Engineering (RSVP-TE) extensions", RFC 5151, February 2008. [RFC5152] Vasseur, JP., Ayyangar, A., and Zhang, R., "A Per-domain path computation method for Establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008. Bitar, Zhang, and Kumaki Inter-AS Requirements for PCEP [Page 13] Internet Draft draft-ietf-pce-interas-pecp-reqs-06 May 2008 [PCE-POLICY] Bryskin, I., Berger, L. and Ash, J., "Policy-Enabled Path Computation Framework", draft-ietf-pce-policy-enabled- path-comp, 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, THE IETF TRUST 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 IETF Trust (2008). 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, and Kumaki Inter-AS Requirements for PCEP [Page 14]