Internet DRAFT - draft-xjz-nfv-model-problem-statement
draft-xjz-nfv-model-problem-statement
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]
