The port controller design in Fairisle was aimed at producing an experimental platform rather than a product. This has led to a very flexible implementation in which functionality, once understood, can be placed in hardware (or more accurately, Xilinx firmware). VCI lookup, free queue management, retry strategy and telemetry have all migrated from the processor to hardware. We expect this trend to continue and in particular believe that low level queue management in hardware will follow.
The question then arises as to the need for the processor. We see the processor engaged in longer time scale activities, possibly altering the parameters of the low level queue management as conditions within the switch change. Thus, the processor need not be any faster than it is now for the line speeds we are dealing with, and as functionality migrates out we can see it being able to cope with higher transmission rates.
As mentioned above, maintaining a tight feedback loop between the contention point and queueing point within the port controller is important. This is a key part of the motivation for migrating functionality into the hardware. This may have direct parallels in host interface design - the response time of the host software may require that certain protocol functions be implemented in the host interface (e.g. any link based flow control).
The flexible implementation of the port controller has also allowed us to use the port controllers as traffic sources and monitoring devices whose in band functionality is completely configurable.
We were originally attracted to input buffering because of its inherent simplicity. We were well aware of its performance limitations, but were not overly concerned since we were considering the local area where utilisation is not a key factor. Oft cited head of line blocking was also not a concern since we were building port controllers that did not have to perform fifo queueing and a fabric that could run faster than the line rate.
This decision was clearly partly born of necessity; it allowed us, with our rather modest resources, to build a switch. There is no custom silicon in the design and although there are Xilinx devices, none is over 10,000 gates. However, our own experience and the example of AN2 has led us to believe that input buffered switches can achieve output buffered performance; this is achieved without the excessive hardware requirements of output buffered switches but rather by the application of more effective arbitration and/or the fabric speedups possible due to simplicity.
Something that is often overlooked in the discussion of fabrics is what happens to cells that must be discarded. The most effective discard policy would be implemented at a point in the switch where information derived from relevant higher level Quality of Service is available. Hence ``Hail Mary'' fabrics which can discard cells internally and are dimensioned on calculations that predict that such events are rare based on traffic assumptions, are unlikely to be universally valid.
Fairisle, because it allows blocking fabrics and blocking outputs must
deal with cells that do not get through; the input port controller is
always aware. The decision to actually throw a cell away can be made
in the processor if required. This fact is exploited in the Desk Area
Network; the connection between cache and memory is hardly going to be
successful if one in 
cache lines are thrown away!
A number of years ago a campaign was mounted to gain the acceptance of a new adaptation layer by CCITT, now known as AAL5. Part of this campaign was to acquire a bit (or more accurately code points) in the ATM cell header for communication of the frame boundaries.
Within Fairisle we have taken the approach of defining the semantics of the bit such that it is consistent with the current AAL5 usage and makes sense in the AAL1/2 and AAL3/4 cases. This has proved useful in dealing with congestion conditions and our experience has shown that it is straightforward to implement in switches.
The British Telecom sponsored extension to the Fairisle Project will be using the flexibility of the implementation to run a number of experiments with artificial and real traffic. We will be able to measure quantities such as cell loss, cell variation extremely accurately on a switch by switch basis.
The flexible manner in which processing functions are distributed
will also allow us to experiment with new signalling
architectures, in particular those based on ODP. We are
particular interested in the relationship between signalling,
security and third party setup. This is also the forward looking
direction being taken by the ITU-T for release 2 and release 3
B-ISDN signalling. We are contributing to this effort in the hope
that we never have to implement Q.93B / SSCOP / ...