Appsawg H. Song Internet-Draft Huawei Intended status: Informational July 15, 2013 Expires: January 16, 2014 The Problems of Service Configuration in NFV Context draft-song-appsawg-service-template-00 Abstract This document describes the problem space of virtual function installation and dynamic configuration in network function virtulization (NFV) context. And identify the scope that needs standardization. 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 January 16, 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 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. Song Expires January 16, 2014 [Page 1] Internet-Draft Service Template July 2013 Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problems of Service Configuration . . . . . . . . . . . . . . 3 4. Scope for Standardization . . . . . . . . . . . . . . . . . . 4 5. Normative References . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Background Users always have different requirements when they need a software. So a software vendor often provides a lot of functions to satisfy a majority of its users. But one user might only need a few sub-set functions . For example, a firewarll could protect against various attacks, but a user's environment decides that he only needs to be protected from several attacks, and other attacks may not happen in this context. As a result, these functions exist in the software as components. There are several possibilities: (1) A software vendor distinguish users as several classes, and provide related versions of software to the users accordingly, for example, "home edition". (2) When user request a software, a person negotiate with the software vendor, 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. (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. But these methods either too complex, or authorize the user with more components than what he wants. Song Expires January 16, 2014 [Page 2] Internet-Draft Service Template July 2013 In the context of netwrok function virtulizaition (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 to virtual machines through the NFV control center. These virtual functions can be replaced with new virtual functions when needed, with only re-configuring it with a new software through the control center. In this case, NFV control center is just like a broker for many software applications. 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 below. 3. Problems of Service Configuration There are several problems in the context of NFV to configure a virtual function, which makes it different from the traditional ways. First, in the NFV framework, a software is installed according to the user (enterprise and etc.) requirements.And it is not installed locally in the user's equipment, but remotely in the 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 postion or the hardware/ software resources. But the control center has the direct control. In a result, the user needs to interact with the control center to accomplish the configuration of the components in a software installation. Second, the NFV control center is just like a broker for various software applications. If every software vendor has its own proprietary messages for the software installation component configuration, then it will make the control center and the user envrionment 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 control center also needs a standard format to communicate with the software vendors, so as to acquire the detailed descriptions of the software components. Song Expires January 16, 2014 [Page 3] Internet-Draft Service Template July 2013 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 control center 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 VMs that it applies to. 4. Scope for Standardization (1) An interface between user and NFV control center for software installation configuration, about the components. (2) An interface between software vendor and NFV control center for the detailed description of the software components. (3) An interface between user and NFV control center for dynamic configuraiton. The data model of the service components is the key point for the standardization. 5. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Haibin Song Huawei Email: haibin.song@huawei.com Song Expires January 16, 2014 [Page 4]