NFV RG CJ. Bernardos
Internet-Draft UC3M
Intended status: Informational LM. Contreras
Expires: September 22, 2016 TID
March 21, 2016
Multi-domain Network Virtualization
draft-bernardos-nfvrg-multidomain-00
Abstract
This draft introduces the challenge of Multi-domain Network
Virtualization. The mutiple domains considered here correspond to
multiple administrative domains operating distinct infrastructures.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bernardos & Contreras Expires September 22, 2016 [Page 1]
Internet-Draft Multi-domain Network Virtualization March 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background: the ETSI NFV architecture . . . . . . . . . . . . 4
4. Multidomain problem statement . . . . . . . . . . . . . . . . 6
5. Multi-domain architectural approaches . . . . . . . . . . . . 7
5.1. Hierarchical . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Cascading . . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. Informative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
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.
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-
Bernardos & Contreras Expires September 22, 2016 [Page 2]
Internet-Draft Multi-domain Network Virtualization March 2016
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.
Network Function Virtualization (NFV) and Software Defined Networking
(SDN) are changing the way the telecommunications sector will deploy,
extend and operate their networks.
A challenge not yet sufficiently addressed is the multi-domain case,
where the infrastructure (considered as network, computing and
storage resources), or even some of the necessary network functions,
are provided by different providers each of them constituting a
separate administrative domain.
Innovative solutions have to be defined for multi-domain services
provisioned in an automated and on-demand manner in order to
accommodate future services. Such solutions not only should permit
programmability, flexibility and automation, but also should allow
for agile contracting, invoking and settling of services reducing
significantly the time for provision (moving from the current figure
of 90 days to 90 minutes as a goal) [Project_5GEx_Whitepaper].
2. Terminology
The following terms used in this document are defined by the ETSI NVF
ISG, and the ONF and the IETF:
NFV Infrastructure (NFVI): totality of all hardware and software
components which build up the environment in which VNFs are
deployed
NFV Management and Orchestration (NFV-MANO): functions
collectively provided by NFVO, VNFM, and VIM.
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.
OpenFlow protocol (OFP): allowing vendor independent programming
of control functions in network nodes.
Bernardos & Contreras Expires September 22, 2016 [Page 3]
Internet-Draft Multi-domain Network Virtualization March 2016
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.
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.
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.
Virtualized Network Function (VNF): implementation of a Network
Function that can be deployed on a Network Function Virtualisation
Infrastructure (NFVI).
Virtualized Network Function Manager (VNFM): functional block that
is responsible for the lifecycle management of VNF.
3. Background: the ETSI NFV architecture
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 [etsi_nvf_whitepaper]. The ETSI NFV
framework architecture framework is composed of three domains
(Figure 1):
o Virtualized Network Function, running over the NFVI.
o NFV Infrastructure (NFVI), including the diversity of physical
resources and how these can be virtualized. NFVI supports the
execution of the VNFs.
o 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.
Bernardos & Contreras Expires September 22, 2016 [Page 4]
Internet-Draft Multi-domain Network Virtualization March 2016
+-------------------------------------------+ +---------------+
| 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 | | | |
| +---------------------------------------+ | | |
+-------------------------------------------+ +---------------+
Figure 1: ETSI NFV framework
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 (Figure 2):
o Virtualized Network Function (VNF).
o Element Management (EM).
o NFV Infrastructure, including: Hardware and virtualized resources,
and Virtualization Layer.
o Virtualized Infrastructure Manager(s) (VIM).
o NFV Orchestrator.
o VNF Manager(s).
o Service, VNF and Infrastructure Description.
Bernardos & Contreras Expires September 22, 2016 [Page 5]
Internet-Draft Multi-domain Network Virtualization March 2016
o Operations and Business Support Systems (OSS/BSS).
+--------------------+
+-------------------------------------------+ | ---------------- |
| 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 |
+-------------------------------------------+ +--------------------+
Figure 2: ETSI NFV reference architecture
4. Multidomain problem statement
Complex network services enabled by NFV could be deployed leveraging
on different infrastructure environments pertaining to distinct
administrative domains, that is, operated and managed by distinct
providers.
It is then necessary to explore mechanisms for providing access to
that multiple domain environments in a common, standardized way, in
order to facilitate portability among NFVI PoPs independently of the
owner of such infrastructure.
Bernardos & Contreras Expires September 22, 2016 [Page 6]
Internet-Draft Multi-domain Network Virtualization March 2016
Common service catalog, normalized ways of requesting services,
negotiation capabilities for ensuring and agreeing service levels,
etc. are topics that have to be analyzed for truly allowing
multidomain NFV services.
5. Multi-domain architectural approaches
Different levels of relationship could be observed among customers
demanding NFV-based services and the providers offering those
capabilities.
From the customer perspective, the customer could be aware or not of
the existence of different underlying administrative domains
supporting NFV-based services. If the customer is aware of that
multi-domain situation, the customer would need to support some
features for (functionally) splitting the intended NFV-based service
among the multiple domains, ensuring proper coordination,
troubleshooting and operation between the distinct domains.
If the customer is unaware of the underlying multi-domain situation,
some of the providers would need to play the role of coordinator
between domains, in order to present towards the customer a unified
view of the services, as if it was served from one single provider.
Two possible approached for this last case are described in the
following sub-sections.
5.1. Hierarchical
In the hierarchical approach, the provider facing the customer as a
single entry point for the service request will maintain
relationships with the other providers in order to complete the
service. The Entry-Point Provider (EPP) will produce the service
split among parties, ensuring adequate levels of coordination to
offer the service as provided by a single domain to the customer.
This EPP could even not having any NFV infrastructure, just acting as
a trading agent, interacting with the rest of providers which
actually have NFVIs available for the service.
5.2. Cascading
In the cascading approach the EPP partially satisfies the service
request but complements the service by using resources external to
its own domain. The provider will trade such resources with some
other provider's offering capabilities at disposal of external
domains. It could be the case that those capabilities could even be
owned by a third provider, but this is not visible for the first
Bernardos & Contreras Expires September 22, 2016 [Page 7]
Internet-Draft Multi-domain Network Virtualization March 2016
provider. The second provider will be in charge of providing the
adequate levels of operation to the first providers, either using
resources of the second or third provider. In this way, the control
and management is cascaded among parties.
6. IANA Considerations
N/A.
7. Security Considerations
TBD.
8. Acknowledgments
TBD.
This work is supported by 5G-PPP 5GEx, an innovation action project
partially funded by the European Community under the H2020 Program
(grant agreement no. 671636). 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 presentation.
9. Informative References
[etsi_nvf_whitepaper]
"Network Functions Virtualisation (NFV). White Paper 2",
October 2014.
[Project_5GEx_Whitepaper]
"5GEx Multi-domain Service Creation - from 90 days to 90
minutes", March 2016, <http://www.5gex.eu/wp/wp-content/
uploads/2016/03/5GEx-White-Paper-v1.pdf>.
Authors' Addresses
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Bernardos & Contreras Expires September 22, 2016 [Page 8]
Internet-Draft Multi-domain Network Virtualization March 2016
Luis M. Contreras
Telefonica I+D
Ronda de la Comunicacion, S/N
Madrid 28050
Spain
Email: luismiguel.conterasmurillo@telefonica.com
URI: http://lmcontreras.com
Bernardos & Contreras Expires September 22, 2016 [Page 9]