User Tools

Site Tools


project_proposals:domino

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
project_proposals:domino [2016/03/09 09:27]
Ulas Kozat [Dependencies:]
project_proposals:domino [2016/03/22 14:26] (current)
Prakash Ramchandran [Committers :]
Line 1: Line 1:
 ==== Project Name: ==== ==== Project Name: ====
  
-  * Proposed name for the project: ​Domino ​Template Distribution Service+  * Proposed name for the project: Template Distribution Service ​(Domino)
   * Proposed name for the repository: Domino   * Proposed name for the repository: Domino
 ==== Project description:​ ==== ==== Project description:​ ====
Line 20: Line 20:
  
   * An example of successful template generation and distribution with respect to the MANO components defined in ETSI reference architecture is shown in Figure 2. OSS/BSS in this example generates service policies and models. Note that OSS/BSS can also directly generate a TOSCA service template. Domino creates a service template that combines policies and models in one service descriptor file. OSS/BSS can inject new policies, update existing policies, or update service models at a later time. Domino keeps track of these changes and reflect them into the service template, optionally versioning the previous service templates for the particular sender. Next, Domino passes the service template to NFV Orchestrator (NFVO). Domino also generates VNF orchestration templates and VIM orchestration templates to pass them to the respective VNF managers (VNFMs) and Virtual Infrastructure Managers (VIMs). If all the templates can be successfully generated, distributed,​ and accepted by the corresponding template receivers (i.e., NFVO, VNFMs, VIMs), then a success response is sent back to the policy/​model generator. Note that the actual data flow can be different with first templates offered to each template receiver and upon receiving positive reply from each receiver, a subsequent commit or abandon message can be sent before sending a final response back to the service policy & model producers.   * An example of successful template generation and distribution with respect to the MANO components defined in ETSI reference architecture is shown in Figure 2. OSS/BSS in this example generates service policies and models. Note that OSS/BSS can also directly generate a TOSCA service template. Domino creates a service template that combines policies and models in one service descriptor file. OSS/BSS can inject new policies, update existing policies, or update service models at a later time. Domino keeps track of these changes and reflect them into the service template, optionally versioning the previous service templates for the particular sender. Next, Domino passes the service template to NFV Orchestrator (NFVO). Domino also generates VNF orchestration templates and VIM orchestration templates to pass them to the respective VNF managers (VNFMs) and Virtual Infrastructure Managers (VIMs). If all the templates can be successfully generated, distributed,​ and accepted by the corresponding template receivers (i.e., NFVO, VNFMs, VIMs), then a success response is sent back to the policy/​model generator. Note that the actual data flow can be different with first templates offered to each template receiver and upon receiving positive reply from each receiver, a subsequent commit or abandon message can be sent before sending a final response back to the service policy & model producers.
 +
 +
 +__Use Case 1: Using templates for policy based delegation of resource orchestration__
 +
 +End to end service provisioning typically traverses multiple control domains, where different orchestrators/​controllers manage the “local” resources in their respective domains. Locality here is in general refers to a relative proximity rather than absolute proximity. These orchestrators/​controllers have several advantages, but the most prominent ones are (1) being closer to the resources whose states can be observed with higher fidelity and their actions can be controlled at finer granularity and (2) having domain specific knowledge to deliver the desired service behavior by configuring and programming the resources accordingly. In such a scenario, NFVO that performs service orchestration over multiple control domains can first generate a service template. Then, NFVO can use Domino Service for automatically generating the local orchestration templates and sending them to each local controller/​orchestrator. These local templates can specify what actions should be taken autonomously by local controllers/​orchestrators by prescribing constraints,​ conditions, workflow, pseudo-algorithms,​ expected service behavior, etc. For instance, NFVO can request an auto-scaling service from a target VIM, but also define various resource units (e.g., CPU size, memory size, VM flavor, etc.), workload conditions, and prescribe which resource unit to use to increase/​reduce service capacity under what workload conditions.
 +    ​
 + __Use Case 2: Intent based API with domain specific rendering via templates__
 +
 +OPNFV architecture relies heavily on northbound APIs (NBIs) for resource management and orchestration. Keeping NBI simple and generic increases the usability and potentially prevents issues with backward compatibility. A simple API call to a particular VIM such as SDN controller or OpenStack controller can be interpreted in various ways if multiple options are available. ​
 +
 +{{:​project_proposals:​vnf_scaling.png?​300|}}
 +
 +Figure 3: VNF Scaling Options
 +
 +In Figure 3, an example for VNF scaling is provided. VNFM can simply make a call such as VNF.scale(scaling.factor),​ where the input parameter //​scaling.factor // determines the factor of capacity increase. If for instance //​scaling.factor//​ is specified as two, then VIM is supposed to double the capacity after receiving the API call. The two options shown in the figure are both meaningful choices in the absence of additional clues about the service. In the first option, VIM changes the configuration of the VM by doubling its CPU, memory, and disk resources (i.e., it scales up the VM instance). This may be done by first pausing the VM, taking a snapshot, and then rebooting the snapshot image with a larger hardware configuration. This clearly interrupts the existing workloads and sessions on the scaled VNF. If the VIM had the capability of doubling the resources without any service interruption (e.g., it can add virtual hardware resources without requiring any image snapshot and reboot), scaling up a given VNF would have a different consequence on the actual services that utilize this particular VNF. Thus, even though the VNF is simply moved to a larger instance size, the service implications are quite different based on VIM capabilities. In the second option, VNF capacity is doubled by simply launching another VM with the same size (i.e., VNF is scaled out). For stateless network functions, this is relatively a straight forward and easy way of doubling the service capacity as long as the VMs do not have a shared bottleneck. If VNF has stateful implementation,​ state synchronization between the VMs to handle the existing sessions might be a major issue. The main point of this discussion is that without knowing the context of service and behavior/​performance modeling of these VNFs going from one configuration to the other, an arbitrary decision by VIM can lead to poor performance. This undesired outcome could have been completely avoided if enough conditions and rules (i.e., prescriptions) were passed onto the VIM from VNFM.       
 +
 +Even for single VNF scaling, as the example shows, templating NBI calls is useful. In reality, service scenarios can be significantly more complex. For instance, VNF definition can be quite complex and can consist of many functions (e.g., vIMS, vEPC). Another popular example is services that are composed of VNF graphs or service chains. Managing the lifecycle and performance of such VNFs or services often require a series of well-orchestrated low level API calls and state maintenance. Thus, capturing all this orchestration only with a high level intent API in many use cases is not an option. Instead the consumer of an API should be able to describe the requested workflow in a resource orchestration template and provide this template to the producer of the API before actually utilizing the API.
 +
 +A byproduct of supplementing an API definition with a service template is that the service template producer can change the run-time behavior of a given API without requiring any changes in NBI definitions. NBI consumer simply changes the service template associated with the API call. This is quite useful for instance when the resource models, VNF models, service models, or service policies change over time. 
 +
  
 ==== Scope: ==== ==== Scope: ====
Line 55: Line 75:
 ==== Documentation:​ ==== ==== Documentation:​ ====
  
 +  * Presentations:​
 +    * {{:​project_proposals:​opnfv_technical_discussion_-_domino_proposal.pptx|}}
   * API Docs (TBD)   * API Docs (TBD)
   * Functional block description (TBD)   * Functional block description (TBD)
Line 62: Line 84:
   * Project has dependencies on Parser, OpenStack Heat, ONOSFW. Project has also dependency on SFC solutions (e.g., OpenStack neutron extensions, ODL SFC, ONOS SFC, etc.) at the API level.   * Project has dependencies on Parser, OpenStack Heat, ONOSFW. Project has also dependency on SFC solutions (e.g., OpenStack neutron extensions, ODL SFC, ONOS SFC, etc.) at the API level.
   * Although it does not have any particular dependency on OpenStack Tacker, the project has overlaps in the context of multi-site resource orchestration and parsing/​translating/​mapping TOSCA templates. Project has also potential overlaps with multi-site project.   * Although it does not have any particular dependency on OpenStack Tacker, the project has overlaps in the context of multi-site resource orchestration and parsing/​translating/​mapping TOSCA templates. Project has also potential overlaps with multi-site project.
-  * Tacker and Open-O are the main upstreams ​+  * Open-O ​and Tacker ​are the main upstreams
  
-==== Committers and Contributors====+(See [[:project_proposals/​domino/​dependencies|Dependency Analysis]] for more detailed analysis)
  
-  * Names and affiliations of the committers 
-  * Names and affiliations of any other contributors 
  
 +==== Committers : ====
 +
 +  * Ulas Kozat (ulas.kozat@huawei.com)
 +  * Prakash Ramchandran (prakash.ramchandran@huawei.com)
 +  * someone@hp.com (Vinayak Ram of Parser project to assign HP committer)
 +
 +==== Contributors : ====
 +
 +  * Artur Tyloch (artur.tyloc@canonical.com)
 ==== Planned deliverables:​ ==== ==== Planned deliverables:​ ====
  
-  * Described the project release package ​as OPNFV or open source upstream ​projects. +  * The project release package ​will include: 
-  If project ​deliverables have multiple dependencies across other project categories, described linkage ​of the deliverables.+    * OPNFV test suite: service models, policy rules 
 +    * OPNFV functions: ​ new Parser modules (policy2tosca),​ Domino template distribution 
 +    * Upstream ONOSFW, ODL: Template agent 
 +    * Upstream Heat: HOT templates and new requirements documents 
 +    * OPNFV requirements:​ lifecycle management artifacts for VNF and service scaling 
 +  * Dependencies 
 +    * Parser project: policy2tosca module is to be implemented in Parser. Also tosca2heat and yang2tosca modules implemented in Parser ​projects ​will be utilized.  
 +    OpenStack Heat: project ​will use Heat as one of the template consumers 
 +    * SDN Controllers:​ project will add SDN (e.g., ONOS and ODL) applications to act as template consumers
  
-==== Proposed Release Schedule: ==== 
  
-  * When is the first release planned? +==== Proposed Release Schedule: ====
-  * Will this align with the current release cadence+
  
 +Release C plans:
 +  * Specification for example service policy for VNF auto-scaling and service model 
 +  * Specification for example service policy for VNFFG auto-scaling and service model
 +  * Implement template distribution to a single OpenStack Heat instance
 +  * Implement template distribution to two OpenStack Heat instances
 +  * Implement template distribution to a Heat instance and an ONOS instance
 +  * Implement use case 1 (orchestration templating) and use case 2 (API templating)
  
-Use the above information to create a key project facts section on your project page 
 ===== Key Project Facts ===== ===== Key Project Facts =====
  
-** Project Name: ** Project Name (repo name) \\ +** Project Name: ** Template Distribution Service ​(Domino) \\ 
-** Repo name: ** \\ +** Repo name: ** Domino ​\\ 
-** Lifecycle State: ** \\ +** Lifecycle State: ** Proposal ​\\ 
-** Primary Contact: ** \\ +** Primary Contact: ** Ulas Kozat (ulas.kozat@huawei.com) ​\\ 
-** Project Lead: ** \\ +** Project Lead: ** Ulas Kozat (ulas.kozat@huawei.com) ​\\ 
-** Jira Project Name: ** Same as Project name \\ +** Jira Project Name: ** Template Distribution Service  ​\\ 
-** Jira Project Prefix: ** [10 Characters max [A-Z] ] \\ +** Jira Project Prefix: ** [Domino] \\ 
-** mailing list tag ** [Should match Jira Project Prefix] \\+** mailing list tag ** [Domino] \\
 ** Committers: ** \\ ** Committers: ** \\
-foo@bar.com \\ +Ulas Kozat (ulas.kozat@huawei.com\\ 
-baz@qux.com \\+Prakash Ramchandran (prakash.ramchandran@huawei.com\\
 ** Link to TSC approval: Example http://​meetbot.opnfv.org/​meetings/​opnfv-meeting/​2015/​opnfv-meeting.2015-03-03-15.01.html ** \\  ** Link to TSC approval: Example http://​meetbot.opnfv.org/​meetings/​opnfv-meeting/​2015/​opnfv-meeting.2015-03-03-15.01.html ** \\ 
 ** Link to approval of additional submitters: ** Example http://​meetbot.opnfv.org/​meetings/​opnfv-meeting/​2015/​opnfv-meeting.2015-03-03-15.01.html \\ ** Link to approval of additional submitters: ** Example http://​meetbot.opnfv.org/​meetings/​opnfv-meeting/​2015/​opnfv-meeting.2015-03-03-15.01.html \\
  
  
project_proposals/domino.1457515620.txt.gz · Last modified: 2016/03/09 09:27 by Ulas Kozat