idnits 2.17.1 draft-bernardos-nfvrg-multidomain-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2016) is 2957 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFV RG CJ. Bernardos 3 Internet-Draft UC3M 4 Intended status: Informational LM. Contreras 5 Expires: September 22, 2016 TID 6 March 21, 2016 8 Multi-domain Network Virtualization 9 draft-bernardos-nfvrg-multidomain-00 11 Abstract 13 This draft introduces the challenge of Multi-domain Network 14 Virtualization. The mutiple domains considered here correspond to 15 multiple administrative domains operating distinct infrastructures. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 22, 2016. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Background: the ETSI NFV architecture . . . . . . . . . . . . 4 54 4. Multidomain problem statement . . . . . . . . . . . . . . . . 6 55 5. Multi-domain architectural approaches . . . . . . . . . . . . 7 56 5.1. Hierarchical . . . . . . . . . . . . . . . . . . . . . . 7 57 5.2. Cascading . . . . . . . . . . . . . . . . . . . . . . . . 7 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 61 9. Informative References . . . . . . . . . . . . . . . . . . . 8 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 The telecommunications sector is experiencing a major revolution that 67 will shape the way networks and services are designed and deployed 68 for the next decade. We are witnessing an explosion in the number of 69 applications and services demanded by users, which are now really 70 capable of accessing them on the move. In order to cope with such a 71 demand, some network operators are looking at the cloud computing 72 paradigm, which enables a potential reduction of the overall costs by 73 outsourcing communication services from specific hardware in the 74 operator's core to server farms scattered in datacenters. These 75 services have different characteristics if compared with conventional 76 IT services that have to be taken into account in this cloudification 77 process. Also the transport network is affected in that it is 78 evolving to a more sophisticated form of IP architecture with trends 79 like separation of control and data plane traffic, and more fine- 80 grained forwarding of packets (beyond looking at the destination IP 81 address) in the network to fulfill new business and service goals. 83 Virtualization of functions also provides operators with tools to 84 deploy new services much faster, as compared to the traditional use 85 of monolithic and tightly integrated dedicated machinery. As a 86 natural next step, mobile network operators need to re-think how to 87 evolve their existing network infrastructures and how to deploy new 88 ones to address the challenges posed by the increasing customers' 89 demands, as well as by the huge competition among operators. All 90 these changes are triggering the need for a modification in the way 91 operators and infrastructure providers operate their networks, as 92 they need to significantly reduce the costs incurred in deploying a 93 new service and operating it. Some of the mechanisms that are being 94 considered and already adopted by operators include: sharing of 95 network infrastructure to reduce costs, virtualization of core 96 servers running in data centers as a way of supporting their load- 97 aware elastic dimensioning, and dynamic energy policies to reduce the 98 monthly electricity bill. However, this has proved to be tough to 99 put in practice, and not enough. Indeed, it is not easy to deploy 100 new mechanisms in a running operational network due to the high 101 dependency on proprietary (and sometime obscure) protocols and 102 interfaces, which are complex to manage and often require configuring 103 multiple devices in a decentralized way. 105 Network Function Virtualization (NFV) and Software Defined Networking 106 (SDN) are changing the way the telecommunications sector will deploy, 107 extend and operate their networks. 109 A challenge not yet sufficiently addressed is the multi-domain case, 110 where the infrastructure (considered as network, computing and 111 storage resources), or even some of the necessary network functions, 112 are provided by different providers each of them constituting a 113 separate administrative domain. 115 Innovative solutions have to be defined for multi-domain services 116 provisioned in an automated and on-demand manner in order to 117 accommodate future services. Such solutions not only should permit 118 programmability, flexibility and automation, but also should allow 119 for agile contracting, invoking and settling of services reducing 120 significantly the time for provision (moving from the current figure 121 of 90 days to 90 minutes as a goal) [Project_5GEx_Whitepaper]. 123 2. Terminology 125 The following terms used in this document are defined by the ETSI NVF 126 ISG, and the ONF and the IETF: 128 NFV Infrastructure (NFVI): totality of all hardware and software 129 components which build up the environment in which VNFs are 130 deployed 132 NFV Management and Orchestration (NFV-MANO): functions 133 collectively provided by NFVO, VNFM, and VIM. 135 NFV Orchestrator (NFVO): functional block that manages the Network 136 Service (NS) lifecycle and coordinates the management of NS 137 lifecycle, VNF lifecycle (supported by the VNFM) and NFVI 138 resources (supported by the VIM) to ensure an optimized allocation 139 of the necessary resources and connectivity. 141 OpenFlow protocol (OFP): allowing vendor independent programming 142 of control functions in network nodes. 144 Service Function Chain (SFC): for a given service, the abstracted 145 view of the required service functions and the order in which they 146 are to be applied. This is somehow equivalent to the Network 147 Function Forwarding Graph (NF-FG) at ETSI. 149 Service Function Path (SFP): the selection of specific service 150 function instances on specific network nodes to form a service 151 graph through which an SFC is instantiated. 153 Virtualized Infrastructure Manager (VIM): functional block that is 154 responsible for controlling and managing the NFVI compute, storage 155 and network resources, usually within one operator's 156 Infrastructure Domain. 158 Virtualized Network Function (VNF): implementation of a Network 159 Function that can be deployed on a Network Function Virtualisation 160 Infrastructure (NFVI). 162 Virtualized Network Function Manager (VNFM): functional block that 163 is responsible for the lifecycle management of VNF. 165 3. Background: the ETSI NFV architecture 167 The ETSI ISG NFV is a working group which, since 2012, aims to evolve 168 quasi-standard IT virtualization technology to consolidate many 169 network equipment types into industry standard high volume servers, 170 switches, and storage. It enables implementing network functions in 171 software that can run on a range of industry standard server hardware 172 and can be moved to, or loaded in, various locations in the network 173 as required, without the need to install new equipment. To date, 174 ETSI NFV is by far the most accepted NFV reference framework and 175 architectural footprint [etsi_nvf_whitepaper]. The ETSI NFV 176 framework architecture framework is composed of three domains 177 (Figure 1): 179 o Virtualized Network Function, running over the NFVI. 181 o NFV Infrastructure (NFVI), including the diversity of physical 182 resources and how these can be virtualized. NFVI supports the 183 execution of the VNFs. 185 o NFV Management and Orchestration, which covers the orchestration 186 and life-cycle management of physical and/or software resources 187 that support the infrastructure virtualization, and the life-cycle 188 management of VNFs. NFV Management and Orchestration focuses on 189 all virtualization specific management tasks necessary in the NFV 190 framework. 192 +-------------------------------------------+ +---------------+ 193 | Virtualized Network Functions (VNFs) | | | 194 | ------- ------- ------- ------- | | | 195 | | | | | | | | | | | | 196 | | VNF | | VNF | | VNF | | VNF | | | | 197 | | | | | | | | | | | | 198 | ------- ------- ------- ------- | | | 199 +-------------------------------------------+ | | 200 | | 201 +-------------------------------------------+ | | 202 | NFV Infrastructure (NFVI) | | NFV | 203 | ----------- ----------- ----------- | | Management | 204 | | Virtual | | Virtual | | Virtual | | | and | 205 | | Compute | | Storage | | Network | | | Orchestration | 206 | ----------- ----------- ----------- | | | 207 | +---------------------------------------+ | | | 208 | | Virtualization Layer | | | | 209 | +---------------------------------------+ | | | 210 | +---------------------------------------+ | | | 211 | | ----------- ----------- ----------- | | | | 212 | | | Compute | | Storage | | Network | | | | | 213 | | ----------- ----------- ----------- | | | | 214 | | Hardware resources | | | | 215 | +---------------------------------------+ | | | 216 +-------------------------------------------+ +---------------+ 218 Figure 1: ETSI NFV framework 220 The NFV architectural framework identifies functional blocks and the 221 main reference points between such blocks. Some of these are already 222 present in current deployments, whilst others might be necessary 223 additions in order to support the virtualization process and 224 consequent operation. The functional blocks are (Figure 2): 226 o Virtualized Network Function (VNF). 228 o Element Management (EM). 230 o NFV Infrastructure, including: Hardware and virtualized resources, 231 and Virtualization Layer. 233 o Virtualized Infrastructure Manager(s) (VIM). 235 o NFV Orchestrator. 237 o VNF Manager(s). 239 o Service, VNF and Infrastructure Description. 241 o Operations and Business Support Systems (OSS/BSS). 243 +--------------------+ 244 +-------------------------------------------+ | ---------------- | 245 | OSS/BSS | | | NFV | | 246 +-------------------------------------------+ | | Orchestrator +-- | 247 | ---+------------ | | 248 +-------------------------------------------+ | | | | 249 | --------- --------- --------- | | | | | 250 | | EM 1 | | EM 2 | | EM 3 | | | | | | 251 | ----+---- ----+---- ----+---- | | ---+---------- | | 252 | | | | |--|-| VNF | | | 253 | ----+---- ----+---- ----+---- | | | manager(s) | | | 254 | | VNF 1 | | VNF 2 | | VNF 3 | | | ---+---------- | | 255 | ----+---- ----+---- ----+---- | | | | | 256 +------|-------------|-------------|--------+ | | | | 257 | | | | | | | 258 +------+-------------+-------------+--------+ | | | | 259 | NFV Infrastructure (NFVI) | | | | | 260 | ----------- ----------- ----------- | | | | | 261 | | Virtual | | Virtual | | Virtual | | | | | | 262 | | Compute | | Storage | | Network | | | | | | 263 | ----------- ----------- ----------- | | ---+------ | | 264 | +---------------------------------------+ | | | | | | 265 | | Virtualization Layer | |--|-| VIM(s) +-------- | 266 | +---------------------------------------+ | | | | | 267 | +---------------------------------------+ | | ---------- | 268 | | ----------- ----------- ----------- | | | | 269 | | | Compute | | Storage | | Network | | | | | 270 | | | hardware| | hardware| | hardware| | | | | 271 | | ----------- ----------- ----------- | | | | 272 | | Hardware resources | | | NFV Management | 273 | +---------------------------------------+ | | and Orchestration | 274 +-------------------------------------------+ +--------------------+ 276 Figure 2: ETSI NFV reference architecture 278 4. Multidomain problem statement 280 Complex network services enabled by NFV could be deployed leveraging 281 on different infrastructure environments pertaining to distinct 282 administrative domains, that is, operated and managed by distinct 283 providers. 285 It is then necessary to explore mechanisms for providing access to 286 that multiple domain environments in a common, standardized way, in 287 order to facilitate portability among NFVI PoPs independently of the 288 owner of such infrastructure. 290 Common service catalog, normalized ways of requesting services, 291 negotiation capabilities for ensuring and agreeing service levels, 292 etc. are topics that have to be analyzed for truly allowing 293 multidomain NFV services. 295 5. Multi-domain architectural approaches 297 Different levels of relationship could be observed among customers 298 demanding NFV-based services and the providers offering those 299 capabilities. 301 From the customer perspective, the customer could be aware or not of 302 the existence of different underlying administrative domains 303 supporting NFV-based services. If the customer is aware of that 304 multi-domain situation, the customer would need to support some 305 features for (functionally) splitting the intended NFV-based service 306 among the multiple domains, ensuring proper coordination, 307 troubleshooting and operation between the distinct domains. 309 If the customer is unaware of the underlying multi-domain situation, 310 some of the providers would need to play the role of coordinator 311 between domains, in order to present towards the customer a unified 312 view of the services, as if it was served from one single provider. 314 Two possible approached for this last case are described in the 315 following sub-sections. 317 5.1. Hierarchical 319 In the hierarchical approach, the provider facing the customer as a 320 single entry point for the service request will maintain 321 relationships with the other providers in order to complete the 322 service. The Entry-Point Provider (EPP) will produce the service 323 split among parties, ensuring adequate levels of coordination to 324 offer the service as provided by a single domain to the customer. 326 This EPP could even not having any NFV infrastructure, just acting as 327 a trading agent, interacting with the rest of providers which 328 actually have NFVIs available for the service. 330 5.2. Cascading 332 In the cascading approach the EPP partially satisfies the service 333 request but complements the service by using resources external to 334 its own domain. The provider will trade such resources with some 335 other provider's offering capabilities at disposal of external 336 domains. It could be the case that those capabilities could even be 337 owned by a third provider, but this is not visible for the first 338 provider. The second provider will be in charge of providing the 339 adequate levels of operation to the first providers, either using 340 resources of the second or third provider. In this way, the control 341 and management is cascaded among parties. 343 6. IANA Considerations 345 N/A. 347 7. Security Considerations 349 TBD. 351 8. Acknowledgments 353 TBD. 355 This work is supported by 5G-PPP 5GEx, an innovation action project 356 partially funded by the European Community under the H2020 Program 357 (grant agreement no. 671636). The views expressed here are those of 358 the authors only. The European Commission is not liable for any use 359 that may be made of the information in this presentation. 361 9. Informative References 363 [etsi_nvf_whitepaper] 364 "Network Functions Virtualisation (NFV). White Paper 2", 365 October 2014. 367 [Project_5GEx_Whitepaper] 368 "5GEx Multi-domain Service Creation - from 90 days to 90 369 minutes", March 2016, . 372 Authors' Addresses 374 Carlos J. Bernardos 375 Universidad Carlos III de Madrid 376 Av. Universidad, 30 377 Leganes, Madrid 28911 378 Spain 380 Phone: +34 91624 6236 381 Email: cjbc@it.uc3m.es 382 URI: http://www.it.uc3m.es/cjbc/ 383 Luis M. Contreras 384 Telefonica I+D 385 Ronda de la Comunicacion, S/N 386 Madrid 28050 387 Spain 389 Email: luismiguel.conterasmurillo@telefonica.com 390 URI: http://lmcontreras.com