In ONAP today, ETSI NFV based solution with container support is based on existing ETSI NFV IFA011/SOL001 VNFD concept. (https://wiki.onap.org/display/DW/ETSI+NFV+SOL001+v4.2.1+based+proposal).
The suggested ASD proposal also provides a descriptor approach for supporting containers.
When reviewing the ASD proposal, there are lots of attributes as described in ASD are identical or similar to the VNFD as defined in ETSI NFV standard. Please see the below tables.
Re-use the output from other SDOs and build a new approach which is fine, but considering the different IPR/copyright policies among different organizations, corresponding reference for each related attribute should be added.
Since the new wiki page for supporting SOL001 v4.3.1 is added (https://wiki.onap.org/pages/viewpage.action?pageId=117747423) , and SOL001 v4.3.1 is still under development in ETSI NFV, also considering the similarity of ASD and VNFD, the alignment work between the 2 models should be taken into account.
Application Service Descriptor (ASD) Information Element (top level)
Attribute | Qualifier | # | Type | Description | Comments |
asdId | M | 1 | Identifier | Identifier of this ASD information element. This attribute shall be globally unique. The format will be defined in the data model specification phase. | Identical to vnfdId in ETSI NFV IFA011 |
asdVersion | M | 1 | String | Identifies the version of the ASD | Identical to vnfdVersion in ETSI NFV IFA011 |
asdSchemaVersion | M | 1 | Version | Specifies the version of the ASD’s schema (if we modify an ASD field definition, add/remove field definitions, etc.). | |
asdProvider | M | 1 | String | Provider of the AS and of the ASD. | Identical to vnfProvider in ETSI NFV IFA011 |
asdApplicationName | M | 1 | String | Name to identify the Application Service. Invariant for the AS lifetime. | Identical to vnfProductName in ETSI NFV IFA011 |
asdApplicationVersion | M | 1 | Version | Specifies the version of the Application (so, if software, DeploymentArtifacts , ASD values, ... change, this changes). | Identical to vnfSoftwareVersion in ETSI NFV IFA011 |
asdApplicationInfoName | M | 0..1 | String | Human readable name for the Application service. Can change during the AS lifetime. | Identical to vnfProductInfoName in ETSI NFV IFA011 |
asdInfoDescription | M | 0..1 | String | Human readable description of the AS. Can change during the AS lifetime. | Identical to vnfProductInfoDescription in ETSI NFV IFA011 |
asdExtCpd | M | 0..N | datatype.ExtCpd | Describes the externally exposed connection points of the application. | Similar to vnfExtCpd in ETSI NFV IFA011 |
enhancedClusterCapabilities | M | 0..1 | datatype. enhancedClusterCapabilities | A list of expected capabilities of the target Kubernetes cluster to aid placement of the application service on a suitable cluster. | |
deploymentItems | M | 1..N | DeploymentItem | Deployment artifacts | Similar to mciopId and mciopProfile in ETSI NFV IFA011 |
Deployment Item Information Element
Attribute | Qualifier | # | Content | Description | Comments |
deploymentItemId | M | 1 | Identifier | The identifier of this deployment item | Identical to mciopId in ETSI NFV IFA011 |
artifactType | M | 1 | String | Specifies the artifact type. One of following values can be chosen: "helm_chart", "helmfile", "crd", "terraform" | |
artifactId | M | 1 | String | Reference to a DeploymentArtifact. It can refer to URI or file path. | |
deploymentOrder | M | 0..1 | Integer | Specifies the deployment stage that the DeploymentArtifact belongs to. A lower value specifies that the DeploymentArtifact belongs to an earlier deployment stage, i.e. needs to be installed prior to DeploymentArtifact with higher deploymentOrder values. If not specified, the deployment of the DeploymentArtifact can be done in arbitrary order and decided by the orchestrator. | Identical to deploymentOrder in ETSI NFV IFA011 |
lifecycleParameters | M | 0..N | String | The list of parameters that can be overridden at deployment time (e.g., the list of parameters in the values.yaml which can be overridden at deployment time) |
|
networkInterfaceRealizationRequirements Information Element
Attribute | Qualifier | Cardinality | Content | Description | comments |
trunkMode | M | 0..1 | ”false” | ”true” | If not present or set to”false”, means that this interface shall connect to single network. If set to ”true” then the network interface shall be a trunk interface (connects to multiple VLANS). | Identical to trunkMode in ETSI NFV IFA011 |
ipam | M | 0..1 | "infraProvided", "orchestrated", "userManaged" | The default value ("infraProvided") means that the CNI specifies how IPAM is done and assigns the IP address to the pod interface. | Similar to iPAddressAssignment in ETSI NFV IFA011 |
interfaceType | M | 0..1 | "kernel.netdev", "direct.userdriver", "direct.kerneldriver", "direct.bond", "userspace | This attribute is applicable for passthrough and memif interfaces. Value default value is ”kernel.netdev”. | Similar to vnicType in ETSI NFV IFA011 |
interfaceOptions | M | 0..N | "virtio", | Alternative vNIC configurations the network interface is verified to work with. | |
interfaceRedundancy | M | 0..1 | "infraProvided", "activePassiveBond", "activeActiveBond", "activePassiveL3", "activeActiveL3", | ”infraProvided” means that the application sees one vNIC but that the infrastruture provides redundant access to the network via both switch planes. ”Left” and ”right” indicates a vNIC connected non-redundantly to the network via one specific (left or right) switchplane. All other attributes indicates a mated vNIC pair in the Pod, one connecting to the network via left switchplane and the other connecting to the network via the right switchplane, and with application using them together as a redundant network interface using a particular redundancy method that need to be accomodated in the node infrastructure. |
|
nicOptions | M | 0..N | "examples": ["i710", "mlx-cx5v"] | nics a direct user space driver the application is verified to work with. Allowed values from ETSI registry. |
3 Comments
Zu Qiang (Ericsson)
shitao li Thanks for your comments. However, it is not clear why this comparing between two different information model is needed. Can you clarify it?
shitao li
There are lots of attributes as described in ASD are identical or similar to the VNFD as defined in ETSI NFV standard. I donot think there are totaly different information mode. ASD is more like a subset of VNFD model.
In addition, I see the ASD proposal also plans to reuse the SOL004 and NSD (SOL001) standard to fit other requirements, such as VNF on-boarding, then it is more straightforward to make ASD proposal aligning with the VNFD spec.
Zu Qiang (Ericsson)
In ONAP, we define the cloud native CNF information model. It is not a problem if ETSI NFV would like to adopt ONAP cloud native CNF information model.
ASD Information model defines the requirements on how to define a cloud native CNF LCM. Mixing the CNF modelling requirements with VNF / PNF modelling requirements is not a good idea and it doesn't bring us any benefits. Once the CNF model requirements are clear for everyone, we need to work on the implementation which is the CNF data model. For the CNF data model, we could reuse any data structures which are supported in implementation. I do see benefits by reusing current implementation in CNF data model. We can discuss the details when ASD DM discussion is coming.
If you have an alternative CNF IM solution, please follow the ONAP procedure to submit your REQ ticket and contribute the code to prove it. The output of ONAP is not documentation, it is coding. Just by comparing the attributer name to stop ONAP moving forward is not appreciated.