One document matched: draft-unify-nfvrg-challenges-00.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">
]>
<rfc category="info" ipr="trust200902" docName="draft-unify-nfvrg-challenges-00">
<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>
<date year="2014" />
<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:">NFV Infrastructure - Any combination
of virtualized compute, storage and network
resources.</t>
<t hangText="VNF:">Virtualized Network Function -
a software-based network function.</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="Motivation and Challenges">
<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, f3)</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 Point of Presence (PoP) 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 simple case, all resources
could be part of the same service provider (SP) domain, which case, we need to ensure that each entity in <xref target="fig_infrastructure"/>
could be procured from a different vendor and therefore
interoperability is key for multi-vendor NFVI deployment.</t>
<t>Alternatively, different technologies like data center
operation and network operation could result in a
separation of technology domains within a single ownership
(multi-technology).</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}. </t>
<t>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">
<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>Note that in <xref target="fig_ro-ctrls"/> we denote the
control plane interfaces with (line) arrows. Data
plane connections use simple lines.</t>
<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 is 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>Even further, 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 example of
<xref target="motivation" /> illustrates 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. Existing separated compute and network programming
interfaces cannot provide such recursions and cannot 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>
<t>We conclude this section with two key questions which we hope
will initiate the discussion in the NFVRG community for further
development of the concept described in this document.</t>
<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 a
recursive SDN architecture <xref target="ONF-SDN-ARCH"/>?
</t>
</section>
<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>
&SFCProb;
&SDNT;
&I-D.huang-sfc-use-case-recursive-service;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:47:34 |