Internet DRAFT - draft-xjz-nfv-model-problem-statement


Internet Working Group                                          W. Xu
                                                             Y. Jiang
                                                              C. Zhou
Internet Draft

Intended status: Informational

Expires: February 2014                              September 01, 2013

         Problem Statement of Network Functions Virtualization Model

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

   The list of Internet-Draft Shadow Directories can be accessed at

   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
   ( 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.


   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",
   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

   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

   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

   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.


   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

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

   - 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

   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.


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.


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


8. IANA Considerations

   No IANA action is needed for this document.

9. References

9.1.  Normative References

9.2. Informative References


   ETSI NFVMAN(13)20

10.  Acknowledgments


                     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

   Yuanlong Jiang
   Huawei Technologies Co., Ltd.
   Bantian, Longgang district
   Shenzhen 518129, China

   Cathy Zhou
   Huawei Technologies Co., Ltd.
   Bantian, Longgang district
   Shenzhen 518129, China

                     Expires February 30, 2014              [Page 10]