The question of how the network of the future could work, how SDN in particular could be introduced and managed, needs to be answered. What’s really interesting is that it might have been answered already, and that not only are we not running to explore the solution, we might be running away.
One of the goals of SDN (at least the OpenFlow version) was to substitute central and explicit control over forwarding tables for adaptive protocols and behavior. An SDN controller is expected to “rule” on explicit requests for routes or to set up default routes based on some policies. The challenge with this is that it’s obvious that central control of a very large network with a single controller begs major scalability issues. The solution so far has been to apply SDN to relatively limited domains and to rely on legacy interworking techniques to connect these domains. But that limits SDNs benefits. Is there a better way?
SDN displaces adaptive routing. Could it be that there were developments in the past that could be considered in deciding how SDN networks might work? Remember the line “Return with us now to those thrilling days of yesteryear?” Well, it’s not the Lone Ranger here, but maybe the “Lonely Protocol” I’m talking about. Let’s go back in time to the late ‘90s and early 2000’s. We were in the age of frame relay and ATM, and startups like Ipsilon, and we were struggling to figure out how to make connection-oriented protocols work with IP. Along came a solution, what was known as NHRP or the Next Hop Resolution Protocol.
“Call-oriented” services like ATM required that a connection be made by setting up a virtual circuit to something specific. If we imagine an IP user at the edge of a frame relay network wanting to do an IP session with another such user, you can see the problem. Both users are on the network but the network doesn’t support the normal IP discovery processes. The standards (in the IETF) at the time even came up with a name for this kind of network—an “NBMA” or “non-broadcast multi-access” network.
NHRP was a solution to the NBMA problem. You had a “next-hop server” that was a lot like a DNS. The server would provide an NHRP agent at the edge of an NBMA with the network address (in the NBMA) of the “next hop”. The agent would then call the designated partner agent, make the connection, and we’d have a packet path. Even if the network were made up of multiple subnet-NBMAs we could run NHRP at each border to find a way across.
No, we’re not going back to ATM here, but consider for a moment the question that SDN should be considering; is an SDN network something like an NBMA? There are no forwarding paths in the network in its initial state, right? There’s a “server” that can establish what needs to be done for a given packet at a given node, but no systemic notion of destination. Could we adopt NHRP principles at the edge of an SDN network to establish pathways for packets based on source/destination?
This probably seems like a lot of work, going to next-hop servers and all. Remember, though, that we go to DNS servers to decode the URLs that start most web activity. We also go to an SDN controller to get forwarding instructions, and this on a per-packet basis. At the very least, something like NHRP could be used for high-value services, and it could easily be used in carrier Ethernet, VPNs, and so forth. Could it scale to the Internet? As easily as SDN could without it, and perhaps more easily.
An NHRP-ish concept could in fact be combined with DNS. We could get an IP address the way we do now when we decode a URL, but we could also get routing information, almost like the source-route vector that was a part of frame relay and ATM and also a part of MPLS. Suppose the DNS server returned to us an ordered list of NHRP-ish domains that we had to transit to the destination. We’d then move the packet to the edge of the first domain, let it get through itself as needed, and then do the same with the rest.
With this sort of model (and again I stress I’m citing this as an example, just something to start discussions) we have a mechanism for inter-SDN-domain linkage. We also have a way of using SDN and the model to improve security. The enhanced DNS-and-NHRP stuff could also be used to validate source address, so that packets can’t be emitted into the network unless they’re part of the “source tree” that they should be given their address. You can also quench sources at the source only, by telling their home domain not to connect to them.
This would work for SDN, but it would also work for any tunneling or “connection” protocol as well, at any of the OSI levels. We could tunnel through something Ethernet-like, tunnel Ethernet through something IP-like, tunnel both through SDN. Add in the microservices concept that I talked about yesterday to handle control-layer and management-layer interactions, and you could compose a service protocol from bare connectivity, which is what SDN provides.
There are obviously questions about how we’d set up a DNS-like hierarchy for this model, and how we’d integrate it with current IP, but I think you can see that we could route “normally” where we have adaptive discovery and using the new model where we don’t. There may indeed be scalability issues but those wouldn’t be any worse than we face with DNS now, and that we’d face with SDN controllers in the future.
The net of all of this is that we’d establish a model of “destination finding” that isn’t dependent on discovery, and that we would be able to apply that method to any technology that has forwarding tables that allow for packet movement and delivery. That includes “connection-mode” stuff like RSVP/MPLS and OpenFlow SDN. We can even fit the model to legacy technology.
NHRP has been around a long time so you might think that all this is in place and ready to be used. Well, while researching it I found a note that said Cisco was pulling NHRP support from its products. It seems to me that we should be looking instead about how either NHRP or its principles could support SDN. Of course, Cisco’s not a big fan of a revolutionary SDN transition.
I know a lot of people besides Cisco are going to tell me this is an awful idea (or at least they’ll think that!) and that we should be using the pure notions of IP. I don’t have a problem with that assertion. If the industry wants IP forever, go for it. The problem is that we’re saying we want “new” technologies and benefits. If we plan on doing everything the old way, we have to square that attitude with the notion that we’re going to do something revolutionary with SDN.