Skip to content

openmano descriptors

Jump to bottom
Gerardo García edited this page Nov 28, 2016 · 17 revisions

This page is obsolete.

The project OpenMANO has been contributed to the open source community project Open Source MANO (OSM), hosted by ETSI.

Go to the URL osm.etsi.org to know more about OSM.

Openmano descriptors are used in openmano module for defining Virtualised Network Functions (VNF) and Network Scenarios (NS):

  • Virtualised Network Functions (VNF) are SW-based network functions that can be deployed on an NFV datacenter
  • Network Scenarios (NS) are topologies of VNFs and their interconnections. Interconnections are typically point-to-point L2 networks, but could also be point-to-multipoint L2 networks. This term is very similar to the term "Network Service", used in ETSI NFV ISG.

Openmano distinguishes between VNF definitions and VNF instances (once deployed in an NFV datacenter), as well as between NS definitions and NS instances (once deployed in an NFV datacenter).

Openmano descriptors are used in the definition of a VNF or NS to declare the main properties of a VNF (VNF Descriptor or VNFD) or a NS (Network Scenario Descriptor or NSD). You could think of VNFD as a file provided by the VNF vendor to describe the properties of its VNF in order to deploy it appropriately, while the NSD is a file created by the service provider/network operator describing a VNF topology to be deployed.

From a single VNF definition or NS definition, multiple VNF and NS instances can be created respectively.

#VNF Descriptor (VNFD)# A VNFD contains the following main properties:

  • name: unique name of the VNF
  • external-connections: external interfaces of that VNF that can be connected in an NS to other VNFs or networks
  • internal-connections: it defines how the internal components of the VNF (termed VNF components, VNFC or just VM) are interconnected. This property is only required in case of VNFs consisting of several VMs
  • VNFC: list of components or virtual machines this VNF is composed of. Each VNFC has a name, a descriptor and other interesting properties:
    • numas, CPU, memory and interface requirements for high I/O performance are specified in this section. CPU and NUMA pinning requirements are specified in this section. Memory requirement in this section will be assigned from the hugepages memory, and interfaces in this section will be assigned from data plane interfaces provided in passthrough (either passthrough of the whole port, or passthrough of an SR-IOV Virtual Function).
    • bridge-ifaces. Interfaces with no high I/O performance requirements are declared here. They will be typically created as virtio interfaces attached to Linux bridges in the host. All the Linux bridges in the host must be pre-provisioned following these guidelines].
    • devices. Additional devices can be included in this section
    • vcpus. This is only useful for traditional VMs with no requirements for high I/O performance. By default, it is commented.
    • ram. This is only useful for traditional VMs with no requirements for high I/O performance. By default, it is commented.

We are providing together with the code 2 templates of VNFD to help in the creation of a VNF:

Next figures show the internal structure of those VNFs. Specific performance requirements are not shown in the figures.

vnf template for single VM VNF
vnf template for multi VM VNF

In addition, we are also providing here some examples of VNFD.

The different versions of VNFD can be found here.

#Network Scenario Descriptor (NSD)# An NSD contains the following main properties:

  • name: unique name of the network scenario
  • topology: it defines the nodes (VNFs and networks) and its connections:
    • nodes. Each node has the following properties:
      • type: VNF (for a VNF), network (for a internal/private scenario network), external_network (for a datacenter network, previously created as external/public).
      • VNF model (only for VNF): this must match a VNF previosly created with a VNF Descriptor
      • model (only for networks). In case of an external/public datacenter network, the name of the network must be included here. In case of an internal/private network, the model must be bridge_net (for control plane networks) or dataplane_net (for data plane networks).
    • connections. Each connection has a name and the set of nodes (VNFs and networks) that must be interconnected together. Openmano intelligently distinguishes if the L2 network that will be created needs to be point-to-point or point-to-multipoint.

We are providing together with the code an NSD template to help in the creation of network scenarios. Next figure shows the internal structure of that scenario template. network scenario template

In addition, we are also providing here some examples of NSD.

Clone this wiki locally