One document matched: draft-bernardos-nfvrg-gaps-network-virtualization-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' '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 I-D.matsushima-stateless-uplane-vepc SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.matsushima-stateless-uplane-vepc.xml'>
<!ENTITY I-D.king-vnfpool-mobile-use-case SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.king-vnfpool-mobile-use-case.xml'>
<!ENTITY I-D.ietf-i2rs-problem-statement SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-problem-statement.xml'>
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml'>
<!ENTITY I-D.ietf-nvo3-arch SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nvo3-arch.xml'>
<!ENTITY I-D.rfernando-bess-service-chaining SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rfernando-bess-service-chaining.xml'>
<!ENTITY rfc7665 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7665.xml'>
<!ENTITY rfc7498 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7498.xml'>
<!ENTITY I-D.ietf-dmm-fpc-cpdp SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dmm-fpc-cpdp.xml'>
<!ENTITY I-D.bernini-nfvrg-vnf-orchestration SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bernini-nfvrg-vnf-orchestration.xml'>
<!ENTITY I-D.ceccarelli-teas-actn-framework SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ceccarelli-teas-actn-framework.xml'>
<!ENTITY I-D.leeking-teas-actn-problem-statement SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.leeking-teas-actn-problem-statement.xml'>
<!ENTITY I-D.abad-sdnrg-sdn-ipsec-flow-protection SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.abad-sdnrg-sdn-ipsec-flow-protection'>
<!ENTITY rfc2330 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2330.xml'>
<!ENTITY rfc7398 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7398.xml'>
<!ENTITY rfc6349 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6349.xml'>
<!ENTITY I-D.jeong-i2nsf-sdn-security-services SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jeong-i2nsf-sdn-security-services'>
<!ENTITY I-D.cmzrjp-ippm-twamp-yang SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cmzrjp-ippm-twamp-yang'>
<!ENTITY I-D.ietf-bmwg-virtual-net SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-bmwg-virtual-net'>
<!ENTITY I-D.ietf-bmwg-sdn-controller-benchmark-term SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-bmwg-sdn-controller-benchmark-term'>
<!ENTITY I-D.ietf-bmwg-sdn-controller-benchmark-meth SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-bmwg-sdn-controller-benchmark-meth'>
<!ENTITY I-D.kim-bmwg-ha-nfvi SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kim-bmwg-ha-nfvi'>
<!ENTITY I-D.vsperf-bmwg-vswitch-opnfv SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vsperf-bmwg-vswitch-opnfv'>
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-bernardos-nfvrg-gaps-network-virtualization-04"
ipr="trust200902">
<front>
<title abbrev="Gap Analysis Network Virtualization">
Gap Analysis on Network Virtualization Activities
</title>
<!-- AUTHORS -->
<author fullname="Carlos J. Bernardos"
initials="CJ."
surname="Bernardos">
<organization abbrev="UC3M">
Universidad Carlos III de Madrid
</organization>
<address>
<postal>
<street>Av. Universidad, 30</street>
<city>Leganes, Madrid</city>
<code>28911</code>
<country>Spain</country>
</postal>
<phone>+34 91624 6236</phone>
<email>cjbc@it.uc3m.es</email>
<uri>http://www.it.uc3m.es/cjbc/</uri>
</address>
</author>
<author fullname="Akbar Rahman"
initials="A."
surname="Rahman">
<organization abbrev="InterDigital">
InterDigital Communications, LLC
</organization>
<address>
<postal>
<street>1000 Sherbrooke Street West, 10th floor</street>
<city>Montreal, Quebec</city>
<code> H3A 3G4</code>
<country>Canada</country>
</postal>
<email>Akbar.Rahman@InterDigital.com</email>
<uri>http://www.InterDigital.com/</uri>
</address>
</author>
<author fullname="Juan Carlos Zuniga"
initials="JC."
surname="Zuniga">
<organization abbrev="InterDigital">
InterDigital Communications, LLC
</organization>
<address>
<postal>
<street>1000 Sherbrooke Street West, 10th floor</street>
<city>Montreal, Quebec</city>
<code> H3A 3G4</code>
<country>Canada</country>
</postal>
<email>JuanCarlos.Zuniga@InterDigital.com</email>
<uri>http://www.InterDigital.com/</uri>
</address>
</author>
<author fullname="Luis M. Contreras"
initials="LM."
surname="Contreras">
<organization abbrev="TID">
Telefonica I+D
</organization>
<address>
<postal>
<street>Ronda de la Comunicación, S/N</street>
<city>Madrid</city>
<code>28050</code>
<country>Spain</country>
</postal>
<email>luismiguel.conterasmurillo@telefonica.com</email>
</address>
</author>
<author fullname="Pedro Aranda"
initials="P."
surname="Aranda">
<organization abbrev="TID">
Telefonica I+D
</organization>
<address>
<postal>
<street>Ronda de la Comunicación, S/N</street>
<city>Madrid</city>
<code>28050</code>
<country>Spain</country>
</postal>
<email>pedroa.aranda@telefonica.com</email>
</address>
</author>
<date month="March" year="2016" />
<area>Internet</area>
<workgroup>NFVRG</workgroup>
<abstract>
<!--
<t>
Network Function Virtualization (NFV) and Software Defined Networking (SDN) are
changing the way the telecommunications sector will deploy, extend and operate
their networks. These new technologies aim at reducing the overall costs by outsourcing
communication services from specific hardware in the operators’ core to server
farms scattered in datacenters (i.e. compute and storage virtualization). In addition,
the connecting networks are fundamentally affected in the way they route, process and
control traffic(i.e. network virtualization).
</t>
<t>
Virtualization is becoming a trend which is being adopted in many
scenarios for different purposes. This document overviews existing efforts
around virtualization at the IETF/IRTF, focusing on those related to
NFV and SDN. These efforts are mapped to the most relevant architectures being
defined outside IETF, namely at the ETSI NFV ISG, the ETSI MEC ISG and the ONF.
</t>
-->
<!-- 2015-07-06 cjbc: once we have the text about this in the annex -->
<!-- A particular use case, virtualization at the mobile networks, is then taken as
an example to go deeper in which are the current trends and the existing gaps
that require standardization efforts. -->
<t>
The main goal of this document is to serve as a survey of the different efforts
that have been taken and are currently taking place at IETF and IRTF in regards
to network virtualization, automation and orchestration, putting them into
context considering efforts by other SDOs, and identifying current gaps and
challenges that can be tackled at IETF or researched at the IRTF.
</t>
</abstract>
<!--
<note title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.
</t>
</note>
-->
</front>
<middle>
<section anchor="sec:introduction" title="Introduction">
<t>
The telecommunications sector is experiencing a major revolution that will shape
the way networks and services are designed and deployed for the next decade.
We are witnessing an explosion in the number of applications and services
demanded by users, which are now really capable of accessing them on the move.
In order to cope with such a demand, some network operators are looking at the
cloud computing paradigm, which enables a potential reduction of the overall
costs by outsourcing communication services from specific hardware in the
operator's core to server farms scattered in datacenters. These services have
different characteristics if compared with conventional IT services that have to
be taken into account in this cloudification process. Also the transport network
is affected in that it is evolving to a more sophisticated form of IP
architecture with trends like separation of control and data plane traffic, and
more fine-grained forwarding of packets (beyond looking at the destination IP
address) in the network to fulfill new business and service goals.
</t>
<t>
Virtualization of functions also provides operators with tools to deploy new
services much faster, as compared to the traditional use of monolithic and
tightly integrated dedicated machinery. As a natural next step, mobile network
operators need to re-think how to evolve their existing network infrastructures
and how to deploy new ones to address the challenges posed by the increasing
customers' demands, as well as by the huge competition among operators. All
these changes are triggering the need for a modification in the way operators
and infrastructure providers operate their networks, as they need to
significantly reduce the costs incurred in deploying a new service and operating
it. Some of the mechanisms that are being considered and already adopted by
operators include: sharing of network infrastructure to reduce costs,
virtualization of core servers running in data centers as a way of supporting
their load-aware elastic dimensioning, and dynamic energy policies to reduce the
monthly electricity bill. However, this has proved to be tough to put in
practice, and not enough. Indeed, it is not easy to deploy new mechanisms in a
running operational network due to the high dependency on proprietary (and
sometime obscure) protocols and interfaces, which are complex to manage and
often require configuring multiple devices in a decentralized way.
</t>
<t>
Network Function Virtualization (NFV) and Software Defined Networking (SDN) are
changing the way the telecommunications sector will deploy, extend and operate
their networks. This document provides a survey of the different efforts that
have taken and are currently taking place at IETF and IRTF in regards of network
virtualization, looking at how they relate to the ETSI NFV ISG, ETSI MEC ISG and
ONF architectural frameworks. Based on this analysis, we also go a step farther,
identifying which are the potential work areas where IETF/IRTF can work on to
complement the complex network virtualization map of technologies being
standardized today.
</t>
<!-- [2015-08-06] Carlos: do we want to also consider Open Source related
projects, such as ODL, OPNFV? -->
</section>
<section anchor="sec:terminology" title="Terminology">
<!--
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in
<xref target='RFC2119'>RFC2119</xref>.
</t>
-->
<t>
The following terms used in this document are defined by the ETSI NVF ISG,
the ONF and the IETF:
<list style="empty">
<t>Application Plane - The collection of applications and services
that program network behavior.</t>
<t>Control Plane (CP) - The collection of functions responsible for
controlling one or more network devices. CP instructs network
devices with respect to how to process and forward packets. The
control plane interacts primarily with the forwarding plane and,
to a lesser extent, with the operational plane.</t>
<t>Forwarding Plane (FP) - The collection of resources across all
network devices responsible for forwarding traffic.</t>
<t>Management Plane (MP) - The collection of functions responsible
for monitoring, configuring, and maintaining one or more network
devices or parts of network devices. The management plane is
mostly related to the operational plane (it is related less to the
forwarding plane).</t>
<t>NFV Infrastructure (NFVI): totality of all hardware and software
components which build up the environment in which VNFs are
deployed</t>
<t>NFV Management and Orchestration (NFV-MANO): functions collectively
provided by NFVO, VNFM, and VIM.</t>
<t>NFV Orchestrator (NFVO): functional block that manages the Network
Service (NS) lifecycle and coordinates the management of NS lifecycle,
VNF lifecycle (supported by the VNFM) and NFVI resources (supported by
the VIM) to ensure an optimized allocation of the necessary resources
and connectivity.</t>
<t>OpenFlow protocol (OFP): allowing vendor independent programming of
control functions in network nodes.</t>
<t>Operational Plane (OP) - The collection of resources responsible
for managing the overall operation of individual network devices.</t>
<t>Service Function Chain (SFC): for a given service, the abstracted
view of the required service functions and the order in which they are
to be applied. This is somehow equivalent to the Network Function
Forwarding Graph (NF-FG) at ETSI.</t>
<t>Service Function Path (SFP): the selection of specific service
function instances on specific network nodes to form a service graph
through which an SFC is instantiated.</t>
<t>virtual EPC (vEPC): control plane of 3GPPs EPC operated on NFV
framework (as defined by <xref
target="I-D.matsushima-stateless-uplane-vepc" />).</t>
<t>Virtualized Infrastructure Manager (VIM): functional block that is
responsible for controlling and managing the NFVI compute, storage and
network resources, usually within one operator's Infrastructure
Domain.</t>
<t>Virtualized Network Function (VNF): implementation of a Network
Function that can be deployed on a Network Function Virtualisation
Infrastructure (NFVI).</t>
<t>Virtualized Network Function Manager (VNFM): functional block that
is responsible for the lifecycle management of VNF.</t>
</list>
</t>
</section>
<section anchor="sec:background" title="Background">
<section anchor="sec:nfv" title="Network Function Virtualization">
<t>
The ETSI ISG NFV is a working group which, since 2012, aims to evolve
quasi-standard IT virtualization technology to consolidate many network
equipment types into industry standard high volume servers, switches, and
storage. It enables implementing network functions in software that can run on a
range of industry standard server hardware and can be moved to, or loaded in,
various locations in the network as required, without the need to install new
equipment. To date, ETSI NFV is by far the most accepted NFV reference framework
and architectural footprint <xref target="etsi_nvf_whitepaper" />. The ETSI NFV
framework architecture framework is composed of three domains
(<xref target="fig:nfv_framework" />):
<list style="symbols" >
<t>
Virtualized Network Function, running over the NFVI.
</t>
<t>
NFV Infrastructure (NFVI), including the diversity of physical resources and how
these can be virtualized. NFVI supports the execution of the VNFs.
</t>
<t>
NFV Management and Orchestration, which covers the orchestration and life-cycle
management of physical and/or software resources that support the infrastructure
virtualization, and the life-cycle management of VNFs. NFV Management and
Orchestration focuses on all virtualization specific management tasks necessary
in the NFV framework.
</t>
</list>
</t>
<figure anchor="fig:nfv_framework" title="ETSI NFV framework" >
<artwork><![CDATA[
+-------------------------------------------+ +---------------+
| Virtualized Network Functions (VNFs) | | |
| ------- ------- ------- ------- | | |
| | | | | | | | | | | |
| | VNF | | VNF | | VNF | | VNF | | | |
| | | | | | | | | | | |
| ------- ------- ------- ------- | | |
+-------------------------------------------+ | |
| |
+-------------------------------------------+ | |
| NFV Infrastructure (NFVI) | | NFV |
| ----------- ----------- ----------- | | Management |
| | Virtual | | Virtual | | Virtual | | | and |
| | Compute | | Storage | | Network | | | Orchestration |
| ----------- ----------- ----------- | | |
| +---------------------------------------+ | | |
| | Virtualization Layer | | | |
| +---------------------------------------+ | | |
| +---------------------------------------+ | | |
| | ----------- ----------- ----------- | | | |
| | | Compute | | Storage | | Network | | | | |
| | ----------- ----------- ----------- | | | |
| | Hardware resources | | | |
| +---------------------------------------+ | | |
+-------------------------------------------+ +---------------+
]]></artwork>
</figure>
<t>
The NFV architectural framework identifies functional blocks and the main
reference points between such blocks. Some of these are already present in
current deployments, whilst others might be necessary additions in order to
support the virtualization process and consequent operation. The functional
blocks are (<xref target="fig:nfv_arch" />):
<list style="symbols" >
<t>
Virtualized Network Function (VNF).
</t>
<t>
Element Management (EM).
</t>
<t>
NFV Infrastructure, including: Hardware and virtualized resources, and
Virtualization Layer.
</t>
<t>
Virtualized Infrastructure Manager(s) (VIM).
</t>
<t>
NFV Orchestrator.
</t>
<t>
VNF Manager(s).
</t>
<t>
Service, VNF and Infrastructure Description.
</t>
<t>
Operations and Business Support Systems (OSS/BSS).
</t>
</list>
</t>
<figure anchor="fig:nfv_arch" title="ETSI NFV reference architecture" >
<artwork><![CDATA[
+--------------------+
+-------------------------------------------+ | ---------------- |
| OSS/BSS | | | NFV | |
+-------------------------------------------+ | | Orchestrator +-- |
| ---+------------ | |
+-------------------------------------------+ | | | |
| --------- --------- --------- | | | | |
| | EM 1 | | EM 2 | | EM 3 | | | | | |
| ----+---- ----+---- ----+---- | | ---+---------- | |
| | | | |--|-| VNF | | |
| ----+---- ----+---- ----+---- | | | manager(s) | | |
| | VNF 1 | | VNF 2 | | VNF 3 | | | ---+---------- | |
| ----+---- ----+---- ----+---- | | | | |
+------|-------------|-------------|--------+ | | | |
| | | | | | |
+------+-------------+-------------+--------+ | | | |
| NFV Infrastructure (NFVI) | | | | |
| ----------- ----------- ----------- | | | | |
| | Virtual | | Virtual | | Virtual | | | | | |
| | Compute | | Storage | | Network | | | | | |
| ----------- ----------- ----------- | | ---+------ | |
| +---------------------------------------+ | | | | | |
| | Virtualization Layer | |--|-| VIM(s) +-------- |
| +---------------------------------------+ | | | | |
| +---------------------------------------+ | | ---------- |
| | ----------- ----------- ----------- | | | |
| | | Compute | | Storage | | Network | | | | |
| | | hardware| | hardware| | hardware| | | | |
| | ----------- ----------- ----------- | | | |
| | Hardware resources | | | NFV Management |
| +---------------------------------------+ | | and Orchestration |
+-------------------------------------------+ +--------------------+
]]></artwork>
</figure>
</section>
<section anchor="sec:sdn" title="Software Defined Networking">
<t>
The Software Defined Networking (SDN) paradigm pushes the intelligence currently
residing in the network elements to a central controller implementing the
network functionality through software. In contrast to traditional approaches,
in which the network’s control plane is distributed throughout all network
devices, with SDN the control plane is logically centralized. In this way, the
deployment of new characteristics in the network no longer requires of complex
and costly changes in equipment or firmware updates, but only a change in the
software running in the controller. The main advantage of this approach is the
flexibility it provides operators with to manage their network, i.e., an
operator can easily change its policies on how traffic is distributed throughout
the network.
</t>
<t>
The most visible of the SDN protocol stacks is the OpenFlow protocol (OFP),
which is maintained and extended by the Open Network Foundation
(ONF: https://www.opennetworking.org/). Originally this protocol was developed
specifically for IEEE 802.1 switches conforming to the ONF OpenFlow Switch
specification. As the benefits of the SDN paradigm have reached a wider
audience, its application has been extended to more complex scenarios such as
Wireless and Mobile networks. Within this area of work, the ONF is actively
developing new OFP extensions addressing three key scenarios: (i) Wireless
backhaul, (ii) Cellular Evolved Packet Core (EPC), and (iii) Unified access and
management across enterprise wireless and fixed networks.
</t>
<figure anchor="fig:onf_arch" title="High level SDN ONF architecture" >
<artwork><![CDATA[
+----------+
| ------- |
| |Oper.| | O
| |Mgmt.| |<········> -+- Network Operator
| |Iface| | ^
| ------- | +----------------------------------------+
| | | +------------------------------------+ |
| | | | --------- --------- --------- | |
|--------- | | | | App 1 | | App 2 | ··· | App n | | |
||Plugins| |<····>| | --------- --------- --------- | |
|--------- | | | Plugins | |
| | | +------------------------------------+ |
| | | Application Plane |
| | +----------------------------------------+
| | A
| | |
| | V
| | +----------------------------------------+
| | | +------------------------------------+ |
|--------- | | | ------------ ------------ | |
|| Netw. | | | | | Module 1 | | Module 2 | | |
||Engine | |<····>| | ------------ ------------ | |
|--------- | | | Network Engine | |
| | | +------------------------------------+ |
| | | Controller Plane |
| | +----------------------------------------+
| | A
| | |
| | V
| | +----------------------------------------+
| | | +--------------+ +--------------+ |
| | | | ------------ | | ------------ | |
|----------| | | | OpenFlow | | | | OpenFlow | | |
||OpenFlow||<····>| | ------------ | | ------------ | |
|----------| | | NE | | NE | |
| | | +--------------+ +--------------+ |
| | | Data Plane |
|Management| +----------------------------------------+
+----------+
]]></artwork>
</figure>
<t>
<xref target="fig:onf_arch"/> shows the blocks and the functional interfaces of
the ONF architecture, which comprises three planes: Data, Controller, and
Application. The Data plane comprehends several Network Entities (NE), which
expose their capabilities toward the Controller plane via a Southbound API. The
Controller plane includes several cooperating modules devoted to the creation
and maintenance of an abstracted resource model of the underneath network. Such
model is exposed to the applications via a Northbound API where the Application
plane comprises several applications/services, each of which has exclusive
control of a set of exposed resources.
</t>
<t>
The Management plane spans its functionality across all planes performing the
initial configuration of the network elements in the Data plane, the assignment
of the SDN controller and the resources under its responsibility. In the
Controller plane, the Management needs to configure the policies defining the
scope of the control given to the SDN applications, to monitor the performance
of the system, and to configure the parameters required by the SDN controller
modules. In the Application plane, Management configures the parameters of the
applications and the service level agreements. In addition to the these
interactions, the Management plane exposes several functions to network
operators which can easily and quickly configure and tune the network at each
layer.
</t>
<t>
The SDNRG has documented a reference layer model in
<xref target='RFC7426'>RFC7426</xref>, which is reproduced in
<xref target="fig:sdn_layer_arch" />. This model structures SDN in planes and
layers which are glued together by different abstraction layers. This
architecture differentiates between the control and the management planes and
provides for differentiated southbound interfaces (SBIs).
</t>
<figure anchor="fig:sdn_layer_arch" title="SDN Layer Architecture" >
<artwork><![CDATA[
o--------------------------------o
| |
| +-------------+ +----------+ |
| | Application | | Service | |
| +-------------+ +----------+ |
| Application Plane |
o---------------Y----------------o
|
*-----------------------------Y---------------------------------*
| Network Services Abstraction Layer (NSAL) |
*------Y------------------------------------------------Y-------*
| |
| Service Interface |
| |
o------Y------------------o o---------------------Y------o
| | Control Plane | | Management Plane | |
| +----Y----+ +-----+ | | +-----+ +----Y----+ |
| | Service | | App | | | | App | | Service | |
| +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ |
| | | | | | | |
| *----Y-----------Y----* | | *---Y---------------Y----* |
| | Control Abstraction | | | | Management Abstraction | |
| | Layer (CAL) | | | | Layer (MAL) | |
| *----------Y----------* | | *----------Y-------------* |
| | | | | |
o------------|------------o o------------|---------------o
| |
| CP | MP
| Southbound | Southbound
| Interface | Interface
| |
*------------Y---------------------------------Y----------------*
| Device and resource Abstraction Layer (DAL) |
*------------Y---------------------------------Y----------------*
| | | |
| o-------Y----------o +-----+ o--------Y----------o |
| | Forwarding Plane | | App | | Operational Plane | |
| o------------------o +-----+ o-------------------o |
| Network Device |
+---------------------------------------------------------------+
]]></artwork>
</figure>
</section>
<section anchor="sec:mec" title="Mobile Edge Computing">
<t>
Mobile Edge Computing capabilities deployed in the edge of the mobile network
can facilitate the efficient and dynamic provision of services to mobile users.
The ETSI ISG MEC working group, operative from end of 2014, intends to specify
an open environment for integrating MEC capabilities with service providers
networks, including also applications from 3rd parties. These distributed
computing capabilities will make available IT infrastructure as in a cloud
environment for the deployment of functions in mobile access networks. It can be
seen then as a complement to both NFV and SDN.
</t>
</section>
<section anchor="sec:omniran" title="IEEE 802.1CF (OmniRAN)">
<t>
The IEEE 802.1CF Recommended Practice specifies an access network, which
connects terminals to their access routers, utilizing technologies based on the
family of IEEE 802 Standards (e.g., 802.3 Ethernet, 802.11 Wi-Fi, etc.). The
specification defines an access network reference model, including entities and
reference points along with behavioral and functional descriptions of
communications among those entities.
</t>
<t>
The goal of this project is to help unifying the support of different
interfaces, enabling shared network control and use of software defined network
(SDN) principles, thereby lowering the barriers to new network technologies, to
new network operators, and to new service providers.
</t>
</section>
<section anchor="sec:dmtf" title="Distributed Management Task Force">
<t>
The DMTF is an industry standards organization working to simplify the
manageability of network-accessible technologies through open and collaborative
efforts by some technology companies. The DMTF is involved in the creation and
adoption of interoperable management standards, supporting implementations that
enable the management of diverse traditional and emerging technologies including
cloud, virtualization, network and infrastructure.
</t>
<t>
There are several DMTF initiatives that are relevant to the network
virtualization area, such as the Open Virtualization Format (OVF), for VNF
packaging; the Cloud Infrastructure Management Interface (CIM), for cloud
infrastructure management; the Network Management (NETMAN), for VNF management;
and, the Virtualization Management (VMAN), for virtualization infrastructure
management.
</t>
</section>
<section anchor="sec:open_source" title="Open Source initiatives">
<t>
The Open Source community is especially active in the area of network
virtualization. We next summarize some of the active efforts:
<list style="symbols">
<t>
OpenStack. OpenStack is a free and open-source cloud-computing software
platform. OpenStack software controls large pools of compute, storage, and
networking resources throughout a datacenter, managed through a dashboard or via
the OpenStack API.
</t>
<t>
OpenDayLight. OpenDaylight (ODL) is a highly available, modular, extensible,
scalable and multi-protocol controller infrastructure built for SDN deployments
on modern heterogeneous multi-vendor networks. It provides a model-driven
service abstraction platform that allows users to write apps that easily work
across a wide variety of hardware and southbound protocols.
</t>
<t>
ONOS. The ONOS (Open Network Operating System) project is an open source
community hosted by The Linux Foundation. The goal of the project is to create a
software-defined networking (SDN) operating system for communications service
providers that is designed for scalability, high performance and high
availability.
</t>
<t>
OpenContrail. OpenContrail is an Apache 2.0-licensed project that is built
using standards-based protocols and provides all the necessary components for
network virtualization–SDN controller, virtual router, analytics engine, and
published northbound APIs. It has an extensive REST API to configure and gather
operational and analytics data from the system.
</t>
<t>
OPNFV. OPNFV is a carrier-grade, integrated, open source platform to accelerate
the introduction of new NFV products and services. By integrating components
from upstream projects, the OPNFV community aims at conducting performance and
use case-based testing to ensure the platform’s suitability for NFV use cases.
The scope of OPNFV’s initial release is focused on building NFV Infrastructure
(NFVI) and Virtualized Infrastructure Management (VIM) by integrating components
from upstream projects such as OpenDaylight, OpenStack, Ceph Storage, KVM, Open
vSwitch, and Linux. These components, along with application programmable
interfaces (APIs) to other NFV elements form the basic infrastructure required
for Virtualized Network Functions (VNF) and Management and Network Orchestration
(MANO) components. OPNFV’s goal is to increase performance and power efficiency;
improve reliability, availability, and serviceability; and deliver comprehensive
platform instrumentation.
</t>
<t>
OSM. Open Source Mano (OSM) is an ETSI-hosted project to develop an Open Source
NFV Management and Orchestration (MANO) software stack aligned with ETSI NFV.
OSM is based on components from previous projects, such Telefonica's OpenMANO
or Canonical’s Juju, among others.
</t>
<t>
OpenBaton. OpenBaton is a ETSI NFV compliant Network Function Virtualization
Orchestrator (NFVO). OpenBaton was part of the OpenSDNCore project started with
the objective of providing a compliant implementation of the ETSI NFV
specification.
</t>
</list>
</t>
<t>
Among the main areas that are being developed by the former open source
activities that related to network virtualization research, we can highlight:
policy-based resource management, analytics for visibility and orchestration,
service verification with regards to security and resiliency.
</t>
</section>
</section>
<section anchor="sec:virtualization_at_IETF" title="Network Virtualization
at IETF/IRTF">
<section anchor="sec:sdnrg" title="SDN RG">
<t>
The SDNRG provides the grounds for an open-minded investigation of Software
Defined Networking. They aim at identifying approaches that can be defined
and used in the near term as well as the research challenges in the field.
As such, they SDNRG will not define standards, but provide inputs to
standards defining and standards producing organizations.
</t>
<t>
It is working on classifying SDN models, including definitions and
taxonomies. It is also studying complexity, scalability and applicability of
the SDN model. Additionally, the SDNRG is working on network description
languages (and associated tools), abstractions and interfaces. They also
investigate the verification of correct operation of network or node
function.
</t>
<t>
The SDNRG has produced a reference layer model <xref target='RFC7426'>RFC7426</xref>,
which structures SDNs in planes and layers which are glued together by different
abstraction layers. This architecture differentiates between the control and the
management planes and provides for differentiated southbound interfaces (SBIs).
</t>
</section>
<section anchor="sec:sfc" title="SFC WG">
<t>
Current network services deployed by operators often involve the composition
of several individual functions (such as packet filtering, deep packet
inspection, load balancing). These services are typically implemented by the
ordered combination of a number of service functions that are deployed at
different points within a network, not necessary on the direct data path. This
requires traffic to be steered through the required service functions, wherever
they are deployed.
</t>
<t>
For a given service, the abstracted view of the required service functions and
the order in which they are to be applied is called a Service Function Chain
(SFC), which is called Network Function Forwarding Graph (NF-FG) in ETSI. An SFC
is instantiated through selection of specific service function instances on
specific network nodes to form a service graph: this is called a Service
Function Path (SFP). The service functions may be applied at any layer within
the network protocol stack (network layer, transport layer, application layer,
etc.).
</t>
<t>
The SFC working group is working on an architecture for service function
chaining that includes the necessary protocols or protocol extensions to convey
the Service Function Chain and Service Function Path information to nodes that
are involved in the implementation of service functions and Service Function
Chains, as well as mechanisms for steering traffic through service functions.
</t>
<t>
In terms of actual work items, the SFC WG is chartered to deliver: (i) a problem
statement document <xref target="RFC7498" />, (ii) an architecture document
<xref target="RFC7665" />, (iii) a service-level data plane
encapsulation format (the encapsulation should indicate the sequence of service
functions that make up the Service Function Chain, specify the Service Function
Path, and communicate context information between nodes that implement service
functions and Service Function Chains), and (iv) a document describing
requirements for conveying information between control or management elements
and SFC implementation points.
</t>
<t>
Potential gap: as stated in the SFC charter, any work on the management and
configuration of SFC components related to the support of Service Function
Chaining will not be done yet, until better understood and scoped. This part is
of special interest for operators and would be required in order to actually put
SFC mechanisms into operation.
</t>
<t>
Potential gap: redundancy and reliability mechanisms are currently not dealt
with by any WG in the IETF. While this has been the main goal of the VNFpool BoF
efforts, it still remains un-addressed.
</t>
</section>
<section anchor="sec:nvo3" title="NVO3 WG">
<t>
The Network Virtualization Overlays (NVO3) WG is developing protocols that
enable network virtualization overlays within large Data Center (DC)
environments. Specifically NVO3 assumes an underlying physical Layer 3 (IP)
fabric on which multiple tenant networks are virtualized on top (i.e. overlays).
With overlays, data traffic between tenants is tunneled across the underlying
DC’s IP network. The use of tunnels provides a number of benefits by decoupling
the network as viewed by tenants from the underlying physical network across
which they communicate <xref target="I-D.ietf-nvo3-arch" />.
</t>
<t>
Potential gap: It would be worthwhile to see if some of the specific approaches
developed in this WG (e.g. overlays, traffic isolation, VM migration) can be
applied outside the DC, and specifically if they can be applicable to network
virtualization (NFV). These approaches would be most relevant to the ETSI
Network Function Virtualization Infrastructure (NFVI), and the Virtualized
Infrastructure Manager part of the MANO.
</t>
</section>
<section anchor="sec:dmm" title="DMM WG">
<t>
The Distributed Mobility Management (DMM) WG is looking at solutions for IP
networks that enable traffic between mobile and correspondent nodes taking an
optimal route, preventing some of the issues caused by the use of centralized
mobility solutions, which anchor all the traffic at a given node (or a very
limited set of nodes). The DMM WG is considering the latest developments in
mobile networking research and operational practices (i.e., flattening network
architectures, the impact of virtualization, new deployment needs as wireless
access technologies evolve in the coming years) and aims at describing how
distributed mobility management addresses the new needs in this area better than
previously standardized solutions.
</t>
<t>
Although network virtualization is not the main area of the DMM work, the impact
of SDN and NFV mechanisms is clear on the work that is currently being done in
the WG. One example is architecture defined for the virtual Evolved Packet Core
(vEPC) in <xref target="I-D.matsushima-stateless-uplane-vepc" />. Here, the
authors describe a particular realization of the vEPC concept, which is designed
to support NFV. In the defined architecture, the user plane of EPC is decoupled
from the control-plane and uses routing information to forward packets of mobile
nodes. This proposal does not modify the signaling of the EPC control plane,
although the EPC control plane runs on an hypervisor.
</t>
<t>
Potential gap: in a vEPC/DMM context, how to run the EPC control plane on NFV.
</t>
<t>
The DMM WG is also looking at ways to supporting the separation of the
Control-Plane for mobility- and session management from the actual Data-Plane
<xref target="I-D.ietf-dmm-fpc-cpdp" />. The protocol semantics being defined
abstract from the actual details for the configuration of Data-Plane nodes and
apply between a Client function, which is used by an application of the mobility
Control-Plane, and an Agent function, which is associated with the configuration
of Data-Plane nodes according to the policies issued by the mobility
Control-Plane.
<!--The actual mappings between these generic protocol semantics and
the configuration commands required on the data plane network elements are not
in the scope of this document, and are therefore a potential gap that will need
to be addressed (e.g., for OpenFlow switches).-->
</t>
<t>
Potential gap: the actual mappings between these generic protocol semantics and
the configuration commands required on the data plane network elements are not
in the scope of this document, and are therefore a potential gap that will need
to be addressed (e.g., for OpenFlow switches).
</t>
</section>
<section anchor="sec:i2rs" title="I2RS WG">
<t>
The Interface to the Routing System (I2RS) WG is developing a high-level
architecture that describes the basic building-blocks to access the routing
system through a set of protocol-based control or management interfaces.
This architecture, as described in <xref target='I-D.ietf-i2rs-architecture' />,
comprises an I2RS Agent as a unified interface that is accessed by I2RS clients
using the I2RS protocol. The client is controlled by one or more network
applications and accesses one or more agents, as shown in the following figure:
</t>
<figure anchor="fig:i2rs_arch" title="High level I2RS architecture" >
<artwork><![CDATA[
****************** ***************** *****************
* Application C * * Application D * * Application E *
****************** ***************** *****************
| | |
+--------------+ | +-------------+
| | |
***************
* Client P *----------------------+
*************** |
*********************** | |
* Application A * | |
* * | *********************** |
* +----------------+ * | * Application B * |
* | Client A | * | * * |
* +----------------+ * | * +----------------+ * |
*********************** | * | Client B | * |
| | * +----------------+ * |
| +----------------+ *********************** |
| | | | |
| | +------------------------+ | +-----+
| | | | |
******************************* *******************************
* * * *
* Routing Element 1 * * Routing Element 2 *
* * * *
******************************* *******************************
]]></artwork>
</figure>
<t>
Routing elements consist of an agent that communicates with the client
or clients driven by the applications and accesses the different subsystems in
the element as shown in the following figure:
</t>
<figure anchor="fig:i2rs" title="Architecture of a routing element" >
<artwork><![CDATA[
|
*****************v**************
* +---------------------+ *
* | Agent | *
* +---------------------+ *
* ^ ^ ^ ^ *
* | | | | *
* | | | +--+ *
* | | | | *
* v | | v *
* +---+-----+ | | +----+---+ *
* | Routing | | | | Local | *
* | and | | | | Config | *
* |Signaling| | | +--------+ *
* +---------+ | | ^ *
* ^ | | | *
* | +----+ | | *
* v v v v *
* +----------+ +------------+ *
* | Dynamic | | Static | *
* | System | | System | *
* | State | | State | *
* +----------+ +------------+ *
* *
* Routing Element *
********************************
]]></artwork>
</figure>
<t>
The I2RS architecture proposes to use model-driven APIs. Services can
correspond to different data-models and agents can indicate which model
they support.
</t>
<t>
Potential gap: network virtualization is not the main aim of the I2RS WG.
However, they provide an infrastructure that can be part of an SDN deployment.
</t>
</section>
<section anchor="sec:bess" title="BESS WG">
<t>
BGP is already used as a protocol for provisioning and operating Layer-3
(routed) Virtual Private Networks (L3VPNs). The BGP Enabled Services (BESS)
working group is responsible for defining, specifying, and extending network
services based on BGP. In particular, the working group will work on the
following services:
<list style="symbols">
<t>
BGP-enabled VPN solutions for use in the data center networking. This work
includes consideration of VPN scaling issues and mechanisms applicable to such
environments.
</t>
<t>
Extensions to BGP-enabled VPN solutions for the construction of virtual
topologies in support of services such as Service Function Chaining.
</t>
</list>
</t>
<t>
Potential gap: The most relevant activity in BESS that would be worthwhile to
investigate for relevance to network virtualization (NFV) is the extensions to
BGP-enabled VPN solutions to support of Service Function Chaining
<xref target="I-D.rfernando-bess-service-chaining" />.
</t>
</section>
<section anchor="sec:bm" title="BM WG">
<t>
The Benchmarking Methodology Working Group (BMWG) provides recommendations
concerning the key performance characteristics of internetworking technologies,
or benchmarks for network devices, systems, and services. The scope of BMWG
includes benchmarks for the management, control, and forwarding planes, and is.
</t>
<t>
The main distinguishing characteristic of BMWG from other IETF measurement
initiatives like the IPPM WG is that BMWG is limited to characterization of
implementations using controlled stimuli in a lab environment. The BMWG does not
attempt to produce benchmarks for live, operational networks.
</t>
<t>
As part of the tasks of the BMWG, it is explicitly tasked to develop benchmarks
and methodologies for VNF and related infrastructure benchmarking, Benchmarking
Methodologies have reliably characterized many physical devices. This work item
extends and enhances the methods to virtual network functions (VNF) and their
unique supporting infrastructure. The first deliverable from this activity
mentioned in the charter of the WG is a document
<xref target="I-D.ietf-bmwg-virtual-net" /> that considers the new benchmarking
space to ensure that common issues are recognized from the start, using
background materials from industry and SDOs (e.g., IETF, ETSI NFV). This
document investigates the additional methodological considerations necessary
when benchmarking VNFs instantiated and hosted in general-purpose hardware. The
approach is to benchmark physical and virtual network functions in the same way
when possible, thereby allowing direct comparison. Also defining benchmarking
combinations of physical and virtual devices in a System Under Test.
</t>
<t>
Benchmarks for platform capacity and performance characteristics of virtual
routers, switches, and related components will be also addressed, including
comparisons between physical and virtual network functions. In many cases, the
traditional benchmarks should be applicable to VNFs, but the lab set-ups,
configurations, and measurement methods will likely need to be revised or
enhanced.
</t>
<t>
There are additional documents of the BMWG relevant to the virtualization area,
such as: <xref target="I-D.ietf-bmwg-sdn-controller-benchmark-term" />,
<xref target="I-D.ietf-bmwg-sdn-controller-benchmark-meth" />,
<xref target="I-D.kim-bmwg-ha-nfvi" /> and
<xref target="I-D.vsperf-bmwg-vswitch-opnfv" />.
</t>
<!--
<t>
Potential gap:
</t>
-->
</section>
<section anchor="sec:teas" title="TEAS WG">
<t>
Transport network infrastructure provides end-to-end connectivity for networked
applications and services. Network virtualization facilitates effective sharing
(or ’slicing’) of physical infrastructure by representing resources and
topologies via abstractions, even in a multi-administration, multi-vendor,
multi-technology environment. In this way, it becomes possible to operate,
control and manage multiple physical networks elements as single virtualized
network. The users of such virtualized network can control the allocated
resources in an optimal and flexible way, better adapting to the specific
circumstances of higher layer applications.
</t>
<t>
Abstraction and Control of Transport Networks (ACTN) intends to define methods
and capabilities for the deployment and operation of transport network resources
<xref target="I-D.ceccarelli-teas-actn-framework" />. This activity is currently
being carried out within the Traffic Engineering Architecture and Signaling
(TEAS) WG.
</t>
<t>
Several use cases are being proposed for both fixed and mobile scenarios <xref
target="I-D.leeking-teas-actn-problem-statement" />.
</t>
<t>
Potential gap: Several use cases in ACTN are relevant to network virtualization
(NFV) in mobile environments. Control of multi-tenant mobile backhaul transport
networks, mobile virtual network operation, etc, can be influenced by the
location of the network functions. A control architecture allowing for
inter-operation of NFV and transport network (e.g., for combined optimization)
is one relevant area for research.
</t>
</section>
<section anchor="sec:i2nsf" title="I2NSF WG">
<t>
The I2NSF WG at defining interfaces to the flow based network security functions
(NSFs) hosted by service providers at different premises. Network Security
Function (NSF) is to ensure integrity, confidentiality and availability of
network communications, to detect unwanted activity, and to block it or at
least mitigate its effects. NSFs are provided and consumed in increasingly
diverse environments. Users of NSFs could consume network security services
hosted by one or more providers, which may be their own enterprise, service
providers, or a combination of both. The NSFs may be provided by
physical and/or virtualized infrastructure.
</t>
<t>
Without standard interfaces to express, monitor, and control security policies
that govern the behavior of NSFs, it becomes virtually impossible for security
service providers to automate their service offerings that utilize different
security functions from multiple vendors. Based on this, the main goal of I2NSF
is to define an information model, a set of software interfaces and data models
for controlling and monitoring aspects of NSFs (both physical and virtual)
<xref target="I-D.jeong-i2nsf-sdn-security-services" />.
</t>
<t>
Since different security vendors may support different features and functions on
their devices, I2NSF focuses on flow based NSFs that provide treatment to
packets/flow.
</t>
<t>
The I2NSF WG’s target deliverables include: (i) a use cases, problem statement,
gap analysis document, (ii) a framework document, presenting an overview of
the use of NSFs and the purpose of the models developed by the WG, (iii) a
single, unified, Information Model for controlling and monitoring flow-based
NSFs, (iv) the corresponding YANG Data Models derived from the Information
Model, (v) a vendor-neutral vocabulary to enable the characteristics and
behavior of NSFs to be specified without requiring the NSFs themselves to be
standardized, and (vi) an examination of existing secure communication
mechanisms to identify the appropriate ones for carrying the controlling and
monitoring information between the NSFs and their management entities.
The WG is also targeted to work closely with I2RS, Netconf and Netmod WGs, as
well as to communicate with external SDOs like ETSI NFV.
</t>
<t>
Potential gap: aspects of NSFs such as device or network provisioning and
configuration are out of scope.
</t>
<t>
Potential gap: the use of SDN tools to interact with security functions is not
explictly considered, but seems a potential approach, as for example described
for the particular case of IPsec flow protection in
<xref target="I-D.abad-sdnrg-sdn-ipsec-flow-protection" />.
</t>
</section>
<section anchor="sec:ippm" title="IPPM WG">
<t>
The IP Performance Metrics (IPPM) WG defines metrics that can be used to measure
the quality and performance of Internet services and applications running over
transport layer protocols (e.g. TCP, UPD) over IP. It also develops and
maintains protocols for the measurement of these metrics. The IPPM WG is a long
running WG that started in 1997. The architecture (framework) for IPPM WG
metrics and associated protocols are defined in RFC 2330 <xref target="RFC2330"
/>. Some examples of recent output by IPPM WG include “A Reference Path and
Measurement Points for Large-Scale Measurement of Broadband Performance” (RFC
7398 <xref target="RFC7398" />) and “Framework for TCP Throughput Testing” (RFC
6349 <xref target="RFC6349" />).
</t>
<t>
The IPPM WG currently does not have a charter item or active drafts related to
the topic of network virtualization. On the automation and orchestration side,
there is an ongoing effort <xref target="I-D.cmzrjp-ippm-twamp-yang" /> to
define a YANG model for the IPPM protocol.
</t>
<t>
Potential gap: There is a pressing need to define metrics and associated
protocols to measure the performance of NFV. Specifically, since NFV is based on
the concept of taking centralized functions and evolving it to highly
distributed SW functions, there is a commensurate need to fully understand and
measure the baseline performance of such systems. A potential topic for the IPPM
WG is defining packet delay, throughput, and test framework for the application
traffic flowing through the NFVI.
</t>
</section>
<section anchor="sec:nvfrg" title="NFV RG">
<t>
The NFVRG focuses on research problems associated with virtualization of fixed
and mobile network infrastructures, new network architectures based on
virtualized network functions, virtualization of the home and enterprise network
environments, co-existence with non-virtualized infrastructure and services, and
application to growing areas of concern such as Internet of Things (IoT) and
next generation content distribution. Another goal of the NFVRG is to bring a
research community together that can jointly address such problems,
concentrating on problems that relate not just to networking but also to
computing and storage constraints in such environments.
</t>
<t>
Since the NFVRG is a research group, it has a wide scope. In order to keep the
focus, the group has identified some near term work items: (i) Policy based
Resource Management, (ii) Analytics for Visibility and Orchestration, (iii)
Virtual Network Function (VNF) Performance Modelling to facilitate transition to
NFV and (iv) Security and Service Verification.
</t>
</section>
<section anchor="sec:vnfpool" title="VNFpool BoF">
<t>
The VNFPOOL BoF proposed to work on the way to group Virtual Network
Function (VNF) into pools to improve resilience, provide better
scale-out and scale-in characteristics, implement stateful failover
among VNF members of a pool, etc. Additionally, they propose to
create VNF sets from VNF pools. For this, the BoF proposed to study
signaling (both between members of a pool and across pools),
state sharing mechanisms between members of a VNFPOOL, the exchange
of reliability information between VNF sets, their users and the
underlying network, and the reliability and security of the control
plane needed to transport the exchanged information.
</t>
<t>
The use cases initially considered by VNFPOOL include Content
Deliver Networks (CDNs), the LTE mobile core network and
reliable server pooling. The VNFPOOL work has been dropped in the
IETF.
</t>
<t>
Potential gap: VNFPOOL tried to introduce and manage resilience in virtualized
networking environments and therefore addresses a desirable feature for any
software defined network. VNFPOOL has also been integrated into the NFV
architecture <xref target='I-D.bernini-nfvrg-vnf-orchestration' />.
</t>
<!-- TODO: add reference to this
Reference <xref target="I-D.king-vnfpool-mobile-use-case" />
-->
</section>
</section>
<section anchor="Summary-of-Gaps" title="Summary of Gaps">
<t>
Potential Gap-1: as stated in the SFC charter, any work on the management and
configuration of SFC components related to the support of Service Function
Chaining will not be done yet, until better understood and scoped. This part is
of special interest for operators and would be required in order to actually put
SFC mechanisms into operation.
</t>
<t>
Potential Gap-2: redundancy and reliability mechanisms are currently not dealt
with by SFC or any other WG in the IETF. While this has been the main goal of
the VNFpool BoF efforts, since VNFPOOL work has been dropped for the time being
without any WG being chartered, the technical topics it aimed at targetting
still remain un-addressed.
</t>
<t>
Potential Gap-3: it would be worthwhile to see if some of the specific approaches
developed in the NVO3 WG (e.g. overlays, traffic isolation, VM migration) can be
applied outside the DC, and specifically if they can be applicable to network
virtualization (NFV). These approaches would be most relevant to the ETSI
Network Function Virtualization Infrastructure (NFVI), and the Virtualized
Infrastructure Manager part of the MANO.
</t>
<t>
Potential Gap-4: the most relevant activity in BESS that would be worthwhile to
investigate for relevance to network virtualization (NFV) is the extensions to
BGP-enabled VPN solutions to support of Service Function Chaining.
</t>
<t>
Potential Gap-5: in a vEPC/DMM context, how to run the EPC control plane on NFV.
</t>
<t>
Potential Gap-6: in DMM, on the work item addressing the separation of the
Control-Plane for mobility- and session management from the actual Data-Plane,
the actual mappings between these generic protocol semantics and the
configuration commands required on the data plane network elements (e.g.,
OpenFlow switches) are not currently in the scope of the DMM WG.
</t>
<t>
Potential Gap-7: network virtualization is not the main aim of the I2RS WG.
However, they provide an infrastructure that can be part of an SDN deployment.
</t>
<t>
Potential Gap-8: VNFPOOL tries to introduce and manage resilience in virtualized
networking environments and therefore addresses a desirable feature for any
software defined network. VNFPOOL has also been integrated into the NFV
architecture <xref target='I-D.bernini-nfvrg-vnf-orchestration' />.
</t>
<t>
Potential Gap-9: within the Traffic Engineering Architecture and Signaling
(TEAS) WG, several use cases in ACTN are relevant to network virtualization
(NFV) in mobile environments. Control of multi-tenant mobile backhaul transport
networks, mobile virtual network operation, etc, can be influenced by the
location of the network functions. A control architecture allowing for
inter-operation of NFV and transport network (e.g., for combined optimization)
is one relevant area for research.
</t>
<t>
Potential Gap-10: within I2NSF', aspects of NSFs such as device or network
provisioning and configuration are out of scope.
</t>
<t>
Potential Gap-11: the use of SDN tools to interact with security functions is
not explictly considered in I2NSF, but seems a potential approach, as for
example described for the particular case of IPsec flow protection in
<xref target="I-D.abad-sdnrg-sdn-ipsec-flow-protection" />.
</t>
<t>
Potential Gap-12: there is a pressing need to define metrics and associated
protocols to measure the performance of NFV. Specifically, since NFV is based on
the concept of taking centralized functions and evolving it to highly
distributed SW functions, there is a commensurate need to fully understand and
measure the baseline performance of such systems. A potential topic for the IPPM
WG is defining packet delay, throughput, and test framework for the application
traffic flowing through the NFVI.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
N/A.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
TBD.
</t>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>
The authors want to thank Dirk von Hugo, Rafa Marin, Diego Lopez, Ramki
Krishnan, Kostas Pentikousis, Rana Pratap Sircar and Alfred Morton for their
very useful reviews and comments to the document.
</t>
<t>
The work of Pedro Aranda is supported by the European FP7 Project Trilogy2 under
grant agreement 317756.
</t>
</section>
</middle>
<back>
<!--
<references title="Normative References">
&rfc2119;
</references>
-->
<references title="Informative References">
<!---->
<!--&I-D.king-vnfpool-mobile-use-case;-->
&I-D.matsushima-stateless-uplane-vepc;
&rfc7426;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-nvo3-arch;
&I-D.rfernando-bess-service-chaining;
&rfc7665;
&rfc7498;
&I-D.ietf-dmm-fpc-cpdp;
&I-D.bernini-nfvrg-vnf-orchestration;
&I-D.ceccarelli-teas-actn-framework;
&I-D.leeking-teas-actn-problem-statement;
&I-D.abad-sdnrg-sdn-ipsec-flow-protection;
&I-D.jeong-i2nsf-sdn-security-services;
&rfc2330;
&rfc7398;
&rfc6349;
&I-D.cmzrjp-ippm-twamp-yang;
&I-D.ietf-bmwg-virtual-net;
&I-D.ietf-bmwg-sdn-controller-benchmark-term;
&I-D.ietf-bmwg-sdn-controller-benchmark-meth;
&I-D.kim-bmwg-ha-nfvi;
&I-D.vsperf-bmwg-vswitch-opnfv;
<reference anchor="etsi_nvf_whitepaper">
<front>
<title>Network Functions Virtualisation (NFV). White Paper 2</title>
<author fullname="ETSI NFV ISG"/>
<date year="2014" month="October"/>
</front>
</reference>
</references>
<section anchor="sec:appx1" title="The mobile network use case">
<section anchor="sec:eps" title="The 3GPP Evolved Packet System">
<t>
TBD. This will include a high level summary of the 3GPP EPS architecture,
detailing both the EPC (core) and the RAN (access) parts. A link with the two
related ETSI NFV use cases (Virtualisation of Mobile Core Network and IMS, and
Virtualisation of Mobile base station) will be included.
</t>
<t>
The EPS architecture and some of its standardized interfaces are depicted in
<xref target="fig:eps_arch" />. The EPS provides IP connectivity to user
equipment (UE) (i.e., mobile nodes) and access to operator services, such as
global Internet access and voice communications. The EPS comprises the core
network -- called Evolved Packet Core (EPC) -- and different radio access
networks: the 3GPP Access Network (AN), the Untrusted non-3GPP AN and the
Trusted non-3GPP AN. There are different types of 3GPP ANs, with the evolved
UMTS Terrestrial Radio Access Network (E-UTRAN) as the most advanced
one. QoS is supported through an EPS bearer concept, providing bindings to
resource reservation within the network.
</t>
<t>
The evolved NodeB (eNB), the Long Term Evolution (LTE) base station, is part of
the access network that provides radio resource management, header compression,
security and connectivity to the core network through the S1 interface. In an
LTE network, the control plane signaling traffic and the data traffic ar
handled separately. The eNBs transmit the control traffic and data traffic
separately via two logically separate interfaces.
</t>
<t>
The Home Subscriber Server, HSS, is a database that contains user subscriptions
and QoS profiles. The Mobility Management Entity, MME, is responsible for
mobility management, user authentication, bearer establishment and modification
and maintenance of the UE context.
</t>
<t>
The Serving gateway, S-GW, is the mobility anchor and manages the user plane
data tunnels during the inter-eNB handovers. It tunnels all user data packets
and buffers downlink IP packets destined for UEs that happen to be in idle mode.
</t>
<t>
The Packet Data Network (PDN) Gateway, P-GW, is responsible for IP address
allocation to the UE and is a tunnel endpoint for user and control plane
protocols. It is also responsible for charging, packet filtering, and
policy-based control of flows. It interconnects the mobile network to external
IP networks, e.g. the Internet.
</t>
<t>
In this architecture, data packets are not sent directly on an IP network
between the eNB and the gateways. Instead, every packet is tunneled over a
tunneling protocol - the GPRS Tunneling Protocol (GTP over UDP/IP. A GTP path
is identified in each node with the IP address and a UDP port number on the
eNB/gateways. The GTP protocol carries both the data traffic (GTP-U tunnels) and
the control traffic (GTP-C tunnels). Alternatively Proxy Mobile IP (PMIPv6) is
used on the S5 interface between S-GW and P-GW.
</t>
<t>
In addition to the above basic functions and entities, there are also additional
features being discussed by the 3GPP that are relevant from a network
virtualization viewpoint. One example is the Traffic Detection Function (TDF),
which can be used by the P-GW, and in general by the whole transport network, to
decide how to forward the traffic. In a virtualized infrastructure, this kinf of
information can be used to elastic and dynamically adapt the network
capabilities to the traffic nature and volume.
</t>
<figure anchor="fig:eps_arch" title="EPS (non-roaming) architecture
overview" >
<artwork><![CDATA[
+---------------------------------------------------------+
| PCRF |
+-----------+--------------------------+----------------+-+
| | |
+----+ +-----------+------------+ +--------+-----------+ +-+-+
| | | +-+ | | Core Network | | |
| | | +------+ |S|__ | | +--------+ +---+ | | |
| | | |GERAN/|_|G| \ | | | HSS | | | | | |
| +-----+ UTRAN| |S| \ | | +---+----+ | | | | E |
| | | +------+ |N| +-+-+ | | | | | | | x |
| | | +-+ /|MME| | | +---+----+ | | | | t |
| | | +---------+ / +---+ | | | 3GPP | | | | | e |
| +-----+ E-UTRAN |/ | | | AAA | | | | | r |
| | | +---------+\ | | | SERVER | | | | | n |
| | | \ +---+ | | +--------+ | | | | a |
| | | 3GPP AN \|SGW+----- S5---------------+ P | | | l |
| | | +---+ | | | G | | | |
| | +------------------------+ | | W | | | I |
| UE | | | | | | P |
| | +------------------------+ | | +-----+ |
| | |+-------------+ +------+| | | | | | n |
| | || Untrusted +-+ ePDG +-S2b---------------+ | | | e |
| +---+| non-3GPP AN | +------+| | | | | | t |
| | |+-------------+ | | | | | | w |
| | +------------------------+ | | | | | o |
| | | | | | | r |
| | +------------------------+ | | | | | k |
| +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s |
| | +------------------------+ | | | | | |
| | | +-+-+ | | |
| +--------------------------S2c--------------------| | | |
| | | | | |
+----+ +--------------------+ +---+
]]></artwork>
</figure>
</section>
<section anchor="sec:veps" title="Virtualizing the 3GPP EPS">
<t>
TBD. We describe how a "virtual EPS" (vEPS) would look like and the existing
gaps that exist from the point of view of network virtualization.
</t>
<!--
<t>
We can coin here a new term: vEPS, to not only limit to the vEPC, but also
include the RAN, which is very relevant as well (e.g., Xhaul).
TBD: Present a high level view of how a virtualized EPS would look like,
identifying already the functionality required (e.g., resiliency, elasticity,
etc.), to then link that with the work being done at IETF.
</t>
-->
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:43:14 |