Vendors take alternatives to OpenFlow SDN
A comprehensive collection of articles, videos and more, hand-picked by our editors
Finding one mechanism to manage a network top to bottom is the Holy Grail for network architects. This usually unobtainable goal now has a significant chance of coming into existence as we transition OpenFlow into a protocol that goes beyond Layer 2 and the data center.
For the last few years the networking industry has been abuzz about SDN and OpenFlow. While these two are often coupled, this obfuscates the real value of both -- specifically much of the SDN discourse has been around data center and campus networks. Yet OpenFlow is only one element of that picture. Creating forwarding paths within a Layer 2 domain is important, but it is ultimately only a small piece of the picture. After all, how valuable is data center networking and provisioning without connectivity to other resources and consumers of these services?
Too often we overlook how OpenFlow could alter centralized management and control at every layer of the network. WAN and the existing carrier networks, with their current forwarding mechanisms -- e.g., MPLS, VPLS and the venerable Layer 3 routing mechanisms -- are a critically important part of providing application-level services and last-mile connectivity.
Failing to consider these pieces of the larger network puzzle when considering an OpenFlow strategy is simply shortsighted. To that end, OpenFlow must be refined into a cross-platform, multi-layer network control protocol.
One control protocol for every network layer?
OpenFlow has the potential to be the one ring of control protocols. Eventually it can be part of a single strategy to manage and manipulate DWDM Waves, MPLS LSPs, VPLS circuits, Layer 3 routing, Layer 2 tagging and access level ports, and even "Layer 8" -- or the administrative and political layer.
OpenFlow has all of the markings of a great equalizer in an industry that is using YANG, NETCONF, SSH, Telnet and a range of other management mechanisms. This is perhaps an idealistic goal but it is achievable and foundations have already been poured to make it a reality.
With OpenFlow 1.4, support for optical interfaces has already been added into the specifications. Optical control is one of the more difficult aspects of centralized control. This is an early indicator that OpenFlow 1.3 and, even more so, 1.4, are well positioned to manage based on criteria from the optical layer up, which includes supporting MPLS and protocols like IPv6.
A few roadblocks to OpenFlow as a single network control protocol
More on the OpenFlow in action
OpenFlow in use for self-service WAN provisioning
OpenFlow and the open transport switch for optical networks
OpenFlow for SDN monitoring
This is not to say that there isn't a long way to go for OpenFlow, considering the 1.4 specification includes provisions for only very basic optical control. While 1.4 already has some of the foundational bits for optical control, Layer 3 at the WAN level is an entirely different beast. To make that happen, there must be a way to consume and act on a very large data set --~400k IPv4 routes, ~13k IPv6 routes, for example. It's doable, but making it stable, redundant and scalable will be difficult.
Realistically, in the shorter term I see OpenFlow controlling L2/L2.5/MPLS circuits and L3 next hops, as well as some other bits like time-to-live (TTL). However, for now, the heavy lifting of the global table will be left to "real" routers that may operate in hybrid mode for a life cycle or two.
To see real growth as a single network control protocol, OpenFlow will need full multi-vendor support, which is significant and thus far not completely uniform. What's more, the controller market must mature. OpenDaylight is currently the leader in this space, but for wide adoption, the market will need some competitive options to help drive innovation and adoption. Finally, to really make an impact into the full stack of the networking industry, OpenFlow must be considered as important as any other standard protocol and it must be ubiquitously deployed and supported much like SSH and SNMP are today.