As discussed in the WP6 call on Fri. 27th April 2018, it would be a nice benefit if the 5GTANGO SP could support EPA capabilities.

George is going to provide more details about requirements for the platform etc. For our descriptors, this means that we need some additional fields to express the EPA configuration of a VNF.

I suggested to have a look at the OSM information model, because OSM already has EPA support, and I believe that it is a good idea to be more or less compatible to them.

There is an example VNF package from OSM's hackfest that has EPA enabled: https://osm-download.etsi.org/ftp/osm-3.0-three/2nd-hackfest/packages/hackfest_4_vnfd.tar.gz

The corresponding section in the VNFD is placed in the VDU section an named guest-epa:

vdu:
        -   id: mgmtVM
            name: mgmtVM
            image: hackfest3-mgmt
            count: '1'
            vm-flavor:
                vcpu-count: '1'
                memory-mb: '1024'
                storage-gb: '10'
            guest-epa:
                cpu-pinning-policy: DEDICATED
                cpu-thread-pinning-policy: PREFER
                mempage-size: LARGE
                numa-node-policy:
                    mem-policy: STRICT
                    node-cnt: '1'
                    node:
                    -   id: '1'

The corresponding definition in OSM's information model can be found here.

I suggest the following action to add EPA support to our descriptors:

• investigate OSM (and other, e.g., TOSCA, ETSI, OpenStack EPA APIs) information models to see what is needed
• make a list of EPA-related fields that we want to have (as a comment to this issue)
• agree on those EPA fields
• add the EPA fields to our VND schemas

Note: Even if our current platform does not support all EPA functionalities, it is still valuable that our descriptors support as many as possible.

If we adjust the schemas and have different versions, it should somehow be clear to which schema version a descriptor belongs. If only minor changes were made, it's fine to use older schema versions.
If no schema version is specified, just use the latest schema.

Also the descriptor generator should generate and validate based on schemas of a specific version.

Physical Network Functions
Cloud Native Network Functions (Kubernets)
(optional) Hybrid Network Functions

Implemented through PDUs and CNDUs (see mail thread):

• xNFD has VDU(s) ==> VNF
• xNFD has PDU(s) ==> PNF
• xNFD has CNDU(s) ==> CNNF
• xNFD has VDU(s), PDUs, CNDUs ==> HNF (not saying that we should try to deploy something this complicated :-D but the concept makes sense and we can easily built it into the schemas)

Final design to be made in Detmold F2F. Done.

TODOs

• Create wiki page with an example for a PNF to collect inputs about the field/parameters needed in a PDU (similar to the CNF example) -> maybe links are enough?
• Allow CNF and PNF objects in vnfd-schema, ensure that at least one of them is always there
• Create example PNF in tng-schema
• Create example CNF in tng-schema
• Create example HNF in tng-schema
• Finalize CNDU schema
• Finalize PNF schema
• update release notes for 4.1

Allow tagging of NSDs for easier selection when tested by the V&V. Should simply be an optional testing_tags field in the NS schema.
See user story: https://git.cs.upb.de/5gtango/UserStories/issues/63

We need this for the communication pilot.
It seems parts of this is already implemented, so at least do a cross check.

Something like:

properties:  # (arbitrary key/value list for each link)
   qos:
     latency: value 
     bw: value

See https://git.cs.upb.de/5gtango/UserStories/issues/176#vnfdnsd-adaption-to-include-soft-constraints

bandwidth_units definition is missing in nsd-schema.yml and the validation is failing when bandwidth QoS contraints are added in the NS descriptor. In vnfd-schema is properly defined:
bandwidth_units:
enum:

• "bps" # Bit per second
• "kbps" # Kilobit per second
• "Mbps" # Megabit per second
• "Gbps" # Gigabit per second
• "Tbps" # Terabit per second

I will create a PR to add this missing definition.

Align 5GTANGO's terminology to ETSI terminology as far as possible (e.g., rename/restructure fields).
Identify gaps between the two information models.
Aim for high standardization impact.

This probably requires quite some effort, to check all relevant ETSI documentation and compare it with ours. Any help is appreciated.

Easier syntax as described here: https://git.cs.upb.de/5gtango/UserStories/issues/176#note_57319

Currently, giving a slice a name with spaces braks the code

Problem: Validator stores schemas locally e.g. in ~/.tng-schema/ but never updates them.

It should always try to download the latest version from GitHub and replace the local version with them (if not internet connection is available the the old ones can be used).

On top, the validator should log (level info) which schema files (path + date) it uses so a user finds this bug. Right now it is incredible complicated to find this :-/

This is certainly not "highly important" but still nice to have (a lot of other systems support it):

Add a (optional!) logo field to NSDs and VNFDs that it of type string and points to a logo file that is shipped with the package.

The GUIs can then make use of it and display it in the list of on-boarded or instantiated services / VNFs, e.g., the logo of the VNF vendor.

The package descriptors will support it as well.

Example:

vendor: "eu.5gtango"
name: "example-package"
version: "0.1.1"
maintainer: "Manuel Peuster, Paderborn University"
release_data_time: "2017.01.01T10:00+03:00"  # IETF RFC3339
description: "This is an example 5GTANGO package."
logo: "icons/upb_logo.png"  # path to logo file (PNG or JPEG)

Small overview of different kinds of descriptors as discussed here: https://git.cs.upb.de/5gtango/generalInfo/wikis/WP4%20conference%20calls#cc-522018

Descriptor overview table (we have/need many?) -> organize: producer, user, location of storage

• package
• service
• vnf
• sla
• policies
• slice
• test
• napd

These (and any other) descriptors should be shortly described and distinguished on a wiki page (eg, here or on GitLab). Coordinate with others.

Problem:
Someone gives you two YAML files, a NSD and a VNFD. But you are not told which of the files is the NSD and which the VNFD. To find out, you can either check the fields in the descriptor and make a qualified guess or we could directly include a type field in the descriptor's header that tells us.

This would look like this:

descriptor_version: "1.0"
descriptor_type: "eu.5gtango.nsd"
...

Possible values for the type could be (but are not limited to):

• eu.5gtango.nsd
• eu.5gtango.vnfd
• eu.5gtango.msd
• eu.sonata-nfv.nsd
• eu.sonata-nfv.vnfd
• eu.sonata-nfv.msd

This will also support to distinguish VNF only vs. NS packages.

Some background discussion from email between Manuel and Peer:

if I remember right, it is not possible right now. There is a field for the image_type but one can only specify a single image per VDU.

But we can add the possibility to have more images with different types in there. In fact, I think OSM recently introduced something similar to support OpenStack and vWare deployments with different images. They call it “alternative_image” or so.

I think the 5GPICTURE project works on similar things under the umbrella of “multi version VNFs”: Have one VNFs for x86, have one for x86 with attached FPGA or GPU accelerator, have one VNF for a small ARM chip on a switch, etc.

Adding it to the descriptors is easy. But our IA and SP guys have to support it. I would say we should add it to the TODOs for the time after v4.0, no?

One thing to keep in mind is that if such a field exists, V&V results need to reference the image that was used in testing, as the results may and will vary depending on the selected architecture and image.

Something like:

• images:
  • image: “the name or id or url of the image”
    • image_type: qcow2
    • image_arch: x86
  • image: “the name or id or url of the image”
    • image_type: qcow2
    • image_arch: arm
  • image: “the name or id or url of the image”
    • image_type: docker
    • image_arch: x86

extend as discussed in Athens F2F. Details to follow.

See:

• https://github.com/sonata-nfv/tng-sp-ia/wiki/QoS
• https://github.com/sonata-nfv/tng-sp-ia/wiki/Miscellaneous