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

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

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

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

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

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

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

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”

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

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

Click to edit Master title style Lorem Ipsum Dolor Sit

??? 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