Structure of the MSNL Master



next up previous
Next: The Rarp Server Up: MSNL Connection Management Using Previous: Introduction

Structure of the MSNL Master

The MSNL master is responsible for implementing all functions required to set up and maintain a data path (a liaison) between two MSNL Service Access Points (SAPs) in an MSNL internetwork, and includes the following functions:

  1. Signalling to request connection setup,
  2. Topology determination and routeing of internetwork requests.
  3. Allocation and management of MSNL SAPs.
  4. Resource management and monitoring to ensure that QOS constraints are met.
  5. Network maintenance functions.

The MSNL master is structured internally as two independent state machines representing the user side of the UNI and the network side of the UNI respectively. The UNI describes the protocol used by MSNL entities to request connection setup, teardown and other facilities. The full protocol has been documented and will be made available on request (it is too long to include here).

The user side of the UNI is responsible for the maintenance of all state associated with the MSNL SAP for the requesting user. This is maintained in a structure called the fsm, representing a finite state machine for the user side of the connection. No MSNL management or control plane functions are located on the user side of the UNI. The user side of the UNI encodes UNI requests in response to socket layer requests received from the Unix platform supporting the requesting user. The Protocol used for communication between the kernel and master is documented elsewhere in this document collection. Typical requests include requests to allocate a SAP, make a connection, offer a SAP for incoming connections, accept an incoming connection, and tear down a connection.

Requests encoded by the user side of the UNI are ``transmitted'' to the network side of the UNI by placing them in an asynchronous queue which is serviced by an independent thread which operates on the network side of the UNI. On the network side of the UNI each connection is referred to by its unique call reference, assigned when the SAP for the connection was first requested. Significantly more state must be maintained for connections at the network side of the UNI. In addition the full control plane functions for the MSNL protocol stack are implemented on the network side of the UNI. Messages from the Unix kernel pertaining to the state of associations, receipt of data for associations which do not exist, and other status information are managed by the association layer management, located within the control plane of the network side of the UNI. Metasignalling requests, routed from the kernel to the MSNL master, are routed to a protocol translation package which converts metasignalling into NNI requests, thereby simulating the receipt of connection requests from a remote MSNL master. Responses from the network side of the UNI to the user side are returned via a second asynchronous queue. On the network side of the UNI independent threads manage communication with the Unix kernel, the user side of the UNI, and manage timeouts for the MSNL signalling protocol. On the user side of the UNI two threads operate, one receives requests the socket layer of the Unix kernel, and the other awaits responses from the network side of the UNI.

The upper layers of the MSNL master are designed be platform independent. A platform specific layer interfaces to the host operating system. For Unix this interface is described elsewhere in this collection. The Unix interface consists of a special control socket which is used to transfer messages between the MSNL master and the kernel. On the MSNL master side of this interface, a hash table is used to map the Unix kernel notion of a call reference, namely a pointer to a protocol control block, to an integer which represents the call reference for the MSNL master. Messages passed up from the kernel are translated from the Platform Specific Interface (PSI) message format into the format expected by the MSNL master on the user side of the UNI. The UNI, PSI and NNI are described in an interface description language, MSDR, which is used by MSRPC to define service interfaces. This will be changed in the second release of the manager, planned for the summer of 1994. At this time the manager will be modified to either use msrpc2 or to use a hand-coded representation of the messages which are transferred across the interfaces described in the architectural document.



next up previous
Next: The Rarp Server Up: MSNL Connection Management Using Previous: Introduction



Simon Crosby