1. Proposed Approach for ONAP Runtime Support of Network Service Onboarding
Gil Bullard, AT&T

2. Proposal Summary
Application-level configuration and LCM is the functionality that is peculiar to ONAP, outside of the scope of ETSI MANO.
ONAP should provide two Service Provider options with respect to application level configuration and LCM on a per-NF/per-Service basis:
Option 1: ONAP supports application level configuration and LCM of the NF in the context of the Service
Option 2: An external OSS/BSS/EM supports this application level configuration and LCM
For Service Providers who choose to do so, ONAP should support onboarding of SOL001 NSDs
ONAP runtime support of an onboarded Network Service Descriptor should minimize changes to a Service Provider’s OSS/BSS infrastructure that had been supporting the corresponding “end to end service”
ONAP runtime support should allow Service Provider the option to either “plug in” a VNFM or not. (In the subsequent detailed slide descriptions of this proposal examples of both cases are shown.)
To accomplish these needs, the ONAP runtime/internal model need not support a separate “object type” called “Network Service”. Rather, the onboarding model of Network Service would be mapped to a standard ONAP “Service” in the internal model. Depending on whether Option 1 or Option 2 is desired, this ONAP “Service” would either be enriched to include application level configuration and LCM support, or not.

3. Proposal Summary: Service Provider Options to Meet Standards at the “Edges”
SOL005
Standards Translation/Adaptation Layer
ETSI Translation/Adaptation Layer
ONAP
Onboarding
Service Request
Management
SOL001/SOL004 VNFD
SOL001 NSD
Standards Translation/Adaptation Layer
ETSI Translation/Adaptation Layer
SOL003
Ciaran 14:00
“Evolving support of ETSI - Alignment - VNF LCM”

4. Proposal Summary: Service Provider Option 1
Best viewed in “slideshow model”
VNF 3
ONAP Service B
Have ONAP support onboarding of a SOL001 Network Service Descriptor
Through standard “nested service” support, ONAP modeling would allow the onboarded Service to be included in a higher-order ONAP service. However, because of “separation of concerns” considerations, this higher-order Service would not be aware of the existence of VNF 1 and VNF 2. All management of these VNFs would be delegated to Service A.
VNF 1
VNF 2
ETSI NS A
Translate
VNF 1
VNF 2
ONAP Service A
ONAP SDC would translate the Network Service Descriptor into the ONAP internal format. ONAP would not manage the application level configuration or LCM of that ONAP Service. Rather, external actors would do this (e.g., EM).

5. Proposal Summary: Service Provider Option 1
Best viewed in “slideshow model”
Of course, the resultant Service can still be included in a higher-order ONAP service. Again, because of “separation of concerns” considerations, this higher-order Service would not be aware of the existence of VNF 1 and VNF 2. All management of these VNFs would be delegated to Service A’.
VNF 3
ONAP Service B
Enrich
VNF 1
VNF 2
ETSI NS A
Translate
VNF 1
VNF 2
ONAP Service A
VNF 1’
VNF 2’
ONAP Service A’
If the Service Provider wants ONAP to manage the application level configuration and LCM of the VNFs, the ONAP Service model can be “enriched” with the application level support information.

6. ONAP SO Approach to TOSCA Model-Driven Orchestration

7. Nested Service Topology Templates Drive SO Orchestration
Service Service Template
Assign (inputs)
Create (inputs)
Configure (inputs)
Activate (inputs)
Build (inputs)
VNF Service Template
Assign (inputs)
Create (inputs)
Configure (inputs)
Activate (inputs)
VF Module Service Template
Assign (inputs)
Request (inputs)
TOSCA Standard Node Templates
Network
Service Template
Assign (Inputs)
Create/Config (Inputs)
PNF Service Template
Assign
Configure
Activate
AllottedResource Service Template
Assign
Create/Config
Activate

8. “Outer” Topology Template Drives Service-Level Flow
Service Service Template
Assign
Create
Configure
Activate
Build
Instantiate (Build)
Service_Request
Service Level Flow
Decompose
Home
Assign Service
Create Service
Configure
Activate
Assign Service_Instance
OOF
Create Service_Instance
Configure Service_Instance
Activate Service_Instance
Decompose Service
Configure Service Instance
Configure
Resources
Assign Service Instance
Create Service Instance
Activate Service Instance
Assign
Resources
Assign Svc
Instance
Loop Thru Resources
Create
Resources
Activate Resources
Loop Thru Resources
Loop Thru Resources
Loop Thru Resources
ANF
Service Template
Configure
PNF
Service Template
Configure
Assign Service Instance
VNF
Service Template
Configure
Network
Service Template
Create
Network
Service Template
Activate
Network
Service Template
Assign
ANF
Service Template
Create
ANF
Service Template
Activate
ANF
Service Template
Assign
VNF
Service Template
Create
PNF
Service Template
Activate
PNF
Service Template
Assign
VNF
Service Template
Activate
VNF
Service Template
Assign

9. “Inner” Topology Template Drives VNF-Level Flow
Assign VNF_Instance
Request VNF_Instance
With “Plugged In” VNFM
Assign VNF Instance
Request VNF Instance (with VNFM)
Assign VF Module
Get VF Mod Assignments
Loop Thru VF Modules
Activate VF Module
Request VNF_Instance
Assign VNF
Instance
Create VNF
Instance
No “Plugged In” VNFM
Loop Thru VF Modules
Loop Thru VF Modules
Request VNF Instance (MultiVIM)
VNFM
Create VF Module
Activate VF Module
Get Vf Mod Assign
Activate Vf Module
Assign Vnf
Loop Thru VF Modules
Assign Vf Module
Send a VF-Module activate request to SND-C
Update the vf-module object in A&AI, orchestration-status = Active
Create generic-vnf object in A&AI, orchestration-status = Inventoried
Call SDN-C Assign
Update generic-vnf object in A&AI, orchestration-status = Assigned
Request Vf Module Create
Activate Vf Module
Call SDN-C to get vf-module assignments
Generate VF Module Template (or HEAT) input parameter instance values (e.g., ENV) and pass to Cloud Orchestrator (e.g., OpenStack HEAT) to create object in cloud
Update vf-module object in A&AI, orchestration-status = Created
Create vf-module object in A&AI, orchestration-status = Inventoried
Call SDN-C Assign
Update volume-group object in A&AI, orchestration-status = Assigned

10. Terminology and Background

11. Terminology VNF Onboarding and Enrichment (Onboarding SOL001/4 Example)
Manually Enrich
Promote to Finished Good
VNF 1 SOL004 Package
Attachments
VNF Descriptor
Promote to Finished Good
Translate
Auto Enrich
Manually Enrich
Promote to Finished Good
Translate – Convert from “onboarding” model to ONAP internal model
Auto Enrich – Onboard any “application level” management information from the “AppConfig Template,” an ONAP-standard format attachment to the SOL004 package
Manually Enrich – The “Resource Designer” adds any additional information or constraints that are deemed necessary for the VNF as a “generic” VNF (i.e., across all Services). For example, the Resource Designer could choose to constrain, for perceived security reasons, a particular attribute setting that was allowed by the vendor.
Promote to Finished Good – The Resource Designer indicates that their work on the VNF model is complete, and is now ready to be used in Services as an “ONAP Generic VNF Design Time Model”.
Promote to Finished Good

12. That which the VNF Vendor knows as VNF 1
Background A Note About Notation – Use of ’ to denote “Application Level Awareness”
VNF 1’
Model information descriptive of “Application Aspects” of that which the VNF Vendor knows as VNF 1
VNF 1
Model information descriptive of the “Infrastructure Aspects” of that which the VNF Vendor knows as VNF 1
That which the VNF Vendor knows as VNF 1
VNF 1

13. Background A Note About Notation
The notation ’ indicates that the “application level” aspects are included in the management of that object. E.g., VNF 1’ indicates that the management of that object includes the application level management.
VNF 1
VNF 2
NS A
Model formally specified in ETSI
E.g., because VNF 1 does not have a ’ behind its numeral, the ETSI specification (descriptor) of VNF 1 would not include any information about the application level management of VNF 1.
Model formally specified in ONAP
VNF 1’
VNF 2’
Service A’
E.g., VNF 1’ in this color indicates that management of that object includes both the application level management as well as information about how to instantiate and perform LCM functions on VNF 1.
The VNF itself
VNF 1
VNF 1 in this color represents the VNF 1 itself as a managed object (potentially) in the network.
Service A’
VNF 2’
VNF 1’
Model outside the scope of ETSI
E.g., VNF 1’ in this color indicates that management of that object includes only the application level management. I.e., the “specification” of VNF 1’ represented in this color would not include any information about how to instantiate or perform LCM functions on VNF 1.

14. (*EM is optionally considered part of OSS)
Background Assumed Understanding of an ETSI Service Provider’s Operations Environment 1
BSS/OSS
Design/Develop Time:
Create and distribute Service A’, VNF 1’, and VNF 2’ definitions (outside of the scope of MANO) to OSS/BSS. In this example VNF 1’ and VNF 2’ “descriptors” capture the application level configuration needs of what the VNFM knows as (though the OSS/BSS does not) VNF 1 and VNF 2.
Create and distribute VNF 1, VNF 2, and NS A descriptors to NFVO.
Create and distribute VNF 1 and VNF 2 descriptors to VNFM.
Run Time:
OSS/BSS receives request to create an instance of Service A’. OSS/BSS “decomposes” request into NS A, VNF 1’, VNF 2’.
OSS/BSS calls NFVO via SOL005 API requesting instantiation of NS A.
NFVO calls VNFM 1 via SOL003 API, requesting creation of VNF 1, passing necessary “deployment data” values.
VNFM 1 calls VIM to create VNF 1, and applies any needed deployment data via SOL002 API. At this point VNF 1 only has “deployment data” (networking data) configured. “Deployment data” can be thought of as the functional equivalent of the sort of data one might expect to find captured in a HEAT ENV.
NFVO calls VNFM 2 via SOL003 API, requesting creation of VNF 2, passing necessary “deployment data” values.
VNFM 2 calls VIM to create VNF 2, and applies any needed deployment data via SOL002 API. At this point VNF 2 only has “deployment data” (networking data) configured.
Connectivity between the VNFs is configured via a direct interface between the NFVO and the VIM
The BSS/OSS stages the EM(s) with the appropriate application configuration data. (Note that this is outside of the scope of ETSI, and so different Service Providers can use different triggers for sending application level data to the EMs, and triggering the application of that data into the VNFs.)
(*EM is optionally considered part of OSS) 1
Service A’
(Service A’ Request)
Does not formally specify application level data, only deployment data
NS A
SM (Service A’)
VNF 2’
VNF 1’ 8
(Service A’ Request) NM 2
NS A 2
SOL005
(“NS A” request)
VNF 1
VNF 2
Ntw A
SOL001 (NSD)
NFVO
Application Level configuration of VNF 1 in context of Service A’
Application Level configuration of VNF 2 in context of Service A’
SOL003 3 3 5
SOL001 (VNFD)
VNFM 1
VNFM 2 7
VIM 4 6
SOL002 (deployment data)
VIM
VNF1
EMs
Ntw A
VNF2 EM
Does not formally specify application level data, only deployment data

15. Detailed Proposal: Design Time and Run Time

16. SDC VNF 1 VNF 2 NS A Ntw A Service A’ OSS/BSS NS A VNF 2’ VNF 1’ ONAP
Service Provider Options for Migrating a Given ETS NS into ONAP without an Optional “Plugged In” VNFM Service Provider Option A1: ONAP Supports Application Level Configuration
Does not formally specify application level data, only deployment data
Service Designer enriches the Service A model to create the Service A’ model. Included is the definition of the input level data that must be supplied with the service A’ instantiation request and the associated data transformation and mapping (to the NFVO). Also included is the definition of the transformation and mapping of the Service A’ input parameters to the underlying VNF 1’ and VNF 2’ application data parameters.
SDC 4 6
VNF 1
VNF 2
NS A
Ntw A 1 2
Service A’
Translate
Enrich
OSS/BSS 1
OSS would be modified to relinquish the SM and NM functionality to ONAP. OSS would thus send a single Service A’ level request, as opposed to separate NS A and Service A’/VNF 1 and Service A’/VNF 2 requests. 5
Enrich
Translate 3
NS A
VNF 2’
SOL001 (NSD, VNFD)
VNF 1’
TBD
(Service A’ request) 2
VNF 1 AppConfig Template
VNF 2 AppConfig Template
Automated enrichment based on vendor’s artifact 7
ONAP 3
ONAP Service Descriptor 4 5
Service A’
An ONAP formalization of the VNF’s application level configuration needs, incorporated as an attached into the SOL004 VNF Package.
VNF 1’
VNF 2’
Ntw A
application
data 9 10 7 8
Though not formally a part of the ONAP internal model, the ETSI Network Service is still conceptually present in this approach, but is merged into the single ONAP Service, allowing ONAP to treat both the application level configuration and the deployment level LCM as part of the same service. 6
(*if an optional EM is present, its configuration data and activation trigger would be handled by ONAP)
VIM
Ntw A
VNF1
VNF2

17. Service Provider Options for Migrating a Given ETS NS into ONAP with a “Plugged In” VNFM Service Provider Option A1: ONAP Supports Application Level Configuration
Design/Develop Time:
OSS/BSS is modified such that it no longer knows how to decompose Service A’ into component NS A, VNF 1’, and VNF 2’. OSS/BSS also modified such that its endpoint of requesting Service A’ instantiation is now ONAP.
The existing NS A descriptor is loaded into ONAP SDC, along with the VNF 1 and VNF 2 descriptors.
ONAP SDC translates the VNF 1 and VNF 2 descriptors from the onboarding model (green VNF 1 and 2) to the SDC internal VNF models (blue VNF 1 and 2)
ONAP SDC translates the NS A descriptor from the onboarding model to the SDC internal Service model (Service A).
ONAP defines a standard format in which a VNF vendor can capture their VNF’s application level configuration needs. This ONAP-specific artifact would be included in the VNF Package as an attachment. SDC would extract this content and apply to the VNFs, now referring to them as VNF 1’ and VNF 2’.
SDC service designer enriches the SDC internal model for Service A to capture the application level configuration data needs of the corresponding “end to end service”. We now refer to this as Service A’.
Distribute VNF 1’, VNF 2’, and Service A’ descriptors to ONAP run time catalog.
Distribute VNF 1 and VNF 2 descriptors to VNFM.
Run Time:
OSS/BSS receives request to create an instance of Service A’. OSS/BSS does not decompose request.
OSS/BSS calls ONAP via (TBD) API requesting instantiation of Service A’. ONAP decomposes Service A’ into VNF 1’, VNF 2’ and Ntw A, and performs homing for these Resources.
ONAP makes network assignments for Ntw A.
ONAP makes network assignments for VNF 1’.
ONAP makes network assignments for VNF 2’.
ONAP calls appropriate endpoint to create/configure Ntw A.
ONAP calls VIM to create VNF 1, and applies any needed deployment data (e.g., via HEAT ENV). At this point VNF 1 only has “deployment data” (networking data) configured.
ONAP calls VIM to create VNF 2, and applies any needed deployment data (e.g., via HEAT ENV). At this point VNF 2 only has “deployment data” (networking data) configured.
ONAP configures application level data of VNF 1’.
ONAP configures application level data of VNF 2’.

18. SDC VNF 1 VNF 2 NS A Ntw A Service A’ OSS/BSS NS A VNF 2’ VNF 1’ ONAP
Service Provider Options for Migrating a Given ETS NS into ONAP with an Optional “Plugged In” VNFM Service Provider Option A2: ONAP Supports Application Level Configuration
Does not formally specify application level data, only deployment data
Service Designer enriches the Service A model to create the Service A’ model. Included is the definition of the input level data that must be supplied with the service A’ instantiation request and the associated data transformation and mapping (to the NFVO). Also included is the definition of the transformation and mapping of the Service A’ input parameters to the underlying VNF 1’ and VNF 2’ application data parameters.
SDC 4 6
VNF 1
VNF 2
NS A
Ntw A 1 2
Service A’
Translate
Enrich
OSS/BSS 1
OSS would be modified to relinquish the SM and NM functionality to ONAP. OSS would thus send a single Service A’ level request, as opposed to separate NS A and Service A’/VNF 1 and Service A’/VNF 2 requests. 5
Enrich
Translate 3
NS A
VNF 2’
SOL001 (NSD, VNFD)
VNF 1’
TBD
(Service A’ request) 2
VNF 1 AppConfig Template
VNF 2 AppConfig Template
Automated enrichment based on vendor’s artifact 7
ONAP
SM/NM/EM
ONAP Service Descriptor
NFVO
The “DataMap” function reverse maps instance data from the ONAP internal to the ETSI model. 3 4 5
Service A’
An ONAP formalization of the VNF’s application level configuration needs, incorporated as an attached into the SOL004 VNF Package. 8
DataMap -> VNF 1
DataMap -> VNF 2
VNF 1’
VNF 2’
Ntw A
SOL003 7 9
application
data 11 12
This reverse mapping can be derived from the SDC onboard translate.
VNFM 1
ETSI VNF Descriptor
VNFM 2
Though not formally a part of the ONAP internal model, the ETSI Network Service is still conceptually present in this approach, but is merged into the single ONAP Service, allowing ONAP to treat both the application level configuration and the deployment level LCM as part of the same service. 6 8 10
SOL002 (deployment data)
VIM
(*if an optional EM is present, its configuration data and activation trigger would be handled by ONAP)
Ntw A
VNF1
VNF2

19. Service Provider Options for Migrating a Given ETS NS into ONAP with a “Plugged In” VNFM Service Provider Option A2: ONAP Supports Application Level Configuration
Design/Develop Time:
OSS/BSS is modified such that it no longer knows how to decompose Service A’ into component NS A, VNF 1’, and VNF 2’. OSS/BSS also modified such that its endpoint of requesting Service A’ instantiation is now ONAP.
The existing NS A descriptor is loaded into ONAP SDC, along with the VNF 1 and VNF 2 descriptors.
ONAP SDC translates the VNF 1 and VNF 2 descriptors from the onboarding model (green VNF 1 and 2) to the SDC internal VNF models (blue VNF 1 and 2)
ONAP SDC translates the NS A descriptor from the onboarding model to the SDC internal Service model (Service A).
ONAP defines a standard format in which a VNF vendor can capture their VNF’s application level configuration needs. This ONAP-specific artifact would be included in the VNF Package as an attachment. SDC would extract this content and apply to the VNFs, now referring to them as VNF 1’ and VNF 2’.
SDC service designer enriches the SDC internal model for Service A to capture the application level configuration data needs of the corresponding “end to end service”. We now refer to this as Service A’.
Distribute VNF 1’, VNF 2’, and Service A’ descriptors to ONAP run time catalog.
Distribute VNF 1 and VNF 2 descriptors to VNFM.
Run Time:
OSS/BSS receives request to create an instance of Service A’. OSS/BSS does not decompose request.
OSS/BSS calls ONAP via (TBD) API requesting instantiation of Service A’. ONAP decomposes Service A’ into VNF 1’, VNF 2’ and Ntw A, and performs homing for these Resources.
ONAP makes network assignments for Ntw A.
ONAP makes network assignments for VNF 1’.
ONAP makes network assignments for VNF 2’.
ONAP calls appropriate endpoint to create/configure Ntw A.
ONAP calls VNFM 1 via SOL003 API, requesting creation of VNF 1, passing necessary “deployment data” values (e.g., assignments). This requires reverse translation of VNF 1’->VNF 1 be preserved in the SDC onboarding translation function.
VNFM calls VIM to create VNF 1, and applies any needed deployment data via SOL002 API. At this point VNF 1 only has “deployment data” (networking data) configured. “Deployment data” can be thought of as the functional equivalent of the sort of data one might expect to find captured in a HEAT ENV
ONAP calls VNFM 2 requesting creation of VNF 2, passing necessary “deployment data” values (e.g., assignments). This requires reverse translation of VNF 2’->VNF 2 be preserved in the SDC onboarding translation function. At this point VNF 1 only has “deployment data” (networking data) configured.
VNFM calls VIM to create VNF 2, and applies any needed deployment data via SOL002 API. At this point VNF 1 only has “deployment data” (networking data) configured.
ONAP configures application level data of VNF 1’.
ONAP configures application level data of VNF 2’.

20. OSS/BSS Service A’ VNF 2’ VNF 1’ SDC VNF 1 VNF 2 NS A Ntw A NS A ONAP
Service Provider Options for Migrating a Given ETS NS into ONAP without an Optional “Plugged In” VNFM Service Provider Option B1: OSS/BSS Supports Application Level Configuration
In this option, ONAP is unaware of Service A’
OSS/BSS
In this option the OSS/BSS and EMs retain the responsibility of managing Service A’, including applying the application level data.
Service A’
VNF 2’
VNF 1’ 1
SDC 3
SM (Service A’)
VNF 1
VNF 2
NS A
Ntw A 1
NS A
(Service A’ Request) 12
Translate NM 2
SOL001 (NSD, VNFD)
SOL005
(“NS A” request) 2
In this option, ONAP is unaware of the application-level data associated with these VNFs.
Translate
ONAP Adaptor
(TBD)
(Service A request) 3
Application Level configuration of VNF 1 in context of Service A’
Application Level configuration of VNF 2 in context of Service A’ 4
ONAP Service Descriptor
ONAP
Does not formally specify application level data, only deployment data
NM/EM
NFVO
VNF 1
VNF 2
Service A
Ntw A 4 5 6
Does not know about application level data, only deployment data 10 11 7 8 9
For VNFs which are supported by a “plug in” VNFM, the SDC “Translate” function maps ETSI “resource data” and “deployment data” into ONAP “cloud services” data sent across the SOL003 API to the VNFM. In this case, ONAP interacts with the VNFM at the “Create” operation, and not with a VIM directly.
VIM
Ntw A
Ntw A
VNF1
EMs
VNF2
EMs

21. Service Provider Options for Migrating a Given ETS NS into ONAP with a “Plugged In” VNFM Service Provider Option B1: OSS/BSS Supports Application Level Configuration
Design/Develop Time:
The existing NS A descriptor is loaded into ONAP SDC, along with the VNF 1 and VNF 2 descriptors.
ONAP SDC translates the VNF 1 and VNF 2 descriptors from the onboarding model (green VNF 1 and 2) to the SDC internal VNF models (blue VNF 1 and 2).
ONAP SDC translates the NS A descriptor from the onboarding model to the SDC internal Service model (Service A).
Distribute VNF 1, VNF 2, and Service A descriptors to ONAP run time catalog.
Distribute VNF 1 and VNF 2 descriptors to VNFM.
Run Time:
OSS/BSS receives request to create an instance of Service A’. OSS/BSS decomposes request into NS A, VNF 1’, VNF 2’.
OSS/BSS calls ONAP SOL005 Adaptor requesting instantiation of NS A.
ONAP Adaptor uses SDC model information to translate the SOL005 NS A request into an ONAP API request for Service A. ONAP decomposes Service A into VNF 1 and VNF 2, and performs homing for these VNFs.
ONAP makes network assignments for Ntw A.
ONAP makes any needed network assignments for VNF 1 as per the VNF 1 descriptor. (Depends upon whether the Service Provider wants the OSS/BSS to pass in VNF 1 network assignments with the SOL005 request, or whether wants to have ONAP make these assignments.)
ONAP makes any needed network assignments for VNF 2 as per the VNF 2 descriptor. (Depends upon whether the Service Provider wants the OSS/BSS to pass in VNF 2 network assignments with the SOL005 request, or whether wants to have ONAP make these assignments.)
ONAP calls appropriate endpoint to create/configure Ntw A.
ONAP calls VIM to create VNF 1, and applies any needed deployment data (e.g., via HEAT ENV). At this point VNF 1 only has “deployment data” (networking data) configured.
ONAP calls VIM to create VNF 2, and applies any needed deployment data (e.g., via HEAT ENV). At this point VNF 2 only has “deployment data” (networking data) configured.
ONAP determines that, as per the SDC model thereof, there is no application level data for ONAP to configure for VNF 1 in the context of Service A.
ONAP determines that, as per the SDC model thereof, there is no application level data for ONAP to configure VNF 2 in the context of Service A.
Upon receipt of success from ONAP, OSS/BSS requests the appropriate EM(s) to configure VNF 1’ and VNF 2’ (i.e., the application level data configuration of VNF 1 and VNF 2 in the Service A’ context).

22. OSS/BSS Service A’ VNF 2’ VNF 1’ SDC VNF 1 VNF 2 NS A Ntw A NS A ONAP
Service Provider Options for Migrating a Given ETS NS into ONAP with an Optional “Plugged In” VNFM Service Provider Option B2: OSS/BSS Supports Application Level Configuration
In this option, ONAP is unaware of Service A’
OSS/BSS
In this option the OSS/BSS and EMs retain the responsibility of managing Service A’, including applying the application level data.
Service A’
VNF 2’
VNF 1’ 1
SDC 3
SM (Service A’)
VNF 1
VNF 2
NS A
Ntw A 1
NS A
(Service A’ Request) 14
Translate NM 2
SOL001 (NSD, VNFD)
SOL005
(“NS A” request) 2
In this option, ONAP is unaware of the application-level data associated with these VNFs.
Translate
ONAP Adaptor
(TBD)
(Service A request) 3
Application Level configuration of VNF 1 in context of Service A’
Application Level configuration of VNF 2 in context of Service A’ 4
ONAP Service Descriptor
ONAP
Does not formally specify application level data, only deployment data 4 5 6
NM/EM
NFVO
VNF 1
VNF 2
Service A
Ntw A
Does not know about application level data, only deployment data
DataMap -> VNF 1
DataMap -> VNF 2 12 13
SOL003 8 10 7
ETSI VNF Descriptor 5
VNFM 1
VNFM 2
For VNFs which are supported by a “plug in” VNFM, the SDC “Translate” function maps ETSI “resource data” and “deployment data” into ONAP “cloud services” data sent across the SOL003 API to the VNFM. In this case, ONAP interacts with the VNFM at the “Create” operation, and not with a VIM directly. 9
SOL002 11
VIM
Ntw A
Ntw A
VNF1
EMs
VNF2
EMs

23. Service Provider Options for Migrating a Given ETS NS into ONAP with a “Plugged In” VNFM Service Provider Option B2: OSS/BSS Supports Application Level Configuration
Design/Develop Time:
The existing NS A descriptor is loaded into ONAP SDC, along with the VNF 1 and VNF 2 descriptors.
ONAP SDC translates the VNF 1 and VNF 2 descriptors from the onboarding model (green VNF 1 and 2) to the SDC internal VNF models (blue VNF 1 and 2).
ONAP SDC translates the NS A descriptor from the onboarding model to the SDC internal Service model (Service A).
Distribute VNF 1, VNF 2, and Service A descriptors to ONAP run time catalog.
Distribute VNF 1 and VNF 2 descriptors to VNFM.
Run Time:
OSS/BSS receives request to create an instance of Service A’. OSS/BSS decomposes request into NS A, VNF 1’, VNF 2’.
OSS/BSS calls ONAP SOL005 Adaptor requesting instantiation of NS A.
ONAP Adaptor uses SDC model information to translate the SOL005 NS A request into an ONAP API request for Service A. ONAP decomposes Service A into VNF 1 and VNF 2, and performs homing for these VNFs.
ONAP makes network assignments for Ntw A.
ONAP makes any needed network assignments for VNF 1 as per the VNF 1 descriptor. (Depends upon whether the Service Provider wants the OSS/BSS to pass in VNF 1 network assignments with the SOL005 request, or whether wants to have ONAP make these assignments.)
ONAP makes any needed network assignments for VNF 2 as per the VNF 2 descriptor. (Depends upon whether the Service Provider wants the OSS/BSS to pass in VNF 2 network assignments with the SOL005 request, or whether wants to have ONAP make these assignments.)
ONAP calls appropriate endpoint to create/configure Ntw A.
ONAP calls VNFM 1 via SOL003 API, requesting creation of VNF 1, passing necessary “deployment data” values (e.g., assignments). This requires reverse translation of internal VNF 1 model (blue) to ETSI VNF 1 model (green), which in turn requires this mapping be preserved in the SDC onboarding translation function.
VNFM calls VIM to create VNF 1, and applies any needed deployment data via SOL002 API. At this point VNF 1 only has “deployment data” (networking data) configured. “Deployment data” can be thought of as the functional equivalent of the sort of data one might expect to find captured in a HEAT ENV
ONAP calls VNFM 2 via SOL003 API, requesting creation of VNF 2, passing necessary “deployment data” values (e.g., assignments). This requires reverse translation of internal VNF 2 model (blue) to ETSI VNF 2 model (green), which in turn requires this mapping be preserved in the SDC onboarding translation function.
VNFM calls VIM to create VNF 2, and applies any needed deployment data via SOL002 API. At this point VNF 2 only has “deployment data” (networking data) configured.
ONAP determines that, as per the SDC model thereof, there is no application level data for ONAP to configure for VNF 1.
ONAP determines that, as per the SDC model thereof, there is no application level data for ONAP to configure for VNF 2.
Upon receipt of success from ONAP, OSS/BSS requests the appropriate EM(s) to configure VNF 1’ and VNF 2’ (i.e., the application level data configuration of VNF 1 and VNF 2 in the Service A’ context).

24. Backup Slides

25. “Plugging In” a VNFM Into ONAP: Instantiate VNF
Determine cloud instance for each VNF Resource (including this one) 1 SO 3
OOF
Create Service Instance
SO Internal: Service Level Workflow
Request Homing 4 2
Decompose
Determine Resource needs (including this VNF)
Spawn Resource-Level Sub-Flows
Only this single “instantiate VNF” sub-flow shown
SO Internal: VNF Level Workflow 5
Locate ordered set of VF Modules associated with the requested instantiation level (from the transformed VNF TOSCA).
Determine if requested instantiation level is allowed. (If not, return Error) 8
Instantiate VNF
Inventory 6
Assign VNF (Instantiate) 14
Configure VNF 13
SO or VNFM Adaptor responsible for retrieving the assignments from SDNC (organized by VF Module) and consolidating them (organizing by VM type).
SO Loop:
Per VF Module
If necessary
Stub 12
VNFM Adaptor 9
SOL003 (CreateVnf, InstantiateVnf,Grant) 7
Assign VF Module
VNFM
(Doesn’t necessarily care about VF Modules)
Only those major ONAP components associated with this new option are represented.
A&AI
Gen NFC
SDNC 11
Deployment Data (SOL002)
Application Data
Resource Data
VIM 10 15
VNF

26. ECOMP Delegates Application Level Configuration to an External Entity
Background AT&T Currently Supports Two Separate Approaches to Managing Application Level Data
ECOMP Delegates Application Level Configuration to an External Entity
ECOMP Performs Application Level Configuration
BSS/OSS*
OSS/BSS
(*if an optional EM is present, its configuration data and activation trigger would be handled by BSS/OSS) 1
ECOMP’s responsibility is to stand up collections of VNFs as infrastructure. 4
In AT&T’s understanding, this first approach is similar to the approach that ETSI took for support of NFV. 1
ECOMP
ECOMP
Application Level configuration 4
Application Level configuration
VNF instantiation 2 2
VNF instantiation
(*if an optional EM is present, its configuration data and activation trigger would be handled by ECOMP) 3
VIM 3
VIM
VNF1
Ntw A
VNF2
Ntw A
VNF1
VNF2