DTJ Number 3 September 1987 - Digital Technical Journals

New Productshas already been added. Therefore , two 48-bitnetwork addresses must be located for eachpacket received. It cannot be assumed that the48-bit source and destination addresses found invarious packets have any known relationship toeach other. On the other hand, the addresses arelikely to occur in groups because each of the variousequipment manufacturers has been assigneda block of addresses. The look-up function mustoccur quickly,-since only a small ponion of thetime available for processing each packet can bedevoted to this. one function.There are several possible techniques for lookingup network addresses. One straightforwardapproach is based on a software search performedby the microprocessor. With this technique,the microprocessor fetches a networkaddress from a packet and then searches the database.Even with efficient search algorithms andthe fastest available microprocessor, however,this technique is much too slow, especiallywhen.the database is filled to capacity.A second.•approach, also based on software, isto use the source or destination address as anindex into a: table. This technique has the advantageof.being fast; yet, it is quite impractical ,since the table length would be almost 280 billion(248) entries.A third solution is hashing, which might be fastenough in software and could also be easilyimplemented in hardware. In this technique,48-bit addresses are transformed by an arithmeticfunction to a hash address with a smaller maximumvalue of the address . For example, ifthe maximum hash value were .216, a directtable look-up could be ;performed, using thehash address as an index. The disadvantage ofhashing is that the distribution of-networkaddresses is not known a pFiod; therefore, manynetwork addresses could translate to the samehash address. This duplication could resultin either unnecessary forwarding or incorrectfilterig.'Thus all three software solutions were unusable.It became clear that some type of hardwareassist was required. The most attractive hardwareassist from the -standpoint of speed and ease ofuse was content addressable memory (CAM) .Unfortunately, the available CAMs were bestsuited for use in cache memory applications,since they are small and faster than needed (thus,more expensive) . These CAMs also do not scale.wt Hrin width; for example, 8-bit wide CAMs can-not be easily used in parallel to form a 16-bit ora 48-bit wide CAM. .:IThe only feasible alternative remaining was toemploy a hardware-assisted search using economical,commercially avaHable memories fordata storage. Binary search w:as cb.sen as thesearch algorithm. This search technique is fastsince it requires at most log( n) probes, where nis the number of entries i n the table. Unfortunately,the table must be kept soned in numericorder. That is not a severe disadvantage, however,since the table can be soned in place withoutinterrupting search operations.In the IANBridge 100, tl;ie search function isperformed entirely in hardWare at the request ofthe .microprocessor. The microprocessor loadsthe search hardware, or binary search engine,with network addresses fetched from a packet.The engine then runs in parallel while the processor,doesother work. Aftr 3.9 microseconds,the microprocessor logic [ returns to read the·results of the ·search.Although-searching is a hardware function, themicroprocessor uses software to order the tableof network addresses. Reordering must be doneonly when new stations are, added or when inactivestations are removed. these events happenrelatively infrequently, and analysis and experiencehave shown that software is fast enough notto hinder operations. If there are several changesin a shon time · (for example, during the initiallearning period) , they are cached and added, atlower priority, to the search table.IPacket Memory SizeUpon determining that a packet received on oneEthernet should be forwarded to another Ethernet,the IANBridge 1 00 must queue the packetfor transmission. Since Ethernet is a shared channel,the bridge must prov i de buffering to storeall packets that might be queued while the Ethernetis busy with traffic from other users. Theamount of buffer memory must be large enoughto avoid excessive packet loss resulting frombuffer exhaustion, yet smll enough to be costeffective.1Over the long term, if the average traffic generatedby a bridge and other users on a single Ethernetexceeds the total capacity, only/an infiniteamount of memory will prevent packet loss. Inthis case latency will incease without bound.This situation is rather uninteresting from the\Standpoint of bridge design. The system user willDJglltll•TecbnicoljournalNo. 3 ·september 198669