One document matched: draft-unify-nfvrg-challenges-01.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 SFCProb SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sfc-problem-statement.xml">
<!ENTITY SDNT SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.irtf-sdnrg-layer-terminology.xml">
<!ENTITY I-D.huang-sfc-use-case-recursive-service SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.huang-sfc-use-case-recursive-service.xml">
<!ENTITY I-D.zu-nfvrg-elasticity-vnf SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.zu-nfvrg-elasticity-vnf.xml">
]>
<rfc category="info" ipr="trust200902" docName="draft-unify-nfvrg-challenges-01">
<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>
</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>
<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. 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="I-D.irtf-sdnrg-layer-terminology" />. 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>
</section>
<section anchor="problem" title="Problem Statement">
<t>The motivational examples of <xref target="motivation" />
illustrate that compute virtualization implicitly involves network
virtualization. On the other hand, if one starts with an SDN
network and adds compute resources to network elements, then
compute resources must be assigned to some virtualized network
resources if offered to clients. That is, we observe that compute
virtualization is implicitly associated with network
virtualization. Furthermore, virtualization leads to recursions
with clients (redefining and) reselling resources and services
<xref target="I-D.huang-sfc-use-case-recursive-service"/>. </t>
<t>We argue that given the multi-level virtualization of compute,
storage and network domains, automation of the corresponding
resource provisioning needs a recursive programmatic
interface. The current separated compute and network programming
interfaces cannot provide such recursions and cannot satisfy key
requirements 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.</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. 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. 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 for his 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;
&SDNT;
&I-D.huang-sfc-use-case-recursive-service;
&I-D.zu-nfvrg-elasticity-vnf;
</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:35 |