📄 rfc871.txt
字号:
--------- < INC-PROJECT, MAP-PERSPECTIVE.NLS.14, >, 12-Aug-83 11:34 AMW ;;;; RFC 871 September 1982 M82-47 A PERSPECTIVE ON THE ARPANET REFERENCE MODEL M.A. PADLIPSKY THE MITRE CORPORATION Bedford, Massachusetts 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). i "A PERSPECTIVE ON THE ARPANET REFERENCE MODEL" M. A. Padlipsky 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. 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 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 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.) 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 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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -