Network Working Group YL. Zhao Internet-Draft J. Zhang Intended status: Informational BUPT Expires: April 21, 2011 DJ. Wang XH. Fu ZTE Corporation October 18, 2010 Protocol Extension Requirement for Cooperation between PCE and Distributed Routing Controller in GMPLS Networks draft-zhaoyl-pce-dre-00 Abstract Path Computation Element (PCE) and distributed routing controller in GMPLS networks have different advantages of path computation respectively. PCE is suitable for the path computation in multi- layer and multi-domain networks, especially in multi-constraints environment. While distributed routing controller is good at the path computation in parallel and distributed network control in the local domain. A cooperative path computation architecture named Dual Routing Engine (DRE) is proposed, which is based on the two path computation engines and can combine the advantages of centralized and distributed. The corresponding PCE communication protocol extension and other protocol requirements for cooperation between PCE and distributed routing controller are listed in this document. 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- 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 21, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the Zhao, et al. Expires April 21, 2011 [Page 1] Internet-Draft Cooperation between PCE and DRC October 2010 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 3. General Assumptions . . . . . . . . . . . . . . . . . . . . . 4 4. Cooperative Architecture based on PCE and Distributed Routing Controller . . . . . . . . . . . . . . . . . . . . . . 5 4.1. DRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. PCE . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Different Application Scenarios . . . . . . . . . . . . . . . 7 5.1. Cross layers and cross domains . . . . . . . . . . . . . . 7 5.2. Independent coexistence . . . . . . . . . . . . . . . . . 7 5.3. Security backup . . . . . . . . . . . . . . . . . . . . . 7 5.4. Policy-enabled . . . . . . . . . . . . . . . . . . . . . . 7 5.5. Constraint-based . . . . . . . . . . . . . . . . . . . . . 8 5.6. Service-oriented . . . . . . . . . . . . . . . . . . . . . 8 5.7. Cooperation between network level and node level . . . . . 8 6. PCEP Extension Requirements . . . . . . . . . . . . . . . . . 9 6.1. PCEP extension requirement for the communication between RES and PCE . . . . . . . . . . . . . . . . . . . 9 6.2. PCEP extension requirement for the communication between RES and DRC . . . . . . . . . . . . . . . . . . . 10 7. Other Protocol Extension Requirements . . . . . . . . . . . . 10 7.1. OSPF-TE extension requirement for the cooperative architecture . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. RSVP-TE extension requirement for the cooperative architecture . . . . . . . . . . . . . . . . . . . . . . . 11 8. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Zhao, et al. Expires April 21, 2011 [Page 2] Internet-Draft Cooperation between PCE and DRC October 2010 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]. Then 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 prove 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 potentially applied to resource allocation and routing optimization [3-4]. While traditional distributed routing controller (DRC) in GMPLS/ASON control plane is good at the path computation in parallel and distributed network control in the local domain. On the other hand, as the huge bandwidth requirement emerges, capacity of Tbit/s transmission links and Pbit/s switching are necessary for next generation optical networks. According to the current photonics technology level, the node architecture will be very complicated and of large power consumption. Then how to configure the switching architecture in the node will be very important for the entire network performance. DRC can also be used for the management and configuration of resource in the internal node. Of course, both PCE and DRC have corresponding different disadvantages respectively. In order to optimize the performance of optical networks under different application scenarios, PCE and distributed routing controller need to cooperate with each other. A cooperative path computation architecture named Dual Routing Engine (DRE) is proposed, which includes two path computation engines, i.e. PCE and distributed routing controller, and can combine their advantages. Several different application scenarios are described in this document. PCE communication protocol extension and other protocol extension requirements for cooperation between PCE and distributed routing controller are 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]. 2. Terminologies LSR: Label Switching Router. Zhao, et al. Expires April 21, 2011 [Page 3] Internet-Draft Cooperation between PCE and DRC October 2010 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 the local domain or the 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, we make some assumptions as follows. o Each GMPLS-based control node is equipped with a distributed routing controller which can complete the path computation in the local domain, even the path computation and resource configuration in the internal node, and each domain is equipped with no less than one PCE which cannot 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. 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 path computation including the intra-domain path and inter-domain path. Zhao, et al. Expires April 21, 2011 [Page 4] Internet-Draft Cooperation between PCE and DRC October 2010 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 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 while a LSP setup request arrives. At the same time, RES posses the function of PCC and can be implemented in Connection Controller (CC) module of GMPLS-based control plane. ------- ------- | 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 Zhao, et al. Expires April 21, 2011 [Page 5] Internet-Draft Cooperation between PCE and DRC October 2010 networks 4.1. DRC DRC offers general routing functions based on GMPLS/ASON control plane including link state advertisement, topology update and path computation. A typical DRC contains two essential modules which are topology analysis module and path computer module. The former floods network topology and resource utilization information to maintain a TED in each node. The latter responds to a routing request from Connection Controller (CC), finds the optimized path solution and returns it to CC. Except the general routing functions, DRC can also complete the resource allocation and configuration, which refers to internal resource allocation, ports interconnection, and switch fabric configuration in the internal node. This function is getting more and more important with the structure of the internal node getting more and more complex. Details of DRC operation are out of this document. 4.2. PCE PCE has the advantage of centralized path computation especially 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. Firstly RES makes choice of the best PCE based on a certain policy. 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 one is feasible. Then a combination of RES and PCE is founded. Secondly PCE serves to deal with the path computation requests coming from RES through message parser. If a request carries path information, it will be directed towards path computer. If it carries policy information from RES, it is first 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 are 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 21, 2011 [Page 6] Internet-Draft Cooperation between PCE and DRC October 2010 5. Different Application Scenarios Cooperation between PCE and DRC is one of the key issues for the cooperative architecture, which 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. 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. DRC runs usually to fulfill intra-domain or intra- layer routing in contrast to PCE. 5.2. Independent coexistence Both PCE and DRC are working independently under this scenario. While one customer applies a TE-LSP computation RES could select PCE or DRC arbitrarily. Of course only one path computation engine can be selected at each time. If a lot of applications for path computation arrive simultaneously, the burst computing load may be also balanced between them. The changed topology and resource status information have to be maintained in PCE and DRC. So it is difficult for the management of 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 have to 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 which mean series of rules and actions from management plane or control plane are involved. 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. Zhao, et al. Expires April 21, 2011 [Page 7] Internet-Draft Cooperation between PCE and DRC October 2010 Effective combinations of the above scenarios as well as possible new scenarios could occur in the real networks. +------------------------+------------------------------------------+ | 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 of 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 Zhao, et al. Expires April 21, 2011 [Page 8] Internet-Draft Cooperation between PCE and DRC October 2010 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 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 general routing problem, 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 with PCE and DRC, but also complete the cooperation between PCE with 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, the path computation request messages from RES to PCE should be added an identification which appoints different application scenarios, 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 except 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. Zhao, et al. Expires April 21, 2011 [Page 9] Internet-Draft Cooperation between PCE and DRC October 2010 6.2. PCEP extension requirement for the communication between RES and DRC DRC can complete the path computation in the local domain in distributed method, which is usually implemented in the OSPF-TE module of GMPLS-based control plane. After the path computation, DRC returns the computation results to RES (CC) including the detailed routes and some failure or indication information. As another important application, DRC can complete the path computation, resource management and configuration in the internal node with the node structure 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 the analogous functions with PCE and some different extension functions, such as the functions above. So there is 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 as the function of control node getting more and more complex. Because RES and DRC are implemented in the same control node and DRC has similar functions with PCE, then 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 the 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 extension requirement for OSPF-TE to guarantee the information at each node synchronized in time. Except 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 physcial 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. Zhao, et al. Expires April 21, 2011 [Page 10] Internet-Draft Cooperation between PCE and DRC October 2010 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, 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 to be conducted by some protocol as the control node is getting more and more complex. RSVP-TE is the optimal option for this function, 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 each DRC, especially the exchange of information across domain boundaries is necessary in the multi- domain operation, there is some security and confidentiality risk, which can inherits the security requirement defined [RFC5440] and [RFC5376]. 10. Acknowledgments The RFC text was produced using Marshall Rose's xml2rfc tool. 11. References Zhao, et al. Expires April 21, 2011 [Page 11] Internet-Draft Cooperation between PCE and DRC October 2010 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. 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 21, 2011 [Page 12] Internet-Draft Cooperation between PCE and DRC October 2010 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 21, 2011 [Page 13]