[Return to Pegasus II home page]

Pegasus II: Resource Management Work Package

This work package is being done by APM Ltd, Glasgow University and Cambridge University. It comprises the following tasks:

[Return to task list]

Industry standard Distributed Processing Environment

(APM Ltd.)

The Telecommunications Industry has identified through the activities of the TINA Consortium the need for a Distributed Processing Environment at the platform for running distributed call control and service logic, for interfacing to external value added services and for providing operations, administration and management support. In turn, the OMG CORBA Object Request Broker standard and the associated CORBA Object Services have been identified as the most suitable standards baseline.

However, current CORBA standards and implementations are more oriented to the needs of the workstation and desktop marketplace than the telecoms market. Whilst some CORBA products can coexist with real-time operating systems, they do not provide the fine grained resource management required to enable end-to-end management of quality of service, nor do they provide means for software functions (such as compression/decompression algorithms) to be connected into a multi-media channel.

APM, through the Distributed Interactive Multi-Media Architecture component of the ANSA Work programme, is developing a "framework" Object Request Broker with many of the desired facilities for real-time, multi-media and quality of service manageement. The framework accommodates the first version OMG defined Internet Interoperability Protocol (IIOP) for CORBA and supports a basic CORBA "personality API". This work is being taken into the ACTS RETINA project to build a prototype TINA DPE for large scale telecommunication networks, and the UK Government funded DCAN project to provide a platform for Distributed Control of lightweight ATM networks.

The participation in Pegasus II is enabling APM to track the evolution of IIOP and provide a more complete implementation of CORBA. Additionally the work is giving APM the means to exploit CORBA in networks and operating systems optimised for multi-media applications.

There has been much attention devoted to making a link between the Java programming language and CORBA. There are proposals for Java "remote method invocation" (RMI) and Java ORBs. These proposals are attractive for a number of reasons: first, with Java a much simpler distributed object API is possible than with C++; second, Java is seen a key development to enable portable applicatio across a wide range of systems including "network appliances".

APM is evolving its CORBA "personality module" for DIMMA into a Java "personality module", adhering as appropriate to standard Java APIs such as RMI.

Deliverables:

[Return to task list]

Synchronous programming toolkit

(APM Ltd.)

Multi-media applications require end-to-end control of quality of service. In addition to obtaining the necessary quality of transmission from the network, the operating systems of the end applications must also manage their resources to ensure data is signalled and accepted in a timely fashion. Whilst raw performance provides a degree of statistical comfort, it is still necessary for there to be explicit real-time scheduling and management. Synchronous programming, for example as demonstrated in the ESTER-EL and Reactive C programming languages provides an excellent framework for writing event and time-driven schedulers, and for writing applications and protocol drivers with predictable execution times, providing the foundation for making quality of service guarantees. (The application of synchronous programming to protocol design is being explored in the HIPPARCH project). In Pegasus II, APM wish to understand how to integrate synchronous modules into the context of distributed computing concepts such as RPC and threads and real-time concepts such as priorities, deadlines and resource and to test their applicability to multimedia applications.

Deliverable:

[Return to task list]

Quality of Service management

(Cambridge and Glasgow)

The underlying structure of Nemesis is a consequence of the goal of providing fine grain accounted sharing of all resources in the system. This however needs to be augmented with QoS management which allocates resources on a longer time scale. Thus every identifiable resource in the system should have some resource manager which responds to long term requests (e.g., on the scale of user requests to control allocation or application phase change). This resource manager is not in the data path when applications use resources, only when allocation change.

If this regime is to be extended to all resources, it is essential that resource managers present a unified feel to requesters (whether applications or user agents) and that the effort required to create a resource manager be minimal. Thus tools required to provide this long term QoS management are:

  1. libraries to provide applications a means to negotiate for resource changes

  2. toolkits to build user agents for different resource managers

  3. toolkits to ease the building of resource managers

These are clearly inter-related and are being designed together. The resource managers that will be used to demonstrate the toolkits are the CPU allocator and the ATM network interface manager. In addition a user agent to provide users direct control over resource allocation to applications is being provided.

Deliverables:

[Return to task list]

"Client renders" window system

(Glasgow and Cambridge)

A client rendering window system was proposed as a means of accounting for resources expended in graphics operations to the correct client application and to remove the server performance bottleneck. In fact this approach is widely used in high performance graphics systems, where clients often have direct access to the frame buffer and graphics processors of the graphics subsystem. However such access is usually uncontrolled, both from an accounting and protection point of view.

The task is buildomg on the preliminary study undertaken on DAN-based devices, to design and produce an implementation of a window system providing controlled client access to graphics display subsystems. As with other Nemesis services, the main aim is to separate the main data path, to be executed in client context, from the control path, implemented in a server, which should only be invoked on changes involving high level protection checks.

A key point to note is that such a client can offer a service to several other window clients using a compact X-like encoding, so that the benefits of an X-server type approach can still be obtained for applications separated from the actual display device by low bandwidth links.

Deliverables: