OPSAWG H. Zhou Internet-Draft H. Song Intended status: Informational Huawei Expires: January 4, 2015 Q. Fu China Mobile July 4, 2014 Virtual Network Function Configuration Architecture draft-zhou-opsawg-vnf-config-arch-01 Abstract This document describes the architecture of remote service installation and configuration in the provider's network through a centralized management system. This is a typical scenario for virtual network function installation and dynamic configuration in network function virtualization (NFV) context. It is also a typical scenario in cloud computing environment where end users do not have to install applications on their end hosts, but can install their own featured powerful software application in the cloud. This specification describes an architecture of virtual network function installation and configuration. It is also applicable to other use cases with similar requirements. 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 March 27, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Zhou, et al. Expires March 27, 2014 [Page 1] Internet-DraftVirtual Network Function Configuration ArchiSeptember 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Design Principals . . . . . . . . . . . . . . . . . . . . 5 3.2. User-controller . . . . . . . . . . . . . . . . . . . . . 6 3.3. Software Vendor-Controller . . . . . . . . . . . . . . . 7 3.4. Controller-VNF . . . . . . . . . . . . . . . . . . . . . 7 3.5. Controller-Infrastructure . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction This document describes the architecture to solve the problems described in [I-D.song-opsawg-virtual-network-function-config], In virtual network function configuration. The network function virtualization (NFV) controller is a broker for various software vendors. It manages how to install a virtual network function in the provider's network according to user's requirements. There needs standard protocols between user and NFV controller to describe the components requirements and resource requirements for a (or a batch of) virtual network function installation and configuration. There also needs a standard protocol between software vendor and NFV controller to describe the software basic information, running environment resource requirements, components information description. The component of a virtual network function may be another virtual network function. And the NFV controller may combine some virtual network functions together to form another virtual network function. If layer N (N can be 1, 2, 3...) virtual network function is consisted of several layer N-1 virtual network functions, the NFV controller must communicate with the user on how to construct the upper layer VNF with lower layer VNFS, and what are the Zhou, et al. Expires March 27, 2014 [Page 2] Internet-DraftVirtual Network Function Configuration ArchiSeptember 2013 forwarding sequences and what are the conditions to trigger that forwarding sequence. The resource requirements from the user can be either explicit or implicit. If the resource requirement is "on- demand", then the NFV controller has to communicate with the virtual network function layer to create new service instances when the service load is increasing or delete extra service instances when the service load is decreasing. The resource requirements for each service instance is based on the recommendation from the software vendor. This specification gives a basic management architecture for virtual network function (VNF) configuration. It lists the main functional modules that plays important roles in VNF configuration, and specifies what each functional module does, and what are the contents communicated among these functional modules, as depicted in Figure 1. The main concepts from this document are from ETSI NFV ISG [NFVE2E] . But there is slightly difference from ESTI. For example, we have a central NFV controller in this architecture that contains OSS/BSS, VNF management and Infrastructure management, unlike ESTI NFV ISG, where it separates the OSS/BSS and a management and orchestration system. In real world implementation, these functional units usually reside in the same physical equipment(s) called network management system. OSS/BSS (operations support system / business support system) functional module is responsible for communication with users. It provides software (VNF) provider's information to the users, and get components requirements and resource requirements from the users. It also communicates with VNF software vendors to get the software information and the recommended resource information, and etc.. VNF management module is responsible for VNF instance creation/deletion, VNF status management, VNF resource management, and VNF connection management when one VNF is represented as a conditional/static connection of multiple VNFs. Infrastructure management module is responsible for physical layer resource (CPU, memory, storage, bandwidth etc.) allocation for the virtual machine that a VNF is resided on. This document will describe the basic principle for the architecture first, then give the description of the interfaces and what contents are exchanged among those interfaces. At the end, it will discuss the security threats for the VNF configuration. Zhou, et al. Expires March 27, 2014 [Page 3] Internet-DraftVirtual Network Function Configuration ArchiSeptember 2013 +----------------------------------------------+ | Controller | | +----------+-----------+ | | | | | | | +---------+-+ +-----+----+ +----+----------+| | |OSS/BSS | |VNF | | Infrastructure|| | | | |Management| | Management || | ++--------+-+ +------+---+ +------+--------+| | | | | | | +--+--------+-----------+------------+---------+ | | | | | | | | | | | | +----++ +----+------+ ++-+ +-----+--------+ |User | |VNF | |V | |NFV | +-----+ |Software | |N | |Infrastructure| |Vendor | |F | +--------------+ +-----------+ +--+ / \ / \ +------+ +------+ |VNF |-->|VNF | +------+ +------+ Figure 1 Virtual Network Function Configuration Framework 2. Terminology 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]. And the following terms used in this document have their definitions from the NFV end to end architecture [NFVE2E]. User: a person, home or an enterprise customer who installs their own virtual network function (such as virtual enterprise firewall, virtual home gateway) in the provider's network. A user can also be the provider's network system administrator who want to install a general virtual network function (such like the carrier grade network address translator (NAT) ) that can server various customers inside the provider's network NFV: network function virtualization. NFV technology uses the commodity servers to replace the dedicated hardware boxes for the network functions, for example, home gateway, enterprise access router, carrier grade NAT and etc. So as to improve the reusability, allow more vendors into the market, and reduce time to market. NFV Zhou, et al. Expires March 27, 2014 [Page 4] Internet-DraftVirtual Network Function Configuration ArchiSeptember 2013 architecture includes a NFV controller (orchestrator) to manage the virtual network functions and the infrastructure resources. NF: A functional building block within an operator's network infrastructure, which has well-defined external interfaces and a well-defined functional behavior. Note that the totality of all network functions constitutes the entire network and services infrastructure of an operator/service provider. In practical terms, a Network Function today is often a network node or physical appliance. vNF: virtual network function, an implementation of an executable software program that constitutes the whole or a part of an NF that can be deployed on a virtualization infrastructure. VM: virtual machines, a program and configuration of part of a host computer server. Note that the Virtual Machine inherits the properties of its host computer server e.g. location, network interfaces. 3. Architecture 3.1. Design Principals There are five key modules in the architecture. They are controller, software vendor, user, VNF, and infrastructure. And the controller has three key functional modules, OSS/BSS, VNF management, and infrastructure management. (1) Controller is the brain of all operations. Controller creates virtual network functions in the provider's network. Although the users may communicate with the virtual network functions in the service layer directly, but it has not to directly communicate with the VNF in the management level. A user can have multiple VNFs in the provider's network, and can configure them or a subset of them through a simple communication with the controller. The controller is also a broker for various software vendors. It provides standard interfaces to convey information model with software vendors and users. It also monitors the VNF resource consumption status when the resource consumption model is "on-demand". (2) Controller MUST NOT be aware of the service logic of each VNF. When a user configures multiple VNFs by sending a configuration template to the controller. The controller does not understand the contents in the configuration template. It only has to know how to apply the configuration to the appropriate VNFs. Zhou, et al. Expires March 27, 2014 [Page 5] Internet-DraftVirtual Network Function Configuration ArchiSeptember 2013 (3) The key point for the protocol development SHOULD focus on the information model to describe the VNF itself, the resource requirements, the service/forwarding graph, and the status report. 3.2. User-controller User communicates with the OSS/BSS module of the controller, to query, buy, or configure VNFs. User gets the VNF list from the query interface. Each VNF in the list contains: VNF type, function description, description of components that can be installed optionally, installation resource requirements, possible performance standard (which may include capable number of users per instance, throughput, concurrent connections, and etc.), and pricing information. User can select the appropriate VNF to install from the list. The information that the user can provide to the OSS/BSS before the installation can be the VNF name, quantity, the preferred components of the VNF, the preferred installation locations in high level (user do not have to know the detailed location such like on which virtual machine), and the possible performance requirement at the beginning (which will be considered when allocating resources, so that even the same VNF provided by the same software vendor can have different initial resource allocation when it is installed to serve different customers that have different amount of users/traffic). User should also tell the controller whether it needs specific resources or it only needs resources on-demand. In the meantime, user should also provide the data forwarding graph to the controller, so that the controller can figure out how the new VNF is connected to the existing network, and how the data flow should forward after the installation of this new VNF. Such forwarding graph should be written in a fixed format in spite of the difference of users. User can get the relative report from the controller, the report contains information of which VNFs have been installed, the status of each VNF, the number of VNF instances, logging information, and accounting information. User can also configure its VNFs from the controller, the details of the configuration are relative to the specific VNF vendors. User needs to specify the ID of which VNFs the configuration file is used to configure. When update package is released by the vendor, possible procedure may also need for the OSS/ BSS to inquire the user whether he would like to update the VNF of his own. The protocol between the user and OSS/BSS module of controller could be a new protocol or an extension of existing protocols such like HTTP, NetConf, YANG or XML. Zhou, et al. Expires March 27, 2014 [Page 6] Internet-DraftVirtual Network Function Configuration ArchiSeptember 2013 3.3. Software Vendor-Controller Software Vendor communicates with the OSS/BSS module of the controller, to publish a VNF, update a VNF, off-the-shelf a VNF. To the details, if a software vendor sends a request to publish a VNF, the identity of the software vendor must be verified before any further action. The software vendor needs to provide the software description information and the software package itself. The description information should include the following: VNF name, classification (classification types can be provided by the controller to the software vendor in advance), function description, components description, installation environment description (operation system, CPU, memory, storage and etc.), and the capacity description under the recommended installation environment (for example, the capable number of users per instance, throughput, concurrent connections, and etc.), as well as the pricing information if needed. Please note that the software package can be submitted to the OSS/BSS together with the description information, or be provided from some out-of-band methods. For example, the software vendor can provide a URL where the OSS/BSS can get this VNF package, or the OSS/ BSS provides a URL where the software vendor can upload its package. The software vendor should provide the VNF name and the update package to the controller when updating a certain VNF. Modification of functions, components, and the other basic information should also be provided to the controller. The protocol between software vendor and the OSS/BSS module of controller could be a new protocol or an extension of existing protocols such like HTTP, NetConf, YANG and XML. 3.4. Controller-VNF Another important role for the controller is the VNF management. VNF management module collaborates with the OSS/BSS and infrastructure management module for the VNF creation, deletion, update, monitoring, scale-out/scale-in, and software configuration. OSS/BSS receives the VNF request from the user, and then invokes its interface with the VNF management module to create VNFs. VNF management module gets VMs with requested resources from the infrastructure module, or directly gets the physical host resources. And then it mounts operation system on the VM or the host, then installs the customized VNF(s), sets up the forwarding rules between VNFs according to the forwarding graph provided by the user. VNF management is also in charge of VNF update when update request is made by the vendor. When update request is agreed by the user, the OSS/BSS invoke the update procedure of the VNF management to install the update version VNF(s) on the corresponding VM. Each VNF will report its status to the VNF management module, such like the CPU, memory, storage usage, current traffic volume information , the link usage on the forwarding graph. Zhou, et al. Expires March 27, 2014 [Page 7] Internet-DraftVirtual Network Function Configuration ArchiSeptember 2013 User can configure his VNFs through the OSS/BSS interface, but the configurations are finally carried out by the VNF management module. VNF management module can automatically scale-out or scale-in the number of VNF instances according to the load information on the current VNFs. For example, when a user's resource model is "on- demand", then when the VNF management module finds a relative VNF is beyond the load threshold, then it creates another same VNF to offload the relative VNF. And if the VNF function is process network traffic for the user, then VNF management module needs to coordinate with the NFV infrastructure to configure the relative switches (including soft switches), routers (including soft routers), so as to make traffic be divided to different VNFs. And user SHOULD be agnostic of this traffic division operation. The protocol between the VNF management module can be a new protocol or the extension of existing protocols, such like HTTP, NetConf, and YANG. 3.5. Controller-Infrastructure The third module in the controller is the infrastructure management module. It manages the infrastructure resources that the VNFs are using. It can create, delete, query about VMs. It configures the underlying network, including IP address, VLAN, ACL rules and flow tables. It can utilize OpenStack, CloudStack for some network management system similar to that. Infrastructure management can use the existing open interfaces. Infrastructure management also configure the network for the forwarding graph among the VNFs. 4. Security Considerations Because VNFs are running in the provider's network, so the privacy concern should be the most important aspect that a user would think about. The operator of NFV must guarantee that no third party can access the user's VNFs or any information of the VNFs without the user's permission. VNFs are generally considered to be run on cloud computing environment, so the security threats to a cloud computing system are also applicable here. 5. IANA Considerations There is no IANA considerations in this document. 6. References Zhou, et al. Expires March 27, 2014 [Page 8] Internet-DraftVirtual Network Function Configuration ArchiSeptember 2013 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.song-opsawg-virtual-network-function-config] Song, H., "The Problems of Virtual Network Function Configuration", draft-song-opsawg-virtual-network- function-config-00 (work in progress), September 2013. 6.2. Informative References [NFVE2E] , "Network Functions Virtualisation: End to End Architecture, http://docbox.etsi.org/ISG/NFV/70-DRAFT/0010 /NFV-0010v016.zip", . Authors' Addresses Hong Zhou Huawei Email: zhouhong@huawei.com Haibin Song Huawei Email: haibin.song@huawei.com Fu Qiao China Mobile Email: fuqiao@chinamobile.com Zhou, et al. Expires March 27, 2014 [Page 9]