Scalable Ethernet: Rbridge and SEATTLE

thoughtlessskytopNetworking and Communications

Oct 29, 2013 (4 years and 14 days ago)

80 views

Scalable Ethernet:
Rbridge

and
SEATTLE



Motivation



Rbridge



SEATTLE (Scalable Ethernet Architecture for Large
Enterprises)


Motivation


“All
-
Ethernet” enterprise networks or data
center networks are appealing.


Network management is easy


Self
-
learning, plug
-
and
-
play


Permanent and location independent addresses


Host mobility


Access control policies


troubleshooting



Ethernet does not scale


Inefficient forwarding paths


The spanning tree algorithm


Broadcasting for basic service


ARP and DHCP all broadcast
-
based


Flooding
-
based delivery


Flooding when the destination is unknown.

State of the practice 1: IP based
solution


Enterprise networks comprised of a network
of Ethernet IP subnets.

R

R

R

R

Ethernet Bridging


-

Flat addressing


-

Self
-
learning


-

Flooding


-

Forwarding along a tree

IP Routing (e.g., OSPF
)


-

Subnet configuration


-

Host configuration


-

Forwarding along shortest paths

R

Broadcast Domain

(LAN or VLAN)

IP based solution


Issues


An IP prefix for each link (broadcast domain), lot
of configuration.


Worse for more dynamic networks


No service continuity across location changes


IP address changes when changing subnets



Location
-
based access
-
control?


State of current practice 2: VLAN


What is VLAN?


VLAN is basically a LAN


The difference is in the packaging


VLANs are
separete

LANs among ports on the same switch


VLAN can also be built across multiple switches.

»
One spanning tree per VLAN


Machines on different VLAN will have different IP
addresses.

State of current practice 2: VLAN


VLAN for large enterprise network


Better address configuration


Not one prefix per link


VLAN configuration is still hard


Host mobility across VLAN has the same problem
as the IP based solution.


Scalable Ethernet


Problem to be addressed


Ineffective routing


Broadcast storm


Minimizing flooding


Additional constraints: no change to other
layers


Rbridge

and the TRILL protocol (IEEE
802.1ah)


What does it provide?


Optimal point
-
to
-
point forwarding with zero
configuration.


Multi
-
pathing


Mechanism:


Introduce IS
-
IS link state routing at Layer 2


Add TTL to Layer 2 header


Started by
Radia

Perlman who is the inventor
of the spanning tree protocol.



Where is
Rbridge

in the layered
model?

Use of
Rbridges

Use of
Rbridges

How
RBridges

work?


RBridges

find each other by exchanging TRILL
IS
-
IS
Hellow

frames


Send the multicast address ALL
-
IS
-
IS
-
Rbridges

(design the header such that traditional bridges
understand the header)


Each link has one
Designated
Rbridge


Each
Rbridge

has a copy of the global link
-
state
dtabase




How
RBridges

work?


The designated
RBridge

specifies the
Appointed
Forwarder

for each VLAN on the link and
Designated VLAN
for inter
-
RBridge

communication


Appointed forwarder handle native frames
to/from that VLAN


Encapsulates the frame into a TRILL frame


Decapsulates

the native frame from TRILL frames



TRILL header

Rbridge

property


Compatible with the current layer 1, 2, and 3
devices, not change needed.


Rbridges

can be incrementally deployed.


Rbridges

provide shortest path routing


Rbridges

support multi
-
path routing


Rbridges

handles transience loops.

SEATTLE: Scalable Ethernet
Architecture for Large Enterprises


Clean
-
slate approach


Design objectives


Unicast

unicast

traffic


Unicast
-
based bootstrapping (ARP, DHCP)


More effective broadcasting


On demand host location information


Shortest paths without broadcast storms


Not change in Layer 3


Major operations at SEATTLE


Flat addressing of end
-
hosts


Switches use hosts


MAC addresses for routing


Ensures zero
-
configuration and backwards
-
compatibility



Automated host discovery at the edge


Switches detect the arrival/departure of hosts


Obviates flooding and ensures scalability



Hash
-
based on
-
demand resolution


Hash deterministically maps a host to a switch


Switches resolve end
-
hosts


location and address via hashing


Using a distributed hash table (DHT)


Ensures scalability



Shortest
-
path forwarding between switches


Switches run link
-
state routing to maintain only switch
-
level topology (i.e.,
do
not

disseminate end
-
host information)


Ensures data
-
plane efficiency


Seattle example

Host discovery


or registration

B

D

x

y

Hash

(
F
(
x
) =
B
)


Store

<
x
,
A
> at

B

Traffic to
x

Hash

(
F
(
x
) =
B
)

Tunnel to


egress node,
A

Deliver to
x

Switches

End
-
hosts

Control flow

Data flow

Notifying

<
x
,
A
> to
D


Entire enterprise

(A large single IP subnet)

LS core

E

Optimized forwarding


directly from
D

to
A

C

A

Tunnel to

relay switch,
B



DHT for location/address resolution


The quality of the hashing matters:

F(x)


Each switch is

logically one hop away.



B

C

D

x

y

y

sends traffic
to

x

E

Every switch on a ring
is

logically one hop away

21

Unicast
-
based Bootstrapping: ARP


ARP


Ethernet: Broadcast requests


SEATTLE: Hash
-
based on
-
demand address resolution



1. Host


discovery

2. Hashing


F
(
IP
a
) =
r
a

3. Storing


(
IP
a

,
mac
a

,

s
a
)

4. Broadcast

ARP req

for
a

5. Hashing

F
(
IP
a
)

=
r
a

Switch

End
-
host

Control msgs

ARP msgs

s
a

a

b

r
a

s
b

6. Unicast

ARP req

to
r
a



7.
Unicast

ARP reply


(
IP
a

,
mac
a

,

s
a
)


to ingress

Owner of

(
IP
a
,
mac
a
)

22

Control
-
Plane Scalability When Using Relays


Minimal overhead for disseminating host
-
location
information


Each host’s location is advertised to only two switches



Small forwarding tables


The number of host information entries over all
switches leads to
O(H)
, not
O(SH)



Simple and robust mobility support


When a host moves, updating only its relay suffices


No forwarding loop created since update is atomic

23

Data
-
Plane Efficiency w/o Compromise


Price for path optimization


Additional control messages for on
-
demand resolution


Larger forwarding tables


Control overhead for updating stale info of mobile
hosts



The gain is much bigger than the cost


Because most hosts maintain a small, static
communities of interest (COIs)
[
Aiello et al., PAM’05
]


Classical analogy: COI


Working Set (WS);

Caching is effective when a WS is small and static


24

SEATTLE Conclusions


SEATTLE is a
plug
-
and
-
playable

enterprise
architecture ensuring both
scalability

and
efficiency


Trading a little data
-
plane efficiency for huge control
-
plane scalability makes a qualitatively different system




Enabling design choices


Hash
-
based location management


Reactive location resolution and caching


Shortest
-
path
forwarding