Jump to: navigation, search

Difference between revisions of "TelcoWorkingGroup"

(Who we are)
(Technical Team Meetings)
 
(166 intermediate revisions by 54 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'''
 
  
= What is NFV? =
+
<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>
 +
 
 +
<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 =
  
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.
+
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.
  
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.
+
= Communication =
  
For more details on NFV, the following references may be useful:
+
== IRC ==
* [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]
 
  
= Who we are =
+
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.
  
''' 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. '''
+
== Mailing Lists ==
{| class="wikitable"
 
|-
 
  
 +
The working group does not have a dedicated mailing list, instead using the existing openstack-dev and openstack-operators mailing lists:
  
| adrian-hoban || Adrian Hoban || Intel OpenStack team || NFV & SDN extensions across OpenStack projects
+
* http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
|-
+
* http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
| akhila-chetlapalle || Akhila Chetlapalle || TCS Openstack Team || NFV & SDN Test Framework with Openstack
 
|-
 
| armax || Armando Migliaccio || HP || Neutron, NFV, SDN
 
|-
 
| arosen || Aaron Rosen || nicira/vmware || Automation, SDN/Neutron/NFV, Openstack
 
|-
 
| alank35 || Alan Kavanagh || Ericsson Inc || NFV & SDN & Neutron and ODL
 
|-
 
| 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
 
|-
 
| cdub || Chris Wright || Red Hat || NFV and SDN work between OpenStack and OpenDaylight
 
|-
 
| cgoncalves || Carlos Goncalves || Instituto de Telecomunicacoes || Service Function Chaining, Traffic Steering
 
|-
 
| cliljenstolpe || Christopher Liljenstolpe || Metaswitch Networks || Neutron, orchestration, network architecture
 
|-
 
| cloudon || Calum Loudon || Metaswitch Networks || Neutron, data plane acceleration, orchestration
 
|-
 
| danpb || Daniel Berrange || Red Hat || Libvirt, KVM & Nova performance & enablement for NFV
 
|-
 
| davidpc || David Perez Caparros || DOCOMO Euro-Labs || Supporting NFV in OpenStack
 
|-
 
| diga || Digambar Patil || Persistent System Ltd. || Neutron, Nova, SDN, NFV
 
|-
 
| dmitry_huawei || Dmitry Meytin || Huawei || MANO integration with OpenStack
 
|-
 
| 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
 
|-
 
| 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
 
|-
 
| jmsoares || Joao Soares || Portugal Telecom || Service Function Chaining, Traffic Steering
 
|-
 
| kalyan || Kalyanjeet Gogoi || Juniper Networks || NFV integration with OpenStack
 
|-
 
| 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
 
|-
 
| mpetrus || Margaret Petrus || VMware || NFV-MANO, OpenStack for Service Orchestration
 
|-
 
| 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
 
|-
 
| radek ||Radoslaw Smigielski||Alcatel-Lucent||OpenStack+NFV, SR-IOV, PCI passthrough, KVM performance
 
|-
 
| 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.
 
|-
 
| 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
 
|-
 
| thomnico || Nicolas Thomas || Canonical || Allowing OpenStack to be gradually used in NFV type of deployments ETSI NFV IG participant.
 
|-
 
| tvvcox || Tomas Von Veschler || Red Hat || Openstack enablement for NFVi and VIM
 
|-
 
| ulikleber || Ulrich Kleber || Huawei || Help better support NFV
 
|-
 
| 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
 
|-
 
| 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
 
|-
 
| zuqiang || Zu Qiang || Ericsson || NFV support in OpenStack
 
|}
 
  
= Mission statement =
+
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.
  
<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>
+
Refer to [[Mailing_Lists]] for more information on OpenStack mailing lists and how to use them.
  
<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>
+
= Meetings =
 +
  
[[IRC|OpenStack IRC details]]
+
== Technical Team Meetings ==
  
Chair: Russell Bryant (russellb)
+
The working group meeting schedule is available at http://eavesdrop.openstack.org/#Telco_Working_Group_meeting
  
== Agenda for next meeting ==
+
[[IRC|OpenStack IRC details]]
  
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.
+
=== Upcoming Meetings ===  
  
 
Agenda: [https://etherpad.openstack.org/p/nfv-meeting-agenda]
 
Agenda: [https://etherpad.openstack.org/p/nfv-meeting-agenda]
  
== Previous meetings ==
+
=== Previous Meetings ===  
 
 
* [http://eavesdrop.openstack.org/meetings/nfv/ Meeting logs]
 
* [https://etherpad.openstack.org/p/juno-nfv-bof Juno Design Summit NFV BoF]
 
  
=Use Cases=
+
* [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"
 
|-
 
|-
! Workload Type !! Description || Characteristics !! Examples !! Requirements
+
! 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
 +
|-
 +
| 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
 +
|-
 +
| 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
 
|-
 
|-
| Data plane || Tasks related to packet handing in an end-to-end communication between edge applications. ||
+
| 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
* 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. ||
+
| 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
* 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
+
| 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
||  
 
* 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.
+
| 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
||
 
* 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 ==
+
= What is NFV? =
  
===Use Case #1: Network Functions Virtualisation Infrastructure as a Service===
+
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.
  
This is a reasonably generic IaaS requirement.  
+
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.
  
===Use Case #2: Virtual Network Function as a Service (VNFaaS)===
+
For more details on NFV, the following references may be useful:
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.
+
* [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]
===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===
+
== Glossary ==
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===
+
[[TelcoWorkingGroup/Glossary]]
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====
 
 
 
* Fast & guaranteed performance (network)
 
** Packets per second target -> either SR-IOV or an accelerated DPDK-like data plane:
 
*** "SR-IOV Networking Support" (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov)
 
*** "Open vSwitch to use patch ports" (https://blueprints.launchpad.net/neutron/+spec/openvswitch-patch-port-use)
 
*** "userspace vhost in ovd vif bindings" (https://blueprints.launchpad.net/nova/+spec/libvirt-ovs-use-usvhost)
 
*** "Snabb NFV driver" (https://blueprints.launchpad.net/neutron/+spec/snabb-nfv-mech-driver)
 
*** "VIF_VHOSTUSER"  (https://blueprints.launchpad.net/nova/+spec/vif-vhostuser)
 
 
 
* Fast & guaranteed performance (compute):
 
** To optimize data rate we need to keep all working data in L3 cache:
 
***"Virt driver pinning guest vCPUs to host pCPUs" (https://blueprints.launchpad.net/nova/+spec/virt-driver-cpu-pinning)
 
** To optimize data rate need to bind to NIC on host CPU's bus:
 
*** "I/O (PCIe) Based NUMA Scheduling" (https://blueprints.launchpad.net/nova/+spec/input-output-based-numa-scheduling)
 
**To offer guaranteed performance as opposed to 'best efforts' we need:
 
** To control placement of cores, minimise TLB misses and get accurate info about core topology (threads vs. hyperthreads etc.); maps to the remaining blueprints on NUMA & vCPU topology:
 
*** "Virt driver guest vCPU topology configuration" (https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology)
 
*** "Virt driver guest NUMA node placement & topology" (https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement)
 
*** "Virt driver large page allocation for guest RAM" (https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages)
 
** May need support to prevent 'noisy neighbours' stealing L3 cache - unproven, and no blueprint we're aware of.
 
 
 
* 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.
 
 
 
* VLAN trunking:
 
** "VLAN trunking networks for NFV" (https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks et al).
 
 
 
* Other:
 
** Being able to offer apparent traffic separation (e.g. service traffic vs. application management) over single network is also useful in some cases.
 
*** "Support two interfaces from one VM attached to the same network" (https://blueprints.launchpad.net/nova/+spec/multiple-if-1-net)
 
 
 
== References: ==
 
* [http://docbox.etsi.org/ISG/NFV/Open/Latest_Drafts/NFV-PER001v009%20-%20NFV%20Performance%20&%20Portability%20Best%20Practises.pdf Network Functions Virtualization NFV Performance & Portability Best Practices - DRAFT]
 
* ETSI-NFV Use Cases V1.1.1 [http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v010101p.pdf]
 
  
 
== Related Teams and Projects ==
 
== Related Teams and Projects ==
Line 310: Line 93:
 
= Development Efforts =
 
= Development Efforts =
  
== Active Bugs ==
+
== 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.
 +
 
 +
<!--== 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 324: Line 111:
 
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(s)  !! ETSI-NFV Use Cases
 
! Description !! Project(s) !! Status !! Blueprint(s) !! Design(s)  !! ETSI-NFV Use Cases
|-
 
| Support two interfaces from one VM attached to the same network || Nova || first BP submit || https://blueprints.launchpad.net/nova/+spec/multiple-if-1-net || https://review.openstack.org/97716 https://review.openstack.org/98488 (patch?) ||
 
* #1 is a broadly applicable IaaS requirement.
 
* #2 TBD?
 
* #3 TBD?
 
* #4 TBD?
 
* #5 TBD?
 
* #6 TBD?
 
* #7 TBD?
 
* #8 TBD?
 
* #9 TBD?
 
 
|-
 
|-
 
| VLAN trunking networks for NFV
 
| VLAN trunking networks for NFV
Line 346: Line 122:
 
management of VLANs on ports as sub-ports (nice to have, not a blocker)
 
management of VLANs on ports as sub-ports (nice to have, not a blocker)
 
| Neutron  
 
| Neutron  
| first BP submit
+
| New
 
| https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks (tenant trunking)  
 
| 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/l2-gateway (physical appliance-specific decomposition)
Line 364: Line 140:
 
* #9 TBD?
 
* #9 TBD?
 
|-
 
|-
| Permit unaddressed interfaces for NFV use cases || Neutron || first BP submit
+
| 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://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/ ||  
 
| https://review.openstack.org/97715 https://review.openstack.org/#/c/99873/ ||  
Line 383: Line 159:
 
neutron port enhancement related to servicevm is summarized at https://wiki.openstack.org/wiki/ServiceVM/neutron-port-attributes
 
neutron port enhancement related to servicevm is summarized at https://wiki.openstack.org/wiki/ServiceVM/neutron-port-attributes
  
{| class="wikitable"
+
{| class="wikitable sortable"
 
|-
 
|-
 
! Description !! Project(s) !! Status !! Blueprint(s) !! Design(s) !! ETSI-NFV Use Cases
 
! Description !! Project(s) !! Status !! Blueprint(s) !! Design(s) !! ETSI-NFV Use Cases
|-
 
| SR-IOV Networking Support || Nova || Design Approved || 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.
 
|-
 
| colspan="3" | ''Support for NUMA and VCPU topology configuration'' || ''https://blueprints.launchpad.net/nova/+spec/nova-virt-numa-and-vcpu-topology'' || ||
 
* #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 guest vCPU topology configuration
+
Virt driver guest NUMA node placement & topology
|| Nova || Design Approved || 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.
 
* #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 guest NUMA node placement & topology
 
|| Nova || Design review Approved ||  https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement || https://review.openstack.org/93636 ||
 
 
* #1 is a broadly applicable IaaS requirement.  
 
* #1 is a broadly applicable IaaS requirement.  
 
* #2 Needed for performance reasons.
 
* #2 Needed for performance reasons.
Line 436: Line 177:
 
|-
 
|-
 
|
 
|
: 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.  
 
* #1 is a broadly applicable IaaS requirement.  
 
* #2 Needed for performance reasons.
 
* #2 Needed for performance reasons.
Line 449: Line 190:
 
|-
 
|-
 
|
 
|
: 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.  
 
* #1 is a broadly applicable IaaS requirement.  
 
* #2 Needed for performance reasons.
 
* #2 Needed for performance reasons.
Line 463: Line 204:
 
|
 
|
 
: I/O (PCIe) Based NUMA Scheduling  
 
: I/O (PCIe) Based NUMA Scheduling  
|| Nova || Design Approved || https://blueprints.launchpad.net/nova/+spec/input-output-based-numa-scheduling || https://review.openstack.org/#/c/100871/ ||
+
|| 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.  
 
* #1 is a broadly applicable IaaS requirement.  
 
* #2 Needed for performance reasons.
 
* #2 Needed for performance reasons.
Line 474: Line 215:
 
* #9 Needed for performance reasons.
 
* #9 Needed for performance reasons.
 
|-
 
|-
| 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 ||
+
| 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.  
 
* #1 is a broadly applicable IaaS requirement.  
 
* #2 TBD?
 
* #2 TBD?
Line 496: Line 237:
 
* #9 Needed in the non-SR-IOV based deployments.
 
* #9 Needed in the non-SR-IOV based deployments.
 
|-
 
|-
| Framework for Advanced Services in Virtual Machines || Neutron || || https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms || ||
+
| 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.  
 
* #1 is a broadly applicable IaaS requirement.  
 
* #2 Potential lifecycle management support
 
* #2 Potential lifecycle management support
Line 507: Line 248:
 
* #9 Potential lifecycle management support
 
* #9 Potential lifecycle management support
 
|-
 
|-
| Neutron Services Insertion, Chaining, and Steering || Neutron || Approved || https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering || https://review.openstack.org/93524 ||
+
| 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?
 
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.  
 
* #1 is a broadly applicable IaaS requirement.  
Line 519: Line 260:
 
* #9 May need to chain multiple functions to deliver a service.
 
* #9 May need to chain multiple functions to deliver a service.
 
|-
 
|-
| 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 ||
+
| 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 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.
 
|-
 
| OVF Meta-Data Import via Glance || Glance || Design review in progress || https://blueprints.launchpad.net/glance/+spec/epa-ovf-meta-data-import || https://review.openstack.org/#/c/104904/ ||
 
 
* #1 is a broadly applicable IaaS requirement.  
 
* #1 is a broadly applicable IaaS requirement.  
 
* #2 Needed as one optional path to auto import platform feature requests to meet performance targets.  
 
* #2 Needed as one optional path to auto import platform feature requests to meet performance targets.  
Line 545: Line 275:
 
|
 
|
 
: 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 || Design review in progress || https://blueprints.launchpad.net/neutron/+spec/openvswitch-patch-port-use  || https://review.openstack.org/96183 ||
+
|| 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.  
 
* #1 is a broadly applicable IaaS requirement.  
 
* #2 Needed in the non-SR-IOV based deployments.
 
* #2 Needed in the non-SR-IOV based deployments.
Line 569: Line 302:
 
* #9 Needed in the non-SR-IOV based deployments.
 
* #9 Needed in the non-SR-IOV based deployments.
 
|-
 
|-
| NIC state aware scheduling || Nova || Rejected || https://blueprints.launchpad.net/nova/+spec/nic-state-aware-scheduling || https://review.openstack.org/87978 ||
+
| [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 to help with service delivery
 
* #3 TBD?
 
* #4 Need to understand if the ports are up when deploying the service chain.
 
* #5 Needed to help with service delivery
 
* #6 Needed to help with service delivery
 
* #7 Needed to help with service delivery
 
* #8 Needed to help with service delivery
 
* #9 Needed to help with service delivery
 
|-
 
| Add PCI and PCIe device capability aware scheduling || Nova || Abandoned || https://blueprints.launchpad.net/nova/+spec/pci-device-capability-aware-scheduling  || https://review.openstack.org/92843 ||
 
* #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
 
|-
 
| [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 ||
 
 
* #1 is a broadly applicable IaaS requirement.  
 
* #1 is a broadly applicable IaaS requirement.  
 
* #2 Needed in the non-SR-IOV based deployments.
 
* #2 Needed in the non-SR-IOV based deployments.
Line 602: Line 313:
 
* #9 Needed in the non-SR-IOV based deployments.
 
* #9 Needed in the non-SR-IOV based deployments.
 
|-
 
|-
| VIF_VHOSTUSER (qemu vhost-user) support || Nova || Submitted w/ code || https://blueprints.launchpad.net/nova/+spec/vif-vhostuser || https://review.openstack.org/96138 ||
+
| 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.  
 
* #1 is a broadly applicable IaaS requirement.  
 
* #2 Needed in the non-SR-IOV based deployments.
 
* #2 Needed in the non-SR-IOV based deployments.
Line 645: Line 356:
 
* #8 Needed for performance reasons
 
* #8 Needed for performance reasons
 
* #9 Needed for performance reasons
 
* #9 Needed for performance reasons
|-
 
| Persist scheduler hints || Nova || Design review in progress  || https://blueprints.launchpad.net/nova/+spec/persist-scheduler-hints || https://review.openstack.org/#/c/88983/ ||
 
* #1 is a broadly applicable IaaS requirement.
 
* #2 Needed for performance reasons on migration.
 
* #3 TBD?
 
* #4 TBD?
 
* #5 Needed for performance reasons on migration.
 
* #6 Needed for performance reasons on migration.
 
* #7 Needed for performance reasons on migration.
 
* #8 Needed for performance reasons on migration.
 
* #9 Needed for performance reasons on migration.
 
 
|-
 
|-
 
| Port mirroring || Neutron || Under discussion || https://blueprints.launchpad.net/neutron/+spec/port-mirroring || ||
 
| Port mirroring || Neutron || Under discussion || https://blueprints.launchpad.net/neutron/+spec/port-mirroring || ||
Line 679: Line 379:
 
* #9 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.
 
|-
 
|-
| Evacuate instance to scheduled host || Nova || Needs code review || https://blueprints.launchpad.net/nova/+spec/find-host-and-evacuate-instance || https://review.openstack.org/84429 ||
+
|}
 +
 
 +
=== Implemented (Juno) ===
 +
 
 +
{| class="wikitable sortable"
 +
|-
 +
! 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 ||
 +
* 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?
 +
|-
 +
| 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.
 
|-
 
|-
| Extensible resource tracker (dependency of other work) || Nova || Design Approved || https://blueprints.launchpad.net/nova/+spec/extensible-resource-tracking || https://review.openstack.org/#/c/86050/ ||
+
| 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 ||
 
|-
 
|-
 +
| 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.