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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

New Productslonger packets will have a greater store-and-forwarddelay, proportional to their length.A bridge must be able to store informationabout the location of the stations attached to itsLAN. If insufficient room exists to store all thestations in the station database, the bridge mustforward messages for any station that did not fit.This situation leads to inefficiency in the operationof the LAN, since traffic may be forwardedunnecessarily. Based on trends in network applications, we judged it unlikely that a singleextended LAN would grow to over 8000 simultaneouslyactive stations within the lifetime of thisproduct. Therefore, the storage limit was set at8000 station addresses.In addition to providing a low packet loss rateand efficient filtering, a bridge should not contributesignificantly to the data error rate of theextended LAN. Even more importantly, an undetectedbit error corrupting a packet while it is ina bridge should be detected at the destinationstation. This detection can be ensured to a highprobability by forwarding the received cyclicredundancy check (CRC) instead of generating anew CRC in the bridge.It is essential that a bridge be reliable andavailable, since it is as important in an extendedLAN as in the Ethernet cable itself. Therefore, theLANBridge 100 had to power up and operate correctlywithout the intervention of any person orother machine. Since a bridge is important to theproper operation of an extended LAN, a mechanismto ensure high network availability was alsorequired. Parallel standby bridges provided thatmechanism. The bridges also had to be able todetect and correct for many unworkable configurations,such as looping topologies, that mightresult from installation errors.Although a bridge must operate without intervention,a network manager should be able toobserve parameters and counters associated withthe bridge's operation. He should also be able toalter some of those parameters. A centrallylocated bridge is an ideal place from which toobserve activity in order to isolate faults andgather information. That information can then beused to make decisions about changes andenhancements to the particular network configuration.Of course, all these goals should be met with acost as low as possible. Although a bridge providesmany valuable features, it neverthelesscompetes with single Ethernet cables, withirepeaters, and with routers. Jo be successful, theLANBridge 100 had to be perceived as having acost/performance advantae relative to thoseother options.IDesign PrinciplesDesigning the LANBridge 1 00 hardware startedIwith the premise that a! general-purposemicroprocessor is often th most cost-effectivemethod for implementing sveral complex functionsin a single system. Microprocessors are flexibleand economical because the same set ofhardware logic can be used to perform many differentfunctions under program control . For anygiven technology, however, 'they are rarely as fastas dedicated logic. Therefore, the bridge wasdesigned to implement as many functions as possiblein microcode; special hardware logic wasused only for time-critical functions.With a sufficiently fast microprocessor, applyingthe principles above to the LANBridge 100requirements resulted in the high-level blockdiagram shown in Figure 5. This diagram is use,ful for understanding the general principles ofbridge operation and represents the first pass atthe LANBridge 100 design.Of course, this design: was based on thehypothesis that some available microprocessorwas fast enough to do all the required work inthe allotted time. In reality, orne hardware assistwas required. Moreover, the memory sizes andthe implementations of th Ethernet interfacesIhad not been considered. [fhese complicatingfactors are now examined ip more detail, alongwith the trade-offs that were required.1IProcessor and Suppor( LogicIA preliminary performance analysis of thebridge design in Figure 5 showed that all bridgefunctions, except associating network addresseswith forwarding informtion, could be handledby several available microprocessors. Assumingthat this exception could be. performed by externallogic, it was possible to consider other priceand performance requirements and select themost suitable processor.In this design, the microprocessor is directlyinvolved in making forwarding decisions, butwith hardware assistance. It also coordinates thepacket-forwarding process, although actual datamovement is the responsibility of the Ethernetinterface logic. Thus the microprocessor hassome stringent real-time requirements. Further-I<strong>Digital</strong> <strong>Technical</strong> journalNo. 3 <strong>September</strong> 198667

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

Saved successfully!

Ooh no, something went wrong!