requirements_projects:high_availability_for_opnfv
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
requirements_projects:high_availability_for_opnfv [2014/12/04 06:52] Qiao Fu |
requirements_projects:high_availability_for_opnfv [2015/03/17 06:42] (current) Qiao Fu |
||
|---|---|---|---|
| Line 2: | Line 2: | ||
| * Proposed name for the project: ''High availability for OPNFV'' | * Proposed name for the project: ''High availability for OPNFV'' | ||
| - | * Proposed name for the repository: ''HA'' | + | * Proposed name for the repository: ''availability'' |
| * Project Categories: ''(Requirements) '' | * Project Categories: ''(Requirements) '' | ||
| ====Project description: ==== | ====Project description: ==== | ||
| - | This project is based on the requirement proposal in “HA requirement-Chinamobile.pptx”, which is proposed in the initial TSC meeting. The proposal is focusing on the high availability requirements of the OPNFV platform regarding the Carrier Grade NFV scenarios. Some possible development of codes to meet the requirement may also be developed. | + | This project is based on the requirement proposal in “HA requirement-Chinamobile.pptx”, which is proposed in the initial TSC meeting. The proposal is focusing on the high availability requirements of the OPNFV platform regarding the Carrier Grade NFV scenarios. Specific codes to meet the requirements may also be developed later, e.g. in the subsequent integration & testing, and collaborative development projects. |
| In many existing networks, various forms of HA have been implemented for protecting from underlying physical hardware faults and failures, such as the 1:1 or active:standby model. Migrating network applications to a new implementation paradigm, anchored around the end-to-end NFV architecture, introduce new HA considerations and approaches. Hardware HA must still be managed, but now so too are the HA aspects of the virtual infrastructure, and the overall HA of the services provided by VNFs. In this project, we address HA requirements and solutions in 3 different perspectives, the hardware HA, the virtual infrastructure HA and the service HA, to be specific. | In many existing networks, various forms of HA have been implemented for protecting from underlying physical hardware faults and failures, such as the 1:1 or active:standby model. Migrating network applications to a new implementation paradigm, anchored around the end-to-end NFV architecture, introduce new HA considerations and approaches. Hardware HA must still be managed, but now so too are the HA aspects of the virtual infrastructure, and the overall HA of the services provided by VNFs. In this project, we address HA requirements and solutions in 3 different perspectives, the hardware HA, the virtual infrastructure HA and the service HA, to be specific. | ||
| Line 13: | Line 13: | ||
| The hardware HA can be solved by several legacy HA schemes. However, when considering the NFV scenarios, hardware failure will cause collateral damage to not only virtual infrastructures but also services running on it. Therefore, fault detection and report of HW failure from the hardware to VIM, VNFM and Orchestrator is necessary for the HA approaches in OPNFV. | The hardware HA can be solved by several legacy HA schemes. However, when considering the NFV scenarios, hardware failure will cause collateral damage to not only virtual infrastructures but also services running on it. Therefore, fault detection and report of HW failure from the hardware to VIM, VNFM and Orchestrator is necessary for the HA approaches in OPNFV. | ||
| - | Virtual infrastructure HA addresses the high availability mechanisms for NFV infrastructures and VIM. The HA schemes Openstack now have, which provides HA for different components for Openstack (such as Nova, Quantum, and etc.), can be categorized into this class. However, considering the Carrier Grade NFV scenarios, current HA schemes may not be enough. Gap analysis for Openstack HA schemes can be done in this project. Based on the analysis, further improvement and development can be done to improve the HA schemes for the virtual infrastructure. | + | Virtual infrastructure HA addresses the high availability mechanisms for NFV infrastructures and VIM. The HA schemes Openstack now have, which provides HA for different components for Openstack (such as Nova, Quantum, and etc.), can be categorized into this class. However, considering the Carrier Grade NFV scenarios, current HA schemes in OpenStack is possibly not efficient. However before enhancing the HA schemes in OpenStack, the Gap analysis for Openstack HA schemes to meet with OPNFV requirements (e.g. the Carrier Grade HA) should be studied in this project. Based on the analysis, further improvement and development can be done to improve the HA schemes for the virtual infrastructure in the scope of OPNFV. |
| - | There are several different mechanisms for the service HA. In this project, a white paper concluding these different mechanisms will be accomplished. Based on these mechanisms, we can further study what capability and interfaces OPNFV platform shall provide to the services. Therefore, API provided by the OPNFV platform to the services HA schemes should be well defined. | + | There are several different mechanisms for the service HA. In this project, a report concluding these different mechanisms will be accomplished. Based on these mechanisms, we can further study what capability and interfaces OPNFV platform shall provide to the services. Therefore, API provided by the OPNFV platform to the services HA schemes should be well defined. |
| In this project, we will first work on the HA requirements of Carrier Grade NFV. The requirements will include the hardware HA, the virtual infrastructure HA, and the service HA. HA API will then be well defined according to the requirements. Such API may include not only state update but also capability provision from the hardware and platform to the Orchestrator, the VNFM and different VNFs, | In this project, we will first work on the HA requirements of Carrier Grade NFV. The requirements will include the hardware HA, the virtual infrastructure HA, and the service HA. HA API will then be well defined according to the requirements. Such API may include not only state update but also capability provision from the hardware and platform to the Orchestrator, the VNFM and different VNFs, | ||
| Line 24: | Line 24: | ||
| For the service HA, studies about the current service HA schemes can be pulled out. In the meantime, API can be defined for state update and capability provision for the VNFs from the lower layers. Related interfaces may include vn-nf, vi-vnfm and or-vi. | For the service HA, studies about the current service HA schemes can be pulled out. In the meantime, API can be defined for state update and capability provision for the VNFs from the lower layers. Related interfaces may include vn-nf, vi-vnfm and or-vi. | ||
| - | |||
| - | Based on the output of this requirement project, corresponding testing may also be worked out about the HA APIs and possible development in the following integration and testing project. | ||
| ====Scope:==== | ====Scope:==== | ||
| - | • Propose high availability requirement for Carrier Grade NFV. | + | * Propose high availability requirement for Carrier Grade NFV. |
| - | + | * Define requirements for HA API. Related interfaces may include vl-ha, vn-nf, nf-vi, vi-vnfm, or-vi. | |
| - | • Define HA API. Related interfaces may include vl-ha, vn-nf, nf-vi, vi-vnfm, or-vi. | + | * Define the supporting key performance indicators (KPIs) for measuring the HA |
| - | + | * Gap analyses of Openstack HA schemes | |
| - | • Define the supporting KPIs for measuring the HA | + | * Report about service HA scheme study |
| - | + | * HA requirements for the SDN controller | |
| - | • Gap analyses of Openstack HA schemes | + | |
| - | + | ||
| - | • Whitepaper about service HA scheme study | + | |
| ====Possible work for the following projects==== | ====Possible work for the following projects==== | ||
| Line 48: | Line 43: | ||
| • Identify any open source upstream projects and release timeline. | • Identify any open source upstream projects and release timeline. | ||
| - | Related with Openstack | + | Related with Openstack, Opendaylight |
| • Identify any specific development be staged with respect to the upstream project and releases. | • Identify any specific development be staged with respect to the upstream project and releases. | ||
| Line 56: | Line 51: | ||
| • Are there any external fora or standard development organization dependencies. If possible, list and | • Are there any external fora or standard development organization dependencies. If possible, list and | ||
| - | None | + | The ETSI NFV REL GS (e.g. Draft ETSI GS NFV-REL 001 V1.0.0 (2014-11)) and the ongoing discussion in NFV REL field |
| ====Committers and Contributors:==== | ====Committers and Contributors:==== | ||
| - | • Name of and affiliation of the maintainer: | ||
| - | Qiao Fu (fuqiao@chinamobile.com) | + | Names and affiliations of the committers: |
| - | • Names and affiliations of the committers: | + | * Qiao Fu (fuqiao@chinamobile.com) |
| - | + | * Palani Chinnakannan (pals) [pals@cisco.com] | |
| - | Palani Chinnakannan (pals) [pals@cisco.com] | + | * Huailin Chen [huailin@arraynetworks.net] |
| + | * Jun Zhang [zhang.jun3g@zte.com.cn] | ||
| + | * Stefan Arntzen [Stefan.Arntzen@huawei.com] | ||
| + | * Yuyijun (Eugene) [yuyijun@huawei.com] | ||
| + | * xueyifei [xueyifei@huawei.com] | ||
| + | * Hellmann, Gil [gil.hellmann@windriver.com] | ||
| + | * Mario Cho [hephaex@gmail.com] | ||
| + | * Jonas Bjurel [jonas.bjurel@ericsson.com] | ||
| + | * Maria Toeroe [maria.toeroe@ericsson.com] | ||
| + | * Tamas Zsiros [tamas.zsiros@ericsson.com] | ||
| - | Huailin Chen [huailin@arraynetworks.net] | + | Names and affiliations of the contributers: |
| - | + | ||
| - | Jun Zhang [zhang.jun3g@zte.com.cn] | + | |
| - | + | ||
| - | Stefan Arntzen [Stefan.Arntzen@huawei.com] | + | |
| - | + | ||
| - | Yuyijun (Eugene) [yuyijun@huawei.com] | + | |
| - | + | ||
| - | xueyifei [xueyifei@huawei.com] | + | |
| - | + | ||
| - | Hellmann, Gil [gil.hellmann@windriver.com] | + | |
| - | + | ||
| - | Jonas Bjurel [jonas.bjurel@ericsson.com] | + | |
| - | + | ||
| - | Maria Toeroe [maria.toeroe@ericsson.com] | + | |
| - | + | ||
| - | Tamas Zsiros [tamas.zsiros@ericsson.com] | + | |
| - | + | ||
| - | + | ||
| - | • Any other contributors | + | |
| + | * Ian Jolliffe[Ian.Jolliffe@windriver.com] | ||
| + | * 'Hans Feldt'[hans.feldt@ericsson.com] | ||
| + | * Yao Cheng LIANG [ycliang@astri.org] | ||
| ====Planned deliverables==== | ====Planned deliverables==== | ||
| - | • HA requirement documents | + | • Report of HA Requirement (including KPI) |
| - | + | ||
| - | • HA API specification | + | |
| - | • KPIs for measuring the HA | + | • HA API Integration, Testing, and Development Guideline |
| - | • Openstack HA gap analyses | + | • HA Gap Analysis Report for OpenStack |
| - | • Whitepaper of service HA schemes | + | • Report of service HA schemes |
| ====Proposed Release Schedule:==== | ====Proposed Release Schedule:==== | ||
requirements_projects/high_availability_for_opnfv.1417675973.txt.gz · Last modified: 2014/12/04 06:52 by Qiao Fu
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
