University College London

H718

Contract

MDA972-99-1-0009

28 JUL 1999

Contract

31 MAY 2002

$191,700

$156,063

$35,637

September 30, 2000

Funding

$166,600

Additional

Since our organisation invoices the government annually, we have not provided an invoice.

Peter

Kirstein

Address 1:

Department of Computer Science, University College London

Address 2:

Gower St

London

United Kingdom

WC1E 6BT

+44-20-7679-7286.

+44-20-7387-1397

p.kirstein@cs.ucl.ac.uk

Level Of

15 %

10%

Principal

Investigator:

John

Crowcroft

Address 1:

Department of Computer Science, University College London

Address 2:

Gower St

London

United Kingdom

WC1E 6BT

+44-20-7679-7296.

+44-20-7387-1397

j.crowcroft@cs.ucl.ac.uk

Level Of

0 %

15%

The main objective of this project is to show how Application Level Active Services can be used to provide important new functionality in computer networks. The main emphasis is on the demonstration of the added functionality that can be achieved; of particular importance in this context are application-level routing, packet forwarding with DiffServ, and mechanisms for the location of key modules. As part of this work, it is important to identify the security architecture and to develop a number of key components that can be located as applications at boundaries between domains.

Both this project and SCAMPI are of small size. To allow the maximum impact of both projects, they will be closely aligned – with similar basic functional components. The RADIOACTIVE project will concentrate on their deployment in an Active Application Service environment; the SCAMPI project will concentrate on the Security of the components and their operation.

<P>

The approach is to utilise a system for application level active services (ALAN) developed previously in earlier projects, and to develop suitable components which fully demonstrate the utility of the system. The system requires that all the active components be written in JAVA, and run as Proxylets down-loaded from a Server; the requisite policies will be expressed in XML. The JAVA requirements implies that the system will be able to move over to be run under IPv6 when the requisite JAVA support become available. Both proxylets and policies will be developed for Application Level Routing, Packet Forwarding with DiffServ and the location of key modules. Algorithms for packet forwarding will be investigated, and a security architecture developed. The components will be ones that are appropriate to the active service environment; they will include recording caches, replay caches, relays, and QoS modules. Each of these is appropriate to be located near a domain boundary.

<P>

The use of such components in an automated form requires automated placement; this in terms requires location discovery of resources; components to achieve these functions will be developed. Rugged operation requires also replication; the mechanisms for replication will be provided; they will use the location discovery procedures to ensure usable distributed replication. The security architecture will embrace the use of PKIs, IPSEC/IKE and secured components. The requisite security procedures will be implemented both to allow the secure operation of the active components, and the confidentiality of data carried through the active components. The main components to be developed will be those for secure conferencing, secured conference announcement depositories, secured relays, recording and replay caches and QoS modules.

<P>

To be compatible with the DARPA interest in collaboration in their managed programmes, there will be joint demonstrations with the Kansas U Active Networks programme and the ISI Xbone activity. Partly to enable the large-scale deployment in general, and partly to aid in the specific demonstrations, extensive measurement and monitoring facilities will be provided.

The latest version of the basic Active Service system, now called FunnelWeb (FW) has been mounted.. The system now allows dynamic protocol stacks to be placed in a depository, where they be shared for down-load so that the Dynamic Proxy Servers (DPS) and the end systems can use the same stack. This is essential for widespread deployment of a system that will require ongoing maintenance for a while. Only trusted hostts are allowed to submit requests to a DPS, and only trusted servers can be the depository for DPSs. DPSs can only communicate with proxylets via the interface provided, protecting the DPSs from modification.

`<P>

The complete architecture has been defined, and most of it implemented. The infrastructure of proxylet (running in a WWW browser) and a servlet on a WWW server is available. The Execution Environment (EEP), which downloads and runs the servlet, is largely complete; it is written in JAVA - for ease of development, portability and security features.. The FW and the EEP have been made to run on Linux, FreeBSD and Solaris. To scale to large systems, it must be possible to set up a large mesh of EEPs – which permit each to discover neighbours, and other nodes of the mesh. Several routing requirements have emerged based on cost functions. The full functionality is defined on the Web site.

<P>

A number of proxlets have been written. These include ones to proved multicast functionality (using Receiver-driven layer congestion), reliable multicast data distribution and a multicast reflector, and several for modifying QoS (a TCP bridge, a transcoder and a compressor/decompressor). Currently their functionality is limited, and they need to be statically located.

<P>

A number of more complex applications have been rewritten in JAVA in preparation for being made into proxylets. These include a cache recorder/player and .a transcoding gateway. These again still have limited functionality, and they need to be statically located.

<P>

The structure of a collaborative demonstration in Atlanta in December 2000 between Kansas U, ISI and UCL has been designed. This will involve mounting the UCL EEPs and Proxylets on Kansas U’s nodes at Atlanta, and configuring an active service cloud, which includes UCL and Ksndsd, using the Xbone technology of ISI.

During the coming year, we will complete the Reliable Multicast, Audio transcoding and filtering gateway proxylets – integrating them into FunnelWeb. We will verify that the whole EEP infrastructure can be run over, and controlled through, the Abone. We will verify that we can set up an Active Node WAN, with the nodes configured by ISI’s Xbone engine. We will liaise with SCAMPI to ensure that we have a suitable infrastructure. We will start providing some of the facilities for neighbour discovery and automatic placement of the proxylets on demand. Finally we will provide a joint demonstration at the December Atlanta Active Networks PIs’ meeting.

<P>

It is not fruitful to identify individual pieces of this plan with specific defence needs. The whole Active Service environment will have important impact on the way future networks for Defence are built. The activities during this year will have an important impact on the deployability of this technology.

The transition of this technology to the US DoD has not yet occurred – partly because nothing has been demonstrated yet to them. However in the UK, BT has been sufficiently interested to fund the basic programme which is leading to enhanced technology, and leads a European Commission project which will explore the management aspects of the technology.