This is an old revision of the document!
NFVReadyNeSs (NFV Ready Networking Services)
nfvreadyness
OPNFV provides an infrastructure with different SDN controller options to realize NFV functionality on the platform it builds. As OPNFV uses OpenStack as VIM, we need to analyse the capabilities this component offers us. The networking functionality is provided by a single component called Neutron, which hides the controller under it, let it be Neutron itself or any supported SDN controller. As NFV wasn't taken into consideration at the time when Neutron was designed we are already facing several bottlenecks and architectural shortcomings while implementing our use cases.
The NFVReadyNeSs project aims at evolving OpenStack networking step-by-step to find the most efficient way to fulfill the requirements of the identified NFV use cases, taking into account the NFV mindset and the capabilities of SDN controllers.
The base set of use cases the project focuses on is the following:
More use cases may be included as they show up during the evolution of the project.
Examples for L3VPN use cases:
The intention to implement these use cases with using OpenStack Neutron highlights a conceptual mismatch regarding the aimed architectural and functional design.
As a highlight, the list of the limitations of the OpenStack architecture and Neutron includes the following items:
The NFVReadyNeSs project focuses on addressing the limitations within OpenStack in order to open up an easier and more efficient way of addressing telecom specific use cases and making the platform NFV ready by enabling a more flexible integration of SDN controllers.
The planned stages of the project are the following:
The primary scope of the project is not focusing on implementation work, but it includes prototyping activity as well. The scope of the implementation work within the project is limited to provide the support for and fulfill the requirements defined by the identified NFV use cases.
The project is intended to focus on the API layer of both the networking service in OpenStack and the SDN controllers in OPNFV's scope evaluating their best way of integration into OpenStack in order to efficiently fulfill NFV needs and the given requirements. Gluon is considered one prototyping activity out of a potential set of alternatives and hence not decided to be the preferred solution/implementation before finishing the evaluation phase.
Fulfilling the principles of OPNFV:
The project aims to identify and evaluate the possible solutions that can fulfill the requirements with following statements and criterias:
The project does not have a proposed architecture at this point. The provided outcome has to fulfill the requirements specified above. It is also important to state that the project does not have a necessary interest in creating a new component in OpenStack. The final architecture of the solution has to be chosen by the results of the evaluation process.
For evaluating the alternatives in consideration the project is intended to use the OPNFV labs and CI infrastructure.
Repository and Source Code Handling:
The outcome of the project, that is the requirements document and the complementary prototyping code, will be hosted in public repositories.
Testing should leverage the integration effort that has been done in OPNFV so far to support different choices of available SDN controllers. The project will need to investigate the possibilities to extend the tested platform with the prototypes under evaluation.
The project can consider an integration point with the OPNFV SFC project to run existing functional tests to evaluate the prototypes/validate the solution. As the project focuses on finding an efficient way to integrate SDN controllers into OpenStack the created functional tests shall validate this aim.
The project will produce a document that captures the use cases, requirements and work to fufill our needs. The final solution should be integrated into OpenStack, which means that the related documentations should be added to OpenStack and referenced from OPNFV documentations.
There is no known OPNFV project or project proposal that covers the activities desccribed for this project.
The project has a dependency on OpenStack, which means it has to follow the release cycle and process with all activities that affect projects which are part of OpenStack Big Tent. In case of creating new OpenStack project(s) the release cycle will be a constarint only after the project is included in Big Tent.
The networking APIs should follow the existing standardization guidelines if any.
The project will produce documentation to identify requirements and architecture during the C-release. The earliest OpenStack release to add our solution to is Newton, which means the D-release of OPNFV.
The project will follow the OPNFV and OpenStack release schedules.
Project Name: NFVReadyNeSs (nfvreadyness)
Repo name: nfvreadyness
Lifecycle State: proposal
Primary Contact: georg.kunz@ericsson.com
Project Lead: TBD
Jira Project Name: nfvreadyness
Jira Project Prefix: [nfvreadyness]
mailing list tag [nfvreadyness]
Committers:
georg.kunz@ericsson.com
ildiko.vancsa@ericsson.com
nikolas.hermanns@ericsson.com
bh526r@att.com
ashlee@wildernessvoice.com
Link to TSC approval:
Link to approval of additional submitters: