idnits 2.17.1 draft-bernardos-nfvrg-gaps-network-virtualization-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 6, 2015) is 3216 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-bernini-nfvrg-vnf-orchestration-00 == Outdated reference: A later version (-02) exists of draft-ceccarelli-teas-actn-framework-00 == Outdated reference: A later version (-14) exists of draft-ietf-dmm-fpc-cpdp-00 == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-09 == Outdated reference: A later version (-08) exists of draft-ietf-nvo3-arch-03 == Outdated reference: A later version (-11) exists of draft-ietf-sfc-architecture-09 == Outdated reference: A later version (-06) exists of draft-matsushima-stateless-uplane-vepc-04 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFVRG/SDNRG groups CJ. Bernardos 3 Internet-Draft UC3M 4 Intended status: Informational A. Rahman 5 Expires: January 7, 2016 JC. Zuniga 6 InterDigital 7 LM. Contreras 8 P. Aranda 9 TID 10 July 6, 2015 12 Gap Analysis on Network Virtualization Activities 13 draft-bernardos-nfvrg-gaps-network-virtualization-00 15 Abstract 17 Network Function Virtualization (NFV) and Software Defined Networking 18 (SDN) are changing the way the telecommunications sector will deploy, 19 extend and operate their networks. These new technologies aim at 20 reducing the overall costs by outsourcing communication services from 21 specific hardware in the operators' core to server farms scattered in 22 datacenters (i.e. compute and storage virtualization). In addition, 23 the connecting networks are fundamentally affected in they way they 24 route, process and control traffic(i.e. network virtualization). 26 Virtualization is becoming a trend which is being adopted in many 27 scenarios for different purposes. This document overviews existing 28 efforts around virtualization at the IETF/IRTF, focusing on those 29 related to NFV and SDN. These efforts are mapped to the most 30 relevant architectures being defined outside IETF, namely at the ETSI 31 NFV ISG, the ETSI MEC ISG and the ONF. 33 The main goal of this document is to serve as a survey of the 34 different efforts that have been taken and are currently taking place 35 at IETF and IRTF in regards to network virtualization, putting them 36 into context considering efforts by other SDOs, and identifying 37 current gaps that can be tackled at IETF or researched at the IRTF. 39 Requirements Language 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in RFC 2119 [RFC2119]. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at http://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on January 7, 2016. 62 Copyright Notice 64 Copyright (c) 2015 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 3.1. Network Function Virtualization . . . . . . . . . . . . . 5 83 3.2. Software Defined Networking . . . . . . . . . . . . . . . 7 84 3.3. Mobile Edge Computing . . . . . . . . . . . . . . . . . . 10 85 4. Network Virtualization at IETF/IRTF . . . . . . . . . . . . . 10 86 4.1. SFC WG . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 4.2. NVO3 WG . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 4.3. DMM WG . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 4.4. I2RS WG . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 4.5. BESS WG . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 4.6. VNFpool BoF . . . . . . . . . . . . . . . . . . . . . . . 15 92 4.7. ACTN (at TEAS WG) . . . . . . . . . . . . . . . . . . . . 15 93 4.8. NFV RG . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 4.9. SDN RG . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 5. Summary of Gaps . . . . . . . . . . . . . . . . . . . . . . . 17 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 98 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 101 9.2. Informative References . . . . . . . . . . . . . . . . . 19 102 Appendix A. The mobile network use case . . . . . . . . . . . . 20 103 A.1. The 3GPP Evolved Packet System . . . . . . . . . . . . . 20 104 A.2. Virtualizing the 3GPP EPS . . . . . . . . . . . . . . . . 21 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 107 1. Introduction 109 The telecommunications sector is experiencing a major revolution that 110 will shape the way networks and services are designed and deployed 111 for the next decade. We are witnessing an explosion in the number of 112 applications and services demanded by users, which are now really 113 capable of accessing them on the move. In order to cope with such a 114 demand, some network operators are now following a cloud computing 115 paradigm, enabling the reduction of the overall costs by outsourcing 116 communication services from specific hardware in the operator's core 117 to server farms scattered in datacenters. These services have 118 different characteristics if compared with conventional IT services 119 that have to be taken into account in this cloudification process. 120 Also the transport network is affected in that it is evolving to a 121 more sophisticated form of IP architecture with trends like 122 separation of control and data plane traffic, and more fine-grained 123 forwarding of packets (beyond looking at the destination IP address) 124 in the network to fulfill new business and service goals. 126 Virtualization of functions also provides operators with tools to 127 deploy new services much faster, as compared to the traditional use 128 of monolithic and tightly integrated dedicated machinery. As a 129 natural next step, mobile network operators need to re-think how to 130 evolve their existing network infrastructures and how to deploy new 131 ones to address the challenges posed by the increasing customers' 132 demands, as well as by the huge competition among operators. All 133 these changes are triggering the need for a modification in the way 134 operators and infrastructure providers operate their networks, as 135 they need to significantly reduce the costs incurred in deploying a 136 new service and operating it. Some of the mechanisms that are being 137 considered and already adopted by operators include: sharing of 138 network infrastructure to reduce costs, virtualization of core 139 servers running in data centers as a way of supporting their load- 140 aware elastic dimensioning, and dynamic energy policies to reduce the 141 monthly electricity bill. However, this has proved to be tough to 142 put in practice, and not enough. Indeed, it is not easy to deploy 143 new mechanisms in a running operational network due to the high 144 dependency on proprietary (and sometime obscure) protocols and 145 interfaces, which are complex to manage and often require configuring 146 multiple devices in a decentralized way. 148 Network Function Virtualization (NFV) and Software Defined Networking 149 (SDN) are changing the way the telecommunications sector will deploy, 150 extend and operate their networks. This document provides a survey 151 of the different efforts that have taken and are currently taking 152 place at IETF and IRTF in regards of network virtualization, looking 153 at how they relate to the ETSI NFV ISG, ETSI MEC ISG and ONF 154 architectural frameworks. Based on this analysis, we also go a step 155 farther, identifying which are the potential work areas where IETF/ 156 IRTF can work on to complement the complex network virtualization map 157 of technologies being standardized today. 159 2. Terminology 161 The following terms used in this document are defined by the ETSI NVF 162 ISG, and the ONF and the IETF: 164 NFV Infrastructure (NFVI): totality of all hardware and software 165 components which build up the environment in which VNFs are 166 deployed 168 NFV Management and Orchestration (NFV-MANO): functions 169 collectively provided by NFVO, VNFM, and VIM. 171 NFV Orchestrator (NFVO): functional block that manages the Network 172 Service (NS) lifecycle and coordinates the management of NS 173 lifecycle, VNF lifecycle (supported by the VNFM) and NFVI 174 resources (supported by the VIM) to ensure an optimized allocation 175 of the necessary resources and connectivity. 177 OpenFlow protocol (OFP). 179 Service Function Chain (SFC): for a given service, the abstracted 180 view of the required service functions and the order in which they 181 are to be applied. This is somehow equivalent to the Network 182 Function Forwarding Graph (NF-FG) at ETSI. 184 Service Function Path (SFP): the selection of specific service 185 function instances on specific network nodes to form a service 186 graph through which an SFC is instantiated. 188 virtual EPC (vEPC). 190 Virtualized Infrastructure Manager (VIM): functional block that is 191 responsible for controlling and managing the NFVI compute, storage 192 and network resources, usually within one operator's 193 Infrastructure Domain. 195 Virtualized Network Function (VNF): implementation of a Network 196 Function that can be deployed on a Network Function Virtualisation 197 Infrastructure (NFVI). 199 Virtualized Network Function Manager (VNFM): functional block that 200 is responsible for the lifecycle management of VNF. 202 3. Background 204 3.1. Network Function Virtualization 206 The ETSI ISG NFV is a working group which, since 2012, aims to evolve 207 quasi-standard IT virtualization technology to consolidate many 208 network equipment types into industry standard high volume servers, 209 switches, and storage. It enables implementing network functions in 210 software that can run on a range of industry standard server hardware 211 and can be moved to, or loaded in, various locations in the network 212 as required, without the need to install new equipment. To date, 213 ETSI NFV is by far the most accepted NFV reference framework and 214 architectural footprint. The ETSI NFV framework architecture 215 framework is composed of three domains (Figure 1): 217 o Virtualized Network Function, running over the NFVI. 219 o NFV Infrastructure (NFVI), including the diversity of physical 220 resources and how these can be virtualized. NFVI supports the 221 execution of the VNFs. 223 o NFV Management and Orchestration, which covers the orchestration 224 and life-cycle management of physical and/or software resources 225 that support the infrastructure virtualization, and the life-cycle 226 management of VNFs. NFV Management and Orchestration focuses on 227 all virtualization specific management tasks necessary in the NFV 228 framework. 230 +-------------------------------------------+ +---------------+ 231 | Virtualized Network Functions (VNFs) | | | 232 | ------- ------- ------- ------- | | | 233 | | | | | | | | | | | | 234 | | VNF | | VNF | | VNF | | VNF | | | | 235 | | | | | | | | | | | | 236 | ------- ------- ------- ------- | | | 237 +-------------------------------------------+ | | 238 | | 239 +-------------------------------------------+ | | 240 | NFV Infrastructure (NFVI) | | NFV | 241 | ----------- ----------- ----------- | | Management | 242 | | Virtual | | Virtual | | Virtual | | | and | 243 | | Compute | | Storage | | Network | | | Orchestration | 244 | ----------- ----------- ----------- | | | 245 | +---------------------------------------+ | | | 246 | | Virtualization Layer | | | | 247 | +---------------------------------------+ | | | 248 | +---------------------------------------+ | | | 249 | | ----------- ----------- ----------- | | | | 250 | | | Compute | | Storage | | Network | | | | | 251 | | ----------- ----------- ----------- | | | | 252 | | Hardware resources | | | | 253 | +---------------------------------------+ | | | 254 +-------------------------------------------+ +---------------+ 256 Figure 1: ETSI NFV framework 258 The NFV architectural framework identifies functional blocks and the 259 main reference points between such blocks. Some of these are already 260 present in current deployments, whilst others might be necessary 261 additions in order to support the virtualization process and 262 consequent operation. The functional blocks are (Figure 2): 264 o Virtualized Network Function (VNF). 266 o Element Management (EM). 268 o NFV Infrastructure, including: Hardware and virtualized resources, 269 and Virtualization Layer. 271 o Virtualized Infrastructure Manager(s) (VIM). 273 o NFV Orchestrator. 275 o VNF Manager(s). 277 o Service, VNF and Infrastructure Description. 279 o Operations and Business Support Systems (OSS/BSS). 281 +--------------------+ 282 +-------------------------------------------+ | ---------------- | 283 | OSS/BSS | | | NFV | | 284 +-------------------------------------------+ | | Orchestrator +-- | 285 | ---+------------ | | 286 +-------------------------------------------+ | | | | 287 | --------- --------- --------- | | | | | 288 | | EM 1 | | EM 2 | | EM 3 | | | | | | 289 | ----+---- ----+---- ----+---- | | ---+---------- | | 290 | | | | |--|-| VNF | | | 291 | ----+---- ----+---- ----+---- | | | manager(s) | | | 292 | | VNF 1 | | VNF 2 | | VNF 3 | | | ---+---------- | | 293 | ----+---- ----+---- ----+---- | | | | | 294 +------|-------------|-------------|--------+ | | | | 295 | | | | | | | 296 +------+-------------+-------------+--------+ | | | | 297 | NFV Infrastructure (NFVI) | | | | | 298 | ----------- ----------- ----------- | | | | | 299 | | Virtual | | Virtual | | Virtual | | | | | | 300 | | Compute | | Storage | | Network | | | | | | 301 | ----------- ----------- ----------- | | ---+------ | | 302 | +---------------------------------------+ | | | | | | 303 | | Virtualization Layer | |--|-| VIM(s) +-------- | 304 | +---------------------------------------+ | | | | | 305 | +---------------------------------------+ | | ---------- | 306 | | ----------- ----------- ----------- | | | | 307 | | | Compute | | Storage | | Network | | | | | 308 | | | hardware| | hardware| | hardware| | | | | 309 | | ----------- ----------- ----------- | | | | 310 | | Hardware resources | | | NFV Management | 311 | +---------------------------------------+ | | and Orchestration | 312 +-------------------------------------------+ +--------------------+ 314 Figure 2: ETSI NFV reference architecture 316 3.2. Software Defined Networking 318 The Software Defined Networking (SDN) paradigm pushes the 319 intelligence currently residing in the network elements to a central 320 controller implementing the network functionality through software. 321 In contrast to traditional approaches, in which the network's control 322 plane is distributed throughout all network devices, with SDN the 323 control plane is logically centralized. In this way, the deployment 324 of new characteristics in the network no longer requires of complex 325 and costly changes in equipment or firmware updates, but only a 326 change in the software running in the controller. The main advantage 327 of this approach is the flexibility it provides operators with to 328 manage their network, i.e., an operator can easily change its 329 policies on how traffic is distributed throughout the network. 331 The most visible of the SDN protocol stacks is the OpenFlow protocol 332 (OFP), which is maintained and extended by the Open Network 333 Foundation (ONF). Originally this protocol was developed 334 specifically for IEEE 802.1 switches conforming to the ONF OpenFlow 335 Switch specification. As the benefits of the SDN paradigm have 336 reached a wider audience, its application has been extended to more 337 complex scenarios such as Wireless and Mobile networks. Within this 338 area of work, the ONF is actively developing new OFP extensions 339 addressing three key scenarios: (i) Wireless backhaul, (ii) Cellular 340 Evolved Packet Core (EPC), and (iii) Unified access and management 341 across enterprise wireless and fixed networks. 343 +----------+ 344 | ------- | 345 | |Oper.| | O 346 | |Mgmt.| |<........> -+- Network Operator 347 | |Iface| | ^ 348 | ------- | +----------------------------------------+ 349 | | | +------------------------------------+ | 350 | | | | --------- --------- --------- | | 351 |--------- | | | | App 1 | | App 2 | ... | App n | | | 352 ||Plugins| |<....>| | --------- --------- --------- | | 353 |--------- | | | Plugins | | 354 | | | +------------------------------------+ | 355 | | | Application Plane | 356 | | +----------------------------------------+ 357 | | A 358 | | | 359 | | V 360 | | +----------------------------------------+ 361 | | | +------------------------------------+ | 362 |--------- | | | ------------ ------------ | | 363 || Netw. | | | | | Module 1 | | Module 2 | | | 364 ||Engine | |<....>| | ------------ ------------ | | 365 |--------- | | | Network Engine | | 366 | | | +------------------------------------+ | 367 | | | Controller Plane | 368 | | +----------------------------------------+ 369 | | A 370 | | | 371 | | V 372 | | +----------------------------------------+ 373 | | | +--------------+ +--------------+ | 374 | | | | ------------ | | ------------ | | 375 |----------| | | | OpenFlow | | | | OpenFlow | | | 376 ||OpenFlow||<....>| | ------------ | | ------------ | | 377 |----------| | | NE | | NE | | 378 | | | +--------------+ +--------------+ | 379 | | | Data Plane | 380 |Management| +----------------------------------------+ 381 +----------+ 383 Figure 3: High level SDN ONF architecture 385 Figure 3 shows the blocks and the functional interfaces of the ONF 386 architecture, which comprises three planes: Data, Controller, and 387 Application. The Data plane comprehends several Network Entities 388 (NE), which expose their capabilities toward the Controller plane via 389 a Southbound API. The Controller plane includes several cooperating 390 modules devoted to the creation and maintenance of an abstracted 391 resource model of the underneath network. Such model is exposed to 392 the applications via a Northbound API where the Application plane 393 comprises several applications/services, each of which has exclusive 394 control of a set of exposed resources. 396 The Management plane spans its functionality across all planes 397 performing the initial configuration of the network elements in the 398 Data plane, the assignment of the SDN controller and the resources 399 under its responsibility. In the Controller plane, the Management 400 needs to configure the policies defining the scope of the control 401 given to the SDN applications, to monitor the performance of the 402 system, and to configure the parameters required by the SDN 403 controller modules. In the Application plane, Management configures 404 the parameters of the applications and the service level agreements. 405 In addition to the these interactions, the Management plane exposes 406 several functions to network operators which can easily and quickly 407 configure and tune the network at each layer. 409 3.3. Mobile Edge Computing 411 Mobile Edge Computing capabilities deployed in the edge of the mobile 412 network can facilitate the efficient and dynamic provision of 413 services to mobile users. The ETSI ISG MEC working group, operative 414 from end of 2014, intends to specify an open environment for 415 integrating MEC capabilities with service providers networks, 416 including also applications from 3rd parties. These computing 417 capabilities will make available IT infrastructure for the deployment 418 of functions in mobile access networks. It can be seen then as a 419 complement to both NFV and SDN. 421 4. Network Virtualization at IETF/IRTF 423 4.1. SFC WG 425 Current network services deployed by operators often involve the 426 composition of several individual functions (such as packet 427 filtering, deep packet inspection, load balancing). These services 428 are typically implemented by the ordered combination of a number of 429 service functions that are deployed at different points within a 430 network, not necessary on the direct data path. This requires 431 traffic to be steered through the required service functions, 432 wherever they are deployed. 434 For a given service, the abstracted view of the required service 435 functions and the order in which they are to be applied is called a 436 Service Function Chain (SFC), which is called Network Function 437 Forwarding Graph (NF-FG) in ETSI. An SFC is instantiated through 438 selection of specific service function instances on specific network 439 nodes to form a service graph: this is called a Service Function Path 440 (SFP). The service functions may be applied at any layer within the 441 network protocol stack (network layer, transport layer, application 442 layer, etc.). 444 The SFC working group is working on an architecture for service 445 function chaining that includes the necessary protocols or protocol 446 extensions to convey the Service Function Chain and Service Function 447 Path information to nodes that are involved in the implementation of 448 service functions and Service Function Chains, as well as mechanisms 449 for steering traffic through service functions. 451 In terms of actual work items, the SFC WG is chartered to deliver: 452 (i) a problem statement document [RFC7498], (ii) an architecture 453 document [I-D.ietf-sfc-architecture], (iii) a service-level data 454 plane encapsulation format (the encapsulation should indicate the 455 sequence of service functions that make up the Service Function 456 Chain, specify the Service Function Path, and communicate context 457 information between nodes that implement service functions and 458 Service Function Chains), and (iv) a document describing requirements 459 for conveying information between control or management elements and 460 SFC implementation points. 462 Potential gap: as stated in the SFC charter, any work on the 463 management and configuration of SFC components related to the support 464 of Service Function Chaining will not be done yet, until better 465 understood and scoped. This part is of special interest for 466 operators and would be required in order to actually put SFC 467 mechanisms into operation. 469 Potential gap: redundancy and reliability mechanisms are currently 470 not dealt with by any WG in the IETF. While this has been the main 471 goal of the VNFpool BoF efforts, it still remains un-addressed. 473 4.2. NVO3 WG 475 The Network Virtualization Overlays (NVO3) WG is developing protocols 476 that enable network virtualization overlays within large Data Center 477 (DC) environments. Specifically NVO3 assumes an underlying physical 478 Layer 3 (IP) fabric on which multiple tenant networks are virtualized 479 on top (i.e. overlays). With overlays, data traffic between tenants 480 is tunneled across the underlying DC's IP network. The use of 481 tunnels provides a number of benefits by decoupling the network as 482 viewed by tenants from the underlying physical network across which 483 they communicate [I-D.ietf-nvo3-arch]. 485 Potential gap: It would be worthwhile to see if some of the specific 486 approaches developed in this WG (e.g. overlays, traffic isolation, VM 487 migration) can be applied outside the DC, and specifically if they 488 can be applicable to mobile network virtualization (NFV). These 489 approaches would be most relevant to the ETSI Network Function 490 Virtualization Infrastructure (NFVI), and the Virtualized 491 Infrastructure Manager part of the MANO. 493 4.3. DMM WG 495 The Distributed Mobility Management (DMM) WG is looking at solutions 496 for IP networks that enable traffic between mobile and correspondent 497 nodes taking an optimal route, preventing some of the issues caused 498 by the use of centralized mobility solutions, which anchor all the 499 traffic at a given node (or a very limited set of nodes). The DMM WG 500 is considering the latest developments in mobile networking research 501 and operational practices (i.e., flattening network architectures, 502 the impact of virtualization, new deployment needs as wireless access 503 technologies evolve in the coming years) and aims at describing how 504 distributed mobility management addresses the new needs in this area 505 better than previously standardized solutions. 507 Although network virtualization is not the main area of the DMM work, 508 the impact of SDN and NFV mechanisms is clear on the work that is 509 currently being done in the WG. One example is architecture defined 510 for the virtual Evolved Packet Core (vEPC) in 511 [I-D.matsushima-stateless-uplane-vepc]. Here, the authors describe a 512 particular realization of the vEPC concept, which is designed to 513 support NFV. In the defined architecture, the user plane of EPC is 514 decoupled from the control-plane and uses routing information to 515 forward packets of mobile nodes. This proposal does not modify the 516 signaling of the EPC control plane, although the EPC control plane 517 runs on an hypervisor. How to run the EPC control plane on NFV is 518 actually a potential gap. 520 The DMM WG is also looking at ways to supporting the separation of 521 the Control-Plane for mobility- and session management from the 522 actual Data-Plane [I-D.ietf-dmm-fpc-cpdp]. The protocol semantics 523 being defined abstract from the actual details for the configuration 524 of Data-Plane nodes and apply between a Client function, which is 525 used by an application of the mobility Control-Plane, and an Agent 526 function, which is associated with the configuration of Data-Plane 527 nodes according to the policies issued by the mobility Control-Plane. 528 The actual mappings between these generic protocol semantics and the 529 configuration commands required on the data plane network elements 530 are not in the scope of this document, and are therefore a potential 531 gap that will need to be addressed (e.g., for OpenFlow switches). 533 4.4. I2RS WG 535 The Interface to the Routing System (I2RS) WG is developing a high- 536 level architecture that describes the basic building-blocks to access 537 the routing system through a set of protocol-based control or 538 management interfaces. This architecture, as described in 539 [I-D.ietf-i2rs-architecture], comprises an I2RS Agent as a unified 540 interface that is accessed by I2RS clients using the I2RS protocol. 541 The client is controlled by one or more network applications and 542 accesses one or more agents, as shown in the following figure: 544 ****************** ***************** ***************** 545 * Application C * * Application D * * Application E * 546 ****************** ***************** ***************** 547 | | | 548 +--------------+ | +-------------+ 549 | | | 550 *************** 551 * Client P *----------------------+ 552 *************** | 553 *********************** | | 554 * Application A * | | 555 * * | *********************** | 556 * +----------------+ * | * Application B * | 557 * | Client A | * | * * | 558 * +----------------+ * | * +----------------+ * | 559 *********************** | * | Client B | * | 560 | | * +----------------+ * | 561 | +----------------+ *********************** | 562 | | | | | 563 | | +------------------------+ | +-----+ 564 | | | | | 565 ******************************* ******************************* 566 * * * * 567 * Routing Element 1 * * Routing Element 2 * 568 * * * * 569 ******************************* ******************************* 571 Figure 4: High level I2RS architecture 573 Routing elements consist of an agent that communicates with the 574 client or clients driven by the applications and accesses the 575 different subsystems in the element as shown in the following figure: 577 | 578 *****************v************** 579 * +---------------------+ * 580 * | Agent | * 581 * +---------------------+ * 582 * ^ ^ ^ ^ * 583 * | | | | * 584 * | | | +--+ * 585 * | | | | * 586 * v | | v * 587 * +---+-----+ | | +----+---+ * 588 * | Routing | | | | Local | * 589 * | and | | | | Config | * 590 * |Signaling| | | +--------+ * 591 * +---------+ | | ^ * 592 * ^ | | | * 593 * | +----+ | | * 594 * v v v v * 595 * +----------+ +------------+ * 596 * | Dynamic | | Static | * 597 * | System | | System | * 598 * | State | | State | * 599 * +----------+ +------------+ * 600 * * 601 * Routing Element * 602 ******************************** 604 Figure 5: Architecture of a routing element 606 The I2RS architecture proposes to use model-driven APIs. Services 607 can correspond to different data-models and agents can indicate which 608 model they support. 610 Potential gap: network virtualization is not the main aim of the I2RS 611 WG. However, they provide an infrastructure that can be part of an 612 SDN deployment. 614 4.5. BESS WG 616 BGP is already used as a protocol for provisioning and operating 617 Layer-3 (routed) Virtual Private Networks (L3VPNs). The BGP Enabled 618 Services (BESS) working group is responsible for defining, 619 specifying, and extending network services based on BGP. In 620 particular, the working group will work on the following services: 622 o BGP-enabled VPN solutions for use in the data center networking. 623 This work includes consideration of VPN scaling issues and 624 mechanisms applicable to such environments. 626 o Extensions to BGP-enabled VPN solutions for the construction of 627 virtual topologies in support of services such as Service Function 628 Chaining. 630 Potential gap: The most relevant activity in BESS that would be 631 worthwhile to investigate for relevance to mobile network 632 virtualization (NFV) is the extensions to BGP-enabled VPN solutions 633 to support of Service Function Chaining 634 [I-D.rfernando-bess-service-chaining]. 636 4.6. VNFpool BoF 638 The VNFPOOL BoF is working on the way to group Virtual Network 639 Function (VNF) into pools to improve resilience, provide better 640 scale-out and scale-in characteristics, implement stateful failover 641 among VNF members of a pool, etc. Additionally, they propose to 642 create VNF sets from VNF pools. For this, the BoF proposes to study 643 signaling (both between members of a pool and across pools), state 644 sharing mechanisms between members of a VNFPOOL, the exchange of 645 reliability information between VNF sets, their users and the 646 underlying network, and the reliability and security of the control 647 plane needed to transport the exchanged information. 649 The VNFPOOL BoF started work on the charter, use case study, and 650 requirements and initial architecture. The use cases include Content 651 Deliver Networks (CDNs), the LTE mobile core network and reliable 652 server pooling. Currently, there is no activity on the mailing list 653 setup for this activity. 655 Potential gap: VNFPOOL tries to introduce and manage resilience in 656 virtualized networking environments and therefore addresses a 657 desirable feature for any software defined network. VNFPOOL has also 658 been integrated into the NFV architecture 659 [I-D.bernini-nfvrg-vnf-orchestration]. 661 4.7. ACTN (at TEAS WG) 663 Transport network infrastructure provides end-to-end connectivity for 664 networked applications and services. Network virtualization 665 facilitates effective sharing (or 'slicing') of physical 666 infrastructure by representing resources and topologies via 667 abstractions, even in a multi-administration, multi-vendor, multi- 668 technology environment. In this way, it becomes possible to operate, 669 control and manage multiple physical networks elements as single 670 virtualized network. The users of such virtualized network can 671 control the allocated resources in an optimal and flexible way, 672 better adapting to the specific circumstances of higher layer 673 applications. 675 Abstraction and Control of Transport Networks (ACTN) intends to 676 define methods and capabilities for the deployment and operation of 677 transport network resources [I-D.ceccarelli-teas-actn-framework]. 678 This activity is currently being carried out within the Traffic 679 Engineering Architecture and Signaling (TEAS) WG. 681 Several use cases are being proposed for both fixed and mobile 682 scenarios [I-D.leeking-teas-actn-problem-statement]. 684 Potential gap: Several use cases in ACTN are relevant to mobile 685 network virtualization (NFV). Control of multi-tenant mobile 686 backhaul transport networks, mobile virtual network operation, etc, 687 can be influenced by the location of the network functions. A 688 control architecture allowing for inter-operation of NFV and 689 transport network (e.g., for combined optimization) is one relevant 690 area for research. 692 4.8. NFV RG 694 The NFVRG focuses on research problems associated with virtualization 695 of fixed and mobile network infrastructures, new network 696 architectures based on virtualized network functions, virtualization 697 of the home and enterprise network environments, co-existence with 698 non-virtualized infrastructure and services, and application to 699 growing areas of concern such as Internet of Things (IoT) and next 700 generation content distribution. Another goal of the NFVRG is to 701 bring a research community together that can jointly address such 702 problems, concentrating on problems that relate not just to 703 networking but also to computing and storage constraints in such 704 environments. 706 Since the NFVRG is a research group, it has a wide scope. In order 707 to keep the focus, the group has identified some near term work 708 items: (i) Policy based Resource Management, (ii) Analytics for 709 Visibility and Orchestration, (iii) Virtual Network Function (VNF) 710 Performance Modelling to facilitate transition to NFV and (iv) 711 Security and Service Verification. 713 4.9. SDN RG 715 The SDNRG provides the grounds for an open-minded investigation of 716 Software Defined Networking. They aim at identifying approaches that 717 can be defined and used in the near term as well as the research 718 challenges in the field. As such, they SDNRG will not define 719 standards, but provide inputs to standards defining and standards 720 producing organizations. 722 It is working on classifying SDN models, including definitions and 723 taxonomies. It is also studying complexity, scalability and 724 applicability of the SDN model. Additionally, the SDNRG is working 725 on network description languages (and associated tools), abstractions 726 and interfaces. They also investigate the verification of correct 727 operation of network or node function. 729 The SDNRG has produced a reference layer model RFC7426 [RFC7426], 730 which structures SDNs in planes and layers which are glued together 731 by different abstraction layers. This architecture differentiates 732 between the control and the management planes and provides for 733 differentiated southbound interfaces (SBIs). 735 5. Summary of Gaps 737 Potential Gap-1: as stated in the SFC charter, any work on the 738 management and configuration of SFC components related to the support 739 of Service Function Chaining will not be done yet, until better 740 understood and scoped. This part is of special interest for 741 operators and would be required in order to actually put SFC 742 mechanisms into operation. 744 Potential Gap-2: redundancy and reliability mechanisms are currently 745 not dealt with by SFC or any other WG in the IETF. While this has 746 been the main goal of the VNFpool BoF efforts, it still remains un- 747 addressed. 749 Potential Gap-3: it would be worthwhile to see if some of the 750 specific approaches developed in the NVO3 WG (e.g. overlays, traffic 751 isolation, VM migration) can be applied outside the DC, and 752 specifically if they can be applicable to mobile network 753 virtualization (NFV). These approaches would be most relevant to the 754 ETSI Network Function Virtualization Infrastructure (NFVI), and the 755 Virtualized Infrastructure Manager part of the MANO. 757 Potential Gap-4: the most relevant activity in BESS that would be 758 worthwhile to investigate for relevance to mobile network 759 virtualization (NFV) is the extensions to BGP-enabled VPN solutions 760 to support of Service Function Chaining. 762 Potential Gap-5: in a vEPC/DMM context, how to run the EPC control 763 plane on NFV. 765 Potential Gap-6: in DMM, on the work item addressing the separation 766 of the Control-Plane for mobility- and session management from the 767 actual Data-Plane, the actual mappings between these generic protocol 768 semantics and the configuration commands required on the data plane 769 network elements (e.g., OpenFlow switches) are not currently in the 770 scope of the DMM WG. 772 Potential Gap-7: network virtualization is not the main aim of the 773 I2RS WG. However, they provide an infrastructure that can be part of 774 an SDN deployment. 776 Potential Gap-8: the most relevant activity in BESS that would be 777 worthwhile to investigate for relevance to mobile network 778 virtualization (NFV) is the extensions to BGP-enabled VPN solutions 779 to support of Service Function Chaining. 781 Potential Gap-9: VNFPOOL tries to introduce and manage resilience in 782 virtualized networking environments and therefore addresses a 783 desirable feature for any software defined network. VNFPOOL has also 784 been integrated into the NFV architecture 785 [I-D.bernini-nfvrg-vnf-orchestration]. 787 Potential Gap-10: several use cases in ACTN are relevant to mobile 788 network virtualization (NFV). Control of multi-tenant mobile 789 backhaul transport networks, mobile virtual network operation, etc, 790 can be influenced by the location of the network functions. A 791 control architecture allowing for inter-operation of NFV and 792 transport network (e.g., for combined optimization) is one relevant 793 area for research. 795 6. IANA Considerations 797 N/A. 799 7. Security Considerations 801 The work of Pedro Aranda is supported by the European FP7 Project 802 Trilogy2 under grant agreement 317756. 804 8. Acknowledgments 806 The authors would like to thank ... 808 9. References 810 9.1. Normative References 812 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 813 Requirement Levels", BCP 14, RFC 2119, March 1997. 815 9.2. Informative References 817 [I-D.bernini-nfvrg-vnf-orchestration] 818 Bernini, G., Maffione, V., Lopez, D., and P. Aranda, "VNF 819 Orchestration For Automated Resiliency in Service Chains", 820 draft-bernini-nfvrg-vnf-orchestration-00 (work in 821 progress), July 2015. 823 [I-D.ceccarelli-teas-actn-framework] 824 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 825 Control of Transport Networks", draft-ceccarelli-teas- 826 actn-framework-00 (work in progress), June 2015. 828 [I-D.ietf-dmm-fpc-cpdp] 829 Liebsch, M., Matsushima, S., Gundavelli, S., and D. Moses, 830 "Protocol for Forwarding Policy Configuration (FPC) in 831 DMM", draft-ietf-dmm-fpc-cpdp-00 (work in progress), May 832 2015. 834 [I-D.ietf-i2rs-architecture] 835 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 836 Nadeau, "An Architecture for the Interface to the Routing 837 System", draft-ietf-i2rs-architecture-09 (work in 838 progress), March 2015. 840 [I-D.ietf-nvo3-arch] 841 Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 842 Narten, "An Architecture for Overlay Networks (NVO3)", 843 draft-ietf-nvo3-arch-03 (work in progress), March 2015. 845 [I-D.ietf-sfc-architecture] 846 Halpern, J. and C. Pignataro, "Service Function Chaining 847 (SFC) Architecture", draft-ietf-sfc-architecture-09 (work 848 in progress), June 2015. 850 [I-D.leeking-teas-actn-problem-statement] 851 Lee, Y., King, D., Boucadair, M., Jing, R., and L. 852 Contreras, "Problem Statement for Abstraction and Control 853 of Transport Networks", draft-leeking-teas-actn-problem- 854 statement-00 (work in progress), June 2015. 856 [I-D.matsushima-stateless-uplane-vepc] 857 Matsushima, S. and R. Wakikawa, "Stateless user-plane 858 architecture for virtualized EPC (vEPC)", draft- 859 matsushima-stateless-uplane-vepc-04 (work in progress), 860 March 2015. 862 [I-D.rfernando-bess-service-chaining] 863 Fernando, R., Rao, D., Fang, L., Napierala, M., So, N., 864 and A. Farrel, "Virtual Topologies for Service Chaining in 865 BGP/IP MPLS VPNs", draft-rfernando-bess-service- 866 chaining-01 (work in progress), April 2015. 868 [RFC7426] Haleplidis, E., Pentikousis, K., Denazis, S., Hadi Salim, 869 J., Meyer, D., and O. Koufopavlou, "Software-Defined 870 Networking (SDN): Layers and Architecture Terminology", 871 RFC 7426, January 2015. 873 [RFC7498] Quinn, P. and T. Nadeau, "Problem Statement for Service 874 Function Chaining", RFC 7498, April 2015. 876 Appendix A. The mobile network use case 878 A.1. The 3GPP Evolved Packet System 880 TBD. This will include a high level summary of the 3GPP EPS 881 architecture, detailing both the EPC (core) and the RAN (access) 882 parts. A link with the two related ETSI NFV use cases 883 (Virtualisation of Mobile Core Network and IMS, and Virtualisation of 884 Mobile base station) will be included. 886 +---------------------------------------------------------+ 887 | PCRF | 888 +-----------+--------------------------+----------------+-+ 889 | | | 890 +----+ +-----------+------------+ +--------+-----------+ +-+-+ 891 | | | +-+ | | Core Network | | | 892 | | | +------+ |S|__ | | +--------+ +---+ | | | 893 | | | |GERAN/|_|G| \ | | | HSS | | | | | | 894 | +-----+ UTRAN| |S| \ | | +---+----+ | | | | E | 895 | | | +------+ |N| +-+-+ | | | | | | | x | 896 | | | +-+ /|MME| | | +---+----+ | | | | t | 897 | | | +---------+ / +---+ | | | 3GPP | | | | | e | 898 | +-----+ E-UTRAN |/ | | | AAA | | | | | r | 899 | | | +---------+\ | | | SERVER | | | | | n | 900 | | | \ +---+ | | +--------+ | | | | a | 901 | | | 3GPP AN \|SGW+----- S5---------------+ P | | | l | 902 | | | +---+ | | | G | | | | 903 | | +------------------------+ | | W | | | I | 904 | UE | | | | | | P | 905 | | +------------------------+ | | +-----+ | 906 | | |+-------------+ +------+| | | | | | n | 907 | | || Untrusted +-+ ePDG +-S2b---------------+ | | | e | 908 | +---+| non-3GPP AN | +------+| | | | | | t | 909 | | |+-------------+ | | | | | | w | 910 | | +------------------------+ | | | | | o | 911 | | | | | | | r | 912 | | +------------------------+ | | | | | k | 913 | +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s | 914 | | +------------------------+ | | | | | | 915 | | | +-+-+ | | | 916 | +--------------------------S2c--------------------| | | | 917 | | | | | | 918 +----+ +--------------------+ +---+ 920 Figure 6: EPS (non-roaming) architecture overview 922 A.2. Virtualizing the 3GPP EPS 924 TBD. We describe how a "virtual EPS" (vEPS) would look like and the 925 existing gaps that exist from the point of view of network 926 virtualization. 928 Authors' Addresses 929 Carlos J. Bernardos 930 Universidad Carlos III de Madrid 931 Av. Universidad, 30 932 Leganes, Madrid 28911 933 Spain 935 Phone: +34 91624 6236 936 Email: cjbc@it.uc3m.es 937 URI: http://www.it.uc3m.es/cjbc/ 939 Akbar Rahman 940 InterDigital Communications, LLC 941 1000 Sherbrooke Street West, 10th floor 942 Montreal, Quebec H3A 3G4 943 Canada 945 Email: Akbar.Rahman@InterDigital.com 946 URI: http://www.InterDigital.com/ 948 Juan Carlos Zuniga 949 InterDigital Communications, LLC 950 1000 Sherbrooke Street West, 10th floor 951 Montreal, Quebec H3A 3G4 952 Canada 954 Email: JuanCarlos.Zuniga@InterDigital.com 955 URI: http://www.InterDigital.com/ 957 Luis M. Contreras 958 Telefonica I+D 959 Ronda de la Comunicacion, S/N 960 Madrid 28050 961 Spain 963 Email: luismiguel.conterasmurillo@telefonica.com 965 Pedro Aranda 966 Telefonica I+D 967 Ronda de la Comunicacion, S/N 968 Madrid 28050 969 Spain 971 Email: pedroa.aranda@telefonica.com