OPSAWG H. Song Internet-Draft Huawei Intended status: Informational September 06, 2013 Expires: March 10, 2014 The Problems of Virtual Network Function Configuration draft-song-opsawg-virtual-network-function-config-00 Abstract This document describes the problem space of remote service installation and configuration in the provider's network through a centralized management system. This is a typical scenario for virtual 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 in their end hosts, but can install their own featured powerful software application in the cloud. This specification also identifies the scope that needs standardization based on the problems. 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 10, 2014. 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 Song Expires March 10, 2014 [Page 1] Internet-Draft Virtual Network Function Configuration September 2013 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. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problems of Service Configuration . . . . . . . . . . . . . . 5 4. Scope for Standardization . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Background This document describes the problems in the context of remote software installation and service configuration through a central management system, called a controller. Four main roles are involved, including the user, the software provider, the controller and the infrastructure resources. Users always have different requirements when they need a software. So a software vendor often provides a "full-set" of functions to satisfy a majority of users in the market. But for each individual user it might only need a few sub-set functions according to his own requirements. For example, a firewall could provide many functions, including anti-DDoS attack, anti-phishing attack, IP filtering function, MAC filtering function, network address translator function, and etc.. But a home user who is going to install a virtual firewall from the network operator, (which may be installed in a virtual machine inside the provider's network and the operator can make the traffic from/to this user go through that virtual machine,) may contempt his own environment and determines that he only needs anti-phishing attack function and MAC filtering function for his traffic. Other functions may be not useful for this user, for example, DDoS attacks may not happen to this user in this context. Typically, these functions exist in the software as different components. There are several possibilities for the user to acquire the relative components that he needs: (1) A software vendor distinguishes users as several classes, and provides related versions of software to the users accordingly, for example, a "home edition" version, an "enterprise edition" Song Expires March 10, 2014 [Page 2] Internet-Draft Virtual Network Function Configuration September 2013 version and etc. In this case, the specific version may satisfy most users in that class, but for each individual user, it may also contain many function components that the user does not need. (2) When a user requests a software, the user negotiates with a customer service person from the software vendor about his requirements, and the software vendor makes a specified version of software to the user, in this version, it enables the components that the user need, and disables those unneeded. In this case, it costs more human energy, and is not efficient. The user has to wait days or even longer for his specific software version after the negotiation. (3) The user get a license and software packet, and with the license, it allows the user to choose inside a range of components for installation. The user enables components that he wants in that range. In this case, it gives the user more flexibility to operate the software components, but from another perspective, it also authorizes the user with more components than the user wants. These methods either too complex, or authorize the user with more components than what he wants. A real-time, exact matching and flexible way for the user to choose his software components is desirable. In the context of network function virtualizaition (NFV), more and more network functions become to be available in a virtualized function way. It adopts the common IT infrastructure instead of physical hardware box to implement these network functions. The benefits of this method is to reduce cost through improved infrastructure reusability and lower entry of the industry, which allows more software vendors. Various virtual functions exist in the network. They are deployed into virtual machines through the NFV controller. These virtual functions can be replaced with new virtual functions when needed, with only re-configuring it with a new software through the controller. In this case, NFV controller is just like a broker for many software applications. The user may also have his own requirements or want to put his constraints on the network properties of the software that is to be installed in the provider's network. For example, the bandwidth requirements for this software. This is different from the virtual machine level or host level bandwidth limitation. It is an application specific bandwidth limitation. A number of software applications can be installed on a same virtual machine, and they share the bandwidth of this virtual machine. But they are different applications and have different requirements on the bandwidth. In this case, the user specifies his requirements on the bandwidth of Song Expires March 10, 2014 [Page 3] Internet-Draft Virtual Network Function Configuration September 2013 this software, and the NFV controller will enforce that constraints to the application level through some kind of configuration. Besides the network properties, during the remote installation, the user would also need to notify the controller about the virtual network function's storage space requirements, memory requirements, CPU requirements, operating system requirements, location constraints for the software installation. These constraints can be mapped to a virtual machine if a virtual network function is mapped to a single virtual machine, or a subset resources of a virtual machine if multiple virtual network functions share a virtual machine. It is the controller's responsibility to select the most appropriate hardware resources for the virtual network function based on some mapping algorithm, but it is totally an implementation issue. These constraints are also relative to the software vendor, and the software vendor should describe the basic hardware and software requirements of the installation environment to the user, and the user should combine it with capacity requirements from himself and make a final decision on these parameters. The previous two paragraphs describe the explicit way between the user and the controller for resource requirements. But there could also be an implicit way. In the implicit way, the user only describes what software components he needs. But the controller will choose appropriate resources for the user. When the user needs more capacity due to the service expansion, for example, in a scenario where an enterprise has a virtual firewall in the provider's network, the controller is responsible for the redirection of the traffic from or to this enterprise go through the virtual firewall. The configuration could be that the controller sends flow rules to the network equipment, so as to forward the related traffic to the virtual firewall. And the virtual firewall notifies the controller about its traffic load status. If the load is above some threshold, the controller will automatically create new virtual firewall instances, and allocate additional CPU/memory/storage/bandwidth resources to handle that traffic. The controller will configure new flow rules to make a portion of the traffic go through the new instances. If the traffic volume is shrinking, the controller will automatically reduce the number of virtual instances for the user. The resource requirements for each virtual instance can be from the recommendation of the software provider. This kind of automatic scale-out and scale-in mechanism can make a better utilization of the network, computing and storage resources. And users do not need to have a deep understanding of the resource consumption model, but only pay as much as the resources he used. 2. Terminology Song Expires March 10, 2014 [Page 4] Internet-Draft Virtual Network Function Configuration September 2013 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]. 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 architecture includes a NFV controller (orchestrator) to manage the virtual network functions and the infrastructure resources. (Note: will use terms defined by ETSI NFV ISG in the next version.) NF: A functional building block within an operator's network infrastructure, which has well-defined external interfaces and a well-defined functional behaviour. 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 is today 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 virtualisation 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. Problems of Service Configuration There are several problems in the context of remote software installation, which makes it different from the traditional ways. First, it is a remote operation. For example, in the NFV framework, a software is installed according to the user (home user or enterprise user) requirements through NFV controller. It is not installed locally in the user's equipment, but remotely in the provider's network. NFV's control center needs to coordinate the necessary infrastructure resources for the installation. So the user does not have direct control over the software installation position or the hardware and software resources. But the controller has the direct control. In a result, the user needs to interact with the controller to accomplish the configuration of the components and his preferred locations for a software installation. Song Expires March 10, 2014 [Page 5] Internet-Draft Virtual Network Function Configuration September 2013 Second, the NFV controller is just like a broker for various software applications. There are different methods for the software installation. A proprietary method is that every software vendor has a plug-in in the NFV controller platform, and each end user uses the proprietary messages to interact with that software vendor's plug-in for the software installation. Another way is using standard messages to allow users to select their preferred software components for all different kinds of software installation. The drawback for every software vendor has its own proprietary messages for the software installation component configuration, is that it will make both the controller and the user environment more complex. A uniform and standard component configuration is more appropriate for this context. Third, if the software vendor does not provide a clear description of these software components, then users do not know how to choose among those components. So the controller also needs a standard format to communicate with the software vendors, so as to acquire the detailed descriptions of the software components. Fourth, dynamic configuration is another problem. A user may want to change its service configuration when the software is running. In the traditional context, a user logs into the server, and changes the service template in the server, then save it. It may become effect immediately or after reboot. But in the context of NFV, a user's virtual function may be installed in many virtual machines. It gets coo complex if we let the user maintains the installed virtual machines information and logs into each virtual machine to reconfigure the service template one by one. A centralized service template configuration modification is much more easier. The controller may be or not be aware of the meaning of these dynamic configurations, But it needs to know that this is a configuration file and the range of VMs that it applies to. There are also resource requirements for the remote software installation, which are complement to the software components selection. There is lack of a standard for a user to tell the controller how much bandwidth, storage, CPU, memory are allocated to a specific software in the provider's network (perhaps there is existing standard for the virtual machine or host level resources), or just tell the controller allocate the resources dynamically for him. A recommended resource requirements notification for a service instance is also needed between a software vendor and the controller. 4. Scope for Standardization Song Expires March 10, 2014 [Page 6] Internet-Draft Virtual Network Function Configuration September 2013 The key point is the information model. Network Function Virtualization needs standard information model so as to improve the interoperation. How to represent the user's functional and resource requirements, and how to map and apply these requirements to the underlying infrastructure is the key point to success. This specification on the stage only focuses on the virtual network function level at the beginning, but virtual overlay network of network functions should be extended in the near future. The narrowed scope for the current stage is: (1) A protocol between the user and controller for software installation components choices, dynamic service configuration through the controller, and the resource requirements for the installation. (2) A protocol between software vendor and the controller for the detailed description of the software components and the recommended resource requirements for service instance. 5. Security Considerations This document does not introduce any new security threats. But for any solution to solve these problems, authentication is required between a user and the controller to verify whether the user is authorized to install that software. And the messages among the user, the controller and software vendor must be encrypted to prevent from interception attack. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [NFVE2E] , "Network Functions Virtualisation: End to End Architecture, http://docbox.etsi.org/ISG/NFV/70-DRAFT/0010 /NFV-0010v016.zip", . Author's Address Haibin Song Huawei Email: haibin.song@huawei.com Song Expires March 10, 2014 [Page 7]