Transcript opnfv_technical_discussion_-_domino_proposalx

Domino:
Template Distribution Service
Basic Architecture and Brief Background
contacts:
[email protected],
[email protected]
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
Store
Template
Translation
(tosca2heat)
Orchestration Templates
Domino
Client
HEAT,
Kubernetes,etc.
Domino
Client
ONOS, ODL,
etc.
Green: to be implemented as part of Domino Proposal
Blue: existing components
Domino
Client
Juju, Tacker,
etc.
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
VDU CP Internal VL
FP
Search for “properties:”, “requirements”, “capabilities”, “policies”
labels under each node. E.g., VNF:properties:flavor_ID
10
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
OSS/BSS
NFV-O
DOMINO
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
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
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)
High Level API call
(e.g., VNF.scale,
VNFFG.scale, etc.)
Template
Consumer
(e.g., VIM)
template T
DOMINO
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
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: [email protected]
20