|"Devolved Control of ATM Networks"|
The aim of the DCAN (Devolved Control ATM Networks) project is to design and develop the necessary infrastructure for scalable control and management of multiservice Networks.
DCAN starts from the premise that control/management functions of the various devices that make up such a network - typically ATM switches - should be extracted from the devices themselves and be delegated to external workstations dedicated to that purpose.
By devolving the management and control of switches and end devices into a coherent external system, one escapes the need for switch and device manufacturers to capture these functions within their equipment. This enables customers to configure their systems in a manner best suited to their needs. In addition, it enables new management and control policies to be introduced in the network without modifying every switch, and thus will allow legacy and new signalling and management systems to co-exist.
DCAN also presumes that the control/management of Multi-Service networks is necessarily distributed due to, amongst other reasons, the need for end-to-end resource allocation in order to give guarantees about Quality of Service (QoS).
Finally DCAN takes into the account the fact that extracting control functions from the networks device and placing them into workstations requires us to be able to place real-time constraints on the execution of the software performing those control functions.
Thus to be successful, DCAN must address both real-time OS and Distributed Processing Environment issues.
It is intended that the designed and implemented infra-structure be scalable. Scalable here does not just refer to size; rather it means being able to cope with a range of system capabilities, including simple devices with limited functionality. Thus, while retaining compatibility with developments in telecommunication system management, the emphasis is on ATM networks used to interconnect workstations and simple devices.
In what follows we distinguish from the two related areas of management and control. Control:
For example, call set-up is a typical control function and alarm correlation a management function. Although, control and management to some extent overlap and are often referred together simply as network management it is still useful to make a distinction between them.
Current developments in ATM Networking are leading to the notion of devolved control in which a number of switches are controlled by a largely separate distributed system as shown below:
This approach is in line with current thinking in Intelligent Networking (IN), whereby typically the actual routing of a call is achieved outside of the network by some higher level entity which then uses knowlege about the type of call being made in order to determine what script to run in order to perform the service e.g. freephones charge the callee rather than the caller.
In addition, it resonates with the approach to telecommunication management as specified by the ITU-TS Reference Model for Open Distributed Processing (X.901-4), which defines a Telecommunication Management Network (TMN) which manages the underlying telecommunication network.
However, both IN and TMN standards have been defined with a Public Switching Telecommunication Network in mind. Within such a wide-area environment one may assume that network elements are autonomous and powerful; neither processing power nor implementation complexity are primary limitations.
In local ATM networks, this assumption may not hold. Switches may only perform the relaying of cells (unicast or multicast) with even simple connection and network management functions performed by an external (distributed) system. There may also be end system elements, such as an ATM camera, which are so simple that they cannot perform network signalling and thus may not be able to initiate communication. They can be thought of as slaves.
Furthermore, the IN and TMN standards have defined complex protocols between the managing and managed layers. The rational seems to be that all embracing protocols will enhance their adapability to new services. For managed elements to be able to communicate with a manager using such protocols require them to have some knowledge of the management strategy.
We take the view that the protocols between the manager and the network should be minimalist. Additional management functionality e.g. synchronisation between streams, can be added in the management domain.
We propose to develop a system which allows the distributed management platform to encompass a range of intelligences and to make as few assumptions as possible about the management strategy to be used.
The work divides naturally into four related, but distinct domains:
The consortium is composed of APM Limited, Nemesys Research Limited and the University of Cambridge Computer Laboratory.
APM Limited, whose origins can be traced to the ANSA Alvey project begun in 1984, is a pioneer in the field of distributed computing. It has developed the ANSA architecture for distributed systems and ANSAware, an implementation of the architecture which runs on a number of vendor operating systems. It was founded as a limited company in 1989.
Fore Audio Video Systems Ltd (formerly Nemesys Research), is an ATM end system manufacturer, specialising in products that can take multiple audio and video feeds and send them over an AT M network.
The University of Cambridge Computer Laboratory has a great deal of experience in distributed computing and ATM networks. It developed the original IPR which led to the AVA-200 which was exploited by Nemesys Research.
DCAN started in mid 1995 and is set to finish in mid 1998.
Papers from Cambridge
Accessible only from cl.cam.ac.uk, ansa.co.uk, nemesys.co.uk.
Papers from Cambridge
Papers from APM
The Pegasus project, in which the Nemesis OS has been developed.
The TINA-C, consortium.
|Ian Leslie, Cambridge Computer Laboratory, firstname.lastname@example.org Simon Crosby, Cambridge Computer Laboratory, email@example.com Sean Rooney, Cambridge Computer Laboratory, firstname.lastname@example.org|
$Id: index.html,v 1.12 2000/02/07 11:47:44 and1000 Exp $