RFC 3153

PPP Multiplexing

📅 published August 2001, from ietf

PPP Multiplexing 🦋

Network Working Group · RFC 3153 🎀 Authors: R. Pazhyannur (Motorola), I. Ali (Motorola), C. Fox (Cisco Systems) 💖 Category: Standards Track ✨ Date: August 2001 📅 Obsoletes / Updates: the header doesn't list any RFCs being obsoleted or updated, so this one stands on its own 🌸

Status of this Memo 📜

Okay so this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions to make it better 🫶 If you want to know where it stands in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1). And the good news is that distribution of this memo is unlimited, so share away 💅

Copyright (C) The Internet Society (2001). All Rights Reserved. 🔒

Abstract 🍓

This doc is all about a way to shrink the PPP (Point-to-Point Protocol) framing overhead that gets stuck on small packets when they travel over slow links 🐢💨

1. Description ✨

Okay, so the main event is PPP Multiplexing, and the vibe is simple: it sends several PPP encapsulated packets inside one single PPP frame 🧚 Because you're sharing one frame instead of paying the framing tax for each packet, the PPP overhead per packet goes down. It's giving efficiency 💅

Here's the tea on the overhead. PPP encapsulation, like PPP in HDLC framing, adds a bunch of bytes: an HDLC flag (at least one, to separate adjacent packets), the Address (0xFF) and Control (0x03) field bytes, a two byte PPP Protocol ID, and the two byte CRC field 😭 Even if you negotiate the Address and Control Fields off and compress the PPP Protocol ID, each PPP encapsulated frame still carries four bytes of overhead. And when PPP frames get tunneled, like in L2TP [1], that L2TP overhead per PPP frame adds up to something significant 🙈

The key idea is to glue multiple PPP encapsulated frames into a single PPP multiplexed frame by putting a delimiter in front of each frame. You'll find the delimiters explained in Subsection 1.1. The demultiplexor uses those delimiters to split the PPP frames back apart inside the multiplexed frame. Each PPP encapsulated frame inside the multiplexed frame gets called a PPP subframe 🌈

During the NCP negotiation phase of PPP, a receiver can offer to receive multiplexed frames using the PPP Mux Control Protocol (PPPMuxCP), which Section 2 covers 🎀 Once PPPMuxCP has been negotiated, the transmitter gets to pick which PPP frames to multiplex. And here's a big one: frames should not be re-ordered by either the transmitter or the receiver, whether they show up inside a PPP multiplexed frame or all by themselves 👑

This scheme is pretty similar to the concatenated framing option [2]. The differences? PPP multiplexing is more efficient, and it lets you concatenate variable sized frames. Concatenated framing only lets you do fixed length frames, so it's a little more restrictive 💖

Like with any concatenation scheme, the implementer has to weigh the tradeoff. Multiplexing and demultiplexing add delay, but the packet overhead goes down as the multiplexed frame gets longer. So you're balancing latency against efficiency ⭐

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 [7] 🫶

1.1. Payload Format 🧁

Here's the full layout of a complete PPP frame with multiple subframes for PPP in HDLC-like framing [3], shown in Figure 1 💅 One thing to keep in mind: no matter what order the individual bits go out in (LSB first or MSB first), the PFF bit always ends up as the MSB of a byte that holds both the PFF and the subframe length field 🔥

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       +P|L|     +       +     +   +P|L|     +       +     +     |
   |  PPP/ +F|X|Len1 +  PPP  +     +   +F|X|LenN +  PPP  +     +     |
   |  HDLC +F|T|     + Prot. +Info1+ ~ +F|T|     + Prot. +InfoN+ CRC |
   | Header+ | |     + Field1+     +   + | |     +FieldN +     +     |
   | (2-5) +  (1-2 ) + (0-2) +     +   +  (1-2)  + (0-2) +     + (2) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1. Multiplexing subframes in a PPP frame. 🖼️

PPP Header 🎀

The PPP header carries the PPP Protocol Field for a PPP Multiplexed Frame, which is 0x0059 💜 The PPP header compression options, ACFC and PFC, may be negotiated during LCP, and that could change how this header looks ✨

Length Field 📏

The length field is made up of three subfields 🧚

  1. Protocol Field Flag (PFF): The PFF refers to the most significant bit of the first byte of each subframe. It's a one bit field that tells you whether the PPP Protocol ID of the subframe follows the subframe length field. For the first subframe, the PFF bit could be set to zero if the PPP protocol ID of the first subframe equals the default PID value negotiated in PPPMuxCP. PFF = 1 means the protocol field is present (and follows the length field) for this subframe. PFF = 0 means the protocol field is absent for this subframe. If PFF = 0, then the PPP Protocol ID is the same as that of the preceding subframe with PFF = 1, or it equals the default PID value of the PPPMuxCP Option for the first subframe. The transmitter isn't obligated to remove the PPP Protocol ID for any subframe 🙌
  2. Length Extension (LXT): This one bit field tells you whether the length field is one byte or two bytes long. If the LXT bit is set, the length field is two bytes long (a PFF bit, a length extension bit, and 14 bits of sub-frame length). If the LXT bit is cleared, the length field is one byte long (a PFF bit, a length extension bit, and 6 bits of sub-frame length) 🦋
  3. Sub-frame Length (LEN): This is the length of the subframe in bytes, not counting the length field. It does include the PPP Protocol ID if it's present (that is, if PFF = 1). If the subframe is less than 64 bytes (less than or equal to 63 bytes), LXT is set to zero and the last six bits of the length field are the subframe length. If the subframe is greater than 63 bytes, LXT is set to one and the last 14 bits of the length field are the length of the subframe. The maximum length of a subframe is 16,383 bytes. PPP packets larger than 16,383 bytes will need to be sent in their own PPP frame. A transmitter is not required to multiplex all frames smaller than 16,383 bytes. It may choose to only multiplex frames smaller than a configurable size into a PPP multiplexed frame 🌸

Protocol Field 🍓

This field holds the Protocol Field value for the subframe. It's optional. If PFF = 1 for a subframe, the protocol field is present in the subframe. Otherwise, it's inferred at the receiver 🔍

The receiver MUST support Protocol-Field-Compression (PFC) one or two bytes long. The transmitter SHOULD compress PPP Protocol IDs in this field that have an upper byte of zero (that is, Protocol IDs from 0x21 thru 0xFD). This Protocol Field Compression in each PPP subframe has nothing to do with the PFC negotiation during LCP, which affects the length of PPP Multiplexed Frame Protocol ID. Keep those two straight, bestie 💅

Information Field ℹ️

This field holds the actual packet being encapsulated. Any frame may be included here, except for LCP Configure Request, ACK, NAK and Reject frames and PPP Multiplexed frames 🚫 And if LCP gets renegotiated, PPP Multiplexing MUST be disabled until the PPP Mux Control Protocol is negotiated again 🙈

1.2 Transmitter procedure ✨

Here's a simple implementation of the transmitter 🧚 While a multiplexed PPP frame is being transmitted, the transmitter keeps a state variable called Last_PID, which holds the most recent protocol field value in a subframe with PFF=1. At the start of the multiplexing process, Last_PID is set equal to the default PID value negotiated in PPPMuxCP. There's also a user configurable parameter, the maximum subframe length (MAX_SF_LEN), which decides the maximum size of a PPP frame that can be multiplexed. The value of MAX_SF_LEN should be less or equal to the minimum of MRU-2 (maximum size of length field) and 16,383 (14 bits) 📏

After transmitting a PPP frame, multiplexed or not, on the channel, the PPP multiplexing logic checks the buffers that hold the PPP frames waiting to go out 👀 If there are multiple frames, the logic checks whether the length of the first frame in the buffer is less than or equal to MAX_SF_LEN bytes. If it is, the transmitter starts compiling a multiplexed PPP frame with the protocol field value for PPP Multiplexed Frame (0x59). For each subframe, the decision to prepend the protocol field is made by comparing the subframe's protocol field value to Last_PID. If they match, PFF is set to 0 and the protocol field is deleted. If they don't, PFF is set to 1, the protocol field is included after PFC in the subframe, and Last_PID is updated to the protocol field value of the current subframe 💖

The concatenation process stops under any of these conditions: (i) the length of the next subframe is greater than MAX_SF_LEN bytes, (ii) adding the new subframe would make the entire PPP frame exceed the maximum receive unit (MRU) parameter negotiated during LCP [4], or (iii) there are no more subframes to concatenate 🛑

Implementers can also choose to use timers. If they do, a timeout, in addition to the conditions above, becomes another stopping criterion for the multiplexing process ⏰ It may also be desirable to keep the maximum size of a multiplexed packet considerably smaller than the MRU, for reasons of multiplexing latency and packet error considerations 🫧

1.3 Receiver procedure 🌈

If a multiplexed frame comes in, meaning a frame whose Protocol field value equals PPP Multiplexed Frame (0x0059), it gets demultiplexed in order using the input demultiplexing logic below 📦 Just like the transmitter, the receiver has a state variable called Last_rcvd_PID, which is the value of the protocol field in the most recently demultiplexed subframe with PFF=1. Last_rcvd_PID is initialized to the default PID value negotiated by PPPMuxCP. If PFF=0 for a subframe, Last_rcvd_PID gets appended to the beginning of the subframe before the subframe, as determined by its length field, is handed to the PPP logic. If PFF=1 for a subframe, Last_rcvd_PID is set to that value, and the subframe, as determined by its length field, is passed to the PPP logic. The remainder of the frame goes back to the demultiplexor. Each succeeding subframe is processed the same way 🔁

This processing is complete when the remainder of the frame is empty, or when the size field of a subframe exceeds the amount of data remaining in the packet. In that second case, there's an error either in the length field of the last subframe or in the length field of one of the previous subframes. Either way, the last subframe must be dropped by the demultiplexing logic 🗑️

It is illegal to put a multiplexed frame within a multiplexed frame 🚫💅

2. PPP Network Control Protocol for PPP Multiplexing (PPPMuxCP) 💖

Okay so, a receiver shows it can handle multiplexed frames by negotiating an NCP for PPP multiplexing, called PPPMuxCP 🦋. PPPMuxCP frames use the protocol field value 0x8059. It's giving the same energy as other NCPs like IPCP [6]. A transmitter may not send a multiplexed frame unless the peer has offered to receive multiplexed frames. Support for receiving multiplexed frames is negotiated in each direction independently, so you can say yes one way and not the other 🙅‍♀️. Successfully negotiating PPPMuxCP does not obligate a peer to transmit multiplexed frames, so nobody gets forced into anything 🌸.

As part of the PPPMuxCP negotiation, a 'default PID' option is always negotiated ✨. This lets the transmitter send the first subframe of a PPP multiplexed frame without a PID (PFF=0), which saves one or two bytes. Lowkey genius 🧠. Negotiating the default PID does not require the transmitter to send the first subframe with PFF=0, even if doing that would make the transmission more efficient. And as always, the option (and so the default PID) is negotiated by the receiver. That means the receiver interprets a received PPPmux packet using the default PID it offered 💅.

LCP frames MUST NOT be sent in Multiplexed frames 🚫. The only option in PPPMuxCP is negotiating the Default PID, and it looks like this:

    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 = 1    |   Length = 4  |        Default PID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2. Default PID option for PPPMuxCP 🎀

PPP multiplexed frame option is negotiated by an NCP. LCP is negotiated over each member link of a multilink bundle and not on the bundle itself [5]. So with MP, PPPmux can't be negotiated for individual links, only for the whole bundle 🧺.

That's why, on the transmitter side, PPP multiplexing always happens before multilink PPP encapsulation 🔄. On a link, an MP header (if present) MUST be outside of a PPPmux header (if present). Multilink frames must not be sent in Multiplexed frames 🙈.

4. Interaction with CCP and ECP 🌈

PPP multiplexing must be performed below (after) any bundle-level CCP and/or ECP, and above (before) MP and any per-link CCP and/or ECP. So to negotiate the hypothetical transmit path sequence CCP -> PPPMux -> ECP, the bundle-level version of CCP (80fd) and the per-link version of ECP (8055) get negotiated along with the PPPMux Option 🧩.

An implementation that cannot perform PPPMux above CCP or ECP MUST issue Protocol-Reject for the per-link forms of CCP and ECP if PPPMux has been negotiated 🙅‍♀️. No cap, the ordering matters.

5. Security Considerations 🔐

This document does not impose additional security considerations beyond those that apply to PPP and header-compression schemes over PPP. So the security stuff is the same as what you already have with PPP and header compression 🫶.

6. Acknowledgements 💜

The authors would like to thank contributors on the PPPext mailing list, especially James Carlson, for valuable inputs to this document. Iconic behaviour from them 👑.

7. References 📚

  • [1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
  • [2] Simpson, W., Ed., "PPP LCP extensions", RFC 1570, January, 1994.
  • [3] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
  • [4] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
  • [5] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
  • [6] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
  • [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

8. Author's Addresses 🦋

Rajesh Pazhyannur
Motorola, Network Solutions Sector
1501, W. Shure Drive
Arlington Heights, IL 60004

Phone: (847) 632-4524
EMail: pazhynnr@cig.mot.com


Irfan Ali
Motorola, Network Solutions Sector
1501, W. Shure Drive
Arlington Heights, IL 60004

Phone: (847) 632-3281
EMail: fia225@email.mot.com


Craig Fox
Cisco Systems
170 W. Tasman Street
San Jose, CA 95134

Phone: (408) 526-6296
EMail: fox@cisco.com

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and 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.

Acknowledgement 🌷

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

📦 where this page comes from