PPP in HDLC Framing
obsoleted by
- rfc-1662 — PPP in HDLC-like Framing
Extracted elements (28)
NRZI encoding is recommended as an alternative to NRZ for bit-synchronous links because of its relative immunity to signal inversion errors and potential to avoid DSU/CSU costs. However, NRZI eliminates the (1+x) factor of the 16-bit FCS, reducing undetected error probability from 1-in-2^16 to 1-in-2^15; therefore the 32-bit FCS is recommended when NRZI is used.
PPP uses the HDLC Frame Check Sequence for error detection because it is commonly available in hardware implementations. Some protocols either provide error detection only conditionally or not at all; the FCS design ensures that a specific 'good FCS' residue (0xf0b8) results when the receiver's FCS computation passes over the appended complemented FCS, allowing a single-pass receive check.
The asynchronous ACCM mechanism escapes all ASCII control characters (octets less than 0x20, excluding DEL) to allow transparent communication through all known data communications equipment that may intercept or inject control characters such as XON/XOFF. The sending ACCM may be extended to 256 bits to cover additional octets, though this does not address 7-bit links.
The physical layer MAY be decoupled from the data link layer, hiding transient physical transport details. This enables mobility in cellular radio networks where an implementation may treat an entire zone as a single link across multiple cell frequencies, but the link SHOULD re-establish its configuration when switched to a different administration.
Synchronous-to-asynchronous converters (sometimes built into modems) may be present on point-to-point links, creating a hybrid where one end is bit-synchronous and the other is asynchronous. The converter is responsible for all ACCM mapping; bit-synchronous PPP must still acknowledge the ACCM Configuration Option to enable this.
Asynchronous links use 8-bit encoding: one start bit, eight bits of data, and one stop bit. There is no provision for seven-bit asynchronous links.
Bit-synchronous PPP implementations MUST always respond to the Async-Control-Character-Map Configuration Option with an LCP Configure-Ack to enable interoperability with synchronous-to-asynchronous converters, even though acceptance does not imply the bit-synchronous implementation will perform octet mapping itself.
For asynchronous links, inter-octet and inter-frame time fill MUST be accomplished by transmitting continuous '1' bits (mark-hold state). Transmitters SHOULD send an opening Flag Sequence whenever 'appreciable time' (suggested maximum ~1 second) has elapsed after the prior closing Flag Sequence.
For bit-synchronous links, the Flag Sequence SHOULD be transmitted during inter-frame time fill. Mark idle SHOULD NOT be used, but when required (e.g., circuit-switched accounting), the implementation MUST ensure at least 15 consecutive '1' bits between Flags during idle and always generate a Flag Sequence at the start of a frame after an idle period.
For octet-synchronous links, the Flag Sequence MUST be transmitted during inter-frame time fill. There is no provision for inter-octet time fill.
Implementations SHOULD signal the Down event to the link layer whenever 'significant time' has elapsed since the physical link was disconnected, to avoid security lapses from over-reliance on the integrity of switching systems.
PPP links MUST be full-duplex, but MAY be either dedicated or circuit-switched. The link may be asynchronous (start/stop), bit-synchronous, or octet-synchronous.
The All-Stations address (0xff) MUST always be recognized and received. Frames with unrecognized Address values SHOULD be silently discarded.
The 'shared zero mode' Flag Sequence '011111101111110' SHOULD NOT be used in bit-synchronous HDLC. When unavoidable, the implementation MUST ensure the first detected Flag Sequence (end of frame) is promptly communicated to the link layer.
When Address or Control field values other than 0xff/0x03 are in use, Address-and-Control-Field-Compression MUST NOT be negotiated.
When physical layer control signals (RTS, CTS, DCD, DTR) are not available, the implementation MUST signal the Up event to LCP upon initialization and SHOULD NOT signal the Down event. When signals are available, they SHOULD be used to signal Up and Down events.
Address-and-Control-Field-Compression (negotiated via LCP) omits the 0xff Address and 0x03 Control fields on transmission. On reception, if the first two octets are 0xff and 0x03 they are treated as Address/Control; otherwise the fields are assumed compressed. The Protocol field value 0x00ff is reserved to avoid ambiguity.
Asynchronous HDLC uses octet stuffing for transparency. The Control Escape octet is 0x7d. Each end maintains sending and receiving Async-Control-Character-Maps (ACCMs); the receiving ACCM is 32 bits and the sending ACCM may be up to 256 bits. The default for both is 0xffffffff.
Bit-synchronous HDLC uses bit stuffing for transparency: the transmitter inserts a '0' bit after every five consecutive '1' bits (including the last 5 bits of the FCS). The receiver discards any '0' bit that directly follows five contiguous '1' bits. The default sending and receiving ACCM is 0 (no octet stuffing).
Octet-synchronous HDLC (used with SONET and optionally ISDN B or H channels) uses the same octet stuffing procedure as asynchronous HDLC but escapes only the Flag Sequence (0x7e) and Control Escape (0x7d) octets. There is no bit stuffing despite the synchronous bit rate.
The Address field is a single octet containing 0xff (All-Stations address). PPP does not assign individual station addresses. Frames with unrecognized Address values SHOULD be silently discarded.
The Control field is a single octet containing 0x03, the Unnumbered Information (UI) command with the P/F bit set to zero. Frames with unrecognized Control field values SHOULD be silently discarded.
The Flag Sequence (binary 01111110, hexadecimal 0x7e) marks the beginning or end of a frame and serves as a frame separator. Only one Flag Sequence is required between two frames; two consecutive Flag Sequences constitute an empty frame that is ignored and not counted as an FCS error.
The Frame Check Sequence (FCS) field is normally 16 bits (two octets), transmitted most-significant coefficient first. It is calculated over the Address, Control, Protocol, Information, and Padding fields, excluding Flag Sequences, FCS itself, start/stop bits, and any transparency-inserted octets or bits.
When implementations disconnect the physical layer during inactivity without notifying the data link layer, security lapses can result: an insertion attack may go undetected, and an attacker spoofing the same calling identity may bypass link authentication. Implementations should signal the Down event after 'significant time' has elapsed to force link re-authentication.
In asynchronous HDLC octet stuffing, each Flag Sequence (0x7e), Control Escape (0x7d), and octet less than 0x20 flagged in the sending ACCM is replaced by a two-octet sequence: Control Escape (0x7d) followed by the original octet XOR'd with 0x20. Examples: 0x7e → 0x7d 0x5e; 0x7d → 0x7d 0x5d; 0x01 → 0x7d 0x21.
The 16-bit FCS uses CRC polynomial x^16 + x^12 + x^5 + 1 (0x8408 in reflected representation). The initial FCS value is 0xffff (PPPINITFCS16) and a correctly received frame yields a residual value of 0xf0b8 (PPPGOODFCS16). The FCS is appended as the complement, least-significant byte first.
The PPP HDLC frame consists, in order: Flag (0x7e, 1 octet), Address (0xff, 1 octet), Control (0x03, 1 octet), Protocol (16 bits), Information (variable), Padding (variable), FCS (16 bits), Flag (0x7e). Start/stop bits and transparency octets are not shown in this layout.