Reference VNF and NS Descriptors (Release TWO)
The following reference examples are provided to help VNF vendors to create their own descriptors (NSD, VNFD) usable in OSM. Please follow the below instruction to create descriptor packages
- Clone the descriptor-packages repo:
git clone https://osm.etsi.org/gerrit/osm/descriptor-packages
- Create a new VNF folder under src/vnfd and copy the VNF yaml descriptors in the new folder
- Create a new NS folder under src/nsd and copy the NS yaml descriptors in the new folder
- Build VNF and NS packages
make
- Packages will be created under build/vnfd_pkgs and build/nsd_pkgs
Reference NS#1: Testing an endpoint VNF
The following network service captures a simple test setup where a VNF is tested with a traffic generator VNF (or a simple VNF/VM with a basic client application). For simplicity, this network service assumes that the VNF under test is the endpoint of a given service (e.g. DNS, AAA, etc.) and does not require special conditions or resource allocation besides the usual in a standard cloud environments.
In this example, unless otherwise specified in the description, the following defaults apply:
- CPs are regular para-virtualized interfaces (VirtIO or equivalent).
- VLs provide E-LAN connectivity via regular (overlay) networks provided by the VIM.
- VLs provide IP addressing via DHCP if applicable.
- Mapping between internal and external CPs may be either direct (as aliases) or via an intermediate VL.
- VIM+NFVI can guarantee predictable ordering of guest interfaces' virtual PCI addresses.
In the case of REF_NS_1:
- When deploying the NS, VL1 would be typically mapped to a pre-created VIM network intended to provide management IP address to VNFs via DHCP.
- DHCP in VL2 may be optional.
Reference VNF#11: Endpoint VNF
Description in common language
- Name: Ref_VNF_11
- Component: Ref_VM1
- Memory: 2 GB
- CPU: 2 vCPU
- Storage: 8 GB
- Image: ref_vm1.qcow2
- Component: Ref_VM2
- Memory: 4GB
- CPU: 2 vCPU
- Storage: 16GB
- Image: ref_vm2.qcow2
- Internal Virtual Link: VL12
- No DHCP server is enabled.
- Static addressing may be used at CP iface11 and CP iface21.
- Component: Ref_VM1
OSM VNF descriptor for VNF#11
Reference VNF#21: Generator 1 port
Description in common language
- Name: Ref_VNF_21
- Component: Ref_VM5
- Memory: 1 GB
- CPU: 1 vCPU
- Storage: 16 GB
- Image: ref_vm21.qcow2
- Component: Ref_VM5
OSM VNF descriptor for VNF#21
OSM NS descriptor for NS#1
Reference NS #2: Testing a middle point VNF
The following network service captures a more advanced test setup where the VNF under test is a middlepoint in the communication (e.g. router, EPC) and might require special conditions or resource allocation and connectivity foreseen in NFV ISG specs. In this case, the traffic generator VNF behaves as source and sink of traffic and might also require special resource allocation.
In this example, unless otherwise specified in the description, the following applies:
- Same defaults as in NS#1
- vCPUs must be pinned to dedicated physical CPUs, with no over subscription.
- CPUs, memory and interfaces (if applicable) to be assigned to a given VM should belong to the same socket (NUMA awareness).
- Memory assigned to VMs should be backed by host's huge pages memory.
- VL2 and VL3 are E-Line underlay connectivity. No DHCP is required.
Reference VNF#12: Middle point VNF
Description in common language
- Name: Ref_VNF_12
- Component: Ref_VM3
- Memory: 2 GB huge pages
- CPU: 2 vCPU (= CPU)
- Storage: 8 GB
- Image: ref_vm3.qcow2
- Component: Ref_VM4
- Memory: 4GB
- CPU: 2 vCPU
- Storage: 16GB
- Image: ref_vm4.qcow2
- Connection Point: iface42 (west)
- Type: Passthrough
- Connection Point: iface43 (east)
- Type: SR-IOV
- Component: Ref_VM3
OSM VNF descriptor for VNF#12
Reference VNF#22: Generator 2 ports
Description in common language
- Name: Ref_VNF_22
- Component: Ref_VM6
- Memory: 1 GB huge pages
- CPU: 1 vCPU (= CPU)
- Storage: 16 GB
- Image: ref_vm22.qcow2
- Connection Point: iface61 (west)
- Type: Passthrough
- Connection Point: iface62 (east)
- Type: SR-IOV
- Component: Ref_VM6