Floodless in SEATTLE: A Scalable Ethernet Architecture for Large Enterprises May 12, 2009

Three Important Things:

• The motivating question for this work is that Ethernet networks provide several benefits such as “zero configuration” and a flat address space but do not scale well. The proposed solution operates at the network level and leverages a scalable DHT that does not require level 2 switches to maintain state for every host. Instead, host information (MAC, IP address) is mapped to a switch as the result of a distributed hash query. This removes the need for flooding in order to dissminate information, and protocols like ARP and DHCP can be replaced with on-demand queries and updates to a directory service abstraction.
• SEATTLE was designed to provide the appearance of regular ethernet to regular hosts, while maintaining a new internal network structure. This is a key selling point and paves the way for realistic, practical deployment. This feature is achieved by making the switches “link aware.” A switch is able to detect which links are connected to hosts as opposed to other switches by sending a control messge not recognized by end host level 2 NICs. Such links are treated in a special way in order to perform discovery and configuration. DHCP and ARP packets are snooped for this purpose.
• Experimental results were important in order to justify the claims of scalability and Ethernet class performance. Using simulation traces, the authors determined that forwarding table size is reduced by a factor of 41 in a 50K host network when compared to Ethernet. Table size and control overhead scale linearly with the number of hosts. In an Emulab implementation, SEATTLE switches significantly outperformed Ethernet in the middle of the network, however border switches required more processing time in order to deal with learning host addresses.

Glaring Problem:

Although a SEATTLE deployment would be transparent from the perspective of the end hosts, it would require a complete overhaul of the underlying network. This represents a significant cost barrier for an organization with a large existing infrastructure, the likes of which such a solution would be directed at. The authors dedicated little or no discussion to incremental deployment and coexistence with regular Ethernet switches and level 3 routers. Such a scenario has significant implications for the adoption of SEATTLE.

Future Work:

The DHT abstraction provided by the network is currently hidden from  the end hosts. Assuming the hosts can be made “SEATTLE aware,” they could make great use of the DHT for applications such as peer-to-peer content sharing. In order for this to happen future work would need to explore the necessary modifications to the host and possibly to the network.

Floodless in SEATTLE: A Scalable Ethernet Architecture for Large Enterprises May 12, 2009

(i) the three most important things the paper says

One of the most important ideas that the paper discusses are the changes to the link state protocol.  Most notably, the change that allows SEATTLE to only map the switch locations (instead of mapping individual machines).  This reduces the number of broadcast advertisements sent throughout the network, which helps to address one of the biggest problems with Ethernet and IP.  Another important idea that the paper speaks about is the fact that this scheme can do away with the spanning tree protocol, which will actually allow for more efficiency in switch communication (instead of letting a shortest path go to waste for the sake of configurability).  This is important because the authors are attempting to address one of the weak points of Ethernet, because of the bottlenecks that it could possibly create.  A third important idea that the authors put forth is that this scheme can still function properly while still maintaining end-to-end Ethernet and IP semantics.  This means that only the switching hardware needs to change in order to implement this scheme and all end-host hardware can remain the same.

(ii) the most glaring problem with the paper

One of the biggest problems that I can see with this scheme is the fact that it requires 100% proprietary hardware, and in order to function properly cannot use any traditional hardware.  This requires a user to completely revamp their entire networking system with potentially expensive hardware all at once.  This will make this idea much more difficult to transition to.

(iii) the future research directions of the work

A couple future directions would be useful.  First, reducing the complexity of the hardware would be an option, as this would make the “glaring problem” much more tolerable.  Another option would be to somehow adapt the scheme to work partly with commodity hardware, so that users could gradually move their scheme over (which would probably give this scheme more feasibility).

Floodless in SEATTLE: A Scalable Ethernet Architecture for Large Enterprises May 12, 2009

SEATTLE is a proposal for an architecture that is as auto-configuring as Ethernet, but scales like configured IP networks. The problems with Ethernet are its use of flooding to communicate, forwarding tables proportional to the number of hosts, and a single spanning tree that does not provide shortest path semantics. The problems with IP networks are the need for subnetting, coordinating IP prefixes (for DHCP servers), and lack of support for mobility.

The paper provides contributions in the way of building a scalable auto-configuring network that uses a distributed directory service as the basis for address resolution and location information. Some key features include the use of a single hop DHT as the directory service, and reactive caching for address and location information to avoid excessive load.

The directory service is used to distribute key value pairs such as: (MAC, IP) and (MAC, location info). This information is used by switches to avoid broadcasting requests across the network. For example, when an ARP request is received by a switch, it looks up the switch that corresponds to the MAC address and asks it for the current IP address. This alleviates the need to store per node information in each switch. Additionally, it makes IP changes (perhaps from node mobility) easy to implement. The MAC address never changes, and therefore neither does the switch that corresponds to it. Therefore, when an IP address changes, it needs to be updated in only 1 location.

A DHT is the underlying mechanism for the directory service. All the switches use the same hash function to identify which switch corresponds to which key (in a key value pair). Thus, every access to the DHT is a single hop. For extremely large networks, the DHT can cover a large geographic range. Therefore, the authors considered a region grouped variant of the DHT. In this variant, the hash function for a region identifies switches only within that region. When link state is written to a switch, that information is also written to a border switch (on the network’s so called backbone). The border switch is the externally responsible switch that other regions will hash to for nodes in the original, local region.

The last contribution is the use of fastidious caching. The authors recognized that within large enterprises/organizations most nodes communicate only with a small set of other nodes with in the network (i.e. email server, file server, etc.). Thus when the authors added address and location caching to the switches (as an optimization), they do so reactively instead of proactively. This reduces the amount of forwarding table use in each switch while at the same time providing shortest path information.

The SEATTLE architecture is quite impressive. As with other “scalable Ethernet” alternatives it suffers from the fact that switches must be modified to implement the new architecture. Until switches become configurable or a vendor begins implementing modified switches, I don’t expect these new architectures to be anything other than good simulations.

Despite its applicability in real world networks (as of the moment), I think that further research would make it a more attractive option for business to adopt. Research in the area of multicast and anycast would add to the usefulness and could push this design closer to real world adoption.