User Tools

Site Tools


requirements_projects:escalator

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

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] (current)
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 releasedor 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 upgrade +  * the maximum duration of an upgrade 
-  * the maximum duration of a rollback when 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 upgrade is carried on +  ​* the granularity of an upgrade 
-  * the required mechanisms to prepare ​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
requirements_projects/escalator.1426055863.txt.gz · Last modified: 2015/03/11 06:37 by Jie Hu