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, . 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]