ENFV: Edge NFV requirements project


The purpose of this Requirements Project is to articulate the capabilities and behaviours needed in Edge NFV platforms, and how they interact with centralized NFVI and MANO components of NFV solutions.

Problem description

Edge NFVI location has certain specific requirements related to:

  1. Appropriate Tunneling for User Traffic across WAN (Ethernet, IP/MPLS) links
  2. Appropriate Tunneling for Management Traffic across WAN links
  3. Including reachability requirements to the compute platform (‘eth0’ resilience, this also include backup path through other media e.g. 4G/5G)
  4. Extending Multi-data center management to address many small or micro data center locations
  5. Monitoring Capabilities required for a remote Compute Node
  6. Squaring Bare Metal with remote survivability and whether IaaS is more appropriate for remote locations
  7. Security. As demarcation technology is operated in an un-trusted environment (CSP perspective) additional means need to be implemented. Similarly, the enterprise might have concerns if the security architecture is impacted as VNFs provide functions at different locations than the precious hardware; topics like authentication, authorization, securing the traffic.

Use cases and scenarios

There are several use cases related to Edge NFV. This section will briefly describe them, along with the issues or complexities that they introduce versus a typical data center (DC) deployment.

  1. vE-CPE.

    [vE-CPE] is related to most popular NFV use case where a NFVI compute node is located at customer premises. Typical applications are virtual firewall and virtual router to replace physical equivalents. The service chain can include VNFs hosted in vE-CPE host and/or a centralized data center. Complexities include:

    • This application is very cost-sensitive, so the server will typically be lower performance than in the DC.
    • There may not be layer 2/Ethernet connectivity at the deployment site, so tunneling may be required.
    • There may not be initial connectivity to the node, so some sort of zero-touch protocol may be required.
  2. Stand-alone vE-CPE.

    It is the same as above but all virtual network functions are hosted at the same CPE compute node.

  3. Residential GW.

    Similar to vE-CPE, the major difference is scale. Typical VNFs are “WAN fault monitoring”, “Performance monitoring”. Ratio between deployed vE-CPE and Residential GW might reach 1:100 or even 1:1000, so VNF management overhead must be minimized. For instance, self-termination after predefined activity period seems preferable over explicit VNF removing via management system.

  4. Distributed Base station.

    Base station is the cellular towers that handle 3G/4G/4G LTE wireless communications with the UE at handsets, smartphones, and smart devices. The base stations are usually macro base stations. Distributed base station is a centralized base stations that are deployed in multiple units synchronized the efforts among one another.

  5. Network connectivity.

    In most cases CPE is connected to Metro Ethernet [1] .

  6. Micro Data Center

    NFVI resources may be located at the edge of the network for the use cases listed above. Doing so increases the scale of the clouds or locations that must be orchestrated and controlled. If OpenStack is run in a distributed fashion, with a central node controlling distributed NFVI servers, the following issues may be seen:

    • Lack of compatibility between different versions of OpenStack.
    • Scalability of OpenStack.
    • Operation in low speed or lossy networks is complicated by the amount of messaging required.
    • OpenStack numbers VNF ports in a sequential manner, with the sequence serially numbered in the VM/VNF. The difficulty comes when trying to verify that the LAN has been connected to the correct LAN port, the WAN has been connected to the correct WAN port and so on.
    • While OpenStack provides a rich set of APIs, critical support is lacking:
      • No APIs for ssh access to VM/VNFs.
      • No APIs for port mirroring in Neutron.
      • No APIs for OpenStack oversubscription parameter setting
[1]In all above use cases management traffic is coming inband with tenant traffic.

High level architecture and general features

Functional overview

We foresee two OpenStack deployment models:
  1. Single-cloud. Centralized OpenStack controller and ENFVI nodes are Compute nodes
  2. Multi-cloud. Each NFVI node contains OpenStack controller, thus it becomes an “embedded cloud” with single internal compute node

Architecture Overview

Architecture overview is here.

General Features and Requirements

This is main part.

High level northbound interface specification

What is northbound here? VIM controller?

Gap analysis in upstream projects

Hypervisor gaps

  1. Monitoring Capabilities required for a remote Compute Node; Hypervisor shall provide extended monitoring of VM and its resource usage.

OpenStack gaps

Later should be per specific component? (nova, neutron...)

OpenStack Nova
  1. Management system should support dozen of thousands individual hosts. Currently each Edge Host is allocated in individual zone, is this approach scalable?
  2. Host is explicitly selected effectively bypassing NOVA scheduler

Deployment gaps

  1. Only traffic interfaces are exposed (e.g. no eth0, no USB); SW deployment is different from DC.
  2. Linux shell shall not be exposed; linux CLI shall be replaced presumable by REST.
  3. Kernel and Hypervisor are hardened. Only OpenStack agents might be added during deployment.
  4. AMT or IPMI shall not be used for SW deployment.

Detailed implementation plan


Functional Blocks




Implementation plan for OPNFV Release XYZ


Information elements


Detailed northbound interface specification




Summary and conclusion


References and bibliography

[OPSK]OpenStack, [Online]. Available at https://www.openstack.org/
[ENFV]ETSI NFV, [Online]. Available at http://www.etsi.org/technologies-clusters/technologies/nfv
[vE-CPE]ETSI NFV Use Cases, [Online]. Available at http://www.etsi.org/deliver/etsi_gs/nfv/001_099/001/01.01.01_60/gs_nfv001v010101p.pdf
[security]IETF, [Online]. Available at https://tools.ietf.org/html/draft-ietf-nvo3-security-requirements-06
[firewall]OpenStack FW, [Online]. Available at http://docs.openstack.org/juno/config-reference/content/firewalls-default-ports.html


Definition of terms

Different SDOs and communities use different terminology related to NFV/Cloud/SDN. This list tries to define an OPNFV terminology, mapping/translating the OPNFV terms to terminology used in other contexts.

Customer Premises Equipment
Communication Service Provider
Data Center
Network Function Virtualization
Network Function Virtualization Infrastructure
Virtual Enterprise-Customer Premises Equipment