Kandoo

Soheil Hassas Yeganeh, Yashar Ganjali

2012 · 633 citations · 19 references

DOIFull text

Open access

Concepts

TL;DR

Limiting overhead of frequent events on the control plane is essential for scalable SDN, but processing them in the data plane requires switch modifications that reduce control‑plane visibility. The authors propose Kandoo, a framework that preserves scalability without modifying switches. Kandoo uses a two‑layer controller hierarchy: a bottom layer of independent local controllers handling most frequent events, and a top logically centralized controller maintaining global state. Evaluations show that Kandoo reduces control‑channel consumption by an order of magnitude compared to standard OpenFlow networks, enabling on‑demand replication of local controllers to relieve the top layer.

Abstract

Limiting the overhead of frequent events on the control plane is essential for realizing a scalable Software-Defined Network. One way of limiting this overhead is to process frequent events in the data plane. This requires modifying switches and comes at the cost of visibility in the control plane. Taking an alternative route, we propose Kandoo, a framework for preserving scalability without changing switches. Kandoo has two layers of controllers: (i) the bottom layer is a group of controllers with no interconnection, and no knowledge of the network-wide state, and (ii) the top layer is a logically centralized controller that maintains the network-wide state. Controllers at the bottom layer run only local control applications (i.e., applications that can function using the state of a single switch) near datapaths. These controllers handle most of the frequent events and effectively shield the top layer. Kandoo's design enables network operators to replicate local controllers on demand and relieve the load on the top layer, which is the only potential bottleneck in terms of scalability. Our evaluations show that a network controlled by Kandoo has an order of magnitude lower control channel consumption compared to normal OpenFlow networks.

References

19