RFC 2686

The Multi-Class Extension to Multi-Link PPP

📅 published September 1999, from ietf

Title Block and Status ✨

Okay bestie, let's get the basics locked in first 💅 This one is RFC 2686: The Multi-Class Extension to Multi-Link PPP 🎀. It was written by C. Bormann from Universitaet Bremen TZI, it's a Standards Track document, and it's dated September 1999 🦋. It doesn't obsolete or update anything, so no drama there 🌸.

This is part 1 of 3 🫶, so more is coming!

Status of this Memo 🌈

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please check the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited 💜.

Copyright Notice 🌈

Copyright (C) The Internet Society (1999). All Rights Reserved 💖.

Abstract 🦋

Okay so a companion document lays out an architecture for giving integrated services over low-bitrate links, like modem lines, ISDN B-channels, and sub-T1 links [1] 📞. The main pieces are a real-time encapsulation format for asynchronous and synchronous low-bitrate links, a header compression setup built for real-time flows, negotiation protocols that routers (or hosts and routers) use with each other, and announcement protocols that apps use so the negotiation can happen 🤝.

This document proposes the fragment-oriented solution for the real-time encapsulation part of that architecture ✨. The general idea is to start with the PPP Multilink fragmentation protocol [2] and add a small number of extensions that bring in new features and cut down on overhead 🧚.

1. Introduction ✨

So the Internet is famous for "best-effort" service, right? 💅 Well, extra service types ("integrated services") that support real-time multimedia are being developed and deployed now 🎀.

This document defines the fragment-oriented solution for the real-time encapsulation part of the architecture, meaning the queues-of-fragments type sender [1] 🌸. The architecture doc goes into more detail, but the short version is that a real-time encapsulation format is needed. For example, a 1500 byte packet on a 28.8 kbit/s modem link hogs the line for about 400 ms 😭. That adds a worst-case delay that makes real-time apps have round-trip delays of at least about a second, which is totally unacceptable for a real conversation 💀. The PPP extensions in this document let a sender fragment packets of different priorities into multiple classes of fragments, so high-priority packets can squeeze in between fragments of lower-priority ones 🦋.

A companion document based on these extensions [5] defines a suspend/resume-oriented solution for cases where the best possible delay is needed and the senders are type 1 [1] 🍓.

1.1. Specification Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [8] 📜.

2. Requirements 💜

The main design goal for an architecture handling real-time multimedia over low-bitrate links is to minimize end-to-end delay 🔥. To be more specific, the worst-case delay (after dropping possible outliers, which act like packet losses from an application's point of view) is what sets the playout points apps pick, and that's the delay the user actually feels 🫶.

Beyond that, every attempt should obviously be made to maximize the bandwidth actually available to media data, so overheads must be minimized ✨.

The solution should not place unnecessary burdens on the non-real-time flows. In particular, the usual MTU should still be available to these flows 🌈.

The most general approach would let any packet (real-time or not) be suspended for a more urgent real-time packet, with up to an infinite number of levels of nesting 🧚. But realistically, a real-time packet would rarely need to suspend another real-time packet unless that packet is at least about twice as long 🙈. The largest packet size you'd expect on a PPP link is the default MTU of 1500 bytes, and the smallest high-priority packets are likely to be around 22 bytes (compressed RTP/G.723.1 packets) 💖. Across that 1:72 range of packet sizes, the maximum requirement works out to about eight levels of suspension (including one level where long real-time packets suspend long non-real-time packets) 👑. On 28.8kbit/s modems, there seems to be a practical need for at least two levels of suspension (so audio suspends any longer packet including video, and video suspends other very long packets) 🎀.

On an architectural level, the fragmentation scheme has several more requirements 🔥:

a) The scheme must be predictable enough that admission control can make decisions based on its characteristics. As [1] argues, this will often only be the case when additional hints about the flow's characteristics are available (application hints) 🧠.

b) The scheme must be robust against errors, at least with the same level of error detection as PPP 🛡️.

c) The scheme must in general cooperate nicely with PPP. In particular, it should be as compatible with existing PPP standards as possible. On a link that (based on PPP negotiation) uses the scheme, it should always be possible to fall back to standard LCP (PPP Link Control Protocol [6, 7]) without ambiguity 🫶.

d) The scheme must work well with existing chips and router systems. (See [1] for a more extensive discussion of implementation models.) For synchronous links this means using HDLC framing, and with a lot of existing hardware it's also hard to switch off the HDLC per-frame CRC 🔧. For asynchronous links there's much more freedom in design, but on the other hand, treating them very differently from synchronous links would lose a number of desirable PPP properties 🌸.

e) The scheme must be future proof. In particular, the emergence of V.80 based modems may significantly change the way PPP is used with modems 🔮.

This document doesn't address additional requirements that might matter with Frame Relay, but the principles here seem to apply without much trouble to "PPP in Frame Relay" [3] 🦋.

Sending only part of a packet so higher-priority traffic can cut in, then picking up the rest later, is a kind of fragmentation 🧩. The existing PPP Multilink Protocol (MP, [2]) already gives you sequence numbers and begin/end bits, so packets can be split into fragments (Figure 1) 🌈.

Figure 1: Multilink Short Sequence Number Fragment Format [2]

          +---------------+---------------+
PPP Header:  | Address 0xff  | Control 0x03  |
          +---------------+---------------+
          | PID(H)  0x00  | PID(L)  0x3d  |
          +-+-+-+-+-------+---------------+
MP Header:   |B|E|0|0|    sequence number    |
          +-+-+-+-+-------+---------------+
          |    fragment data              |
          |               .               |
          |               .               |
          |               .               |
          +---------------+---------------+
PPP FCS:     |              FCS              |
          +---------------+---------------+

(Heads up: the address, control, and most significant PID bytes are often negotiated to be compressed away 🙈.)

MP's sequence numbering only ever goes up (contiguous numbers are needed for all fragments of a packet), so it doesn't let you pause sending a packet's fragments to send another packet 😤. You can send packets that aren't wrapped in multilink headers in between, though, so MP supports two levels of priority 💅.

The multilink-as-is approach can be built with existing standards 🙌. Multilink is already widely deployed, and only the sending side needs to know it's being used to give priority to real-time packets 🎉.

Multilink-as-is isn't the complete solution, for a few reasons 🥲. First, because of the single monotonically increasing serial number, there's only one level of suspension: "big" packets sent via multilink can be suspended by "small" packets sent outside of multilink, and those small packets aren't fragmentable. That means the content of one packet can't be sent in parallel over multiple links. And if packets are sent in rounds over multiple links, the order they're processed at the receiver may differ from the order they were sent 🌀.

Another problem this spec doesn't solve is that the multi-link header is pretty big. As delay bounds get small (for queues-of-fragments type implementations), the overhead can become significant ⏱️.

(Part 1 of 3. More coming up next, bestie! 💖)

okay so the obvious way to get more than one level of suspension with PPP Multilink is to just run Multilink multiple times over one link 🤔 but the thing is, Multilink as it's defined has no way for more than one instance to be active 💀 lowkey tragic. BUT, good news bestie: a bunch of bits in the Multilink header are just sitting there unused! 🎀 That's two bits in the short sequence number format (you can see them in Figure 1) and six bits in the long sequence number format.

This document defines (some of the) previously unused bits as a class number 🦋:

    Figure 2: Short Sequence Number Fragment Format With Classes

             +---------------+---------------+
PPP Header:  | Address 0xff  | Control 0x03  |
             +---------------+---------------+
             | PID(H)  0x00  | PID(L)  0x3d  |
             +-+-+-+-+-------+---------------+
MP Header:   |B|E|cls|    sequence number    |
             +-+-+-+-+-------+---------------+
             |    fragment data              |
             |               .               |
             |               .               |
             |               .               |
             +---------------+---------------+
PPP FCS:     |              FCS              |
             +---------------+---------------+

Each class runs its own separate copy of the mechanism defined in [2], which means it uses its own sequence number space and its own reassembly buffer 🧚

Same deal for the long sequence number format:

    Figure 3:  Long Sequence Number Fragment Format With Classes

             +---------------+---------------+
PPP Header:  | Address 0xff  | Control 0x03  |
             +---------------+---------------+
             | PID(H)  0x00  | PID(L)  0x3d  |
             +-+-+-+-+-+-+-+-+---------------+
MP Header:   |B|E| class |0|0|sequence number|
             +-+-+-+-+-+-+-+-+---------------+
             |      sequence number (L)      |
             +---------------+---------------+
             |        fragment data          |
             |               .               |
             |               .               |
             |               .               |
             +---------------+---------------+
PPP FCS:     |              FCS              |
             +---------------+---------------+

Put that together with the ability to send packets without a multilink header, and you get four levels of suspension with 12-bit headers (probably more than enough for lots of real-world stuff 🌸) and sixteen levels with 24-bit headers. Only four of the six free bits get used in that case, though. Based on the reasoning above, sixteen levels should generally be more than sufficient 💅

5. Prefix elision: Compressing common header bytes 🍓

For some applications, every packet in a certain class has the same protocol identifier (or even more than one common prefix byte) 👀 When that happens, you can do this optimization: the class number gets associated with a prefix of bytes. Those bytes get stripped off each packet before transmission, and then they get implicitly prepended back onto the reassembled packet after reception. Galaxy brain, right? 🧠✨

Here's a sneaky detail. If only some of the packets at a given priority level have the common prefix, you can still use this trick by allocating two class numbers and only associating one of them with the prefix. (This is also why four of the unused bits in the long sequence number format went to the class number, instead of the three that generally should suffice 🙈)

Prefix elision is NOT a replacement for header compression or data compression, periodt 💅 What it does is let implementations compress away prefixes that header or data compression methods often can't reach.

6. Negotiable options 🎀

The following PPP LCP options are already defined by MP:

  • Multilink Maximum Received Reconstructed Unit
  • Multilink Short Sequence Number Header Format
  • Endpoint Discriminator

This document defines two brand new LCP options:

  • Multilink Header Format
  • Prefix Elision

Here's the summary of the Multilink Header Format Option. The fields go across the wire from left to right.

                             Figure 4:

 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 = 27   |  Length = 4   |     Code      | # Susp Clses  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This LCP option tells the peer that the implementation wants to receive fragments in the format given by the code number, and it also says the maximum number of suspendable classes (more on that below) 📣

When this option is negotiated, the accepting implementation MUST either transmit all subsequent multilink packets on all links of the bundle with the multilink header format given, OR Configure-Nak or Configure-Reject the option. (Quick side note: an implementation MAY continue to send packets outside of multilink in any case 💜) If this option is offered on a link that's meant to join an existing bundle, a system MUST offer the same multilink header format option value that was previously negotiated for the bundle, or none if none was negotiated previously.

The values defined in this document for this option are:

  • Code = 2: long sequence number fragment format with classes
  • Code = 6: short sequence number fragment format with classes

The Multilink Header Format option MUST NOT occur more than once in a Configure-Request or Configure-Ack. And if it's present, the Short Sequence Number Header Format option ([2]) MUST NOT also be present. Okay, this is important 👑 If no instance of this option or the Short Sequence Number Header Format option is present, but an MRRU option [2] is present, then by default, long sequence number multilink headers with class 0 only get used. That's equivalent to code equals 2 and number of suspendable classes equals 1. An instance of the Short Sequence Number Header Format Option is equivalent to an instance of this option with code equals 6 and number of suspendable classes equal to 1.

The number of suspendable classes bounds which class numbers are allowed: only class numbers numerically lower than this limit can be used for suspendable classes. Implementations MAY want to negotiate a number smaller than what the packet format makes possible, if they want to limit their reassembly buffer space requirements 🧃 Implementations SHOULD at least support the value 4 for the short sequence number fragment format, and the value 8 for the long sequence number fragment format, unless they're configured differently. Bit combinations that would indicate class numbers outside the negotiated range MAY be used for other semantics, if those get negotiated by other means outside the scope of this document (e.g., [6]) 🌈

6.2. Prefix elision option 💖

This LCP option tells the peer that, in each of the given classes, the implementation only expects to receive packets with a certain prefix. That prefix does NOT get sent as part of the information in the fragment(s) of that class. By default, the common prefix is empty for all classes. When this option is negotiated, the accepting implementation MUST either transmit all subsequent multilink packets of each of the given classes with the given prefix removed from the start of the packet, OR Configure-Nak or Configure-Reject the option. If none of the formats with classes has been negotiated, class number 0 may be used to indicate a common prefix for all packets sent within multilink fragments.

Apart from the type and length octets that every LCP option has, this option holds a sequence of zero or more sequences. Each one is a single-octet class number, a single-octet length of the prefix for that class, and then the octets of that prefix:

                             Figure 5:
 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 = 26   | Option Length |    Class      | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Prefix...                                   |    Class      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |   Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Prefix Elision option MUST NOT occur more than once in a Configure-Request or Configure-Nak. If this option is offered on a link that's meant to join an existing multilink bundle, a system MUST offer the same prefix elision option value that was previously negotiated for the bundle, or none if none was negotiated previously.

IMPLEMENTATION NOTE: as with most PPP options that tell the sender about the receiver's capabilities, this option is an indication from the receiver to the sender about the packets concerned. Usually only the senders have enough control over their usage of classes to supply useful values for this option. A receiver that's willing to accept prefix-elided packets SHOULD request this option with empty content, and then the sender can use Configure-Nak to propose the class-to-prefix mapping it wants. 🙌

7. Security Considerations 🔐

Operation of this protocol is believed to be no more and no less secure than operation of the PPP multilink protocol [2]. So, no extra drama, no less drama 🙈

8. References 📚

  • [1] Bormann, C., "Providing Integrated Services over Low-bitrate Links", RFC 2689, September 1999.
  • [2] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
  • [3] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.
  • [4] Andrades, R. and F. Burg, "QOSPPP Framing Extensions to PPP", Work in Progress.
  • [5] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999.
  • [6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
  • [7] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
  • [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

9. Author's Address 🌸

Carsten Bormann
Universitaet Bremen FB3 TZI
Postfach 330440
D-28334 Bremen, GERMANY

Phone: +49.421.218-7024
Fax:   +49.421.218-7000
EMail: cabo@tzi.org

10. Acknowledgements 🫶

David Oran suggested using PPP Multilink for real-time framing, and he reminded the author of his earlier attempts to make Multilink more useful for this purpose 👑 The participants in a lunch BOF at the 1996 Montreal IETF gave useful input on the design tradeoffs in various environments 🥪 And the members of the ISSLL subgroup on low bitrate links (ISSLOW) helped cut down the big pile of options that the early versions of this specification had. Iconic teamwork ✨

Copyright (C) The Internet Society (1999). All Rights Reserved. 🌸

Okay, bestie, the legal bit 💅 You're allowed to copy this document and share it with others, and you can make derivative works that comment on it, explain it, or help people implement it. Those can be published, copied, and distributed too, in whole or in part, with no restrictions of any kind. The one condition is that the copyright notice above and this paragraph have to stay on all of those copies and derivative works 🫶

BUT the document itself can't be modified in any way ✋ That covers removing the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions. The first is developing Internet standards, and then the copyright procedures in the Internet Standards process have to be followed. The second is translating it into languages other than English. Those are the only times changes are allowed 🌈

These permissions are perpetual, which means the Internet Society or its successors or assigns will never take them back 💜

Now the big disclaimer 😭 This document and the information in it are provided on an "AS IS" basis. THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Translation: they're not promising it's perfect, so read it with your own brain too 🧚

Acknowledgement ⭐

Funding for the RFC Editor function is currently provided by the Internet Society. 👑

📦 where this page comes from