VNF Orchestration For Automated Resiliency in Service Chains
draft-bernini-nfvrg-vnf-orchestration-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Giacomo Bernini , Vincenzo Maffione , Diego Lopez , Pedro A. Aranda | ||
| Last updated | 2015-07-03 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bernini-nfvrg-vnf-orchestration-00
NFV Research Group G. Bernini
Internet-Draft V. Maffione
Intended status: Informational Nextworks
Expires: January 4, 2016 D. Lopez
P. Aranda Gutierrez
Telefonica I+D
July 3, 2015
VNF Orchestration For Automated Resiliency in Service Chains
draft-bernini-nfvrg-vnf-orchestration-00
Abstract
Network Function Virtualization (NFV) aims at evolving the way
network operators design, deploy and provision their networks by
leveraging standard IT virtualization technologies to move and
consolidate a wide range of network functions and services onto
industry standard high volume servers, switches and storage. Primary
area of impact for operators is the network edge, being stimulated by
the recent updates on NFV and SDN. In fact, operators are looking at
their future datacenters and Points of Presence (PoPs) as
increasingly dynamic infrastructures to deploy Virtualized Network
Functions (VNFs) and on-demand chained services with high elasticity.
This document presents an orchestration framework for automated
deployment of highly available VNF chains. Resiliency of VNFs and
chained services is a key requirement for operators to improve, ease,
automate and speed up services lifecycle management. The proposed
VNFs orchestration framework is also positioned with respect to
current NFV and Service Function Chaining (SFC) architectures and
solutions.
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."
Bernini, et al. Expires January 4, 2016 [Page 1]
Internet-Draft VNF Orchestration July 2015
This Internet-Draft will expire on January 4, 2016.
Copyright Notice
Copyright (c) 2015 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. VNF Orchestration for Resilient Virtual Appliances . . . . . 4
3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 5
3.2. Orchestration Framework . . . . . . . . . . . . . . . . . 6
3.2.1. Orchestrator . . . . . . . . . . . . . . . . . . . . 8
3.2.2. SDN Controller . . . . . . . . . . . . . . . . . . . 8
3.2.3. VNF Chain Configurator . . . . . . . . . . . . . . . 9
3.2.4. Edge Configurator . . . . . . . . . . . . . . . . . . 10
3.3. Resiliency Control Functions for Chained VNFs . . . . . . 10
4. Positioning in Existing NFV and SFC Frameworks . . . . . . . 12
4.1. Mapping into NFV Architecture . . . . . . . . . . . . . . 12
4.2. Mapping into SFC Architecture . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
Current Telco infrastructures are facing the rapid development of the
cloud market, which includes a broad range of emerging virtualized
services and distributed applications. Network Function
Virtualization (NFV) is gaining wide interest across operators to
evolve the way networks are operated and provisioned, with the
Bernini, et al. Expires January 4, 2016 [Page 2]
Internet-Draft VNF Orchestration July 2015
execution in virtualized environments of those network functions and
services traditionally integrated in hardware devices.
A Virtualized Network Function (VNF) provides the same function as
the equivalent network function (e.g. firewall, load balancer) but is
deployed as a software instance running on general purpose servers
via a virtualization technology. The main idea is therefore to run
network functions in either datacenters or commodity network nodes
that are, in some cases, close to the end user premises. With NFV,
network functions that were traditionally implemented on specialized
hardware devices are moved to general purpose servers, running in
self-contained virtual machines. These virtualized functions can be
deployed in multiple instances or moved to various locations in the
network, adapting themselves to traffic dynamicity and customer
demands without the overhead cost and management of installing new
equipment. Moreover, operators' networks are populated with a large
and increasing variety of proprietary software and hardware tools and
appliances. The deployment of new network services in operational
environments is often a complex and costly procedure, requiring
additional space and power to accommodate new boxes. Moreover,
current hardware-based appliances rapidly reach end of life,
requiring much of the design integration and deployment cycle to be
repeated with little revenue benefit. In this context, the
transition of network functions and appliances from hardware to
software solutions by means of NFV promises to address and overcome
these hindrances for network operators.
While the above considerations are valid for stand-alone VNFs running
independently, additional challenges and requirements raise for
network operators when services offered to customers are built by the
composition of multiple VNFs. In this case, the deployment and
provisioning of each VNF composing the service for the customer needs
to be coordinated with the other VNFs, applying control functions to
steer the traffic through them following the proper order (i.e.
according to the specific service function path). An orchestration
framework capable of coordinating the automated deployment,
configuration, provisioning and chaining of multiple VNFs would ease
the management of the whole lifecycle of services offered to
customers. Additionally, when dealing with virtualized functions,
resiliency and high availability of chained services pose additional
requirements for a VNF orchestration framework, in terms of detection
of software failure at various levels, including hypervisors and
virtual machines, hardware failure, and virtual appliance migration.
This document presents an orchestration framework for automated
deployment of high available VNF chains, and introduces its
architecture and building blocks. Resiliency for both stand-alone
VNFs and chained services is considered in this document as a key
Bernini, et al. Expires January 4, 2016 [Page 3]
Internet-Draft VNF Orchestration July 2015
control function based on VNF pool concepts. The proposed VNF
orchestration framework is also positioned with respect to approaches
and architectures currently defined for Network Function
Virtualization and Service Function Chaining (SFC).
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].
The following acronyms are used in this document:
NFV: Network Function Virtualization.
SDN: Software Defined Networking.
VNF: Virtualized Network Function.
SFC: Service Function Chaining.
CPE: Customer Premise Equipment.
VPN: Virtual Private Network.
EMS: Element Management System.
PoP: Point of Presence.
VM: Virtual Machine.
3. VNF Orchestration for Resilient Virtual Appliances
The telco market is rapidly moving towards an Everything as a Service
model, where the virtualization of traditionally in-the-box network
functions can benefit from Software Defined Networking (SDN) tools
and technologies. As said, the recent updates and proposed solutions
on NFV and SDN is practically bringing, from an operator perspective,
a deep evolution on how the network edge is architected, operated and
provisioned, since that is the place where VNFs and virtual services
can be deployed and provisioned close to the customers. Operators
target to evolve their datacenters and PoPs into more and more
dynamic infrastructures where VNFs and chained services can be
deployed with high availability and high elasticity to scale up and
down while optimizing performances and resources utilization.
This section introduces the VNF orchestration framework proposed in
this document for the deployment, provisioning and chaining of
Bernini, et al. Expires January 4, 2016 [Page 4]
Internet-Draft VNF Orchestration July 2015
resilient virtual appliances and services within operators'
datacenters.
3.1. Problem Statement
The orchestration framework proposed in this document aims at solving
some of the challenges that operators face when, trying to apply the
base NFV concepts, they replace hardware devices implementing well-
known network functions with software-based virtual appliances. In
particular, this VNF orchestration framework targets an automated,
flexible and elastic provisioning of service chains within operators'
datacenters.
When operators need to compose and chain multiple VNFs to provision a
given service to the customer, they need to operate network and
computing resources in a coordinated way, and above all to implement
control mechanisms and procedures to steer the traffic through the
different VNFs and the customer sites. As an example, the
virtualization of the Customer Premises Equipment (CPE) is emerging
as one of the first applications of the Network Functions
Virtualization (NFV) architecture that is currently being
commercialized by several software (and hardware) vendors. It has
the potential to generate a significant impact on the operators
businesses. The term virtual CPE (vCPE) refers to the execution in a
virtual environment of the network functions that traditionally
integrated in hardware gears at customer premises, like BGP speakers,
firewall, NAT, etc. Different scenarios and use cases exist for the
vCPE. Currently, the typical scenario is the vCPE in the PoP, that
actually provides softwarization and shift to the first PoP of the
operator for those network functions normally deployed at customer
premises (e.g. NAT, Firewall, etc.). The goal is to manage the
whole LAN environment of the customer, while preserving QoE of its
services, providing added value services to users not willing to get
involved with technology issues, and reducing maintenance trouble
tickets and the need for in-house problem solving. In addition, the
vCPE can be used in the operator's datacenter to implement in
software those chained network functions to provision automated VPN
services for customers [VCPE-T2], in order to dynamically and
automatically extend existing L3 VPNs (e.g. connecting remote
customer sites) to incorporate new virtual assets (like virtual
machines) into a private cloud.
As additional requirements for the proposed orchestration framework,
the use of VNFs opens new challenges concerning the reliability of
provided virtual services. When network functions are deployed on
monolithic hardware platforms, the lifecycle of individual services
is strictly bound to the availability of the physical device, and
management tools may detect outages and migrate affected services to
Bernini, et al. Expires January 4, 2016 [Page 5]
Internet-Draft VNF Orchestration July 2015
new instances deployed on backup hardware. When introducing VNFs,
individual network functions may still fail, but with more risk
factors such as software failure at various levels, including
hypervisors and virtual machines, hardware failure, and virtual
appliance migration. Moreover, when considering chains of VNFs, the
management and control tools used by the operators have to consider
and apply reliability mechanisms at the service level, including
transparent migration to backup VNFs and synchronization of state
information. In this context, VNF pooling mechanisms and concepts
are valid and applicable, thus considering VNF instances grouped as
pools to provide the same function in a reliable way.
3.2. Orchestration Framework
The VNF orchestration framework proposed in this document aims to
provide automated functions for the deployment, provisioning and
composition of resilient VNFs within operators' datacenters.
Figure 1 presents the high level architecture, including building
blocks and functional components.
This VNF orchestration framework is built around two key components:
the orchestrator and the SDN controller. The orchestrator includes
all the functions related to the management, coordination, and
control of VNFs instantiation, configuration and composition. It is
the component at the highest level of the architecture and represents
the access point to the VNF orchestration framework for the operator.
On the other hand, the SDN controller provides dynamic traffic
steering and flexible network provisioning within the datacenter as
needed by the VNF chains. The basic controller functions are
augmented by a set of enhanced network applications deployed on top,
that might be themselves control and management VNFs for operator use
(i.e. not related to customers and users functions).
Therefore, the architecture depicted in Figure 1 is a practical
demonstration of how SDN and NFV technologies and concepts can be
integrated to provide substantial benefits to network operators in
terms of robustness, ease of management, control and provisioning of
their network infrastructures and services. SDN and NFV are clearly
complementary solutions for enabling virtualization of network
infrastructures, services and functions while supporting dynamic and
flexible network traffic engineering. SDN focuses on network
programmability, traffic steering and multi-tenancy by means of a
common, open, and dynamic abstraction of network resources. NFV
targets a progressive migration of network elements, network
appliances and fixed function boxes into VMs that can be ran on
commodity hardware, enabling the benefits of cloud and datacenters to
be applied to network functions.
Bernini, et al. Expires January 4, 2016 [Page 6]
Internet-Draft VNF Orchestration July 2015
+----------------------------------------------+
| Orchestrator |
+-----+----------------+----------------+------+
| | |
V V V
+------------+ +-------------+ +-------------+
| | | | | |
| VNF Pool | | VNF Chain | | Edge |
| Manager | |Configurator | |Configurator |
| | | | | |
+-----+------+ +------+------+ +------+------+
| | |
V V V
+----------------------------------------------+
| SDN Controller |
+--------------+---+----+---------------+------+
+.......................+ | | | |
: +--------+ \ | | | +-----+
: |+-------++ :| +-----+---+----+----+ |
: +| || :\ | +-----------------+-+ +---+----+
: /|| VNF1 || : | | | +---------------+-+-+ | |
: / || || :..+ | | | Virtual | | +-------+ Edge |
: / ++-------+| : : | | | Switche(s) | | +-------+ Router |
: / +---+----+ : :| +-+-+---------------+ | | | |
: / | : :\ +-+-----------------+ | +--------+
: +--+-----+ | : : | +-----+---+---+-----+
: |+-------++ | : : \ | | |
: || || | : : | | | |
: || VNF2 || | : : \---------+---+---+------+
: || || | : : | |
: ++-------+| | : : | |
: +--+-+---+ | : : | Virtual Compute |
: \ +----+---+ : : | Infrastructure |
: \|+-------++ : : | |
: +| || : : | |
: || VNF3 || : : /------------------------+
: || || : : |
: ++-------+| : : |
: +--------+ : : |
:Service Chain "X" : : /
+.......................+ : |
:Service Chain "Y" :/
+........................+
Figure 1: VNF Orchestration Framework Architecture.
Bernini, et al. Expires January 4, 2016 [Page 7]
Internet-Draft VNF Orchestration July 2015
3.2.1. Orchestrator
The VNF orchestrator implements a set of functions to seamlessly
control and manage in a coordinated way the instantiation and
deployment of VNFs on one hand, and their composition and chaining to
steer the traffic through them on the other. It is fully controlled
and operated by the network operator, and basically it is the highest
control and orchestration layer that sits above all the softwarized
and virtualized components in the proposed architecture.
Therefore the VNF orchestrator provides a consistent way to access
the system and provision chains of VNFs to the operator. It exposes
a set of primitives to instantiate, configure VNFs and compose them
according to the specific service chain requirements. Practically,
it aims at enabling an efficient and dynamic management of operator's
infrastructure resources with great flexibility by means of a
consistent set of APIs.
To enable this, the orchestrator can be seen as a composition of
several internal functionalities, each providing a given coordination
function needed to orchestrate the lower layer control and management
functions depicted in Figure 1 (i.e. VNF chain configuration, VNF
pool provisioning, etc.). In practice, the orchestrator needs to
include at least an internal component to manage the instantiation
and configuration of stand-alone VNFs (e.g. implemented by a self-
contained VM) that might be directly interfaced with the physical
servers in the datacenter. And also a dedicated component for
programmatic coordination and provisioning of VNF chains is needed to
properly orchestrate the traffic steering through VNFs belonging to
the same service chain. This should also provide multi-tenant
functionalities and maintain isolation across VNF chains deployed for
different customers. It is then clear that the VNF orchestrator is
the overall coordinator of the proposed framework, and it drives all
the lower layer components that implement the actual control logic.
3.2.2. SDN Controller
The SDN controller provides the logic for network control,
provisioning and monitoring. It is the component where the SDN
abstraction happens. This means it exposes a set of primitives to
configure the datacenter network according to the requirements of the
VNF chains to be provisioned, while hiding the specific technology
constraints and capabilities of the software switches and edge
routers underneath. The deployment of an SDN controller allows to
implement a software driven VNF orchestration, with flexible and
programmable network functions for service chaining and resilient
virtual appliances.
Bernini, et al. Expires January 4, 2016 [Page 8]
Internet-Draft VNF Orchestration July 2015
At its southbound interface, the SDN controller interfaces with
software switches running in servers, physical switches
interconnecting them and edge routers connecting the datacenter with
external networks. Multiple control protocols can be used at this
southbound interface to actually provision the datacenter network and
enable traffic steering through VNFs, including OpenFlow, OVSDB,
NETCONF and others.
Therefore the SDN controller provides the basic network provisioning
functions needed by upper layer coordination functions to perform
service chain and VNF pool-wide actions. Indeed, the logic and the
state at the service level is only maintained and coordinated by
network applications on top of the SDN controller.
3.2.3. VNF Chain Configurator
The VNF chain configurator is deployed as a bridging component
between the orchestrator and the SDN controller, and it is mostly
dedicated to the implementation of VNF chaining and composition
logic. It computes a suitable path to interconnect the involved VNFs
(already instantiated and identified by the orchestrator) and
forwards the network configuration request to the SDN controller for
each new VNF chain requested by the orchestrator.
Following the datacenter service chains and related traffic types
defined in [I-D.ietf-sfc-dc-use-cases], the VNF chain configurator
should implement its coordination logic to support both north-south
and east-west chains. The former refer to network traffic staying
within the datacenter but coming from a remote datacenter or a user
through the edge router connecting to an external network. In this
case, the VNF chain configurator should also coordinate with the edge
configurator to properly provision the datacenter edge router.
Moreover, this north-south case may also refer to VNF chains spanning
multiple datacenters, thus requiring a further inter-datacenter
coordination between VNF chain configurators and orchestrators.
These coordination functions are out of the scope of this document.
On the other hand, the east-west chains refer to VNFs treating
network traffic that do not exit the datacenter. For both cases, the
VNF chain configurator (in combination with the SDN controller)
should implement and support proper service chains encapsulation
solutions [I-D.ietf-sfc-nsh] to isolate and segregate traffic related
to VNF chains belonging to different tenants.
Different deployment models may exist for the VNF chain configurator:
a dedicated configurator for each chain, or a single configurator for
all the VNF chains. In the first approach, the orchestrator needs to
implement some coordination logic related to the dynamic
instantiation of configurators when new VNF chains are provisioned.
Bernini, et al. Expires January 4, 2016 [Page 9]
Internet-Draft VNF Orchestration July 2015
3.2.4. Edge Configurator
The edge configurator is a network control application deployed on
top of the SDN controller. Its main role is to coordinate the
provisioning and configuration of the edge router for those north-
south VNF chains exiting the datacenter. In particular, it keeps the
binding between the traffic steered through the VNFs and the related
network service outside the datacenter terminated at the edge router
(e.g. a L3 VPN, VLAN, VXLAN, VRF etc), possibly considering the
service chain encapsulation implemented within the VNF chain. The
mediation of the SDN controller allows to support a variety of
control and management protocols for the actual configuration of the
datacenter edge router.
3.3. Resiliency Control Functions for Chained VNFs
In the proposed orchestration architecture, the resiliency control
functions that have been identified as a key feature for a flexible
and dynamic provisioning of chained VNF services, are implemented by
the VNF pool manager depicted in Figure 1. It is the entity that
manages and coordinates VNFs reliability providing high availability
and resiliency features at both stand-alone and chained VNFs level.
The deployment of VNF based services requires a transition of
resiliency capabilities and mechanisms from physical network devices
typically highly available (and often specialized) to entities (like
self-contained VMs) running VNFs in the context of pools of
virtualized resources.
When moving towards a resilient approach for VNFs deployment and
operation, the generic high availability requirements to be matched
are translated into the following ones:
Service continuity: when a hardware failure or capacity limits
(memory and CPU) occur on platforms hosting VMs (and therefore
VNFs), it is necessary to migrate VNFs to other VMs and/or
hardware platforms to guarantee service continuity with minimum
impact on the users
Topological transparency: the hand-over between live and backup VNFs
must be implemented in a transparent way for the user and also for
the service chain itself. The backup VNF instances need to
replicate the necessary information (configuration, addressing,
etc.) so that the network function is taken over without any
topological disruption (i.e. at the VNF chain level)
Load balancing or scaling: migration of VNF instances may also
happen for load-balancing purposes (e.g. for CPU, memory overload
Bernini, et al. Expires January 4, 2016 [Page 10]
Internet-Draft VNF Orchestration July 2015
in virtualized platforms) or scaling of network services (with
VNFs moved to new hardware platforms). In both cases the working
network function is moved to a new VNF instance and the service
continuity must be maintained.
Auto scale of VNFs instances: when a VNF requires increased resource
allocation to improve overall service performance, the network
function could be distributed across multiple VMs, and to
guarantee the performance improvement dedicated pooling mechanisms
for scaling up or down resources to each VNF in a consistent way
are needed.
Multiple VNF resiliency classes: each type of end-to-end service
(e.g. web, financial backend, video streaming, etc.) has its own
specific resiliency requirements for the related VNFs. While for
operators it is not easy to achieve service resiliency SLAs
without building to peak, a basic set of VNF resiliency classes
can be defined to identify some metrics, such as: if a VNF needs
status synchronization; fault detection and restoration time
objective (e.g. real-time); service availability metrics; service
quality metrics; service latency metrics for VNF chain components.
The aim of the VNF orchestration presented in this document is to
address the above requirements by introducing the VNF pool manager
that follows the principles of the IETF VNFPOOL architecture [I-
D.zong-vnfpool-arch], where a pool manager coordinates the
reliability of stand-alone VNFs, by selecting the active instance and
interacting with the Service Control Entity for consistent end-to-end
service chain reliability and provisioning. In the VNF orchestration
architecture illustrated in Figure 1, the Service Control Entity is
implemented by the combination of the orchestrator (for overall
coordination of service chains) and the VNF chain configuration (for
actual provisioning and coordination of individual service chains).
Different deployment models may exist for the VNF pool manager: a
dedicated manager for each VNF chain, or a single one for all the
chains.
In terms of offered resiliency functionalities, the VNF pool manager
provides some post-configuration functions to instantiate VNFs (as
self-contained VMs) with the desired degree of reliability and
redundancy. This translates into further actions to create and
configure additional VMs as backups, therefore building a pool for
each VNF in the chain.
The VNF pool manager is conceived to offer several types and degrees
of reliability functions. First, it provides specific functions for
the persistence of VNFs configuration, including making periodic
Bernini, et al. Expires January 4, 2016 [Page 11]
Internet-Draft VNF Orchestration July 2015
snapshots of the VMs running the VNF. Moreover, at runtime (i.e.
with the service chain in place), it monitors the operational status
and performances of the master VNFs VMs, and collects notifications
about VMs status, e.g. by registering as an observer to dedicated
services offered by the virtualization platform used within the
virtual compute infrastructure. Moreover, VNF pool manager reacts to
any failure condition by autonomously replacing the master VNF with
one of its backup on the pool, basically implementing a swap of VMs
for service chain recovery purposes. Thus, the VNF pool manager also
takes care in coordination with the VNF chain configurator of
implementing those resiliency mechanisms at the chain level. Two
options have been identified so far: cold recovery and hot recovery.
In the former, backup VNFs, properly configured with the same master
configuration, are kept ready (but switched off) to be started when
the master dies. In this case the recovery time depends on the
specific VNF and its type of function, e.g. it may depend on
convergence time for a virtual BGP router. In the hot recovery,
active backup VNFs are kept synchronized with the master ones, and
the recovery of the service chain (mostly performed at the VNF chain
configurator) in case of failure is faster than cold recovery.
4. Positioning in Existing NFV and SFC Frameworks
4.1. Mapping into NFV Architecture
For the presented solution to be integrated in the ETSI NFV reference
architecture, some modifications need to be applied to it. The VNF
pools replace the VNFs in the architecture. They are then controlled
by the Element Management System (EMS) on the northbound. So the EMS
has to be made VNFPOOL aware. Additional elements that need to
support the mechanisms proposed by VNFPOOL are the VNF managers,
which need to implement the resiliency and VNF scaling
(up-/downscale) functions. This has also implications on the
orchestrator, which has to be aware of the augmented functionality
offered by the VNF Manager. In fact, the orchestrator also provides
primitives for VNFs chaining, matching the Service Control Entity in
the VNFPool architecture.
4.2. Mapping into SFC Architecture
[I-D.ietf-sfc-architecture] describes the Service Function Chaining
(SFC) architecture. It describes the concept of a service function
(SF) and how to chain SFs and provides only little detail of the SFC
control plane, which is responsible with the coordination of the SFs
and their stitching into SFCs. The combination of orchestrator, VNF
chain configurator and VNF pool manager functionalities described in
this document cover most of the functions expected from the SFC
control plane.
Bernini, et al. Expires January 4, 2016 [Page 12]
Internet-Draft VNF Orchestration July 2015
5. IANA Considerations
This draft does not have any IANA consideration.
6. Security Considerations
Security issues related to VNF orchestration and resiliency of
service chains are left for further study.
7. Acknowledgements
This work has been partially supported by the European Commission
through the FP7 ICT Trilogy2 project (Building the Liquid Net, grant
agreement no:317756).
The views expressed here are those of the author only. The European
Commission is not liable for any use that may be made of the
information in this document.
Authors would like to thank G. Carrozzo and G. Landi from Nextworks
for valuable discussions and contributions to the topics addressed in
this document.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.ietf-sfc-dc-use-cases]
Surendra, S., Tufail, M., Majee, S., Captari, C., and S.
Homma, "Service Function Chaining Use Cases In Data
Centers", draft-ietf-sfc-dc-use-cases-02 (work in
progress), January 2015.
[I-D.ietf-sfc-architecture]
Halpern, J. and C. Pignataro, "Service Function Chaining
(SFC) Architecture", draft-ietf-sfc-architecture-09 (work
in progress), June 2015.
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-00 (work in progress), March 2015.
Bernini, et al. Expires January 4, 2016 [Page 13]
Internet-Draft VNF Orchestration July 2015
[I-D.zong-vnfpool-problem-statement]
Zong, N., Dunbar, L., Shore, M., Lopez, D., and G.
Karagiannis, "Virtualized Network Function (VNF) Pool
Problem Statement", draft-zong-vnfpool-problem-
statement-06 (work in progress), July 2014.
[VCPE-T2] G. Bernini, G. Carrozzo, P. A. Gutierrez, D. R. Lopez, ,
"Virtualizing the Network Edge: Virtual CPE for the
datacenter and the PoP", European Conference on Networks
and Communications , June 2014.
Authors' Addresses
Giacomo Bernini
Nextworks
via Livornese 1027
San Piero a Grado, Pisa 56122
Italy
Phone: +39 050 3871600
Email: g.bernini@nextworks.it
Vincenzo Maffione
Nextworks
via Livornese 1027
San Piero a Grado, Pisa 56122
Italy
Phone: +39 050 3871600
Email: v.maffione@nextworks.it
Diego R. Lopez
Telefonica I+D
Calle Zubaran, 12
Madrid 28010
Spain
Email: diego.r.lopez@telefonica.com
Bernini, et al. Expires January 4, 2016 [Page 14]
Internet-Draft VNF Orchestration July 2015
Pedro Andres Aranda Gutierrez
Telefonica I+D
Calle Zubaran, 12
Madrid 28010
Spain
Email: pedroa.aranda@telefonica.com
Bernini, et al. Expires January 4, 2016 [Page 15]