NFVRG L. Geng Internet-Draft China Mobile Intended status: Informational March 7, 2017 Expires: September 8, 2017 Distributed NFV in Scattered Premises draft-geng-nfvrg-distributed-nfv-00 Abstract This document introduces the distributed NFV (D-NFV) concept based on potential implementation in scattered locations including customer edge devices and transport network equipments. The motivation of pushing NFV entities from conventional centralized infrastructures to distributed promises is discussed, which are driven by the requirements of high flexibility, low end-to-end latency and faster time-to-market in future network. To better understand the D-NFV concept, examples of D-NFV implementation is introduced. Potential use cases are also described as references for readers. Gaps have also been recognized in the documents in terms of the investigation of appropriate virtualization technologies used in the D-NFV and corresponding management and orchestration challenges. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 8, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Geng Expires September 8, 2017 [Page 1] Internet-Draft Distributed NFV March 2017 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 4. NFV in Different Points of Presence . . . . . . . . . . . . . 3 4.1. Centralized NFV . . . . . . . . . . . . . . . . . . . . . 3 4.2. Distributed NFV . . . . . . . . . . . . . . . . . . . . . 4 5. Typical NFVI-PoPs in Distributed NFV . . . . . . . . . . . . 6 5.1. Distributed NFV in Customer Edge Devices . . . . . . . . 6 5.2. Distributed NFV in Service Provider Transport and Bearer Networks . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Use cases of Distributed NFV . . . . . . . . . . . . . . . . 7 6.1. Use Case 1 - VNFaaS and VNPaaS in Residential and Enterprise Network . . . . . . . . . . . . . . . . . . . 7 6.2. Use Case 2 - Mission Critical Services . . . . . . . . . 7 6.3. Use Case 3 - End-to-end Network Slicing Management . . . 8 6.4. Use Case 4 - Managed Multiple Provisioning for Network Elements . . . . . . . . . . . . . . . . . . . . . . . . 8 6.5. Use Case 5 - Elastic VPN . . . . . . . . . . . . . . . . 8 7. Rethinking VNFs in Distributed NFV . . . . . . . . . . . . . 8 8. Virtualization Technologies in Distributed NFV . . . . . . . 8 9. Management and Orchestration of Distributed NFV . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 12.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction As new services such as IoT start to emerge, service provider's network is required to have higher flexibility, greater security and reliable service quality guarantee from customer end to service provider core. NFV technology has been proved to be an excellent candidate to fulfil these demands for future network. And it has been widely investigated in centralized premises including data centre and mobile core network applications. To further improve overall system flexibility and performance, it is also extremely Geng Expires September 8, 2017 [Page 2] Internet-Draft Distributed NFV March 2017 interesting to explore how NFV technology can be implemented in scattered network premises. NFV make use of the virtualization technology to decouple software functions from hardware infrastructures. There is no fundamental limitations on where NFV can be applied to. Some network functions in principle are most efficient when hosted in distributed premises. In this case, it is worth to consider how these functions can be virtualized locally to maintain their efficiency whilst benefit from the flexibility, fast time-to-market deployment and new business model such as VNPaaS that NFV can offer. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Terminology and Abbreviations The terminology and abbreviations used in this document are defined in this section. o D-NFV: Distributed NFV. A system architecture where the NFV entities are distributively implemented in scattered network premises. o NFVI-PoPs: NFV infrastructure points of presence. The location where network functions are realized by VNFs. 4. NFV in Different Points of Presence In general, NFV provides decoupled software and hardware for vendor- specific network elements. Based on this principle, VNFs are allowed to be located anywhere as long as the corresponding infrastructures support. According to ETSI, proposed points of presence for NFV include customers' premises, central offices, data centres and etc. In principle, VNFs should be placed where they are most cost- effective, providing better efficiency and performances . 4.1. Centralized NFV At present, most of the NFV deployments are centralized. As an example, the evolving mobile core network is one of the most popular areas where centralized NFV deployment most likely to take place in the near future. It is accelerating its pace in the process of the transition to the next generation NFV-based architecture for 5G. In fact, most of the network functions in core network in form of Geng Expires September 8, 2017 [Page 3] Internet-Draft Distributed NFV March 2017 conventional vendor-specific network elements are intrinsically centralized. Naturally, the virtualized entities of these network functions are expected to follow the centralized architecture. +------+ Centralized NFVI-PoPs |Device| +---------------------+ | 1 | ____ | | +------+-----( )__ | +---+ +---+ +---+ | +------+ __( )_ | |VNF| |VNF| |VNF| | |Device| _( )__ + +---+ +---+ +---+ | | 2 +--( Network ) | | +------+ (___________________)---| +---------------+ | | | | NFVI | | Distributed +---+--+ | +---------------+ | Devices 1-3 |Device| +---------------------+ | 3 | +------+ Figure 1 Figure 1 illustrates the scheme diagram of a centralized NFV deployment. In centralized NFV, conventional vendor-specific network elements are realized as VNFs which reside in centralized NFVI-PoPs (i.e. private telecommunication clouds). The computing and storage hardware resources in the centralized NFV are commonly in the form of server clusters. They are normally pooled and usually span across different physical locations. Network hardware resources (i.e. switches, routers) are essential in centralized NFV to provide connectivities. These include connectivities within and between NFVI-PoPs. Given the powerful computing and storage resources benefited from clusters, centralized NFV is capable of supporting the virtualization of many complex network elements. The COTS used in NFVI also guarantees the system scalability and elastic deployment. 4.2. Distributed NFV Centralization is not an intrinsic nature of NFV. Many vendor- specific network elements located in scattered premises may also benefit from the implementation of NFV by decoupling software and hardware. Service providers used to replace these equipments or make a full system upgrade on them to deploy new functions and services. With the implementation of NFV, service providers can push new functions and services directly corresponding network elements and end users respectively simply by the deployment of new VNFs. Geng Expires September 8, 2017 [Page 4] Internet-Draft Distributed NFV March 2017 Many services need local processing provided by network functions are implemented in distributed network elements. These network functions, when virtualized, still make sense to be hosted at the same location for many reasons. Some examples are given as follows. o Security. Service requiring end-to-end security has to be implemented from the customer end. VNF for such purposes, i.e. encryption are preferred to be hosted locally. o Latency. Mission critical services are very sensitive to latency. Local precessing is preferred to minimize the round trip latency. o Resilience. In some scenarios where services are provided remotely in the cloud, customers want their internal networks and services to keep working when there is a network failure. Locally hosted VNFs can work as backups for this purpose. D-NFV focuses on the scenarios where the NFVI-PoPs locate in scattered premises. Common infrastructures seen in these premises include but are not limited to end-user devices, customer premises equipment and dedicated network equipments in transport and bearer networks. Distributed NFVI-PoP 1 +-------------+ | +---+ +---+ | | |VNF| |VNF| | | +---+ +---+ | Distributed | NFVI | NFVI-PoP 2 +-------------+ +-------------+ _|__ | +---+ +---+ | ( )__ +--------------+ | |VNF| |VNF| +-------( )_ | Centralized | | +---+ +---+ | _( +------------+Infrastructure| | NFVI | ( Network ) | (Data Center)| +-------------+ (___________________) +--------------+ | +-------------+ Distributed | +---+ +---+ | NFVI-PoP 3 | |VNF| |VNF| | | +---+ +---+ | | NFVI | +-------------+ Figure 2 Geng Expires September 8, 2017 [Page 5] Internet-Draft Distributed NFV March 2017 Figure 2 illustrates the scheme diagram of a D-NFV deployment in customer premises. Instead of nested with integrated software and hardware, the CPE provides NFVI for various VNFs. Since the VNFs are decoupled with the hardware resources, service provider can dynamically deploy corresponding VNFs according to performance and customer requirements. The hardware resources in scattered premises are normally different from that in centralized data centres. Typical examples include SoCs and individual servers. Given the fact that these infrastructures are not designed to be clustered, the network hardware between NFVI- PoPs of D-NFV is not as essential as that of centralized scenario. However, specific services may require network connectivity between NFVI-PoPs to achieve better performances. Network connectivity within NFVI-PoPs in D-NFV may be required depending on the actual design of the VNF entities.Given the limited computing and storage resources, VNFs in the D-NFV should be normally much less resource- hungry than those in centralized NFV. 5. Typical NFVI-PoPs in Distributed NFV D-NFV focuses on NFV implementations in scattered locations. This section introduces 2 typical examples of NFVI-PoPs including customer edge devices and transport network equipments. 5.1. Distributed NFV in Customer Edge Devices A customer edge device is the first service-provider-owned device for an end-user to connect to the network and subscribe to specific services. This device is normally purchased by service providers with required functionalities. Accordingly, it normally has well- defined hardware and vendor-specific software. In residential network, customer edge devices are typically in forms of WiFi routers, with various uplink interface including PON, xDSL and cellular. Service providers used to provide only internet access to residential users and the customer edge devices were rather simple. Recently, many service provider started to provide value- added services such as IPTV, VoIP, home storage, remote download and VPNs. Accordingly, the concept of "intelligent home gateway" is introduced, which enables the residential customer edge device to dynamically implement new services by downloading applications. These application are normally realized as C and Java modules. D-NFV is another way to provide application and hardware decoupling, with extra benefits of better isolation between applications, improved service security, high reliability, managed resource allocation and comprehensive device capability exposure. As IoT services start to emerge in residential market, D-NFV can improve overall deployment Geng Expires September 8, 2017 [Page 6] Internet-Draft Distributed NFV March 2017 flexibility and generate potential new business model by providing guaranteed isolation, resources and deep capability exposure for different value-added service providers Other example of customer edge devices include enterprise premise and industrial premise equipment. There are plenty of services which require local implementation and flexible deployment for optimized performance. For example, WAN acceleration and firewalls have best efficiency when they are implemented locally. Meanwhile, low latency services such as manufacture plant control and item tracking in industrial network also require extremely high reliability which need dedicatedly allocated hardware and network resources. 5.2. Distributed NFV in Service Provider Transport and Bearer Networks The application of NFV in service provider transport network has been investigated mostly in combination of SDN technology. It is interesting to see that NFV as a technology is applied to transport network as a way of implementing the separated control plane in centralized infrastructure. This can be seen as a coordination of SDN and NFV technology with the control plane decoupled and virtualized. Indeed, as a data plane network equipment, current virtualization technologies are not efficient enough to provide data forwarding performance comparable to network processing chips used in these devices. However, it is attractive to use NFV technology in these network equipment to provide isolated management and control plane. There is great potential for service providers to exploit this technology for a much more flexible management and control model for data plane equipments at a sliced granularity. 6. Use cases of Distributed NFV In this version, several use cases are listed for general references. Descriptions in detail are subjected to be added according to initial discussion in the group. The author would also like to call for more use cases for D-NFV identified by the community. 6.1. Use Case 1 - VNFaaS and VNPaaS in Residential and Enterprise Network 6.2. Use Case 2 - Mission Critical Services Geng Expires September 8, 2017 [Page 7] Internet-Draft Distributed NFV March 2017 6.3. Use Case 3 - End-to-end Network Slicing Management 6.4. Use Case 4 - Managed Multiple Provisioning for Network Elements 6.5. Use Case 5 - Elastic VPN 7. Rethinking VNFs in Distributed NFV In centralized NFV, VNFs are normally virtualized forms of conventional network elements. Sometimes, the network function of a network element may be broken into multiple VNFs for specific implementation considerations. In D-NFVs, VNFs are typically not a full representation of any existing network element. They are more like applications or new services that are pushed to the customer or equipments. As distributed NFVI-PoP are normally limited in hardware resources, VNFs with complex functionalities are not recommended in these infrastructures. Meanwhile, as VNFs in D-NFV are subjected to be application-specific, it is expected that the variety of VNFs in D-NFV will proportionally grow with the number of services provided through the network. Hence, these VNFs need to have fast time-to- market and adapt to practices like DevOps. 8. Virtualization Technologies in Distributed NFV The D-NFV may need to consider various virtulization technologies that are different from centralized NFV, as VNFs in D-NFV are expected in much smaller granularities. In this case, container- based virtualization technology may be preferred. This is also due to the potential large number of VNFs and limited hardware resources provided in distributed NFVI-PoPs. Further studies need to be carried out to investigate the appropriated virtualization technologies used in different scenarios of D-NFV 9. Management and Orchestration of Distributed NFV The management and orchestration of D-NFV need to consider the following difference compared with that of centralized NFV. o Individually located NFVI and VIM - The nature of D-NFV decide the scattered locations of NFVI-PoPs. In addition, the limited hardware resources are unlikely to support a full MANO implementation in distributed NFVI-PoPs and this is simply not cost-efficient and makes the overall system complicated. Hence a centralized MANO is expected as a feasible solution. This introduce a rather diverted model for the virtualization layer Geng Expires September 8, 2017 [Page 8] Internet-Draft Distributed NFV March 2017 management where the VIM and NFVI will locate in centralized and distributed infrastructure respectively. o Massive number of NFVI-PoPs and VNFs - Distributed NFVI-PoPs have a large number in quantity. Taking the residential NFVI-PoP as an example, the number is expected to be millions for a service provide with a fair size business. This does not count the potential industrial and IoT applications which introduce even more. The number of VNFs need to be provisioned can be easily 10-100 times of the NFVI-PoPs. The traditional MANO intrinsically designed for data center applications simply does not fit. It is also too heavy for this purpose - D-NFV may not need such comprehensive resource and network provisioning. The management and orchestration for D-NFV needs to be redesigned. 10. IANA Considerations This memo includes no request to IANA. 11. Security Considerations TBA 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, DOI 10.17487/RFC2629, June 1999, . 12.2. Informative References [ETSI-GS-NFV-002] ETSI, "ETSI GS NFV 002", 2014, . Author's Address Geng Expires September 8, 2017 [Page 9] Internet-Draft Distributed NFV March 2017 Liang Geng China Mobile Email: gengliang@chinamobile.com Geng Expires September 8, 2017 [Page 10]