Abstract Base IM Class for Network Function

We’d like to propose, at the information model level, a NetworkFunctionDesc class which is the base for VnfDesc and PnfDesc in the info model. It captures what is common about PNFs and VNFs (at least in my opinion). I started with the VnfD and removed fields I thought might not apply to PNFs, but I could use review. Clearly, the more the common elements are captured in NetworkFunctionDesc, the better/more accurate.

At the data model level, we would like to propose working towards a model where we do not further subclass Network Function. This permits service providers to construct services which use Network Functions whose capabilities are used to define them. Any concrete Network Function in the resource catalog (be it VNF, PNF, Allotted Network Function) which has those capabilities and meets the criteria of any filtering would be useable as a resolution for the abstract Network Function in the service. The concrete VNFs, PNFs, etc. would derive directly from Network Function and then be further specialized with their capabilities, etc. Of course, a service provider could directly use the concrete network functions in their service definitions, and that’s the likely scenario for a while until there is a defined use case for the abstract resolution. Some service providers already have this use case looming, so it’s not a long ways away.

We should strive to define some base capabilities for common behaviors and socialize them with the standards bodies in an effort to make onboarding simple (i.e, the standards bodies adopt/incorporate them). We might consider modeling extensions to those base capabilities in the same manner as being proposed in the HPA approach, a well defined and governed set of keys that encourages reuse as one vendor catches up to the next, but which continues to expand as one vendor gets ahead of the others.

Class: NetworkFunctionDesc

The NetworkFunctionDesc

Attribute Name	Type			Multiplicity		Description		Applied Stereotypes
descriptorId [called pnfdId for PNFs, vnfdId for VNFs, nsdId for network services, but it always means descriptorId for the particular class it appears in]	Identifier			1		Identifier of this NFD information element. This attribute shall be globally unique. NOTE: The NFD Identifier shall be used as the unique identifier of the NF Package that contains this NFD. Any modification of the content of the NFD or the NF Package shall result in a new NFD Identifier.		support: MANDATORY
provider	String			1		Provider of the NF and of the NFD.		support: MANDATORY
productName	String			1		Name to identify the NF Product. Invariant for the NF Product lifetime.[WCC1]		support: MANDATORY
descriptorInvariantId	String			1		Invariant ID that is shared across all versions of the descriptor		support: Mandatory
softwareVersion	String			1		Software version of the NF. This is changed when there is any change to the software that is included in the NF Package.		support: MANDATORY
descriptorVersion	String			1		Identifies the version of the NFD.		support: MANDATORY
productInfoName	String			0..1		Human readable name for the NF Product. Can change during the NF Product lifetime.		support: MANDATORY <experimental>
productInfoDescription	String			0..1		Human readable description of the NF Product. Can change during the NF Product lifetime.		support: MANDATORY
platformControllerType [was NF_Controller in pnfd proposal]	String			0..N		Identifies the type of ONAP controller for the network function		support: MANDATORY <experimental> valueRange: Should be enums for the ONAP controller (APP-C, SDN-C, etc.) Not saying these are the enums, just they should be and that’s the type of data that should be captured.
localizationLanguage	String			0..N		Information about localization languages of the NF (includes e.g. strings in the NFD). NOTE: This allows to provide one or more localization languages to support selecting a specific localization language at NF instantiation time.		support: MANDATORY <experimental> valueRange: refer to ISO936 https://www.iso.org/iso-639-language-codes.html
defaultLocalizationLanguage	String			0..1		Default localization language that is instantiated if no information about selected localization language is available.		support: MANDATORY <experimental> valueRange: refer to ISO936 https://www.iso.org/iso-639-language-codes.html condition: Shall be present if "localizationLanguage" is present and shall be absent otherwise.
nfExtCpd	ExtCpd [Proposing new base class which might supercede VnfExtCpd. No need to get so specific about virtualization in that class] At info model level, this should be a relationship.			1..N		Describes external interface(s) exposed by this NF enabling connection with a network.		support: MANDATORY
deploymentFlavour	NfDf [Proposing new base class which may supercede VnfDf. The multiplicities in the VnfDf seem to support what would be applicable to a PNF (i.e., 0 lower bound)] At info model level, this should be a relationship.			1..N Could this be 0..N?		Describes specific DF(s) of a NF with specific requirements for capacity and performance.		support: MANDATORY
configurableProperties		NfConfigurableProperties [Proposing new base class which may supercede VnfConfigurableProperties. The multiplicities in the Vnf version for autoscale and autoheal, and the fact that they are Booleans, seem to support what would be applicable to a PNF (i.e., 0 lower bound or false)]	0..1		Describes the configurable properties of the NF (e.g. related to auto scaling and auto healing).		support: MANDATORY <experimental>
modifiableAttributes		NfInfoModifiableAttributes [Proposing new base class which may supercede VnfInfoModifiableAttributes They are generic enough to be applicable to a PNF (i.e., 0 lower bound)]	0..1		Describes the modifiable attributes of the NF. Editor's note: need check the usage of this attribute		support: MANDATORY <experimental>
lifeCycleManagementScript		LifeCycleManagementScript [Might require slight modification of the enums]	0..N		Includes a list of events and corresponding management scripts performed for the NF.		support: MANDATORY <experimental>
elementGroup		NfdElementGroup [Suggest renaming this. While VNFs may have both VDUs and VLs, PNFs would only reference VLs.]	0..N		Describes the associated elements of a NFD for a certain purpose during NF lifecycle management.		support: MANDATORY <experimental>
nfId		Identifier (runtime)			runtime instance id		Support: MANDATORY
nfIndicator		NfIndicator [Suggest renaming this.]	0..N		Declares the NF indicators that are supported by this NF.		support: MANDATORY <experimental>

NF Indicators are information supplied by the NF or the EM to provide some indication on the NF

behaviour. NFM can use these indicators in conjunction with host platform resource data to perform

auto-scaling decisions or to trigger a NF LCM script (e.g., failover). These indicators are applicable at both the NF level (e.g. global indicators) and the deployment flavour level of a certain NFD (e.g. local indicators). In this

release, NF indicators are only declared at the NF level.

Class: PNFDevice <experimental>

This class represents the purpose specific physical hardware platform on which the network function software runs.

Attribute Name	Type	Multiplicity	Description	Applied Stereotypes
nfDescriptorId	Reference to NetworkFunctionDesc descriptorId	1	Reference to the identifier of the NFD information element.	support: MANDATORY
nfDescriptorInvariantId	Reference to NetworkFunctionDesc descriptorInvariantId	1	Reference to the identifier of the NFD information element.	support: MANDATORY
geographicLocationInfo (runtime)	Reference to Complex (need the definition from MultiVIM project)	0..1	Reference to the physical location	support: MANDATORY

A PNF instance would be related 1..1 to a PNFDevice instance.

[WCC1]Should always have been just the invariant id so that the name could change but I'm not going to mess with this name now.