...

This option proposes to preserve the flexibility described in the Assumptions section by having ONAP SDC, when onboarding an ETSI VNF Descriptor, automatically capture the content thereof in an ONAP VNF model that assumes that ONAP will manage only the "deployment aspects" of that VNF.  Similarly, when onboarding an ETSI NS Descriptor, ONAP SDC would capture the content thereof in an ONAP Service model that assumes that ONAP will manage only the "deployment aspects" of that Service.  If the Service Provider intends that ONAP manage the application aspects of such a VNF/Service as well, the Service Provider would be expected to provide supplemental information into SDC that captures the "application management aspects" of the "extended" Service and Network Functions.  To limit the amount of manual work involved to so supplement SDC, this proposal recommends that the ONAP community define a method through which the VNF vendor itself would capture the "application management aspects" of their VNF, and provide that to SDC as an attachment to the SOL004 package at onboarding time.

ONAP Runtime Processing for an Onboarded Network Service Whereby ONAP Manages Only the "Deployment Aspects" of that Service

...

One benefit of mapping an onboarded ETSI NS to the internal representation of an ONAP Service is that the ETSI NS can access the standard ONAP runtime functionality implemented or planned for support of ONAP Services.  This benefit will be presented in this section.

As described above in Assumption #4, this ONAP management pattern assumes that the Service Provider has onboarded the associated ETSI NSD/VNFDs into SDC without any substantial extensions to that information content being needed.   However, this scenario assumes that the Service Provider does want to leverage that ONAP functionality that is relevant to Network Services per se, but outside of the formally specified scope of ETSI NFV for both NFVO and VNFM.  I.e., the ability to perform "homing" on VNFs and to automatically make "network assignments". 

Specifically, for a "simple" (un-nested) Service, upon receipt of a service instantiation request:

1. SO will decompose the Service (i.e., the translated NS) into its component VNFs which must be instantiated
2. SO will call OOF, which will perform "homing" to determine cloud instance locations for each such VNF to be instantiated
3. SO will perform the following steps for each VNF, performing cross-VNF orchestration in the proper sequence based on the relationships between the VNFs

...

1. in that

...

...

1. Service's/NS's topology template: 
   1. SO will call a Controller which will make any needed network assignments for that VNF
   2. SO can either:
      1. Call Multi-VIM to request instantiation of that VNF, passing in the corresponding "deployment data" values (i.e., either data values mapped from the input parameters received in the service instantiation request, or mapped from the output of the Controller network assignments interaction), or
      2. Call the SOL003 Adaptor, passing in the corresponding "deployment data" values, and requesting the subtending VNFM to instantiate that VNF.  (For details of this approach see ONAP – ETSI Alignment Proposals in Support of VNF Scaling and SO Plug-in Support for VNFM.)

ONAP Runtime Processing for an Onboarded Network Service Whereby ONAP Also Manages the "Application Aspects" of that Service

As described above in Assumption #5, this ONAP management pattern assumes that the Service Provider has onboarded the associated ETSI NSD/VNFDs into SDC, and then provided supplemental information into SDC that captures the "application management aspects" of the "extended" Service and VNFs, either manually via the SDC GUI or by uploading a document in the SOL004 package that captures this information in a formal manner.

This runtime pattern is the same as that specified in the above, with the following added step after SO having called either Multi-VIM or the SOL003 Adaptor:

c. SO will call the Application Controller which will configure that VNF as appropriate.

ONAP Runtime Processing for an Onboarded and "Nested" Network Service the Management of Which is Delegated to an NFVO as an External Manager

As described in Assumption #8 and other associated assumptions above, one can intuit that this ONAP management pattern would assume that the Service Provider has onboarded the NSD and associated VNFDs into SDC without providing any supplemental information into SDC.

Next the Service Provider has defined another ONAP Service in SDC (i.e., an "outer Service") and included the formerly described Service as a component therein as an "inner Service".  Presumably the "outer Service" would also include other components, either VNFs or other (also "inner") nested Services with which we are not interested.

If it is desired that ONAP provide "homing" and "assignments" functionality for the "inner Service" in the context of this "outer Service", then the Service Provider would capture the corresponding information and policies in SDC as well.

Of course, it will also be necessary to load the original NSD and associated VNFDs into the NFVO, with ONAP's involvement in so doing TBD.

Upon receipt of a service instantiation request for this "outer" Service:

1. SO will decompose the "outer" Service into its component VNFs and nested Services (including our "inner Service") which must be instantiated
2. SO will call OOF, which will perform "homing" to determine cloud instance locations for each such VNF to be instantiated.  For a nested Service that is managed by ONAP itself (i.e., not delegated to an external manager), OOF could be responsible performing homing on the VNFs comprising that nested service in a recursive manner (see Modular Orchestration and Homing of Complex Services and Allotted Resources ).  For a nested Service that is managed by an external manager (as is our "inner Service") and hence "opaque" to ONAP, OOF would likely be responsible only for determining the desired location of the "Service Access Point" for that delegated Service.
3. SO will perform the following steps for each VNF and nested Service, performing cross-VNF/nested Service orchestration in the proper sequence based on the relationships between the VNFs/nested Services in that ("outer") Service's topology template: 

1. SO processing continues, For each component VNF now homed, SO will orchestrate in the proper sequence as described above.
2. For each component  
   1. SO will call a Controller which will make any needed network assignments for that VNF
   2. SO can either:

1. SO will decompose the "outer" Service (i.e., the translated NS) into its component VNFs which must be instantiated
2. SO will call OOF, which will perform "homing" to determine cloud instance locations for each such VNF to be instantiated
3. For each such VNF, SO will orchestrate the following in the proper sequence based on the relationships between the VNFs in that Service's/NS's topology template: 
   1. SO will call a Controller which will make any needed network assignments for that VNF
   2. SO can either:

Option B: information

References

...