on 11-Feb-2013 03:00
"If you look at the standard SDN model, [Layer 4-7 services] are applications that can basically run on the [SDN] controller platform. But that's not the only way to do them. We'll hear about different approaches. Network services for SDN are going to be a big story in 2013."
-- Brad Casemore, "Networking outlook: Controllers, Layer 4-7 will roil SDN 2013 market" [emphasis mine]
Since SDN became the darling du jour of the networking industry, there's been a lot of head nodding and ancillary mention of L4-7 services eventually becoming part of the overall fabric. What there hasn't been is a lot of discussion on the challenges inherent in bringing those services to bear in what has become the de facto standard mode...: a centralized controller responsible for directing the flow of packets throughout the network.
That's challenging, because as you move up the network stack there's a natural evolution that occurs. You move from directing packets to managing flows, and managing flows requires a completely different set of features. That's because the closer to layer 7 you get, the more stateful the network necessarily must become. It can no longer act on individual packets; it must aggregate those packets and it must do it often - far more often than is presupposed when working at layer 2 and 3 of the network stack.
John Giacomoni said it well when he explained in a recent post, "Beyond SDN Fabric: Complex problems require L7+ SDN technologies":
“To implement even basic load balancing with OpenFlow the majority of packets, and all ACKs in particular, need to be forwarded to the controller so session flow state can be accurately tracked.”
Consider that in a router, about 1 in every 1 million packets needs to be forwarded to the controller. In a switch, that ratio is on the order of 1 in every 1 billion. For TCP that ratio drops to a mere 1 out of every 10 packets. If you climb a bit higher in the network stack to layer 7, you might as well consider every packet a candidate to be forwarded on to the controller.
The SDN model upon which most solutions today are based work on the assumption that most packets don't need to be examined by the controller. Thus they are able to scale and maintain wire speed while adding agility and programmability to the lower layers of the network.
A different model is required for Application Layer SDN to ensure agility and performance can be maintained while gaining the benefits of application intelligence and programmability. The SDN Network Fabric (layer 2-3) operates on the premise of centralized control and execution. The SDN Application Services Fabric (layer 4-7) must operate on the premise of centralized control and decentralized execution in order to scale without sacrificing the many benefits of stateful network devices enjoyed by current models of network architecture such as security-related functions, fault tolerance and isolation, and performance enhancing services.
Extreme Programmability: Enter LineRate Systems
As SDN matures, its focus will continue to move up the network stack, toward the application layers. The programmable, scalable services at the application layer comprising the Application Services Fabric are necessary to fully realize the benefits of SDN and software-defined data centers, particularly in environments where network function virtualization (NFV) is adopted as a strategy to achieve maximum agility. Network function virtualization requires not only the improved performance of today’s modern x86 hardware platforms, but software capable of scaling on demand while maintaining optimal performance and offering a high-degree of programmability for superior software defined control over the network.
Programmability is required for reducing operational costs through automation and centralized control, but it is also needed to enable customers to develop innovative, application-specific services that work in concert with SDN architectures. Critical to the success of these architectures are security, acceleration, optimization, and routing services at the application layers that are able to meet modern expectations of flexibility, scale, and performance.
LineRate brings a programmable, scalable platform to the Application Layer SDN table. Its platform is not only capable of scaling on demand and meeting performance expectations on commoditized x86 hardware, but it is highly programmable. In fact it is designed specifically to be programmed to execute purpose-built business and operational logic at high speeds. It's a proxy-based architecture, similar to that of F5 BIG-IP, and offers what I can only describe as "extreme programmability" as its core capability. Rather than insert lightweight rules into the data plane as is the operating procedure for SDN L2-3 fabrics, LineRate SDN Services act as independently operating service nodes that maintain the scaling properties expected of SDN solutions and of modern high-availability architectures, i.e. unlike the centralized SDN controller architecture, a decentralized execution model is fault tolerant even when maintaining state, a requirement for the Application Services Fabric.
As networks continue to become commoditized, it is the application layer services in an SDN that will provide organizations with the competitive advantage they need. A programmable data path is required for organizations desiring to roll their own services and it must be scalable and fast; organizations are unwilling (and rightfully so) to sacrifice performance. LineRate Systems offers such a platform and its addition to the F5 portfolio expands F5's continued leadership in application layer networking in both traditional and Application Layer SDN architectures.
"If you look at the standard SDN model, [Layer 4-7 services] are applications that can basically run on the [SDN] controller platform.".... this statement is plain wrong as applications don't "run" on the controller but are delegated to the various vswitch and gateways in the network.
John Giacomoni's comment is also misleading as he mixes multiple types of "flows" and "states" in his post and brings one to a false conclusion: as controllers need to know the state of the "flows" or path entries, they have no needs for instance for the state of the network (handled by the routing protocols) or the stateful flow entries of a firewall which would be local to that firewall instance only.
It follows that the model you are proposing "centralized control and decentralized execution" is exactly what is being currently implemented.
Glad to see F5 jumping on the virtual networking bandwagon and looking forward to more details on the integration / implementation with what is the best L7 proxy out there.
Thanks for your feedback! I think your point brings up a good point that we (as in the industry) are going to have to address - the differences (and just as importantly relationship) between the concepts of a "flow" at the network and application layers. State, too, will need to be better understood.
Interesting times we're in!
On distributed processing: the problem described in the post is if a switch does not have the intelligence to process application level traffic, it punts it to the controller and "... as an unintended consequence, the OpenFlow Controller has become a critical part of the data path – a job it was not designed to handle".
Absolutely true, but the fact the end point lacks intelligence to process the information is just bad design, not a problem with the model which calls for distributed processing.