DTJ Number 3 September 1987 - Digital Technical Journals

The Extended Local Area Network Architecture and LAN Bridge 100reduces the applied load on the LAN , thusimproving performance for the local users.Another effect is more subtle. Consider aCSMAfCD system with an extent of D meters andN stations distributed uniformly over that extent.Without using bridges, all N stations have toshare the resources of that one LAN extendedover D meters. The delay and capacity are determinedby the applied load, as described above . Ifadded in the center of the system, the Ethernetwill be partitioned into two Ethernets, each withN/2 stations . Thus the collision windows oneach partition have been cut in half. The smallercollision windows cause less bandwidth to bewasted per collision. The net effect on the systemis not only to reduce the load applied to agiven Ethernet (through filtering) , but also toimprove the overall efficiency or capacity of thatEthernet since the extent it must cover is smaller.In effect, the Ethernet gets more efficient as theload applied to it is reduced. Given these factors,along with performance information characterizingthe behavior of the Ethernets under load, thebridge designer can investigate the performanceof bridged networks using these IANs.4 ,22The remaining section of this paper discussesthe IANBridge 100, which is an implementationof the Extended IAN Architecture .Development of the LANB ridge 100The bridge architecture was developed in parallelwith the first implementation of that architecture. An Ethernet-to-Ethernet bridge, wasdesigned as a prototype to demonstrate the usefulnessand practicality of the bridge concept.This was called the "Brooklyn Bridge ." The prototypehardware and software were operated in alaboratory environment. After some operatingfor a time, the prototype was installed in Tewksbury,Massachusetts, between an Ethernet andDigital's Engineering Network (ENet) . This prototypeled to a full-scale product developmentproject, called Janus, that resulted in the IAN­Bridge 100.The prototype incorporated some , but not all,of the higher-level reliability and availability featuresof the final LANBridge 100. Many of thefinal features were incorporated by the productdevelopment groups as the final product designevo lved. Another feature added in developmentwas a fiber-optic Ethernet extension that allowsnetworks to be extended farther than is possiblewith the Ethernet cable alone .In the following sections, the design goals andprinciples of the IANBridge 100 are discussed,along with the trade-offs that had to be made inthe design.Design GoalsThe design of the IANBridge 100 was guided byone primary principle: The bridge characteristicsshould not cause the performance of theextended network to degrade . Network congestioncould cause such a degradation, but not thebridge. Therefore, the bridge had to have sufficientprocessing power to receive any possiblestream of incoming traffic and make the correctforwarding decisions. If some or all traffic is tobe forwarded, the bridge must queue it for forwarding.If the outbound Ethernet is congested,however, it may be impossible to fo rward thepackets and some or all may eventually have tobe discarded. This is a problem of network utilization,however, and not bridge design.Although a bridge must discard packets duringperiods of prolonged congestion, it should notdiscard traffic during periods of transient congestion.Therefore, the bridge must provide sufficientbuffering to prevent packet loss during thetraffic peaks occurring in any properly operatingIAN. When the individual Ethernets are operatingclose to saturation, any IAN 's performancewill be generally unsatisfactory regardless ofthe presence or performance of bridges. When aLAN is operating in the range in wh ich goodperformance can be expected, transient congestionmay still occur. In this case, packet lossin bridges can be avo ided with a boundedamount of buffer memory, an amount that can bepredicted.Since bridges can be installed in series, theissue of store-and-forward latency becomesimportant. In varying degrees, higher-level protocolsare intolerant of delay; therefore, storeand-forwarddelay must be kept to a minimum.Ideally, this delay should be equal to the packetreception time; however, some additional time isneeded to make the forwarding decision. Even ifthe decision process were partially overlappedwith the packet reception , this decision couldnot be made until after the frame checksequence (FCS) had been received at the end ofthe packet. The nature of the applications inwhich bridges were expected to be used led usto choose 100 microseconds as the maximumlatency for minimum-sized packets . Of course,66Digital TecbnicalJournalNo . 3 September 1986