Internet Working Group W. Xu Y. Jiang C. Zhou Huawei Internet Draft Intended status: Informational Expires: February 2014 September 01, 2013 Problem Statement of Network Functions Virtualization Model draft-xjz-nfv-model-problem-statement-00.txt 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 February 30, 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 Xu, et al Expires February 30, 2014 [Page 1] Internet-Draft Problem Statement of NFV Model August 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document discusses the problem space of the Network Functions Virtualisation (NFV) models in the NFV environment. Possible use cases and the language for the models will also be identified. Table of Contents 1. Introduction ............................................. 2 2. Conventions used in this document ......................... 3 3. Terminology .............................................. 4 4. Problems and Use Cases .................................... 5 5. Aspects of the Problems ................................... 6 5.1. NFV Modeling Objectives ................................ 6 5.2. Modeling Language considerations ....................... 7 6. Related IETF work......................................... 7 7. Security Considerations ................................... 9 8. IANA Considerations ....................................... 9 9. References ............................................... 9 9.1. Normative References ................................... 9 9.2. Informative References ................................. 9 10. Acknowledgments .......................................... 9 1. Introduction Network Functions Virtualisation (NFV), as currently being in progress in ETSI NFV, leverages standard IT virtualisation technology to consolidate many network equipment types onto industry standard high volume servers, switches and storage. The traditional physical network device could be implemented using the Virtualized Network Function (VNF) with the introduction of the NFV technology, which will bring some benefit, e.g., reduced costs, increased speed of Time to Market, one platform for different applications, users and tenants, and inspired service innovation. The NFV Orchestrator (NFVO) is one of the key entities in the end-to- end NFV reference architecture, which manages and coordinates VNFs and the respective NFVI provides a northbound interface with some candidate protocols to offer the NFV management and orchestration functions to other entities. The E2E NFV architecture abstracts the network function information model to the external network. However, those protocols do not include a modeling language or accompanying Expires February 30, 2014 [Page 2] Internet-Draft Problem Statement of NFV Model August 2013 rules that can be used to model the management information that is to be configured using protocol. Another key entity in ETSI NFV is the VNF. We need an abstracted information model for VNFD (Virtual Network Function Descriptor) to specify the configuration data model for the virtual network function. The VNFD describes the resource requirements of the VNF, the VNF Forwarding Graphs describe how service providers wish to have multiple VNFs connected together to form customized services for end users, and the NFV service describes how a network service can be realized using NFs. The VNF configuration data model which is included by the VNFD may need a standard data modeling language to specify it. This allows the OSS/orchestrator to dynamically extract and parse the data model from the VNFD at run-time and to implement some rudimentary flow-through provisioning of any service. VNF Forwarding Graphs and NFV service also need a standard data modeling language for their description. The NETCONF Data Modeling Language (netmod) working group in the Internet Engineering Task Force (IETF) has defined the data modeling language YANG and has developed a set of YANG data models and other activities for configuration and management of network elements. Since the VNF Forwarding Graphs are organized independent of the existing network topology and protocols, a new set of data models (e.g., YANG) may be needed to provide implementation guidance for the operators to configure and manage the virtual network functions. Therefore, NFV model (NFVMOD) is proposed to be studied in IETF, with the goal to provide management entities with standardized information they can use to deploy, instantiate, configure and manage network services based on NFV infrastructure. The information is organized with VNFD, the VNF Forwarding Graph and the NFV Service. Network topologies constructed with Network Service Chaining (NSC mechanism) may also be in the scope of NFVMOD if its work starts. The models to be developed in NFVMOD may also help the understanding of NFV and the development of NSC protocol. Finally, the modeling language used for NFVMOD may be YANG. 2. Conventions used in this document 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]. Expires February 30, 2014 [Page 3] Internet-Draft Problem Statement of NFV Model August 2013 3. Terminology CMS: Cloud Management System. Network Function (NF): A functional building block within an operator's network infrastructure, which has well-defined external interfaces and a well-defined functional behaviour. NF set: A collection of NFs with unspecified connectivity between them. Network Functions Virtualization Orchestrator (NFVO): a function that deploys, operates, manages, and coordinates VNFs and the respective NFVI. The Orchestrator has control and visibility of all VNF running inside the NFVI. Network Functions Virtualization Infrastructure (NFVI): the totality of all hardware and software components that constitute the environment in which VNFs are deployed, managed and executed. The NFVI includes resources for computation, networking and storage. Physical Network Function (PNF): An implementation of a NF via a tightly coupled software and hardware system. Virtual Machine (VM): 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. Virtualised Network Function (VNF): An implementation of an executable software program that constitutes the whole or a part of an NF and can be deployed on a virtualisation infrastructure. VNFD: Virtualized Network Function Description, used to describe all properties associated in the NFV infrastructure. VNF Forwarding Graph: A graph specified by a Network Service Provider of bi-directional logical links connecting NF nodes where at least one node is a VNF through which network traffic is directed. NFV Service: A network service utilizing NFs, where at least some NFs are VNFs. A VNF Forwarding Graph is an example of such a service. Expires February 30, 2014 [Page 4] Internet-Draft Problem Statement of NFV Model August 2013 4. Problems and Use Cases Much of the following materials and all definitions are brought from the ongoing ETSI NFV work, which may undergo frequent changes in the future. From a top down viewpoint of NFV (that is, from an end to end service to its serving infrastructure), three layers of logical abstraction are defined in NFV architecture: NFV Service, VNF Forwarding Graph and VNF. -NFV Service NFV Service is a network service utilizing NFs, where at least some NFs are VNFs. It can be regarded as a service presentation layer. An NFV service requires a modeling language which can describe how an end to end service is to be assembled including which VNFs and PNFs are required and how they are connected, and the relevant service parameters (e.g. relationship with other VNFs in terms of latency, co-location, etc). It can optionally contain a reliability class description that specifies the reliability, availability, and scale metrics for each VNF. -VNF Forwarding Graph A VNF forwarding graph requires a modeling language which can describe how a forwarding graph is formed, including which VNFs are required and how forwarding from one VNF to another VNF is to be realized. It can also describe the link options available in the infrastructure, such as E-LAN, E-LINE, and E-TREE services. These enable the connection of VNFs to other VNFs or the existing networks that can be selected by the NFVO and be used to configure the Infrastructure network. -VNF A VNF also requires a detailed data model, written in a standardized data modeling language, describing its configurable parameters, operational state variables, operations and notifications, thus enabling the resources required for an instance to be deployed by the NFVO and CMS onto an appropriate server. Five separate logical interfaces are envisioned (see GS NFV-SWA001) to enable effective orchestration of a VNF. Expires February 30, 2014 [Page 5] Internet-Draft Problem Statement of NFV Model August 2013 These modeling languages must have a well-defined grammar in textual form so that automation tools can process and translate the models described in them. These modeling languages must have well-defined upgrade rules, so that clients (OSS and/or Orchestrators) can work with different versions of a VNF data model. Following these upgrade rules ensures that upgrade scenarios are handled properly in the network. ETSI NFV has proposed some information models on the NFV architecture, e.g., NFVMAN(13)20_003r4. But it is not clear which modeling language will be used and what is the data model for configuration and management when using these languages. 5. Aspects of the Problems Some considerations on the NFV modeling issue are provided in this section. 5.1. NFV Modeling Objectives The main objective of VNF modeling may include: - Basic VNF attributes: VNF name, function description, sharing or non-sharing attribute. - Deployment attributes: environment requirements of VNF deployment such as the number of VMs, virtual CPU, memory and disk requirements, image of each VM, and QoS requirements such as bandwidth and delay of VNF. - Operational attributes: which defines the operational and management behavior, such as start, stop, pause, migration and etc. - Interface attributes: external interface, such as interface type, configuration parameters of these interfaces. The main objective of VNF Forwarding Graph modeling may include: - VNFs in a Forwarding Graph. - VNF connectivity, such as virtual links between VNFs. - Attributes of service flows in a VNF forwarding graph. Expires February 30, 2014 [Page 6] Internet-Draft Problem Statement of NFV Model August 2013 The main objective of NFV service modeling may include: - VNFs and PNFs in an NFV service. - VNF connectivity between PNFs and VNFs. - Service attributes of an NFV service, such as entry and exit point, QoS of an NFV service, and etc. 5.2. Modeling Language considerations YANG is a modular language representing data structures in an XML tree format. A YANG module defines a hierarchy of data that can be used for NETCONF-based operations, including configuration, state data, Remote Procedure Calls (RPCs), and notifications. This allows a complete description of all data sent between a NETCONF client and server. The IETF NETMOD working group has defined the data modeling language YANG and a set of core YANG data models, which can be used by network operators for the configuration and management of their physical network elements. YANG can also be used for NFV data modeling, the advantages include: - Its simplicity and flexibility in modeling semantics. - Consistence with the modeling of its physical network elements, thus facilitate an end to end service constructed with both virtual and physical network functions, and across both virtual and physical networks. 6. Related IETF work The following subsections discuss related IETF work and are provided for reference. They may be deleted when the document is published. - NVO3 NVO3 WG is mainly developing the tunnel technology for DC inter- connection, and solving the problem of VM migration. Expires February 30, 2014 [Page 7] Internet-Draft Problem Statement of NFV Model August 2013 The NVO3 mechanism can be used to accommodate the needs of end to end services in NFV, especially when the virtualization platforms (e.g., server pools) involve multiple DCs. The virtual link between Virtual Network Functions (VNFs) can also use NVO3 technology as a tunneling mechanism (if intra DC protocols such as VXLAN and NVGRE are adopted into charter and specified there). Thus, NVO3 at most solves the problem of supporting virtual links. When VMs serving a VNF (or VNFs) migrate from on DC to another DC, NVO3 can also have its use. - NSC Service chaining is a broad term used to describe a common model for delivering multiple services in a specific order. Service chaining de- couples service delivery from the underlying network topology and creates a dynamic services plane that addresses the requirements of cloud and virtual application delivery. Packets and/or flows that require service chaining are classified and redirected to the appropriate, available services. Additionally, context can be shared between the network and the services. During the 87th IETF meeting, NSC BoF had triggered quite a lot of interests in the attendees. Though the charter of NSC is still unclear thus far, it is believed to cover the routing of a service chain, i.e., providing an end to end path to serve a service chain. As shown in discussions, NSC can provide routing and forwarding mechanisms for service chains. Its main focus is on data plane, and some control plane issues may also be involved. -NETMOD The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. The NETMOD working group has defined the data modeling language YANG but no IETF models exist yet. The purpose of the NETMOD working group is to support the ongoing deployment of YANG by developing a set of core YANG data models and other activities that will allow network operators to use YANG for configuration and management of network elements. The NETMOD Working Group currently works on the following items: Core system data model, Core interface data model, Core routing data model Expires February 30, 2014 [Page 8] Internet-Draft Problem Statement of NFV Model August 2013 and Data model for configuring SNMP engines. Virtual network functions and virtual network is not in the scope of NETMOD. 7. Security Considerations TBD. 8. IANA Considerations No IANA action is needed for this document. 9. References 9.1. Normative References 9.2. Informative References ETSI GS NFV-SWA001 ETSI NFVMAN(13)20 10. Acknowledgments TBD Expires February 30, 2014 [Page 9] Internet-Draft Problem Statement of NFV Model August 2013 Authors' Addresses Weiping Xu Huawei Technologies Co., Ltd. Bantian, Longgang district Shenzhen 518129, China Email: xuweiping@huawei.com Yuanlong Jiang Huawei Technologies Co., Ltd. Bantian, Longgang district Shenzhen 518129, China Email: jiangyuanlong@huawei.com Cathy Zhou Huawei Technologies Co., Ltd. Bantian, Longgang district Shenzhen 518129, China Email: cathy.zhou@huawei.com Expires February 30, 2014 [Page 10]