...
- 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.
- Thus, an ETSI Network Function Descriptor (VNF or PNF) would be expected to formally capture only those management requirements for the "deployment aspects" of that Network Function, and not the "application aspects".
- Similarly, an ETSI Network Service Descriptor would be expected to formally capture only those management requirements for the "deployment aspects" of that Network Service, and not the "application management aspects".
- 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.
- 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. However, because the ETSI Descriptors as currently defined would not be expected to 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.
- 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.
- 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.
- 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.
- 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 whether how those input parameters are considered by the external
- In the case whereby ONAP delegates an "inner" Service to an NFVO,
High Level Proposal
- 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.
- 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.
- 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 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 Processing for an Onboarded Network Service
ONAP management hereof The onboarded ETSI NSD should be represented in ONAP via an existing ONAP object, ONAP object which would obtain for the Service Provider the desired runtime behavior in orchestrating the instantiation of that NS. My understanding is that the Service Provider, for an NS, would want ONAP to decompose the NS into its component VNFs, home each of those VNFs to the proper cloud instance, and then orchestrate the instantiation of those VNFs in the proper sequence based on the relationships between the VNFs that appear in that NS’s topology template.
...