RFC 1547

Requirements for an Internet Standard Point-to-Point Protocol

📅 published December 1993, from ietf

RFC 1547 🎀

Requirements for an Internet Standard Point-to-Point Protocol

Okay bestie, here are the deets 💖. This one comes from the Network Working Group 🌸 and was written by D. Perkins at Carnegie Mellon University 🎓. It's Informational, dated December 1993 📅. The header doesn't list anything it obsoletes or updates, so it's doing its own thing 🦋.

Status of this Memo ✨

So this memo's whole job is to provide information for the Internet community 💅. It does not specify an Internet standard of any kind, so don't go calling it one 🙅‍♀️. Distribution of this memo is unlimited, so share away 🫶.

Abstract 🔥

This doc is all about the evaluation criteria for an Internet Standard Data Link Layer protocol that's used on point-to-point links 🔗. Like, there are already tons of industry standard and ad hoc data link protocols out there, but none are complete AND versatile enough to be accepted as an Internet Standard 😤. So to get ready for designing one, the doc goes deep on which features a point-to-point protocol needs to qualify as an Internet Standard 🧠. It also checks the strengths and weaknesses of a bunch of existing protocols against those requirements, and honestly? Each one fails to address key issues 💀.

Historical Note: Okay so this was the design requirements doc dated June 1989, and it's been the guide for RFC-1134 through now. It's getting published for completeness and future guidance 📜✨.

Table of Contents 📑

Here's the full lineup, copied exactly so nothing gets lost 🫶:

   1.    Introduction ................................................3
   1.1   Definitions of Terms ........................................4
   2.    Required Features ...........................................6
   2.1   Simplicity ..................................................7
   2.2   Transparency ................................................7
   2.3   Packet Framing ..............................................7
   2.4   Bandwidth Efficiency ........................................8
   2.5   Protocol Processing Efficiency ..............................8
   2.6   Protocol Multiplexing .......................................8
   2.7   Multiple Physical and Data Link Layer Protocols..............8
   2.8   Error Detection .............................................9
   2.9   Standardized Maximum Packet Length (MTU) ....................9
   2.10  Switched and Non-Switched Media .............................9
   2.11  Symmetry ....................................................9
   2.12  Connection Liveness .........................................10
   2.13  Loopback Detection ..........................................10
   2.14  Misconfiguration Detection ..................................11
   2.15  Network Layer Address Negotiation ...........................11
   2.16  Data Compression Negotiation ................................11
   2.17  Extensibility and Option Negotiation ........................12
   3.    Features Not Required .......................................12
   3.1   Error Correction ............................................12
   3.2   Flow Control ................................................13
   3.3   Sequencing ..................................................13
   3.4   Backward Compatibility ......................................13
   3.5   Multi-Point Links ...........................................13
   3.6   Half-Duplex or Simplex Links ................................14
   3.7   7-bit Asynchronous RS-232 Links .............................14
   4.    Prior Work On PPP Protocols .................................14
   4.1   Internet Protocols ..........................................14
   4.1.1 RFC 891 - DCN Local-Network Protocols, Appendix A............14
   4.1.2 RFC 914 - Thinwire Protocols ................................14
   4.1.3 RFC 916 - Reliable Asynchronous Transfer Protocol............15
   4.1.4 RFC 935 - Reliable Link Layer Protocols .....................15
   4.1.5 RFC 1009 - Requirements for Internet Gateways ...............15
   4.1.6 RFC 1055 - Serial Line IP ...................................16
   4.2   International Protocols .....................................16
   4.2.1 ISO 3309 - HDLC Frame Structure .............................16
   4.2.2 ISO 6256 - HDLC Balanced Class of Procedures.................16
   4.2.3 CCITT X.25 and X.25 LAPB ....................................17
   4.2.4 CCITT I.441 LAPD ............................................17
   4.3   Other Protocols .............................................17
   4.3.1 Cisco Systems point-to-point protocols ......................17
   4.3.2 MIT PC/IP framing protocol ..................................18
   4.3.3 Proteon p4200 point-to-point protocol .......................18
   4.3.4 Ungermann Bass point-to-point protocol ......................18
   4.3.5 Wellfleet point-to-point protocol ...........................19
   4.3.6 XNS Synchronous Point-to-Point Protocol .....................19
   REFERENCES ........................................................20
   SECURITY CONSIDERATION.............................................21
   CHAIR'S ADDRESS ...................................................21
   AUTHOR'S ADDRESS ..................................................21
   EDITOR'S ADDRESS ..................................................21

1. Introduction 🦋

Bestie, the Internet has been blowing up 📈 with hosts running IP [1]. The vast majority of these hosts sit on Local Area Networks (LANs) of all kinds, Ethernet being the most common 🧃. Most of the rest connect over Wide Area Networks (WANs), like X.25 style Public Data Networks (PDNs) 🌐.

Back in the day, not many hosts used simple point-to-point links 🙈. Which is kinda wild, because point-to-point serial links are among the oldest ways to do data communications, and basically every host supports them. Asynchronous RS-232 interfaces? Essentially everywhere 💅.

One reason there were so few point-to-point IP links? There was no single established encapsulation protocol 😭. Plenty of non-standard ones existed (and at least one de facto standard), but nothing everyone agreed on as an Internet Standard. Iykyk.

Lots of protocols got proposed to the Internet community, but nobody reached consensus on which one should become the standard 🤷‍♀️. Maybe that's because the proposals were often fixing specific problems instead of offering general purpose service 🧩.

Case in point: one of the most successful protocols so far was Rick Adam's SLIP for BSD UNIX [9] 🏆. But honestly? SLIP only gives the most basic support for sending IP datagrams over asynchronous serial lines. It totally skips stuff like using protocols other than IP and using synchronous links 🙃.

So this doc puts together a set of requirements for an Internet Standard point-to-point protocol (ISPPP) 📋. It isn't picking one design 🙅. Any solutions in the text are just examples, and they don't rule out other implementations 🌈.

The doc is split into four big sections 🍰. Section 1 defines the technical terms used throughout. Section 2 lists the proposed requirements and digs into issues other protocols just ignore 👀. Section 3 tries to clarify a bunch of non-requirements. Section 4 checks existing protocols against the requirements and spills the tea on how each one fails to address key issues ☕.

1.1 Definitions of Terms 📖

Okay, so this section defines a bunch of the terms used later on 🧠. The words "layer" and "level" get used a lot, and they mean protocol layers as defined by the International Organization For Standardization's Reference Model (ISORM) standard. Specifically, Physical Layer, Data Link Layer and Network Layer mean layers one, two and three of the ISORM respectively. A "higher layer" is one with a numerically larger layer number 🔢.

datagram 🎁

Basically the unit of transmission at the network layer (think IP 🌊). A datagram may get encapsulated in one or more packets (q.v.) that get passed down to the data link layer.

data link layer 🔗

Layer two in the ISO reference model. It defines how bits sent and received by the physical layer get recognized as bytes and frames. It may also define procedures for error detection and correction, sequencing and flow control 🛠️.

fragment 🧩

This is the result of fragmentation. Fragmentation at the network layer breaks large datagrams into multiple parts that are less than or equal to the size of the packets passed to the data link layer. Fragmentation at the data link layer breaks large packets into multiple frames 💥.

frame 🖼️

The unit of transmission at the data link layer. A frame may include a header and/or a trailer along with some number of units of data 📦.

framing protocol 🚧

A protocol at the data link level that marks where a frame begins and ends as it travels across a link 🏁.

internet 🌐

An interconnected system of networks tied together by a common "internet protocol," giving a common and consistent network address structure 💞.

Internet 🌍

Specifically refers to the IP Internet.

Internet Standard Point-to-Point Protocol (ISPPP) 👑

A point-to-point protocol that's been declared an official Internet Standard. This protocol does not yet exist, but its proposed characteristics are presented in this paper ✨.

Maximum Transmission Unit (MTU) 📏

The biggest packet (q.v.) you can send over a point-to-point link without triggering network layer fragmentation.

network layer 🛣️

Layer three in the ISO reference model. Responsible for routing packets (q.v) between physical networks.

octet 8️⃣

A unit of transmission made up of 8 bits. On most machines an octet is the same as a byte or a character, but that doesn't have to be true 🤓.

packet 📦

The unit of transmission passed across the interface between the network layer and the data link layer. A packet is usually mapped to a frame (q.v.); the exception is when data link layer fragmentation is being performed.

physical layer ⚡

The first layer in the ISO reference model. Describes the electrical, mechanical and timing characteristics of a link.

point-to-point protocol (ppp) 🔌

A data link layer protocol for sending packets (q.v.) over a point-to-point link. In the following discussion, the acronym "ppp" refers to any generic point-to-point protocol.

serial line IP (slip) 🧵

Often used incorrectly as a synonym for "point-to-point protocol," "slip" specifically refers to any protocol for sending IP datagrams over a serial point-to-point line.

SLIP 🔠

Lots of proposed protocols got named "SLIP," so in this doc, SLIP (uppercase) means Rick Adam's slip (q.v.) for BSD UNIX [9] 💖.

2. Required Features ✨

Okay so, for a point-to-point protocol to get accepted by the Internet community, it MUST adequately address a whole bunch of requirements 💅. This section lists the proposed requirements and talks through them. The main focus is on protocol architecture, but implementation requirements come up sometimes too 🎀.

These requirements were picked to make sure the ISPPP actually serves its users 🦋. Some needs are universal and set clear rules for the protocol (a packet framing protocol is an absolute necessity, obviously 😭). Other needs are more specific and can even clash. Connection liveness detection is super important on some links but can be wildly expensive on others 💀. A standard protocol MUST address all of these needs, and in particular, it MUST be able to resolve conflicts effectively ✨.

Resolving these conflicts means a protocol feature needs both enabled and disabled modes, and these modes MUST be compatible with each other. Enabled mode lets the protocol solve problems where they exist. Disabled mode lets problems be ignored where they don't. To assure interoperability, implementations are REQUIRED to support both modes and to let the user (not necessarily human) dynamically choose which one is appropriate 🫶.

This is basically the same trick the User Datagram Protocol (UDP) [2] uses 🌈. The UDP datagram checksum may be computed (enabled mode) or it may not (disabled mode). Compatibility is maintained by requiring the checksum to be transmitted as zero in disabled mode and ignored when received as zero in either mode. Implementations of UDP are generally encouraged to support both modes, but they let the application choose the mode.

2.1 Simplicity

The ISPPP MUST be simple 🧚. The Internet architecture very carefully puts the most complexity in the transport layer (that's TCP, bestie 💖). The internetwork layer (IP) is a fairly simple, almost stateless protocol that provides an unreliable datagram service. The data link layer needs to provide no more capability than the IP protocol does. No error correction, sequencing or flow control is necessary. Including these would in most cases needlessly duplicate the capabilities of the transport layer, and might possibly decrease efficiency. This is not to say that these capabilities must never be included, because there are some cases which may warrant them. For instance, very noisy links may be handled more efficiently by a more complex data link layer protocol such as CCITT's LAPB. Nevertheless, the watchword for a point-to-point protocol SHOULD be simplicity 🍓.

A simple design also decreases the incidence of programming errors, which makes interoperability among different implementations more likely. Since interoperability is a primary goal of standardization, this is another strong argument for simplicity 💜.

2.2 Transparency

The ISPPP MUST be transparent to higher layers. The protocol MUST NOT place any constraints on transmitted data. All ISPPP data, including higher level headers as well as data, MUST be transported unmodified end-to-end. No restrictions are placed on how the ISPPP accomplishes this. For example, if the ISPPP uses a particular character for framing, it MUST also provide some way of disambiguating higher level data containing that character from a framing character (such as escaping or bit-stuffing). This is mainly an issue for the data link and physical layer protocols incorporated into the ISPPP 🔥.

2.3 Packet Framing

The ISPPP MUST be able to correctly and efficiently frame packets. A receiver MUST be able to locate correctly the beginning and end of each transmitted packet. Within each packet, the receiver MUST be able to identify the boundaries of each octet. Finally, within each octet, each bit MUST be located and identified. No restrictions other than those specified in this document are placed on the packet framing protocol 🎀.

2.4 Bandwidth Efficiency

The ISPPP MUST make efficient use of available bandwidth 🌸. At most, the ppp overhead may impose a few percent reduction in raw link bandwidth.

2.5 Protocol Processing Efficiency

The processing of the ISPPP headers MUST typically be very fast and efficient ⭐. The format for data packets SHOULD be very simple in the normal case, without complex field checking. No overcomplicating the headers, bestie 🙈.

2.6 Protocol Multiplexing

The ISPPP MUST support multiplexing of many higher level protocols. Although the Internet community is mainly interested in IP, co-existence of other protocols is frequently required 🧚. IP networks must often support additional protocols such as AppleTalk, DECnet, IPX, and XNS. For point-to-point links connecting gateways on geographically separated Local Area Networks (LANs), the ISPPP MUST simultaneously support all protocols implemented on both the LANs and the gateways. This suggests that the ISPPP MUST include a protocol type field or other multiplexing scheme. Given the large number of protocols, the potential use of the protocol type field as a data compression aid, and the experimental nature of the Internet, eight bits of type field are not sufficient. Sixteen bits of type field are suggested, although twelve bits (4096 protocols) SHOULD suffice 👑.

The ISPPP MUST support a multiplicity of physical and data link layer protocols. Many types of point-to-point links exist. Links can be serial or parallel, synchronous or asynchronous, low speed or high speed, electrical or optical. Standards are REQUIRED for the transmission of IP datagrams over each type of commonly used link 🌈.

The ISPPP MUST NOT inhibit the use of any type of link. This includes, but is not limited to, asynchronous, bit-oriented synchronous (HDLC [10] and X.25 LAPB [11]), and byte-oriented synchronous (BISYNC and DDCMP [15]) links 💅.

The ISPPP MUST initially provide support for at least the following types of links:

  • Full duplex asynchronous RS-232 [3] links with 8 bits of data and no parity, ranging in speeds from 300 to 19.2k bps or more.
  • Full duplex bit-oriented synchronous links including RS-422, RS-423, V.35 and T1.
  • Other links SHOULD be standardized as the need arises.

2.8 Error Detection

The ISPPP MUST provide some form of basic error detection. Most network and transport layer protocols provide mechanisms to detect corrupted packets. However, some network protocols expect error-free transmission and either provide error detection only on a conditional basis or don't provide it at all 🙄. The consensus of the Internet community is that error correction SHOULD always be implemented in the end-to-end transport. Link error detection, in the form of a checksum, Cyclic Redundancy Check (CRC) or other frame check mechanism, is useful to prevent wasted bandwidth from propagation of corrupted packets. Link level error correction is not REQUIRED 💖.

2.9 Standardized Maximum Packet Length (MTU)

The ISPPP MUST have a standardized default maximum packet length for each type of point-to-point link. This standardization helps to promote interoperable implementations. Higher layer protocols MUST NOT attempt to transmit packets longer than the MTU. If a higher layer protocol does try to transmit a packet which is too long, the ISPPP MUST drop the packet and return an error 🚫. The MTU MAY potentially be changed from the default via some sort of explicit negotiation or private agreement, but the default MUST be enforced in all other cases. The default SHOULD be at least 1500 bytes, to efficiently carry common LAN traffic 🍓.

2.10 Switched and Non-Switched Media

The ISPPP MUST be able to support both switched (dynamic) and non-switched (static) point-to-point links. A common example of a non-switched link is a 3-wire asynchronous RS-232 cable which might connect a host to a particular gateway. Switched media may be exemplified by connections over a standard voice network or an Integrated Services Digital Network (ISDN). Links over ISDN are currently rare, but they're expected to become increasingly commonplace 🌸. To be a viable standard, the ISPPP MUST be able to effectively support both types of links. Procedures for establishing switched connections are beyond the scope of this document.

2.11 Symmetry

The ISPPP SHOULD operate symmetrically to maximize flexibility ✨.

The ISPPP MUST allow communications among any combination of gateways and hosts. One host may need to communicate directly with another host, or it may be connected to a gateway to gain access to a whole network. A gateway may establish a connection to a single host in order to deliver a packet, or it may connect to another gateway on a permanent or transient basis. Symmetry is destroyed by pre-assigned static roles, such as master and slave or gateway and host 🙅‍♀️. If necessary, roles MAY be dynamically determined on a per connection basis.

2.12 Connection Liveness

The ISPPP MUST include a mechanism to automatically determine when a link is functioning properly and when it is defunct. This mechanism SHOULD be enabled by default, but the protocol and all implementations MUST allow this mechanism to be disabled 🔍.

When enabled, this mechanism SHOULD discover changes in a link's status in a timely fashion, no more than a few minutes. Continuing to utilize a link which is down often causes routing problems commonly referred to as "black holes". These problems can be hard to find and diagnose 💀. By automatically detecting a failing link, a point-to-point protocol can avoid such problems, and it can also provide a powerful tool for a network manager trying to locate and remedy the fault 👑.

When a point-to-point connection is not functioning properly, it MUST be declared "down" for the purposes of routing packets for higher level protocols. In order to certify a link "up", the systems on either end of the link MUST be able to successfully exchange packets. In other words, the systems at both ends MUST be able both to transmit and to receive packets, and the link MUST be able to transport packets in both directions. Links are defined to be "down" at initialization, and their liveness MUST be verified before they MAY be declared "up" 🦋.

This feature MAY be disabled in situations where connection status determination is "expensive". For example, a link may traverse a Public Data Network (such as TELENET or TYMNET) which accounts for bandwidth utilization. Constant pinging would result in charges being accrued even in the absence of useful communications 🙈.

2.13 Loopback Detection

The ISPPP MUST be capable of automatically detecting a looped-back link without operator assistance. Modems and other communications gear are often placed in a loopback mode to aid in diagnosis of circuit failures 🔧. Detection of this condition MUST take no longer than one period of the liveness protocol. While the link is in loopback mode, each end of the link MUST declare the other end to be unreachable. However, to aid in diagnosis, each end of the link MAY declare itself reachable for any higher-level protocol which distinguishes between the two ends of the link 🫶.

2.14. Misconfiguration Detection 🔍

okay so the ISPPP has to be able to spot misconfigured point-to-point connections super fast ⚡. a connection that's misconfigured must never be declared to be up, no exceptions bestie 🙅‍♀️. gateways especially have more than one point-to-point connection, and when lots of cables end up in one small area it's giving total chaos 😭. it is SO easy to plug a cable into the wrong connector or even swap two cables 🙈. the protocol should do its best to protect against these mix-ups by checking the remote end's identity whenever possible before marking an interface as operational 🫶. the point of this check isn't rigorous authentication, it's just catching simple errors ✨.

2.15. Network Layer Address Negotiation 🦋

the ISPPP must let network layer addresses (like IP ones) be negotiated 🌐. the negotiation algorithm should be as simple as possible and must be guaranteed to terminate in all cases, periodt 💅.

so a bunch of network layer protocols and implementations need to know the addresses at both ends of a point-to-point link before packets can be routed 🗺️. those addresses can be statically configured, but sometimes it's necessary or convenient for them to be dynamically ascertained at connection establishment 🤝. this is especially important when switched media are used. for example, a dial-up IP gateway must know the IP address of its peer before packets can be successfully routed 📞. that address can be either statically or dynamically configured. if it's static, the gateway's peer must therefore learn the static address (static with respect to the gateway) 📌. if it's dynamic, the gateway must dynamically learn the address used by its peer 🔄.

2.16. Data Compression Negotiation 📦

the ISPPP must provide a way to negotiate the use of data compression algorithms. this mechanism should be as simple as possible and must be guaranteed to terminate in all cases 🙌. the protocol is not required to standardize any data compression algorithms, so conforming implementations may refuse to do data compression when negotiating. refusal to do data compression always takes precedence over an offer to do it, so no is no 🛑.

BUT (and this is the iconic part ✨) to allow data compression between consenting systems, the point-to-point protocol must not impede the use of data compression. in fact, it should be possible to use multiple, independent data compression schemes simultaneously 🎶. data compression algorithms are still very experimental in the Internet environment, so it's likely that many different algorithms will get tried 🧪. the negotiation protocol must distinguish between these different algorithms, so data compression isn't enabled unless the same algorithm or algorithms are used at both ends of the connection 🫂. and the number of such supported algorithms must be easily extensible 🌈.

2.17. Extensibility and Option Negotiation 🧩

the ISPPP must allow for future extensions in a flexible way. the Internet will never stop evolving 🌱. changes in technology and user demands keep creating new requirements, so to function effectively as a standard, the protocol has to be able to evolve along with its environment 🦋.

to make that happen, the ISPPP should be designed to be as extensible as possible and to allow for experimentation within the guidelines of the other requirements in this document 🧪. a proposed solution is to specify an option negotiation protocol 💡. this could be used to negotiate network layer addresses, data compression schemes, MTU, encryption, etc. ✨. the option negotiation protocol must itself be extensible. it should allow the negotiation of a large number of future options, and it should allow the use of other types of point-to-point links and encapsulation schemes 👑.

3. Features Not Required 🚫

this section talks about functionality that's explicitly not required 🙅‍♀️. these functions may be included in implementations as long as the inclusion doesn't violate any of the requirements itemized in the previous section 💖.

3.1. Error Correction 🛠️

remember how we said earlier in the Simplicity and Error Detection sections? error correction is the responsibility of the transport layer and is not required in a point-to-point protocol 🙌. BUT on links with high error rates, performance may go up by adding error correction at the data link level 📈. so the ISPPP must not prevent the addition of error correction by private agreement, even though those mechanisms aren't required in the basic implementation 🤝.

3.2. Flow Control 🌊

flow control (such as XON/XOFF) is not required 🙅‍♀️. any implementation of the ISPPP is expected to be capable of receiving packets at the full rate possible for the particular data link and physical layers it uses 🏎️. if higher layers can't receive packets at the full rate, it's up to those layers to discard packets or invoke flow control procedures 🗑️. like we said before, end-to-end flow control is the responsibility of the transport layer. including flow control within a point-to-point protocol often causes violation of the simplicity requirement, and nobody wants that 😤.

3.3. Sequencing 🔀

sequencing of packets is not required 🙃. the ISPPP needs to provide no more service than the IP protocol, which is an unreliable datagram service that's free to reorder packets 🎲. in fact, it's specifically allowed to reorder packets based on some type-of-service criteria implemented in higher-level protocols 💅.

3.4. Backward Compatibility 🕰️

there is no requirement for the ISPPP to provide backward compatibility with any other point-to-point protocol 🙌. first, there are no official Internet Standards that backward compatibility must be maintained with. second, trying to maintain backward compatibility may lead to needless restrictions on the new protocol 🚧. however, the designers of the ISPPP don't need to go out of their way to inhibit backward compatibility either 🫶.

there is no requirement for supporting multi-point links 🙅‍♀️. a lot of the required features are only valid between two peers. these links are rare enough that the benefits of supporting them are outweighed by the added complexity they'd bring into the ISPPP 🧠.

Historical Note: The original rationale also stated: "Furthermore, it is unlikely that many new types of multi-point links will be introduced in the foreseeable future." Since this was written, considerable effort has been expended in new multi-point links, including Switched Multimegabit Data Service, Frame Relay, and Asynchronous Transfer Mode. However, it is clear that these are considerably more complex than ISPPP. 🙈

support for half-duplex or simplex links is not required 🙅‍♀️. these types of links aren't in common use in the current Internet. half-duplex links need some method of turning the line around, but the ISPPP doesn't need an explicit mechanism for handling line turnaround 🔄. that kind of support might get added in the future through the required extension mechanism 🔮.

the use of asynchronous RS-232 doesn't need to support 7-bit links. 8-bit links are the predominant ones in the Internet environment, and supporting 7-bit links would add unnecessary complexity 🙅‍♀️💀.

4. Prior Work On PPP Protocols 📚

this section reviews a bunch of existing point-to-point and data link layer protocols and points out which of our requirements they don't satisfy 🕵️‍♀️.

4.1. Internet Protocols 🌐

4.1.1. RFC 891 - DCN Local-Network Protocols, Appendix A

in Appendix A of RFC 891, "DCN Local-Network Protocols" [4], D.L. Mills describes the data link layer packet formats used by the Fuzzball system for asynchronous, character-oriented synchronous, DDCMP, HDLC, ARPANET 1822, X.25 LAPB and ethernet links 📝. these protocols meet the stated requirements for simplicity, transparency, packet framing and efficiency, but they fall short on a lot of the others 😬. most of them assume the use of the IP protocol and don't include any type of protocol demultiplexing field. no error detection mechanism is provided except when it's necessary to comply with another standard, like ethernet 🫠. RFC 891 doesn't mention the MTU used for any of these links. loopback detection and misconfiguration detection aren't discussed either. finally, no option negotiation scheme is defined, and without a protocol demultiplexing field it would be difficult or impossible to include one 🚫.

4.1.2. RFC 914 - Thinwire Protocols

RFC 914, "Thinwire Protocols" [5], discusses the use of low speed links in the Internet 🐢. this document puts its main emphasis on decreasing round-trip delay and increasing link efficiency with the help of header compression (vs. data compression) techniques ⚡. three "Thinwire" protocols are discussed: Thinwire I, Thinwire II and Thinwire III. the latter two need a reliable data link layer protocol, and one such protocol, "SLIP" (not to be confused with Rick Adams' SLIP), is proposed in Appendix D of the RFC 🧐. as proposed, "SLIP" doesn't meet many of the stated requirements. it isn't terribly complex, but as a reliable, error detecting and correcting protocol, it's not "simple" 😩. the 32 octet packet size makes it inefficient for large or uncompressed packets, which means it needs complex fragmentation and reassembly 🧩. the use of links other than asynchronous ones isn't mentioned. the entire reliable link layer would be redundant over LAPB links 🔁. and there's no mechanism for option negotiation or future extensibility 🙃.

4.1.3. RFC 916 - Reliable Asynchronous Transfer Protocol

RFC 916 [6] presents RATP, the Reliable Asynchronous Transfer Protocol 🛡️. RATP provides error detection and correction, sequencing and flow control across a point-to-point connection. it's directed towards full duplex RS-232 links, although it's useful for other point-to-point links too 🔌. the author claims RATP isn't as complex as some other protocols, but it's far from simple 🤨. RATP solves a lot of the problems we've labeled non-requirements, and it fails to solve many of our stated requirements 💔. specifically, RATP doesn't support option negotiation and has no mechanism for future extensibility. since RFC 916 was published, no consensus has emerged advocating RATP. for these reasons, RATP is not recommended as the ISPPP 🚫.

RFC 935 [7] is a rebuttal to the protocols proposed in RFCs 914 and 916 🥊. J. Robinson discusses existing and widely-used national and international standards that meet the needs addressed by the two prior RFCs 🌍. the standards reviewed include character-oriented asynchronous and synchronous (bisynch) protocols and bit-oriented synchronous protocols. RFC 935 doesn't present any higher level issues, like option negotiation or extensibility 🤷‍♀️.

4.1.5. RFC 1009 - Requirements for Internet Gateways

Section 3 of RFC 1009, "Constituent Network Interfaces" [8], briefly discusses requirements for transmitting IP datagrams over a number of types of point-to-point links 📬. those include X.25 LAPB, HDLC framed synchronous links, Xerox Synchronous Point-to-Point synchronous lines, and the MIT Serial Line Framing Protocol for asynchronous lines 🧾. RFC 1009 only mentions these as reasonable candidates and doesn't go into depth on any of them. all of them get discussed further in this document 🫶💜

4.1.6 RFC 1055 - Serial Line IP 🦋

Okay so Rick Adams' Serial Line IP (SLIP) protocol [9] is basically the de facto standard, bestie 💅 It got popular because of the 4.2 and 4.3BSD UNIX operating systems. SLIP is super easy to add to 4.2 systems and it's included with 4.3. Tons of other TCP/IP implementations added SLIP too so they'd stay compatible 🫶

BUT ngl, SLIP is not a real standard. The protocol only got published in RFC form recently. Before RFC 1055 it was specified in the SLIP source code 💀 SLIP doesn't meet most of the requirements we talked about above. It absolutely meets the requirement for simplicity 🍓 and also meets the requirements for transparency and bandwidth efficiency ✨ However, SLIP only handles sending IP packets over asynchronous serial lines. It has no higher level protocol field for demultiplexing, so it can't support multiple concurrent higher level protocols 😭 It's only a framing protocol, so it would be totally redundant with a LAPB synchronous link. SLIP has zero mechanism for error detection, not even parity. And since there's no protocol type field, SLIP doesn't support any kind of option negotiation or extensibility. Not it 🙈

4.2 International Protocols 🌍

4.2.1 ISO 3309 - HDLC Frame Structure 🎀

ISO 3309 [10], the HDLC frame structure, is a simple data link layer protocol that frames packets sent over bit-oriented synchronous links. Special flag sequences mark where frames start and end, and bit stuffing lets data containing flag characters get sent anyway 🧚 A 16-bit Frame Check Sequence handles error detection.

By itself, the HDLC frame structure doesn't meet most of the requirements. HDLC doesn't do protocol multiplexing, standard MTUs, fault detection or option negotiation. There's no mechanism for future extensibility either 😭

Given how widely accepted and simple the HDLC frame structure is, it may be an ideal building block for the ISPPP 👑

4.2.2 ISO 6256 - HDLC Balanced Class of Procedures 💜

ISO 6256, the HDLC Balanced Class of Procedures, is a data link layer protocol that gives you error correction, sequencing and flow control. It builds on ISO 3309 and ISO 4335, HDLC Elements of Procedures.

When it comes to our requirements, ISO 6256 doesn't give us any more utility than ISO 3309 does. The extra capabilities it adds are all considered unnecessary and overly complex 🙄

4.2.3 CCITT X.25 and X.25 LAPB 🌸

CCITT recommendation X.25 [11] describes a network layer protocol that provides error-free, sequenced, flow controlled virtual circuits. X.25 includes a data link layer, X.25 LAPB, which uses ISO 3309, 4335 and 6256. Neither X.25 LAPB nor full LAPB meets any more of our requirements than the ISO protocols do ✨

4.2.4 CCITT I.441 LAPD 🦄

CCITT I.441 LAPD [12] defines the Link Access Procedure on the ISDN D-Channel. The data link layer of LAPD is very similar to LAPB's and fails to meet the same requirements 🥲

4.3 Other Protocols 🧁

4.3.1 Cisco Systems point-to-point protocols 🖤

The Cisco Systems gateway supports both asynchronous links using SLIP and synchronous links using either simple HDLC framing, X.25 LAPB or full X.25. The HDLC framing procedure includes a four byte header. The first octet (address) is either 0x0F (unicast intent) or 0x8F (multicast intent). The second octet (control byte) is left zero and isn't checked on reception. The third and fourth octets contain a standard 16 bit Ethernet protocol type code.

A "keepalive" or "beaconing" protocol is used to make sure the two-way connectivity of the serial line is working. Each end of the link periodically sends two 32 bit sequence numbers to the other side. One sequence number is the local side's sequence number, and the other is the sequence number received from the other side. Hearing the local sequence number back from the other side means the link is working in both directions 🔥

The keepalive protocol is extensible. One extension is used to default IP addresses on serial lines of systems without non-volatile memory. A request for address is sent to the remote side. The remote side responds with its own IP address and a subnet mask. When the querying side gets the reply, it checks whether the host portion of the remote address is either 1 or 2. If so, the opposite address is chosen for the local address. If not, the protocol can't be used and we'd have to rely on other address resolution means. This protocol assumes that each serial link uses one subnet or network number.

LAPB assuming IP is another possible encapsulation. A multi-protocol extension of LAPB (multi-LAPB) includes a 16 bit Ethernet type code after the address and control bytes and in front of the actual protocol data. DDN X.25 and Commercial X.25 encapsulations are also supported. Multiple protocols are supported by making protocol dependent CALL REQUEST's 📞

4.3.2 MIT PC/IP framing protocol 🌷

The MIT PC/IP framing protocol [13] provides a mechanism for transmitting IP datagrams over asynchronous links. The low-level protocol (LLP) sublayer provides encapsulation, while the local net protocol provides multiplexing of IP datagrams and IP address request packets. The protocol only allows host-to-gateway connections. Host-to-gateway flow control is provided by requiring the host to transmit request packets to the gateway until an acknowledgment is received. Rudimentary IP address negotiation requires the host to ascertain its IP address from the gateway.

The protocol does not implement error detection, connection status determination, fault detection or option negotiation. Only asynchronous links are supported.

4.3.3 Proteon p4200 point-to-point protocol 🐚

The Proteon p4200 multi-protocol router supports transmission of packets over bit-oriented synchronous links with a wide range of speeds (zero to 2 Mb/sec). The p4200 point-to-point protocol encapsulates packets inside HDLC frames but does not use the HDLC address or control fields. These two octets are instead used for a 16-bit type field. The p4200 does use the HDLC frame check sequence trailer. Protocol type numbers are ad hoc and do not correspond to any existing standard. A simple liveness protocol detects dead connections.

Although the Proteon protocol does meet many of our requirements, it does not meet our requirements for option negotiation.

4.3.4 Ungermann Bass point-to-point protocol 🎈

The Ungermann Bass router supports synchronous links using simple HDLC framing. Neither the HDLC address nor the control field is used, and IP datagrams are placed immediately after the HDLC flag.

The U-B protocol does not meet any of our requirements for fault detection or option negotiation. No mechanism for future extensibility is currently defined.

4.3.5 Wellfleet point-to-point protocol 💌

The Wellfleet router supports synchronous links using simple HDLC framing. The HDLC framing procedure uses the HDLC address and places the Unnumbered Information (UI) command in all frames. A simple header following the UI command provides a two octet type field using the same values as Ethernet.

The Wellfleet protocol does not meet any of our requirements for fault detection or option negotiation. No mechanism for future extensibility is currently defined, although one could be added.

4.3.6 XNS Synchronous Point-to-Point Protocol 🪩

The Xerox Network Systems Synchronous Point-to-Point protocol (XNS PPP) [14] was designed to address most of the same issues that an ISPPP must address. In particular, it addresses simplicity, transparency, efficiency, packet framing, protocol multiplexing, error detection, standard MTUs, symmetry, switched and non-switched media, connection status, network address negotiation and future extensibility. However, the XNS SPPP does not meet our requirements for multiple data link layer protocols, fault detection and data compression negotiation. Although protocol multiplexing is provided, the packet type field has only 8 bits, which is too few 🙃

References 📚

  • [1] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.
  • [2] Postel, J., "User Datagram Protocol", STD 6, RFC768, USC/Information Sciences Institute, August 1980.
  • [3] Electronic Industries Association, EIA Standard RS-232-C, "Interface Between Data Terminal Equipment and Data Communications Equipment Employing Serial Binary Data Interchange", August 1969.
  • [4] Mills, D. L., "DCN Local-Network Protocols", STD 44, RFC 891, University of Delaware, December 1983.
  • [5] Farber, David J., Delp, Gary S., and Conte, Thomas M., "A Thinwire Protocol for Connecting Personal Computers to the Internet", RFC 914, University of Delaware, September 1984.
  • [6] Finn, G., "Reliable Asynchronous Transfer Protocol (RATP)", RFC 916, USC/Information Sciences Institute, October 1984.
  • [7] Robinson, J., "Reliable Link Layer Protocols", RFC 935, BBN, January 1985.
  • [8] Braden, R., and J. Postel, "Requirements for Internet Gateways", STD 4, RFC1009, USC/Information Sciences Institute, June 1987.
  • [9] Romkey, J., "A Nonstandard for the Transmission of IP Datagrams Over Serial Lines: SLIP", STD 47, RFC 1055, June 1988. STD 4, RFC 1009, June 1987.
  • [10] ISO International Standard (IS) 3309, "Data Communications - High-level Data Link Control Procedures - Frame Structure", 1979.
  • [11] 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", Vol. VIII, Fascicle VIII.2, Rec. X.25.
  • [12] CCITT Recommendation Q.921 "ISDN User-Network Interface Data Link Layer Specification".
  • [13] Romkey, J.L., "PC/IP Programmer's Manual", Massachussetts Institute of Technology Laboratory for Computer Science, January 1986.
  • [14] Xerox Corporation, "Synchronous Point-to-Point Protocol", Xerox System Integration Standard, Stamford, Connecticut, XSIS 158412, December 1984.
  • [15] "Digital Data Communications Message Protocol", Digital Equipment Corporation.

Security Consideration 🔒

Security issues are not discussed in this memo, so there's nothing more from me on that one.

Chair's Address 🪄

The working group can be contacted via the current chair:

      Fred Baker
      Advanced Computer Communications
      315 Bollay Drive
      Santa Barbara, California  93117

      EMail: fbaker@acc.com

Author's Address 🖊️

Questions about this memo can also be directed to:

      Drew Perkins
      4015 Holiday Park Drive
      Murrysville, PA  15668

      EMail: perkins+@cmu.edu

Editor's Address 🌈

Typographic revision and historical notes by:

      William Allen Simpson
      1384 Fontaine
      Madison Heights, Michigan  48071

      EMail: Bill.Simpson@um.cc.umich.edu
📦 where this page comes from