idnits 2.17.1 draft-geng-nfvrg-distributed-nfv-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 (March 7, 2017) is 2600 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2629' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'ETSI-GS-NFV-002' is defined on line 415, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFVRG L. Geng 3 Internet-Draft China Mobile 4 Intended status: Informational March 7, 2017 5 Expires: September 8, 2017 7 Distributed NFV in Scattered Premises 8 draft-geng-nfvrg-distributed-nfv-00 10 Abstract 12 This document introduces the distributed NFV (D-NFV) concept based on 13 potential implementation in scattered locations including customer 14 edge devices and transport network equipments. The motivation of 15 pushing NFV entities from conventional centralized infrastructures to 16 distributed promises is discussed, which are driven by the 17 requirements of high flexibility, low end-to-end latency and faster 18 time-to-market in future network. To better understand the D-NFV 19 concept, examples of D-NFV implementation is introduced. Potential 20 use cases are also described as references for readers. Gaps have 21 also been recognized in the documents in terms of the investigation 22 of appropriate virtualization technologies used in the D-NFV and 23 corresponding management and orchestration challenges. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 8, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 62 4. NFV in Different Points of Presence . . . . . . . . . . . . . 3 63 4.1. Centralized NFV . . . . . . . . . . . . . . . . . . . . . 3 64 4.2. Distributed NFV . . . . . . . . . . . . . . . . . . . . . 4 65 5. Typical NFVI-PoPs in Distributed NFV . . . . . . . . . . . . 6 66 5.1. Distributed NFV in Customer Edge Devices . . . . . . . . 6 67 5.2. Distributed NFV in Service Provider Transport and Bearer 68 Networks . . . . . . . . . . . . . . . . . . . . . . . . 7 69 6. Use cases of Distributed NFV . . . . . . . . . . . . . . . . 7 70 6.1. Use Case 1 - VNFaaS and VNPaaS in Residential and 71 Enterprise Network . . . . . . . . . . . . . . . . . . . 7 72 6.2. Use Case 2 - Mission Critical Services . . . . . . . . . 7 73 6.3. Use Case 3 - End-to-end Network Slicing Management . . . 8 74 6.4. Use Case 4 - Managed Multiple Provisioning for Network 75 Elements . . . . . . . . . . . . . . . . . . . . . . . . 8 76 6.5. Use Case 5 - Elastic VPN . . . . . . . . . . . . . . . . 8 77 7. Rethinking VNFs in Distributed NFV . . . . . . . . . . . . . 8 78 8. Virtualization Technologies in Distributed NFV . . . . . . . 8 79 9. Management and Orchestration of Distributed NFV . . . . . . . 8 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 84 12.2. Informative References . . . . . . . . . . . . . . . . . 9 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 87 1. Introduction 89 As new services such as IoT start to emerge, service provider's 90 network is required to have higher flexibility, greater security and 91 reliable service quality guarantee from customer end to service 92 provider core. NFV technology has been proved to be an excellent 93 candidate to fulfil these demands for future network. And it has 94 been widely investigated in centralized premises including data 95 centre and mobile core network applications. To further improve 96 overall system flexibility and performance, it is also extremely 97 interesting to explore how NFV technology can be implemented in 98 scattered network premises. 100 NFV make use of the virtualization technology to decouple software 101 functions from hardware infrastructures. There is no fundamental 102 limitations on where NFV can be applied to. Some network functions 103 in principle are most efficient when hosted in distributed premises. 104 In this case, it is worth to consider how these functions can be 105 virtualized locally to maintain their efficiency whilst benefit from 106 the flexibility, fast time-to-market deployment and new business 107 model such as VNPaaS that NFV can offer. 109 2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 3. Terminology and Abbreviations 117 The terminology and abbreviations used in this document are defined 118 in this section. 120 o D-NFV: Distributed NFV. A system architecture where the NFV 121 entities are distributively implemented in scattered network 122 premises. 124 o NFVI-PoPs: NFV infrastructure points of presence. The location 125 where network functions are realized by VNFs. 127 4. NFV in Different Points of Presence 129 In general, NFV provides decoupled software and hardware for vendor- 130 specific network elements. Based on this principle, VNFs are allowed 131 to be located anywhere as long as the corresponding infrastructures 132 support. According to ETSI, proposed points of presence for NFV 133 include customers' premises, central offices, data centres and etc. 134 In principle, VNFs should be placed where they are most cost- 135 effective, providing better efficiency and performances . 137 4.1. Centralized NFV 139 At present, most of the NFV deployments are centralized. As an 140 example, the evolving mobile core network is one of the most popular 141 areas where centralized NFV deployment most likely to take place in 142 the near future. It is accelerating its pace in the process of the 143 transition to the next generation NFV-based architecture for 5G. In 144 fact, most of the network functions in core network in form of 145 conventional vendor-specific network elements are intrinsically 146 centralized. Naturally, the virtualized entities of these network 147 functions are expected to follow the centralized architecture. 149 +------+ Centralized NFVI-PoPs 150 |Device| +---------------------+ 151 | 1 | ____ | | 152 +------+-----( )__ | +---+ +---+ +---+ | 153 +------+ __( )_ | |VNF| |VNF| |VNF| | 154 |Device| _( )__ + +---+ +---+ +---+ | 155 | 2 +--( Network ) | | 156 +------+ (___________________)---| +---------------+ | 157 | | | NFVI | | 158 Distributed +---+--+ | +---------------+ | 159 Devices 1-3 |Device| +---------------------+ 160 | 3 | 161 +------+ 163 Figure 1 165 Figure 1 illustrates the scheme diagram of a centralized NFV 166 deployment. In centralized NFV, conventional vendor-specific network 167 elements are realized as VNFs which reside in centralized NFVI-PoPs 168 (i.e. private telecommunication clouds). 170 The computing and storage hardware resources in the centralized NFV 171 are commonly in the form of server clusters. They are normally 172 pooled and usually span across different physical locations. Network 173 hardware resources (i.e. switches, routers) are essential in 174 centralized NFV to provide connectivities. These include 175 connectivities within and between NFVI-PoPs. Given the powerful 176 computing and storage resources benefited from clusters, centralized 177 NFV is capable of supporting the virtualization of many complex 178 network elements. The COTS used in NFVI also guarantees the system 179 scalability and elastic deployment. 181 4.2. Distributed NFV 183 Centralization is not an intrinsic nature of NFV. Many vendor- 184 specific network elements located in scattered premises may also 185 benefit from the implementation of NFV by decoupling software and 186 hardware. Service providers used to replace these equipments or make 187 a full system upgrade on them to deploy new functions and services. 188 With the implementation of NFV, service providers can push new 189 functions and services directly corresponding network elements and 190 end users respectively simply by the deployment of new VNFs. 192 Many services need local processing provided by network functions are 193 implemented in distributed network elements. These network 194 functions, when virtualized, still make sense to be hosted at the 195 same location for many reasons. Some examples are given as follows. 197 o Security. Service requiring end-to-end security has to be 198 implemented from the customer end. VNF for such purposes, i.e. 199 encryption are preferred to be hosted locally. 201 o Latency. Mission critical services are very sensitive to latency. 202 Local precessing is preferred to minimize the round trip latency. 204 o Resilience. In some scenarios where services are provided 205 remotely in the cloud, customers want their internal networks and 206 services to keep working when there is a network failure. Locally 207 hosted VNFs can work as backups for this purpose. 209 D-NFV focuses on the scenarios where the NFVI-PoPs locate in 210 scattered premises. Common infrastructures seen in these premises 211 include but are not limited to end-user devices, customer premises 212 equipment and dedicated network equipments in transport and bearer 213 networks. 215 Distributed 216 NFVI-PoP 1 217 +-------------+ 218 | +---+ +---+ | 219 | |VNF| |VNF| | 220 | +---+ +---+ | 221 Distributed | NFVI | 222 NFVI-PoP 2 +-------------+ 223 +-------------+ _|__ 224 | +---+ +---+ | ( )__ +--------------+ 225 | |VNF| |VNF| +-------( )_ | Centralized | 226 | +---+ +---+ | _( +------------+Infrastructure| 227 | NFVI | ( Network ) | (Data Center)| 228 +-------------+ (___________________) +--------------+ 229 | 230 +-------------+ 231 Distributed | +---+ +---+ | 232 NFVI-PoP 3 | |VNF| |VNF| | 233 | +---+ +---+ | 234 | NFVI | 235 +-------------+ 237 Figure 2 239 Figure 2 illustrates the scheme diagram of a D-NFV deployment in 240 customer premises. Instead of nested with integrated software and 241 hardware, the CPE provides NFVI for various VNFs. Since the VNFs are 242 decoupled with the hardware resources, service provider can 243 dynamically deploy corresponding VNFs according to performance and 244 customer requirements. 246 The hardware resources in scattered premises are normally different 247 from that in centralized data centres. Typical examples include SoCs 248 and individual servers. Given the fact that these infrastructures 249 are not designed to be clustered, the network hardware between NFVI- 250 PoPs of D-NFV is not as essential as that of centralized scenario. 251 However, specific services may require network connectivity between 252 NFVI-PoPs to achieve better performances. Network connectivity 253 within NFVI-PoPs in D-NFV may be required depending on the actual 254 design of the VNF entities.Given the limited computing and storage 255 resources, VNFs in the D-NFV should be normally much less resource- 256 hungry than those in centralized NFV. 258 5. Typical NFVI-PoPs in Distributed NFV 260 D-NFV focuses on NFV implementations in scattered locations. This 261 section introduces 2 typical examples of NFVI-PoPs including customer 262 edge devices and transport network equipments. 264 5.1. Distributed NFV in Customer Edge Devices 266 A customer edge device is the first service-provider-owned device for 267 an end-user to connect to the network and subscribe to specific 268 services. This device is normally purchased by service providers 269 with required functionalities. Accordingly, it normally has well- 270 defined hardware and vendor-specific software. 272 In residential network, customer edge devices are typically in forms 273 of WiFi routers, with various uplink interface including PON, xDSL 274 and cellular. Service providers used to provide only internet access 275 to residential users and the customer edge devices were rather 276 simple. Recently, many service provider started to provide value- 277 added services such as IPTV, VoIP, home storage, remote download and 278 VPNs. Accordingly, the concept of "intelligent home gateway" is 279 introduced, which enables the residential customer edge device to 280 dynamically implement new services by downloading applications. 281 These application are normally realized as C and Java modules. D-NFV 282 is another way to provide application and hardware decoupling, with 283 extra benefits of better isolation between applications, improved 284 service security, high reliability, managed resource allocation and 285 comprehensive device capability exposure. As IoT services start to 286 emerge in residential market, D-NFV can improve overall deployment 287 flexibility and generate potential new business model by providing 288 guaranteed isolation, resources and deep capability exposure for 289 different value-added service providers 291 Other example of customer edge devices include enterprise premise and 292 industrial premise equipment. There are plenty of services which 293 require local implementation and flexible deployment for optimized 294 performance. For example, WAN acceleration and firewalls have best 295 efficiency when they are implemented locally. Meanwhile, low latency 296 services such as manufacture plant control and item tracking in 297 industrial network also require extremely high reliability which need 298 dedicatedly allocated hardware and network resources. 300 5.2. Distributed NFV in Service Provider Transport and Bearer Networks 302 The application of NFV in service provider transport network has been 303 investigated mostly in combination of SDN technology. It is 304 interesting to see that NFV as a technology is applied to transport 305 network as a way of implementing the separated control plane in 306 centralized infrastructure. This can be seen as a coordination of 307 SDN and NFV technology with the control plane decoupled and 308 virtualized. 310 Indeed, as a data plane network equipment, current virtualization 311 technologies are not efficient enough to provide data forwarding 312 performance comparable to network processing chips used in these 313 devices. However, it is attractive to use NFV technology in these 314 network equipment to provide isolated management and control plane. 315 There is great potential for service providers to exploit this 316 technology for a much more flexible management and control model for 317 data plane equipments at a sliced granularity. 319 6. Use cases of Distributed NFV 321 In this version, several use cases are listed for general references. 322 Descriptions in detail are subjected to be added according to initial 323 discussion in the group. The author would also like to call for more 324 use cases for D-NFV identified by the community. 326 6.1. Use Case 1 - VNFaaS and VNPaaS in Residential and Enterprise 327 Network 329 6.2. Use Case 2 - Mission Critical Services 330 6.3. Use Case 3 - End-to-end Network Slicing Management 332 6.4. Use Case 4 - Managed Multiple Provisioning for Network Elements 334 6.5. Use Case 5 - Elastic VPN 336 7. Rethinking VNFs in Distributed NFV 338 In centralized NFV, VNFs are normally virtualized forms of 339 conventional network elements. Sometimes, the network function of a 340 network element may be broken into multiple VNFs for specific 341 implementation considerations. In D-NFVs, VNFs are typically not a 342 full representation of any existing network element. They are more 343 like applications or new services that are pushed to the customer or 344 equipments. 346 As distributed NFVI-PoP are normally limited in hardware resources, 347 VNFs with complex functionalities are not recommended in these 348 infrastructures. Meanwhile, as VNFs in D-NFV are subjected to be 349 application-specific, it is expected that the variety of VNFs in 350 D-NFV will proportionally grow with the number of services provided 351 through the network. Hence, these VNFs need to have fast time-to- 352 market and adapt to practices like DevOps. 354 8. Virtualization Technologies in Distributed NFV 356 The D-NFV may need to consider various virtulization technologies 357 that are different from centralized NFV, as VNFs in D-NFV are 358 expected in much smaller granularities. In this case, container- 359 based virtualization technology may be preferred. This is also due 360 to the potential large number of VNFs and limited hardware resources 361 provided in distributed NFVI-PoPs. Further studies need to be 362 carried out to investigate the appropriated virtualization 363 technologies used in different scenarios of D-NFV 365 9. Management and Orchestration of Distributed NFV 367 The management and orchestration of D-NFV need to consider the 368 following difference compared with that of centralized NFV. 370 o Individually located NFVI and VIM - The nature of D-NFV decide the 371 scattered locations of NFVI-PoPs. In addition, the limited 372 hardware resources are unlikely to support a full MANO 373 implementation in distributed NFVI-PoPs and this is simply not 374 cost-efficient and makes the overall system complicated. Hence a 375 centralized MANO is expected as a feasible solution. This 376 introduce a rather diverted model for the virtualization layer 377 management where the VIM and NFVI will locate in centralized and 378 distributed infrastructure respectively. 380 o Massive number of NFVI-PoPs and VNFs - Distributed NFVI-PoPs have 381 a large number in quantity. Taking the residential NFVI-PoP as an 382 example, the number is expected to be millions for a service 383 provide with a fair size business. This does not count the 384 potential industrial and IoT applications which introduce even 385 more. The number of VNFs need to be provisioned can be easily 386 10-100 times of the NFVI-PoPs. The traditional MANO intrinsically 387 designed for data center applications simply does not fit. It is 388 also too heavy for this purpose - D-NFV may not need such 389 comprehensive resource and network provisioning. The management 390 and orchestration for D-NFV needs to be redesigned. 392 10. IANA Considerations 394 This memo includes no request to IANA. 396 11. Security Considerations 398 TBA 400 12. References 402 12.1. Normative References 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, 406 DOI 10.17487/RFC2119, March 1997, 407 . 409 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 410 DOI 10.17487/RFC2629, June 1999, 411 . 413 12.2. Informative References 415 [ETSI-GS-NFV-002] 416 ETSI, "ETSI GS NFV 002", 2014, 417 . 420 Author's Address 421 Liang Geng 422 China Mobile 424 Email: gengliang@chinamobile.com