Host and workstation ATM interface design.

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:

1. sorting, or fragmented reassembly, of received cells according to their incoming VCI/VPI - and for protocol stacks such as AAL-3/4, sorting on fields within the payload (e.g. the MID), and;

2. the extraction and checking of per-cell adaptation layer check functions and protocol headers.

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 [10].

Cost and role of end-to-end check functions.

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 [12]). 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:

1. Within a reliable end-system, it is pointless to implement a transport level integrity check of the same strength (or weaker strength) than an already implemented end-to-end check at a lower protocol level.

2. A CRC algorithm is the best type of data check, given that we are considering heterogeneous ATM networks, including radio and optical mobiles, where the error rates will typically be higher than in B-ISDN.

3. CRC calculation in software is too slow and CPU intensive for most applications (which is why weaker checksums have normally been used).

4. The network interface is a potentially sensible place to put CRC hardware.

5. If hardware in the interface is helping with the adaptation layer requirement that PDUs which are wrong owing to cell removal, repositioning or replication are not (eventually) discarded, it must perform a check on the cells. This is either with per-cell sequence numbers or whole PDU check functions (e.g. CRC).

These observations lead to a number of possible solutions:

1. Do not check cells at the adaptation layer. Instead, pass up to the transport layer all cells received on a virtual circuit until the end-of-PDU indication is set, then check only at the transport layer. This essentially results in a transport protocol which is able to operate directly on concatenated ATM cell payloads. There is no reason why it should not also be able to operate and inter-work with instances of itself on non-ATM data-links.

2. Implement a specified level of checking at the adaptation layer, then pass up the partially checked PDU to the transport layer software, where the remainder of the checking is done. This may in fact be a sensible approach if, as mentioned, for efficiency the transport entity can only do weak checking, such as checksum (checksum does not spot out-of-order cells.)

3. Fully reassemble and check each received PDU at the adaptation layer and then pass up only correct PDUs with the implicit semantic that they are checked and correct.

4. Calculate the CRC (or other check) of each cell payload in the interface and pass up this partial CRC along with the payload. The benefit of this is that higher level software is able to combine the partial CRCs to obtain a full CRC for the PDU at twelve times the rate it would achieve by performing the whole CRC in software.