ONAP layering/MEF alignment Date , 2017

Current FUNCTIONAL Architecture for R2+ Portal (GUI/CLI) Run-time Dashboard OA&M (VID) External Data Movement & APIs Design-time A&AI Service Orchestration Domain Service Descriptors Domain Service Descriptors ESR SDC Common Service Resource Orchestration Domain Resource Descriptors Domain Resource Descriptors VNF SDK DMaaP Auth. Microservice Bus … Policy DCAE Alarm Correlation (Holmes) … Multi-VIM/MultiCloud SDN-C APP-C (g/s) vnfm Other? CLAMP Cloud & WAN OpenStack VMware RackSpace Azure ...... Consensus on layered architecture. This picture does not imply project structure.

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 Customer Domain SP Domain Partner Domain 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) Definition of LSO Ecosystem Components (From Section 9.1 of MEF 55)  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. Business Applications (BUS): The Service Provider functionality supporting Business Management Layer functionality (e.g., product catalog, ordering, billing, relationship management, etc.).  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. Section 9.1.1 provides some ICM implementation examples.  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.  Customer Application Coordinator (CUS): A functional management entity in the Customer domain that is responsible for coordinating the management of the various service needs (e.g., compute, storage, network, etc.) of specific applications. The AC may be responsible for the harmonization of cloud services on behalf of multiple applications. The AC supports Customer interactions with the Service Provider to request, modify, manage, control, and terminate Products or Services. Definition of interface reference points (From Section 9.2 of MEF 55) CANTATA (CUS:BUS): The Management Interface Reference Point that provides a Customer Application Coordinator (including enterprise Customers) with capabilities to support the operations interactions (e.g., ordering, billing, trouble management, etc.) with the Service Provider’s Business Applications for a portion of the Service Provider service capabilities related to the Customer’s Products and Services (e.g., Customer Service Management interface). Since cross domain interactions are supported, additional security considerations need to be addressed on this Management Interface Reference Point.  ALLEGRO (CUS:SOF): The Management Interface Reference Point that allows Customer Application Coordinator supervision and control of dynamic service behavior (see Section 8.2.3) of the LSO service capabilities under its purview through interactions with the Service Orchestration Functionality. When a Customer exercises dynamic service behavior via Allegro, the Service Orchestration Functionality must validate each request using the Service specific policies that govern such dynamic behavior. Such dynamic behavior and associated constraints are defined based on the Product Specification implemented by the Service. For example, a Service specific dynamic service policy may describe the range of bandwidth in which the Customer is permitted to throttle. Allegro may also be used to share service level fault information with the Customer. Since cross domain interactions are supported, additional security considerations need to be addressed on this Management Interface Reference Point.  LEGATO (BUS:SOF): The Management Interface Reference Point between the Business Applications and the Service Orchestration Functionality needed to allow management and operations interactions supporting LSO connectivity services. For example, the Business Applications may, based on a Customer order, use Legato to request the instantiation of a Connectivity Service. Legato may also allow the SOF to describe Services and capabilities it is able to instantiate. Also, the Service Orchestration Function may use Legato to ask the Business Applications to place an order to a Partner provider for the access service needed as a Service Component of an end-to-end Connectivity Service.  SONATA (BUS:BUS): The Management Interface Reference Point supporting the management and operations interactions (e.g., ordering, billing, trouble management, etc.) between two network providers (e.g., Service Provider Domain and Partner Domain). For example, the Service Provider Business Applications may use Sonata to place an order to a Partner provider for an access service that is needed as a part of an end-to-end Connectivity Service. Since cross domain interactions are supported, additional security considerations need to be addressed on this Management Interface Reference Point.  INTERLUDE (SOF:SOF): The Management Interface Reference Point that provides for the coordination of a portion of LSO services within the partner domain that are managed by a Service Provider’s Service Orchestration Functionality within the bounds and policies defined for the service. Through Interlude, the Service Orchestration Functionality may request initiation of technical operations or dynamic control behavior associated with a Service with a partner network domain (see Section 8.2.3). Such requests must be within the constraints set forth in the policies associated with established Services and performed without impacting business applications. For example, to satisfy a Customer request, the Service Orchestration Functionality may request changes to a CE-VLAN ID mapping at a UNI that resides in a partner domain. Interlude may also be used to share service level fault information with the partner domain. Since cross domain interactions are supported, additional security considerations need to be addressed on this Management Interface Reference Point.  PRESTO (SOF:ICM): The resource Management Interface Reference Point needed to manage the network infrastructure, including network and topology view related management functions. For example, the Service Orchestration Function will use Presto to request ICM to create connectivity or functionality associated with specific Service Components of an end-to-end Connectivity Service within the domain managed by each ICM. Presto may also allow the ICM to describe Resources and capabilities it is able to instantiate.  ADAGIO (ICM:ECM): The element Management Interface Reference Point needed to manage the network resources, including element view related management functions. For example, ICM will use Adagio to implement cross-connections or network functions on specific elements via the ECM functionality responsible for managing the element. Element Control and Management Element Control and Management Network Infrastructure

LSO Reference Architecture w/ ONAP Framework End to End Services Business Application Business Applications Business Applications Customer Domain SP Domain Partner Domain OSS BSS Portals Legato Service Orchestration SO Presto IO Infrastructure Control and Management SDN Controllers EMS APPC, VNFM Adagio Element Control and Management

LSO Reference Architecture can be recursive Framework End to End Services Business Application Business Applications Business Applications Customer Domain SP Domain Partner Domain OSS BSS Portals Legato Service Orchestration 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 Application Business Applications Business Applications Customer Domain SP Domain Partner Domain OSS BSS Portals Legato Service Orchestration SOF Presto MANO NFV-O Infrastructure Control and Management SDN Controllers VIM Adagio Element Control and Management EMS VNFM

Use Case 1: multi-region support Business Application Service Orchestration SO Presto Infrastructure Control and Management IO Chicago IO Frankfurt IO Tokyo Presto SDN Controllers APPC, VNFM SDN Controllers APPC, VNFM SDN Controllers APPC, VNFM Region 1 Region 2 Region 3 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 Framework End to End Services Business Application Business Applications Business Applications Customer Domain SP Domain Partner Domain OSS BSS Portals Legato Service Orchestration SO Presto Infrastructure Control and Management IO (SDN) SDN-C? IO (NFV) IO (IOT) SDN Controllers APPC, VNFM IOT-C IOT-C 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 Controllers APPC, VNFM SDN Controllers APPC, VNFM SDN Controllers APPC, VNFM Service Provider 1 Service Provider 2 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 Controllers APPC, VNFM SDN Controllers APPC, VNFM SDN Controllers APPC, VNFM Operating Region 1 Operating Region 2 Operating Region 3 Separate instances of ONAP in each region; single service provider

(independent sw module) Deployment Scenarios SDN Controllers APPC, VNFM SO Scenario 1: simple deployment No IO Presto SDN Controllers APPC, VNFM SO Scenario 2: larger deployment Presto IO Domain 2 IO Domain 1 (independent sw module) SDN Controllers APPC, VNFM SO SO acting as IO (hierarchical) Scenario 3: larger deployment with hierarchical SO Presto SDN Controllers APPC, VNFM SO (federated) Scenario 4: federated deployment Presto Interlude SO acting as IO (hierarchical)

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)