Reference VNF and NS Descriptors (Release TWO): Difference between revisions

From OSM Public Wiki
Jump to: navigation, search
(Created page with "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 desc...")
 
 
(One intermediate revision by the same user not shown)
Line 130: Line 130:
== OSM NS descriptor for NS#2 ==
== OSM NS descriptor for NS#2 ==
[https://osm.etsi.org/gitweb/?p=osm/descriptor-packages.git;a=blob;f=src/vnfd/ref2_ns/ref2_nsd.yaml;h=f308282b4f3fab25161e780c084efd82bc0f42d2;hb=HEAD NS2.yaml]
[https://osm.etsi.org/gitweb/?p=osm/descriptor-packages.git;a=blob;f=src/vnfd/ref2_ns/ref2_nsd.yaml;h=f308282b4f3fab25161e780c084efd82bc0f42d2;hb=HEAD NS2.yaml]
= Resources =
The template used to create these NS/VNF diagrams is available at:
[https://drive.google.com/open?id=0B0IUJnTZzp2iUnJUb1JFSGpBRGs Reference_NS-VNF_diagrams.pptx]

Latest revision as of 17:18, 20 June 2017

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.

Reference NS #1: Testing an endpoint VNF

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

Reference VNF#11: Endpoint

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.

OSM VNF descriptor for VNF#11

VNF11.yaml

Reference VNF#21: Generator 1 port

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

OSM VNF descriptor for VNF#21

VNF21.yaml

OSM NS descriptor for NS#1

NS1.yaml

Reference NS #2: Testing a middle point VNF

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

Reference VNF#12: Middle point

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

OSM VNF descriptor for VNF#12

VNF12.yaml

Reference VNF#22: Generator 2 ports

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

OSM VNF descriptor for VNF#22

VNF22.yaml

OSM NS descriptor for NS#2

NS2.yaml


Resources

The template used to create these NS/VNF diagrams is available at: Reference_NS-VNF_diagrams.pptx