I read a piece this morning, a paper from a vendor, who’s promising that just because SDN comes along, Levels 4-7 won’t get commoditized. We’re suffering here again by a victory of hype and popular usage over technical accuracy, and so it’s time we took a look at the whole “higher-layer” or Level 4-7 picture to sort out what SDN and NFV might mean there.
Back in the 1970s, the “Basic Reference Model for Open Systems Interconnect”, shortened to the “OSI Model” came out. This model established a seven-layer structure that was based on the notion that a given layer saw the network only through the services of the layer below and that each layer was simply a user of that lower one, used by the one above. The progression of the first three layers is simple; physical media, data link, and network. Above are the transport, session, presentation, and application layers.
The first stumble we find in popular discussions is that only Levels 1-3 are present in the network; all the higher layers are end-to-end. Thus, fairly speaking, there could never be any impact of SDN on higher layers unless it stepped outside the network. The facts never constrained a good marketing yarn, of course, but in this case there’s a reason why we’ve taken to implicitly violating the very model we reference.
The bigger problem for the 4-7 story is that your chances of encountering 7-layer traffic in the real world are probably about the same as being struck by lightning while kissing a Hollywood star/starlet. The Internet protocol suite never really established formal structure above Level 4 (TCP and UDP) and nothing based on the OSI suite really deployed at all. But it’s the reaction to this reality that has created the current higher-layer mythology. Two specific developments, in fact.
Development number one was that the lack of a formal higher-layer structure made it difficult to distinguish between application flows to the same transport port. As it became clear that certain applications demanded different QoS, the lack of a fixed structure of headers to look at meant that you had to inspect the packet payloads to try to classify what you had. Hence, DPI. DPI builds application awareness into the network, but not through “higher layers” but by accommodating as best as it can the fact that there aren’t any.
The second development was that some network vendors added their own layers above the TCP (Level 4) process. These “overlay networks” do impose a formal structure and add formal headers, so traffic within one can actually be manipulated by higher-layer processes. However, there really aren’t three additional layers up there; there are typically only one and in theory you could stack them up like playing cards as deep as you liked, presuming you could tolerate the header overhead.
DPI and overlays are different potential solutions to the common problem of application-specific handling. With overlays, the endpoints can classify traffic and tag the stuff with a header so that everything that has to be recognized can be. Without them, you dig into the packet content to look for structural patterns that would identify traffic.
SDN is different from “OSI” networking in that in theory you could define forwarding rules to accommodate as many layers as you like, and you can make the network sensitive to the higher layers even though OSI says that’s a no-no. Thus, far from commoditizing higher layers, SDN could actually empower them. However, it’s not enough in itself.
If you have traffic with a uniform header structure, a layer-modeled conforming packet, you know where to look for the signals that divide application traffic types. If you have any traffic at all that doesn’t conform to the header structure you have the risk that the data payload of those packets will appear to be headers, and you’ll mishandle them as a result. Thus, the most useful presumption for higher-layer traffic is that you create some sort of overlay network and tag all the packets with the proper headers.
Tagging packets is easy if they’re your packets, and if you know they need to be tagged. Obviously we have a zillion apps out there that don’t know anything about higher layers and so won’t do the tagging. A good approach then would be to apply DPI at the very edge and examine packets meticulously to be sure you identify them correctly, then tag them so you don’t have to repeat this potentially complicated and delay-generating process at every point in the network where you want to provide discriminating handling. You can apply edge-DPI-based tagging to any stream that has enough information to reliably classify stuff.
The point here is that you can’t offer higher-layer handling without some explicit process of classification, which means that the data sources have to be equipped or augmented to provide that before the network can use it. Otherwise you have to continually examine stuff at every point, which will likely generate way too much lost time and resources.
NFV enters into this picture not so much as a handling option (an NFV-based switch or router would have the same basic constraints on headers and DPI as anything else) but as a way to classify and as a source of classified traffic. You could host DPI VNFs in useful places to classify stuff when you needed it, and you could also use overlay networks to separate service-plane traffic from the intra-function traffic that should never be exposed to direct user interaction. It helps higher-layer, and could also help justify it.
So the point here is that higher-layer handling could be done very flexibly using DPI and SDI, better than we’d normally do. The question is whether we can create a “service model” to describe how this kind of handling would work so it could be done cooperatively through a network. Even in SDN, you can’t forward packets unless all the handling nodes have a cohesive idea of how the whole thing is supposed to hang together. That model, sadly, is another of the applications of those missing “northbound APIs”.