...

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

2.2.2.1 Description 

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.

...

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 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:
      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.)

2.2.2.2 Model

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

2.2.3.1 Description

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.

...

Alternative Text: SO will call the  SOL003 Adapter or Application Controller which will configure that VNF as appropriate.

2.2.3.2 Model

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

2.2.4.1 Description

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.

...

Note that for the "inner" (Network) Service SO orchestrated only the "assign" and "create" functions, and not the (application level) "configure" of the VNFs that comprise the Network Service.  This is because to ONAP the (externally managed) Network Service is an opaque structure, and ONAP is not aware of the individual VNFs that comprise it.  Only the external manager (in this case the NFVO) is aware of the internal structure of the Network Service, the VNFs that comprise it.  If, however, the application level configuration of the Network Service could be accomplished without ONAP needing to be aware of the internal structure of the Network Service (e.g., if the collection of VNFs which comprise the NS can all be collectively configured through a single configuration API endpoint), then it is perhaps possible that ONAP (the Application Controller) could also perform the application layer configuration function.  Of course this would require that the appropriate model information would have been input into SDC, maintaining the proper abstractions.

2.2.4.2 Model

Alternative Option A: Alternative Option A

(Should this be removed??)

3 Option B: information

4 Analysis and comparison

...