idnits 2.17.1 draft-bernardos-nfvrg-gaps-network-virtualization-03.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 (September 28, 2015) is 3132 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-abad-sdnrg-sdn-ipsec-flow-protection-00 == 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-01 == 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 (-05) exists of draft-jeong-i2nsf-sdn-security-services-02 == Outdated reference: A later version (-06) exists of draft-matsushima-stateless-uplane-vepc-05 Summary: 0 errors (**), 0 flaws (~~), 10 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: March 31, 2016 JC. Zuniga 6 InterDigital 7 LM. Contreras 8 P. Aranda 9 TID 10 September 28, 2015 12 Gap Analysis on Network Virtualization Activities 13 draft-bernardos-nfvrg-gaps-network-virtualization-03 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 March 31, 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 3.4. IEEE 802.1CF (OmniRAN) . . . . . . . . . . . . . . . . . 10 86 3.5. Distributed Management Task Force . . . . . . . . . . . . 11 87 3.6. Open Source initiatives . . . . . . . . . . . . . . . . . 11 88 4. Network Virtualization at IETF/IRTF . . . . . . . . . . . . . 12 89 4.1. SFC WG . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 4.2. NVO3 WG . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 4.3. DMM WG . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 4.4. I2RS WG . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 4.5. BESS WG . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 4.6. VNFpool BoF . . . . . . . . . . . . . . . . . . . . . . . 17 95 4.7. TEAS WG . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 4.8. I2NSF BoF . . . . . . . . . . . . . . . . . . . . . . . . 18 97 4.9. IPPM WG . . . . . . . . . . . . . . . . . . . . . . . . . 19 98 4.10. NFV RG . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 4.11. SDN RG . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 5. Summary of Gaps . . . . . . . . . . . . . . . . . . . . . . . 20 101 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 102 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 103 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 104 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 105 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 106 9.2. Informative References . . . . . . . . . . . . . . . . . 22 107 Appendix A. The mobile network use case . . . . . . . . . . . . 24 108 A.1. The 3GPP Evolved Packet System . . . . . . . . . . . . . 25 109 A.2. Virtualizing the 3GPP EPS . . . . . . . . . . . . . . . . 27 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 112 1. Introduction 114 The telecommunications sector is experiencing a major revolution that 115 will shape the way networks and services are designed and deployed 116 for the next decade. We are witnessing an explosion in the number of 117 applications and services demanded by users, which are now really 118 capable of accessing them on the move. In order to cope with such a 119 demand, some network operators are looking at the cloud computing 120 paradigm, which enables a potential reduction of the overall costs by 121 outsourcing communication services from specific hardware in the 122 operator's core to server farms scattered in datacenters. These 123 services have different characteristics if compared with conventional 124 IT services that have to be taken into account in this cloudification 125 process. Also the transport network is affected in that it is 126 evolving to a more sophisticated form of IP architecture with trends 127 like separation of control and data plane traffic, and more fine- 128 grained forwarding of packets (beyond looking at the destination IP 129 address) in the network to fulfill new business and service goals. 131 Virtualization of functions also provides operators with tools to 132 deploy new services much faster, as compared to the traditional use 133 of monolithic and tightly integrated dedicated machinery. As a 134 natural next step, mobile network operators need to re-think how to 135 evolve their existing network infrastructures and how to deploy new 136 ones to address the challenges posed by the increasing customers' 137 demands, as well as by the huge competition among operators. All 138 these changes are triggering the need for a modification in the way 139 operators and infrastructure providers operate their networks, as 140 they need to significantly reduce the costs incurred in deploying a 141 new service and operating it. Some of the mechanisms that are being 142 considered and already adopted by operators include: sharing of 143 network infrastructure to reduce costs, virtualization of core 144 servers running in data centers as a way of supporting their load- 145 aware elastic dimensioning, and dynamic energy policies to reduce the 146 monthly electricity bill. However, this has proved to be tough to 147 put in practice, and not enough. Indeed, it is not easy to deploy 148 new mechanisms in a running operational network due to the high 149 dependency on proprietary (and sometime obscure) protocols and 150 interfaces, which are complex to manage and often require configuring 151 multiple devices in a decentralized way. 153 Network Function Virtualization (NFV) and Software Defined Networking 154 (SDN) are changing the way the telecommunications sector will deploy, 155 extend and operate their networks. This document provides a survey 156 of the different efforts that have taken and are currently taking 157 place at IETF and IRTF in regards of network virtualization, looking 158 at how they relate to the ETSI NFV ISG, ETSI MEC ISG and ONF 159 architectural frameworks. Based on this analysis, we also go a step 160 farther, identifying which are the potential work areas where IETF/ 161 IRTF can work on to complement the complex network virtualization map 162 of technologies being standardized today. 164 2. Terminology 166 The following terms used in this document are defined by the ETSI NVF 167 ISG, and the ONF and the IETF: 169 NFV Infrastructure (NFVI): totality of all hardware and software 170 components which build up the environment in which VNFs are 171 deployed 173 NFV Management and Orchestration (NFV-MANO): functions 174 collectively provided by NFVO, VNFM, and VIM. 176 NFV Orchestrator (NFVO): functional block that manages the Network 177 Service (NS) lifecycle and coordinates the management of NS 178 lifecycle, VNF lifecycle (supported by the VNFM) and NFVI 179 resources (supported by the VIM) to ensure an optimized allocation 180 of the necessary resources and connectivity. 182 OpenFlow protocol (OFP): allowing vendor independent programming 183 of control functions in network nodes. 185 Service Function Chain (SFC): for a given service, the abstracted 186 view of the required service functions and the order in which they 187 are to be applied. This is somehow equivalent to the Network 188 Function Forwarding Graph (NF-FG) at ETSI. 190 Service Function Path (SFP): the selection of specific service 191 function instances on specific network nodes to form a service 192 graph through which an SFC is instantiated. 194 virtual EPC (vEPC): control plane of 3GPPs EPC operated on NFV 195 framework (as defined by [I-D.matsushima-stateless-uplane-vepc]). 197 Virtualized Infrastructure Manager (VIM): functional block that is 198 responsible for controlling and managing the NFVI compute, storage 199 and network resources, usually within one operator's 200 Infrastructure Domain. 202 Virtualized Network Function (VNF): implementation of a Network 203 Function that can be deployed on a Network Function Virtualisation 204 Infrastructure (NFVI). 206 Virtualized Network Function Manager (VNFM): functional block that 207 is responsible for the lifecycle management of VNF. 209 3. Background 211 3.1. Network Function Virtualization 213 The ETSI ISG NFV is a working group which, since 2012, aims to evolve 214 quasi-standard IT virtualization technology to consolidate many 215 network equipment types into industry standard high volume servers, 216 switches, and storage. It enables implementing network functions in 217 software that can run on a range of industry standard server hardware 218 and can be moved to, or loaded in, various locations in the network 219 as required, without the need to install new equipment. To date, 220 ETSI NFV is by far the most accepted NFV reference framework and 221 architectural footprint [etsi_nvf_whitepaper]. The ETSI NFV 222 framework architecture framework is composed of three domains 223 (Figure 1): 225 o Virtualized Network Function, running over the NFVI. 227 o NFV Infrastructure (NFVI), including the diversity of physical 228 resources and how these can be virtualized. NFVI supports the 229 execution of the VNFs. 231 o NFV Management and Orchestration, which covers the orchestration 232 and life-cycle management of physical and/or software resources 233 that support the infrastructure virtualization, and the life-cycle 234 management of VNFs. NFV Management and Orchestration focuses on 235 all virtualization specific management tasks necessary in the NFV 236 framework. 238 +-------------------------------------------+ +---------------+ 239 | Virtualized Network Functions (VNFs) | | | 240 | ------- ------- ------- ------- | | | 241 | | | | | | | | | | | | 242 | | VNF | | VNF | | VNF | | VNF | | | | 243 | | | | | | | | | | | | 244 | ------- ------- ------- ------- | | | 245 +-------------------------------------------+ | | 246 | | 247 +-------------------------------------------+ | | 248 | NFV Infrastructure (NFVI) | | NFV | 249 | ----------- ----------- ----------- | | Management | 250 | | Virtual | | Virtual | | Virtual | | | and | 251 | | Compute | | Storage | | Network | | | Orchestration | 252 | ----------- ----------- ----------- | | | 253 | +---------------------------------------+ | | | 254 | | Virtualization Layer | | | | 255 | +---------------------------------------+ | | | 256 | +---------------------------------------+ | | | 257 | | ----------- ----------- ----------- | | | | 258 | | | Compute | | Storage | | Network | | | | | 259 | | ----------- ----------- ----------- | | | | 260 | | Hardware resources | | | | 261 | +---------------------------------------+ | | | 262 +-------------------------------------------+ +---------------+ 264 Figure 1: ETSI NFV framework 266 The NFV architectural framework identifies functional blocks and the 267 main reference points between such blocks. Some of these are already 268 present in current deployments, whilst others might be necessary 269 additions in order to support the virtualization process and 270 consequent operation. The functional blocks are (Figure 2): 272 o Virtualized Network Function (VNF). 274 o Element Management (EM). 276 o NFV Infrastructure, including: Hardware and virtualized resources, 277 and Virtualization Layer. 279 o Virtualized Infrastructure Manager(s) (VIM). 281 o NFV Orchestrator. 283 o VNF Manager(s). 285 o Service, VNF and Infrastructure Description. 287 o Operations and Business Support Systems (OSS/BSS). 289 +--------------------+ 290 +-------------------------------------------+ | ---------------- | 291 | OSS/BSS | | | NFV | | 292 +-------------------------------------------+ | | Orchestrator +-- | 293 | ---+------------ | | 294 +-------------------------------------------+ | | | | 295 | --------- --------- --------- | | | | | 296 | | EM 1 | | EM 2 | | EM 3 | | | | | | 297 | ----+---- ----+---- ----+---- | | ---+---------- | | 298 | | | | |--|-| VNF | | | 299 | ----+---- ----+---- ----+---- | | | manager(s) | | | 300 | | VNF 1 | | VNF 2 | | VNF 3 | | | ---+---------- | | 301 | ----+---- ----+---- ----+---- | | | | | 302 +------|-------------|-------------|--------+ | | | | 303 | | | | | | | 304 +------+-------------+-------------+--------+ | | | | 305 | NFV Infrastructure (NFVI) | | | | | 306 | ----------- ----------- ----------- | | | | | 307 | | Virtual | | Virtual | | Virtual | | | | | | 308 | | Compute | | Storage | | Network | | | | | | 309 | ----------- ----------- ----------- | | ---+------ | | 310 | +---------------------------------------+ | | | | | | 311 | | Virtualization Layer | |--|-| VIM(s) +-------- | 312 | +---------------------------------------+ | | | | | 313 | +---------------------------------------+ | | ---------- | 314 | | ----------- ----------- ----------- | | | | 315 | | | Compute | | Storage | | Network | | | | | 316 | | | hardware| | hardware| | hardware| | | | | 317 | | ----------- ----------- ----------- | | | | 318 | | Hardware resources | | | NFV Management | 319 | +---------------------------------------+ | | and Orchestration | 320 +-------------------------------------------+ +--------------------+ 322 Figure 2: ETSI NFV reference architecture 324 3.2. Software Defined Networking 326 The Software Defined Networking (SDN) paradigm pushes the 327 intelligence currently residing in the network elements to a central 328 controller implementing the network functionality through software. 329 In contrast to traditional approaches, in which the network's control 330 plane is distributed throughout all network devices, with SDN the 331 control plane is logically centralized. In this way, the deployment 332 of new characteristics in the network no longer requires of complex 333 and costly changes in equipment or firmware updates, but only a 334 change in the software running in the controller. The main advantage 335 of this approach is the flexibility it provides operators with to 336 manage their network, i.e., an operator can easily change its 337 policies on how traffic is distributed throughout the network. 339 The most visible of the SDN protocol stacks is the OpenFlow protocol 340 (OFP), which is maintained and extended by the Open Network 341 Foundation (ONF: https://www.opennetworking.org/). Originally this 342 protocol was developed specifically for IEEE 802.1 switches 343 conforming to the ONF OpenFlow Switch specification. As the benefits 344 of the SDN paradigm have reached a wider audience, its application 345 has been extended to more complex scenarios such as Wireless and 346 Mobile networks. Within this area of work, the ONF is actively 347 developing new OFP extensions addressing three key scenarios: (i) 348 Wireless backhaul, (ii) Cellular Evolved Packet Core (EPC), and (iii) 349 Unified access and management across enterprise wireless and fixed 350 networks. 352 +----------+ 353 | ------- | 354 | |Oper.| | O 355 | |Mgmt.| |<........> -+- Network Operator 356 | |Iface| | ^ 357 | ------- | +----------------------------------------+ 358 | | | +------------------------------------+ | 359 | | | | --------- --------- --------- | | 360 |--------- | | | | App 1 | | App 2 | ... | App n | | | 361 ||Plugins| |<....>| | --------- --------- --------- | | 362 |--------- | | | Plugins | | 363 | | | +------------------------------------+ | 364 | | | Application Plane | 365 | | +----------------------------------------+ 366 | | A 367 | | | 368 | | V 369 | | +----------------------------------------+ 370 | | | +------------------------------------+ | 371 |--------- | | | ------------ ------------ | | 372 || Netw. | | | | | Module 1 | | Module 2 | | | 373 ||Engine | |<....>| | ------------ ------------ | | 374 |--------- | | | Network Engine | | 375 | | | +------------------------------------+ | 376 | | | Controller Plane | 377 | | +----------------------------------------+ 378 | | A 379 | | | 380 | | V 381 | | +----------------------------------------+ 382 | | | +--------------+ +--------------+ | 383 | | | | ------------ | | ------------ | | 384 |----------| | | | OpenFlow | | | | OpenFlow | | | 385 ||OpenFlow||<....>| | ------------ | | ------------ | | 386 |----------| | | NE | | NE | | 387 | | | +--------------+ +--------------+ | 388 | | | Data Plane | 389 |Management| +----------------------------------------+ 390 +----------+ 392 Figure 3: High level SDN ONF architecture 394 Figure 3 shows the blocks and the functional interfaces of the ONF 395 architecture, which comprises three planes: Data, Controller, and 396 Application. The Data plane comprehends several Network Entities 397 (NE), which expose their capabilities toward the Controller plane via 398 a Southbound API. The Controller plane includes several cooperating 399 modules devoted to the creation and maintenance of an abstracted 400 resource model of the underneath network. Such model is exposed to 401 the applications via a Northbound API where the Application plane 402 comprises several applications/services, each of which has exclusive 403 control of a set of exposed resources. 405 The Management plane spans its functionality across all planes 406 performing the initial configuration of the network elements in the 407 Data plane, the assignment of the SDN controller and the resources 408 under its responsibility. In the Controller plane, the Management 409 needs to configure the policies defining the scope of the control 410 given to the SDN applications, to monitor the performance of the 411 system, and to configure the parameters required by the SDN 412 controller modules. In the Application plane, Management configures 413 the parameters of the applications and the service level agreements. 414 In addition to the these interactions, the Management plane exposes 415 several functions to network operators which can easily and quickly 416 configure and tune the network at each layer. 418 3.3. Mobile Edge Computing 420 Mobile Edge Computing capabilities deployed in the edge of the mobile 421 network can facilitate the efficient and dynamic provision of 422 services to mobile users. The ETSI ISG MEC working group, operative 423 from end of 2014, intends to specify an open environment for 424 integrating MEC capabilities with service providers networks, 425 including also applications from 3rd parties. These distributed 426 computing capabilities will make available IT infrastructure as in a 427 cloud environment for the deployment of functions in mobile access 428 networks. It can be seen then as a complement to both NFV and SDN. 430 3.4. IEEE 802.1CF (OmniRAN) 432 The IEEE 802.1CF Recommended Practice specifies an access network, 433 which connects terminals to their access routers, utilizing 434 technologies based on the family of IEEE 802 Standards (e.g., 802.3 435 Ethernet, 802.11 Wi-Fi, etc.). The specification defines an access 436 network reference model, including entities and reference points 437 along with behavioral and functional descriptions of communications 438 among those entities. 440 The goal of this project is to help unifying the support of different 441 interfaces, enabling shared network control and use of software 442 defined network (SDN) principles, thereby lowering the barriers to 443 new network technologies, to new network operators, and to new 444 service providers. 446 3.5. Distributed Management Task Force 448 The DMTF is an industry standards organization working to simplify 449 the manageability of network-accessible technologies through open and 450 collaborative efforts by some technology companies. The DMTF is 451 involved in the creation and adoption of interoperable management 452 standards, supporting implementations that enable the management of 453 diverse traditional and emerging technologies including cloud, 454 virtualization, network and infrastructure. 456 There are several DMTF initiatives that are relevant to the network 457 virtualization area, such as the Open Virtualization Format (OVF), 458 for VNF packaging; the Cloud Infrastructure Management Interface 459 (CIM), for cloud infrastructure management; the Network Management 460 (NETMAN), for VNF management; and, the Virtualization Management 461 (VMAN), for virtualization infrastructure management. 463 3.6. Open Source initiatives 465 The Open Source community is especially active in the area of network 466 virtualization. We next summarize some of the active efforts: 468 o OpenStack. OpenStack is a free and open-source cloud-computing 469 software platform. 471 o OpenDayLight. OpenDaylight (ODL) is a highly available, modular, 472 extensible, scalable and multi-protocol controller infrastructure 473 built for SDN deployments on modern heterogeneous multi-vendor 474 networks. It provides a model-driven service abstraction platform 475 that allows users to write apps that easily work across a wide 476 variety of hardware and southbound protocols. 478 o OPNFV. OPNFV is a carrier-grade, integrated, open source platform 479 to accelerate the introduction of new NFV products and services. 480 By integrating components from upstream projects, the OPNFV 481 community aims at conducting performance and use case-based 482 testing to ensure the platform's suitability for NFV use cases. 483 The scope of OPNFV's initial release is focused on building NFV 484 Infrastructure (NFVI) and Virtualized Infrastructure Management 485 (VIM) by integrating components from upstream projects such as 486 OpenDaylight, OpenStack, Ceph Storage, KVM, Open vSwitch, and 487 Linux. These components, along with application programmable 488 interfaces (APIs) to other NFV elements form the basic 489 infrastructure required for Virtualized Network Functions (VNF) 490 and Management and Network Orchestration (MANO) components. 491 OPNFV's goal is to increase performance and power efficiency; 492 improve reliability, availability, and serviceability; and deliver 493 comprehensive platform instrumentation. 495 Among the main areas that are being developed by the former open 496 source activities that related to network virtualization research, we 497 can highlight: policy-based resource management, analytics for 498 visibility and orchestration, service verification with regards to 499 security and resiliency. 501 4. Network Virtualization at IETF/IRTF 503 4.1. SFC WG 505 Current network services deployed by operators often involve the 506 composition of several individual functions (such as packet 507 filtering, deep packet inspection, load balancing). These services 508 are typically implemented by the ordered combination of a number of 509 service functions that are deployed at different points within a 510 network, not necessary on the direct data path. This requires 511 traffic to be steered through the required service functions, 512 wherever they are deployed. 514 For a given service, the abstracted view of the required service 515 functions and the order in which they are to be applied is called a 516 Service Function Chain (SFC), which is called Network Function 517 Forwarding Graph (NF-FG) in ETSI. An SFC is instantiated through 518 selection of specific service function instances on specific network 519 nodes to form a service graph: this is called a Service Function Path 520 (SFP). The service functions may be applied at any layer within the 521 network protocol stack (network layer, transport layer, application 522 layer, etc.). 524 The SFC working group is working on an architecture for service 525 function chaining that includes the necessary protocols or protocol 526 extensions to convey the Service Function Chain and Service Function 527 Path information to nodes that are involved in the implementation of 528 service functions and Service Function Chains, as well as mechanisms 529 for steering traffic through service functions. 531 In terms of actual work items, the SFC WG is chartered to deliver: 532 (i) a problem statement document [RFC7498], (ii) an architecture 533 document [I-D.ietf-sfc-architecture], (iii) a service-level data 534 plane encapsulation format (the encapsulation should indicate the 535 sequence of service functions that make up the Service Function 536 Chain, specify the Service Function Path, and communicate context 537 information between nodes that implement service functions and 538 Service Function Chains), and (iv) a document describing requirements 539 for conveying information between control or management elements and 540 SFC implementation points. 542 Potential gap: as stated in the SFC charter, any work on the 543 management and configuration of SFC components related to the support 544 of Service Function Chaining will not be done yet, until better 545 understood and scoped. This part is of special interest for 546 operators and would be required in order to actually put SFC 547 mechanisms into operation. 549 Potential gap: redundancy and reliability mechanisms are currently 550 not dealt with by any WG in the IETF. While this has been the main 551 goal of the VNFpool BoF efforts, it still remains un-addressed. 553 4.2. NVO3 WG 555 The Network Virtualization Overlays (NVO3) WG is developing protocols 556 that enable network virtualization overlays within large Data Center 557 (DC) environments. Specifically NVO3 assumes an underlying physical 558 Layer 3 (IP) fabric on which multiple tenant networks are virtualized 559 on top (i.e. overlays). With overlays, data traffic between tenants 560 is tunneled across the underlying DC's IP network. The use of 561 tunnels provides a number of benefits by decoupling the network as 562 viewed by tenants from the underlying physical network across which 563 they communicate [I-D.ietf-nvo3-arch]. 565 Potential gap: It would be worthwhile to see if some of the specific 566 approaches developed in this WG (e.g. overlays, traffic isolation, VM 567 migration) can be applied outside the DC, and specifically if they 568 can be applicable to network virtualization (NFV). These approaches 569 would be most relevant to the ETSI Network Function Virtualization 570 Infrastructure (NFVI), and the Virtualized Infrastructure Manager 571 part of the MANO. 573 4.3. DMM WG 575 The Distributed Mobility Management (DMM) WG is looking at solutions 576 for IP networks that enable traffic between mobile and correspondent 577 nodes taking an optimal route, preventing some of the issues caused 578 by the use of centralized mobility solutions, which anchor all the 579 traffic at a given node (or a very limited set of nodes). The DMM WG 580 is considering the latest developments in mobile networking research 581 and operational practices (i.e., flattening network architectures, 582 the impact of virtualization, new deployment needs as wireless access 583 technologies evolve in the coming years) and aims at describing how 584 distributed mobility management addresses the new needs in this area 585 better than previously standardized solutions. 587 Although network virtualization is not the main area of the DMM work, 588 the impact of SDN and NFV mechanisms is clear on the work that is 589 currently being done in the WG. One example is architecture defined 590 for the virtual Evolved Packet Core (vEPC) in 591 [I-D.matsushima-stateless-uplane-vepc]. Here, the authors describe a 592 particular realization of the vEPC concept, which is designed to 593 support NFV. In the defined architecture, the user plane of EPC is 594 decoupled from the control-plane and uses routing information to 595 forward packets of mobile nodes. This proposal does not modify the 596 signaling of the EPC control plane, although the EPC control plane 597 runs on an hypervisor. 599 Potential gap: in a vEPC/DMM context, how to run the EPC control 600 plane on NFV. 602 The DMM WG is also looking at ways to supporting the separation of 603 the Control-Plane for mobility- and session management from the 604 actual Data-Plane [I-D.ietf-dmm-fpc-cpdp]. The protocol semantics 605 being defined abstract from the actual details for the configuration 606 of Data-Plane nodes and apply between a Client function, which is 607 used by an application of the mobility Control-Plane, and an Agent 608 function, which is associated with the configuration of Data-Plane 609 nodes according to the policies issued by the mobility Control-Plane. 611 Potential gap: the actual mappings between these generic protocol 612 semantics and the configuration commands required on the data plane 613 network elements are not in the scope of this document, and are 614 therefore a potential gap that will need to be addressed (e.g., for 615 OpenFlow switches). 617 4.4. I2RS WG 619 The Interface to the Routing System (I2RS) WG is developing a high- 620 level architecture that describes the basic building-blocks to access 621 the routing system through a set of protocol-based control or 622 management interfaces. This architecture, as described in 623 [I-D.ietf-i2rs-architecture], comprises an I2RS Agent as a unified 624 interface that is accessed by I2RS clients using the I2RS protocol. 625 The client is controlled by one or more network applications and 626 accesses one or more agents, as shown in the following figure: 628 ****************** ***************** ***************** 629 * Application C * * Application D * * Application E * 630 ****************** ***************** ***************** 631 | | | 632 +--------------+ | +-------------+ 633 | | | 634 *************** 635 * Client P *----------------------+ 636 *************** | 637 *********************** | | 638 * Application A * | | 639 * * | *********************** | 640 * +----------------+ * | * Application B * | 641 * | Client A | * | * * | 642 * +----------------+ * | * +----------------+ * | 643 *********************** | * | Client B | * | 644 | | * +----------------+ * | 645 | +----------------+ *********************** | 646 | | | | | 647 | | +------------------------+ | +-----+ 648 | | | | | 649 ******************************* ******************************* 650 * * * * 651 * Routing Element 1 * * Routing Element 2 * 652 * * * * 653 ******************************* ******************************* 655 Figure 4: High level I2RS architecture 657 Routing elements consist of an agent that communicates with the 658 client or clients driven by the applications and accesses the 659 different subsystems in the element as shown in the following figure: 661 | 662 *****************v************** 663 * +---------------------+ * 664 * | Agent | * 665 * +---------------------+ * 666 * ^ ^ ^ ^ * 667 * | | | | * 668 * | | | +--+ * 669 * | | | | * 670 * v | | v * 671 * +---+-----+ | | +----+---+ * 672 * | Routing | | | | Local | * 673 * | and | | | | Config | * 674 * |Signaling| | | +--------+ * 675 * +---------+ | | ^ * 676 * ^ | | | * 677 * | +----+ | | * 678 * v v v v * 679 * +----------+ +------------+ * 680 * | Dynamic | | Static | * 681 * | System | | System | * 682 * | State | | State | * 683 * +----------+ +------------+ * 684 * * 685 * Routing Element * 686 ******************************** 688 Figure 5: Architecture of a routing element 690 The I2RS architecture proposes to use model-driven APIs. Services 691 can correspond to different data-models and agents can indicate which 692 model they support. 694 Potential gap: network virtualization is not the main aim of the I2RS 695 WG. However, they provide an infrastructure that can be part of an 696 SDN deployment. 698 4.5. BESS WG 700 BGP is already used as a protocol for provisioning and operating 701 Layer-3 (routed) Virtual Private Networks (L3VPNs). The BGP Enabled 702 Services (BESS) working group is responsible for defining, 703 specifying, and extending network services based on BGP. In 704 particular, the working group will work on the following services: 706 o BGP-enabled VPN solutions for use in the data center networking. 707 This work includes consideration of VPN scaling issues and 708 mechanisms applicable to such environments. 710 o Extensions to BGP-enabled VPN solutions for the construction of 711 virtual topologies in support of services such as Service Function 712 Chaining. 714 Potential gap: The most relevant activity in BESS that would be 715 worthwhile to investigate for relevance to network virtualization 716 (NFV) is the extensions to BGP-enabled VPN solutions to support of 717 Service Function Chaining [I-D.rfernando-bess-service-chaining]. 719 4.6. VNFpool BoF 721 The VNFPOOL BoF is working on the way to group Virtual Network 722 Function (VNF) into pools to improve resilience, provide better 723 scale-out and scale-in characteristics, implement stateful failover 724 among VNF members of a pool, etc. Additionally, they propose to 725 create VNF sets from VNF pools. For this, the BoF proposes to study 726 signaling (both between members of a pool and across pools), state 727 sharing mechanisms between members of a VNFPOOL, the exchange of 728 reliability information between VNF sets, their users and the 729 underlying network, and the reliability and security of the control 730 plane needed to transport the exchanged information. 732 The VNFPOOL BoF started work on the charter, use case study, and 733 requirements and initial architecture. The use cases include Content 734 Deliver Networks (CDNs), the LTE mobile core network and reliable 735 server pooling. Currently, there is no activity on the mailing list 736 setup for this activity. 738 Potential gap: VNFPOOL tries to introduce and manage resilience in 739 virtualized networking environments and therefore addresses a 740 desirable feature for any software defined network. VNFPOOL has also 741 been integrated into the NFV architecture 742 [I-D.bernini-nfvrg-vnf-orchestration]. 744 4.7. TEAS WG 746 Transport network infrastructure provides end-to-end connectivity for 747 networked applications and services. Network virtualization 748 facilitates effective sharing (or 'slicing') of physical 749 infrastructure by representing resources and topologies via 750 abstractions, even in a multi-administration, multi-vendor, multi- 751 technology environment. In this way, it becomes possible to operate, 752 control and manage multiple physical networks elements as single 753 virtualized network. The users of such virtualized network can 754 control the allocated resources in an optimal and flexible way, 755 better adapting to the specific circumstances of higher layer 756 applications. 758 Abstraction and Control of Transport Networks (ACTN) intends to 759 define methods and capabilities for the deployment and operation of 760 transport network resources [I-D.ceccarelli-teas-actn-framework]. 761 This activity is currently being carried out within the Traffic 762 Engineering Architecture and Signaling (TEAS) WG. 764 Several use cases are being proposed for both fixed and mobile 765 scenarios [I-D.leeking-teas-actn-problem-statement]. 767 Potential gap: Several use cases in ACTN are relevant to network 768 virtualization (NFV) in mobile environments. Control of multi-tenant 769 mobile backhaul transport networks, mobile virtual network operation, 770 etc, can be influenced by the location of the network functions. A 771 control architecture allowing for inter-operation of NFV and 772 transport network (e.g., for combined optimization) is one relevant 773 area for research. 775 4.8. I2NSF BoF 777 The I2NSF BoF aims at defining interfaces to the flow based network 778 security functions (NSFs) hosted by service providers at different 779 premises. Network Security Function (NSF) is to ensure integrity, 780 confidentiality and availability of network communications, to detect 781 unwanted activity, and to block it or at least mitigate its effects. 782 NSFs are provided and consumed in increasingly diverse environments. 783 Users of NSFs could consume network security services hosted by one 784 or more providers, which may be their own enterprise, service 785 providers, or a combination of both. The NSFs may be provided by 786 physical and/or virtualized infrastructure. 788 Without standard interfaces to express, monitor, and control security 789 policies that govern the behavior of NSFs, it becomes virtually 790 impossible for security service providers to automate their service 791 offerings that utilize different security functions from multiple 792 vendors. Based on this, the main goal of I2NSF is to define an 793 information model, a set of software interfaces and data models for 794 controlling and monitoring aspects of NSFs (both physical and 795 virtual) [I-D.jeong-i2nsf-sdn-security-services]. 797 Since different security vendors may support different features and 798 functions on their devices, I2NSF focuses on flow based NSFs that 799 provide treatment to packets/flow. 801 The I2NSF WG's target deliverables include: (i) a use cases, problem 802 statement, gap analysis document, (ii) a framework document, 803 presenting an overview of the use of NSFs and the purpose of the 804 models developed by the WG, (iii) a single, unified, Information 805 Model for controlling and monitoring flow-based NSFs, (iv) the 806 corresponding YANG Data Models derived from the Information Model, 807 and (v) an IANA registry consideration for flow-based NSFs 808 controlling and monitoring capabilities. It is also targeted to work 809 closely with I2RS, Netconf and Netmod WGs, as well as to communicate 810 with external SDOs like ETSI NFV. 812 Potential gap: aspects of NSFs such as device or network provisioning 813 and configuration are out of scope. 815 Potential gap: the use of SDN tools to interact with security 816 functions is not explictly considered, but seems a potential 817 approach, as for example described for the particular case of IPsec 818 flow protection in [I-D.abad-sdnrg-sdn-ipsec-flow-protection]. 820 4.9. IPPM WG 822 The IP Performance Metrics (IPPM) WG defines metrics that can be used 823 to measure the quality and performance of Internet services and 824 applications running over transport layer protocols (e.g. TCP, UPD) 825 over IP. It also develops and maintains protocols for the 826 measurement of these metrics. The IPPM WG is a long running WG that 827 started in 1997. The architecture (framework) for IPPM WG metrics 828 and associated protocols are defined in RFC 2330 [RFC2330]. Some 829 examples of recent output by IPPM WG include "A Reference Path and 830 Measurement Points for Large-Scale Measurement of Broadband 831 Performance" (RFC 7398 [RFC7398]) and "Framework for TCP Throughput 832 Testing" (RFC 6349 [RFC6349]). The IPPM WG currently does not have a 833 charter item or active drafts related to the topic of network 834 virtualization. 836 Potential gap: There is a pressing need to define metrics and 837 associated protocols to measure the performance of NFV. 838 Specifically, since NFV is based on the concept of taking centralized 839 functions and evolving it to highly distributed SW functions, there 840 is a commensurate need to fully understand and measure the baseline 841 performance of such systems. A potential topic for the IPPM WG is 842 defining packet delay, throughput, and test framework for the 843 application traffic flowing through the NFVI. 845 4.10. NFV RG 847 The NFVRG focuses on research problems associated with virtualization 848 of fixed and mobile network infrastructures, new network 849 architectures based on virtualized network functions, virtualization 850 of the home and enterprise network environments, co-existence with 851 non-virtualized infrastructure and services, and application to 852 growing areas of concern such as Internet of Things (IoT) and next 853 generation content distribution. Another goal of the NFVRG is to 854 bring a research community together that can jointly address such 855 problems, concentrating on problems that relate not just to 856 networking but also to computing and storage constraints in such 857 environments. 859 Since the NFVRG is a research group, it has a wide scope. In order 860 to keep the focus, the group has identified some near term work 861 items: (i) Policy based Resource Management, (ii) Analytics for 862 Visibility and Orchestration, (iii) Virtual Network Function (VNF) 863 Performance Modelling to facilitate transition to NFV and (iv) 864 Security and Service Verification. 866 4.11. SDN RG 868 The SDNRG provides the grounds for an open-minded investigation of 869 Software Defined Networking. They aim at identifying approaches that 870 can be defined and used in the near term as well as the research 871 challenges in the field. As such, they SDNRG will not define 872 standards, but provide inputs to standards defining and standards 873 producing organizations. 875 It is working on classifying SDN models, including definitions and 876 taxonomies. It is also studying complexity, scalability and 877 applicability of the SDN model. Additionally, the SDNRG is working 878 on network description languages (and associated tools), abstractions 879 and interfaces. They also investigate the verification of correct 880 operation of network or node function. 882 The SDNRG has produced a reference layer model RFC7426 [RFC7426], 883 which structures SDNs in planes and layers which are glued together 884 by different abstraction layers. This architecture differentiates 885 between the control and the management planes and provides for 886 differentiated southbound interfaces (SBIs). 888 5. Summary of Gaps 890 Potential Gap-1: as stated in the SFC charter, any work on the 891 management and configuration of SFC components related to the support 892 of Service Function Chaining will not be done yet, until better 893 understood and scoped. This part is of special interest for 894 operators and would be required in order to actually put SFC 895 mechanisms into operation. 897 Potential Gap-2: redundancy and reliability mechanisms are currently 898 not dealt with by SFC or any other WG in the IETF. While this has 899 been the main goal of the VNFpool BoF efforts, it still remains un- 900 addressed. 902 Potential Gap-3: it would be worthwhile to see if some of the 903 specific approaches developed in the NVO3 WG (e.g. overlays, traffic 904 isolation, VM migration) can be applied outside the DC, and 905 specifically if they can be applicable to network virtualization 906 (NFV). These approaches would be most relevant to the ETSI Network 907 Function Virtualization Infrastructure (NFVI), and the Virtualized 908 Infrastructure Manager part of the MANO. 910 Potential Gap-4: the most relevant activity in BESS that would be 911 worthwhile to investigate for relevance to network virtualization 912 (NFV) is the extensions to BGP-enabled VPN solutions to support of 913 Service Function Chaining. 915 Potential Gap-5: in a vEPC/DMM context, how to run the EPC control 916 plane on NFV. 918 Potential Gap-6: in DMM, on the work item addressing the separation 919 of the Control-Plane for mobility- and session management from the 920 actual Data-Plane, the actual mappings between these generic protocol 921 semantics and the configuration commands required on the data plane 922 network elements (e.g., OpenFlow switches) are not currently in the 923 scope of the DMM WG. 925 Potential Gap-7: network virtualization is not the main aim of the 926 I2RS WG. However, they provide an infrastructure that can be part of 927 an SDN deployment. 929 Potential Gap-8: VNFPOOL tries to introduce and manage resilience in 930 virtualized networking environments and therefore addresses a 931 desirable feature for any software defined network. VNFPOOL has also 932 been integrated into the NFV architecture 933 [I-D.bernini-nfvrg-vnf-orchestration]. 935 Potential Gap-9: within the Traffic Engineering Architecture and 936 Signaling (TEAS) WG, several use cases in ACTN are relevant to 937 network virtualization (NFV) in mobile environments. Control of 938 multi-tenant mobile backhaul transport networks, mobile virtual 939 network operation, etc, can be influenced by the location of the 940 network functions. A control architecture allowing for inter- 941 operation of NFV and transport network (e.g., for combined 942 optimization) is one relevant area for research. 944 Potential Gap-10: within I2NSF', aspects of NSFs such as device or 945 network provisioning and configuration are out of scope. 947 Potential Gap-11: the use of SDN tools to interact with security 948 functions is not explictly considered in I2NSF, but seems a potential 949 approach, as for example described for the particular case of IPsec 950 flow protection in [I-D.abad-sdnrg-sdn-ipsec-flow-protection]. 952 Potential Gap-12: there is a pressing need to define metrics and 953 associated protocols to measure the performance of NFV. 954 Specifically, since NFV is based on the concept of taking centralized 955 functions and evolving it to highly distributed SW functions, there 956 is a commensurate need to fully understand and measure the baseline 957 performance of such systems. A potential topic for the IPPM WG is 958 defining packet delay, throughput, and test framework for the 959 application traffic flowing through the NFVI. 961 6. IANA Considerations 963 N/A. 965 7. Security Considerations 967 TBD. 969 8. Acknowledgments 971 The authors want to thank Dirk von Hugo, Rafa Marin, Diego Lopez, 972 Ramki Krishnan and Kostas Pentikousis for their very useful reviews 973 and comments to the document. 975 The work of Pedro Aranda is supported by the European FP7 Project 976 Trilogy2 under grant agreement 317756. 978 9. References 980 9.1. Normative References 982 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 983 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 984 RFC2119, March 1997, 985 . 987 9.2. Informative References 989 [I-D.abad-sdnrg-sdn-ipsec-flow-protection] 990 Abad-Carrascosa, A., Lopez, R., and G. Lopez-Millan, 991 "Software-Defined Networking (SDN)-based IPsec Flow 992 Protection", draft-abad-sdnrg-sdn-ipsec-flow-protection-00 993 (work in progress), July 2015. 995 [I-D.bernini-nfvrg-vnf-orchestration] 996 Bernini, G., Maffione, V., Lopez, D., and P. Aranda, "VNF 997 Orchestration For Automated Resiliency in Service Chains", 998 draft-bernini-nfvrg-vnf-orchestration-00 (work in 999 progress), July 2015. 1001 [I-D.ceccarelli-teas-actn-framework] 1002 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 1003 Control of Transport Networks", draft-ceccarelli-teas- 1004 actn-framework-00 (work in progress), June 2015. 1006 [I-D.ietf-dmm-fpc-cpdp] 1007 Liebsch, M., Matsushima, S., Gundavelli, S., and D. Moses, 1008 "Protocol for Forwarding Policy Configuration (FPC) in 1009 DMM", draft-ietf-dmm-fpc-cpdp-01 (work in progress), July 1010 2015. 1012 [I-D.ietf-i2rs-architecture] 1013 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1014 Nadeau, "An Architecture for the Interface to the Routing 1015 System", draft-ietf-i2rs-architecture-09 (work in 1016 progress), March 2015. 1018 [I-D.ietf-nvo3-arch] 1019 Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 1020 Narten, "An Architecture for Overlay Networks (NVO3)", 1021 draft-ietf-nvo3-arch-03 (work in progress), March 2015. 1023 [I-D.ietf-sfc-architecture] 1024 Halpern, J. and C. Pignataro, "Service Function Chaining 1025 (SFC) Architecture", draft-ietf-sfc-architecture-11 (work 1026 in progress), July 2015. 1028 [I-D.jeong-i2nsf-sdn-security-services] 1029 Jeong, J., Kim, H., and P. Jung-Soo, "Software-Defined 1030 Networking Based Security Services using Interface to 1031 Network Security Functions", draft-jeong-i2nsf-sdn- 1032 security-services-02 (work in progress), July 2015. 1034 [I-D.leeking-teas-actn-problem-statement] 1035 Lee, Y., King, D., Boucadair, M., Jing, R., and L. 1036 Contreras, "Problem Statement for Abstraction and Control 1037 of Transport Networks", draft-leeking-teas-actn-problem- 1038 statement-00 (work in progress), June 2015. 1040 [I-D.matsushima-stateless-uplane-vepc] 1041 Matsushima, S. and R. Wakikawa, "Stateless user-plane 1042 architecture for virtualized EPC (vEPC)", draft- 1043 matsushima-stateless-uplane-vepc-05 (work in progress), 1044 September 2015. 1046 [I-D.rfernando-bess-service-chaining] 1047 Fernando, R., Rao, D., Fang, L., Napierala, M., So, N., 1048 and A. Farrel, "Virtual Topologies for Service Chaining in 1049 BGP/IP MPLS VPNs", draft-rfernando-bess-service- 1050 chaining-01 (work in progress), April 2015. 1052 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1053 "Framework for IP Performance Metrics", RFC 2330, DOI 1054 10.17487/RFC2330, May 1998, 1055 . 1057 [RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, 1058 "Framework for TCP Throughput Testing", RFC 6349, DOI 1059 10.17487/RFC6349, August 2011, 1060 . 1062 [RFC7398] Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 1063 A. Morton, "A Reference Path and Measurement Points for 1064 Large-Scale Measurement of Broadband Performance", RFC 1065 7398, DOI 10.17487/RFC7398, February 2015, 1066 . 1068 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 1069 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 1070 Defined Networking (SDN): Layers and Architecture 1071 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 1072 2015, . 1074 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1075 Service Function Chaining", RFC 7498, DOI 10.17487/ 1076 RFC7498, April 2015, 1077 . 1079 [etsi_nvf_whitepaper] 1080 "Network Functions Virtualisation (NFV). White Paper 2", 1081 October 2014. 1083 Appendix A. The mobile network use case 1084 A.1. The 3GPP Evolved Packet System 1086 TBD. This will include a high level summary of the 3GPP EPS 1087 architecture, detailing both the EPC (core) and the RAN (access) 1088 parts. A link with the two related ETSI NFV use cases 1089 (Virtualisation of Mobile Core Network and IMS, and Virtualisation of 1090 Mobile base station) will be included. 1092 The EPS architecture and some of its standardized interfaces are 1093 depicted in Figure 6. The EPS provides IP connectivity to user 1094 equipment (UE) (i.e., mobile nodes) and access to operator services, 1095 such as global Internet access and voice communications. The EPS 1096 comprises the core network -- called Evolved Packet Core (EPC) -- and 1097 different radio access networks: the 3GPP Access Network (AN), the 1098 Untrusted non-3GPP AN and the Trusted non-3GPP AN. There are 1099 different types of 3GPP ANs, with the evolved UMTS Terrestrial Radio 1100 Access Network (E-UTRAN) as the most advanced one. QoS is supported 1101 through an EPS bearer concept, providing bindings to resource 1102 reservation within the network. 1104 The evolved NodeB (eNB), the Long Term Evolution (LTE) base station, 1105 is part of the access network that provides radio resource 1106 management, header compression, security and connectivity to the core 1107 network through the S1 interface. In an LTE network, the control 1108 plane signaling traffic and the data traffic ar handled separately. 1109 The eNBs transmit the control traffic and data traffic separately via 1110 two logically separate interfaces. 1112 The Home Subscriber Server, HSS, is a database that contains user 1113 subscriptions and QoS profiles. The Mobility Management Entity, MME, 1114 is responsible for mobility management, user authentication, bearer 1115 establishment and modification and maintenance of the UE context. 1117 The Serving gateway, S-GW, is the mobility anchor and manages the 1118 user plane data tunnels during the inter-eNB handovers. It tunnels 1119 all user data packets and buffers downlink IP packets destined for 1120 UEs that happen to be in idle mode. 1122 The Packet Data Network (PDN) Gateway, P-GW, is responsible for IP 1123 address allocation to the UE and is a tunnel endpoint for user and 1124 control plane protocols. It is also responsible for charging, packet 1125 filtering, and policy-based control of flows. It interconnects the 1126 mobile network to external IP networks, e.g. the Internet. 1128 In this architecture, data packets are not sent directly on an IP 1129 network between the eNB and the gateways. Instead, every packet is 1130 tunneled over a tunneling protocol - the GPRS Tunneling Protocol (GTP 1131 over UDP/IP. A GTP path is identified in each node with the IP 1132 address and a UDP port number on the eNB/gateways. The GTP protocol 1133 carries both the data traffic (GTP-U tunnels) and the control traffic 1134 (GTP-C tunnels). Alternatively Proxy Mobile IP (PMIPv6) is used on 1135 the S5 interface between S-GW and P-GW. 1137 In addition to the above basic functions and entities, there are also 1138 additional features being discussed by the 3GPP that are relevant 1139 from a network virtualization viewpoint. One example is the Traffic 1140 Detection Function (TDF), which can be used by the P-GW, and in 1141 general by the whole transport network, to decide how to forward the 1142 traffic. In a virtualized infrastructure, this kinf of information 1143 can be used to elastic and dynamically adapt the network capabilities 1144 to the traffic nature and volume. 1146 +---------------------------------------------------------+ 1147 | PCRF | 1148 +-----------+--------------------------+----------------+-+ 1149 | | | 1150 +----+ +-----------+------------+ +--------+-----------+ +-+-+ 1151 | | | +-+ | | Core Network | | | 1152 | | | +------+ |S|__ | | +--------+ +---+ | | | 1153 | | | |GERAN/|_|G| \ | | | HSS | | | | | | 1154 | +-----+ UTRAN| |S| \ | | +---+----+ | | | | E | 1155 | | | +------+ |N| +-+-+ | | | | | | | x | 1156 | | | +-+ /|MME| | | +---+----+ | | | | t | 1157 | | | +---------+ / +---+ | | | 3GPP | | | | | e | 1158 | +-----+ E-UTRAN |/ | | | AAA | | | | | r | 1159 | | | +---------+\ | | | SERVER | | | | | n | 1160 | | | \ +---+ | | +--------+ | | | | a | 1161 | | | 3GPP AN \|SGW+----- S5---------------+ P | | | l | 1162 | | | +---+ | | | G | | | | 1163 | | +------------------------+ | | W | | | I | 1164 | UE | | | | | | P | 1165 | | +------------------------+ | | +-----+ | 1166 | | |+-------------+ +------+| | | | | | n | 1167 | | || Untrusted +-+ ePDG +-S2b---------------+ | | | e | 1168 | +---+| non-3GPP AN | +------+| | | | | | t | 1169 | | |+-------------+ | | | | | | w | 1170 | | +------------------------+ | | | | | o | 1171 | | | | | | | r | 1172 | | +------------------------+ | | | | | k | 1173 | +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s | 1174 | | +------------------------+ | | | | | | 1175 | | | +-+-+ | | | 1176 | +--------------------------S2c--------------------| | | | 1177 | | | | | | 1178 +----+ +--------------------+ +---+ 1180 Figure 6: EPS (non-roaming) architecture overview 1182 A.2. Virtualizing the 3GPP EPS 1184 TBD. We describe how a "virtual EPS" (vEPS) would look like and the 1185 existing gaps that exist from the point of view of network 1186 virtualization. 1188 Authors' Addresses 1189 Carlos J. Bernardos 1190 Universidad Carlos III de Madrid 1191 Av. Universidad, 30 1192 Leganes, Madrid 28911 1193 Spain 1195 Phone: +34 91624 6236 1196 Email: cjbc@it.uc3m.es 1197 URI: http://www.it.uc3m.es/cjbc/ 1199 Akbar Rahman 1200 InterDigital Communications, LLC 1201 1000 Sherbrooke Street West, 10th floor 1202 Montreal, Quebec H3A 3G4 1203 Canada 1205 Email: Akbar.Rahman@InterDigital.com 1206 URI: http://www.InterDigital.com/ 1208 Juan Carlos Zuniga 1209 InterDigital Communications, LLC 1210 1000 Sherbrooke Street West, 10th floor 1211 Montreal, Quebec H3A 3G4 1212 Canada 1214 Email: JuanCarlos.Zuniga@InterDigital.com 1215 URI: http://www.InterDigital.com/ 1217 Luis M. Contreras 1218 Telefonica I+D 1219 Ronda de la Comunicacion, S/N 1220 Madrid 28050 1221 Spain 1223 Email: luismiguel.conterasmurillo@telefonica.com 1225 Pedro Aranda 1226 Telefonica I+D 1227 Ronda de la Comunicacion, S/N 1228 Madrid 28050 1229 Spain 1231 Email: pedroa.aranda@telefonica.com