RFC 871

A PERSPECTIVE ON THE ARPANET REFERENCE MODEL 🦋

part 1 of 7 💖 more parts coming, so stay tuned

Bestie, here's the title block. The date stamp line is verbatim:

     < INC-PROJECT, MAP-PERSPECTIVE.NLS.14, >, 12-Aug-83 11:34 AMW

So this is RFC 871, written by M. A. Padlipsky of The MITRE Corporation in Bedford, Massachusetts 🎀 The header doesn't list a category, or what it obsoletes or updates, so I'm not guessing 🙈

Abstract

Okay so the author helped build this stuff, and this paper walks through the big conceptual framework the ARPANET intercomputer networking protocol suite was designed in 🧚 That includes the DoD standard Transmission Control Protocol (TCP) and Internet Protocol (IP), which are literally the main character here ✨ It also compares and contrasts a few parts of the ARPANET Reference Model (ARM) with the more famous International Standards Organization's Reference Model for Open System Interconnection (ISORM) 💅

Introduction

Okay, real talk: "the ARPANET" is the proof-of-concept of intercomputer networking, and it introduced fundamental ideas like Layering and Virtualizing to the literature 🌈 But because so much material about the International Standards Organization's Reference Model for Open System Interconnection (ISORM) is floating around, newcomers to the field keep forgetting something: the designers of the ARPANET protocol suite had their own reference model the whole time 😭 It was mostly tacit, but it was there the entire time. Long before ISO even got interested in "networking," people in the ARPA-sponsored research community were doing their research and development with a particular frame of reference in mind 💜

They were either too busy, or maybe not the type to write learned papers on abstract topics when there were interesting things to say about specific ones 🙈 So it's only recently that the research community has really noticed how much the ISORM has hit the lay mind. When the author got asked to review solemn memoranda comparing things like the ARPANET treatment of "internetting" with CCITT's approach, which uses the ISORM "as the frame of reference," the time had clearly come to publicly enunciate the ARPANET Reference Model (ARM) 📣 Those comparisons are painfully close to comparing an orange with an apple using redness and smoothness as the dominant criteria 🍓 The CCITT and ISO models are philosophically close to each other, and both are different from the ARPANET model in their own ways.

This paper is mainly a perspective on the ARM. (Secondarily, it points 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 it 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 came out in NWG general meetings, NWG protocol design committee meetings, and private conversations over the years. (Members of the current ARPA Internet Working Group, which applied and adapted the original model to a broader arena than had initially been contemplated, were also consulted.) ✨

That might not sound as impressive as a pronunciamento from an international standards organization, but here's the comfy part 🫶 The views here are claimed to be those of the primary workers in the field, and at least one Englishman helped out in the review process 🇬🇧

Historical/Philosophical Context

Okay, so rigorous historians of science might quibble over whether these ideas were "invented" by a particular group. But it's a historical fact that many now widely accepted, fundamental concepts of intercomputer networking were original to the ARPANET Network Working Group. [2] Before we appreciate what that means, let's define its two key terms and then go over the concepts it points to 🔥

By "intercomputer networking" we mean attaching multiple, usually general-purpose computer systems, which are Operating Systems of potentially different manufacture (i.e., "Heterogeneous Operating Systems"), to some communications network, or to communications networks somehow interconnected. The goal is resource sharing among the participating operating systems, which are usually called Hosts 🖥️💖 (By "resource sharing" we mean the potential for programs on each Host to interoperate with programs on the other Hosts, and for data on each Host to be made available to the other Hosts in a more general and flexible way than just letting users on each Host log in to the others as if they were local. In other words, we expect to do more than mere "remote access" to intercomputer networked Hosts.) 🦋 By "the ARPANET Network Working Group," we mean the system programmers and computer scientists from numerous Defense Advanced Research Projects Agency-sponsored installations whose home operating systems were meant to become early Hosts on the ARPANET. (By "the ARPANET" we mean, depending on context, either the communications network sponsored by DARPA that served as proof-of-concept for "packet switching," or, matching common usage, the intercomputer network the NWG evolved, which uses that communications network, or "comm subnet," as its inter-Host data transmission medium.) 🌸

The concepts of particular interest go like this. By analogy to how traditional communications uses the term, the NWG decided that the key to mechanizing the resource-sharing goal (which had been posited in their informal charter) would be "protocols" that Hosts interpret both when communicating with the comm subnet and when communicating with each other 🧠 Because the active entities in Hosts (the programs in execution) were widely called "processes" in Computer Science, it seemed clear that mechanizing resource sharing had to involve interprocess communication. Protocols that enabled and used interprocess communication became, almost axiomatically, the path to the goal ✨

Maybe the limits of mere remote access were noticed early, or maybe it was just analogy to how physical tape drives are told apart from tape drives tied to a conventionally defined function, like the System Input stream or the System Output stream in batch operating systems. Either way, the discernible communications paths (or "channels") through the desired interprocess communication mechanism became known as "logical connections" 🎀 The point of the term was 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 do 💅

"Modularity" was a big deal in Computer Science at the time, and the separation of Hosts and Interface Message Processors (IMP's) was a given. So the NWG realized the protocols it designed should be "layered" 🧅 In this sense, a given set of related functions (for example, 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 (for example, the comm subnet attachment mechanism, as realized in a Host-Comm Subnet Processor protocol). Indeed, protocols may be viewed as existing in a hierarchy 🌈

With the notion of achieving resource sharing through layered protocols for interprocess communication over logical connections fairly firmly in place, the NWG turned to the best way to achieve the first step of intercomputer networking: letting a distant user log in to a Host as if they were local 🔐 The understanding was that the mechanisms used had to be generalizable to other types of resource sharing too. This is where we get the final fundamental concept the NWG contributed. 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, that's an administratively intractable "n x m problem" 😵‍💫 The same goes if n different kinds of Host had to know about the native terminals supported by m other kinds of Hosts, in order for physical control to stay local.

So the notion of a "virtual terminal" came up, probably by analogy to "virtual memory" in the sense of something that "wasn't really there" but could be used as if it were 🧚 A common intermediate representation (CIR) of terminal characteristics was defined. That let the Host a terminal was physically attached to map the terminal's particular characteristics into a CIR. The Host being logged into, which knows the CIR as part of the relevant protocol, could then map out of it into a form already acceptable to its 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 it was 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 the ARPA research community, "the ARPANET" was seen as a major technological advance, and "Networking" became the "in" thing 🔥 With that popular success came calls 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" happen a lot, and emerging higher level protocols tend to virtualize, because after all, you'd expect 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 the ARM is by no means a whitecap. It deserves explication, both in its role as the ISORM's "roots" and as the basis of a still-viable alternative protocol suite 🦋✨

Axiomatization ✨

Okay bestie, let's start with the axioms of the ARPANET Reference Model (ARM) 🦋. So what even is an axiom? In everyday talk it's a principle whose truth is deemed self-evident 💅. That's why axioms basically never get said out loud outside of math class 🙈. But here's the tea: the ARM's axiomatization (as best we can remember and reconstruct it) is totally germane to explaining the ARM, and it's also a source of really instructive contrasts with how we see the ISORM's axiomatization. (See [1] again.) 💖

Resource Sharing

The fundamental axiom of the ARM is that intercomputer networking protocols (as distinct from communications network protocols) are meant to let heterogeneous computer operating systems ("Hosts") achieve resource sharing 🖥️✨. Fun fact: the session at the 1970 SJCC where the ARPANET first entered the open literature was literally called "Resource Sharing Computer Networks" 🎀.

Of course, as self-evident truths, axioms rarely get much scrutiny 🙃. Honestly, nobody can pin down exactly what resource sharing is, and the same goes for Open System Interconnection 😭. But it must have something to do with the programs and data on several Hosts being usable by, and together with, programs and data on other Hosts, in some sort of cooperative way 🤝. It must, that is, give the human user more functionality than just being able to log in/on to a Host miles away ("remote access") 💅.

A striking thing about this axiom is that it makes protocol suites like "X.25"/"X.28"/"X.29" kinda uninteresting for our purposes 🥱. They seem to have remote access as their only fundamental axiom. (It might even be a valid rule of thumb that any "network" which hooks up to Hosts through devices that look like milking machines, meaning it attaches as if it were just a group of locally-known types of terminals, isn't a resource sharing network 🐄💀.)

Reference [3] goes deeper into the resource sharing vs. remote access topic if you want the full tea 📚.

Interprocess Communication

The second axiom of the ARM is that resource sharing will be achieved via some sort of interprocess communication mechanism 🔁. Again, this concept isn't super well-defined in the "networking" literature 🙄. But there's some justification here, because the idea is pretty well known in the Operating Systems branch of Computer Science, which was the field most of the NWG members came from 🧠. Unfortunately, since intercomputer networking involves all kinds of communications devices, lots of people whose main field was Communications jumped into "networking" without really being able to appreciate what the axiom implied 😬.

A process can 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, it can be any one (or more) of at least 29 definitions from at least 28 reputable computer scientists 🤯. What matters for now isn't the precise definition (even if there were one), but the fact that choosing this axiom rules out at least one other axiom at the same level of abstraction 🚫. We could have tried to achieve resource sharing through an explicitly interprocedure communication oriented mechanism, where the entities being enabled to communicate were subroutines or pieces of address spaces, but we didn't 🙅‍♀️. Maybe somebody realized you could do interprocedure communication (or get a "virtual address space" or "distributed operating system" or some such formulation) on top of an interprocess communication mechanism (IPC), or maybe IPC just "seemed obvious". Honestly, it doesn't matter very much ✨. What matters is that the axiom was chosen, it assumes a fair degree of familiarity with Operating Systems, it doesn't assume extremely close coupling of Hosts, and it led to a working protocol suite that does achieve resource sharing 🏆. It also seems to be an axiom the ISORM tacitly accepted, right alongside resource sharing 👀.

Logical Connections

The next axiom is about whether and how to demultiplex IPC "channels", "routes", "paths", "ports", or "sockets" 🔀. Basically, if you're doing interprocess communication (IPC), you still have to decide whether a process can talk to more than one other process, and if so, how to tell the bit streams apart 🫠. (Fun detail: even choosing streams instead of blocks is a decision too 🌸.) Even though the literature doesn't really spell this out, it's clear the ARM's axiom is to do IPC over logical connections, in the following sense 💜.

Think about batch oriented operating systems. They found it useful to insulate processes (usually thought of as jobs, or even "programs") from the details of which physical tape drive was working well enough at a given moment to spin the System Input and Output reels 📼. They came up with the idea that a reference to a "logical tape number" would always reach the right physical drive for the defined purpose 🎯. The ARM's IPC mechanism does the same thing with logical connections between processes 🪄. So the IPC addressing mechanism has semantics as well as syntax 🧁.

"Socket" n on any participating Host is defined as the "Well-Known Socket" (W-KS) where a particular service is found, meaning the program that follows, or "interprets", a particular protocol [4] 🔌. (Note that the W-KS is defined for the "side" of a connection where a given service lives. The user side, so it can demultiplex its network-using processes, will of course assign different numbers to its "sides" of connections to a given W-KS 🙋‍♀️. Also, the serving side takes into account the using side's Host designation as well as the offered socket, so it can demultiplex too 💅.) Obviously you want free sockets as well as Well-Known ones, and we have them 🥰. In fact, at each level of the ARM hierarchy, the addressing entities are divided into assigned and unassigned sets. That distinction has proven super useful to networking researchers, because it lets them experiment with new functions without interfering with running mechanisms 🧪🦋.

Here the ISORM is different from the ARM 🙃. ISORM "peer-peer" connections (or "associations") seem to be used only for demultiplexing, with the number assigned by the receive side rather than the send side 📥. That means a separate protocol gets introduced 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 way cleaner than "virtual" connections. (By "virtual" I mean something that "isn't really there" but can be used as if it were, like virtual memory, as noted above. It also nods to the X.25 term "virtual circuit", which seems to have dictated the receiver-assigned posture the ISORM takes at its higher levels 🙄.) Although the ISORM view "works", the W-KS approach avoids introducing an extra protocol 💖.

Layering

The next axiom is probably the best-known, and almost certainly the worst-understood 💀. As best we can reconstruct things, the NWG was really into the Computer Science buzzword of the time, "modularity" 🧩. "Everybody knew" modularity was a Good Thing 🙌. Plus, we got a head start because the IMPs weren't under our direct control anyway. They could possibly change at some future date, and we didn't want to get "locked in" to the then-current IMP-Host protocol 🔒. So it was declared that protocols which were going 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 🍰. The general agreement was that this meant a given protocol's control information (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. That way, you could invoke a protocol interpreter (PI) through a known interface. If either protocol changed, nothing in the other would depend 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 that hadn't changed 🫶.

All well and good, if kinda cryptic 😵‍💫. The important point isn't a seemingly-rigorous definition of Layering, though. It's understanding what the axiom meant for the evolution of the ARM. It meant we tried to come up with protocols that represented reasonable "packagings" of functionality 📦. For reasons that are probably unknowable (but I'll offer some conjectures later), the ARM and the ISORM agree strongly that Layering is part of their axiomatizations, but they differ dramatically on which packagings of functionality count as appropriate 🥊. To jump ahead a bit: the ARM concerns itself with three layers, and only one of them is mandatorily traversed. The ISORM, as everybody knows, has (because of emerging "sub-layers") what must be viewed as at least seven layers, and lots of people who've studied it believe all of the layers must be traversed on each transmission/reception of data 🫠.

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!" 😂 Yet nobody had a noticeably clearer view of what Layering meant than what's been presented here, and the ARMS still exists 💅. We can only guess what goes on in 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.... 🙈💜

Okay so, the ARM's whole vibe on Layering 🦋 is treating layers as pretty broad functional groupings (Network Interface, Host-Host, and Process-Level, or Applications) 🌸, and the stuff inside each layer is supposed to be modular 🧩. Like, in the Host-Host layer of the current ARMS, the Internet Protocol, IP, handles internet addressing among other things 🌐 for both TCP, which handles reliable interprocess communication 💖, and UDP (the less well-known User Datagram Protocol) 🧚, which only handles demultiplexable interprocess communication ✨. And it leaves room for any other IPC packaging that might be desirable later 💅. The ISORM is giving a totally different energy 🙈. It treats layers as rather narrow functional groupings and tries to force modularity by adding extra layers for extra functions. (Though the "classes" view of the proposed ECMA-sponsored ISORM Transport protocol kinda copies the relationships between TCP, UDP, and IP 👀.)

Honestly? We think forcing modularity by multiplying layers, instead of trusting the designers of a protocol to make it usable by other protocols in its own layer, is a major reason the ISORM and the ARM diverged 🤔. But as we said, this one almost certainly can't be proven 🫠. (The less structured view of modularity gets its own spotlight in the next major section 💜.) Anyway, the idea that "N-entities" must communicate with one another by means of "N-1 entities" pulls the ISORM out of its intended sphere of description and into prescription territory 😭, and we don't think it belongs there. Not even a little! A reference model that plays a prescriptive role has unrealizable requirements for precision, and for familiarity with every style of operating system, on whoever's explaining it 💀. So as it's currently presented, the ISORM hierarchy is a pretty strict one, with required "chain of command" implications 👑. It's basically the Elizabethan World Picture's Great Chain of Being, if you've studied Shakespeare 🎭. Meanwhile, in the ARM, a cat can even invoke a king, much less look at one 🐈‍⬛👑💅.

Common Intermediate Representations

Next up is an axiom that might not be an axiom in the strict sense, because it's actually susceptible to "proof" in some sense 🧐. When it came time to design the first Process-Level ARMS protocol (roughly equivalent to ISORM Level 5.3 [5] through 7), it seemed totally self-evident that a "virtual terminal" was a sound conceptual model 💅. But it can also be demonstrated that it is ✨. The argument is customarily shorthanded as "the N X M Problem", which we sketched above, and it goes like this 📝: if you want to let users at remote terminals log in/on to Hosts (and you do, because resource sharing doesn't preclude remote access, it subsumes it 🫶), you've got a problem with Hosts' native terminal control software or "access methods" 😩. Those only "know about" certain kinds, brands, and types of terminals, and there are way more terminals out there than any Host has internalized. This is true even for operating systems that take a generic view of I/O and don't let applications programs "expect" particular terminals 🙃.

You don't want to make N different types of Host/Operating System become aware of M different types of terminal 🙅‍♀️. You also don't want to limit access to users who are at one particular type of terminal, even if all your Hosts happen to have that one in common 🚫. So, you define a common intermediate representation (CIR) of the properties of terminals, or you create a Network Virtual Terminal (NVT) 🪄. "Virtual" is used here by analogy to "virtual memory," meaning 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. Adding it means translating or mapping from the CIR to something acceptable to the rest of the programs on your system when terminal-oriented traffic comes "from the net," and translating or mapping to the CIR from whatever your acceptable native representation is when terminal-oriented traffic goes "to the net" 🔁. (And the system that the terminal is physically attached to does the same things 💖.)

"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 got used 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 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 📂. But the first way a CIR got used deserves more publicity 📣! We decided to have a command-oriented FTP, which means users could cause files to be deleted from remote directories, for example, as well as simply get 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 they had one 📬.) So we needed an agreed-upon representation of the commands. That meant 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 🙅‍♀️. Instead, 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 programs that provided the FTP functionality interfaced with the programs that provided the Telnet functionality 🙈. 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 (which means 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 🧑‍💻. The ISORM takes a similar view in principle, but in practice many ISORM advocates take the model prescriptively rather than descriptively 😤. They construe it to mean 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, meaning single protocols per level, but that view seems to be abating 🌈.)

One more thing about virtualizing is worth mentioning: it's a good servant but a bad master 👑. When you're dealing with the amount of traffic that goes across 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 when you're dealing with files that can be millions of bits long, you probably should worry 😬, because those CPU cycles are, in a fairly real sense, the resources you're making sharable 🧠. So 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 of going into and out of the CIR 🏃‍♀️. This applies 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

The last point leads nicely into an axiom that is rarely acknowledged explicitly but really does belong in the ARM list of axioms 📜: Efficiency is a concern, in several ways ⚡. First off, protocol mechanisms are meant to follow the design principle of Parsimony, or Least Mechanism. Just look at the argument right above about letting FTP's avoid the double mapping of a Virtual File approach when they can 🎯. Second, look at 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 🙃. It's decreeing that "N-entities" must communicate via "N-1 entities" in a way that supports the interpretation that this applies intra-Host as well as inter-Host 😵. Picture the ISORM as a highrise apartment building 🏢. You're constrained to climb down the stairs and then back up just to visit a neighbor whose apartment is on your own floor 🪜. That might be good exercise 🏋️‍♀️, but CPU's don't need aerobics as far as we know 💀.

Now, this paper is only secondarily about ARM "vs." ISORM, so let's duly note that the ARM does care about efficiency from the perspective of the participating Hosts' resources 💜. That includes CPU cycles and, it shouldn't be overlooked, "core" 🧠, all expended on interpreting protocols. Then we'll move on to the final axiom without digressing into one or two proposed specific ISORM mechanisms that seem to be extremely inefficient 🙅‍♀️.

Equity

The least known of the ARM axioms is about whether particular protocol mechanisms would cause undue perturbation of native mechanisms if implemented in particular Hosts 🥺. The ARMS designers were, however reluctantly, willing to listen when someone said "you can't implement that in my system" about a proposed tactic 🙈. And however grudgingly, they'd retreat from a mechanism that seemed perfectly natural on their home systems to one that didn't seriously discommode a colleague's home system 🫶. A tacit design principle based on equity was at work here 💖. The classic example involved "electronic mail" 📧. 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 some operating systems needed those commands to actuate not only accounting mechanisms but authentication mechanisms as well 🔐. And the process that "fielded" FTP connections was too privileged (and too busy) to contain the FTP PI too 😩. 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, they were still mandatory 🔥.

okay so instead of trying to untangle the example 🙃, let's go straight to the moral 💅: how well protocol mechanisms fit with a particular operating system can be super subtle 🫠. So if you want to be equitable to the systems taking part, you must either have your designers be sophisticated implementers, or subject your designs to review by sophisticated implementers (and give them veto power in some sense) 👑.

It's important to note that, in the author's view, the ISORM doesn't just fail to reflect the Principle of Equity 😬. It also never explicitly acknowledges that its protocol interpreters have to be properly integrated into continuing operating systems. Probably because Equity was on their minds, the ARMS protocols, on the other hand, came out of intense implementation discussion and testing 🧠✨.

Articulation

Okay, so given everything we just covered about its axioms, plus a reminder that we find it impossible to believe in rigorous definitions when there are dozens of definitions of something as basic as "process" 🙄, the ARPANET Reference Model doesn't need much space to spell out. And since 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 🌈. These typically employ common intermediate representations over logical connections. Three 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 aren't directly germane to the model. No assumption is made that CSNP's of different types can be directly interfaced to one another. That's the whole point of "internetting": it gets done 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). That means "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 it 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 these protocols is the ability to direct IPC to processes on Hosts attached to "proximate networks" (meaning CSNP's of various autonomous communications subnetworks) other than the one the Host at hand is on, 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, though, we assume that the Principle of Parsimony dominates 💅.) Another significant property of Host-Host protocols is the ability to do such IPC over logical connections. It's not a required one, though 🙃. 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 it may also be invoked by a Host process interpreting no formal protocol whatsoever. Also, a Host doesn't need to support more than a single, possibly notional, process. 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, like letting users log in/on to foreign Hosts, transferring files, exchanging messages, and the like 💌. Protocols in this layer will often employ common intermediate representations, or "virtualizations", to perform their functions. This isn't a necessary condition, though 🫶. They're 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 used to offload Network and Host-Host layer PI's from Hosts 🫧. The offloading goes 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). It can also cover 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 have 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. (This observation shouldn't be read as implying that any of their PI's must of necessity be implemented in a particular operating system's "hard-core supervisor" or equivalent 🙈.) Their PI's must be able to behave as such 👑.

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 you learn in Geometry that you can't "prove" anything from the figures in the text, they're intended only to supplement the prose description above 📐. (At least they bear no resemblance to highrise apartment houses 🏢💀.)

TCP/IP Design Goals and Constraints

The foregoing description of the ARM deferred detailed discussion of two rather relevant topics, in the interests of conciseness 🫠. The first is just what TCP and IP (the Transmission Control Protocol and the Internet Protocol) are "about". The second is just what role Gateways are expected to play in the model. We turn to those topics now, under separate headings 🎀.

As has been stated, the ARPANET [7] was a huge success, both as a proof-of-concept of intercomputer resource sharing via a packet-switched communications subnetwork and as a (still) functional resource sharing network 🏆. A number of other bodies, research and commercial, then 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. Still, new networks abounded 🌈. In the research community, it was perceived that Hosts attached to the original ARPANET or to DoD nets meant to be transferences of ARPANET technology should be able to do resource sharing (i.e., interpret common high level protocols) with Hosts attached to these other networks 🤝. So 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, was somewhat flawed, particularly in the area of "robustness" 😭. AH-HP is often miscalled NCP, because it was the most visible component of the Network Control Program of the early literature 🙃. 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 at 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 with the ability to communicate as if their respective containing Hosts were attached to the best comm subnet possible (e.g., a hardwired connection) 🔗. Its users might be processes interpreting formal protocols, or simply processes communicating in an ad hoc fashion, and TCP serves both 💅.

The mechanizations considered to achieve reliability, and even those for internetting, were alien enough to AH-HP's style 👽. Also, 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. So 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. This is a design goal that's easy to overlook 👀. It's a rather subtle issue, because 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 are retained in TCP without much discussion. These include sockets, logical connections, Well-Known Sockets, and in general the interprocess communication premise 🫶. Meanwhile, 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. Think about them hard for a few years and they justify a document of even more than this one's length 📜💖. So what about the implied and/or accepted design constraints, though? 👀🔥

okay so the first design constraint is kinda obvious, but let's do it anyway 💅 Just like the original ARPANET popularized packet-switching (and, unfortunately to a lesser extent, resource sharing), its literature popularized the notion of "Layering." 🧚 Mechanically, 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, though, it's subtle enough that researchers of good will are still arguing over what "proper" layering implies, also as discussed earlier 🙈 For present purposes, it's enough to notice the following: Layering is a useful concept. ✨ The precise set of functions offered by a given layer is open to debate, and so is the precise number of layers needed 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 you presse them, they admit that "the IMPs must have a protocol too." 💀 Adherents of the International Standards Organization's "Open System Interconnection" program (which, honestly, appears to be how they spell resource sharing) claim seven is the right number of levels. Though if you press them, they admit 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 is the primary rationale for separating the internetting mechanization into a discrete protocol (the Internet Protocol: IP). 🦋 In other words, although designed

— p. 16 —

"for" the ARM, TCP and IP are actually layered so well that they're 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 (for example, 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 (for example, a non-reliable "Real-Time" protocol). 🌸

Resisting the temptation to do full 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" made up 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 limiting 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, it's 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 on 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. That includes, 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

— p. 17 —

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). That 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. Of course, that's only if 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. 😵‍💫

Gateways

One other aspect of the ARPANET Reference Model bears separate mention. Even though it's an exceedingly fine point 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.) Of course, they also handle 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). 🛤️

— p. 18 —

Aside from their role in routing, another property of Gateways is also significant: 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 (for example, TCP and AH-HP) or dissimilar Process-level protocols (for example, ARPANET FTP and EDN FTP) at the Gateways. 🧠 The justifications for this position are somewhat complex, so the interested reader is encouraged to see Reference [10]. For present purposes, though, it should suffice to note that the case against translating/mapping Gateways is a sound one. And, 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

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. These 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. 🎀

(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. 🙌)

"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 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. 🛰️🌈

— p. 19 —

Also, the kind of Outboard Processing Environment mentioned earlier, where networking protocols get interpreted on behalf of the Host in a distributed processing way, fits super comfortably into the ARM 💅🦋. That doesn't mean you couldn't build an OPE for/to the ISORM. It just doesn't feel natural to it, and there are at least two reasons:

1. The Session Level associates sockets with processes, so it belongs "inboard" 🏠. The Presentation Level involves a LOT of bit-diddling, so it belongs "outboard" 🛸. And the Presentation Level is, unfortunately, above the Session Level 😭. This seems to suggest that outboard processing wasn't taken into account by the formulators of the ISORM. Bestie, that's a whole vibe check.
2. Some ISORMites have claimed that "X.25 can be used as a Host-Front End Protocol," but honestly it doesn't look like one to us 🙈. Sure, the ability to do end-to-end things through what's nominally the Network interface is kinda suggestive. (People who believe 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 lean on protocols above X.25 for full L II functionality, so nope 💀.) Maybe, with enough ingenuity, you could use X.25 to carry an H-FP. But it's clear it isn't meant to be one in and of itself 🎀.

"Plenty of Roads" 🛣️

Based on several pictures shown at conferences and in articles, DCE's in the X.25-based ISORM appear to many people 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, so there can be as many "roads" as needed between the ARM equivalent of ISORM parking garages 🚗💨. This also clears up fears about taking advantage of alternate routing in X.25 subnets or in X.75 internets. (Both X.25 and X.75 are "hop-by-hop" oriented, and they wouldn't seem to allow alternate routing without revision. Not it 🙅‍♀️.)

📄 page 20

"Multiple Apartments Per Floor" 🏢

As noted, the ISORM's strictures on inter-entity communication within each "highrise" are basically like having to climb downstairs and then back up just to visit another apartment on your own floor 😩. The ARM explicitly expects PI's within a layer to interface directly with one another when it makes sense, which gives the effect of multiple apartments on each floor off a common hallway 🌸. (Also, for those who think the ISORM implies only one protocol/apartment per layer/story, the ARM is more flexible. Obsessed 😍.)

"Elevators" 🛗

The ISORM is widely read as requiring each layer to be traversed on every transmission. (There are rumors about the upcoming introduction of "null layers," though 👀.) That gives you the effect of climbing all seven stories' worth of stairs every single 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 don't need to come into play, so you get to take the elevator instead of climbing the stairs 🛗✨. Iconic.

"Straight Clotheslines" 🧺

Because they seem 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. They 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, idk what does 💀.)

"Townhouse Styles Available" 🏘️

Should ISORM Level 6 and 7 protocols eventuate that 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 🔨🪚.

"Manned Customs Sheds" 🛂

Okay, this is straining the architectural metaphor pretty hard, but one of the unfortunate implications of the ISORM's failure to address operating system integration issues is that "Expedited Data" exchanges between "peer entities" might only amount to an SST flight to a foreign land where nobody is on duty at 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) that Layer III (Process-Level/ Applications) protocols use to convey "out-of-band signals," the ARM keeps the Customs Sheds manned at all times 👮‍♀️💖. (Fair warning, we know it's hard to address system integration issues without biasing the discussion toward particular systems. But we feel that not trying is far worse than trying and failing to avoid all parochialism 🫶.)

📄 page 21

"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., just so we remember 🇬🇧) only the highly constraining functionality of X.25 as L1-L3. L4-L7 are still in the design and agreement processes. After that, they presumably have to be put through stringent checkout in multiple implementations before becoming useful standards 🧪. So the metaphorical highrises are years away from being fit for occupancy 🏗️. Even if you're willing to accept the taste of the interior decorators, who 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, come with stoves and refrigerators, but there's plenty of room for your own furniture 🪑. And they're ready for immediate occupancy 🎉🏡.

Conclusion ✨

The architectural metaphor might have been overly extended as it was. It could have been drawn out even further to point up more issues where the ARM appears to us to be superior to the ISORM, if our main concern were which one is "better" 🤷‍♀️. In fairness, the one issue it skipped, which many would take to be in the ISORM's favor, is that "vendor support" for interpreters of the ISORM protocols will eventually amount to a desirable "prefabrication." Building 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, a close look at the vendor support idea suggests it's largely illusory (vide [11]) 🫠. That's especially true given how long the international standardization process will take to run its course, and the likelihood that specification ambiguities and optional features will handicap interoperability 🌀. So rather than extend the present paper even further, it seems fair to conclude that, with the possible exception of "vendor support" (with which exception we take

📄 page 22

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 planning to do real inter-computer networking in the next several years 🌈. This is especially true if they have operating systems with counterparts on the present ARPANET, so that most if not all of the labor-intensive part has already been taken care of 💜. That's true irrespective of one's views on how good the ISORM protocols will eventually be 🦋✨.

Acknowledgments ✨

Okay so, "any remaining shortcomings are the author's responsibility" has basically never been more true 🙈 but this paper got SO much help from the sharpest people in the research community and the (DoD) Protocol Standards Technical Panel 🧚 The author is extremely grateful, and extremely pleased to admit how much he owes them. Here's the list, 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 might or might not thank them for turning a personal catharsis into a fair semblance of a "real" paper 😭 but the author absolutely does 🫶

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 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. 🙃

[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.) 🧠

[3] Padlipsky, M. A. "The Elements of Networking Style", M81-41, The MITRE Corporation, Bedford, MA, October 1981

[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. 💀

[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. ✨

[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.

[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. 🌈

[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 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. 📡

[9] Cerf, V. G. and R. E. Lyons, "Military Requirements for Packet-Switched Networks and for Their Protocol Standardization" Proc EASCON 1982.

[10] Padlipsky, M. A., "Gateways, Architectures and Heffalumps", M82-51, The MITRE Corporation, Bedford, MA, September 1982. 🐘

[11] ---------- "The Illusion of Vendor Support", M82-49, The MITRE Corporation, Bedford, MA, September 1982.

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. 💌

And that's a wrap on the whole paper, bestie! 🎀💖