Agenda:
- ETSI PNF to ONAP service descriptor translation by Anatoly Katzman
Presented materials:
vCPE with Tosca VNF Test Guide
Recommendations slide presented to the Modeling sub-committee
Onboarded PNF example, ONAP Distributed PNF example
Overview
Content Tools
5 Comments
Michela Bevilacqua
HI, some updates.
The PNF example, "Onboarded PNF example" file, attached above , is the PNF example provided in ETSI SOL001 v2.5.1 but incomplete.It describes a PNF with an external connection point. The updated and complete version is reported below
Two important aspects of the onboarding PNF descriptor to be highlighed:
1) it uses the OASIS TOSCA substitution_mappings metadata (today, Dublin release, the presence of the substitution mappings in the VNF descriptor is not supported as it is possible to see in the onboarded VNF descriptor of the vCPE wiki page link above)
For instance in the onboarded VNF descriptor of the vgw is commented the substitution mapping that exposes the internal CP as external one.
topology_template:
#substitution_mappings:
# node_type: onap.vcpe_vgw
# requirements:
# virtual_link: [ Cp_vgw_public, virtual_link ]
# expose as external CP
# virtual_link: [ Cp_vgw_onap_private, virtual_link ] # expose as external CP
).
The nfv VNFVirtualLink is also commented in the onboarded VNF descriptor
# type: tosca.nodes.nfv.VnfVirtualLink......
2) it uses the nfv node type defined in ETSI to model the PNF external connection points: tosca.nodes.nfv.PnfExtCp. The PnfExtCp in ETSI it is NOT an internal CP as in the VNF. If the substitution mapping is not preserved, it will be lost the relation between the PNF and the PnfExtCp.
--
The reccomended mapping will not allow to properly translate the onboarded information in the above example. The onboarded substitution mapping metadata cannot be preserved from the onboarding descriptor to the internal descriptor today as this mechanism is already proposed to be used to translate the tosca.nodes.nfv.PNF into org.openecomp.resource.abstract.nodes.PNF.
---
The second file is a proposal for an internal descriptor definition that is relative to a different PNF example.
We started to create a PNF resource by the SDC composition mechanism without any package onboarding.
The PNF descriptor created by default by SDC is defined as follows. The CP is of type openecomp.resource.cp.v2.extCP and a substitution mapping is used to model the pnf named Zupnf2.
node_templates:
MyExtCp-1:
type: org.openecomp.resource.cp.v2.extCP
metadata:
invariantUUID: 7e82db71-1799-4b64-a029-4816a29741d3
UUID: 6c84604c-21ed-4369-9948-1cd7f01f6201
customizationUUID: 9f8729c7-5902-4e5e-8be0-54cadfcc894
version: '1.0'
name: ExtCP2
description: The AT&T Connection Point base type all other CP derive from
type: CP
category: Generic
subcategory: Network Elements
resourceVendor: ONAP (Tosca)
resourceVendorRelease: 1.0.0.wd03
resourceVendorModelNumber: ''
properties:
subinterface_indicator: false
mac_requirements:
mac_count_required:
is_required: false
exCP_naming:
ecomp_generated_naming: true
is_default: false
capabilities:
network.incoming.packets.rate:
properties:
unit: packet/s
description: Average rate of incoming packets
type: Gauge
category: network
network.outgoing.bytes:
properties:
unit: B
description: Number of outgoing bytes
type: Cumulative
category: network
network.outgoing.packets.rate:
properties:
unit: packet/s
description: Average rate of outgoing packets
type: Gauge
category: network
network.outpoing.packets:
properties:
unit: packet
description: Number of outgoing packets
type: Cumulative
category: network
network.incoming.bytes.rate:
properties:
unit: B/s
description: Average rate of incoming bytes
type: Gauge
category: network
network.incoming.bytes:
properties:
unit: B
description: Number of incoming bytes
type: Cumulative
category: network
network.outgoing.bytes.rate:
properties:
unit: B/s
description: Average rate of outgoing bytes
type: Gauge
category: network
network.incoming.packets:
properties:
unit: packet
description: Number of incoming packets
type: Cumulative
category: network
substitution_mappings: node_type: org.openecomp.resource.pnf.Zupnf2
The second attached file above "ONAP distributed PNF example" is a modified proposal of a PNF descriptor generated by SDC when a onboarding PNF is progressed. The main difference between the two descriptors (the one above and the proposal in the "ONAP distributed PNF example file) is the node type used to describe the PNF external connection point.
At this point there is no indication of impacts on SO and other RT component to support the new proposal in particular for 5G UC, PnP UC.
Michela
Anatoly Katzman
>>> today, Dublin release, the presence of the substitution mappings in the VNF descriptor is not supported >>>
You are right, the TOSCA onboarding logic should fully support substitution mappings, and it currently doesn't. But this lack of support is not a result of a deliberate modeling decision. It was caused by a hasty Dublin implementation, and it has to be fixed. However fixes of this kind are not in the scope of the modeling committee, they should be taken to the relevant development teams which are responsible for the TOSCA onboarding implementation.
Anatoly Katzman
>>> If the substitution mapping is not preserved, it will be lost the relation between the PNF and the PnfExtCp. >>>
>>> The reccomended mapping will not allow to properly translate the onboarded information in the above example >>>
What exactly will be lost? The translation will keep ALL internal nodes AS-IS, along with their original types, assigned values and interconnections. All capabilities and requirements responsible for external connectivity of the PNF, will be exposed through substitution mapping, with all their original types and property values.
What am I missing?
Anatoly Katzman
I am going to upload an updated example of a translated PNF, will update this comment with the link when ready
Anatoly Katzman
Michela Bevilacqua , done. The updated example is here.
Changes: the "internal pnf" node is also preserved now inside the PNF topology, with all its ETSI properties with the vendor-provided values.