This is an outline for a 3 year program of work for UCL CS, Imperial DoC, Lancaster, the Unversity of Technology, Sydney, and BT, with possible inclusion of further sites after discussion (e.g. UKC, Sussex, etc).

Current proposers are:

The broad area of work is in programmable networks for telecommunications. Recent interest on active networks at MIT (David Tennenhouse et al) and at Penn State (Jonathan Smith) has resulted in a large body of work emerging from a DARPA funded program of work.

This has moved on at least 3 fronts

The area of interest for this work is mostly in c) and partly in b). We think that the questions of Turing halting problem mean that applying a) awaits some theoetical breakthroughs before it is applicable in mission critical services.

There are a number of area that could be tackled using the active network approach, and a number of baseline technologies that are applicable. Some of the work in this project would involve comparisons of the available and emerging middleware for programmable services.

Another important output would be a framework which would allow comparison of a) (for IPv4, IPv6), b) (for RSVP, Differentiated Services and for ATM signaling) and c) above. The work would however concentrate on c).

Here we outline three main areas of work:

The first is to establish a common middleware system for the partners. The second is to look at the trends in programmable networks and services. The last is the meat of the project for years 2 and 3.

Infrastructure and Rationale

This work would take a large part of the first year, and would entail selecting the technology and seeing implementing and deploying those extensions that are necessary between the partners (including BT labs).

We would observe that application level active networking middleware infrastructure does not just consist of:

We need to look at scalable naming and addressing architectures for maintaining transparency with network efficiency for mobile objects and for multicast delivery of events, distributeion of code and filters, and so on.

One promising technology we could look at here is Jini. Other active network technologes are emerging.

IPC mechanisms (e.g. reliable multicast RMI?) and so on will also be needed. Distributed, replicated factories and some form of performance monitoring and other mechanisms to help carry out experiments.

Trends

Distributed applications have need moving to a richer set than the traditional client server technologies of the 70s, 80s. In the 90s, we have seen streaming services emerge. Early statistics from NLANR show that realaudio growth in the internet in the last 2-3 years ressembles the growth of HTTP in the first 3 years of its life.

Applications are increasingly making use of the store and forward nature of systems which incorporate proxies such as WWW. Some filtering (for relevance, currency, pricing, etc) can take place at such a branch/merge point - this sort of technology lends itself to some kind of generalization. UTS work has already led the way with the concept of a proxylet here.

Caches serve a similar traffic function to multicast, but de-couple the requreiment for users to have concurrent requests. There are clver automatic tradeoffs that can be made here if users can be deferred - work under another BT project by Paul White has started looking at this. Howwever, inter-cache protocols (ICP and others) need to be made aware of such policies.

Mobility (nomadic users, wireless access) is likely to grow massively in the next 2-5 years - the effect of systems that mobile phone and PDA manufacturers are about to release (Ericsson, Nokia, Motorola, Symbian, and HP/Microsoft etc) will create much more diverse call patterns. The step function in capacity between wireless access (GSM at around 10Kbps, Bluetooth at 1Mbps, fixed wired networks at 10-100Mbps) means that distributed transcoders and filters are even more crucial to the operation of services.

Work Areas

Underlying the applications that users themselves use, we have applications that the network provider will use - these allow placement and dimensioning of servers as well as control of traffic and pricing. The list above is a set of areas of expertise that the partners bring to this proposal.

UCL will work on Host Proximity Services - this will allow dynamic selection of neighbours, based in some type of (Nimrod) map based path-vector distribution of information about current conditions in and around each server, flooded to all interested neighbours in a management domain. Collaborations with existing work by Lixia Zhang at UCL, Deborah Estrin at USc, Carl Malamud at MIT and Paul Francis at NTT will allow this work to progress rapidly in the standards arenas.

IC have a long standing expertise in policies in network management (and mangement of policies) - some of the technology developed under previous BT funding and other projects would lend itself to scalable control of access, as well as protecting the subtle service level agreements (Obligations) that may accrue when we deploy active services.

Lancaster have been working on video and other servers, as well as distributed filters and event notification systems, and have some work that naturally leads to future experimental platforms for performance measurements - these could be deployed on the IP(v4/v6)/ATM infrastructure there and at UCL and Imperial; We need to see where we can take this with UTS.

UTS has developed for BT a basic proxylet infrastructure to support Application Level Active Networking, and is currently working on issues of deployment and manageability within a provider domain. For the URI UTS will work on Dynamic Proxy Server discovery using application level routing, and dynamic construction of application level multicast. This is related to the Proximity Servecies work at UCL.

Non Work Areas

1 RF + Seek other funding for 1 PhD per site.

Start Date

Expected start, Oct 1999.

.UCL is engaged on work for BT in 3 main areas: firstly we are working in the URI on the management of protocol stacks within end systems. This work is focussed around transport protocol performance control through remote access from a management center to the key performance parameters in a protocol. The system can operate in a client and in principle, in a server, and can be added without re-building (or re-compiling) the application of operating system protocol stack. Remote access from Java RMI, Corba RPC and SNMP/CMIP are all possible. The next year will use feedback fro mthe Loughborough work which makes available detailed network performance statistics.

A second tier of UCL work for BT is in the area of pricing and perfoamnce management. The LEARNET project involves looking at feed-forward (signaling) and feedback (adaption) and the effect on application and user behaviour when this is coupled with pricing policies. The goal is to gain the same level of understanding of a users dis-satisfaction with the Internet’s gradual performance degradation under load, as that which we have about user’s concerns with high call-blocking probabilities and call drop out in POTS and the GSM phone networks.

The third aspect of UCL’s work with BT is in the trio of projects, HICID, JAVIC and HIGHVIEW, which are all concerned with the performance of workstation based IP audio and video tools based. JAVIC is centereed on interactive and combined tools. HIGHVIEW is more concerned with media on demand services, and HICID is using next generation router technology to try to control the performance.

As well as the BT funded work, there are a number of UK, EC and US funded projects at UCL that are relevant. Until recently, the HIPPARCH project has taken a long term look at protocol performance, and has evolved a novel multicast based web service with controllable performance for heterogeneous receivers. The Prospect and FlowThru projects have addressed management of subscription and business flow models in Internet and TMN combined services. The DARPA work at UCL makes use of CAIRN router technology to offer a range of integrated and differentiated services, with RSVP signaling. There is a mobile research group which has looks at a number f topics ranging from scheduling in base stations during handover, through to trust and authorisation models of use of 3^rd party wireless access services.

University College Work within ALPINE

There are 3 main areas of UCL work within the new project:

Current IP routers provide a very simple forwarding function, together with a complex route exchange and computation function. As we add further services such as integrated and differentiated services, mobility support, security and so forth, the control functionality concerned with both the routing and the forwarding function become more complex. Proponents of "strong AN (Active Networks") claim that, provided there are sufficient safeguards, distributed programs may be dynamically updated to create new services "on the fly". In this area of work, we would look at a parsimonious approach to adding programmability to routers. Based on work at Sussex University (ref: safetynet), we would design a low level VM that would interact with the baseline (unicast, multicast, mobile, qos)routing and forwarding functions, and allow combinations low level operations to make up higher level programs.

A key requirement of distributed application level services is the selection of the appropriate server from a pool in a scalable way. A Proximity metric can be delay, or throughput, and may reflect both network and application level performance. In this work, we would build the proximity service as a unification of two separate services, one host based and the other router based, to test some of the ideas in the first area. Applications such as load balancing of massively fault tolerant scalable web servers could be used to stress test this work. An additional factor to consider here is the effect of policy on the complexity of this service (can we just make use of ideas from BGP or RAP?).

One of the great strengths of the Internet is that a number of its functions are loosely coupled (naming, addressing, routing, congestion and flow control, to name but a few). This means that partial failures of the network do not bring the whole system to a grinding halt. It has its downsides, but assuming that we believe it is a good basis for doing things, this work would look at how we reflect this design philosophy in a programmed environment.

Currently, it is hard to express algorithms "in the large" such as OSPF, or WFQ/RSVP, in a single program; the convention is to express the program that specifies the behaviour of one peer at a time; we then rely on the ingenuity of the protocol designer that the system as a whole will work.

No current Active Network work takes this into account properly; there is great danger in letting programmers loose on network services with all the expressiveness of general purpose algorithmic specification languages, when the class of problems that can be realistically carried out in a very large scale are radically different than those that can be run in a single (or tightly couple multiple) address/CPU space.

Work Plan

36MM:

Application components are not limited to object-based request/reply interactions. We have defined a language, Midas [PC97], in which the programmer specifies interactions in terms of asynchronous message s and state machines. The use of Midas allows the succint specification of the various interaction styles required by a large distributed system, such as request/reply, event dissemination, bulk data transfer or media streams. Midas syntax is similar to the CORBA Interface Definition Language (IDL). It uses IDL syntax for constant, type and module definitions and replaces object interface definitions with definitions of interactions following the model described above. Midas also allows the definition of generic interaction styles, parameterised by type, and so does not need an Any type to represent untyped data.

Midas specifications are compiled into implementation language constructs, such as Java classes, that define the message interfaces and provide distribution transparency via proxy objects. Midas allows interactions to be defined independently of the implementation language and simplifies the task of the programmer by generating support for distribution transparency.

The runtime support generated from Midas specifications interfaces with the Regent transport subsystem. This subsystem provides an object oriented framework for implementing transport protocols. The framework takes a component-based approach: lightweight protocol layers encapsulate small aspects of protocol functionality and are composed into protocol "stacks" (actually directed graphs) in order to implement the required transport protocol.

Protocol stacks can be identified by composite names that specify the layers within the stack. These names can be "elaborated" by the Regent runtime to dynamically load implementations of the named layers into the node, instantiate layers and compose them into the stack described. References to distributed services contain these stack names, allowing servers and clients to evolve independently, making use of new transport protocols as they become available.

A protocol layer can also provide control interfaces through which higher layers can control the operation of the protocol. Control interfaces can also expose events to higher layers. To be notified of events occuring beneath it in the stack, a protocol layer must implement a compatible "event listener" interface and register the interface to be called back when events occur. The model of attributes and events used by control interfaces is similar to that used by the Java Beans component framework.

A useful type of protocol layer is the virtual protocol, that does not modify the packets passing through it. Virtual protocols can be added to a stack without affecting its compatability with stacks with which it communicates. Virtual protocols that expose control interfaces and events are the basis for configuring monitoring and management support into a node’s communication subsystem.

A policy notation and support tools have been developed which permit the specification of authorisation and obligation policies [Sloman 94, Marriott 96, 97] . We are concerned with two types of policies. Authorisation policies specify what activities a manager is permitted or forbidden to do to a set of target objects and are similar to security access-control policies. Obligation policies specify what activities a manager must or must not do to a set of target objects and define the duties of a manager. Obligations policies define actions which are triggered by events. Policies are interpreted by automated manager agents and so the behaviour of the agents can be modified dynamically by changing policy rather than re-coding. The policies thus provide a constrained form of ‘programming’ of automated agents to change management strategy without shutting down the management system.

Imperial College Work within ALPINE

There are 2 main areas of IC work within the new project:

We will investigate the use of the Darwin Architecture Description Language (ADL) to specify the ALPINE components required for a particular application. This will give a declarative specification of what proxylets are required, what dynamic proxy servers they should be loaded onto, what protocol stacks are potentially required and how they should be configured. The Darwin language allows a component’s implementation itself to be distributed. This would allow the specification of proxylets that span multiple DPS servers, making best use of available communication, computation and storage resources.

The advantage of an approach based on the use of Darwin is that more checking can be performed at design time to detect potential incompatibilities and problems. Of particular benefit is that the fact that architectural descriptions are an ideal skeletal framework for other support tools e.g. graphical design tools, compilers, behavioural and performance modellers, debuggers and application management software. The Midas language integrates with Darwin to allow the modelling and analysis of designs that take the component behaviours, interaction protocols, and transport layers into account.

A new EPSRC funded project LinkMe See http://www-dse.doc.ic.ac.uk/projects/linkme/ for details) is investigating the use of constraints at the ADL level to allow generic constraint specifications for component selection (e.g. component type’s A and B conflict and must not be used in the same context), composition (every composite component must include an authentication component), binding (at most 10 clients can bind to the file service), topology (token protocol components must be connected in a ring) and reconfiguration to be defined. Although the emphasis in the LinkMe project is on mobile applications, there are likely to be architectural constraints on the configuration of Proxylets which need to be defined.

The proxylet required to perform a particular application and the protocols they use may need to adapt to events such as component failures or changes in the Quality of Service during a long-running interaction. The obligation policies provide a flexible means of specifying how the systems should adapt to these changes. The advantage of the obligation policies is that they are interpreted and so can be dynamically disabled/enabled or replaced without stopping the manager agents i.e. the management policy of the active networking can be dynamically changed as well as the proxylets themselves. The research objective will be to see whether the event based obligation policy rules can be used to control proxylets and protocol stacks.

As part of the use investigation of the use policies to manage transport protocol stacks, we intend to insert virtual protocols into a binding’s stack to monitor the actual quality of service available to the binding. If the QoS varies beyond some predetermined threshold, control events can be generated. Management agents within the node can use these events to trigger policies as to how to react to changing QoS levels. Potential actions could include fine-tuning the operation of the protocol stack via the control interfaces exported by layers in the stack, replacement of the stack with another which makes better use of network resources, or the triggering of application-level changes, such as changing the media encoding used or selection of a different Dynamic Proxy Server from those available in the ALPINE framework.

Another issue addressed by the policy framework is security. Authorisation policies can be used to define what proxylets or stacks can be loaded by a server, who can install proxylets on a proxy server etc. Obligation policies can be used to specify actions to be taken in the event of security violations.

This work will also benefit from a new EPSRC funded project (SecPol) which will be investigating the use of Requirements Engineering tools and techniques for refining high level goals into implementable policies. (See http://www-dse.doc.ic.ac.uk/projects/secpol/SecPol-overview.html for

details)

Work Plan

<needs extension and further refinement, e.g is UCL doing QoS monitoring, how do we fit in with Lancs work?

We would have deliverables over the 36 month period, but this needs discussion amongst the partner>

Current Research at Lancaster University

Within the BT-URI we are currently carrying out research under the broad title of "End-system QoS Management". Management of distributed multimedia application sessions involves three distinct processes; QoS specification, which captures application level QoS requirements; QoS mapping, which translates user-level requirements to finer grained network and operating system level requirements; and QoS assurance, which is the maintenance of the end-to-end service through resource monitoring, policing and adaptation. Our current work is addressing the design and engineering of end-system mechanisms which fulfil such QoS management tasks.

In addition we already some work, under an EPSRC case award funded by BT, which is aimed at designing and building an Active Router Architecture. The router architecture consists of proprietary Linux-based IPv6 routers which enable modularised Java (JIT compiled) components to be dynamically instantiated into the modified kernels.

Other work which is relevant to the new projects is our previous involvement with QoS Filtering (which is the introduction of application level media filters into the network) and the QoS Architecture (providing a framework for the provision of QoS constrained end-to-end communications services). Both of these projects have delivered useful ideas and artefacts to our collaborators at BT Labs as well as bringing valuable research experiences to the group.

Adapt is a three year EPSRC funded project in collaboration with BT Labs which has been investigating the concept of open bindings to support mobile multimedia applications. The Design and Implementation of Reflective Middleware is again a three-year EPSRC funded project in collaboration with BT Labs. The aim of the project is to investigate the role of reflection in middleware platforms, with particular emphasis on the design of a reflective group service.

BT Labs has supported a PhD project on the feasibility of ubiquitous computing; this project has been based on (mobile) laptop users with mobile IP, and IPv6 Linux-based implementations built at Lancaster.

A directly-funded PhD project is investigating the scalability of RTP’s control protocol (RTCP) and its possible use in a QoS manager that provides feedback information on congestion in large-scale group communications applications.

Lancaster’s Work within Alpine

What is ALPINE? ALPINE is about putting intelligence into the network so that services provide more than simple connectivity. The sort of functionality it could add includes filtering, load balancing, routing, group support, monitoring, auditing, content filtering, mobile support, flow control, caching,, proximity location, QoS control, store and forward, and so on.

The current QoS management work in the BT-URI is primarily in the end-systems. We would aim to take some of these principles to place aspects of QoS management within application level networking.

An overall goal might be to provide customisable functionality determined by the user/manager of the (leased) multiservice network.

In this new project we would continue to use the same context of the Information Services Supermarket, where the QoS broker is implemented in a Dynamic Proxy Server, and functionality loaded dynamically in the form of proxylets as appropriate to the service (and QoS) required by the customer.

Support for QoS control

The purpose of Application Level Active Networking (ALAN) is to put ‘intelligent’ processing into the network.

SUPPORTING ALAN INFRASTRUCTURE : what sort of QoS management functionality can we put in the network? What sort of applications would use these functions?

QoS management is provisioning, adaptation, monitoring (overlap with UCL), specification, reservation, negotiation, policing and protection. We would investigate whether a chain of DPSs could be used to implement resource reservation, first in the peer-to-peer case then (see below) in the multipeer case.

APPLICATION : Load balancing - use QoS monitoring information (from UCL) to carry out admission control for adaptation.

APPLICATION : Mobile Application Support ? This would build on the ubiquitous computing work.

APPLICATION : Media Streaming - control of continuous media sessions including;

synchronisation, buffering, high level routing, filtering

Support for Group Management

See our previous work on the EPSRC GCommS project on group communications services.

Can we provide high level (i.e. application level) group communications mechanisms over an ALAN infrastructure. We would investigate the provision of a lightweight middleware platform for doing this.

We would aim to use (cooperating) Dynamic Proxy Servers to implement resource reservation for multipeer groups.

Issues of Scalability

Is putting application level functionality in the network sensible? Will this provide scalable solutions?

[This part of the work would be discussed with the groups at BT Labs involved with scalable distributed computing, and with those involved in the Futures Testbed.]

Support for Media Processing

The emergent MPEG-7standard being developed under the aegis of ISO SC29/WG11(MPEG) will provide a mechanism to describe multimedia content. MPEG-7 is addressing a wide range of applications including such as real-time surveillance. Other applications for MPEG-7 involve filtering multimedia traffic on the basis of user preferences for sport entertainment etc. Lancaster University has been active in MPEG-7 since the 39^th meeting in Bristol in spring of 1997.

Within the context of Application Level Networking, we would propose the introduction of MPEG-7 processing entities into the active network. Such entities may carry out media processing tasks including content analysis and the generation of content meta-data, or content filtering based on end-user / systems administrator requirements.

Background

UTS has developed a basic infrastructure for the deployment of proxylets to support Application Level Active Networking. These are supported by an initial implementation of a Dynamic Proxy Server (DPS). Some proxylets have been developed that show the plausibility and benefits of this approach.

Ongoing UTS research contracted to BT is exploring deployment issues. This research is constrained by a set of assumptions. It is assumed that DPSs are deployed within a single domain of ownership, eg the network provider or ISP. This helps constrain issues of location, management and security. It is also assumed that the DPS configuration is relatively fixed and changes slowly over time. This is analogous to the current WWW cache infrastructure. It means that global state is fairly easy to maintain. Thus ongoing research is looking at the following.

In conjunction with Lancaster and UCL we are considering proxylet admission control and policing. This involves the definition of proxylet metadata, and permits DPS load balancing. We are also developing proxylet based QoS management via feedback monitoring to an adaptive streaming proxylet.

We are looking at the DPS discovery problem within the context of a single domain. We may relate DPS location to the caching hierarchy, and use appropriate techniques for building global (intra-domain) state. We are building a "location proxylet", and intend to experiment with some ideas from the caching community. Finally, in conjunction with BT Labs, we hope to develop further network and application proxylets to test the infrastructure.

For the URI we want to relax the constraining assumptions. We will no longer assume a single domain of ownership. The environments will be massive scale and highly dynamic. End systems will arbitrarily roam and network connectivity will be very heterogenous. Here we want to provide facilities for rapid and dynamic construction of network and application services. DPSs become a general purpose resource, with proxylets and protocols available from a global fabric of servers.

Dynamic Proxy Server Discovery: Application Level Routing

In a world where there are many DPS's distributed around the world a mechanism is required to discover the optimally located DPS's for a

particular task.

We believe that a mechanism analogous to a routing protocol will need to be adopted to allow the discovery of a DPS. In a routing infrastructure packets between domain A and domain B may not be allowed to transit domain C. The same may be true of the use of DPS's a user/host in domain A may not be allowed to use a DPS in domain B.

DPS discovery will need to be performed based on a number of metrics an incomplete list is:

1. Allowed domains as discussed above.
2. Closest to a particular host in terms of bandwidth or latency.
3. Perhaps some fault tolerance metrics to discover clusters of DPS's.
4. CPU availabilty to support heavily cpu intensive transcodings.
5. A list of DPS's which define the current "highest bandwidth"/"lowest
6. latency" path between two hosts.

In order to support the multi-metric discovery discussed above a number of issues will need to be taken into account. There are known scaling issues. Ownership and security issues: one domain may not want to advertise specific information about the internals of its DPS infrastructure. It may be necessary to support non overlapping DPS domains.

Application Level Multicast

We suggest using the DPS infrastruture to build application level multicast trees. The trees can be structured to meet the requirements of a particular application. Optimised for one to many for a traditional broadcast or for many to many for a conference. The system chooses the appropriate multicast routing protocol and reliability semantics. We also add the facility to manipulate the payload to support transcoding and media scaling.

Such a system would be self organising - dynamically discovering the characteristics of the local environment and adapting accordingly. Some of the techniques from ad-hoc networking may be useful.

Micropayments

One of the perceived problems with allowing arbitary proxylets to run on DPSs is the turing halting problem. Rather than attempting to discover whether proxylet is going to terminate, it may be sufficient to just keep charging the user who is attempting to use a particular proxylet. It may be perfectly reasonable for a proxylet to run for extended periods of time in some contexts. A mechanism could be developed to accept some form of electronic cash in order to continue to run a proxylet. It is therefore the responsibility of the user or author of a proxylet to verify that a particular proxylet terminates correctly. The owner of a DPS will not mind that a local resource is being consumed if s/he is being suitably recompensed.

Work Plan

UTS-WP1: DPS Discovery

UTS-WP2: Application Level Multicast

UTS-WP3: Micropayments

UTS_WP4: Integration with Other Partners