I hope you never believed the “OpenFlow networking nirvana” hype in which smart open-source programmable controllers control dumb low-cost switches, busting the “networking = mainframes” model and bringing the Linux-like golden age to every network. As the debates during the OpenFlow symposium clearly illustrated, the OpenFlow reality is way more complex than it appears at a first glance.
The switches are totally dumb; the controller performs all control-plane functions, including running control-plane protocols with the outside world. For example, the controller has to use packet-out messages to send LACP, LLDP and CDP packets to adjacent servers and packet-in messages to process inbound control-plane packets from attached devices.
This model has at least two serious drawbacks even if we ignore the load placed on the controller by periodic control-plane protocols:
The switches need IP connectivity to the controller for the OpenFlow control session. They can use out-of-band network (where OpenFlow switches appear as IP hosts), similar to the QFabric architecture. They could also use in-band communication sufficiently isolated from the OpenFlow network to prevent misconfigurations (VLAN 1, for example), in which case they would probably have to run STP (at least in VLAN 1) to prevent bridging loops.
Fast control loops like BFD are hard to implement with a central controller, more so if you want to have very fast response time.
NEC seems to be using this model quite successfully (although they probably have a few extensions), but already encountered inherent limitations: a single controller can control up to ~50 switches and rerouting around failed links takes around 200 msec (depending on the network size). For more details, watch their Networking Tech Field Day presentation.
Native OpenFlow with extensions
A switch controlled entirely by the OpenFlow controller could perform some of the low-level control-plane functions independently. For example, it could run LLDP and LACP, and bundle physical links into port channels (link aggregation groups). Likewise, it could perform load balancing across multiple links without involvement of the controller.
OpenFlow 1.1 supports multipathing, but is rarely implemented in hardware devices.
Some controller vendors went down that route and significantly extended OpenFlow 1.1. For example, Nicira has added support for generic pattern matching, IPv6 and load balancing.
Needless to say, the moment you start using OpenFlow extensions or functionality implemented locally on the switch, you destroy the mirage of the nirvana described at the beginning of the article – we’re back in the muddy waters of incompatible extensions and hardware compatibility lists. The specter of Fiber Channel looms large.
Ships in the night
Switches have traditional control plane; OpenFlow controller manages only certain ports or VLANs on trunked links. The local control plane (or linecards) can perform the tedious periodic tasks like running LACP, LLDP and BFD, passing only the link status to the OpenFlow controller. The controller-to-switch communication problem is also solved: the TCP session between them traverses the non-OpenFlow part of the network.
This approach is commonly used in academic environments where OpenFlow is running in parallel with the production network. It’s also one of the viable pilot deployment models.
OpenFlow classifiers and forwarding entries are integrated with the traditional control plane. For example, Juniper’s OpenFlow implementation inserts compatible flow entries (those that contain only destination IP address matching) as ephemeral static routes into RIB (Routing Information Base). OpenFlow-configured static routes can also be redistributed into other routing protocols.
Going a step further, Juniper’s OpenFlow model presents routing tables (including VRFs) as virtual interfaces to the OpenFlow controller (or so it was explained to me). It’s thus possible to use OpenFlow on the network edge (on user-facing ports), and combine the flexibility it offers with traditional routing and forwarding mechanisms.
From my perspective, this approach makes most sense: don’t rip-and-replace the existing network with a totally new control plane, but augment the existing well-known mechanisms with functionality that’s currently hard (or impossible) to implement. You’ll obviously lose the vague promised benefits of Software Defined Networking, but I guess that the ability to retain field-proven mechanisms while adding customized functionality and new SDN applications more than outweighs that.
For more details on Juniper’s OpenFlow implementation, watch Dave Ward’s presentation from the OpenFlow symposium or a more detailed presentation he gave during the Network Field Day.
Disclosure: vendors mentioned in this post indirectly covered my travel expenses during the OpenFlow Symposium and Networking Tech Field Day, but nobody has ever asked me to write about their products or solutions. Read the full disclosure (or more precise ones by Tony Bourke or Matt Simmons).