RFC 787
Connectionless data transmission survey/tutorial
RFC 787 🎀 Connectionless Data Transmission Survey/Tutorial
Okay bestie, this one is RFC 787 🦋, a Request For Comments written by A. Lyman Chapin and dated July 1981 🌸. This part doesn't list a category, and it doesn't say what the RFC obsoletes or updates, so I'm not guessing 🙈. Just know the body of the paper is a survey and tutorial on connectionless data transmission ✨.
Subject: Connectionless Data Transmission Survey/Tutorial From: A. Lyman Chapin
So the paper is getting passed around to a bunch of US orgs that care about building international data communication standards 💅. There's a review period ending September 1, 1981. After that, a revised version (with everybody's comments baked in 🫶) goes to the American National Standards Institute (ANSI) committee in charge of OSI Reference Model issues, ANSC X3T5. If they approve it, it gets presented to the relevant International Organization for Standardization (ISO) groups as the basis of a US position. The goal is to get connectionless data transmission added to the Reference Model and the related OSI service and protocol standards 🔥.
It really matters that people send in comments, plus a note about how important connectionless data transmission is to you or your org 💜. That's how the final version ends up reflecting a true US position. Send everything to the author at:
A. Lyman Chapin
Data General Corporation MS E111
4400 Computer Drive
Westborough, MA 01580
(617) 366-8911 x3056 ,---------------------------------,
X3S33/X3T56/81-85 | WORKING PAPER |
X3T5/81-171 | This document has not been re- |
X3T51/81-44 | viewed or approved by the appro-|
X3S37/81-71R | priate Technical Committee and |
| does not at this time represent |
| a USA consensus. |
'---------------------------------'⚠️ Heads up: that box says it's a WORKING PAPER. It hasn't been reviewed or approved by the right Technical Committee, and it doesn't represent a USA consensus yet. Not finalized, babe 💀.
Connectionless Data Transmission A. Lyman Chapin 22 May 1981, Revision 1.00
Abstract 📜
Okay so the Reference Model of Open Systems Interconnection is everywhere right now 👑. ISO is looking at promoting it to a Draft International Standard, and it's built on one big assumption: a "connection" is needed for data to move around in an OSI environment. A connection is an association between two or more communicating entities that has certain characteristics beyond the entities themselves 🧚. The connection-oriented model of communication has been super powerful, and it's been used successfully for protocols and systems across a huge range of applications 💖.
But a growing pile of research and experience says there's a complementary idea, connectionless data transmission, that's an essential piece of the OSI architecture and should be embraced by the Reference Model 🌈. This paper digs into what connectionless transmission is, how it relates to the more familiar connection-oriented stuff, and why it should be included in the Reference Model as an integral part of the standard description of OSI architecture. It's giving real argument, no cap 🫶.
1. Introduction ✨
For the past three years, a bunch of national and international standards orgs have put in a ton of work 😭 to describe an architectural Reference Model for connecting computer systems that count as "open" because they all use standard communication protocols and formats. The current version, the Reference Model of Open Systems Interconnection (RM/OSI)[1], is broadly accepted by ISO, the International Telephone and Telegraph Consultative Committee (CCITT), the European Computer Manufacturer's Association (ECMA), and lots of national standards bodies, including ANSI. It's already reached Draft Proposed Standard (DP7498) status within ISO 🎀.
The model describes the concepts and principles of a communications architecture that's organized hierarchically, by function, into seven discrete layers 🍓. It also spells out the services each layer must provide to the layer right above it. The top layer provides its services to user applications, which are considered to be outside the Open Systems Interconnection environment. Each layer builds on the services from the layer below it and uses standard OSI protocols to talk to its peers in other systems (see Figure 1) 💅.
User of (N)-services User of (N)-services
[an (N+1)-entity] [an (N+1)-entity]
\ /
\ /
\ /-----(N)-service-access-points-----\ / (N+1)
-----------o-------------------------------------o------------
\ / (N)
\<-----services provided to------>/
\ (N+1)-layer /
\ /
,------------, ,------------,
| | | |
| (N)-entity |<----"Peers"---->| (N)-entity | (N)-LAYER
| | | |
'------------' '------------'
\ /
\<----services required---->/
\ from (N-1)-layer /
\ / (N)
-------------------o---------------------o--------------------
\ / (N-1)
\ /
\ /
\ /
,--------------------------------,
| |
| |
| (N-1)-LAYER |
| |
| |
'--------------------------------' FIGURE 1 - General Model of an OSI LayerSplitting the work into layers is a genius move 🧠. You take a super complex, abstract problem, which is basically "how can the parts of a distributed application cooperate when they're running in potentially very different environments?", and break it into more manageable problems that connect to each other logically and are easier to understand one at a time 🦋.
The Reference Model was built to be the framework for coordinating existing and future standards that make it easier to interconnect data processing systems ✨. The whole point of OSI is to let an end-user application activity (called an "application process") in an open system (one that uses OSI procedures and protocols) talk to any other application process in any other open system 🌸. OSI isn't trying to dictate the functions or implementation details of the systems that provide OSI capabilities. Communication happens because everyone sticks to agreed-upon, standardized services and protocols. An OSI entity in one system only needs to know how an OSI entity in the same layer of another system behaves, not how it's built inside 🙈. OSI doesn't care how the interfaces between adjacent layers are implemented in an open system either. Any interface mechanism is fine, as long as it supports access to the right standard OSI services 💖.
A Note on OSI Terminology 📝
The construction of a formal system, like the architecture of Open Systems Interconnection, means introducing unambiguous terminology. That terminology tends to look kind of impenetrable at first glance 😭. All the terms used here and in the text are defined in an Appendix. The "(N)-" notation shows that a term refers to an OSI characteristic that applies to each layer individually. The "(N)-" prefix stands in generically for the name of a layer. So "(N)-address", for example, refers abstractly to the concept of an address associated with a specific layer, while "transport-address" refers to that same concept applied to the transport layer 🍭.
OSI doesn't care how the interfaces between adjacent layers are implemented in an open system, so long as the standard OSI services are accessible 🎀.
A major goal of the OSI standardization effort is generality 👑. The ideal is for the Reference Model to be the shared architectural framework for many different types of distributed systems that use a wide range of telecommunication technologies. An important measure of OSI's success will be whether it can apply the standard architecture across a broad spectrum of user applications 🌈. The Reference Model's development over the past four years shows that the team cared about this goal, among others. The process started by identifying the essential concepts of a layered architecture, including the general architectural elements of protocols. Then it carefully moved from those basic principles to a detailed description of each layer 🧚. The current Reference Model document [1] follows the same top-down progression 💅. At the highest level, three elements are identified as basic to the architecture [1]:
- a) the application processes which exist within the Open Systems Interconnection environment;
- b) the connections which join the application processes and permit them to exchange information; and
- c) systems.
The assumption that a connection is a fundamental prerequisite for communication in the OSI environment runs through the whole Reference Model 🔥. It's actually one of the most useful and important unifying concepts of the architecture. But a growing number of experts think this deeply rooted connection orientation seriously and unnecessarily limits the power and scope of the Reference Model 😤. It shuts out a large class of applications and implementation technologies that are inherently connectionless 🙅♀️. Those experts argue that the architectural goals of the Reference Model don't depend on using connections exclusively to describe every OSI interaction. They recommend treating the two options, connection-oriented data transfer and connectionless data transmission, as complementary concepts. Each one can be applied in parallel to the different applications it suits best 👑🫶.
2. What Is Connectionless Data Transmission? 🌈
Okay so at the November, 1980 meeting of the ISO subcommittee responsible for OSI (TC97/SC16) 😭✨, a working party basically laid the groundwork for this whole argument with two documents: the Report of the Ad Hoc Group on Connectionless Data Transmission[3], and Recommended Changes to Section 3 of [the Reference Model] to Include Connectionless Data Transmission[2]. The full subcommittee noticed how big this was and passed a resolution[25] asking every member organization to send in comments on both documents. Whether connectionless data transmission should show up in the OSI architecture, and specifically whether it should become an integral part of the Reference Model, is getting debated again this summer, when the current Draft Proposed Standard Reference Model turns into a Draft International Standard. The rest of this article digs into the issues around that question 🧚.
Connectionless data transmission (CDT), even with the unfamiliar name, is honestly not new at all 💅. In one form or another it has been doing important work in the specification of services and protocols for over a decade. The literature uses "message mode"[ ], "datagram"[35], "transaction mode"[22,23,24], and "connection-free"[37,47] to describe variations on the same basic idea: sending a data unit in a single self-contained operation without establishing, maintaining, and terminating a connection.
Since CDT and connection-oriented data transfer are complementary concepts, they're best understood side by side 👯, especially because CDT is most often defined by its relationship to the more familiar idea of a connection 🫶.
2.1. Connection-Oriented Data Transfer 💖
A connection (or "(N)-connection", in the formal OSI terminology) is an association set up between two or more entities ("(N+1)-entities") for conveying data ("(N)-service-data-units"). The (N)-layer gives (N+1)-entities the ability to set up (N)-connections and send data units over them, and it does this as a set of services called connection-oriented (N)-services. Connection-oriented interactions go through three distinct sequential phases: connection establishment, data transfer, and connection release. Figure 2 shows the sequence of operations for these interactions, schematically. Beyond this explicitly distinguishable duration, or "lifetime", a connection has the following fundamental characteristics:
Connection Establishment
------------------------
- Successful - - Unsuccessful -
(N)- | | (N)- | |
connect | |(N)-connect connect | | (N)-
------->| |indication ------->| | connect
request | | request | |indication
| |-------> | |------->
|(N)-LAYER | |(N)-LAYER |
(N)- | |<------- (N)- | |<-------
connect | | disconnect | | (N)-
<-------| |(N)-connect <-------| |disconnect
confirm | | response indication | | request
| | | |
Data Transfer
-------------
(N)- | | (N)- | |
data | | (N)-data data | |
------->| |indication ------->| | (N)-
request | | request | | data
| |-------> | |indication
|(N)-LAYER | |(N)-LAYER |------->
| | (N)- | |
| | data | |
| | <-------| |
| | confirm | |
| | | |
Connection Release
------------------
- User Initiated - - Provider Initiated -
(N)-dis | | | |
connect | | (N)- | | (N)-
------->|(N)-LAYER |(N)-disconnect disconnect|(N)-LAYER |disconnect
request | |indication <-------| |------->
| |-------> indication| |indication
| | | |
FIGURE 2 - Connection Oriented Interaction[Note: Much of the material in this section is derived from reference 3]
- Prior negotiation. In a connection-oriented interaction, no connection gets established and no data gets transferred until all parties agree on the set of parameters and options that will govern the data transfer 🤝. An incoming connection establishment request can be rejected if it asserts parameter values or options that are unacceptable to the receiver, and the receiver may in many cases suggest alternative parameter values and options along with the rejection. The reason negotiation happens during connection establishment is the assumption that each party must reserve or allocate the resources (such as buffers and channels) that will be required to carry out data transfer operations on the new connection. Negotiation gives everyone a chance to scuttle the establishment of a connection when the resources needed to support it can't be dedicated, or to propose alternatives that the available resources could support 💀.
- Three-party Agreement. The fundamental nature of a connection involves establishing and dynamically maintaining a three-party agreement about the transfer of data 👑. The three parties are the two (N+1)-entities that wish to communicate, and the (N)-service that provides them with a connection. They must first agree on their mutual willingness to participate in the transfer (see above). This initial agreement establishes a connection. After that, for as long as the connection persists, they must continue to agree on the acceptance of each data unit transferred over the connection. As the source puts it: "With a connection, there is no possibility of data transfer through an unwilling service to an unwilling partner, because the mutual willingness must be established before the data transfer can take place, and data must be accepted by the destination partner; otherwise, no data [are] transferred on that connection."[3] Iconic, honestly 🔥.
- Connection Identifiers. At connection establishment time, each participating (N+1)-entity is identified to the (N)-service by an (N)-address, and the (N)-service uses these addresses to set up the requested connection. Later requests to transfer data over the connection (or to release it) don't refer to the (N)-address(es) of the intended recipient(s). Instead they use a connection identifier supplied by the (N)-service (in OSI parlance, an "(N)-connection-endpoint-identifier"). This is a locally-significant "shorthand" reference that uniquely identifies an established connection during its lifetime 🏷️. Similarly, the protocol units that carry data between systems typically include a mutually-understood logical identifier rather than the actual addresses of the correspondents. This technique cuts out the overhead that would otherwise come with resolving and transmitting addresses on every data transfer. In some cases, though, particularly when non-homogeneous networks are interconnected and very location-sensitive addressing schemes are used, it can make dynamic routing of data units extremely difficult, if not impossible 😬.
- Data Unit Relationship. Once a connection has been established, it may be used to transfer one data unit after another, until the connection is released by one of the three parties 📦. These data units are logically related to each other simply by virtue of being transferred on the same connection. Since data units are transferred over a connection in sequence, they're related ordinally as well. These data unit relationships are an important characteristic of connections, because they create a context for interpreting arriving data units that is independent of the data themselves. Because a connection maintains the sequence of messages associated with it, out-of-sequence, missing, and duplicated messages can easily be detected and recovered, and flow control techniques can be invoked to make sure the message transfer rate doesn't exceed what the correspondents are capable of handling 🎀.
These characteristics make connection-based data transfer attractive in applications that call for relatively long-lived, stream-oriented interactions in stable configurations, such as direct terminal use of a remote computer, file transfer, and long-term attachments of remote job entry stations 🖥️. In these applications, the interaction between communicating entities is modelled very well by the connection concept. The entities first discuss their requirements and agree to the terms of their interaction, reserving whatever resources they'll need. Then they transfer a series of related data units to accomplish their mutual objective, and finally they explicitly end the interaction, releasing the previously reserved resources 🌸.
2.2. Connectionless Data Transmission 🦋
In many other applications, though, the interaction between entities is more naturally modelled by the connectionless data transmission concept. This involves sending a single self-contained data unit from one entity to another without prior negotiation or agreement, and without the assurance of delivery normally associated with connection-based transfers 📬. The users of a connectionless (N)-service may, of course, use their (N+1)-protocol to make any prior or dynamic arrangements they like about how they interpret the data sent and received. The (N)-service itself, however, attaches no significance to individual data units and doesn't try to relate them in any way ✨. Two (N+1)-entities communicating by means of a connectionless (N)-service could, for example, apply whatever techniques they consider appropriate in executing their own protocol (timers, retransmission, positive or negative acknowledgements, sequence numbers, etc.) to reach the level of error detection and/or recovery they want 🛠️. Users of a connectionless, as opposed to connection-oriented, (N)-service aren't restricted or inhibited in performing their (N+1)-protocol. Obviously, though, the assumption is that CDT will be used in situations that either don't require the characteristics of a connection, or actively benefit from the alternative characteristics of connectionless transmission 💜.
Okay so Figure 3 is the simplest possible move: one single operation where a connectionless service gets used to send one single data unit. 💖 No drama, just vibes.
(N)-data | |
request | |
--------->| |
| (N)-LAYER |
| |--------->
| | (N)-data
| | indication
FIGURE 3 - Connectionless Data TransmissionFigure 4 is the one that gets implemented all the time, sometimes called "reliable datagram" service 🎀. Here the service provider goes the extra mile and confirms the delivery or non-delivery of each data unit. ✨
(N)-data | |
request | |
--------->| |
| | (N)-data
| (N)-LAYER |--------->
| | indication
<---------| |
(N)-data | |
confirm | |
FIGURE 4 - "Reliable Datagram" ServiceReal talk though, it must be emphasized that this is not a true connectionless service 🦋. It's more of a hybrid, mixing the delivery assurance of connection-oriented service with the single-operation interface vibe of connectionless service. Ate the hybrid energy, ngl. 💅
Many people in OSI standardization have agreed on a pair of definitions for connectionless data transmission [4]. One is architectural and conceptual, for the Reference Model. The other is for service definitions. The architectural one, which has been proposed for inclusion in the Reference Model, goes like this:
"Connectionless Data Transmission is the transmission (not transfer) of an (N)-service-data-unit from a source (N)-service-access-point to one or more destination (N)-service-access-points without establishing an (N)-connection for the transmission."
The service definition, which is meant to give us a workable basis for putting a connectionless service into the service descriptions for individual layers of the Reference Model, is:
"A Connectionless (N)-Service is one that accomplishes the transmission of a single self-contained (N)-service-data-unit between (N+1)-entities upon the performance of a single (N)-service access."
Both of these definitions lean super hard on the difference between "transmit", "transfer", and "exchange" 🧚:
- Transmit: "to cause to pass or be conveyed through space or a medium." This is only about the act of conveying, without implying anything about reception.
- Transfer: "to convey from one place, person, or thing, to another." A one-way peer-to-peer connotation restricts the use of this term to cases in which the receiving peer is party to and accepts the data transferred.
- Exchange: "to give and receive, or lose and take, reciprocally, as things of the same kind." A two-way peer-to-peer connotation restricts the use of this term to cases in which both give and receive directions are clearly evident.
Honestly, these definitions are kinda limited on their own 🙈. BUT they give us a framework for exploring the following characteristics of CDT.
1. "One-shot" Operation. 💖
The most user-visible thing about connectionless data transmission is the single service access you need to start sending a data unit. All of the info needed to deliver the data unit (destination address, quality of service selection, options, etc.) gets handed to the connectionless (N)-service provider, along with the data, in one logical service-access operation. The (N)-service doesn't treat that operation as related to any other access operations, before or after. Note, however, that since OSI isn't concerned with implementation details, the specific interface mechanism used by a particular implementation of connectionless service might involve more than one interface exchange to accomplish what is, logically, a single operation. Once the service provider has accepted a data unit for connectionless transmission, no more communication happens between the provider and the user about what happens to the data. ✨
2. Two-party Agreement. 🤝
Connection-oriented data transfer needs a three-party agreement between the participating (N+1)-entities and the (N)-service. A connectionless service only involves two-party agreements. There may be an agreement between the corresponding (N+1)-entities, which the (N)-service doesn't know about. There may also be local agreements between each (N+1)-entity and its local (N)-service provider. But no (N)-protocol information is ever exchanged between (N)-entities about whether the (N+1)-entities are willing to engage in a connectionless transmission or to accept a particular data unit. 🌸
In practice, there's usually some sort of a priori agreement (often a system engineering design decision) between the (N+1)-entities and the (N)-service, covering the parameters, formats, and options that affect all three parties as a unit. Still, there's a lot of freedom, since the user of a connectionless service can specify most parameter values and options (things like transfer rate, acceptable error rate, etc.) at the time the service is invoked. In a given implementation, if the local (N)-service provider figures out right away (from info it has locally) that the requested operation can't be performed under the conditions specified, it may abort the service primitive and return an implementation-specific error message across the interface to the user. If that same determination only happens later, after the service-primitive interface event has finished, the transmission is simply abandoned. That's fine, because users of a connectionless service can be expected to recover lost data themselves if it matters to them. 🫶
3. Self-contained Data Units. 🎀
Data units sent through a connectionless service don't relate to other data units or to a "higher abstraction" (like a connection), so they are entirely self-contained. Every bit of addressing and other info the service provider needs to deliver a data unit has to be included in each transmission. On one hand, that's more overhead than you'd get during the data transfer phase of a connection-oriented interaction. On the other hand, it makes routing way simpler, since each data unit carries a complete destination address and can be routed without looking at connection-related info that may not, for example, be easy to find at intermediate nodes. 🦋
4. Data Unit Independence. 💅
Sending data connectionlessly creates no relationship, express or implied, between data units. Each invocation of a connectionless service starts the transmission of one single data unit. Nothing about the service invocation, the transmission of the data, or the data unit itself affects or gets affected by any other past, present, or future operation, whether connection-oriented or connectionless. If you hand a series of data units to a connectionless service, one after the other, for delivery to the same destination, they will not necessarily arrive in the same order. And the connectionless service will make no attempt to report or recover non-delivery. 🙈
Note: A number of popular variations on CDT include features that run counter to those described above. These variations deserve to be discussed on their own merits, but should not be confused with the architectural concept of connectionless data transmission. 💀
These characteristics make CDT attractive for applications that involve short-term request-response interactions, show a high level of redundancy, must be flexibly reconfigurable, or get no benefit from guaranteed in-sequence delivery of data. 👑
3 The Rationale for Connectionless Data Transmission ✨
Because CDT isn't as widely understood as connection-oriented data transfer, it has often been hard, while developing service and protocol definitions, to come up with a rationale for including CDT. It's even harder to figure out the right spots for a connectionless service within the layered hierarchy of OSI. This section deals with the first concern, and the next section handles the second. 🌈
The most natural way to see the power and utility of the CDT concept is to look at the applications and implementation technologies that depend on it. The following observations are distilled from the specifications and descriptions of actual protocols and systems (many of which have been implemented), and from the work of individuals and organizations engaged in the OSI standardization effort. Quoted material is from reference 3, except where otherwise noted. They're divided into seven (occasionally overlapping) categories that classify the applications for which CDT is well suited. 🍓
Inward data collection involves the periodic active or passive sampling of a large number of data sources. A sensor net gathering data from dedicated measurement stations, a network status monitor constantly refreshing its knowledge of a network environment, and an automatic alarm or security system in which each component regularly self-tests and reports the result are all doing this type of interaction. As the reference puts it:
"large number of sources may be reporting periodically and asynchronously to a single reporting point. In a realtime monitoring situation, these readings could normally be lost on occassion without causing distress, because the next update would be arriving shortly. Only if more than one successive update failed to arrive within a specified time limit would an alarm be warranted. If, say, a fast connect/disconnect three-way handshake cost twice as much as a one-way [connectionless] data transmission which had been system engineered to achieve a certain acceptable statistical reliability figure, the cost of connection-oriented inward data collection for a large distributed application could be substantially greater than for [connectionless collection], without a correspondingly greater benefit to the user."[3]
Outward data dissemination is kind of the opposite of the first category 🔥. It's about distributing a single data unit to a large number of destinations. You see this when a node joins a network, or when a commonly-accessible server changes its location and a new address gets sent to other nodes on the network. It also happens when a synchronizing message, like a real-time clock value, has to go to all participants in some distributed activity, and when an operator broadcasts a nonspecific message (e.g., "Network coming down in five minutes"). In these cases, the distribution cost (including time) can far exceed the cost of generating the data. So controlling the overall cost depends on keeping the cost of dissemination as low as possible. 🧚
Okay bestie, so request-response apps are the ones where a popular server process offers a service to a ton of distributed request sources 💌 The usual vibe is one request, then one response, and honestly the only acknowledgement anyone cares about is the highest-level one, the response itself 🙈 This shows up in commercial stuff like point of sale terminals, credit checking, reservation systems, inventory control, and automated banking systems 💳, plus some industrial process control and general information retrieval like videotex 📺. In every case, each application component already knows what the interaction should look like, because it's baked into an application-process design and implementation that's known in advance, outside of OSI ✨ So lower level negotiations, acknowledgements, and other connection-related functions are often unnecessary and cumbersome 💅
Next up, an example that mashes together inward data collection, outward data dissemination, and request-response interaction all at once 🔥 The IEEE Power Engineering Society's Working Group on Power System Control Centers wrote a recent letter to the chairman of ANSI committee X3T51 about using data communication in utility control centers[17]. They said that "a utility control center receives information from remote terminal units (located at substations and generating plants) and from other control centers, performs a variety of monitoring and control functions, and transmits commands to the remote terminals and coordinating information to other control centers." While all that's happening, these things go down:
- Some measurements are transmitted or requested from remote terminals or control centers every few seconds. No attempt is necessarily made to recover data lost due to transmission error; the application programs include provisions for proper operation when input data is occassionally missing. [Inward data collection]
- Some data items are transferred from commonly accessed remote sites or multi-utility pool coordination centers on a request-response basis. [Request-response interaction]
- In some cases, an application program may require that some measurements be made simultaneously in a large number of locations. In these cases, the control center will broadcast a command to make th affected measurements. [Outward data dissemination]
To wrap it up, they noted that "utility control centers around the world use data communications in ways similar to those in the United States." Iconic global energy, honestly 🌍⚡
Broadcast and multicast (group addressed) communication over connection-oriented services is awkward at best and impossible at worst 😭 That's true even though the Reference Model occasionally mentions "multi-endpoint connections." Some connection-based data transfer stuff, like sequencing and error recovery, is really hard to provide in a broadcast/multicast environment, and it may not even be desirable 🙅♀️ It's also not easy to come up with a useful definition of broadcast/multicast acknowledgement that a low-level protocol can actually support. So when group addressing is an important application consideration, connectionless data transmission is usually the only choice 🦋
Some special apps, like digitized voice, data telemetry, and remote command and control, have a lot of data redundancy and/or real-time transmission requirements 🎧 They might actually benefit from the fact that CDT doesn't try to detect or recover lost or corrupted data 🫶 If the window where a single datum is meaningful is pretty short, since the next one quickly supersedes it, or if losing one or even several data units doesn't really matter (like in digitized voice), the app could suffer way more from the delay of a connection-oriented service dealing with a lost or out-of-sequence data unit (even if retransmission or other recovery procedures weren't invoked) than from the unreported loss of a few data units in a connectionless exchange 🤷♀️ Other special considerations also push CDT as an alternative to connection-oriented transfer. For example, for security reasons, you might not want connection-state information kept between data transfers in a military command and control system 🫣
Local area networks (LANs) are probably the most fertile ground for connectionless services, which find useful application at several layers 🌸 LANs use physical transmission media and techniques that are intrinsically reliable (baseband and broadband coaxial cable, fiber optics, etc.) over a restricted range (generally no greater than 1 or 2 kilometers), and they're typically able to achieve extremely low bit error rates ✨ On top of that, the media-access contention mechanisms LAN designers love handle transmission errors as a matter of course 💪 The usual approach to physical interconnection ties all nodes together on a common medium, which creates an inherently broadcast environment where every transmission can be received by every station 📡 Taking advantage of these characteristics pretty much demands a connectionless data link service. In fact, most current and proposed LANs (the Xerox Ethernet[43], the proposed IEEE 802 LAN standard[14,46], and many others) depend on such a service 💖 And as a bonus, since connectionless services are simpler to implement (requiring only two or three service primitives), inexpensive VLSI implementations are often possible 🤑
Also, the applications LANs are often installed for tend to be exactly the ones CDT handles best 💅 Check out this list of eight application classes the IEEE 802 Interface Subcommittee identified as targets for the 802 LAN standard[46]:
- Periodic status reporting - telemetry data from instrumentation, monitoring devices associated with static or dynamic physical environments;
- Special event reporting - fire alarms, overload or stressing conditions;
- Security control - security door opening and closing, system recovery or initialization, access control;
- File transfer;
- Interactive transactions - reservation systems, electronic messaging and conferencing;
- Interactive information exchange - communicating text and word processors, electronic mail, remote job entry;
- Office information exchange - store and forward of digitized voice messages, digitized graphic/image handling;
- Real-time stimulus and response - universal product code checkout readers, distributed point of sale cash registers, military command and control, and other closed-loop and real-time applications.
Almost all of these have already been identified as classic examples of applications that are essentially connectionless in nature 🙌 Now here's a more detailed take on (8): a local area network with a large number of nodes and a large number of services (e.g., file management, printing, plotting, job execution, etc.) provided at various nodes. In a setup like that, it's impractical to keep a table at each node giving the address of every service, because changing the location of a single service would mean updating the address table at every node 😩 The alternative is one independent "server lookup" service that maps the name of a given service to the address of a server providing it. The server-lookup server gets requests like "where is service X?" and returns the address where an instance of service X is currently located 🗺️ Talking to the server-lookup server is inherently self-contained, consisting of a single request/response exchange. Only the highest-level acknowledgement (the response from the lookup service giving the requested address) is at all significant. The native reliability of the LAN keeps the error rate low, and if a message gets lost, no harm done, because the request will just be re-sent if a timely response doesn't arrive 🙆♀️ That kind of interaction is poorly modelled by the connection-oriented paradigm of opening a connection, transferring a stream of data, and closing the connection. It's perfectly suited to connectionless transmission techniques 👑
Network interconnection (internetworking) can be facilitated, especially when networks of different types are involved (which is often the case), if the internetwork service is connectionless 🌐 A bunch of related activities, like gateway-to-gateway communication, also show request-response, inward data collection, and outward data dissemination characteristics that CDT supports really well 🥰 One of the best examples of a connectionless internetwork service is described in a document published by the National Bureau of Standards (Features of Internetwork Protocol[29]), which includes a straightforward discussion of the merits of the connectionless approach:
"The greatest advantage of connectionless service at the internet level is simplicity, particularly in the gateways. Simplicity is manifested in terms of smaller and less complicated computer code and smaller computer storage requirements. The gateways and hosts are not required to maintain state information, nor interpret call request and call clear commands. Each data-unit can be treated independently...Connectionless service assumes a minim[al] service from the underlying subnetworks. This is advantageous if the networks are diverse. Existing internet protocols which are intended for interconnection of a diverse variety of networks are based on a connectionless service [for example the PUP Internetwork protocol[44], the Department of Defence Standard Internet Protocol[31], and the Delta-t protocol developed at Lawrence Livermore Laboratory[45]]."
The principle behind building internetwork services and protocols that make few assumptions about the individual network services (the "lowest common denominator" approach) was formulated by Carl Sunshine as the "local net independence principle"[39] 🧠 It says: "Each local net shall retain its individual address space, routing algorithms, packet formats, protocols, traffic controls, fees, and other network characteristics to the greatest extent possible." The simplicity and robustness of connectionless internetworking systems basically guarantee their widespread use as the number of different network types (X.25 networks, LANs, packet radio networks, other broadcast networks, and satellite networks) grows and the pressure to interconnect them builds 🚀💜
4. CDT and the OSI Reference Model ✨
4.1 Physical Layer ✨
Okay so, connectionless data transmission is the bestie to connection-oriented data transfer 💖 they complement each other all through the OSI architecture. Building standard OSI services and protocols on top of it hits some layers way harder than others 👀 so you really have to weigh connectionless against connection-oriented at each layer. Otherwise you get a pile of incompatible or useless options 🙃 and the power of the two concepts gets out of balance with the stabilizing goal of OSI standardization 🎀
Figure 5 shows the layered OSI hierarchy the way it's usually drawn 🧚 (two instances of the stack, one for each of two OSI systems). The sections below break down CDT across all seven layers 💅
,---------------------, ,---------------------,
| | | |
Level 7 | Application Layer |<---------->| Application Layer |
| | | |
|----------|----------| |----------|----------|
| | | |
Level 6 | Presentation Layer |<---------->| Presentation Layer |
| | | |
|----------|----------| |----------|----------|
| | | |
Level 5 | Session Layer |<---------->| Session Layer |
| | | |
|----------|----------| |----------|----------|
| | | |
Level 4 | Transport Layer |<---------->| Transport Layer |
| | | |
|----------|----------| |----------|----------|
| | | |
Level 3 | Network Layer |<---------->| Network Layer |
| | | |
|----------|----------| |----------|----------|
| | | |
Level 2 | Data Link Layer |<---------->| Data Link Layer |
| | | |
|----------|----------| |----------|----------|
| | | |
Level 1 | Physical Layer |<---------->| Physical Layer |
| | | |
'---------------------' '---------------------'
FIGURE 5 - Layered Hierarchy of Open Systems InterconnectionNow the physical layer 🌸 honestly, the connectionless vs connection-oriented thing is hard to show here, mostly because a physical "connection" is already such an intuitive, everyday idea 🙈 The physical layer handles generating and interpreting signals that get sent over the wire using some kind of physical encoding (electrical, optical, acoustic, whatever 🔊). A physical connection, in the broadest sense (and we're only looking at telecom media, same as the Reference Model itself 📡), is a signal pathway through one medium or a combo of them 🛤️
So is a packet radio broadcast network using a "connectionless" physical service? 🤔 No explicit signal pathway through a medium is set up before data gets sent. BUT you could also argue that a physical connection gets made the moment you stick two antennae out into the "ether" 📡✨ and if they're pointed at each other and built for microwave transmission, it feels even more like a real connection. Whether you think connectionless physical services exist (other than purely whimsical ones) is basically a matter of perspective 🫶 and it won't change how actual telecom systems get built 💅
4.2 Data Link Layer 🦋
A lot of data link tech, especially the stuff that got big with local area networking, is way easier to understand and work with when you swap out the traditional connection-oriented concepts (like the super popular HDLC, SDLC, and ADCCP standards) for connectionless data transmission 💜 The earlier LAN discussion already made the point: the fast, short-range, naturally reliable broadcast media that link stations together on a LAN are complemented, both functionally and conceptually, by connectionless data link techniques 🔥
One of the groups building a LAN data link layer standard, the Data Link and Media Access (DLMAC) subcommittee of IEEE 802, gets both things: it needs to stay compatible with existing long-haul techniques, AND it sees the unique perks of CDT for LANs 🙌 So they proposed defining two data link procedures for the IEEE 802 standard 🌈
In the first procedure, information frames are unnumbered and any station can send them at any time without setting up a connection first 🚀 The intended receiver can accept and interpret the frame, but it isn't obligated to, so it can just throw the frame away with no notice to the sender 🗑️ The sender also isn't told if no station recognizes the address coded into the frame, or if there's no receiver at all 😬 This "connectionless" procedure assumes the "friendly" environment and the higher-layer acceptance of responsibility that are usually found in LAN implementations 🫶
The second procedure gives you all the sequencing, recovery, and other guarantees normally tied to connection-oriented link procedures 👑 It's actually very similar to the ISO standard HDLC balanced asynchronous mode procedure ✨
Data link procedures for transmission media that (unlike LAN media) have unacceptable error rates are almost always connection-based 🙃 Why? Because it's generally more efficient to fix point-to-point bit-stream errors at the data link layer, where the timeout intervals are comparatively short, than to wait and fix them at a higher layer 🧠
4.3 Network Layer 🌍
Connectionless network service is useful for a lot of the same reasons we already talked about in the network interconnection discussion 💖 It seriously simplifies the design and implementation of systems ✨ it makes few assumptions about the underlying services 🧩 and it's more efficient than a connection-oriented service when the higher layers handle whatever sequencing, flow control, and error recovery the user applications need (internetwork services are provided by the Network Layer, after all 🌐). CDT also makes dynamic routing easier in packet- and message-switched networks 🛣️ because each data unit (packet or message) can take the most appropriate "next hop" without being boxed in by connection-mandated node configurations 🏃♀️💨
There are loads of more-or-less connectionless network layer designs and implementations out there, honestly it's giving buffet 🍓 Zilog's Z-net (which offers both "reliable" and "unreliable" service options) 🌸 DECNET's "transport layer" (which corresponds to the OSI Network layer) 🧚 Livermore Lab's Delta-t protocol (although it provides only a reliable service, doing error checking, duplicate detection, and acknowledgement) 💎 the User Datagram protocol[48] 📮 and the Cyclades network protocol[38] 🦋
Even the super connection-oriented X.25 public data networks (Canada's Datapac is the best example 🇨🇦) generally employ what amounts to a connectionless network-layer service inside their internal packet switches 😭 which lets them do flexible dynamic routing on a packet-by-packet basis 🔥 iykyk 💅
4.4 Transport Layer 🎀
The connectionless transport service matters mainly in systems that treat the Transport layer and everything below it as providing one thing generically called the "Transport Service," and that abandon or badly compromise OSI architecture above the Transport layer 🙅♀️ In those systems, a connectionless transport service might be needed for the same reasons that other, more OSI-respecting systems need a connectionless application service 🫶 Otherwise, the whole point of defining a connectionless transport service is to let a uniformly connectionless service pass efficiently through the Transport layer up to the higher layers 🚂✨
4.5 Session Layer 🌷
The whole idea of a session, which binds presentation-entities into a relationship that lasts for some stretch of time, is inherently connection-oriented 💜 So the reason to define a connectionless session service is, again, to let a uniformly connectionless service pass efficiently through the session layer to the higher layers 🌊 In this sense, the connectionless session service has exactly the same relationship to the connectionless transport service that a session-connection has to a transport-connection 🤝
4.6 Presentation Layer 💫
Very much the same considerations apply to the Presentation layer as apply to the Session layer 💅
4.7 Application Layer 💌
The most obvious reason to define a connectionless application service is to give user application processes access to the architecture's connectionless services, but it's not the only one 👀 The application layer helps user application processes converse about the meaning of the information they exchange, and it's also responsible for the overall system management side of OSI operation 🛠️ On top of the many user-application requirements for connectionless service, it can be put to good use by system management functions that monitor and report on the status of resources in the local open system 📊 by application layer management functions that need to talk in a request-response mode with similar functions in other systems to do security access control 🔐 and by user application process functions that monitor the status of activities in progress 👩💻
Having two complementary services available at each layer of the architecture raises an obvious question, though: how do you choose between them? 🤔 At this point it should be clear that just banning one or the other might simplify things for some applications, but it's not a general solution 🙅♀️ There are actually two parts to the question. First, how do you select a suitable set of cooperating services for all seven layers when you're designing a particular open system? Second, if one or more layers of the system offer both connection-oriented and connectionless services, how do you provide for dynamically picking one or the other in a given circumstance? 🧠✨
The second part is easiest to dispose of, because real systems are not the same as the abstract pile of services and protocols that OSI describes. Real systems combine services cooperatively, and the designers pay attention to how those services will work together to hit specific goals 🧩. Two services can exist at the same layer, but logical combinations for different applications are usually put together using fairly simple rules that get set during system design 💖
Working out the requirements of the applications a system has to support, plus the characteristics of the implementation technologies you prefer, also answers the first question 🎀 A system built mainly to move big files over a long-haul network would probably use only connection-oriented services 📦. One built to collect data from sensors scattered all over the place, so it can be processed at a central site, might offer a connectionless application service but use a connection-oriented network service so it stays compatible with a public data network 🛰️. Another system, built around a local area network bus or ring, might use a connectionless data link service no matter which applications it supports. And if several LANs were going to be interconnected, perhaps with other network types, it might also use a connectionless internetwork service 🌈
The definition of OSI standard services and protocols, though, has to think about the general case so it can handle a wide range of real system configurations 🫶 The guiding idea should be a balance between two goals: power and simplicity ⚖️ The service definition for each layer must include both connection-oriented and connectionless services. Otherwise, a service at one layer could be made useless by the lack of a matching service somewhere else in the hierarchy 😭 Still, the role each service plays can be totally different from one layer to the next 🦋 The Presentation, Session, and Transport layers, for example, only need to support their connectionless services because the Application layer has to provide a connectionless service to user applications, and it can't do that well if those lower layers don't 💅 Once you notice these role differences, you can get back some of the simplicity that was lost when choice was added at every layer. You don't limit the choices themselves. Instead, you limit the places in the hierarchy where switching from one type to the other (connection to connectionless, or the reverse) is allowed (see figure 6) 👑 At this stage of the CDT concept, there are excellent reasons to allow that switch in the Application, Transport, and Network layers, and in the Data Link layer too if some physical interconnection strategies are considered connectionless. In the other layers, providing one kind of service to the next-higher layer must always be done by using the same kind of service from the next-lower layer (see figure 7) 🔥 This like-to-like mapping principle has nothing to do with multiplexing. It is about service types (connection-oriented and connectionless), not about actual services. Adopting this restriction would help reach the balance mentioned above, without ruling out the combinations of services that have already proven useful 🍓
^ ^ (N+1)-LAYER
| |
| |
----------------o------------------------------o----------------
| |
,-------------------------, ,-------------------------,
| Offers a connectionless | | Offers a connection- |
| (N)-service | | oriented (N)-service |
| | | | | |
| (N)-LAYER | OR | (N)-LAYER |
| | | | | |
| Uses a connection- | | Uses a connectionless |
| oriented (N-1)-service | | (N-1)-service |
'-------------------------' '-------------------------'
| |
----------------o------------------------------o----------------
| |
| |
v v (N-1)-LAYERFIGURE 6 - Service Type Conversion
^ ^ (N+1)-LAYER
| |
| |
----------------o------------------------------o----------------
| |
,-------------------------, ,-------------------------,
| Offers a connectionless | | Offers a connection- |
| (N)-service | | oriented (N)-service |
| | | | | |
| (N)-LAYER | OR | (N)-LAYER |
| | | | | |
| Uses a connectionless | | Uses a connection- |
| (N-1)-service | | oriented (N-1)-service |
'-------------------------' '-------------------------'
| |
----------------o------------------------------o----------------
| |
| |
v v (N-1)-LAYERFIGURE 7 - Same-Service Mapping
5. Summary ✨
Support for putting connectionless data transmission in as a basic architectural element of the Reference Model has grown as people have understood the concept better 📈 The protocol work backed by various parts of the U.S. Department of Defense, for example, has long treated connections and connectionless transmission as complementary ideas, and has used both 🇺🇸 Similar work done by a division of the Institute for Computer Science and Technology at the National Bureau of Standards, which will become a series of Federal Information Processing Standards, relies heavily on connectionless concepts as well as connection-oriented ones 🧠 CDT matters a lot to some of these U.S. efforts, and that's clear from comments ANSI committee X3T5 got during the recent Reference Model ballot period. One of them says, "Publication of this material [DP7498] without incorporation of the concerns associated with Connectionless Data Trans[mission] makes a mockery of U.S. interests."[18] 💀 A somewhat less dramatic version of the same feeling shows up in the official U.S. Position on Connectionless Data Transmission[9], where X3T5, the responsible U.S. organization, "endorses SC16/N555 [Recommended Changes to Section 3 of [the Reference Model] to Include CDT] without exception and announces its intention to pursue vigorously the incorporation of CDT as the first major extension to the Basic Reference Model of OSI." In that same document, X3T5 also notes that it "intends to issue and maintain a version of DP7498 to be referred to as DP7498-prime, incorporating the CDT extensions." 🎀
There's also a lot of international support for the CDT concept. The ISO SC16/WG1 Ad Hoc Group on Connectionless Data Transmission produced the N555 document last November, and its members include representatives from France, Japan, Germany, and the United Kingdom, as well as from the U.S. 🌍 Anyone who believes CDT is an essential part of the OSI architecture hopes that, eventually, the DP7498-prime document, or its successor, will replace the exclusively connection-oriented Reference Model before the latter becomes an International Standard 🚀💜
6. Acknowledgements 🫶
[to be supplied]
APPENDIX A - Vocabulary 📚
OSI Terminology
The following terms are defined in either the text or the vocabulary annex (or both) of the Draft Proposed Reference Model of OSI (ISO/DP7498) 📖 Some terms get more than one definition in different sections of the Reference Model. These are marked with an asterisk (*), to show that choosing the definition that goes with them involved the author's personal judgement 🤓
[to be supplied]
(N)-connection(N)-service-access-point(N)-service-access-point-address(N)-layersystem(N)-entity(N)-connection-endpoint-identifier
CDT Terminology
The following terms are not yet part of the standard OSI vocabulary. They relate to the concept of connectionless data transmission 🦋
"Connectionless Data Transmission is the transmission (not transfer) of an (N)-service-data-unit from a source (N)-service-access-point to one or more destination (N)-service-access-points without establishing an (N)-connection for the transmission."
"A Connectionless (N)-Service is one that accomplishes the transmission of a single self-contained (N)-service-data-unit between (N+1)-entities upon the performance of a single (N)-service access."
Transmit: "to cause to pass or be conveyed through space or a medium." This term refers to the act of conveying only, without implying anything about reception 📡
Transfer: "to convey from one place, person, or thing, to another." A one-way peer-to-peer connotation restricts the use of this term to cases in which the receiving peer is party to and accepts the data transferred 📬
Exchange: "to give and receive, or lose and take, reciprocally, as things of the same kind." A two-way peer-to-peer connotation restricts the use of this term to cases in which both give and receive directions are clearly evident 🔁
datagramunit-data transfer/transmissiontransaction (from SC1/N688)data transmission (from DIS 2382 Section 9)
[End of Appendix A]
APPENDIX B - References 🔖
- Data Processing - Open Systems Interconnection - Basic Reference Model.
- Source: ISO/TC97/SC16
- Reference: ISO/DP7498, X3T51/80-67, X3S33/X3T56/80-121, X3S37/80-115
- Date: 12/80
- Recommended Changes to Section 3 of 97/16 N537, Basic Specifications of the Reference Model of OSI, to Include Connectionless Data Transmission.
- Source: ISO/TC97/SC16/WG1 Ad Hoc Group on Connectionless Data Transmission
- Reference: ISO/TC97/SC16/N555, X3S37/81-9, X3T51/80-68, X3S33/X3T56/80-122
- Date: 11/80
- Report of the Ad Hoc Group on Connectionless Data Transmission.
- Source: ISO/TC97/SC16/WG1 Ad Hoc Group on Connectionless Data Transmission
- Reference: ISO/TC97/SC16/N566, X3T51/80-69, X3S33/X3T56/81-13, X3S37/81-35
- Date: 11/80
4. Definitions of the Term "Connectionless Data Transmission" (a letter to the chairman of ANSC X3T51 from the acting chairman of ANSC X3T56) 💌
Source: ANSC X3S33/X3T56
Reference: X3S33/X3T56/81-22
X3T51/81-2
X3S37/81-6
Date: 1/815. Connectionless Provisions for OSI Reference Model 🌸
Source: ANSC X3S37
Reference: ISO/TC97/SC6/WG2/W12
X3S37/81-16R
Date: 2/816. Comments on Recommended Changes to Section 3 of 97/16 N537, Basic Specification of the Reference Model of OSI, to include Connectionless Data Transmission, SC16/N555 🧚
Source: DIN (FRG)
Reference: ISO/TC97/SC6/WG2/W10
Date: 2/817. Connectionless Data Transmission 🦋
Source: X3S33/X3T56 Ad Hoc Group on Connectionless Data Transmission
Reference: X3S33/X3T56/81-26
Date: 1/818. Contribution to Document ISO/TC97/SC16 N555 Concerning the Extension of General Concepts from the Basic Reference Model to Connectionless Data Transfer Mode ✨
Source: ISO/TC97/SC16/WG1 Ad Hoc Model Extension Group B
Reference:
Date: 3/819. US Position on Connectionless Data Transmission 🇺🇸
Source: ANSC X3T5
Reference: ISO/TC97/SC16/N605
X3T51/81-26
Date: 3/8110. Revision of SC16/N551 to Include Connectionless Data Transmission 💅
Source: ANSC X3S33/X3T56
Reference: ISO/TC97/SC16/N602
X3S33/X3T56/81-67
X3T51/81-20
X3S37/81-17
Date: 3/8111. Report of USA Vote and Comments on ISO DP7498 🗳️
Source: ANSC X3T5
Reference: ISO/TC97/SC16/N590
X3T51/81-29
Date: 3/8112. USA Proposed Revision to Draft Basic Session Service Specification, ISO TC97/SC16 N553 🎀
Source: ANSC X3S33/X3T56
Reference: ISO/TC97/SC16/N597
X3S33/X3T56/81-39R
X3T51/81-28
Date: 3/8113. USA Proposed Revision to Draft Transport Service Specification, ISO TC97/SC16 N563 🌈
Source: ANSC X3S33/X3T56
Reference: ISO/TC97/SC16/N601
X3S33/X3T56/81-33R
X3T51/81-17
Date: 3/8114. Comments on Connectionless Data Transmission 🍓
Source: Robert F. Stover, Honeywell Inc.
Reference: Private communication
Date: 4/8115. Proposed Changes to the OSI Transport Layer 🔥
Source: Gregory Ennis, Sytek Inc.
Reference: X3T51 Reference Model Editing Group
V3.B
Date: 3/8116. Review of the ISO Draft Proposal (DP 7498), Open System Interconnection Reference Model (Project IPSC-0168) 🔍
Source: National Security Agency, Central Security Service, Department of Defense
Reference: NSA/CSS Serial T095/008/81
X3T51 Reference Model Editing Group
V3.F
Date: 3/8117. Comments on Draft Proposal ISO/DP7498 ⚡
Source: Working Group on Power System Control Centers, IEEE Power Engineering Society
Reference: X3T51 Reference Model Editing Group
V3.I, V4.4
Date: 3/8118. Review of ISO Draft Proposal 7498 (Open Systems Interconnection) 🦄
Source: Department of the Air Force
Reference: X3T51 Reference Model Editing Group
V3.J, V4.5, V1.15, V2.H
Date: 3/8119. Proposed Improvements to Section 6 of DP7498 🌟
Source: A. Lyman Chapin, Data General Corporation
Reference: X3T51 Reference Model Editing Group
V3.M
Date: 3/8120. Comments on Section 7.4 of DP7498 💜
Source: ANSC X3S33/X3T56
Reference: X3S33/X3T56/81-30
X3T51 Reference Model Editing Group
V3.H
Date: 3/8121. Comments on DP7498 🫶
Source: ANSC X3S33/X3T56
Reference: X3S33/X3T56/81-60
X3T51 Reference Model Editing Group
V3.N
Date: 3/8122. USA Position Concerning Progression of the Reference Model of Open Systems Interconnection (Parts I and II of USA Comments on N309) 🌸
Source: ANSC X3T5
Reference: ISO/TC97/SC16/N405
X3T5/80-120
X3T51/80-43
Date: 9/8023. Addenda to the USA Position Concerning Progression of OSI Reference Model (Parts I and II) 🎀
Source: ANSC X3T5
Reference: X3T5/80-143
X3T51/80-63
Date: 9/8024. US Position on the WG1 Rapporteur's Report of October 1980 🦋
Source: ANSC X3T5
Reference: X3T5/80-142
X3T51/80-62
Date: 10/8025. Resolutions: ISO/TC97/SC16 - Open Systems Interconnection: Berlin - November 12 - 14, 1980 🌍
Source: ISO/TC97/SC16
Reference: ISO/TC97/SC16/N570
X3S33/X3T56/80-11
Date: 11/8026. NBS Analysis of Major US Government Requirements of Transport Protocol Services 📊
Source: National Bureau of Standards, US Department of Commerce
Reference: ISO/TC97/SC16/N404
X3T51/80-32
X3S33/X3T56/80-82
Date: 9/8027. Features of the Transport and Session Protocols 🧚
Source: National Bureau of Standards, US Department of Commerce
Reference: X3S33/X3T56/80-30
Date: 3/8028. Specification of the Transport Protocol 💖
Source: National Bureau of Standards, US Department of Commerce
Reference: X3S33/X3T56/81-59
Date: 2/8129. Features of Internetwork Protocol 🌐
Source: National Bureau of Standards, US Department of Commerce
Reference: X3T51/81-23
X3S33/X3T56/80-96
X3S37/81-31
Date: 7/8030. Service Specification of an Internetwork Protocol 🔗
Source: National Bureau of Standards, US Department of Commerce
Reference: X3T51/81-24
X3S33/X3T56/81-18
X3S37/81-32
Date: 9/8031. DoD Standard Internet Protocol 👑
Source: US Department of Defense Advanced Research Projects Agency
Reference: X3S33/X3T56/80-17
X3S37/80-17
Date: 1/8032. Connectionless Data Transfer (letter from the chairman of X3T51 to X3T55, X3T56, and X3S3) 💌
Source: John Day, Digital Technology, Inc.
Reference: X3T51/80-76
Date: 12/8033. Local Area Networks and the OSI Reference Model 🏠
Source: Robert R. Shatzer, Hewlett-Packard Corp.
Reference: X3T51/80-38
Date: 8/8034. An Introduction to Local Area Networks 📚
Source: David D. Clark, et. al.
Reference: IEEE Proceedings 66:11
Date: 11/7835. Issues in Packet-Network Interconnection 🧠
Source: V.G. Cerf and P.T. Kirstein
Reference: IEEE Proceedings 66:11
Date: 11/7836. Connectionless Data Transfer 💫
Source: John Neumann, Microdata Corp.
Reference: X3S33/X3T56/80-120
Date: 12/8037. A Protocol for Packet Network Interconnection 📦
Source: V.G. Cerf and R.E. Kahn
Reference: IEEE Transactions on Communication
COM-22 No. 5
Date: 5/7438. The CYCLADES End-to-End Protocol 🛤️
Source: H. Zimmermann
Reference: Proceedings of the IEEE Vol. 66 No. 11
Date: 11/7839. Interprocess Communication Protocols for Computer Networks 🤝
Source: Carl Sunshine, USC/ISI
Reference: Stanford Digital Systems Laboratory
TR105
Date: 12/7540. CCITT Recommendation X.25 - Interface Between Data Terminal Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) for Terminals Operating in the Packet Mode on Public Data Networks 📡
Source: CCITT Study Group VII
Reference: COM VII/489
Date: 11/8041. An Analysis of ARPAnet Protocols 🕵️♀️
Source:
Reference:
Date:42. ISO High-Level Data Link Control - Elements of Procedure 🔐
Source: ISO
Reference: ISO/IS4335
Date: 197743. ETHERNET Specification (Version 1.0) 🌈
Source: Xerox Corporation
Reference: X3T51/80-50
Date: 9/8044. PUP: An Internetwork Architecture 🐣
Source: D.R. Boggs, J.F. Shoch, E.A. Taft, R.M. Metcalfe
Reference: IEEE Transactions on Communications
COM-28 No. 4
Date: 4/8045. Delta-t Protocol Preliminary Specification ⏱️
Source: R.W. Watson
Reference: Lawrence Livermore Laboratories
Date: 11/7946. The Evolving IEEE 802 (Local Network) Standard 🧩
Source: Bryan R. Hoover, Hewlett-Packard Corporation
Reference:
Date:47. A System for Interprocess Communication in a Resource Sharing Computer Network 🏁
Source: D. Walden
Reference: Communications of the ACM Vol. 15
Date: 4/72📦 where this page comes from
- ietf: rfc787 1981-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms