Page Comparison

...

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 Adapter/Controller, 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

...

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 more information).  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. For each component VNF now homed, the "outer" Service level flow will spawn a VNF level sub-flow to perform the "assign", "create" and "configure" of that VNF as described above.
2. For each component "nested" Service that is managed by ONAP itself (as opposed to an external manager), the "outer" Service level flow will spawn a separate Service level sub-flow to orchestrate that "nested" Service, passing in the appropriate modular structure within the homing solution returned by OOF.  This is a recursive pattern in that processing of this Service level sub-flow is another thread clone of that of the "outer" Service, with the exception that decomposition and homing need not be repeated due to the presence of the homing solution provided.  See Modular Orchestration and Homing of Complex Services and Allotted Resources for more information.
3. For each component "nested" (Network) Service that is managed by an external manager, specifically for our "inner" Service, the "outer" Service level flow will spawn a separate sub-flow that will do the following:
1. SO will call a Controller which will make any needed network assignments for that "inner" Service as an opaque structure.  I.e., the Controller will see only that which is externally visible from the inner Service, such as its external connection points.
2. SO will call the SOL005 Adaptor, passing in the corresponding input data values (i.e., either data values mapped from the input parameters received in the "outer" Service's service instantiation request, or mapped from the output of the Controller network assignments interaction).

...