Wiki

• Proposed name for the project: High availability for OPNFV
• Proposed name for the repository: availability
• Project Categories: (Requirements)

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.

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 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 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,

For hardware HA, legacy HA mechanisms will be studied. Considering the NFV scenario, API will be defined for the hardware to inform the up-layers about its states and its capability. Related interfaces may include vl-hw, nf-vi, vi-vnfm, and or-vi.

For the virtual infrastructure HA, gap analyses of HA mechanism will be proposed for the current Openstack. Advance mechanisms of OPNFV HA can be studied and developed. And corresponding Openstack extension can then be developed in the following collaborative development project.

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.

• 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 the supporting key performance indicators (KPIs) for measuring the HA
• Gap analyses of Openstack HA schemes
• Report about service HA scheme study
• HA requirements for the SDN controller

• Openstack extension and development on HA

• Testcases of OPNFV HA API and development.

• Identify any open source upstream projects and release timeline.

Related with Openstack, Opendaylight

• Identify any specific development be staged with respect to the upstream project and releases.

Implementation will be tied to a recent and relevant OpenStack release, with Ice House or later release being a likely target.

• Are there any external fora or standard development organization dependencies. If possible, list and

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

Names and affiliations of the committers:

• Qiao Fu (fuqiao@chinamobile.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]

Names and affiliations of the contributers:

• Ian Jolliffe[Ian.Jolliffe@windriver.com]
• 'Hans Feldt'[hans.feldt@ericsson.com]
• Yao Cheng LIANG [ycliang@astri.org]

• Report of HA Requirement (including KPI)

• HA API Integration, Testing, and Development Guideline

• HA Gap Analysis Report for OpenStack

• Report of service HA schemes

• When is the first release planned?

Tentative March 2, 2015

• Will this align with the current release cadence

May not be as part of the 1st release