idnits 2.17.1 draft-irtf-nfvrg-gaps-network-virtualization-02.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 (October 19, 2016) is 2739 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 NFVRG CJ. Bernardos 3 Internet-Draft UC3M 4 Intended status: Informational A. Rahman 5 Expires: April 22, 2017 InterDigital 6 JC. Zuniga 7 SIGFOX 8 LM. Contreras 9 P. Aranda 10 TID 11 October 19, 2016 13 Network Virtualization Research Challenges 14 draft-irtf-nfvrg-gaps-network-virtualization-02 16 Abstract 18 This document describes open research challenges for network 19 virtualization. Network virtualization is following a similar path 20 as previously taken by cloud computing. Specifically, Cloud 21 computing popularized migration of computing functions (e.g., 22 applications) and storage from local, dedicated, physical resources 23 to remote virtual functions accessible through the Internet. In a 24 similar manner, network virtualization is encouraging migration of 25 networking functions from dedicated physical hardware nodes to a 26 virtualized pool of resources. However, network virtualization can 27 be considered to be a more complex problem than cloud computing as it 28 not only involves virtualization of computing and storage functions 29 but also involves abstraction of the network itself. This document 30 describes current research challenges in network virtualization 31 including guaranteeing quality-of-service, energy efficiency, 32 supporting multiple domains, network slicing, self-management, device 33 virtualization, privacy and security. In addition, some proposals 34 are made for new activities in IETF/IRTF that could address some of 35 these challenges. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 22, 2017. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Network Function Virtualization . . . . . . . . . . . . . 5 75 3.2. Software Defined Networking . . . . . . . . . . . . . . . 8 76 3.3. Mobile Edge Computing . . . . . . . . . . . . . . . . . . 11 77 3.4. IEEE 802.1CF (OmniRAN) . . . . . . . . . . . . . . . . . 12 78 3.5. Distributed Management Task Force . . . . . . . . . . . . 12 79 3.6. Open Source initiatives . . . . . . . . . . . . . . . . . 12 80 3.7. Internet of Things (IoT) . . . . . . . . . . . . . . . . 14 81 4. Network Virtualization Challenges . . . . . . . . . . . . . . 14 82 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 14 83 4.2. Guaranteeing quality-of-service . . . . . . . . . . . . . 15 84 4.2.1. Virtualization Technologies . . . . . . . . . . . . . 15 85 4.2.2. Metrics for NFV charaterization . . . . . . . . . . . 15 86 4.2.3. Predictive analysis . . . . . . . . . . . . . . . . . 16 87 4.2.4. Portability . . . . . . . . . . . . . . . . . . . . . 16 88 4.3. Performance improvement . . . . . . . . . . . . . . . . . 16 89 4.3.1. Energy Efficiency . . . . . . . . . . . . . . . . . . 16 90 4.3.2. Improved link usage . . . . . . . . . . . . . . . . . 16 91 4.4. Multiple Domains . . . . . . . . . . . . . . . . . . . . 17 92 4.5. Network Slicing . . . . . . . . . . . . . . . . . . . . . 17 93 4.6. Service Composition . . . . . . . . . . . . . . . . . . . 18 94 4.7. End-user device virtualization . . . . . . . . . . . . . 19 95 4.8. Security and Privacy . . . . . . . . . . . . . . . . . . 19 96 5. Summary of Gaps . . . . . . . . . . . . . . . . . . . . . . . 21 97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 99 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 100 9. Informative References . . . . . . . . . . . . . . . . . . . 22 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 103 1. Introduction 105 The telecommunications sector is experiencing a major revolution that 106 will shape the way networks and services are designed and deployed 107 for the next decade. We are witnessing an explosion in the number of 108 applications and services demanded by users, which are now really 109 capable of accessing them on the move. In order to cope with such a 110 demand, some network operators are looking at the cloud computing 111 paradigm, which enables a potential reduction of the overall costs by 112 outsourcing communication services from specific hardware in the 113 operator's core to server farms scattered in datacenters. These 114 services have different characteristics if compared with conventional 115 IT services that have to be taken into account in this cloudification 116 process. Also the transport network is affected in that it is 117 evolving to a more sophisticated form of IP architecture with trends 118 like separation of control and data plane traffic, and more fine- 119 grained forwarding of packets (beyond looking at the destination IP 120 address) in the network to fulfill new business and service goals. 122 Virtualization of functions also provides operators with tools to 123 deploy new services much faster, as compared to the traditional use 124 of monolithic and tightly integrated dedicated machinery. As a 125 natural next step, mobile network operators need to re-think how to 126 evolve their existing network infrastructures and how to deploy new 127 ones to address the challenges posed by the increasing customers' 128 demands, as well as by the huge competition among operators. All 129 these changes are triggering the need for a modification in the way 130 operators and infrastructure providers operate their networks, as 131 they need to significantly reduce the costs incurred in deploying a 132 new service and operating it. Some of the mechanisms that are being 133 considered and already adopted by operators include: sharing of 134 network infrastructure to reduce costs, virtualization of core 135 servers running in data centers as a way of supporting their load- 136 aware elastic dimensioning, and dynamic energy policies to reduce the 137 monthly electricity bill. However, this has proved to be tough to 138 put in practice, and not enough. Indeed, it is not easy to deploy 139 new mechanisms in a running operational network due to the high 140 dependency on proprietary (and sometime obscure) protocols and 141 interfaces, which are complex to manage and often require configuring 142 multiple devices in a decentralized way. 144 Network Function Virtualization (NFV) and Software Defined Networking 145 (SDN) are changing the way the telecommunications sector will deploy, 146 extend and operate their networks. This document describes current 147 research challenges in network virtualization and correlates them to 148 activities currently occurring in the key standards forums and open 149 source efforts. Based on this analysis, we also go a step farther, 150 identifying which are the potential work areas where IETF/IRTF can 151 work on to complement the complex network virtualization map of 152 technologies being standardized today. 154 2. Terminology 156 The following terms used in this document are defined by the ETSI NVF 157 ISG, the ONF and the IETF: 159 Application Plane - The collection of applications and services 160 that program network behavior. 162 Control Plane (CP) - The collection of functions responsible for 163 controlling one or more network devices. CP instructs network 164 devices with respect to how to process and forward packets. The 165 control plane interacts primarily with the forwarding plane and, 166 to a lesser extent, with the operational plane. 168 Forwarding Plane (FP) - The collection of resources across all 169 network devices responsible for forwarding traffic. 171 Management Plane (MP) - The collection of functions responsible 172 for monitoring, configuring, and maintaining one or more network 173 devices or parts of network devices. The management plane is 174 mostly related to the operational plane (it is related less to the 175 forwarding plane). 177 NFV Infrastructure (NFVI): totality of all hardware and software 178 components which build up the environment in which VNFs are 179 deployed 181 NFV Management and Orchestration (NFV-MANO): functions 182 collectively provided by NFVO, VNFM, and VIM. 184 NFV Orchestrator (NFVO): functional block that manages the Network 185 Service (NS) lifecycle and coordinates the management of NS 186 lifecycle, VNF lifecycle (supported by the VNFM) and NFVI 187 resources (supported by the VIM) to ensure an optimized allocation 188 of the necessary resources and connectivity. 190 OpenFlow protocol (OFP): allowing vendor independent programming 191 of control functions in network nodes. 193 Operational Plane (OP) - The collection of resources responsible 194 for managing the overall operation of individual network devices. 196 Service Function Chain (SFC): for a given service, the abstracted 197 view of the required service functions and the order in which they 198 are to be applied. This is somehow equivalent to the Network 199 Function Forwarding Graph (NF-FG) at ETSI. 201 Service Function Path (SFP): the selection of specific service 202 function instances on specific network nodes to form a service 203 graph through which an SFC is instantiated. 205 virtual EPC (vEPC): control plane of 3GPPs EPC operated on NFV 206 framework (as defined by [I-D.matsushima-stateless-uplane-vepc]). 208 Virtualized Infrastructure Manager (VIM): functional block that is 209 responsible for controlling and managing the NFVI compute, storage 210 and network resources, usually within one operator's 211 Infrastructure Domain. 213 Virtualized Network Function (VNF): implementation of a Network 214 Function that can be deployed on a Network Function Virtualisation 215 Infrastructure (NFVI). 217 Virtualized Network Function Manager (VNFM): functional block that 218 is responsible for the lifecycle management of VNF. 220 3. Background 222 3.1. Network Function Virtualization 224 The ETSI ISG NFV is a working group which, since 2012, aims to evolve 225 quasi-standard IT virtualization technology to consolidate many 226 network equipment types into industry standard high volume servers, 227 switches, and storage. It enables implementing network functions in 228 software that can run on a range of industry standard server hardware 229 and can be moved to, or loaded in, various locations in the network 230 as required, without the need to install new equipment. To date, 231 ETSI NFV is by far the most accepted NFV reference framework and 232 architectural footprint [etsi_nvf_whitepaper]. The ETSI NFV 233 framework architecture framework is composed of three domains 234 (Figure 1): 236 o Virtualized Network Function, running over the NFVI. 238 o NFV Infrastructure (NFVI), including the diversity of physical 239 resources and how these can be virtualized. NFVI supports the 240 execution of the VNFs. 242 o NFV Management and Orchestration, which covers the orchestration 243 and life-cycle management of physical and/or software resources 244 that support the infrastructure virtualization, and the life-cycle 245 management of VNFs. NFV Management and Orchestration focuses on 246 all virtualization specific management tasks necessary in the NFV 247 framework. 249 +-------------------------------------------+ +---------------+ 250 | Virtualized Network Functions (VNFs) | | | 251 | ------- ------- ------- ------- | | | 252 | | | | | | | | | | | | 253 | | VNF | | VNF | | VNF | | VNF | | | | 254 | | | | | | | | | | | | 255 | ------- ------- ------- ------- | | | 256 +-------------------------------------------+ | | 257 | | 258 +-------------------------------------------+ | | 259 | NFV Infrastructure (NFVI) | | NFV | 260 | ----------- ----------- ----------- | | Management | 261 | | Virtual | | Virtual | | Virtual | | | and | 262 | | Compute | | Storage | | Network | | | Orchestration | 263 | ----------- ----------- ----------- | | | 264 | +---------------------------------------+ | | | 265 | | Virtualization Layer | | | | 266 | +---------------------------------------+ | | | 267 | +---------------------------------------+ | | | 268 | | ----------- ----------- ----------- | | | | 269 | | | Compute | | Storage | | Network | | | | | 270 | | ----------- ----------- ----------- | | | | 271 | | Hardware resources | | | | 272 | +---------------------------------------+ | | | 273 +-------------------------------------------+ +---------------+ 275 Figure 1: ETSI NFV framework 277 The NFV architectural framework identifies functional blocks and the 278 main reference points between such blocks. Some of these are already 279 present in current deployments, whilst others might be necessary 280 additions in order to support the virtualization process and 281 consequent operation. The functional blocks are (Figure 2): 283 o Virtualized Network Function (VNF). 285 o Element Management (EM). 287 o NFV Infrastructure, including: Hardware and virtualized resources, 288 and Virtualization Layer. 290 o Virtualized Infrastructure Manager(s) (VIM). 292 o NFV Orchestrator. 294 o VNF Manager(s). 296 o Service, VNF and Infrastructure Description. 298 o Operations and Business Support Systems (OSS/BSS). 300 +--------------------+ 301 +-------------------------------------------+ | ---------------- | 302 | OSS/BSS | | | NFV | | 303 +-------------------------------------------+ | | Orchestrator +-- | 304 | ---+------------ | | 305 +-------------------------------------------+ | | | | 306 | --------- --------- --------- | | | | | 307 | | EM 1 | | EM 2 | | EM 3 | | | | | | 308 | ----+---- ----+---- ----+---- | | ---+---------- | | 309 | | | | |--|-| VNF | | | 310 | ----+---- ----+---- ----+---- | | | manager(s) | | | 311 | | VNF 1 | | VNF 2 | | VNF 3 | | | ---+---------- | | 312 | ----+---- ----+---- ----+---- | | | | | 313 +------|-------------|-------------|--------+ | | | | 314 | | | | | | | 315 +------+-------------+-------------+--------+ | | | | 316 | NFV Infrastructure (NFVI) | | | | | 317 | ----------- ----------- ----------- | | | | | 318 | | Virtual | | Virtual | | Virtual | | | | | | 319 | | Compute | | Storage | | Network | | | | | | 320 | ----------- ----------- ----------- | | ---+------ | | 321 | +---------------------------------------+ | | | | | | 322 | | Virtualization Layer | |--|-| VIM(s) +-------- | 323 | +---------------------------------------+ | | | | | 324 | +---------------------------------------+ | | ---------- | 325 | | ----------- ----------- ----------- | | | | 326 | | | Compute | | Storage | | Network | | | | | 327 | | | hardware| | hardware| | hardware| | | | | 328 | | ----------- ----------- ----------- | | | | 329 | | Hardware resources | | | NFV Management | 330 | +---------------------------------------+ | | and Orchestration | 331 +-------------------------------------------+ +--------------------+ 333 Figure 2: ETSI NFV reference architecture 335 3.2. Software Defined Networking 337 The Software Defined Networking (SDN) paradigm pushes the 338 intelligence currently residing in the network elements to a central 339 controller implementing the network functionality through software. 340 In contrast to traditional approaches, in which the network's control 341 plane is distributed throughout all network devices, with SDN the 342 control plane is logically centralized. In this way, the deployment 343 of new characteristics in the network no longer requires of complex 344 and costly changes in equipment or firmware updates, but only a 345 change in the software running in the controller. The main advantage 346 of this approach is the flexibility it provides operators with to 347 manage their network, i.e., an operator can easily change its 348 policies on how traffic is distributed throughout the network. 350 The most visible of the SDN protocol stacks is the OpenFlow protocol 351 (OFP), which is maintained and extended by the Open Network 352 Foundation (ONF: https://www.opennetworking.org/). Originally this 353 protocol was developed specifically for IEEE 802.1 switches 354 conforming to the ONF OpenFlow Switch specification. As the benefits 355 of the SDN paradigm have reached a wider audience, its application 356 has been extended to more complex scenarios such as Wireless and 357 Mobile networks. Within this area of work, the ONF is actively 358 developing new OFP extensions addressing three key scenarios: (i) 359 Wireless backhaul, (ii) Cellular Evolved Packet Core (EPC), and (iii) 360 Unified access and management across enterprise wireless and fixed 361 networks. 363 +----------+ 364 | ------- | 365 | |Oper.| | O 366 | |Mgmt.| |<........> -+- Network Operator 367 | |Iface| | ^ 368 | ------- | +----------------------------------------+ 369 | | | +------------------------------------+ | 370 | | | | --------- --------- --------- | | 371 |--------- | | | | App 1 | | App 2 | ... | App n | | | 372 ||Plugins| |<....>| | --------- --------- --------- | | 373 |--------- | | | Plugins | | 374 | | | +------------------------------------+ | 375 | | | Application Plane | 376 | | +----------------------------------------+ 377 | | A 378 | | | 379 | | V 380 | | +----------------------------------------+ 381 | | | +------------------------------------+ | 382 |--------- | | | ------------ ------------ | | 383 || Netw. | | | | | Module 1 | | Module 2 | | | 384 ||Engine | |<....>| | ------------ ------------ | | 385 |--------- | | | Network Engine | | 386 | | | +------------------------------------+ | 387 | | | Controller Plane | 388 | | +----------------------------------------+ 389 | | A 390 | | | 391 | | V 392 | | +----------------------------------------+ 393 | | | +--------------+ +--------------+ | 394 | | | | ------------ | | ------------ | | 395 |----------| | | | OpenFlow | | | | OpenFlow | | | 396 ||OpenFlow||<....>| | ------------ | | ------------ | | 397 |----------| | | NE | | NE | | 398 | | | +--------------+ +--------------+ | 399 | | | Data Plane | 400 |Management| +----------------------------------------+ 401 +----------+ 403 Figure 3: High level SDN ONF architecture 405 Figure 3 shows the blocks and the functional interfaces of the ONF 406 architecture, which comprises three planes: Data, Controller, and 407 Application. The Data plane comprehends several Network Entities 408 (NE), which expose their capabilities toward the Controller plane via 409 a Southbound API. The Controller plane includes several cooperating 410 modules devoted to the creation and maintenance of an abstracted 411 resource model of the underneath network. Such model is exposed to 412 the applications via a Northbound API where the Application plane 413 comprises several applications/services, each of which has exclusive 414 control of a set of exposed resources. 416 The Management plane spans its functionality across all planes 417 performing the initial configuration of the network elements in the 418 Data plane, the assignment of the SDN controller and the resources 419 under its responsibility. In the Controller plane, the Management 420 needs to configure the policies defining the scope of the control 421 given to the SDN applications, to monitor the performance of the 422 system, and to configure the parameters required by the SDN 423 controller modules. In the Application plane, Management configures 424 the parameters of the applications and the service level agreements. 425 In addition to the these interactions, the Management plane exposes 426 several functions to network operators which can easily and quickly 427 configure and tune the network at each layer. 429 The SDNRG has documented a reference layer model in RFC7426 430 [RFC7426], which is reproduced in Figure 4. This model structures 431 SDN in planes and layers which are glued together by different 432 abstraction layers. This architecture differentiates between the 433 control and the management planes and provides for differentiated 434 southbound interfaces (SBIs). 436 o--------------------------------o 437 | | 438 | +-------------+ +----------+ | 439 | | Application | | Service | | 440 | +-------------+ +----------+ | 441 | Application Plane | 442 o---------------Y----------------o 443 | 444 *-----------------------------Y---------------------------------* 445 | Network Services Abstraction Layer (NSAL) | 446 *------Y------------------------------------------------Y-------* 447 | | 448 | Service Interface | 449 | | 450 o------Y------------------o o---------------------Y------o 451 | | Control Plane | | Management Plane | | 452 | +----Y----+ +-----+ | | +-----+ +----Y----+ | 453 | | Service | | App | | | | App | | Service | | 454 | +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ | 455 | | | | | | | | 456 | *----Y-----------Y----* | | *---Y---------------Y----* | 457 | | Control Abstraction | | | | Management Abstraction | | 458 | | Layer (CAL) | | | | Layer (MAL) | | 459 | *----------Y----------* | | *----------Y-------------* | 460 | | | | | | 461 o------------|------------o o------------|---------------o 462 | | 463 | CP | MP 464 | Southbound | Southbound 465 | Interface | Interface 466 | | 467 *------------Y---------------------------------Y----------------* 468 | Device and resource Abstraction Layer (DAL) | 469 *------------Y---------------------------------Y----------------* 470 | | | | 471 | o-------Y----------o +-----+ o--------Y----------o | 472 | | Forwarding Plane | | App | | Operational Plane | | 473 | o------------------o +-----+ o-------------------o | 474 | Network Device | 475 +---------------------------------------------------------------+ 477 Figure 4: SDN Layer Architecture 479 3.3. Mobile Edge Computing 481 Mobile Edge Computing capabilities deployed in the edge of the mobile 482 network can facilitate the efficient and dynamic provision of 483 services to mobile users. The ETSI ISG MEC working group, operative 484 from end of 2014, intends to specify an open environment for 485 integrating MEC capabilities with service providers networks, 486 including also applications from 3rd parties. These distributed 487 computing capabilities will make available IT infrastructure as in a 488 cloud environment for the deployment of functions in mobile access 489 networks. It can be seen then as a complement to both NFV and SDN. 491 3.4. IEEE 802.1CF (OmniRAN) 493 The IEEE 802.1CF Recommended Practice specifies an access network, 494 which connects terminals to their access routers, utilizing 495 technologies based on the family of IEEE 802 Standards (e.g., 802.3 496 Ethernet, 802.11 Wi-Fi, etc.). The specification defines an access 497 network reference model, including entities and reference points 498 along with behavioral and functional descriptions of communications 499 among those entities. 501 The goal of this project is to help unifying the support of different 502 interfaces, enabling shared network control and use of software 503 defined network (SDN) principles, thereby lowering the barriers to 504 new network technologies, to new network operators, and to new 505 service providers. 507 3.5. Distributed Management Task Force 509 The DMTF is an industry standards organization working to simplify 510 the manageability of network-accessible technologies through open and 511 collaborative efforts by some technology companies. The DMTF is 512 involved in the creation and adoption of interoperable management 513 standards, supporting implementations that enable the management of 514 diverse traditional and emerging technologies including cloud, 515 virtualization, network and infrastructure. 517 There are several DMTF initiatives that are relevant to the network 518 virtualization area, such as the Open Virtualization Format (OVF), 519 for VNF packaging; the Cloud Infrastructure Management Interface 520 (CIM), for cloud infrastructure management; the Network Management 521 (NETMAN), for VNF management; and, the Virtualization Management 522 (VMAN), for virtualization infrastructure management. 524 3.6. Open Source initiatives 526 The Open Source community is especially active in the area of network 527 virtualization. We next summarize some of the active efforts: 529 o OpenStack. OpenStack is a free and open-source cloud-computing 530 software platform. OpenStack software controls large pools of 531 compute, storage, and networking resources throughout a 532 datacenter, managed through a dashboard or via the OpenStack API. 534 o OpenDayLight. OpenDaylight (ODL) is a highly available, modular, 535 extensible, scalable and multi-protocol controller infrastructure 536 built for SDN deployments on modern heterogeneous multi-vendor 537 networks. It provides a model-driven service abstraction platform 538 that allows users to write apps that easily work across a wide 539 variety of hardware and southbound protocols. 541 o ONOS. The ONOS (Open Network Operating System) project is an open 542 source community hosted by The Linux Foundation. The goal of the 543 project is to create a software-defined networking (SDN) operating 544 system for communications service providers that is designed for 545 scalability, high performance and high availability. 547 o OpenContrail. OpenContrail is an Apache 2.0-licensed project that 548 is built using standards-based protocols and provides all the 549 necessary components for network virtualization-SDN controller, 550 virtual router, analytics engine, and published northbound APIs. 551 It has an extensive REST API to configure and gather operational 552 and analytics data from the system. 554 o OPNFV. OPNFV is a carrier-grade, integrated, open source platform 555 to accelerate the introduction of new NFV products and services. 556 By integrating components from upstream projects, the OPNFV 557 community aims at conducting performance and use case-based 558 testing to ensure the platform's suitability for NFV use cases. 559 The scope of OPNFV's initial release is focused on building NFV 560 Infrastructure (NFVI) and Virtualized Infrastructure Management 561 (VIM) by integrating components from upstream projects such as 562 OpenDaylight, OpenStack, Ceph Storage, KVM, Open vSwitch, and 563 Linux. These components, along with application programmable 564 interfaces (APIs) to other NFV elements form the basic 565 infrastructure required for Virtualized Network Functions (VNF) 566 and Management and Network Orchestration (MANO) components. 567 OPNFV's goal is to increase performance and power efficiency; 568 improve reliability, availability, and serviceability; and deliver 569 comprehensive platform instrumentation. 571 o OSM. Open Source Mano (OSM) is an ETSI-hosted project to develop 572 an Open Source NFV Management and Orchestration (MANO) software 573 stack aligned with ETSI NFV. OSM is based on components from 574 previous projects, such Telefonica's OpenMANO or Canonical's Juju, 575 among others. 577 o OpenBaton. OpenBaton is a ETSI NFV compliant Network Function 578 Virtualization Orchestrator (NFVO). OpenBaton was part of the 579 OpenSDNCore project started with the objective of providing a 580 compliant implementation of the ETSI NFV specification. 582 Among the main areas that are being developed by the former open 583 source activities that related to network virtualization research, we 584 can highlight: policy-based resource management, analytics for 585 visibility and orchestration, service verification with regards to 586 security and resiliency. 588 3.7. Internet of Things (IoT) 590 The Internet of Things (IoT) refers to the vision of connecting a 591 multitude of automated devices (e.g. lights, environmental sensors, 592 traffic lights, parking meters, health and security systems, etc.) to 593 the Internet for purposes of reporting, and remote command and 594 control of the device. This vision is being realized by a multi- 595 pronged approach of standardization in various forums and 596 complementary open source activities. For example, in IETF, support 597 of IoT web services has been defined by an HTTP-like protocol adapted 598 for IoT called CoAP [RFC7252], and lately a group has been studying 599 the need to develop a new network layer to support IP applications 600 over Low Power Wide Area Networks (LPWAN). 602 Elsewhere, for 5G cellular evolution there is much discussion on the 603 need for supporting virtual "network slices" for the expected massive 604 numbers of IoT devices. A separate virtual network slice is 605 considered necessary for different 5G IoT use cases because devices 606 will have very different characteristics than typical cellular 607 devices like smart phones [ngmn_5G_whitepaper], and the number of IoT 608 devices is expected to be at least one or two orders of magnitude 609 higher than other 5G devices. 611 4. Network Virtualization Challenges 613 4.1. Introduction 615 Network Virtualization is changing the way the telecommunications 616 sector will deploy, extend and operate their networks. These new 617 technologies aim at reducing the overall costs by outsourcing 618 communication services from specific hardware in the operators' core 619 to server farms scattered in datacenters (i.e. compute and storage 620 virtualization). In addition, the connecting networks are 621 fundamentally affected in the way they route, process and control 622 traffic (i.e. network virtualization). 624 4.2. Guaranteeing quality-of-service 626 Guaranteeing a given quality-of-service in an NFV environment is not 627 an easy task. For example, ensuring a guaranteed and stable 628 forwarding data rate has proven not to be straightforward when the 629 forwarding function is virtualized and runs on top of COTS server 630 hardware. We next identify some of the challenges that this poses. 632 4.2.1. Virtualization Technologies 634 The issue of guaranteeing a network quality-of-service is less of an 635 issue for "traditional cloud computing". NFV poses very strict 636 requirements posed in terms of performance, stability and 637 consistency. Although there are some tools and mechanisms to improve 638 this, such as Enhanced Performance Awareness (EPA), SR-IOV, NUMA, 639 DPDK, etc, these are still unsolved challenges. One open research 640 issue is finding out technologies that are different from VM and more 641 suitable for dealing with network functionalities. 643 Lately, a number of light-weight virtualization technologies 644 including containers, unikernels (specialized VMs) and minimalistic 645 distributions of general-purpose OSes have appeared as virtualization 646 approaches that can be used when constructing an NFV platform. 647 [I-D.natarajan-nfvrg-containers-for-nfv] describes the challenges in 648 building such a platform and discusses to what extent these 649 technologies, as well as traditional VMs, are able to address them. 651 4.2.2. Metrics for NFV charaterization 653 Another relevant aspect is the need for tools for diagnostics and 654 measurement suited for NFV. There is a pressing need to define 655 metrics and associated protocols to measure the performance of NFV. 656 Specifically, since NFV is based on the concept of taking centralized 657 functions and evolving it to highly distributed SW functions, there 658 is a commensurate need to fully understand and measure the baseline 659 performance of such systems. 661 The IP Performance Metrics (IPPM) WG defines metrics that can be used 662 to measure the quality and performance of Internet services and 663 applications running over transport layer protocols (e.g., TCP, UPD) 664 over IP. It also develops and maintains protocols for the 665 measurement of these metrics. While the IPPM WG is a long running WG 666 that started in 1997 it does not have a charter item or active drafts 667 related to the topic of network virtualization. In addition to using 668 IPPM metrics to evaluate the QoS, there is a need for specific 669 metrics for assessing the performance of network virtualization 670 techniques. 672 4.2.3. Predictive analysis 674 On top of diagnostic tools that enable an assessment of the QoS, 675 predictive analyses are required to react before anomalies occur. 676 Due to the SW characteristics of VNFs, a reliable diagnosis framework 677 could potentially enable the prevention of issues by a proper 678 diagnosis and then a reaction in terms of acting on the potentially 679 impacted service (e.g., migration to a different compute node, 680 scaling in/out, up/down, etc). 682 4.2.4. Portability 684 Portability is also a key feature that, if fully enabled, would 685 contribute to making the NFV environment achieve a better reliability 686 than a traditional system. The fact of running functionality in SW 687 over "commodity" infrastructure should make much easier to port/move 688 functions from one place to another. However this is not yet as 689 ideal as it sounds and there are aspects not fully tackled. The 690 existence of different hypervisors, specific hardware dependencies 691 (e.g., EPA related) or state synchronization aspects are just some 692 examples of trouble-makers for portability purposes. 694 4.3. Performance improvement 696 4.3.1. Energy Efficiency 698 Virtualization is typically seen as a direct enabler of energy 699 savings. Some of the enablers for this that are often mentioned are: 700 (i) the multiplexing gains achieved by centralizing functions in data 701 centers reduce overall the energy consumed, (ii) the flexibility 702 brought by network programmability enables to switch off 703 infrastructure as needed in a much easier way. However there is 704 still a lot of room for improvement in terms of virtualization 705 techniques to reduce the power consumption, such as enhanced 706 hypervisor technologies. 708 4.3.2. Improved link usage 710 The use of NFV and SDN technologies can help improving link usage. 711 SDN has shown already that it can greatly increase average link usage 712 (e.g., Google example). NFV adds more complexity (e.g., due to 713 service function chaining / VNF forwarding drafts) which need to be 714 considered. Aspects like the ones described in 715 [I-D.bagnulo-nfvrg-topology] on NFV data center topology design have 716 to be carefully looked as well. 718 4.4. Multiple Domains 720 Market fragmentation has resulted in a multitude of network operators 721 each focused on different countries and regions. This makes it 722 difficult to create infrastructure services spanning multiple 723 countries, such as virtual connectivity or compute resources, as no 724 single operator has a footprint everywhere. Cross-domain 725 orchestration of services over multiple administrations or over 726 multi-domain single administrations will allow end-to-end network and 727 service elements to mix in multi-vendor, heterogeneous technology and 728 resource environments. 730 For the specific use case of 'Network as a Service', it becomes even 731 more important to ensure, that Cross Domain Orchestration also takes 732 care of hierarchy of networks and their association, with respect to 733 provisioning tunnels and overlays. 735 Multi-domain orchestration is currently an active research topic, 736 which is being tackled, among others, by ETSI NFV ISG and the 5GEx 737 project. 739 4.5. Network Slicing 741 From the beginning of all 5G discussions in the research and industry 742 fora, it has been agreed that 5G will have to address much more use 743 cases than the preceding wireless generations, which first focused on 744 voice services, and then on voice and high speed packet data 745 services. In this case, 5G should be able to handle not only the 746 same (or enhanced) voice and packet data services, but also new 747 emerging services like tactile Internet and IoT. These use cases 748 take the requirements to opposite extremes, as some of them require 749 ultra-low latency and higher-speed, whereas some others require 750 ultra-low power consumption and high delay tolerance. 752 Because of these very extreme 5G use cases, it is envisioned that 753 different radio access networks are needed to better address the 754 specific requirements of each one of the use cases. However, on the 755 core network side, virtualization techniques can allow tailoring the 756 network resources on separate slices, specifically for each radio 757 access network and use case, in an efficient manner. 759 Network slicing techniques can also allow dedicating resources for 760 even more specific use cases within the major 5G categories. For 761 example, within the major IoT category, which is perhaps the most 762 disrupting one, some autonomous IoT devices will have very low 763 throughput, will have much longer sleep cycles (and therefore high 764 latency), and a battery life thousands of times longer compared to 765 smart phones or some other connected IoT devices that will have 766 almost continuous control and data communications. Hence, it is 767 envisioned that a single virtual core network could be used by 768 slicing separate resources to dedicated radio access networks (RANs) 769 that are better suited for specific use cases. 771 Network slicing is also a key for introducing new actors in existing 772 market at low cost -- by letting new players rent "blocks" of 773 capacity, if this new market provides performance that are adequate 774 with the application needs (e.g., broadcasting updates to many 775 sensors with satellite broadcasting capabilities). 777 4.6. Service Composition 779 Current network services deployed by operators often involve the 780 composition of several individual functions (such as packet 781 filtering, deep packet inspection, load balancing). These services 782 are typically implemented by the ordered combination of a number of 783 service functions that are deployed at different points within a 784 network, not necessary on the direct data path. This requires 785 traffic to be steered through the required service functions, 786 wherever they are deployed. 788 For a given service, the abstracted view of the required service 789 functions and the order in which they are to be applied is called a 790 Service Function Chain (SFC), which is called Network Function 791 Forwarding Graph (NF-FG) in ETSI. An SFC is instantiated through 792 selection of specific service function instances on specific network 793 nodes to form a service graph: this is called a Service Function Path 794 (SFP). The service functions may be applied at any layer within the 795 network protocol stack (network layer, transport layer, application 796 layer, etc.). 798 Service composition is a powerful tool which can provide significant 799 benefits when applied in a softwarized network environment. There 800 are however many research challenges in this area, as for example the 801 ones related to composition mechanisms and algorithms to enable load 802 balancing and improve reliability. The service composition should 803 also act as an enabler to gather information across all hierarchies 804 (underlays and overlays) of network deployments which may span across 805 multiple operators, for faster serviceablity thus facilitating in 806 accomplishing aforementioned goals of "load balancing and improve 807 reliability". 809 The SFC working group is working on an architecture for service 810 function chaining that includes the necessary protocols or protocol 811 extensions to convey the Service Function Chain and Service Function 812 Path information to nodes that are involved in the implementation of 813 service functions and Service Function Chains, as well as mechanisms 814 for steering traffic through service functions. 816 In terms of actual work items, the SFC WG is has not yet considered 817 working on the management and configuration of SFC components related 818 to the support of Service Function Chaining. This part is of special 819 interest for operators and would be required in order to actually put 820 SFC mechanisms into operation. Similarly, redundancy and reliability 821 mechanisms are currently not dealt with by any WG in the IETF. While 822 this was the main goal of the VNFpool BoF efforts, it still remains 823 un-addressed. 825 4.7. End-user device virtualization 827 So far, most of the network softwarization efforts have focused on 828 virtualizing functions of network elements. While virtualization of 829 network elements started with the core, mobile networks architectures 830 are now heavily switching to also virtualize radio access network 831 (RAN) functions. The next natural step is to get virtualization down 832 at the level of the end-user device (i.e., virtualizing a 833 smartphone). The cloning of a device in the cloud (central or local) 834 bears attractive benefits to both the device and network operations 835 alike (e.g., power saving at the device by offloading computational- 836 heaving functions to the cloud, optimized networking -- both device- 837 to-device and device-to-infrastructure) for service delivery through 838 tighter integration of the device (via its clone in the networking 839 infrastructure). This is being explored for example by the European 840 H2020 ICIRRUS project (www.icirrus-5gnet.eu). 842 4.8. Security and Privacy 844 Similar to any other situation where resources are shared, security 845 and privacy are two important aspects that need to be taken into 846 account. 848 In the case of security, there are situations where multiple vendors 849 will need to coexist in a virtual or hybrid physical/virtual 850 environment. This requires attestation procedures amongst different 851 virtual/physical functions and resources, as well as ongoing external 852 monitoring. Similarly, different network slices operating on the 853 same infrastructure can present security problems, for instance if 854 one slice running critical applications (e.g. support for a safety 855 system) is affected by another slice running a less critical 856 application. In general, the minimum common denominator for security 857 measures on a shared system should be equal or higher than the one 858 required by the most critical application. Multiple and continuous 859 threat model analysis, as well as DevOps model are required to 860 maintain certain level of security in an NFV system. 862 On the other hand, privacy in its strictest interpretation, refers to 863 concerns about exposing users of the system to individual threats 864 such as surveillance, identification, stored data compromise, 865 secondary use, intrusion, etc. In this case, the storage, 866 transmission, collection, and potential correlation of information in 867 the NFV system, for purposes not originally intended or not known by 868 the user, should be avoided. This is particularly challenging, as 869 future intentions and threats cannot be easily predicted, and still 870 can be applied for instance on data collected in the past. 871 Therefore, well-known techniques such as data minimization, using 872 privacy features as default, and allowing users to opt in/out should 873 be used to prevent potential privacy issues. 875 Compared to traditional networks, NFV will result in networks that 876 are much more dynamic (in function distribution and topology) and 877 elastic (in size and boundaries). NFV will thus require network 878 operators to evolve their operational and administrative security 879 solutions to work in this new environment. For example, in NFV the 880 network orchestrator will become a key node to provide security 881 policy orchestration across the different physical and virtual 882 components of the virtualized network. For highly confidental data, 883 for example, the network orchestrator should take into account if 884 certain physical HW of the network is considered more secure (e.g., 885 because it is located in secure premises) than other HW. 887 Traditional telecom networks typically run under a single 888 administrative domain controlled by an operator. With NFV, it is 889 expected that in many cases, the telecom operator will now become a 890 tenant (running the VNFs), and the infrastructure (NFVI) may be run 891 by a different operator and/or cloud service provider (see also 892 Section 4.4). Thus, there will be multiple administrative domains 893 which will make coordination of security policy more complex. For 894 example, who will be in charge of provisioning and maintaing security 895 credentials such as public and private keys? Also, should private 896 keys be allowed to be replicated across the NFV for redundancy 897 reasons? 899 On a positive note, NFV will allow better defense against Denial of 900 Service (DoS) attacks because of the distributed nature of the 901 network (i.e. no single point of failure) and the ability to steer 902 (undesirable) traffic quickly. Also, NFVs which have physical HW 903 which is distributed across multiple data centers will also provide 904 better fault isolation environments. Especially, if each data center 905 is protected separately via fire walls, DMZs and other network 906 protection techniques. 908 5. Summary of Gaps 910 Table 1 correlates the open network virtualization research areas to 911 potential IETF/IRTF WGs and new activities that could address these 912 gaps. 914 +------------------------------+------------------------------------+ 915 | Open Research Area | Potential IETF/IRTF Gap | 916 +------------------------------+------------------------------------+ 917 | 1-Guaranteeing QoS | IPPM WG (Measurements for NFV) | 918 | 2-Performance improvement | WG-x | 919 | 3-Multiple Domains | WG-x | 920 | 4-Network Slicing | NVO3 (Traffic isolation) | 921 | 5-Service Composition | SFC WG (Mgmt and configuration) | 922 | 6-Orchestration | WG-x | 923 | 7-Self Management | WG-x | 924 | 8-Robustness and Reliability | VNFPool BoF (Redundancy and | 925 | | reliability) | 926 | 9-End-user device | WG-x | 927 | virtualization | | 928 | 10-Security | WG-x | 929 +------------------------------+------------------------------------+ 931 Table 1: Mapping of Open Research Areas to Potential IETF/IRTF Gaps 933 6. IANA Considerations 935 N/A. 937 7. Security Considerations 939 This is an informational document, which therefore does not introduce 940 any securiy threat. Research challenges and gaps related to security 941 and privacy have been included in Section 4.8. 943 8. Acknowledgments 945 The authors want to thank Dirk von Hugo, Rafa Marin, Diego Lopez, 946 Ramki Krishnan, Kostas Pentikousis, Rana Pratap Sircar, Alfred 947 Morton, Nicolas Kuhn and Saumya Dikshit for their very useful reviews 948 and comments to the document. 950 The work of Carlos J. Bernardos and Luis M. Contreras is partially 951 supported by the H2020-ICT-2014 project 5GEx (Grant Agreement no. 952 671636). 954 The work of Pedro Aranda is supported by the European FP7 Project 955 Trilogy2 under grant agreement 317756. 957 9. Informative References 959 [etsi_nvf_whitepaper] 960 "Network Functions Virtualisation (NFV). White Paper 2", 961 October 2014. 963 [I-D.bagnulo-nfvrg-topology] 964 Bagnulo, M. and D. Dolson, "NFVI PoP Network Topology: 965 Problem Statement", draft-bagnulo-nfvrg-topology-01 (work 966 in progress), March 2016. 968 [I-D.matsushima-stateless-uplane-vepc] 969 Matsushima, S. and R. Wakikawa, "Stateless user-plane 970 architecture for virtualized EPC (vEPC)", draft- 971 matsushima-stateless-uplane-vepc-06 (work in progress), 972 March 2016. 974 [I-D.natarajan-nfvrg-containers-for-nfv] 975 natarajan.sriram@gmail.com, n., Krishnan, R., Ghanwani, 976 A., Krishnaswamy, D., Willis, P., Chaudhary, A., and F. 977 Huici, "An Analysis of Lightweight Virtualization 978 Technologies for NFV", draft-natarajan-nfvrg-containers- 979 for-nfv-03 (work in progress), July 2016. 981 [ngmn_5G_whitepaper] 982 "NGMN 5G. White Paper", February 2015. 984 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 985 Application Protocol (CoAP)", RFC 7252, 986 DOI 10.17487/RFC7252, June 2014, 987 . 989 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 990 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 991 Defined Networking (SDN): Layers and Architecture 992 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 993 2015, . 995 Authors' Addresses 996 Carlos J. Bernardos 997 Universidad Carlos III de Madrid 998 Av. Universidad, 30 999 Leganes, Madrid 28911 1000 Spain 1002 Phone: +34 91624 6236 1003 Email: cjbc@it.uc3m.es 1004 URI: http://www.it.uc3m.es/cjbc/ 1006 Akbar Rahman 1007 InterDigital Communications, LLC 1008 1000 Sherbrooke Street West, 10th floor 1009 Montreal, Quebec H3A 3G4 1010 Canada 1012 Email: Akbar.Rahman@InterDigital.com 1013 URI: http://www.InterDigital.com/ 1015 Juan Carlos Zuniga 1016 SIGFOX 1017 425 rue Jean Rostand 1018 Labege 31670 1019 France 1021 Email: j.c.zuniga@ieee.org 1022 URI: http://www.sigfox.com/ 1024 Luis M. Contreras 1025 Telefonica I+D 1026 Ronda de la Comunicacion, S/N 1027 Madrid 28050 1028 Spain 1030 Email: luismiguel.contrerasmurillo@telefonica.com 1032 Pedro Aranda 1033 Telefonica I+D 1034 Ronda de la Comunicacion, S/N 1035 Madrid 28050 1036 Spain 1038 Email: pedroa.aranda@telefonica.com