WP1 (Operations): This workpackage will assure the existence of an operating testbed for OneLab over the course of the project. It will also lay the groundwork for continuing operations beyond the end of the project. In the process, OneLab will assume administration of the PlanetLab infrastructure in Europe, thus providing Europe with significant autonomy in shaping its portion of this key infrastructure. On the one hand, we need to run an a standalone testbed that gathers the components developed, for early use and validation purposes; second, we intend to prepare for the migration towards a federated PlanetLab management scheme, so that we can take over the management of the PlanetLab Europe testbed that we would have full control upon, and that at the same time will be fully interoperable with the current Public PlanetLab.
WP2(Integration): This workpackage will: build a centralized software development infrastructure to be used by all OneLab partners, ensure the consistency of the OneLab software throughout the course of the project, as well as perform the actual build of the OneLab software. Our objectives in identifying a workpackage dedicated to these activities are as follows:
Ensure that the PlanetLab software becomes a suitable running environment for all our new contributions, and that OneLab becomes fully autonomous and acquires the ability to work around any missing feature in PlanetLab.
Ensure that all the new contributions from OneLab fit well into PlanetLab, that is to say adhere to the current PlanetLab operation modes.
Maintain OneLab as consistent as possible with the future evolutions of PlanetLab.
WP3 (Topology component): The objective of the topology monitoring component is to provide applications or multihomed hosts with an interface through which they can obtain information concerning the underlying network topology. This interface will allow a host to send queries to determine the characteristics of the paths, either measured or predicted, between itself and a list of destinations. This information is important for traffic engineering boxes or multihomed hosts that are willing to select the best path to reach a destination. There are two subcomponents to the proposed topology monitoring component.
The first one is an active measurement subcomponent that sends probe packets in the network, and, where these probes are destined for OneLab nodes, receives them as well. This subcomponent will run as an application on the OneLab nodes. To obtain a larger number of sources we will develop virtual sources. A virtual source is a source of probe packets that resides in a distant network. Each virtual source is linked to a OneLab node through Mobile IP. Each remote site configures one of its routers as the home agent for one unused IP address. We will develop a software tool to allow each OneLab node to register as a mobile node using multiple distant IP addresses, and to tunnel probe packets to the distant routers. This will allow the topology monitoring component to benefit from more sources of observation than simply the OneLab nodes.
The second subcomponent is an AS-level topology monitor, which tracks BGP announcements. This component will start as a BGP feed on each OneLab node and we will add the ability of querying the BGP routing tables of distant nodes or BGP route collection servers such as RouteViews, RIPE RIS or Netlantis. This will allow the ASlevel topology monitor to obtain more up-to-date information about the AS-level topology.
WP4A – WiMAX component: The objective of this component is to provide OneLab with connectivity towards two WiMAX nodes located at UCL. This WiMAX connectivity is intended to represent the diversity of wireless access networks.
WP4B – UMTS component: The integration of a UMTS micro-cell within OneLab is an important goal for the project since it allows researchers to investigate the characteristics of UMTS when used as an access network for the Internet. Moreover, the availability of a UMTS micro-cell will give researchers the opportunity to experiment with customizable application gateways that can be used to make interoperable the advanced communication services today available in the Internet and the UMTS world.
WP4C – Multihomed component
WP4D – Wireless ad hoc component: The major benefit of this component is to offer a real testbed for the testing and validation of new protocols for ad hoc networks or applications, rather than based on simulation as it is currently done. Improvement and customisation of proposed solutions can be achieved in an easy manner based on real information
WP4E – Emulation component
WP5 (Validation): The purpose of this workpackage is twofold. First, the integrated OneLab? platform, as output from WP2 through D2.5, will be progressively migrated to the publicly available platform as operated by WP1. Second, the various components will be subject to validation in real conditions and for that purpose will start to be used in real experiments. Our objectives in grouping these activities in a separate workpackage, as opposed to having each component run his own validation activities, is that we are here interested in system-wide validation, and not simply validation of the individual components. This workpackage is thus divided into two tasks, each of which will produce one deliverable.