TelcoWorkingGroup

= 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:


 * 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

OpenStack IRC details

Upcoming Meetings
Agenda:

Previous Meetings

 * Meeting logs
 * Meeting logs (archived)
 * Atlanta (Juno) Summit NFV BoF
 * Paris (Kilo) Summit Telco Working Group
 * Vancouver (Liberty) Summit Telco Working Group
 * Tokyo (Mitaka) Summit Telco Working Group]

= 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:
 * Definition of NFV by ETSI
 * Definition of NFV on Wikipedia

Glossary
TelcoWorkingGroup/Glossary

Related Teams and Projects

 * OpenStack Congress - Policy as a Service

= 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.

<!--== Active Bugs ==

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


 * Nova: https://bugs.launchpad.net/nova/+bugs?field.tag=nfv
 * Neutron: https://bugs.launchpad.net/neutron/+bugs?field.tag=nfv

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:

The rest:

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

Needed Development Not Yet Started
-->