Jump to: navigation, search

Difference between revisions of "TelcoWorkingGroup"

(Requirements)
(Requirements)
Line 372: Line 372:
 
*** "Virt driver guest vCPU topology configuration" (https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology) - implemented 2014.2
 
*** "Virt driver guest vCPU topology configuration" (https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology) - implemented 2014.2
 
*** "Virt driver guest NUMA node placement & topology" (https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement) - implemented 2014.2
 
*** "Virt driver guest NUMA node placement & topology" (https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement) - implemented 2014.2
*** "Virt driver large page allocation for guest RAM" (https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages) - proposed kilo
+
*** "Virt driver large page allocation for guest RAM" (https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages) - proposed kilo, target for kilo-1
 
** May need support to prevent 'noisy neighbours' stealing L3 cache - unproven, and no blueprint we're aware of.
 
** May need support to prevent 'noisy neighbours' stealing L3 cache - unproven, and no blueprint we're aware of.
  

Revision as of 08:21, 7 November 2014

What is NFV?

NFV stands for Network Functions Virtualization. It defines the replacement of usually stand alone appliances used for high and low level network functions, such as firewalls, network address translation, intrusion detection, caching, gateways, accelerators, etc, into virtual instance or set of virtual instances, which are called Virtual Network Functions (VNF). In other words, it could be seen as replacing some of the hardware network appliances with high-performance software taking advantage of high performance para-virtual devices, other acceleration mechanisms, and smart placement of instances. The origin of NFV comes from a working group from the European Telecommunications Standards Institute (ETSI) whose work is the basis of most current implementations. The main consumers of NFV are Service providers (telecommunication providers and the like) who are looking to accelerate the deployment of new network services, and to do that, need to eliminate the constraint of slow renewal cycle of hardware appliances, which do not autoscale and limit their innovation.

NFV support for OpenStack aims to provide the best possible infrastructure for such workloads to be deployed in, while respecting the design principles of a IaaS cloud. In order for VNF to perform correctly in a cloud world, the underlying infrastructure needs to provide a certain number of functionalities which range from scheduling to networking and from orchestration to monitoring capacities. This means that to correctly support NFV use cases in OpenStack, implementations may be required across most, if not all, main OpenStack projects, starting with Neutron and Nova.

For more details on NFV, the following references may be useful:

Who we are

Add your name here if you're joining the meetings - IRC nicks are pretty anonymous unless you give us a clue! Please keep the list in alphabetical order by IRC nick.

adrian-hoban Adrian Hoban Intel OpenStack team NFV & SDN extensions across OpenStack projects
akhila-chetlapalle Akhila Chetlapalle TCS Openstack Team NFV & SDN Test Framework with Openstack
alank35 Alan Kavanagh Ericsson Inc NFV & SDN & Neutron and ODL
aleksandr_null Aleksandr Shaposhnikov Mirantis Inc NFV, SDN, Core Networking, Neutron, Virtualization, Storage
Ali_Kafel Ali Kafel Stratus Technologies State-full OpenStack, Cloud Orchestration with High Availability and Fault Tolerance for NFV / SDN
andrews Andrew Sergeev ADVA Optical Networking NFV, Openstack
andrewv Andrew Veitch BTI Systems NFV, SDN, Openstack
armax Armando Migliaccio HP Neutron, NFV, SDN
arosen Aaron Rosen nicira/vmware Automation, SDN/Neutron/NFV, Openstack
Arun_Aruchamy Arun Aruchamy TechMahindra Ltd - NTS NFV / Control plane / Openstack / KVM / VMware Testing
arturt Artur Tyloch Canonical NFV, Orchestration, SDN
atylee Andy Tylee Metaswitch Networks NFV, SR-IOV, data plane acceleration, orchestration
balajip Balaji Padnala Freescale OpenStack Team NFV, SDN, SRIOV, Libvirt, Neutron, Nova, Service VMs and Service Chaining
banix Mohammad Banikazemi IBM NFV, SDN, Neutron, OpenStack
bauzas Sylvain Bauza Red Hat SLA and Scheduling in Nova
bertys Bertrand Souville DOCOMO Euro-Labs NFV, SDN, OpenStack
cdub Chris Wright Red Hat NFV and SDN work between OpenStack and OpenDaylight
cgoncalves Carlos Goncalves NEC Europe Ltd. Fault management, Service Function Chaining, Traffic Steering
choonho Choonho Son Samsung KVM, OpenStack & DPDK
cliljenstolpe Christopher Liljenstolpe Metaswitch Networks Neutron, orchestration, network architecture
cloudon Calum Loudon Metaswitch Networks Neutron, data plane acceleration, orchestration
ctlmcb Kevin McBride CenturyLink OpenStack for NFV, SDN tech, Programmable Hardware/integrated circuits, etc.
dandrushko Dmitriy Andrushko Mirantis SDN, NFV, OpenDaylight, network architecture
danpb Daniel Berrange Red Hat Libvirt, KVM & Nova performance & enablement for NFV
davej Dave Johnston Openwave Mobility NFV on Openstack for the Telco industry
davidmck David McKinley Oracle OpenStack support for NFV
diga Digambar Patil Persistent System Ltd. Neutron, Nova, SDN, NFV
djhunt Jason Hunt IBM Orchestration, SDN, NFV
dmitry_huawei Dmitry Meytin Huawei MANO integration with OpenStack
DonBowman Don Bowman Sandvine OpenStack support for NFV
eranb Eran Bello ASOCS NFV compute and accelerator resources integration with OpenStack
fjramons Francisco-Javier Ramon Salguero Telefonica Libvirt, KVM & Nova performance & enablement for NFV
ggarcia Gerardo Garcia Telefonica Libvirt, KVM & Nova performance & enablement for NFV
gc4rella Giuseppe Carella Fraunhofer FOKUS NFV MANO, Service Function Chaining, SDN
heyongli Yongli He Intel Openstack team nova enabling NFV SRIOV PCI passthrough
HiteshW Hitesh Wadekar Graduate Student at Clarkson University SDN/Neutron/NFV, Openstack
ian_ott Ian Jolliffe Wind River Openstack, NFV, Networking
ijw Ian Wells Cisco's Openstack team Vendor neutral NFV infrastructure, Cisco NFV appliances
imendel Itai Mendelsohn Alcatel-Lucent NFV in general and how OpenStack can enable it
irenab Irena Berezovsky Mellanox NFV, SDN, NFV SRIOV PCI passthrough
JeremyLiu Jeremy Liu Huawei NFV & OpenStack
jjstevensjj Joe Stevens HP Helion NFV & Neutron
jmsoares Joao Soares Portugal Telecom Service Function Chaining, Traffic Steering
kalyan Kalyanjeet Gogoi Juniper Networks NFV integration with OpenStack
kranthi Kranthi Molleti Tech Mahindra Neutron, NFV and Virtual Networking
KyleMacDonald Kyle MacDonald OpenNile NFV / OpenStack / Carrier & Telco Deployment
LouisF Louis Fourie Huawei NFV-MANO, Service Function chaining, Traffic steering
lukego Luke Gorrie Snabb Making open source NFV work for Deutsche Telekom's TeraStream project
malini1 Malini Bhandaru Intel NFV, Adv. Service VMs, compute node capabilities, security
martin_t Martin Taylor Metaswitch Networks Neutron networking and data plane acceleration
matrohon Mathieu Rohon Orange NFV, SDN, Neutron
mjbright Mike Bright HP Openstack, NFV/SDN
mkashyap Madhu Kashyap Brocade OpenStack, NFV / SDN
mkoderer Marc Koderer Deutsche Telekom OpenStack, Orchestration, QA
mpaolino Michele Paolino Virtual Open Systems ARM, KVM, libvirt, Nova and Neutron
mpetrus Margaret Petrus VMware NFV-MANO, OpenStack for Service Orchestration
natarajk Karthik Natarajan Brocade NFV integration with OpenStack
nbal Nuri Bal Cyan OpenStack support of NFV, MANO in particular
nbouthors Nicolas Bouthors Qosmos Service Chaining, Classifier VNFC
nijaba Nick Barcet eNovance NFV support on OpenStack
nnikolaev Nikolay Nikolaev Virtual Open Systems vhost-user maintainer, Snabbswitch, Nova and Neutron
pals Palani Chinnakannan Cisco Systems Inc NFV, Orchestration, Networking
prabhu-nk Prabhuling Kalyani Global Edge NFV, Service Chaining
pgpus Prakash Ramchandran Futurewei Technologies Architecture,OpenStack, Orchestration, NFV, SDN, 3GPP
PushkarU Pushkar Umaranikar Graduate student at San Jose State University SDN/Neutron/NFV, Openstack
radek Radoslaw Smigielski Alcatel-Lucent OpenStack+NFV, SR-IOV, PCI passthrough, KVM performance
Rajesh R HP NFV MANO and Helion
ravirik Ravi Virik AT&T Neutron and Flowspace for NFV
r-mibu Ryota Mibu NEC Nova enhancement for NFV
ricky.bo ricky.bo Huawei Help better support NFV
rohit404 Rohit Agarwalla Cisco's OpenStack team OpenStack+NFV
rseth Rajeev Seth Sonus Networks NFV integration with OpenStack
runarut Larry Pearson AT&T OpenStack as NFVI, VNF Service Chaining
russellb Russell Bryant Project: OpenStack TC, Nova. Corporate: Red Hat Nova. Ensuring requirements and designs are consumable by OpenStack developers. Reviewing designs and implementations.
timmer Tim Reddin HP Cloud NFV, Kernel , OpenStack
s3wong Stephen Wong Midokura NFV support on OpenStack
safchain Sylvain Afchain eNovance NFV, SDN, Neutron
sasud S Sud Intel NFV and SDN use case PoCs
sean-k-mooney Sean Mooney Intel OpenStack team NFV & SDN enabling
sgordon Steve Gordon Red Hat NFV and SDN enablement across OpenStack projects but particularly Nova and the Libvirt driver.
shane-wang Shane Wang Intel NFV support on OpenStack, VM QoS in Nova, PCI/SR-IOV support
smazziotta Sandro Mazziotta eNovance OpenStack extensions required to meet NFV requirements
tapiotallgren Tapio Tallgren Nokia Networks OpenStack enhancements for NFV
tcroteau Tammy Croteau HP Cloud Neutron and NFV
thomnico Nicolas Thomas Canonical Allowing OpenStack to be gradually used in NFV type of deployments ETSI NFV IG participant.
tidwellr Ryan Tidwell HP NFV, Neutron, SDN
Torsten Torsten Bottjer Swisscom Orchestrating VNFs on Openstack
tvvcox Tomas Von Veschler Red Hat Openstack enablement for NFVi and VIM
ulikleber Ulrich Kleber Huawei Help better support NFV
vikasd Vikas Deolaliker ... NFV & SDN extenstions across Openstack projects
vpandari Vinod Pandarinathan Cisco Systems NFV Framework, Service Chaining and Neutron
vjardin Vincent JARDIN 6WIND Help using DPDK applications efficiently and ivshmem to start with (memnic)
Venkatesh Venkatesh Wipro Technologies NFV & SDN extenstions across Openstack projects
wenjing Wenjing Chu Dell NFV, Openstack for NFV, OPNFV
yamahata Isaku Yamahata Intel Neutron, servicevm, service chaining, traffic steering
yjiang5 Yunhong Jiang Intel Nova enablement for NFV
yukiarbel Yuki Arbel Alcatel Lucent NFV, Openstack for NFV
zeddii Bruce Ashfield Wind River KVM, libvirt, nova and platform awareness for NFV
zhyu Yu Zhang Huawei OpenStack enhancement for enabling NFV
zhipengh Zhipeng Huang Huawei OpenStack enhancement for enabling NFV
zuqiang Zu Qiang Ericsson NFV support in OpenStack

Mission statement

The sub-team aims to define the use cases and identify and prioritise the requirements which are needed to run Network Function Virtualization (NFV) workloads on top of OpenStack. This work includes identifying functional gaps, creating blueprints, submitting and reviewing patches to the relevant OpenStack projects and tracking their completion in support of NFV.
The requirements expressed by this group should be made so that each of them have a test case which can be verified using an OpenSource implementation. This is to ensure that tests can be done without any special hardware or proprietary software, which is key for continuous integration tests in the OpenStack gate. If special setups are required which cannot be reproduced on the standard OpenStack gate, the use cases proponent will have to provide a 3rd party CI setup, accessible by OpenStack infra, which will be used to validate developments against.

OpenStack IRC details

Chair: Russell Bryant (russellb)

Agenda for next meeting

Alternating between Wednesdays at 1400 UTC in #openstack-meeting-alt and Thursdays at 1600 UTC in #openstack-meeting. See schedule below.

Agenda: [1]

Date Time IRC Channel
Wednesday 22th October 2014 1400 UTC #openstack-meeting-alt
Thursday 30th October 2014 1600 UTC #openstack-meeting
Wednesday 5th November 2014 1400 UTC No meeting, OpenStack Summit

Previous meetings

Use Cases

Workload Type Description Characteristics Examples Requirements
Data plane Tasks related to packet handing in an end-to-end communication between edge applications.
  • Intensive I/O requirements - potentially millions of small VoIP packets per second per core
  • Intensive memory R/W requirements
  • CDN cache node
  • Router
  • IPSec tunneller
  • Session Border Controller - media relay function
-
Control plane Any other communication between network functions that is not directly related to the end-to-end data communication between edge applications.
  • Less intensive I/O and R/W requirements than data plane, due to lower packets per second
  • More complicated transactions resulting in (potentially) higher CPU load per packet.
  • PPP session management
  • Border Gateway Protocol (BGP) routing
  • Remote Authentication Dial In User Service (RADIUS) authentication in a Broadband Remote Access Server (BRAS) network function
  • Session Border Controller - SIP signaling function
  • IMS core functions (S-CSCF / I-CSCF / BGCF)
-
Signal processing All network function tasks related to digital processing
  • Very sensitive to CPU processing capacity.
  • Delay sensitive.
  • Fast Fourier Transform (FFT) decoding
  • Encoding in a Cloud-Radio Access Network (C-RAN) Base Band Unit (BBU)
  • Audio transcoding in a Session Border Controller
-
Storage All tasks related to disk storage.
  • Varying disk, SAN, or NAS, I/O requirements based on applications, ranging from low to extremely high intensity.
  • Logger
  • Network probe
-

ETSI-NFV Use Cases - High Level Description

ETSI NFV gap analysis document: https://wiki.openstack.org/wiki/File:NFV%2814%29000154r2_NFV_LS_to_OpenStack.pdf

Use Case #1: Network Functions Virtualisation Infrastructure as a Service

This is a reasonably generic IaaS requirement.

Use Case #2: Virtual Network Function as a Service (VNFaaS)

This primarily targets Customer Premise Equipment (CPE) devices such as access routers, enterprise firewall, WAN optimizers etc. with some Provider Edge devices possible at a later date. ETSI-NFV Performance & portability considerations will apply to deployments that strive to meet high performance and low latency considerations.

Use Case #3: Virtual Network Platform as a Service (VNPaaS)

This is similar to #2 but at the service level. At larger scale and not at the "app" level only.

Use Case #4: VNF Forwarding Graphs

Dynamic connectivity between apps in a "service chain".

Use Case #5: Virtualisation of Mobile Core Network and IMS

Primarily focusing on Evolved Packet Core appliances such as the Mobility Management Entity (MME), Serving Gateway (S-GW), etc. and the IP Multimedia Subsystem (IMS).

Use Case #6: Virtualisation of Mobile base station

Focusing on parts of the Radio Access Network such as eNodeB's, Radio Link Control and Packet Data Convergence Protocol, etc..

Use Case #7: Virtualisation of the Home Environment

Similar to Use Case 2, but with a focus on virtualising residential devices instead of enterprise devices. Covers DHCP, NAT, PPPoE, Firewall devices, etc.

Use Case #8: Virtualisation of CDNs

Content Delivery Networks focusing on video traffic delivery.

Use Case #9: Fixed Access Network Functions Virtualisation

Wireline related access technologies.

Contributed Use Cases

Session Border Controller

Contributed by: Calum Loudon

Description

Perimeta Session Border Controller, Metaswitch Networks. Sits on the edge of a service provider's network and polices SIP and RTP (i.e. VoIP) control and media traffic passing over the access network between end-users and the core network or the trunk network between the core and another SP.

Characteristics

  • Fast and guaranteed performance:
    • Performance in the order of several million VoIP packets (~64-220 bytes depending on codec) per second per core (achievable on COTS hardware).
    • Guarantees provided via SLAs.
  • Fully high availability
    • No single point of failure, service continuity over both software and hardware failures.
  • Elastically scalable
    • NFV orchestrator adds and removes instances in response to network demands.
  • Traffic segregation (ideally)
    • Separate traffic from different customers via VLANs.

Requirements

  • High availability:
    • Requires anti-affinity rules to prevent active/passive being instantiated on same host - already supported, so no gap.
  • Elastic scaling:
    • Readily achievable using existing features - no gap.
  • Other:

Virtual IMS Core

Contributed by: Calum Loudon

Description

Project Clearwater, http://www.projectclearwater.org/. An open source implementation of an IMS core designed to run in the cloud and be massively scalable. It provides SIP-based call control for voice and video as well as SIP-based messaging apps. As an IMS core it provides P/I/S-CSCF function together with a BGCF and an HSS cache, and includes a WebRTC gateway providing interworking between WebRTC & SIP clients.

Characteristics relevant to NFV/OpenStack

  • Mainly a compute application: modest demands on storage and networking.
  • Fully HA, with no SPOFs and service continuity over software and hardware failures; must be able to offer SLAs.
  • Elastically scalable by adding/removing instances under the control of the NFV orchestrator.

Requirements

  • Compute application:
    • OpenStack already provides everything needed; in particular, there are no requirements for an accelerated data plane, nor for core pinning nor NUMA
  • HA:
    • implemented as a series of N+k compute pools; meeting a given SLA requires being able to limit the impact of a single host failure
    • potentially a scheduler gap here: affinity/anti-affinity can be expressed pair-wise between VMs, which is sufficient for a 1:1 active/passive architecture, but an N+k pool needs a concept equivalent to "group anti-affinity" i.e. allowing the NFV orchestrator to assign each VM in a pool to one of X buckets, and requesting OpenStack to ensure no single host failure can affect more than one bucket
    • (there are other approaches which achieve the same end e.g. defining a group where the scheduler ensures every pair of VMs within that group are not instantiated on the same host)
    • for study whether this can be implemented using current scheduler hints
  • Elastic scaling:
    • as for compute requirements there is no gap - OpenStack already provides everything needed.

VLAN Trunking

The big picture is that this is about how service providers can use virtualisation to provide differentiated network services to their customers (and specifically enterprise customers rather than end users); it's not about VMs want to set up networking between themselves.

A typical service provider may be providing network services to thousands or more of enterprise customers. The details of and configuration required for individual services will differ from customer to customer. For example, consider a Session Border Control service (basically, policing VoIP interconnect): different customers will have different sets of SIP trunks that they can connect to, different traffic shaping requirements, different transcoding rules etc.

Those customers will normally connect in to the service provider in one of two ways: a dedicated physical link, or through a VPN over the public Internet. Once that traffic reaches the edge of the SP's network, then it makes sense for the SP to put all that traffic onto the same core network while keeping some form of separation to allow the network services to identify the source of the traffic and treat it independently. There are various overlay techniques that can be used (e.g. VXLAN, GRE tunnelling) but one common and simple one is VLANs. Carrying VLAN trunking into the VM allows this scheme to continue to be used in a virtual world.

In this set-up, then any VMs implementing those services have to be able to differentiate between customers. About the only way of doing that today in OpenStack is to configure one provider network per customer then have one vNIC per provider network, but that approach clearly doesn't scale (both performance and configuration effort) if a VM has to see traffic from hundreds or thousands of customers. Instead, carrying VLAN trunking into the VM allows them to do this scalably.

The net is that a VM providing a service that needs to have access to a customer's non-NATed source addresses needs an overlay technology to allow this, and VLAN trunking into the VM is sufficiently scalable for this use case and leverages a common approach.

From: http://lists.openstack.org/pipermail/openstack-dev/2014-October/047548.html

References:

Related Teams and Projects

  • OpenStack Congress - Policy as a Service [3]

Development Efforts

Active Bugs

Add the "nfv" tag to bugs to have them appear in these queries:

Active Blueprints

The NFV use case mappings identified below are from the perspective of higher performing use cases. Please note that there are many possible configurations of devices for each of these use cases and it is not implied that they will all need the proposed capability in the relevant blueprint.

There is an automatically updated gerrit dashboard for all specs and code under review here: http://nfv.russellbryant.net

PRIORITY - repeatedly mentioned at the BOF as blockers:

Description Project(s) Status Blueprint(s) Design(s) ETSI-NFV Use Cases
VLAN trunking networks for NFV

This line item now confuses various requirements together: VLAN tagged traffic transmissible over a tenant network is the most important (even if Openstack is otherwise VLAN unaware) decomposition of VLAN trunks to virtual networks VLAN tagged traffic to a physical appliance management of VLANs on ports as sub-ports (nice to have, not a blocker)

Neutron New https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks (tenant trunking)

https://blueprints.launchpad.net/neutron/+spec/l2-gateway (physical appliance-specific decomposition) https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms (VLAN port management)

https://review.openstack.org/#/c/100278/ (physical appliance-specific decomposition)

https://review.openstack.org/97714 (tenant trunking) https://review.openstack.org/#/c/94612/ (subports) https://review.openstack.org/#/c/92541/ (patch for subports)

 * #1 is a broadly applicable IaaS requirement.
  • #2 TBD?
  • #3 TBD?
  • #4 TBD?
  • #5 TBD?
  • #6 TBD?
  • #7 TBD?
  • #8 TBD?
  • #9 TBD?
Permit unaddressed interfaces for NFV use cases Neutron New https://blueprints.launchpad.net/neutron/+spec/nfv-unaddressed-interfaces https://blueprints.launchpad.net/neutron/+spec/ml2-ovs-portsecurity https://review.openstack.org/97715 https://review.openstack.org/#/c/99873/
  • #1 is a broadly applicable IaaS requirement.
  • #2 TBD?
  • #3 TBD?
  • #4 TBD?
  • #5 TBD?
  • #6 TBD?
  • #7 TBD?
  • #8 TBD?
  • #9 TBD?

The rest:

neutron port enhancement related to servicevm is summarized at https://wiki.openstack.org/wiki/ServiceVM/neutron-port-attributes

Description Project(s) Status Blueprint(s) Design(s) ETSI-NFV Use Cases

Virt driver guest NUMA node placement & topology

Nova Design Approved / Needs Code Review https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement https://review.openstack.org/93636
  • #1 is a broadly applicable IaaS requirement.
  • #2 Needed for performance reasons.
  • #3 TBD?
  • #4 TBD?
  • #5 Needed for performance reasons.
  • #6 Needed for performance reasons.
  • #7 Needed for performance reasons.
  • #8 Needed for performance reasons.
  • #9 Needed for performance reasons.

Virt driver large page allocation for guest RAM *

Nova Design Approved / Needs Code Review https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages https://review.openstack.org/93653
  • #1 is a broadly applicable IaaS requirement.
  • #2 Needed for performance reasons.
  • #3 TBD?
  • #4 TBD?
  • #5 Needed for performance reasons.
  • #6 Needed for performance reasons.
  • #7 Needed for performance reasons.
  • #8 Needed for performance reasons.
  • #9 Needed for performance reasons.

Virt driver pinning guest vCPUs to host pCPUs

Nova Design Approved / Needs Code Review https://blueprints.launchpad.net/nova/+spec/virt-driver-cpu-pinning https://review.openstack.org/93652
  • #1 is a broadly applicable IaaS requirement.
  • #2 Needed for performance reasons.
  • #3 TBD?
  • #4 TBD?
  • #5 Needed for performance reasons.
  • #6 Needed for performance reasons.
  • #7 Needed for performance reasons.
  • #8 Needed for performance reasons.
  • #9 Needed for performance reasons.
I/O (PCIe) Based NUMA Scheduling
Nova Design Approved / Needs Code Review https://blueprints.launchpad.net/nova/+spec/input-output-based-numa-scheduling https://review.openstack.org/#/c/100871/
  • #1 is a broadly applicable IaaS requirement.
  • #2 Needed for performance reasons.
  • #3 TBD?
  • #4 TBD?
  • #5 Needed for performance reasons.
  • #6 Needed for performance reasons.
  • #7 Needed for performance reasons.
  • #8 Needed for performance reasons.
  • #9 Needed for performance reasons.
Soft affinity support for server groups Nova Abandoned https://blueprints.launchpad.net/nova/+spec/soft-affinity-for-server-group https://review.openstack.org/91328
  • #1 is a broadly applicable IaaS requirement.
  • #2 TBD?
  • #3 TBD?
  • #4 TBD?
  • #5 TBD?
  • #6 TBD?
  • #7 TBD?
  • #8 TBD?
  • #9 TBD?
Open vSwitch-based Security Groups: Open vSwitch Implementation of FirewallDriver Neutron Design review in progress https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver https://review.openstack.org/89712
  • #1 is a broadly applicable IaaS requirement.
  • #2 Needed in the non-SR-IOV based deployments.
  • #3 TBD?
  • #4 vSwitch configuration may be needed to complete the forwarding graph (service chain).
  • #5 Needed in the non-SR-IOV based deployments.
  • #6 TBD?
  • #7 Needed in the non-SR-IOV based deployments.
  • #8 TBD?
  • #9 Needed in the non-SR-IOV based deployments.
Framework for Advanced Services in Virtual Machines Neutron Under Discussion https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms
  • #1 is a broadly applicable IaaS requirement.
  • #2 Potential lifecycle management support
  • #3 TBD?
  • #4 TBD?
  • #5 Potential lifecycle management support
  • #6 Potential lifecycle management support
  • #7 Potential lifecycle management support
  • #8 Potential lifecycle management support
  • #9 Potential lifecycle management support
Neutron Services Insertion, Chaining, and Steering Neutron Design Approved / Needs Code Review https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering https://review.openstack.org/93524

NOTE: this service chaining BP is all about chaining aaS services, not chaining tenant NFVs. Is this the one we want or do we require a new BP?

  • #1 is a broadly applicable IaaS requirement.
  • #2 May need to chain multiple functions to deliver a service.
  • #3 TBD?
  • #4 Closely coupled requirement needed to deliver on a forwarding graph.
  • #5 May need to chain multiple functions to deliver a service.
  • #6 May need to chain multiple functions to deliver a service.
  • #7 May need to chain multiple functions to deliver a service.
  • #8 May need to chain multiple functions to deliver a service.
  • #9 May need to chain multiple functions to deliver a service.
OVF Meta-Data Import via Glance Glance New https://blueprints.launchpad.net/glance/+spec/epa-ovf-meta-data-import https://review.openstack.org/#/c/104904/
  • #1 is a broadly applicable IaaS requirement.
  • #2 Needed as one optional path to auto import platform feature requests to meet performance targets.
  • #3 TBD?
  • #4 TBD?
  • #5 Needed as one optional path to auto import platform feature requests to meet performance targets.
  • #6 Needed as one optional path to auto import platform feature requests to meet performance targets.
  • #7 Needed as one optional path to auto import platform feature requests to meet performance targets.
  • #8 Needed as one optional path to auto import platform feature requests to meet performance targets.
  • #9Needed as one optional path to auto import platform feature requests to meet performance targets.
Support for high performance Intel(R) Data Plane Development Kit based vSwitches
Open vSwitch to use patch ports in place of veth pairs for vlan n/w
Neutron Superseded / Unknown https://blueprints.launchpad.net/neutron/+spec/openvswitch-patch-port-use
Support userspace vhost in ovs vif bindings
Nova Design review in progress https://blueprints.launchpad.net/nova/+spec/libvirt-ovs-use-usvhost https://review.openstack.org/95805
  • #1 is a broadly applicable IaaS requirement.
  • #2 Needed in the non-SR-IOV based deployments.
  • #3 TBD?
  • #4 Closely coupled requirement needed to deliver on a forwarding graph.
  • #5 Needed in the non-SR-IOV based deployments.
  • #6 TBD?
  • #7 Needed in the non-SR-IOV based deployments.
  • #8 TBD?
  • #9 Needed in the non-SR-IOV based deployments.
Snabb NFV mechanism driver Neutron Approved https://blueprints.launchpad.net/neutron/+spec/snabb-nfv-mech-driver https://review.openstack.org/95711
  • #1 is a broadly applicable IaaS requirement.
  • #2 Needed in the non-SR-IOV based deployments.
  • #3 TBD?
  • #4 TBD?
  • #5 Needed in the non-SR-IOV based deployments.
  • #6 TBD?
  • #7 Needed in the non-SR-IOV based deployments.
  • #8 TBD?
  • #9 Needed in the non-SR-IOV based deployments.
VIF_VHOSTUSER (qemu vhost-user) support Nova Approved https://blueprints.launchpad.net/nova/+spec/vif-vhostuser https://review.openstack.org/96138
  • #1 is a broadly applicable IaaS requirement.
  • #2 Needed in the non-SR-IOV based deployments.
  • #3 TBD?
  • #4 TBD?
  • #5 Needed in the non-SR-IOV based deployments.
  • #6 TBD?
  • #7 Needed in the non-SR-IOV based deployments.
  • #8 TBD?
  • #9 Needed in the non-SR-IOV based deployments.
Solver Scheduler - complex constraints scheduler with NFV use cases Nova Design review in progress https://blueprints.launchpad.net/nova/+spec/solver-scheduler https://review.openstack.org/#/c/96543/
  • #1 is a broadly applicable IaaS requirement.
  • #2 Possibly needed for smarter scheduling decision making to help with performance.
  • #3 TBD?
  • #4 TBD?
  • #5 Possibly needed for smarter scheduling decision making to help with performance.
  • #6 Possibly needed for smarter scheduling decision making to help with performance.
  • #7 Possibly needed for smarter scheduling decision making to help with performance.
  • #8 Possibly needed for smarter scheduling decision making to help with performance.
  • #9 Possibly needed for smarter scheduling decision making to help with performance.
Discless VM Nova Under discussion https://blueprints.launchpad.net/nova/+spec/libvirt-empty-vm-boot-pxe
  • #1 is a broadly applicable IaaS requirement.
  • #2 TBD?
  • #3 TBD?
  • #4 TBD?
  • #5 TBD?
  • #6 TBD?
  • #7 TBD?
  • #8 TBD?
  • #9 TBD?
Network QoS API Neutron Under discussion https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api https://review.openstack.org/#/c/88599
  • #1 is a broadly applicable IaaS requirement.
  • #2 Needed for performance reasons
  • #3 TBD?
  • #4 Needed to capture network QoS aspects of forwarding graph.
  • #5 Needed for performance reasons
  • #6 Needed for performance reasons
  • #7 Needed for performance reasons
  • #8 Needed for performance reasons
  • #9 Needed for performance reasons
Port mirroring Neutron Under discussion https://blueprints.launchpad.net/neutron/+spec/port-mirroring
  • #1 is a broadly applicable IaaS requirement.
  • #2 Needed for some specialized use cases.
  • #3 TBD?
  • #4 Needed based on forwarding graph for specialized use cases.
  • #5 Needed for some specialized use cases.
  • #6 Needed for some specialized use cases.
  • #7 Needed for some specialized use cases.
  • #8 TBD?
  • #9 Needed for some specialized use cases.
Traffic Steering Abstraction Neutron Design review in progress https://blueprints.launchpad.net/neutron/+spec/traffic-steering-abstraction https://review.openstack.org/92477/
  • #1 is a broadly applicable IaaS requirement.
  • #2 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
  • #3 TBD?
  • #4 Closely coupled requirement needed to deliver on a forwarding graph.
  • #5 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
  • #6 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
  • #7 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
  • #8 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
  • #9 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.

Implemented (Juno)

Description Project(s) Status Blueprint(s) Design(s) ETSI-NFV Use Cases
Support two interfaces from one VM attached to the same network Nova Design Approved / Implemented https://blueprints.launchpad.net/nova/+spec/multiple-if-1-net
  • #1 is a broadly applicable IaaS requirement.
  • #2 TBD?
  • #3 TBD?
  • #4 TBD?
  • #5 TBD?
  • #6 TBD?
  • #7 TBD?
  • #8 TBD?
  • #9 TBD?
SR-IOV Networking Support Nova Design Approved / Needs Code Review https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov https://review.openstack.org/#/c/86606/
  • #1 is a broadly applicable IaaS requirement.
  • #2 Needed for performance reasons.
  • #3 TBD?
  • #4 _Potential_ intersect if forwarding graph makes any particular request about the port connectivity.
  • #5 Needed for performance reasons.
  • #6 Needed for performance reasons.
  • #7 Needed for performance reasons.
  • #8 TBD?
  • #9 Needed for performance reasons.
Virt driver guest vCPU topology configuration Nova Design Approved / Implemented https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology https://review.openstack.org/93510
  • #1 is a broadly applicable IaaS requirement.
  • #2 Needed for performance reasons.
  • #3 TBD?
  • #4 TBD?
  • #5 Needed for performance reasons.
  • #6 Needed for performance reasons.
  • #7 Needed for performance reasons.
  • #8 Needed for performance reasons.
  • #9 Needed for performance reasons.
Evacuate instance to scheduled host Nova Approved / Implemented (juno-2) https://blueprints.launchpad.net/nova/+spec/find-host-and-evacuate-instance https://review.openstack.org/84429

Needed Development Not Yet Started