Domino Template Distribution Service Overview
Learn about Domino Template Distribution Service, its importance, use cases, and how it simplifies network service deployment through template distribution. Understand the need for template distribution in heterogeneous resource environments and supporting Intent APIs for resource allocation decisions.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Domino: Template Distribution Service Basic Architecture and Brief Background contacts: ulas.kozat@huawei.com, prakash.ramchandran@huawei.com
What are Templates useful for? Formal, unambiguous, and reproducible way of describing Network services and their lifecycle management Resources (compute, storage, network), resource groups, resource dependencies/relations, and their lifecycle management Automation of resource allocation/scaling Service and resource management policies Examples: Tosca specifies VNFs, VDUs, VNFFGs, CPs, VLs, policies, etc. Heat Orchestration Template (HOT) in OpenStack describes resource, resource groups, auto-scaling rules, etc. Kubernetes YAML templates describe services, load balancing groups, shared secrets, scripts to launch, etc. 2
Why do we need Template Distribution Service? (Use Case 1) Carrier networks cover a large geographical region with heterogeneous resource types Edge cloud, access network, backhaul network, core network, central offices, data centers Centralized resource orchestration is not feasible in many cases Resources should be orchestrated in each domain locally for fast, autonomous service deployment, monitoring and lifecycle management (LCM) Template distribution service takes a consistent description of a network service, generates resource orchestration templates for each resource domain, and distributes them (while resolving dependencies) Template producer does not need to know how to translate, map, and orchestrate resources in each domain 3
Why do we need Template Distribution Service? (Use Case 2) Support for Intent resolution Intent APIs are declarative (e.g., Scale number of VoIP calls per second by 2x ) How intents are mapped onto actual resource allocation decisions may not be a simple task (e.g., Scale up VNF-1, scale out VNF-2 under conditions X, Y, Z ) Intent APIs can be templated based on online or offline analysis Template Distribution Service translates and distributes the templates for Intent APIs to each domain supporting those Intent APIs 4
What is Domino It is a template distribution service Starts with a service template that combines service models and policies It creates a registry for orchestrators and controllers that indirectly or directly control the described resources It translates the service template into orchestration templates and distribute to the relevant orchestrators and controllers 5
Why the name Domino? Template generation and distribution has a Domino Effect on the service creation and execution Change service template to change network service 6
Proposed Architecture Template Producer TOSCA Service Template DOMINO Server (Template Distributor) Template Translation (tosca2heat) Template Store Orchestration Templates Domino Client Domino Client Domino Client HEAT, ONOS, ODL, etc. Juju, Tacker, etc. Kubernetes,etc. Green: to be implemented as part of Domino Proposal Blue: existing components 7
Label Based Pub/Sub System Label := Topic:SubTopic:SubSubTopic: Example labels: Template Labels: template:tosca, template:hot:v1.1, template:bash_script Operator Labels: operator:at&t, operator:amazon, operator:verizon, etc. Region Labels: region:DC1, region:Singapore, region:US-west, region:lat;lon, region:US:95050 Availability Zone Labels: availability_zone:DC1:zone_A Technology Labels: sfc:bgp, sfc:nsh, sfc:nsh:LB_RR, virtuallink:E-LAN Resource Labels: compute:baremetal, compute:VM:flavor:xlarge, network:IP, network:OpenFlow 8
Label Based Pub/Sub System Domino Client-1 Domino Server Domino Client-2 Domino Client-3 9
Label Extraction from TOSCA TOSCA Service Template VNF External VL VNFFG FP VDU CP Internal VL Search for properties: , requirements , capabilities , policies labels under each node. E.g., VNF:properties:flavor_ID 10
Release C Targets DOMINO server Provides a pub/sub infrastructure for Template Producers and Consumers Provides parsing, mapping, translation, and distribution services for TOSCA service templates DOMINO agents Implements simple Template Producers and Consumers Two template consumers initially 2 Heat sites 1 Heat and 1 SDN site (ONOS) 12
Template Based Orchestration: Orchestration Glue for ETSI MANO OSS/BSS DOMINO NFV-O VNF-M VIM-1 VIM-N VNFs and Network Services have complex descriptions Logical topology, VNFFGs, configuration, scaling behavior Typical workflow: Service Templates Resource Templates Resource Domino is the template glue that maps & translates service templates into resource orchestration templates and distributes them to VNF-Ms & VIMs Creation/Modification/Deletion via API calls 14
Scaling Use Cases VNF scaling Simple VNF case: single VDU Scale up/down or Scale out/in, when and how? Complex VNF case: multiple VDUs (e.g., vEPC, vIMS) VNF now has a topology graph How do we monitor the VNF graph? How do we handle a bottleneck in this graph? How do we ensure service continuity? Service Scaling Service is composed of a Logical Topology (with VNFs as nodes) and one or more forwarding graphs (i.e., VNFFGs) When and how do we update the logical topology or the forwarding graphs according to SLAs while ensuring service continuity? 15
API Templating Template Producer (e.g., NFVO) template T High Level API call (e.g., VNF.scale, VNFFG.scale, etc.) DOMINO translated & mapped template T* Template Consumer (e.g., VIM) To modify API behavior, simply produce a new template and pass to DOMINO service Especially useful when: 1. Service model or policies evolve 2. VIM evolves with new low level API models and resources 16
VNF Scaling An API call should be as simple as vnf.scale VM (large) VM (xlarge) or VM (large) VM (large) VM (large) Which one is the desired execution if a VIM can support both options? The answer depends on VNF and actual workload as well as infrastructure states. Workflow and policy can provide a detailed picture based on VNF model and previous benchmark results. The cost of providing this as part of API is prohibitive in terms of overhead of generating and processing the workflow/policy at the time of API call. It would also make API highly complex. 17
SFC Scaling An API call should be as simple as sfc.scale VNF Group VNF Group VNF Group VNF Group VNF Group VNF Group Workflow/policies determine which part of the chain scale under what conditions, how session consistencies are enforced (e.g., session stickiness after load balancing), how a VNF group is scaled (horizontal, vertical, etc.) 18
SFC Upgrade VNF1 VNF2 VNF3 VNFn VNF2 What do we do for the existing sessions? Do we create a new chain with the new VNF version or do we modify the existing chain? If we create a new chain, do we terminate the old chain and how/when? 19
Q&A Session Follow up: ulas.kozat@huawei.com 20
