This is an old revision of the document!
Project Name:
Project description:
With NFV evolution, carriers need to manage not only transport resources, but also compute and storage resources spread over a large geographical footprint. To support variety of resource types and geographical spread, multiple resource orchestrators and controllers need to coexist. Yet, there is also a need to define end-to-end (e2e) services that need to be orchestrated over these heterogeneous set of resources and orchestrators/controllers consistently with a top-down approach. At the top of the hierarchy, service models and policies are combined together to define an overall service scenario in a single service template. Once a service template is generated, it must be processed, partitioned, translated, and distributed to various domains where local orchestrators and controllers manage their local resources properly and enforce the local policies. Thus, service template creates a domino effect on multiple control domains in terms of resource scheduling, lifecycle management, service scaling, etc.
Figure 1: High Level Architecture
Figure 1 depicts the main building blocks in the high level architecture. The first step is the generation of service policies and service models. These policies and models for a particular service can be generated by multiple (service and model) producers. Although we will define some specific policies and models for testing purposes, how to express policies and models is not the focus of the project. Instead, we will reuse existing tools to express policies and describe models (e.g., Copper, Model, Congress, yang/yaml models, NEMO, protocol buffers, etc.).
The first main component and deliverable of the Domino project is the policy2tosca module, which parses the policy rules and service models to generate a single, coherent service template. Policy Producer, Model Producer, and policy2tosca module together constitute Template Producer.
The second main component of the project is the Domino Template Distributor. Domino module serves Template Producers and Template Consumers. Its main services constitute mapping and translation (i.e., determine which portion of the service template is targeting which consumer and perform template conversion to the format understood by each consumer), serialization (i.e., to determine the workflow dependencies between and within Consumer domains), and distribution (i.e., transfer the converted templates to the corresponding consumers). To utilize Domino module, Template Producers and Template Consumers register with the Domino services. Domino module itself will utilize template translation services provided by other OPNFV and upstream projects (e.g., Parser Project).
Template Consumers should be capable of supporting one or more resource orchestration templates. In the case of OpenStack Heat Orchestrator and Kubernetes, such support natively exists. In other cases where template support is not present, a template based orchestration agent must be deployed. For instance, in the case of SDN controllers, this may be done by adding a controller application that registers with Domino service from which it receives an orchestration template and utilizes SDN
API or services to perform the local orchestration tasks. Note that in reference to the ETSI NFV architecture, the template producers and receivers can be part of EMS, NFVO, VNFM, or VIM depending on the workflow and hierarchy of controllers.
OSS/BSS functions are the main source of service policies and models at the top of the service provisioning hierarchy [see IFA 009 V0.5.0 (2015-12)].
Figure 2: An example flow diagram for template distribution
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.
Scope:
Develop new functionality for template based multi-site service orchestration and intent resolution for abstract, intent-based NBI.
New Interface: Domino Template Distributor defines new interfaces for template consumers and producers to join the distribution and template translation services.
New APIs will be defined for Parser, Template Producer, Template Consumer
Specify testing and integration:
Testing will be done by simple Template Producer and Template Consumer agents. Template Producer will define simple service with simple VNF (packed in a single VM, complex service with complex VNF (micro services distributed over multiple interconnected VMs), and complex service with multiple VNFs connected through a VNFFG. We will change the service template via altering service model or policy rules, log the resource allocation decisions, verify that the final and transient states are in line with the expected behavior. We will also test
API level calls to scale VNF, service, and VNFFG and test if the resource allocation/reallocation happens according to the service model.
Debugging and Tracing:
Unit/Integration Test plans: TBD
New functionalities:
policy2tosca module: merges service policies and service models into one coherent TOSCA yaml template
Domino Template Distributor: creates a registry of service template producers and service template consumers; creates workflows out of the service template; performs required template partitioning, translation, & distribution tasks
Domino Agents: register as template producers and consumers
In scope:
Service template generation
Policy specifications for various service use cases
Service model specifications for various service use cases
Service template parsing, partitioning into one or more orchestration templates, template translation to consumer accepted formats, template distribution
Template definitions for consumers, template agents for carrying out resource scheduling and orchestration
Out of scope:
Extensions:
Testability:
Specify testing and integration like interoperability, scalability, high availability
What QA and test resources will be available?
Documentation:
Dependencies:
Identify similar projects is underway or being proposed in OPNFV or upstream project
Identify any open source upstream projects and release timeline.
Identify any specific development be staged with respect to the upstream project and releases.
Are there any external fora or standard development organization dependencies. If possible, list and informative and normative reference specifications.
If project is an integration and test, identify hardware dependency.
Committers and Contributors:
Planned deliverables:
Described the project release package as OPNFV or open source upstream projects.
If project deliverables have multiple dependencies across other project categories, described linkage of the deliverables.
Proposed Release Schedule:
Use the above information to create a key project facts section on your project page
Key Project Facts