Rbridges: Transparent Routing

1
Rbridges Transparent Routing

• Radia Perlman
• radia.perlman_at_sun.com

2
Some info

• www.postel.org/rbridge
• Has bunch of info, including how to join mailing
  list, the archives of mailing list, original
  INFOCOM paper and slides, ...
• There is an internet draft coauthored by me, Joe
  Touch (touch_at_isi.edu), and Alper Yegin
  (alper.yegin_at_samsung.com), also posted on
  www.postel.org/rbridge

3
Goals

• Glue a bunch of links together to appear to be a
  single LAN to IP nodes
• No configuration of internal switches
• Compatible with existing bridges
• Compatible with existing IP nodes (v4 and v6,
  endnodes and routers)

4
Whats wrong with bridges?

• They solve the problems on the previous slide
• But
• Routes not optimal
• Temporary loops a disaster
• Choice of meltdowns or conservative failover

5
Basic idea of transparent bridge

• Listen promiscuously
• Learn location of source address based on source
  address in packet and port from which packet
  received
• Forward based on learned location of destination
• When in doubt, forward

6
Station learning
Q
V
V
X,F
A
X
X,A,V
A
C
F
F
G
7
But loops are a disaster

• No hop count
• Exponential proliferation

B2
B1
B3
8
Thus the Spanning Tree Algorithm

• I think that I shall never seeA graph more
  lovely than a tree.
• A tree whose crucial propertyIs loop-free
  connectivity.
• A tree which must be sure to spanSo packets can
  reach every LAN.
• First the Root must be selectedBy ID it is
  elected.
• Least cost paths from Root are tracedIn the tree
  these paths are placed.
• A mesh is made by folks like me.Then bridges
  find a spanning tree.
• Radia Perlman

9
Path from a to c
a
2,1,6
2,3,3
11
6
c
7
2,3,3
9
2,0,2
2,2,7
3
2
5
10
2,2,4
2,0,2
4
14
2,2,4
2,1,5
2,1,14
10
Problems with Bridges

• Routes are not optimal (spanning tree)
• STA 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

11
Compare this to routing

• Routers have temporary loops, too
• Part of the life of distributed algorithms
• But IP has a hop count (TTL)
• An IP router only forwards in one direction
• And the router specifies the next recipient

12
Why bridges are slow to start forwarding

• Temporary loops might cause meltdown
• Cant (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 dont want
  meltdowns)

13
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

14
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 IP address if change links

15
Using bridges with IP

• Bridging is used to create a campus in which all
  nodes share the same prefix
• Looks to IP like a single link
• But bridging isnt as good as routing
• Suboptimal routes
• Traffic concentration (onto spanning tree links)
• Meltdowns
• Slow failover

16
What wed like best of both worlds

• Keep transparency to endnodes and zero
  configuration
• Optimal paths
• Make temporary loops safe
• Fast failover
• No meltdowns

17
Rbridges

• Compatible with todays 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

18
Basic Rbridge idea

• Link state protocol among Rbridges (so know how
  to route to other Rbridges)
• Somehow learn location of endnodes (e.g., from
  data traffic, or ARP replies)
• Report attached endnodes in link state info
• Need to encapsulate pkts
• To distinguish originating traffic from transit
• To specify next recipient
• To include a hop count

19
Rbridging
R7
c
R9
R1
R8
R5
R4
R3
R6
R2
a
20
Encapsulation Header
SXmitting Rbridge DRcving Rbridge pttransit
hop count
original pkt (including L2 hdr)

• Outer L2 hdr must not confuse bridges
• So its 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

21
Need spanning tree for flooding

• Need it for distributed ARP request
• Or for unknown layer 2 destinations (e.g.,
  endnode knows the layer 2 address of the exit
  router)
• Dont need to use the bridge spanning tree
• Instead, compute it from the link state database

22
Rbridges and Bridges
R4
R7
R2
Seems like
R2
Actually can be
bridged LAN
R4
R7
23
Example IP nodes A and B
B
RB2
RB1
A
24
Example A and B, Rbridges dont know B

• A issues ARP request for B
• RB1 doesnt know, so issues distributed ARP
  request (flooded through spanning tree)
• Each Designated RBridge issues ARP request on its
  LAN
• RB2 receives a reply (B,b)
• RB2 reports (B,b) in its link state info

25
Example A and B, RBridges DO know B

• A issues ARP request for B
• RB1 responds with an ARP reply (Bb)
• A transmits to b
• RB1 encapsulates
• RBridges forward towards b, replacing outer
  header on each hop, and decrementing outer hdr
  TTL
• RB2 decapsulates

26
Example A and off-campus B
R
RB2
B
RB1
A
27
A and off-campus B

• A will send to a routers layer 2 address, say
  Rs layer 2 address x
• RBridges have to send to that IP router
• If x is in the forwarding table, then RB1
  encapsulates and forwards to x
• Else (x unknown), RB1 encapsulates and sends on
  spanning tree
• Each Designated RBridge decapsulates

28
Learning a layer 2 address

• Can learn from data packets
• Or if dont want to for IP, listen to routing
  messages in order to learn layer 2 addresses of
  IP routers

29
Another optimization for IP

• Can have short endnode cache timer
• Designated RBridge pings to make sure local IP
  nodes still there

30
Non-IP

• Learn layer 2 address from data packets
• Flood packets for unknown destinations on
  spanning tree

31
New IS-IS TLVs

• For layer 2 only MAC addresses that are locally
  connected
• For IP (layer 3, layer 2) pairs, for proxy ARP

32
Other IS-IS changes

• Calculate a spanning tree deterministically and
  uniquely from link state database
• pick router with smallest ID
• calculate a tree with him as root
• this is the tree to use for unknown layer 2
  destinations, or ARP requests
• Make sure IS-IS instances don't mix (new L2
  multicast to send IS-IS msgs?, maybe area
  address?)

33
Conclusions

• Looks to routers like a bridge
• invisible, plug-and-play
• Looks to bridges like routers
• terminates spanning tree, broadcast domain

34
Conclusions, contd

• Much better replacement for bridging
• optimal paths
• still plug and play and transparent
• fast convergence
• no meltdowns
• For IP
• allows plug-and-play single-prefix campus