DTJ Number 3 September 1987 - Digital Technical Journals

More documents

Recommendations

Info

New Productscess is one of the key aspects of the bridge technology.This facet is covered later in the paper inthe discussion of the technology used in the IANBridge 100 product.A final point with respect to caching is inorder. Further enhancements in performance canbe obtained by recognizing something about thenature of the traffic on IANs. Extensive measurementson token rings, Ethernets, etc. have uncoveredseveral important facts. These are related tothe nature of higher-layer protocol and applicationoperation. One is that, given that a framefrom station S and station D has just beenobserved on the LAN , the probability that thenext frame observed is either from D to S or alsofrom S to D is very high.21 Thus, if the bridgekeeps the last few associations it has obtainedfrom the database, it is very likely that the nextframe will use one of those associations. Keepingthem further reduces table access rates. Itamounts to a two-level cache .With these observations we now focus on congestionat the receive or transmit buffers. Congestionat the receive buffers canbe avoidedthrough proper machine organization. For example,a bridge using separate controllers for eachIAN, each controller having its own local buffering,will have to assure that sufficient bufferingis available to maintain stability in the queue(particularly during transient bursts of frames) .Frames will have to be moved (out of the controllerbuffers or shared mmory) into anotherbuffer to queue for the forwrding process. WithIrespect to bridge delay, ths time must also beincluded in the forwarding process. With respectto bridge throughput, the bottleneck server willdetermine the peak.Therefore, the only place any congestion willoccur in these bridges is at the outbound IAN.This congestion will occur if that LAN is notfast enough for the volurrle of traffic it mustcarry. This problem is an isse of IAN speed, notbridge speed. The philosophy is to designbridges so that they will not be bottlenecks.Most of these comments apply to any routingalgorithm and hold true whether a table or aframe must be searched. AQ.d they hold true for·all the MACs.Effect of Bridges on Ethernet LinksIBridges have several effects' on the performanceof CSMAfCD IANs. One effect is due to the filteringfunction that prevents traffic from entering asubnet that it need not traverse . Recall thatbridges operate above the data link MAC layer asshown in Figure 4. Preventing this traffic flowAPPLICATIONLAYERAPPLICATIONLAYERNETWORKLAYERIINETWORKLAYER------- ·--------------------------------------------------------------------j _______ -------BRIDGEBRIDGE FUNCTIONSDATA LINKLAYERPHYSICALLAYERPHYSICAL MEDIUMDATA LINKLAYERDATA LINKLAYERPHYSICAL PHYSICALILAYERLAYERPHYSICAL MEDIUMpiDATA LINKLAYERPHYSICALLAYERFigure 4Bridges and Data LinksDigital Technicaljournal 65No. 3 September 1986
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 IANBridge 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
Page 1 and 2:
Netwo;king ProductsDigital Technica
Page 3 and 4:
Editor's IntroductionRichard W. Bea
Page 5 and 6:
BiographiesRaj Jain Raj Jain gradua
Page 7:
BiographiesDavid R. Oran Dave Oran
Page 10 and 11:
increase the sizes of networks, we
Page 12:
New Productsmust be able to coexist
Page 15 and 16: A Digital Network Architecture Over
Page 21 and 22: ---A Digital Network Architecture O
Page 27 and 28: Performance Analysis and Modeling o
Page 29 and 30: ---Performance Analysis and Modelin
Page 31 and 32: Performance Analysis and Modeling o
Page 33 and 34: ---Performance Analysis and Modelin
Page 35 and 36: --Performance Analysis and Modeling
Page 37 and 38: The DECnet/SNA Gateway Product• H
Page 39 and 40: The DECnetjSNA Gateway ProductFrom
Page 41 and 42: The DECnetjSNA Gateway Productcommu
Page 43 and 44: The DECnetjSNA Gateway ProductUSER
Page 45 and 46: The DECnetjSNA Gateway ProductThe u
Page 47 and 48: The DECnetjSNA Gateway ProductDECne
Page 49 and 50: The DECnetjSNA Gateway Productopera
Page 51 and 52: The DECnetjSNA Gateway ProductSegme
Page 53 and 54: The DECnetjSNA Gateway Product• O
Page 55 and 56: WiUiam R. HaweMark F. KempfAlanJ. K
Page 57 and 58: The Extended Local Area Network Arc
Page 65: The Extended Local Area Network Arc
Page 75 and 76: Terminal Servers on Ethernet Local
Page 89 and 90: Paul R. Beckjames A. KryckaThe DECn
Page 91 and 92: The DEC net- VA X Product - An Inte
Page 93 and 94: The DECnet- VA X Product - An Integ
Page 95 and 96: The DECnet- VAX Product - An Integr
Page 97 and 98: The DEC net- VA X Product - An Inte
Page 99 and 100: The DECnet- VAX Product - An Integr
Page 101 and 102: john Forecastjames L. jacksonjeffre
Page 103 and 104: The DECnet,ULTRIX SoftwareComponent
Page 105 and 106: The DECnet- ULTRIX Softwarehave pro
Page 107 and 108: The DECnet- ULTRIX Softwaresystems.
Page 109 and 110: Peter 0. MierswaIDavid J. MittonMar
Page 111 and 112: The DECnet-DOS Systemthat CCB, whic
Page 113 and 114: The DECnet-DOS Systemdata link laye
Page 115 and 116: Tbe DECnet-DOS SystemNDU and the vi
Page 117 and 118:
Th e DECnet-DOS Systemconsole can a
Page 119 and 120:
The Evolution of Network Management
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
The NMCCjDECnet Monitor Design5. Op
Page 133 and 134:
Th e NMCCjDECnet Monitor DesignFigu
Page 135 and 136:
The NMCCjDECnet Monitor DesignKERNE
Page 137 and 138:
The NMCCjDECnet Monitor Designinto
Page 139 and 140:
The NMCCj/JECnet Monitor DesignThe
Page 141 and 142:
The NMCCjDECnet Monitor Designcan s
Page 143 and 144:
Editorial StaffEditor - Richard W.
show all

DTJ Number 3 September 1987 - Digital Technical Journals

Create successful ePaper yourself

Delete template?

Save as template?