Ethane: Taking Control of the Enterprise
by Martin Casado, Michael Freedman, Justin Pettit, Scott Shenker, Nick McKeown
url show details
Details
| type: | misc | | booktitle: | Proceedings of the {ACM} {SIGCOMM} 2007 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, Kyoto, Japan | | year: | 2007 | | publisher: | ACM | | pages: | 1--12 | | abstract: | This paper presents Ethane, a new network architecture for the
enterprise. Ethane allows managers to define a single networkwide
fine-grain policy, and then enforces it directly. Ethane couples
extremely simple flow-based Ethernet switches with a centralized
controller that manages the admittance and routing of flows.
While radical, this design is backwards-compatible with existing
hosts and switches.
We have implemented Ethane in both hardware and software,
supporting both wired and wireless hosts. Our operational Ethane
network has supported over 300 hosts for the past four months in
in Stanford University’s network, and this deployment experience
has significantly affected Ethane’s design. | | url: | http://ccr.sigcomm.org/online/files/fp298-casado.pdf | | editor: | Jun Murai and Kenjiro Cho |
|
|
You need to log in to add tags and post comments.
I think this paper is an excellent example of a real world implementation of an SDN. The authors make a compelling case for the use of Ethane in real world environments and demonstrate its viability as an SDN platform.
The paper describes work by the authors to build an end-to-end SDN platform, which can be easily configured through a simple configuration on a central controller. After rules are written, data plane configuration is generated as the controller finds the optimal flow path between any two hosts on the network.
The paper makes a compelling argument for their proposed method of SDN through an actual implementation. The authors demonstrate that the system would scale well to small/medium sized networks and that their system is highly effective at determining optimal layer 2/3 paths/routes between hosts.
The weaknesses in the paper are largely enumerated, the biggest being that in order for the full potential of the proposed solution to be realized custom hardware must be built. In the case of this paper the authors implemented 11 custom switched, the authors are however careful to point out that the custom hardware is actually far simpler than traditional hardware as most computations are offloaded to the controller for flow calculation. Another potential weakness is that the system clearly cannot scale to very large networks without much adaptation as the central controller must look at the first packet in all flows and must have full knowledge of the entire network topology. Determining optimal routes in larger networks does not scale linearly with the number of nodes in the network.
One thing I would consider doing differently is putting more work into splitting up/distributing the functionality of the controller. The authors show that their proposed system is viable but it has scalability limits. If it is possible to have switches communicate with their nearest controller it might be possible to design a system with far larger scalability potential.