Distributed NFV in Scattered Premises

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 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.

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.

The terminology and abbreviations used in this document are defined in this section. D-NFV: Distributed NFV. A system architecture where the NFV entities are distributively implemented in scattered network premises. NFVI-PoPs: NFV infrastructure points of presence. The location where network functions are realized by VNFs.

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 .

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 conventional vendor-specific network elements are intrinsically centralized. Naturally, the virtualized entities of these network functions are expected to follow the centralized architecture.

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.

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. 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. 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. Latency. Mission critical services are very sensitive to latency. Local precessing is preferred to minimize the round trip latency. 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.

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.

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.

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 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.

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.

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.

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.

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

The management and orchestration of D-NFV need to consider the following difference compared with that of centralized NFV. 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 management where the VIM and NFVI will locate in centralized and distributed infrastructure respectively. 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.

This memo includes no request to IANA.

TBA