Page tree
Skip to end of metadata
Go to start of metadata

Project Name:

  • Proposed name for the project: Multisite Virtualized Infrastructure
  • Proposed name for the repository: multisite
  • Project Categories: Requirements

Project description:

NFV infrastructure must be distributed across multiple geographical locations. This will require multiple connected OpenStack deployments, of different sizes. The infrastructure will also mix physical and virtual infrastructure.

The platform must be able to support application-level redundancy across different datacenters, network management across multiple sites, and between physical and virtual infrastructure, multi-site image replication, and global and per-site quota management.

This project focus on the enhancement to OpenStack ( Nova / Cinder / Neutron / Glance / Ceilometer / KeyStone ), so that OpenStack as the VIM is able to support multisite NFV cloud.

As shown in the above figure, although Multisite is not a requirement project that only integrates works from other requirement projects, it does have possible inputs from projects like Copper, Promise, VNFFG, Doctor, HA, Paser, and other new project being able to running on multi-site scenario. It should be noted that it is up to the respective project team to decide if they have requirements for such scenario, and what those requirements would be (That's why they are all in dotted lines). For projects that do see multi-site scenario is necessary, Multisite project would be more than glad to work together with those projects, through any form it deems fit, to provide common requirements, and further feedback to the upstream community for implementation.

For those of which features will be developed only inside one site, for example Qtip, VSPERF, some feature of HA, some feature of Doctor, will not produce dependency on multi-site project. However it should also be noted that there are certain scenarios in a single site deployment that actually deals with similar technical difficualties as in a multisite deployment. These scenarios, if deems necessary, would be included in the Multisite project discussion.

General High Level Requirements

The Multisite Project would like to drive the following high level requirements to be defined in the process:

1. The requirement of supporting performance and fault management for a multisite VIM deployment scenario.

2. The requirement of supporting vnf software image management for a multisite VIM deployment scenario.

3. The requirement of virtualized resource management for a multisite VIM deployment scenario.

4. The requirement of supporting identity management for a multisite VIM deployment scenario.

5. The requirement of supporting policy management for a multisite VIM deployment scenario.

6. The requirement of message bus enhancement for a multisite VIM deployment scenario.

7. The requirement of defining/utilizing NFVI Descriptor/Record for a multisite VIM deployment scenario.

8. The requirement of supporting High Availability for a multisite VIM deployment scenario.

9. The requirement of supporting Disaster Recovery for a multisite VIM deployment scenario.

10. ...

More requirements would be added afterwards.

Terminology

Multisite Terminology

Uses Cases

Sample Use Cases dealing with HA, GR:

  1. 1. HA: High Availability cross VIMs ( in one site, but not limited to). Requirements for such use case would relate to how Neutron establish the networks to support HA or how Keystone maintains HA features, for instances.
  1. 2. GR: Geo-site Redundancy, with/without application level data/configuration replication (Cross-site disaster recovery would be one classic use case of this type). Requirements for such use case would relate to for example, how Cinder supports cross-site data replication.
  1. 3. GLB: Geo-site Load Balancing, DNS based, or non-DNS based. GLB can work as the front-end for HA and GR, HA and GR can work without GLB.

In the above exemplary use cases, VNF may run in active-active or active-standby mode, according to the VNF management setup, which is out of the scope of this project. This project only concerns with how VIM should support the VNF in multi-site scenario.

It should be noted that these are non-exhaustive exemplary use cases which aim to serve the purpose of the clarification of the project, in certain aspects that may have confusions .

More detailed use cases are among the targeted deliverables of phase 1 of this project, which won’t be available during the proposal period, and more sophisticated use cases like migration across VIM could be discussed in the later phase.

Currently there are several high level use cases already defined by ETSI NFV documents?

Multisite Use Cases Background

The application level use cases and requirements to deploy VNFs in multiple OpenStack instances in multi-site for NFV cloud need to be investigated and defined.

Gap Analysis

Based on the application level use cases defined in this project, currently technical solution provided by OpenStack should be studied whether these solutions are good enough for multi-site NFV cloud, what's the improvement for OpenStack (including KeyStone, Nova, Cinder, Neutron, Glance, Ceilometer) to meet the demand for multi-site use cases:

Multisite Gap Analysis

The gaps for OpenStack (including KeyStone, Nova, Cinder, Neutron, Glance, Ceilometer ) to support multi-site NFV cloud need to be identified and addressed.

General Info

Use Cases

Requirements

Multisite Related BPs For OpenStack Liberty Release

Search For "Multisite" in OPNFV BP Page

Scope

Describe the problem being solved by project.

    ''Identify the requirements and gaps for the VIM (OpenStack) to support multi-site NFV cloud.''


Specify any interface/API specification proposed

    ''OpenStack API''


Specify testing and integration:

Debugging and Tracing

    ''Use OpenStack infrastructure''


Unit/Integration Test plans

    ''Use OpenStack infrastructure''
    

Client tools developed for status shows etc.

    ''Use OpenStack infrastructure'' 


Identity a list of features and functionality will be developed.

    ''1. NFV cloud multi-site use cases and requirements. 2. Gaps for the current VIM (OpenStack) 3. Blueprint/specification to the VIM (OpenStack) service like KeyStone, Nova, Cinder, Neutron, Glance, Ceilometer''


Identify what is in or out of scope. So during the development phase, it helps reduce discussion.

    ''Gaps and Requirements only to the following OpenStack services are included in the scope of the project: KeyStone / Nova / Cinder / Neutron / Glance / Ceilometer''
    ''Out of scope : Any functionality regarding VNFM and NFVO. For example the management of the VNF, network service catalogue and so forth are out of the scope of this project''


Describe how the project is extensible in future.

    ''In future all other relevant OpenStack service should be discussed. Also it should be extended to support hybrid clouds.''

 

Testability: (optional, Project Categories: Integration & Testing)

  • Specify testing and integration like interoperability, scalability, high availablity
    ''When multisite requirements get implemented, the OPNFV distributed lab could support the testing activities.''

* What QA and test resources will be available?

Documentation: (optional, Project Categories: Documention)

  • API Docs
    ''Same as OpenStack API document, but need to identify the API of OpenStack not supported in multi-site cloud.''

* Functional block description

    ''Refer to OpenStack documentation''

 

Dependencies:

  • Identify similar projects is underway or being proposed in OPNFV or upstream project
    ''OpenStack''

* Identify any open source upstream projects and release timeline.

    ''OpenStack as upstream project, and target Liberty Release which is available by the middle of Oct.2015''

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

    ''OpenStack as upstream project, and target Liberty Release which is available by the middle of Oct.2015''

* Are there any external fora or standard development organization dependencies. If possible, list and informative and normative reference specifications.

    ''ETSI NFV: GS MANO,GS INF, GS IFA005, GS IFA006, GS IFA010, and future Phase 3 work''

* If project is an integration and test, identify hardware dependency.

    ''None''

 

Committers and Contributors:

Names and affiliations of the committers

  • Chaoyi Huang, Huawei ( joehuang@huawei.com)
  • Xiaolong Kong, Orange (xiaolong.kong@orange.com)
  • Gerald Kunzmann (kunzmann@docomolab-euro.com)
  • Ulrich Kleber (Ulrich.Kleber@huawei.com)
  • Colin Tregenza Dancer (ctd@metaswitch.com)

Names and affiliations of any other contributors

  • Morgan Richomme, Orange (morgan.richomme@orange.com)
  • Dimitri Mazmanov, Ericsson (dimitri.mazmanov@ericsson.com)
  • Ashiq Khan (khan@nttdocomo.com)
  • Zhipeng Huang, Huawei (huangzhipeng@huawei.com)
  • Jianfeng Lai, Huawei (laijianfeng@huawei.com)
  • Ray, Smartscale Systems (rnugent@smartscalesystems.com)
  • Mike Godley, Intel (michael.godley@intel.com)
  • Jie Hu, ZTE (hu.jie@zte.com.cn)

Planned deliverable

  • Described the project release package as OPNFV or open source upstream projects.
    1. NFV cloud multi-site use cases
    2. NFV cloud multi-site requirements
    3. Gaps for the current services of VIM (OpenStack), including KeyStone, Nova, Cinder, Neutron, Glance, Ceilometer
    4. Blueprint/specification to the services of VIM (OpenStack), including KeyStone, Nova, Cinder, Neutron, Glance, Ceilometer
  • If project deliverable have multiple dependencies across other project categories, described linkage of the deliverables.
         ''OpenStack''

 

Proposed Release Schedule:

  • When is the first release planned?
    ''The project will target OPNFV Release Two as its earliest first release date.''

* Will this align with the current release cadence

    ''Yes''
  • No labels