PPP Multiplexing
Extracted elements (23)
Implementers are advised that limiting the maximum multiplexed frame size to well below MRU reduces multiplexing latency and packet-error impact, representing a deliberate tradeoff between throughput efficiency and delay.
PPP Multiplexing differs from the concatenated framing option (RFC 1570) by supporting variable-length subframes rather than restricting all frames to fixed length, making it more efficient for heterogeneous traffic.
PPP Multiplexing is motivated by L2TP tunneling scenarios where per-frame PPP overhead (HDLC flag, Address/Control fields, Protocol ID, CRC) is amplified; multiplexing amortizes that overhead across several small packets carried in one frame.
The default PID negotiation in PPPMuxCP allows the transmitter to omit the protocol field from the first subframe (PFF=0) when it matches the default, saving one or two bytes per multiplexed frame.
In PPP Multilink (MP) bundles, PPPMuxCP is negotiated at the bundle level, not per link, because LCP is negotiated per link. PPP multiplexing therefore occurs before multilink encapsulation in the transmit path.
PPP multiplexing must be performed below (after) any bundle-level CCP/ECP and above (before) MP and any per-link CCP/ECP. To achieve the transmit path CCP→PPPMux→ECP, bundle-level CCP (0x80FD) and per-link ECP (0x8055) are negotiated alongside PPPMux.
A transmitter may not send a multiplexed frame unless the peer has negotiated PPPMuxCP to offer reception of multiplexed frames. Support is negotiated independently in each direction; successful negotiation does not obligate a peer to transmit multiplexed frames.
An implementation that cannot perform PPPMux above CCP or ECP MUST issue Protocol-Reject for the per-link forms of CCP (0x80FD per-link variant) and ECP (0x8055) if PPPMux has been negotiated.
Frames SHOULD NOT be re-ordered by either transmitter or receiver, regardless of whether they arrive as part of a multiplexed frame or individually.
If LCP is renegotiated, PPP Multiplexing MUST be disabled until PPPMuxCP is renegotiated. LCP Configure Request, ACK, NAK, and Reject frames and PPP Multiplexed frames themselves MUST NOT appear as subframes in the Information Field.
It is illegal to put a multiplexed frame within a multiplexed frame — recursive PPP multiplexing is prohibited.
LCP frames MUST NOT be sent in Multiplexed frames.
On a multilink (MP) link, an MP header MUST be outside of (i.e., wrap) a PPPmux header if both are present. Multilink frames must not be sent in Multiplexed frames.
The receiver MUST support Protocol-Field-Compression (PFC) of one or two bytes in each PPP subframe's Protocol Field.
The transmitter SHOULD compress PPP Protocol IDs whose upper byte is zero (Protocol IDs 0x21 through 0xFD) in the per-subframe protocol field. This compression is independent of LCP-negotiated PFC for the outer multiplexed frame header.
MAX_SF_LEN is a user-configurable parameter representing the maximum subframe size eligible for multiplexing. Its value MUST be less than or equal to the minimum of (MRU minus 2) and 16,383 bytes.
PPP Multiplexing sends multiple PPP encapsulated packets (subframes) in a single PPP frame with Protocol ID 0x0059, using per-subframe delimiters to allow demultiplexing. The PPP Mux Control Protocol (PPPMuxCP) uses Protocol ID 0x8059 for negotiation.
PPP Multiplexing does not impose additional security considerations beyond those already applicable to PPP and header-compression schemes over PPP.
The receiver maintains Last_rcvd_PID (initialized to PPPMuxCP default PID). For each subframe: if PFF=0, Last_rcvd_PID is prepended before passing the subframe to PPP logic; if PFF=1, Last_rcvd_PID is updated to the subframe's protocol value. Processing ends when the frame is exhausted or a length field exceeds remaining data, in which case the last subframe is dropped.
The transmitter maintains Last_PID (initialized to PPPMuxCP default PID) and a configurable MAX_SF_LEN. For each candidate subframe, if its protocol equals Last_PID, PFF is set to 0 and the protocol field omitted; otherwise PFF=1, the protocol field is included, and Last_PID is updated. Multiplexing stops when: the next subframe exceeds MAX_SF_LEN, the accumulated frame would exceed MRU, or no more subframes are pending.
Each subframe is preceded by a length field of 1 or 2 bytes. The most significant bit is the Protocol Field Flag (PFF), the next bit is the Length Extension (LXT), and the remaining 6 or 14 bits are the subframe length (LEN). LXT=0 means 1-byte length (6-bit LEN, max 63 bytes); LXT=1 means 2-byte length (14-bit LEN, max 16,383 bytes).
The PPPMuxCP Default PID option has Type=1, Length=4, and a 2-byte Default PID field. This is the only option negotiated by PPPMuxCP.
The Protocol Field Flag (PFF) is the MSB of the length field byte. PFF=1 indicates a PPP Protocol ID field follows the length field for this subframe; PFF=0 means the protocol is inherited from the most recent subframe with PFF=1, or from the PPPMuxCP-negotiated default PID.