The nearer we get to seeing complete implementations of the Open Systems Interconnection protocols, the louder the rumblings become that they will be simply inadequate for many applications. Already, segments of the industry are looking to implement 100Mbit-per-second FDDI Fibre Digital Data Interface fibre optic networks for real-time applications and others where speed is a premier requirement (CI No 933). But already, the limiting factor in Ethernet networks is typically the communications software; estimates suggest that of the 10Mbps nominal bandwidth in a TCP/IP Ethernetwork, only 1.2 Mbps is available to an application because of the layers of overhead imposed mainly by the TCP and IP protocols. Simply plugging in faster wiring or fibre optics clearly does not solve the problem. It would be nice if the Open Systems protocol stack could be simply implemented in silicon in a compact enough fashion to overcome the performance restrictions, but the OSI protocols are large, complex and general-purpose, and many feel that the current level of chip technology is just not up to it. Transfer protocol One unusual alternative approach is being pursued at Protocol Engines Inc, a Santa Barbara, California company spun out from workstation manufacturer Silicon Graphics Inc last September. Founded by Larry Green and Silicon Graphics chief scientist Greg Chesson, the company has a mission to exploit and promote Chesson’s ideas for a lightweight, specialised transfer protocol, corresponding to Open Systems layers three and four that can be implemented in silicon protocol engines to enable applications to use the full bandwidth of a network – and the company is aiming for the 100 Mbps of the FDDI standard as an early design goal. As Chesson puts it, the aim was to provide reliable communications where the protocol processing for a packet is completed within the minimum packet arrival time – effectively removing the overhead imposed by the protocols. The company has no pretensions to implementing higher-level services in silicon, and Chesson is keen to emphasise that he is not promoting a competitor to OSI: Protocol Engines’ Express Transfer Protocol, XTP, incorporates various specialised features, could theoretically coexist on a network with OSI transport protocols, and would typically be accessed directly – instead of through a stack of higher level protocols – for performance reasons by real-time applications. Among the design features cited by Chesson are extensions for reliable multicast systems (involving communications between more than two systems) and a real-time reliable datagram service. Initially, he is looking for an implementation in silicon – a chip set rather than a single chip, although later implementations may be shrunk onto a chip and a slower, Ethernet single chip implementation is planned. By hooking chips in parallel, the aim is to get up to the gigabit per second level eventually. Not too surprisingly, relatively little is yet available; the company has been designing a software emulation of the Protocol Engine and working on perfecting the XTP specification; according to Protocol Engines president Larry Green, target timescales not, as yet, committed delivery dates – include a stable XTP specification this summer, with several ports of a software XTP implementation for Unix, VRTX, and VMEbus specialist Interphase’s Smart operating system. By December, the company hopes to have a VME board emulating the Protocol Engine and providing half the 100Mbps target performance. A semi-custom implementation of the engine is due around the third quarter of 1989, to be followed by a full custom VLSI version in mid-1990.
Apart from the technical difficulties of Protocol Engines’ developments, there is of course the problem of getting people to adopt the products when they appear, and Protocol Engines has taken an equally unusual approach to proliferating the technology. A Technical Advisory Board, limited initially to 12 members, is being set up to operate as a consortium evaluating, providing feedback, and implementing
the technology. So far, members include Apollo Computer, Unisys, Martin Marietta, and, naturally, Silicon Graphics. The Board will probably also include semiconductor manufacturers contracted to make the chips; Protocol Engines will operate as a licensing and development company selling to and through the Board members. In addition, Chesson emphasises that much of the work of Protocol Engines will be put in the public domain. And for a young company, Protocol Engines appears to have attracted considerable interest elsewhere: the US Department of Defense group developing standards for military fibre optic networks is studying the use of XTP, and there is already an ANSI committee working on the formal adoption of XTP. Nevertheless, acceptance of XTP remains top of Green’s list of worries. Problem solved He considers funding to be less of a problem, despite the fact that Protocol Engines has a mere $250,000 in seed financing so far; Green said probably only $2.5m would be needed for production of the semicustom engines. Green sees three likely markets for the Protocol Engines products – military real-time local area networks, graphics data transfer between high performance workstations, and mainframe-to-mainframe communications. The company also hopes to get products adopted for the fibre optic metropolitan data networks currently beinmg worked on by AT&T and other telecommunications companies including British Telecom.
However, once the products start to appear, a new set of technical problems is likely to appear with them. As Chesson points out, no-one has implemented protocols in silicon that operate real-time networks at this level of performance before, and the properties of the networks will be quite different. But if the company does succeed in making the products perform and work together, the interest in them could well expand dramatically; and with the throughput problem solved, Chesson says that at last, the industry will be freed to concentrate on providing higher level services.
