Alternative NS-D Option A

Owned by Fernando Oliveira
Jan 17, 2019
9 min read

Assumptions:

  1. ETSI NFV is currently silent about how application level data is managed for a given VNF, but provides elements in the VNF-D which are intended to hold this application level data.  The interface between the NFVO and the VNFM provides mechanisms to pass this data to the VNF. (Figures taken from ETSI GS NFV-MAN 001 V1.1.1, 2014-12). 



  1. The ETSI NFV community took the perspective that there were already well-established systems, precedence and standards around the tools (e.g., BSS/OSS/SM/NM/EM) needed to manage traditional Network Functions (i.e., PNFs), and the need of ETSI NFV was to put standards around that which was new: how to instantiate and managed "Virtualized" Network Functions to the point that they can look to the established systems (SM/NM/EM) indistinguishable from "traditional Network Functions".

  1. Therefore, in the context of Figure B.3.2.2 above, "deployment specific parameters" should be understood as that subset of VNF configuration data that must be applied in the VNF in order to make it an endpoint capable of being managed by the non-ETSI NFV OSS/BSS/SM/NM/EM. 

  2. SInce the VNF-D contains elements that can be used to describe application level data an ETSI Network Function Descriptor (VNF or PNF) can formally capture the management requirements for the "deployment aspects" of that Network Function, as well as the "application aspects".

  3. Certain Service Providers may already have the necessary BSS/OSS/SM/NM/EM systems in place to manage the "application aspects" of an ETSI NS and associated NFs, and look to ONAP only to manage the "deployment aspects" of such a NS and NFs.  Such Service Providers should have the option to have ONAP perform only the equivalent functionality that would be performed by an NFVO/VNFM given that same NSD/NFD collection.  Through the principle of "least astonishment", such a Service Provider would expect to elicit such behavior from ONAP by onboarding the corresponding NDS/NFD collection into SDC without any substantial extensions to that information content needing to be entered into SDC.

  4. However, other Service Providers may not have or want to leverage BSS/OSS/SM/NM/EM systems for this purpose, but rather look to ONAP to manage the "application aspects" of VNFs and Services.  These Service Providers should have this option as ONAP was envisioned to be able to do just this, such as perform application level configuration of VNFs within the context of their Services, and to perform control loop functionality on application level telemetry.  If the provided ETSI Descriptors do not formally contain information as to the application management needs of the NS/NFs, a Service Provider that onboarded such descriptors into SDC would reasonably expect to have to provide substantial additional information content to SDC regarding the "application management aspects" of the "extended" Service and Network Functions. If the the ETSI Descriptor does formally include information as to the application management needs of the NS/NFs, a Service Provider that onboarded such descriptors into SDC would reasonably expect to have SDC accept the information regarding the "application management aspects" of the NS/NFs.

  5. Even in the case that the Service Provider chooses to leverage ONAP's "application configuration" capabilities, that does not mean that no additional configuration of the corresponding NFs will take place "out of band", outside of the purview of ONAP.  For example, after ONAP has completed its application level configuration of the VNF, it may be the case that another system or person would access the VNF to perform additional configuration, e.g., via another system's direct configuration API to the VNF, or via a URL/GUI that the VNF exposes directly as a user portal.  In such a case, ONAP should remain unaware of and unconcerned (in a separation of concerns sense) with whether such configuration should or should not take place, and what specific information should be or has been configured into such VNF.

  6. ONAP should support the ETSI construct of "nested Services", such that one ServiceA is composed of another "inner" ServiceB.  ONAP should support this construct irrespective of whether the Service Provider chose to have ONAP manage the "application aspects" of both the "inner" and "outer" Service, just one of the same, or neither.  This affords the Service Provider with maximum flexibility.

  7. In addition to this, ONAP should support the ability to support Service nesting patterns such that management of an "inner" Service is delegated to an external manager via a southbound interface.  ONAP should support various external manager types, including patterns where the external manager is another ONAP instance (e.g., from a partner Service Provider) or an ETSI NFVO.

  8. In order to maintain separation of concerns in such a delegation pattern, ONAP would view an "inner" nested Service as being opaque, delegating all aspects of internal management to the external manager.  For example, ONAP would understand how to interact with the peer external manager to request an instance of such a delegated "inner" Service, and ONAP would know what input parameters must be supplied to the external manager as part of this request.  However, ONAP should not understand how those input parameters are used by the external manager to configure that "inner" Service.  Certainly ONAP should remain unaware of and unconcerned with whether an additional configuration should or should not take place outside the purview of this external manager, whether by another system's direct configuration API or via a URL/GUI exposed as a user portal.  ONAP's responsibility for instantiation/configuration of such a delegated Service would end with successful handoff to the external manager.

  9. This separation of concerns approach should be such as to allow Service Provider to migrate management of the delegated "inner" nested Service from one external manager type to another, as long as the externally visible aspects of the "inner" nested Service (e.g., the input parameters required to request an instance of such Service) remain unchanged.  E.g., a Service Provider with an ETSI NFVO/VNFM installation may want to migrate management of a NS to ONAP, or vice versa.  To avoid complexity of such migration, our goal should be an architecture such that ONAP interactions across its southbound API with various external managers are adaptable to the various supported external managers. 

  10. In light of the separation of concerns delegation approach described above, and in order to preserve the flexibility to switch between external managers, the interactions between ONAP and such adaptors on its southbound interface should be fundamentally the same irrespective of whether the external manager is an ONAP that is fully responsible for all aspects of application configuration and management of the "inner" Service, an ONAP that is responsible for some aspects of application configuration and management with other aspects being handled "out of band", or an ONAP that is responsible only for managing the "deployment aspects" of the "inner" Service.   The last example being functionally equivalent to an ETSI NFVO/VNFM, it follows that ONAP interactions across its southbound API with an external manager should be fundamentally the same irrespective of whether the external manager is an ONAP or an NFVO.

High Level Proposal

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 may manage both the "deployment aspects" and the "application 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 may manage both the "deployment aspects" and the "application aspects" of that Service.  To limit the amount of manual work involved to so supplement SDC, this proposal recommends that the SDC be able to extract the "application aspects" from the VNF Descriptor 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 #3, 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. 

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

As described above in Assumption #4, 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  SOL003 Adapter/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 #7 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, optionally providing application management aspects"  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.

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:

  4.  

    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:

    4.  

      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.