Kill the Beast: Why the Seven-Layer Model Must Die

Reviewing a manuscript for a book on service-oriented architecture (SOA) recently, I ran across a section where the author described SOA-based interactions using the traditional seven-layer model for networking.

My blood boiled.

I don’t mean to pick on this particular writer–everybody uses the seven-layer model–but it’s time to stop. We need to kill this beast.

Here are the main reasons why nobody should ever use the seven-layer model to describe modern networks:

• The model is wrong for today. It was created in the late 1970s as part of the Open Systems Interconnection (OSI) effort. Think how different networking was then: wide-area networks were the main story, not LANs, and connecting mainframes to dumb terminals was still important. Why would anyone expect that an architecture invented for this world would still be relevant today?

• The model was never right. Born in an international standards committee, its seven layers reflect politics as much as technology. The Session layer, for example, exists because the Germans insisted on having a place to put something called T.62, their pet protocol. The services this layer is meant to provide just don’t exist in modern networks. Similarly, the bottom three layers–Physical, Data Link, and Network–were intended to reflect the three-layer structure of the then-new X.25 protocol for wide-area networks. The slightly more modern idea of a connectionless internetworking protocol like IP was seen as heresy by the model’s creators, and so had to be shoehorned in later over their vociferous objections.

• Most people don’t really understand the model. This is especially true of the upper layers. I spent several years as chair of the US implementer’s group for the OSI upper layers (a group that’s roughly analogous to today’s Web Services Interoperability Organization, WS-I). A frequent topic of conversation at our meetings was how little non-specialists grasped the function–and the lack of value–of these layers. For instance, the Presentation layer exists to allow negotiating the format of exchanged data. But who needs to do this? The reality is that either some a priori agreement is in place or the negotiation is so simple that no real protocol exchanges are required. Similarly, I’ve lost count of the number of "authoritative" networking books I’ve seen that describe the purpose of the Session layer incorrectly. Unless you’ve spent time deep inside this arcane world, it’s all but impossible to grasp what these layers are really meant to do.

The obvious question, of course, is what to use instead of the seven-layer model. Yet the answer is equally obvious: we live in a world ruled by TCP/IP, and so we should use the layered structure these protocols imply. One way to think of this is to view networks as having four layers.

The middle two layers, here called Transport and Network, contain TCP and IP, respectively. The bottom layer, which I’ve called Subnetwork, includes all the various ways we connect machines: Ethernet, frame relay, and everything else. Each of these approaches has its own set of internal layers, and so it doesn’t make sense to define one layered structure that applies to all of them. Similarly, the top layer, here called Application, may actually contain assorted layered structures depending on exactly what protocols are being used. Plain old FTP sits right on top of TCP, for instance, while an RPC-based protocol will probably have at least one sub-layer. As with the bottom of the stack, it’s not possible to define a single layered structure that accurately describes all application protocols. (One thing we can be sure of, however, is that none of them needs a Session layer.)

Earlier in my career, I spent several years giving seminars on OSI. Since I once helped spread this false gospel, I feel a special responsibility to root out its remaining pernicious effects. Please join my campaign. Together, we can kill this seven-layered beast.

• Kill the Beast: Why the Seven-Layer Model Must Die
   
• David Chappell's Weblog
   
• David Chappell’s Upcoming Speaking Schedule
   

David Chappell’s Weblog

Like everybody else, people who work in technology can get caught up in fads. Weblogs, for example, sometimes bloom like algae, then just as quickly die. Yet blogs can be useful, both as an effective way to engage in non-real-time dialog with others and as a low-overhead mechanism for thinking out loud.

Accordingly, my blog is now live. You can find it at www.davidchappell.com/blog.

David Chappell’s January/February Speaking Schedule

I’m spending several weeks this winter on a European speaking tour. Each day begins with a keynote presentation on the Longhorn version of Windows, covering Avalon, WinFS, and Indigo, followed by various other talks at each stop. The dates and cities are:

January 26: Oslo, Norway

January 27: Copenhagen, Denmark

January 28: Helsinki, Finland

January 29: Geneva, Switzerland

January 30: Budapest, Hungary

February 2: Warsaw, Poland

February 4: Ljubljana, Slovenia

February 5: Zagreb, Croatia

February 6: Milan, Italy

February 9: Lisbon, Portugal

February 10: Dublin, Ireland

February 11: Ghent, Belgium

David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. Through his speaking, writing, and consulting, David helps information technology professionals around the world understand, use, market, and make better decisions about enterprise software technologies. David has given keynotes at conferences and in-house events in the U.S., Europe, Latin America, and the Middle East, and his seminars have been attended by tens of thousands of developers and decision makers in thirty-five countries. David’s books have been translated into ten languages and used in courses at MIT, ETH Zurich, and other universities. His consulting clients have included HP, Microsoft, Stanford University, and other technology vendors and users.

©Copyright2007 David Chappell and Associates
All rights Reserved.