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",
"memif"

Alternative vNIC configurations the network interface is verified to work with.


interfaceRedundancy

M

0..1

"infraProvided", "activePassiveBond", "activeActiveBond", "activePassiveL3", "activeActiveL3",
 ”bondCni”,
"Left", "Right"

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.
"activeActiveBond": The bonded left/right links must be part of a multi-chassis LAG in active-active mode
"activePassiveBond": Interfaces bonded in active-passive mode in the application with move of bond MAC address. No specific requirements on DC fabric.
"activePassiveL3":  Move of application IP address
"activeActiveL3": Anycast/ECMP
bondCni ; the mated pair network interfaces are used via a 3rd bond cni based network interface.

 

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.


  • No labels

3 Comments

  1. 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? 

    1. 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.   

      1. 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.