project_proposals:nfvreadyness
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
project_proposals:nfvreadyness [2016/03/12 03:22] Georg Kunz [Scope:] |
project_proposals:nfvreadyness [2016/03/15 16:59] (current) Georg Kunz |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | |||
| + | ====== Note ====== | ||
| + | |||
| + | **Outdated Wiki** | ||
| + | |||
| + | This project proposal has been renamed to NetReady. Please find the updated wiki here: [[https://wiki.opnfv.org/project_proposals/netready]] | ||
| + | |||
| + | **Outdated Wiki** | ||
| + | |||
| + | |||
| ==== Project Name: ==== | ==== Project Name: ==== | ||
| Line 18: | Line 28: | ||
| - | **Example NFV use cases** | + | === Example NFV use cases === |
| - | It is a fundamental goal of the proposed project to jointly define relevant NFV use cases in the first project phase. The following list comprises **examples** for an initial scope. This list is neither complete nor exclusive and will be reviewed and extended in the first phase of the project: | + | It is a goal of the proposed project to identify relevant NFV use cases and their requirements in the first phase of the project. The following list shows **examples** of potentially relevant use cases. This list is neither complete nor exclusive and will be reviewed and extended in the first phase of the project: |
| * L3 VPN | * L3 VPN | ||
| Line 27: | Line 37: | ||
| - | **Observations** | + | === Observations === |
| Initial observations reveal the following list of challenges when attempting to implement NFV-related use cases in the current Openstack networking architecture. A full list of challenges will be the result of a detailed gap analysis based on the requirements of the identified use cases and the current Openstack networking architecture. | Initial observations reveal the following list of challenges when attempting to implement NFV-related use cases in the current Openstack networking architecture. A full list of challenges will be the result of a detailed gap analysis based on the requirements of the identified use cases and the current Openstack networking architecture. | ||
| Line 42: | Line 52: | ||
| 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 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. | ||
| + | Edge Computing use case for Cloudlet Handoff: | ||
| + | Cloudlet Handoff across two sites with network connections either L2 and/or L3 similar to L3 VPN diagram above. | ||
| + | This is not same as live migration of VM across two Data Centers with applications within those VMs who need to restart from one site to another without context. | ||
| - | ** Phasing ** | + | But having Cloudlet as pre-instantiated VM instances from pre-identified low footprint images like say a 4 or 8 GB VM (base images) at two or more connected hosts/hypervisors/sites(clusters) with cloudlets (network + application) context data being transmitted as part of Handoff from one instance of cloudlet VM to another with all context being transferred as an delta image or blob. (the terminology used in Cloudlet is Overlay for context saving as images and computing disk and memory deltas. The network context saved as part of delta changes when we resume the merged overlay and base images at the new VM and that is where we have options to do through Neutron L2 or L3 and to make this happen we need possibly changes to Nova-Neutron or Nova-Neutron-SDN interactions, very similar to VPN use cases for Network ReadyNeSs. [Refer for Cloudlet for OpenStack: https://en.wikipedia.org/wiki/Cloudlet ] |
| + | |||
| + | |||
| + | |||
| + | === Phasing === | ||
| The planned stages of the project are the following: | The planned stages of the project are the following: | ||
| Line 59: | Line 76: | ||
| - Start evaluating selected alternatives as identified in 3.1 based on the strategy defined in 3.2 | - Start evaluating selected alternatives as identified in 3.1 based on the strategy defined in 3.2 | ||
| - Document the results of the evaluation process and decide about the preferred solution | - Document the results of the evaluation process and decide about the preferred solution | ||
| + | - Recommend next steps in upstream development and drive upstream solution if needed | ||
| * Planned duration: 3 months. Input to Openstack P release summit | * Planned duration: 3 months. Input to Openstack P release summit | ||
| Line 68: | Line 86: | ||
| 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. | 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 ** | + | === Fulfilling the principles of OPNFV === |
| * the first stage of the project is intended to focus on discussing and capturing the use cases that we are aiming to find a solution for and clearly articulate and document the problem space | * the first stage of the project is intended to focus on discussing and capturing the use cases that we are aiming to find a solution for and clearly articulate and document the problem space | ||
| Line 74: | Line 92: | ||
| - | ** Requirements on potential solutions ** | + | === Requirements on potential solutions === |
| The project aims to identify and evaluate the possible solutions that can fulfill the requirements with following statements and criterias: | The project aims to identify and evaluate the possible solutions that can fulfill the requirements with following statements and criterias: | ||
| Line 89: | Line 107: | ||
| - | ** Repository and Source Code Handling ** | + | === 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. | The outcome of the project, that is the requirements document and the complementary prototyping code, will be hosted in public repositories. | ||
| Line 117: | Line 135: | ||
| SDNVPN: While L3VPN is one of the use cases in the scope of this project, there is no overlap with the existing SDNVPN project in OPNFV. The goal of the SDNVPN project is to ensure the integration of the OpenStack BGPVPN API and the ODL backend driver to make it available in the OPNFV platform. It does not cover a gap analysis to identify how to evolve the Openstack networking API. | SDNVPN: While L3VPN is one of the use cases in the scope of this project, there is no overlap with the existing SDNVPN project in OPNFV. The goal of the SDNVPN project is to ensure the integration of the OpenStack BGPVPN API and the ODL backend driver to make it available in the OPNFV platform. It does not cover a gap analysis to identify how to evolve the Openstack networking API. | ||
| + | |||
| + | OEC: While VM Handoff for Edge Computing is proposed in Cloudlet under OEC, it is limited due to OpneStack Nova-Neutron interactions and need the ability to enhance the same with flexibility with evolution of SDN and WAN technologies. The VM Handoff for Cloudlet is being considered as a use case for NFVReadyNeSs to addrees the same in OPNFV. You can refer to OEC at http://www.openedgecomputing.org/. | ||
| Line 133: | Line 153: | ||
| * Bin Hu (AT&T), bh526r@att.com | * Bin Hu (AT&T), bh526r@att.com | ||
| * Ashlee Young (Huawei), ashlee@wildernessvoice.com | * Ashlee Young (Huawei), ashlee@wildernessvoice.com | ||
| + | * Juraj Linkes (jlinkes@cisco.com) | ||
| + | * Viliam Luc -X (vluc@cisco.com) | ||
| + | |||
| * Names and affiliations of any other contributors | * Names and affiliations of any other contributors | ||
project_proposals/nfvreadyness.1457752927.txt.gz · Last modified: 2016/03/12 03:22 by Georg Kunz
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
