10.07.2015 Views

DTJ Number 3 September 1987 - Digital Technical Journals

DTJ Number 3 September 1987 - Digital Technical Journals

DTJ Number 3 September 1987 - Digital Technical Journals

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

The Extended Local Area Network Architecture and LANBridge 100have exceeded not only the capabilities of anyrealizable bridge, but of the underlying networktechnology as well. However, there is the moreinteresting question of the magnitude and durationof traffic transients in real networks, and theamount of memory required to avoid packet lossduring those transients.The size of the bridge memory can be boundedif one notes that most high-level protocols builton a datagram service like Ethernet expect tiinelypacket delivery. If the delivery of a packet isdelayed excessively, these protocols treat thepacket like a lost datagram and retransmit it. Inthese circumstances forwarding the originalcopy has the undesirable effect of generatingmultiple copies, thus increasing network congestion.One way to avoid this problem is toemploy the concept of maximum packet lifetime.This concept is enforced by the bridge andc:in be used to place an upper limit on bridgememory requirements. Unfortunately, even arather short packet lifetime requires largeamounts of memory. For example, a lifetime oftwo seconds requires five megabytes of memory(lOMB/second X 2 seconds X 2 directions -:- 8) .Although declining costs may make memories ofthis size practical in the future, packet lifetimecould not be used to size memory for thisproduct.Another way to size bridge memory is to simulatethe behavior of the system under variousworkloads. The LANBridge 1 00 can be modeledrather easily if one notes that the bridge takes lesstime in deciding to discard or forward a packetthan the packet takes to transmit. In this case theforwarding operation will not be a bottleneck,and the receive buffers will never hold morethan one packet. The transmit buffers, however,will be emptied at a variable rate depending onthe load on the Ethernet.We considered four different workloads: thefirst based on an existing timesharing environment,the second on a file transfer application,the third on a process control system, and thefourth on a hybrid of office and process control .The results showed that 16KB of memory (ineach direction) was inadequate. Increasing thememory size beyond 64KB gained very little interms of performance . Therefore, since 64KBmemories were readily available, a 16-bit memorybus provided the required 128KB in a convenientand cost-effective manner.Packet Memory PerformanceThe packet memory system in the bridge wasdesigned to handle worst-case conditions withoutallowing overruns, underruns, or processormemory · cycle starvation. The worst case occurswhen both Ethernet interfaces are continuouslyreceiving but not forwarding Ethernet packets ofthe minimum size (64 bytes) . The packet sourceand destination addresses are examined onlywhen a packet is received. Therefore, if the packetswere forwarded, fewer memory cycles wouldbe required. If the packets were longer, thenumber of memory cycles needed to deal withbuffer descriptors would be reduced, sincemore data would be contained in each buffer.Under worst-case conditions, the memory musttransfer approximately 108 16-bit words perminimum packet time (63.3 microseconds) .When the required memory refresh cyclesare also included, one memory cycle takes580 nanoseconds.The packet memory system must also providelow-latency microprocessor access so that valuableCPU cycles are not lost because of packetmemory wait states. Since the LANCE chips areburst-transfer direct memory access (DMA)devices, any shared bus system would have aninherently unacceptable latency. Therefore, aftersome analysis, a four-port memory system waschosen: a port for each LANCE, a port for theCPU, and a port for the refresh operation. Thememory is fully buffered so that the RAMs themselvescycle every 300 nanoseconds, eventhough the LANCE has a 600-nanosecond minimumcycle time, and the CPU has a 400-nanosecondminimum cycle.The Final LANB ridge 100 DesignA high-level block diagram of the final !.AN­Bridge 100 design is shown in Figure 6. Its logicis quite similar to the original prototype designin Figure 5. The primary change was the additionof hardware to assist in locating forwarding information.In addition, the single bus has beendivided into several buses to increase the totalbandwidth of the system.SummaryThe LANBridge 1 00 is the first product to implement<strong>Digital</strong>'s Extended LAN Architecture. Withthis product, customers may easily expandbeyond the confines of a single Ethernet to an70<strong>Digital</strong> Tecbnical]ournalNo. 3 <strong>September</strong> 1986

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!