Computer networking reference models: Difference between revisions
John Leach (talk | contribs) No edit summary |
John Leach (talk | contribs) m (Text replacement - "]]" to "") |
||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
{{PropDel}}<br><br>{{subpages}} | {{PropDel}}<br><br>{{subpages}} | ||
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 | 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)<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 | 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 | :*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 | :*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., | :*Techniques for moving (i.e., routing) packets from intermediate point (i.e., routers inside the network "cloud" | ||
:*Mechanisms for sharing a | :*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 | 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.<ref name=IEEE802>{{citation | ||
| title = IEEE 802 LAN/MAN Standards Committee | | title = IEEE 802 LAN/MAN Standards Committee | ||
| publisher = Institute of Electrical and Electronic Engineers | | publisher = Institute of Electrical and Electronic Engineers | ||
Line 18: | Line 18: | ||
| 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. Some of the conflicts in the Open Systems Interconnection Reference Model were resolved in the reference model for | </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 Open Systems Interconnection Reference 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 | 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 Open Systems Interconnection Reference Model, there is a continuing and frustrating tendency, in educational material on network architecture, to treat the Open Systems Interconnection Reference 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. | ||
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:<ref name=RFC1925> {{Citation | 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:<ref name=RFC1925> {{Citation | ||
Line 60: | Line 60: | ||
:#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. | :#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. | ||
:#'''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. | :#'''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. | ||
:#Be parsimonious with unsolicited packets, especially | :#Be parsimonious with unsolicited packets, especially multicasting#Generic multicast|multicasts and multicasting#Generic broadcast|broadcasts. | ||
:#Circular dependencies must be avoided. | :#Circular dependencies must be avoided. | ||
:#Objects should be self describing (include type and size), within reasonable limits. Only type codes and other magic numbers assigned by the | :#Objects should be self describing (include type and size), within reasonable limits. Only type codes and other magic numbers assigned by the Internet Corporation for Assigned Names and Numbers#Internet Assigned Numbers Authority|Internet Assigned Numbers Authority (IANA) may be used. | ||
:#All specifications should use the same terminology and notation, and the same bit- and byte-order convention. | :#All specifications should use the same terminology and notation, and the same bit- and byte-order convention. | ||
:#And perhaps most important: '''Nothing gets standardised until there are multiple instances of running code.''' | :#And perhaps most important: '''Nothing gets standardised until there are multiple instances of running code.''' | ||
Line 68: | Line 68: | ||
===The end-to-end assumption=== | ===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 <blockquote>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" <ref name=RFC1958 /></blockquote> | One of the basic architectural assumptions of the Internet is the end-to-end principle, the core of which is <blockquote>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" <ref name=RFC1958 /></blockquote> | ||
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 | 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. | ||
<blockquote>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., | <blockquote>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. <ref name=RFC3439> {{Citation | ||
| first1 = R. | | first1 = R. | ||
| last1 = Bush | | last1 = Bush | ||
Line 80: | Line 80: | ||
| id = RFC3439 }}</ref> </blockquote> | | id = RFC3439 }}</ref> </blockquote> | ||
===Per-hop behavior=== | ===Per-hop behavior=== | ||
'''Relaying''' is a broader term than | '''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. | 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. | '''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 | 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: 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, <ref name=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, as an abstraction, is useful up to a point. It can be overused. An updated IETF architectural document, RFC3439, <ref name=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 | 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. | 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 | 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. | 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. | ||
Line 111: | Line 111: | ||
</ref> and no IETF document, as opposed to some nonauthoritative textbooks, say it has five. | </ref> and no IETF document, as opposed to some nonauthoritative textbooks, say it has five. | ||
No | 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 Open Systems Interconnection Reference 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? | 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? |
Revision as of 16:22, 30 March 2024
This article may be deleted soon. | ||
---|---|---|
![]() 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)[1] 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:
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.[2] The Historical BackgroundThe Open Systems Interconnection Reference Model was originally published with seven abstract layers [3], 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 Open Systems Interconnection Reference 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 Open Systems Interconnection Reference Model, there is a continuing and frustrating tendency, in educational material on network architecture, to treat the Open Systems Interconnection Reference Model as if it is still used other than as a teaching aid, and to try to “coerce” [4] 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:[5]
Architectural principlesThere 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:[6]
The end-to-end assumptionOne of the basic architectural assumptions of the Internet is the end-to-end principle, the core of which is
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.
Per-hop behaviorRelaying 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 badLayering, as an abstraction, is useful up to a point. It can be overused. An updated IETF architectural document, RFC3439, [7]<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 PrincipleThe 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.[7] Internet Engineering Task Force reference model and protocol developmentThe 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[8] 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 Open Systems Interconnection Reference 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 refinementsUnfortunately not available free online, there are ISO documents such as "Internal Organization of the Network Layer" [9], 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" [10], 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 [11], with both system management and layer management components. Limitations of models with advancing technologiesWhen 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
|