RFC871 日本語訳
0871 Perspective on the ARPANET reference model. M.A. Padlipsky. September 1982. (Format: TXT=74455 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
---------
---------
< INC-PROJECT, MAP-PERSPECTIVE.NLS.14, >, 12-Aug-83 11:34 AMW ;;;;
< INC-PROJECT, MAP-PERSPECTIVE.NLS.14, >, 12-Aug-83 11:34 AMW ;;;;
RFC 871 September 1982 M82-47
RFC 871 September 1982 M82-47
A PERSPECTIVE ON THE ARPANET REFERENCE MODEL
A PERSPECTIVE ON THE ARPANET REFERENCE MODEL
M.A. PADLIPSKY THE MITRE CORPORATION Bedford, Massachusetts
M.A. PADLIPSKY THE MITRE CORPORATION Bedford, Massachusetts
Abstract
Abstract
The paper, by one of its developers, describes the conceptual framework in which the ARPANET intercomputer networking protocol suite, including the DoD standard Transmission Control Protocol (TCP) and Internet Protocol (IP), were designed. It also compares and contrasts several aspects of the ARPANET Reference Model (ARM) with the more widely publicized International Standards Organization's Reference Model for Open System Interconnection (ISORM).
The paper, by one of its developers, describes the conceptual framework in which the ARPANET intercomputer networking protocol suite, including the DoD standard Transmission Control Protocol (TCP) and Internet Protocol (IP), were designed. It also compares and contrasts several aspects of the ARPANET Reference Model (ARM) with the more widely publicized International Standards Organization's Reference Model for Open System Interconnection (ISORM).
i
i
"A PERSPECTIVE ON THE ARPANET REFERENCE MODEL"
"A PERSPECTIVE ON THE ARPANET REFERENCE MODEL"
M. A. Padlipsky
M. A. Padlipsky
Introduction
Introduction
Despite the fact that "the ARPANET" stands as the proof-of-concept of intercomputer networking and, as discussed in more detail below, introduced such fundamental notions as Layering and Virtualizing to the literature, the wide availability of material which appeals to the International Standards Organization's Reference Model for Open System Interconnection (ISORM) has prompted many new- comers to the field to overlook the fact that, even though it was largely tacit, the designers of the ARPANET protocol suite have had a reference model of their own all the long. That is, since well before ISO even took an interest in "networking", workers in the ARPA-sponsored research community have been going about their business of doing research and development in intercomputer networking with a particular frame of reference in mind. They have, unfortunately, either been so busy with their work or were perhaps somehow unsuited temperamentally to do learned papers on abstract topics when there are interesting things to be said on specific topics, that it is only in very recent times that there has been much awareness in the research community of the impact of the ISORM on the lay mind. When the author is asked to review solemn memoranda comparing such things as the ARPANET treatment of "internetting" with that of CCITT employing the ISORM "as the frame of reference," however, the time has clearly come to attempt to enunciate the ARPANET Reference Model (ARM) publicly--for such comparisons are painfully close to comparing an orange with an apple using redness and smoothness as the dominant criteria, given the philosophical closeness of the CCITT and ISO models and their mutual disparities from the ARPANET model.
Despite the fact that "the ARPANET" stands as the proof-of-concept of intercomputer networking and, as discussed in more detail below, introduced such fundamental notions as Layering and Virtualizing to the literature, the wide availability of material which appeals to the International Standards Organization's Reference Model for Open System Interconnection (ISORM) has prompted many new- comers to the field to overlook the fact that, even though it was largely tacit, the designers of the ARPANET protocol suite have had a reference model of their own all the long. That is, since well before ISO even took an interest in "networking", workers in the ARPA-sponsored research community have been going about their business of doing research and development in intercomputer networking with a particular frame of reference in mind. They have, unfortunately, either been so busy with their work or were perhaps somehow unsuited temperamentally to do learned papers on abstract topics when there are interesting things to be said on specific topics, that it is only in very recent times that there has been much awareness in the research community of the impact of the ISORM on the lay mind. When the author is asked to review solemn memoranda comparing such things as the ARPANET treatment of "internetting" with that of CCITT employing the ISORM "as the frame of reference," however, the time has clearly come to attempt to enunciate the ARPANET Reference Model (ARM) publicly--for such comparisons are painfully close to comparing an orange with an apple using redness and smoothness as the dominant criteria, given the philosophical closeness of the CCITT and ISO models and their mutual disparities from the ARPANET model.
This paper, then, is primarily intended as a perspective on the ARM. (Secondarily, it is intended to point out some of the differences between the ARM and the ISORM. For a perspective on this subtheme, please see Note [1]) It can't be "the official" version because the ARPANET Network Working Group (NWG), which was the collective source of the ARM, hasn't had an official general meeting since October, 1971, and can scarcely be resurrected to haggle over it. It does, at least, represent with some degree of fidelity the views of a number of NWG members as those views were expressed in NWG general meetings, NWG protocol design committee meetings, and private conversations over the intervening years. (Members of the current ARPA Internet Working Group, which applied
This paper, then, is primarily intended as a perspective on the ARM. (Secondarily, it is intended to point out some of the differences between the ARM and the ISORM. For a perspective on this subtheme, please see Note [1]) It can't be "the official" version because the ARPANET Network Working Group (NWG), which was the collective source of the ARM, hasn't had an official general meeting since October, 1971, and can scarcely be resurrected to haggle over it. It does, at least, represent with some degree of fidelity the views of a number of NWG members as those views were expressed in NWG general meetings, NWG protocol design committee meetings, and private conversations over the intervening years. (Members of the current ARPA Internet Working Group, which applied
1 RFC 871 September 1982
1 RFC 871 September 1982
and adapted the original model to a broader arena than had initially been contemplated, were also consulted.) That might not sound so impressive as a pronunciamento from an international standards organization, but the reader should be somewhat consoled by the consideration that not only are the views expressed here purported to be those of the primary workers in the field, but also at least one Englishman helped out in the review process.
and adapted the original model to a broader arena than had initially been contemplated, were also consulted.) That might not sound so impressive as a pronunciamento from an international standards organization, but the reader should be somewhat consoled by the consideration that not only are the views expressed here purported to be those of the primary workers in the field, but also at least one Englishman helped out in the review process.
Historical/Philosophical Context
Historical/Philosophical Context
Although rigorous historians of science might quibble as to whether they were "invented" by a particular group, it is an historical fact that many now widely-accepted, fundamental concepts of intercomputer networking were original to the ARPANET Network Working Group. [2] Before attempting to appreciate the implications of that assertion, let's attempt to define its two key terms and then cite the concepts it alludes to:
Although rigorous historians of science might quibble as to whether they were "invented" by a particular group, it is an historical fact that many now widely-accepted, fundamental concepts of intercomputer networking were original to the ARPANET Network Working Group. [2] Before attempting to appreciate the implications of that assertion, let's attempt to define its two key terms and then cite the concepts it alludes to:
By "intercomputer networking" we mean the attachment of multiple, usually general-purpose computer systems--in the sense of Operating Systems of potentially different manufacture (i.e., "Heterogeneous Operating Systems")--to some communications network, or communications networks somehow interconnected, for the purpose of achieving resource sharing amongst the participating operating systems, usually called Hosts. (By "resource sharing" we mean the potential ability for programs on each of the Hosts to interoperate with programs on the other Hosts and for data housed on each of the Hosts to be made available to the other Hosts in a more general and flexible fashion than merely enabling users on each of the Hosts to be able to login to the other Hosts as if they were local; that is, we expect to do more than mere "remote access" to intercomputer networked Hosts.) By "the ARPANET Network Working Group," we mean those system programmers and computer scientists from numerous Defense Advanced Research Projects Agency-sponsored installations whose home operating systems were intended to become early Hosts on the ARPANET. (By "the ARPANET" we mean, depending on context, either that communications network sponsored by DARPA which served as proof-of-concept for the communications technology known as "packet switching," or, consistent with common usage, the intercomputer network which was evolved by the NWG that uses that communications network--or "comm subnet"--as its inter-Host data transmission medium.)
By "intercomputer networking" we mean the attachment of multiple, usually general-purpose computer systems--in the sense of Operating Systems of potentially different manufacture (i.e., "Heterogeneous Operating Systems")--to some communications network, or communications networks somehow interconnected, for the purpose of achieving resource sharing amongst the participating operating systems, usually called Hosts. (By "resource sharing" we mean the potential ability for programs on each of the Hosts to interoperate with programs on the other Hosts and for data housed on each of the Hosts to be made available to the other Hosts in a more general and flexible fashion than merely enabling users on each of the Hosts to be able to login to the other Hosts as if they were local; that is, we expect to do more than mere "remote access" to intercomputer networked Hosts.) By "the ARPANET Network Working Group," we mean those system programmers and computer scientists from numerous Defense Advanced Research Projects Agency-sponsored installations whose home operating systems were intended to become early Hosts on the ARPANET. (By "the ARPANET" we mean, depending on context, either that communications network sponsored by DARPA which served as proof-of-concept for the communications technology known as "packet switching," or, consistent with common usage, the intercomputer network which was evolved by the NWG that uses that communications network--or "comm subnet"--as its inter-Host data transmission medium.)
The concepts of particular interest are as follows: By analogy to the use of the term in traditional communications, the NWG decided that the key to the mechanization of the resource-sharing goal (which in turn had been posited in their informal charter)
The concepts of particular interest are as follows: By analogy to the use of the term in traditional communications, the NWG decided that the key to the mechanization of the resource-sharing goal (which in turn had been posited in their informal charter)
2 RFC 871 September 1982
2 RFC 871 September 1982
would be "protocols" that Hosts would interpret both in communicating with the comm subnet and in communicating with each other. Because the active entities in Hosts (the programs in execution) were widely referred to in Computer Science as "processes," it seemed clear that the mechanization of resource sharing had to involve interprocess communication; protocols that enabled and employed interprocess communication became, almost axiomatically, the path to the goal. Perhaps because the limitations of mere remote access were perceived early on, or perhaps simply by analogy to the similar usage with regard to distinguishing between physical tape drives and tape drives associated with some conventionally-defined function like the System Input stream or the System Output stream in batch operating systems, the discernible communications paths (or "channels") through the desired interprocess communication mechanism became known as "logical connections"--the intent of the term being to indicate that the physical path didn't matter but the designator (number) of the logical connection could have an assigned meaning, just like logical tape drive numbers. Because "modularity" was an important issue in Computer Science at the time, and because the separation of Hosts and Interface Message Processors (IMP's) was a given, the NWG realized that the protocols it designed should be "layered," in the sense that a given set of related functions (e.g., the interprocess communication mechanism, or "primitives," as realized in a Host-to-Host protocol) should not take special cognizance of the detailed internal mechanics of another set of related functions (e.g., the comm subnet attachment mechanism, as realized in a Host-Comm Subnet Processor protocol), and that, indeed, protocols may be viewed as existing in a hierarchy.
would be "protocols" that Hosts would interpret both in communicating with the comm subnet and in communicating with each other. Because the active entities in Hosts (the programs in execution) were widely referred to in Computer Science as "processes," it seemed clear that the mechanization of resource sharing had to involve interprocess communication; protocols that enabled and employed interprocess communication became, almost axiomatically, the path to the goal. Perhaps because the limitations of mere remote access were perceived early on, or perhaps simply by analogy to the similar usage with regard to distinguishing between physical tape drives and tape drives associated with some conventionally-defined function like the System Input stream or the System Output stream in batch operating systems, the discernible communications paths (or "channels") through the desired interprocess communication mechanism became known as "logical connections"--the intent of the term being to indicate that the physical path didn't matter but the designator (number) of the logical connection could have an assigned meaning, just like logical tape drive numbers. Because "modularity" was an important issue in Computer Science at the time, and because the separation of Hosts and Interface Message Processors (IMP's) was a given, the NWG realized that the protocols it designed should be "layered," in the sense that a given set of related functions (e.g., the interprocess communication mechanism, or "primitives," as realized in a Host-to-Host protocol) should not take special cognizance of the detailed internal mechanics of another set of related functions (e.g., the comm subnet attachment mechanism, as realized in a Host-Comm Subnet Processor protocol), and that, indeed, protocols may be viewed as existing in a hierarchy.
With the notion of achieving resource sharing via layered protocols for interprocess communication over logical connections fairly firmly in place, the NWG turned to how best to achieve the first step of intercomputer networking: allowing a distant user to login to a Host as if local--but with the clear understanding that the mechanisms employed were to be generalizable to other types of resource sharing. Here we come to the final fundamental concept contributed by the NWG, for it was observed that if n different types of Host (i.e., different operating systems) had to be made aware of the physical characteristics of m different types of terminal in order to exercise physical control over them--or even if n different kinds of Host had to become aware of the native terminals supported by m other kinds of Hosts if physical control were to remain local--there would be an administratively intractable "n x m problem." So the notion of creating a "virtual terminal" arose, probably by analogy to "virtual memory" in the sense of something that "wasn't really there" but could be used as if it
With the notion of achieving resource sharing via layered protocols for interprocess communication over logical connections fairly firmly in place, the NWG turned to how best to achieve the first step of intercomputer networking: allowing a distant user to login to a Host as if local--but with the clear understanding that the mechanisms employed were to be generalizable to other types of resource sharing. Here we come to the final fundamental concept contributed by the NWG, for it was observed that if n different types of Host (i.e., different operating systems) had to be made aware of the physical characteristics of m different types of terminal in order to exercise physical control over them--or even if n different kinds of Host had to become aware of the native terminals supported by m other kinds of Hosts if physical control were to remain local--there would be an administratively intractable "n x m problem." So the notion of creating a "virtual terminal" arose, probably by analogy to "virtual memory" in the sense of something that "wasn't really there" but could be used as if it
3 RFC 871 September 1982
3 RFC 871 September 1982
were; that is, a common intermediate representation (CIR) of terminal characteristics was defined in order to allow the Host to which a terminal was physically attached to map the particular characteristics of the terminal into a CIR, so that the Host being logged into, knowing the CIR as part of the relevant protocol, could map out of it into a form already acceptable to the native operating system. And when it came time to develop a File Transfer Protocol, the same virtualizing or CIR trick was clearly just as useful as for a terminal oriented protocol, so virtualizing became part of the axiom set too.
were; that is, a common intermediate representation (CIR) of terminal characteristics was defined in order to allow the Host to which a terminal was physically attached to map the particular characteristics of the terminal into a CIR, so that the Host being logged into, knowing the CIR as part of the relevant protocol, could map out of it into a form already acceptable to the native operating system. And when it came time to develop a File Transfer Protocol, the same virtualizing or CIR trick was clearly just as useful as for a terminal oriented protocol, so virtualizing became part of the axiom set too.
The NWG, then, at least pioneered and probably invented the notion of doing intercomputer networking/resource sharing via hierarchical, layered protocols for interprocess communication over logical connections of common intermediate representations/ virtualizations. Meanwhile, outside of the ARPA research community, "the ARPANET" was perceived to be a major technological advance. "Networking" became the "in" thing. And along with popular success came the call for standards; in particular, standards based on a widely-publicized "Reference Model for Open System Interconnection" promulgated by the International Standards Organization. Not too surprisingly, Open System Interconnection looks a lot like resource sharing, the ISORM posits a layered protocol hierarchy, "connections" occur frequently, and emerging higher level protocols tend to virtualize; after all, one expects standards to reflect the state of the art in question. But even if the ISORM, suitably refined, does prove to be the wave of the future, this author feels that the ARM is by no means a whitecap, and deserves explication--both in its role as the ISORM's "roots" and as the basis of a still-viable alternative protocol suite.
The NWG, then, at least pioneered and probably invented the notion of doing intercomputer networking/resource sharing via hierarchical, layered protocols for interprocess communication over logical connections of common intermediate representations/ virtualizations. Meanwhile, outside of the ARPA research community, "the ARPANET" was perceived to be a major technological advance. "Networking" became the "in" thing. And along with popular success came the call for standards; in particular, standards based on a widely-publicized "Reference Model for Open System Interconnection" promulgated by the International Standards Organization. Not too surprisingly, Open System Interconnection looks a lot like resource sharing, the ISORM posits a layered protocol hierarchy, "connections" occur frequently, and emerging higher level protocols tend to virtualize; after all, one expects standards to reflect the state of the art in question. But even if the ISORM, suitably refined, does prove to be the wave of the future, this author feels that the ARM is by no means a whitecap, and deserves explication--both in its role as the ISORM's "roots" and as the basis of a still-viable alternative protocol suite.
Axiomatization
Axiomatization
Let's begin with the axioms of the ARPANET Reference Model. Indeed, let's begin by recalling what an axiom is, in common usage: a principle the truth of which is deemed self-evident. Given that definition, it's not too surprising that axioms rarely get stated or examined in non-mathematical discourse. It turns out, however, that the axiomatization of the ARM--as best we can recall and reconstruct it--is not only germane to the enunciation of the ARM, but is also a source of instructive contrasts with our view of the axiomatization of the ISORM. (See [1] again.)
Let's begin with the axioms of the ARPANET Reference Model. Indeed, let's begin by recalling what an axiom is, in common usage: a principle the truth of which is deemed self-evident. Given that definition, it's not too surprising that axioms rarely get stated or examined in non-mathematical discourse. It turns out, however, that the axiomatization of the ARM--as best we can recall and reconstruct it--is not only germane to the enunciation of the ARM, but is also a source of instructive contrasts with our view of the axiomatization of the ISORM. (See [1] again.)
Resource Sharing
Resource Sharing
The fundamental axiom of the ARM is that intercomputer networking protocols (as distinct from communications network
The fundamental axiom of the ARM is that intercomputer networking protocols (as distinct from communications network
4 RFC 871 September 1982
4 RFC 871 September 1982
protocols) are to enable heterogeneous computer operating systems ("Hosts") to achieve resource sharing. Indeed, the session at the 1970 SJCC in which the ARPANET entered the open literature was entitled "Resource Sharing Computer Networks".
protocols) are to enable heterogeneous computer operating systems ("Hosts") to achieve resource sharing. Indeed, the session at the 1970 SJCC in which the ARPANET entered the open literature was entitled "Resource Sharing Computer Networks".
Of course, as self-evident truths, axioms rarely receive much scrutiny. Just what resource sharing is isn't easy to pin down--nor, for that matter, is just what Open System Interconnection is. But it must have something to do with the ability of the programs and data of the several Hosts to be used by and with programs and data on other of the Hosts in some sort of cooperative fashion. It must, that is, confer more functionality upon the human user than merely the ability to log in/on to a Host miles away ("remote access").
Of course, as self-evident truths, axioms rarely receive much scrutiny. Just what resource sharing is isn't easy to pin down--nor, for that matter, is just what Open System Interconnection is. But it must have something to do with the ability of the programs and data of the several Hosts to be used by and with programs and data on other of the Hosts in some sort of cooperative fashion. It must, that is, confer more functionality upon the human user than merely the ability to log in/on to a Host miles away ("remote access").
A striking property of this axiom is that it renders protocol suites such as "X.25"/"X.28"/ "X.29" rather uninteresting for our purposes, for they appear to have as their fundamental axiom the ability to achieve remote access only. (It might even be a valid rule of thumb that any "network" which physically interfaces to Hosts via devices that resemble milking machines--that is, which attach as if they were just a group of locally-known types of terminals--isn't a resource sharing network.)
それがそのようなものをプロトコル群にするこの原理の衝撃的な特性がある、「X.25"/、「X.28"/、「それらの基本的公理として遠隔アクセスだけを達成する能力を持っているように見えるのによる私たちの目的のためにかなりおもしろくないX.29" (まるでそれらがただ局所的に知られているタイプの端末のグループであるかのように付く搾乳器に類似している装置を通して物理的にHostsに連結するどんな「ネットワーク」もあらゆるリソース・シェアリングネットワークであるのも有効な経験則になりさえしないかもしれません。)
Reference [3] addresses the resource sharing vs. remote access topic in more detail.
参照[3]はさらに詳細に遠隔アクセスの話題に対してリソース・シェアリングを記述します。
Interprocess Communication
プロセス間通信
The second axiom of the ARM is that resource sharing will be achieved via an interprocess communication mechanism of some sort. Again, the concept isn't particularly well-defined in the "networking" literature. Here, however, there's some justification, for the concept is fairly well known in the Operating Systems branch of the Computer Science literature, which was the field most of the NWG members came from. Unfortunately, because intercomputer networking involves communications devices of several sorts, many whose primary field is Communications became involved with "networking" but were not in a position to appreciate the implications of the axiom.
ARMの2番目の原理はリソース・シェアリングがある種のプロセス間通信メカニズムで達成されるということです。 一方、概念は「ネットワーク」文学で特に明確ではありません。 しかしながら、ここに、何らかの正当化があります、概念はOperating SystemsブランチでコンピュータScience文学(NWGメンバーの大部分が来た分野であった)を公正によく知られているので。 残念ながら、intercomputerネットワークが数種類のコミュニケーション装置にかかわるので、第一の分野がCommunicationsである多くは、「ネットワーク」にかかわるようになりましたが、原理の含意に感謝する立場にありませんでした。
A process may be viewed as the active element of a Host, or as an address space in execution, or as a "job", or as a "task", or as a "control point"--or, actually, as any one (or more) of at least 29 definitions from at least 28 reputable computer scientists. What's important for present purposes isn't the precise definition (even if there were one), but the fact that the axiom's presence dictates the absence of at least one other axiom at the same level of
過程はHostの能動素子として、または、実行におけるアドレス空間として、または、「仕事」として、または、「タスク」として、または、「制御点」として、または、実際に少なくとも28人の評判のよいコンピュータ科学者からの少なくとも29の定義のどれか(さらに)として見なされるかもしれません。 現在の目的のために重要なことは厳密な定義(1つがあったとしても)ではなく、原理の存在が平らな状態で同じくらいの他の少なくとも1つの原理の欠如を決めるという事実です。
5 RFC 871 September 1982
5 RFC871 1982年9月
abstraction. That is, we might have chosen to attempt to achieve resource sharing through an explicitly interprocedure communication oriented mechanism of some sort--wherein the entities being enabled to communicate were subroutines, or pieces of address spaces--but we didn't. Whether this was because somebody realized that you could do interprocedure communication (or achieve a "virtual address space" or "distributed operating system" or some such formulation) on top of an interprocess communication mechanism (IPC), or whether "it just seemed obvious" to do IPC doesn't matter very much. What matters is that the axiom was chosen, assumes a fair degree of familiarity with Operating Systems, doesn't assume extremely close coupling of Hosts, and has led to a working protocol suite which does achieve resource sharing--and certainly does appear to be an axiom the ISORM tacitly accepted, along with resource sharing.
抽象化。 すなわち、私たちは、交信するのが可能にされる実体がサブルーチン、またはアドレス空間の断片であったところである種の明らかにinterprocedureコミュニケーション指向のメカニズムを通してリソース・シェアリングを達成するのを試みるのを選んだかもしれません--私たちだけはそうしませんでした。 これがだれかが、あなたがIPCをするために、プロセス間通信メカニズム(IPC)か「ただ、明白に見えたかどうか」の上でinterprocedureコミュニケーション(「仮想アドレス空間」、「分配されたオペレーティングシステム」またはそのような何らかの定式化を達成する)ができたとわかったからであるかどうかあまり重要ではありません。 重要なことは原理が選ばれて、公正な度のOperating Systemsへの親しみを仮定して、Hostsの非常に近いカップリングを仮定しないで、リソース・シェアリングを達成する働くプロトコル群に通じたということです--そして、確かに、ISORMが暗に受け入れた原理であるように見えます、リソース・シェアリングと共に。
Logical Connections
論理的なコネクションズ
The next axiom has to do with whether and how to demultiplex IPC "channels", "routes", "paths", "ports", or "sockets". That is, if you're doing interprocess communication (IPC), you still have to decide whether a process can communicate with more than one other process, and, if so, how to distinguish between the bit streams. (Indeed, even choosing streams rather than blocks is a decision.) Although it isn't treated particularly explicitly in the literature, it seems clear that the ARM axiom is to do IPC over logical connections, in the following sense: Just as batch oriented operating systems found it useful to allow processes (usually thought of as jobs--or even "programs") to be insulated from the details of which particular physical tape drives were working well enough at a particular moment to spin the System Input and Output reels, and created the view that a reference to a "logical tape number" would always get to the right physical drive for the defined purpose, so too the ARM's IPC mechanism creates logical connections between processes. That is, the IPC addressing mechanism has semantics as well as syntax.
次の原理は関係がある、そして、demultiplex IPC「チャンネル」、「ルート」、「経路」、「ポート」、または「ソケット」へのどのように?。 すなわち、あなたがプロセス間通信(IPC)をしているなら、あなたは、過程が他の1つ以上の過程で交信できるかどうかと、そうだとすれば、どのようにビットストリームを見分けるかをまだ決めなければなりません。. (ブロックよりむしろ流れを選びさえするのは、決定です。) それは文学で特に明らかに扱われませんが、ARM原理が論理的な接続の上にIPCをすることであることは明確に見えます、以下の意味で: ちょうどバッチとして、指向のオペレーティングシステムは、隔離される特定の瞬間に大変うまくいくのがSystem InputとOutputを回転させるつもりであったなら特定の物理的なテープがそれの詳細を追い立てる過程(通常、仕事、または「プログラム」としてさえ考えられる)にリールを許容するのが役に立つのがわかって、「論理的なテープ番号」の参照はいつも定義された目的を求める正しい物理的な運動を始めるでしょう、したがって、また、ARMのIPCメカニズムが過程の間の論理的な関係を作成するという意見を作成しました。 すなわち、IPCアドレシングメカニズムには、構文と同様に意味論があります。
"Socket" n on any participating Host will be defined as the "Well-Known Socket" (W-KS) where a particular service (as mechanized by a program which follows, or "interprets", a particular protocol [4]) is found. (Note that the W-KS is defined for the "side" of a connection where a given service resides; the user side will, in order to be able to demultiplex its network-using processes, of course assign different numbers to its "sides" of connections to a given W-KS. Also, the serving side takes cognizance of the using side's Host designation as well as the proferred socket, so it too can demultiplex.) Clearly, you want free sockets as well as Well-Known ones, and we have them. Indeed, at each level of the ARM
どんな参加Hostの「ソケット」nもa特定であるところで「周知のソケット」(W-カンザス)と定義される、サービス、(続くか、または「解釈する」プログラムで機械化されているように、特定のプロトコル[4])は見つけられます。 (W-カンザスが与えられたサービスがある接続の「側」と定義されることに注意してください。 ユーザ側は、ネットワーク使用が処理する「反-マルチプレックス」にできるためにもちろん与えられたW-カンザスとの接続の「側」に異なった数を割り当てるでしょう。 また、給仕側は、「反-マルチプレックス」がproferredソケットと同様に使用側のHost名称気が付くことができるように気が付きます。) 明確に、あなたはWellによって知られているものと同様に無料のソケットが欲しいです、そして、私たちはそれらを持っています。 本当にそれぞれのレベルのARM
6 RFC 871 September 1982
6 RFC871 1982年9月
hierarchy the addressing entities are divided into assigned and unassigned sets, and the distinction has proven to be quite useful to networking researchers in that it confers upon them the ability to experiment with new functions without interfering with running mechanisms.
アドレシング実体が分割される階層構造は、セットは割り当てて、割り当てませんでした、そして、走行メカニズムを妨げないで新しい機能を実験する能力を彼らに与えるので、区別はかなりネットワーク研究者の役に立つと判明しました。
On this axiom, the ISORM differs from the ARM. ISORM "peer-peer" connections (or "associations") appear to be used only for demultiplexing, with the number assigned by the receive side rather than the send side. That is, a separate protocol is intro- duced to establish that a particular "transport" connection will be used in the present "session" for some particular service. At the risk of editorializing, logical connections seem much cleaner than "virtual" connections (using virtual in the sense of something that "isn't really there" but can be used as if it were, by analogy to virtual memory, as noted above, and in deference to the X.25 term "virtual circuit", which appears to have dictated the receiver-assigned posture the ISORM takes at its higher levels.) Although the ISORM view "works", the W-KS approach avoids the introduction of an extra protocol.
この原理では、ISORMはARMと異なっています。 ISORM「同輩同輩」接続(または、「協会」)は、逆多重化にだけ使用されるように見えます、数が割り当てられている状態でむしろ側を受け取ってください、側を送ってください。 すなわち、別々のプロトコルは特定の「輸送」接続が現在の「セッション」のときに何らかの特定のサービスに使用されると証明するためにducedされた序奏です。 社説に書くというリスクで、論理的な接続は「仮想」の接続(仮想でまるでそれが仮想記憶への類推で上で述べたようにあるかのように、「本当にそこには、ありません」が、使用できる何かの意味、「仮想のサーキット」というX.25用語およびを重んじて使用しますISORMが、より高いレベルで取る受信機で割り当てられた姿勢を書き取ったように見える)よりはるかにきれいに見えます。 ISORM視点は「働いています」が、W-カンザスアプローチは余分なプロトコルの導入を避けます。
Layering
レイヤリング
The next axiom is perhaps the best-known, and almost certainly the worst-understood. As best we can reconstruct things, the NWG was much taken with the Computer Science buzzword of the times, "modularity". "Everybody knew" modularity was a Good Thing. In addition, we were given a head start because the IMP's weren't under our direct control anyway, but could possibly change at some future date, and we didn't want to be "locked in" to the then-current IMP-Host protocol. So it was enunciated that protocols which were to be members of the ARM suite (ARMS, for future reference, although at the time nobody used "ARM", much less "ARMS") were to be layered. It was widely agreed that this meant a given protocol's control information (i.e., the control information exchanged by counterpart protocol interpreters, or "peer entities" in ISORM terms) should be treated strictly as data by a protocol "below" it, so that you could invoke a protocol interpreter (PI) through a known interface, but if either protocol changed there would not be any dependencies in the other on the former details of the one, and as long as the interface didn't change you wouldn't have to change the PI of the protocol which hadn't changed.
次の原理は、恐らく最もよく知られていてほぼ確実に最もひどく理解です。 私たちがものを最もよく再建できるように、NWGは現代のコンピュータScience専門用語、「モジュール方式」に夢中になっていました。 「みんなは知っていた」というモジュール方式がGood Thingでした。 さらに、私たちは、いつかの将来の期日に変化できた以外に、IMPのものがとにかく私たちの直轄でなくて、「閉じ込められたくなかった」ので、次に、現在のIMP-ホストプロトコルに有利なスタートを与えました。 それで、ARMスイート(ARMS、だれも当時、「アーム」を使用しませんでしたが、多くがそれほど後日のために、「軍備されない」)の部材であることであったそのプロトコルが述べられて、層にされることであったということでした。 これが、与えられたプロトコルの制御情報(すなわち、対応者プロトコルインタプリタ、または「同輩実体」によってISORM用語で交換された制御情報)がプロトコル“below"によって厳密にデータとして扱われるはずであることを意味したのに広く同意されました。それ; あなたがプロトコルを呼び出すことができるように、知られているインタフェースにもかかわらず、どちらのプロトコルもそこで変化したかどうかを通したインタプリタ(PI)はものの前の詳細に関するもう片方であらゆる依存でないでしょう、そして、インタフェースが変化しなかった限り、あなたは変化していなかったプロトコルのPIを変える必要はないでしょう。
All well and good, if somewhat cryptic. The important point for present purposes, however, isn't a seemingly-rigorous definition of Layering, but an appreciation of what the axiom meant in the evolution of the ARM. What it meant was that we tried to come up
すべて良くて、良くて、いくらか不可解です。 しかしながら、現在の目的のための重要なポイントはLayeringの外観上厳しい定義ではなく、原理がARMの発展で意味したことに関する感謝です。 それが私たちが来ようとしたということであることを意味したこと
7 RFC 871 September 1982
7 RFC871 1982年9月
with protocols that represented reasonable "packagings" of functionality. For reasons that are probably unknowable, but about which some conjectures will be offered subsequently, the ARM and the ISORM agree strongly on the presence of Layering in their respective axiomatizations but differ strikingly as to what packagings of functionality are considered appropriate. To anticipate a bit, the ARM concerns itself with three layers and only one of them is mandatorily traversed; whereas the ISORM, again as everybody knows, has, because of emerging "sub-layers", what must be viewed as at least seven layers, and many who have studied it believe that all of the layers must be traversed on each transmission/reception of data.
プロトコルで、それは機能性の妥当な「輸送容器」を表しました。 たぶん不可知ですが、いくつかの憶説が次に提供される理由で、ARMとISORMは彼らのそれぞれの公理化で強くLayeringの存在に同意しますが、機能性のどんな輸送容器が適切であると考えられるかに関してきわだって異なります。 少し、ARMが3に携わると予期するために、それらの層と1つだけがmandatorilyに横断されます。 ISORMには、見なければならないものが「副層」として現れるので、再び周知のようにありますが、少なくとも7つの層、およびそれを研究した多くとしてデータの各トランスミッション/レセプションで層のすべてを横断しなければならないと信じてください。
Perhaps the most significant point of all about Layering is that the most frequently-voiced charge at NWG protocol committee design meetings was, "That violates Layering!" even though nobody had an appreciably-clearer view of what Layering meant than has been presented here, yet the ARMS exists. We can only guess what goes on in the design meetings for protocols to become members of the ISORM suite (ISORMS), but it doesn't seem likely that having more layers could possibly decrease the number of arguments....
恐らく、Layeringに関するすべての最も重要なポイントはNWGプロトコル委員会のデザインミーティングにおける最も多くの頻繁に有声な料金が「それはLayeringに違反する!」ということであったということであり、だれにも、Layeringが意味したことに関するかなりここにまだ提示されているより明確な意見がありませんでしたが、ARMSは存在しています。 私たちは、何がプロトコルがISORMスイート(ISORMS)の部材になるデザインミーティングで起こるかを推測できるだけですが、より多くの層を持っているのは引数の数が減少しそうにないかもしれません…
Indeed, it's probably fair to say that the ARM view of Layering is to treat layers as quite broad functional groupings (Network Interface, Host-Host, and Process-Level, or Applications), the constituents of which are to be modular. E.g., in the Host-Host layer of the current ARMS, the Internet Protocol, IP, packages internet addressing--among other things--for both the Transmission Control Protocol, TCP, which packages reliable interprocess communication, and UDP--the less well-known User Datagram Protocol--which packages only demultiplexable interprocess communication ... and for any other IPC packaging which should prove desirable. The ISORM view, on the other hand, fundamentally treats layers as rather narrow functional groupings, attempting to force modularity by requiring additional layers for additional functions (although the "classes" view of the proposed ECMA-sponsored ISORM Transport protocol tends to mimic the relations between TCP, UDP, and IP).
本当に、LayeringのARM視点がそれの成分がことであるモジュールであるかなり広い機能的な組分け(ネットワークInterfaceか、Host-ホストと、Process-レベルか、Applications)として層を扱うことであると言うのはたぶん公正です。 例えば、現在のARMSのHost-ホスト層の中では、インターネットプロトコル(IP)は特に、通信制御プロトコル、信頼できるプロセス間通信をパッケージするTCP、およびUDP--それほど周知でないユーザー・データグラム・プロトコル--どのパッケージの両方がプロセス間通信を…「反-多重-可能」するだけであるか、そして、望ましいと判明するべきであるいかなる他のIPCパッケージのためのインターネットアドレシングもパッケージします。 他方では、ISORM視点は基本的にかなり狭い機能的な組分けとして層を扱います、追加機能のために追加層を必要とすることによってモジュール方式を強制するのを試みて(提案されたECMAによって後援されたISORM Transportプロトコルの「クラス」視点は、TCPと、UDPと、IPとの関係をまねる傾向がありますが)。
It is, by the way, forcing this view of modularity by multiplying layers rather than by trusting the designers of a given protocol to make it usable by other protocols within its own layer that we suspect to be a major cause of the divergence between the ISORM and the ARM, but, as indicated, the issue almost certainly is not susceptible of proof. (The less structured view of modularity will be returned to in the next major section.) At any rate, the notion that "N-entities" must communicate with one another by means of "N-1 entities" does seem to us to take the ISORM out of its
それは与えられたプロトコルのデザイナーがISORMとARMの間で分岐の主な原因であることを私たちが疑うそれ自身の層の中で他のプロトコルで使用可能にすると信じることによってというよりむしろ層を掛けることによってモジュール方式のこの視点を強制しながら、方法でありますが、示されるように、問題はほぼ確実に証拠で影響されやすくはありません。 (次の主要なセクションでモジュール方式のそれほど構造化されなかった視点に戻るでしょう。) いずれにせよ、ISORMを取る、必須が「N-1実体」によってお互いと伝える「N-実体」がそうするという概念が、私たちにとって思えるそれ
8 RFC 871 September 1982
8 RFC871 1982年9月
intended sphere of description into the realm of prescription, where we believe it should not be, if for no other reason than that for a reference model to serve a prescriptive role levies unrealizable requirements of precision, and of familiarity with all styles of operating systems, on its expositors. In other words, as it is currently presented, the ISORM hierarchy of protocols turns out to be a rather strict hierarchy, with required, "chain of command" implications akin to the Elizabethan World Picture's Great Chain of Being some readers might recall if they've studied Shakespeare, whereas in the ARM a cat can even invoke a king, much less look at one.
私たちがそれを信じている処方箋の分野への記述の意図している範囲はそうであるべきではありません、それいいえ以外の規範モデルの理由が規範的な役割を受けるように課税がすべてのスタイルのオペレーティングシステムで精度、および親しみの要件を「非-実現可能」するなら、説明者の上で。 言い換えれば、それが現在提示されるとき、プロトコルのISORM階層構造はかなり厳しい階層構造であると判明します、エリザベス朝のWorld Pictureの彼らがシェークスピアを研究しましたが、猫がARMで王を呼び出しさえするか、またはまして、1時に見ることができますが、何人かの読者が思い出すかもしれないBeingのすばらしいChainと同様の必要な「指揮系統」含意で。
Common Intermediate Representations
共通中間体表現
The next axiom to be considered might well not be an axiom in a strict sense of the term, for it is susceptible of "proof" in some sense. That is, when it came time to design the first Process-Level (roughly equivalent to ISORM Level 5.3 [5] through 7) ARMS protocol, it did seem self-evident that a "virtual terminal" was a sound conceptual model--but it can also be demonstrated that it is. The argument, customarily shorthanded as "the N X M Problem", was sketched above; it goes as follows: If you want to let users at remote terminals log in/on to Hosts (and you do--resource sharing doesn't preclude remote access, it subsumes it), you have a problem with Hosts' native terminal control software or "access methods", which only "know about" certain kinds/brands/types of terminals, but there are many more terminals out there than any Host has internalized (even those whose operating systems take a generic view of I/O and don't allow applications programs to "expect" particular terminals).
考えられる次の原理はたぶん用語の厳しい意味で原理でないでしょう、それが何らかの意味における「証拠」で影響されやすいので。 すなわち、来たとき、最初のProcess-レベル(ISORM Level5.3[5]に7を通しておよそ同等な)ARMSを設計する時間は議定書を作りますが、「仮想端末」が健全な概念モデルであったのが自明に見えましたが、また、それがそうであることを示すことができます。 「N X M問題」として通例に人手不足である議論は上にスケッチされました。 それは以下の通り行きます: Hostsにログイン/オンな遠隔端末でユーザをさせたいなら(あなたはそうします--リソース・シェアリングは遠隔アクセスを排除しないで、それはそれを包括します)、あなたには、ある種類/ブランド/タイプの端末が「知っているだけです」が、ずっと多くの端末がむこうにあるHostsの固有の端末の制御ソフトウェアか「アクセス法」に関する問題がどんなHostも内面化させたより(オペレーティングシステムが、入出力の一般的な意見を取って、アプリケーションプログラムが特定の端末を「予想すること」を許容しないそれらさえ)あります。
You don't want to make N different types of Host/Operating System have to become aware of M different types of terminal. You don't want to limit access to users who are at one particular type of terminal even if all your Hosts happen to have one in common. Therefore, you define a common intermediate representation (CIR) of the properties of terminals--or create a Network Virtual Terminal (NVT), where "virtual" is used by analogy to "virtual memory" in the sense of something that isn't necessarily really present physically but can be used as if it were. Each Host adds one terminal to its set of supported types, the NVT--where adding means translating/mapping from the CIR to something acceptable to the rest of the programs on your system when receiving terminal-oriented traffic "from the net", and translating/mapping to the CIR from whatever your acceptable native representation was when sending terminal-oriented traffic "to the net". (And the system to which the terminal is physically attached does the same things.)
あなたはSystemが意識するようになるように持っているN異なったタイプのMのHost/作動を異なったタイプの端末にしたがっていません。 あなたはアクセスをあなたのすべてのHostsがたまたま1つが共通であってもさえ1つの特定のタイプの端末にいるユーザに制限したがっていません。 したがって、あなたは端末の特性の共通中間体表現(CIR)を定義します--または、Network Virtual Terminal(NVT)を作成します。そこでは、「仮想」を必ず本当に物理的に何か存在するというわけではないものの意味で「仮想記憶」への類推で使用されますが、まるでそれがあるかのように使用できます。 端末指向の交通を「ネット」に送るとき、各Hostは、あなたの許容できる固有の表現を何でもからCIRに支持されたタイプと、付加が「ネット」を翻訳するか、または端末指向の交通を受けるときのあなたのシステムの上のプログラムの残りにCIRから何か許容できるものまで写像することを意味するところのNVTと、翻訳するか、または写像するセットへの1台の端末がそうであったと言い足します。 (そして、端末が物理的に取り付けられるシステムは同じことをします。)
9 RFC 871 September 1982
9 RFC 871 September 1982
"Virtualizing" worked so well for the protocol in question ("Telnet", for TELetypewriter NETwork) that when it came time to design a File Transfer Protocol (FTP), it was employed again--in two ways, as it happens. (It also worked so well that in some circles, "Telnet" is used as a generic term for "Virtual Terminal Protocol", just like "Kleenex" for "disposable handkerchief".) The second way in which FTP (another generic-specific) used Common Intermediate Representations is well-known: you can make your FTP protocol interpreters (PI's) use certain "virtual" file types in ARMS FTP's and in proposed ISORMS FTP's. The first way a CIR was used deserved more publicity, though: We decided to have a command-oriented FTP, in the sense of making it possible for users to cause files to be deleted from remote directories, for example, as well as simply getting a file added to a remote directory. (We also wanted to be able to designate some files to be treated as input to the receiving Hosts' native "mail" system, if it had one.) Therefore, we needed an agreed-upon representation of the commands--not only spelling the names, but also defining the character set, indicating the ends of lines, and so on. In less time than it takes to write about, we realized we already had such a CIR: "Telnet".
"Virtualizing" worked so well for the protocol in question ("Telnet", for TELetypewriter NETwork) that when it came time to design a File Transfer Protocol (FTP), it was employed again--in two ways, as it happens. (It also worked so well that in some circles, "Telnet" is used as a generic term for "Virtual Terminal Protocol", just like "Kleenex" for "disposable handkerchief".) The second way in which FTP (another generic-specific) used Common Intermediate Representations is well-known: you can make your FTP protocol interpreters (PI's) use certain "virtual" file types in ARMS FTP's and in proposed ISORMS FTP's. The first way a CIR was used deserved more publicity, though: We decided to have a command-oriented FTP, in the sense of making it possible for users to cause files to be deleted from remote directories, for example, as well as simply getting a file added to a remote directory. (We also wanted to be able to designate some files to be treated as input to the receiving Hosts' native "mail" system, if it had one.) Therefore, we needed an agreed-upon representation of the commands--not only spelling the names, but also defining the character set, indicating the ends of lines, and so on. In less time than it takes to write about, we realized we already had such a CIR: "Telnet".
So we "used Telnet", or at any rate the NVT aspects of that protocol, as the "Presentation" protocol for the control aspects of FTP--but we didn't conclude from that that Telnet was a lower layer than FTP. Rather, we applied the principles of modularity to make use of a mechanism for more than one purpose--and we didn't presume to know enough about the internals of everybody else's Host to dictate how the program(s) that conferred the FTP functionality interfaced with the program(s) that conferred the Telnet functionality. That is, on some operating systems it makes sense to let FTP get at the NVT CIR by means of closed subroutine calls, on others through native IPC, and on still others by open subroutine calls (in the sense of replicating the code that does the NVT mapping within the FTP PI). Such decisions are best left to the system programmers of the several Hosts. Although the ISORM takes a similar view in principle, in practice many ISORM advocates take the model prescriptively rather than descriptively and construe it to require that PI's at a given level must communicate with each other via an "N-1 entity" even within the same Host. (Still other ISORMites construe the model as dictating "monolithic" layers--i.e., single protocols per level--but this view seems to be abating.)
So we "used Telnet", or at any rate the NVT aspects of that protocol, as the "Presentation" protocol for the control aspects of FTP--but we didn't conclude from that that Telnet was a lower layer than FTP. Rather, we applied the principles of modularity to make use of a mechanism for more than one purpose--and we didn't presume to know enough about the internals of everybody else's Host to dictate how the program(s) that conferred the FTP functionality interfaced with the program(s) that conferred the Telnet functionality. That is, on some operating systems it makes sense to let FTP get at the NVT CIR by means of closed subroutine calls, on others through native IPC, and on still others by open subroutine calls (in the sense of replicating the code that does the NVT mapping within the FTP PI). Such decisions are best left to the system programmers of the several Hosts. Although the ISORM takes a similar view in principle, in practice many ISORM advocates take the model prescriptively rather than descriptively and construe it to require that PI's at a given level must communicate with each other via an "N-1 entity" even within the same Host. (Still other ISORMites construe the model as dictating "monolithic" layers--i.e., single protocols per level--but this view seems to be abating.)
One other consideration about virtualizing bears mention: it's a good servant but a bad master. That is, when you're dealing with the amount of traffic that traverses a terminal-oriented logical (or even virtual) connection, you don't worry much about how many CPU cycles you're "wasting" on mapping into and out of the NVT CIR; but
One other consideration about virtualizing bears mention: it's a good servant but a bad master. That is, when you're dealing with the amount of traffic that traverses a terminal-oriented logical (or even virtual) connection, you don't worry much about how many CPU cycles you're "wasting" on mapping into and out of the NVT CIR; but
10 RFC 871 September 1982
10 RFC 871 September 1982
when you're dealing with files that can be millions of bits long, you probably should worry--for those CPU cycles are in a fairly real sense the resources you're making sharable. Therefore, when it comes to (generic) FTP's, even though we've seen it in one or two ISORM L6 proposals, having only a virtual file conceptual model is not wise. You'd rather let one side or the other map directly between native representations where possible, to eliminate the overhead for going into and out of the CIR--for long enough files, anyway, and provided one side or the other is both willing and able to do the mapping to the intended recipient's native representation.
when you're dealing with files that can be millions of bits long, you probably should worry--for those CPU cycles are in a fairly real sense the resources you're making sharable. Therefore, when it comes to (generic) FTP's, even though we've seen it in one or two ISORM L6 proposals, having only a virtual file conceptual model is not wise. You'd rather let one side or the other map directly between native representations where possible, to eliminate the overhead for going into and out of the CIR--for long enough files, anyway, and provided one side or the other is both willing and able to do the mapping to the intended recipient's native representation.
Efficiency
Efficiency
The last point leads nicely into an axiom that is rarely acknowledged explicitly, but does belong in the ARM list of axioms: Efficiency is a concern, in several ways. In the first place, protocol mechanisms are meant to follow the design principle of Parsimony, or Least Mechanism; witness the argument immediately above about making FTP's be able to avoid the double mapping of a Virtual File approach when they can. In the second place, witness the argument further above about leaving implementation decisions to implementers. In the author's opinion, the worst mistake in the ISORM isn't defining seven (or more) layers, but decreeing that "N-entities" must communicate via "N-1 entities" in a fashion which supports the interpretation that it applies intra-Host as well as inter-Host. If you picture the ISORM as a highrise apartment building, you are constrained to climb down the stairs and then back up to visit a neighbor whose apartment is on your own floor. This might be good exercise, but CPU's don't need aerobics as far as we know.
The last point leads nicely into an axiom that is rarely acknowledged explicitly, but does belong in the ARM list of axioms: Efficiency is a concern, in several ways. In the first place, protocol mechanisms are meant to follow the design principle of Parsimony, or Least Mechanism; witness the argument immediately above about making FTP's be able to avoid the double mapping of a Virtual File approach when they can. In the second place, witness the argument further above about leaving implementation decisions to implementers. In the author's opinion, the worst mistake in the ISORM isn't defining seven (or more) layers, but decreeing that "N-entities" must communicate via "N-1 entities" in a fashion which supports the interpretation that it applies intra-Host as well as inter-Host. If you picture the ISORM as a highrise apartment building, you are constrained to climb down the stairs and then back up to visit a neighbor whose apartment is on your own floor. This might be good exercise, but CPU's don't need aerobics as far as we know.
Recalling that this paper is only secondarily about ARM "vs." ISORM, let's duly note that in the ARM there is a concern for efficiency from the perspective of participating Hosts' resources (e.g., CPU cycles and, it shouldn't be overlooked, "core") expended on interpreting protocols, and pass on to the final axiom without digressing to one or two proposed specific ISORM mechanisms which seem to be extremely inefficient.
Recalling that this paper is only secondarily about ARM "vs." ISORM, let's duly note that in the ARM there is a concern for efficiency from the perspective of participating Hosts' resources (e.g., CPU cycles and, it shouldn't be overlooked, "core") expended on interpreting protocols, and pass on to the final axiom without digressing to one or two proposed specific ISORM mechanisms which seem to be extremely inefficient.
Equity
Equity
The least known of the ARM axioms has to do with a concern over whether particular protocol mechanisms would entail undue perturbation of native mechanisms if implemented in particular Hosts. That is, however reluctantly, the ARMS designers were willing to listen to claims that "you can't implement that in my system" when particular tactics were proposed and, however
The least known of the ARM axioms has to do with a concern over whether particular protocol mechanisms would entail undue perturbation of native mechanisms if implemented in particular Hosts. That is, however reluctantly, the ARMS designers were willing to listen to claims that "you can't implement that in my system" when particular tactics were proposed and, however
11 RFC 871 September 1982
11 RFC 871 September 1982
grudgingly, retreat from a mechanism that seemed perfectly natural on their home systems to one which didn't seriously discommode a colleague's home system. A tacit design principle based on equity was employed. The classic example had to do with "electronic mail", where a desire to avoid charging for incoming mail led some FTP designers to think that the optionally mandatory "login" commands of the protocol shouldn't be mandatory after all. But the commands were needed by some operating systems to actuate not only accounting mechanisms but authentication mechanisms as well, and the process which "fielded" FTP connections was too privileged (and too busy) to contain the FTP PI as well. So (to make a complex story cryptic), a common name and password were advertised for a "free" account for incoming mail, and the login commands remained mandatory (in the sense that any Host could require their issuance before it participated in FTP).
grudgingly, retreat from a mechanism that seemed perfectly natural on their home systems to one which didn't seriously discommode a colleague's home system. A tacit design principle based on equity was employed. The classic example had to do with "electronic mail", where a desire to avoid charging for incoming mail led some FTP designers to think that the optionally mandatory "login" commands of the protocol shouldn't be mandatory after all. But the commands were needed by some operating systems to actuate not only accounting mechanisms but authentication mechanisms as well, and the process which "fielded" FTP connections was too privileged (and too busy) to contain the FTP PI as well. So (to make a complex story cryptic), a common name and password were advertised for a "free" account for incoming mail, and the login commands remained mandatory (in the sense that any Host could require their issuance before it participated in FTP).
Rather than attempt to clarify the example, let's get to its moral: The point is that how well protocol mechanisms integrate with particular operating systems can be extremely subtle, so in order to be equitable to participating systems, you must either have your designers be sophisticated implementers or subject your designs to review by sophisticated implementers (and grant veto power to them in some sense).
Rather than attempt to clarify the example, let's get to its moral: The point is that how well protocol mechanisms integrate with particular operating systems can be extremely subtle, so in order to be equitable to participating systems, you must either have your designers be sophisticated implementers or subject your designs to review by sophisticated implementers (and grant veto power to them in some sense).
It is important to note that, in the author's view, the ISORM not only does not reflect application of the Principle of Equity, but it also fails to take any explicit cognizance of the necessity of properly integrating its protocol interpreters into continuing operating systems. Probably motivated by Equity considerations, ARMS protocols, on the other hand, represent the result of intense implementation discussion and testing.
It is important to note that, in the author's view, the ISORM not only does not reflect application of the Principle of Equity, but it also fails to take any explicit cognizance of the necessity of properly integrating its protocol interpreters into continuing operating systems. Probably motivated by Equity considerations, ARMS protocols, on the other hand, represent the result of intense implementation discussion and testing.
Articulation
Articulation
Given the foregoing discussion of its axioms, and a reminder that we find it impossible in light of the existence of dozens of definitions of so fundamental a notion as "process" to believe in rigorous definitions, the ARPANET Reference Model is not going to require much space to articulate. Indeed, given further the observation that we believe reference models are supposed to be descriptive rather than prescriptive, the articulation of the ARM can be almost terse.
Given the foregoing discussion of its axioms, and a reminder that we find it impossible in light of the existence of dozens of definitions of so fundamental a notion as "process" to believe in rigorous definitions, the ARPANET Reference Model is not going to require much space to articulate. Indeed, given further the observation that we believe reference models are supposed to be descriptive rather than prescriptive, the articulation of the ARM can be almost terse.
In order to achieve efficient, equitable resource sharing among dissimilar operating systems, a layered set of interprocess communication oriented protocols is posited which typically employ common intermediate representations over logical connections. Three
In order to achieve efficient, equitable resource sharing among dissimilar operating systems, a layered set of interprocess communication oriented protocols is posited which typically employ common intermediate representations over logical connections. Three
12 RFC 871 September 1982
12 RFC 871 September 1982
layers are distinguished, each of which may contain a number of protocols.
layers are distinguished, each of which may contain a number of protocols.
The Network Interface layer contains those protocols which are presented as interfaces by communications subnetwork processors ("CSNP"; e.g., packet switches, bus interface units, etc.) The CSNP's are assumed to have their own protocol or protocols among themselves, which are not directly germane to the model. In particular, no assumption is made that CSNP's of different types can be directly interfaced to one another; that is, "internetting" will be accomplished by Gateways, which are special purpose systems that attach to CSNP's as if they were Hosts (see also "Gateways" below). The most significant property of the Network Interface layer is that bits presented to it by an attached Host will probably be transported by the underlying CSNP's to an addressed Host (or Hosts) (i.e., "reliable" comm subnets are not posited--although they are, of course, allowed). A Network layer protocol interpreter ("module") is normally invoked by a Host-Host protocol PI, but may be invoked by a Process Level/Applications protocol PI, or even by a Host process interpreting no formal protocol whatsoever.
The Network Interface layer contains those protocols which are presented as interfaces by communications subnetwork processors ("CSNP"; e.g., packet switches, bus interface units, etc.) The CSNP's are assumed to have their own protocol or protocols among themselves, which are not directly germane to the model. In particular, no assumption is made that CSNP's of different types can be directly interfaced to one another; that is, "internetting" will be accomplished by Gateways, which are special purpose systems that attach to CSNP's as if they were Hosts (see also "Gateways" below). The most significant property of the Network Interface layer is that bits presented to it by an attached Host will probably be transported by the underlying CSNP's to an addressed Host (or Hosts) (i.e., "reliable" comm subnets are not posited--although they are, of course, allowed). A Network layer protocol interpreter ("module") is normally invoked by a Host-Host protocol PI, but may be invoked by a Process Level/Applications protocol PI, or even by a Host process interpreting no formal protocol whatsoever.
The Host-Host layer contains those protocols which confer interprocess communication functionality. In the current "internet" version of the ARM, the most significant property of such protocols is the ability to direct such IPC to processes on Hosts attached to "proximate networks" (i.e., to CSNP's of various autonomous communications subnetworks) other than that of the Host at hand, in addition to those on a given proximate net. (You can, by the way, get into some marvelous technicoaesthetic arguments over whether there should be a separate Internet layer; for present purposes, we assume that the Principle of Parsimony dominates.) Another significant property of Host-Host protocols, although not a required one, is the ability to do such IPC over logical connections. Reliability, flow control, and the ability to deal with "out-of-band signals" are other properties of Host-Host protocols which may be present. (See also "TCP/IP Design Goals and Constraints", below.) A Host-Host PI is normally invoked by a Process Level/Applications PI, but may also be invoked by a Host process interpreting no formal protocol whatsoever. Also, a Host need not support more than a single, possibly notional, process (that is, the code running in an "intelligent terminal" might not be viewed by its user--or even its creator--as a formal "process", but it stands as a de facto one).
The Host-Host layer contains those protocols which confer interprocess communication functionality. In the current "internet" version of the ARM, the most significant property of such protocols is the ability to direct such IPC to processes on Hosts attached to "proximate networks" (i.e., to CSNP's of various autonomous communications subnetworks) other than that of the Host at hand, in addition to those on a given proximate net. (You can, by the way, get into some marvelous technicoaesthetic arguments over whether there should be a separate Internet layer; for present purposes, we assume that the Principle of Parsimony dominates.) Another significant property of Host-Host protocols, although not a required one, is the ability to do such IPC over logical connections. Reliability, flow control, and the ability to deal with "out-of-band signals" are other properties of Host-Host protocols which may be present. (See also "TCP/IP Design Goals and Constraints", below.) A Host-Host PI is normally invoked by a Process Level/Applications PI, but may also be invoked by a Host process interpreting no formal protocol whatsoever. Also, a Host need not support more than a single, possibly notional, process (that is, the code running in an "intelligent terminal" might not be viewed by its user--or even its creator--as a formal "process", but it stands as a de facto one).
The Process Level/Applications layer contains those protocols which perform specific resource sharing and remote access functions such as allowing users to log in/on to foreign Hosts, transferring files, exchanging messages, and the like. Protocols in this layer
The Process Level/Applications layer contains those protocols which perform specific resource sharing and remote access functions such as allowing users to log in/on to foreign Hosts, transferring files, exchanging messages, and the like. Protocols in this layer
13 RFC 871 September 1982
13 RFC 871 September 1982
will often employ common intermediate representations, or "virtual- izations", to perform their functions, but this is not a necessary condition. They are also at liberty to use the functions performed by other protocols within the same layer, invoked in whatever fashion is appropriate within a given operating system context.
will often employ common intermediate representations, or "virtual- izations", to perform their functions, but this is not a necessary condition. They are also at liberty to use the functions performed by other protocols within the same layer, invoked in whatever fashion is appropriate within a given operating system context.
Orthogonal to the layering, but consistent with it, is the notion that a "Host-Front End" protocol (H-FP), or "Host-Outboard Processing Environment" protocol, may be employed to offload Network and Host-Host layer PI's from Hosts, to Outboard Processing Environments (e.g., to "Network Front Ends", or to BIU's, where the actual PI's reside, to be invoked by the H-FP as a distributed processing mechanism), as well as portions of Process Level/Applications protocols' functionality. The most significant property of an H-FP attached Host is that it be functionally identical to a Host with inboard PI's in operation, when viewed from another Host. (That is, Hosts which outboard PI's will be attached to in a flexible fashion via an explicit protocol, rather than in a rigid fashion via the emulation of devices already known to the operating system in question.)
Orthogonal to the layering, but consistent with it, is the notion that a "Host-Front End" protocol (H-FP), or "Host-Outboard Processing Environment" protocol, may be employed to offload Network and Host-Host layer PI's from Hosts, to Outboard Processing Environments (e.g., to "Network Front Ends", or to BIU's, where the actual PI's reside, to be invoked by the H-FP as a distributed processing mechanism), as well as portions of Process Level/Applications protocols' functionality. The most significant property of an H-FP attached Host is that it be functionally identical to a Host with inboard PI's in operation, when viewed from another Host. (That is, Hosts which outboard PI's will be attached to in a flexible fashion via an explicit protocol, rather than in a rigid fashion via the emulation of devices already known to the operating system in question.)
Whether inboard or outboard of the Host, it is explicitly assumed that PI's will be appropriately integrated into the containing operating systems. The Network and Host-Host layers are, that is, effectively system programs (although this observation should not be construed as implying that any of their PI's must of necessity be implemented in a particular operating system's "hard-core supervisor" or equivalent) and their PI's must be able to behave as such.
Whether inboard or outboard of the Host, it is explicitly assumed that PI's will be appropriately integrated into the containing operating systems. The Network and Host-Host layers are, that is, effectively system programs (although this observation should not be construed as implying that any of their PI's must of necessity be implemented in a particular operating system's "hard-core supervisor" or equivalent) and their PI's must be able to behave as such.
Visualization
Visualization
Figures 1 and 2 (adapted from [6]) present, respectively, an abstract rendition of the ARPANET Reference Model and a particular version of a protocol suite designed to that model. Just as one learns in Geometry that one cannot "prove" anything from the figures in the text, they are intended only to supplement the prose description above. (At least they bear no resemblance to highrise apartment houses.)
Figures 1 and 2 (adapted from [6]) present, respectively, an abstract rendition of the ARPANET Reference Model and a particular version of a protocol suite designed to that model. Just as one learns in Geometry that one cannot "prove" anything from the figures in the text, they are intended only to supplement the prose description above. (At least they bear no resemblance to highrise apartment houses.)
TCP/IP Design Goals and Constraints
TCP/IP Design Goals and Constraints
The foregoing description of the ARM, in the interests of conciseness, deferred detailed discussion of two rather relevant topics: just what TCP and IP (the Transmission Control Protocol and the Internet Protocol) are "about", and just what role Gateways are
The foregoing description of the ARM, in the interests of conciseness, deferred detailed discussion of two rather relevant topics: just what TCP and IP (the Transmission Control Protocol and the Internet Protocol) are "about", and just what role Gateways are
14 RFC 871 September 1982
14 RFC 871 September 1982
expected to play in the model. We turn to those topics now, under separate headings.
expected to play in the model. We turn to those topics now, under separate headings.
As has been stated, with the success of the ARPANET [7] as both a proof-of-concept of intercomputer resource sharing via a packet-switched communications subnetwork and a (still) functional resource sharing network, a number of other bodies, research and commercial, developed "their own networks." Often just the communications subnetwork was intended, with the goal being to achieve remote access to attached Hosts rather than resource sharing among them, but nonetheless new networks abounded. Hosts attached to the original ARPANET or to DoD nets meant to be transferences of ARPANET technology should, it was perceived in the research community, be able to do resource sharing (i.e., interpret common high level protocols) with Hosts attached to these other networks. Thus, the first discernible goal of what was to become TCP/IP was to develop a protocol to achieve "internetting".
As has been stated, with the success of the ARPANET [7] as both a proof-of-concept of intercomputer resource sharing via a packet-switched communications subnetwork and a (still) functional resource sharing network, a number of other bodies, research and commercial, developed "their own networks." Often just the communications subnetwork was intended, with the goal being to achieve remote access to attached Hosts rather than resource sharing among them, but nonetheless new networks abounded. Hosts attached to the original ARPANET or to DoD nets meant to be transferences of ARPANET technology should, it was perceived in the research community, be able to do resource sharing (i.e., interpret common high level protocols) with Hosts attached to these other networks. Thus, the first discernible goal of what was to become TCP/IP was to develop a protocol to achieve "internetting".
At roughly the same time--actually probably chronologically prior, but not logically prior--the research community came to understand that the original ARPANET Host-Host Protocol or AH-HP (often miscalled NCP because it was the most visible component of the Network Control Program of the early literature) was somewhat flawed, particularly in the area of "robustness." The comm subnet was not only relied upon to deliver messages accurately and in order, but it was even expected to manage the transfer of bits from Hosts to and from its nodal processors over a hardware interface and "link protocol" that did no error checking. So, although the ARPANET-as-subnet has proven to be quite good in managing those sorts of things, surely if internetting were to be achieved over subnets potentially much less robust than the ARPANET subnet, the second discernible goal must be the reliability of the Host-to-Host protocol. That is, irrespective of the properties of the communications subnetworks involved in internetting, TCP is to furnish its users--whether they be processes interpreting formal protocols or simply processes communicating in an ad hoc fashion--with the ability to communicate as if their respective containing Hosts were attached to the best comm subnet possible (e.g., a hardwired connection).
At roughly the same time--actually probably chronologically prior, but not logically prior--the research community came to understand that the original ARPANET Host-Host Protocol or AH-HP (often miscalled NCP because it was the most visible component of the Network Control Program of the early literature) was somewhat flawed, particularly in the area of "robustness." The comm subnet was not only relied upon to deliver messages accurately and in order, but it was even expected to manage the transfer of bits from Hosts to and from its nodal processors over a hardware interface and "link protocol" that did no error checking. So, although the ARPANET-as-subnet has proven to be quite good in managing those sorts of things, surely if internetting were to be achieved over subnets potentially much less robust than the ARPANET subnet, the second discernible goal must be the reliability of the Host-to-Host protocol. That is, irrespective of the properties of the communications subnetworks involved in internetting, TCP is to furnish its users--whether they be processes interpreting formal protocols or simply processes communicating in an ad hoc fashion--with the ability to communicate as if their respective containing Hosts were attached to the best comm subnet possible (e.g., a hardwired connection).
The mechanizations considered to achieve reliability and even those for internetting were alien enough to AH-HP's style, though, and the efficiency of several of AH-HP's native mechanisms (particularly Flow Control and the notion of a Control Link) had been questioned often enough, that a good Host-Host protocol could not be a simple extension of AH-HP. Thus, along with the desire for reliability came a necessity to furnish a good Host-Host protocol, a
The mechanizations considered to achieve reliability and even those for internetting were alien enough to AH-HP's style, though, and the efficiency of several of AH-HP's native mechanisms (particularly Flow Control and the notion of a Control Link) had been questioned often enough, that a good Host-Host protocol could not be a simple extension of AH-HP. Thus, along with the desire for reliability came a necessity to furnish a good Host-Host protocol, a
15 RFC 871 September 1982
15 RFC 871 September 1982
design goal easy to overlook. This is a rather subtle issue in that it brings into play a wealth of prior art. For present purposes, in practical terms it means that the "good" ideas (according to the technical intuition of the designers) of AH-HP--such as sockets, logical connections, Well-Known Sockets, and in general the interprocess communication premise--are retained in TCP without much discussion, while the "bad" ideas are equally tacitly jettisoned in favor of ones deemed either more appropriate in their own right or more consistent with the other two goals.
design goal easy to overlook. This is a rather subtle issue in that it brings into play a wealth of prior art. For present purposes, in practical terms it means that the "good" ideas (according to the technical intuition of the designers) of AH-HP--such as sockets, logical connections, Well-Known Sockets, and in general the interprocess communication premise--are retained in TCP without much discussion, while the "bad" ideas are equally tacitly jettisoned in favor of ones deemed either more appropriate in their own right or more consistent with the other two goals.
It could be argued that other goals are discernible, but the three cited--which may be restated and compressed as a desire to offer a good Host-Host protocol to achieve reliable internetting--are challenging enough, when thought about hard for a few years, to justify a document of even more than this one's length. What of the implied and/or accepted design constraints, though?
It could be argued that other goals are discernible, but the three cited--which may be restated and compressed as a desire to offer a good Host-Host protocol to achieve reliable internetting--are challenging enough, when thought about hard for a few years, to justify a document of even more than this one's length. What of the implied and/or accepted design constraints, though?
The first discernible design constraint borders on the obvious: Just as the original ARPANET popularized packet-switching (and, unfortunately to a lesser extent, resource sharing), its literature popularized the notion of "Layering." Mechanistically, layering is easy to describe: the control information of a given protocol must be treated strictly as data by the next "lower" protocol (with processes "at the top," and the/a transmission medium "at the bottom"), as discussed earlier. Philosophically, the notion is sufficiently subtle that even today researchers of good will still argue over what "proper" layering implies, also as discussed earlier. For present purposes, however, it suffices to observe the following: Layering is a useful concept. The precise set of functions offered by a given layer is open to debate, as is the precise number of layers necessary for a complete protocol suite to achieve resource sharing. (Most researchers from the ARPANET "world" tend to think of only three layers--the process, applications, or user level; the Host-Host level; and the network level--though if pressed they acknowledge that "the IMPs must have a protocol too." Adherents of the International Standards Organization's "Open System Interconnection" program--which appears to be how they spell resource sharing--claim that seven is the right number of levels--though if pressed they acknowledge that "one or two of them have sublevels." And adherents of the Consultative Committee for International Telephony and Telegraphy don't seem particularly concerned with resource sharing to begin with.) At any rate, TCP and IP are constrained to operate in a (or possibly in more than one) layered protocol hierarchy. Indeed, although it is not the sole reason, this fact is the primary rationale for separating the internetting mechanization into a discrete protocol (the Internet Protocol: IP). In other words, although designed
The first discernible design constraint borders on the obvious: Just as the original ARPANET popularized packet-switching (and, unfortunately to a lesser extent, resource sharing), its literature popularized the notion of "Layering." Mechanistically, layering is easy to describe: the control information of a given protocol must be treated strictly as data by the next "lower" protocol (with processes "at the top," and the/a transmission medium "at the bottom"), as discussed earlier. Philosophically, the notion is sufficiently subtle that even today researchers of good will still argue over what "proper" layering implies, also as discussed earlier. For present purposes, however, it suffices to observe the following: Layering is a useful concept. The precise set of functions offered by a given layer is open to debate, as is the precise number of layers necessary for a complete protocol suite to achieve resource sharing. (Most researchers from the ARPANET "world" tend to think of only three layers--the process, applications, or user level; the Host-Host level; and the network level--though if pressed they acknowledge that "the IMPs must have a protocol too." Adherents of the International Standards Organization's "Open System Interconnection" program--which appears to be how they spell resource sharing--claim that seven is the right number of levels--though if pressed they acknowledge that "one or two of them have sublevels." And adherents of the Consultative Committee for International Telephony and Telegraphy don't seem particularly concerned with resource sharing to begin with.) At any rate, TCP and IP are constrained to operate in a (or possibly in more than one) layered protocol hierarchy. Indeed, although it is not the sole reason, this fact is the primary rationale for separating the internetting mechanization into a discrete protocol (the Internet Protocol: IP). In other words, although designed
16 RFC 871 September 1982
16 RFC 871 September 1982
"for" the ARM, TCP and IP are actually so layered as to be useful even outside the ARM.
"for" the ARM, TCP and IP are actually so layered as to be useful even outside the ARM.
It should be noted that as a direct consequence of the Layering constraint, TCP must be capable of operating "above" a functionally- equivalent protocol other than IP (e.g., an interface protocol directly into a proximate comm subnet, if internetting is not being done), and IP must be capable of supporting user protocols other than TCP (e.g., a non-reliable "Real-Time" protocol).
It should be noted that as a direct consequence of the Layering constraint, TCP must be capable of operating "above" a functionally- equivalent protocol other than IP (e.g., an interface protocol directly into a proximate comm subnet, if internetting is not being done), and IP must be capable of supporting user protocols other than TCP (e.g., a non-reliable "Real-Time" protocol).
Resisting the temptation to attempt to do justice to the complexities of Layering, we move on to a second design constraint, which also borders on the obvious: Only minimal assumptions can be made about the properties of the various communications subnetworks in play. (The "network" composed of the concatenation of such subnets is sometimes called "a catenet," though more often--and less picturesquely--merely "an internet.") After all, the main goal is to let processes on Hosts attached to, essentially, "any old (or new) net" communicate, and to limit that communication to processes on Hosts attached to comm subnets that, say, do positive acknowledgments of message delivery would be remiss. [8]
Resisting the temptation to attempt to do justice to the complexities of Layering, we move on to a second design constraint, which also borders on the obvious: Only minimal assumptions can be made about the properties of the various communications subnetworks in play. (The "network" composed of the concatenation of such subnets is sometimes called "a catenet," though more often--and less picturesquely--merely "an internet.") After all, the main goal is to let processes on Hosts attached to, essentially, "any old (or new) net" communicate, and to limit that communication to processes on Hosts attached to comm subnets that, say, do positive acknowledgments of message delivery would be remiss. [8]
Given this constraint, by the way, it is quite natural to see the more clearly Host-to-Host functions vested in TCP and the more clearly Host-to-catenet functions vested in IP. It is, however, a misconception to believe that IP was designed in the expectation that comm subnets "should" present only the "lowest common denominator" of functionality; rather, IP furnishes TCP with what amounts to an abstraction (some would say a virtualization--in the ARPANET Telnet Protocol sense of virtualizing as meaning mapping from/to a common intermediate representation to/from a given native representation) of the properties of "any" comm subnet including, it should be noted, even one which presents an X.25 interface. That is, IP allows for the application to a given transmission of whatever generic properties its proximate subnet offers equivalents for; its design neither depends upon nor ignores the presence of any property other than the ability to try to get some packet of bits to some destination, which surely is an irreducible minimum for the functionality of anything one would be willing to call a network.
Given this constraint, by the way, it is quite natural to see the more clearly Host-to-Host functions vested in TCP and the more clearly Host-to-catenet functions vested in IP. It is, however, a misconception to believe that IP was designed in the expectation that comm subnets "should" present only the "lowest common denominator" of functionality; rather, IP furnishes TCP with what amounts to an abstraction (some would say a virtualization--in the ARPANET Telnet Protocol sense of virtualizing as meaning mapping from/to a common intermediate representation to/from a given native representation) of the properties of "any" comm subnet including, it should be noted, even one which presents an X.25 interface. That is, IP allows for the application to a given transmission of whatever generic properties its proximate subnet offers equivalents for; its design neither depends upon nor ignores the presence of any property other than the ability to try to get some packet of bits to some destination, which surely is an irreducible minimum for the functionality of anything one would be willing to call a network.
Finally, we take note of a design constraint rarely enunciated in the literature, but still a potent factor in the design process: Probably again stemming from the popularity of the original ARPANET, as manifested in the number of types of Hosts (i.e., operating systems) attached to it, minimal assumptions are made about the nature or even the "power" of the Hosts which could implement TCP/IP. Clearly, some notion of process is necessary if there is to
Finally, we take note of a design constraint rarely enunciated in the literature, but still a potent factor in the design process: Probably again stemming from the popularity of the original ARPANET, as manifested in the number of types of Hosts (i.e., operating systems) attached to it, minimal assumptions are made about the nature or even the "power" of the Hosts which could implement TCP/IP. Clearly, some notion of process is necessary if there is to
17 RFC 871 September 1982
17 RFC 871 September 1982
be interprocess communication, but even here the entire Host might constitute a single process from the perspective of the catenet. Less clearly, but rather importantly, Hosts must either "be able to tell time" or at least be able to "fake" that ability; this is in order to achieve the reliability goal, which leads to a necessity for Hosts to retransmit messages (which may have gotten lost or damaged in the catenet), which in turn leads to a necessity to know when to retransmit. It should be noted, however, that this does not preclude a (presumably quite modestly endowed) Host's simply going into a controlled loop between transmissions and retransmitting after enough megapasses through the loop have been made--if, of course, the acknowledgment of receipt of the transmission in question has not already arrived "in the meantime."
be interprocess communication, but even here the entire Host might constitute a single process from the perspective of the catenet. Less clearly, but rather importantly, Hosts must either "be able to tell time" or at least be able to "fake" that ability; this is in order to achieve the reliability goal, which leads to a necessity for Hosts to retransmit messages (which may have gotten lost or damaged in the catenet), which in turn leads to a necessity to know when to retransmit. It should be noted, however, that this does not preclude a (presumably quite modestly endowed) Host's simply going into a controlled loop between transmissions and retransmitting after enough megapasses through the loop have been made--if, of course, the acknowledgment of receipt of the transmission in question has not already arrived "in the meantime."
To conclude with a formulation somewhere between the concise and the terse, TCP/IP are to constitute a means for processes on Hosts about which minimal assumptions are made to do reliable interprocess communication in a layered protocol suite over a catenet consisting of communications subnetworks about which minimal assumptions are made. Though it nearly goes without saying, we would probably be remiss not to conclude by observing that that's a lot harder to do than to say.
To conclude with a formulation somewhere between the concise and the terse, TCP/IP are to constitute a means for processes on Hosts about which minimal assumptions are made to do reliable interprocess communication in a layered protocol suite over a catenet consisting of communications subnetworks about which minimal assumptions are made. Though it nearly goes without saying, we would probably be remiss not to conclude by observing that that's a lot harder to do than to say.
Gateways
Gateways
One other aspect of the ARPANET Reference Model bears separate mention. Even though it is an exceedingly fine point as to whether it's actually "part" of the Model or merely a sine qua non contextual assumption, the role of Gateways is of considerable importance to the functioning of the Internet Protocol, IP.
One other aspect of the ARPANET Reference Model bears separate mention. Even though it is an exceedingly fine point as to whether it's actually "part" of the Model or merely a sine qua non contextual assumption, the role of Gateways is of considerable importance to the functioning of the Internet Protocol, IP.
As noted, the defining characteristic of a Gateway is that it attaches to two or more proximate comm subnets as if it were a Host. That is, from "the network's" point of view, Gateways are not distinguished from Hosts; rather, "normal" traffic will go to them, addressed according to the proximate net's interface protocol. However, the most important property of Gateways is that they interpret a full version of IP which deals with internet routing (Host IP interpreters are permitted to take a static view of routing, sending datagrams which are destined for Hosts not directly attached to the proximate net to a known Gateway, or Gateways, addressed on the proximate net), as well of course, as with fragmentation of datagrams which, although of permissible size on one of their proximate nets, are too large for the next proximate net (which contains either the target Host or still another Gateway).
As noted, the defining characteristic of a Gateway is that it attaches to two or more proximate comm subnets as if it were a Host. That is, from "the network's" point of view, Gateways are not distinguished from Hosts; rather, "normal" traffic will go to them, addressed according to the proximate net's interface protocol. However, the most important property of Gateways is that they interpret a full version of IP which deals with internet routing (Host IP interpreters are permitted to take a static view of routing, sending datagrams which are destined for Hosts not directly attached to the proximate net to a known Gateway, or Gateways, addressed on the proximate net), as well of course, as with fragmentation of datagrams which, although of permissible size on one of their proximate nets, are too large for the next proximate net (which contains either the target Host or still another Gateway).
18 RFC 871 September 1982
18 RFC 871 September 1982
Aside from their role in routing, another property of Gateways is also of significance: Gateways do not deal with protocols above IP. That is, it is an explicit assumption of the ARM that the catenet will be "protocol compatible", in the sense that no attempt will be made to translate or map between dissimilar Host-Host protocols (e.g., TCP and AH-HP) or dissimilar Process-level protocols (e.g., ARPANET FTP and EDN FTP) at the Gateways. The justifications for this position are somewhat complex; the interested reader is encouraged to see Reference [10]. For present purposes, however, it should suffice to note that the case against translating/mapping Gateways is a sound one, and that, as with the ARMS protocols, the great practical virtue of what are sometimes called "IP Gateways" is that they are in place and running.
Aside from their role in routing, another property of Gateways is also of significance: Gateways do not deal with protocols above IP. That is, it is an explicit assumption of the ARM that the catenet will be "protocol compatible", in the sense that no attempt will be made to translate or map between dissimilar Host-Host protocols (e.g., TCP and AH-HP) or dissimilar Process-level protocols (e.g., ARPANET FTP and EDN FTP) at the Gateways. The justifications for this position are somewhat complex; the interested reader is encouraged to see Reference [10]. For present purposes, however, it should suffice to note that the case against translating/mapping Gateways is a sound one, and that, as with the ARMS protocols, the great practical virtue of what are sometimes called "IP Gateways" is that they are in place and running.
"Architectural" Highlights
"Architectural" Highlights
As was implied earlier, one of the problems with viewing a reference model prescriptively rather than descriptively is that the articulation of the model must be more precise than appears to be humanly possible. That the ISORM, in striving for superhuman precision, fails to achieve it is not grounds for censure. However, by reaching a degree of apparent precision that has enticed at least some of its readers to attempt to use it in a prescriptive fashion, the ISORM has introduced a number of ambiguities which have been attributed as well to the ARM by relative laymen in intercomputer networking whose initial exposure to the field was the ISORM. Therefore, we conclude this not-very-rigorous paper with a highly informal treatment of various points of confusion stemming from attempting to apply the ISORM to the ARM.
より早く含意されたように、規範モデルを描写的であるというよりむしろ規範的に見ることに関する問題の1つは人間的に可能であるように見えるよりモデルの歯切れが正確であるに違いないということです。 ISORMが超人的な精度を求めて努力する際にそれを達成しないのは、非難の根拠ではありません。 しかしながら、少なくとも何人かの読者が、規範的なファッションでそれを使用するのを試みるのを誘惑した1段階の見かけの精度に達することによって、ISORMはまた、相対的な俗人によってその分野への初期の露出がISORMであったintercomputerネットワークでARMの結果と考えられた多くのあいまいさを導入しました。 したがって、ISORMを適用するのを試みるので、私たちは様々なポイントの混乱ステミングの非常に非公式の処理をもってこの非常に厳しくない紙をARMに結論づけます。
(It should be noted, by the way, that one of the most striking ambiguities about the ISORM is just what role X.25 plays in it: We have been informed by a few ISORMites that X.25 "is" Levels 1-3, and we accepted that as factual until we were told during the review process of the present paper that "that's not what we believe in the U.K." What follows, then, is predicated on the assumption that the earlier reports were probably but not definitely accurate--and if it turns out to be in time to help prevent ISO from embracing X.25 exclusively by pointing out some of the problems entailed, so much the better.)
( ISORMに関する最も衝撃的なあいまいさの1つがX.25がそれでまさしくどんな役割を果たすかということであることにところで、注意されるべきです; 私たちにそのX.25が「ある」といういくつかのISORMites Levels1-3によって知らされました、そして、ISOが排他的に問題のいくつかが伴った指示でX.25を抱擁するのを防ぐのを助ける時間あるようにレビューの間、以前のレポートが確実にない、しかし、たぶん正確であったという前提で叙述されて、判明するなら次に「それはイギリスの私たちが信じていることではありません」Whatが続く現在の新聞の過程がそうであると言われるまで、それが事実上であると受け入れました、尚更良いです; )
"Customized Parking Garages"
「車庫を駐車しながら、カスタム設計されます」
The typical picture of the ISORM shows what looks like two highrises with what looks like two parking garages between them. (That is, seven layers of protocol per "Data Terminal Equipment", three layers per "Data Circuit Terminating Equipment".) The problem
ことでhighrisesされるISORMの絵が、2に似ているものに示す典型的はそれらの間の2つの駐車場に似ています。 (「データ回線終端装置」あたりそれは7つの層の「データ端末装置」あたりのプロトコルに3つの層です。) 問題
19 RFC 871 September 1982
19 RFC871 1982年9月
is that only one "style" of parking garage--i.e., one which presents an X.25 interface--is commonly understood to be available to stand beside an ISORM DTE by those who believe that ISO has adopted X.25 as its L1-3. In the ARM, on the other hand, no constraints are levied on the Communications Subnetwork Processors. Thus, satellite communications, "Packet Radios", "Ethernets" and the like are all accommodated by the ARM.
駐車場(すなわち、X.25インタフェースを提示するもの)の「スタイル」が利用可能であることが一般的に理解されているその唯一のものがISOがL1-3としてX.25を採用したと信じている人によるISORM DTEの横のスタンドですか? 他方では、ARMでは、規制は全くCommunications Subnetwork Processorsに徴収されません。 したがって、衛星通信、「パケットラジオ」、「イーサネット」、および同様のものはARMによってすべて対応されます。
Also, the sort of Outboard Processing Environment mentioned earlier in which networking protocols are interpreted on behalf of the Host in a distributed processing fashion is quite comfortably accommodated by the ARM. This is not to say that one couldn't develop an OPE for/to the ISORM, but rather that doing so does not appear to us to be natural to it, for at least two reasons: 1. The Session Level associates sockets with processes, hence it belongs "inboard". The Presentation Level involves considerable bit-diddling, hence it belongs "outboard". The Presentation Level is, unfortunately, above the Session Level. This seems to indicate that outboard processing wasn't taken into account by the formulators of the ISORM. 2. Although some ISORMites have claimed that "X.25 can be used as a Host-Front End Protocol", it doesn't look like one to us, even if the ability to do end-to-end things via what is nominally the Network interface is somewhat suggestive. (Those who believe that you need a protocol as strong as TCP below X.25 to support the virtual circuit illusion might argue that you've actually outboarded the Host-Host layer, but both the X.25 spec and the ISORM appeal to protocols above X.25 for full L II functionality.) Perhaps, with sufficient ingenuity, one might use X.25 to convey an H-FP, but it seems clear it isn't meant to be one in and of itself.
また、ネットワーク・プロトコルが分散処理ファッションによるHostを代表して解釈されるより早く言及されたOutboard Processing Environmentの種類はARMによって全くゆったり設備されます。 これは少なくとも2つの理由でそれに自然になるように人が/のためにISORMにOPEを開発できませんでしたが、むしろ、そうするのが私たちにとって現れないと言わないためのものです: 1. Session Levelはソケットを過程に関連づけます、したがって、それが「内側に」属します。 Presentation Levelはかなりのビットだますことにかかわります、したがって、それが「船外で」属します。 残念ながら、Session Levelの上にPresentation Levelがあります。 これは船外の処理がISORMの調合剤によって考慮に入れられなかったのを示すように思えます。 2. いくつかのISORMitesが、「Host-前部EndプロトコルとしてX.25を使用できます」と主張しましたが、私たちに1つに似ていません、ことで終わりから終わりへのことをする能力が名目上は、Networkインタフェースがいくらか思わせ振りであるということであっても。 (あなたが仮想のサーキット幻想を支持するためにX.25の下でTCPと同じくらい強いプロトコルを必要とすると信じている人は、あなたが実際にHost-ホスト層に外到達したと主張するかもしれませんが、X.25仕様とISORMの両方が完全なL IIの機能性のためにX.25の上でプロトコルに求めます。) 恐らく、十分な巧みさと共に、1つはH-FPを運ぶのにX.25を使用するかもしれませんが、そういうものの1であるようにそれが意味されないのが明確に思えます。
"Plenty of Roads"
「多くの道路」
Based upon several pictures presented at conferences and in articles, DCE's in the X.25-based ISORM appear to many to be required to present X.25 interfaces to each other as well as to their DTE's. Metaphorically, the parking garages have single bridges between them. In the ARM, the CSNP-CSNP protocol is explicitly outside the model, thus there can be as many "roads" as needed between the ARM equivalent to ISORM parking garages. This also allays fears about the ability to take advantage of alternate routing in X.25 subnets or in X.75 internets (because both X.25 and X.75 are "hop-by-hop" oriented, and would not seem to allow for alternate routing without revision).
会議において記事に提示されたいくつかの絵に基づいて、X.25ベースのISORMのDCEのものは見えますそれらのDTEのものに関してまた、互いにインタフェースをX.25に提示するのが必要であるべき多くに。 比喩的に、駐車場の間には、単一の橋があります。 ARMでは、CSNP-CSNPプロトコルはその結果、モデルの外に、明らかに、ISORM駐車場に同等なARMの間で必要とされるのと同じくらい多くの「道路」があることができるということです。 また、これはX.25サブネットかX.75インターネットにおける迂回中継を利用する能力に関する恐怖を鎮めます(X.25とX.75の両方が、「ホップごとの」適応して、改正なしで迂回中継を考慮するように思えないでしょう、したがって)。
20 RFC 871 September 1982
20 RFC871 1982年9月
"Multiple Apartments Per Floor"
「複数の1床あたりのアパート」
As noted, the ISORM's strictures on inter-entity communication within each "highrise" are equivalent to having to climb downstairs and then back up to visit another apartment on your own floor. The ARM explicitly expects PI's within a layer to interface directly with one another when appropriate, metaphorically giving the effect of multiple apartments on each floor off a common hallway. (Also, for those who believe the ISORM implies only one protocol/apartment per layer/story, again the ARM is more flexible.)
注意されるように、それぞれ中の"highriseする"であるという相互実体コミュニケーションにおけるISORMの狭窄はあなた自身の床の上の別のアパートを訪問するために階下に登って、次に、支援しなければならないために同等です。 適切であるときに、ARMは、層の中のPIのものが直接お互いに連結すると明らかに予想します、一般的な廊下で比喩的に各床への複数のアパートの効果を与えて。 (また、ISORMが層/話あたり1つのプロトコル/アパートだけを含意すると信じている人に関して、一方、ARMも、よりフレキシブルです。)
"Elevators"
「エレベーター」
The ISORM is widely construed as requiring each layer to be traversed on every transmission (although there are rumors of the forthcoming introduction of "null layers"), giving the effect of having to climb all seven stories' worth of stairs every time you enter the highrise. In the ARM, only Layer I, the Network Interface layer, must be traversed; protocols in Layers II and/or III need not come into play, giving the effect of being able to take an elevator rather than climb the stairs.
各層があらゆるトランスミッションのときに横断されるのが必要にISORMは広く理解されています(「ヌル層」の今度の導入の噂がありますが)、あなたが入るときはいつも、すべての7つの話の階段の価値を登らなければならないという効果を与えてhighrise ARMでは、Layer I(Network Interface層)だけを横断しなければなりません。 II、そして/または、IIIが入る必要はないLayersのプロトコルはプレーします、階段を登るよりむしろエレベーターに乗ることができるという効果を与えて。
"Straight Clotheslines"
「まっすぐな物干し綱」
Because they appear to have to go down to L3 for their initiation, the ISORM's Session and Transport connections are, to us, metaphorically tangled clotheslines; the ARM's logical connections are straight (and go from the second floor to the second floor without needing a pole that gets in the way of the folks on the third floor--if that doesn't make a weak metaphor totally feeble.)
彼らの開始、ISORMのSession、およびTransport接続のためのL3に、彼らが、落ちなければならないように見えるのが、私たちへの比喩的にもつれている物干し綱の理由です。 ARMの論理的な接続は異性愛者です。(弱い比喩がそれで完全に弱くならないなら3階で人々の邪魔をするポールを必要としないで、2階から2階まで行ってください。)
"Townhouse Styles Available"
「利用可能なタウンハウス様式」
Should ISORM Level 6 and 7 protocols eventuate which are desirable, the "two-story townhouse style apartments" they represent can be erected on an ARM L I - L II (Network Interface and Host-Host Layers) "foundation". With some clever carpentry, even ISORM L5 might be cobbled in.
望ましいです、彼らが表す「2階建てのタウンハウススタイルアパート」がARM L I--L IIで建設された(ネットワークInterfaceとHost-ホストLayers)「基礎」であることができるということであるISORM Level6と7プロトコルはeventuateされるべきですか? 何らかの賢明な大工仕事で、ISORM L5さえ中で修繕されるかもしれません。
"Manned Customs Sheds"
「有人の税関上屋」
Although it's straining the architectural metaphor quite hard, one of the unfortunate implications of the ISORM's failure to address operating system integration issues is that the notion of "Expedited Data" exchanges between "peer entities" might only amount to an SST flight to a foreign land where there's no one on duty at
全く強く建築比喩を曲解していますが、ISORMがオペレーティングシステム統合問題を記述しないことの不幸な含意の1つは「同輩実体」の間の「速められたデータ」交換の概念が勤務中であることの人はだれもいない異郷行きのSSTフライトに達するだけであるかもしれないということです。
21 RFC 871 September 1982
21 RFC871 1982年9月
the Customs Shed (and the door to the rest of the airport is locked from the other side). By clearly designating the Host-Host (L II) mechanism(s) which are to be used by Layer III (Process-Level/ Applications) protocols to convey "out-of-band signals", the ARM gives the effect of keeping the Customs Sheds manned at all times. (It should be noted, by the way, that we acknowledge the difficulty of addressing system integration issues without biasing the discussion toward particular systems; we feel, however, that not trying to do so is far worse than trying and failing to avoid all parochialism.)
税関Shed(空港の残りへのドアは反対側からロックされます)。 「バンドで出ている信号」を運ぶために明確にLayer IIIによって使用されることであるHost-ホスト(L II)メカニズム(過程レベル/アプリケーション)をプロトコルに指定することによって、ARMはいつも税関Shedsを配置し続けるという効果を与えます。 (私たちが特定のシステムに向かって議論に偏ることのないシステムインテグレーション問題を記述するという困難を承認することにところで、注意されるべきです; しかしながら、私たちは、試みて、すべての小教区制度を避けるのに失敗するよりそうしようとしないのがはるかに悪いと感じます。)
"Ready For Immediate Occupancy"
「即座の占有の、準備ができています」。
The ARM protocol suite has been implemented on a number of different operating systems. The ISORM protocol suite "officially" offers at most (and not in the U.K., it should be recalled) only the highly constraining functionality of X.25 as L1-L3; L4-L7 are still in the design and agreement processes, after which they must presumably be subjected to stringent checkout in multiple implementations before becoming useful standards. The metaphorical highrises, then, are years away from being fit for occupancy, even if one is willing to accept the taste of the interior decorators who seem to insist on building in numerous features of dubious utility and making you take fully furnished apartments whether you like it or not; the ARM buildings, on the other hand, offer stoves and refrigerators, but there's plenty of room for your own furniture-- and they're ready for immediate occupancy.
ARMプロトコル群は多くの異なったオペレーティングシステムで実行されました。ISORMプロトコル群はL1-L3として「公式に」X.25の非常に抑制している機能性だけを高々(いずれのイギリスでも、それを思い出すべきでない)提供します。 L4-L7がまだデザインと協定の過程にあります。(おそらく、その時、役に立つ規格になる前に、複数の実現における厳しいチェックアウトにそれらをかけなければなりませんでした後)。 比喩的はhighrisesされます、そして人が、疑わしいユーティリティの多数の特徴に建てると主張するように思えるインテリアデザイナーの味を受け入れても構わないと思っていて、あなたがそれが好きであるか否かに関係なく、あなたに取らせるのがアパートを完全に提供したとしても占有に適しているので離れている年はそうです。 あなた自身の家具の多くの余地があります、そして、ARMビルは他方ではストーブと冷蔵庫を提供しますが、それらは即座の占有の準備ができています。
Conclusion
結論
The architectural metaphor might have been overly extended as it was, but it could have been drawn out even further to point up more issues on which the ARM appears to us to be superior to the ISORM, if our primary concern were which is "better". In fairness, the one issue it omitted which many would take to be in the ISORM's favor is that "vendor support" of interpreters of the ISORM protocols will eventually amount to a desirable "prefabrication", while the building of the ARM PI's is believed to be labor-intensive. That would indeed be a good point, if it were well-founded. Unfortunately for its proponents, however, close scrutiny of the vendor support idea suggests that it is largely illusory (vide [11]), especially in light of the amount of time it will take for the international standardization process to run its course, and the likelihood that specification ambiguities and optional features will handicap interoperability. Rather than extend the present paper even further, then, it seems fair to conclude that with the possible exception of "vendor support" (with which exception we take
建築比喩はそれのようにひどく拡張されていたかもしれませんが、それはISORMより優れるようにARMが私たちにとって載っているさらに多くの問題へのポイントに加えてさえ引き出されたかもしれません、私たちの第一の関心がどれが「より良いか」ということであるなら。 公正では、それが省略した多くがISORMの好意にはあるように取る1冊はISORMプロトコルのインタプリタの「業者サポート」が結局望ましい「プレハブ」に達するということです、ARM PIのビルが労働集約的であると信じられていますが。 それがゆるぎないなら、本当に、それは長所でしょうに。 残念ながら、しかしながら、提案者に関して、業者サポート考えの厳密な調査は、それが主に非現実的であると示唆します。([11])を参照してください、特に自然の経過をたどるには国際標準化の過程にかかる時間、および仕様のあいまいさとオプション機能が相互運用性にハンディキャップをつけるという見込みの観点から。 次に、むしろ、「業者サポート」の可能な例外でそれを結論づけるのがさらにさえ現在の新聞を広げているより公正に思える、(私たちはどの例外を取りますか。
22 RFC 871 September 1982
22 RFC871 1982年9月
exception, for it should be noted that a number of vendors are already offering support for TCP/IP), the ARPANET Reference Model and the protocols designed in conformance with it are at least worthy of consideration by anybody who's planning to do real inter- computer networking in the next several years--especially if they have operating systems with counterparts on the present ARPANET, so that most if not all of the labor intensive part has been taken care of already--irrespective of one's views on how good the ISORM protocols eventually will be.
多くの業者が既にTCP/IPのサポートを提供していることに注意されるべきであるので例外、それで順応で設計されたアルパネットReference Modelとプロトコルは彼らにオペレーティングシステムが現在のアルパネットの対応者と共に特にいるなら数年内に本当の相互コンピュータのネットワーク化をするのを計画しているだれによるも考慮に少なくともふさわしいです; ISORMプロトコルが結局どれくらい良くなるかに関する人の意見の如何にかかわらず既に作業の徹底的な部分の大部分かすべての世話をしてあるように。
Acknowledgments
承認
Although it has seldom been more germane to observe that "any remaining shortcomings are the author's responsibility", this paper has benefited tremendously from the close scrutiny and constructive comments of several distinguished members of both the research community and the (DoD) Protocol Standards Technical Panel. The author is not only extremely grateful to, but is also extremely pleased to acknowledge his indebtedness to the following individuals (cited in alphabetical order): Mr. Trevor Benjamin, Royal Signals and Radar Establishment (U.K.); Mr. Edward Cain, Chairman of the PSTP; Dr. Vinton Cerf, DARPA/IPTO (at the time this was written); Dr. David Clark, M.I.T. Laboratory for Computer Science (formerly Project MAC); and Dr. Jonathan Postel, U.S.C. Information Sciences Institute. Posterity may or may not thank them for their role in turning an act of personal catharsis into a fair semblance of a "real" paper, but the author emphatically does.
「どんな残っている短所も作者の責任です」と述べるのがめったにより適切ではありませんが、この紙はものすごく研究団体と(DoD)プロトコルStandards Technical Panelの両方の数人の著名なメンバーの厳密な調査と建設的なコメントの利益を得ました。 作者が非常に感謝しているだけではない、また、以下の個人(アルファベット順に引用されます)に彼の負債を承認して、非常に嬉しい、: トレバー・ベンジャミンさん、ロイヤル信号、およびレーダー設立(イギリス)。 エドワード・カインさん、PSTPの議長。 ビントン・サーフ博士、DARPA/IPTO(これが書かれたとき)。 デヴィッド・クラーク博士、マサチューセッツ工科大学コンピュータ科学研究所(以前プロジェクトMAC)。 そして、科学が設けるジョナサン・ポステル博士(米国)C.情報。 子孫は個人的なカタルシスの行為を「本当」の論文の公正な類似に変えることにおけるそれらの役割について彼らに感謝するかもしれませんが、作者は強調してします。
Notes and References
注意と参照
[1] It almost goes without saying that the subtheme is certainly not intended to be a definitive statement of the relative merits of the two approaches, although, as will be seen, the ARM comes out ahead, in our view. But then, the reader might well say, what else should I expect from a paper written by one of the developers of the ARM? To attempt to dispel thoughts of prejudgment, the author would observe that although he is indeed an Old Network Boy of the ARPANET, he was not a member of the TCP/IP (the keystone of the current ARM) design team, and that he began looking into ARM "vs." ISORM from the position of "a plague on both your houses". That he has concluded that the differences between TCP/IP-based ARM intercomputer networking and X.25-based ISORM intercomputer networking are like day and night may be taken as indicative of something, but that he also holds that the day is at least partly cloudy and the night is not altogether moonless should at least meliorate fears of prejudice. That is, of course the
[1] ARMは見られるようにトップになりますが確かに、副主題が2つのアプローチの優劣の決定的な声明であることを意図しないのがほとんど言うまでもないです、私たちの意見で。 しかし、読者は、次に、私が開発者のひとりによって書かれた論文からARMに他の何を予想するべきであるかとたぶん言うでしょうか? 予断裁決という考えを晴らすのを試みるために、作者は本当にアルパネットのOld Network Boyですが、彼がTCP/IP(現在のARMのかなめ石)デザインチームのメンバーでなく、「あなたの両方の家における疫病」の位置からARM “vs." ISORMを調べ始めたのを観測するでしょう。 彼が、TCP/IPベースのARM intercomputerネットワークとX.25ベースのISORM intercomputerネットワークの違いが昼夜に似ていると結論を下したのが何かの暗示としてみなされるかもしれませんが、また、彼が、日が少なくとも一部曇りであると主張して、夜が全体で月がないというわけではないのが偏見への恐怖を少なくとも改良するべきです。 それがそうである、もちろん
23 RFC 871 September 1982
23 RFC871 1982年9月
ISORM has its merits and the ARM its demerits neither of which are dealt with here. But "A Perspective" really means "My Perspective", and the author really is more concerned in this context with exposition of the ARM than with twitting the ISORM, even if he couldn't resist including the comparisons subtheme because of the one-sidedness of the ISORM publicity he has perceived of late.
ISORMには長所があります、そして、ARMには、それのどちらもここで対処されていない欠点があります。 しかし、「見解」は本当に「私の見解」を意味します、そして、作者は本当にISORMを責めるよりこのような関係においてはARMの博覧会に関係があります、彼が、彼が最近知覚したISORMの宣伝の不公平のために比較副主題を含んでいるのに抵抗できないでも。
[2] Source material for this section was primarily drawn from the author's personal experience as a member the NWG and from numerous conversations with Dr. Jonathan B. Postel, long-time Chairman of the NWG and participant in the design meetings prior to the author's involvement. (See also Acknowledgments.)
[2] NWGとジョナサンB.ポステル博士との頻繁な会話からのメンバー、作者のかかわり合いの前のデザインミーティングのNWGと関係者の長年の委員長として作者の個人的な経験からこのセクションへの資料を主として得ました。 (また、Acknowledgmentsを見てください。)
[3] Padlipsky, M. A. "The Elements of Networking Style", M81-41, The MITRE Corporation, Bedford, MA, October 1981
[3]Padlipsky、「ネットワークの原理は流行に合わせる」M.A.、M81-41、斜め継ぎ社、ベッドフォード、MA、1981年10月
[4] Yes, the notion of using "protocols" might well count as an axiom in its own right, but, no, we're not going to pretend to be that rigorous.
[4] いいえ、はい、「プロトコル」を使用するという概念はたぶんそれ自体で原理にみなすでしょうが、私たちはそんなに厳しいふりをするつもりではありません。
[5] That is, about three tenths of the possible span of "Session" functionality, which has to do with making up for the lack of Well-Known Sockets, isn't subsumed by the ARM Process-Level protocols, but the rest is, or could be.
[5] すなわち、「セッション」の機能性の可能な長さのおよそ3/10がARM Process-レベルプロトコルによって包括されていませんが、残りは、あるか、またはあるかもしれません。機能性はWellによって知られているSocketsの不足によって作成と関係があります。
[6] Davidson, J., et al., "The ARPANET Telnet Protocol: Its Purpose, Principles, Implementation, and Impact on Host Operating System Design," Proc Fifth Data Communications Symposium, ACM/IEEE, Snowbird, Utah, September, 1977.
[6] ディヴィッドソン、J.、他、「アルパネットtelnetは以下について議定書の中で述べます」。 「ホスト・オペレーティング・システムへの目的、原則、実現、および影響は設計する」、第5Procデータ通信シンポジウム、ACM/IEEE、ユキホウジロ、ユタ(1977年9月)
[7] See Proceedings of the 1970 SJCC, "Resource Sharing Computer Networks" session, and Proceedings of the 1972 SJCC, "The ARPA Network" session for the standard open literature references to the early ARPANET. Other source material for this chapter is drawn from the author's personal conversations with TCP/IP's principal developers; see also Acknowledgments.
[7] 早めのアルパネットの標準の開いている文学参照のための1970SJCC、「リソース・シェアリングコンピュータネットワーク」セッション、および1972SJCCのProceedings、「アーパネット」セッションのProceedingsを見てください。 TCP/IPの主要な開発者との作者の個人的な会話から本章のための他の資料を得ます。 また、Acknowledgmentsを見てください。
[8] A strong case can be made for desiring that the comm subnets make a "datagram" (or "connectionless") mode of interface available, based upon the desire to support such functionality as Packetized Speech, broadcast addressing, and mobile subscribers, among other things. For a more complete description of this point of view, see [9]. For present
[8] commサブネットでインタフェースの「データグラム」の、そして、(「コネクションレス」)のモードが利用可能になることを望むために強い弁護をすることができます、Packetized Speechのような機能性、ブロードキャスト・アドレッシング、および携帯電話の契約者を支持する特に願望に基づきます。 この観点の、より完全な記述に関しては、[9]を見てください。 プレゼントのために
24 RFC 871 September 1982
24 RFC871 1982年9月
purposes, we do not cite the presentation of a datagram mode interface as a design constraint because it is possible--albeit undesirable--to operate IP "on top of" a comm subnet which does not present such an interface.
目的、望ましくないのですが、それが可能であるので、私たちはデザイン規制としてデータグラムモードインタフェースのプレゼンテーションを引用しません--そのようなインタフェースを提示しないcommサブネット「上」でIPを経営するために。
[9] Cerf, V. G. and R. E. Lyons, "Military Requirements for Packet-Switched Networks and for Their Protocol Standardization" Proc EASCON 1982.
[9] サーフ、V.G.、およびR.E.リヨン(「パケット交換網と彼らのプロトコル標準化のための軍事の要件」Proc EASCON1982)。
[10] Padlipsky, M. A., "Gateways, Architectures and Heffalumps", M82-51, The MITRE Corporation, Bedford, MA, September 1982.
[10]Padlipskyと、M.A.と、「ゲートウェイ、構造、およびHeffalumps」、M82-51、斜め継ぎ社、ベッドフォード、MA、9月1982
[11] ---------- "The Illusion of Vendor Support", M82-49, The MITRE Corporation, Bedford, MA, September 1982.
[11] ---------- 「業者サポートの幻想」、M82-49、斜め継ぎ社、ベッドフォード、MA、1982年9月。
NOTE: Figure 1: ARM in the Abstract, and Figure 2: ARMS, Somewhat Particularized, may be obtained by writing to: Mike Padlipsky, MITRE Corporation, P.O. Box 208, Bedford, Massachusetts 01730, or sending computer mail to Padlipsky@USC-ISIA.
以下に注意してください。 図1: 要約、および図2で軍備してください: 以下のことのために書くことによって、ARMS(Somewhat Particularized)を入手するかもしれません。 マイクPadlipsky、MITRE社、私書箱208、ベッドフォード、マサチューセッツ 01730、またはコンピュータメールを Padlipsky@USC-ISIA に送ること。
25
25
一覧
スポンサーリンク