RFC 1663

PPP Reliable Transmission

📅 published July 1994, from ietf

RFC 1663: PPP Reliable Transmission 💖

okay bestie, this is RFC 1663, called PPP Reliable Transmission 🎀 It was written by D. Rand at Novell, it's on the Standards Track, and it's dated July 1994. The header doesn't list anything it obsoletes or updates, so it's just doing its own thing ✨

Status of this Memo 📜

So this is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions to make it better 🫶 For the standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1) 💅 Distribution of this memo is unlimited 🌈

Abstract 💜

The Point-to-Point Protocol (PPP) [1] gives us a standard way to carry multi-protocol datagrams over point-to-point links 🔗

This doc defines a way to negotiate and use Numbered-Mode, as defined by ISO 7776 [2], so you get a reliable serial link 🔥

This doc is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF) 👑 Comments go to the ietf-ppp@ucdavis.edu mailing list 💌

Table of Contents 🍓

   1.     Introduction ..........................................    1
   2.     Physical Layer Requirements ...........................    2
   3.     The Data Link Layer ...................................    2
   3.1       Frame Format .......................................    2
   4.     Configuration Option Format ...........................    4
   5.     Numbered-Mode Operation ...............................    5
   5.1       Single Link ........................................    6
   5.2       Inverse Multiplexing ...............................    6
   5.3       Using Multi-Link Procedure... ......................    7
   5.4       LAPB Parameter defaults ............................    8
   SECURITY CONSIDERATIONS ......................................    9
   REFERENCES ...................................................    9
   ACKNOWLEDGEMENTS .............................................    9
   CHAIR'S ADDRESS ..............................................   10
   AUTHOR'S ADDRESS .............................................   10

1. Introduction ✨

Okay so by default, PPP packets over HDLC framed links are "connectionless" datagrams 🦋 If you want reliable transmission over the HDLC link, the implementation MUST specify the Numbered-Mode Configuration Option during Link Establishment phase 💖

Honestly, serial link reliability isn't usually a huge deal 🙄 Datagram networking is built on the assumption of best-effort non-sequential delivery. When errors get detected, datagrams are discarded 💀

But there are times when it's advisable to provide a reliable link, at least for a subset of the messages 🫶 The most obvious one is when the link is compressed. The dictionary gets recovered from the compressed data stream, and a lost datagram corrupts the dictionary, so datagrams must not be lost 😭 Not every compression type needs a reliable data stream, since the cost to detect and reset a corrupt dictionary is small 🧚

The ISO 7776 LAPB can be used to guarantee delivery. This document calls it "Numbered Mode" to tell it apart from "Unnumbered Information," which is standard PPP framing practice 🎀

When multiple parallel links are used to emulate one faster link, Bridged traffic, Source Routed traffic, and traffic subjected to Van Jacobsen TCP/IP header compression must be delivered to the higher layer in a certain sequence. But since the links are relatively asynchronous, the traffic ordering is uncertain 🌀

The ISO 7776 Multi-Link Procedure MAY be used to restore order 🔧 Implementation of the ISO Multi-Link Procedure is deprecated, and it's recommended that the PPP multilink procedure [4] be used instead 💅

2. Physical Layer Requirements 🌸

PPP Reliable Transmission has the same requirements as "PPP in HDLC Framing" [3], with the following exceptions 💖

Control Signals ⚡

PPP doesn't normally need control signals, but Numbered-Mode LAPB or LAPD does need them 🧠 They tell you when the link has connected or disconnected, and they give the Up and Down events to the LCP state machine 🔌

Numbered-Mode only touches the Address and Control fields 🎀 The rest of the frame follows whatever framing PPP is using ✨

The Address Field of the frame MUST take the value announced in the Numbered-Mode Configuration Option, and the Control Field MAY take any value valid in ISO 7776 💅

Once the link enters Numbered-Mode, Numbered-Mode MUST be used on all frames 🚫 Some implementations don't support the Unnumbered-Information control field, or the All-Stations address mixed in with Numbered-Mode frames 😬

3.1. Frame Format 🦋

The frame format below is valid under Numbered-Mode 💖 The fields are sent from left to right ➡️

   Numbered Mode
           +----------+----------+----------+
           |   Flag   | Address  | Control  |
           | 01111110 |1-2 octets|1-2 octets|
           +----------+----------+----------+
           +----------+-------------+---------+
           | Protocol | Information | Padding |
           |1-2 octets|      *      |    *    |
           +----------+-------------+---------+
           +----------+----------+-----------------
           |   FCS    |   Flag   | Inter-frame Fill
           | 16 bits  | 01111110 | or next Address
           +----------+----------+-----------------

The Protocol, Information and Padding fields are described in the Point-to-Point Protocol Encapsulation [1] 🧁 The FCS and Flag Sequence fields are described in "PPP in HDLC Framing" [3] 🌈

4. Configuration Option Format 🌸

Description 📝

The LCP Numbered-Mode Configuration Option negotiates the use of Numbered-Mode on the link 🤝 By default, or in ultimate disagreement, Unnumbered-Mode is used 💀

A summary of the Numbered-Mode Configuration Option format is shown below. The fields are sent from left to right ➡️

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |    Window     |   Address...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 🔢

The value is 11 ✨

Length 📏

The value is >= 4 💅

Window 🪟

A value between 1 and 127. This is the number of frames the receiver will buffer, which is the most frames the sender should send without getting an acknowledgement. If window < 8, then modulo 8 sequencing is used on the link. Otherwise, modulo 128 sequencing is used 🔢

It's conceivable and legal that differing window values might get announced 🤷‍♀️ However, one system can't use modulo 8 sequencing while the other uses modulo 128 🚫 So the rule is: a Configure-Nak may reduce the window, but it may not increase it 🙅‍♀️

Address 📍

An HDLC Address as specified in ISO 3309. ISO 7776 specifies four of the possible values: 1 and 3 for single link operation, and 7 and 15 for the Multi-Link Procedure. Other values consistent with ISO 3309 are considered legal 💫

Implementation of the Multi-Link Procedure is optional. A Configure-Nak may therefore force a change from MLP to single link mode, but not the reverse 🔁

If the address comes in as zero when it's received, the receiver MUST Configure-Nak with an appropriate address 🙌 If both peers send address zero, the system advertising the numerically smaller window will select the smaller address. If both windows are the same size, a random choice MUST be made. When good sources of randomness are used, the link will converge in a reasonable time 🎲

If magic numbers have been negotiated on the link, the system with the numerically smaller magic number SHOULD specify the smaller address 💅

5. Numbered-Mode Operation 👑

When using Numbered-Mode, each link is established in the usual manner for its type 🔗 The Numbered-Mode Configuration Option is negotiated, the Magic-Number Configuration Option MUST also be negotiated, and the Address-and-Control-Field-Compression Configuration Option MUST NOT be negotiated 🚫

Following successful negotiation of the Numbered-Mode Configuration Option during LCP Link Establishment phase, the system with the numerically smaller Magic-Number sends a SABM or SABM(E), and the other responds with a UA 📨 If either the SABM or UA is lost, this exchange may be repeated according to the same parameters as the configuration exchange itself, using the Restart Timer and counter values 🔁 Authentication, Link Quality Determination, and NCP Configuration follow this step ✅

Once the link has been established with Numbered-Mode, whenever re-negotiation of link configuration occurs, the entire re-negotiation MUST be conducted in Numbered-Mode 🛡️ If the Numbered-Mode Configuration Option isn't successfully re-negotiated, the link reverts to Unnumbered-Information operation before Authentication, Link Quality Determination, and NCP Configuration 🔙

When an implementation that is capable of Numbered-Mode, and is not currently configured for Numbered-Mode operation, detects a frame which has a correct FCS but does not have a UI Control octet, the implementation MUST send a DM message, immediately followed by a LCP Configure-Request 👀

When an implementation that is currently configured for Numbered-Mode operation receives a DM message, it MUST revert to Unnumbered-Information operation, and immediately send a LCP Configure-Request 🔄

When Network-Layer packets are sent over a single link, the packets are encapsulated in the following order:

    +----------+   +----------+   +----------+
    |          |   |          |   | Numbered |
    | Header   |-->| Data     |-->| Mode     |--> link
    | Compress |   | Compress |   | Header   |
    +----------+   +----------+   +----------+

5.2. Inverse Multiplexing ✨

okay so sending a bunch of connections over one link is what people call "multiplexing" 💅, and sending packets from a single connection across several parallel links is sometimes called "inverse-multiplexing" 🦋. by default PPP does literally nothing special for these links 🙈. each link gets set up and torn down on its own, negotiates its own configuration options, and can end up with different combos of stuff like ACCM, Protocol Field Compression and IP-Address. ngl this is giving flexibility, because you can run links at the same time over totally different media, like 56K sync with async backup 🔥

bestie rule #1 🔑: every link on one machine MUST have its own different Magic Numbers, and each end of every link between two peers SHOULD have Magic Numbers that are unique to those peers 💜. this protects you from patch-panel errors 🔌 as well as links that loop back on themselves 🔁.

which link gets which packets is decided by the higher level routing mechanisms 🗺️. and here's the tea ☕: if your Network-Layer compression (like Van Jacobsen Compression) needs packets to arrive in sequence, and you don't have Multi-Link Procedure support, then that compression MUST be applied on a link by link basis 💀.

                    +----------+   +----------+   +----------+
                    |          |   |          |   | Numbered |
               +--->| Header   |-->| Data     |-->| Mode     |--> link 1
               |    | Compress |   | Compress |   | Header   |
  +--------------+  +----------+   +----------+   +----------+
  | Distribution |
  +--------------+  +----------+   +----------+   +----------+
               |    |          |   |          |   | Numbered |
               +--->| Header   |-->| Data     |-->| Mode     |--> link 2
                    | Compress |   | Compress |   | Header   |
                    +----------+   +----------+   +----------+

quick heads up 🚨: this doc doesn't hand you a standard for ISO Multi-Link, BUT it does give you a way to agree on the addressing scheme you can use with Multi-Link 💖. there's a sample implementation right below ✨. implementing Multi-Link is not required, so no pressure 🫶.

when you're using the ISO 7776 Multi-Link Procedure, every link gets established the way we just talked about 🌸. on top of that, the Numbered-Mode Configuration Option gets negotiated with the right addresses for the Multi-Link Procedure 🎀. the Multi-Link Procedure is the one handling distribution to each link, and it's also the one that puts the sequence back together on the receiving side 👑.

                                                            +---> link 1
  +----------+   +----------+   +----------+                |
  |          |   |          |   | Multi    |   +--------------+
  | Header   |-->| Data     |-->| Link     |-->| Distribution |
  | Compress |   | Compress |   | Procedure|   +--------------+
  +----------+   +----------+   +----------+                |
                                                            +---> link 2

5.4. LAPB Parameter defaults 🧁

here are the default-value guidelines for the LAPB configurable parameters 💅. let's go one by one 💜.

Timer T1 ⏱️

Timer T1 is the maximum time allowed before a retransmission starts, because nothing came back for a transmitted I frame 😭. this value must be greater than the time it takes for a maximum sized frame to reach the other side of the link, plus the time for a response to be generated for that frame ✨. this SHOULD be determined dynamically, based on the round trip time delay of the link that's measured at the LAPB level 📏. if the system can't figure out the round trip time of the link, then this value SHOULD be set to twice the bit rate of the link, divided by the maximum number of bits per frame, plus 100 milliseconds of processing time 🧮. example time, bestie: on a 14,400 bps link with a maximum frame size of 8000 bits (1000 octects), the T1 value would be set to 3.7 seconds 🍓.

Timer T3 🕰️

Timer T3 gives you an indication of the idle state of the link 🦋. its value must be greater than the T1 value 💫.

Maximum number of attempts to complete a transmission, N2 🔁

Parameter N2 gives the maximum number of retransmission attempts for a given frame 🌈. if this value gets exceeded, the link SHOULD be terminated 💀. and the default value for parameter N2 SHOULD be 3 👑.

Security Considerations 🔒

okay real talk 😤 security issues are not discussed in this memo. so this doc isn't going to hand you any security guidance, and that's something to keep in mind as you read it 🙈.

References 📚

[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994.

[2] ISO 7776, Information Processing Systems - Data Communication - High Level Data Link Control Procedures - Description of the X.25 LAPB-Compatible DTE Data Link Procedures

[3] Simpson, W., Editor, "PPP in HDLC Framing", STD 51, RFC 1662, Daydreamer, July 1994.

[4] Sklower, K., "PPP MultiLink Procedure", Work in Progress.

Acknowledgments 🫶

Fred Baker was the original author of this document 🌟.

Bill Simpson contributed materially to the document 💜.

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:

Dave Rand
2180 Fortune Drive
San Jose, CA  95131

Phone: +1 408 321-1259
EMail: dave_rand@novell.com
📦 where this page comes from