Network Working Group Young Lee Internet Draft Huawei Technologies Intended status: Informational Greg Bernstein Expires: April 2014 Grotto Networking Ning So Tata Communications October 14, 2013 Network Control Function Virtualization for Transport SDN draft-lee-network-control-function-virtualization-00.txt Abstract This presentation explores the concept of network control function virtualization for transport SDN to help evolve transport networks to provide programmable virtual network services with infrastructure changes to the traditional control plane architecture. 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 April 14, 2014. Lee, et al. Expires April 14, 2014 [Page 1] Internet-Draft Network Control Function Virtualization October 2013 Copyright Notice Copyright (c) 2013 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. Table of Contents 1. Terminology....................................................2 2. Requirements Language..........................................2 3. Introduction...................................................3 4. Transport SDN Control Architecture.............................4 5. Transport SDN Virtual Network Service..........................6 6. Summary and Conclusion........................................11 7. Acknowledgments...............................................11 8. References....................................................11 8.1. Informative References...................................11 9. Contributors..................................................12 Authors' Addresses...............................................12 Intellectual Property Statement..................................12 Disclaimer of Validity...........................................13 1. Terminology This document uses the terminology defined in [RFC4655], and [RFC5440]. 2. Requirements Language 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]. Lee, et al. Expires April14,2014 [Page 2] Internet-Draft Network Control Function Virtualization October 2013 3. Introduction One of the main drivers for SDN has been a separation of network control plane from forwarding plane. This separation alone, however, would not provide much benefit for transport SDN as this separation has been already achieved by control plane technology such as GMPLS/ASON for transport networks. In fact, in transport networks such separation of data and control plane was dictated at the onset due to the very different natures of the data plane (circuit switched TDM or wavelength) and a packet switched control plane. Another attraction of SDN technology is its logically centralized control regime which allows a global view of the underlying networks under its control. The centralized control of SDN helps improve network resource utilization from a distributed network control. Transport networks have long used this centralized model via network management systems and currently supplement it with topology and resource status information gathered dynamically via GMPLS routing. For transport network control, PCE technology is essentially equivalent to a logically centralized control for path computation function. By combining the strength of GMPLS/ASON [GMPLS] and PCE [PCE], transport network control plane technology has already been in a position to take advantage of these SDN concepts. However, the current transport network control plane technology is not suitable for virtualization and client programmability, which are the two of the main drivers for SDN in recent years. Virtualization refers to allowing the clients to utilize a certain amount of network resources as if they own them and thus control their allocated resources in a way most optimal with higher layer or application processes. This empowerment of client control facilitates introduction of new services and applications as the clients are given to create, modify, and delete their virtual network services. The level of virtual control given to the clients can vary from a tunnel connecting two end-points to virtual network elements that consist of a set of virtual nodes and virtual links in a mesh network topology. As part of the VNS, a client control concept is added to the traditional VPN along with a client specific virtual network view. Client control is operated on the view of virtual network resources allocated to the client. This view is called abstracted network topology. Such a view may be specific to the set of client services as well as the particular client. As the client control is envisioned to support a plethora of applications, there is another level of virtualization from the client to individual applications. Lee, et al. Expires April14,2014 [Page 3] Internet-Draft Network Control Function Virtualization October 2013 4. Transport SDN Control Architecture To allow virtualization, the network has to provide open, programmable interfaces in which clients/applications can create, replace, modify virtual network services in an interactive manner while having no impact on other network clients. Traditional transport network infrastructure is not suitable for providing programmable interfaces to clients. Direct client control of transport network elements over existing programmable interfaces (control or management plane) is not perceived as a viable proposition for transport network providers due to security and policy concerns among other reasons. Hence, the need for network control function virtualization where there is a "virtualizer" that interfaces directly with client control and translates/allocates resources (from physical to virtual and vice versa) and creates abstracted network topology for each client and interacts with physical network connection control functions (e.g., GMPLS/ASON for provisioning, PCE for path computation). The Network control function virtualizer maintains two interfaces: one interface with physical network control functions assumed by GMPLS/ASON and PCE, which is termed as VNC-PNC Interface (VPI); another interface with client control of virtual network, which is termed as Client-VNC Interface (CVI). Figure 1 depicts the overall architecture for transport SDN control in which the virtual network control entity provides network control function virtualization. Lee, et al. Expires April14,2014 [Page 4] Internet-Draft Network Control Function Virtualization October 2013 ------------------------------------------ | Application Stratum | ------------------------------------------ /|\ /|\ /|\ | | \|/ North Bound API | | --------------- | \|/ | Client | | -------------- Control | \|/ | Client |-------- -------------- Control | /|\ | Client |------- | | Control | /|\ | -------------- | | /|\ | | Client-VNC Interface | | | (CVI) \|/ \|/ \|/ ---------------------------------- | Virtual Network Control (VNC) | ---------------------------------- /|\ | VNC-PNC Interface (VPI) \|/ ---------------------------------- | Physical Network Control (PNC) | ---------------------------------- /|\ | Control Interface to NEs \|/ Physical Network Infrastructure Figure 1: Transport SDN control architecture Figure 1 shows that there are multiple client controls which are independent to each other and that each client supports various business applications over its NB API. There are layered client- server relationships in this architecture. As various applications are clients to client control, client control itself is also a client to virtual network control; likewise, virtual network control is also a client to physical network control. This layered relationship is important in protocol definition work on NB API, CVI and VPI interfaces as this allows third-party software developers to Lee, et al. Expires April14,2014 [Page 5] Internet-Draft Network Control Function Virtualization October 2013 program client control and virtual network control functions in such a way to create, modify and delete virtual network services. 5. Transport SDN Virtual Network Service Virtual Network Service is instantiated by the client control via the CVI. As client control directly interfaces the application stratum, it understands multiple application requirements and their service needs. It is assumed that client control and VNC have the common knowledge on the end-point interfaces based on their business negotiation prior to service instantiation. End-point interfaces refer to client-network physical interfaces that connect client premise equipment to network provider equipment. Figure 2 shows an example physical network topology that supports multiple clients. In this example, client A has three end-points A.1, A.2 and A.3. The interfaces between clients and transport networks are assumed to be 40G OTU links. For simplicity's sake, all network interfaces are assumed to be 40G OTU links and all network ports support ODU switching and grooming on the level of ODU1 and ODU2. Client control for A provides its traffic demand matrix that describes bandwidth requirements and other optional QoS parameters (e.g., latency, diversity requirement, etc.) for each pair of end-point connections. Figure 2 shows that three independent clients A, B and C provide its respective traffic demand matrices to the VNC. The physical network topology shown in Figure 2 is the provider's network topology created by the PNC's topology creation engine such as the link state database (LSDB) and Traffic Engineering DB (TEDB) based on control plane discovery function. This topology is internal to PNC and not available to the client. What is available to the client is abstracted network topology (aka, virtual network topology) based on the negotiated level of abstraction. This is a part of VNS instantiation between a client control and VNC. Lee, et al. Expires April14,2014 [Page 6] Internet-Draft Network Control Function Virtualization October 2013 +------+ +------+ +------+ A.1 ------o o-----------o o----------o o------- A.2 B.1 ------o 1 | | 2 | | 3 | C.1 ------o o-----------o o----------o o------- B.2 +-o--o-+ +-o--o-+ +-o--o-+ | | | | | | | | | | | | | | | | | | | | +-o--o-+ +-o--o-+ | `-------------o o----------o o------- B.3 | | 4 | | 5 | `----------------o o----------o o------- C.3 +-o--o-+ +------+ | | | | | | C.2 A.3 Traffic Matrix Traffic Matrix Traffic Matrix for Client A for Client B for Client C A.1 A.2 A.3 B.1 B.2 B.3 C.1 C.2 C.3 ------------------- ------------------ ----------------- A.1 - 20G 20G B.1 - 40G 40G C.1 - 20G 20G A.2 20G - 10G B.2 40G - 20G C.2 20G - 10G A.3 20G 10G - B.3 40G 20G - C.3 20G 10G - Figure 2: Physical network topology shared with multiple clients Figure 3 depicts illustrative examples of different level of topology abstractions that can be provided by the VNC topology abstraction engine based on physical topology base maintained by the PNC. The level of topology abstraction is expressed in terms of the number of virtual network elements (VNEs) and virtual links (VLs). For example, the abstracted topology for client A shows there are 5 VNEs and 10 VLs. This is by far the most detail topology abstraction with a minimal link hiding compared to other abstracted topologies in Figure 3. Lee, et al. Expires April14,2014 [Page 7] Internet-Draft Network Control Function Virtualization October 2013 Abstracted Topology for Client A (5 VNEs and 10 VLs) +------+ +------+ +------+ A.1 ------o o-----------o o----------o o------- A.2 | 1 | | 2 | | 3 | | | | | | | +-o----+ +-o----+ +-o----+ | | | | | | | | | | +-o----+ +-o--o-+ | | | | | | | 4 | | 5 | `----------------o o----------o | +----o-+ +------+ | | | A.3 Abstracted Topology for Client B (3 VNEs and 6 VLs) +------+ +------+ B.1 ------o o-----------------------------o o------ B.2 | 1 | | 3 | | | | | +-o----+ +-o----+ \ | \ | \ | `------------------- | ` +-o----+ \ | o------ B.3 \ | 5 | `-------o | +------+ Lee, et al. Expires April14,2014 [Page 8] Internet-Draft Network Control Function Virtualization October 2013 Abstracted Topology for Client B (1 VNE and 3 VLs) +-------------------------------------------+ | | | | C.1 ------o | | | | | | | | o--------C.3 | | +--------------------o----------------------+ | | | | C.2 Figure 3: Topology Abstraction Examples for Clients As different client has different control/application needs, abstracted topologies for client B and C, respectively show much less degree of abstraction. The level of topology abstraction is determined by the policy (e.g., the granularity level) placed for the client and/or the path computation results by the PNC's PCE. The more granular the abstraction topology is, the more control is given to the client control. If the client controller has applications that require more granular control of virtual network resources, then abstracted topology for client A may be the right abstraction level for such client controller. For instance, if the client is a third-party virtual service broker/provider, then it would desire much more sophisticated control of virtual network resources to support differing application needs. On the other hand, if the client were only to support simple tunnel services to its application, then abstracted topology for client C that consists of one VNE and three VLs would suffice. Lee, et al. Expires April14,2014 [Page 9] Internet-Draft Network Control Function Virtualization October 2013 Figure 4 shows workflows across client control, VNC and PNC for the VNS instantiation, topology exchange, and VNS setup. Client control "owns" a VNS and initiates by providing the instantiation identifier with the traffic demand matrix with path selection constraints for that instance. This VNS instantiation request from Client Control triggers a path computation request by the virtual PCE (vPCE) agent in the VNC after VNC's proxy's interlay of this request to the vPCE. vPCE requests a concurrent path computation request that is converted based on the traffic demand matrix as part of the VNS instantiation request from Client Control. Upon receipt of this path computation request, the PCE in the PNC block computes paths and updates network topology DB and informs the vPCE agent of the VNC of the paths and topology updates. ------------------------------------------------------------------ | Client ----------------------------------------------- | | Control | VNS Control | | | ----------------------------------------------- | ------------------------------------------------------------------ 1.VNS | /|\ 4. Abstracted | /|\ Instantiation | | Topology | | (instance id, | | | | Traffic Matr.) | | | | 8. VNS | | 5. VNS | | Set-up \|/ | Set-up \|/ | Confirm ------------------------------------------------------------------ | Virtual ------------------------------------------ | | Network | VNS Proxy | | | Control ------------------------------------------ | | ----------------------- ----------------------- | | | vPCE Agent | | vConnection Ageet | | | ----------------------- ----------------------- | ------------------------------------------------------------------ 2. Path | /|\ 3. PC Reply | /|\ Computation | | with updated | | Request | | topology | | | | 6. Network | |8.Network | | Provisioning | |Provisioning \|/ | Request \|/ |Confirm ------------------------------------------------------------------ | Physical ------------- -------------------------- | | Network | PCE | | Network Provisioning || | Control ------------- -------------------------- | ------------------------------------------------------------------ Figure 4. Workflows across Client control, VNC and PNC Lee, et al. Expires April14,2014 [Page 10] Internet-Draft Network Control Function Virtualization October 2013 It is assumed that the PCE in PNC is a stateful PCE [PCE-S]. vPCE agent abstracts the network topology into an abstracted topology for the client based on the agree-upon granularity level. The abstracted topology is then passed to the VNS control of the Client Control block. The Client Control's VNS control computes and assigns virtual network resources for its applications based on the abstracted topology and creates VNS setup command to the VNC. The VNC's vConnection module turns this VN setup command into network provisioning requests over the network elements using control plane messages such as GMPLS, etc. 6. Summary and Conclusion This presentation explores the concept of network control function virtualization for transport SDN to help evolve transport networks to provide programmable virtual network services with infrastructure changes to the traditional control plane architecture. The VNC and its interfaces with the Client Control and the PNC provide control plane function virtualization over programmable interfaces such as virtual network path computation and optimization, topology abstraction hiding details of physical topology while supporting service-specific objectives the clients demand, maintaining virtual network service instances and the states, policy enforcement for virtual network services. With this evolutionary architecture, virtual network services can be readily introduced while re-using physical network control plane functions. 7. Acknowledgments The authors would like to thank Adrian Farrel for many helpful comments that greatly improved the contents of this draft. This document was prepared using 2-Word-v2.0.template.dot. 8. References 8.1. Informative References [PCE] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", IETF RFC 4655, August 2006. Lee, et al. Expires April14,2014 [Page 11] Internet-Draft Network Control Function Virtualization October 2013 [PCE-S] Crabbe, E, et. al., "PCEP extension for stateful PCE",draft-ietf-pce-stateful-pce, work in progress. [GMPLS] Manning, E., et al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture, RFC 3945, October 2004. 9. Contributors Authors' Addresses Young Lee Huawei Technologies 1700 Alma Drive, Suite 100 Plano, TX 75075, USA Phone: (972) 509-5599 (x2240) Email: leeyoung@huawei.com Greg Bernstein Grotto Networking Fremont, CA, USA Phone: (510) 573-2237 Email: gregb@grotto-networking.com Intellectual Property Statement The IETF Trust 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 any IETF 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. Copies of Intellectual Property 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 Lee, et al. Expires April14,2014 [Page 12] Internet-Draft Network Control Function Virtualization October 2013 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 any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lee, et al. Expires April14,2014 [Page 13]