Network work group Hongmiao Xia Internet Draft Dan Li Huawei Intended Status: Informational Expires: December 2007 June 30, 2007 Path Computation in Multiple Autonomous Systems Networks with Path Computation Element draft-xia-pce-hybrid-network-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 on December 30, 2007. Abstract The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. One key application of the PCE-based architecture is the computation of inter-domain Traffic Engineering Label Switched Path (TE-LSP) Xia & Li Expires December 30, 2007 [Page 1] Internet-Draft Hybrid PCE Networks June 2007 paths(i.e. inter-area, inter-AS, inter-provider, etc.). In this case, cooperation between PCEs is desirable due to the partial topology visibility available to each separate PCE. Per-domain path computation is another method that can be used to determine paths for inter-domain TE-LSPs when PCE cooperation is not applied in the network. In practice, some Service Providers may choose not to implement PCEs within their network that can cooperate with PCEs that are outside their network. In this case, a scenario may exist where an LSP spans multiple autonomous systems (ASes), some of which have PCEs capable of cooperation with external PCEs and some of which do not. For example, some ASes may be PCE-enabled, while others consist of just normal LSRs. Another scenario arises if a PCE fails or becomes unreachable. This gives rise to the same lack of inter-PCE cooperation. Both cases are named Hybrid PCE Networks in this document. This document describes the specific issues introduced for end-to-end path computation in Hybrid PCE Networks and defines extensions to the PCE Communication Protocol (PCEP) to perform inter-domain LSP computation in Hybrid PCE Networks. 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 [RFC2119]. Table of Contents 1. Introduction.................................................3 2. Process......................................................4 2.1. Example Scenario........................................4 2.2. Specific and Generic Cases..............................5 3. Security Considerations......................................6 4. Manageability Considerations.................................6 5. IANA Considerations..........................................6 6. Acknowledgments..............................................6 7. References...................................................6 7.1. Normative References....................................6 7.2. Informative References..................................7 8. Authors' Addresses...........................................7 9. Full Copyright Statement.....................................8 10.Intellectual Property Statement..............................8 Xia & Li Expires December 30, 2007 [Page 2] Internet-Draft Hybrid PCE Networks June 2007 1. Introduction The Path Computation Element (PCE) [RFC4655] provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A PCE serves path computation requests sent by Path Computation Clients (PCC). The PCE communication protocol (PCEP) defined in [PCEP] is designed as a communication protocol between a PCC and a PCE, or between two PCEs, in compliance with requirements and guidelines set forth in [RFC4657]. Such interactions include path computation requests and path computation replies. One key application of the PCE-based architecture is the computation of Label Switched Paths (LSPs) that traverse multiple Autonomous Systems (ASes). These are referred to as inter-AS TE-LSPs. Inter-AS MPLS TE requirements for PCEP are described in [INTERAS-TE-REQ]. When computing inter-AS LSPs, a PCE may not be able to supply a full path because it might not have full visibility of the network topology. Typically, a PCE can only see the topology within its own LSA. In this case there are two proposed path computation techniques ([RFC4726] and [RFC4655]) that involve multiple PCEs, each with visibility into a different domain or AS. o The per-domain computation approach [PER-DOMAIN] can be used during LSP setup to determine the inter-domain TE LSP as it traverses multiple domains. In this case, it is not necessary for separate or cooperating PCEs to be used in each AS. o The Backward Recursive Path Computation (BRPC) method [BRPC] can also be used to compute the path of an inter-domain TE LSP. In this case cooperating PCEs are required. In practice, some Service Providers may choose not to implement separate PCEs within their network, or may choose not to offer PCE cooperation with external PCEs. Additionally, a PCE set up for inter- PCE cooperation may fail or be unreachable A network that contains some domains with cooperative PCEs and some without is termed in this document a 'Hybrid PCE Network'. And a multi-domain TE LSP may need to cross domains some of which offer cooperating PCEs and some of which do not. Therefore, there is a requirement to be able to compute paths as extensively as possible Xia & Li Expires December 30, 2007 [Page 3] Internet-Draft Hybrid PCE Networks June 2007 before signaling (using, for example, BRPC), and to rely on per- domain computation to fill in the gaps during signaling. This document presents PCEP extensions and procedures to enable the computation of paths in Hybrid PCE Networks. 2. Process 2.1. Example Scenario +---------------------------------+ +------------------+ | Provider A | | Provider B | | PCE1 PCE2 | | | | | | | | | | V V | | | | R1-----R3------R5-----R6-----|---|----R9-----R11 | | | | / | | | | | | | | R2-----R4---- R7---R8------|---|----R10----R12 | | | | | | <---AS 1---> <---AS 2---> | | <---AS 3---> | | | | | +---------------------------------+ +------------------+ Figure 1: Mixed Provider networks with and without PCE Suppose provider A and B are two carrier networks. The network of provider A is divided into two AS, AS 1 and AS 2, each of which is deployed with a PCE. Provider B is composed of just one AS, AS 3, and has no PCE deployed in its network (or perhaps the PCE has failed). Assume a TE-LSP is needed between R1 and R11. The head-end node, R1, chooses to use PCE1 to compute the path and selects BRPC as the computation method. AS1-AS2-AS3 is provided as the AS sequence. R1 sends a PCReq message to PCE1. PCE1 determines that PCE2 is a PCE for AS2 and relays the PCReq message to PCE2. PCE2 finds no PCE for the next AS to cooperate with. If PCE2 were to just return a negative PCRep message, then this reply would be returned to R1 and R1 could select another approach such as the per-domain method to compute the path from R1 to R11. This is a complete procedure, but there are two disadvantages . First, the process falls back on the per-domain mehod which does not have such a good chance of selecting an optimal path. Second, the process is inefficient due to the failed BRPC attempt and the negative PCRep message. Xia & Li Expires December 30, 2007 [Page 4] Internet-Draft Hybrid PCE Networks June 2007 But a combination of BRPC and per-domain path computation can be used to increase the likelihood of achieving an optimal path. PCE2, upon finding that there is no PCE available for AS3, can compute a Virtual Shortest Path Tree (VSPT) [BRPC] to provide a path to each of the entry points into AS3, or to some selected entry points into AS3 by policy. This tree will be passed to PCE1 which will update the VSPT and select a path. The final path supplied to R1 will include all of the strict hops as far as AS3 (through either R9 or R10) and a loose hop to the destination, R11. When the LSP is signaled, the boundary node of AS3 (R9 or R10) will expand the ERO using the per-domain approach, and the LSP will be completed. 2.2. Specific and Generic Cases The Hybrid PCE Network can be generalized based on three specific cases as follows: 1) Domain 1 and domain 2 have PCEs, but domain 3 does not. This is the case described in Section 2.1. BRPC cannot be used in all domains, but can be combined with the per-domain approach. 2) Domain 2 and domain 3 have PCEs, but domain 1 does not. In this case, a path computation request can never be initiated from domain 1, and he LSP must be signaled across domain 1 with a loose hop to cover the combination of domains 2 and 3. But, when the LSP is signaled as far as domain 2, then normal PCE process may take place using BRPC if desired. 3) Domain 1 and domain 3 have PCEs, but domain 2 does not. In this case, ASBRs between domain 1 and domain 3 may establish virtual inter-AS TE links through domain 2, and PCEs in domain 1 and domain 3 may communicate and use the inter-AS TE links to compute. If one domain has no PCE, then it can provide inter-AS TE links for its neighboring domain which has PCEs. If domain 2 does not have the policy to provide inter-AS TE links, then per-domain method may still be used. A network may be more complex than the three cases listed above, but an arbitrarily complex series of domains may be composed as a sequence of the specific cases. When a domain sequence is selected, where some domains have PCEs and some do not, the sequence can be regarded as several contiguous segments. Each segment is composed of domains that all have a PCE or all do not. For each segment having Xia & Li Expires December 30, 2007 [Page 5] Internet-Draft Hybrid PCE Networks June 2007 PCEs, the BRPC method may still be used for the segment as PCE can provide a better solution considering the resources of whole network it serves. For each segment having not PCE, the per-domain method may be used. So computation will not be backward to head node if some domain has not PCE. A PCC can set O-bit in RP object to indicate it is willing to accept a loose path. So if a PCE find there is no PCE in downstream domain, it check whether O-bit in RP object is set. If the flag is set, the PCE can use the process described above. Else, it just returns an error with corresponding reasons. 3. Security Considerations TBD. 4. Manageability Considerations TBD (This section is compliant with [PCE-MGBT-REQ]). 5. IANA Considerations This document defines no new protocols or extensions and makes no requests to IANA for registry management. 6. Acknowledgments We would like to thank Adrian Farrel for his useful comments. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation Element (PCE)-based Architecture", RFC4655, august 2006. [RFC4726] Farrel, A., Vasseur, J.P. and Ayyangar, A., " Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC4726, November 2006. [INTERAS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic Engineering Requirements", RFC4216, November 2005. Xia & Li Expires December 30, 2007 [Page 6] Internet-Draft Hybrid PCE Networks June 2007 [PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE) communication Protocol (PCEP)", draft-ietf-pce-pcep, work in progress. [PER-DOMAIN] Ayyangar, A., Vasseur, J., and Zhang, R., " A Per-domain path computation method for establishing Inter-domain", draft-ietf-ccamp-inter-domain-pd-path-comp-05 (work in progress), February, 2006. [BRPC] Vasseur, J., Ed., R. Zhang, N. Bitar, JL. Le Roux, "A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Paths ", draft-ietf-pce-brpc-05.txt, Work in Progress, January 2007. 7.2. Informative References [RFC4657] Ash, J., Le Roux, J.L., " PCE Communication Protocol Generic Requirements", RFC4657, September 2006. [PCE-MGBT-REQ] Farrel, A., "Inclusion of Manageability Sections in PCE Working Group Drafts", draft-ietf-pce-manageability- requirements-01 (work in progress), March 2007. 8. Authors' Addresses Hongmiao Xia Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28973679 Email: xiahongmiao@huawei.com Dan Li Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28973237 Email: danli@huawei.com Xia & Li Expires December 30, 2007 [Page 7] Internet-Draft Hybrid PCE Networks June 2007 9. Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, 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. 10.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. 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. Xia & Li Expires December 30, 2007 [Page 8] Internet-Draft Hybrid PCE Networks June 2007 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". Xia & Li Expires December 30, 2007 [Page 9]