Network Working Group YL. Zhao Internet-Draft J. Zhang Intended status: Informational BUPT Expires: April 23, 2012 RQ. Jing China Telecom Beijing Research Institute DJ. Wang XH. Fu ZTE Corporation October 21, 2011 Protocol Extension Requirement for Cooperation between PCE and Distributed Routing Controller in GMPLS Networks draft-zhaoyl-pce-dre-03 Abstract Path Computation Element (PCE) is proposed for path computation in multi-layer and multi-domain networks where PCE can be implemented in either centralized method or distributed method. In the former case, PCE can serve tens or hundreds of nodes simultaneously, while in the later case, each node is equipped with a PCE, which can be regarded as a distributed routing controller (DRC) in GMPLS networks and each one of those provides similar path computation capability. PCE and DRC have different advantages in path computation respectively. PCE is suitable for cross-layer and cross-domain path computation, especially in multi-constraints environment. But distributed routing controller is good at path computation in parallel ways and distributed network control in local domain. A cooperative path computation architecture named Dual Routing Engine (DRE) is necessary to be used in the future networks, for it based on the ideas of the cooperation of these two types of path computation engines and can take the advantages of both centralized and distributed method by which the PCE is implemented. The corresponding PCE communication protocol extension and other protocol requirements for cooperation between PCE and distributed routing controller are listed in this document to recommend the standard interfaces between different components in DRE architecture. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Zhao, et al. Expires April 23, 2012 [Page 1] Internet-Draft Cooperation between PCE and DRC October 2011 Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 23, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Zhao, et al. Expires April 23, 2012 [Page 2] Internet-Draft Cooperation between PCE and DRC October 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 5 3. General Assumptions . . . . . . . . . . . . . . . . . . . . . 5 4. Cooperative Architecture based on PCE and Distributed Routing Controller . . . . . . . . . . . . . . . . . . . . . . 6 4.1. DRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. PCE . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Different Application Scenarios . . . . . . . . . . . . . . . 9 5.1. Cross layers and cross domains . . . . . . . . . . . . . . 10 5.2. Independent coexistence . . . . . . . . . . . . . . . . . 10 5.3. Security backup . . . . . . . . . . . . . . . . . . . . . 10 5.4. Policy-enabled . . . . . . . . . . . . . . . . . . . . . . 10 5.5. Constraint-based . . . . . . . . . . . . . . . . . . . . . 11 5.6. Service-oriented . . . . . . . . . . . . . . . . . . . . . 11 5.7. Cooperation between network level and node level . . . . . 11 6. PCEP Extension Requirements . . . . . . . . . . . . . . . . . 12 6.1. PCEP extension requirement for the communication between RES and PCE . . . . . . . . . . . . . . . . . . . 12 6.2. PCEP extension requirement for the communication between RES and DRC . . . . . . . . . . . . . . . . . . . 12 7. Other Protocol Extension Requirements . . . . . . . . . . . . 13 7.1. OSPF-TE extension requirement for the cooperative architecture . . . . . . . . . . . . . . . . . . . . . . . 13 7.2. RSVP-TE extension requirement for the cooperative architecture . . . . . . . . . . . . . . . . . . . . . . . 13 8. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Zhao, et al. Expires April 23, 2012 [Page 3] Internet-Draft Cooperation between PCE and DRC October 2011 1. Introduction Path Computation Element (PCE) is proposed to complete the constraint-based shortest path computation in Multi-protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) multi-layer and multi- domain networks [RFC4665]. And a series of Request for Comments (RFCs) related to PCE technology, such as requirements for PCE discovery, PCE Communication Protocol (PCEP), a backward recursive PCE-based computation procedure (BRPC) and so on, have been standardized. Studies have been proving that PCE is suitable for cross-layer and cross-domain design of networks, capable of end-to- end path computation under multiple constraints [1-2] and could be potentially applied to resource assignment and routing optimization [3-4]. PCE can be implemented either in centralized method or distributed method. In the former case, PCE can serve tens or hundreds of nodes simultaneously. while in the later case, each node is equipped with a PCE, which can be regarded as a distributed routing controller (DRC) in GMPLS networks and each one of them provides similar path computation capability. DRC in GMPLS/ASON control plane is good at the path computation in parallel ways and distributed network control in local domain. On the other hand, DRC can also be used in the management and configuration of resource in internal node. Becaues of that the huge bandwidth requirement is emerging, links with the transmission capacity of Tbit/s and switching at Pbit/s are necessary for next generation optical networks. According to the level of current photonics technology level, the node's architecture should to be very complicated with large power consumption. Therefore, how to configure the switching architecture in the node will be a very important issue for the entire network performance. On the other side, of course, PCE and DRC has corresponding disadvantages respectively. In order to optimize the performance of optical networks under different application scenarios, PCE and distributed routing controller are needed to cooperate with each other. A cooperative path computation architecture named Dual Routing Engine (DRE) is proposed, which includes two types of path computation engines, i.e. PCE and distributed routing controller, and can combine advantages of both of them. In this document, several different application scenarios are described. And PCE communication protocol extension and other protocol extension requirements for cooperation between PCE and distributed routing controller are also listed here. 1.1. 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 [RFC2119]. Zhao, et al. Expires April 23, 2012 [Page 4] Internet-Draft Cooperation between PCE and DRC October 2011 2. Terminologies LSR: Label Switching Router. LSP: Label Switched Path. PCC: Path Computation Client. Any client application requesting a path computation to be performed by the Path Computation Element. PCE (Path Computation Element): an entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. PCEP: PCE Communication Protocols, the communication protocol between PCC and PCE. DRC: Distributed Routing Controller, the module that can complete path computation in local domain or in internal node. DRE: Dual Routing Engine, including PCE and DRC. TED: Traffic Engineering Database. RID: Resource Information Databases. 3. General Assumptions PCE and distributed routing controller are two path computation engines which have been standardized by IETF working group. They can both complete the path computation in GMPLS networks. In order to show how the cooperative architecture based on PCE and distributed routing controller works, some assumptions as follows should be made before. o Each GMPLS-based control node is equipped with a distributed routing controller which can complete the path computation in local domain and even the path computation and resource configuration in the internal node, and each domain is equipped with no less than one PCE which can not only complete the intra- domain path computation, but also complete the inter-domain path computation. o The topology and TE information are updated as soon as any change occurs in the network, and the information kept at PCE and distributed routing controller are synchronized by OSPF-TE. Zhao, et al. Expires April 23, 2012 [Page 5] Internet-Draft Cooperation between PCE and DRC October 2011 o PCE and distributed routing controller can be selected arbitrary according to the local routing strategy. o Constraints and strategies can be considered by PCE during the process of the intra-domain path computation and the inter-domain path computation. o An end-to-end path which crosses domains or crosses layers can be completed by several PCEs or several DRCs or several PCEs and DRCs. For example, the section of an end-to-end path in one domain may be computed by PCE, but the other section of this path in another domain may be computed by DRC. 4. Cooperative Architecture based on PCE and Distributed Routing Controller As shown in Fig. 1, cooperative architecture consists of Path Computation Element (PCE) and distributed routing controller (DRC). Both of them maintain Traffic Engineering Databases (TEDs) to keep network topology and other status information within the scope of their respective functions. There is a function module named Routing Engine Selector (RES) at each control node, which is responsible for managing the switchover process between PCE and DRC and choosing the right one when a LSP setup request is arriving. RES as well as posses the function of PCC when cooperating with PCE and DRC and can be implemented in Connection Controller (CC) module of GMPLS-based control plane. Zhao, et al. Expires April 23, 2012 [Page 6] Internet-Draft Cooperation between PCE and DRC October 2011 ------- ------- | PCE |-------------------------| PCE | ------- ------- /|\ /|\ / | \ / | \ / | \ / | \ -----------/---|---\---------- ----------/---|---\---------- | / ------- \ | | / ------ \ | | / | RES | \ | | / | RES | \ | | / ---|--- \ | | / ---|--- \ | | / /---|---\ \ | | / /---|---\ \ | | / /| DRC |\ \ | | / /| DRC |\ \ | | / / ------- \ \ | | / / ------- \ \ | | / / \ \ | | / / \ \ | | / / \ \ | | / / \ \ | | / / \ \ | | / / \ \ | | ------- ------- | | ------- ------- | | | RES |-----------| RES |-----| RES |-----------| RES || | ---|--- ---|--- | | ---|--- ---|--- | | ---|--- ---|--- | | ---|--- ---|--- | | | DRC | | DRC || || DRC | | DRC || | ------- ------- | | ------- ------- | | domain A | | domain B | ------------------------------ ----------------------------- Fig.1 Cooperative architecture in multi-layer and multi-domain networks 4.1. DRC DRC offers general routing functions based on GMPLS/ASON control plane including link state adverting, topology updating and path computation. A typical DRC contains two essential modules which are topology analysis module and path computation module. The former floods network topology and resource utilization information to sychronize TED maintained on each node. The latter responds to a routing request from Connection Controller (CC), finds the optimized path solution and returns it to CC. Besides these general routing functions, DRC can also complete the resource allocation and configuration, which refer to internal resource allocation, ports interconnection, and switch fabric configuration in the internal node. This function is getting more and more important as the structure of the internal node is getting more and more complex. Details of DRC's operation are out of this document's scope. Zhao, et al. Expires April 23, 2012 [Page 7] Internet-Draft Cooperation between PCE and DRC October 2011 4.2. PCE PCE is of particular advantage of centralized path computation in multi-layer and multi-domain networks, especially in multi- constraints environment. There is a Client/Server model between RES and PCE. RES sends a TE-LSP computation request to PCE. PCE performs path computation and returns the results back to RES. As shown in Fig.2, RES chooses the best PCE based on a certain policy first. It sends performance query requests to multiple related PCEs, each of which evaluates itself individually and then feeds back to the RES. RES gathers performance status information from PCEs and decides which PCE is feasible. Thus a combination of RES and PCE is founded. Secondly PCE deals with the path computation requests coming from RES by the using of message parser. After the message parsing, if a request carries path information, it will be delivered towards path computer module. Or, if it carries policy information from RES, it should be firstlly interpreted by policy parser along with local policy settings and then loaded into path computer. Finally path computer implements multi-constraint routing on the basis of the path information, policy information and TE information. If path computation is successful the details of the whole route will be returned to RES. If it only gets an incomplete route a new application for path computation request will be sent to the next hop RES. Then a PCE or DRC will be selected to complement the incomplete route. Zhao, et al. Expires April 23, 2012 [Page 8] Internet-Draft Cooperation between PCE and DRC October 2011 --------------------- | RES |__________ | in Domain A | | --------------------- | | | 1.Sending the path computation | request to the selected PCE | | | _________________ __________________________________ | |4. Whether to | | | | | Response the | | ____________________ | | |RES in domain A or| | | | | | | to the | | | The Message Parser | | | | next hop RES | | | | | | /|is depending on the | | | | | / | output of path | | -------------------- | | / | computer | | | | | / ------------------ | | | | / | 2.Delivering the message | | / | to policy parser or directively | | / | to path computer according to | |/ ------------------- | the information carried |----+-----| RES | | | | | | in Domain B | | ----------- ----------- | ------------------- | | | | | | | | The | | Path | | | | Policy | |Computation| | | | Parser | | Module | | | | | | | | | ----------- ----------- | | | | | | 3.Passing the reques to path | | computer after policy parsing | | | | The Selected PCE | |__________________________________| Fig.2 The path computation request handlling procedure of PCE 5. Different Application Scenarios Cooperation between PCE and DRC is one of the key issues in the cooperative architecture, for it helps to achieve fast and exact routing due to the advantages of both PCE and DRC. This section will list several typical application scenarios of cooperation between PCE and DRC. Zhao, et al. Expires April 23, 2012 [Page 9] Internet-Draft Cooperation between PCE and DRC October 2011 5.1. Cross layers and cross domains It is necessary for PCE to collaborate with DRC when the requirements for path computation occur in multi-layer and multi-domain GMPLS networks. PCE could be shared among several domains or layers and make the best use of the inter-domain and inter-layer network resources, so it is more suitable for inter-domain or inter-layer path computation. In contrast to PCE, DRC usually runs to fulfill intra-domain or intra-layer routing. 5.2. Independent coexistence Both PCE and DRC are working independently under this scenario. While one customer applies a TE-LSP computation, the respective RES/ RESs could select PCE or DRC arbitrarily. Of course each time only one path computation engine can be selected. If a lot of applications for path computation arrive simultaneously, the burst computing load may be also balanced between them according to the implementation of RES. The changing topology and resource status information should be maintained in PCE and DRC in time although it is difficult to manage the information synchronization on both sides. 5.3. Security backup The cooperation mechanisms among different engines make it possible that PCE and DRC backup each other to enhance the routing security and reliability, since they both satisfy the demands of path computation from customers. When the working engine (e.g. PCE) fails, computation tasks could be switched to another reserved engine (e.g. DRC) as soon as possible. In such a case both PCE and DRC should maintain the accordant network topology and resource status information. 5.4. Policy-enabled In order to compute the optimal path in consideration of traffic engineering, different policies are implemented, which mean there are series of rules and actions from management plane or control plane. PCE is obviously more suitable for policy-enabled path computation framework than DRC. Tab.1 lists some typical policy application instances that may be exerted to the cooperative path computation architecture. Effective combinations of the above scenarios as well as possible new scenarios could occurence in the real networks. Zhao, et al. Expires April 23, 2012 [Page 10] Internet-Draft Cooperation between PCE and DRC October 2011 +------------------------+------------------------------------------+ | Policy application | Description | | scenarios | | +------------------------+------------------------------------------+ | Policy configured | To centrally administer configured paths | | paths | | | Provider selection | To be applied in multi-provider | | policy | topologies | | Policy based | To provide constraints in a path | | constraints | computation request | | Advanced load | To balance the traffic load for the | | balancing | whole network | +------------------------+------------------------------------------+ Policy-enabled path computation instances Table 1 5.5. Constraint-based Constraint-based path computation is a basic function especially for TE-LSP establishment. Available bandwidth, diversity, Shared Risk Link Group (SRLG), optical impairments, wavelength continuity and other constraints are likely to be considered. However, it is difficult to compute an optimal path with these constraints under the condition of the general GMPLS/ASON routing architecture. The centralized operation manner makes PCE easy to fulfill constraint- based path computation. 5.6. Service-oriented PCEs can collaborate to finish constraint-based path computation without sharing TE information with each other, which are particularly useful when end-to-end constraints have to be taken into account because of protection and path diversity. PCEs should play an important role in service-oriented applications such as Layer 1 Virtual Private Network (L1 VPN), Bandwidth on Demand (BoD) and so on. Based on GMPLS/ASON architecture, the advantages of PCE and service plane can be combined to implement the framework of service- oriented application. 5.7. Cooperation between network level and node level In this application scenario, PCE maintains Traffic Engineering Databases (TEDs) to keep network topology, and DRC maintains Resource Information Databases (RIDs) to keep node internal topology and resource status. Both of them maintain the status information within the scope of their functions. Routing Engine Selector (RES) is Zhao, et al. Expires April 23, 2012 [Page 11] Internet-Draft Cooperation between PCE and DRC October 2011 responsible for managing the switchover process between PCE and DRC and choosing the right one when a LSP setup request arrives. The interconnection between different nodes is becoming the routing problem generally, which can be solved by PCE framework effectively, especially in multi-domain, multi-layer and multi-constraints scenarios, while the interconnection within the node is the problem of resource allocation and configuration, which refers to internal resource allocation, ports interconnection, and switch fabric configuration. Through the cooperation of PCE and DRC, we can make resource configuration more effectively and improve the performance of the entire optical networks. 6. PCEP Extension Requirements As an extension of PCC, RES can not only complete the communication between PCE and DRC, but also complete the cooperation between PCE and DRC. There are some PCEP extension requirements for the cooperative path computation architecture and the procedure. 6.1. PCEP extension requirement for the communication between RES and PCE PCEP is the communication protocol between RES and PCE. However, there is some extension requirement for PCEP in the cooperative path computation architecture. Firstly, an identification which appoints different application scenarios should be added to the path computation request messages from RES to PCE, and the corresponding data structure should be defined according to different identifications. For example, in the policy-enabled scenario, a policy object is necessary to be defined in the message sent from RES to PCE, and PCE should be able to parse the different policies and conduct the corresponding operations during the procedure of path computation. Secondly, in the reply message from PCE to RES, some indication information should be contained besides the routes information, such as the inter-domain loose path or the intra-domain path, the complete end-to-end path or section path, some failure information and path computation engine switchover requests. 6.2. PCEP extension requirement for the communication between RES and DRC DRC can complete the path computation in local domain in the distributed method, which is usually implemented in the OSPF-TE Zhao, et al. Expires April 23, 2012 [Page 12] Internet-Draft Cooperation between PCE and DRC October 2011 module of GMPLS-based control plane. After the path computation, DRC returns the computation results to RES (CC) including the detailed routes or some failure or indication information. As another important application, DRC can complete the path computation, resource management and configuration in the internal node even the node structure is getting more and more complex. In this application scenario, DRC has the function of routing and resource allocation. In all the application scenarios, DRC has all the analogous functions with PCE and some different extension functions, such as the functions above. So there is a requirement for application scenarios identification in the communication message between RES and DRC. The communication protocol between RES and DRC is necessary to be standardized because of that the function of control node is getting more and more complex. Because RES and DRC are implemented in the same control node and DRC has similar functions with PCE, a simplified PCEP can be used as the communication protocol between RES and DRC, which can include the path computation request, identification and reply messages only. 7. Other Protocol Extension Requirements 7.1. OSPF-TE extension requirement for the cooperative architecture In the cooperative path computation architecture, the topology and TE information should be kept and synchronized at each control node and PCE in local domain, and should also be updated as soon as any change occurs. Meanwhile, all the inter-domain links and TE information should be kept and synchronized at each PCE. So there is an extension requirement for OSPF-TE to guarantee the information at each node synchronized in time. Besides the normal topology and TE information, some other constraints information may be necessary to be contained in the OSPF-TE protocol flooding in the entire networks, such as the physical impairment information. Then there is an extension requirement for the OSPF-TE protocol to enable the synchronization of all the constraint information at each node, which is of great value for the path computation and resource allocation. 7.2. RSVP-TE extension requirement for the cooperative architecture In different cooperation modes between PCE and DRC, an end-to-end path may be computed by several PCE and DRC, and then be setup by signaling from the source node to the destination node. However, Zhao, et al. Expires April 23, 2012 [Page 13] Internet-Draft Cooperation between PCE and DRC October 2011 sometimes an end-to-end path which crosses domains or layers may be computed and setup section by section. Signaling should be triggered when a section path is gained. The current RSVP-TE protocol is necessary to be extended to support this application scenario. Furthermore, as the scheme of path and resource allocation in the internal node is gained, the resource reservation and action of switches are need to be conducted by some protocol as the control node is getting more and more complex. RSVP-TE is the optimal option for this need, and to be extended. 8. Discussions According to the development of GMPLS networks, the cooperative architecture can be introduced in two steps. First, PCE and DRC can cooperate with each other to complete the path computation of the entire networks at network level. Second, PCE and DRC can cooperate with each other to complete the path computation at network level and resource computation and allocation at node level with the network size increasing and node structure getting complex. 9. Security Considerations The cooperation between PCE and DRC can enhance the security of networks because they can backup each other. However, because the information is kept at both PCE and DRC, especially in the condition of the exchanging of information across domain boundaries is necessary in the multi-domain operations, there are some security and confidentiality risks, which can be minimized through the inheritance of the security requirement defined [RFC5440] and [RFC5376]. 10. Acknowledgments The RFC text was produced using Marshall Rose's xml2rfc tool. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", RFC 2119, March 1997. [RFC4665] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. Zhao, et al. Expires April 23, 2012 [Page 14] Internet-Draft Cooperation between PCE and DRC October 2011 11.2. Informative References [1] Nishioka, Itaru., "End-to-End path routing with PCEs in multi-domain GMPLS networks", July 2008. [2] Jabbari, Bijan., "On Constraints for Path Computation in Multi-Layer Switched Networks", August 2007. [3] Giorgetti, A. and F. Paolucci, "Routing and Wavelength Assignment in PCE-based Wavelength Switched Optical Networks", September 2008. [4] Hayashi, Michiaki., "Advance Reservation-Based Network Resource Manger for Optical Networks", February 2008. Authors' Addresses Yongli Zhao BUPT No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China Phone: +8613811761857 Email: yonglizhao@bupt.edu.cn URI: http://www.bupt.edu.cn/ Jie Zhang BUPT No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China Phone: +8613911060930 Email: lgr24@bupt.edu.cn URI: http://www.bupt.edu.cn/ Zhao, et al. Expires April 23, 2012 [Page 15] Internet-Draft Cooperation between PCE and DRC October 2011 Ruiquan Jing China Telecom Beijing Research Institute 118 Xizhimenwai Avenue Beijing 100035 P.R.China Phone: +86-10-58552000 Email: jingrq@ctbri.com.cn URI: http://www.ctbri.com.cn/ Dajiang Wang ZTE Corporation No.16,Huayuan Road,Haidian District Beijing 100191 P.R.China Phone: +8613811795408 Email: wang.dajiang@zte.com.cn URI: http://www.zte.com.cn/ Xihua Fu ZTE Corporation West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District Xi'an 710065 P.R.China Phone: +8613798412242 Email: fu.xihua@zte.com.cn URI: http://www.zte.com.cn/ Zhao, et al. Expires April 23, 2012 [Page 16]