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 Protocol Suite, which is far less abstract, and not routinely called a reference model, 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 application protocols such as the Simple Mail Transfer Protocol(SMTP)
• Methods for moving bytes from network endpoint to network endpoint, using end-to-end protocols 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 device-level network interfaces to physical media.

Note that the mechanisms for sharing media and connecting devices are generally outside the scope of the IETF, but, for wired and wireless local networks, the Institute for Electrical and Electronic Engineers (IEEE) does have an architecture IEEE Project 802 and issues specific standards.

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.

Experience has taught us a set of Networking Truths, articulated by Ross Callon. While they were issued in a April 1 document, traditionally the date of less-than-serious IETF publications, the points are very valid:

1. It Has To Work
2. No matter how hard you push and no matter what the priority, you can't increase the speed of light. 299,792,458 meters per second/186,282.397 miles per second isn't just a good idea. It's the Law. Corollary: No matter how hard you try, you can't make a baby in much less than 9 months. Trying to speed this up might make it slower, but it won't make it happen any quicker.
3. With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.
4. Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.
5. It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
6. It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it.(corollary). It is always possible to add another level of indirection.
7. It is always something. (corollary). Good, Fast, Cheap: Pick any two (you can't have all three).
8. It is more complicated than you think.
9. For all resources, whatever it is, you need more. (corollary 9A) Every networking problem always takes longer to solve than it seems like it should.
10. One size never fits all, although it is a fundamental Internet assumption that general-purpose protocols should be able to scale to arbitrary size.
11. Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. (corollary). See the corollary to Rule 6.
12. In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.

Architectural principles

There are good ideas in several models, as well as concepts that tend to be used as a drunk uses a lamppost: for support rather than illumination. Some basic Internet assumptions are:

1. If there are several ways of doing the same thing, choose one. If there is an existing technique that can deal with some requirement, use it, unless there are valid technical reasons not to do so.
2. designs must scale readily to very many nodes per site and to many billions of nodes.
3. Performance and cost must be considered as well as functionality.
4. Keep it simple. When in doubt during design, choose the simplest solution.
5. Modularity is good. If you can keep things separate, do so.
6. In many cases it is better to adopt an almost complete solution now, rather than to wait until a perfect solution can be found. Perfection is the enemy of excellence.
7. If you must have options and parameters in a network mechanism, design that mechanism such that the entities involved can negotiate the values, for a particular interaction, without human intervention. To design a mechanism with the assumption that it needs significant manual configuration is at least a venial, if not mortal, sin.
8. Be conservative of what your code sends, and liberal about handling the messages it receives. When unable to handle something received, discard it without generating new traffic, unless the mechanism specifically requires notifications of errors. If you do have to notify of errors, put in mechanisms that limit traffic storms caused by infinite error loops.
9. Be parsimonious with unsolicited packets, especially multicasts and broadcasts.
10. Circular dependencies must be avoided.
11. Objects should be self decribing (include type and size), within reasonable limits. Only type codes and other magic numbers assigned by the Internet Assigned Numbers Authority (IANA) may be used.
12. All specifications should use the same terminology and notation, and the same bit- and byte-order convention.
13. And perhaps most important: Nothing gets standardised until there are multiple instances of running code.

The end-to-end assumption

One of the basic architectural assumptions of the Internet is the end-to-end principle, the core of which is

The basic argument is that, as a first principle, certain required end- to-end functions can only be performed correctly by the end-systems themselves. A specific case is that any network, however carefully designed, will be subject to failures of transmission at some statistically determined rate. The best way to cope with this is to accept it, and give responsibility for the integrity of communication to the end systems. Another specific case is end-to-end security"

In the real world, things are much less pure. There are valid reasons to have devices that break the end-to-end assumption, such as firewalls, content caches, load balancers, security gateways.

The End-to-End Argument does not imply that the core of the Internet will not contain and maintain state. In fact, a huge amount coarse grained state is maintained in the Internet's core (e.g., routing state). However, the important point here is that this (coarse grained) state is almost [mutually exclusive of] the state maintained by the end-points (e.g., hosts). It is this minimization of interaction that contributes to simplicity. As a result, consideration of "core vs. end-point" state interaction is crucial when analyzing protocols such as Network Address Translation (NAT), which reduce the transparency between network and hosts.

Per-hop behavior

Relaying is a broader term than routing, which includes forwarding of application records, forwarding of regular and encapsulated packets, and frames at the data link level. From a relaying standpoint, everything can be called a network element (NE). Protocols fall into Network protocols fall into two categories: those in which the flow of a piece of information runs from network element (NE) to NE inside the network, and from network edge to network edge. The classical assumption of IP, now selectively broken, of IP is that the primary intelligence is at the edge. There are some intermediate cases, but the two general classes cover most situations.

Per-hop behavior (PHB) refers to behavior at the intermediate NE, not the endpoint. Specific kinds of NE are associated with different layers, such as bridging at the data link layer and routers at the internetwork layer. Not all real-world NE, however, follow strict layering.

PHB is the main way of defining quality of service in the Internet. Quality of service requires that NE keep state of the performance they have guaranteed to deliver.

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.

The Amplification Principle

The Amplification Principle states that there are non-linearities which occur at large scale which do not occur at small to medium scale. A corollary, for many large networks, even small things can and do cause huge events. In system-theoretic terms, in large systems such as these, even small perturbations on the input to a process can destabilize the system's output.

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 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; 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/)