Cisco’s announcements on Network Convergence System (NCS) follow their normal pattern that’s fairly characterized as “chicken-little” sales stimulation. The network sky is falling because everyone and everything is going to be connected and demanding their bits be transported. Suck it up, operators, and start spending!
Underneath this opportunism is a reality, though, which is that there will be changes to traffic and network facilitation of applications. I think that Cisco, underneath it all, actually has a handle on what those changes might be and is preparing for them. The problem is that it’s complicated and it’s coming over a longer cycle than they’d like, so they need to toss some blue pieces of china up into the air and generate some near-term sales momentum.
Networking has always been a layered process, a way of creating connectivity by dividing the overall mission among functional elements in an orderly way. Data links create reliable box-to-box connection, and then a network layer takes over to offer addressing and open connectivity. The Internet works that way today. SDN, which is an element of Cisco’s NCS, offers us an opportunity to do things a little differently.
“Routing” in a functional sense (meaning at any level) means that we make a per-device forwarding decision set that adds up to creating a service model, which is really a connection model. The presumption behind nearly all of our connection models today is that we have a community of users who expect to communicate. They may not all talk with each other, but they might. Therefore we build open models to address and connect.
When you move to Cisco’s “Internet-of-Everything” what changes is that you add a bunch of “things” that aren’t designed for open communication. The traffic camera or process sensor needs to communicate with a control center, and in fact needs to be protected from other access. If you add a bunch of these new things to the Internet what you break is less traffic than the model of open connection. With SDN you could fix it.
SDN (at least in its purist OpenFlow form) says that connection is explicitly controlled by a “central” meaning non-device, non-adaptive, process. Traffic goes from hither to yon because you explicitly made that happen. There is no presumption of open connectivity, only “Mother-may-I”. If you have a traffic camera or a process sensor, you can drive a route between them and everything is fine.
The challenge for this is that it’s clearly not going to scale. We can’t build routes for every flow on the Internet, not even in a small geography. The challenge of SDN in a technical sense is addressing this natural trade-off between the explicit control of connectivity that would literally change everything online, and the challenge of scaling central control to manage all the connections. Right now, for all the hype and crap to the contrary, we’re not meeting that challenge.
I’ve postulated that the solution to the problem of SDN is to break “the network” into two layers. Up top we have an SDN layer that’s highly agile and based largely on software processes that are largely (but not necessarily entirely) concentrated at the network edge. This layer runs on top of a transport infrastructure that is fully connective and reliable, offering the same relationship to the higher SDN layer as the data-link layer has with the network layer today. The goal is to strip requirements for resiliency from the top SDN layer to reduce issues of scalability. You’d then create “user services” by manipulating only higher-layer SDN paths.
In many cases, we could use this structure without being per-flow in our thinking. Collect all the workers in a facility by job classification, so that all workers in a given class have the same application access needs. Make an access subnet out of each class. Now collect all the application components for each application you run in a data center subnet, per application. To build a WAN, you now drive an SDN connection between each access subnet and the data center subnet for the applications it needs.
For an Internet of things, we can have an access subnet that contains the process sensors or other telemetry sources associated with a given application, and we can have our data center subnet for applications. The same concept would then let us connect one to the other. What we’ve done is to create a new service model using the natural agility of SDN. If we have carefully placed “facility switches” in our SDN layer, there are only minimal places that have to be made flow-aware, and only minimal scaling of central control processes is needed.
This is what we need to be doing with SDN, people. We need to think of the ways that controlling forwarding explicitly lets us build service models that better suit present and evolving applications than the permissive connection models we have today. This is what “Northbound APIs” on OpenFlow controllers should be doing, what Cisco should be (and, I think, sort-of-is) doing with NCS. I also think other SDN players are seeing some of this same stuff. We’re just not hearing about it, because as always vendors will expose what sells the most the fastest and not what the future really holds. It’s up to the media, analysts, bloggers, and people who read the industry news to demand that we get more depth on the future so we can better judge the present.
Service models are in a very real sense the only thing that matters in SDN. If we can’t generate new and useful service models with it, then the only value SDN might offer is slightly lower capital cost on equipment. “Slightly lower” because I don’t think that we can replicate an IP or Ethernet network at current scale with both lower capex and opex. We’re building SDN for a limited future if we don’t think beyond our current service limits. Looking for something to beat your vendor up on? Think service models.