User Tools

Site Tools


requirements_projects:nemo

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:nemo [2015/02/27 06:32]
Tianran Zhou [Committers and Contributors:]
requirements_projects:nemo [2015/07/02 07:43] (current)
Tianran Zhou
Line 1: Line 1:
 +====== This page is outdated. ​ ======
 +====== Please go to the following link for the project proposal ======
 +
 +[[requirements_projects:​vimnbi|Project Name: MOVIE]]
 +
 +
 +
 ==== Project Name: ==== ==== Project Name: ====
  
   * Proposed name for the project: ''​VIM Northbound Model and Interface''​   * Proposed name for the project: ''​VIM Northbound Model and Interface''​
-  * Proposed name for the repository: ''​nemo''​+  * Proposed name for the repository: ''​vim_nbi''​
   * Project Categories: ​ ''​(Requirements) ''​   * Project Categories: ​ ''​(Requirements) ''​
  
 ==== Project description:​ ==== ==== Project description:​ ====
-According to the OPNFV architectureOr-Vi and Vi-Vnfm are the northbound interface ​provided by the Virtualized Infrastructure Manager (VIM)which face to the orchestrator ​and VNF manager separately.+While OpenStack is a competitive candidate for VIMexisting interfaces ​provided by OpenStack include three major parts: computestorage, and network. However, OpenStack as a general cloud platform is not customized for NFV scenario, leaving a lot of detailed work for the NFV orchestrator. ​
  
-While OpenStack ​is a competitive candidate ​for VIM, existing interfaces provided by OpenStack include three major parts: computestorageand network. HoweverOpenStack as a general cloud platform is not customized for NFV scenarioThose APIs are not intuitive to be used as the northbound ​interface ​exposed to the upper layer applications(e.g. orchestrator). For example, while the VNF manager requests ​to create a VNF instance, it will consequently invoke several OpenStack APIs from Nova, Neutron or more. It would be intuitive for the NFV Scenario if only one simple API can express this request+The proposed project ​is to provide ​consistent and intuitive northbound interface ​for VIM to better fitting the orchestratorand make it easy for resource accessconnection generationflow identificationpolicy operation, etcThis higher level interface ​gives the upper layer application ​(e.g. orchestrator) ​another option in addition ​to openstack native interfaces.
  
-The proposed project is to provide ​consistentorganized ​and intuitive northbound interface for VIM to better fitting ​the VNF manager ​and the orchestrator. For the existing ​NBI we are not going to redefine but to refine in a consistent way.+There will be shim layer to encapsulate higher order operations appropriately in the NFV problem domain, and convert them into collections of calls to cloud platforms. This project will use existing projects, like promise, copper, VNFFG, and so on, to implement ​the NBI and find gaps when the NBI cannot be implemented by existing projects.
  
-As we studied many NFV use-cases, most of them follows the same operation pattern: +{{ :​requirements_projects:​vim_nbi.png?nolink&​500 ​|}}
-  - Create network elements; +
-  - Generate links for the connectivity;​ +
-  - Identify flows; +
-  - Apply policies. +
-Or the combination of these operations. +
- +
-Based on this kind of pattern, we got the following initial inputs, which need to be discussed and replenished. +
- +
-With regard to the northbound interface requirements,​ four kinds of operations need to be considered. +
-  * Node operations: are to create, terminate, query, scale, migrate and operate a VNF or a VNFC instance. A VNF instance with several VNFCs can be abstracted as a logical node. +
-  * Link operations: are used for the connectivity among VNF/VNFC instances. +
-  * Flow operations: identity the flow to be operated with flow characters matching. +
-  * Policy operations: control the behavior of specific flow following the same pattern "with <​condition>,​ to execute <​action>"​. +
-The NBI should meet those requirements. +
- +
-Model Driven Architecture (MDA) approach defines system functionality using platform-independent models. Interfaces can be generated automatically with well defined models. According to the previous interface requirements,​ the following model is necessary to be provided: +
-{{ :​requirements_projects:​model.png?600 |}} +
- +
- +
- +
- +
- +
- +
- +
- +
- +
- +
- +
- +
- +
- +
- +
- +
- +
- +
- +
- +
-Based on the above models, all the operations to the models forms the NBI. One popular NBI fashion is the RESTful interface with implicit CRUD operations. Another notable NBI fashion is in the form of Domain Specific Language (DSL), which facilitate the intuitive expression on user intent and easily to be embedded into the system.+
  
 +To achieve the NBI consistency,​ we can use the Model Driven Architecture (MDA) approach and define system functionality using platform-independent models. Interfaces can be generated automatically with well defined models.
 ==== Scope: ==== ==== Scope: ====
  
 **Describe the problem being solved by project** **Describe the problem being solved by project**
  
-This project is to provide a consistent, organized ​and intuitive northbound interface for VIM to better fitting ​the VNF manager and the orchestrator. With a set of information models and interfaces, we can address most use-cases in a systematical way. The proposed project is intended to (tentatively scheduled):+This project is to provide a consistent and intuitive northbound interface for VIM to better fitting the orchestrator. With a set of information models and interfaces, we can address most use-cases in a systematical way. The proposed project is intended to (tentatively scheduled):
   * document typical NFV use-cases for high-level functional abstraction,​ and find gaps between OpenStack API and high level applicaitons;​   * document typical NFV use-cases for high-level functional abstraction,​ and find gaps between OpenStack API and high level applicaitons;​
-  * abstract VIM NB models and interfaces, refine existing information models and develop new models;+  * abstract ​the service oriented ​VIM NB models and interfaces, refine existing information models and develop new models;
   * work together with other entities to achieve collaboration and synergy;   * work together with other entities to achieve collaboration and synergy;
-  ​The following figure shows the mapping to ETSI NFV architecture. As the first step, Or-Vnfm interface is beyond the scope of existing OPNFV. So the logical node operation will map to this architecture with secondary priority. +  * provide open source implementation for a shim layer. ​
-{{ :​requirements_projects:​nemo-nfv_arch-mapping.png?​nolink&​600 |}} +
-  ​* provide open source implementation for a shim layer. The northbound API encapsulates higher order operations appropriate in the NFV problem domain, and converts them into collections of calls to cloud platforms.+
   * and coordinate integrated testing and release testing results.   * and coordinate integrated testing and release testing results.
 +
  
 **Specify any interface/​API specification proposed** **Specify any interface/​API specification proposed**
Line 73: Line 42:
  
   * The "​Promise"​ project in OPNFV   * The "​Promise"​ project in OPNFV
 +  * The "​Copper"​ project in OPNFV
 +  * The "​VNFFG"​ project in OPNFV
 +  * The "​Doctor"​ project in OPNFV
   * The "​Nova"​ project in OpenStack   * The "​Nova"​ project in OpenStack
   * The "​Neutron"​ project in OpenStack   * The "​Neutron"​ project in OpenStack
-  * The "​Congress"​ project ​in OpenStack +  * the use cases and messages specified ​in the individual projects 
 +  * new shim layer will consider the interface specifications currently being made by ETSI NFV IFA
 ==== Committers and Contributors:​ ==== ==== Committers and Contributors:​ ====
- +**Names and affiliations ​of the committers:**
-**Name of and affiliation ​of the maintainer:** +
     Tianran Zhou (zhoutianran@huawei.com)     Tianran Zhou (zhoutianran@huawei.com)
- 
- 
-**Names and affiliations of the committers:​** 
- 
-    Yinben Xia (xiayinben@huawei.com) 
-    Wei Cao (wayne.caowei@huawei.com) 
     Lei Zhu (lei.zhu@huawei.com)     Lei Zhu (lei.zhu@huawei.com)
     Zhipeng Huang (huangzhipeng@huawei.com)     Zhipeng Huang (huangzhipeng@huawei.com)
     Linghui Zeng (linghui.zeng@huawei.com)     Linghui Zeng (linghui.zeng@huawei.com)
-    Guofeng Shao (shaoguofeng@huawei.com) 
     Qiao Fu (fuqiao@chinamobile.com)     Qiao Fu (fuqiao@chinamobile.com)
     Susan Hares (shares@ndzh.com)     Susan Hares (shares@ndzh.com)
     Zhiying Wang (wang.zhiying1@zte.com.cn)     Zhiying Wang (wang.zhiying1@zte.com.cn)
     Gerald Kunzmann (kunzmann@docomolab-euro.com) ​     Gerald Kunzmann (kunzmann@docomolab-euro.com) ​
 +    Peter Lee (plee@clearpathnet.com)
 +    David Lenrow (david.lenrow@hp.com)
  
 **Any other contributors:​** **Any other contributors:​**
     Julien Zhang (zhang.jun3g@zte.com.cn)     Julien Zhang (zhang.jun3g@zte.com.cn)
     Rajeev Seth (rseth@sonusnet.com)     Rajeev Seth (rseth@sonusnet.com)
- +    Guofeng Shao (shaoguofeng@huawei.com) 
 +    Yinben Xia (xiayinben@huawei.com) 
 +    Wei Cao (wayne.caowei@huawei.com)
 ==== 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.
 +  - Document on typical NFV use-cases for high-level functional abstraction
 +  - Gap Analysis for OpenStack API and high level applicaitons
 +  - Blueprint sent to OpenStack, e.g. "​Congress"​ and more.
 +
   * 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.
  
requirements_projects/nemo.1425018778.txt.gz · Last modified: 2015/02/27 06:32 by Tianran Zhou