The Bifurcation of the Network: Flows versus Messages
#SDN The network is naturally stratified because flows are not messages, and vice versa.
Once the initial thrill of SDN abated to a dull roar, the issue of what to do about higher order services (layers 4-7) was raised. Thus far, we've seen some fairly expected responses with notions like service chaining and SDN application service insertion into the controller.
What's been missing, however, is a discussion on why SDN needs to address higher order services differently in the first place. The reason is fairly simple: the network is naturally stratified. There's a clear delineation between layer 2-3, aka "the network layers", and layers 4-7, aka "the application layers". If you look around at market segmentation, at product descriptions, at marketing, you'll quickly see this clear line in the sand between the two network stacks that make up the full network stack.
The reason for this is fairly straightforward; at layer 4 in the traditional OSI network model the focus of the protocols and of the layer itself begins to change from packets and flows to connections and messages.
This differentiation in the stack itself turns out to be fairly important when you start looking at actual function of services at given layers and, perhaps more importantly, resource requirements.
SDN Flows versus Messages
Current thoughts on SDN propose such a model; based upon flows these transactions would be directed to the proper location (i.e. an available web/app service) and then they'd flow back to the end user without necessarily traversing any infrastructure capable of inspecting the response and taking action, if necessary. This is necessary because of the need to route traffic based on layer 7 data, particularly in HTTP-based applications. This is increasingly true for operational architectures supporting APIs and frequent application releases where differentiation between versions (and client types) as well as authentication and authorization is carried within the application layer message (often in the HTTP headers or the URI).
A layer 4 flow is able to differentiate on IP address (important) and port (also important). But it cannot differentiate between version 2 and version 3 of an API, nor can it extract an API key from a message to ensure the request should be processed. That's because that data is carried in the application data, in the application protocol headers, and these layers are not parsed nor processed by layer 4 and below devices. The reason for that is simple - resources. Application layer processing requires a great deal more compute resources than packet processing. The foci of the two different "stacks" are completely orthogonal in many respects: one is focused on rapidly processing fixed data packets while the other on intelligently process variable data messages. Each is important in its own right, and the emerging focus on layer 4-7 services within SDN architectures is partially borne of that recognition.
Programmable layer 7 data path elements are required as part of a larger SDN effort to realize basic layer 4-7 service capabilities, i.e. parsing, extraction, inspection and action of messages, not packets. Service chaining certainly provides a solution as it attempts to enforce a route traversal through infrastructure services on the ingress and egress, but such solutions are currently still being defined and in most proposed cases they, too, lack the visibility into messages required to enable a rich, programmatic (and therefore flexible) service environment.
There still remains a significant disconnect between packet-based and message-based services in the SDN realm. While packet-based L2-3 and even L4 services fit nicely into a standard SDN model, there are still issues at the application layers. The natural inflection point in the network stack where the focus moves from packets to messages, from I/O to compute, from stateless to stateful,remains problematic. The same data path element, i.e. a switch, router, or firewall, capable of managing a high-volume of both configuration change and traffic does not have the appropriate compute or memory resources to manage a high-volume of messages while maintaining sessions, inspecting messages, and executing logic.
It is encouraging to see solutions being proposed and discussed. But in order to choose the best direction - the one that will enable SDN to seamlessly provide both packet and message-based services - we need to understand why there is a need for both in the architecture.