Introduction
Supporting ASD deployment in NSD is required in cloud native service deployment. ETSI NFV SOL001 has NSD defined. This NSD structure could contain one or more VNF node template.
The proposed solution is to use the NSD to support ASD without any NSD standardization impacts. It only requires a sub-set of the existing NSD functionality which is needed for ONAP to define. The ASD support would be provided by an ONAP tailored “NFVO-light” with a sub-set of the NFVO functionality and an integrated ASD application manager component. The ONAP NFVO-light could expose a subset of the ETSI NFV SOL005 as an internal SMO interface. This would be a natural consequence when using the ETSI NFV NSD, rather than inventing a new NBI. However, this “NFVO-light” shall be standardized in ONAP so that vendor provided ASDs + NSDs can be onboarded into ONAP.
NSD referring to ASD
In order to avoid any changes to the NSD standard, the way to refer to a VNF as a VNF node template in the NSD shall be kept the same. This means that the VNF node template shall have an ETSI compliant VNF node type definition, derived from the tosca.nodes.nfv.VNF node type and the NSD will use this node type to refer to the ASD package. Meaning a generic “ASD_in_NS” “asdInNsd” node type is defined derived from the ETSI VNF node type, with default/fixed values for any property not used by the ASD and a number of generic virtual link requirements. The vnf_profile property in the ETSI VNF node type shall be possible to used to define the VNF cardinality in the NSD
The “ASD_in_NS” “asdInNsd” node type definition for the ASD must be included in both the NSD CSAR and the ASD CSAR package as it is referred from both the NSD and ASD yaml.
In the NSD the ASD package will be referred using the VNF node type descriptor_id. An NFVO that supports onboarding of ASD packages would need to have logic to identify the ASD package based on this descriptor_id. It is supported by exposing an ASD-unique descriptor_id as a substitution filter in the ASD TOSCA yaml file.
The NSD shall also support a VNF package invariant id for the ASD package
NSD features that shall be supported for the ASD
- The NSD shall still support to define min/max number of instances within the vnf_profile
- This will be used in order to support flexible deployment of ASD instances
- The existing SOL005 support for Instantiate NS with zero occurrence of some VNF instances and Update NS in order to add VNF instances later can be used for this
- The external virtual link requirement mapping towards NS Virtual Links is required
- The simplification will be to define a fixed set of Virtual Link requirements in the ASD_in_NSD asdInNsd node type definition
- If a fixed set is not seen as sufficient it would also be possible in TOSCA to just define one Virtual Link requirement with occurrence [10, UNBOUNDED]
- Instead of references to cpdIds an implicit reference based on the cpdIds list order will be used, first cpdId using first Virtual Link etc.
- The NSD shall support NSD specific NS additional params
- It could be relevant to define a number of pre-defined NS additional params, e.g. for target cluster name/id
NSD features not used for ASD packages
- The ASD does not have support for multiple deployment flavors, thus the flavor_id would not be needed in the VNF node template
- It is already optional so no changes to the NSD template structure
- It can be constrained/defaulted to “simple” in the ASD_in_NSD asdInNsd
- The ASD does not have support for instantiation levels and scaling, thus the instantiation_level would not be needed in vnf_profile in the VNF node template
- It is already optional so no changes to the NSD template structure
- NSD level deployment flavor, scaling and instantiation level would not be used
- NSD Service Access Points and externally exposed Virtual Link requirements would not be needed.
- The NS Virtual Links created based on the ASD virtual link requirements would connect to transport network VPNs that can provide connectivity both within an NS Virtual Link (for distributed NS deployment) and between NS Virtual Links in different NS:es connected to the same VPN
- Dedicated transport network VPNs for certain NS instances/NS Virtual Links can still be created/managed on Service Orchestration level
- No requirements on Forwarding Graph support
- Support for hierarchical NSDs under discussion in the ongoing Cloud RAN orchestration study
- Hierarchical NSDs could be a solution for deploying only the NS Virtual Links/network resources that are needed for the deployed FUUs
- But the preferred solution is instead to include logic in the ORAN NFVO-light to only deploy NS virtual Links with their network resources if at least one FUU that requires the NS Virtual Link is deployed in the NS
- Will require changes in the SOL005 NS Update operation if an NS Virtual Link shall be added later
- No PNF support, the scope for the NSD is only to manage virtualized deployments
- Sharing of VNF instances between NS instances
- This is recommended to be handled on SO level by sharing of resources in a common NS instance
Note 1: The details of the node type definition for asd and asdInNsd can be found in the following wiki page: TOSCA node types of ASD
Note 2: The details of ASD service template example can be found in the following wiki page: Application Service Descriptor (ASD) Resource Data Model
Note 3: The details of the NSD template example is following:
| Code Block | ||||
|---|---|---|---|---|
| ||||
tosca_definitions_version: tosca_simple_yaml_1_3
imports: nsd_types.yaml
node_types:
tosca.example_NS:
derived_from: tosca.nodes.nfv.NS
properties:
descriptor_id:
type: string
constraints: [ equal: b1bb0ce7-ebca-4fa7-95ed-4840d70a1177 ]
default: b1bb0ce7-ebca-4fa7-95ed-4840d70a1177
designer:
type: string
constraints: [ equal: MyCompany ]
default: MyCompany
name:
type: string
constraints: [ equal: ExampleService ]
default: ExampleService
version:
type: string
constraints: [ equal: '1.0' ]
default: '1.0'
invariant_id:
type: string
constraints: [ equal: 1111b1bb0ce7-ebca-22224fa7-aaaa95ed-bbbb4840d70a8888 ]
default: 1111b1bb0ce7-ebca-22224fa7-aaaa95ed-bbbb4840d70a8888
flavour_id:
type: string
constraints: [ equal: simple ]
default: simple
interfaces:
Nslcm:
type: tosca.interfaces.nfv.Nslcm
operations:
instantiate:
inputs:
additional_parameters:
type: MyCompany.datatypes.nfv.NsInstantiateAdditionalParameters
topology_template:
node_templates:
my_service:
type: tosca.example_NS
properties:
descriptor_id: b1bb0ce7123e4567-ebcae89b-4fa712d3-95eda456-4840d70a1177426614174000
designer designer: MyCompany
name: ExampleService
version: '1.0'
invariant_id: 1111zzze4567-e89b-222212d3-aaaaa456-bbbb426614174uuu
flavour_id: simple
interfaces:
Nslcm:
operations:
instantiate:
implementation: instantiate.workflow.yaml
terminate:
implementation: terminate.workflow.yaml
asd_1:
type: tosca.nodes.asdInNsd
properties:
descriptor_id: fdsa123e4567-e89b-12342222-edxc1111-2ws3426614174000
requirements:
- virtual_links: NsVirtualLink_1
- virtual_links: NsVirtualLink_2
asd_2:
type: tosca.nodes.asdInNsd
properties:
descriptor_id: cabx123e4567-e89b-2w3w3214-e4er0000-2w3e426614174000
requirementsrequirements:
- virtual_links: NsVirtualLink_1
- virtual_links: NsVirtualLink_2
- dependency: asd_1
NsVirtualLink_1:
type: tosca.nodes.nfv.NsVirtualLink
properties:
connectivity_type:
layer_protocols: [ipv4]
flow_pattern: mesh
vl_profile:
max_bitrate_requirements:
root: 1000
min_bitrate_requirements:
root: 1000
NsVirtualLink_2:
type: tosca.nodes.nfv.NsVirtualLink
properties:
connectivity_type:
layer_protocols: [ipv4]
flow_pattern: mesh
vl_profile:
max_bitrate_requirements:
root: 5000
min_bitrate_requirements:
root: 10000
policies:
- ...
|