A workstation interface for an ATM LAN should not require a host processor interrupt for every cell transmitted or received. Such interfaces thus differ from conventional LAN controllers (e.g. Ethernet) in that they must provide buffering for multiple received PDUs (cells). Simple FIFO buffering of the received and transmitted cell streams is sufficient to enable the host to operate asynchronously with respect to the network and also to reduce the interrupt rate below the one-per-cell level. This allows host interactions to occur at the `packet' rate - although at high load, this is still a rate of interrupts twenty times that experienced from a fully utilised Ethernet. An interface which restricts itself to this minimum hardware complexity is the current Olivetti Research Turbochannel ATM interface, described in Section 6.2.
Two ATM-specific functions may be readily incorporated into a more sophisticated ATM workstation interface. On the receive side, these are:
The following question arises: what applications require interfaces which should have, or need to have, this level of complexity? A high performance system may wish to have these functions implemented in hardware to relieve load on the main processor. On the other hand, for a low power mobile ATM station, several megabits-per-second can easily be handled by the CPU, providing a trade off between hardware complexity and processor cycles.
The advent of a low power, high performance ATM interface ASIC would probably be suitable for a range of interfaces, but restricted in the supported adaptation layer protocols. Equally, in some instances, the bus architecture of a machine may lead to network interface solutions in which no adaptation is done in the interface, rather cells are routed to various dedicated processing units, for example, the framestore, compression engine, disk controller or main store. This latter approach preserves the fine granularity of ATM over the internal workstation bus, and the network attachment has then become merely an ATM multiplexer/demultiplexor. An extension of this approach is to implement the internal interconnections within the end-system as an ATM switch. This is being investigated within the `Desk Area Network' project at Cambridge .
Returning to data applications, a necessary protocol function is guaranteed end-to-end integrity of PDUs. In OSI and TCP/IP, this function is implemented in the transport layer using the TP4 and TCP check functions respectively. The cost of computing the check function in software has been recently widely debated.
One view is that data generally has to be copied at least once by the processor, whether by the kernel or user-space code, and whether from a shared IPC buffer pool or from dedicated interface buffers. It is then of negligible cost to introduce into the copying code a simple checksum or cyclic exclusive-or function (as used in XTP ). In addition, through suitable implementation, data which is never processed, need not be checked.
An alternative view is that a combination of current operating system environments and protocol stacks leads to the inefficiency of a software copy. For example, many operating systems lack mechanisms to allow network DMA into user address spaces (e.g. user processes cannot lock down pages), while at the point in the network interface where DMA could be simply implemented, a protocol stack can require a sufficiently complex demultiplexing operation, that the interface has insufficient information and intelligence to identify the target user address space.
An further extreme view is that PDU integrity might be ensured at the network level; this may be available in an ATM environment as a virtual circuit attribute in the style of QoS parameters. The network level can combine knowledge of the error performance of each individual data-link along the route and so may be able to offer a nothing-corrupt-if-delivered QoS.
Several observations are easily made:
These observations lead to a number of possible solutions: