ONAP Layering and MEF Alignment in 2017
ONAP layering/MEF alignment
Date , 2017
SDC
C
u
r
r
e
n
t
F
U
N
C
T
I
O
N
A
L
A
r
c
h
i
t
e
c
t
u
r
e
f
o
r
R
2
+
Design-time
VNF SDK
Dashboard
OA&M
(VID)
A&AI
DCAE
Resource
Orchestration
SDN-C
APP-C
Service
Orchestration
External Data Movement & APIs
Run-time
Cloud & WAN
OpenStack
Azure
VMware
RackSpace
......
Policy
Alarm
Correlation
(Holmes)
Multi-
VIM/Mul
tiCloud
(g/s)
vnfm
Other?
Common Service
Microservice
Bus
DMaaP
Auth.
ESR
Consensus on layered architecture. This picture does not imply project structure.
…
Domain Service
Descriptors
Domain Service
Descriptors
Domain Resource
Descriptors
Domain Resource
Descriptors
…
CLAMP
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
•
O
r
c
h
e
s
t
r
a
t
i
o
n
:
a
u
t
o
m
a
t
e
d
s
e
r
v
i
c
e
m
a
n
a
g
e
m
e
n
t
a
c
r
o
s
s
m
u
l
t
i
p
l
e
o
p
e
r
a
t
o
r
n
e
t
w
o
r
k
s
t
h
a
t
i
n
c
l
u
d
e
s
f
u
l
f
i
l
l
m
e
n
t
,
c
o
n
t
r
o
l
,
p
e
r
f
o
r
m
a
n
c
e
,
a
s
s
u
r
a
n
c
e
,
u
s
a
g
e
,
s
e
c
u
r
i
t
y
,
a
n
a
l
y
t
i
c
s
,
a
n
d
p
o
l
i
c
y
c
a
p
a
b
i
l
i
t
i
e
s
•
S
e
r
v
i
c
e
O
r
c
h
e
s
t
r
a
t
i
o
n
F
u
n
c
t
i
o
n
a
l
i
t
y
(
S
O
F
)
:
T
h
e
s
e
t
o
f
s
e
r
v
i
c
e
m
a
n
a
g
e
m
e
n
t
l
a
y
e
r
f
u
n
c
t
i
o
n
a
l
i
t
y
s
u
p
p
o
r
t
i
n
g
a
n
a
g
i
l
e
f
r
a
m
e
w
o
r
k
t
o
s
t
r
e
a
m
l
i
n
e
a
n
d
a
u
t
o
m
a
t
e
t
h
e
s
e
r
v
i
c
e
l
i
f
e
c
y
c
l
e
i
n
a
s
u
s
t
a
i
n
a
b
l
e
f
a
s
h
i
o
n
f
o
r
c
o
o
r
d
i
n
a
t
e
d
m
a
n
a
g
e
m
e
n
t
s
u
p
p
o
r
t
i
n
g
d
e
s
i
g
n
,
f
u
l
f
i
l
l
m
e
n
t
,
c
o
n
t
r
o
l
,
t
e
s
t
i
n
g
,
p
r
o
b
l
e
m
m
a
n
a
g
e
m
e
n
t
,
q
u
a
l
i
t
y
m
a
n
a
g
e
m
e
n
t
,
u
s
a
g
e
m
e
a
s
u
r
e
m
e
n
t
s
,
s
e
c
u
r
i
t
y
m
a
n
a
g
e
m
e
n
t
,
a
n
a
l
y
t
i
c
s
,
a
n
d
p
o
l
i
c
y
-
b
a
s
e
d
m
a
n
a
g
e
m
e
n
t
c
a
p
a
b
i
l
i
t
i
e
s
p
r
o
v
i
d
i
n
g
c
o
o
r
d
i
n
a
t
e
d
e
n
d
-
t
o
-
e
n
d
m
a
n
a
g
e
m
e
n
t
a
n
d
c
o
n
t
r
o
l
o
f
L
a
y
e
r
2
a
n
d
L
a
y
e
r
3
C
o
n
n
e
c
t
i
v
i
t
y
S
e
r
v
i
c
e
s
.
•
I
n
f
r
a
s
t
r
u
c
t
u
r
e
C
o
n
t
r
o
l
a
n
d
M
a
n
a
g
e
m
e
n
t
(
I
C
M
)
:
T
h
e
s
e
t
o
f
f
u
n
c
t
i
o
n
a
l
i
t
y
p
r
o
v
i
d
i
n
g
d
o
m
a
i
n
s
p
e
c
i
f
i
c
n
e
t
w
o
r
k
a
n
d
t
o
p
o
l
o
g
y
v
i
e
w
r
e
s
o
u
r
c
e
m
a
n
a
g
e
m
e
n
t
c
a
p
a
b
i
l
i
t
i
e
s
i
n
c
l
u
d
i
n
g
c
o
n
f
i
g
u
r
a
t
i
o
n
,
c
o
n
t
r
o
l
a
n
d
s
u
p
e
r
v
i
s
i
o
n
o
f
t
h
e
n
e
t
w
o
r
k
i
n
f
r
a
s
t
r
u
c
t
u
r
e
.
I
C
M
i
s
r
e
s
p
o
n
s
i
b
l
e
f
o
r
p
r
o
v
i
d
i
n
g
c
o
o
r
d
i
n
a
t
e
d
m
a
n
a
g
e
m
e
n
t
a
c
r
o
s
s
t
h
e
n
e
t
w
o
r
k
r
e
s
o
u
r
c
e
s
w
i
t
h
i
n
a
s
p
e
c
i
f
i
c
m
a
n
a
g
e
m
e
n
t
a
n
d
c
o
n
t
r
o
l
d
o
m
a
i
n
.
F
o
r
e
x
a
m
p
l
e
,
a
s
y
s
t
e
m
s
u
p
p
o
r
t
i
n
g
I
C
M
c
a
p
a
b
i
l
i
t
i
e
s
p
r
o
v
i
d
e
s
c
o
n
n
e
c
t
i
o
n
m
a
n
a
g
e
m
e
n
t
a
c
r
o
s
s
a
s
p
e
c
i
f
i
c
s
u
b
n
e
t
w
o
r
k
d
o
m
a
i
n
.
S
u
c
h
c
a
p
a
b
i
l
i
t
i
e
s
m
a
y
b
e
p
r
o
v
i
d
e
d
w
i
t
h
i
n
s
y
s
t
e
m
s
s
u
c
h
a
s
s
u
b
n
e
t
w
o
r
k
m
a
n
a
g
e
r
s
,
S
D
N
c
o
n
t
r
o
l
l
e
r
s
,
e
t
c
.
•
E
l
e
m
e
n
t
C
o
n
t
r
o
l
a
n
d
M
a
n
a
g
e
m
e
n
t
(
E
C
M
)
:
T
h
e
s
e
t
o
f
f
u
n
c
t
i
o
n
a
l
i
t
y
s
u
p
p
o
r
t
i
n
g
e
l
e
m
e
n
t
m
a
n
a
g
e
m
e
n
t
l
a
y
e
r
c
a
p
a
b
i
l
i
t
i
e
s
f
o
r
i
n
d
i
v
i
d
u
a
l
n
e
t
w
o
r
k
e
l
e
m
e
n
t
s
.
W
h
i
l
e
a
s
y
s
t
e
m
s
u
p
p
o
r
t
i
n
g
E
C
M
c
a
p
a
b
i
l
i
t
i
e
s
p
r
o
v
i
d
e
s
f
o
r
t
h
e
a
b
s
t
r
a
c
t
i
o
n
o
f
i
n
d
i
v
i
d
u
a
l
i
n
f
r
a
s
t
r
u
c
t
u
r
e
e
l
e
m
e
n
t
s
,
i
t
m
a
y
r
e
f
l
e
c
t
t
h
e
e
l
e
m
e
n
t
v
i
e
w
f
o
r
m
u
l
t
i
p
l
e
e
l
e
m
e
n
t
s
,
b
u
t
n
o
t
p
r
o
v
i
d
e
c
o
o
r
d
i
n
a
t
e
d
m
a
n
a
g
e
m
e
n
t
a
c
r
o
s
s
t
h
e
s
e
t
o
f
e
l
e
m
e
n
t
s
.
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.
MEF LSO Reference Architecture
SP Domain
Customer Domain
Partner Domain
Network Infrastructure
Customer
Application
Coordinator
Service Orchestration
Functionality
Service Orchestration
Functionality
PRESTO
(SOF:ICM)
LEGATO
(BUS:SOF)
Element Control
and Management
Infrastructure Control
and Management
ADAGIO (ICM:ECM)
LEGATO
(BUS:SOF)
PRESTO
(SOF:ICM)
ADAGIO (ICM:ECM)
Business
Applications
Service Orchestration
Infrastructure Control
and Management
Business Application
Element Control
and Management
Customer Domain
SP Domain
Partner Domain
End to End Services
LSO Reference Architecture w/ ONAP
Presto
Legato
Adagio
Infrastructure Control and Management
Service Orchestration
Infrastructure Control and Management
Business Application
Element Control
and Management
Customer Domain
SP Domain
Partner Domain
End to End Services
LSO Reference Architecture can be recursive
Presto
Legato
Adagio
Presto
Service Orchestration
Infrastructure Control
and Management
Business Application
Element Control
and Management
MANO
Customer Domain
SP Domain
Partner Domain
End to End Services
MEF
+
ETSI NFV
+
ONF
(my view)
Presto
Legato
Adagio
10
Use Case 1: multi-region support
Infrastructure Control and Management
Business Application
Element Control and Management
Service Orchestration
Presto
Presto
Region 1
Region 2
Region 3
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
Service Orchestration
Infrastructure Control
and Management
Business Application
Element Control
and Management
Customer Domain
SP Domain
Partner Domain
End to End Services
Presto
Legato
Adagio
Illustrating a different IO for each technology domain.
12
Use Case 3: multi-operator federation support
Interlude
Interlude
Service Provider 1
Service Provider 2
Service Provider 3
Business Application
Sonata
Sonata
Different instances of ONAP for each service provider
13
Use Case 3a: multi-region federation within one operator
Interlude
Interlude
Operating Region 1
Operating Region 2
Operating Region 3
Business Application
Sonata
Sonata
Separate instances of ONAP in each region; single service provider
14
Deployment Scenarios
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)
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.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
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.
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)
