Last week, I read a blog by Tom Nolle at CIMI Corporation that really hit the nail on the head. Mr. Nolle wrote that SDN and NFV implementations are limited by the lack of a “fully baked” signaling system, à la SS7. I couldn’t agree more — SDN and NFV should use signaling to be most effective in controlling and managing networks. In fact, I’d argue that all modern IP networking could operate more efficiently with a signaling system.
So here it is — I believe that signaling in SDN and NFV architectures will soon be required. As Nolle noted, “when you try to build extensive SDN topologies that span more than a single data center, or when you build an NFV service over a practical customer topology, you encounter several key issues. Most can be attributed to the fact that both SDN and NFV depend on a kind of ‘out of band’ connectivity.”
Before we go further, we first need to clarify signaling for real circuits, virtual circuits, and signaling for a specific use. For real circuits or pathways, we currently enjoy IGPs — such as OSPF or IS-IS — that maintain our local area network systems. We also have EGPs for managing inter-authority pathways. So it’s safe to say we have a system in place to learn pathways in the public Internet.
The dilemma. There are two public Internets — IPv4 and IPv6 — and neither share signaling information with each other. Stateful, brittle NAT64 devices connect these two networks, but without any support for signaling between the network boundaries. There are also millions of private networks that connect to either IPv4 or IPv6 networks through stateful NATs and also do not share signaling support.
So in actuality, our current network routing systems do not properly signal. Since many deem this unfixable, SDN/NFV use cases are adding proprietary systems of overlay or tunnel connections between various networks. Both of these solutions gather connectivity and performance information for each tunnel in a collection of tunnels to create yet another closed network.
It’s safe to say there is no network information exchange between IPv4 public networks, IPv6 public networks, private IP networks and subnetworks, or SDN/NFV implementations. And the signaling system I’m speaking of will need to work across and between any combination of these networking solutions.
Applications Can Do It, Why Can’t Networks?
With all this information, it’s ironic that the application makers seem to have no problem signaling across all of the above networks. By using application layer mechanisms involving sessions, cookies, tokens, dynamic DNS, and other techniques, applications are now seamlessly moving authenticated sessions from one network to another. Applications are also re-routing traffic, performing load balancing, adding authentication, and supporting mobility without any network involvement.
Think about cookies and Single Sign On tokens. These application layer mechanisms are truly showing us the way. They help make network edges smart enough to insert metadata, process metadata, and remove metadata once per session to signal for network resources on a session-by-session basis.
The answer. Nolle writes that “even the operators who say they’ve seen the early signs of the signaling issue say that they see only hints today because of the limited scope of SDN and NFV deployments.” He believes we need an SS7-like network for virtualization, and I completely agree — signaling should be session-based like SS7.
Signaling should take advantage of all existing networks, but pass through NATs and network boundaries. Insertion of signaling information should only occur once in a session and signaling should only be inserted if the network is sure it can be used and removed by upstream network equipment. The requirements for an end-to-end signaling system include:
- Must be in the payload, to play nicely with decades of middleboxes that have been deployed
- Must support hop-by-hop authentication, to avoid the pitfalls associated with source-based routing
- Must be inserted only when upstream equipment can process the information, lest applications will be broken
- Must pass through any number of NATs, tunnels, and networks
- Must speak the language of services and not IP addresses, to be available to IPv4 and IPv6 unilaterally
- Must be included only as needed (often just the first packet), to avoid the tax imposed by tunnels and overlay networking techniques
Like any signaling protocol, the “backward” signaling is as important as the forward signaling. If networking equipment had information about the already established sessions and sent metadata backwards, each participating network element could learn about conditions on the selected pathway and route future sessions differently. Once again, this signaling metadata could be inserted in the payload, and removed by a participating network element, transparent to the end application.
One last and vital requirement for session-based signaling is that routing equipment needs to be session-stateful. We need to force a bi-directional flow to go through the same router — the NAT boundaries between networks are guaranteed. I say that because it is reasonable to assume that a session-based signaling system could make NATs invisible, just as IP networking makes MAC addresses invisible. A real life, scalable example is local number portability. The PSTN address space has both real numbers and virtual numbers, and most phone calls are signaled with both addresses. The real numbers do the actual routing. There is no way data networks can’t use similar models to communicate and force bi-directionality where needed.
There is a networking revolution coming as our tens of millions of unconnected IP networks start to communicate through signaling at the session layer. And with it is the hope and promise for renewed innovation in networking.