idnits 2.17.1 draft-irtf-nfvrg-gaps-network-virtualization-01.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 (July 8, 2016) is 2820 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-natarajan-nfvrg-containers-for-nfv-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: January 9, 2017 InterDigital 6 JC. Zuniga 7 SIGFOX 8 LM. Contreras 9 P. Aranda 10 TID 11 July 8, 2016 13 Gap Analysis on Network Virtualization Activities 14 draft-irtf-nfvrg-gaps-network-virtualization-01 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 service guarantees, energy efficiency, supporting multiple 32 domains, network slicing, self-management, privacy and security. In 33 addition, some proposals are made for new activities in IETF/IRTF 34 that could address some of these challenges. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 9, 2017. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.1. Network Function Virtualization . . . . . . . . . . . . . 5 74 3.2. Software Defined Networking . . . . . . . . . . . . . . . 7 75 3.3. Mobile Edge Computing . . . . . . . . . . . . . . . . . . 11 76 3.4. IEEE 802.1CF (OmniRAN) . . . . . . . . . . . . . . . . . 12 77 3.5. Distributed Management Task Force . . . . . . . . . . . . 12 78 3.6. Open Source initiatives . . . . . . . . . . . . . . . . . 12 79 3.7. Internet of Things (IoT) . . . . . . . . . . . . . . . . 14 80 4. Network Virtualization Challenges . . . . . . . . . . . . . . 14 81 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 14 82 4.2. Service Guarantees . . . . . . . . . . . . . . . . . . . 15 83 4.3. Energy Efficiency . . . . . . . . . . . . . . . . . . . . 16 84 4.4. Multiple Domains . . . . . . . . . . . . . . . . . . . . 16 85 4.5. Network Slicing . . . . . . . . . . . . . . . . . . . . . 16 86 4.6. Service Composition . . . . . . . . . . . . . . . . . . . 17 87 4.7. Orchestration . . . . . . . . . . . . . . . . . . . . . . 18 88 4.8. Self Management . . . . . . . . . . . . . . . . . . . . . 18 89 4.9. Robustness . . . . . . . . . . . . . . . . . . . . . . . 18 90 4.10. Security and Privacy . . . . . . . . . . . . . . . . . . 18 91 5. Summary of Gaps . . . . . . . . . . . . . . . . . . . . . . . 19 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 94 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 95 9. Informative References . . . . . . . . . . . . . . . . . . . 20 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 98 1. Introduction 100 The telecommunications sector is experiencing a major revolution that 101 will shape the way networks and services are designed and deployed 102 for the next decade. We are witnessing an explosion in the number of 103 applications and services demanded by users, which are now really 104 capable of accessing them on the move. In order to cope with such a 105 demand, some network operators are looking at the cloud computing 106 paradigm, which enables a potential reduction of the overall costs by 107 outsourcing communication services from specific hardware in the 108 operator's core to server farms scattered in datacenters. These 109 services have different characteristics if compared with conventional 110 IT services that have to be taken into account in this cloudification 111 process. Also the transport network is affected in that it is 112 evolving to a more sophisticated form of IP architecture with trends 113 like separation of control and data plane traffic, and more fine- 114 grained forwarding of packets (beyond looking at the destination IP 115 address) in the network to fulfill new business and service goals. 117 Virtualization of functions also provides operators with tools to 118 deploy new services much faster, as compared to the traditional use 119 of monolithic and tightly integrated dedicated machinery. As a 120 natural next step, mobile network operators need to re-think how to 121 evolve their existing network infrastructures and how to deploy new 122 ones to address the challenges posed by the increasing customers' 123 demands, as well as by the huge competition among operators. All 124 these changes are triggering the need for a modification in the way 125 operators and infrastructure providers operate their networks, as 126 they need to significantly reduce the costs incurred in deploying a 127 new service and operating it. Some of the mechanisms that are being 128 considered and already adopted by operators include: sharing of 129 network infrastructure to reduce costs, virtualization of core 130 servers running in data centers as a way of supporting their load- 131 aware elastic dimensioning, and dynamic energy policies to reduce the 132 monthly electricity bill. However, this has proved to be tough to 133 put in practice, and not enough. Indeed, it is not easy to deploy 134 new mechanisms in a running operational network due to the high 135 dependency on proprietary (and sometime obscure) protocols and 136 interfaces, which are complex to manage and often require configuring 137 multiple devices in a decentralized way. 139 Network Function Virtualization (NFV) and Software Defined Networking 140 (SDN) are changing the way the telecommunications sector will deploy, 141 extend and operate their networks. This document describes current 142 research challenges in network virtualization and correlates them to 143 activities currently occurring in the key standards forums and open 144 source efforts. Based on this analysis, we also go a step farther, 145 identifying which are the potential work areas where IETF/IRTF can 146 work on to complement the complex network virtualization map of 147 technologies being standardized today. 149 2. Terminology 151 The following terms used in this document are defined by the ETSI NVF 152 ISG, the ONF and the IETF: 154 Application Plane - The collection of applications and services 155 that program network behavior. 157 Control Plane (CP) - The collection of functions responsible for 158 controlling one or more network devices. CP instructs network 159 devices with respect to how to process and forward packets. The 160 control plane interacts primarily with the forwarding plane and, 161 to a lesser extent, with the operational plane. 163 Forwarding Plane (FP) - The collection of resources across all 164 network devices responsible for forwarding traffic. 166 Management Plane (MP) - The collection of functions responsible 167 for monitoring, configuring, and maintaining one or more network 168 devices or parts of network devices. The management plane is 169 mostly related to the operational plane (it is related less to the 170 forwarding plane). 172 NFV Infrastructure (NFVI): totality of all hardware and software 173 components which build up the environment in which VNFs are 174 deployed 176 NFV Management and Orchestration (NFV-MANO): functions 177 collectively provided by NFVO, VNFM, and VIM. 179 NFV Orchestrator (NFVO): functional block that manages the Network 180 Service (NS) lifecycle and coordinates the management of NS 181 lifecycle, VNF lifecycle (supported by the VNFM) and NFVI 182 resources (supported by the VIM) to ensure an optimized allocation 183 of the necessary resources and connectivity. 185 OpenFlow protocol (OFP): allowing vendor independent programming 186 of control functions in network nodes. 188 Operational Plane (OP) - The collection of resources responsible 189 for managing the overall operation of individual network devices. 191 Service Function Chain (SFC): for a given service, the abstracted 192 view of the required service functions and the order in which they 193 are to be applied. This is somehow equivalent to the Network 194 Function Forwarding Graph (NF-FG) at ETSI. 196 Service Function Path (SFP): the selection of specific service 197 function instances on specific network nodes to form a service 198 graph through which an SFC is instantiated. 200 virtual EPC (vEPC): control plane of 3GPPs EPC operated on NFV 201 framework (as defined by [I-D.matsushima-stateless-uplane-vepc]). 203 Virtualized Infrastructure Manager (VIM): functional block that is 204 responsible for controlling and managing the NFVI compute, storage 205 and network resources, usually within one operator's 206 Infrastructure Domain. 208 Virtualized Network Function (VNF): implementation of a Network 209 Function that can be deployed on a Network Function Virtualisation 210 Infrastructure (NFVI). 212 Virtualized Network Function Manager (VNFM): functional block that 213 is responsible for the lifecycle management of VNF. 215 3. Background 217 3.1. Network Function Virtualization 219 The ETSI ISG NFV is a working group which, since 2012, aims to evolve 220 quasi-standard IT virtualization technology to consolidate many 221 network equipment types into industry standard high volume servers, 222 switches, and storage. It enables implementing network functions in 223 software that can run on a range of industry standard server hardware 224 and can be moved to, or loaded in, various locations in the network 225 as required, without the need to install new equipment. To date, 226 ETSI NFV is by far the most accepted NFV reference framework and 227 architectural footprint [etsi_nvf_whitepaper]. The ETSI NFV 228 framework architecture framework is composed of three domains 229 (Figure 1): 231 o Virtualized Network Function, running over the NFVI. 233 o NFV Infrastructure (NFVI), including the diversity of physical 234 resources and how these can be virtualized. NFVI supports the 235 execution of the VNFs. 237 o NFV Management and Orchestration, which covers the orchestration 238 and life-cycle management of physical and/or software resources 239 that support the infrastructure virtualization, and the life-cycle 240 management of VNFs. NFV Management and Orchestration focuses on 241 all virtualization specific management tasks necessary in the NFV 242 framework. 244 +-------------------------------------------+ +---------------+ 245 | Virtualized Network Functions (VNFs) | | | 246 | ------- ------- ------- ------- | | | 247 | | | | | | | | | | | | 248 | | VNF | | VNF | | VNF | | VNF | | | | 249 | | | | | | | | | | | | 250 | ------- ------- ------- ------- | | | 251 +-------------------------------------------+ | | 252 | | 253 +-------------------------------------------+ | | 254 | NFV Infrastructure (NFVI) | | NFV | 255 | ----------- ----------- ----------- | | Management | 256 | | Virtual | | Virtual | | Virtual | | | and | 257 | | Compute | | Storage | | Network | | | Orchestration | 258 | ----------- ----------- ----------- | | | 259 | +---------------------------------------+ | | | 260 | | Virtualization Layer | | | | 261 | +---------------------------------------+ | | | 262 | +---------------------------------------+ | | | 263 | | ----------- ----------- ----------- | | | | 264 | | | Compute | | Storage | | Network | | | | | 265 | | ----------- ----------- ----------- | | | | 266 | | Hardware resources | | | | 267 | +---------------------------------------+ | | | 268 +-------------------------------------------+ +---------------+ 270 Figure 1: ETSI NFV framework 272 The NFV architectural framework identifies functional blocks and the 273 main reference points between such blocks. Some of these are already 274 present in current deployments, whilst others might be necessary 275 additions in order to support the virtualization process and 276 consequent operation. The functional blocks are (Figure 2): 278 o Virtualized Network Function (VNF). 280 o Element Management (EM). 282 o NFV Infrastructure, including: Hardware and virtualized resources, 283 and Virtualization Layer. 285 o Virtualized Infrastructure Manager(s) (VIM). 287 o NFV Orchestrator. 289 o VNF Manager(s). 291 o Service, VNF and Infrastructure Description. 293 o Operations and Business Support Systems (OSS/BSS). 295 +--------------------+ 296 +-------------------------------------------+ | ---------------- | 297 | OSS/BSS | | | NFV | | 298 +-------------------------------------------+ | | Orchestrator +-- | 299 | ---+------------ | | 300 +-------------------------------------------+ | | | | 301 | --------- --------- --------- | | | | | 302 | | EM 1 | | EM 2 | | EM 3 | | | | | | 303 | ----+---- ----+---- ----+---- | | ---+---------- | | 304 | | | | |--|-| VNF | | | 305 | ----+---- ----+---- ----+---- | | | manager(s) | | | 306 | | VNF 1 | | VNF 2 | | VNF 3 | | | ---+---------- | | 307 | ----+---- ----+---- ----+---- | | | | | 308 +------|-------------|-------------|--------+ | | | | 309 | | | | | | | 310 +------+-------------+-------------+--------+ | | | | 311 | NFV Infrastructure (NFVI) | | | | | 312 | ----------- ----------- ----------- | | | | | 313 | | Virtual | | Virtual | | Virtual | | | | | | 314 | | Compute | | Storage | | Network | | | | | | 315 | ----------- ----------- ----------- | | ---+------ | | 316 | +---------------------------------------+ | | | | | | 317 | | Virtualization Layer | |--|-| VIM(s) +-------- | 318 | +---------------------------------------+ | | | | | 319 | +---------------------------------------+ | | ---------- | 320 | | ----------- ----------- ----------- | | | | 321 | | | Compute | | Storage | | Network | | | | | 322 | | | hardware| | hardware| | hardware| | | | | 323 | | ----------- ----------- ----------- | | | | 324 | | Hardware resources | | | NFV Management | 325 | +---------------------------------------+ | | and Orchestration | 326 +-------------------------------------------+ +--------------------+ 328 Figure 2: ETSI NFV reference architecture 330 3.2. Software Defined Networking 332 The Software Defined Networking (SDN) paradigm pushes the 333 intelligence currently residing in the network elements to a central 334 controller implementing the network functionality through software. 336 In contrast to traditional approaches, in which the network's control 337 plane is distributed throughout all network devices, with SDN the 338 control plane is logically centralized. In this way, the deployment 339 of new characteristics in the network no longer requires of complex 340 and costly changes in equipment or firmware updates, but only a 341 change in the software running in the controller. The main advantage 342 of this approach is the flexibility it provides operators with to 343 manage their network, i.e., an operator can easily change its 344 policies on how traffic is distributed throughout the network. 346 The most visible of the SDN protocol stacks is the OpenFlow protocol 347 (OFP), which is maintained and extended by the Open Network 348 Foundation (ONF: https://www.opennetworking.org/). Originally this 349 protocol was developed specifically for IEEE 802.1 switches 350 conforming to the ONF OpenFlow Switch specification. As the benefits 351 of the SDN paradigm have reached a wider audience, its application 352 has been extended to more complex scenarios such as Wireless and 353 Mobile networks. Within this area of work, the ONF is actively 354 developing new OFP extensions addressing three key scenarios: (i) 355 Wireless backhaul, (ii) Cellular Evolved Packet Core (EPC), and (iii) 356 Unified access and management across enterprise wireless and fixed 357 networks. 359 +----------+ 360 | ------- | 361 | |Oper.| | O 362 | |Mgmt.| |<........> -+- Network Operator 363 | |Iface| | ^ 364 | ------- | +----------------------------------------+ 365 | | | +------------------------------------+ | 366 | | | | --------- --------- --------- | | 367 |--------- | | | | App 1 | | App 2 | ... | App n | | | 368 ||Plugins| |<....>| | --------- --------- --------- | | 369 |--------- | | | Plugins | | 370 | | | +------------------------------------+ | 371 | | | Application Plane | 372 | | +----------------------------------------+ 373 | | A 374 | | | 375 | | V 376 | | +----------------------------------------+ 377 | | | +------------------------------------+ | 378 |--------- | | | ------------ ------------ | | 379 || Netw. | | | | | Module 1 | | Module 2 | | | 380 ||Engine | |<....>| | ------------ ------------ | | 381 |--------- | | | Network Engine | | 382 | | | +------------------------------------+ | 383 | | | Controller Plane | 384 | | +----------------------------------------+ 385 | | A 386 | | | 387 | | V 388 | | +----------------------------------------+ 389 | | | +--------------+ +--------------+ | 390 | | | | ------------ | | ------------ | | 391 |----------| | | | OpenFlow | | | | OpenFlow | | | 392 ||OpenFlow||<....>| | ------------ | | ------------ | | 393 |----------| | | NE | | NE | | 394 | | | +--------------+ +--------------+ | 395 | | | Data Plane | 396 |Management| +----------------------------------------+ 397 +----------+ 399 Figure 3: High level SDN ONF architecture 401 Figure 3 shows the blocks and the functional interfaces of the ONF 402 architecture, which comprises three planes: Data, Controller, and 403 Application. The Data plane comprehends several Network Entities 404 (NE), which expose their capabilities toward the Controller plane via 405 a Southbound API. The Controller plane includes several cooperating 406 modules devoted to the creation and maintenance of an abstracted 407 resource model of the underneath network. Such model is exposed to 408 the applications via a Northbound API where the Application plane 409 comprises several applications/services, each of which has exclusive 410 control of a set of exposed resources. 412 The Management plane spans its functionality across all planes 413 performing the initial configuration of the network elements in the 414 Data plane, the assignment of the SDN controller and the resources 415 under its responsibility. In the Controller plane, the Management 416 needs to configure the policies defining the scope of the control 417 given to the SDN applications, to monitor the performance of the 418 system, and to configure the parameters required by the SDN 419 controller modules. In the Application plane, Management configures 420 the parameters of the applications and the service level agreements. 421 In addition to the these interactions, the Management plane exposes 422 several functions to network operators which can easily and quickly 423 configure and tune the network at each layer. 425 The SDNRG has documented a reference layer model in RFC7426 426 [RFC7426], which is reproduced in Figure 4. This model structures 427 SDN in planes and layers which are glued together by different 428 abstraction layers. This architecture differentiates between the 429 control and the management planes and provides for differentiated 430 southbound interfaces (SBIs). 432 o--------------------------------o 433 | | 434 | +-------------+ +----------+ | 435 | | Application | | Service | | 436 | +-------------+ +----------+ | 437 | Application Plane | 438 o---------------Y----------------o 439 | 440 *-----------------------------Y---------------------------------* 441 | Network Services Abstraction Layer (NSAL) | 442 *------Y------------------------------------------------Y-------* 443 | | 444 | Service Interface | 445 | | 446 o------Y------------------o o---------------------Y------o 447 | | Control Plane | | Management Plane | | 448 | +----Y----+ +-----+ | | +-----+ +----Y----+ | 449 | | Service | | App | | | | App | | Service | | 450 | +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ | 451 | | | | | | | | 452 | *----Y-----------Y----* | | *---Y---------------Y----* | 453 | | Control Abstraction | | | | Management Abstraction | | 454 | | Layer (CAL) | | | | Layer (MAL) | | 455 | *----------Y----------* | | *----------Y-------------* | 456 | | | | | | 457 o------------|------------o o------------|---------------o 458 | | 459 | CP | MP 460 | Southbound | Southbound 461 | Interface | Interface 462 | | 463 *------------Y---------------------------------Y----------------* 464 | Device and resource Abstraction Layer (DAL) | 465 *------------Y---------------------------------Y----------------* 466 | | | | 467 | o-------Y----------o +-----+ o--------Y----------o | 468 | | Forwarding Plane | | App | | Operational Plane | | 469 | o------------------o +-----+ o-------------------o | 470 | Network Device | 471 +---------------------------------------------------------------+ 473 Figure 4: SDN Layer Architecture 475 3.3. Mobile Edge Computing 477 Mobile Edge Computing capabilities deployed in the edge of the mobile 478 network can facilitate the efficient and dynamic provision of 479 services to mobile users. The ETSI ISG MEC working group, operative 480 from end of 2014, intends to specify an open environment for 481 integrating MEC capabilities with service providers networks, 482 including also applications from 3rd parties. These distributed 483 computing capabilities will make available IT infrastructure as in a 484 cloud environment for the deployment of functions in mobile access 485 networks. It can be seen then as a complement to both NFV and SDN. 487 3.4. IEEE 802.1CF (OmniRAN) 489 The IEEE 802.1CF Recommended Practice specifies an access network, 490 which connects terminals to their access routers, utilizing 491 technologies based on the family of IEEE 802 Standards (e.g., 802.3 492 Ethernet, 802.11 Wi-Fi, etc.). The specification defines an access 493 network reference model, including entities and reference points 494 along with behavioral and functional descriptions of communications 495 among those entities. 497 The goal of this project is to help unifying the support of different 498 interfaces, enabling shared network control and use of software 499 defined network (SDN) principles, thereby lowering the barriers to 500 new network technologies, to new network operators, and to new 501 service providers. 503 3.5. Distributed Management Task Force 505 The DMTF is an industry standards organization working to simplify 506 the manageability of network-accessible technologies through open and 507 collaborative efforts by some technology companies. The DMTF is 508 involved in the creation and adoption of interoperable management 509 standards, supporting implementations that enable the management of 510 diverse traditional and emerging technologies including cloud, 511 virtualization, network and infrastructure. 513 There are several DMTF initiatives that are relevant to the network 514 virtualization area, such as the Open Virtualization Format (OVF), 515 for VNF packaging; the Cloud Infrastructure Management Interface 516 (CIM), for cloud infrastructure management; the Network Management 517 (NETMAN), for VNF management; and, the Virtualization Management 518 (VMAN), for virtualization infrastructure management. 520 3.6. Open Source initiatives 522 The Open Source community is especially active in the area of network 523 virtualization. We next summarize some of the active efforts: 525 o OpenStack. OpenStack is a free and open-source cloud-computing 526 software platform. OpenStack software controls large pools of 527 compute, storage, and networking resources throughout a 528 datacenter, managed through a dashboard or via the OpenStack API. 530 o OpenDayLight. OpenDaylight (ODL) is a highly available, modular, 531 extensible, scalable and multi-protocol controller infrastructure 532 built for SDN deployments on modern heterogeneous multi-vendor 533 networks. It provides a model-driven service abstraction platform 534 that allows users to write apps that easily work across a wide 535 variety of hardware and southbound protocols. 537 o ONOS. The ONOS (Open Network Operating System) project is an open 538 source community hosted by The Linux Foundation. The goal of the 539 project is to create a software-defined networking (SDN) operating 540 system for communications service providers that is designed for 541 scalability, high performance and high availability. 543 o OpenContrail. OpenContrail is an Apache 2.0-licensed project that 544 is built using standards-based protocols and provides all the 545 necessary components for network virtualization-SDN controller, 546 virtual router, analytics engine, and published northbound APIs. 547 It has an extensive REST API to configure and gather operational 548 and analytics data from the system. 550 o OPNFV. OPNFV is a carrier-grade, integrated, open source platform 551 to accelerate the introduction of new NFV products and services. 552 By integrating components from upstream projects, the OPNFV 553 community aims at conducting performance and use case-based 554 testing to ensure the platform's suitability for NFV use cases. 555 The scope of OPNFV's initial release is focused on building NFV 556 Infrastructure (NFVI) and Virtualized Infrastructure Management 557 (VIM) by integrating components from upstream projects such as 558 OpenDaylight, OpenStack, Ceph Storage, KVM, Open vSwitch, and 559 Linux. These components, along with application programmable 560 interfaces (APIs) to other NFV elements form the basic 561 infrastructure required for Virtualized Network Functions (VNF) 562 and Management and Network Orchestration (MANO) components. 563 OPNFV's goal is to increase performance and power efficiency; 564 improve reliability, availability, and serviceability; and deliver 565 comprehensive platform instrumentation. 567 o OSM. Open Source Mano (OSM) is an ETSI-hosted project to develop 568 an Open Source NFV Management and Orchestration (MANO) software 569 stack aligned with ETSI NFV. OSM is based on components from 570 previous projects, such Telefonica's OpenMANO or Canonical's Juju, 571 among others. 573 o OpenBaton. OpenBaton is a ETSI NFV compliant Network Function 574 Virtualization Orchestrator (NFVO). OpenBaton was part of the 575 OpenSDNCore project started with the objective of providing a 576 compliant implementation of the ETSI NFV specification. 578 Among the main areas that are being developed by the former open 579 source activities that related to network virtualization research, we 580 can highlight: policy-based resource management, analytics for 581 visibility and orchestration, service verification with regards to 582 security and resiliency. 584 3.7. Internet of Things (IoT) 586 The Internet of Things (IoT) refers to the vision of connecting a 587 multitude of automated devices (e.g. lights, environmental sensors, 588 traffic lights, parking meters, health and security systems, etc.) to 589 the Internet for purposes of reporting, and remote command and 590 control of the device. This vision is being realized by a multi- 591 pronged approach of standardization in various forums and 592 complementary open source activities. For example, in IETF, support 593 of IoT web services has been defined by an HTTP-like protocol adapted 594 for IoT called CoAP [RFC7252], and lately a group has been studying 595 the need to develop a new network layer to support IP applications 596 over Low Power Wide Area Networks (LPWAN). 598 Elsewhere, for 5G cellular evolution there is much discussion on the 599 need for supporting virtual "network slices" for the expected massive 600 numbers of IoT devices. A separate virtual network slice is 601 considered necessary for different 5G IoT use cases because devices 602 will have very different characteristics than typical cellular 603 devices like smart phones [ngmn_5G_whitepaper], and the number of IoT 604 devices is expected to be at least one or two orders of magnitude 605 higher than other 5G devices. 607 4. Network Virtualization Challenges 609 4.1. Introduction 611 Network Virtualization is changing the way the telecommunications 612 sector will deploy, extend and operate their networks. These new 613 technologies aim at reducing the overall costs by outsourcing 614 communication services from specific hardware in the operators' core 615 to server farms scattered in datacenters (i.e. compute and storage 616 virtualization). In addition, the connecting networks are 617 fundamentally affected in the way they route, process and control 618 traffic (i.e. network virtualization). 620 4.2. Service Guarantees 622 Providing service guarantees in an NFV environment is not an easy 623 task. We next identify some of the challenges that this poses. 625 An important difference between NFV and traditional Cloud computing 626 comes from the very strict requirements posed by NFV in terms of 627 performance, stability and consistency. Although there are some 628 tools and mechanisms to improve this, such as Enhanced Performance 629 Awareness (EPA), SR-IOV, NUMA, DPDK, etc, these are still unsolved 630 challenges. [I-D.natarajan-nfvrg-containers-for-nfv] analyzes 631 different virtualization technologies that could be used, instead of 632 just using VMs. 634 Another relevant aspect is the need for tools for diagnostics and 635 measurement suited for NFV. There is a pressing need to define 636 metrics and associated protocols to measure the performance of NFV. 637 Specifically, since NFV is based on the concept of taking centralized 638 functions and evolving it to highly distributed SW functions, there 639 is a commensurate need to fully understand and measure the baseline 640 performance of such systems. 642 The IP Performance Metrics (IPPM) WG defines metrics that can be used 643 to measure the quality and performance of Internet services and 644 applications running over transport layer protocols (e.g. TCP, UPD) 645 over IP. It also develops and maintains protocols for the 646 measurement of these metrics. While the IPPM WG is a long running WG 647 that started in 1997 it does not have a charter item or active drafts 648 related to the topic of network virtualization. 650 Related to the need of diagnostics tools, there is also a need in 651 terms of predictive analysis allowing for reaction before an 652 operation anomaly takes place. Due to the SW characteristics of 653 VNFs, a reliable diagnosis framework could potentially enable the 654 prevention of issues by a proper diagnosis and then a reaction in 655 terms of acting on the potentially impacted service (e.g., migration 656 to a different compute node, scaling in/out, up/down, etc). 658 Portability is also a key feature that, if fully enabled, would 659 contribute to making the NFV environment achieve a better reliability 660 than a traditional system. The fact of running functionality in SW 661 over "commodity" infrastructure should make much easier to port/move 662 functions from one place to another. However this is not yet as 663 ideal as it sounds and there are aspects not fully tackled. The 664 existence of different hypervisors, specific hardware dependencies 665 (e.g., EPA related) or state synchronization aspects are just some 666 examples of trouble-makers for portability purposes. 668 4.3. Energy Efficiency 670 Virtualization is typically seen as a direct enabler of energy 671 savings. Some of the enablers for this that are often mentioned are: 672 (i) the multiplexing gains achieved by centralizing functions in data 673 centers reduce overall the energy consumed, (ii) the flexibility 674 brought by network programmability enables to switch off 675 infrastructure as needed in a much easier way. However there is 676 still a lot of room for improvement in terms of virtualization 677 techniques to reduce the power consumption, such as enhanced 678 hypervisor technologies. 680 4.4. Multiple Domains 682 Market fragmentation has resulted in a multitude of network operators 683 each focused on different countries and regions. This makes it 684 difficult to create infrastructure services spanning multiple 685 countries, such as virtual connectivity or compute resources, as no 686 single operator has a footprint everywhere. Cross-domain 687 orchestration of services over multiple administrations or over 688 multi-domain single administrations will allow end-to-end network and 689 service elements to mix in multi-vendor, heterogeneous technology and 690 resource environments. 692 Multi-domain orchestration is currently an active research topic, 693 which is being tackled, among others, by ETSI NFV ISG and the 5GEx 694 project. 696 4.5. Network Slicing 698 From the beginning of all 5G discussions in the research and industry 699 fora, it has been agreed that 5G will have to address much more use 700 cases than the preceding wireless generations, which first focused on 701 voice services, and then on voice and high speed packet data 702 services. In this case, 5G should be able to handle not only the 703 same (or enhanced) voice and packet data services, but also new 704 emerging services like tactile Internet and IoT. These use cases 705 take the requirements to opposite extremes, as some of them require 706 ultra-low latency and higher-speed, whereas some others require 707 ultra-low power consumption and high delay tolerance. 709 Because of these very extreme 5G use cases, it is envisioned that 710 different radio access networks are needed to better address the 711 specific requirements of each one of the use cases. However, on the 712 core network side, virtualization techniques can allow tailoring the 713 network resources on separate slices, specifically for each radio 714 access network and use case, in an efficient manner. 716 Network slicing techniques can also allow dedicating resources for 717 even more specific use cases within the major 5G categories. For 718 example, within the major IoT category, which is perhaps the most 719 disrupting one, some autonomous IoT devices will have very low 720 throughput, will have much longer sleep cycles (and therefore high 721 latency), and a battery life thousands of times longer compared to 722 smart phones or some other connected IoT devices that will have 723 almost continuous control and data communications. Hence, it is 724 envisioned that a single virtual core network could be used by 725 slicing separate resources to dedicated radio access networks (RANs) 726 that are better suited for specific use cases. 728 4.6. Service Composition 730 Current network services deployed by operators often involve the 731 composition of several individual functions (such as packet 732 filtering, deep packet inspection, load balancing). These services 733 are typically implemented by the ordered combination of a number of 734 service functions that are deployed at different points within a 735 network, not necessary on the direct data path. This requires 736 traffic to be steered through the required service functions, 737 wherever they are deployed. 739 For a given service, the abstracted view of the required service 740 functions and the order in which they are to be applied is called a 741 Service Function Chain (SFC), which is called Network Function 742 Forwarding Graph (NF-FG) in ETSI. An SFC is instantiated through 743 selection of specific service function instances on specific network 744 nodes to form a service graph: this is called a Service Function Path 745 (SFP). The service functions may be applied at any layer within the 746 network protocol stack (network layer, transport layer, application 747 layer, etc.). 749 Service composition is a powerful tool which can provide significant 750 benefits when applied in a softwarized network environment. There 751 are however many research challenges in this area, as for example the 752 ones related to composition mechanisms and algorithms to enable load 753 balancing and improve reliability. 755 The SFC working group is working on an architecture for service 756 function chaining that includes the necessary protocols or protocol 757 extensions to convey the Service Function Chain and Service Function 758 Path information to nodes that are involved in the implementation of 759 service functions and Service Function Chains, as well as mechanisms 760 for steering traffic through service functions. 762 In terms of actual work items, the SFC WG is has not yet considered 763 working on the management and configuration of SFC components related 764 to the support of Service Function Chaining. This part is of special 765 interest for operators and would be required in order to actually put 766 SFC mechanisms into operation. Similarly, redundancy and reliability 767 mechanisms are currently not dealt with by any WG in the IETF. While 768 this was the main goal of the VNFpool BoF efforts, it still remains 769 un-addressed. 771 4.7. Orchestration 773 TBD. 775 4.8. Self Management 777 TBD. Include aspects such as: Planning, optimization, diagnostics, 778 recovery, validation. 780 4.9. Robustness 782 TBD. 784 4.10. Security and Privacy 786 Similar to any other situation where resources are shared, security 787 and privacy are two important aspects that need to be taken into 788 account. 790 In the case of security, there are situations where multiple vendors 791 will need to coexist in a virtual or hybrid physical/virtual 792 environment. This requires attestation procedures amongst different 793 virtual/physical functions and resources, as well as ongoing external 794 monitoring. Similarly, different network slices operating on the 795 same infrastructure can present security problems, for instance if 796 one slice running critical applications (e.g. support for a safety 797 system) is affected by another slice running a less critical 798 application. In general, the minimum common denominator for security 799 measures on a shared system should be equal or higher than the one 800 required by the most critical application. Multiple and continuous 801 threat model analysis, as well as DevOps model are required to 802 maintain certain level of security in an NFV system. 804 On the other hand, privacy in its strictest interpretation, refers to 805 concerns about exposing users of the system to individual threats 806 such as surveillance, identification, stored data compromise, 807 secondary use, intrusion, etc. In this case, the storage, 808 transmission, collection, and potential correlation of information in 809 the NFV system, for purposes not originally intended or not known by 810 the user, should be avoided. This is particularly challenging, as 811 future intentions and threats cannot be easily predicted, and still 812 can be applied for instance on data collected in the past. 813 Therefore, well-known techniques such as data minimization, using 814 privacy features as default, and allowing users to opt in/out should 815 be used to prevent potential privacy issues. 817 5. Summary of Gaps 819 Table 1 correlates the open network virtualization research areas to 820 potential IETF/IRTF WGs and new activities that could address these 821 gaps. 823 +----------------------------+--------------------------------------+ 824 | Open Research Area | Potential IETF/IRTF Gap | 825 +----------------------------+--------------------------------------+ 826 | 1-Service Guarantee | IPPM WG (Measurements for NFV) | 827 | 2-Energy Efficiency | WG-x | 828 | 3-Multiple Domains | WG-x | 829 | 4-Network Slicing | NVO3 (Traffic isolation) | 830 | 5-Service Composition | SFC WG (Mgmt and configuration) | 831 | 6-Orchestration | WG-x | 832 | 7-Self Management | WG-x | 833 | 8-Robustness and | VNFPool BoF (Redundancy and | 834 | Reliability | reliability) | 835 | 9-Security | WG-x | 836 +----------------------------+--------------------------------------+ 838 Table 1: Mapping of Open Research Areas to Potential IETF/IRTF Gaps 840 6. IANA Considerations 842 N/A. 844 7. Security Considerations 846 TBD. 848 8. Acknowledgments 850 The authors want to thank Dirk von Hugo, Rafa Marin, Diego Lopez, 851 Ramki Krishnan, Kostas Pentikousis, Rana Pratap Sircar and Alfred 852 Morton for their very useful reviews and comments to the document. 854 The work of Carlos J. Bernardos and Luis M. Contreras is partially 855 supported by the H2020-ICT-2014 project 5GEx (Grant Agreement no. 856 671636). 858 The work of Pedro Aranda is supported by the European FP7 Project 859 Trilogy2 under grant agreement 317756. 861 9. Informative References 863 [etsi_nvf_whitepaper] 864 "Network Functions Virtualisation (NFV). White Paper 2", 865 October 2014. 867 [I-D.matsushima-stateless-uplane-vepc] 868 Matsushima, S. and R. Wakikawa, "Stateless user-plane 869 architecture for virtualized EPC (vEPC)", draft- 870 matsushima-stateless-uplane-vepc-06 (work in progress), 871 March 2016. 873 [I-D.natarajan-nfvrg-containers-for-nfv] 874 natarajan.sriram@gmail.com, n., Krishnan, R., Ghanwani, 875 A., Krishnaswamy, D., Willis, P., Chaudhary, A., and F. 876 Huici, "An Analysis of Lightweight Virtualization 877 Technologies for NFV", draft-natarajan-nfvrg-containers- 878 for-nfv-02 (work in progress), July 2016. 880 [ngmn_5G_whitepaper] 881 "NGMN 5G. White Paper", February 2015. 883 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 884 Application Protocol (CoAP)", RFC 7252, 885 DOI 10.17487/RFC7252, June 2014, 886 . 888 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 889 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 890 Defined Networking (SDN): Layers and Architecture 891 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 892 2015, . 894 Authors' Addresses 896 Carlos J. Bernardos 897 Universidad Carlos III de Madrid 898 Av. Universidad, 30 899 Leganes, Madrid 28911 900 Spain 902 Phone: +34 91624 6236 903 Email: cjbc@it.uc3m.es 904 URI: http://www.it.uc3m.es/cjbc/ 905 Akbar Rahman 906 InterDigital Communications, LLC 907 1000 Sherbrooke Street West, 10th floor 908 Montreal, Quebec H3A 3G4 909 Canada 911 Email: Akbar.Rahman@InterDigital.com 912 URI: http://www.InterDigital.com/ 914 Juan Carlos Zuniga 915 SIGFOX 916 425 rue Jean Rostand 917 Labege 31670 918 France 920 Email: JuanCarlos.Zuniga@sigfox.com 921 URI: http://www.sigfox.com/ 923 Luis M. Contreras 924 Telefonica I+D 925 Ronda de la Comunicacion, S/N 926 Madrid 28050 927 Spain 929 Email: luismiguel.contrerasmurillo@telefonica.com 931 Pedro Aranda 932 Telefonica I+D 933 Ronda de la Comunicacion, S/N 934 Madrid 28050 935 Spain 937 Email: pedroa.aranda@telefonica.com