Project SONATA announces the 3.0 release

SONATA announces the launch of an upgraded release of its integrated service platform, SONATA 3.0, which includes all the software components developed, integrated, tested and qualified within the time frame of the project.

Read our press release here

SONATA Service Platform Release 2.0

SONATA H2020 project, where NCSRD is participating, officially announces the launch of its release 2.0, the third official software release delivered since the project started in July 2015.

SONATA is developing a Network Functions Virtualisation (NFV) service framework that provides a programming model and development tool chain for virtualized services, fully integrated with a DevOps-enabled service platform and orchestration system. SONATA results include:

  • SONATA Service Platform, which accommodates Communication Service Providers’ needs in the new and much more challenging 5G environment.
  • SONATA Network Service Software Development Kit (SDK) that provides an invaluable set of tools for assisting developers in the development and testing of NFV-based services.

These SONATA building blocks complement each other in the context of next generation of mobile networks and telecommunication standards referred as 5G, focusing on optimal use of the available network and cloud infrastructure.


SONATA 2.0 Release main improvements
  • SONATA Service Platform  Tool for automatic and complete installation
  •  New Security policy (HTTPS and user registration).
  •  New modules in the Gatekeeper that provide monetization capability and business intelligence support.
  • Function Lifecycle Managers and improved Specific Managers infrastructure in the MANO Framework.
  •  Initial support of container-based VIMs, multi-PoP service deployment, Service Function chaining configuration and VNF image pre-deploymentand management in the Infrastructure Abstraction Layer.
  •  Extended monitoring functionality.  Improved Catalogues and Repositories
  •  Use of the platform’s GUI by Service Platform managers to manage VIMs


  •  Automated versioning of development setups. Improvement in the validation functionality for detecting bugs in the developed network services/functions.
  •  Updated SDK tools to support multiple platforms and authentication/security options.
  •  The SDK emulator has been extended. It is a key asset which provides a very rapid testing environment to deploy developed services
  •  Additional debugging and monitoring functionality for easy inspection and visualisation of network interfaces and links.

OVS – DPDK on Openstack Newton

In this tutorial we will show detailed instructions and debugging info, in order to deploy a DPDK enabled OVS on an Openstack Newton environment, on Ubuntu 16.04.

First and foremost you must have a working Openstack Newton environment with OVS networking.

Secondly you need to have a DPDK enabled OVS, built and running on your system.

The easy way to do that is to just download and configure the official package.

Following these instructions:

sudo apt-get install openvswitch-switch-dpdk
sudo update-alternatives --set ovs-vswitchd /usr/lib/openvswitch-switch-dpdk/ovs-vswitchd-dpdk

This will install the ovs with dpdk in it. But we also need to add some parameters to the configuration files, and also enable it.

However, before that we need to build DPDK and reserve some hugepages in order to make it run successfully.

The easiest way I have found to do so is, download the DPDK source from, and then run the ./<DPDK-dir>/tools/

Then select the reserve hugepages option and enter the number. (For us it was 4096 x 2MB hugepages).

Now it is time to configure our OVS files

at the /etc/default/openvswitch-switch, an example configuration would be:

DPDK_OPTS='--dpdk -c 0x3 -n 4 --socket-mem 512 --vhost-owner libvirt-qemu:kvm --vhost-perm 0660'

SIDENOTE: The vhost-perm parameter is very important, as it may lead to a permission denied error in kvm, when binding the port to the VM

So one more thing needs to be configured at the /etc/libvirt/qemu.conf

You need to set:

user = "root"
group = "root"

Then as OVS is running exectute this command:

ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true

And then restart the ovs service.

service openvswitch-switch restart.

Check the logs to see the successful execution

You should see something like this at the /var/log/openvswitch/ovs-vswitchd.log:

dpdk|INFO|DPDK Enabled, initializing
dpdk|INFO|No vhost-sock-dir provided - defaulting to /var/run/openvswitch
dpdk|INFO|EAL ARGS: ovs-vswitchd --socket-mem 1024,0 -c 0x00000001
dpdk|INFO|DPDK pdump packet capture enabled
ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports recirculation
ofproto_dpif|INFO|netdev@ovs-netdev: MPLS label stack length probed as 3

One cause of failure would occur if someone does not reserve sufficient hugepages, or does not fill the configuration files correctly.

From then on, the Openstack part remains to be configured

Now comes the first tricky part. Most guides state that you need to configure the tag [OVS] at the ml2_conf.ini, like this:


what they fail to state is that at the Newton release you need to change the /etc/neutron/plugins/ml2/openvswitch_agent.ini , which overwrites the ml2_conf.ini .

Once OVS is correctly configured with DPDK support, vhost-user interfaces are completely transparent to the guest. However, guests must request large pages. This can be done through flavors. For example:

openstack flavor set m1.large –property hw:mem_page_size=large

At last we are ready to setup and boot a DPDK-port enabled VM.

We can boot it through an already created network, or create a new network.

MediaNet Lab in the first open-call experiments of SoftFIRE project

The proposal of the MediaNet Lab in the first open-call of the SoftFIRE project has been accepted and therefore MediaNet Lab will participate in the first experiments of the SoftFIRE project. SoftFIRE aims at creating an ecosystem of organizations around the technological field of NFV/SDN and and its evolution towards 5G developments. In order to achieve this goal, SoftFIRE plans to aggregate as many as possible organizations and people around an enabling platform. The SoftFIRE platform consists in a federated testbed that comprises very different experimental frameworks and is available for experimenting new services, applications and functional extensions of the platform.

The aim of the MedialNet lab experiments is the development and validation of the necessary extensions to the current SoftFIRE federated testbed, in order to enhance it with the capability to execute experiments involving satellite communication systems.

More details will follow in due time, once the design of the experiment and the expected results have been fully defined.


The First International Workshop on Security in NFV-SDN (SNS2016)


The First International Workshop on Security in NFV-SDN (SNS2016) in conjunction with the 2nd IEEE NFV-SDN conference, 7-9 November, Palo Alto, California, USA
Workshop website:

Network Function Virtualization (NFV) and Software Defined Network (SDN) have changed the networking industry dramatically. NFV virtualizes network services by utilizing virtualization technologies to reduce the dependency on underlying hardware. NFV provides many benefits such as faster service enablement, ease of resource management and lower OPEX and CAPEX. SDN separates the control functions from the underlying physical network by decoupling the control and data planes. SDN provides many benefits such as reduced costs, ease of deployment and management, better scalability, availability, flexibility and fine-grain control of traffic and security. Like traditional networks, they are subject to various security threats and attacks. In this workshop, we invite high-quality submissions in the areas of NFV and SDN security and other related areas. Submitted papers should highlight methods and approaches that can be used to analyse the security risks and requirements, threats and techniques related to NFV and SDN and to provide novel methods and approaches to assure security in NFV and SDN.

Topics of interest include but are not limited to the following areas:
• Security, reliability and privacy through SDN and NFV in 5G networks
• Management and orchestration of NFV and SDN elements for security
• Secure design of NFV and SDN solutions, security enablers
• Security threats and vulnerabilities introduced by NFV and SDN technologies
• Threat detection and mitigation through SDN and NFV
• Security policy specification and management in SDN and NFV systems
• Security related monitoring and analytics in SDN and NFV solutions
• 5G security architecture, trust and confidence
• Authentication, authorization and Accounting in SDN
• Security of applying SDN to wireless and mobile network
• Security of applying NFV and SDN to IoT
• Security of applying NFV and SDN to cloud computing
• Security of SDN API
• Risk and compliance issues in SDN
• Securing SDN infrastructure
• Security architecture for SDN
• Security standard of SDN
• Security of SDN data plane
• Security of SDN control plane
• Security of SDN application plane
• Security of Routing in SDN
• Security of network slicing
• Security as a service for SDN

Paper submissions will be handled on-line through the EDAS system at

All submitted papers will be peer-reviewed. The manuscripts must be prepared in English, following IEEE two-column Manuscript Templates for Conference Proceedings with a maximum length of six (6) printed pages (10-point font), including figures. You can find the IEEE Computer Society Proceedings Author Guidelines at To be published in the Workshop Proceedings and to be eligible for publication in IEEE Xplore, at least one author of an accepted paper is required to register and present the paper at the workshop. The IEEE reserves the right to exclude a paper from distribution after the conference (including its removal from IEEE Explore) if the paper is not presented at the conference. Papers are reviewed on the basis that they do not contain plagiarized material and have not been submitted to any other conference at the same time (double submission). These matters are taken very seriously and the IEEE Communications Society will take action against any author who engages in either practice. Authors of selected papers will be invited to submit an extended version of their work as a book chapter for Springer book Guide to Security in SDN and NFV – Challenges, Opportunities, and Applications (

• Paper Submission: July 31, 2016
• Notification of Acceptance: September 7, 2016
• Camera Ready: October 7, 2016

• Shao Ying Zhu, University of Derby,UK
• Eleni Trouva, NCSR Demokritos, Greece
• Richard Hill, University of Derby, UK
• Collin Allison, University of St Andrews,UK
• Muhammad Shuaib Siddiqui, Fundació i2CAT, Spain
• Linas Maknavicius, Nokia Bell Labs, France

• Sandra Scott-Hayward – Queen’s University Belfast, UK
• Roberto Bifulco – NEC Labs Europe, Germany
• Ludovic Jacquin – Hewlett Packard Labs, UK
• Marco Anisetti – University of Milan, Italy
• Augusto Ciuffoletti – University of Pisa, Italy
• Colin Allison – University of St Andrews, UK
• Rhonda L. Farrell- Booz Allen Hamilton, USA
• Jianxin Li-Beihang University, China
• Ljiljana Trajkovic – Simon Fraser University, Canada
• Eleni Trouva, Harilaos Koumaras, Michail-Alexandros Kourtis – NCSR Demokritos, Greece
• Muhammad Shuaib Siddiqui, Eduard Escalona, Jordi Ferrer, Amaia Legarrea – i2CAT, Spain
• Carolina Canales, Miguel Angel Garcia, Miguel-Angel Monjas, Manuel Lorenzo – Ericsson, Spain
• Felix Klaedtke – NEC Labs Europe, Germany
• Linas Maknavicius, Abdelkader Outtagarts – Nokia, Bell Labs, France
• Nicolae Paladi – SICS, Sweden
• Gergely Biczók – Budapest Univ. of Technology and Economics, Hungary

If you have any question, please contact the organizers:
Shao Ying Zhu –
Eleni Trouva –

SR-IOV in Openstack – Various Tips, Hacks and Setups

Single Root I/O virtualization (SR-IOV) in networking is a very useful and strong feature for virtualized network deployements.

SRIOV is a specification that allows a PCI device, for example a NIC or a Graphic Card, to share access to its resources among various PCI hardware functions:

Physical Function (PF) (meaning the real physical device), from it a number of one or more Virtual Functions (VF) are generated.

Supposedly we have one NIC and we want to share its resources among various Virtual Machines, or in terms of NFV various VNFCs of a VNF.

We can split the PF into numerous VFs and distribute each one to a different VM.

The routing and forwarding of the packets is done through L2 routing where the packets are forwarded to the matching MAC VF.

The purpose of this post is to share a few tips and hacks we came across during our general activities related to SRIOV.

A very good tutorial for SRIOV setup :


SRIOV VF Mirroring

Let’s say you want to send the same flows and packets to 2 VMs simultaneously.

if you enter the ip link show you should see something like this:

p2p1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether a0:36:9f:68:fc:f4 brd ff:ff:ff:ff:ff:ff
vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 1 MAC fa:16:3e:c0:d8:11, spoof checking on, link-state auto
vf 2 MAC fa:16:3e:a1:43:57, spoof checking on, link-state auto
vf 3 MAC fa:16:3e:aa:33:59, spoof checking on, link-state auto

In order to perform our mirroring and send all traffic both ways we need to change the MAC address both on the VM and on the VF and disable the spoof check.

Let’s change vf2 -> vf3

On the VM:

ifconfig eth0 down
ifconfig eth0 hw ether fa:16:3e:aa:33:59
ifconfig eth0 up

On the host – VF:

ip link set eth0 down
ip link set eth0 vf 2 mac fa:16:3e:aa:33:59
ip link set eth0 vf 2 spoofchk off
ip link set eth0 up

After that we have 2 VFs with the same MAC.

But it will still do not work. What you have to do is, change again the vf 2 to something resembling the latest MAC

ip link set eth0 vf 2 mac fa:16:3e:aa:33:58

After these changes through the experiments we performed we managed to mirror the traffic on 2 different VFs.


SRIOV Openstack setup with flat networking – no VLAN

In openstack the default setup and various tutorials use the VLAN networking. Meaning the routing is done through MAC and VLAN.

In one of our tests we had trouble creating traffic matching both rules, so we investigated the no VLAN option.

Even though the setup of SRIOV over flat networking in Openstack is pretty simple, we did not find any tutorial, or a note underlining its simplicity.

The steps are pretty straightforward :

neutron net-create –-provider:physical_network=physnet1 –-provider:network_type=flat <Network_Name>
neutron subnet-create <Network_Name> <CIDR> –name <Subnet_Name> –allocation-pool=<start_ip>, end=<end_ip>
neutron port-create <Network_Id>  –binding:vnic-type direct

And launch VM with port you have just created.

nova boot –flavor <Flavor_Id> –image <Image-id> –nic port-id=<Port_Id> <VM_Name>


Job opening: R&D Software Engineer

We are seeking a competent software engineer to contribute to cutting-edge innovative developments in the frame of European research projects in the fields of IT and telecom.
Required qualifications:

  • Bachelor’s degree (in IT field)
  • At least five years professional experience in software development
  • Expertise in:
    • Java
    • Python
    • C/C++
    • Web development (HTML/CSS/PHP/Javascript)
    • WebServices/SOAP-XML, RESTful APIs, SOA
    • Database management (MySQL, PostgreSQL)
  • Expertise in Linux administration and development
  • Very good knowledge of network technologies and L3-L7 protocols
  • Proficient in Greek and English
  • Ability to contribute to and edit technical reports and deliverables

Desired qualifications:

  • MSc degree
  • Previous involvement in research projects
  • Agile development skills
  • Experience with cloud platforms (e.g. Openstack, Cloudstack)
  • Previous involvement in open-source community projects

Interested? Send your CV to:

T-NOVA project releases NFV architecture specification document for VNFaaS

The NFV-focused T-NOVA EC/FP7 research project, led by MNL, released its second specification document, proposing an integrated top-down NFV system architecture for the provision of Virtual Network Functions as-a-Service. The T-NOVA architecture reuses ETSI NFV concepts for the lower architectural layers, while it introduces novel entities, including an NFV Marketplace with the aim of accelerating the market uptake of the VFNaaS business case. The defined architecture is reasonably complex and feasible to realise, being compatible with existing state-of-the-art IT and network infrastructures and will be fully implemented in the course of the project.

VNFaaS Use Cases and Requirements document released

T-NOVA project released its first specification document, identifying use cases and requirements for an integrated Virtual Network Functions as-a-Service (VNFaaS) platform, such as the T-NOVA system. From a business point of view, the document proposes multiple value chain configurations, involving actors such as Infrastructure Providers, VNFaaS Service Providers and Function Developers. Elementary VNFaaS use cases cover all technical and commercial aspects and include: service composition, trading, provision, scaling, monitoring, billing and termination. High-level system requirements are derived from the list of use cases. Read the document here.

T-NOVA at FIA Athens

MNL, as T-NOVA coordinator, in liaison with projects NetIDE, UNIFY and SECURED co-organised a session on “Open platforms and SDN-NFV_a paradigm shift to boost innovative Internet services and applications” at Future Internet Assembly, Athens, March 2014. The session brought together industry experts for a discussion on how open platforms could pave the way toward an innovative way to build Internet applications and services leveraging on the emerging “softwarization” of networks and data-centers.