In its infancy, a war to define the protocols of the Internet was fought between geeks and governments. Two standards, TCP/IP and OSI sought to provide a usable, structured design for the computer networking efforts which would eventually make our global Internet possible.
Despite their correspondences, significant technical differences exist between TCP/IP and OSI which stem from their design philosophies and which are far from simplistic. I admit at the outset that I've never worked with OSI, so the technical information presented is drawn mostly from the sources cited and my TCP/IP knowledge.
A technical audience should note that this discussion is based upon the reference models, rather than the protocol stacks as such. However, the issue of "TCP/IP versus OSI" is far more than just a technical discussion. It is a historical demonstration of what occurs when two opposite design philosophies are used to develop a protocol, and is far more a political and philosophical than a technical issue, and perhaps serves as a lesson in why politics makes for bad technical standards.
"So the Internet perspective is implement it, make it work well, then write it down,
whereas the OSI perspective is to agree on it, write it down, circulate it a lot and now we'll
see if anyone can implement it after it's an international standard and every vendor in the
world is committed to it. One of those processes is backwards, and I don't think it takes
a Lucasian professor of physics at Oxford to figure out which."
-- Marshall Rose, "The Pied Piper of OSI"
On OSI:
OSI's major contribution to networking theory is in its distinct separation between three fundamental concepts:
- 1. Services: A service defines what a layer does, but abstracts the details of implementation from higher levels in the protocol stack.
- 2. Interfaces: The interface makes the layer available to higher layers. It defines the conventions of communication - what to send and what to expect, but also does not deal with implementation details.
- 3. Protocols: These are private methods of implementation which the higher layers have no access to or knowledge of. Thus, they can be changed (i.e. to allow adding support for a new hardware technology) without altering the basic functioning of higher layers.
It should be rather obvious to someone with a computer science background that these concepts are extremely similar to the design philosophy of object-oriented programming. The layer possesses a set of service methods which can be invoked through the layer interface to initiate internal protocols.
This similarity also means that OSI would gain some of the main advantages of object-based design: data encapsulation, modularity and reusability, and access protection. Because the protocols themselves are hidden, they can be changed as new and improved technologies become available, without compromising the integrity of the system, in a way transparent to higher layers (to say nothing of the end-users!).
We might in hindsight consider that this was a good idea. Unfortunately, the designers of the OSI model built the reference model before the protocols existed and did not understand from an engineering perspective where various pieces would optimally fit. This is because the majority of the protocols they were designing this for hadn't even been invented yet!
On TCP/IP:
TCP/IP's differences from the OSI model stem from its design requirements:
It should be clearly noted that TCP/IP has no provisions for the object-like separation between service, interface, and protocol of the OSI model. Whereas OSI was an abstraction created before technologies existed, TCP/IP simply described the existing hardware from an engineer's perspective and gave little thought to ensuring the model made sense at a higher level. The layers fit the technology perfectly, of course, but dialogue was impossible with other non-TCP/IP-based networks!
The main differences between OSI and TCP/IP exist in the higher layers (5-7) and in the Network layer (3). OSI supports connectionless as well as connection-oriented protocols at the network level (again, due to its inherently abstract design), but only connection-oriented communication at the transport layer. TCP/IP is connectionless at the network level and supports both modes at the transport level, where the user, who often has little knowledge of low-level networking hardware and protocols, has to select how his connection functions.
Problems with OSI
OSI was a poor performer in implementation, and there are definite flaws in the protocols. Flow control is a problem at every layer and error control must be implemented all layers as well. Network management is problematic and was actually omitted from the original OSI model. Semantic confusion about the Presentation and Application layers created so many major headaches that data security and encryption were eventually taken out altogether!
OSI was killed off because:
- Early slow and bug-filled, unusable implementations ruined its public image.
- OSI was thought to originate with the European Community and the U.S. federal government.
- Its probable market for use was proprietary. TCP/IP was bundled as part of Berkeley UNIX and was free.
- OSI is labyrinthine and full of almost bureaucratic levels of unnecessary complexity.
- The seven-layer model was somewhat arbitrary, and was basically done in an attempt to wrest control away from IBM's 7-layer SNATM protocol to a world standard controlled by a neutral organization (the ISO) rather than by a single corporation -- not to simplify actually using the model!
Problems with TCP/IP:
Far from blameless, TCP/IP has some problems as well, the primary one being that it speaks only its own language:
- It can't be used to intelligently describe another type of protocol stack (like SNA).
- Its network layer is more of an interface than a true layer of its own.
- There is no distinction between the Physical and Data Link layers. This is a poor choice from an engineering standpoint.
- Many of the original protocol implementations were hacks (in the "oldskool" sense, of course) with very limited usefulness and arbitrary constraints based on hardware limitations or on simplifying the coding task.
A Point of Networking Zen:
- The terminology of the OSI reference model is widely-used to describe behavior and design of networks.
- The implementations of that model are basically crap.
- The protocols of TCP/IP are generally well-thought-out and widely-used.
- Those protocols are usually best described by the design terminology of the OSI reference model.
...At these words Joshu was enlightened.
sources:
- Tannenbaum, Andrew Computer Networks: Third Edition Prentice-Hall 1996.
- http://www.cellsoft.de/telecom/tcpiposi.htm
- "Forcing the TCP/IP suite into a non-standard 5-layer Model"
(http://mike.passwall.com/networking/netmodels/tcpip5layermodel.html)
(
node what you learn)...
and someday, suddenly, boring technical knowledge you were forced to memorize becomes meaningful!