|
David Chappell: Kill the OSI Model. "Everybody uses the seven-layer model–but it’s time to stop. We need to kill this beast." David suggests a 4-layer model consisting of (top down): Application, Transport, Network, Subnetwork.
I won't try to defend ISO's OSI model as-is, but I think David's model oversimplifies some important discrete technologies, some of them related to hardware. (Remember, we still ened hardware!) The OSI model's Physical Layer describes the cables, connectors, and electrical signals. The Data-Link Layer typically describes "frames" such as those of Ethernet or ATM which are built upon the physical-layer electronics. I don't know of any important network technolgoy that doesn't have a frame structure. This is where, for example, we get MAC-level addressing and CRCs in Ethernet. The OSI Network Layer adds end-to-end datagram (i.e. connection-less) communications through a routing infrastructure. This is where the Internet Protocol (IP) and IP addresses are introduced. The TCP part of TCP/IP, which supports connections, sits atop this in the Transport Layer. If you're an engineer working at the Physical or Data Link layer you certainly care about the distinction, so I can't support David's desire to combine OSI's lowest two layers.
To some extent, the upper-layer problems David describes are due to the fact that some of the OSI terminology has been co-opted in the same way as the term "hacker" has been redefined by those who have entered IT since...well, since it became known as IT. For example, HTTP is the HyperText Transfer Protocol, but it's generally referred to as a Transport protocol. Well that's a problem now, isn't it, since HTTP typically sits atop TCP, which is also a transport protocol. To make matters worse, TCP supports a form of state management: a connection. Yet the higher-level HTTP doesn't make use of TCP's connection IDs, so it is itself a stateless protocol. Just think of all the effort we go to to re-create the state management which could just as easily have been inherited from TCP by HTTP. We've got to use cookies, session IDs in URLs, etc. It could have been a whole lot easier--the Web could have used TCP connections as sessions, just as FTP and other protocols do.
So I agree with David in part: The OSI model doesn't accurately reflect the way our communications systems are build. But OTOH, I don't think his short-stack version represents it any more accurately. [BTW, I, too, used to teach the OSI model, but unlike David, I think it was a huge improvement as a way for humans to describe, specify, and build networks. I still find it very helpful in explaining the segregation of protocol responsibilities, even if the definitions aren't consistent across all protocols.]
Posted Tuesday, January 13, 2004 12:19:43 AM 
|
