1. FUNCTIONAL Architecture for R2+
Every Resource can be exposed as a Service.
Portal
(GUI/CLI)
Run-time
Dashboard OA&M
(VID)
External Data Movement & APIs
Design-time
A&AI
Service Orchestration
Because every Resource can be exposed as a Service, we do not believe it wise to separate the Service Orchestration and the Resource Orchestration functions into separate ONAP components.
Domain Service Descriptors
Domain Service Descriptors
ESR
SDC
Common Service
Resource Orchestration
Domain Resource Descriptors
Domain Resource Descriptors
VNF SDK
DMaaP
Auth.
Microservice Bus …
CLAMP
Policy
DCAE
Alarm Correlation (Holmes) …
SDN-C
APP-C
(g/s) vnfm
Other?
Addressed only tangentially in this discussion
Multi-VIM/MultiCloud
Cloud & WAN
OpenStack
VMware
RackSpace
Azure
......
Consensus on layered architecture. This picture does not imply project structure.

2. Terminology Mapping
ONAP
ETSI MANO (1)
Service
Network Service (Infrastructure Services only) (2)
Service Orchestration
Network Service Orchestration (2)
Resource
VNF and Network (NFVI) network resources (3)
Resource Orchestration
Specific NFVO functions that manage or coordinate the VNF or NFVI network resource’s lifecycle (3)
Cloud Resource
NFVI compute, storage, network
Cloud Resource Orchestration
Functions, perhaps provided by the underlying Cloud Provider (4), that manage or coordinate the NFVI compute, storage, network resource’s lifecycle
Network
An NFVI resource
Allotted Resource (5)
This concept is not discussed in MANO
VF Module
Virtualisation Deployment Unit (VDU)
VF Component
VNFC
Because of this, ETSI TERMINOLOGY IN AND OF ITSELF IS NOT SUFFICIENT TO DESCRIBE THE ONAP PROBLEM SPACE.
Ref: ETSI - NFV Terminology for Main Concepts in NFV
ONAP includes “Customer Services” that ride on top of what ETSI would call a “Network Service”. Also ETSI considers a “Network Service” as always including at least one dedicated VNF, whereas ONAP allows for “Services” that do not include any dedicated VNFs.
Concept of “Allotted Resource” is not discussed in MANO. The concept of “PNF” seems to be out of scope for an NFV-MANO implementation.
For example, the orchestration provided by OpenStack HEAT
An “Allotted Resource” is a resource that is provided by an underlying Service, and which is allotted to a customer’s (for example) Service Instance. E.g., a “VRF” would be modeled as an “Allotted Resource” provided by a virtual PE Router VNF.

3. Allotted Resources – vPE/VRF Example1 4
Every Resource can be exposed as a Service. The ONAP model supports this today through the “Allotted Resource” construct. This concept of “Allotted Resource” does not seem to appear in the ETSI model. Perhaps this is due to ETSI seemingly covering only instantiation of Infrastructure Services, and not instantiation of end Customer Services.
An instantiation request for a L3VPN_Cust Service would result in a VRF being instantiated. That VRF would be “homed” to an existing vPE_Infra Service instance (i.e., the vPE VNF instance on which this VRF will be configured).
“Higher Level” Service 2
L3VPN_Cust Service:
topology_template:
node_templates:
VRF
In this case, the vPE VNF has been packaged as an Infrastructure Service. An instantiation request for this vPE_Infra Service would result in a new vPE VNF being instantiated.
VRF Allotted Resource
requirement: VRF_Capability
“Lower Level” Service
vPE VNF
vPE_Infra Service:
topology_template:
node_templates:
vPE VNF
vPE_Network
capability: VRF_Capability 3
The vPE_Infra Service exposes a capability to provide “VRFs” (a “VRF_Capability”). The L3VPN_Cust Service consumes this capability through its “VRF Allotted Resource” construct.
Network

4. Model-Driven Orchestration
“Generic” model-driven Service flow (limited existing)
Each Resource Type has its own “Generic” model-driven flow. There currently exist such flows for “VNF” and “Network” Resource Types.
Service Orchestration
Resource Orchestration
Cloud Resource Orchestration
PNF
Service X:
topology_template:
node_templates:
PNF
Network
VNF
Allotted Resource
Network
VF Module
Note recursion
VNF
Service Orchestration
Resource Orchestration
Allotted Resource
requirement: A
PNF
An Allotted Resource can be homed to an existing “underlying” Service Instance, or homing could determine that a new Service Instance is needed. This would result in a 2nd level of Service Orchestration.
Service Y:
topology_template:
node_templates:
PNF
Network
VNF
Allotted Resource
capability: A
Network
Service Y is being treated as a “Resource” from the perspective of Service X.
VNF
Allotted Resource

5. N-Level Run Time Nesting? Let The Service Providers Decide
Each Service/Resource “reuse unit” results in a separate thread of orchestration. This would allow for “on demand” spin up of “lower level” (Infrastructure) Service instances.
Could be extended to allow multiple “higher level Services” to each have a “share” of a “lower level Service’s” instance
For the case whereby a “higher level Service” consumes the entirety of a “lower level Service’s” instance, then rather than using an “Allotted Resources” modeling approach, the Service Provider could use a “substitution mapping’ modeling approach. This would result in “flattening” the run-time orchestration

6. Conclusions
Service Providers require the ability to define Services that can be leveraged by higher order Services.
We should not separate Service Orchestration and Resource Orchestration into two separate named components, because each Resource can be exposed as a Service.
What appears as a “Resource” from one Service’s perspective, may actually be a Service from another perspective.
ONAP includes the modeling of “Customer Services” in its charter, whereas ETSI does not appear to do so. Thus, the ETSI terminology and modeling in and of itself is not sufficient to cover the ONAP problem space.
ONAP should provide Service Providers the ability to model their “Service reuse” to drive run-time behavior on a service-by-service basis, including:
Allowing each Service/Resource level to result in a separate set of orchestration threads.
Allow the Service Provider to “flatten” some levels of reuse at run time (e.g., through design time substitution mapping).

7. ONAP Proposed Target Merged Architecture
OSS
BSS
ONAP Portal – Design Studio & Dashboard
Design-time (SDC)
Run-time
Lab Integration & Certification
ONAP Operations Management (OOM)
External Data Movement & APIs
Modeling (specs & Utilities)
Resource Onboarding
A&AI
DCAE
Policy
Active / Available
VNF SDK
Orchestration Framework
Analytic µServices
Runtime Policy Execution Engine
Service & Product Design
Entitlements
Service Orchestration
CDAP
Holmes …
Policy Creation & Validation
Resource / Service Topology
Data Distribution
Resource Orchestration
ESR
Data Collection Layer
Analytic Application Design
Common
Service
DMaaP
AAF
Logging
Micro Services Bus
Catalog
Testing & Certification
SDN-C
gVNF-Controller (prev. App-C)
Products
Resources
Eng. Rules
Services
Policies
Analytics
Multi-VIM
L0-3 Network Controller
Addressed only tangentially in this discussion
L4-7 Generic VNF Controller
Model Driven
Infrastructure
Adaption Layer
Config
Database
Service Logic
Interpreter
Life Cycle Mgmt DGs
Config Database
Service Logic Interpreter
Life Cycle Mgmt func.
Recipe / Engineering Rules & Policy Distribution
Adaption Layer
Standard & sVNFM Adaption Layer
Open
Stack
AWS
Azure
Netconf
Yang
CLI
3rd Party Network
controller
Chef
Netconf
Ansible
Vendor A
Vendor B
sVNFM
EMS
VNF 1
VNF 2
VNF n
PNF
VNF x
Infrastructure
OpenStack
VMware
RackSpace
Azure
......

8. Backup Slides

9. VoLTE Use Case (Approved)

10. Release 1: VoLTE Allotted Resource Modeling Approach
(TOSCA)
Service Level
(TOSCA)
vIMS_Edge Service:
topology_template:
node_templates:
vSBC (VNF):
vPCSCF (VNF):
VoLTE_Edge Service:
topology_template:
node_templates:
vEPC_Edge (Allotted Resource):
vIMS_Edge (Allotted Resource):
“Run Time” Nesting
vSBC VNF:
vPCSCF VNF:
“Run Time” Nesting
vSPGW VNF:
Service Level
(TOSCA)
VNF Level
(TOSCA or HEAT)
Allotted Resource Level
Key:
vEPC_Edge Service:
topology_template:
node_templates:
vSPGW (VNF):
vEPDG (VNF):
vPEDG VNF:

11. Service Level VNF Level (TOSCA) (TOSCA or HEAT) Key:
Alternative Possible Modeling Approach VoLTE Substitution Mapping Modeling Approach – Design Time View
Service Level
(TOSCA)
VNF Level
(TOSCA or HEAT)
vIMS_Edge Service:
topology_template:
node_templates:
vSBC (VNF):
vPCSCF (VNF):
VoLTE_Edge Service:
topology_template:
node_templates:
vEPC (Service):
vIMS (Service):
“Compile Time” Nesting
(For Service Designer
Reuse Purposes)
vSBC VNF:
vPCSCF VNF:
“Compile Time” Nesting
(For Service Designer
Reuse Purposes)
vSPGW VNF:
Service Level
(TOSCA)
VNF Level
(TOSCA or HEAT)
Allotted Resource Level
Key:
vEPC_Edge Service:
topology_template:
node_templates:
vSPGW (VNF):
vEPDG (VNF):
vPEDG VNF:
SDC would support the ability to construct an “upper” Service Definition from other Services definitions. One approach to this would be to use “compile time nesting”. See the next slide for the “distribution time” structure which would be distributed from such a design approach.

12. VNF Level Service Level (TOSCA or HEAT) (TOSCA)
Alternative Possible Modeling Approach VoLTE Substitution Mapping Modeling Approach – Run Time View
VNF Level
(TOSCA or HEAT)
Service Level
(TOSCA)
vIMS_Edge Service:
topology_template:
node_templates:
vSBC (VNF):
vPCSCF (VNF):
vSBC VNF:
vPCSCF VNF:
VoLTE_Edge Service:
topology_template:
node_templates:
vSBC (VNF):
vPCSCF (VNF):
vSPGW (VNF):
vEPDG (VNF):
groups:
vIMS [vSBC, vPCSCF]
vEPC [vSPGW, vPEDG]
vSPGW VNF:
vPEDG VNF:
vEPC_Edge Service:
topology_template:
node_templates:
vSPGW (VNF):
vEPDG (VNF):
“Compile time nesting” results in a substitution mapping at the time of model distribution. At that point the VoLTE_Edge Service no longer has a modeling relationship with the vIMS_Edge or vEPC_Edge services, but is rather “flattened”. All appropriate model constructs of vIMS and vEPC are inherited by VoLTE. Note that the vIMS and vEPC VNF grouping does remain in the VoLTE Model.

13. ETSI MANO – Network Service Instantiation Flow
Orchestration Framework
SDN-C and gVNF-C (APP-C)
Multi-VIM
Homing

14. ETSI MANO – VNF Instantiation Flow
Orchestration Framework
SDN-C and gVNF-C (APP-C)
VNF
Multi-VIM

15. ETSI Terminology
network service: composition of Network Functions and defined by its functional and behavioural specification
network service orchestration: subset of NFV Orchestrator functions that are responsible for Network Service lifecycle management
Network Functions Virtualisation Orchestrator (NFVO): functional block that manages the Network Service (NS) lifecycle and coordinates the management of NS lifecycle, VNF lifecycle (supported by the VNFM) and NFVI resources (supported by the VIM) to ensure an optimized allocation of the necessary resources and connectivity
Virtualisation Deployment Unit (VDU): construct that can be used in an information model, supporting the description of the deployment and operational behaviour of a subset of a VNF, or the entire VNF if it was not componentized in subsets
NFV Infrastructure (NFVI): totality of all hardware and software components which build up the environment in which VNFs are deployed

16. vCPE Use Case Used in These Examples

17. Residential Broadband vCPE Use Case Model: vCpeResCust & vGMuxInfra Topology
TOSCA
HEAT
TunnelXConn AllottedResource:
Requirement:
TunnelXConnCapability
vCpeResCust Service:
topology_template:
node_templates:
TunnelXConn (AllotRes):
BRG (PNF):
vG (VNF):
HEAT indicates that the single vG VM is to be connected to network “vGMUX_LAN” for the vGMuxInfra Service Instance referenced.
BRG PNF Resource:
vG VNF Resource:
VFC (single)
Ext_Conn_Pt (vGMUX_LAN)
vG VF Module:
vGMuxInfra Service:
topology_template:
node_templates:
vGMux_LAN (Ntw):
vGMux (VNF)
Capabilities:
TunnelXConnCapability
Local network to the cloud zone. No need to touch the WAN. So OpenStack only.
vGMUX_LAN Network Resource:
HEAT indicates that the single vGMUX VM is to be connected to network “vGMUX_LAN”
vGMUX VNF Resource:
topology_template:
node_templates:
VFC (single)
Ext_Conn_Pt (vGMUX_LAN)
Ext_Conn_Pt(vBNG_WAN)
vGMUX VF Module:
SDNC uses the TOSCA to determine that these connection points need to be assigned; SDNC returns a structure to SO, which SO maps to the HEAT.

18. vGMuxInfra Service Level Processing

19. vGMuxInfra Resource Level Processing (Network)

20. vGMuxInfra Resource Level Processing
(VNF)
To incorporate ARIA option, need to show that the SO Adaptor determines from the SDC Model that the VNF is described using TOSCA versus HEAT. In the former case the Adaptor will generate a TOSCA document to forward to ARIA, rather than what is shown here.
Need to flesh out the interactions between HEAT and OS and ARIA and OS