One document matched: draft-caszpe-nfvrg-orchestration-challenges-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC7426 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7426.xml">
<!ENTITY RFC7498 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7498.xml">
<!ENTITY I-D.zu-nfvrg-elasticity-vnf SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.zu-nfvrg-elasticity-vnf.xml">
<!ENTITY I-D.unify-nfvrg-challenges SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.unify-nfvrg-challenges.xml">
<!ENTITY I-D.unify-nfvrg-recursive-programming SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.unify-nfvrg-recursive-programming.xml">
<!ENTITY I-D.cmzrjp-ippm-twamp-yang SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cmzrjp-ippm-twamp-yang.xml">
<!ENTITY I-D.felix-nfvrg-recursive-orchestration SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.felix-nfvrg-recursive-orchestration.xml">
<!ENTITY I-D.unify-nfvrg-devops SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.unify-nfvrg-devops.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC): -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="2"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references: -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space:
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of popular PIs -->
<rfc category="info" docName="draft-caszpe-nfvrg-orchestration-challenges-00" ipr="trust200902">
<front>
<title abbrev="NFV Resource Orchestration Challenges">Network
Function Virtualization: Resource Orchestration Challenges</title>
<author fullname="Gino Carrozzo" initials="G.Carrozzo" surname="Carrozzo" role="editor">
<organization>Nextworks</organization>
<address>
<postal>
<street>via Livornese 1027</street>
<city>Pisa</city>
<!-- <region/> -->
<code>56122</code>
<country>Italy</country>
</postal>
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>g.carrozzo@nextworks.it</email>
<uri>http://www.nextworks.it/</uri>
</address>
</author>
<author fullname="Robert Szabo" initials="R." surname="Szabo" role="editor">
<organization abbrev="Ericsson">Ericsson Research, Hungary</organization>
<address>
<postal>
<street>Irinyi Jozsef u. 4-20</street>
<city>Budapest</city>
<!-- <region></region> -->
<code>1117</code>
<country>Hungary</country>
</postal>
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>robert.szabo@ericsson.com</email>
<uri>http://www.ericsson.com/</uri>
</address>
</author>
<author fullname="Kostas Pentikousis" initials="K. Pentikousis" surname="Pentikousis" role="editor">
<organization>EICT</organization>
<address>
<postal>
<street>Torgauer Strasse 12-15</street>
<city>Berlin</city>
<!-- <region/> -->
<code>10829</code>
<country>Germany</country>
</postal>
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>k.pentikousis@eict.de</email>
<uri>http://www.eict.de</uri>
</address>
</author>
<date year="2015"/>
<workgroup>Internet Research Task Force NFVRG </workgroup>
<keyword>Resource orchestration</keyword>
<keyword>Resource federation</keyword>
<keyword>Recursive orchestration</keyword>
<abstract>
<t>Network function virtualization (NFV) promises improved
operations in terms of flexibility, efficiency, and manageability,
but orchestration, in general, and recursive orchestration, in
particular, is still an item of ongoing research. We summarize the
current state of the art in open-source initiatives in this area
and present current directions of research and development in
terms of orchestration, resource decomposition and federation,
policy-based resource management, measurement and analytics, and
virtual network function (VNF) elasticity.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>To a large degree there is agreement in the network
research, practitioner, and standardization communities that
rigid network control limits the flexibility and manageability
of service creation, as discussed in <xref target="NSC" /> and
the references therein. Today operators run IP networks
stitched together by a plethora of highly specialized
middleboxes that implement firewall, NAT, DPI, traffic
scrubbing, and other functionality
<xref target="middlebox"/>. In this environment orchestration
is fragmented, hindering rapid service deployment. Moreover,
recursive orchestration for heterogeneous resources is not
practically employed. In this memo, we examine orchestration
support in current open-source efforts and describe research
challenges in this area.</t>
<section anchor="motivation" title="Motivation">
<t>Flexible service definition and creation start by
formalizing the service into the concept of network function
forwarding graphs, such as the ETSI VNF Forwarding Graph
<xref target="ETSI-NFV-Arch"/> or the ongoing work in IETF
<xref target="RFC7498" />. These graphs represent the way in
which service end-points (e.g., customer access) are
interconnected with a set of selected network functionalities
such as firewalls, load balancers, and so on, to deliver a
network service. Service graph representations form the input
for the management and orchestration to instantiate and
configure the requested service. For example, ETSI defined a
Management and Orchestration (MANO) framework in
<xref target="ETSI-NFV-MANO"/>. We note that throughout such a
management and orchestration framework different abstractions
may appear for separation of concerns, roles or functionality,
or for information hiding.</t>
<t>In the simplest case, technology specific domains (e.g.,
software or networking) create a technology specific
abstraction and control interfaces (e.g., Open Stack
Controller or an SDN Controller), which are connected to an
overarching orchestrator. <xref target="fig_simple-nfv-view"/>
shows an NFVO orchestrating three NFVI PoPs: two DCs with
OpenStack Controller (OSC) and a Wide Area Network domain by
an SDN Controller.</t>
<figure anchor="fig_simple-nfv-view" align="center"
title="">
<artwork align="center">
<![CDATA[
+---------+
| NVFO |
+---------+
.---/ | \---.
/ | \
+-----+ +-----+ +-----+
| VIM | | WIM | | VIM |
|(OSC)| |(SDN)| |(OSC)|
+-----+ +-----+ +-----+
]]>
</artwork></figure>
<t>However, technology specific separation of the orchestration
interface is not necessarily rational once the orchestrator (e.g.,
NFVO) aggregated all the different resource types into a joint
abstraction. <xref target="fig_recursive_orchestration"/> shows two
autonomous systems with their own technology specific resource
domains plus a resource virtualization between the two domains. In
<xref target="fig_recursive_orchestration"/> RO denotes resource
orchestrators, Service O denotes service lifecycle management and
VIM/WIM denote technology specific resource managers. Further, for
the interworking interface between the two autonomous domains the
resource virtualization is denoted by S (as a slice). Control
over the virtualized resource offered by RO 1 to RO 2 is assumed to
be exercised also by the API exposed at S. Assume that the
resource virtualization contains both i) networking resources (e.g.,
topology of forwarding elements) and ii) software resources capable
of hosting VNFs. S is interworking interface, which needs
standardization for efficient interworking.</t>
<figure anchor="fig_recursive_orchestration" align="center"
title="">
<artwork align="center">
<![CDATA[
* +---------+
* |Service O|
* +---------+
* |
* +---------+
* | RO 2 |
* +-[aggr-]-+
* | \ \
* | \ \----------.
* | \----. \
+---------+ *| +--+--+ +-----+
|Service O| |* | WIM | | VIM |
+---------+ | * |(SDN)| |(OSC)|
| | * +-----+ +-----+
+------[S]+ * AS 2
| RO 1 | ******************
+-[aggr-]-+ AS 1
.---/ | \---.
/ | \
+-----+ +-----+ +-----+
| VIM | | WIM | | VIM |
|(OSC)| |(SDN)| |(OSC)|
+-----+ +-----+ +-----+
]]>
</artwork></figure>
<t>As soon as resources become part of multiple administration
domains; technology or vendor specific domains or multi-operator
setup standardized interfaces are key for smooth interworking.
Without such interoperability different technologies for data center
and network operation result in distinct technology domains even
within a single carrier. Multi technology/domain barriers start to
emerge hindering the full programmability of the NFVI and limiting
the potential for rapid service deployment.</t>
</section>
<section title="Scope">
<t>In this document we consider the virtualization and resource
orchestration of heterogeneous resources and functions over multiple
technology, vendor or administrative domains.</t>
<t>Examples of application contexts for recursive orchestration
include, but are not limited to, the following:
<list style="symbols">
<t>large scale experimentation over software networks, based on
slices of network and compute resources from different federated
providers;</t>
<t>operators who intend to implement their network service offer
over virtual infrastructure in the form of virtual network and
compute resources and functions, all procured as a service from
physical infrastructure providers.</t>
</list>
</t>
</section>
<section title="Terminology">
<t>We use the term software, compute and "compute and storage"
interchangeably throughout the document. Moreover, we use the
following definitions, some of which are established in
<xref target="ETSI-NFV-Arch"/> and are copied here for reader
convenience.</t>
<t><list style="hanging">
<t hangText="Network Function Virtualization (NFV)"><vspace/>The
principle of separating network functions from the hardware they
run on by using virtual hardware abstraction.</t>
<t hangText="NFV Infrastructure Point of Presence (NFVI PoP)"><vspace/> Any combination of virtualized compute, storage and network resources.</t>
<t hangText="NFV Infrastructure (NFVI)"><vspace/>Collection of
NFVI PoPs under one orchestrator.</t>
<t hangText="Virtual Network Function (VNF)"><vspace/>One or more
virtual machines running different software and processes on top
of industry-standard high-volume servers, switches and storage, or
cloud computing infrastructure, and capable of implementing
network functions traditionally implemented via custom hardware
appliances and middleboxes (e.g. router, NAT, firewall, load
balancer, etc.)</t>
<t hangText="Virtualized Network Function Forwarding Graph (VNF
FG)"><vspace/>An ordered list of VNFs creating a service
chain.</t>
<t hangText="VNF Island"><vspace/>A set of virtualized network
functions and related network and compute resources under the same
administrative ownership/control. A VNF island could consist of
multiple zones, each characterized by a specific set of control
tools and interfaces.</t>
<t hangText="VNF Zone"><vspace/>A set of virtual network functions
grouped for homogeneity of technologies and/or control tools
and/or interfaces (e.g. L2 switching zone, optical switching zone,
OpenFlow controlled zone, other transit domain zone with a control
interface). The major goal of defining SDN zones is to implement
appropriate policies for increasing availability, scalability and
control of the different resources of the island. Examples of zone
definitions are available in popular cloud management systems like
CloudStack (e.g. refer to the CloudStack Infrastructure
partitioning into regions, zones, pods, etc.,
<xref target="cloudstack"/>) and OpenStack (e.g. refer to the
infrastructure partitioning in availability zones and host
aggregates <xref target="openstack"/>).</t>
<t hangText="Transit network domains"><vspace/>Network domains can
use a bandwidth-on-demand interface to expose automatically and
on-demand control of connectivity services and, optionally,
inter-domain topology exchange. In order to federate resources
of distant facilities (i.e. islands/zones) it must be ensured
that interconnectivity is provided on-demand and with a specific
granularity.</t>
<t hangText="Slice"><vspace/>A provider-created subset of virtual
networking and compute resources, created from physical or virtual
resources available for the (slice) provider.</t>
<t hangText="Resource Orchestrator (RO)"><vspace/>Entity
responsible for domain wide global orchestration of network services
and software resource reservations in terms of network functions
over the physical or virtual resources the RO owns. The domain an
RO oversees may consist of slices of other domains.</t>
<t hangText="Resource Manager (RM)"> <vspace/>Entity responsible for
controlling and managing different types of resources and/or network
functions.</t>
<t hangText="Management and Orchestration (MANO)"><vspace/>In the
ETSI NFV framework <xref target="ETSI-NFV-MANO"/>, MANO is the
global entity responsible for management and orchestration of NFV
lifecycle.</t>
</list></t>
<t> Further, we make use of the following terms:
<list style="hanging">
<t hangText="NF"> is a network function, either software-based
(VNF) or appliance-based.</t>
<t hangText="SW"> is a (routing/switching) network element with a
programmable control plane interface.</t>
<t hangText="DC"> is a data center network element which in
addition to a programmable control plane interface offers a DC
control interface.</t>
<t hangText="LS"> is a logical switch instance.</t>
<t hangText="CN"> is an element equipped with compute and/or storage resources.</t>
<t hangText="UN"> or universal node, is a network element that
integrates and manages in a unified platform both compute and
networking components.</t>
</list></t>
</section>
</section>
<section title="Examples">
<section title="DC - WAN - DC Example">
<t>Assume that the set of virtual network and non-network functions is
determined, reserved and deployed across the different islands, the
resulting virtual network environment is ready for being used by any
tool or application the user wants to deploy in
it. <xref target="fig_ro-mapping"/> illustrates a resource
orchestrator (RO) as a functional entity whose task is to map the
service graph to the infrastructure resources under some service
constraints and taking into account the NF resource
descriptions.</t>
<figure anchor="fig_ro-mapping" align="center"
title="Resource Orchestrator: network function information base (NF-IB), inputs and output">
<artwork align="center">
<![CDATA[
|[Service Graph]
V
+--------------------+
|Service Orchestrator|
+--------------------+
|
V
^ +--------+ +--------------------+
| | NF-IB | |Resource |
|C |Resource|<->|Orchestrator (RO0) |
|O | Descr. | | |
|N +--------+ +---[aggregator]-----+
|T A A A
|R .-----------/ | \---------.
|O | | |
|L +-S-+ +-S-+ +-S-+
| |RO1| |RO2| |RO3|
V +---+ +---+ +---+
^ +---+
|D +--|SW3|--+
|A | +---+ |
|T +---+ | | +---+
|A 1 |PoP| +---+ +---+ |PoP| 8
| o--|DC1|-----|SW2|-----|SW4|----|DC2|--o
V +---+ +---+ +---+ +---+
[- SP1 -][- SP2 -][- SP3 -]
]]>
</artwork></figure>
<t>NF resource descriptions in the NF-IB are assumed to contain
information necessary to map NF types to a choice of instantiable
VNF flavor or a selection of an already deployed NF appliance and
networking demands for different operational policies. For example,
if energy efficiency is to be considered during the decision process
then information related to energy consumption of different NF
flavors under different conditions (e.g., network load) should be
included in the resource description.</t>
<t>Note that we also introduce a new service provider (SP0) which
effectively operates on top of the virtualized infrastructure
offered by service providers SP1, SP2 and SP3.</t>
<t>In order for the RO to execute the resource mapping it needs to
operate on the combined control plane illustrated in
<xref target="fig_ro-ctrls"/>. In this figure we mark clearly that
the interfaces to the compute (DC) control plane and the SDN (SW)
control plane are distinct and implemented through different
interfaces/APIs. For example, Ic1 could be the Apache CloudStack
API, while Ic2 could be a control plane protocol such as ForCES or
OpenFlow <xref target="RFC7426" />. In this case, the orchestrator at
SP0 (top part of the figure) needs to maintain a tight coordination
across this range of interfaces.</t>
<figure anchor="fig_ro-ctrls" align="center"
title="The RO Control Plane view. Control plane interfaces are indicated
with (line) arrows. Data plane connections are indicated with simple
lines.">
<artwork align="center">
<![CDATA[
+---------+
|Orchestr.|
| RO0 |
_____+---------+_____
/ | \
/ V Ic2 \
| +---------+ |
Ic1 V |SDN Ctrl | V Ic3
+---------+ | RO2 | +---------+
|Comp Ctrl| +---------+ |Comp Ctrl|
| RO1 | / | \ | RO3 |
+---------+ +--- V ----+ +---------+
| | +----+ | |
| | |SW3 | | |
V | +----+ | V
+----+ V / \ V +----+
1 |PoP | +----+ +----+ |PoP | 8
o--|DC1 |----|SW2 |------|SW4 |----|DC2 |--o
+----+ +----+ +----+ +----+
[- SP1 -][- SP2 -][- SP3 -]
[- SP0 -]
]]>
</artwork>
</figure>
</section>
<section title="Monitoring and AAA">
<t><xref target="fig-mro"/> illustrates Resource Orchestrators (RO)
which are responsible for orchestrating end-to-end network services
and resources reservations in the whole infrastructure. Moreover,
ROs should be able to delegate end-to-end resource and service
provisioning in technology-agnostic way.</t>
<t>ROs are connected to different types of Resource Managers (RMs),
which are in turn used to control and manage different kinds of
technological resources. For example, the RM (WAN) provides
connectivity between L1/L2 network domains at the two ends. This
management can be achieved using frame, packet or circuit switching
technologies and should support different protocols.</t>
<t>On the other hand, for instance, the RM (LAN) manages the network
infrastructure composed of SDN-enabled devices, e.g. OpenFlow
switches or routers. In short, it can control the user traffic
environment by updating flow tables in physical devices.</t>
<t>AAA is a cross layer function facilitating authN/authZ procedures
in federated facilities. Similarly, monitoring allows to retrieve,
correlate and abstract statistics from the different components of
the physical and virtual resources.</t>
<figure title="Recursive Orchestration: Monitoring and AAA"
align="center" anchor="fig-mro">
<preamble/>
<artwork>
<![CDATA[
+---+ +------------------------------------------+ +---+
| | | Resource Orchestrator - RO | | |
| |--| |--| |
| | +------------------------------------------+ | |
| | ... ... | |
| | | | | |
| | | | | |
| M | +-------------------------------+ +----+ | |
| O |--| RO | ... | RO |--| A |
| N | +-------------------------------+ +----+ | A |
| I | | | | | | A |
| T | | | | | | |
| O | +-----------+ +-------+ +-------+ +----+ | |
| R | | Resource | | RM | | RM | | RM | | |
| I |--| Manager | | | | | | |--| |
| N | | (compute) | | (LAN) | | (WAN) | | | | |
| G | +-----------+ +-------+ +-------+ +----+ | |
| | | | | | | |
| | +-----------+ +-------+ +-------+ +----+ | |
| |--| NVFI PoP | |Network| |Network| |NFVI|--| |
+---+ +-----------+ +-------+ +-------+ +----+ +---+
]]>
</artwork>
<postamble/>
</figure>
</section>
</section>
<section title="Review of Open Orchestration Frameworks">
<section title="OpenStack">
<t>Among cloud orchestration solutions, OpenStack is the de facto
common reference through its Heat module
<xref target="os-heat"/>. OpenStack Heat implements an orchestration
engine to launch multiple composite cloud applications based on
templates in the form of text files that can be treated like
code. Many existing CloudFormation templates can be launched on
OpenStack. Heat provides both an OpenStack-native REST API and a
CloudFormation-compatible Query API.</t>
<t>A Heat template describes the infrastructure for a cloud
application in a text file. Infrastructure resources that can be
described include: servers, floating IPs, volumes, security groups,
users, etc. Templates can also specify the relationships between
resources (e.g. this volume is connected to this server). Heat also
provides an auto-scaling service.</t>
<t>Heat primarily manages cloud infrastructure, does not support federation and AAA is bundled in the OpenStack framework.</t>
</section>
<section title="OpenMANO">
<t>OpenMANO is an open source project which implements the reference
architecture for Management and Orchestration under standardization at
ETSI NFV ISG (NFV MANO) <xref target="openmano"/>. OpenMANO consists
of two main SW components:
<list style="symbols">
<t>NFV VIM (Virtualised Infrastructure Manager) to provide
computing and networking capabilities and to deploy virtual
machines.</t>
<t>A reference implementation of an Network Functions
Virtualisation Orchestrator (NFV-O), which allows the creation and
deletion of VNF templates, VNF instances, network service
templates and network service instances.</t>
</list></t>
<t>OpenMANO does not support federation and AAA as of today.</t>
</section>
<section title="UNIFYing Carrier Network and Cloud Resources (UNIFY)">
<t>The UNIFY project pursues full network and service virtualization
to enable rich and flexible services and operational efficiency. The
main goal of the project is to unify software and network resources in
a common framework. The UNIFY API combines compute, storage and
network resources into a joint programmatic reference point, allowing
multi-level virtualization and orchestration of Network Function
Forwarding Graph for fast and flexible service chaining. While the
ambition is similar to ETSI NFV, the project pursues a recurring
control architecture, which similar to the ONF's SDN control plane
architecture <xref target="ONF-SDN-ARCH"/>. The UNIFY's problem
statement and challenges are documented in
<xref target="I-D.unify-nfvrg-challenges"/> while the proposed
virtualization and control API is defined in
<xref target="I-D.unify-nfvrg-recursive-programming"/>.</t>
</section>
<section title="Federated Experimentation Infrastructures">
<t>The FELIX project implements federation and integration of
different network and compute resources controlled via SDN and
Network Service Interface (NSI) in a multi-domain heterogeneous
environment across, initially spanning Europe and Japan. The FELIX
architecture extends and advances assets previously developed
(e.g. in OFELIA), by realizing the federation concepts defined in
SFA <xref target="SFA"/> with a combination of recursive and
hierarchical orchestration, request delegation and inter-domain
dependency management. Further details are available in
<xref target="I-D.felix-nfvrg-recursive-orchestration" /> and the
references therein.</t>
</section>
</section>
<section anchor="sec-challenges" title="Challenges">
<t>Orchestrating networking resources appears to have a recursive
nature at different levels of the hierarchy. Would a programmatic
interface at the combined compute and network abstraction better
support this recursive and constraint-based resource allocation?
Further, can such a joint compute, storage and network programmatic
interface allow an automated resource orchestration similar to the
recursive SDN architecture
<xref target="RFC7426"/><xref target="ONF-SDN-ARCH"/>? Below we we
summarize key questions and challenges which arise from the
recursive resource orchestration and management concepts.</t>
<section anchor="sec:chal-res-descr" title="Resource description">
<t>A prerequisite for joint placement decisions of compute, storage
and network is the adequate description of available
resources. There have been manifold attempts to create frameworks
for resource description, most prominently RDF of W3C, NDL, the
GENI RPC and its concept of Aggregate Managers, ONF's TTP and many
more. Quite naturally, all attempts to standardize "arbitrary"
resource descriptions lead to creating ontologies, complex graphs
describing relations of terms to each other.</t>
<t>Practical descriptions of compute resources are currently
focusing on number of logical CPU cores, available RAM and storage,
allowing, e.g., the OpenStack Nova scheduler to meet placement
decisions. In heterogeneous network and compute environments,
hardware may have different acceleration capabilities (e.g., AES-NI
or hardware random number generators), so the notion of logical
compute cores is not expressive enough. In addition, the network
interfaces (and link load) provide important information on how
fast a certain VNF can be executed in one node.</t>
<t>This may lead to a description of resources as VNF-FGs themselves.
Networking resource (SW) may expose the capability to forward and
process frames in, e.g., an OpenFlow TableFeatures reply. Compute nodes
in the VNF-FG would expose lists of capabilities like the presence of
AES hardware acceleration, Intel DPDK support, or complex functions
like a running web server. An essential part of the compute node's
capability would be the ability to run a certain VNF of type X within
a certain QoS spec. As the QoS is service specific, it can only be
exposed by a control function within the instantiated VNF-FG.</t>
</section> <!-- resource description -->
<section anchor="sec:chal-dependencies" title="Dependencies (de-composition)">
<t>Salt <xref target="SALT"/>, Puppet <xref target="PUPPET"/>, Chef
<xref target="CHEF"/> and Ansible <xref target="ANSIBLE"/> are
tools to manage large scale installations of virtual machines in
DC environments. Essentially, the decomposition of a complex
function into its dependencies is encoded in "recipes"
(Chef).</t>
<t>The OASIS TOSCA <xref target="TOSCA"/> specification aims at
describing application layer services to automate interoperable
deployment in alternative cloud environments. The TOSCA
specification "provides a language to describe service components
and their relationships using a service topology".</t>
<t>Is there a dependency (decomposition) abstraction suitable to
drive resource orchestration between application layer descriptions
(like TOSCA) and cloud specific installations (like Chef
recipes)?</t>
</section>
<section anchor="sec:chal-elastic-VNF" title="Elastic VNF">
<t>In many use cases, a VNF may not be designed for scaling
up/down, as scaling up/down may require a restart of the VNF
which the state data may be lost. Normally a VNF may be capable
for scaling in/out only. Such VNF is designed running on top of
a small VM and grouped as a pool of one VNF function. VNF
scaling may cross multiple NFVI PoPs (or data center)s in
order to avoid limitation of the NVFI capability. At cross-DC
scaling, the result is that the new VNF instance may be placed
at a remote cloud location. At VNF scaling, it is a must
requirement to provide the same level of Service Level Agreement
(SLA) including performance, reliability and security.</t>
<t>In general, a VNF is part of a VNF Forwarding Graph (VNF FG),
meaning the data traffic may traverse multiple stateful and
stateless VNF functions in sequence. When some VNF instances of
a given service function chain are placed / scaled out in a
distant cloud execution, the service traffic may have to
traverse multiple VNF instances which are located in multiple
physical locations. In the worst case, the data traffic may
ping-pong between multiple physical locations. Therefore it is
important to take the whole service function chain's performance
into consideration when placing and scaling one of its VNF
instance. Network and cloud resources need mutual
considerations, see
<xref target="I-D.zu-nfvrg-elasticity-vnf"/>.</t>
</section> <!-- Elastic VNF -->
<section anchor="sec:chal-measurement" title="Measurement and analytics">
<t>Programmable, dynamic, and elastic VNF deployment requires that
the Resource Orchestrator (RO) entities obtain timely information
about the actual operational conditions between different
locations where VNFs can be placed. Scaling VNFs in/out/up/down,
VNF execution migration and VNF mobility, as well as right-sizing
the VNFI resource allocations is a research area that is expected
to grow in the coming years as mechanisms, heuristics, and
measurement and analytics frameworks are developed.</t>
<t>For example, Veitch et al. <xref target="IAF"/> point out that NFV deployment
will "present network operators with significant implementation
challenges". They look into the problems arising from the lack of
proper tools for testing and diagnostics and explore the use of
embedded instrumentation. They find that in certain scenarios
fine-tuning resource allocation based on instrumentation can lead
to at least 50% reduction in compute provisioning. In this
context, three categories emerge where more research is
needed.</t>
<t>First, in the compute domain, performance analysis will need to evolve
significantly from the current "safety factor" mentality which has served
well carriers in the dedicated, hardware-based appliances era. In the
emerging softwarized deployments, VNFI will require new tools for planning,
testing, and reliability assurance. Meirosu et
al. <xref target="I-D.unify-nfvrg-devops" /> describe in detail the
challenges in this area with respect to verification, testing,
troubleshooting and observability.</t>
<t>Second, in the network domain, performance measurement and analysis will
play a key role in determining the scope and range of VNF distribution
across the resources available. For example, IETF has worked on the
standardization of IP performance metrics for years. The Two-Way Active
Measurement Protocol (TWAMP) could be employed, for instance, to capture
the actual operational state of the network prior to making RO
decisions. TWAMP management, however, still lacks a standardized and
programmable management and configuration data model
<xref target="I-D.cmzrjp-ippm-twamp-yang" />. We expect that as VNFI
programmability gathers interest from network carriers several IETF
protocols will be revisited in order to bring them up to date with respect
to the current operational requirements. To this end, NFVRG can play an
active role in identifying future IETF standardization directions.</t>
<t>Third, non-technical considerations which relate to business aspects or
priorities need to be modeled and codified so that ROs can take intelligent
decisions. Meirosu et al. <xref target="I-D.unify-nfvrg-devops" />
identify two aspects of this problem, namely a) how high-level network
goals are translated into low-level configuration commands; and b)
monitoring functions that go beyond measuring simple metrics such as delay
or packet loss. Energy efficiency and cost, for example, can steer NFV
placement. In NFVI deployments operational practices such as follow-the-sun
will be considered as earlier research in the data center context
implies.</t>
</section> <!-- Measurement -->
</section> <!-- Challenges -->
<section anchor="IANA" title="IANA Considerations">
<t>No IANA considerations are applicable.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not have any impact on the security of the Internet.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This work has been partially supported and funded by the European
Commission through the FP7 UNIFY (grant agreement no. 619609), FP7
ICT FELIX (grant agreement no. 608638) projects and the National Institute of
Information and Communications Technology (NICT) in Japan. The views
expressed here are those of the authors only. The European
Commission and NICT are not liable for any use that may be made of
the information in this document.</t>
</section>
<section title="Contributors">
<t>The editors would like to acknowledge in alphabetical order the
following contributors from the FELIX and UNIFY projects who have
provided text, comments, pointers, and ideas during the development
of earlier versions of this document: Bartosz Belter, Carlos
Bermudo, Andras Csaszar, Diego Daino, Mario Kind, Tomohiro Kudoh,
Catalin Meirosu, Zu Qiang, Jin Tanaka, Fritz-Joachim Westphal, and
Hagen Woesner.</t>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor="SFA">
<front>
<title abbrev="SFA">
Slice-based Federation Architecture (SFA) v2.0
</title>
<author surname="L. Peterson, R. Ricci, A. Falk and J. Chase"/>
<date year="2010" month="July"/>
</front>
<seriesInfo name="" value=""/>
</reference>
<reference anchor="FELIX-D2.1">
<front>
<title abbrev="FELIX-D2.1">
FELIX Deliverable D2.1 - Experiment Use Cases and Requirements
</title>
<author surname="R. Krzywania, W. Bogacki, B. Belter, K. Pentikousis, T. Rothe, G. Carrozzo, N. Ciulli, C. Bermudo, T. Kudoh, A. Takefusa, J. Tanaka and B. Puype"/>
<date year="2013" month="September"/>
</front>
<seriesInfo name="" value="Available online at http://www.ict-felix.eu."/>
</reference>
<reference anchor="FELIX-D2.2">
<front>
<title abbrev="FELIX-D2.2">
FELIX Deliverable D2.2 - General Architecture and Functional Blocks
</title>
<author surname="R. Krzywania, W. Bogacki, B. Belter, K. Pentikousis, T. Rothe, M. Broadbent, G. Carrozzo, N. Ciulli, R. Monno, C. Bermudo, A. Vico, C. Fernandez, T. Kudoh, A. Takefusa, J. Tanaka and B. Puype"/>
<date year="2014" month="February"/>
</front>
<seriesInfo name="" value="Available online at http://www.ict-felix.eu."/>
</reference>
<reference anchor="middlebox">
<front>
<title abbrev="middlebox">
Flow Processing and the Rise of Commodity Network Hardware
</title>
<author surname="A. Greenhalgh, F. Huici, M. Hoerdt, P. Papadimitriou, M. Handley, and L. Mathy"/>
<date year="2009" month="April"/>
</front>
<seriesInfo name="ACM SIGCOMM Computer Communication Review" value="Volume 39 issue 2"/>
</reference>
<reference anchor="cloudstack">
<front>
<title abbrev="cloudstack">
Apache CloudStack documentation. Cloud Infrastructure Concepts
</title>
<author surname=""/>
<date year="" month=""/>
</front>
<seriesInfo name="Available online at" value="http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.1.0/html/Admin_Guide/cloud-infrastructure-concepts.html"/>
</reference>
<reference anchor="openstack">
<front>
<title abbrev="openstack">
Scaling Openstack
</title>
<author surname=""/>
<date year="" month=""/>
</front>
<seriesInfo name="Available online at" value="http://docs.openstack.org/openstack-ops/content/scaling.html"/>
</reference>
<reference anchor="os-heat">
<front>
<title abbrev="os-heat">
OpenStack Orchestration - Heat
</title>
<author surname=""/>
<date year="" month=""/>
</front>
<seriesInfo name="Available online at" value="https://wiki.openstack.org/wiki/Heat"/>
</reference>
<reference anchor="openmano">
<front>
<title abbrev="openmano">
OpenMANO
</title>
<author surname=""/>
<date year="" month=""/>
</front>
<seriesInfo name="Available online at" value="https://github.com/nfvlabs/openmano/wiki"/>
</reference>
<reference anchor="ETSI-NFV-Arch" target="http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.01.01_60/gs_NFV002v010101p.pdf">
<front>
<title>Architectural Framework v1.1.1</title>
<author>
<organization>ETSI</organization>
</author>
<date month="Oct" year="2013" />
</front>
</reference>
<reference anchor="ETSI-NFV-MANO" target="http://docbox.etsi.org/ISG/NFV/Open/Latest_Drafts/NFV-MAN001v061-%20management%20and%20orchestration.pdf">
<front>
<title>Network Function Virtualization (NFV) Management and
Orchestration V0.6.1</title>
<author>
<organization>ETSI</organization>
</author>
<date month="Jul." year="2014" />
</front>
</reference>
<reference anchor="ONF-SDN-ARCH"
target="https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf">
<front>
<title>SDN architecture</title>
<author>
<organization>ONF</organization>
</author>
<date month="Jun." year="2014" />
</front>
</reference>
<reference anchor="NSC">
<front>
<title>Research directions in network service chaining</title>
<author><organization>John, W., Pentikousis, K., et al.</organization></author>
<date month="November" year="2013" />
</front>
<seriesInfo name="Proc. SDN for Future Networks and Services (SDN4FNS), Trento, Italy" value="IEEE"></seriesInfo>
</reference>
<reference anchor="IAF">
<front>
<title>An Instrumentation and Analytics Framework for Optimal and Robust NFV Deployment</title>
<author><organization>Veitch, P., McGrath, M. J., and Bayon, V.</organization></author>
<date month="February" year="2015" />
</front>
<seriesInfo name="Communications Magazine, vol. 53, no. 2" value="IEEE"></seriesInfo>
</reference>
<reference anchor="CHEF" target="https://docs.chef.io/chef_overview.html">
<front>
<title>An Overview of Chef</title>
<author><organization>Chef Software Inc.</organization></author>
<date year="2015" />
</front>
</reference>
<reference anchor="PUPPET" target="http://docs.puppetlabs.com/puppet/3.7/reference/">
<front>
<title>Puppet 3.7 Reference Manual</title>
<author><organization>Puppet Labs.</organization></author>
<date year="2015" />
</front>
</reference>
<reference anchor="ANSIBLE" target="http://docs.ansible.com/index.html">
<front>
<title>Ansible Documentation</title>
<author><organization>Ansible Inc.</organization></author>
<date year="2015" />
</front>
</reference>
<reference anchor="SALT" target="http://docs.saltstack.com/en/latest/contents.html">
<front>
<title>Salt (Documentation)</title>
<author><organization>SaltStack</organization></author>
<date year="2015" />
</front>
</reference>
<reference anchor="TOSCA" target="http://docs.oasis-open.org/tosca/TOSCA/v1.0/os/TOSCA-v1.0-os.html">
<front>
<title>Topology and Orchestration Specification for Cloud Applications Version 1.0</title>
<author><organization>OASIS Standard</organization></author>
<date year="2013" month="November" day="25" />
</front>
</reference>
&RFC7498;
&RFC7426;
&I-D.zu-nfvrg-elasticity-vnf;
&I-D.cmzrjp-ippm-twamp-yang;
&I-D.unify-nfvrg-devops;
&I-D.unify-nfvrg-challenges;
&I-D.unify-nfvrg-recursive-programming;
&I-D.felix-nfvrg-recursive-orchestration;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:43:46 |