Computer networking reference models: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Howard C. Berkowitz
(Sometimes layers exist. Sometimes, they don't.)
imported>Howard C. Berkowitz
(Moving toward practical reality. Need to load drawings.)
Line 1: Line 1:
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. While the best-known of these, the [[Open Systems Interconnection]] developed by the [[International Organization for Standardization]] (ISO)<ref>ISO is the correct abbreviation. The organization has English and French as its official languages, and adopted a convention to write out group or project names in English, but to use the abbreviation for the French version of the same term. It has been observed that this sort of political compromise is typical of the more formal standards bodies, and compromise rather than technical prototyping has been characteristic of their relatively slow process.</ref>
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]] (OSI) Reference Model (OSIRM), developed by the [[International Organization for Standardization]] (ISO)<ref>ISO is the correct abbreviation. The organization has English and French as its official languages, and adopted a convention to write out group or project names in English, but to use the abbreviation for the French version of the same term. It has been observed that this sort of political compromise is typical of the more formal standards bodies, and compromise rather than technical prototyping has been characteristic of their relatively slow process.</ref> 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 [[byte]]s 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., [[router]]s inside the network "cloud"
:*Mechanisms for sharing a [[network medium]], and for connecting individual [[network interface]]s to physical media.
==The Historical Background==
The OSI model was originally published with seven abstract layers <ref name=ISO7498>{{Citation
The OSI model was originally published with seven abstract layers <ref name=ISO7498>{{Citation
   | title = Open Systems Interconnection -- Basic Reference Modelk  
   | title = Open Systems Interconnection -- Basic Reference Modelk  
   | publisher = International Organization for Standarization  
   | publisher = International Organization for Standarization  
   | id = ISO7498 }}
   | id = ISO7498 }}
</ref>, 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.
</ref>, 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.
 
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” <ref>Posting by Priscilla Oppenheimer to the Groupstudy.com mailing list and website. Groupstudy is a not-for-profit service for helping people study for industrial network certifications</ref> Internet Protocol Suite protocols into OSI layers.  
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” <ref>Posting by Priscilla Oppenheimer to the Groupstudy.com mailing list and website. Groupstudy is a not-for-profit service for helping people study for industrial network certifications</ref> Internet Protocol Suite protocols into OSI layers.  

Revision as of 16:29, 3 May 2008

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 (OSI) Reference Model (OSIRM), developed by the International Organization for Standardization (ISO)[1] 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:

The Historical Background

The OSI model was originally published with seven abstract layers [2], 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” [3] 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, [4] 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 RFC1122[5]and 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. If anyone can find another IETF document that states the OSI model is followed, please cite it. 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. I've written networking textbooks, and, while I might clarify an IETF document, I certainly don't contend that textbooks are more definitive than the actual technical specifications created by expert, not beginning student or teacher, consensus.

OSI refinements

Unfortunately not available free online, there are ISO documents such as "Internal Organization of the Network Layer" [6], 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" [7], 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 [8], 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/)

References

  1. ISO is the correct abbreviation. The organization has English and French as its official languages, and adopted a convention to write out group or project names in English, but to use the abbreviation for the French version of the same term. It has been observed that this sort of political compromise is typical of the more formal standards bodies, and compromise rather than technical prototyping has been characteristic of their relatively slow process.
  2. Open Systems Interconnection -- Basic Reference Modelk, International Organization for Standarization, ISO7498
  3. Posting by Priscilla Oppenheimer to the Groupstudy.com mailing list and website. Groupstudy is a not-for-profit service for helping people study for industrial network certifications
  4. Bush, R. & Meyer (2002), Some Internet Architectural Guidelines and Philosophy, IETF, RFC3439
  5. Braden, R (1989), Requirements for Internet Hosts -- Communication Layers, IETF, RFC1122
  6. Internal Organization of the Network Layer, ISO, 1988, ISO 8648
  7. OSI Routeing Framework, ISO, 1995, ISO/TR 9575
  8. Open Systems Interconnection -- Basic Reference Model -- Part 4: Management framework, ISO, ISO7498/4