Pearl: Proposal for Experimental Academic Research using LEANET

Authors: Simon Crosby, Ian Leslie, Cambridge University Computer Laboratory

Jon Crowcroft, UCL Computer Science Department

Lionel Sacks, Chris Todd, UCL EE

  1. Scenario

The realisation of the Communications Centre joining the strengths of Cambridge with those of UCL, and the ongoing London Communications Centre involving Imperial College, Kings College, QMW and UCL represents a unique concentration of research skills and professional training facilities in communications, certainly in Europe and probably World Wide. The support that BT has given these initiatives and in particular the offer of the London East Anglian Network (LEANET) as a potential active experimental base represents a vital step forward.

Given the scale of LEANET and the implicit complexity of proposed collaborative experimental work on that network, there are a number of critical factors to consider.

Although these critical factors are demanding, UCL/CAM believe their solution is eminently justified by the scale of the research opportunity that collaboration on LEANET could provide at this critical juncture in the evolution of the communications business. The programme, which forms the basis of this proposal, has been targeted at this opportunity and is far too large for the envisaged two RAís to complete in 3 years, given their other duties outlined above. To complete this programme, and the one or two others that are ëa gleam in the eyeí but will take shape soon, will require a critical mass of researchers and the portfolio approach also outlined above.

  1. Programme Introduction and Summary

The provision of new services on current and future high speed networks will require network elements to be flexible and easily controlled, because service components will require specialised communications features to be implemented within the provider network. The Asynchronous Transfer Mode (ATM) has been widely hailed as a solution to the problem of supporting multiple services, because it appears to offer the best prospects for solving a particularly awkward problem in an integrated communications environment, namely the accommodation of multiple services with widely differing resource and performance demands.

Research in recent years has focused on the traffic controls required to ensure that data transmissions from multiple sources of different types each receive the appropriate level of service from the network. Typically these controls are located in the data path, and include scheduling techniques, policing and shaping functions. Until recently, however, few researchers had seriously considered the control plane aspects of the provision of multiple services in broadband networks. Key to the provision of new services and the support of existing and standards-based services is the requirement for a powerful, and flexible network control mechanism capable of meeting the needs of multiple network services, such as native ATM connections, IP, IPv6, and specialised services tailored to specific communications needs, including video distribution, remote sensing or conferencing. ATM as a multiplexing technique can provide resource management for new services, however ATM as standardised by the ITU-T and ATM Forum is inflexible and does not encourage the development of services which require modes of communication or control which cannot be expressed in the standardised UNI protocols. Unfortunately the standardised protocols are not sufficiently expressive for the needs of new services, and even support for IP, the service type from which operators reasonably expect to earn a significant proportion of their revenue in the near future, is poor and does not scale.

Fortunately, recent developments from research in the area of "open signalling" (or more aptly, open control) suggests that this problem can be overcome. The use of sophisticated distributed systems architectures in the network control and management infrastructure can drastically simplify the design and implementation of truly multi-service networks. In addition, devolving the control of switches to off-switch control processors allows the basic switching functionality of the network to be exploited in innovative ways, for example as used by Ipsilon's IP switching, or the Columbia control architecture. The fundamental ability of ATM to perform high speed switching with fixed-sized units of bandwith can thus be exploited by new services.

The LEANET offers a unique opportunity to build a large multiservice network based around a common switched core network with fast and versatile provisioning of connection services, and to test this in a realistic context with sufficient user load processing and communications complexity. The convergence of differing uses of telecommunications networks gives rise to 'layer' convergence in management and service provisioning; with the consequence that the responsibility for set-up, routing, error reporting etc shift between the control plane and distributed management systems and the division between these ëlayersí becomes ill defined. It is clear that to build a complete service, each layer of the system must work harmoniously with the others. This requires more than the traditional stack-service based approach and 'Layer Violation' must be managed and the QoS concepts can be seen as a way to do this. In general, the LEANET test bed, as a complete captive network with full access to all ëlayersí, should provide an ideal context to look well beyond conventional layering criteria and to allow new full service definitions to be created; thus providing a knowledge base for future application development in BT.

The proposed work will range from control to service up and down the stack, and will use as a basis for its research a technique developed at the University of Cambridge Computer Laboratory which enables multiple network control architectures (CAs), such as ITU standard Q.2931 signalling, TAG switching, or Ipsilon IP switching to be supported on top of a single network. New services may be built upon the architecture, and crucially, virtual networks of any type can be created. UCL Computer Science will bring their previous experience to bear to attack complexity and manageability issues associated with IP(v6)/ATM service provision with RSVP control in its own virtual network, and seek some understanding of the very different Virtual Circuit World View and the IP World View of the meaning of multicast; how switch/routers deal with these different viewpoints is itself a significant research issue for the programme. UCL CS are also interested in open service provision, QoS in routers, IP traffic QoS, measurement and estimation of traffic resource requirements, and end system requirements for multimedia. UCL EE will be concerned with the quality of the connectivity management with respect to eg the call / data connection requests (e.g. connecting to data), (advanced IN type) personal services and to the availability of status information and in doing so will move beyond the recent experience gained in a number of ACTS Projects to develop Quality of the Quality of Service ie (Qo)2S concepts, in the context of an ongoing risk management research project for BT; there are particular issues here arising from the Cambridge virtual networks approach. UCL EE would seek to define ëperipheryí agent platforms to link for example advanced personal service generics with the ënetwork service on demandí concepts of Cambridge and thereby build on other recent research in EE dealing with the complexity of mixed technology environments.

As discussed in Section 1, this proposed programme of research which is detailed in Section 3, presumes a fully operational LEANET. However it is assumed the the two RA post holders will need to spend a significant portion of their time working jointly with BT staff to enable a configuration that will support the research programme, and subsequently to aid with the management of LEANET as a multipurpose experimental platform. The proposed programme builds on current research strengths in the Cambridge and UCL groups concerned, and the summary demonstrates how individual research interests in the three groups have been assembled to compliment and be mutually supportive in the programme of work. The UCL and Cambridge groups have prior experience of effective interworking and a methodolgy for technical exchange.

  1. Research Areas
  2. UCL CS

The basic area of work is around the complexity and manageability of IP(v6)/ATM service provision - we will help evaluate the results of the network that BT build, with appropriate RSVP control in its own virtual network, and the QoS support within the virtual networks. The combination of the skills of UCL and Cambridge in this line are extremely appropriate: UCL have the IP/RSVP skills and the network and service management skills, and Cambridge know how to build networks with guarantees, including both security and integrity (performance) aspects (see activity

  1. Topology/flow maintenance scaling

High performance networks are moving towards a seamless integration of switching and routing technologies. There are a variety of proposed approaches including Ipsilon's flow labelling, Cisco's tag switching, Toshiba and IBM have looked at other approaches still. Each involves dynamic creation of state and state table indexes for a flow (whether on demand, as in Ipsilon's case, or per route as in Cisco's proposal). Each has scaling properties, in terms of the amount of state, and the rate of change of state, as well as in the number of messages and changes to the signalling and routing protocols in the IP (RSVP) and ATM (Q.2931/Uni 4 etc) (or other) layers. These scaling properties are dependent on a number of actual traffic characteristics - e.g. location in space and time of flows (how long a flow between a source and a destination appears to last) (see activity activity

Recent work on traffic classes and call admission shows that for some classes, aggregate flows may be admitted with higher acceptance probability, and then queued together with a single index for efficiency. The gains here are mainly in the area of switch/router memory (table sizes) and control messages rather than actual network utilisation (although there are modest gains there too).

Multicast means very different things in the Virtual Circuit world and the IP world. How switch/routers approach this is interesting, and differs widely (and depends on the underlying switch facilities to a large extent as well) (see activity

  1. See "Task AreasTask 1.1Task AreasTask 1.1Task 1.1" Section to "Task 1.4Task 1.4Task 1.4", Section
  2. RSVP/IPv6/ng/IP switching

ATM and Integrated Services IP provide a variety of traffic classes. [See for a detailed tutorial on this]. These classes do not define (prescribe) how a provider decides what percentage of the network each class is limited to. This is a matter for policy. How much we choose to allow of CBR, VBR, ABR etc, or Controlled Load, Guaranteed and Best Effort is a matter of the revenue each class generates, the demand, the service facilities/limitations etc.

See "Task 2.2Task 2.2Task 2.2", Section and "Task 2.3Task 2.3Task 2.3", Section

  1. Server interaction with network

Web servers are adding facilities for sizing documents, and including policies and QoS information concerning the retrieval of a document. [See for details of a Project involving UCL working on Http ng and other aspects of this problem] (see activity

In any case, such a facility leads to the possibility for scheduling flows (retrievals for near media on demand for example), which can interact with traffic monitoring and so on.

  1. See "Task 3.1Task 3.1Task 3.1", Section
  2. QoS routing

We are interested in open service provision, QoS in routers, IP traffic QoS, measurement and estimation of traffic resource requirements, and end system requirements for multimedia (see activity

SDH, ATM and IP all have failure tolerance mechanisms based in alternate trunk routing, PNNI, and a variety of distributed dynamic IP routing schemes. Each has its appropriate timescale and performance.

See "Task 3.1Task 3.1Task 3.1", Section and "Task 4.1Task 4.1Task 4.1" section5.

  1. UCL EE
  2. Trials on a 'Captive' Broadband WAN.

Much of the effort in IPv6 (RSVP) and some of the ATM service definitions are concerned with the provision of high Quality real time services, with defined/guaranteed QoS features. The concerns there are principally in the quality of the provided connection. An equal component for user satisfaction, which interests EE, is the quality of the connectivity management; i.e. the accuracy, speed (and availability) with which the service comes on line. This applies to; call / data connection requests (e.g. connecting to data), (advanced IN type) personal services and to the availability of status information.

These aspects are dependent to many aspects of the system used; network load, processing speed, network scale and complexity. Proof of a system finally requires that it is tested in a realistic context with user load, processing and (control) communications complexity. This context would facilitate developments across all service points and through all/most layers of the stack. Thus it would be possible to produce full service definitions as input for future service product definitions. These service definitions could be assessed for integrity [the Quality of the Quality of Service ie (Qo)2S] and implementation risk frameworks developed (see activitie

  1. See "Task 5.3Task 5.3" in section
  2. User & Application Support Layer.

In the context of a network based information infrastructure, 4 principle roles would be considered. Each of these may require versatile interactions with the network services in order to provide consolidated information flows. These roles are; - The user terminal / application; This is the point from which requests originate and the final destination(s) of data flows.

The information source(s); This may be an alternate role of the user terminal (telephone/videophone) or other sources ranging from multimedia material (web, vod) to stored textual/audio messages (call minder, e-mail) - Intermediate / stream processing services (network computing); services may be constructed by adding processing to the data flow from information source to user terminal. This may range from e-mail to audio conversion to in stream application processing (video mixing, ms-word on demand, etc.). - Information / Knowledge brokers;

These provide high level location / number translation services. Providing capabilities such as; (IN type) number translation, personalisation of services, brokerage of information sources / instream processing, management of mobility, billing etc. Each of these roles has a part to play in building service network management requests. For this, each role must interact both with the network service layer and with each other to agree QoS/performance requirements for each part of a connection, routing requirements and so on. Equally, interaction with users / subscribers / information providers may need to be versatile in order to provide adequate status/performance /billing/etc. information and to facilitate high levels of personalisation.

In the context of a network system supporting mobile, intelligent agents (MIA), it would be natural to define 'periphery' agent platform to interface to the above roles. For the users this would provide an interaction context for such technologies as personal assistance and such like. Equally this context could contribute to the needs of mobility (service tracking) and aid users in the provisioning and maintenance of sophisticated, personal, services (see activities and

See "Task 5.2Task 5.2" in section and "Task 5.4Task 5.4Task 5.1" in section

  1. Open Control for Network Management

The separation between network, service provisioning, Service management & Network management technologies is disappearing as the services required to be supported become increasing more complex. There is, in effect, a convergence in these areas arising in turn from the convergence between telecommunications, data networking and the content industries. The future demands on network provisioning will be to provide a mixture of services with rapid (re)configuration and high levels of user feed back (with more complex services, understanding delivered performance becomes more problematic; and more important for providing user satisfaction).

Current moves to accommodate these emerging network service and management needs focus around open control platforms such as those defined in TMN and/or TINA at differing levels. EE & CS have developed systems for the automated control and management (VPN provisioning, load balancing etc.) of ATM - and sometimes SDH - technologies (in ACTS Projects: TRUMPET, MISA, REFORM, VITAL, possibly WOTAN). These are yielding management infrastructures which may be deployed to some extent for LEARNET. Some of these (eg TRUMPET & MISA) are strongly concerned with QoS based provisioning. The concepts developed in this area will need to be ameliorated with those in the IP & ATM Switchlets worlds in order to see the way forward to fully integrated service provisioning at all levels.

Thus it is seen that the convergence of the differing uses of telecommunications networks gives rise to 'layer' convergence in management and service provisioning. Responsibility for set-up, routing, error reporting and such like shift between control plane and distributed management systems - with such divisions becoming blurred. The LEARNET test bed, as a complete captive network with full access at all layers, should provide an ideal context to bring together these aspects.

New technologies sit between the requirements of; standardisation - for open network provisioning - and versatility - to be able to innovate and support rapidly changing service requirements. A developing approach to tackling this dilemma has involved the use of Mobile (intelligent / adaptive) Agents. In this context, services are built up from co-operating agent units. The agents are given an environment in which they can interact both with each other (visiting agents) and with the local environment (principally the network infrastructure, but also maybe users personal environment, see above, to form fully integrated, personalised services). Studies in progress in EE are looking at adding mobile agent environments to the distributed control systems to be able to add versatile services for users (see previous section) and to aid in the increasingly complex network management & maintenance tasks which exists in mixed technology (and high availability requirement) environments; this research would be focussed into PEARL (blobs of java / whatever executing in VM's on top of switchlets-provide consistent management view of network and solve distributed problems.) (see activities,

  1. See "Task 5.1Task 5.1" in section
  2. Cambridge

This project aims to build infrastructure to support the creation, on demand, of virtual networks positioned logically over a single physical switching backbone. Although not predicated on the use of any particular switching hardware, a good example would be the use of Fore Systems ASX 200 switches for which Cambridge already has a partial implementation of the facilities required to build networks on demand. The work to be undertaken by Cambridge will virtualize the resources the switch and present them to a layer of control which enables multiple control architectures to simultaneously manage portions of the communications resources. The switch control will be achieved using an enhanced implementation of the Ipsilon IP switch control protocol, GSMP, which can be used to instruct the switch to set up, tear down, and manage ATM Virtual Paths (VPs) and Virtual Circuits (VCs). GSMP can be used to control the switch for any of several candidate control architectures, including Q.2931, Ipsilon IP switching, or any of the proposed variants on IP switching currently under consideration by the IETF ION working group. It can also be used to implement radically new control architectures; Cambridge has developed several such CAs, one of which was developed under the BT-URI.

Figure 11. Use of Switchlets to virtualise ATM switch control.

The goal of the Cambridge part of the LEANET project is to facilitate the dynamic creation of virtual networks managed by different CAs simultaneously on the same underlying ATM switch platform. The technique used to achieve this is a concept developed at Cambridge, which permits the hardware switching resources of an ATM switch to be safely divided into multiple "switchlets", each of which can be assigned a subset of the physical switch resources. Figure 11Figure 1 shows the approach, with an external implementation of the Prospero switch divider on a workstation attached to the switch. It exports subsets of the underlying ATM switching capacity to multiple control architectures, via the Ariel switchlet interfaces. A second external controller on a separate physical platform interfaces to one of the switchlets. A given control architecture (such as ITU-T Q.2931, or IP routeing) can be assigned a virtual network composed of a set of switchlets; the virtual network represents a subset of the physical network resources. Figure 22Figure 2 shows multiple virtual networks overlayed on a single underlying switched ATM network. Each switchlet appears to the control architecture which manages it to be a full ATM switch, and is controlled in the same way as a real switch. A Switch Divider Controller (under control of the network operator) is responsible for dividing the resources of each switch between the switchlets it supports (according to some policy), and it can dynamically create and destroy switchlets in response to management commands to create virtual "Networks on Demand" which support the control archictecture of choice. Although the "networks on demand" concept has been discussed theoretically, we have not implemented it, and to do so would require tackling several major research objectives. The Switch Divider Controller is also responsible for policing the control actions exercised on the switch control interface of each of its switchlets, before relaying them to the physical switch. This ensures that the actions are valid, legitimate and manipulate only the resources allocated to that switchlet.

Figure 22. Virtual networks, each controlled using a different control.

Key areas of interest which Cambridge intends to pursue include the following:

  • Development of support for "networks on demand" based on an existing implementation of the switch divider and controller.
  • Development of service specific control architectures which are tailored to new or emerging modes of communication, and which are capable of managing communication in a way which is not possible using standardized control architectures.
  • Provision of facilities for the support of active network control architectures. In our model it is possible to create virtual networks whose control architecture is defined at creation time by a piece of dynamically loadable code which is specifically tailored to management of the resources required by the type of communication to be undertaken. An example of such a control-closure is an architecture which uses mobile code to "track" a mobile user of the network and dynamically create connections and modify their resource requirements in response to the movements of the mobile user.
  • 4. Integration of current Cambridge research into policy based control of multiple CAs on a single underlying switching platform, being carried out in the BT URI project.
  • Below, several areas of research which can be pursued on LEANET are described in more detail. These are by nature very open ended and not all can be pursued at the requested level of resource, as discussued in Section 1. In tasks 6.1 and 6.2 we provisionaly target the areas for the requested funding. We expect the other areas to be addressed by other projects. However, it should be clear that all of these areas of work will benefit enormously from the LEANET infrastructure.

    1. Switchlet Infrastructure
    2. Cambridge has a long term interest in the advantages to be gained in separating control and data paths in networks. This will be extended to consider the separation of forwarding functions in switches, from intelligent functions such as admission control, routing, signalling in general, management etc in IP boxes instead/as well as of ATM ones.
    3. Cambridge will contribute, as background, its switchlets work which will enable different control architectures to be run simultaneously on the same network. This will enable many experiments to proceed in parallel on the same infrastructure. This process will provide a good testing ground for the switchlet concept, in particular, the ability to isolate virtual networks from each other.
    4. Implementation of Switches with Open Control
    5. Cambridge will build on previous work in the Computer Laboratory to deliver to LEANET the switches required to build a multiservice network. Commercially available ATM switches, such as the Fore Systems ASX200 or ASX1000, (or their Nortel telco-strength conterparts) will be used to build the switching support for the LEANET; on top of this we will provide support for virtualise control of subsets of the network capacity, into switchlets. The switches will be controlled using GSMP. The GSMP interface will allow the switch to be controlled by a workstation with an ATM link to the switch.
    6. Cambridge have access to the internal interfaces of the Fore switches, through a NDA licence agreement with Fore; however several switch vendors also support this protocol including NEC, ATML, Hitachi and Ipsilon IP switches, and it is publicly defined in RFC 1987.
    7. Networks on Demand
    8. In the currently running BT URI on management in multiservice networks, Cambridge is developing an architecture and mechanisms for managing dynamically created networks, on demand. The networks will be ëvirtualí in the sense that they will be presented to the control architecture which manages their resources as logical switches, but will use a subset of the real switch resources. The development is based on the existing Prospero Switch Divider at Cambridge and will run on a workstation attached to the switch. The project will use a CORBA compliant ORB as its DPE; a suitable candidate would be the OmniOrb from Oracle & Olivetti Research Laboratories in Cambridge (subject to appropriate licencing arrangements), or any of several commercial ORBs could be used if required.
    9. The URI work will produce components (for example it is currently concerned with policy and scheduling for the creation of virtual networks, and of its own accord the URI will produce a proof of concept demonstration. Using this technology in Learnet will provide a much greater test of the concept since it will be used to support real users (ie other network experimenters). It will also accelerate its development by applying more resource (switches, effort) to the problem.
    10. IP Support
    11. IP can be seen as just one more kind of virtual network that can be built out of switchlets. Functions such as framing, including frame specific services such as Early Packet Discard and Multicast schemes such as SMART or others that rely on frame marker bits and RM cells to build and schedule access to distribution trees are easily built on top of the switchlet architecture.
    12. Routing can be fully abstracted away from the separate levels of VC and IP network address specifics that often confuse work in the classical layered approach.
    13. The interaction between the IP notion of a flow and a reservation such as Ipsilonís flow labelling system can be pulled out from the switch hardware, and made into a soft element that is reconfigurable, as and when the statistics that define a ìlong-livedî flow are better understood. This work will also examine the use of switchlets to provide multiple Intranets over the same ATM network.
    14. Active Networks In the Control Plane
    15. The notion of active networks has been mooted recently in the US academic networking community. The idea is that packets contain method which are interpreted as the packet traverses the network. While this clearly has some interesting and novel properties it is also a largely unworkable scheme, due to interference between elaborate methods and the simple ìIpv4 forwarding methodî . The clear separation of control paths and data paths in ATM provides a straightforward way of applying the active network concept to the control plane. Thus users would be able to supply code (eg in Java) to control their connection setup, in what we currently call a ìconnection closureî.
    16. This work can be viewed as the development of a control architecture which provides interpretation of user supplied connection control code. It must provide suitable libraries to allow controlled fine grain access to the switchlet resources.
    17. Network Management in Switchlet Environments
    18. The partitioning of network resources into virtual networks, each with their own control architecture gives rise to intersting network management problems. This is particularly the case with alarm filtering, where the problem of exactly which control architectures need to be informed of a fault arises. There is also the problem of recovering from failed control architectures (since some will be experimental) to recover network resources. Some initial work on these problems has been done at Cambridge; we believe that running such a management system on a live network will produce very valuable lessons.

    1. Value from using LEANET

  • The LEANET offers a unique opportunity to build a large multiservice network based around a common switched core network with fast and versatile provisioning of connection services, and to test this in a realistic context with sufficient user load processing and communications complexity. The convergence of differing uses of telecommunications networks gives rise to 'layer' convergence in management and service provisioning; with the consequence that the responsibility for set-up, routing, error reporting etc shift between the control plane and distributed management systems and the division between these ëlayersí becomes ill defined. It is clear that to build a complete service, each layer of the system must work harmounisouly with the others. This requires more than the traditional stack-service based approach and 'Layer Violation' must be managed and the QoS concepts can be seen as a way to do this. In general, the LEANET test bed, as a complete captive network with full access to all ëlayersí, should provide an ideal context to look well beyond conventional layering criteria and to allow new full service definitions to be created,. thus providing a knowledge base for future application development in BT
    1. Task Definitions
    2. The following list of tasks are 'broad brush strokes' of work definition. The actual tasks defined for year 1 and directions for subsequent years are discussed below. This structure is followed since it is in the essence of a project such as this - i.e. establishing an experimental facility or context - that the development should be evolutionary. The first year is concerned with building the base system (physical, control, measurement). Activities for subsequent years is dependant, to some extent, on the involvement of other projects and partners.
    3. Task Areas
    4. Task 1.1
    5. Scaling of Flow maintenance protocols.

    We will carry out measurements of the available systems in the network.

    1. Task 1.2

    Flow aggregation: We will look at the facilities in the IP and tag layers for aggregating flows into a single table entry.

    1. Task 1.3

    Multicast: We will carry out measurement experiments to ascertain the scaling properties of various switch/router facilities for many-to-many flows such as those used to support multimedia conferencing.

    1. Task 1.4

    Renumbering/Flexibility: We will look (paper study) at the facilities for dynamic renumbering of the network and end systems (and groups of latter).

    1. Task 2.1

    RSVP has interfaces to a policy database to implement these decisions. We will examine how they can be used, and what distributed functions exist for installing and maintaining and checking policies for consistency.

    1. Task 2.2
    2. We will look at the interfaces between traffic policies and
    3. admission, and billing systems
    4. Task 2.3

    We will look at the various queueing systems implemented in switch routers (number of priority levels, stochastic systems such as CBQ and Weighted RED, WFF, etc etc) and compare their efficiency, and also their suitability in terms of deterministic behaviour and so on, for billing (billing must be transparent to the customer - the relationship between their flow behaviour and its cost should be largely repeatable!).

    1. Task 3.1

    Study interaction between long term traffic flows and in-advance knowledge, and how this affects QoS and utilisation.

    1. Task 4.1

    Study interactions between dynamic routing at various levels, and manageability and QoS performance of each, and their sum behaviour.

    1. Task 5.1

    Study in amelioration between Network & Service management QoS & configuration and 'open' signalling QoS control. Concerns, for example in ATM, matching NM QoS per VP with UNI+ VC QoS definitions.

    1. Task 5.2

    Definition of User & Application level QoS specification and API to drive signalling level in a 'by use' way. Facilitating highly personalised network-application usage.

    1. Task 5.3
    2. Development of metrics for versatile / personalised Mixed & Multimedia usage context.
    3. Task 5.4

    Enabling of User / Peripheral intelligence & the use of Switchlet based VPs. Define Agent environment for service provisioning & mobility.

    1. Task 6.1

    The switchlet concept will be applied to LEANET. This will take the form of planning switch deployment, control box deployment and strategies for allowing different control architectures to control the switchlets. Eventually the Network on Demand service will take over this role. Due to the limited resources (1 RA, see below), this task should be viewed as a glue function, enabling work already in progress to be carried on over a real network. This is an enabling task which will allow collaborative research to be pursued.

    1. Task 6.2

    Bring the Network on Demand architecture up on LEANET. This will be a realisation of the Network on Demand architecture from the current URI effort. Although some components will be available from the URI, this represents a deployment on a real network. It will require considerable support. Although this might still be regarded as glue, it is novel glue.

    1. Year 1 Activities
    2. Co-ordination of Auxiliary interests & Funding
    3. Co-ordination of Dark Fibre Connectivity
    4. Deployment of Switchlets®?
    5. Co-ordination of IP / User / Application API

    1. Definition of Management Architecture
    2. Definition of Service Architecture
    3. Application Support
    4. Development of Measures & Metrics
    5. Directions for Years 2 and 3

    The activities defined for year 1 concern implementation of basic infrastructure, planning and policy development for higher level architectures and usage's. Year 2 should focus on some subset of the possibilities identified in year 1 for implementation and experimentation.

    A continuous process through this should be the incorporation of ideas and applications from other projects. A final objective (depending on the state of other grants) may be, for example, to undertake teaching some of the BTMSc over the system. Such experiments would provide opportunities for proving both the technology deployed at each level of the system as well as to validate some of the performance measures developed.

    1. Deliverables
    2. These would need to be sorted out in the context of a second stage discussion, which actually identified the tasks compatible with the level of RA support. In general the deliverables would be in the form of reports and workshops; although demonstrations on the network may also be ëdeliverablesí in years 2 & 3.
    3. Equipment and Other Issues
    4. Cambridge will require access to at least one ATM switch for development work, a dedicated workstation for each switch for running the control architectures, together with workstations for development. Equipment needs of UCL will include an Ipsilon ATM controller and/or switch, and possibly one or two PCs for use as controllers.
    5. Working with direct BTL involvement in the research programme could be a productive approach. As stated above, the key things UCL have is IP skills, upper layer management skills, (Qo)2S experience and risk management; the key thing Cambridge have is the ability to engineer networks and their support for QoS. Incidentally, Cambridge would like to investigate the use of Nemesis (multimedia OS with QoS guarantees) with RSVP etc, both as an end system for IP based media, and even as a QoS aware router.
    6. The application projects can come from a variety of proposed work, including delivery of parts of the BT MSc material and the critical areas of tutorial and surgery activity, cross linkages between the BT MSc and the Telecom MSc at UCL and with other potential partners, and from the portfolio activities and other linkages.
    7. Other linkages include the BT URI in management of Multiservice Networks, already with partners at UCL, Cambridge, Imperial and onwards. (; the Digital Broadcasting VCE, of which UCL and Cambridge are members of (e.g. see and; and others. BT have expressed interest in including other members of the London Telecom Centre eg Imperial College in LEANET activity, and have recommended this be explored as part of a next phase.
    8. Human Resources
    9. 2 RAs, one Cambridge, one UCL for a 3 year (1 year at a time) program of work which will be carried out by them plus other CCSR projects - the 2 RAs represent "glue effort" mainly.
    10. IPR Issues
    11. Initial Considerations: A consensus is perhaps emerging for UCL/CAM to enter a non-exclusive arrangement on Foreground IPR with BT (which would be compatible with the portfolio approach). However access to Background IPR held either by CAM or UCL would not be included, and any arrangement regarding Background IPR would require separate negotition with CAM and/or with UCL, outside of this proposal. This is an area where further discussion will no doubt be necessary.
    12. Exact forms of IPR is now covered in the contract.


    END PEARL 1 Document 2-25/4/97-UCL/CAM-(CJT-UCL EE)