1. SDN-O LCM for Mercury Release Key Points and Overview

2. Agenda Model Driven LCM Proposal OPEN-O Architecture Alignment1
OPEN-O Architecture Alignment 2
Mercury Release OPEN-O SDN-O LCM Key Points 3
LCM Overview 4
SDN-O TOSCA Types & Templates 5
SDN-O Microservices 6
SDN-O Sequence Diagrams 7

3. Catalogue and Model Driven Orchestration Engine Proposal (Model Driven LCM)
Client
Mercury Release:
Designed generic, for re-use, to support adding new service type via model (CSAR) dynamically run-time, without the need for new SDN-O software releases
Catalog & Model driven, common services model
Use in SDN-O Only
Collect requirements from GS-O and NFV-O
Align states and transitions with GS-O and NFV-O (both target and Mercury Release)
Align any NS API Release 2 changes with GS-O and NFV-O
Mandatory for Overlay and VxLAN
Stretch goal for all other LCM microservices (L2VPN, L3VPN, IPSec, ServiceChain, VPC)
Different Deployment Options, see next slide
To be reviewed by modeling/arch, NFV-O and GS-O
Post Mercury Release:
Could be propagated to Common
Could be enhanced and re-used by GS-O
Could be enhanced and re-used by NFV-O
TOSCA Model Designer
TOSCA
Service model
NBI
<>
Generic Model-Driven NS LCM with configurable state engine
TOSCA Parser / Validator
Catalogue
Workflow
Engine
Resource & Service Inventory
Built-In Generic Workflows (create, provision, delete, terminate, update, ..)
Network Connectivity Service Templates
Tosca Template +
Platform independent and
execution engine independent
Data model and API model
State model and actions
Common Models and APIs
NS Decomposer
(partial re-use)
Dispatcher & Transaction Manager
Custom Workflows (optional)
Model Driven Orchestration
(Model Driven LCM)
Re-use from Release 1
REST calls
Partial re-use from Release 1
APIs

4. OPEN-O Architecture Alignment for SDN-O LCM
Depends On
Mercury Release SDN-O LCM
Common Service HA
Log
Driver Mgr.
Micro-Service Bus
Protocol Stack
Auth.
Common
TOSCA
Workflow
Parser
Catalog
Model
Designer
GS-O
Service Decomposer
Service Lifecycle Mgr.
Service
Formation
Abstract NBI
GUI Portal
SDN-O
NFV-O
GUI Portal
GUI Portal
Abstract NBI
Abstract NBI
SDN
Monitor
SDN Lifecycle Mgr.
NFV Monitor
NS Lifecycle Mgr.
Seed Code Based: Technology Specific Microservices and Hard Coded NSLCM
Model Driven LCM
SDN Res.
Mgr.
Service Inventory
NFV Res. Mgr.
Abstract SBI
Abstract SBI
VNF SDK
SDN-O Drivers
SDN
Driver
NFV
Driver
NFV SDN
Controller Drivers
VNFM Drivers
VIM Drivers
Integration

5. Mercury Release OPEN-O SDN-O LCM (Key Points)
Mercury Release SDN-O addresses the problem of slow introduction of network connectivity service types via new software releases, by providing
catalogue driven orchestration and management engine (SDN-O LCM)
common network connectivity service model (common SDN-O DSL)
re-used of the model and engine for different types of connectivity services and their components via extensions (solution SDN-O DSL, TOSCA templates/CSAR)
The model driven LCM provides generic orchestration that has no pre-defined internal semantics about network APIs, properties or workflows.
Network APIs in Mercury Release are technology specific commercial network microservice APIs (overlayVpn, sfc, l3vpn, l2vpn, site, vpc), future release can bring the following improvements:
All technology specific network microservices can be implemented using LCM (different deployment strategies – one LCM for all, one LCM per technology, combo configurable)
LCM’s Network API will become common network SBI (driver API)
Changes in network APIs, network parameters or workflows for execution of technology specific micro-service API, require NO new software release.
Page 5

6. LCM Overview
LCM is based on the common SDN-O DSL, defined in TOSCA sdno_type_definition.yaml
Based on tosca_simple_yaml_1_0
Defines Common SDN-O TOSCA Model
Common Data Types (BaseServiceInfo, StateMachineType, etc)
Common Node Types (ConnectivityService, Connection, Endpoints, etc)
Common Capability, Relationship and Interface Types
Each Specific Connectivity Service Type is defined in CSAR using
Definitions: Service specific DSL based on common SDN-O DSL, defined in service specific yaml files (e.g. enterprise2Dc_type_definition.yaml, undelayVpn.yaml, etc)
TOSCA templates for Connectivity Services that are created using common and service specific SDN-O DSLs (e.g. enterprise2DC_template.yaml)
Swagger files that define the APIs of the underlaying network microservices (existing network microservice APIs aligned with Huawei commercial product, extension changed for ARIA parsing purpose, e.g overlay.jaml, sfc.jaml, site.jaml, vpc.jaml, etc).
Simple JSON Data Type Mappings to map some common attributes to SBI API specific attributes (e.g. ovelay.tsmap, sfc.tsmap, etc). These may be removed when LCM is used to implement all SDN-O microservices or when network APIs are aligned and using common patterns)
Workflow for execution of atomic service operations is currently defined in the TOSCA service template as sequence of operations via interface dependencies (imperative style):
Workflow semantics of TOSCA yaml1.1 is not yet supported by ARIA Tosca
Further improvement in microservice APIs and common SBIs will allow to derive the workflow from the topology, resource inventory and policies (declarative)
Page 6

7. Network API LCM NBI Model driven LCM State Engine MSB SBI Decomposer
BRS
Service id
Operation
Inputs
TOSCA Catalogue
Common
Common SDN-O types
State Machine
LCM NBI
Decomposer
Generates the service
instance model
Fills ids, ips,…
Generates the state machine
Ent2dc
Vpn
Node
sfc
node
vpc
site
CSAR for Specific Service Type
Tosca reusable types
Tosca templates
SBI’s swagger
DataType mapping
Custom State Machine Extensions and Workflows
State Engine
Generic Workflow
Create, deploy, undeploy, activate, update, deactivate, undeploy, delete
Generates
the API WF
none
created
deployed
activated
Model driven LCM
Create vpn
Create vpc
Create sfc
MSS
Inventory
Dispatcher
Calls network API
Manage transactions
SBI
MSB
SBI
Network API

8. SDN-O TOSCA Types & Templates Overview
SDN-O TOSCA Type Definitions
SDN-O TOSCA Enterprise2DC Type Definitions
SDN-O TOSCA Enterprise2DC Templates
SDN-O TOSCA Enterprise2DC Jason Instance
SDN-O TOSCA Underlay VPN Type Definitions
SDN-O TOSCA Underlay L3VPN Template
Page 8

9. Deployment Options for Model Driven LCM
Candidate deployment approaches:
One SDN-O LCM microservice per service type (one or more templates, one network service definition)
One SDN-O LCM microservice for all service definitions and templates
Both options supported, configurable as a deployment strategy for all services. All services have the same deployment strategy.
Both options supported, configurable as a deployment strategy during the individual service design. Each service type may have different deployment strategy.
Approach 1 (proposal for R2)
Approach 2
Approach 3
Approach 3 =
Approach 1
XOR
(mutual exclusive OR)
Approach 2
Approach 4 (example)
LCM Overlay
LCM L2VPN
LCM L3VPN
Common Hierarchical LCM for full TOSCA Template Hierarchy:
Overlay (Nodes: VxLAN, IPSec, VPC, SFC), L2VPN, L3VPN
LCM Overlay
Common LCM for others
LCM VxLAN
LCM IPSec
LCM VPC
LCM SFC
LCM VxLAN
LCM IPSec
LCM VPC
LCM SFC
Approach 1 keeps it closer to the Release 1 so that we can re-use all testing and user stories and introduce the model driven to the Release iteratively with lower risk (one micro service at a time, mandatory overlay only). Isolation for modeling and testing purposes.
Approach 1 target deployment must be dynamic, driven from the catalogue in order to achieve run time service design.
Approach 2 may be the best long term solution as it provides fully model driven generic design and activation. New microservices could be added for new functionality, e.g. assurance.
Approach 3 provides additional flexibility per solution
Approach 4 gives the most flexibility, we can still test each template in isolation but allow simple deployment, less memory consumption

10. R2 Minimal Viable Product
Service State and Transition Table for Mercury Release (R2)
State:
none
created
deployed
API Operation:
create
Workflow: create
New State: created
Error ‘Service Already Created’
Error ‘Service Already Deployed’
deploy
Workflow: deploy
New State: deployed
Workflow: deployCreated
get
Error ‘Service does not exist’
Workflow: get
No state change
update
Workflow: updateCreated
Workflow: updateDeployed
undeploy
Error ‘Service Not Deployed’
Workflow: undeploy
delete
Workflow: deleteCreated
New State: none
Workflow: deleteDeployed
R2 Stretch Goal
R2 Minimal Viable Product

11. SDN-O High Level Architecture: SDN-O Microservices

12. SDN-O Sequence Diagram: LCM Generic

13. SDN-O Sequence Diagram: LCM Create

14. SDN-O Sequence Diagram: LCM Deploy / Provision