Very Lightweight Network & Service Platform for 5G and Beyond Environments
We have designed and built a platform especially for Software Defined Network and Service environments called the Very Lightweight Network & Service Platform. It can be used for experiments in the domain of SDN, NFV, and in 5G and Beyond Environments. This includes run-time monitoiring, adaption, and adjustment of networks like Software Defined Networking, and also having a dynamic programming environment which allows the setup of complete network topologies on-the-fly — a fully Software Defined Network.
The Network & Service platform is based on a foundational framework called User Space Routing. This uses a set of Virtual Routers and Virtual Network Connections to create a network environment which can easily accommodate (i) fast setup and teardown of a Virtual Router, and (ii) fast setup and teardown of a Virtual Connection. As each Virtual Router can run programs and service elements, it becomes possible to construct an arbitrary network and compute topology.
Here we give our motivations plud an overview of the Virtual Network and Service platform, describe the platform itself and the components in more detail. The usage and startup of the platform together with the configuration options is presented in the attached release notes.
Motivation
There were many motivations for designing and building the User Space Routing framework. These were accumulated from experience on the RESERVOIR project, which investigated running services in virtual machines, and the AutoI project, which investigated the virtualization of network elements, and the UniverSELF project, which invesitaged management techniques and systems for modern network architectures. It was found that the use of a hypervisor and the associated virtual machines did work as expected and as required, however, there were some issues that hindered various experimental situations.
We found that using a hypervisor and virtual machines added only 5% to 10% overhead to operations, compared to running the same operations in the physical machine, which is most cases was entirely acceptable. The small loss of efficiency was easily overcome by the flexibility of having virtual machines. In terms of experimental and research issues, some were general issues and others were specific to the domain. We found the following general issues:
- the number of virtual machines that can run on a physical host is limited. This can be due to the actual resources of the physical machine that need to be shared (such as the number of cores and the amount of memory available), together with the switching capabilities of the hypervisor.
- the speed of startup of a virtual machine can be quite slow. Although virtual machines boot up in the same order of magnitude as a physical host, there are extra layers and inefficiencies that slow them down. Also, if many virtual machines are started concurrently, then we observe that the physical machine and the hypervisor thrash trying to resolve resource utilization.
- the size of a virtual machine image is quite large. A virtual machine has to have a disc image which contains a full operating system and the applications needed for the relevant tasks. To start a virtual machine, the operating system needs to be booted and then the applications started. So every virtualized application needs the overhead of a full OS.
and we found the following issues that were more domain specific:
- in terms of virtual networks, and virtualized routers in particular, we ob- servered that 98% of the router functionality we never utilized in any of the ex- periments that were run. Although software routers such a XORP and Quagga allow anyone to play and evaluated soft networks, the overhead of a virtual ma- chine, with a full OS, and an application where only 2% is used, seems to be an ineffective approach for many situations.
- when trying to configure the IP networking of virtual machines and virtual routers, there are some serious hurdles. The virtual machines do not talk di- rectly to the network, but go via the hypervisor. The hypervisor has various schemes for connecting virtual machines to the underlying network, each of which has different behaviour. In most situations where experimentation of virtual routers is required, there needs to be a large range of IP addresses available. However, this is often hard to come by. We found that the limits of addressing, the IP networking configuration, and virtual machine to vir- tual machine interoperability a hindrance to network topology and network flexibility.
It was felt that to make more progress in the area of dynamic and virtual networking experimentation and research, we needed to design and build a testbed that did not have these limits, but still retain virtual machine technology.
The main goals of the testbed over using a hypervisor running a standard virtual machine and standard OS are to have:
- better scalability
- lower resource utilization
- quicker startup speed
- reduced heaviness
- eliminate the issue where 98% of the router functionality not needed
- more networking flexibility
The choice was made to write our own simple router with simple service capabilities, in Java, that could run in a Java Virtual Machine (the JVM).
Benefits
The benefits of a lightweight VM that includes a simple router and the basic capa- bilities of a service component are:
- it is possible to run many more routers on a host
- it is easier to test scalability and stability
- it is possible do enhanced monitoring and management evaluations
- it provides a different way to do virtual networks: we can create arbitrary topologies using virtual routers
- it is possible to do more evaluations of network management functions by not using complete routers and full services
In general, it is a more effective platform for experimenting with many aspects of virtual networks.
The Platform
The platform is designed using 4 main layers:
- a management application layer which executes management applications that define the software components and network functions of a network service together with their configuration parameters.
- an orchestration layer which is a software element which does most of the management and orchestration and is in charge of managing the full lifecycle of the virtual routers in the network and the allocation of the applications running on the virtual nodes. It is called "Global Controller" and it does the orchestration of the all elements of a service,
- an abstraction layer which contains a software element which presents an abstraction for starting, stopping, and configurating virtual elements. It is called "Local Controller" and acts as a Network Hypervisor, and works in a similar way to a host level Hypervisor managing virtual machines.
- an infrastructure layer which contains both the virtual infrastructure and represents the virtual resources (i.e. the virtual routers) that make up the virtual networks, and the which are the physical resources that are the hosts running the virtual routers.
The main functions of the Very Lightweight Network & Service Platform are outlined in this subsection. The platform uses a set of Virtual Routers and Virtual Network Connections to create an environment which can easily accommodate:
- fast setup / teardown of a Virtual Router
- fast setup / teardown of a Virtual Connection
- each Virtual Router can run programs / service elements
so it becomes possible to construct an arbitrary network and compute topology.
Elements
So the main elements of the Platform are the the GlobalController, the LocalControllers, and the Virtual Routers. These are each explained in further detail below.
There is one GlobalController for the platform, and it has the following functions:
- it starts and stops the LocalControllers
- it acts as a control point for the platform by sending out commands,
- it acts as a management element for the platform by collecting monitoring data and enabling reactive behaviour
The GlobalController can run on the same host as a LocalController, or in a large setup it can run on a separate host.
There is one LocalController for each physical host that needs to execute virtual routers. A LocalController has the following functions:
- it starts and stops virtual routers
- it tells routers to create and remove virtaul network connections
- to get or set attributes on routers or links
A LocalController is similar to a hypervisor in a normal virtualization environment, as it has a role of stopping and stopping virtaul machines.
Within the platform, many Routers can be created. These virtaul routers behave like a real hardware router, with the caveat that they have much simpler functionality.
Figure 2.1: General Architecture
In figure 2.1, the relationship between these elements is shown. There is the GlobalController, shown in brown, which can take various configurations in order to setup and control a run. These configurations can be static configurations, where there is a fixed topology, or dynamic configurations, where the topology of the network and the number of links changes on-the-fly under the control of the GlobalController.
The GlobalController interacts with various LocalControllers. This interaction path is shown as a dotted line. A LocalController, shown in purple, executes on each physical host that participates in the platform. Each LocalController takes requests from the GlobalController and takes the required action. This can be to start or stop a virtual router, to create or remove a virtual link, to get or set attributes on routers or links.
To start a new Router, shown in blue, the LocalController on the relevant host will start a new Java Virtual Machine, shown in white, executing the specific Router code. The router has various elements, which will be discussed later, however for this discussion the most important one is the Router Management element, shown in yellow. Once a Router is up and running, the LocalController interacts with it via the Router Management interface. It is using this interface that commands and requests for the Router are sent by the LocalController. This path is also shown via a dotted line.
Although there is a considerable amoount of infrastructure in the platform dealing with control, the main aim of the platform is to create a topology of virtual routers. These routers execute on a set of hosts, with virtual links between the virtual routers. In figure 2.2, we see how the topology of virtual routers and virtual links manifests itself across multiple hosts, three in this case.
Figure 2.2: Hosts with Virtual Routers and Virtual Links
Figure 2.3: Full Connectivity with Control Path
User Space Routing Code
Source
You can see the source on GitHub
Release Notes
See the release notes and guide , in PDF.
Online Javadoc
See the online documentation