Roadmap

VNUML Roadmap: Current Limitations and New Challenges

Authors:
Fermín Galán (galan at dit.upm.es)
live document

Introduction

This document aims to analyze the current status of the VNUML project (mainly the VNUML tool itself). The new challenges that would be addressed by the project are outlined, leading to a redesign of the architecture and use cases of the tool. In some sense, this document can be seen as a "VNUML 2.0" roadmap, but the fact is that it is goes steps further VNUML when considering other node backends appart of UML, like Xen of Dynamips.

Note that VNUML was born on Januray 31st 2003 (this is the releasing date of the -unpublished- 1.0.0 version). Almost 5 years after that, now that the tool has grown in functionality and users and the current VNUML language specification (1.8) is quite stable, we think is a good time to open a discussion regarding current limitations and future working lines.

Current Limitations of VNUML

• VNUML is too coupled to UML (it even shares acronym! :). We think that UML was the right choice when VNUML was conceived, but several other strong alternatives has appared in the meanwhile (like Xen in late 2003) or are emerging nowadays (like KVM). Additionally, the VNUML language it is also suitable to describe nodes that are not implemented using virtual machines, like for example Dynamips-based router entities, or, in the extreme, even real equipment.
• Mono-host environment. Considering the way VNUML is implemented nowadays, it is mandatory that the entire scenario runs in the same physical host. This is not problematic when your scenario includes few nodes (e.g., 3, 5 or even 50). However, the VNUML specification could (theoretically) include 1,000, 10,000 or 100,000 nodes (maybe adapting the output of some topology generator like Inet3, GT-ITM, Tiers or BRITE), which is not affordable to be deployed in only one physical host. Currently, the only way to deal with this case is to manually split the global scenario into several independent XML files (from the point of view of VNUML management) scenarios, breaking the scenario unity and putting on the user's shoulder the responsibility of interconnect all the pieces properly.
• Monolithic specifications. Currently, the whole scenario has to be described in only one XML file. However, considering the intrinsic hierarchic structure of IP networks nowadays it could be interesting (specially in the case of very big scenarios as the ones introduced above) to split the description into several XML files, but without breaking the scenario unity (i.e., the scenario is the sum of all the XML files). This allow, for example, that different teams of people work on the definition of different parts, quick substitution and evolution of parts of the network without changing others and, in general, all the benefits of the modularization.
• Un-scheduled execution of commands. VNUML allows to execute command sequences, but without any scheduling notion. In other words, all the commands belonging the the sequence are executed in "time zero". It could be desirable to specify in which exact moment each command will be executed (for example, "stop the apache server, wait 5 minutes, start it again"). A further evolution is to include "network events" (i.e., they are not shell commands executed in the virtual machines, but affecting the environment in some way), like "link down" and "link up" (this is very interesting for example, when testing a routing algorithm, in order to know how it reacts to topology changes).
• Monolithic operations. Currently the scenario has to be created (or destroyed) as a whole, which main problem is that it takes a lot of time when a virtual machine fail booting to re-do the entire scenario. An "atomic" approach is more desable.