1. ONAP layering/MEF alignment
Date , 2017

2. 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.

3. 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

4. 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.

5. 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.

6. 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 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

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

8. 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

9. 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

10. 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

11. 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.

12. 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

13. 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

14. (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)

15. 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)