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.