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 02:33]
Jie Hu [Project description:]
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 34: Line 35:
  
   * Describe the problem being solved by project   * Describe the problem being solved by project
-    ​* 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.  +    * 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.+    * 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 MANO+      interface/​API ​for interacting with the Orchestrate or OSS
   * Specify testing and integration:​   * Specify testing and integration:​
-    ​* TBD+      ​* TBD
   * Debugging and Tracing ​   * Debugging and Tracing ​
-    ​* TBD+      ​* TBD
   * Unit/​Integration Test plans   * Unit/​Integration Test plans
-    ​* TBD+      ​* TBD
   * Client tools developed for status shows etc.   * Client tools developed for status shows etc.
-    ​* TBD  ​+      ​* TBD  ​
   * Identity a list of features and functionality will be developed.   * Identity a list of features and functionality will be developed.
-    ​* Upgrade Validation +      ​* Upgrade Validation 
-    * Upgrade Notification +      * Upgrade Notification 
-    * Upgrade Monitor +      * Upgrade Monitor 
-    * 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
   * Are there any external fora or standard development organization dependencies. If possible, list and informative and normative reference specifications.   * Are there any external fora or standard development organization dependencies. If possible, list and informative and normative reference specifications.
-    * TBD+    * None
   * If project is an integration and test, identify hardware dependency.   * If project is an integration and test, identify hardware dependency.
-    * (Hardware independent)+    * N/A
 ==== Committers and Contributors:​ ==== ==== Committers and Contributors:​ ====
  
   * Names and affiliations of the committers   * Names and affiliations of the committers
      * Jie Hu ([[hu.jie@zte.com.cn]])      * Jie Hu ([[hu.jie@zte.com.cn]])
-     ​* ​//more committers are welcome// ​+     ​* ​Qiao Fu ([[fuqiao@chinamobile.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]])
 +     * Zhipeng Huang ([[huangzhipeng@huawei.com]])
      * //more contributors are welcome// ​      * //more contributors are welcome// ​
 ==== Planned deliverables ==== ==== Planned deliverables ====
  
   * Described the project release package as OPNFV or open source upstream projects.   * Described the project release package as OPNFV or open source upstream projects.
-    * User Requirements White Paper +    * User Requirement of OPNFV Escalator 
-    * Released package as OPNFV or open source upstream projects.+    * Gap Analysis on OPNFV Escalator with open source upstream projects.
   * If project deliverables have multiple dependencies across other project categories, described linkage of the deliverables.   * If project deliverables have multiple dependencies across other project categories, described linkage of the deliverables.
     * TBD     * TBD
Line 103: Line 112:
  
   * When is the first release planned?   * When is the first release planned?
-     ​* ​The User Requirement ​White Paper (June 2015)  +     * User Requirement ​of OPNFV Escalator ​(June 2015) 
-     ​* ​Released package ​(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 next release.  +     * It will align with the 2nd or 3rd release ​of OPNFV
requirements_projects/escalator.1426041212.txt.gz · Last modified: 2015/03/11 02:33 by Jie Hu