Miguel PdL

The Perimeter project is heading into its thrid year and is really starting to build up a head a steam. The project is looking to achieve seamless mobility driven by actual user needs rather than simply business considerations. Putting the users at the centre rather than the operator enables them to finely control the way their identity, preferences and credentials are used.
In order to explore this space the project recently released its view on how emergency services could be enhanced with the aid of Perimeter mobility technology. This depiction of the emergency scenario is further explained by the TSSG researchers, Frances, Eileen and Gemma on the Perimeter blog.
In supporting this technological roll out and testing, the TSSG team have procured a FEDERICA slice for use within the project. The slice consists of five virtual nodes, which will be

used to deploy the PERIMETER Support Nodes and will allow for a natural maturation of the of the interconnection from a Layer 3 to a Layer 2 connection between the Waterford Institute of Technology (WIT) and the Technische Universitaet Berlin (TUB) testbeds used in PERIMETER. The slice will be used for a variety of purposes within PERIMETER including scalability, performance, network overloading and disruptive testing.

From my perspective this is a significant milestone as not only does it extend our testing capabilities in the TSSG, but goes some way to proving the existence of experimentally-driven research methodology in the area of the Future Internet. In talking to Eileen, Gemma and Frances they have a more precise definition and have added this opinion to the recently publihsed paper by the FIREworks Support Action. As we drive into the third and final year of the project I’m quite sure experience will further refine this experimentally-driven research methodology.

When starting ICT 4WARD as a project in 2008 I must admit I never thought we’d get so far as to carry out an open source release of code. Given that 4WARD was set the task of taking a clean slate approach to designing a future Internet, and one of the TSSG’s roles in this was to help develop an integrated framework to represent, design, implement and operate network architectures, then open source was not something that immediately came to the fore.
However when we went about tackling this task, Patsy grounded our thoughts in the software industry, he identified that the problem faced is not just a networking one, but a networking combined with software issue. Deploying protocols and network functions as compiled C/C++ kernel modules has the advantage of being highly efficient. Unfortunately, kernel modules that can be safely composed and reused can be quite hard to develop. Weak data typing, lack of well-defined module interfaces, possibly intricate data dependencies between modules, platform dependence, absence of fault isolation, and a development and execution environment unfamiliar to most programmers are some of the major stumbling blocks.

To attempt to overcome these problems Patsy wanted us to use a modern object-orientated language in order to allow the Network Architect to use a new environment to make the first prototypes of developed network solutions. Java is platform independent and has much stronger type checking than C/C++. By design, it explicitly disallows many “dangerous” operations such as reckless memory management and pointer manipulations, which one can perform with C/C++.
However in going this route clearly there are increased demands on the software product, for robustness, reliability, flexibility and ease of deployment. As these demands were growing, the complexity of the processes that the software manages is increasing along with demands for the integration of processes from different areas. As a consequence, we found the software programs becoming larger and more complex which was having a huge knock on effect when it comes to the introduction of new concepts on the networking side.
Patsy spotted that Component Based Architecture (CBA) is an approach that is used to address these demands and is core to the Component Based Software Engineering (CBSE), and so he applied this approach to the Networking Stack.
CBSE was used to model network nodes and topology. The transformation from the models to an execution environment based on Java and OSGi simplified the transition from high level networking concepts from a network architects perspective into the deployed software implementations.
From there Patsy worked on the Component-Based Architecture network stack prototype which has implemented a software component infrastructure for flexible experimentation of network protocols. The protocol components are written in Java but conform to the requirements of the CBA architecture within the Open Services Gateway Initiative (OSGi) framework.
So today it is a great pleasure to announce that we have released as open source the component based architecture network stack prototype.