Operators who talk with me about OpenFlow present a challenge wrapped in a paradox for those who want to promote the technology of SDNs. The paradox is that operators have a variety of highly tactical targets of interest for SDN principles, a variety that’s hard to harmonize with a single drive forward. The challenge is that even future harmony of tactics depends on the emergence of a strategy, and it’s not clear how that can happen. Operators, big potential buyers of SDN and the most likely to push the technology out of the data center, are divided.
The good news is that while I’m seeing a lot of OpenFlow and SDN missions proposed and not a lot of harmony on the details of any of them, there is one common element. Every operator who’s talking SDN to me right now is talking a metro application. Some are looking at SDN principles for what could be called “over-stream capacity management”, meaning the control of bandwidth from source to user to insure that streamed content needs match capacity assigned every step of the way. Some are looking at SDNs as a means of better managing roaming for mobile broadband, specifically in supporting mobility for more general IP/Internet applications rather than IMS applications. Some think SDNs might help WiFi broadband for tablets and smartphones integrate with cellular services, or even help create unified services from a series of hotspots. Most believe that there might be a better electro-optical partnership possible for backhaul, for hotspot connectivity, and for residential broadband. Most also think that network efficiency and operations could be improved.
The bad news is that even among network operators, there is limited contextual awareness of OpenFlow and SDNs. While every operator I talk with or survey has some specialists who are very aware that OpenFlow is a piece of a future SDN whose other pieces aren’t really being talked about, I’d have to admit that if you had to assign a position to the vast bureaucracy of any given operator, that position would be that somehow OpenFlow is going to evolve to address everything. Maybe, but I’m not sure I see where that’s happening and I’m not sure that the recent history of standards processes demonstrates any credibility in the claim that these processes can move quickly toward such a broad goal.
To start with, SDN is at the union of two critical trends, the cloud trend and the evolution of the network to a true NGN model. The cloud frames the demand and requirements side and the SDN frames the evolution and the hardware/operations side. The two cannot meet in OpenFlow because it’s simply a control protocol to manage forwarding-table entries. In the September issue of our technical journal Netwatcher, I talked about the bottom part of this partnership, and in October I’m covering the top end. I also propose to do some hangouts on the topic of cloud/SDN symbiosis, and hope to be able to talk about some specific vendor approaches in October or November, depending obviously on the announcement timing.
The second issue is achieving a strategic SDN position without a specific goal. We can’t define SDN in any universally accepted way, and the problem is getting worse as vendors discover that SDNwashing is even easier than cloudwashing. Even a solid definition isn’t the basis for a strategic position because you need an architecture, something that everything from the network on the bottom to the cloud on the top can work to achieve. We’re trying to do SDN without knowing what one looks like, confident we’d know it if we saw it. Not so; we’ll never know it without a quick injection of order to dispel SDNwash chaos.
The cloud community has defined abstractions for current network services, and SDNs so far are aimed at an alternative mechanism for creating current network services. We need to understand how the totality of the current network can be created with or be symbiotic with SDN elements. I think that will likely emerge as we tweak the relationship between cloud and network, and that’s the best place for them. Why invent stuff hoping the cloud will somehow morph into using it. We have a unique opportunity with SDN—an opportunity to build network services based on demand and not supply. Let’s not blow it.