PCE Working Group . Haomian Zheng Internet Draft Xian Zhang Category: Informational Huawei Technologies Expires: August 14, 2014 February 14, 2014 Path Computation Element to Support Software-Defined Transport Networks Control draft-zheng-pce-for-sdn-transport-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 August 14, 2014. Copyright Notice Copyright (c) 2014 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. Zheng et al Expires August 2014 [Page 1]
draft-zheng-pce-for-SDN-transport-00 February 2014 Abstract This draft describes PCE architecture and protocol in SDN-based transport network. It is demonstrated that PCE can fit in the transport SDN architecture and complete corresponding requests. The PCE and its protocol can satisfy the functional requirement in several transport SDN applications. 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]. Table of Contents 1. Introduction ................................................ 2 2. Path Computation in Transport SDN............................ 4 2.1. Transport SDN Architecture.............................. 4 2.2. Path computation and establishment...................... 5 2.2.1 Stateless PCE....................................... 5 2.2.2 Stateful PCE........................................ 5 2.2.3 PCE Initiation...................................... 5 3. PCE Applicability for Transport SDN.......................... 6 3.1. Photonic Enterprise Networks............................ 6 3.2. Virtualized Transport Network........................... 6 3.3. Data center interconnection............................. 8 3.4. Packet Optical Integration............................. 10 4. IANA Considerations ........................................ 11 5. References ................................................. 11 5.1. Normative References................................... 11 5.2. Informative References................................. 11 6. Authors' Addresses.......................................... 12 1. Introduction Software Defined Networking (SDN) is an emerging approach to networking and has great potential to shift paradigm in the field of network control and management. SDN greatly simplifies the network control and management by separating the control plane from data plane, which allows network operators to manage network services on an abstraction of the underlying physical networks. SDN requires some method for the control plane to communicate with the data Zheng Expires August 2014 [Page 2]
draft-zheng-pce-for-SDN-transport-00 February 2014 plane. OpenFlow is one of such mechanisms and is under development to provide standardized communication [OpenFlow]. Specifically, for transport network, the idea of SDN is a perfect choice for future development due to the natural separation of data and control planes. There are some emerging service features and requirements for transport networks that include services that are time scheduled, dynamic, elastic, and underpinned by a Pay As You Go billing model. These features require the transport controllers to provide services with large bandwidth in a short period. All of the above are the motivations for introducing the SDN idea into the transport network. Path Computation Element (PCE) was firstly developed to solve the path computation problem for MPLS and GMPLS-controlled networks [RFC4655]. Given the demand to simplify the network management and a centralized PCE, the functional transport architecture is very close to the idea of Software-defined Networking (SDN). In the SDN architecture, PCE can be envisioned to be a core functional block in the SDN controller, responsible not only for path computation but for other functions such as provisioning and abstraction control. This draft intends to discuss how the PCE architecture and PCEP protocol developed to date can support the transport SDN by analyzing the role PCE plays in some typical use cases. Optical Enterprise network PCE can provide transport service in small-scale enterprise network, which is under a totally centralized control environment. Virtualized transport network PCE can be used for virtual service provisioning. In this way clients can propose various network requests to operators. Data-center Interconnection Current PCE architecture and protocol can support transport services provisioning in data-center Interconnection Networks. Packet-optical Integration Packet traffic can be transported over optical transport network. The path computation in this case can be supported by coordinating between Packet PCE and Optical PCE. Zheng Expires August 2014 [Page 3]
draft-zheng-pce-for-SDN-transport-00 February 2014 This draft describes several classic scenarios in transport network, to demonstrate the current PCE can be extended beyond path computation functionality. There is NO protocol extension (such as PCEP) in this draft. We only focus on how current PCE (including RFCs and some WG/I-D Draft) can satisfy the requirements. 2. Path Computation in Transport SDN 2.1. Transport SDN Architecture A general architecture of transport SDN is shown as follow: +-------------+ | Client | | Controller | +-------------+ /|\ | \|/ +-------------------------+ |Transport +--------+ | | Network | PCE | | |Controller +--------+ | +-------------------------+ /|\ | \|/ +---------------------+ | Physical | | Network | | Infrastructure | +---------------------+ Fig. 1 Generic Architecture of Transport SDN As shown in Fig. 1, transport network controller (TNC) is core block that connects with both clients and physical network infrastructure. PCE is one of the functional blocks in the TNC for path computation. In general, to request a transport service, client controller sends a request with path requirement to TNC. PCE will compute a path according to the request, and report the result to client. For path establishment, the client will trigger the TNC and then TNC will operate on the physical network infrastructure, for example, network elements. Zheng Expires August 2014 [Page 4]
draft-zheng-pce-for-SDN-transport-00 February 2014 2.2. Path computation and establishment 2.2.1 Stateless PCE The PCE Protocol (PCEP) is the protocol that enables the communication between Path Computation Clients (PCCs) and PCE. It was firstly developed to support a stateless PCE with in [RFC4655]. PCCs will send path computation requests via the Path Computation Request (PCReq) message to a Path Computation Elements (PCE). The PCE, upon receiving this request, will calculate a path or multiple paths and reply the result to the PCC via the Path Computation Reply (PCRep) message. During the computation, the PCE has access to the Traffic Engineering Database (TED). Network topology and resource usage information are stored in the TED. Specific path computation algorithms or policy-based routing schemes are out of scope for this draft. Other details for PCEP can be referred to [RFC5440]. 2.2.2 Stateful PCE In stateless PCE the network information is managed in TED. However, the state of active LSPs is not managed by PCE and as such there may some limitations for real-time, dynamic LSP operations with stateless PCE. With dynamic configuration and management request, there will be resource contention problem in PCE. To address this issue, stateful PCE is introduced in [draft-ietf-pce-stateful-pce- 07], with a LSP Database (LSPD) in the PCE. The LSPD allows efficient LSP state synchronization between PCC and PCEs. A delegation mode is proposed, with allowing PCC to delegate control of its LSP to an active stateful PCE. The stateful PCE can be applied in various scenarios, as presented in [draft-ietf-pce-stateful-pce-app-01], including online optimization, bandwidth scheduling, recovery and so on. 2.2.3 PCE Initiation More dynamical management over LSP is proposed in [draft-ietf-pce- pce-initiated-lsp-00], named as PCE initiation. In this mechanism, PCE is able to trigger the creation of LSPs on demand, which is especially suitable for a controller-based network in service provisioning and path setup. One of the typical applications for PCE initiation is the path computing in SDN. When the request is generated from application stratum, the PCE can compute the path and directly set it up, instead of responding and triggering the application to establish the connection. This new mechanism is more efficient than stateful PCE and can provide better real-time performance in a dynamic transport network. Zheng Expires August 2014 [Page 5]
draft-zheng-pce-for-SDN-transport-00 February 2014 3. PCE Applicability for Transport SDN Several applications are proposed under the transport SDN arhictecture to demonstrate its ability to enhance the control and management of transport networks, such as virtual transport services, data center interconnection network and so on. For these applications, PCE is playing an important role. In the following sub-sections, we describe how the PCE and its protocol can support applications in transport SDN via some typical examples. 3.1. Photonic Enterprise Networks +---------+ | PCE | +---------+ / | \ / | \ / | \ / | \ / | \ +-----+ +-----+ +-----+ | NE1 | | NE2 | | NE3 | +-----+ +-----+ +-----+ Fig. 2: PCE Control over Network Element The enterprise networks are usually a small-scale network with limited network elements. For simplicity, we assume in this use case one PCE is enough for path computation, i.e., no multi-domain or inter-PCE communication is involved. As shown in Fig. 2, NEs are directly connected with PCE. NEs can be but not limited to data centers. NEs are considered as PCC to create request for path computation and establishment. PCEP can be used for communication between PCCs and PCE, through the interfaces between PCE and NEs. Stateful PCE is suited for this use case for dynamic service provisioning, since the path is setup by the PCC directly. 3.2. Virtualized Transport Network Virtual transport service (VTS) is one of the advantages of transport SDN. The architecture of providing VTS is described in Fig. 3. Zheng Expires August 2014 [Page 6]
draft-zheng-pce-for-SDN-transport-00 February 2014 +------------+ +-----------+ | Client | | Client | | Controller | ..... | Controller| +------------+ +-----------+ /|\ /|\ | | \|/ \|/ +--------------------------------------------------+ | | | | | Transport +--------------------------------+ | | Controller | Virtual Network Controller | | | +--------------------------------+ | | /|\ | | +-------------+ |Provider Interface| | | Other | \|/ | | | Functional | +-------------+ | | | Blocks | | PCE | | | +-------------+ +-------------+ | +-----------------------//-/---|-----\-------------+ // / | \ // / +--|--+ \ / / | NE | \ // / +-----+ \ // / \ // / \ +-----/ / \ | NE | / +-\---+ +-----+ / | NE | / +-----+ / +--/--+ | NE | +-----+ Fig. 3: Architecture for VTS Provisioning In this use case, the network elements are totally infrastructure and we do not consider NE as PCC anymore. The path computation in this case can be divided into two types: virtual path computation and physical path computation. The virtual path computation requests come from the client controller and are sent to the virtualized network controller (VNC) in the transport controller. Virtual network information such as topology and available resources are stored in the VNC to determine whether the requests can be satisfied or not and then respond the Zheng Expires August 2014 [Page 7]
draft-zheng-pce-for-SDN-transport-00 February 2014 result to client controller. In this procedure, the VNC can be treated as a PCE, and the interaction between client controller (PCC) and VNC (PCE) is achieved via corresponding interface between PCC and PCE. The physical path computation is similar as described in section 3.1. The PCE is connected with NEs for path computation. VNC projected the virtual path request from client controller to a physical path request and send it to PCE. The request is from the VNC via a provider interface, which can be either considered as an internal interface in transport controller or an external interface between two blocks, depends on implementation policy. By receiving the request, PCE will check the availability of resources and respond to VNC, also via provider interface. The path establishment can be completed by stateless PCE, stateful PCE or PCE initiation. Stateless and stateful PCE will allocate the physical resource by configuring the NEs after receiving the corresponding message from PCC. In PCE initiation, dynamic creation and teardown of LSPs are supported by PCE together with responding LSP information to PCCs. 3.3. Data center interconnection The virtual network services in Data Center Interconnection Network are described in this section. As shown in Fig. 4, the DC controller is connected with network provider controller, while DCs are connected with NEs respectively. In this use case it is assumed that Data center controller knows all information, including endpoints interfaces, resource, location information and any other application/user related information. For the DC interconnection application, the client controller is the DC controller, which can be an internal entity or an external entity with respect to the relationship with the service provider. Zheng Expires August 2014 [Page 8]
draft-zheng-pce-for-SDN-transport-00 February 2014 +------------+ | Data Center| | Controller | +------------+ /|\ | \|/ +------------+ | Network | | Provider | | Controller | +------------+ /|\ +---------+ | +----------+ | Data | | | Data | |Center A | | | Center B | +---------+ \|/ +----------+ \ ------------ / \ //---- ----\\ / \ /// \\\ / \ /// +-----+ \\\ / \ / | NE | \ / \ // +-/---\\ \\ / \ | / \\ | / \ | / \\ / \|+-----/ +----+ / \\ /| |\| NE |-------| NE |/ +\\---+/ | | +---\-+ +-|--+ | NE | | | \ | +-----+ | | \\ | | | \ | Transport | \\ \ | Network // \ \+--/|-+ / \\\ /| NE | /// \\/ +-----+ /// // \\---- ----// / ------------ +-----/----+ | Data | | Center C | +----------+ Fig. 4 Use case: Data Center Interconnection Network In this use case the Network Provider Controller is playing as PCE and DC controller is corresponding PCC. The requests can be either from DC or the DC controller, with the DC controller have a full visibility of all DCs. PCE is used to respond the path computation request, to provide virtual network services. Stateless/Stateful PCE and PCE initiation are all applicable in this case, similar as the way described in Section 4.2. The communication between DC controller and Network Provider Controller can also be implemented via PCEP. Zheng Expires August 2014 [Page 9]
draft-zheng-pce-for-SDN-transport-00 February 2014 3.4. Packet Optical Integration +------------+ | Client | | Controller | +------------+ /|\ | \|/ +------------------------------------------------+ | Network | | Provider | | Controller | +------------------------------------------------+ /|\ /|\ | | \|/ \|/ +---------------+ +---------------+ | Packet | | Optical | | Network | | Network | | Controller | | Controller | +---------------+ +---------------+ /|\ /|\ | | \|/ \|/ /----------\ /----------\ //// IP \\\\ //// Optical \\\\ | Packet | | Transport | | Network | | Network | \\\\ //// \\\\ //// \----------/ \----------/ Fig. 5 Use Case: Packet Optical Integration In this use case we describe packet traffic transported over an optical transport server network (potentially incorporating multiple layer networks), as shown in Fig. 5. The objective of this use case is for packet and optical topologies to be jointly optimized for greater efficiency, taking advantage of knowledge of topologies and status, as well as dynamic capabilities supported by the optical transport network. There can be a few variations for path computation in this case, depends on where the PCE is located. In this draft we assume that there is one PCE located in Packet network controller and another PCE located in Optical Network controller, respectively. A joint optimization is applied by Network Provider controller, which is connected with PCEs, for better resource utilization. Moreover, client controller is also connected with network provider controller. In this case the path computation request is from the client controller. All the three controllers has their respective TED and LSPD (only if stateful or PCE initiation) and there are some Zheng Expires August 2014 [Page 10]
draft-zheng-pce-for-SDN-transport-00 February 2014 synchronization mechanisms among them to guarantee the resource consistency. Once the path computation request arrives the network provider controller, it will be decomposed according to the network topology and sent to the IP-PCE and Optical PCE respectively. The IP-PCE and Optical PCE will then compute the path and respond. The procedure of path establishment is similar as described in section 4.2, which is applicable via stateless PCE, stateful PCE and PCE initiation respectively. Communications among the controllers in Fig. 5 can be achieved by PCEP. 4. IANA Considerations 5. References 5.1. Normative References [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [draft-ietf-pce-pce-initiated-lsp-00] Crabbe, E., Minei, I., Sivabalan, S., Varga. R, PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model, draft-ietf-pce-pce-initiated-lsp-00, December 2013. [draft-ietf-pce-stateful-pce-app-01] Zhang, X., Minei, I., Applicability of Stateful Path Computation Element (PCE), draft- ietf-pce-stateful-pce-app-01, September 2013. [draft-ietf-pce-stateful-pce-07] Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce- stateful-pce-07 (work in progress), October 2013. 5.2. Informative References [Openflow] Openflow Switch Specification, https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf- specifications/openflow/openflow-spec-v1.3.0.pdf Zheng Expires August 2014 [Page 11]
draft-zheng-pce-for-SDN-transport-00 February 2014 6. Authors' Addresses Haomian Zheng Huawei Technologies F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District, Shenzhen 518129 P.R.China Email: zhenghaomian@huawei.com Xian Zhang Huawei Technologies F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District, Shenzhen 518129 P.R.China Email: zhang.xian@huawei.com Zheng Expires August 2014 [Page 12]