Jump to: navigation, search

Difference between revisions of "TelcoWorkingGroup"

(Active Blueprints)
(Technical Team Meetings)
 
(277 intermediate revisions by more than 100 users not shown)
Line 1: Line 1:
= Weekly NFV sub-team IRC meeting =
+
= Mission statement and scope =
'''MEETING TIME: (Proposed, subject to change) Wednesdays, [http://www.timeanddate.com/worldclock/fixedtime.html?hour=14&min=0&sec=0&p1=0 1400 UTC], #openstack-meeting-alt, starting June 4'''
 
  
= Who we are =
+
<blockquote>The working group aims to define the use cases and identify and prioritise the requirements which are needed to deploy, manage, and run telecommunication services 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 telecommunication services.</blockquote>
  
''' 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. '''
+
<blockquote>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.</blockquote>
 +
 
 +
The work group has also established a team to focus ecosystem development (both vendors and industry co-travelers), collateral development and marketing messaging to address the needs to Telco operators who are interested in deploying OpenStack today.
 +
 
 +
= Membership =
 +
 
 +
Members of the Telco Working Group come from a broad array of backgrounds and include service providers, equipment providers, and OpenStack vendors. We aim to include both operators and developers in an open discussion about the needs of this sector and how to meet them in OpenStack. You can find the current membership list of at [[TelcoWorkingGroup/Members]]. Feel free to add your name If you're interested in working with us to improve OpenStack for telecommunications workloads.
 +
 
 +
= Communication =
 +
 
 +
== IRC ==
 +
 
 +
Members of the working group hang out in the #openstack-nfv IRC channel on irc.freenode.net. Refer to [[IRC]] for more information on OpenStack IRC channels and how to use them.
 +
 
 +
== Mailing Lists ==
 +
 
 +
The working group does not have a dedicated mailing list, instead using the existing openstack-dev and openstack-operators mailing lists:
 +
 
 +
* http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 +
* http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 +
 
 +
These are high traffic lists, when sending mail pertaining to the working group include the [NFV] and [Telco] tags in the subject line, users filtering the list specifically for emails pertaining to the working group will do so based on these tags.
 +
 
 +
Refer to [[Mailing_Lists]] for more information on OpenStack mailing lists and how to use them.
 +
 
 +
= Meetings =
 +
 +
 
 +
== Technical Team Meetings ==
 +
 
 +
The working group meeting schedule is available at http://eavesdrop.openstack.org/#Telco_Working_Group_meeting
 +
 
 +
[[IRC|OpenStack IRC details]]
 +
 
 +
=== Upcoming Meetings ===
 +
 
 +
Agenda: [https://etherpad.openstack.org/p/nfv-meeting-agenda]
 +
 
 +
=== Previous Meetings ===
 +
 
 +
* [http://eavesdrop.openstack.org/meetings/telcowg/ Meeting logs]
 +
* [http://eavesdrop.openstack.org/meetings/nfv/ Meeting logs (archived)]
 +
* [https://etherpad.openstack.org/p/juno-nfv-bof Atlanta (Juno) Summit NFV BoF]
 +
* [https://etherpad.openstack.org/p/kilo-summit-ops-telco Paris (Kilo) Summit Telco Working Group]
 +
* [https://etherpad.openstack.org/p/YVR-ops-telco Vancouver (Liberty) Summit Telco Working Group]
 +
* [https://etherpad.openstack.org/p/TYO-telcowg Tokyo (Mitaka) Summit Telco Working Group]]
 +
 
 +
<!--== Ecosystem and Collateral Team ==
 +
This team is focused on accelerating the deployment of OpenStack by Telco Operators by enaging with the Ecosystem (vendors and industry groups) and developing needed information/collateral (case studies, reference architectures, etc).
 +
=== Upcoming Meetings ===
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
! Nick !! Name !! Affiliation !! Interests
+
! Date || Time || Bridge Information || Link to Etherpad Notes
 +
|-
 +
| Tuesday 9th December 2014 || 8ː00 Pacific || Access: (888) 875-9370, Bridge: 3; PC: 7053780 || https://etherpad.openstack.org/p/12_9_TWG_Ecosystem_and_Collateral
 
|-
 
|-
| adrian-hoban || Adrian Hoban || Intel OpenStack team || NFV & SDN extensions across OpenStack projects
+
| Thursday 8th January 2015 || 9ː00 Pacific || Access: (888) 875-9370, Bridge: 3; PC: 7053780 || https://etherpad.openstack.org/p/1_8_TWG_Ecosystem_and_Collateral
 
|-
 
|-
| cgoncalves || Carlos Goncalves || Instituto de Telecomunicacoes || Service Function Chaining, Traffic Steering
+
| Thursday 15th January 2015 || 9ː00 Pacific || Access: (888) 875-9370, Bridge: 3; PC: 7053780 || https://etherpad.openstack.org/p/1_15_TWG_Ecosystem_and_Collateral_Team
 
|-
 
|-
| danpb || Daniel Berrange || Red Hat || Libvirt, KVM & Nova performance & enablement for NFV
+
| Thursday 22th January 2015 || 9ː00 Pacific || Access: (888) 875-9370, Bridge: 3; PC: 7053780 || https://etherpad.openstack.org/p/1_22_TWG_Ecosystem_and_Collateral_Team
 
|-
 
|-
| ijw || Ian Wells || Cisco's Openstack team || Vendor neutral NFV infrastructure, Cisco NFV appliances
+
| Thursday 29th January 2015 || 9ː00 Pacific || Access: (888) 875-9370, Bridge: 3; PC: 7053780 ||  https://etherpad.openstack.org/p/1_29_TWG_Ecosystem_and_Collateral_Team
 +
|-
 +
| Thursday 5th February 2015 ||  9ː00 Pacific || Access: (888) 875-9370, Bridge: 3; PC: 7053780 || https://etherpad.openstack.org/p/2_5_TWG_Ecosystem_and_Collateral_Team
 +
|-
 +
| Thursday 12th February 2015 ||  9ː00 Pacific || Access: (888) 875-9370, Bridge: 3; PC: 7053780 ||  https://etherpad.openstack.org/p/2_12_TWG_Ecosystem_and_Collateral_Team
 
|-
 
|-
| russellb || Russell Bryant || Project: OpenStack TC, Nova. Corporate: Red Hat || Nova. Ensuring requirements and designs are consumable by OpenStack developers. Reviewing designs and implementations.
 
 
|}
 
|}
 +
-->
  
= Mission statement =
+
= What is NFV? =
  
<blockquote>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.</blockquote>
+
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 [http://www.etsi.org/ 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.
  
<blockquote>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.</blockquote>
+
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.
  
[[IRC|OpenStack IRC details]]
+
For more details on NFV, the following references may be useful:
 +
* [http://www.etsi.org/technologies-clusters/technologies/nfv Definition of NFV by ETSI]
 +
* [http://en.wikipedia.org/wiki/Network_Functions_Virtualization Definition of NFV on Wikipedia]
  
Chair: Russell Bryant (russellb)
+
== Glossary ==
  
== Agenda for next meeting ==
+
[[TelcoWorkingGroup/Glossary]]
  
Wednesday, June 4 at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=14&min=0&sec=0&p1=0 1400 UTC] in #openstack-meeting-alt.
+
== Related Teams and Projects ==
 +
* OpenStack Congress - Policy as a Service [https://wiki.openstack.org/wiki/Congress]
  
Agenda: [https://etherpad.openstack.org/p/nfv-meeting-agenda]
+
= Development Efforts =
  
== Previous meetings ==
+
== Use Case Definition ==
  
* [http://eavesdrop.openstack.org/meetings/nfv/ Meeting logs]
+
Use cases are currently collected at [[TelcoWorkingGroup/UseCases]], more are welcome! Definition of target use cases, and identification of gaps based on these, is a primary focus of this working group with the goal being to ensure that blueprints created to close these gaps are furnished with appropriately descriptive information on how they will actually be used in practice. Ultimately it is expected that this will help core review teams understand the need for a given feature when reviewing the blueprint and its associated specification.
* [https://etherpad.openstack.org/p/juno-nfv-bof Juno Design Summit NFV BoF]
 
  
=Use Cases=
+
<!--== Active Bugs ==
 
 
TBD
 
 
 
= Development Efforts =
 
 
 
== Active Bugs ==
 
  
 
Add the "nfv" tag to bugs to have them appear in these queries:
 
Add the "nfv" tag to bugs to have them appear in these queries:
Line 55: Line 105:
  
 
== Active Blueprints ==
 
== 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:
 
PRIORITY - repeatedly mentioned at the BOF as blockers:
  
{| class="wikitable"
+
{| class="wikitable sortable"
|-
 
! Description !! Project(s) !! Status !! Blueprint(s) !! Design
 
 
|-
 
|-
| Support two interfaces from one VM attached to the same network || Nova || first BP submit || https://blueprints.launchpad.net/nova/+spec/2-if-1-net || https://review.openstack.org/97716
+
! Description !! Project(s) !! Status !! Blueprint(s) !! Design(s)  !! ETSI-NFV Use Cases
 
|-
 
|-
| VLAN trunking networks for NFV || Neutron || first BP submit
+
| VLAN trunking networks for NFV
| https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks https://blueprints.launchpad.net/neutron/+spec/l2-gateway https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
+
This line item now confuses various requirements together:
| https://review.openstack.org/97714 https://review.openstack.org/#/c/94612/ https://review.openstack.org/#/c/92541/ (patch)
+
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 || first BP submit || https://blueprints.launchpad.net/neutron/+spec/nfv-unaddressed-interfaces || https://review.openstack.org/97715
+
| 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?
 
|-
 
|-
 
|}
 
|}
Line 74: Line 157:
 
The rest:
 
The rest:
  
{| class="wikitable"
+
neutron port enhancement related to servicevm is summarized at https://wiki.openstack.org/wiki/ServiceVM/neutron-port-attributes
 +
 
 +
{| class="wikitable sortable"
 
|-
 
|-
! Description !! Project(s) !! Status !! Blueprint(s) !! Design(s)
+
! Description !! Project(s) !! Status !! Blueprint(s) !! Design(s) !! ETSI-NFV Use Cases
|-
 
| SR-IOV Networking Support || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov || https://review.openstack.org/#/c/86606/
 
|-
 
| colspan="3" | ''Support for NUMA and VCPU topology configuration'' || ''https://blueprints.launchpad.net/nova/+spec/nova-virt-numa-and-vcpu-topology'' ||
 
 
|-
 
|-
 
|
 
|
: Virt driver guest vCPU topology configuration
+
Virt driver guest NUMA node placement & topology
|| Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology || https://review.openstack.org/93510
+
|| 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.
: Virt driver guest NUMA node placement & topology
+
* #3 TBD?
|| Nova || Design review in progress ||  https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement || https://review.openstack.org/93636
+
* #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 [[#dupe|*]]
+
Virt driver large page allocation for guest RAM [[#dupe|*]]
|| Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages || https://review.openstack.org/93653
+
|| 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  
+
Virt driver pinning guest vCPUs to host pCPUs  
|| Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/virt-driver-cpu-pinning || https://review.openstack.org/93652
+
|| 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  
 
: I/O (PCIe) Based NUMA Scheduling  
|| Nova || New || https://blueprints.launchpad.net/nova/+spec/input-output-based-numa-scheduling || TBD
+
|| 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.
| Soft affinity support for server groups || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/soft-affinity-for-server-group || https://review.openstack.org/91328
+
* #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.
 
|-
 
|-
| 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
+
| 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?
 
|-
 
|-
| Framework for Advanced Services in Virtual Machines || Neutron || || https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms ||
+
| 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.
 
|-
 
|-
| Neutron Services Insertion, Chaining, and Steering || Neutron || Approved || https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering || https://review.openstack.org/93524
+
| 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
 
|-
 
|-
| Schedule vms per flavour cpu overcommit || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/flavor-cpu-overcommit || https://review.openstack.org/88286
+
| 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 || Submitted || https://blueprints.launchpad.net/glance/+spec/epa-ovf-meta-data-import || TBD
+
| 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.
 
|-
 
|-
| colspan="5" | ''Support for high performance Intel(R) Data Plane Development Kit based vSwitches''
+
| colspan="6" | ''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  
 
: Open vSwitch to use patch ports in place of veth pairs for vlan n/w  
|| Neutron || Submitted || https://blueprints.launchpad.net/neutron/+spec/openvswitch-patch-port-use  || TBD
+
|| Neutron || Superseded / Unknown || https://blueprints.launchpad.net/neutron/+spec/openvswitch-patch-port-use  ||
 +
* https://review.openstack.org/96183
 +
* https://bugs.launchpad.net/neutron/+bug/1331569
 +
*https://bugs.launchpad.net/neutron/+bug/1331569 ||
 +
* #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.
 
|-
 
|-
 
|
 
|
: Libvirt hugepage backed memory support
+
: Support userspace vhost in ovs vif bindings
|| Nova || Submitted || https://blueprints.launchpad.net/nova/+spec/libvirt-hugepage || TBD
+
|| 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.
 +
|-
 +
| [http://snabb.co/nfv.html 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/ ||
: Support userspace vhost in ovs vif bindings
+
* #1 is a broadly applicable IaaS requirement.
|| Nova || Submitted || https://blueprints.launchpad.net/nova/+spec/libvirt-ovs-use-usvhost || TBD
+
* #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.
 
|-
 
|-
| NIC state aware scheduling || Nova || Rejected || https://blueprints.launchpad.net/nova/+spec/nic-state-aware-scheduling || https://review.openstack.org/87978
+
| 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?
 
|-
 
|-
| Add PCI and PCIe device capability aware scheduling || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/pci-device-capability-aware-scheduling  || https://review.openstack.org/92843
+
| 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
 
|-
 
|-
| [http://snabb.co/nfv.html Snabb NFV] mechanism driver || Neutron || Design review in progress || https://blueprints.launchpad.net/neutron/+spec/snabb-nfv-mech-driver || https://review.openstack.org/95711
+
| 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.
 
|-
 
|-
| VIF_SNABB (qemu vhost-user) support || Nova || Submitted w/ code || https://blueprints.launchpad.net/nova/+spec/vif-snabb || https://review.openstack.org/96138
+
| 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.
 
|-
 
|-
|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/
+
|}
 +
 
 +
=== Implemented (Juno) ===
 +
 
 +
{| class="wikitable sortable"
 
|-
 
|-
| Discless VM || Nova || Under discussion || https://blueprints.launchpad.net/nova/+spec/libvirt-empty-vm-boot-pxe ||
+
! Description !! Project(s) !! Status !! Blueprint(s) !! Design(s)  !! ETSI-NFV Use Cases
 
|-
 
|-
| Network QoS API || Neutron || Under discussion || https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api || https://review.openstack.org/#/c/88599
+
| 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 ||  
 +
* Spec: https://review.openstack.org/97716
 +
* Patch: https://review.openstack.org/98488
 +
||
 +
* #1 is a broadly applicable IaaS requirement.
 +
* #2 TBD?
 +
* #3 TBD?
 +
* #4 TBD?
 +
* #5 TBD?
 +
* #6 TBD?
 +
* #7 TBD?
 +
* #8 TBD?
 +
* #9 TBD?
 
|-
 
|-
| Persist scheduler hints || Nova || Design review in progress  || https://blueprints.launchpad.net/nova/+spec/persist-scheduler-hints || https://review.openstack.org/#/c/88983/
+
| 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.
 
|-
 
|-
| Security groups using OpenFlow || Neutron || Design review in progress || https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver || https://review.openstack.org/#/c/89712/
+
| 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.
 
|-
 
|-
| Port mirroring || Neutron || Under discussion || https://blueprints.launchpad.net/neutron/+spec/port-mirroring ||
+
| 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 ||
 
|-
 
|-
| Traffic Steering Abstraction || Neutron || Design review in progress || https://blueprints.launchpad.net/neutron/+spec/traffic-steering-abstraction || https://review.openstack.org/92477/
+
| Heat Multi-region Support || Heat || Approved / Code Review || https://blueprints.launchpad.net/heat/+spec/multi-region-support || https://blueprints.launchpad.net/openstack/?searchtext=multi-region-support ||
 
|-
 
|-
 +
 
 
|}
 
|}
  
 
== Needed Development Not Yet Started ==
 
== Needed Development Not Yet Started ==
 +
 +
-->
 +
[[Category: Working_Groups]]

Latest revision as of 13:36, 25 November 2015

Mission statement and scope

The working group aims to define the use cases and identify and prioritise the requirements which are needed to deploy, manage, and run telecommunication services 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 telecommunication services.
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.

The work group has also established a team to focus ecosystem development (both vendors and industry co-travelers), collateral development and marketing messaging to address the needs to Telco operators who are interested in deploying OpenStack today.

Membership

Members of the Telco Working Group come from a broad array of backgrounds and include service providers, equipment providers, and OpenStack vendors. We aim to include both operators and developers in an open discussion about the needs of this sector and how to meet them in OpenStack. You can find the current membership list of at TelcoWorkingGroup/Members. Feel free to add your name If you're interested in working with us to improve OpenStack for telecommunications workloads.

Communication

IRC

Members of the working group hang out in the #openstack-nfv IRC channel on irc.freenode.net. Refer to IRC for more information on OpenStack IRC channels and how to use them.

Mailing Lists

The working group does not have a dedicated mailing list, instead using the existing openstack-dev and openstack-operators mailing lists:

These are high traffic lists, when sending mail pertaining to the working group include the [NFV] and [Telco] tags in the subject line, users filtering the list specifically for emails pertaining to the working group will do so based on these tags.

Refer to Mailing_Lists for more information on OpenStack mailing lists and how to use them.

Meetings

Technical Team Meetings

The working group meeting schedule is available at http://eavesdrop.openstack.org/#Telco_Working_Group_meeting

OpenStack IRC details

Upcoming Meetings

Agenda: [1]

Previous Meetings


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:

Glossary

TelcoWorkingGroup/Glossary

Related Teams and Projects

  • OpenStack Congress - Policy as a Service [2]

Development Efforts

Use Case Definition

Use cases are currently collected at TelcoWorkingGroup/UseCases, more are welcome! Definition of target use cases, and identification of gaps based on these, is a primary focus of this working group with the goal being to ensure that blueprints created to close these gaps are furnished with appropriately descriptive information on how they will actually be used in practice. Ultimately it is expected that this will help core review teams understand the need for a given feature when reviewing the blueprint and its associated specification.