Internet DRAFT - draft-zhou-nfvcon-arch
draft-zhou-nfvcon-arch
OPSAWG H. Zhou
Internet-Draft H. Song
Intended status: Informational Huawei
Expires: December 7, 2014 Q. Fu
China Mobile
June 5, 2014
Virtual Network Function Configuration Architecture
draft-zhou-nfvcon-arch-00
Abstract
This document describes the architecture of NFV configuration in the
provider's network through a centralized management system and focus
on the virtualisation characteristics related issues. It is also a
typical scenario in cloud computing environment where end users do
not have to install or manage their applications on their end hosts,
but can install and manage their own featured powerful software
application in the cloud. This specification describes an
architecture of NFV configuration. It is also applicable to other
use cases with similar requirements.
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 December 7, 2014.
Copyright Notice
Copyright (c) 2014 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
Zhou, et al. Expires December 7, 2014 [Page 1]
Internet-DraVirtual Network Function Configuration Architectu June 2014
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Design Principals . . . . . . . . . . . . . . . . . . . . 5
3.2. NFC-NFVCMP . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. NFP-NFVCMP . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. NFVCMP-VNF . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. NFVCMP-NFVI . . . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
This document describes the architecture to solve the problems
described in [I-D.song-opsawg-virtual-network-function-config], In
virtual network function configuration, the network function
virtualization (NFV) NFV Control and Management Plane is a broker for
various Network Function Providers. It manages how to install a
virtual network function in the provider's network according to
Network Function Consumer's requirements. There needs standard
protocols between Network Function Consumer and NFV Control and
Management Plane to describe the components requirements and resource
requirements for a (or a batch of) virtual network function
installation and configuration. There also needs a standard protocol
between Network Function Provider and NFV Control and Management
Plane to describe the software basic information, running environment
resource requirements, components information description. The
component of a virtual network function may be another virtual
network function. And the NFV Control and Management Plane may
combine some virtual network functions together to form another
virtual network function. If layer N (N can be 1, 2, 3...) virtual
network function is consisted of several layer N-1 virtual network
functions, the NFV Control and Management Plane must communicate with
the Network Function Consumer on how to construct the upper layer VNF
with lower layer VNFS, and what are the forwarding sequences and what
Zhou, et al. Expires December 7, 2014 [Page 2]
Internet-DraVirtual Network Function Configuration Architectu June 2014
are the conditions to trigger that forwarding sequence. The resource
requirements from the Network Function Consumer can be either
explicit or implicit. If the resource requirement is "on-demand",
then the NFV Control and Management Plane has to communicate with the
virtual network function layer to create new service instances when
the service load is increasing or delete extra service instances when
the service load is decreasing. The resource requirements for each
service instance is based on the recommendation from the Network
Function Provider.
This specification gives a basic management architecture for virtual
network function (VNF) configuration. It lists the main functional
modules that plays important roles in VNF configuration, and
specifies what each functional module does, and what are the contents
communicated among these functional modules, as depicted in Figure 1.
The main concepts from this document are from ETSI NFV ISG [NFVE2E] .
But there is slightly difference from ESTI. For example, we have a
central NFV Control and Management Plane in this architecture that
contains OSS/BSS, VNF management and Infrastructure management,
unlike ESTI NFV ISG, where it separates the OSS/BSS and a management
and orchestration system. In real world implementation, these
functional units usually reside in the same physical equipment(s)
called network management system.
OSS/BSS (operations support system / business support system)
functional module is responsible for communication with Network
Function Consumers. It provides software (VNF) provider's
information to the Network Function Consumers, and get components
requirements and resource requirements from the Network Function
Consumers. It also communicates with VNF Network Function Providers
to get the software information and the recommended resource
information, and etc.. VNF management module is responsible for VNF
instance creation/deletion, VNF status management, VNF resource
management, and VNF connection management when one VNF is represented
as a conditional/static connection of multiple VNFs. Infrastructure
management module is responsible for physical layer resource (CPU,
memory, storage, bandwidth etc.) allocation for the virtual machine
that a VNF is resided on.
This document will describe the basic principle for the architecture
first, then give the description of the interfaces and what contents
are exchanged among those interfaces. At the end, it will discuss
the security threats for the VNF configuration.
Zhou, et al. Expires December 7, 2014 [Page 3]
Internet-DraVirtual Network Function Configuration Architectu June 2014
+----------------+ +----------------+ +---------------+
|Network Function| |Network Function| |Network Service|----------
| Consumer | | Provider | |Provider | ^
+----------------+ +-----+----------+ +---------------+ |
| | |
| |
| | | North bound
+----------------------------------------------+
| NFV Control and Management Plane |
| +----------+-----------+ | |
| | | | | V
| +---------+-+ +-----+----+ +----+----------+| ----------
| |OSS/BSS | |VNF | | Infrastructure|| ^
| | | |Management| | Management || |
| +---+-------+ +----------+ +------+--------+| |
| | | | |
+-----+------------------------------+---------+
| |
| | South bound
++-+ |
|V | +-----+--------+ |
|N | |NFV | |
|F | |Infrastructure| -----V------
+--+ +--------------+
/ \
/ \
+------+ +------+
|VNF |-->|VNF |
+------+ +------+
Figure 1 Virtual Network Function Configuration Framework
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].
Network Function Consumer: a Network Function Consumer (NFC) is the
consumer of virtual network functions. It can be either an
individual user, home user or the enterprise user.
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
Zhou, et al. Expires December 7, 2014 [Page 4]
Internet-DraVirtual Network Function Configuration Architectu June 2014
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 Control and Management Plane
(orchestrator) to manage the virtual network functions and the
infrastructure resources.
NF: A functional building block within an operator's network
infrastructure, which has well-defined external interfaces and a
well-defined functional behavior. 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.
Network Function Provider: a Network Function Provider (NFP) provides
virtual network function software.
Network Service Provider (NSP): a company or organization, that
provides a network service on a commercial basis to third parties. A
network service is a composition of network functions and defined by
its functional and behavior specification. The NSP operates the NFV
Control Plane.
NFV Infrastructure(NFVI): NFV Infrastructure indicates the computing,
storage and network resources to implement the virtual network
function. High performance acceleration platform is also part of it.
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 virtualization 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.
NFV Control and Management Plane (NFVCMP): a NFV Control and
Management Plane is operated by a NSP and orchestrates the NFV
Infrastructure to provide NFV service to NFC.
3. Architecture
3.1. Design Principals
There are six key modules in the architecture. They are NFV Control
and Management Plane, Network Function Provider, Network Function
Consumer, Network Service Provider, VNF, and NFV Infrastructure. And
Zhou, et al. Expires December 7, 2014 [Page 5]
Internet-DraVirtual Network Function Configuration Architectu June 2014
the NFV Control and Management Plane has three key functional
modules, OSS/BSS, VNF management, and infrastructure management.
(1) NFV Control and Management Plane is the brain of all operations.
NFV Control and Management Plane creates virtual network functions in
the provider's network. Although the Network Function Consumers may
communicate with the virtual network functions in the service layer
directly, but it has not to directly communicate with the VNF in the
management level. A Network Function Consumer can have multiple VNFs
in the provider's network, and can configure them or a subset of them
through a simple communication with the NFV Control and Management
Plane. The NFV Control and Management Plane is also a broker for
various Network Function Providers. It provides standard interfaces
to convey information model with Network Function Providers and
Network Function Consumers. It also monitors the VNF resource
consumption status when the resource consumption model is "on-
demand".
(2) NFV Control and Management Plane MUST NOT be aware of the service
logic of each VNF. When a Network Function Consumer configures
multiple VNFs by sending a configuration template to the NFV Control
and Management Plane. The NFV Control and Management Plane does not
understand the contents in the configuration template. It only has
to know how to apply the configuration to the appropriate VNFs.
(3) The key point for the protocol development SHOULD focus on the
information model to describe the VNF itself, the resource
requirements, the service/forwarding graph, and the status report.
3.2. NFC-NFVCMP
Network Function Consumer communicates with the OSS/BSS module of the
NFV Control and Management Plane, to query, buy, or configure VNFs.
Network Function Consumer gets the VNF list from the query interface.
Each VNF in the list contains: VNF type, function description,
description of components that can be installed optionally,
installation resource requirements, possible performance standard
(which may include capable number of users per instance, throughput,
concurrent connections, and etc.), and pricing information. Network
Function Consumer can select the appropriate VNF to install from the
list. The information that the Network Function Consumer can provide
to the OSS/BSS before the installation can be the VNF name, quantity,
the preferred components of the VNF, the preferred installation
locations in high level (Network Function Consumer do not have to
know the detailed location such like on which virtual machine), and
the possible performance requirement at the beginning (which will be
considered when allocating resources, so that even the same VNF
provided by the same Network Function Provider can have different
Zhou, et al. Expires December 7, 2014 [Page 6]
Internet-DraVirtual Network Function Configuration Architectu June 2014
initial resource allocation when it is installed to serve different
customers that have different amount of Network Function Consumers/
traffic). Network Function Consumer should also tell the NFV Control
and Management Plane whether it needs specific resources or it only
needs resources on-demand. In the meantime, Network Function
Consumer should also provide the data forwarding graph to the NFV
Control and Management Plane, so that the NFV Control and Management
Plane can figure out how the new VNF is connected to the existing
network, and how the data flow should forward after the installation
of this new VNF. Such forwarding graph should be written in a fixed
format in spite of the difference of Network Function Consumers.
Network Function Consumer can get the relative report from the NFV
Control and Management Plane, the report contains information of
which VNFs have been installed, the status of each VNF, the number of
VNF instances, logging information, and accounting information.
Network Function Consumer can also configure its VNFs from the NFV
Control and Management Plane, the details of the configuration are
relative to the specific VNF vendors. Network Function Consumer
needs to specify the ID of which VNFs the configuration file is used
to configure. When update package is released by the vendor,
possible procedure may also need for the OSS/BSS to inquire the
Network Function Consumer whether he would like to update the VNF of
his own. The protocol between the Network Function Consumer and OSS/
BSS module of NFV Control and Management Plane could be a new
protocol or an extension of existing protocols such like HTTP,
NetConf, YANG or XML.
3.3. NFP-NFVCMP
Network Function Provider communicates with the OSS/BSS module of the
NFV Control and Management Plane, to publish a VNF, update a VNF,
off-the-shelf a VNF. To the details, if a Network Function Provider
sends a request to publish a VNF, the identity of the Network
Function Provider must be verified before any further action. The
Network Function Provider needs to provide the software description
information and the software package itself. The description
information should include the following: VNF name, classification
(classification types can be provided by the NFV Control and
Management Plane to the Network Function Provider in advance),
function description, components description, installation
environment description (operation system, CPU, memory, storage and
etc.), and the capacity description under the recommended
installation environment (for example, the capable number of Network
Function Consumers per instance, throughput, concurrent connections,
and etc.), as well as the pricing information if needed. Please note
that the software package can be submitted to the OSS/BSS together
with the description information, or be provided from some out-of-
band methods. For example, the Network Function Provider can provide
Zhou, et al. Expires December 7, 2014 [Page 7]
Internet-DraVirtual Network Function Configuration Architectu June 2014
a URL where the OSS/BSS can get this VNF package, or the OSS/BSS
provides a URL where the Network Function Provider can upload its
package. The Network Function Provider should provide the VNF name
and the update package to the NFV Control and Management Plane when
updating a certain VNF. Modification of functions, components, and
the other basic information should also be provided to the NFV
Control and Management Plane. The protocol between Network Function
Provider and the OSS/BSS module of NFV Control and Management Plane
could be a new protocol or an extension of existing protocols such
like HTTP, NetConf, YANG and XML.
3.4. NFVCMP-VNF
Another important role for the NFV Control and Management Plane is
the VNF management. VNF management module collaborates with the OSS/
BSS and infrastructure management module for the VNF creation,
deletion, update, monitoring, scale-out/scale-in, and software
configuration. OSS/BSS receives the VNF request from the Network
Function Consumer, and then invokes its interface with the VNF
management module to create VNFs. VNF management module gets VMs
with requested resources from the infrastructure module, or directly
gets the physical host resources. And then it mounts operation
system on the VM or the host, then installs the customized VNF(s),
sets up the forwarding rules between VNFs according to the forwarding
graph provided by the Network Function Consumer. VNF management is
also in charge of VNF update when update request is made by the
vendor. When update request is agreed by the Network Function
Consumer, the OSS/BSS invoke the update procedure of the VNF
management to install the update version VNF(s) on the corresponding
VM. Each VNF will report its status to the VNF management module,
such like the CPU, memory, storage usage, current traffic volume
information , the link usage on the forwarding graph. Network
Function Consumer can configure his VNFs through the OSS/BSS
interface, but the configurations are finally carried out by the VNF
management module. VNF management module can automatically scale-out
or scale-in the number of VNF instances according to the load
information on the current VNFs. For example, when a Network
Function Consumer's resource model is "on-demand", then when the VNF
management module finds a relative VNF is beyond the load threshold,
then it creates another same VNF to offload the relative VNF. And if
the VNF function is process network traffic for the Network Function
Consumer, then VNF management module needs to coordinate with the NFV
infrastructure to configure the relative switches (including soft
switches), routers (including soft routers), so as to make traffic be
divided to different VNFs. And Network Function Consumer SHOULD be
agnostic of this traffic division operation.
Zhou, et al. Expires December 7, 2014 [Page 8]
Internet-DraVirtual Network Function Configuration Architectu June 2014
The protocol between the VNF management module can be a new protocol
or the extension of existing protocols, such like HTTP, NetConf, and
YANG.
3.5. NFVCMP-NFVI
The third module in the NFV Control and Management Plane is the
infrastructure management module. It manages the infrastructure
resources that the VNFs are using. It can create, delete, query
about VMs. It configures the underlying network, including IP
address, VLAN, ACL rules and flow tables. It can utilize OpenStack,
CloudStack for some network management system similar to that.
Infrastructure management can use the existing open interfaces.
Infrastructure management also configure the network for the
forwarding graph among the VNFs.
4. Security Considerations
Because VNFs are running in the provider's network, so the privacy
concern should be the most important aspect that a Network Function
Consumer would think about. The operator of NFV must guarantee that
no third party can access the Network Function Consumer's VNFs or any
information of the VNFs without the Network Function Consumer's
permission.
VNFs are generally considered to be run on cloud computing
environment, so the security threats to a cloud computing system are
also applicable here.
5. IANA Considerations
There is no IANA considerations in this document.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.song-opsawg-virtual-network-function-config]
Song, H. and Z. Cao, "The Problems of Virtual Network
Function Configuration", draft-song-opsawg-virtual-
network-function-config-01 (work in progress), October
2013.
Zhou, et al. Expires December 7, 2014 [Page 9]
Internet-DraVirtual Network Function Configuration Architectu June 2014
6.2. Informative References
[NFVE2E] "Network Functions Virtualisation: End to End
Architecture, http://docbox.etsi.org/ISG/NFV/70-
DRAFT/0010/NFV-0010v016.zip", .
Authors' Addresses
Hong Zhou
Huawei
Email: zhouhong@huawei.com
Haibin Song
Huawei
Email: haibin.song@huawei.com
Fu Qiao
China Mobile
Email: fuqiao@chinamobile.com
Zhou, et al. Expires December 7, 2014 [Page 10]
