Proposed Approach for ONAP Runtime Support of Network

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

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

Proposal Summary: Service Provider Options to Meet Standards at the “Edges” SOL 005 ETSI Translation/Adaptation Layer Standards Translation/Adaptation Layer Service Request SOL 001/SOL 004 VNFD Onboarding SOL 001 NSD ONAP Management ETSI Translation/Adaptation Layer Standards Translation/Adaptation Layer SOL 003 Ciaran Murphy @ 14: 00 “Evolving support of ETSI - Alignment - VNF LCM”

Proposal Summary: Service Provider Option 1 Best viewed in “slideshow model” ONAP Service B 1. Have ONAP support onboarding of a SOL 001 Network Service Descriptor ETSI NS A VNF 1 VNF 2 VNF 3 ONAP Service A Translate VNF 1 VNF 2 2. 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). 3. 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. 4

Proposal Summary: Service Provider Option 1 Best viewed in “slideshow model” 2. 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’. ONAP Service B VNF 3 ETSI NS A VNF 1 VNF 2 ONAP Service A’ ONAP Service A Translate VNF 1 VNF 2 Enrich VNF 1’ VNF 2’ 1. 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. 5

s ONAP SO Approach to TOSCA Model-Driven Orchestration

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

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

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

s Terminology and Background

Terminology VNF Onboarding and Enrichment (Onboarding SOL 001/4 Example) Promote to Finished Good Manually Enrich VNF 1 SOL 004 Package Promote to Finished Good VNF Descriptor Attachments Translate Auto Enrich Translate – Convert from “onboarding” model to ONAP internal model Auto Enrich – Onboard any “application level” management information from the “App. Config Template, ” an ONAP-standard format attachment to the SOL 004 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 Manually Enrich Promote to Finished Good

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

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. Model formally specified in ETSI Model formally specified in ONAP The VNF itself Model outside the scope of ETSI NS A VNF 1 VNF 2 Service A’ VNF 1’ VNF 2’ VNF 1 Service A’ VNF 2’ VNF 1’ 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. 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 in this color represents the VNF 1 itself as a managed object (potentially) in the network. 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.

Background Assumed Understanding of an ETSI Service Provider’s Operations Environment 1 Does not formally specify application level data, only deployment data Service A’ NS A VNF 1’ 2’ VNF (Service A’ Request) SM (Service A’) 8 (Service A’ Request) 2 VNF 2 Ntw A SOL 005 (“NS A” request) NFVO SOL 001 (NSD) SOL 003 3 SOL 001 (VNFD) 5 VNFM 1 VNFM 2 Ntw A 4 VIM 7 VIM Does not formally specify application level data, only deployment data 3 Application Level configuration of VNF 2 in context of Service A’ NM NS A VNF 1 (*EM is optionally considered part of OSS) Application Level configuration of VNF 1 in context of Service A’ 2 1 BSS/OSS 6 SOL 002 (deployment data) VNF 1 VNF 2 EMs EM Design/Develop Time: 1. 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. 2. Create and distribute VNF 1, VNF 2, and NS A descriptors to NFVO. 3. Create and distribute VNF 1 and VNF 2 descriptors to VNFM. Run Time: 1. OSS/BSS receives request to create an instance of Service A’. OSS/BSS “decomposes” request into NS A, VNF 1’, VNF 2’. 2. OSS/BSS calls NFVO via SOL 005 API requesting instantiation of NS A. 3. NFVO calls VNFM 1 via SOL 003 API, requesting creation of VNF 1, passing necessary “deployment data” values. 4. VNFM 1 calls VIM to create VNF 1, and applies any needed deployment data via SOL 002 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. 5. NFVO calls VNFM 2 via SOL 003 API, requesting creation of VNF 2, passing necessary “deployment data” values. 6. VNFM 2 calls VIM to create VNF 2, and applies any needed deployment data via SOL 002 API. At this point VNF 2 only has “deployment data” (networking data) configured. 7. Connectivity between the VNFs is configured via a direct interface between the NFVO and the VIM 8. 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. )

s Detailed Proposal: Design Time and Run Time

Service Provider Options for Migrating a Given ETS NS into ONAP without an Optional “Plugged In” VNFM Service Provider Option A 1: ONAP Supports Application Level Configuration Does not formally specify application level data, only deployment data NS A VNF 1 2 VNF 2 4 6 Translate Ntw A SOL 001 (NSD, VNFD) VNF 1 App. Config VNF 2 App. Config Template An ONAP formalization of the VNF’s application level configuration needs, incorporated as an attached into the SOL 004 VNF Package. 3 Translate 5 2 TBD (Service A’ request) 7 ONAP Service Descriptor ONAP 3 Service A’ VNF 1’ 1 OSS/BSS VNF 2’ VNF 1’ NS A Enrich Automated enrichment based on vendor’s artifact 1 Service A’ Enrich VNF 2’ 4 Ntw A application data 7 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. 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 9 10 8 6 Ntw A VIM SDC 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. VNF 1 VNF 2 (*if an optional EM is present, its configuration data and activation trigger would be handled by ONAP)

Service Provider Options for Migrating a Given ETS NS into ONAP with a “Plugged In” VNFM Service Provider Option A 1: ONAP Supports Application Level Configuration Design/Develop Time: 1. 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. 2. The existing NS A descriptor is loaded into ONAP SDC, along with the VNF 1 and VNF 2 descriptors. 3. 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) 4. ONAP SDC translates the NS A descriptor from the onboarding model to the SDC internal Service model (Service A). 5. 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’. 6. 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’. 7. Distribute VNF 1’, VNF 2’, and Service A’ descriptors to ONAP run time catalog. 8. Distribute VNF 1 and VNF 2 descriptors to VNFM. Run Time: 1. OSS/BSS receives request to create an instance of Service A’. OSS/BSS does not decompose request. 2. 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. 3. ONAP makes network assignments for Ntw A. 4. ONAP makes network assignments for VNF 1’. 5. ONAP makes network assignments for VNF 2’. 6. ONAP calls appropriate endpoint to create/configure Ntw A. 7. 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. 8. 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. 9. ONAP configures application level data of VNF 1’. 10. ONAP configures application level data of VNF 2’.

Service Provider Options for Migrating a Given ETS NS into ONAP with an Optional “Plugged In” VNFM Service Provider Option A 2: ONAP Supports Application Level Configuration Does not formally specify application level data, only deployment data NS A VNF 1 2 VNF 2 4 6 Translate Ntw A SOL 001 (NSD, VNFD) VNF 1 App. Config VNF 2 App. Config Template An ONAP formalization of the VNF’s application level configuration needs, incorporated as an attached into the SOL 004 VNF Package. 3 Translate 5 2 TBD (Service A’ request) 7 ONAP Service Descriptor ONAP 3 4 5 Service A’ 8 VNF 1’ 1 OSS/BSS VNF 2’ VNF 1’ NS A Enrich Automated enrichment based on vendor’s artifact 1 Service A’ Enrich VNF 2’ Ntw A 7 9 VNFM 1 VNFM 2 6 Ntw A 8 10 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. The “Data. Map” function reverse maps instance data from the ONAP internal to the ETSI model. Data. Map -> VNF 1 Data. Map -> VNF 2 SOL 003 ETSI VNF Descriptor 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. SM/NM/EM NFVO VIM SDC 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. application data 11 SOL 002 (deployment data) VNF 1 VNF 2 12 This reverse mapping can be derived from the SDC onboard translate. (*if an optional EM is present, its configuration data and activation trigger would be handled by ONAP)

Service Provider Options for Migrating a Given ETS NS into ONAP with a “Plugged In” VNFM Service Provider Option A 2: ONAP Supports Application Level Configuration Design/Develop Time: 1. 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. 2. The existing NS A descriptor is loaded into ONAP SDC, along with the VNF 1 and VNF 2 descriptors. 3. 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) 4. ONAP SDC translates the NS A descriptor from the onboarding model to the SDC internal Service model (Service A). 5. 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’. 6. 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’. 7. Distribute VNF 1’, VNF 2’, and Service A’ descriptors to ONAP run time catalog. 8. Distribute VNF 1 and VNF 2 descriptors to VNFM. Run Time: 1. OSS/BSS receives request to create an instance of Service A’. OSS/BSS does not decompose request. 2. 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. 3. ONAP makes network assignments for Ntw A. 4. ONAP makes network assignments for VNF 1’. 5. ONAP makes network assignments for VNF 2’. 6. ONAP calls appropriate endpoint to create/configure Ntw A. 7. ONAP calls VNFM 1 via SOL 003 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. 8. VNFM calls VIM to create VNF 1, and applies any needed deployment data via SOL 002 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 9. 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. 10. VNFM calls VIM to create VNF 2, and applies any needed deployment data via SOL 002 API. At this point VNF 1 only has “deployment data” (networking data) configured. 11. ONAP configures application level data of VNF 1’. 12. ONAP configures application level data of VNF 2’.

Service Provider Options for Migrating a Given ETS NS into ONAP without an Optional “Plugged In” VNFM Service Provider Option B 1: OSS/BSS Supports Application Level Configuration In this option, ONAP is unaware of Service A’ NS A VNF 1 3 NS A 1 VNF 2 Ntw A VNF 1’ 2’ VNF SM (Service A’) (Service A’ Request) 2 SOL 001 (NSD, VNFD) Service A VNF 1 VNF 2 Ntw A 3 (TBD) (Service A request) ONAP 4 5 6 Does not know about application level data, only deployment data 10 11 7 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 SOL 003 API to the VNFM. In this case, ONAP interacts with the VNFM at the “Create” operation, and not with a VIM directly. NM/EM NFVO Ntw. AA 8 Application Level configuration of VNF 2 in context of Service A’ ONAP Service Descriptor ONAP Adaptor Application Level configuration of VNF 1 in context of Service A’ 4 Does not formally specify application level data, only deployment data 2 SOL 005 (“NS A” request) In this option, ONAP is unaware of the application-level data associated with these VNFs. Translate 12 NM Translate 9 VIM SDC Service A’ In this option the OSS/BSS and EMs retain the responsibility of managing Service A’, including applying the application level data. OSS/BSS 1 VNF 2 EMs

Service Provider Options for Migrating a Given ETS NS into ONAP with a “Plugged In” VNFM Service Provider Option B 1: OSS/BSS Supports Application Level Configuration Design/Develop Time: 1. The existing NS A descriptor is loaded into ONAP SDC, along with the VNF 1 and VNF 2 descriptors. 2. 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). 3. ONAP SDC translates the NS A descriptor from the onboarding model to the SDC internal Service model (Service A). 4. Distribute VNF 1, VNF 2, and Service A descriptors to ONAP run time catalog. 5. Distribute VNF 1 and VNF 2 descriptors to VNFM. Run Time: 1. OSS/BSS receives request to create an instance of Service A’. OSS/BSS decomposes request into NS A, VNF 1’, VNF 2’. 2. OSS/BSS calls ONAP SOL 005 Adaptor requesting instantiation of NS A. 3. ONAP Adaptor uses SDC model information to translate the SOL 005 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. 4. ONAP makes network assignments for Ntw A. 5. 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 SOL 005 request, or whether wants to have ONAP make these assignments. ) 6. 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 SOL 005 request, or whether wants to have ONAP make these assignments. ) 7. ONAP calls appropriate endpoint to create/configure Ntw A. 8. 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. 9. 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. 10. 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. 11. 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. 12. 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).

Service Provider Options for Migrating a Given ETS NS into ONAP with an Optional “Plugged In” VNFM Service Provider Option B 2: OSS/BSS Supports Application Level Configuration In this option, ONAP is unaware of Service A’ NS A VNF 1 3 NS A 1 VNF 2 Ntw A VNF 1’ 2’ VNF SM (Service A’) (Service A’ Request) 2 Service A VNF 1 VNF 2 Ntw A 3 (TBD) (Service A request) ONAP Does not know about application level data, only deployment data ETSI VNF Descriptor 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 SOL 003 API to the VNFM. In this case, ONAP interacts with the VNFM at the “Create” operation, and not with a VIM directly. 5 4 NM/EM NFVO 5 6 Data. Map -> VNF 1 Data. Map -> VNF 2 SOL 003 12 13 Application Level configuration of VNF 2 in context of Service A’ ONAP Service Descriptor ONAP Adaptor Application Level configuration of VNF 1 in context of Service A’ 4 Does not formally specify application level data, only deployment data 2 SOL 005 (“NS A” request) In this option, ONAP is unaware of the application-level data associated with these VNFs. Translate 14 NM Translate SOL 001 (NSD, VNFD) In this option the OSS/BSS and EMs retain the responsibility of managing Service A’, including applying the application level data. OSS/BSS 8 10 7 VNFM 1 VNFM 2 Ntw. AA SOL 002 VIM SDC Service A’ 1 9 11 VNF 2 EMs

Service Provider Options for Migrating a Given ETS NS into ONAP with a “Plugged In” VNFM Service Provider Option B 2: OSS/BSS Supports Application Level Configuration Design/Develop Time: 1. The existing NS A descriptor is loaded into ONAP SDC, along with the VNF 1 and VNF 2 descriptors. 2. 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). 3. ONAP SDC translates the NS A descriptor from the onboarding model to the SDC internal Service model (Service A). 4. Distribute VNF 1, VNF 2, and Service A descriptors to ONAP run time catalog. 5. Distribute VNF 1 and VNF 2 descriptors to VNFM. Run Time: 1. OSS/BSS receives request to create an instance of Service A’. OSS/BSS decomposes request into NS A, VNF 1’, VNF 2’. 2. OSS/BSS calls ONAP SOL 005 Adaptor requesting instantiation of NS A. 3. ONAP Adaptor uses SDC model information to translate the SOL 005 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. 4. ONAP makes network assignments for Ntw A. 5. 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 SOL 005 request, or whether wants to have ONAP make these assignments. ) 6. 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 SOL 005 request, or whether wants to have ONAP make these assignments. ) 7. ONAP calls appropriate endpoint to create/configure Ntw A. 8. ONAP calls VNFM 1 via SOL 003 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. 9. VNFM calls VIM to create VNF 1, and applies any needed deployment data via SOL 002 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 10. ONAP calls VNFM 2 via SOL 003 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. 11. VNFM calls VIM to create VNF 2, and applies any needed deployment data via SOL 002 API. At this point VNF 2 only has “deployment data” (networking data) configured. 12. ONAP determines that, as per the SDC model thereof, there is no application level data for ONAP to configure for VNF 1. 13. ONAP determines that, as per the SDC model thereof, there is no application level data for ONAP to configure for VNF 2. 14. 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).

s Backup Slides

“Plugging In” a VNFM Into ONAP: Instantiate VNF SO 2 Decompose SO Internal: VNF Level Workflow SO Loop: Per VF Module Only this single “instantiate VNF” sub-flow shown 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). If necessary Stub VNFM Adaptor 12 9 SOL 003 (Create. Vnf, Instantiate. Vnf, Grant) 7 Assign VF Module Only those major ONAP components associated with this new option are represented. Inventory 8 Instantiate VNF 6 Assign VNF (Instantiate) OOF Request Homing 4 Spawn Resource-Level Sub-Flows Determine Resource needs (including this VNF) VNFM (Doesn’t necessarily care about VF Modules) SDNC 10 11 Deployment Data (SOL 002) VIM 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) 3 SO Internal: Service Level Workflow Resource Data 1 Create Service Instance Determine cloud instance for each VNF Resource (including this one) VNF A&AI Gen NFC Application 15 Data

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