Wiki

• Proposed name for the project: escalator
• Proposed name for the repository: escalator
• Project Categories: Requirements

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).

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.

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.

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 a rollback when a upgrade is failed
• the maximum duration of a VNF interruption
• the required mechanisms when a upgrade is carried on
• the required mechanisms to prepare a upgrade
• the potential I/F between VIM and VNF Manager / NFV Orchestrator if needed
• the information flows among the related entities
• etc.

This project will identify the gaps from the user requirements to the approved OPNFV projects and other upstream projects.

This project will provide a requirement document on NFVI and VIM upgrading.

Based on the output of this project, we may propose another project on the reference design and implementation on smooth upgrade of NFVI and VIM.

• 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.
  • 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.
• Specify any interface/API specification proposed,
  • Nf-Vi for control the upgrade procedure
  • Vi-Vnfm for ensure a VNF friendly upgrade
  • Oi-Vi for supporting the policy control from NFV Orchestrator
• Specify testing and integration:
  • TBD
• Debugging and Tracing
  • TBD
• Unit/Integration Test plans
  • TBD
• Client tools developed for status shows etc.
  • TBD
• Identity a list of features and functionality will be developed.
  • Upgrade Validation
  • Upgrade Notification
  • Upgrade Monitor
  • Smooth Upgrade
  • Safe Rollback
• Out of scope:
  • VNF Lifecycle Management, including VNF upgrade and update
  • Abnormal Failure of OPNFV platform
  • High Availability
  • Security
• Describe how the project is extensible in future
  • Codes / Automaton scripts to implement related mechanisms if available in the future.

* Specify testing and integration like interoperability, scalability, high availablity * What QA and test resources will be available?

* API Docs * Functional block description

• Identify similar projects is underway or being proposed in OPNFV or upstream project
  • TBD
• Identify any open source upstream projects and release timeline.
  • Openstack
• Identify any specific development be staged with respect to the upstream project and releases.
  • TBD
• Are there any external fora or standard development organization dependencies. If possible, list and informative and normative reference specifications.
  • None
• If project is an integration and test, identify hardware dependency.
  • N/A

• Names and affiliations of the committers
  • Jie Hu (hu.jie@zte.com.cn)
  • Qiao Fu (fuqiao@chinamobile.com)
  • Ulrich Kleber (Ulrich.Kleber@huawei.com)
• Names and affiliations of any other contributors
  • Zhong Chao (chao.zhong@zte.com.cn)
  • Julien Zhang (zhang.jun3g@zte.com.cn)
  • Yuri Yuan (yuan.yue@zte.com.cn)
  • more contributors are welcome

• Described the project release package as OPNFV or open source upstream projects.
  • User Requirement of OPNFV Escalator
  • 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.
  • TBD

• When is the first release planned?
  • User Requirement of OPNFV Escalator (June 2015)
  • Gap Analysis on OPNFV Escalator with open source upstream projects (October 2015)
• Will this align with the current release cadence
  • It will align with the 2nd release of OPNFV