A Tale of Seven Layers (More or Less)

One of the things we always hear about during SDN events is the SDN/optical relationship and the topic of “flattening” the network.  You’d think that network architects everywhere were out there with mallets, eyeing their infrastructure for possible points of attack.  Another thing we hear about is “Level 4/7 networking”, so apparently we’re looking for SDN to add layers above our three traditional ones and remove them below.

All of this references the venerable (mid-1970s) OSI model and its seven layers.  The model was developed to offer a reasonable way of dividing functionality in a network, to accommodate the fact that a route between two addressable points was necessarily the sum of a number of hops between nodes that handled traffic.  The model defines three basic functional groupings; the hop or subnet portion (layers 1 and 2), the network portion (layer 3) and the endpoint portion (layers 4-7).  As a rule it’s the network portion of the model that defines the user’s connectivity service.  Lower layers build infrastructure over which the routes are laid, and higher layers manage user flows between network endpoints and applications at those endpoints.  Read the documents and you’ll see this is (while simplified) essentially the picture.

One thing this means is that “the network” doesn’t route traffic above Level 3.  When somebody says they support “Level 4-7” what they are saying is that they are application-aware in handling, because all those layers share the same network address.  One thing that we’re doing, not just in SDN but in networking in general, is allowing for things like “class of service routing” of traffic that offers different routes between endpoints based on the needs of the application or services.  Being “aware” of higher OSI layers could facilitate this kind of handling.

The “could” qualifier here is based on two questions.  First, does the actual network (the lower layers) support class-of-service routing in the first place?  If you can’t do anything different for Application “A” versus “B” in a handling sense, what difference does it make whether you can tell them apart at the network service level?  Second, can you determine, by inspecting the messages at these higher OSI layers, what a given message actually is?  While we have Levels 4-7 in the OSI model, for example, the usage of these layers is opaque to the network by definition and so there’s no easy way to enforce standardization of how these layers are described or used.  For example, most Internet traffic really goes up to only Level 4 (TCP/UDP), and it’s perfectly possible to generate eight or ten or more layers instead of the formal seven, as long as the endpoints that are using the message stream agree on the handling.

The point here is that more layers on top of Level 3 aren’t necessarily useful.  If you want application-specific routing then you’ll want to explore the question of how applications can be identified and how special handling can be indicated per application, but otherwise you may be better off ignoring those higher layers.

The flattening stuff is also complicated.  Remember, the OSI model presumes that the “route” between two points is made up of a number of “hops”, each of which connect nodal elements that can examine the end-to-end addressing rules to get a packet through a chain of the hops to its destination.  So Level 1 and 2 are typically associated with node-to-node connectivity and endpoint connectivity is handled at Level 3.  What would you get by “flattening”?  It turns out it depends on how you do it.

In the days when data links were very unreliable, imagine for a moment the result of sending a packet over a chain of ten or twenty nodes/links without any error detection and correction along the way.  The endpoints could still recover from errors in theory, but if the error rate is high enough the chances of getting a packet across all the links successfully would reduce to near zero.  Lower-layer protocols are thus very helpful when you have low transport reliability, or when you have a large number of nodal hops between endpoints (because you’ll waste a lot of capacity retransmitting stuff end to end).  We can argue that the importance of Level 1 and 2 as discrete layers is indeed reducing so we might be able to push Layer 3 directly over the media.

The opposite may also be true.  We need Layer 3 to handle “nodes” that make intermediate decisions on packet routing where there are multiple possible exit paths.  In a traditional data network, one that only connects user endpoints, you can see that any node is likely to have to make that decision so you need Level 3 handling.  But look at the Internet for a moment.  We have broadband access, and that access “connects” us to the Internet.  The connection process is in most cases a kind of expressway between the home/business and the Internet point-of-presence.  If you send an email or IM or make a call or access a webside that happens to terminate next door, you’re not going to be routed out your access line and into the destination line out there at the edge of the network.  You’ll be hauled back to the Internet point of presence for the routing.  And as services move from being directly connected (like P2P) toward being services mediated through a server (social networking, email, content delivery, etc.) you’re really not connecting to a user endpoint at all.

In the metro area, where we have wireline access and wireless backhaul, we’re looking at a world that’s really not all that “connective”.  Everything that starts at an Internet access point ends up at an Internet service point before it goes anywhere else.  Why steer along the way?  You can create an opto-electrical pipe from the user to the Internet POP and that’s all you need.

What all this means is that flattening the network is possible.  The flattening is already happening, and in fact has been happening all along with Internet access so you don’t need SDN to do it, but you could flatten networks using SDN and it would be potentially beneficial because any OSI layer you can omit is a layer you don’t have to populate with devices and manage using expensive support resources.  But most of the drive behind flattening isn’t created by SDN, and so optimized metro networking to take advantage of flattening should include a careful architecting of the whole structure, not just the lower layers, so that you can really eliminate handling and error risk that would otherwise force you to keep the functionality you’re trying to flatten out of existence.

So where are we?  We have industry trends that can validate network awareness of additional layers of the OSI model.  We have industry trends that can validate an elimination of some of the traditional network-oriented (as opposed to endpoint-oriented) layers.  SDN can serve a useful mission by supporting either or both these sets of trends, but it’s not itself a driver nor is it sufficient in itself to re-architect the network.  We should expect to see either more-layer or flattened-layer advocates explain how their stuff works within the framework of real applications before we declare it to be valuable.

Leave a Reply