OPSAWG H. Song Internet-Draft Huawei Intended status: Informational Z. Cao Expires: April 21, 2014 China Mobile October 18, 2013 The Problems of Virtual Network Function Configuration draft-song-opsawg-virtual-network-function-config-01 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 April 21, 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 Song & Cao Expires April 21, 2014 [Page 1] Internet-Draft Virtual Network Function Configuration October 2013 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. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problems of Service Configuration . . . . . . . . . . . . . . 5 4. Scope for Standardization . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Background This document describes the problems in the context of remote virtual network function 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: Song & Cao Expires April 21, 2014 [Page 2] Internet-Draft Virtual Network Function Configuration October 2013 (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" 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 Song & Cao Expires April 21, 2014 [Page 3] Internet-Draft Virtual Network Function Configuration October 2013 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 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. Song & Cao Expires April 21, 2014 [Page 4] Internet-Draft Virtual Network Function Configuration October 2013 In the context of this document, the operator owns the controller. OSS/BSS for the NFV service is part of the controller. The network administrator from the operator can also act as a user to install and configure VNFs in the provider's (operator's) network for the customers or for himself. Note that the controller could be third party SP software components for NFV, and in this case, there should be the interface for the operator to configure the controller beforehand. But we assume the controller has already been configured for the NFV services in this document. And the configuration of the controller itself is out of scope. 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]. 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 Song & Cao Expires April 21, 2014 [Page 5] Internet-Draft Virtual Network Function Configuration October 2013 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, enterprise user or the operator network administrator) 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. This process includes the service parameters selection and event notification, for example, the operating system selection, software components selection, installation location selection, notification of the number of the instances of the same virtual network functions, installation status notification and etc. Service chaining also needs a descriptor from the user. A user can directly establish a service chain. For the service graph, there can be two layers, one is the stable virtual/physical link layer, and the other is conditional/stable service forwarding layer. 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 Song & Cao Expires April 21, 2014 [Page 6] Internet-Draft Virtual Network Function Configuration October 2013 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. Note that VNF level and VM level resource allocation are different. Because one VM might be holding multiple VNFs. The resource allocation interfaces provided by some platforms such like Openstack-Neutron are combined with a VM, and are not easy to make a change. But here when the resource is combined with a VNF. It is much easier to change it. A recommended resource requirements notification for a service instance is also needed between a software vendor and the controller. 4. Scope for Standardization 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. Song & Cao Expires April 21, 2014 [Page 7] Internet-Draft Virtual Network Function Configuration October 2013 Existing protocols can be extended for the description of NFV service configurations and related resource requirements. YANG has deployment in the existing network. So if YANG is extended for the VNF configuration and modeling, it can be seemlessly integrated with other related network management systems. JavaScript Object Notation is a text-based open standard, so it is human readable. There is alo effort in IETF to use JSON to describe the application layer information, as well as the network layer information. For example, in ALTO protocol [I-D.ietf-alto-protocol], it uses JSON to describe the routing cost between peers of network hosts. 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. Acknowledgments The authors would like to thank Zhen Cao for his valuable comments. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [I-D.ietf-alto-protocol] Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- ietf-alto-protocol-20 (work in progress), October 2013. [NFVE2E] , "Network Functions Virtualisation: End to End Architecture, http://docbox.etsi.org/ISG/NFV/70-DRAFT/0010 /NFV-0010v016.zip", . Song & Cao Expires April 21, 2014 [Page 8] Internet-Draft Virtual Network Function Configuration October 2013 Authors' Addresses Haibin Song Huawei Email: haibin.song@huawei.com Cao Zhen China Mobile Email: caozhen@chinamobile.com Song & Cao Expires April 21, 2014 [Page 9]