One document matched: draft-unify-nfvrg-challenges-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc tocindent="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC7426 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7426.xml">
<!ENTITY SFCProb SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sfc-problem-statement.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.cmzrjp-ippm-twamp-yang SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cmzrjp-ippm-twamp-yang.xml">
<!ENTITY I-D.unify-nfvrg-devops SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.unify-nfvrg-devops.xml">
]>
<rfc category="info" ipr="trust200902" docName="draft-unify-nfvrg-challenges-02">
<front>
<title abbrev="UNIFY Challenges">Unifying Carrier and Cloud Networks: Problem Statement and Challenges</title>
<author fullname="Robert Szabo" initials="R." surname="Szabo">
<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>
<email>robert.szabo@ericsson.com</email>
<uri>http://www.ericsson.com/</uri>
</address>
</author>
<author fullname="Andras Csaszar" initials="A." surname="Csaszar">
<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>
<email>andras.csaszar@ericsson.com</email>
<uri>http://www.ericsson.com/</uri>
</address>
</author>
<author fullname="Kostas Pentikousis" initials="K.P." surname="Pentikousis">
<organization abbrev="EICT">EICT GmbH</organization>
<address>
<postal>
<street>EUREF-Campus Haus 13</street>
<street>Torgauer Strasse 12-15</street>
<city>10829 Berlin</city>
<country>Germany</country>
</postal>
<email>k.pentikousis@eict.de</email>
</address>
</author>
<author fullname="Mario Kind" initials="M." surname="Kind">
<organization abbrev="Deutsche Telekom AG">Deutsche Telekom AG</organization>
<address>
<postal>
<street>Winterfeldtstr. 21</street>
<city>10781 Berlin</city>
<country>Germany</country>
</postal>
<email>mario.kind@telekom.de</email>
</address>
</author>
<author fullname="Diego Daino" initials="D." surname="Daino">
<organization abbrev="Telecom Italia">Telecom Italia</organization>
<address>
<postal>
<street>Via Guglielmo Reiss Romoli 274</street>
<city>10148 Turin</city>
<country>Italy</country>
</postal>
<email>diego.daino@telecomitalia.ite</email>
</address>
</author>
<author fullname="Zu Qiang" initials="Z." surname="Qiang">
<organization abbrev="Ericsson">Ericsson</organization>
<address>
<postal>
<street>8400, boul. Decarie</street>
<city>Ville Mont-Royal</city>
<region>QC</region>
<code>8400</code>
<country>Canada</country>
</postal>
<email>zu.qiang@ericsson.com</email>
<uri>http://www.ericsson.com/</uri>
</address>
</author>
<author fullname="Hagen Woesner" initials="H." surname="Woesner">
<organization abbrev="BISDN">BISDN</organization>
<address>
<postal>
<street>Körnerstr. 7-10</street>
<city>Berlin</city>
<code>10785</code>
<country>Germany</country>
</postal>
<email>hagen.woesner@bisdn.de</email>
<uri>http://www.bisdn.de</uri>
</address>
</author>
<date year="2015" />
<area>IRTF</area>
<workgroup>NFVRG</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>The introduction of network and service functionality
virtualization in carrier-grade networks promises improved
operations in terms of flexibility, efficiency, and
manageability. In current practice, virtualization is
controlled through orchestrator entities that expose
programmable interfaces according to the underlying resource
types. Typically this means the adoption of, on the one hand, established data
center compute/storage and, on the other, network control APIs which were
originally developed in isolation. Arguably, the possibility
for innovation highly depends on the capabilities and openness
of the aforementioned interfaces. This document introduces in
simple terms the problems arising when one follows this
approach and motivates the need for a high level of
programmability beyond policy and service descriptions. This
document also summarizes the challenges related to
orchestration programming in this unified cloud and carrier
network production environment.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<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 speedy service
creation, as discussed in <xref target="NSC" /> and the references
therein. For instance, it is not unusual that today an average service
creation time cycle exceeds 90 hours, whereas given the recent advances
in virtualization and cloudification one would be interested in service
creation times in the order of minutes
<xref target="EU-5GPPP-Contract"/> if not seconds.</t>
<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="I-D.ietf-sfc-problem-statement" />. 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>Compute virtualization is central to the concept of Network Function
Virtualization (NFV). However, carrier-grade services demand that all
components of the data path, such as Network Functions (NFs), virtual NFs
(VNFs) and virtual links, meet key performance requirements. In this
context, the inclusion of Data Center (DC) platforms, such as OpenStack
<xref target="OpenStack"/>, into the SDN infrastructure is far from
trivial.</t>
<t>In this document we examine the problems arising as one
combines these two formerly isolated environments in an effort
to create a unified production environment and discuss the
associated emerging challenges. Our goal is the definition of
a production environment that allows multi-vendor and
multi-domain operation based on open and interoperable
implementations of the key entities described in the remainder
of this document.</t>
</section>
<section title="Terms and Definitions" anchor="terms">
<t>We use the term compute and "compute and storage"
interchangeably throughout the document. Moreover, we use the
following definitions, as established in
<xref target="ETSI-NFV-Arch"/>:</t>
<t><list style="hanging">
<t hangText="NFV:">Network Function Virtualization - The
principle of separating network functions from the
hardware they run on by using virtual hardware
abstraction.</t>
<t hangText="NFVI PoP:">NFV Infrastructure Point of
Presence - Any combination of virtualized compute,
storage and network resources.</t>
<t hangText="NFVI:">NFV Infrastructure - Collection of
NFVI PoPs under one orchestrator.</t>
<t hangText="VNF:">Virtualized Network Function -
a software-based network function.</t>
<t hangText="VNF FG:">Virtualized Network Function
Forwarding Graph - an ordered list of VNFs creating a
service chain.</t>
<t hangText="MANO:">Management and Orchestration - In the
ETSI NFV framework <xref target="ETSI-NFV-MANO"/>, this
is the global entity responsible for management and
orchestration of NFV lifecycle.</t>
</list></t>
<t>Further, we make use of the following terms:</t>
<t><list style="hanging">
<t hangText="NF:">a network function, either software-based
(VNF) or appliance-based.</t>
<t hangText="SW:">a (routing/switching) network element
with a programmable control plane interface.</t>
<t hangText="DC:"> a data center network element which in
addition to a programmable control plane interface
offers a DC control interface</t>
<t hangText="LSI:">Logical Switch Instance - a software
switch instance.</t>
<t hangText="CN:">an element equipped with compute and/or storage
resources.</t>
<t hangText="UN:">Universal Node - an innovative element that
integrates and manages in a unified platform both compute and networking
components.</t>
</list></t>
</section>
<section anchor="motivation" title="Motivations">
<t><xref target="fig_service_graph"/> illustrates a simple service
graph comprising three network functions (NFs). For the sake of
simplicity, we will assume only two types of infrastructure
resources, namely SWs and DCs as per the terminology introduced
above, and ignore appliance-based NFs for the time being. The
goal is to implement the given service based on the available
infrastructure resources.</t>
<figure anchor="fig_service_graph" align="center" title="Service graph">
<artwork align="center"><![CDATA[
fr2 +---+ fr3
+->o-|NF2|-o-+
| 4 +---+ 5 |
+---+ | V +---+
1-->o-|NF1|-o----------->o-|NF3|-o-->8
2 +---+ 3 fr1 6 +---+ 7
]]></artwork>
</figure>
<t>The service graph definition contains NF types (NF1, NF2, NF3) along with the
<list style="symbols">
<t>corresponding ports (NF1:{2,3}; NF2:{4,5}; NF3:{6,7})</t>
<t>service access points {1,8} corresponding to infrastructure resources,</t>
<t>definition of forwarding behavior (fr1, fr2, fr3)</t>
</list>
The forwarding behavior contains classifications for matching
of traffic flows and corresponding outbound forwarding
actions.</t>
<t>Assume now that we would like to use the infrastructure
(topology, network and software resources) depicted in
<xref target="fig_infrastructure"/> and
<xref target="fig_pop-dc"/> to implement the aforementioned
service graph. That is, we have three SWs and two Points of
Presence (PoPs) with DC software resources at our
disposal.</t>
<figure anchor="fig_infrastructure" align="center" title="Infrastructure resources">
<artwork align="center"><![CDATA[
+---+
+--|SW3|--+
| +---+ |
+---+ | | +---+
1 |PoP| +---+ +---+ |PoP| 8
o--|DC1|----|SW2|------|SW4 |---|DC2|--o
+---+ +---+ +---+ +---+
[---SP1---][--------SP2-------][---SP3----]
]]></artwork>
</figure>
<figure anchor="fig_pop-dc" align="center" title="A
virtualized Point of Presence (PoP) with software resources
(Compute Node - CN)">
<artwork align="center"><![CDATA[
+----------+
| +----+ |PoP DC (== NFVI PoP)
| | CN | |
| +----+ |
| | | |
| +----+ |
o-+--| SW |--+-o
| +----+ |
+----------+
]]></artwork>
</figure>
<figure anchor="fig:un" align="center" title=" Universal Node - an innovative element that integrates on
the same platform both compute and networking components">
<artwork align="center"><![CDATA[
+----------+
| +----+ | UN
| | CN | |
o-+--+----+--+-o
| | SW | |
| +----+ |
+----------+
]]></artwork>
</figure>
<t>In the simplest case, all resources would be part of the same
service provider (SP) domain. We need to ensure that each entity in
<xref target="fig_infrastructure"/> can be procured from a different
vendor and therefore interoperability is key for multi-vendor NFVI
deployment. Without such interoperability different technologies for
data center and network operation result in distinct technology
domains within a single carrier. Multi-technology barriers start to
emerge hindering the full programmability of the NFVI and limiting
the potential for rapid service deployment.</t>
<t>We are also interested in a multi-operation environment, where the
roles and responsibilities are distributed according to some
organizational structure within the organization. Finally, we are
interested in multi-provider environment, where different
infrastructure resources are available from different service
providers (SPs). <xref target="fig_infrastructure"/> indicates a
multi-provider environment in the lower part of the figure as an
example. We expect that this type of deployments will become more
common in the future as they are well suited with the elasticity and
flexibility requirements <xref target="NSC" />.</t>
<t><xref target="fig_infrastructure"/> also shows the service access
points corresponding to the overarching domain view, i.e., {1,8}. In
order to deploy the service graph of
<xref target="fig_service_graph"/> on the infrastructure resources of
<xref target="fig_infrastructure"/>, we will need an appropriate
mapping which can be implemented in practice.</t>
<t><xref target="fig_pop-dc"/> shows the structure of a PoP DC that
presents compute and network resources while <xref target="fig:un"/>
shows the structure of the Universal Node (UN), an innovative element
that integrates on the same platform both compute and networking
components and that could be used in the infrastructure as an
alternative to elements depicted in
<xref target="fig_infrastructure"/> for what concerns network and/or
compute resources.</t>
<t>In <xref target="fig_ro-mapping"/> we illustrate 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: information base, inputs and output">
<artwork align="center"><![CDATA[
fr2 +---+ fr3
+->o-|NF2|-o-+
| 4 +---+ 5 |
+---+ | V +---+
1-->o-|NF1|-o----------->o-|NF3|-o-->8
2 +---+ 3 fr1 6 +---+ 7
||
||
+--------+ \/ SP0
| NF | +---------------------+
|Resource|==>|Resource Orchestrator|==> MAPPING
| Descr. | | (RO) |
+--------+ +---------------------+
/\
||
||
+---+
+--|SW3|--+
| +---+ |
+---+ | | +---+
1 |PoP| +---+ +---+ |PoP| 8
o--|DC1|-----|SW2|-----|SW4|----|DC2|--o
+---+ +---+ +---+ +---+
[---SP1---][--------SP2-------][---SP3----]
[-------------------SP0-------------------]
]]></artwork>
</figure>
<t>NF resource descriptions 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 SP1, SP2 and SP3.</t>
<t>In order for the RO to execute the resource mapping (which
in general is a hard problem) 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.|
| SP0 |
_____+---------+_____
/ | \
/ V Ic2 \
| +---------+ |
Ic1 V |SDN Ctrl | V Ic3
+---------+ | SP2 | +---------+
|Comp Ctrl| +---------+ |Comp Ctrl|
| SP1 | / | \ | SP3 |
+---------+ +--- V ----+ +---------+
| | +----+ | |
| | |SW3 | | |
V | +----+ | V
+----+ V / \ V +----+
1 |PoP | +----+ +----+ |PoP | 8
o--|DC1 |----|SW2 |------|SW4 |----|DC2 |--o
+----+ +----+ +----+ +----+
[----SP1---][---------SP2--------][---SP3----]
[---------------------SP0--------------------]
]]></artwork>
</figure>
<t>In the real-world, however, orchestration operations do not
stop, for example, at the DC1 level as depicted in
<xref target="fig_ro-ctrls"/>. If we (so-to-speak) "zoom into"
DC1 we will see a similar pattern and the need to coordinate
SW and DC resources within DC1 as illustrated in
<xref target="fig_dc"/>. As depicted, this edge PoP includes
compute nodes (CNs) and SWs which in most of the cases will
also contain an internal topology.</t>
<t>In <xref target="fig_dc"/>, IcA is an interface similar to
Ic2 in <xref target="fig_ro-ctrls"/>, while IcB could be, for
example, OpenStack Nova or similar. The Northbound Interface
(NBI) to the Compute Controller can use Ic1 or Ic3 as shown in
<xref target="fig_ro-ctrls"/>.</t>
<figure anchor="fig_dc" align="center" title="PoP DC Network with Compute Nodes (CN)">
<artwork align="center"><![CDATA[
NBI
|
+---------+
|Comp Ctrl|
+---------+
+----+ |
IcA V | IcB:to CNs
+---------+ V
|SDN Ctrl | | | ext port
+---------+ +---+ +---+
to|SW |SW | |SW |
+-> ,+--++.._ _+-+-+
V ,-" _|,,`.""-..+
_,,,--"" | `. |""-.._
+---+ +--++ `+-+-+ ""+---+
|SW | |SW | |SW | |SW |
+---+ ,'+---+ ,'+---+ ,'+---+
| | ,-" | | ,-" | | ,-" | |
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
|CN| |CN| |CN| |CN| |CN| |CN| |CN| |CN|
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
]]></artwork>
</figure>
<t>In turn, each single Compute Node (CN) may also have
internal switching resources (see <xref target="fig_cn"/>). In a
carrier environment, in order to meet data path requirements,
allocation of compute node internal distributed resources (blades,
CPU cores, etc.) may become equivalently important.</t>
<figure anchor="fig_cn" align="center" title="Compute Node with internal switching resource">
<artwork align="center"><![CDATA[
+-+ +-+ +-+ +-+
|V| |V| |V| |V|
|N| |N| |N| |N|
|F| |F| |F| |F|
+-+ +-+ +-+ +-+
| / / |
+---+ +---+ +---+
|LSI| |LSI| |LSI|
+---+ +---+ +---+
| / |
+---+ +---+
|NIC| |NIC|
+---+ +---+
| |
]]></artwork>
</figure>
<t>Based on the recursion principles shown above and the complexity
implied by separate interfaces for compute and network resources, one
could imagine a recursive programmatic interface for joint compute,
storage and network provisioning as depicted in <xref target="fig:urc-1"/>.</t>
<figure anchor="fig:urc-1" align="center" title="The RO Control Plane view considering a recursive
programmatic interface for joint compute, storage and network
provisioning">
<artwork align="center"><![CDATA[
+---------+
|Service |
|Orchestr.|
+---------+
|
|
V U
+-------------------+
| Unified Recurrent |
| Control (URC) |
+-------------------+
/ | \
/ V U \
| +---------+ |
U V | URC | V U
+---------+ | | +---------+
| URC | +---------+ | URC |
| | / | \ | |
+---------+ +--- V ----+ +---------+
| | +----+ | |
| | |SW3 | | |
V | +----+ | V
+----+ V / \ V +----+
1 |PoP | +----+ +----+ |PoP | 8
o--|DC1 |----|SW2 |------|SW4 |----|DC2 |--o
+----+ +----+ +----+ +----+
[----SP1---][---------SP2--------][---SP3----]
]]></artwork>
</figure>
<t>In <xref target="fig:urc-1"/>, Ic1, Ic2 and Ic3 of
<xref target="fig_ro-ctrls"/> have been substituted by the recursive
programmatic interface U to use for both compute and network
resources and we find also the Unified Recurrent Control (URC), an
element that performs both compute and network control and that can
be used in a hierarchy structure.</t>
<t>Considering the use of the recursive programmatic interface U and
the Unified Recurrent Control, the PoP DC Network structure with
Compute Nodes view changes as reported in <xref target="fig:urc-2"/>.</t>
<figure anchor="fig:urc-2" align="center" title="PoP DC Network with Compute Nodes (CN) considering the
U interface and the URC element">
<artwork align="center"><![CDATA[
NBI
|
+---------+
| URC |
+---------+
+----+ |
U V | U:to CNs
+---------+ V
| URC | | | ext port
+---------+ +---+ +---+
to|SW |SW | |SW |
+-> ,+--++.._ _+-+-+
V ,-" _|,,`.""-..+
_,,,--"" | `. |""-.._
+---+ +--++ `+-+-+ ""+---+
|SW | |SW | |SW | |SW |
+---+ ,'+---+ ,'+---+ ,'+---+
| | ,-" | | ,-" | | ,-" | |
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
|CN| |CN| |CN| |CN| |CN| |CN| |CN| |CN|
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
]]></artwork>
</figure>
</section>
<section anchor="problem" title="Problem Statement">
<t>The motivational examples of <xref target="motivation" /> illustrate that
almost always compute virtualization and network virtualization are
tightly connected. In particular Figure, 3 shows that in a PoP DC there
are not only compute resources (CNs) but also network resources (SWs), and
so it illustrates that compute virtualization implicitly involves network
virtualization unless we consider the unlikely scenario where dedicated
network elements are used to interconnect the different virtual network
functions implemented on the compute nodes (e.g.: to implement Flexible
Service Chaining). On the other hand, considering a network scenario made
not only of just pure SDN network elements (SWs) but also of compute
resources (CNs) or SDN network nodes that are equipped also with compute
resources (UNs), it is very likely that virtualized network resources, if
offered to clients, imply virtualization of compute resources, unless we
consider the unlikely scenario where dedicated compute resources are
available for every virtualized network.</t>
<t>Furthermore, virtualization often leads to scenarios of recursions with
clients redefining and reselling resources and services at different
levels.</t>
<t> We argue that given the multi-level virtualization of compute, storage
and network domains, automation of the corresponding resource provisioning
could be more easily implemented by a recursive programmatic
interface. Existing separated compute and network programming interfaces
cannot easily provide such recursions and cannot always satisfy key
requirement for multi-vendor, multi-technology and multi-provider
interoperability environments. Therefore we foresee the necessity of a
recursive programmatic interface for joint compute, storage and network
provisioning.</t>
</section>
<section anchor="sec-challenges" title="Challenges">
<t>We summarize in this section the key questions and challenges,
which we hope will initiate further discussions in the NFVRG
community.</t>
<section anchor="sec:chal-orch" title="Orchestration">
<t>Firstly, as motivated in <xref target="motivation"/>,
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?
</t>
<t>Secondly, can such a joint compute, storage and network
programmatic interface allow an automated resource orchestration
similar to the recursive SDN architecture
<xref target="ONF-SDN-ARCH"/>?
</t>
</section>
<section anchor="sec:chal-res-descr" title="Resource description">
<t>Prerequisite for joint placement decisions of compute, storage
and network is the adequate description of available
resources. This means that the interfaces (IcA, IcB etc. in
<xref target="fig_ro-ctrls"/> and <xref target="fig_dc"/>) are of
bidirectional nature, exposing resources as well as reserving.
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.</t>
<t>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., 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>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 crossing 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> <!-- Meaurement -->
</section> <!-- Challenges -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD</t>
</section>
<section title="Acknowledgement" anchor="acknowledgement">
<t>The authors would like to thank the UNIFY team for inspiring discussions and in particular Fritz-Joachim Westphal and Catalin Meirosu for their comments and suggestions on how to refine this draft.</t>
<t>This work is supported by FP7 UNIFY, a research
project partially funded by the European Community
under the Seventh Framework Program (grant agreement
no. 619609). The views expressed here are those of
the authors only. The European Commission is not
liable for any use that may be made of the information
in this document.</t>
</section>
</middle>
<back>
<references title="Informative References">
<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 (draft)</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="EU-5GPPP-Contract" target="http://5g-ppp.eu/contract/">
<front>
<title>Contractual Arrangement: Setting up a Public- Private
Partnership in the Area of Advance 5G Network Infrastructure for the
Future Internet between the European Union and the 5G Infrastructure
Association</title>
<author>
<organization>5G-PPP Association</organization>
</author>
<date month="Dec" year="2013" />
</front>
</reference>
<reference anchor="OpenStack" target="http://openstack.org">
<front>
<title>Openstack cloud software</title>
<author><organization>The OpenStack project</organization></author>
<date 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>
&SFCProb;
&RFC7426;
&I-D.zu-nfvrg-elasticity-vnf;
&I-D.cmzrjp-ippm-twamp-yang;
&I-D.unify-nfvrg-devops;
</references>
</back>
</rfc>
<!-- LocalWords: Jozsef EICT GmbH EUREF Haus Torgauer Strasse Reiss -->
<!-- LocalWords: Winterfeldtstr Telecom Italia Romoli boul Decarie -->
<!-- LocalWords: BISDN Körnerstr IRTF NFVRG APIs cloudification VNF -->
<!-- LocalWords: ETSI IETF NFV NFs VNFs OpenStack SDN NFVI PoPs SWs -->
<!-- LocalWords: DCs NF2 NF1 NF3 fr1 fr2 fr3 SPs RO SP0 Descr SW3 -->
<!-- LocalWords: PoP DC1 SW2 SW4 DC2 SP1 SP2 SP3 Ic1 CloudStack API -->
<!-- LocalWords: Ic2 ForCES OpenFlow CNs IcA IcB NBI Ic3 CN RDF W3C -->
<!-- LocalWords: NDL GENI RPC ONF's TTP AES FGs TableFeatures FG -->
<!-- LocalWords: QoS Ansible -->
| PAFTECH AB 2003-2026 | 2026-04-24 04:07:52 |