Domino: Template Distribution Service Basic Architecture and Brief Background contacts:

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 DOMINO Server (Template Distributor) Template Translation (tosca2heat) TOSCA Service Template HEAT, Kubernetes,etc. ONOS, ODL, etc. Juju, Tacker, etc. Domino Client Domino Client Green: to be implemented as part of Domino Proposal Blue: existing components Template Store Orchestration Templates Domino Client 7 Template Producer

Label Based Pub/Sub System 8 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

Label Based Pub/Sub System 9 Domino Server Domino Client-1 Domino Client-2 Domino Client-3 subscribe(operator:at&t, … compute:VM:flavor:[tiny, medium, large]) subscribe(operator:at&t, … compute:VM, region:US:94040) subscribe(operator:at&t, … network:WAN:BGP)

Label Extraction from TOSCA 10 TOSCA Service Template VNFExternal VLVNFFG VDUCPInternal VL FP Search for “properties:”, “requirements”, “capabilities”, “policies” labels under each node. E.g., VNF:properties:flavor_ID

Domino Server Internal Process 11

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

MORE DETAILED USE CASES 13

Template Based Orchestration: Orchestration Glue for ETSI MANO VNFs and Network Services have complex descriptions – Logical topology, VNFFGs, configuration, scaling behavior Typical workflow: Service Templates  Resource Templates  Resource Creation/Modification/Deletion via API calls Domino is the template glue that maps & translates service templates into resource orchestration templates and distributes them to VNF-Ms & VIMs DOMINO VNF-MNFV-OVIM-1VIM-N OSS/BSS 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 DOMINO Template Consumer (e.g., VIM) Template Producer (e.g., NFVO) High Level API call (e.g., VNF.scale, VNFFG.scale, etc.) template T translated & mapped template T* 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 VM (large) VM (xlarge) An API call should be as simple as vnf.scale 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. or VM (large) VM (large) VM (large) 17

SFC Scaling VNF Group VNF Group VNF Group VNF Group VNF Group VNF Group An API call should be as simple as sfc.scale 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 VNF1VNF2VNF3VNFn Existing Chain 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: 20