Ba y Bridge 29 - Stanford Universitytiny-tera.stanford.edu/~nickm/papers/BayBridge/performan...Ba y Br i d g e 27 m or e m ar k ed i n t h ecaseof F D ItoF Ib ri d gi n gi n w h ichan

Bay Bridge 29

[11] Edell , R.; Le, M. and McKeown, N. ; \The BayBridge: A Hi gh SpeedBri dge/Router , " i n Proceedings of IFIPS Workshop on PfHSN, May 92.

[ 12] Le, M. , McKeown, N. and Edel l , R. ; \AHi gh Performance SMDS Interf aceat STS-3c Rate, " IEEE J. Selected Areas i n Comms, submi tted f or thi si ssue.

[ 13] Comer, D. E. , \Internetworki ng wi th TCP/IP, " Prent i ce Hal l , Vol . 1, 2ndEd. , 1991

[ 14] Gei ger , E. ; Estes , G. ; Si ncoski e, W. D; Sammart i no, F. and Lyl es ,B. , \INetwork Compati bl e ATMf or Local Network Appl i cat i ons | Phase1, " Proposal , Vers . 1. 0, Apri l 92

Revision: 2.0

Ba y Br i d g e 2 8

6 Acknowledgements

We are gratef ul to Paci �c Bel l , Bel l core, SunMi crosystems, AdvancedMi cro De-vi ces , TranSwi tch, Integrated Devi ce Technol ogy, Vi ewl ogi c, Hewl ett - Packardand MUSICSemi conductors f or thei r mater i al and techni cal ass i stance. Muchcredi t i s al so due to the f ol l owi ng students at UCBerkel ey who have contr i butedmany hours to thi s project : Ti ng Kao, Fred Burghardt , Mal i k Audeh, GeorgeKesi di s , Karl Petty and Steve McCanne. And �nal l y, we thank our f acul tyadvi sers Prof essors Pravi n Varai ya and Jean Wal rand f or thei r support .

References

[ 1] \Gener i c Systems Requi rements i n Support of Swi tched Mul t i -megabi tData Servi ce, "Bel l core Techni cal Ref erence TR-TSV-000772, May 91

[ 2] Kapoor, S. and Parul kar , G. ; \Desi gn of an ATM-FDDI Gateway, "i n Proc. of ACM/SIGCOMM'91 on Communi cat i on Archi t ectures and

Protocol s, Sept . 91

[ 3] \P802. 1g MACRemote Bri dge Draf t Standard, " IEEEProject 802 Com-

mi t t ee P802. 1g

[ 4] Katz, D. ; \AProposed Standard f or the Transmi ss i on of IP Datagramsover FDDI Networks, "Draf t RFC, Oct . 90

[ 5] Pi sci tel l o, D. ; Lawrence, J. ; \The Transmi ss i on of IP Datagrams over theSMDS Servi ce, "Draf t RFC, Mar. 91

[ 6] Hedri ck, C. ; \Routi ng Inf ormati on Protocol , " Draf t RFC, June 88

[ 7] Fedor, M. ; \GATED: AMul t i - Routi ng Protocol Daemon f or UNIX, "Proceedi ngs of the 1988 USENIX conf erence, San Franci sco, Cal i f orni a

[ 8] Moy, J. ; \The OSPF Speci �cat i on, " Draf t RFC, Oct . 89

[ 9] I nst i tute of El ectr i cal and El ectroni c Engi neers , I nc. IEEE Standard802. 1D.

[ 10] Backes, F. ; \Transparent Bri dges f or Interconnect i on of IEEE802 LANs, "IEEENetwork, Vol . 2, No. 1, Jan. 88

Revision: 2.0

Ba y Br i d g e 2 7

more marked i n the case of FDDI to FDDI bri dgi ng i n whi ch an i ncrease of 138%i s achi eved i f no l earni ng i s carr i ed out . A l arge i mprovement i n throughputcoul d be achi evedby adopt i ng a scheme to reduce the t i me spent l earni ng duri ngper i ods of hi gh throughput. For exampl e: (1) source addresses coul d be storedi n a separate FIFOand l earnt duri ng a l ess busy t i me, f or exampl e when thei nput FIFObecomes empty or when a f rame i s f orwarded that i s much l ongerthan Lmin; (2) many source addresses coul d be packed i nto a si ngl e f rame andsent to the l ocal host , whi ch coul d per i odi cal l y update the address tabl es ; (3)source addresses coul d be l earnt on every n- th f rame that i s recei ved. Sourceaddresses f rombusy stat i ons wi l l st i l l be l earnt i n a short t i me wi th an i ncreasei n perf ormance.

5.2 Improving Performance Further

We have seen that hi gh perf ormance and exi bi l i ty i s provi ded by the ProtocolConverter . Thi s i s i n part due to i ts customi zed desi gn and part l y because bothProtocol Converters are abl e to operate i n paral l el f or most of the t i me. Butthere are a number of l i mi tat i ons of the current desi gn that are bei ng consi deredf or f ol l ow- on work:

Multiple Ports. The current desi gn onl y al l ows two network i nter f aces . Thearchi tcture i s f ul l y- connected and does not l end i tsel f to expansi on tomore ports . We are current l y consi der i ng a desi gn based on a f ul l y-i nterconnected backpl ane usi ng a f ast , paral l el crosspoi nt swi tch. Theswi tch woul d e�ect i vel y be an ATMLAN swi tch [ 14] wi th hi gh speedbri dgi ng and rout i ng capabi l i t i es on each port . Each port woul d contai none or more network i nter f aces and an i ntegrated Protocol Converters i onuni t .

Shared Address Tables. The current desi gn i s l i mi ted, i n some con�gura-t i ons, by the bandi wdth of the address tabl es . Thi s woul d become moreof bott l eneck wi th the mul t i pl e port con�gurat i on descr i bed above. Toovercome thi s , we are consi der i ng the use of a separate address- cache f oreach port . Thi s coul d be i n two l evel s |a l arge associ at i ve cache usi nga CAMand a smal l on- chi p cache of s i mi l ar s i ze to a transl at i on l ooka-s i de bu�er (TLB) used i n convent i onal processors . I n addi t i on, one ormore ports woul d be used f or l arge dedi cated address tabl es f or l ooki ngup unknown physi cal or network addresses . I f the l ocal cache(s) does notcontai n the dest i nat i on address , the central address tabl es are consul ted.

Header Prediction. A f urther advantage of the TLB cache i s that MACorIPheaders coul d be cached and used as templ ates f or header predi ct i on.

Revision: 2.0

Ba y Br i d g e 2 6

5.1 The Cost of Encapsulati on, Val idati on and Learning

for FDDI-SMDS

I t i s worth summari zi ng the reasons f or the l ower perf ormance when bri dgi ngbetween FDDI and SMDS rather than between FDDI and FDDI . These are:

Encapsulation| bui l di ng the encapsul at i ng SMDS and LLC/SNAPhead-ers takes 2:25�s and contr i butes 33. 8%of the t i me to bri dge one packetf romFDDI to SMDS. Al though encapsul at i on i s necessary f or br i dgi ng,the process i ng t i me i s made worse by a l arge number of SMDS header�el ds and 8 bytes of LLC/SNAPheader (redundant, i n the authors ' opi n-i on [ 12] ) .

SMDSSourceAddress Validation|i n a pri vate LANsuch as FDDI , i ti s not usual f or a l ocal br i dge to val i date that a f rame was recei ved f romaknown host : i n f act , i n a l earni ng bri dge, there may be no such thi ng as a\known host" at start - up. But i n an encapsul at i ng bri dge, where f ramesare recei ved f roma smal l number of remote bri dges, i t i s f eas i bl e to ver i f ythat the f rame was recei ved f roma l egi t i mate member of the bri dge group.Thi s i s prudent when f rames are recei ved over a publ i c network. But wesee that i n thi s i mpl ementat i on, val i dat i on contr i butes over 23%of thet i me to process a f rame recei ved f romSMDS. I t shoul d perhaps be l ef t tothe di scret i on of the network admi ni strator to determi ne whether sourceaddress val i dat i on i s necessary.

FDDI DestinationAddress Validation|Apotent i al bene�t o�ered byan encapsul at i ng bri dge i s that al l encapsul ated FDDI f rames recei vedacross the SMDS i nterf ace are potent i al l y f or stat i ons reached vi a the l ocalFDDI ri ng. Thi s means that �l ter i ng i s not str i ct l y necessary. However , abr i dge coul d recei ve an unnecessar i l y mul t i cast SMDS f rame f roma remotebri dge wi th l ess i nf ormati ve address tabl es than i ts own (the remote bri dgemay have onl y recent l y j oi ned the group or coul d have no rooml ef t i ni ts address tabl es) . The recei vi ng bri dge may know that the f rame i snot dest i ned f or thi s FDDI ri ng and di scard i t . Thi s potent i al l y reducestra�c on the l ocal r i ng. But i t comes wi th a penal ty of al most 1�s perf rame, reduci ng the maxi mumthroughput by over 17%. Thi s i s al mostcertai nl y not worth i t , part i cul ar l y as the remote bri dge shoul d qui ckl yl earn the correct address to f orward f rames to. Al so, unl i ke SMDS, i nmost organi zat i ons the FDDI servi ce i s not charged per- f rame.

Another l arge component of the per- f rame process i ng t i me i s address l earni ngf or br i dgi ng. Thi s contr i butes al most 20%of the process i ng t i me i n the FDDIto SMDS di rect i on and over 30%i n the SMDS to FDDI di rect i on. Thi s i s even

Revision: 2.0

Ba y Br i d g e 2 5

Con�guration Per port or Conditions Throughput T bhdr Lb

min

Aggregate (frames/sec) (�s) (bytes)

FDDI to SMDS 1 port l earni ng 150, 375 6. 65 187stat i c 185, 185 5. 40 145

SMDS to FDDI 1 port address 196, 078 5. 10 23val i dat i onno address 333, 333 3. 00 0val i dat i on

FDDI - SMDS Aggregate l earni ng 300, 751 | |l earni ng & 321, 637 | |no val i dat i on

FDDI - FDDI 1 port l earni ng 327, 870 3. 05 64stat i c 555, 555 1. 80 26

Aggregate l earni ng 465, 116 | |stat i c 1, 111, 111 | |

Tabl e 1: Summary of br i dgi ng perf ormance f or di �erent con�gurat i ons of The

BayBridge .

Con�guration Per port or Conditions Throughput T rhdr Lr

min

Aggregate (frames/sec) (�s) (bytes)

FDDI to SMDS 1 port wi th bri dgi ng 132, 450 7. 55 143no bri dgi ng 158, 730 6. 30 101

SMDS to FDDI 1 port br i dgi ng & 133, 333 7. 50 197val i dat i onno bri dgi ng 212, 765 4. 70 20or val i dat i on

FDDI - SMDS Aggregate bri dgi ng & 266, 666 | |val i dat i onno bri dgi ng 372, 340 | |or val i dat i on

FDDI - FDDI 1 port wi th bri dgi ng 168, 067 5. 95 89no bri dgi ng 212, 765 4. 70 48

Aggregate wi th bri dgi ng 336, 134 | |no bri dgi ng 425, 530 | |

Tabl e 2: Summary of rout i ng perf ormance f or di �erent con�gurat i ons of The

Ba y Br i d g e .

Revision: 2.0

Ba y Br i d g e 2 4

Tpc

r= 3.75sus

Time (us)

IP data (bytes)

2.00

6.00

8.00

10.00

12.00

14.00

16.00

0.00 50.00 100.00 150.00

0.00

FDDI Dataarrival time 80ns/byte

Maximum throughput per portBFPS = 168,067 frames/secport


Data copy time 50ns/byte

Minimum length back-to-back packet = 89 bytes


Time to process frames, withoutsimultaneous MAC bridging

Time to process frames, withsimultaneous MAC bridging

FDDI & IP Header arrival time 3.28us

Tat

r = 2.20us

Tat

r= 0.95us

Fi gure 14: Perf ormance of one port of The Ba y Br i d g e f or FDDI - FDDI rout i ngwi th and wi thout s i mul taneous bri dgi ng wi th l earni ng.

Revision: 2.0

Ba y Br i d g e 2 3

BuildingLLC/SNAP& IPHeaders 35 cycl es

Address Lookup 19 cycl es

Address Learning 25 cycl es ( i f al so br i dgi ng)

CopyingIPpacket 1 cycl e per byte

Hence, Tbhdr = 5: 95�s . Thi s corresponds to a maxi mumthroughput of RPPSport =168; 067 packets per second per port . I f the router i s not al so worki ng as a bri dgethen the throughput i ncreases by 26. 6%to RPPSport =212; 766 packets persecond per port .

Fi gure 14 i l l ustrates the perf ormance of one port of The Ba y Br i d g e f or FDDI -FDDI rout i ng wi th and wi thout l earni ng. As can be seen f romthe �gure,Lrmin = 89 bytes i f the router i s al so act i ng as a bri dge. Thi s decreases to

Lrmin =48 bytes i f the router does not l earn MACaddresses .

4.3.5 AggregateFDDI-FDDI IPRouting

For FDDI - FDDI rout i ng, the address tabl es do not provi de a bott l eneck and sothe aggregate throughput i s s i mpl y twi ce the per- port throughput. Wi th si mul -taneous bri dgi ngRPPSagg =336; 1346 packets per second andwi thout bri dgi ngi ncreases by 26%, to RPPSagg =425; 530 aggregate packets per second.

4.4 Summary of Performance

Tabl e 1 summari zes the bri dgi ng perf ormance f or The Ba y Br i d g e con�gured asan FDDI - FDDI and FDDI - SMDS bri dge and Tabl e 2 summari zes the bri dgi ng

perf ormance f or The Ba y Br i d g e con�gured as a router .

5 Concl usions

We have descr i bed i n some detai l archi tecture, f unct i on and perf ormance of The

Ba y Br i d g e f or i nterconnect i ng FDDI LANs over the publ i c SMDS network. Totalaggregate throughput f or FDDI - SMDS was shown to exceed 300, 000 f rames persecond f or br i dgi ng and 250, 000 packets per second f or rout i ng. We have al sopresented resul ts f or FDDI - FDDI bri dgi ng and rout i ng. I n thi s con�gurat i on,the aggregate bri dgi ng throughput i ncreases by over 50%to more than 450, 000f rames per second.

Revision: 2.0

Ba y Br i d g e 2 2

Tpc

r= 3.75us

Time (us)

10.00

15.00

20.00

25.00

0.00 50.00 100.00 150.00 200.00 250.00 300.00

0.00

IP Data size (bytes)


Time for IP framesto depart over FDDI

Minimum length back-to-back frame = 20 bytes


Tat

r = 3.75us

Maximum throughput per portRPPS = 133,333 frames/secport


Time to process packetswith address validation & simultaneous bridging

Time for IP framesto arrive over SMDS

5.00

Tat

r = 0.95us

Maximum throughput per portRPPS = 212,765 frames/secport

Time to process packetswithout address validation or simultaneous bridging

Fi gure 13: Perf ormance of one port of The Ba y Br i d g e f or SMDS-FDDI rout i ngwi th and wi thout s i mul taneous bri dgi ng and address val i dat i on.

Revision: 2.0

Ba y Br i d g e 2 1

4.3.2 SMDStoFDDI IProuting

The ti me f or The Ba y Br i d g e to route one IPpacket i n hardware f roman SMDSnetwork to an FDDI network i s made up of the f ol l owi ng components:

Protocol Converter Set-Up40 cycl es

BuildingLLC/SNAP&IPHeaders 35 cycl es



ValidateSMDSSourceAddress 24 cycl es


Hence, Tbhdr =7: 50�s . Thi s corresponds to a maxi mumthroughput of RPPSport =133; 333 packets per second per port . I f the router i s not al so worki ng as a bri dgeand SMDS source addresses are not val i dated then the throughput i ncreases by59. 6%to RPPS port =212; 766 packets per second per port .

Fi gure 13 i l l ustrates the perf ormance of one port of The Ba y Br i d g e f or SMDS-FDDI rout i ng wi th and wi thout bri dgi ng and SMDS source address val i dat i on.Lrmin =197 bytes i n thi s case and drops to Lrmin =20 bytes i f the router i s

not s i mul taneousl y act i ng as a bri dge and i f SMDS source addresses are notval i dated.

4.3.3 AggregateFDDI-SMDSIPRouting

Usi ng the same techni que as i l l ustrated i n Fi gure 8 we determi ne the aggregatethroughput f or FDDI - SMDS IP rout i ng. Wi th si mul taneous bri dgi ng i n bothdi rect i ons and wi th address val i dat i on, RPPSagg =266; 666 aggregate packetsper second. Wi thout si mul taneous bri dgi ng or address val i dat i on, throughputi ncreases by 40%, and RPPSagg =372; 3406 aggregate packets per second.

4.3.4 FDDI-FDDI IPRouting

The ti me f or The Ba y Br i d g e to route one IPpacket i n hardware f romone FDDInetwork to another FDDI network i s made up of the f ol l owi ng components:


Revision: 2.0

Ba y Br i d g e 2 0

Tpc

r= 5.25us

Time (us)

5.00

10.00

15.00

20.00

25.00

0.00 50.00 100.00 150.00 200.00 250.00 300.00

0.00

FDDI data size (bytes)


Time for IP framesto arrive over FDDI



Tat

r = 2.30us



Tat

r = 1.05us

Time to process packets without simultaneous bridging

Time to process packets with simultaneous bridging

Time for IP framesto depart over SMDS

Fi gure 12: Perf ormance of one port of The Ba y Br i d g e f or FDDI - SMDS rout i ngwi th and wi thout s i mul taneous bri dgi ng wi th l earni ng.



Hence, Tbhdr =7: 55�s whi chcorresponds to a maxi mumthroughput of RPPS port =132; 450 packets per second per port . I f the router i s not al so worki ng as a bri dgethen the throughput i ncreases by 19. 8%to RPPSport =158; 730 packets persecond per port .

Fi gure 12 i l l ustrates the perf ormance f or FDDI to SMDS rout i ng wi th and wi th-out s i mul taneous bri dgi ng. Wi th bri dgi ng, cont i nuous back- to- back IP pack-ets contai ni ng Lrmin =143 bytes of data may be routed. Wi thout bri dgi ng,Lrmin =101.

Revision: 2.0

Ba y Br i d g e 1 9

Time (us)

1.00

2.00

4.00

5.00

6.00

7.00

8.00

9.00

0.00 20.00 40.00 60.00 80.00 100.00

0.00


FDDI Header arrival time 1.04us


3.00

Tpc

b= 0.90us


Tat

b= 0.90us


Time to process frames without learning

Time for FDDIframes to arrive

Maximum throughput per portBFPS = 555,555 frames/sec port

Fi gure 11: Perf ormance of one port of The Ba y Br i d g e f or FDDI - FDDI bri dgi ngwi th stat i c address tabl es .

Revision: 2.0

Ba y Br i d g e 1 8

Time (us)

1.00

2.00

4.00

5.00

6.00

7.00

8.00

9.00

0.00 20.00 40.00 60.00 80.00 100.00

0.00


FDDI Header arrival time 1.04us

FDDI Dataarrival time 80ns/byte3.00

Tpc

b= 0.90us

Tat

b = 2.15us



Time to processframes, with learning



Fi gure 10: Perf ormance of one port of The Ba y Br i d g e f or FDDI - FDDI bri dgi ngwi th source address l earni ng.

Revision: 2.0

Ba y Br i d g e 1 7



Address Learning 25 cycl es

CopyingFDDI frame 1 cycl e per byte

Hence, Tbhdr =3: 05�s .

Thi s corresponds to a maxi mumthroughput of BFPS port =327; 870 packetsper second per port and BFPSagg =465; 116 aggregate f rames per second. I t i si nterest i ng to compare thi s wi th the perf ormance that may be obtai ned i f stat i caddress tabl es are ass i gned by the network admi ni strator : BFPSport =555; 555packets per second per port and BFPSagg =1: 1 mi l l i on aggregate f rames persecond.

Fi gures 10 and 11 i l l ustrate the perf ormance of one port of The Ba y Br i d g e f orFDDI - FDDI bri dgi ng wi th and wi thout l earni ng respect i vel y. For a l earni ngbri dge, back- to- back f rames of l ength Lb

min =64 bytes may be f orwarded. For astat i cal l y al l ocated address tabl e, Lb

min =26. Thi s may be compared wi th themi ni muml ength TCP/IPpacket of 48 bytes [ 4] .

4.3 Routing Performance

The rout i ng perf ormance descr i bed here covers the rout i ng of IP packets thatconf ormto the proposed standards f or FDDI and SMDS [ 4, 5] . I t i s assumedthat the IP checksumi s not checked, but s i mpl y modi �ed to re ect the changei n the Time To Li ve �el d. Fragmentat i on may be requi red i n SMDS to FDDIrout i ng, but i s onl y requi red f or packets l onger than 4500 bytes . As we are onl yconsi der i ng smal l packets here, f ragmentat i on wi l l be i gnored.

4.3.1 FDDI toSMDSIProuting

The ti me f or The Ba y Br i d g e to route one IPpacket i n hardware f roman FDDInetwork to an SMDS network i s made up of the f ol l owi ng components:


BuildingLLC/SNAP&IPHeaders 65 cycl es


Revision: 2.0

Ba y Br i d g e 1 6

TAT SMDS-FDDI

TAT FDDI-SMDS

TPC

TPC FDDI-SMDS

TPC

TPC FDDI-SMDS TAT FDDI-SMDS

TAT SMDS-FDDI TPC

Processing starts on two frames at time 0

Minimum time between framearrivals over SMDS = 5.68us

Repeating cycle length 6.65us

Waiting time foraddress tables

Fi gure 8: Cal cul at i on of aggregate throughput f or FDDI - SMDS bri dgi ng i nboth di rect i ons s i mul ataneousl y. Af ter process i ng of f rames starts at t i me 0,content i on f or the address tabl es wi l l l ead to repet i t i ve cycl es of constant l ength,6: 65�s .

78 55

1 27 32 20

78 55 78 55 78 55

8 32 28 11 32 28 32 28

114

32

78 55

28 32 1 27

114 114 114 114 114

FDDI to SMDS

SMDS to FDDI Tpc Tpc Tpc Tpc Tpc Tpc TpcTat Tat Tat Tat Tat Tat

19

684 clock cycles = 34.20us

Waiting time forAddress Tables

Waiting time for next SMDS cell

Tpc Tpc Tpc Tpc TpcTat Tat Tat Tat Tat

Fi gure 9: Cal cul at i on of aggregate throughput f or FDDI - SMDSbri dgi ng i n bothdi rect i ons s i mul ataneousl y wi thout address val i dat i on by the SMDS i nterf ace.At maxi mumthroughput, repet i t i ve cycl es occur of constant l ength, 34: 2�s .

arr i ve over the SMDS i nterf ace every 2 cel l t i mes (5: 68�s ) . The process i ng f al l si nto a recurr i ng cycl e of l ength 6: 65�s i n whi ch t i me two f rames are processed.Thi s corresponds to an aggregate throughput BFPSagg =300; 751 f rames persecond.

I f addresses are not val i dated on the SMDS i nterf ace then the si tuat i on i s morecompl i cated st i l l , see Fi gure 9. Thi s t i me the recurr i ng cycl e wi l l be 34: 2�s l ongi n whi ch t i me 11 f rames are bri dged. Thi s corresponds to j ust a 7%i ncrease i naggregate throughput to BFPSagg =321; 637 f rames per second.

4.2.3 FDDI toFDDI Bridging

The ti me to bri dge one f rame i s made up of the f ol l owi ng components:

Revision: 2.0

Ba y Br i d g e 1 5

Tpc

b= 1.40us

Time (us)

10.00

15.00

20.00

25.00

0.00 50.00 100.00 150.00 200.00 250.00 300.00

0.00


FDDI Datadeparture time 80ns/byte

Time to processframes, with address validation

Time for encapsulated FDDIframes to arrive over SMDS

Minimum length back-to-back encapsulated FDDI frame = 23 bytes


Tat

b = 3.70us

Tatb = 1.60us


5.00

Time to process frames, withoutaddress validation

Fi gure 7: Perf ormance of one port of The Ba y Br i d g e f or SMDS-FDDI bri dgi ngwi th and wi thout SMDS source and FDDI dest i nat i on address val i dat i on.

Fi gures 7 i l l ustrates the perf ormance of one port of The Ba y Br i d g e f or SMDS toFDDI bri dgi ng respect i vel y wi th and wi thout SMDS source address val i dat i onand FDDI dest i nat i on address val i dat i on. The per- f rame overhead t i me, Tb

hdr

i s broken down i nto Tbpc and T bat . Wi thout address checki ng, Lbmin =0 bytes.

4.2.2 AggregateFDDI-SMDSBridging

The aggregate throughput of The Ba y Br i d g e f or FDDI - SMDS bri dgi ng i s notas strai ghtf orward as f or FDDI - FDDI bri dgi ng because of the asymetr i c useof the address tabl es and the constrai nt that encapsul ated f rames can not ar-r i ve wi th a separat i on of l ess than 2 cel l t i mes over the SMDS i nterf ace. Theaggregate throughput cal cul at i on i s i l l ustrated i n Fi gure 8. Assume that back-to- back mi ni muml ength f rames arr i ve over the FDDI i nter f ace and that f rames

Revision: 2.0

Ba y Br i d g e 1 4

Tpc

b= 1.65us

Time (us)

5.00

10.00

15.00

20.00

25.00

0.00 50.00 100.00 150.00 200.00 250.00 300.00

0.00



Time to processframes, with learning




Tat

b = 2.75us

Tencb = 2.25us


Fi gure 6: Perf ormance of one port of The Ba y Br i d g e f or FDDI - SMDS bri dgi ngwi th source address l earni ng.

Revision: 2.0

Ba y Br i d g e 1 3

BuildingSMDSHeader 45 cycl es


where one cycl e i s 50ns. Hence, Tbhdr =6: 65�s . The per- f rame process i ng t i mei s domi nated by the t i me to bui l d an SMDS header (36 bytes pl us 8 bytes ofLLC/SNAP header) . The protocol converter must al so cal cul ate the BAsi ze

( l ength) �el d that appears i n the SMDS header and the paddi ng bytes . As weshal l see, the address l ookup takes l onger than f or FDDI - FDDI bri dgi ng becausea 64- bi t SMDSaddress must be retr i eved f romthe address tabl es . The per- f rameprocess i ng t i me corresponds to a maxi mumthroughput of , BFPSport =150; 375f rames per second per port . Wi th stat i c address tabl es al l ocated by the networkadmi ni strator the throughput i ncreases by 23%to BFPSport =185; 185 f ramesper second per port . However , we shal l not consi der the opt i on of stat i c addresstabl es f or FDDI - SMDS as thi s woul d potent i al l y l ead to redundant f rames bei ngpassed over and bi l l ed by the SMDS servi ce.

Fi gures 6 i l l ustrates the perf ormance of one port of The Ba y Br i d g e f or FDDI -SMDS bri dgi ng wi th l earni ng. The per- f rame overhead t i me, Tbhdr i s brokendown i nto T b

pc , Tbat , and T

benc . We see f romthe graph that f or a l earni ng bri dge,

back- to- back f rames of l ength, Lbmin =187 bytes may be f orwarded.

We now consi der the perf ormance of The Ba y Br i d g e bri dgi ng f romSMDS toFDDI :


ValidateSMDSSourceAddress 24 cycl es

ValidateFDDI DestinationAddress 18 cycl es

SMDS/FDDIAddress Learning 32 cycl es

DiscardSMDSHeader 4 cycl es


where one cycl e i s 50ns. Hence, Tbhdr =5: 10�s . Thi s corresponds to a maxi mumthroughput of BFPSport = 196; 078 f rames per second per port . We coul dconsi der i ncreasi ng the perf ormance to BFPSport =256; 410 by not val i dat i ngthe SMDS source address and f urther to BFPSport =333; 333 by assumi ng thatal l arr i vi ng encapsul ated FDDI f rames are dest i ned f or thi s r i ng. However , ascan be seen f romFi gure 7, these measures are not needed unl ess the averagei ncomi ng encapsul ated FDDI f rame contai ns l ess than Lbmin =23 bytes of data.

Revision: 2.0

Ba y Br i d g e 1 2

Time (us)

5.00

10.00

15.00

20.00

25.00

30.00

0.00 100.00 200.00 300.00 400.00

0.00




Time for encapsulated FDDI frame in SMDS to depart

Time of 2 SMDS cells to carry 1 FDDI frame (5.68us),Maximum throughput176,056 frames/sec

Departure rate firstexceeds arrival ratefor FDDI frames with 236bytes of data.

Fi gure 5: Overhead of br i dgi ng one FDDI f rame over SMDS requi res at l easttwo cel l s because of the l arge overhead of the SMDS f rame header and theLLC/SNAP�el ds.

Revision: 2.0

Ba y Br i d g e 1 1

For bri dgi ng, we wi l l al so deduce the mi ni mumsi ze f rame that may be bri dgedback-to-back cont i nuousl y wi thout �l l i ng the systembu�ers . Thi s wi l l be de-noted Lbmin . Si mi l ar l y f or rout i ng we wi l l de�ne Lr

min f or IPpackets4.

Note that f or rout i ng we wi l l not take i nto account packets of unknown dest i na-t i on that must be sent to the host . The perf ormance of thi s path i s not knownat thi s t i me.

4.2 Bridging Performance

We wi l l consi der the perf ormance of The Ba y Br i d g e operat i ng as a MAC- l ayerbr i dge i n two con�gurat i ons: �rst as an FDDI - SMDS bri dge, then as an FDDI -FDDI bri dge.

4.2.1 FDDI-SMDSBridging

The bri dgi ng perf ormance of The Ba y Br i d g e operat i ng i n thi s con�gurat i on wi l lbe di �erent i n each di rect i on. We shal l �rst consi der the perf ormance f romFDDI to SMDS, but �rst i t i s i nterest i ng to compare the maxi mumrate off rame arr i val s f romFDDI and departures over SMDS operat i ng at 155Mbps.Assumi ng mi ni muml ength FDDI f rames of 20 bytes , the maxi mumarri val ratei s 625, 000 f rames per second. An SMDS f rame (L3 PDU) contai ni ng an en-capsul ated, mi ni muml ength FDDI f rame i s at l east 65 bytes l ong (excl udi ngopt i onal CRC f or SMDS and any paddi ng bytes) . Thi s requi res two 44- bytecel l s correspondi ng to a maxi mumencapsul ated f rame rate over SMDS of j ust177, 305 f rames per second. Fi gure 5 shows howthi s overhead becomes l ess s i g-ni �cant f or l onger FDDI f rames. But i t i s not unt i l the FDDI f rames reaches236 bytes that the departure rate matches the arr i val rate. Furthermore, i t i snot unt i l the arr i vi ng FDDI f rames are l onger than 450 bytes that the departure

rate wi l l al ways exceed the arr i val rate.

The t i me f or The Ba y Br i d g e to bri dge one FDDI f rame to SMDS, encapsul at i ngthe f rame i nto an SMDS L3 PDUi s made up of the f ol l owi ng components:



Address Learning 25 cycl es

4Clearly, if theaveragepacket lengthis larger thanL min, the�nitebu�er spacemaystill

over ow. But thiswill dependonthe incomingtra�cpatterns andis not consideredhere.

Revision: 2.0

Ba y Br i d g e 1 0

3.4 Host and SBus DMA Card

The Host i s a Sun SPARCStat i on and acts pr i mari l y as a moni tor andmanager ;i t i s not i nvol ved i n bri dgi ng data packets between the two networks.

4 SystemPerf ormance

4.1 Performance Characteri zati on

I n order to understand the perf ormance of a bri dge or router , the per- packetprocess i ng may be broken down i nto i ts const i tuent components: header pro-cess i ng and data copyi ng. For bri dgi ng, header process i ng i ncl udes maki ng adest i nat i on port deci s i on and may i ncl ude encapsul at i on. Data copyi ng consi stsof copyi ng the MAC- l ayer f rame. For rout i ng, header process i ng i ncl udes thenext- hop rout i ng deci s i on, changi ng header parameters and may i ncl ude f rag-mentat i on control and the recal cul at i on of checksums. Data copyi ng consi stsof copyi ng the network- l ayer packet . I n most systems, the data copyi ng rate i sf aster than the data rate of the network ports and so does not provi de a bott l e-neck. The bott l eneck i s al most i nvar i abl y the header processi ng t i me. Thi s i sthe case f or The Ba y Br i d g e . The data copyi ng i s al ways 1 byte per 50ns cycl e,whereas the header process i ng depends on the compl exi ty of the protocol .

To anal yze the perf ormance of The Ba y Br i d g e we break down the per- f rameor per- packet process i ng t i me i nto the header process i ng t i me, Thdr (Tbhdr f orbr i dgi ng and Trhdr f or rout i ng) and the data copyi ng t i me. We wi l l f urther di vi deThdr i nto the deci s i on t i me by each protocol converter operat i ng i n paral l el ,Tpc the addresstabl e l ookup ti me of the shared address tabl es , Tat and whererel evant , the encapsul at i on t i me Tenc .

Fromthe header process i ng t i me we wi l l i nf er the maxi mumthroughput. Forbri dgi ng, the maximumnumber of bri dged f rames per second per port i s denotedBFPS port and f or rout i ng the maximumnumber of routed packet s per second

per port i s denoted RPPSport . These are gi ven by,

BFPS port =1

T bhdr

RPPS port =1

T rhdr

Aggregate throughput of both ports operat i ng si mul taneousl y wi l l be denotedBFPS agg andRPPS agg respect i vel y. The cal cul at i on of BFPSagg andRPPS agg

depends on the part i cul ar con�gurat i on and i s descr i bed l ater .

Revision: 2.0

Ba y Br i d g e 9

messages, the source address of the remote FDDI stat i on i s stored i n the AddressTabl e, al ong wi th the associ ated remote bri dge address (E164) (case 2 above) .

2) HardwareRoutingAssistance.

Hardware rout i ng ass i stance i s provi ded to the host by the Protocol Converter .The Address Tabl es are used to hol d a cache of Network Layer Addresses (weshal l assume here that the network l ayer i s IP) . These are added as stat i c entr i esby the host . When a f rame arr i ves the Protocol Converter consul ts the AddressTabl es to see i f the IP address i s known. I f i t i s , the Protocol Converter makesany necessary changes to the IP header , i . e. , decrements the Time To Li ve

�el d and updates the Checksum, and bui l ds the newMACf rame requi red bythe dest i nat i on port . Fragmentat i on may al so be perf ormed by the ProtocolConverter . I f the Network Address i s not known the f rame i s sent to the host .The host consul ts i ts address tabl es and network to physi cal address resol ut i oncache and determi nes the dest i nat i on address f or the f rame. Af ter f orwardi ngthe f rame, the host updates the Address Tabl es so that i n f uture the ProtocolConverter wi l l route the f rame i n hardware. Note that the Protocol Converterdoes not conf ormto the regul ar model i n whi ch the rout i ng deci s i on i s madei n two stages: �rst the IP address of the next- hop i s determi ned and then theIP address i s bound to a physi cal address . Hi gher perf ormance i s achi eved bycarryi ng out both stages at once, but requi res the host to update the addresstabl es accordi ngl y. Al so note that header predi ct i on i s not perf ormed. Headerpredi ct i on wi th a cache of one header coul d be readi l y perf ormed by the ProtocolConverter but has not been i nvest i gated.

3.2 SMDS Interface

The SMDS Interf ace to The Ba y Br i d g e i s descr i bed i n detai l i n [ 12] and i s notdi scussed here.

3.3 FDDI Board

The FDDI board i s a standard desi gn and i s not descr i bed i n detai l here. Weuse the AMDFDDI Supernet chi pset to control access to the FDDI ri ng and a64Kword packet bu�er between the FDDI MACand the Bri dge/Router Board.

Revision: 2.0

Ba y Br i d g e 8

consul ts the Address Tabl es . The FDDI Dest i nat i on Address (DA) i s used asan i ndex i nto the Address Tabl es . I f a match occurs , the Copy Bi t s are readf romthe tabl e to deci de where to send the f rame. The copy bi ts may i ndi catethat :

1. The f rame i s to be copi ed to the host .

2. The encapsul ated f rame i s to be copi ed to the SMDS i nterf ace. The SMDSmessage header i s bui l t by the Protocol Converter and sent to the Other

Port Channel . The SMDS dest i nat i on address i s read f romthe Associ atedData Tabl e i n the Address Tabl es . The FDDI f rame i s copi ed to the OtherPort Channel f ol l owed by the SMDS message trai l er .

3. The f rame i s to be copi ed to both ports . The SMDSmessage header i s sentto the Other Port Channel , the FDDI f rame i s copi ed to both channel sand the SMDS message trai l er i s sent to the Other Port Channel .

4. The f rame i s not to be copi ed to ei ther port . Thi s i s because the f ramei s dest i ned f or another stat i on on the same FDDI ri ng and theref ore i t i snot f orwarded.

I f a match does not occur i n the Address Tabl es , then the dest i nat i on i s un-known. Amul t i cast SMDS f rame i s bui l t and the encapsul ated f rame i s sent toevery bri dge i n the Bri dge Group.

SMDS messages arr i ve across Port Band are recei ved by Protocol Converter B(PCB). Fi rst of al l PCBmay perf ormopti onal address val i dat i on of the SMDSsource address and the FDDI dest i nat i on address . The SMDS address i s ver i �edi n the address tabl es to be part of the bri dge group. Thi s i s an opt i onal secur i tymeasure to check that the f rame was recei ved f roma l egal source. The FDDIdest i nat i on address i s checked i n the address tabl es to check whether i t shoul d bedel i vered to the l ocal FDDI ri ng. I f the copy bi ts i ndi cate that the f rame shoul dbe copi ed onl y to the SMDS port , then we may deduce that the encapsul atedFDDI f rame was del i vered i n error and i s dropped. Fol l owi ng the val i dat i on,the FDDI f rame i s removed f romthe SMDS f rame. The (FDDI source address ,SMDS source address) pai r are l oaded i nto and l earnt by the address tabl es .The f rame i s then f orwarded to the FDDI ri ng.

Learni ng:The Protocol Converter updates the Address Tabl es to l earn the addressesof stat i ons on the l ocal and remote networks. PCA l earns the source address(IEEE48- bi t f ormat) of al l pass i ng FDDI f rames andupdates the Address Tabl esi ndi cat i ng that f rames dest i ned to thi s address shoul d not be copi ed f romtheFDDI ri ng (case 4 above) . When PCBdecapsul ates FDDI f rames f romSMDS

Revision: 2.0

Ba y Br i d g e 7

ALUHeader FIFO

Output FIFOs

LoggingOther Port Host

8

32

Input Port

MicroProgrammed Controller

External Inputs

Flags

Timestamp

Access to Address Tables

Fi gure 4: Bl ock di agramof Protocol Converter : a programmabl e devi ce f orconvert i ng between network protocol s .

Revision: 2.0

Ba y Br i d g e 6

3.1.2 Protocol Converter

Thi s i s a custombui l t , mi crocoded uni t , opt i mi zed f or f ast convers i on betweennetwork protocol s . Abl ock di agrami s shown i n Fi gure 4.

For a si mpl e, exi bl e and f ast desi gn, a hori zontal mi cro- i nstruct i on i s used. Asa resul t , a wi de range of mi cro- i nstruct i ons are avai l abl e to the programmer f orperf ormance opt i mi zat i on. The mi crocode i s devel oped usi ng a user- de�nabl ei nstruct i on set and a customassembl er . The assembl edmi crocode i s downl oadedto each Protocol Converter duri ng i ni t i al i zat i on.

Duri ng the process i ng of a f rame, the converter searches f or patterns i n protocolheaders (e. g. MACheaders , LLC, SNAP, IP) usi ng the ALU and stores thef rame header i n the Header FIFO. The Protocol Converter arbi trates f or andconsul ts the Address Tabl es to make f orwardi ng and �l ter i ng deci s i ons. Whena deci s i on has been made, the output f rame i s bui l t and f orwarded to one ormore output channel s . Frames dest i ned f or the other network i nter f ace aref orwarded to the Other Port channel , f rames dest i ned f or the host are f orwardedto the Host channel . Loggi ng f rames may al so be sent to the l ocal host to l ogperf ormance stat i st i cs or to provi de cal l - bi l l i ng i nf ormati on. Cal l l oggi ng i suser de�ned as part of the downl oaded programto the Protocol Converter .For exampl e, a l oggi ng f rame coul d be sent to the host each t i me a f rame i sf orwarded to f aci l i tate bi l l i ng. The l oggi ng f rame coul d contai n a t i mestamp(one cl ock cycl e resol ut i on) , the source address , dest i nat i on address and f ramel ength. For perf ormance moni tor i ng, anALUregi ster coul d be used to count thetotal number of f rames f orwarded. Every t i me the regi ster over ows, a l oggi ngf rame coul d be sent to the host contai ni ng an i dent i �er and a t i mestamp.

We nowdescr i be howthe Protocol Converter i s used f or (1) MACLevel Bri dgi ngand (2) Hardware Routi ng Assi stance:

1)MACLevel Bridging: Forwarding, FilteringandLearning

Forwardi ng and Fi l ter i ng:Ref err i ng to Fi gure 2, assume that Port A i s connected to an FDDI networki nter f ace and that Port Bi s connected to an SMDS i nterf ace. Al l FDDI f ramesf romthe r i ng are passed to the Bri dge/Router Board across Port A, del i mi tedby a Tag bi t . Protocol Converter A(PCA) i s l ocated at the i nput to Port A.When a f rame arr i ves , PCAreads the header one byte at a t i me, checki ng eachheader �el d as i t proceeds. The �rst byte of an FDDI f rame wi l l contai n theFrame Control (FC) �el d i ndi cat i ng whether the f rame i s f or LLC or SMT,contai ns 16 or 48- bi t addresses , etc. I f i t i s an SMTf rame, then i t i s sent to thehost vi a the Host channel .

I f the f rame i s not an SMT f rame, the Protocol Converter arbi trates f or and

Revision: 2.0

Ba y Br i d g e 5

Entry TypeStatic/

Dynamic

Host Copy

Position

Copy

Rules

Timeout

Bit48-bit 802 MAC Address

CAM

8 bits 4 bits 1 bit 1 bit 1 bit 1 bit 48 bits

64 bits

RAM

64-bit E164 Address

If the entry is for bridging to SMDS

64 bits

Unused

Fi gure 3: Format of Address Tabl es entr i es .

3. 1 Bri dge/Router Board

The Bri dge/Router Board i s responsi bl e f or maki ng per- f rame deci s i ons. Forbri dgi ng, thi s i ncl udes f orwardi ng and �l ter i ng of f rames. For rout i ng, thi si ncl udes the cal cul at i on of header checksums, decrementi ng the Time To Li ve

�el d, and next- hop determi nat i on. Thi s i s carr i ed out by a pai r of ProtocolConverters and the Address Tabl es .

3.1.1 Address Tables

The address tabl e provi des storage f or 4096 addresses (expandabl e wi th a daugh-terboard) . Each entry consi sts of 64 bi ts of associ at i ve memory (CAM) and 64bi ts of non- associ at i ve memory (RAM). The f ormat of the entr i es i s determi nedby the Protocol Converter mi crocode, i . e. , the hardware does not restr i ct thef ormat. As an exampl e, the f ormat used f or br i dgi ng between FDDI and SMDSi s shown i n Fi gure 3. The unrestr i cted f ormat enabl es physi cal and networkaddresses to co- exi st i n the address tabl es . The address type i s i ndi cated i neach tabl e entry.

The Address Tabl es may be accessed by ei ther Protocol Converter or the at-tached workstat i on. Access i s arbi trated on a round- robi n basi s . The RAMi saccessed by �rst obtai ni ng a match i n the CAM, and then l oadi ng the i ndex ofthe matchi ng CAMentry i nto a memory address regi ster .

Revision: 2.0

Ba y Br i d g e 4

BridgeProtocol

NetworkMgmt

BridgeMgmt SUN

SPARCStation

HostInterface

Packet Buffer

FDDI MAC

FDDI PHY

DQDBMAC A

DQDBMAC B

PLCP SONET FramerPHY & Clock Recovery

SBus

Bridge/Router Board

FDDI Interface SMDS STS3 Interface

ProtocolConverter

PCA

Segmentation Reassembly SARBoard

SMDSLayer 2 Board

FDDIBoard

ProtocolConverter

PCB

AddressTablesPort A Port B

MUX

MUX

SBus DMA Board

Fi gur e 2 : Sys t e mAr c hi t e c t ur e s howi ng ma i n f unc t i o na l bl o c ks . The �ve s hade dboxe s i ndi c a t e e a c h c i r c ui t bo a r d.

Re v i s i o n : 2 . 0

Ba y Br i d g e 3

LOCALBRIDGE

FDDISTATION

REMOTE BRIDGE

BayBridgeBayBridge

SMDS

BayBridgeBayBridge

FDDIRING

ETHERNET

Fi gur e 1 : A t ypi c a l t o po l o g y i nt e r c onne c t i ng FDDI r i ng s . Ea c h FDDI r i ng mayc ont a i n l o c a l br i dg e s c onf o r mi ng t o t he I EEE 802 . 1D St anda r d.

a nd e nabl e s a ne t wo r k manag e r t o s e t l o c a l a nd r e mo t e addr e s s e s a s we l l a smoni t o r ne t wo r k pe r f o r manc e pa r ame t e r s . Fo r r o ut i ng , t he ho s t i s a l s o r e s pon-s i bl e f o r r e c e i v i ng pa c ke t s o f unknown de s t i na t i o n and upda t i ng t he addr e s st a bl e s ( s e e Se c t i o n 3 . 1 . 2 ) a nd r unni ng t he us ua l I nt e r i o r a nd Ext e r i o r Ga t e wayPr o t o c o l s [ 6 , 8 , 7 , 1 3 ] . Fo r br i dg i ng , t he wo r ks t a t i o n r uns t he Spanni ng Tr e eBr i dg e Topo l og y a l g o r i t hm[ 9 , 1 0 ] .

3 Ar c hi t e c t u r e

Fi gur e 2 i s a bl o c k di a g r am o f Th e Ba y Br i d g e a r c hi t e c t ur e [ 1 1 ] . The s ys t e mc ons i s t s o f f o ur ma i n bl o c ks : t he Br i dg e /Rout e r Boa r d, t he SMDS I nt e r f a c e ,t he FDDI I nt e r f a c e and t he Ho s t I nt e r f a c e .

The i nt e r f a c e s be t we e n bl o c ks ( Po r t A, Po r t B and t he Ho s t Po r t ) a r e i de nt i c a lbut separate bus s e s . Thi s e l i mi na t e s t he bo t t l e ne c k o f a s i ng l e s ha r e d s ys t e mbus . Ea c h i nt e r f a c e c ons i s t s o f t wo uni di r e c t i o na l da t a bus s e s a nd a c ont r o l busf o r r e a di ng and wr i t i ng c on�gur a t i o n r e g i s t e r s . Ea c h da t a bus i s 3 2 - bi t s wi dewi t h a \Tag - bi t " t o de l i mi t pr o t o c o l da t a uni t s , a wr i t e c ont r o l l i ne t o i ndi c a tt ha t t he da t a i s va l i d and a f ul l - a g f o r ow c ont r o l . Thi s c ommon i nt e r f a c ea l l ows t he s ys t e m t o be c on�gur e d a s an FDDI - SMDS, FDDI - FDDI o r SMDS-SMDS br i dg e / r out e r . Al t e r na t i ve l y, t he FDDI Boa r d o r SAR Boa r d may bec onne c t e d di r e c t l y t o t he SBus DMA c a r d, o r may be us e d t o t e s t e a c h bo a r dus i ng one o r mo r e o f t he SBus DMA c a r ds .

Re v i s i o n : 2 . 0

Ba y Br i d g e 2

2 S y s t e m Ove r v i e w

2. 1 Object i ves

Apl a t f o r m, known a s Th e Ba y Br i d g e1, ha s be e n bui l t t o i nve s t i g a t e hi g h pe r f o r -manc e br i dg i ng and r out i ng i n ha r dwa r e , ba s e d on a pr o g r ammabl e br i dg e / r out e rbo a r d c onne c t e d t o a ho s t wo r ks t a t i o n. As e xampl e s o f t wo hi g h s pe e d ne t wo r ks ,FDDI and SMDS we r e c ho s e n. Howe ve r , t he a r c hi t e c t ur e i s no t l i mi t e d t o t he s ene t wo r k pr o t o c o l s .

The �r s t i mpl e me nt a t i o n wa s de s i g ne d wi t h t he f o l l owi ng ob j e c t i ve s :

� Hi gh Thr oughput and l ow pe r - f r ame2 pr o c e s s i ng de l a y.

� SMDS i nt e r f a c e a t SONET STS- 3 c 1 5 5Mbps and DS3 45Mbps us i ng c us -t ombui l t DQDB MAC c hi p.

� Expandabl e Addr e s s Tabl e s .

� Con�gur abl e a s FDDI - SMDS o r FDDI - FDDI , br i dg e o r r o ut e r .

� I nve s t i g a t e Pr o g r ammabl e Pr o t o c o l Conve r s i o n.

2. 2 Funct i onal Overvi ew

Fo r br i dg i ng , t he s ys t e m c ompl i e s wi t h t he pr opo s e d I EEE 802 . 1 g Re mo t eBr i dg e Dr a f t St anda r d and t he pr opo s a l s o f t he I EEE 802 . 6 Mul t i po r t Br i dg eCommi t t e e [ 3 , 9 ] . Ha r dwa r e r o ut i ng a s s i s t i s a c hi e ve d by t he Pr o t o c o l Con-ve r t e r . Thi s i s de s c r i be d i n Se c t i o n 3 . 1 . 2 . Whe n r out i ng , t he s ys t e m c ompl i e swi t h t he r e c omme nda t i o ns f o r t he t r a ns mi s s i o n o f I P pa c ke t s o ve r FDDI andSMDS [ 4 , 5 ] .

A t ypi c a l a ppl i c a t i o n and t opo l o g y i s s hown i n Fi g ur e 1 . FDDI f r ame s a r e e n-c aps ul a t e d i nt o a s i ng l e SMDS me s s a g e and t r ans mi t t e d a c r o s s t he Subs c r i be rNe t wo r k I nt e r f a c e3 t o t he Me t r opo l i t a n Swi t c hi ng Sys t e m ( MSS) . The SMDSme s s a g e i s t he n de l i ve r e d t o one o r mo r e r e mo t e Ba y Br i d g e s. A ho s t i nt e r f a c epr o v i de s an FDDI and SMDS i nt e r f a c e t o a l o c a l wo r ks t a t i o n. The l o c a l ho s tr uns t he Ne t wo r k Manag e me nt a g e nt , t he FDDI St a t i o n Manag e me nt Pr o c e s s

1Th e p r o je c t i n i t i a l l y f o c u s s e d o n h i g h s p e e d b r i d g i n g , b u t l a t e r e n h a n c e d t h e d e s

i n c l u d e h a r dwa r e r o u t i n g . He n c e t h e n a me \Th e Ba y Br i d g e "2Th r o u g h o u t t h i s p a p e r we wi l l u s e t h e wo r d \ f r a me " t o d e s c r i b e a MAC La y e r p r o t o c o

d a t a u n i t a n d t h e t e r m \ p a c k e t " t o r e f e r t o a Ne t wo r k La y e r p r o t o c o l d a t a u n i t .3Th e Su b s c r i b e r Ne t wo r k In t e r f a c e i s t h e DQDB p r o t o c o l o f I EEE 80 2 . 6

Re v i s i o n : 2 . 0

Ba y Br i d g e 1

1 In t r o d u c t i o n

As t he numbe r o f hi g h s pe e d LANs i nc r e a s e , s o do e s t he ne e d t o c onne c t t he s ene t wo r ks wi t hi n a me t r opo l i t a n o r wi de a r e a , t hus e xpandi ng t he bounda r y o fLANs be yond a bui l di ng o r c ampus . To ma i nt a i n t he qua l i t y o f s e r v i c e o f -f e r e d by t he LANs , a hi g h pe r f o r manc e Me t r opo l i t a n Ar e a Ne t wo r k ( MAN) i sr e qui r e d. The MAN us e d t o c onne c t t he hi g h s pe e d LANs mus t a i m t o maxi-

mize the throughput and minimize the del ay per packet. SwitchedMul ti-megabit

Data Service (SMDS) [ 1 ] , pr o po s e d by Bel l Communications Research, Inc.

(Bel l core) and o�e r e d by Regional Bel l Operating Companies, e nabl e s LANst o be i nt e r c onne c t e d be yond t he c us t ome r pr e mi s e s , a c r o s s a me t r opo l i t a n o rwi de a r e a . SMDS o�e r s a hi g h t hr oughput c onne c t i o nl e s s da t a g r ams e r v i c e a tDS1 ( 1 . 5Mbps ) , DS3 ( 4 5Mbps ) , a nd STS- 3 c ( 1 5 5Mbps ) . LANs may be i nt e r -c o nne c t e d ove r SMDS wi t h a MAC l aye r br i dg e o r ne t wo r k l a ye r r o ut e r ( o r\ g a t e way") . Br i dg i ng i s s ui t a bl e f o r a s ma l l numbe r o f s i t e s wi t hi n an o r g a -ni z a t i o n. Rout i ng i s mo r e s ui t a bl e f o r l a r g e r ne t wo r ks and be t we e n di �e r e nto r g ani z a t i o ns .

Fo r e �e c t i ve br i dg i ng and r out i ng be t we e n a hi g h s pe e d LAN s uc h a s FDDI anda hi g h s pe e d MANs uc h a s SMDS i t i s i mpo r t a nt t ha t t he br i dg e / r out e r o pe r a t e sa t hi g h t hr oughput and l owde l a y. Al t hough a hi g h pe r f o r manc e r out e r be t we e nFDDI and ATMha s be e n de s c r i be d e l s e whe r e [ 2 ] , t he de s i g n and pe r f o r manc e o fa hi g h s pe e d br i dg e o r r o ut e r be t we e n FDDI and SMDS ha s no t be e n r e po r t e d.

Th e Ba y Br i d g e wa s bui l t t o i nve s t i g a t e hi g h pe r f o r manc e br i dg i ng and r out i ngbe t we e n FDDI and SMDS. The STS- 3 c r a t e f o r SMDS wa s c ho s e n be c aus e i t i sa ne a r ma t c h t o t he FDDI r a t e and e nabl e s hi g h s pe e d br i dg i ng and r out i ng t obe i nve s t i g a t e d.

I n t he r e ma i nde r o f t hi s pape r , we s ha l l de s c r i be t he a r c hi t e c t ur e ope r a t i o n andpe r f o r manc e o f Th e Ba y Br i d g e . I n Se c t i o n 2 we s ha l l c o ns i de r t he ob j e c t i ve s o ft he wo r k and an ove r v i e w o f t he f unc t i o na l o pe r a t i o n o f Th e Ba y Br i d g e . Wet he n de s c r i be t he a r c hi t e c t ur e o f t he s ys t e m i n Se c t i o n 3 wi t h e mpha s i s o n t heProgrammabl e Protocol Converter. I n Se c t i o n 4 we c ons i de r t he t hr oughputpe r f o r manc e and pe r - pa c ke t pr o c e s s i ng t i me o f Th e Ba y Br i d g e ope r a t i ng a s anFDDI - SMDS br i dg e / r out e r a nd a s an FDDI - FDDI br i dg e / r out e r .

Re v i s i o n : 2 . 0

Architecture and Performance of

The BayBri dge: AHi gh Speed

Bri dge/Router Between FDDI and SMDS

Nick McKeown Ri chard Edell My T Le

Abstract

The BayBridge is a highperformance bridge/router designedfor high

throughput bridgingandroutinginhardwarebetweentwonetwork ports.

The �rst prototype may operate as an encapsulating two-port remote

bridge betweenFDDI andSMDS: FDDI rings are interconnectedviathe

publicSMDSnetworkoperatingat theSONETSTS-3corDS3rate. High

throughput is achieved by a specialized processor: The Protocol Con-

vert er , aprogrammable device for translatingbetweennetworkprotocols

andmakingforwarding/routingdecisions.

In this paper, we �rst present an overviewof the systemfollowedby a

descriptionof thearchitecturewithspecial emphasis ontheProt ocol Con-

vert er . Finallythe performance of The Ba y Br i d g e is describedindetail,

�rst as abridge andthenas arouter operatingbetweenFDDI andSMDS

or betweenFDDI andFDDI. With interfaces to FDDI andSMDS, The

Ba y Br i d g e has amaximumbridging throughput of over 300,000 frames

per second and a maximumcombined bridging/routing throughput of

over250,000packetsper second. Methods arediscussedfor increasingthe

throughput inparticular applications.

TheBayBr i dge

Pr oje ct Re po r t : 13 Re vi si o n: 2.0

De p a r t me n t o f Ele c t r i c a l En g i n e e r i n g

a nd Comput e r Sc i e n c e s

Un i v e r s i t y o f Ca l i f o r n i a a t Be r ke l e y

Documents

Ba y Bridge 29 - Stanford Universitytiny-tera.stanford.edu/~nickm/papers/BayBridge/performan...Ba y Br i d g e 27 m or e m ar k ed i n t h ecaseof F D ItoF Ib ri d gi n gi n w h ichan