1. OPEN-O Modeling Directions (DRAFT 0)
OPEN-O Technical Steering Committee

2. OPEN-O High Level Architecture Overview
SDN
Driver
VNFM Drivers
VIM Drivers
ACCESS/WAN SDN Controller Drivers
NFV SDN
Controller Drivers
Orchestrator Service
Model Designer
Portal
GUI Portal …
Test
&
Lab
(for feature)
GS-O
Service Decomposer
Service Lifecycle Mgr.
Service
Parser
Abstract NBI
SDN-O
SDN Res.
Mgr.
Abstract SBI
NFV-O
NFV Res. Mgr.
NFV Monitor
NS Lifecycle Mgr.
VPN
SDN Lifecycle Mgr.
Traffic Optimize
VAS Mgr.
Monitor
O-Common
External System Register
Template Mgr.
Analytics
Policy
Inventory
Common Service HA
Log
Driver Mgr.
Micro-Service Bus
Protocol Stack
Auth.
EMS/NMS Driver
NFV
Workflow Engine
Catalog

3. Current State OPEN-O scope includes management of…
NFV-I
VNFs
Network Services
Customer Facing Services
OPEN-O is implemented using a micro-service based architecture
All functional components are implemented as one or more micro-services
A micro-service bus is used for micro-service registration, location and inter-service communication
There is no shared state
Per-service models and APIs
Services (NS, VNF, NFV-I) are defined and described using a combination of TOSCA and YANG
Each functional component has its own information/data models and APIs
There are no unified northbound and southbound APIs

4. Evolving OPEN-O Architecture…
Principles
Model driven functional component integration
Model driven functional component and micro-service interaction
Model driven interface abstraction
Model Considerations
Attributes & Operations – semantic and syntactic meaning
Encoding – specification grammar
Persistence – packaging for delivery
Interface Considerations
Interactive (H2M) vs Programmatic (M2M)
Imperative vs Declarative
Internal vs External
Northbound Outer (Service) APIs UX
Service
“Thing”
Data Service
Southbound Outer (Resource) APIs
Physical
Cloud
Virtual
Service APIs
API Gateway/Broker
Model
Access
Boundary
NVFI Resources
Micro-service Bus

5. Model Abstraction Layers
CRaaS
NFV Infrastructure
NFV-IaaS
VNF Infrastructure
VNFaaS
Network Services
Customer Facing Services
NSaaS
Physical
Virtual
Cloud
3rd party XaaS services

6. Design-Time Vs Run-Time Models
Service Definition
Service Offering
Service Offering Instance
Design Time Model
Run-Time Model
Design time model is a subset of a run-time model Consistency of attributes and associations Different encodings and persistence

7. Modeling Directions… Design Time Run-Time
End-to-end “service” definition based on TOSCA/YAML templates
End-to-end VNF modeling using TOSCA “requirements” and “capabilities”
Run-Time
Driven by OPEN-O deployment use cases
Core model to support OPEN-O architectural needs and run-time state distribution/decentralization
Model “views” to expose core model using MEF and/or other standard models
Persistence approach likely to include a decentralized “document store” with federated queries

8. Interfaces Directions
“Outer” OPEN-O model and interfaces
Consumption and administration of OPEN-O provided services
Integration with external systems
Model and interface adapters
“Inner” micro-service models and interfaces
Domain specific, functional component centric
For internal OPEN-O use only
Sources of information for the “outer model”

9. Community Synergies Current OPNFV ARIA Juju Future OPNFV ODL OPERA
Functional Test
ARIA
Juju
Future
OPNFV
Models
Onboarding
Telemetry
Benchmarking
ODL

10. SDO Synergies
Current
ETSI/MANO
TOSCA
YANG
Future
Extensions to ETSI/MANO
Extensions to TOSCA
MEF model/interface alignment

11. Click to edit Master title style
Lorem Ipsum Dolor Sit

12. ??? MEF ETSI TMF OPEN-O NB Interfaces Customer Facing Services CS-O
Model
Policies & Rules
Network Services
RS-O
Micro-service Infrastructure
VNF Infrastructure
VNFM
Common Services
NFV Infrastructure
VIM
OPEN-O SB Interfaces