...

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 (SO VNFM Adapter).)

2.2.2.2 Model

2.2.2.3 Implications/Impacts

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: As described above in Assumption #5, this ONAP management pattern assumes that the Service Provider has onboarded the associated ETSI NSD/VNFDs into SDC, including the "application management aspects" of the Network Service and VNFs, either from the information in the VNF-D, 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.

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.3.3 Implications/Impacts

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.

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

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

...

There is no need for a separate object type in the ONAP internal model to capture the "Network Service", but rather the ONAP "Service" construct can be used to capture all ONAP Services.  In this scenario it would so happen that the metadata relating to the specific Service described above would contain no metadata pertaining to application management.  ONAP would interpret this lack of application management metadata as instructions that there is no application data management for ONAP to perform for this specific Service type.

2.2.2.3 Implications/Impacts

Having an ONAP Service type whose metadata contains no application management requirements for ONAP to perform causes no problems.  In fact, this is a common pattern in the current state of the ONAP art.

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: As described above in Assumption #5, this ONAP management pattern assumes that the Service Provider has onboarded the associated ETSI NSD/VNFDs into SDC, including the "application management aspects" of the Network Service and VNFs, either from the information in the VNF-D, 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.

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

2.2.3.2 Model

There is no need for a separate object type in the ONAP internal model to capture the "Network Service", but rather the ONAP "Service" construct can be used to capture all ONAP Services.  In this scenario it would so happen that the metadata relating to the specific Service described above does contain metadata pertaining to application management.  ONAP would perform the required application management functionality as described in that metadata.  Specifically:

• SO would note the presence of application configuration data in the metadata, and interpret this as a requirement to call the appropriate Application Controller after the "Create" of the VNF.
• Application Controller would use the application configuration metadata to:
  • Determine what application data parameters to be configured for this VNF type in the context of the Service in question
  • Determine the appropriate instance values to set for each such  application data parameter.   Application Controller would use the data sourcing and mapping rules (perhaps generic, or perhaps via custom microservices embedded in the distributed Service TOSCA itself) provided in the metadata to derive each such instance value.
  • Determine the southbound API to call to set each such value, and call said API.  Note that this southbound API could be a NetConf, Ansible, Chef, or other API, some of which may require special adaptors.
  • Alternative Text: Determine the southbound API to call to set each such value, and call said API.  Note that this southbound API could be a NetConf, Ansible, Chef, SOL003, or other API.  Some such APIs may require their own adaptors; for example, the Application Controller itself would not call the SOL003 API to the VNFM, but rather would call the VNFM Adaptor with the appropriate application level data parameter values.  The VNFM Adaptor would map these into the appropriate SOL003 API calls. 

2.2.3.3 Implications/Impacts

In all cases whereby ONAP SDC onboards a SOL001 NSD, SDC should preserve that original NSD as an attachment to the ONAP Service as a reference document.

Having an ONAP Service type whose metadata contains application management requirements for ONAP to perform causes no problems as this is the agreed upon target.

Alternative Text:  Having an ONAP Service type whose metadata contains application management requirements for ONAP to perform causes no problems as this is the agreed upon target.  If a VNFM is to be used in the application level configuration of the VNF, then the VNFM would have received the application level configuration data as part of the VNFD distribution to the VNFM.

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.

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

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

There would need to be something in the ONAP internal model that captures the fact that a particular Service is "externally managed", and we may find it useful to define a new object type in the ONAP internal model to represent such an "externally managed" Service.  .  But because there will likely be numerous targets for such "externally managed" Services (e.g., another ONAP instance, an ETSI NFVO, an "as a Service" external provider, etc.), we should not consider having a different object type for each such target.  Rather, a single normalized "externally managed Service" object that relies on Adaptors per external manager target to adapt from the normalized ONAP internal model to the model exposed by the external API of that target manager.  Thus, from the ONAP internal model perspective, an externally managed Service managed by an NFVO via a SOL005 API would look like just another "externally managed Service", though in this specific instance it so happens that the target manager is hidden behind a "SOL005 Adaptor". 

2.2.4.3 Implications/Impacts 

In all cases whereby ONAP SDC onboards a SOL001 NSD, SDC should preserve that original NSD as an attachment to the ONAP Service as a reference document.  If that ONAP Service is considered an "externally managed Service" then the set of additional data to be populated by the Service Designer would be different than that of an ONAP Service that is managed by ONAP itself.  This fact could justify that such an externally managed Service be represented as a new "type" in ONAP. 

The Service designer would need to indicate in the externally managed Service metadata what "target manager type" will manage this Service.  This information would be used for ONAP to determine the appropriate Adaptor type that should be used for this externally managed Service.  ONAP would distribute the associated ONAP internal metadata model for that Service to all instance(s) of that Adaptor type.  By doing so the SOL005 Adaptor would gain access to the original SOL001 NSD.

The Service Designer would need to also ensure the presence in the model of the information that ONAP OOF requires for "homing" such an externally managed Service, such homing perhaps being used to determine which target manager instance ONAP should call and the data to be passed in the calling.  This would allow ONAP runtime to determine the specific Adaptor instance to which to communicate.

3 Option B: Explict NSD representation

...