Communication with the Manager

To permit the ATM connection manager to be implemented in user space, a mechanism was required to permit communication between the kernel socket layer and the manager, and between the ATM layer and the manager. Two possible solutions were identified, namely the provision of a special device in /dev or a ``magic'' control socket type. We chose to implement the latter option, adding a socket type SOCK_RAW to AF_ATM which can have only one instance per machine. The reasons for this choice are:

• For concurrency reasons it was preferable for the manager to interface directly with the networking code rather than via the file system. This would also make implementations on kernel threads, such as on OSF/1, easier. This is particularly important because most of the information for the manager is generated as a result of calls from the socket layer.
• The user space manager is responsible for the transmission and reception of ATM signalling messages. Since these must be presented to the ATM layer in the form of queues of mbufs and the mechanism for the encapsulation of data in mbufs is already provided by the socket layer, it is preferable to transmit and receive signalling via the socket interface rather than via the file system. The fundamentally asynchronous nature of interaction between the kernel and the daemon maps well onto the asynchronous nature of socket communication.

  
Figure 1: Overview of System Components

The control socket is used to exchange three types of information: socket layer requests, ATM layer requests and ATM signalling. Socket layer requests to the manager include, for example, requests to bind() an ATM address to a socket, connect() a socket to a destination ATM address, and close() a connection. Responses from the manager indicate the status of outgoing connections and include notification of incoming connection requests. The manager uses the control socket to issue commands to the ATM layer to build an association for each connection, provide it with a virtual circuit identifier (VCI), and monitor its status. In the control plane the manager transmits and receives ATM signalling messages via the control socket. Implementation of the ATM control plane in user space has the advantage that modification of the signalling protocol to comply with the latest ATM signalling standards involves only the user space daemon and not the kernel ATM layer code. In addition, development can be aided by the use of programming tools such as debuggers.

Messages exchanged between the kernel and the manager are normally in the form of fixed length control messages. Some of these message blocks, however, may be followed by ATM signalling messages for transmission or which have been received.

A few management operations cannot be performed asynchronously and are transferred using the ioctl() system call. In this case the kernel can synchronously modify the block to return the required response.