|
  *****************v**************
  *  +---------------------+     *
  *  |       Agent         |     *
  *  +---------------------+     *
  *     ^        ^  ^   ^        *
  *     |        |  |   |        *
  *     |        |  |   +--+     *
  *     |        |  |      |     *
  *     v        |  |      v     *
  * +---+-----+  |  | +----+---+ *
  * | Routing |  |  | | Local  | *
  * |   and   |  |  | | Config | *
  * |Signaling|  |  | +--------+ *
  * +---------+  |  |      ^     *
  *    ^         |  |      |     *
  *    |    +----+  |      |     *
  *    v    v       v      v     *
  *  +----------+ +------------+ *
  *  |  Dynamic | |   Static   | *
  *  |  System  | |   System   | *
  *  |  State   | |   State    | *
  *  +----------+ +------------+ *
  *                              *
  *       Routing Element        *
  ********************************
      

Figure 6: Architecture of a routing element

The I2RS architecture proposes to use model-driven APIs. Services can correspond to different data-models and agents can indicate which model they support.

Potential gap: network virtualization is not the main aim of the I2RS WG. However, they provide an infrastructure that can be part of an SDN deployment.

4.6. BESS WG

BGP is already used as a protocol for provisioning and operating Layer-3 (routed) Virtual Private Networks (L3VPNs). The BGP Enabled Services (BESS) working group is responsible for defining, specifying, and extending network services based on BGP. In particular, the working group will work on the following services:

• BGP-enabled VPN solutions for use in the data center networking. This work includes consideration of VPN scaling issues and mechanisms applicable to such environments.
• Extensions to BGP-enabled VPN solutions for the construction of virtual topologies in support of services such as Service Function Chaining.

Potential gap: The most relevant activity in BESS that would be worthwhile to investigate for relevance to network virtualization (NFV) is the extensions to BGP-enabled VPN solutions to support of Service Function Chaining [I-D.rfernando-bess-service-chaining].

4.7. BM WG

The Benchmarking Methodology Working Group (BMWG) provides recommendations concerning the key performance characteristics of internetworking technologies, or benchmarks for network devices, systems, and services. The scope of BMWG includes benchmarks for the management, control, and forwarding planes, and is.

The main distinguishing characteristic of BMWG from other IETF measurement initiatives like the IPPM WG is that BMWG is limited to characterization of implementations using controlled stimuli in a lab environment. The BMWG does not attempt to produce benchmarks for live, operational networks.

As part of the tasks of the BMWG, it is explicitly tasked to develop benchmarks and methodologies for VNF and related infrastructure benchmarking, Benchmarking Methodologies have reliably characterized many physical devices. This work item extends and enhances the methods to virtual network functions (VNF) and their unique supporting infrastructure. The first deliverable from this activity mentioned in the charter of the WG is a document [I-D.ietf-bmwg-virtual-net] that considers the new benchmarking space to ensure that common issues are recognized from the start, using background materials from industry and SDOs (e.g., IETF, ETSI NFV). This document investigates the additional methodological considerations necessary when benchmarking VNFs instantiated and hosted in general-purpose hardware. The approach is to benchmark physical and virtual network functions in the same way when possible, thereby allowing direct comparison. Also defining benchmarking combinations of physical and virtual devices in a System Under Test.

Benchmarks for platform capacity and performance characteristics of virtual routers, switches, and related components will be also addressed, including comparisons between physical and virtual network functions. In many cases, the traditional benchmarks should be applicable to VNFs, but the lab set-ups, configurations, and measurement methods will likely need to be revised or enhanced.

There are additional documents of the BMWG relevant to the virtualization area, such as: [I-D.ietf-bmwg-sdn-controller-benchmark-term], [I-D.ietf-bmwg-sdn-controller-benchmark-meth], [I-D.kim-bmwg-ha-nfvi] and [I-D.vsperf-bmwg-vswitch-opnfv].

4.8. TEAS WG

Transport network infrastructure provides end-to-end connectivity for networked applications and services. Network virtualization facilitates effective sharing (or ’slicing’) of physical infrastructure by representing resources and topologies via abstractions, even in a multi-administration, multi-vendor, multi-technology environment. In this way, it becomes possible to operate, control and manage multiple physical networks elements as single virtualized network. The users of such virtualized network can control the allocated resources in an optimal and flexible way, better adapting to the specific circumstances of higher layer applications.

Abstraction and Control of Transport Networks (ACTN) intends to define methods and capabilities for the deployment and operation of transport network resources [I-D.ceccarelli-teas-actn-framework]. This activity is currently being carried out within the Traffic Engineering Architecture and Signaling (TEAS) WG.

Several use cases are being proposed for both fixed and mobile scenarios [I-D.leeking-teas-actn-problem-statement].

Potential gap: Several use cases in ACTN are relevant to network virtualization (NFV) in mobile environments. Control of multi-tenant mobile backhaul transport networks, mobile virtual network operation, etc, can be influenced by the location of the network functions. A control architecture allowing for inter-operation of NFV and transport network (e.g., for combined optimization) is one relevant area for research.

4.9. I2NSF WG

The I2NSF WG at defining interfaces to the flow based network security functions (NSFs) hosted by service providers at different premises. Network Security Function (NSF) is to ensure integrity, confidentiality and availability of network communications, to detect unwanted activity, and to block it or at least mitigate its effects. NSFs are provided and consumed in increasingly diverse environments. Users of NSFs could consume network security services hosted by one or more providers, which may be their own enterprise, service providers, or a combination of both. The NSFs may be provided by physical and/or virtualized infrastructure.

Without standard interfaces to express, monitor, and control security policies that govern the behavior of NSFs, it becomes virtually impossible for security service providers to automate their service offerings that utilize different security functions from multiple vendors. Based on this, the main goal of I2NSF is to define an information model, a set of software interfaces and data models for controlling and monitoring aspects of NSFs (both physical and virtual) [I-D.jeong-i2nsf-sdn-security-services].

Since different security vendors may support different features and functions on their devices, I2NSF focuses on flow based NSFs that provide treatment to packets/flow.

The I2NSF WG’s target deliverables include: (i) a use cases, problem statement, gap analysis document, (ii) a framework document, presenting an overview of the use of NSFs and the purpose of the models developed by the WG, (iii) a single, unified, Information Model for controlling and monitoring flow-based NSFs, (iv) the corresponding YANG Data Models derived from the Information Model, (v) a vendor-neutral vocabulary to enable the characteristics and behavior of NSFs to be specified without requiring the NSFs themselves to be standardized, and (vi) an examination of existing secure communication mechanisms to identify the appropriate ones for carrying the controlling and monitoring information between the NSFs and their management entities. The WG is also targeted to work closely with I2RS, Netconf and Netmod WGs, as well as to communicate with external SDOs like ETSI NFV.

Potential gap: aspects of NSFs such as device or network provisioning and configuration are out of scope.

Potential gap: the use of SDN tools to interact with security functions is not explictly considered, but seems a potential approach, as for example described for the particular case of IPsec flow protection in [I-D.abad-sdnrg-sdn-ipsec-flow-protection].

4.10. IPPM WG

The IP Performance Metrics (IPPM) WG defines metrics that can be used to measure the quality and performance of Internet services and applications running over transport layer protocols (e.g. TCP, UPD) over IP. It also develops and maintains protocols for the measurement of these metrics. The IPPM WG is a long running WG that started in 1997. The architecture (framework) for IPPM WG metrics and associated protocols are defined in RFC 2330 [RFC2330]. Some examples of recent output by IPPM WG include “A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance” (RFC 7398 [RFC7398]) and “Framework for TCP Throughput Testing” (RFC 6349 [RFC6349]).

The IPPM WG currently does not have a charter item or active drafts related to the topic of network virtualization. On the automation and orchestration side, there is an ongoing effort [I-D.cmzrjp-ippm-twamp-yang] to define a YANG model for the IPPM protocol.

Potential gap: There is a pressing need to define metrics and associated protocols to measure the performance of NFV. Specifically, since NFV is based on the concept of taking centralized functions and evolving it to highly distributed SW functions, there is a commensurate need to fully understand and measure the baseline performance of such systems. A potential topic for the IPPM WG is defining packet delay, throughput, and test framework for the application traffic flowing through the NFVI.

4.11. NFV RG

The NFVRG focuses on research problems associated with virtualization of fixed and mobile network infrastructures, new network architectures based on virtualized network functions, virtualization of the home and enterprise network environments, co-existence with non-virtualized infrastructure and services, and application to growing areas of concern such as Internet of Things (IoT) and next generation content distribution. Another goal of the NFVRG is to bring a research community together that can jointly address such problems, concentrating on problems that relate not just to networking but also to computing and storage constraints in such environments.

Since the NFVRG is a research group, it has a wide scope. In order to keep the focus, the group has identified some near term work items: (i) Policy based Resource Management, (ii) Analytics for Visibility and Orchestration, (iii) Virtual Network Function (VNF) Performance Modelling to facilitate transition to NFV and (iv) Security and Service Verification.

4.12. VNFpool BoF

The VNFPOOL BoF proposed to work on the way to group Virtual Network Function (VNF) into pools to improve resilience, provide better scale-out and scale-in characteristics, implement stateful failover among VNF members of a pool, etc. Additionally, they propose to create VNF sets from VNF pools. For this, the BoF proposed to study signaling (both between members of a pool and across pools), state sharing mechanisms between members of a VNFPOOL, the exchange of reliability information between VNF sets, their users and the underlying network, and the reliability and security of the control plane needed to transport the exchanged information.

The use cases initially considered by VNFPOOL include Content Deliver Networks (CDNs), the LTE mobile core network and reliable server pooling. The VNFPOOL work has been dropped in the IETF.

Potential gap: VNFPOOL tried to introduce and manage resilience in virtualized networking environments and therefore addresses a desirable feature for any software defined network. VNFPOOL has also been integrated into the NFV architecture [I-D.bernini-nfvrg-vnf-orchestration].

5. Summary of Gaps

Potential Gap-1: as stated in the SFC charter, any work on the management and configuration of SFC components related to the support of Service Function Chaining will not be done yet, until better understood and scoped. This part is of special interest for operators and would be required in order to actually put SFC mechanisms into operation.

Potential Gap-2: redundancy and reliability mechanisms are currently not dealt with by SFC or any other WG in the IETF. While this has been the main goal of the VNFpool BoF efforts, since VNFPOOL work has been dropped for the time being without any WG being chartered, the technical topics it aimed at targetting still remain un-addressed.

Potential Gap-3: it would be worthwhile to see if some of the specific approaches developed in the NVO3 WG (e.g. overlays, traffic isolation, VM migration) can be applied outside the DC, and specifically if they can be applicable to network virtualization (NFV). These approaches would be most relevant to the ETSI Network Function Virtualization Infrastructure (NFVI), and the Virtualized Infrastructure Manager part of the MANO.

Potential Gap-4: the most relevant activity in BESS that would be worthwhile to investigate for relevance to network virtualization (NFV) is the extensions to BGP-enabled VPN solutions to support of Service Function Chaining.

Potential Gap-5: in a vEPC/DMM context, how to run the EPC control plane on NFV.

Potential Gap-6: in DMM, on the work item addressing the separation of the Control-Plane for mobility- and session management from the actual Data-Plane, the actual mappings between these generic protocol semantics and the configuration commands required on the data plane network elements (e.g., OpenFlow switches) are not currently in the scope of the DMM WG.

Potential Gap-7: network virtualization is not the main aim of the I2RS WG. However, they provide an infrastructure that can be part of an SDN deployment.

Potential Gap-8: VNFPOOL tries to introduce and manage resilience in virtualized networking environments and therefore addresses a desirable feature for any software defined network. VNFPOOL has also been integrated into the NFV architecture [I-D.bernini-nfvrg-vnf-orchestration].

Potential Gap-9: within the Traffic Engineering Architecture and Signaling (TEAS) WG, several use cases in ACTN are relevant to network virtualization (NFV) in mobile environments. Control of multi-tenant mobile backhaul transport networks, mobile virtual network operation, etc, can be influenced by the location of the network functions. A control architecture allowing for inter-operation of NFV and transport network (e.g., for combined optimization) is one relevant area for research.

Potential Gap-10: within I2NSF', aspects of NSFs such as device or network provisioning and configuration are out of scope.

Potential Gap-11: the use of SDN tools to interact with security functions is not explictly considered in I2NSF, but seems a potential approach, as for example described for the particular case of IPsec flow protection in [I-D.abad-sdnrg-sdn-ipsec-flow-protection].

Potential Gap-12: there is a pressing need to define metrics and associated protocols to measure the performance of NFV. Specifically, since NFV is based on the concept of taking centralized functions and evolving it to highly distributed SW functions, there is a commensurate need to fully understand and measure the baseline performance of such systems. A potential topic for the IPPM WG is defining packet delay, throughput, and test framework for the application traffic flowing through the NFVI.

6. IANA Considerations

N/A.

7. Security Considerations

TBD.

8. Acknowledgments

The authors want to thank Dirk von Hugo, Rafa Marin, Diego Lopez, Ramki Krishnan, Kostas Pentikousis, Rana Pratap Sircar and Alfred Morton for their very useful reviews and comments to the document.

The work of Pedro Aranda is supported by the European FP7 Project Trilogy2 under grant agreement 317756.

9. Informative References

Appendix A. The mobile network use case

A.1. The 3GPP Evolved Packet System

TBD. This will include a high level summary of the 3GPP EPS architecture, detailing both the EPC (core) and the RAN (access) parts. A link with the two related ETSI NFV use cases (Virtualisation of Mobile Core Network and IMS, and Virtualisation of Mobile base station) will be included.

The EPS architecture and some of its standardized interfaces are depicted in Figure 7. The EPS provides IP connectivity to user equipment (UE) (i.e., mobile nodes) and access to operator services, such as global Internet access and voice communications. The EPS comprises the core network -- called Evolved Packet Core (EPC) -- and different radio access networks: the 3GPP Access Network (AN), the Untrusted non-3GPP AN and the Trusted non-3GPP AN. There are different types of 3GPP ANs, with the evolved UMTS Terrestrial Radio Access Network (E-UTRAN) as the most advanced one. QoS is supported through an EPS bearer concept, providing bindings to resource reservation within the network.

The evolved NodeB (eNB), the Long Term Evolution (LTE) base station, is part of the access network that provides radio resource management, header compression, security and connectivity to the core network through the S1 interface. In an LTE network, the control plane signaling traffic and the data traffic ar handled separately. The eNBs transmit the control traffic and data traffic separately via two logically separate interfaces.

The Home Subscriber Server, HSS, is a database that contains user subscriptions and QoS profiles. The Mobility Management Entity, MME, is responsible for mobility management, user authentication, bearer establishment and modification and maintenance of the UE context.

The Serving gateway, S-GW, is the mobility anchor and manages the user plane data tunnels during the inter-eNB handovers. It tunnels all user data packets and buffers downlink IP packets destined for UEs that happen to be in idle mode.

The Packet Data Network (PDN) Gateway, P-GW, is responsible for IP address allocation to the UE and is a tunnel endpoint for user and control plane protocols. It is also responsible for charging, packet filtering, and policy-based control of flows. It interconnects the mobile network to external IP networks, e.g. the Internet.

In this architecture, data packets are not sent directly on an IP network between the eNB and the gateways. Instead, every packet is tunneled over a tunneling protocol - the GPRS Tunneling Protocol (GTP over UDP/IP. A GTP path is identified in each node with the IP address and a UDP port number on the eNB/gateways. The GTP protocol carries both the data traffic (GTP-U tunnels) and the control traffic (GTP-C tunnels). Alternatively Proxy Mobile IP (PMIPv6) is used on the S5 interface between S-GW and P-GW.

In addition to the above basic functions and entities, there are also additional features being discussed by the 3GPP that are relevant from a network virtualization viewpoint. One example is the Traffic Detection Function (TDF), which can be used by the P-GW, and in general by the whole transport network, to decide how to forward the traffic. In a virtualized infrastructure, this kinf of information can be used to elastic and dynamically adapt the network capabilities to the traffic nature and volume.

         +---------------------------------------------------------+
         |                           PCRF                          |
         +-----------+--------------------------+----------------+-+
                     |                          |                |
+----+   +-----------+------------+    +--------+-----------+  +-+-+
|    |   |          +-+           |    |  Core Network      |  |   |
|    |   | +------+ |S|__         |    | +--------+  +---+  |  |   |
|    |   | |GERAN/|_|G|  \        |    | |  HSS   |  |   |  |  |   |
|    +-----+ UTRAN| |S|   \       |    | +---+----+  |   |  |  | E |
|    |   | +------+ |N|  +-+-+    |    |     |       |   |  |  | x |
|    |   |          +-+ /|MME|    |    | +---+----+  |   |  |  | t |
|    |   | +---------+ / +---+    |    | |  3GPP  |  |   |  |  | e |
|    +-----+ E-UTRAN |/           |    | |  AAA   |  |   |  |  | r |
|    |   | +---------+\           |    | | SERVER |  |   |  |  | n |
|    |   |             \ +---+    |    | +--------+  |   |  |  | a |
|    |   |   3GPP AN    \|SGW+----- S5---------------+ P |  |  | l |
|    |   |               +---+    |    |             | G |  |  |   |
|    |   +------------------------+    |             | W |  |  | I |
| UE |                                 |             |   |  |  | P |
|    |   +------------------------+    |             |   +-----+   |
|    |   |+-------------+ +------+|    |             |   |  |  | n |
|    |   || Untrusted   +-+ ePDG +-S2b---------------+   |  |  | e |
|    +---+| non-3GPP AN | +------+|    |             |   |  |  | t |
|    |   |+-------------+         |    |             |   |  |  | w |
|    |   +------------------------+    |             |   |  |  | o |
|    |                                 |             |   |  |  | r |
|    |   +------------------------+    |             |   |  |  | k |
|    +---+  Trusted non-3GPP AN   +-S2a--------------+   |  |  | s |
|    |   +------------------------+    |             |   |  |  |   |
|    |                                 |             +-+-+  |  |   |
|    +--------------------------S2c--------------------|    |  |   |
|    |                                 |                    |  |   |
+----+                                 +--------------------+  +---+