This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
requirements_projects:escalator [2015/03/11 06:37] Jie Hu [Committers and Contributors:] |
requirements_projects:escalator [2015/04/10 07:21] Jie Hu [Committers and Contributors:] |
||
---|---|---|---|
Line 8: | Line 8: | ||
In the traditional Telco operator’s network, the service (software) is often bound with dedicated hardware and platform. It is easy to upgrade the whole system on demand. In some cases, software or system update called ISSU (In-Service Software Update) could be done without service interruption. | In the traditional Telco operator’s network, the service (software) is often bound with dedicated hardware and platform. It is easy to upgrade the whole system on demand. In some cases, software or system update called ISSU (In-Service Software Update) could be done without service interruption. | ||
- | With the technical benefit of virtualization, NFV frameworks provides a scalable container for each VNF (service software), and de-couples them from the platform and hardware (NFVI). | + | With the technical benefit of virtualization, NFV framework provides a scalable container for each VNF (service software), and de-couples them from the platform and hardware (NFVI). |
- | As we know, OPNFV is committed to provide an open source platform implementation of NFVI to host Telco services / Network Functions. Currently more than 10 projects have been approved, and more proposals have been created. There will be 2 OPNFV release version per year, just like Openstack community. | + | As we know, OPNFV is committed to provide an open source platform implementation of NFVI and VIM to host Telco services / Network Functions. Currently more than 10 projects have been approved, and more proposals have been created. There will be 2 OPNFV release version per year, just like Openstack community. |
- | OPNFV community must provide some kind of mechanism to assure the operators can perform smooth upgrade of the NFVI and VIM without service interruption when a new version is released or required. | + | OPNFV community must provide some kind of mechanism to assure the operators can perform smooth upgrade of the NFVI and VIM without service interruption when a new major(full set of components with new functions) is released, or a minor version (partial set of components with bug fixed) is required. |
{{ :requirements_projects:opnfv_escalator.png?200|}} | {{ :requirements_projects:opnfv_escalator.png?200|}} | ||
This project is aiming to identify the user requirements on smooth upgrade the NFVI and VIM from one version to another. Such as: | This project is aiming to identify the user requirements on smooth upgrade the NFVI and VIM from one version to another. Such as: | ||
- | * the maximum duration of a upgrade | + | * the maximum duration of an upgrade |
- | * the maximum duration of a rollback when a upgrade is failed | + | * the maximum duration of a rollback when an upgrade is failed |
* the maximum duration of a VNF interruption | * the maximum duration of a VNF interruption | ||
- | * the required mechanisms when a upgrade is carried on | + | * the granularity of an upgrade |
- | * the required mechanisms to prepare a upgrade | + | * the required mechanisms when an upgrade is carried on |
+ | * the required mechanisms to prepare an upgrade | ||
* the potential I/F between VIM and VNF Manager / NFV Orchestrator if needed | * the potential I/F between VIM and VNF Manager / NFV Orchestrator if needed | ||
* the information flows among the related entities | * the information flows among the related entities | ||
Line 35: | Line 36: | ||
* Describe the problem being solved by project | * Describe the problem being solved by project | ||
* In Telco network, a planned network/service interruption for upgrade should be recovered in a short time. This has not been considered by the upstream projects yet. | * In Telco network, a planned network/service interruption for upgrade should be recovered in a short time. This has not been considered by the upstream projects yet. | ||
- | * Upgrade platform will leads to pay a lot of efforts on testing the compatible with the services / network entities and preventing the end users from big influences. | + | * Upgrade platform need a lot of efforts on preparation to avoid making troubles on end users accessing the network services during the upgrading. |
* Specify any interface/API specification proposed, | * Specify any interface/API specification proposed, | ||
- | * Nf-Vi for control the upgrade procedure | + | * interface/API for controlling the upgrade procedure |
- | * Vi-Vnfm for ensure a VNF friendly upgrade | + | * interface/API for sending notifications of the upgrade procedure |
- | * Oi-Vi for supporting the policy control from NFV Orchestrator | + | * interface/API for interacting with the Orchestrate or OSS |
* Specify testing and integration: | * Specify testing and integration: | ||
* TBD | * TBD | ||
Line 54: | Line 55: | ||
* Smooth Upgrade | * Smooth Upgrade | ||
* Safe Rollback | * Safe Rollback | ||
+ | * In the scope: | ||
+ | * Develop an use cases section for upgrade related operations to clarify the scope. | ||
+ | * Joint work with other dependent OPNFV projects, HA, Multisite, etc. | ||
+ | * High level requirements on the compatibility of OPNFV platform. | ||
* Out of scope: | * Out of scope: | ||
* VNF Lifecycle Management, including VNF upgrade and update | * VNF Lifecycle Management, including VNF upgrade and update | ||
- | * Abnormal Failure of OPNFV platform | ||
- | * High Availability | ||
- | * Security | ||
* Describe how the project is extensible in future | * Describe how the project is extensible in future | ||
- | * Codes / Automaton scripts to implement related mechanisms if available in the future. | + | * Architecture, Codes / Automaton scripts to implement related mechanisms if available in the future. |
+ | * Blue Prints to the upstream projects. | ||
==== Testability: ''(optional, Project Categories: Integration & Testing)'' ==== | ==== Testability: ''(optional, Project Categories: Integration & Testing)'' ==== | ||
Line 77: | Line 80: | ||
* Identify any open source upstream projects and release timeline. | * Identify any open source upstream projects and release timeline. | ||
* Openstack | * Openstack | ||
+ | * ODL | ||
* 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. | ||
* TBD | * TBD | ||
Line 90: | Line 94: | ||
* Ulrich Kleber ([[Ulrich.Kleber@huawei.com]]) | * Ulrich Kleber ([[Ulrich.Kleber@huawei.com]]) | ||
* Names and affiliations of any other contributors | * Names and affiliations of any other contributors | ||
+ | * Maria Toeroe ([[maria.toeroe@ericsson.com]]) | ||
+ | * Sama, Malla Reddy ([[sama@docomolab-euro.com]]) | ||
* Zhong Chao ([[chao.zhong@zte.com.cn]]) | * Zhong Chao ([[chao.zhong@zte.com.cn]]) | ||
* Julien Zhang ([[zhang.jun3g@zte.com.cn]]) | * Julien Zhang ([[zhang.jun3g@zte.com.cn]]) | ||
* Yuri Yuan ([[yuan.yue@zte.com.cn]]) | * Yuri Yuan ([[yuan.yue@zte.com.cn]]) | ||
+ | * Zhipeng Huang ([[huangzhipeng@huawei.com]]) | ||
* //more contributors are welcome// | * //more contributors are welcome// | ||
==== Planned deliverables ==== | ==== Planned deliverables ==== | ||
Line 108: | Line 115: | ||
* Gap Analysis on OPNFV Escalator with open source upstream projects (October 2015) | * Gap Analysis on OPNFV Escalator with open source upstream projects (October 2015) | ||
* Will this align with the current release cadence | * Will this align with the current release cadence | ||
- | * It will align with the 2nd release of OPNFV | + | * It will align with the 2nd or 3rd release of OPNFV |