The use of Wanda as the software platform on the switch has already been mentioned. As well as the low level FIQ handler for cell forwarding, each port controller contains three major services:
In service use, one port acts as a switch master processor, providing certain per switch services, e.g.:
.
Besides being used for forwarding cells, the cell buffer memory and Xilinx are used by Wanda to provide an ATM network interface to user level tasks, enabling these various services to use the network for communication. Performance of this interface is comparatively slow, but is sufficient for these services.
To enable the simple interchange of lines card between 4, 8, and 16 port switches the first order of business on booting after a basic self test, is to establish the ``shape'' of the switch fabric. Investigative cells are transmitted into the fabric, with the cell headers and contents carefully constructed so that in any configuration at least one of the cells will be received by the transmitting port - the received cell can then be used to establish the size and location of the port on the fabric. The fact that 16 ports may all be doing this simultaneously (e.g. at power on) adds entertainment.
Port controllers are capable of either performing independent signalling or acting in concert as a switch. Early in the project when there were a small number of port controllers being used by different people, using ports independently was the norm. In this mode the individual port controllers implement signalling even to other ports on the same switch, but can be individually rebooted and configured.
More recently, as complete switches have been available, it has been possible to move to using management code which controls all the ports on the switch as a coherent entity. This is in line with the initial expectations discussed in [\bf\protect\citenameLeslie91].
The signalling system also allows applications to perform third-party call setup on behalf of dumb ATM entities which cannot signal on their own behalf, for example the ATM Camera. The ability to perform third party setup is critical to the simple design of such systems.
For a set of switches under the same administration in the local area we believe that knowledge of the complete topology at each switch is a reasonable assumption; to achieve this we implemented automatic mechanisms for topology determination based on those used in the Autonet [\bf\protect\citenameSchroeder90] [\bf\protect\citenameRodeheffer91]. However, the current experimental work programme would be hindered by automatic reconfiguration and so the system has not been deployed (or fully tested).
Hosts are currently connected to network using a mixture of ORL Yes and Fore interfaces. The hosts have access both a subnet interface for IP over ATM and raw ATM channels. A key feature of this implementation is that only the data paths are implemented within the kernel; all the signalling, socket control, and management is implemented in a generic and portable user space daemon. Details of this work have been previously presented in [\bf\protect\citenameBlack94].