1. BAA: 99-06

 

2. TECHNICAL TOPIC AREAS: (5) Other research related to NGI and Extensible Networks

 

3. TITLE: Realising Adaptive Distributed Internet Operations on ACTIVE networks -

RADIOACTIVE

 

4. PRINCIPAL INVESTIGATORS: Profs Peter T. Kirstein and Jon Crowcroft

 

5. TECHNICAL POINT OF CONTACT: Prof. Peter T. Kirstein

E-mail: kirstein@cs.ucl.ac.uk

Tel: +44 171 380 7286

Fax: +44 171 387 1397

Mailing Address: Department of Computer Science

University College London

Gower St, London, WC1E 6BT, UK

 

6. ADMNISTRATIVE POINT OF CONTACT: Mr .Dominic Abbey

E-mail: d.abbey@cs.ucl.ac.uk

Tel: +44 171 380 7243

Fax: +44 171 387 1397

Mailing Address: Department of Computer Science

University College London

Gower St, London, WC1E 6BT, UK

 

7. SUMMARY OF COSTS

TYPE OF BUSINESS: University - HBCU?

Prof. Peter T. Kirstein Date Prof. Jon Crowcroft Date

Director of Research Department of Computer Science

Department of Computer Science University College London

University College London

1. Innovative claims for the proposed research.

There are a number of innovative claims for the proposed research - though an important aspect of our activities is that we helping other innovative projects to interact. Our innovations include the following:

• We are using state-of-the-art Application Level and Network Level Active Networking technology to build novel, hyper-scaleable applications and services
• We are building infrastructure services within this environment which are themselves scaleable, and offer meta-services, such as application level multicast and mobile routing and load balancing, for other applications and services to leverage off;
• We are using state-of-the-art real networks (IP on the CAIRN, LEARNET etc.) so that we can control the resource usage;
• We are using state-of-the-art services, including integrated ones, viz. differentiated services, bandwidth brokers and support multicast;
• We will build an integrated architecture that factors in authentication, confidentiality and accounting, using the current mechanisms being standardised in the IETF - and will contribute to the Standardisation process;

• The systems will be tested with real networks and users.

• We are applying the Active Service and three-dimensional extraction techniques to a problem of considerable interest, viz. the monitoring of a substantial number of audio sources.

1. Technical rationale, technical approach and constructive plan

1. Technical Rationale

The evolution of the Internet has slowed down since it became large, even though its growth rate has continued. It is becoming increasingly hard to deploy new network layer services. For example, IP Multicast was defined and implemented in 1988; ten years later there has been only limited deployment. Similarly, Integrated Services (Int. Serv) and Differentiated Services (Dif. Serv), IPSEC and Mobile IP have all had limited acceptance and deployment.

In work in the HIPPARCH project at UCL reported in several recent publications [GHOSH 98, GHOSH98b], we have developed an Application Level Active Network system, based on mechanisms called "proxylets" which are loaded throughout a distributed set of dynamic proxylet servers to enhance an internet service in a programmable way. For many classes of large-scale application, this allows one the further enhancement of the scale of participation (both in the number of participants and in the range of performance seen in a heterogeneous network). A number of components in this architecture are not yet available. This proposal addresses those components; it also proposes that we compare and combine this approach with more traditional ones to these problems in the IP Layer.

One such set of modules is that of filters/transcoders where there are impedance mismatches in the bandwidth, and where simple source-based layered coding techniques are not appropriate. A good example is when the mismatch is so big, that the usual exponential distribution of rates of audio or video is much larger than the actual steps in available bandwidth. This will occur in the very practical case when there are a relatively small number of layers, e.g. four, implying a relatively large difference in the offered load between one layer and the next). There are realistic reasons why this will usually be the case. One must chose a small number of layers so that receivers can home in on the right layer(s) quickly, but there may be an increasing number of different access link speeds, as well as mixes of traffic on different bottlenecks.

This example illustrates the need for several activities:

• Methods for ensuring that the modules can be run safely in the network
• Mechanisms for locating components
• Methods for constraining the use of the modules.

This project will consider all these aspects.

Active Networks (ANs) allow switches within the network to execute code on behalf of some granularity of packet. However, these switches are resources shared by all who use the network; as guardians of the common good, it is the responsibility of switch managers to be certain that the benefit of the additional services outweighs the possible damage that ANs may visit upon a switch. In general, most switch managers do not view ANs with enthusiasm. They need to be sure that:

• There will not be a notable loss of performance from the overhead of running AN code.
• Active code will not compromise the integrity of the network.

As an illustration, if an active switch were to allow arbitrary C programs to be executed, then there would be scope for many attacks, for example:

• Violating security by de-referencing arbitrary areas of memory.
• Denial of service attacks from untrusted processes flooding the network with packets, allocating large amounts of memory, or spawning large numbers of sub-processes.
• Service compromise by users acquiring unauthorised resources through the active elements.

In previous work we have developed a number of active network components, e.g. [KIRST98] (based on the UCB work in [AMIR95]) which are important in achieving a Quality of Service (QoS) for multimedia applications; many of these components require up-dating in view of recent advances in algorithms, architecture and protocols. As another part of our programme, we will implement some of these components in JAVA, ensuring the efficiency and safety of the active elements. Since we are prototyping within the JVM, it will be necessary to apply additional measures to ensure that the components are trustworthy.

Mere design of a language and implementation of components is not enough. As a final step we will deploy the active components, using multimedia applications from other projects, to demonstrate that appropriate Quality of Service can be attained, in a safe way. This deployment will include aspects of secure configuration management - which will investigate the advantages of using secure forms of CORBA in the activity.

1. Technical Approach

In the initial phase, network engineers and language designers will enter into a dialogue to determine the safety policies wished for within the architecture. As a result of this dialogue, we will obtain a better idea of the sorts of services needed in the active nodes. The policies to be studied will include:

• Application Level Routing The routing infrastructure is crucial to the operation of any switched packet network. After many years of struggle, the Internet has evolved ``correct'' routing protocols, and enough intra- and inter-organisational process so that the routing generally works (see [PAXSON97] for a discussion of just how well it works). Many of the Active Network proponents talk of enabling access to routing tables for the active programs, to enable the introduction of new routing protocols. This would appear to be inherently unsafe, and from a system design decision contravenes our incremental "don't break existing mechanisms'' approach.

• Packet forwarding Most switches currently only manage one queue per output link. With the advent of the Integrated Services and Differentiated Services Internet, switches will run different queues depending upon the required level of service.

• Location of key modules The accommodation of heterogeneity of audio/video and other real-time facilities will require a multi-tier approach factoring in multi-layer source coders, source-based adaptation, receiver-driven, layered multicast and transcoders. As a result, the architecture must accommodate various mechanisms for placement of active components such as transcoders and filters. The placement may be manually determined, based on design criteria with input from policy/pricing and user profiles from the bandwidth broker system; the placement may also be self-organising, driven partly by the automatic detection of sites of loss after a system of self-organising receiver-driven layered multicast. The mechanisms for such self-organising placement have been proposed by Kouvelas [KOUVEL98], by McCanne [MCCAN96], and by work from Vicisano et al. [VIC98].

The algorithms for forwarding based on service profiles are fairly simple. Basically they are centred on the services provided by Committed Information Rate Frame-Relay or ATM CLP/ABR with MCR-like facilities, and capitalise on recent advances on measurement-based admission and network pricing theory. Various approximations exist for the admission tests and schedules [JSD97]. This ends up being a specification of service profiles; these are implemented at the ingress (or egress) to any "area", where an area can be a backbone or an access net or whatever. The service profile is "accessed" simply by the "user" (which could be ingress router, or source host) setting the IP precedence bit. If low delay is needed also, the TOS bit must also be set appropriately; the rate requested determines the service profile (and therefore tariffs, if appropriate). There are big differences between the model different people have devised; it is these differences which will be studied experimentally.

There are a number of different layers of security required for this project. Some of those needed are described below:

• Confidentiality and Authentication of conferences;
• Security for streams in the gateways;
• Secure configuration of components like relays
• Secure and authenticated requests for QoS;
• Secure operation of Proxylets.

Each of these is treated somewhat differently.

PKI Fundamental to the security architecture is a Public Key Infrastructure (PKI) as it is being addressed in the IETF. We expect to get the PKI itself mainly from the ICE-CAR project, and partly from a continuation of our present DARPA project, which is just being considered by DARPA. ICECAR is starting in January 1999, and lasts for two years; the DARPA extension is scheduled to start at the beginning of 1999, and last one year. These projects will provide the basic components for security like Certification Authorities, Revocation infrastructure, cross-certification, secure depository (mainly secured DNS, but also secured Directory), and smart card support.

IPSEC/IKE Another key component is IPSEC and its concomitant key exchange mechanism. We will obtain these in any case from the COIAS project in which we are participating; here an IPv4 IPSEC is now available, and an IPv6 version should be ready by May 1999. We would hope to obtain also the IPSECs from the CAIRN projects, but export controls may make this route difficult.

Depositories Many of the applications require Host authentication; for these the use of IPSEC is ideal. There is no problem in locating Host certificates in a secure DNS. It is also possible to locate personal certificates there; there is still some controversy whether this is a correct use of the DNS, and some would prefer personal certificates to be located in a normal Directory, with LDAP access. We will have both mechanisms at our disposal. In fact many of our personal security, and some of the Host ones, will be located on smart cards. This will improve the usability of the systems, though it will not provide functionality that would not be available via software.

Secure Conferences For secure conferences, it will probably be desirable to encrypt them in the normal way using IPSEC; this will require both a modification from the way we are currently doing this, and a finalisation of secure multicast. Secure announcements and Invitations are application level functions; we are not yet sure whether these are not best carried out with User-level certificates and application-level functionality.

Security in Relays There are many ways in which to approach the security of and in relays. There must be a secure management path; this is a host-level activity, and the standard IPSEC operations may be used. It is possible that we will experiment also with secure CORBA; this would fit in with some recent activities we have carried out in controlling network elements by CORBA. In addition there must be secured media paths. It will be necessary to decrypt/re-encrypt media streams, in order to do transcoding and filtering; thus the relays must be trusted. They do not need, however, to be trusted too much. They may be provided with a session decryption key by an end-user or a session manager, and can then re-encrypted using a pair-wise defined key. It will also be necessary to sign and authenticate any of the mobile code loaded into relays.

QoS and Security Policy Modules Both QoS and Security require requisite policies. It is probable that many of the QoS modules and IPSEC will have policy databases associated with the implementations. These will have to be invoked at any attempt to apply QoS; because it is associated with charging and with potentially excessive use of resources, any such requests will have to be examined in the light of the QoS and security policies in force for the relevant resources.

We expect to use the above system to help the implementation of two components: a filtering and transcoding gateway and a QoS packet forwarder. The filtering and transcoding Relay/gateway [KIRST98] acts to provide optimal media streams between a portion of a network with reasonably rich resources and one with poorer resources. It achieves this by aggregating some media streams (e.g. audio), transcoding some media streams into different multicast groups, and filtering out certain packets by intelligent discard. At present these operations are static and receiver-initiated. Ideally they should be more dynamic, and should adjust to the traffic offered on the incoming side of the Relay relative to the current traffic capacity on the outgoing channels. It is important, however, to have security procedures in place in such a Relay, to avoid some of the threats mentioned earlier. In addition to some of the language constructs, these procedures will have to include packet authentication - both on the incoming and the outgoing packets, and the loading only of authenticated code.

Another demonstration of considerable interest is an investigation of how intelligent agents may facilitate large-scale use of audio I/O. This activity should include automatic cluster location, mixer placement and rate control of specific sources. This activity will use the 3D sound localisation facilities that have been added recently to the UCL audio tool RAT. It will then make novel use of speech recognition and administrative scoping of multicast groups to home in on interesting audio events.

Once the components have been implemented, it is necessary to deploy them in different realistic environments. This activity has a number of facets:

• The components must be embedded into one or more AN environments which are being developed in other phases of the DARPA Active Network programme;
• The complete components, including both their policies and mechanisms, must be deployed over different environments. Here both the richness of the testbeds available to us (cf. Section I) and the major uses being made of multimedia services give us an excellent proving ground.

An important aspect of the work is to understand both the performance of the AN components, and the reasons for any problems. Here packet loss and delay are the major factors responsible for the poor quality of network services. Thus to characterise and quantify the quality of service, packet loss and network conditions in general (routing, delays etc.) have to be monitored and various parameters have to be measured and analysed.

Real-time multicast traffic is UDP based and therefore unresponsive in times of congestion. In point-to-point TCP traffic, end-to-end measurements can give a clear indication of the perceived QoS. By contrast, the point-to-multipoint nature of multicast traffic, and the heterogeneity of the different paths from a source to destination, make it difficult to characterise the quality of a service based on IP multicast. Moreover routing behaviour can have a profound effect in the multicast case depending on the size of the multicast group. These facts make it essential to measure and monitor network dynamics in the multicast case, if one wishes to understand the performance and impact of AN components. Luckily a number of our colleagues (e.g. Fenner at Xerox PARC, Jacobson at LBL, Thaler at Merit and Stewart at CRC) have developed utilities like mtrace (multicast traceroute) and routing data analysis routines which will allow us to discover the congestion points and to locate losses. Analysis of data coming from mechanisms like RTCP reports can be also helpful. Packets belonging to specific multicast flows will be recorded at all the member sites to allow for a more accurate view of the various parameters and for correlation between different sites. Loss rates, bursts of losses, packets out of order, duplicates, corrupted packets and other pathological network conditions will be discovered in this way. We are also deploying the OpenView/NetMetrics system, which allows the analysis of performance and losses on single sites. Both the SNMP data both from routing MIBs and that from LAN and WAN probes will be used to collect the data.. We expect this combination to allow us to quantify the performance of the components of WP4.

Another interesting application of the UTG and of our component architecture is an investigation of the functionality required to control and aggregate data from a large number of audio devices in a hierarchic organisation. This will include mechanisms for clustering such sources, homing in on ones of interest, visualising the resultant flows. This application is expected to use the UTG Relay mentioned above, and hence is related to that activity - but is significantly different. Considerable more detail is provided in WP5 on this topic.

We envisage a two-level architecture, with information sharing between the levels – the Dynamic Proxylet Servers and the IP Routing levels share information about topology, load and policy.

In the systems architecture, we assume an Internet that features a partial deployment of best-effort, differentiated and integrated services. The differentiated services will utilise Bandwidth Brokers; the Integrated Services will assume RSVP and RSVP Policy Servers. Security services, using both IPSEC and application level security, will provide the potential for various types of access policies and billing in different regions. Both the pieces of code placed manually and those placed automatically can be heterogeneous. These proxies will, at least initially, have parts written in Java, and parts written in C/C++ so that there is danger of causing network damage; this problem is addressed below.

We will address the general problem of scaling in large-scale service environments in two ways:

We divide the services into network level services and application level, and use the proxylet architecture to build systems that scale beyond the capability of network layer functions. We divide the network into administrative domains (recursively if necessary) and envisage that the application level services will manage the boundaries between intra-domain and inter-domain, where there are often discontinuities in the types of network-level support available. Examples of such boundaries are: multicast, best-effort to integrated or differentiated services, free to usage-charged services, and wireless to fixed network edges.

To scope the project and work, we will look at the following specific services; some of these items are already partly underway due to other project funding (e.g. HIPAPRCH, LEARNET, BT studentships etc)

Basically, a lot of these map into application level multi-metric routing. It is important compare the efficacy of doing this at the application level, or at the network level, with respect to throughput, delay and error resilience, and can see what the relative management complexity is for constraint-based versus self-organised application-level and network-level path selection.

The key difference between this application level routing and, say, email routing, is that non-trivial transforms can be applied to traffic as it passes through a proxylet. This means that the application-level route decision must also include load in the proxylets themselves. To some extent, the topology of proxylet placement might be managed - particularly for inter-domain - more through configuration and policy than through self-organisation. Nevertheless, when more than one proxylet path is available, the choice of which to use must be self-organising, particularly for load balance - though also for fault-tolerance reasons.

Here the main activities will be the integration of a number of activities that have been developed in other projects.

• Integrate HIPPARCH Receiver-Driven Layered Congestion Control work
• Receiver-Driven Layered Congestion Control ([RLC98]) is a scheme for providing reliable multicast services to large-scale applications; it has limitations since it exploits IP multicast heavily. However, it is useful for software distribution, tele-presentations etc. within a domain. Algorithms developed in the HIPPARCH project will be integrated into this system.

• Dynamic Reservation Protocol

Dynamic Reservation Protocol (DRP) has been developed by Paul White [HPN98] as part of a BT-sponsored activity in developing a sender-based, re-negotiating signalling protocol. This is written in Java, and would make an excellent adjunct to best-effort services and possibly an interesting contrast to RSVP at the boundaries of regions that support int-serv or diff-serv, or regions that are over-provisioned (e.g. within a campus) and need no reservations.

• Contrast Configured Trees with Self-Organising Transcoders

Self-Organising Transcoders (SOT) were developed by Kouvelas for his PhD [NOSSDAV98]. Self-organising transcoders use a mechanism that is based on multicast - it would be interesting to contrast this with configured trees.

• Develop a Network/Neighbour Status Monitor proxylet

We need an agent that monitors network conditions and feeds this data In a generic form to all the other interested proxylets since they need this data to self configure, at the application-tree level. Metrics for application-level routing could include throughput and delay; it should be subject to authorisation, obligation and pricing policies. This work item will take on board work on the HOPS project at UCLA and USC.

We need a naming service! Particularly for mobile and multicast applications, we need to be able to provide scaleable dynamic naming and location services. These will be internal services to the dynamic proxylet system, and support the higher level services as well as applications themselves. We will either develop one, or adapt one of the others developed in DARPA projects.

• Security Services

These will include the following:

• Digital watermarking for multicast [WATERCAST] is a recent application level active service devised at UCL for discouraging mass copying of multicast data. More important, we must specify mechanisms that will instantiate proxies to perform the actual work.

• Testing will have to be very thorough to reduce damage from new versions.
• In the deployment, the proxylets will include signed code and a secure means of naming and starting.

• Version management proxylets

Version management proxylets (mapper between versions) may be useful! It is possible that this might just be a feature of the naming service, as in ODP.

• Inter-Domain Proxylet Services

In intra-domain part of this work, we are mainly concerned with the interface between network level solutions, which will in general scale to the size of the domain, and the proxylet/application level active components. In the inter-domain, things are quite different. It is here that we believe the power of our approach will make itself most visible. The edges of domains are where there are transitions in control and performance. Borders are where the rules and costs for access to services and resources change. The best mechanisms for interfacing between the policy systems and the applications are themselves application level mechanisms. Since we will have application level hooks in our applications for intermediate nodes (proxylet servers and so on) to interwork, we will be well placed to build these services properly.

Here we are more concerned with edge effects - policy and price are critical components here:

• Policy agent – this is an agent that interfaces between an application and the policy services (e.g. RSVP policy, via RAP or COPS, route policy via BGP, price policy and so on). This is largely transparent to the distributed application, but may involve interfaces back to the end user (e.g. for authentication and billing).
• Price agent – this will interface to bandwidth brokers and other components.
• Multicast QoS price – there is as yet no good model for QoS for Multicast – for example what is the price of a multicast tree? It is dependent on the type of tree – heterogeneity makes this a particularly difficult problem
• Edge wireless/wired net converter proxylet – there are a number of protocol problems at the impedance mis-match between fixed and wireless networks, for example TCP and other end-to-end protocols often need some assistance to operate efficiently. This proxylet would be dynamically invoked at such boundaries to carry out this protocol task. This is not novel (protocol boosters and snoop agents already exist) but the seamless incorporation of it into this architecture will be an interesting piece of the work; we may be able to get some handle on billing for such assistance.
• Certification authorisation agent - within a domain, trust may allow simple authentication. Between domains, we need some sort of vouching service – typically, this is either PGP chains of trust, or else a formal certification hierarchy. We can investigate here how to integrate both schemes with a transparent proxylet service at the edge of each domain.
• User location service – wide area user and service location are quite different from the intra-domain case. Some techniques (scoped multicast search) do not scale (they take either too long, or send to much wide area traffic). The inter-intra boundary is the natural place to self-organise a set of servers that provide a transparent switch between a multicast/search model, and a directory based approach. We will look at how such services are structured to provide a transparent changeover in search styles.

We get more scale out of the applications for ANY scale of what can be done in IP extensions (multicast, PGM, mobile IP, IPSEC, Diff Serv etc) by doing some work at the application level. Intra-domain we do things mostly using IP (ng) features and proxylets, and some intra-domain meta-proxylet that measures performance. In the inter-domain, we need to use some more robust techniques to build proxylets...

The keys used for this signing and vouching may well derive at least in part for those used to choose a Differentiated Service Profile, or an Integrated Services flow specification, since these will need to be signed if they are to be charged.

Duration: Month 0-18

Effort: 12 mm

Deliverables: D1 Report on system architecture and on security facilities.

Activity Using IETF IPPM techniques, but applied in this two-level architecture.

Duration: Month 1-24

Effort: 6 mm

Deliverable: D2.1 Final documentation

Earlier in this proposal, we mentioned the need to place active code at key points; there is still need to locate such points dynamically. UCL has work both on the components that might need to be made active and on mechanisms for locating them. Some of the components that are needed are the following:

1. Relays that allow stream aggregation, filtering and coding;
2. Proxies which deal with reliable multicast establishment;

The layered coding work in RAT with transcoders [KOUV98], and the Universal Transcoding filter developed by Yang [KIRST98], based on earlier work by McCanne's group in UCB [AMIR95], are early versions of the first. This component will have to be extended considerably under this WP, to allow it to adapt dynamically. Two other components which will be developed further for the above are our developments of extended versions of VIC with SAIC and our semi-reliable multicast FEC layered protocol which have been deployed on the CAIRN and in Europe,

In parallel with the need for applications to be adaptive, while still supporting heterogeneity of senders, receivers and links, we would like to look at heterogeneity of network services. There are at least 3 types of network service we envisage this work addressing:

1. Best effort - the current Internet service. The work in WP5 will mainly be in this context.
2. Integrated service - using RSVP and Controlled Load or Guaranteed Service, one can request (including heterogeneity of receivers through RSVP filters) a fixed guarantee of some performance parameter. However, if some of the network provides this level of service, and some does not, then we need to accommodate a mixture of adaptation and non-adaptive applications - this needs to be factored into the self-organisation of filters in WP4.
3. Differentiated Services - using User Profiles, installed long term (in advance), one can provide simpler support for less dynamic guarantees, some of which may involve over-subscription.

In addition, emerging work in the IETF on Differentiated Services implies that the levels of aggregation of flows need to change as one moves from the "edge" of the network towards the centre. An activity related to the above, which will be studied is the mechanisms for differentiating and integrating traffic at routers. The traffic is alternately marked (with diff-serv bits) and policed (and the bits are cleared and the traffic treated differently, if out of profile).

Clark [CLARK97] proposes the service profile allocation approach, while Van Jacobson presented some complementary ideas (see [JAC97], Kalevi [KAL97] presented a "Simple Integrated Media Access" We will compare the models of Jacobson and Clark. A key question that we will examine is how adaptive distributed applications implemented using the language based AN approach can incorporate heterogeneity of the policing function as well as the signalling and admission functions. For example Van Jacobson's scheme drops all packets above the service profile rate (so if you pay, but the net is NOT congested, you do not get more than you paid). For aggregated TCPs down such a pipe, this is not a problem, but a single TCP may not get good utilisation on this scheme (the goal is to create a disincentive for people to use the premium scheme during light load periods anyhow!). Clark/Wroclawski's scheme can do this, but can also specify a "TCP rate", which then implements a complex filter/policy at the ingress, that "understands" TCP dynamics. It only drops packets for non-conforming TCPs (i.e. if TCP does slow start and congestion avoidance. Their scheme for that particular profile will allow a saw-tooth variation (not just a leaky bucket or burst tolerance, but a shaped burst tolerance!) - the details were unclear on how to make this go fast, but there are some nice simulations. We will study the main problem with not dropping packets that exceed the service profile - namely what to do with them - in Clark's scheme, the precedence bit is cleared. This has the problem that they then _compete_ on an equal footing with non-premium packets, and so can cause congestion down stream - another problem is that they can arrive out of order with respect to the premium "in-profile" packets. The QoS routing people really like both schemes, since they can be implemented in 2 queues, (or maybe 4) and scale nicely (the nearer the backbone router, the less things have to be policed). We will consider how these schemes relate to RSVP. RSVP might be used to "install" profiles, although its more likely to be just a subscribe-time service. For alternate path QoS routing, it is also neat, since one only has to add mechanism for distributing 2 (or 4) sets of destination (or for multicast, source) based routes, which means it scales well.

Here we will upgrade the UTG, with its component filters and transcoders mentioned above, to allow it to be controlled more flexibly. We will design a Reliable Multicast Proxy (RMP), which can be used for those services that require reliable multicast for operation; these may be located near the UTG, but may be located at a more significant location on the system. We will also study how components can be built so that their main processing engines can use legacy code in standard languages, while their control functions are written in the server system language. In this work will look also at the APIs between the system and the signalling and policing functions for int-serv and diff-serv. We will also take into account the requirements for security in the management of the components, in the need for authentication in requesting service, and the need to provide confidential services through the active components.

Duration: Months 0-12

Effort: 12mm

Deliverable 3.1 An upgraded version of the UTG and RM proxy suitable for more flexible control, and where necessary, security functionality.

Deliverable 3.2 Report on RMP design and on Control APIs

The control functions of a number of applications, including the Robust Audio Tool (RAT), and a video tool (e.g. VIC) will be modified to work with the new system. We will also implement the actual codecs for some simple coding schemes, and will compare the performance of the hand-coded and automatically-generated systems.

We will implement the UTG and RMP components of Phase 1 into an AN environment , in the presence of heterogeneous network service provision. We will also investigate the algorithms required for self-organisation of the control. To the extent possible from the progress of WP3, we will use the server's language in the key control functions.

Duration: Months 13-24

Effort: 12mm

Deliverable 3.3 AN version of the UTG suitable for deploying as an active component

Deliverable 3.4 Report on algorithms for self-organisation of the UTG and RM Proxy

Here we will look at the long term feasibility of implementing the policing functions of the components themselves a part of the AN system, so that they are adapted appropriately to the application instead of the ad hoc approach used by Clark/Wroclawski to address a particular TCP implementation characteristic. We would hope to be able to implement both a dynamically re-locatable, and active component that can be deployed experimentally.

Duration: Months 1-24

Effort: 24mm

Deliverable 3.5 AN version of the UTG and RM proxy suitable for self-organising deployment.WP4: Experiments and Deployment

One prerequisite for an experimental programme is an appropriate network and computing infrastructure. While various other projects support our work with LEARNET and SUPERJANET, it is this project which will underwrite our activities with CAIRN and the ABone. Some effort will have to be devoted merely to maintain the interconnection of networks indicated in Section I. Moreover, we expect this infrastructure to be maintained not only for this project, but also for other related activities. For example, we have indications that Lancaster U. and UUNET would like to use the same infrastructure to help in their deployment activities using the 6Bone, and that the new CISCO laboratory in the UK would like to use the same facilities in their collaborations with CAIRN partners. In each case the other parties would meet the cost of connecting to UCL, but the maintenance of the UCL-CAIRN infrastructure facilities would be part of this project.

As part of the experimental infrastructure, we would also mount the various measurement and monitoring packages mentioned in B2. We do not expect to undertake a significant effort on individual packages; however, putting up the different packages so that it is possible to get meaningful and complementary information from them will require considerable ongoing activity. Luckily not all this work will need to be charged to this project; some is required by, and will be supported under, the LEARNET and MECCANO activities in which we are also engaged.

At several places in this proposal, we have mentioned the need to add authentication, access control and security to the AN components - and to the processes accessing them. The experimental deployment of such facilities implies also the deployment of a security infrastructure. Here we will rely heavily on the work of the ICE-CAR project, in which we are also engaged; here we are putting in an infrastructure for secure multimedia conferencing. In this project, the ICE-CAR facilities will be extended to the additional needs of AN components.

During the period of this project, we expect that the experimental deployment of IPv6 will become of increasing interest. While we do not expect to undertake major implementation activities with IPv6 code, we do anticipate integrating it into different components being deployed. In view of the experimental nature of such code and its environment, we expect this activity to take considerable effort.

We have found the mounting and running of distributed experiments very time-consuming and frustrating, because of their dependence on others mounting the necessary modules on their systems. We would hope that the advent of the mobile code implied by the AN, will make it possible to mount such modules remotely. Some effort will be devoted to the mechanics of achieving these goals.

As part of the experimental programme, a policy configuration system will be written using the system and local policy managers implemented at each active node. This system will interact with authentication systems and bandwidth brokers (from the LBNL DOE project work) and with the layered multicast applications above. The performance of the overall system will be evaluated through trials and measurement.

Finally, we will undertake a number of application activities such as multimedia conferencing, collaborative seminars and remote media access. These applications will not be developed under this project, but will be imported largely from MECCANO and other projects in which we are involved (with most tools not written by UCL). We will introduce the different AN components mentioned in WP4 into the concatenated system, and undertake a systematic programme of evaluating performance both of the AN components and the applications. These will be used to propose improvements to the developers. In this work we expect to introduce not only components arising from our activities, but also from others in the Active Networks and related programmes.

Duration: Month 34-36

Effort: 18 mm

In most large-scale multicast conferences, the distribution of participants across the network is not random. Rather they are clustered in a number of "interesting'' locations which have a high density of participants, and other regions with few participants. The media stream from each source propagates to all other participants, where it is mixed with the other streams for play-out. There are a number of limitations with this simple system, in particular excessive traffic flow and lack of discrimination of multiple sources. Excessive traffic flow occurs because multiple audio streams flow from clusters of sources to a receiver, where they are mixed into a single stream for play-out. If the mixing could be done "near'' to the cluster, a single stream could flow over the wide area link, reducing the bandwidth requirements of the conference.

Previous work [cf. Kouvel98] has considered the self-organising placement of transcoders in the network to adapt to differing bandwidth availability. It is believed that this can be extended to the placement of mixers within the network. Lack of discrimination of multiple sources occurs because of the mixing process, and the monophonic nature of typical sources. The addition of three-dimensional spatial sound would allow these mixed sources to appear to emanate from different positions in space around the listener, easing identification.

The combination of these mechanisms provides a novel approach to monitoring a large number of active audio sources, whilst maintaining efficient use of bandwidth and effective source discrimination. Source clusters are determined and a mixer placed within each cluster, sending the mixed audio from that cluster to the wide-area session. The non-mixed audio is also transmitted wide-area, but initially no receiver joins these groups, hence the traffic does not flow anywhere. At each receiver, these mixed streams are spatialised and mixed, allowing for cluster discrimination. If one particular cluster is of interest, the receiver leaves the mixed group, and joins the group with the traffic from the individual sources. These can, once again, be spatialised as required. For some applications speech recognition on the cluster may be a desirable facility.

Another aspect of the monitoring is the decision process on whether there are events of interest in the multiplexed stream. For many purposes this is the case whenever the multiplexed audio signal is above some background level. However for some purposes it may b when some trigger phrases are recognised in the multiplexed stream. We will investigate the use of a speech recogniser scanning the multiplexed stream continually. We will not develop such a recogniser; there are many already available from other projects. It is also not necessary that the recognition be very good at first instance. The use of the recogniser should first indicate that it is worth examining the audio source more thoroughly. By moving along the multicast tree towards the audio source, we will be able to examine it more thoroughly.

This placement of transcoders could be used even if the sources are in islands of high bandwidth, connected to the groups interested in monitoring the sources by lower bandwidth links. Both the aggregated and the individual links would be in the high-bandwidth island; only the reduced bandwidth aggregation is passed through the lower portion link until domains of interest are encountered. At that point, only the sources of interest are passed through the narrow bandwidth links.

We hope to investigate also additional: ways of visualising the clustering and navigation around the space. This links well into Virtual Reality work being done in the Department.

There are several novelties in this approach. These include the following:

• Automatic and self-organising placement of mixers, which extends our earlier previous work, and links into the active service framework coming out of UCB.

• Use of three-dimensional sound to visualise network topology.
• Addition of speech recognisers with an increasing precision
• Ways of visualising and navigating through the three-dimensional sound space.

Duration: Months 25-36

Effort: 12mm

.

2. Deliverables and Proprietary Claims

 

We make no proprietary claims to any of the work undertaken in this project. The work may, of course, use Background information and Components deriving from other parties. Wherever such components are under our control they will be made freely available to the US Government and its contractors.

 

We will make available on a WWW Server the system software and some example applications, plus papers that document the results - including the relative performance. A detailed set of Deliverables has been associated with each Work Package.

 

 

 

3. Statement of Work (SOW)

• The architecture of the RADIOACTIVE System will be designed.
• The system will be designed, specified and implemented. The system will be proved typesafe.
• The system will be used to implement two sample application systems, for delivering audio and video to receivers over a heterogeneous network, with partial support for resource reservation and class of service.
• An infrastructure will be refined to allow these activities to be carried out collaboratively between US researchers, those on this project, and other UK groups collaborating with US DARPA-sponsored ones on CAIRN.
• A measurement and monitoring infrastructure will be set up to allow detailed assessment of the performance of the components under conditions as carefully controlled as we can devise.
• The component security facilities will be deployed in a way that can be integrated with an experimental security infrastructure.
• A collection of experiments will be carried out to evaluate the efficiency of the system in comparison to traditional approaches.

2. Schedule and milestones for the proposed research

 

Y1 Q1 Initial Architecture specification - Report

Y1 Q2 Initial implementation - Code

Y1 Q3 Specification of interfaces to network level resource maagement - Report

Y1 Q3 Specification of interfaces to network level authentication - Report

Y1 Q4 Prototype applications

Y1 Q4 Manually implemented distributed filter-based heterogeneous audio tool. - Code

 

Y2 Q3 Manually implemented RLM based video tool with transcoders - Code

Y2 Q3 Audio tool in Language - Code

Y2 Q4 Initial Design of Distribution Algorithm - Report

 

Y3 Q1 Experiment Specification - Report

Y3 Q2 Experiments and Analysis - Report

Y3 Q3 Report on Experiments - Paper

 

3. Technology Transfer

 

The applications and system will be made available to researchers free of charge, and to DARPA's collaborators. The resulting systems will be available for commercialisation through two possible paths - direct work doing technology transfer with the research organisations, or through PhD students and research staff leaving to join the relevant companies. Papers will be submitted to the relevant journals and conferences - the project proposers have a long history of collaboration and publication in both the networking and programming language communities. We will capitalise on this to make sure that the work has high visibility.

 

4. Comparison with other ongoing research

 

The ABone is the virtual network connecting sites involved in AN research. We plan to install ABone nodes at UCL and in partner sites on the CAIRN and on LEARNET. We plan as one of the first group of institutions to develop AN technology within Europe to extend the reach of the ABone. We have been tracking the AN mailing lists for some time.

 

Of existing work within the AN community, the Switchware project [GUNTER97] at Penn U. is mostly closely aligned with our work. They are producing a two-level architecture based on strongly typed languages. The PLAN language [HICKS97] is based upon a subset of ML with the addition of primitives to support remote execution. The language provides only primitive recursion and so guarantees termination, but does not allow the accumulation of state except through use of special system primitives

Netscript from Columbia is a dataflow language to glue together data streams into the appropriate filter primitives [YEMINI96]. It is an object oriented scripting language and so would be more akin to TCL than to a strongly typed language.

 

MIT [WETHERALL98] are basing their work upon Java with its attendant level of safety.

Bhattacharjee et al. at GSU [BHATTACHARJEE97] are providing hooks into switch supplied and controlled functions, rather than providing full programming environment.

 

BBN has defined two programming languages, "Sprocket" a high-level language rooted in C that compiles to "Spanner" an intermediate language that assembles into a small footprint, so that the programs can sit inside a single packet [JACKSON97]. Spanner is a CISC-style stack based assembly language with high level types for the operands. Both Sprocket and Spanner perform type checking at compile and assembly time, respectively. Additional safety relies on cryptographic authentication of the incoming packet, run-time authorisation of the program, and a "sandbox" virtual machine environment which checks the types of arguments before instruction execution and limits the program's access to node resources.

Other work outside of the AN scene of relevance includes Spin [BERSHAD96] which is an extensible operating system which allows users to download code into the kernel. An operating system faces many challenges common to those facing ANs. The language chosen by the Spin designers is Modula-3 which is a strongly typed language with its automatic garbage collection, and known denotational semantics for a Modula-3 subset [ABADI94]. The type checking of the Modula-3 compiler is used to ensure domains of protection at the level of binding names for access to objects.

 

References

ABADI94 Martin Abadi, "Baby modula-3 and a theory of objects", J. Functional Programming, 4(2), April 1994.

 

AMIR95 E Amir, S McCanne & H Zhang, "An Application Level Video Gateway", Proc. ACM Multimedia '95, San Francisco, CA, November 1995.

 

BENTON93: N. Benton, G. Bierman, V. de Paiva, and M. Hyland, "A term calculus for intuitionistic linear logic", Proc. Int. Conf. Typed Lambda Calculi and Applications, 664, LNCS. Springer-Verlag, 1993.

 

BERSHAD96 Brian Bershad, Stefan Savage, Przemyslaw Pardyak, Emin Gun Sirer, David Becker, Marc Fiuczynski, Craig Chambers, and Susan Eggers, "Extensibility, safety and performance in the spin operating system",. Proc. 15th ACM Symposium on Operating System Principles (SOSP-15), pages 267-28, Copper Mountain, CO, 1996.

 

BHATTACHARJEE97: Samrat Bhattacharjee, Ken Calvert, and Ellen W. Zegura, "An architecture for active networking", High Performance Networking (HPN'97), White Plains, NY, April 1997.

 

FERREIRA96: W. Ferreira, M. Hennessy, and A.S.A. Jeffrey, "A theory of weak bi-simulation for core {CML}", Proc. ACM SIGPLAN, Int. Conf. Functional Programming, 201-212. ACM Press, 1996.

 

CLAR97: D.D. Clark and W. Fang, "Explicit Allocation of Best Effort Packet Delivery Service", MIT Lab for Computer Science, http://diffserv.lcs.mit.edu/

 

FHJ98: W. Ferreira, M. Hennessy and. A. Jeffrey, "Combining the Typed Lambda-Calculus with CCS", in Proof, Language and Interaction: Essays in Honour of Robin Milner, Ed. G. Plotkin and C. Stirling and M. Tofte to appear 1998, MIT Press

.

GIRARD87: J.-Y. Girard., "Linear logic", J. Theoret. Comput. Sci., 50, :1-102, 1987.

 

GHOSH98: A Ghosh and M Fry, "Application Level Active Networking", Proceedings of the

HIPPARCH 98 Workshop, http://www.cs.ucl.ac.uk/staff/jon/hipparch/fry.ps.gz

 

GHOSH98b: A Ghosh and M Fry, "Application Level Active Networking", to appear in Computer

Networks and ISDN Systems, 1999.

 

GUNTER97: Carl A. Gunter, Scott M. Nettles, and Jonathan M. Smith, "The switchware active network architecture", To be published in IEEE Network special issue on Active Nets

 

HPN98: "Dynamic Reservation Protocol" P White and J Crowcroft, Proceedings of High Performance Networks 1998, Vienna, 1998.

 

HICKS97: Michael Hicks, Pankaj Kakkar, Jonathan T. Moore, Carl A. Gunter, and Scott Nettles, "Plan: A programming language for active networks.", Submitted to PLDI'98.

 

JACKSON97: Alden W. Jackson and Craig Partridge, "Smart packets", Presented at 2nd Active Nets Workshop, March 1997

 

OGMP: Object Group Management Protocol: B. Leveine, C Diot, J Crowcroft, J Kurose, work in progress available from ftp://cs.ucl.ac.uk/darpa/ogmp.ps.gz

 

JEFFREY94: Alan Jeffrey, "A Fully Abstract Semantics for Concurrent Graph Reduction: Extended Abstract", Proc. {LICS} '94, IEEE Computer Society Press, 1994.

 

JEFFREY97a: Alan Jeffrey and Ian Wakeman, "A Survey of Semantic Techniques for Active Networks", Submitted to IEEE Network special issue on Active Nets.

 

JEFFREY97b: Alan Jeffrey, "Semantics for Core Concurrent ML Using Computation Types", Proc. Higher Order Operational Techniques in Semantics, Ed. Andrew Gordon and Andrew Pitts, 1997

 

JSD97 S Jamin, S Shenker, P Danzig, "Comparison of Measurement based Admission Control Algorithms for Controlled Load Service, in Proc INFOCOM ’97, pp 973-980, 1997.

 

KAL97: Kalevi and Kilkki, "Simple Integrated Media Access" <draft-kalevi-simple-media-access-01.txt>, IETF, 1997.

 

KIRST98: PT Kirstein, J Yang & CS Perkins, "Accessing Mbone sessions over point-to-point connections", Submitted to IEEE Multimedia Systems,1998.

 

KOUVEL98: I. Kouvelas, V. Hardman & J. Crowcroft, Network Adaptive Continuous-Media Applications Through Self Organised Transcoding, Proceedings of Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 98), 8-10 July 1998, Cambridge, UK.

 

MCCAN96: S McCanne, V Jacobson & M Vetterli, "Receiver-driven Layered Multicast", Proceedings ACM SIGCOMM'96, Stanford, August 1996.

 

NOSSDAV98: "Self Organising Transcoders", I Kouvelas, V Hardman, J Crowcroft, proceedings of the Workshop on Networks and Operating System Support for Digital Audio and Video, Cambridge, England 1998.

 

MILNER92: R. Milner, J. Parrow, and D. Walker, "A calculus of mobile processes", J. Inform. and Comput., 100(1):1--77, 1992.

 

PANANGADEN96: P. Panangaden and J. Reppy, "ML with Concurrency, chapter The Essence of Concurrent ML", Monographs in Computer Science, Springer-Verlag, 1996.

 

PAXSON97: V. Paxson, "Measurement in the Internet", PhD thesis, University of California, Berkeley, 1997.

 

PIERCE93: B.C. Pierce and D. Sangiorgi, "Typing and subtyping for mobile processes", Proc. LICS '93, 376-385. IEEE Computer Society Press, 1993.

 

RH97: James Riely and Matthew Hennessy, "A typed language for distributed mobile processes.", Computer Science Tech. Rep., Univ. Sussex, 1997.

 

RLC: Reliable Multicast Protocol from the HIPPARCH Project: Source code in C and Java for Unix, Windows and for ns available from http://www.cs.ucl.ac.uk/staff/l.vicisano

 

SANGIORGI93: D. Sangiorgi, "From pi-calculus to higher-order pi-calculus --- and back", Proc. TAPSOFT '93, 668, LNCS. Springer-Verlag, 1993.

 

VIC98: L Vicisano, L Rizzo & J Crowcroft, "TCP-like congestion control for layered multicast data transfer", Proc. IEEE INFOCOM'98.

 

WATERCAST: "Watercasting: Discouraging the disclosure of multicast media", work in progress, available at ftp://cs.ucl.ac.uk/darpa/discast.ps

 

WETHERALL98: David J. Wetherall, John Guttag, and David L. Tennenhouse, "Ants: a toolkit for building and dynamically deploying network protocols", Proc. first IEEE Conf. Open Architectures for Signalling, San Francisco, CA April 1998.

 

YEMENI96: Y. Yemini and S. da Silva: "Towards programmable networks", Proc. IFIP/IEEE International Workshop on Distributed Systems: Operations and Management, L'Aquila, Italy, October 1996.

 

5. List of key personnel

 

The principal academics who will be associated with this work are Profs Peter Kirstein and Jon Crowcroft. Both have been working in the areas of the proposed research for many years. Recently Jon and Peter have been developing mechanisms for supporting and utilising multicast multimedia both in the context of DARPA activity on the CAIRN and European Research projects over European high-speed networks. Both Jon and Peter have been directing a number of recent DARPA projects including: Supporting Internet Multicast Multimedia (D-079, 1996-98)

 

Peter Kirstein

Peter Kirstein received his undergraduate degree in Maths and EE at Cambridge University. He also has a Ph.D in EE from Stanford U., and a D.Sc from London U. in the same subject. Peter has worked at Stanford U. (USA), CERN (Switzerland), and the US General Electric in (Switzerland). He is now Professor and Director of Research in the Department of Computer Science at University College London. Professor Kirstein has been leading research projects in computer communications networks, Telematics services, mobile communications, security and multimedia for over 20 years. Most of his current research projects include collaboration with European and US colleagues. Amongst these activities are developments in multimedia, mobile access and security applications, and piloting them in the international Research Community.

 

Peter has a number of projects in the high-speed network and multimedia area. He is Director of the CEU-sponsored MECCANO project to pilot multi-way, real-time multimedia services in Europe with links to the US and the ICE-CAR provision of a European security infrastructure. This work arises out of other activities he has been conducting both with DARPA and the CEU ACTS program in Network Management and Distributed real-time systems; which use the emerging ATM infrastructures in the UK, the rest of Europe and links to CAIRN. Peter is a Fellow of the UK Royal Academy of Engineering, the British Computer Society, the Institute of Physics, and the Institution of Electrical Engineering. He is a Senior Member of the Institution of Electrical and Electronic Engineers. He has over 160 publications.

 

Professor Kirstein is also Director of the European Commission MECCANO project, and is co-PI in the European Commission ICECAR and COIAS projects. He also is co-PI of the British EPSRC PIMMS project. He will spend 20% of his time on this project.

 

Jon Crowcroft

Jon Crowcroft is Professor of Networked Systems in the Department of Computer Science, University College London. Here he is responsible for a number of European and US funded research projects in Multi-media Communications. He has been working in these areas for over 15 years. He graduated in Physics from Trinity College, Cambridge University in 1979, and gained his MSc in Computing in 1981, and PhD in 1993. He is a member of the ACM, the British Computer Society and the IEE and a senior member of the IEEE. He is a member of the IAB and general chair for the ACM SIGCOMM. He is also on the editorial team for the ACM/IEEE Transactions on Networks. With Mark Handley, is the co-author of WWW:Beneath the Surf (UCL Press); he also authored Open Distributed Systems (UCL Press/Artech House).

 

Professor Crowcroft is co-PI in the European Commission FlowThrough, HIPPARCH and COIAS projects. He also is Director of the British BT/EPSRC LEARNET URI. He will spend 20% of his time on this project.

 

6. Description of the facilities to be used for the proposed effort.

Inside the UCL-CS Department, we have a testbed facility consisting of some 3-4 Fore ATM switches, a WAVELAN installation, and two CISCO routers with ATM interfaces. These, together with some half dozen servers and workspaces will form the basis of our local testbed. It will be necessary to upgrade some of these facilities during the course of the work to remain compatible with other collaborating projects at UCB, ATT Research, MIT, ISI and SAIC. We work closely with the following: Steve McCanne and others at UCB; Mark Handley and Bill Fenner at ATT; Research; Dave Clark at MIT; Bob Braden and Alison Mankin at ISI; Steve Deering, Van Jacobson and Dino Ferrari at Cisco; and Ken Carlsberg at SAIC.

For wide-area connectivity, we have access to a number of service networks. These include the British academic network (SUPERJANET) and the European Research networks (TEN-155). While the medium-term status of the European networks is somewhat unclear, it is the current intention to provide Virtual Private Networks over the TEN-155 backbone to allow QoS activities for European research projects; UCL is co-ordinating, and is one of, the Alphatest sites. We are already funded for several qualifying research projects until at least FY 2001. These networks would be available for deployment of the results of this work, but only in a manner compatible with the service nature of these networks.

In addition, we are able to set up experiments on other networks which are provided specifically for research, and on which we are able to disturb performance. We have access to a high performance testbed using LEARNET. This is a dark fibre network connecting UCL, Cambridge U, Essex U. and BT Laboratories. We expect that an extension to NORTEL will be installed during the coming year. We will have access to at least OC-3 ATM on this network, though some WDM facilities at higher speed may become available. Additionally we currently have intermittent access to the CAIRN network on the East Coast via a T1 ATM link supported by NASA; a further, higher speed, Plink is being prepared to link into LBL via native IPv6 provided by UUNET with some DARPA support. This link is invaluable for the integration of our experiments with others in the CAIRN community; we hope that this link can continue at least at its present speed and possibly a higher one. We would be happy to have the link used to facilitate a broader research program linking LEARNET and SUPERJANET-III sites with the CAIRN; British Telecom is considering providing such a higher speed link in the context of NGI activity with LEARNET and the CAIRN follow-on, but we cannot guarantee the provision of such facilities yet.

For the purpose of this research we propose to add extra facilities needed in the UK to be part of the ABone. The connection from UCL to the Active Network collaborators in the US will be via the CAIRN or its successor.

The following budget is based on an exchange rate of 1 £UK to $US 1.7 and on stated inflation estimates. Figures are normally given in the currency in which they are incurred, or those relevant for the proposal. We base costs on a 36 months project, but it would be possible to achieve more limited objectives in a 24 month one. The project will require one full-time research fellow (RF) and one research student, substantial equipment, and considerable travel to the US to interact with related groups there. The Department and other projects will provide the majority of the equipment (servers, workstations, local and European communications). Nevertheless, we make provision to ensure that we are able to maintain our equipment compatibility with other DARPA-sponsored projects in the US, and for a travel budget to ensure closer liaison with those groups.

The budget breakdown is based on a 36-months project starting on April 1, 1999 and ending March 31, 2002.

Staffing costs are based on one full time staff member and one full-time student over the thirty-six months of the project at UCL. The UCL-CS Department commits to having at least two more senior staff members and three full-time students working in this area in addition - not charged to the project.

The staff members are costed at the customary 90% O/H rate charged by the Colleges. He/she is presumed to be at Pt 10 on our RA1 scale, with an increment due October 1. The salary costs assumes the normal one point increment each year, and a 3% cost of living increase. The research student is costed at the normal studentship rate, and attracts no College overhead. It is assumed that this will increase by 5% pa, including both cost of living and experience allowances. The salary costs include London Allowance, National Insurance and Superannuation.

CAIRN will require a new equipment base for its routers; in addition it will be necessary to upgrade the workstations and servers in line with the deployment in the related DARPA projects. Provision is made for $45,000 for equipment. On current costs, this will buy one high performance workstation for each of the workers and one router over the life of the project. We allocate about $11,500 pa to service all the equipment used on the project; this includes the large scale server used heavily on the project - but acquired independently, and one of ATM switches which will be used.

The project will have close links with IETF activities and other DARPA-related projects in the US; it will also continue to work with the International Collaboration Board, chaired by Prof. Kirstein. We have budgeted 2 trips to IETF meetings (1 person), 2 to ICB meetings, 1 trip to a DARPA Workshop and one to the DARPA PI meeting each year. Based on an average cost of £1200 ($1980) per trip, this would come to $34200. Since a few of these trips will be in Europe at a lower cost, we have taken a budgetary figure of $8.500 pa for travel. We will continue to use multimedia conferencing facilities in collaborating with researchers in the US and working group discussion in the IETF.

Recurrent Costs are assumed at the historic College rate of £2000 pa, with the research student assumed to operate at 50% costs. These costs include £500 pa for network access.

The costs of the proposed project (in $US) over a thirty-six month period are given below:

The breakdown of the costs by task and year is shown in the following table:

The way that this cost is distributed into fiscal years depends so strongly on when the project is funded to start, that it makes little sense to provide that breakdown at this time.