Peeling The Onion Layer By Layer

Dante's picture

In a recent post on his blog (Twilight in theValley of the Nerds), Brad Casemore brought up some interesting questions about the possibility of extending a Software Defined Network (SDN) as defined in the Nicira announcement to deliver L4-7 Network Services.

While I am not aware of Nicira’s future plans, there are a couple of considerations that I'd like to offer, in an effort to clarify why we so stubbornly point-out the difference between layer 2/3 and layer 4/7; why the two things are quite different; and why they each will require different approaches even as we move to a software-defined world.

There are several ways to look at the difference between layer 2/3 and layer 4/7, but the fundamental point is that an architecture designed to support packet forwarding (layer 2/3) can not be simply adapted or extended to support flow processing (layer 4/7) and vice versa.  Making that assumption would almost be like claiming that a switch or router could be interchangeably used as a server or the other way around.

An interesting way to validate the statement above is that companies like Cisco with obvious dominance in the layer 2/3 market have not had any unfair advantage against newcomers such as F5, Riverbed and others.  Likewise, these companies have not been able (and they have not even attempted) to get into the routing or switching markets despite having been very successful in their respective layer 4/7 segments.

Layer 2/3 is really about routing and switching, i.e. it's about taking packets (or frames) from one end of the network (typically a port, either virtual or physical) to another one.  This means that architectures and products built to perform this type of function are optimized to process each individual packet, and have no ability to reassemble flows. Forwarding decisions and policies can be flow-based, but flows are never reassembled inside the network.  As I was putting together this note, Greg Ferro posted an interesting blog on the differences between switching (aka bridging), routing and “flow forwarding”, which is basically the ability to create flow-based policies to forward individual packets.  Vendors that create solution for layer 2/3 packet processing focus on providing high forwarding throughput (per packet), low latency (per packet), traffic engineering and isolation and many other similar capabilities. Nicira’s NVP (today) follows this model.

Layer 4/7 refers to a set of functionalities that require the reassembly of packets into flows and it’s typically implemented leveraging general-purpose CPUs. The actions taken by layer 4/7 appliances are based on the content of the flows and they may require sophisticated processing of the content itself. Layer 4/7 services look much more like an application than a network function.  We refer to these functionalities as (layer 4-7) network services simply because they have historically been provided by networking vendors and managed by the networking team.  If we could rename them today we would probably stick the word “application” somewhere in there, even though they might still be managed by the networking team.  When you design a solution to deliver layer 4-7 services you focus on how to scale compute capacity that support the service and you want enough flexibility to be able to handle the sophisticated operations that need to be performed on each flow.  Embrane heleos (today and for the foreseeable future) follows this model.

What Nicira and Embrane are doing is not changing the fundamental difference of what happens in the network or at the application layer, but each of us is focusing on delivering a very similar set of benefits at different layers of the stack.  Many customers will choose to evolve their entire networking stacks (from layer 2 to layer 7) to a more software-defined solution, but others will go through the process in phases, and the order with which projects will kick-off will be different on a case-by-case basis.  Some customers will choose to evolve their layer 2/3 infrastructure first, others will choose to begin from the layer 4/7 piece.  A similar message that both Embrane and Nicira have used in their launches and marketing material is co-existence and the ability to interoperate with legacy infrastructure, which is traditional layer 4/7 appliances for Nicira and traditional routing and switching architectures for Embrane.

This is what makes both Embrane and Nicira very cool, very much needed and extremely complementary :-)



On your point about “Layer 4/7 refers to a set of functionalities that require the reassembly of packets into flows and it’s typically implemented leveraging general-purpose CPUs.”

While I agree many networking applications can be handled by general purpose processors, there are some that still require specialized processing (network processors) to scale to high throughput and low latencies. Typically, such applications are deployed at data center edge (WAN edge) rather than server edge and handle 10s of Gbps of aggregate flows.

One such example is WAN Optimization for Data Center Interconnects (which is what we do at Infineta). WAN Optimization requires not only processing flows at L4 and higher layers (e.g. TCP optimization), but also process the content of the flows (deduplication/compression). General purpose processors would add 10s of milliseconds of latency (which is OK for branch, but not for DCI) and won’t scale to 10s of Gbps. Network processors provide a good balance between general purpose processors (performance) and ASICs (flexibility). You can still achieve the flexibility of SDN as long as the network application devices are programmable through APIs.


Ashish, multicore technologies is evolving very fast and there are now some disruptive companies in the Cloud space to provide high performance L2-L4 network services on general purpose processors (thanks to new x86 architecture). Able to provide low network levels to what we call here Applications (L4-L7). Also (from our view) compatible and programmable with Nicira, Embrane and others...
Wait for the MWC for our announcement or follow us on Twitter (@6WINDSoftware)

If you are going for finest contents like I do, just
visit this website everyday because it presents feature contents, thanks

Add new comment