[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 draft-bernardos-nmrg-multidomain

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/