Understanding ONAP Layering and MEF Alignment in 2017
Explore the alignment between ONAP layering and MEF in 2017, focusing on functional architecture, deployment models, and terminology. Discusses MEF LSO framework, service orchestration, and key terminology definitions for better understanding of service management across operator networks.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
ONAP layering/MEF alignment Date , 2017
Current FUNCTIONAL Architecture for R2+ Run-time Portal (GUI/CLI) External Data Movement & APIs Dashboard OA&M (VID) Design-time Service Orchestration A&AI ESR Domain Service Descriptors Domain Service Descriptors SDC Resource Orchestration Common Service VNF SDK Domain Resource Descriptors Domain Resource Descriptors Microservice Bus DMaaP Auth. Alarm Correlation (Holmes) Policy Multi- VIM/Mul tiCloud (g/s) vnfm DCAE SDN-C APP-C Other? CLAMP Cloud & WAN OpenStack VMware RackSpace Azure ...... Consensus on layered architecture. This picture does not imply project structure. 2
Introduction As Gil pointed out, and as we ve discussed on past calls, resource orchestration terminology is ambiguous and insufficient - ETSI TERMINOLOGY IN AND OF ITSELF IS NOT SUFFICIENT TO DESCRIBE THE ONAP PROBLEM SPACE. We agreed to discuss different industry layering models to better describe ONAP and help define interfaces & models Furthermore, service provider deployment models may vary due to different business/organizational models - Our goal should be to facilitate different deployment models in as common/unified a manner as possible This presentation considers MEF LSO framework in the context of ONAP as one approach
MEF Terminology/definitions Orchestration: automated service management across multiple operator networks that includes fulfillment, control, performance, assurance, usage, security, analytics, and policy capabilities Service Orchestration Functionality (SOF): The set of service management layer functionality supporting an agile framework to streamline and automate the service lifecycle in a sustainable fashion for coordinated management supporting design, fulfillment, control, testing, problem management, quality management, usage measurements, security management, analytics, and policy-based management capabilities providing coordinated end-to-end management and control of Layer 2 and Layer 3 Connectivity Services. Infrastructure Control and Management (ICM): The set of functionality providing domain specific network and topology view resource management capabilities including configuration, control and supervision of the network infrastructure. ICM is responsible for providing coordinated management across the network resources within a specific management and control domain. For example, a system supporting ICM capabilities provides connection management across a specific subnetwork domain. Such capabilities may be provided within systems such as subnetwork managers, SDN controllers, etc. Element Control and Management (ECM): The set of functionality supporting element management layer capabilities for individual network elements. While a system supporting ECM capabilities provides for the abstraction of individual infrastructure elements, it may reflect the element view for multiple elements, but not provide coordinated management across the set of elements.
Infrastructure Orchestrator This presentation will use the term Infrastructure Orchestrator (IO) to better align with MEF s terminology and to remove ambiguity regarding Resource Orchestrator (RO). - I am not implying a change in functionality vs. previous discussions Infrastructure Orchestration: - The set of functionality providing domain specific network and topology-view orchestration capabilities including configuration, control, testing, problem management, quality management, usage measurements, and security management. IO is responsible for providing coordinated management across the network resources within a specific management and control domain.
MEF LSO Reference Architecture CANTATA (CUS:BUS) Business Applications Business Applications SONATA (BUS:BUS) Customer Application Coordinator LEGATO (BUS:SOF) LEGATO (BUS:SOF) Service Orchestration Functionality Service Orchestration Functionality ALLEGRO (CUS:SOF) INTERLUDE (SOF:SOF) PRESTO (SOF:ICM) PRESTO (SOF:ICM) Infrastructure Control and Management Infrastructure Control and Management ADAGIO (ICM:ECM) ADAGIO (ICM:ECM) Element Control and Management Element Control and Management Network Infrastructure
LSO Reference Architecture w/ ONAP End to End Services Framework Business Applications Business Applications Business Application OSS BSS Portals Legato Service Orchestration SO Customer Domain Partner Domain SP Domain Presto IO Infrastructure Control and Management SDN EMS APPC, VNFM Controllers Adagio Element Control and Management
LSO Reference Architecture can be recursive End to End Services Framework Business Applications Business Applications Business Application OSS BSS Portals Legato Service Orchestration Customer Domain Partner Domain SP Domain Presto Infrastructure Control and Management Presto Infrastructure Control and Management Adagio Element Control and Management
MEF+ETSI NFV+ONF (my view) End to End Services Business Applications Business Applications Business Application OSS BSS Portals Legato Service Orchestration Customer Domain SOF Partner Domain SP Domain Presto NFV-O Infrastructure Control and Management SDN Controllers VIM Adagio MANO Element Control and Management EMS VNFM
Use Case 1: multi-region support Business Application SO Service Orchestration Presto IO IO IO Frankfurt Tokyo Chicago Presto Infrastructure Control and Management SDN APPC, VNFM APPC, VNFM APPC, VNFM SDN SDN Controllers Controllers Controllers Region 3 Region 1 Region 2 Element Control and Management Assuming OOM/Kubernetes. One instance of ONAP with separate instances of some modules in different regions * Region: geographic area where network resources are under single administrative control
Use Case 2: multi-technology support End to End Services Framework Business Applications Business Applications Business Application OSS BSS Portals Legato Service Orchestration SO Customer Domain Partner Domain SP Domain Presto IO (SDN) SDN-C? Infrastructure Control and Management IO (NFV) IO (IOT) SDN APPC, VNFM IOT-C IOT-C Controllers Adagio IOT-C Element Control and Management Illustrating a different IO for each technology domain.
Use Case 3: multi-operator federation support Business Application Sonata Sonata BSS BSS BSS Interlude Interlude SO SO SO IO IO IO SDN APPC, VNFM APPC, VNFM APPC, VNFM SDN SDN Controllers Controllers Controllers Service Provider 2 Service Provider 1 Service Provider 3 Different instances of ONAP for each service provider
Use Case 3a: multi-region federation within one operator Business Application Sonata Sonata BSS BSS BSS Interlude Interlude SO SO SO IO IO IO SDN APPC, VNFM APPC, VNFM APPC, VNFM SDN SDN Controllers Controllers Controllers Operating Region 2 Operating Region 1 Operating Region 3 Separate instances of ONAP in each region; single service provider
Deployment Scenarios SO Interlude SO SO SO SO Presto (federated) Presto IO Domain 1 No IO SO acting as IO (hierarchical) SO acting as IO (hierarchical) IO Domain 2 (independent sw module) Presto Presto Presto Presto Presto APPC, VNFM APPC, VNFM SDN SDN SDN SDN APPC, VNFM APPC, VNFM Controllers Controllers Controllers Controllers Scenario 1: simple deployment Scenario 2: larger deployment Scenario 3: larger deployment with hierarchical SO Scenario 4: federated deployment
Conclusion Different service provider deployment models require architectural flexibility - We also want to look ahead to new technology introduction A model-driven approach with standardized interfaces and consistent layering gives us the flexibility to support different deployment models while reducing variations in the architecture - Lego blocks MEF LSO offers us one framework to consider - Common interfaces: Presto/Interlude We could also consider other interfaces that serve the same function (provided we have well-defined models) - Provide for three-layer model (even if ONAP can be deployed using two)
