Introduction
Next: The MSNA Protocol
Up: MSNL Connection Management
Previous: MSNL Connection Management
This document describes a management and control architecture which aims
to permit flexible, platform independent communication management in MSNA.
The management and control (M&) functions are those required to
set up and maintain a data path (a liaison) between two MSNL
Service Access Points (SAPs) in an MSNL internetwork,
and include the following tasks:
- Signalling between intranetwork entities.
- Signalling between network entities and internetwork routers.
- Internetwork signalling between internetwork routers.
- Topology determination and routeing of internetwork requests.
- Allocation and management of MSNL SAPs.
- Resource management and monitoring to ensure that QOS constraints are
met.
- Network maintenance functions.
Other functions may also be required for specific communication needs.
The most basic requirements of a network entity
which wishes to use MSNL include only:
- Signalling to intra- and internetwork entities requesting connection
set up and teardown.
- Terminating the MS-Access, MSDL, MSNL, and MSSAR
layers to permit data transfer.
Current implementations of MSNL combine the functions for data transfer and
network M& into a single functional unit, normally bound within the kernel of
the host operating system in an operating system specific manner.
Because it is difficult or impossible to gain access to
the M& functions from outside the kernel this has led to the de
facto ``definition'' of an MSNL entity as the communication part of an
operating system kernel. The consequences of this definition are that:
- Every MSNL entity must incorporate a kernel (or sufficient
intelligence) to permit it to carry out MSNL management and control functions.
- An MSNL entity, and therefore its management plane,
is bounded by an operating system kernel.
Consequence 1 means that dumb devices such as the ATM camera,
which cannot support the M& functions
cannot use MSNL for data transfer. Consequence 2 makes the
management of multiprocessor entities such as switches very difficult, because
each processor (kernel) is responsible for its own management. It is
impossible to manage shared resources, such as switch bandwidth, without
managing the functionality of a switch as a single object with multiple
interfaces. This proposal outlines an approach to MSNL communication
management which will permit us to aviod these unneccessary restrictions.
The remainder of this document is structured as follows:
Section 2 argues for a distinction in functionality between the
different planes of the MSNL protocol stack, and
identifies the functions of each plane. With
reference to this model, Section 3 identifies the
elements of the proposed management and control architecture, and
Sections 4 and 5 describe the proposed structure
of the control and managment planes, discussing metasignalling, signalling,
connection management, routeing and other functions of management and control.
A Unix implementation of the architecture described in this document
already exists. It is fully described elsewhere in this collection.
Instructions for the use of the manager, and the environment in which
it runs are also documented in this collection.
Next: The MSNA Protocol
Up: MSNL Connection Management
Previous: MSNL Connection Management
Simon Crosby