1 / 20

Routing and Rbridges

Explore Rbridges, a concept by Donald Eastlake & Radia Perlman to enhance routing efficiency by replacing traditional bridges in wireless mesh networks. Learn about spanning tree algorithm issues, bridge meltdowns, and the benefits of Rbridges for fast forwarding with optimal paths and plug-and-play functionality. Discover how Rbridges optimize packet forwarding at layer 2, ensuring fast convergence and minimal loop occurrences. Dive into endnode learning and packet forwarding strategies in Rbridge networks. Explore how Rbridges offer a seamless transition from traditional bridges to modern routing solutions, providing optimal paths and scalability for evolving network requirements.

geddie
Download Presentation

Routing and Rbridges

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Routing and Rbridges Donald E. Eastlake 3rdDonald.Eastlake@motorola.com+1-508-786-7554 Radia Perlmanradia.perlman@sun.com Donald Eastlake 3rd, Motorola

  2. Routing and Rbridges • Radia Perlman, inventor of the spanning tree algorithm and many original mechanisms in routing, has recently devised the Rbridges concept as a replacement for bridging. I believe it would be applicable to wireless mesh networks. • Radia was unable to make it to this IEEE 802.11 meeting but has agreed that I could present her ideas and use some of her slides. • Donald Eastlake 3rd Donald Eastlake 3rd, Motorola

  3. Problems with Bridges • Routes are not optimal (spanning tree) • Spanning Tree Algorithm cuts off redundant paths • If A and B are on opposite side of path, they have to take long detour path • Temporary loops really dangerous • no hop count in header • proliferation of copies during loops • So, should be conservative in transition Donald Eastlake 3rd, Motorola

  4. Path from a to c a 2,1,6 2,3,3 11 6 c 7 2,3,3 2,2,7 2,0,2 9 3 2 5 2,2,4 10 2,0,2 4 14 2,2,4 2,1,5 2,1,14 Donald Eastlake 3rd, Motorola

  5. Why loops are a disaster • No hop count • Exponential proliferation B2 B1 B3 Donald Eastlake 3rd, Motorola

  6. Why bridges are slow to start forwarding • Temporary loops can cause meltdown • Can’t (except in certain special cases, like a port to an endnode) know if turning on a link might cause temporary loop • Simple solution: wait before turning on link, so other bridges can turn off links first • People want instant failover (but they don’t want meltdowns) Donald Eastlake 3rd, Motorola

  7. Bridge meltdowns • They do occur (a Boston hospital) • Lack of receipt of spanning tree msgs tells bridge to turn on link • So if too much traffic causes spanning tree messages to get lost… • loops • exponential proliferation of looping packets Donald Eastlake 3rd, Motorola

  8. Why are there still bridges? • Why not just use routers? • Bridges plug-and-play • Endnode addresses can be per-campus • IP routes to links, not endnodes • So IP addresses are per-link • Need to configure routers • Need to change endnode address if change links Donald Eastlake 3rd, Motorola

  9. Rbridges • Compatible with today’s bridges and routers • Like routers, terminate bridged LAN • Like bridges, glue LANs together to create one IP subnet (or for other protocols, a broadcast domain) • Like routers, optimal paths, fast convergence, no meltdowns • Like bridges, plug-and-play Donald Eastlake 3rd, Motorola

  10. Rbridging layer 2 • Link state protocol among Rbridges (so know how to route to other Rbridges) • Like bridges, learn location of endnodes from receiving data traffic • But since traffic on optimal paths, need to distinguish originating traffic from transit • So encapsulate packet to destination Rbridge Donald Eastlake 3rd, Motorola

  11. Rbridging R7 c R4 R1 R5 R3 R6 a R2 Donald Eastlake 3rd, Motorola

  12. Encapsulation Header S=Xmitting Rbridge D=Rcving Rbridge pt=“transit” hop count original pkt (including L2 hdr) • Outer L2 hdr must not confuse bridges • So it’s just like it would be if the Rbridges were routers • Need special layer 2 destination address • for unknown or multicast layer 2 destinations • can be L2 multicast, or any L2 address provided it never gets used as a source address Donald Eastlake 3rd, Motorola

  13. Rbridges and Bridges R4 R2 R7 Seems like: R2 Actually can be: bridged LAN R4 R7 Donald Eastlake 3rd, Motorola

  14. Endnode Learning • On shared link, only one bridge (DR) can learn and decapsulate onto link • otherwise, a “naked” packet will look like the source is on that link • have election to choose which Rbridge • When DR sees naked packet from S, announces S in its link state information to other Rbridges Donald Eastlake 3rd, Motorola

  15. Packet Forwarding • If D known: encapsulate and forward towards D • Else, send to “destination=flood”, meaning send on spanning tree • tree calculated from Link State info, not separate protocol • each DR decapsulates Donald Eastlake 3rd, Motorola

  16. Rbridging IP • Rbridging at layer 2 will do it • Optimization: locally answer ARPs • learn (layer 3, layer 2) • pass that in link state info • Another optimization for IP: shorter end node cache timer (since can ping) Donald Eastlake 3rd, Motorola

  17. Alternative for IP • Some router hardware doesn’t like to learn on data packets (“fast path”) • Encapsulation not too desirable • For IP packets, we can avoid both the above • Forward like IP, using IP header • learn from ARP replies • decrement hop count in IP header • L2 header: Rbridge to Rbridge Donald Eastlake 3rd, Motorola

  18. Avoiding encapsulation for IP • On-campus IP destination • forward based on IP header • learn from ARP replies • if destination unknown, flood ARP query • Off-campus IP destination • forward based on layer 2 destination Donald Eastlake 3rd, Motorola

  19. Conclusions • Looks to routers like a bridge • invisible, plug-and-play • Looks to bridges like routers • terminates spanning tree, broadcast domain • Much better replacement for bridging • optimal paths • still plug and play and transparent • fast convergence • no meltdowns Donald Eastlake 3rd, Motorola

  20. Further References • See web site (includes info on the rbridge mailing list) • http://www.postel.org/rbridge • IETF draft: • http://www.ietf.org/internet-drafts/draft-perlman-rbridge-01.txt Donald Eastlake 3rd, Motorola

More Related