Demonstration of Network Function Virtualisation (NFV)

Demo: users control the network

This year’s demonstration focused on Network Function Virtualisation (NFV) combined with Service Function Chaining (SFC) through a programmable network (SDN). A user interface based on a web browser enabled visitors at the SURF booth, standing in front of a camera in Austin, to direct video traffic through Amsterdam using various random functions set up across Europe. Through the user interface, visitors sent API calls generated by the SFC to the OpenDayLight controller to programme the network. The result was a processed live video image. The types of video processing that could be applied were: upside down, mirror, greyscale, insert text and insert logo.

Network Functions Virtualisation (NFV)

With NFV, the functions traditionally performed by specialised network equipment are moved to smaller or larger virtualised environments (e.g. cloud) which enables them to be applied in a very flexible and scaleable way. Examples of network functions include rate limiting, firewalling, intrusion detection, on-the-fly encoding and decoding, etc. This makes it possible to manage network traffic through several functions, creating a chain of network functions.

Adding network functions to active traffic with full transparency and in real-time requires a programmable network. With a programmable network, you can add and remove network functions at any time, in any order.

Service Function Chaining made visible using video traffic

Demonstrating and discussing Service Function Chaining is made easier when the network functionality is replaced with more visible video functions. That’s why we chose a video setup for the demonstration at SC15. A live UHD camera was positioned at the SURF booth, which visitors could stand in front of. The traffic was collected by a computer and using UltraGrid software it was sent uncompressed to the NetherLight open light path exchange in Amsterdam. The traffic flow was 3.2Gbit/s.        With no video functions activated, the traffic came straight back to Austin from Amsterdam so that the video image was displayed on a UHD display at the booth with a delay of around 240ms.

Programmable network (SDN)

As well as production equipment, the NetherLight open light path exchange also has equipment used for trying out various new technologies. For the demonstration at SuperComputing, we used three Pica8 P-5101 switches controlled through the OpenFlow protocol by an OpenDayLight controller.

Cloud suppliers

The demonstration also featured a number of service providers capable of supplying virtual machines, connected directly to the programmable network by Ethernet. This made it possible to activate different UltraGrid video functions at different locations: on the SURFsara HPC Cloud in Amsterdam, the Okeanos platform in Greece, the CloudSigma environment in Switzerland, the Microsoft Azure cloud in Amsterdam and the SURFnet OpenStack testbed in Amsterdam.

Video functions

A virtual machine was launched for each service provider using an UltraGrid transcode. That enabled each machine to accept incoming video traffic, modify it, and send it on. The traffic was sent to the display from the camera at the IP level.

Classifying traffic with VLAN stitching and MAC rewriting

The demonstration used VLAN stitching and MAC rewriting to keep the different paths and function sequences separate. The traffic is sent from the camera using the camera’s MAC address for the SMAC, and the display’s MAC address for the DMAC. En route, the programmable network adapts these parameters and the traffic stops in the correct VLAN. When the traffic goes to a VM the SMAC is replaced with the camera’s MAC address and the DMAC is replaced with the VM’s MAC address. On the return, the VM’s MAC address is used for the SMAC, and the camera’s MAC address for the DMAC.

IETF working on new protocol

The current setup is quite complex and is not yet being used as flexibly as intended. That’s why the Internet Engineering Task Force (IETF) is working on a protocol called Network Services Headers (NSH). NSH is a new protocol for identifying service function paths in the network by equipping each network package with the required metadata. This new standard is widely supported by network vendors. The protocol decouples the service topology from the actual network topology.

More information

• Read the blog ‘NFV demo with live video images’
• NetherLight open lightpath exchange
• SURFnet SDN Testbed
• SuperComputing website
• IETF website