C. Kim, M. Caesar, J. Rexford, “Floodless in SEATTLE: A Scalable Ethernet Architecture for Large Enterprises,” ACM SIGCOMM Conference, (August 2008). [PDF]

Summary

SEATTLE is an enterprise network architecture that combines the scalability of IP networks with the simplicity of Ethernet without incurring respective drawbacks. It uses flat address space to provide plug-n-play functionality and ensures scalability and performance through shortest-path routing, hash-based host resolution mechanism, aggressive caching, and one hop DHT lookups to avoid flooding in ARP and DHCP protocols.

The authors present a nice overview of the existing technologies used in enterprise networks and argue why Ethernet, now largely adopted, cannot be continued as the method of choice in relatively large networks even though it has some nice properties (e.g., flat address space for instant installation, manageability etc.). There are several critical faults in Ethernet-based solutions:

• Ethernet bridging requires flooding in the network to locate previously unknown end hosts (i.e., end hosts without physical to MAC address mapping). This requires large number of states and incurs control overhead that grows linearly with the number of end hosts.
• Ethernet arranges the broadcast domain as a spanning tree, which cannot be scaled to larger networks due to low latency, high availability requirements.
• In a Ethernet solution, ARP is used to resolve IP to MAC addresses which rely on broadcasting, hence not scalable. Same goes for commonly used DHCP for dynamic IP address allocation to end hosts.

Scalability issues in Ethernet can be solved by arranging them into IP subnets and then using shortest-path routing over IP addresses. However, as the authors point out, IP is harder to manage and require considerable amount of resources. There are several other solutions such as VLANs that allow logical grouping of hosts for better management while providing many of the Ethernet’s management advantages. However, VLAN also rely on IP to allow host in different VLANs to communicate.

Considering all the options, the authors go for a middle ground to implement a one-hop network layer DHT in the switch-level that stores the location of all the end hosts using a link-state routing protocol. The DHT also acts as a directory service for address resolution and provides service discovery service. SEATTLE forwards packets based on end host MAC address using the DHT as a mapper and resolver. In order to reduce control overheads during network failure or excessive churn, SEATTLE uses consistent hashing, and it balances load using the concept of virtual switches. Scalability in SEATTLE is supported by creating multi-level hierarchy of one-hop DHTs. In addition, SEATTLE removes broadcasting requirement from ARP and DHCP.

SEATTLE promotes a traffic-driven reactive location resolution and caching to avoid excessive load on the directory service. Cache update in this architecture is based on explicit notifications, heart-beat protocol, and some other clever workarounds (e.g., MAC eviction list for updating remote host’s cache). Based on its features, SEATTLE inherently supports mobility without having to do anything explicitly.

In addition to everything, the proposed architecture is backward compatible in the sense that it exposes Ethernet-like semantics for immediate deployment. However, beneath its hood, all the broadcasting is replaced by unicast or DHT lookups, multi-casting and access control is supported by using group concept, and bootstrapping functionalities are modified to avoid flooding.

The authors demonstrate the validity and performance of SEATTLE using extensive packet-level simulation of real enterprise network traces and through experimentation using XORP and Click modular router.

Critique

SEATTLE’s focus on solving an old problem using a clean-slate design without throwing out old values and restrictions is admirable. The paper itself is very well-presented and hence easy to follow. One special attraction of this paper is the detailed discussion on the past and the state-of-the-art in enterprise networks.

Hierarchical arrangement of DHTs for scalability is half-baked and not well explained (an aside: most probably it is inspired by Caesar’s previous work on ROFL). However, it is unlikely that too many levels in the hierarchy will be necessary (how many end hosts can there be in an enterprise network anyway?)

Security can be an issue if any of the end hosts is compromised, but one can probably assume that within the guarded perimeter of an enterprise network it can be handled somehow (at least with higher probability than in the Internet)!