PPP in a Real-time Oriented HDLC-like Framing
Extracted elements (22)
A 1500-byte packet on a 28.8 kbit/s modem link occupies the link for about 400 ms, causing worst-case round-trip delays on the order of a second, which is unacceptable for real-time conversation. A suspend/resume encapsulation allows higher-priority real-time packets to preempt long packets mid-transmission.
Class 7 with R=0 uses the sequence field to provide eight additional non-suspendable classes (7-14), significantly increasing the applicability of prefix elision by providing more classes with potentially different elided prefixes at minimal additional complexity.
FSE value 0xDE was chosen because it is a relatively unlikely byte in typical data streams, does not trigger octet stuffing, and triggers bit stuffing for only 1/8 of possible preceding bytes. The transparency scheme limits worst-case expansion to about 25% and is designed so a stream cannot simultaneously trigger worst-case expansion by both octet/bit stuffing and FSE processing.
The existing PPP Multilink 'end' bit is located in the fragment header (the wrong place for suspend/resume): a suspendable packet must be sent with E=0 and then followed by an empty fragment to close it, incurring minimum overhead of twice the multilink header size (six bytes) plus three bytes of PPP framing per suspension. This overhead motivated a new compact header design.
The real-time frame format retains the overall HDLC-based frame structure so that existing synchronous HDLC chips and async-to-sync converters can operate on the link without modification, prioritizing compatibility over the additional design alternatives that would be available for async-only operation.
Async-to-sync converters monitoring LCP negotiations may interpret the negotiated MRU as the maximum HDLC frame size. Implementations should negotiate an MRU large enough to cover the worst-case 25% FSE-expansion plus suspended-fragment overhead, or actively limit HDLC frame size by injecting FSE-terminated empty final fragments when approaching the MRU.
The suspend/resume FSE format is an alternative to Address-and-Control-Field-Compression (ACFC, LCP option 8) and is mutually exclusive with it. Frames starting with 0xFF are treated as standard PPP-in-HDLC frames per RFC 1661/1662, ensuring LCP renegotiation attempts are never misinterpreted as real-time frames.
An implementation MUST NOT request both LCP Address-and-Control-Field-Compression (ACFC) and Multilink Header Format code values 11 or 15, as these framing modes are mutually exclusive.
For suspendable classes (class field 0-6), one of the two compact fragment formats (basic or extended) SHOULD be used consistently within each class to avoid sequence number discontinuities that force the receiver to resynchronize.
If the class field is set to 7, the R bit MUST never be set to 1. This reserves the byte value 0xFF to avoid ambiguity with LCP frame detection; class-7 frames are by design non-suspendable.
If the extended compact fragment format has been negotiated, receivers MAY keep 10-bit sequence numbers for all classes to facilitate senders switching between basic and extended formats within a class without causing discontinuities.
Links where incorrect fragment reassembly raises security concerns SHOULD use the extended sequence number range (10-bit) for multi-fragment packets to reduce the probability of cross-packet reassembly errors.
Class numbers 0-6 map directly from the 3-bit class field and support suspend/resume. When class field equals 7, the 3-bit sequence field distinguishes class numbers 7-14 (non-suspendable, for high-priority flows such as compressed voice). In the extended format, class field 7 can address classes 7-1030 using the 10-bit sequence field.
Data transparency is achieved via FSE/0xnF sequences: an FSE byte followed by a byte whose lower nibble is 0xF (values 0x8F-0xFF, with R=1 always) encodes between one and four literal FSE bytes using the upper 4 bits as a bitmask pattern. Zero bits in the pattern indicate positions where actual data bytes are copied.
The real-time frame format is an HDLC-like frame (flags, FCS, no address/control fields) whose data portion contains FSE-delimited compact fragments. A normal frame ending implicitly sets E=1 on the final fragment; an FSE byte sets E=0 (suspended). This allows type-2 receivers to trigger a receive interrupt immediately on complete packets.
Two new code points for the Multilink Header Format LCP option (Type=27, Length=4): Code 11 negotiates basic and extended compact real-time fragment format with classes in FSE-encoded HDLC frames; Code 15 negotiates basic compact real-time fragment format only in FSE-encoded HDLC frames.
When combining octet-stuffing and FSE processing, FSE processing must wait until two bytes of HDLC frame content are available and a third byte has been received, to ensure the candidate bytes are not the final FCS bytes (which are not subject to FSE processing). This requires a two-byte lookahead above the HDLC layer.
Operating with a small (3-bit) sequence number range increases the likelihood that fragments from different packets could be incorrectly reassembled into one packet. While most such packets will be discarded by higher-layer checksum failures, there is increased risk that packet contents destined for one host could be delivered to another host.
Compact fragment header is 1 byte: bit 7 = R (resume flag, inverted B-bit; R=1 means resuming prior fragments), bits 6-4 = 3-bit sequence number, bits 3-1 = 3-bit class field, bit 0 = always 1 (for HDLC chip compatibility). Data follows immediately.
Extended compact fragment header is 2 bytes: byte 1 has R(1 bit), seq LSB(3 bits), class(3 bits), bit0=0; byte 2 has seq MSB(7 bits), bit0=1. The 10-bit sequence number (3 LSBs from byte 1, 7 MSBs from byte 2) supports multi-link operation.
Fragment Suspend Escape (FSE) byte value is 0xDE. Within the HDLC frame data part, each FSE marks the end of a suspended fragment (E=0). A final FSE immediately before the FCS bytes indicates the last fragment is suspended with no final fragment in the frame.
Multilink Header Format LCP option: 4 bytes total — Type=27 (1 byte), Length=4 (1 byte), Code (1 byte, value 11 or 15 per this spec), Number of Suspendable Classes (1 byte). The class limit applies only to suspendable class numbers (0-6); non-suspendable classes (7+) are exempt.