This page describes the run time information model of resources for ONAP R2+.
| Anchor | ||||
|---|---|---|---|---|
|
VNF Model (VNF Instance)
Chesla general comment:
1) AAI is not generally the Provider of data. For the most part, AAI stores information provided other components. There are some exceptions (e.g., provStatus is set by other systems but AAI is considered the source of truth for the value). For example, the vnfInstanceId is provided by either SO or SDN-C. So it's not clear to me what is meant by provider and consumer in your table.
...
| attribute name | cardinality | data type | constraint | description | provider | consumer | note | Chesla's Comments | |
|---|---|---|---|---|---|---|---|---|---|
| vnfInstanceId | 1 | identifier of the VNF instance | AAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy | AAI: vnf-id | OK | |||
| vnfInstanceName | 1 | name of the VNF instanceAAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy? | AAI: vnf-name | OK, would make it mandatory just from a usage perspective | ||||
| vnfInstanceAlterName | 0..1 | alternative name of the VNF instanceAAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy? | AAI: vnf-name2 | OK | ||||
| vnfInstanceNamingCode | 0..1 | short code of the VNF instance | AAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy? | AAI: nf-naming-code | This is used by naming policies as a short string which is used to construct the name of the VNF instance. It could be removed if it is in the descriptor. | |||
| vnfProductName | 0..1 | name to identify the VNF Product, invariant for the VNF Product lifetimeAAI | SO, VF-C? | maybe combined with one of the above name attributes relates to ETSI IFA007v231: vnfProductName | Think this should be removed as it should be identifiable by "joining" to the descriptor. | ||||
| description | 0..1 | description of the VNF instance | AAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy? | AAI: nf-function, ETSI IFA007v231: vnfInstanceDescription | At least within AT&T, we were trying to standardize on type/role/function fields to help describe. Is it necessary to rename the function to description? When I see description, I generally think of something quite free form. We thought there could be policy and automation around type/role/function. We were planning to have type/role/function in the descriptor. Is this something in addition? | |||
| vnfProvider | 1 | provider of the VNF modelAAI | SO, VF-C? | ETSI IFA007v231: vnfProvider | Think this should be removed as it should be identifiable by "joining" to the descriptor. | ||||
| vnfdId | 1 | identifier of the VNF modelAAI | SO, VF-C, APP-C, DCAE? | AAI: model-invariant-id, ETSI IFA007v231: vnfdId | This is part of your "join" key to the descriptor. OK | ||||
| vnfdVersion | 1 | version of the VNF model | AAI | SO, VF-C, APP-C, DCAE? | AAI: model-version-id, ETSI IFA007v231: vnfdVersion | If this is a UUID uniquely pointing to the specific version of a model, then OK. Don't want to see, e.g., v1.0, in this field. | |||
| vnfSoftwareVersion | 1 | Software version of the VNF. This is changed when there is any change to the software that is included in the VNF packageAAI | SO, VF-C, APP-C? | ETSI IFA007v231: vnfSoftwareVersion | OK | ||||
| onboardedVnfPkgInfoId | 1 | identifier of the specific VNF package on which the VNF instance is based | AAI | SO, VF-C? | ETSI IFA007v231: onboardedVnfPkgInfoId | Surprised me but not my area of expertise. | |||
| availabilityZone | 1 | availability zone information of the VNF instanceAAI | SO, VF-C, APP-C? | AAI: regional-resource-zone | This should be removed and expressed as a relationship to the availability zone. | ||||
| provStatus | 0..1 | provisioning status, used as a trigger for operational monitoring of this resource by service assurance systems valid value example: PROVISIONED, PREPROVISIONED, CAPPEDAAI | service assurance system | AAI: prov-status | OK, must have enumerated values. | ||||
| operationalStatus | 0..1 | indicator for whether the resource is considered operational. Valid values are in-service-path and out-of-service-path. | AAI | SO, APP-C? | AAI: operational-status | OK, must have enumerated values | |||
| instantiationState | 1 | whether the VNF instance is instantiatedAAI | SO, VF-C? | ETSI IFA007v231: instantiationState | Is this what AAI currently calls orchestration-status? | ||||
| oamIpv4Address | 0..1 | oam ip address, ipv4 | AAI | SO, VF-C, APP-C, DCAE? | AAI: ipv4-oam-address | Would like the whole IM to standardize on naming of IP address field names. | |||
| oamIpv6Address | 0..1 | oam ip address, ipv6AAI | SO, VF-C, APP-C, DCAE? | AAI: management-v6-address | Would like the whole IM to standardize on naming of IP address field names. | ||||
| instantiatedVnfInfo | 0..1 | information specific to an instantiated VNF instance, e.g., vm informationAAI | SO, VF-C, APP-C, DCAE? | ETSI IFA007v231: instantiatedVnfInfo | VM information doesn't belong as an attribute of the VNF. I would expect the VNF would be related to a set of VNFC instances, and each VNFC instance is related to its VM (execution environment) instance. | ||||
| inMaint | 0..1 | whether the VNF instance is in maintenance mode, if yes, DCAE will not observe alarms/traps, etc. | AAI | DCAE | AAI: in-maint | OK | |||
| isClosedLoopDisabled | 0..1 | whether closed loop function is enabledAAI | Policy | AAI: is-closed-loop-disabled | OK | ||||
| encryptedAccessFlag | 0..1 | whether this VNF is accessed using SSH | AAIAAI: encrypted-access-flag | OK | |||||
| vnfConfigurableProperty | 0..1 | indicator for whether autoHeal and autoScale is enabledAAI | VF-C, SO | ETSI IFA007v231: vnfConfigurableProperty | Need more info about the purpose of this. E.g., should there be a configuration object which the VNF is related to? The model-customization-id is used today to link to configuration in ECOMP. This one probably needs discussion with the SO team. |
NOTE: cardinality, producer and consumer column are to be confirmed.
| Anchor | ||||
|---|---|---|---|---|
|
NFC Model (VNFC Instance)
Chesla's General Comments:
...
| attribute name | cardinality | data type | constraint | description | provider | consumer | note | Chesla's Comments | |
|---|---|---|---|---|---|---|---|---|---|
| nfcInstanceId | 1 | identifier of the NFC instanceAAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy | AAI: vnfc-name, ETSI IFA008v231: vnfcInstanceId. | OK - but has there been an info modeling standard on attribute naming? E.g., should this be vnfcInstanceId or nfcInstanceId? | ||||
| nfcNamingCode | 0..1 | short code of the NFC instance | AAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy? | AAI: nfc-naming-code | This is used by naming policies as a short string which is used to construct the name of the VNFC instance. It could be removed if it is in the descriptor. | |||
| description | 0..1 | description of the NFC instanceAAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy? | AAI: nfc-function | Same comments as on VNF, we would like to see type/role/function and perhaps description is in addition. Also, type/role/function can be in the descriptor. | ||||
| vduId | 1 | identifier of the model of the NFC instance | AAI | SO, VF-C, APP-C? | AAI: model-invariant-id, ETSI : vduId | Has the modeling team had the hard discussion regarding what ONAP really wants VDU to mean? Regardless, perhaps this shouldn't be an attribute but instead should be a relationship? | |||
| l3InterfaceIpv4AddressList | 0..N | layer-3 interface addresses, ipv4AAI | SO, VF-C, APP-C, SDN-C? | AAI: l3-interface-ipv4-address-list | This is not an attribute, it is a relationship. See general comments as well. | ||||
| l3InterfaceIpv6AddressList | 0..N | layer-3 interface addresses, ipv6AAI | SO, VF-C, APP-C, SDN-C? | AAI: l3-interface-ipv6-address-list | This is not an attribute, it is a relationship. See general comments as well. | ||||
| vnfcState | 0..1 | operating status of the VM valid value example: STARTED (POWER_ON), STOPPED (POWER_OFF) | AAI | SO?, VF-C | ETSI IFA008v231: vnfcState | Should this be vnfcOperatingState? Should it be operationalStatus (akin to the VNF instance)? Should we standardize on "State" vs. "Status"? | |||
| provStatus | 0..1 | provisioning status, used as a trigger for operational monitoring of this resource by service assurance systems valid value example: PROVISIONED, PREPROVISIONED, CAPPEDAAI | service assurance system | AAI: prov-status | OK | ||||
| inMaint | 0..1 | whether the NFC instance is in maintenance mode, if yes, DCAE will not observe alarms/traps, etc. | AAI | DCAE | AAI: in-maint | OK | |||
| isClosedLoopDisabled | 0..1 | whether closed loop function is enabledAAI | Policy | AAI: is-closed-loop-disabled | OK |
...