Computer networking reference models

To varying extents, architectures for computer networking have used conceptual models into which their mechanisms are mapped, the scope of mechanisms defined, and possible gaps in coverage. The best-known of these, the Open Systems Interconnection Reference Model (OSIRM), developed by the International Organization for Standardization (ISO) is indeed best known, but is, in practical networks, relegated to historical significance.

In contrast, the Internet Reference Model, which is far less abstract and indeed less formally specified, operates in a practical role, guiding but not controlling real-world implementations. It defines network activities into rough categories:

• Ways that applications talk to their peer applications, such as electronic mail message interchange defined by the Simple Mail Transfer Protocol(SMTP)
• Methods for moving bytes from network endpoint to network endpoint, such as the Transmission Control Protocol (TCP)
• Techniques for moving (i.e., routing) packets from intermediate point (i.e., routers inside the network "cloud"
• Mechanisms for sharing a network medium, and for connecting individual network interfaces to physical media.

The Historical Background

The OSI model was originally published with seven abstract layers , and is widely taught on the basis of those layers. ISO actually saw deficiencies in the original seven-layer model and issued modifications, but these modifications are presented only rarely in basic networking courses, especially in industry. Some of the conflicts in the OSI model were resolved in the reference model for Asynchronous Transfer Mode (ATM), but its refinements also are not often presented.

The dominant, and much more informal, networking reference model is that defined by the Internet Engineering Task Force. As a result of the academic and industry emphasis on teaching the now-obsolete original OSI model, there is a continuing and frustrating tendency, in educational material on network architecture, to treat the OSI model as if it is still used other than as a teaching aid, and to try to “coerce” Internet Protocol Suite protocols into OSI layers.

Layering: the good and the bad

Layering, as an abstraction, is useful up to a point. It can be overused. An updated IETF architectural document, RFC3439, even contains a section entitled: "Layering Considered Harmful": Emphasizing layering as the key driver of architecture is not a feature of the TCP/IP model, but rather of OSI. Much confusion comes from attempts to force OSI-like layering onto an architecture that minimizes their use.

Layering can be useful as a way to put together similar functions. Protocols communicate between equivalent layers in different computers, or networking devices such as routers. OSI has the concept that, inside a single computer, layer (N) provides a defined set of abstract services to layer (N+1), and depends on layer (N-1) for a set of services it needs.

The specific set of layers used in the original OSI definition did not reflect the sets of functions that experience showed was wise to build. From an implementation standpoint, it often proved better to write a monolithic piece of software that handled the services of several layers, so the service boundaries did not, in reality, exist.

A service boundary is useful when a set of programming interfaces can be mapped to it, such as a network socket, sometimes called a transport layer interface, for end-to-end communications to another computer. If the functions of the layer are null in a particular implementation, discussing them confuses students for no good reason, as they look for things that don't exist and don't need to exist.

Abstract definitions, however, tend to have only abstract uses. Unfortunately, it's easy for certification test writers to write questions to check if a student has memorized material, so we have had generations of networking people memorizing fundamentally useless information

Internet Engineering Task Force reference model and protocol development

The Internet protocol suite was not intended to match OSI, was developed before OSI, the full set of OSI specifications (i.e., not just document ISO 7498) subdivide layers so that it is no longer seven, and that OSI has, in the real world, been relegated to a teaching tool. The Internet Protocol Suite has four layers, defined in RFC1122and no IETF document, as opposed to some nonauthoritative textbooks, say it has five.

No Internet Engineering Task Force (IETF) standards track document has accepted a five-layer model, and IETF documents indeed deprecate strict layering of all sorts. Given the lack of acceptance of the five-layer model by the body with technical responsibility for the protocol suite, it is not unreasonable to regard five-layer presentations as teaching aids, possibly to make the IP suite architecture more familiar to those students who were first exposed to layering using the OSI model. Comparisons between the IP and OSI suites can give some insight into the abstraction of layering, but trying to coerce Internet protocols, not designed with OSI in mind, can only lead to confusion.

Again, RFC1122 defines 4 layers; no IETF document speaks of other general layering models, or even the desirability of OSI compliance. Further, RFC 1122 was published in 1989, while the OSI Reference Model, ISO 7498, was published in 1984. If the RFC 1122 authors had wanted to be OSI compliant, they had the OSI definitions available to them. They didn't use them. Does that suggest they were not concerned with OSI compliance?

For Internet Protocol Suite architecture, textbooks are not authoritative; the IETF's work, particularly the Standards Track, is definitive for the Internet Protocol Suite.

OSI refinements

Unfortunately not available free online, there are ISO documents such as "Internal Organization of the Network Layer" , which splits the network layer nicely into three levels, logical (lower-layer agnostic), subnetwork (i.e., link technology) specific, and a mapping sublayer between them. ARP, with which many people struggle, drops perfectly into the mapping (technically subnetwork dependence convergence) between them. Another ISO document, "OSI Routeing [sic] Framework" , makes it clear that routing protocols, no matter what protocol carries their payloads, are layer management protocols for the network layer. Annex 4 to ISO 7498 gives the OSI Management Framework , with both system management and layer management components.

Limitations of models with advancing technologies

When the IETF was dealing with MPLS and some other things that "don't quite fit", and some people insisted on calling it "layer 2.5", the reality is that the IETF set up a "Sub-IP Area" and did the original work there. MPLS is now back under the Routing Area. There was also a Performance Implications of Link Characteristics (PILC) working group that has ended its effort, but also deals with sub-IP (archives at http://www.isi.edu/pilc/)