Resource IM (Design time) OPTION 1:
Name | Required | Cardinality | Content | Description |
descriptor_id | M | 1 | string | Identifier of this PNFD information element. It uniquely identifies the PNFD. The format will be defined in the data model specification phase. |
function_description | M | 1 | string | Describes the PNF function. |
Provider | M | 1 | string | Identifies the provider of the PNFD. |
version | M | 1 | Version | Identifies the version of the PNFD. |
descriptor_invariant_id | M | 1 | string | Identifier of this PNFD in a version independent manner. This attribute is invariant across versions of PNFD. |
Name | M | 1 | string | Name to identify the PNFD. |
geographical_location_info | M | 0…1 | Not specified | It provides information about the geographical location (e.g. geographic coordinates or address of the building, etc.) of the PNF. |
| software_version_list | M | 1 | Not specified | Describes the software the PNF supported |
Resource IM (Design time) OPTION 2?
Name | Required | Cardinality | Content | Description |
descriptor_id | M | 1 | string | Identifier of this PNFD information element. It uniquely identifies the PNFD. The format will be defined in the data model specification phase. |
pnfId | O | 1 | Not specified | Identifier of this Pnfinformation element. CORRELATIONID (A&AI) |
function_description | M | 1 | string | Describes the PNF function. |
Provider | M | 1 | string | Identifies the provider of the PNFD. |
version | M | 1 | Version | Identifies the version of the PNFD. |
descriptor_invariant_id | M | 1 | string | Identifier of this PNFD in a version independent manner. This attribute is invariant across versions of PNFD. |
Name | M | 1 | string | Name to identify the PNFD. |
geographical_location_info | M | 0…1 | Not specified | It provides information about the geographical location (e.g. geographic coordinates or address of the building, etc.) of the PNF. |
NF_Controller | O | 0…1 | Not specified | Controller for PNF (APP-C, SDN-R, SDN-C, VF-C) |
software_version_list | M | 1 | Not specified | Describes the software the PNF supported |
12 Comments
Chesla Wechsler
I would like to see a NetworkFunction descriptor super class at the info model level from which the VNF descriptor and PNF descriptor derive.
At the data model level, I would like to see NetworkFunction NOT be further subclassed but instead that we investigate whether, in Casablanca, we could possibly introduce a PNFDevice type on which NetworkFunction can optionally depend. Such a NetworkFunction with that dependency would be a PNF without having to further subclass it.
Min Sang Yoon
In the first page description, 'Beijing implemented the first phase of PNF discovery and instantiation' means Beijing release support PNF instantiation in run-time or only in design time?
Chesla Wechsler
Would someone knowledgeable please explain to me the following:
1) what is meant by the software_version_list field? How is it used?
2) how PNFD's NF_Controller field is similar or different from the VNFD's vnfmInfo field?
THanks.
Chesla Wechsler
I added an input here with a proposal for a NetworkFunctionDesc base class for the Info Model (only) level. The VnfD and PnfD Info Model classes could extend this.
Abstract Base IM Class for Network Function
Michela Bevilacqua
I have concerns about the use of a software version list in the PNFD from a modelling prospective.
As we know, a PNFD is defining a PNF type not a PNF instance. It could be reasonable to suppose that a vendor could also require to define new artifacts providing a new sw version of a PNF type. For these reason a new package should be provided with a new PNFD when the vendor provides a new sw version.
I do not expect an ONAP operator knows at PNF instantiation time all the future sw version releases to fill in a list of sw versions for a PNF type as well as I do not expect too to update the sw version list of a PNFD after the instantiation of PNF instances to avoid useless complication in the management of potential multiple versions of the same artifact.
Moreover, the focus is now on the sw version but we should not preclude that a new PNF type sw version could also require to update other fields/attributes/capabilities of a PNFD too.
There is a certain level of similarities when we think to the ETSI VNF sw upgrade in terms of artifacts and package and the list of the sw version is not the approach considered there.
I understand Casablanca still do not support the onboarding PNFD provided by the vendor but we should deeply analyze the consequences that a sw version list can have in the PNFD.
Li Xiang
Hi Michela, thanks for your comments, I try to answer your questions as below in-line, and any communication are welcome.
As we know, a PNFD is defining a PNF type not a PNF instance. It could be reasonable to suppose that a vendor could also require to define new artifacts providing a new sw version of a PNF type. For these reason a new package should be provided with a new PNFD when the vendor provides a new sw version.
[lx] Here, the purpose of the SW list is to describe the different SWs the PNF supported. Like the multi-RAT scenario, a specific PNF hardware could support multiple radio functions, which could be implemented with different SWs, meanwhile the specific SW could be assigned at the stage of an operator designs the network. And through the PNF SWs showed in PNFD, operators could also select the specific SW to deploy to the PNF.
I do not expect an ONAP operator knows at PNF instantiation time all the future sw version releases to fill in a list of sw versions for a PNF type as well as I do not expect too to update the sw version list of a PNFD after the instantiation of PNF instances to avoid useless complication in the management of potential multiple versions of the same artifact.
Moreover, the focus is now on the sw version but we should not preclude that a new PNF type sw version could also require to update other fields/attributes/capabilities of a PNFD too.
[lx] If a new version has been published, the PNFD could be updated to align the new version, but to be honest I am not sure if the PNFD updating operations will impact the PNF instances which associated to the PNFD. In my point of view, I see the PNFD like Class, and PNF are objects which “instanced” from the PNFD, if PNFs from a same vendor ” instanced” with this vendor’s PNFD, the amount of PNFs would have similar capability, e.g. these PNFs support a specific software version, and so on.
And I agreed with you, some other attributes may be affected.
There is a certain level of similarities when we think to the ETSI VNF sw upgrade in terms of artifacts and package and the list of the sw version is not the approach considered there.
[lx] In design time, I prefer to see that ONAP user could orchestrate a network in demand, and lots of useful information could gain from VNFD and PNFD, which means do not depend on other management entities.
I understand Casablanca still do not support the onboarding PNFD provided by the vendor but we should deeply analyze the consequences that a sw version list can have in the PNFD.
Michela Bevilacqua
I have concerns about the introduction of the NF_controller in the PNFD. The NF_controller should not be part of the onboarding PNFD from the vendor. It is a ONAP specific need only. It can be managed in different ways. IN R3, we have spoken of a static behaviour provided by a lookup table but in the long run some proposals have been already considered as the possibility to provide a policy rule. I do not recoomend therefore to add it in the PNFD
Li Xiang
[lx] In my personal view, implement the ONAP Controller selection as a model-driven way is reasonable, the vendor knows the controller of their VNF/PNF.
Jacqueline Beaulac
Wouldn't this bind the value in the PNFD to the architecture of the current ONAP release? Changes will probably be made in coming releases regarding what controllers are available and their division of responsibilities. Vendors will then need to update their PNFDs in consequence for already released PNF versions.
Li Xiang
Hi, Jacqueline Beaulac, sorry for replying you so late. I think you are right, if there is any changing of the ONAP Controllers, e.g. the name of the controller, it will impact the PNFD. This topic also under discussed in 5G UC.
Michela Bevilacqua
PNFID is specific for PNF instance. In Casablanca release, we are assuming that the PNF serial number will be used. It is not expected to be part of the PNFD.
Li Xiang
[lx] if we interpreted the PNF ID as a runtime attribute, it should not be added in PNFD.