Standard reference: 

  • RFC 1662 - PPP framing
  • RFC 1661 - PPP encapsulation

PPP framing

The PPP encapsulation is used to disambiguate multiprotocol datagrams. This encapsulation requires framing to indicate beginning or end of the encapsulation over different link types:

  • bit oriented synchronous link.
  • characters-oriented (8-bit asynchronous and octet-synchronous) links.

PPP frame structure: fields

Basic Frame

The following does not include bits inserted for synchronization (such as start and stop bits for asynchronous links), nor any bits or octets inserted for transparency.

length field
1 octet Flag = 7E H
1 octet Address = FF H (All-Stations address)
1 octet Control = 03 H
1 or 2 octets Protocol
n octets Information
The Information field is zero or more octets.
p octets Padding
2 or 4 octets Frame Control Sequence
1 octet Flag = 7E H
x octets Inter-frame fill or Next Address

Flag Sequence

Each frame begins and ends with a Flag Sequence, which is the binary sequence 01111110 (hexadecimal 0x7e). All implementations continuously check for this flag, which is used for frame synchronization.

Only one Flag Sequence is required between two frames. Two consecutive Flag Sequences constitute an empty frame, which is silently discarded, and not counted as a FCS error.

Address Field

The Address field is a single octet, which contains the binary sequence 11111111 (hexadecimal 0xff), the All-Stations address.

Individual station addresses are not assigned. The All-Stations address MUST always be recognized and received.

Control Field

The Control field is a single octet, which contains the binary sequence 00000011 (hexadecimal 0x03), the Unnumbered Information (UI) command with the Poll/Final (P/F) bit set to zero.

The use of other Control field values may be defined at a later time, or by prior agreement. Frames with unrecognized Control field values SHOULD be silently discarded.

Frame Check Sequence (FCS) Field

The Frame Check Sequence field defaults to 16 bits (two octets). The FCS is transmitted least significant octet first, which contains the coefficient of the highest term.

A 32-bit (four octet) FCS is also defined. Its use may be negotiated as described in "PPP LCP Extensions".

The FCS field is calculated over all bits of the Address, Control, Protocol, Information and Padding fields, not including any start and stop bits (asynchronous) nor any bits (synchronous) or octets (asynchronous or synchronous) inserted for transparency. This also does not include the Flag Sequences nor the FCS field itself.

When octets are received which are flagged in the Async-Control-Character-Map, they are discarded before calculating the FCS.

The end of the Information and Padding fields is found by locating the closing Flag Sequence and removing the Frame Check Sequence field.

Modification of the Basic Frame - Address-and-Control-Field-Compression

The Link Control Protocol can negotiate modifications to the standard HDLC-like frame structure. However, modified frames will always be clearly distinguishable from standard frames.

When using the standard HDLC-like framing, the Address and Control fields contain the hexadecimal values 0xff and 0x03 respectively. When other Address or Control field values are in use, Address-and-Control-Field-Compression MUST NOT be negotiated. On transmission, compressed Address and Control fields are simply omitted.

On reception, the Address and Control fields are decompressed by examining the first two octets. If they contain the values 0xff and 0x03, they are assumed to be the Address and Control fields. If not, it is assumed that the fields were compressed and were not transmitted.

By definition, the first octet of a two octet Protocol field will never be 0xff (since it is not even). The Protocol field value 0x00ff is not allowed (reserved) to avoid ambiguity when Protocol-Field-Compression is enabled and the first Information field octet is 0x03.

PPP HDLC frame structure: fields

length field
1 octet Address = FF H (All-Stations address)
1 octet Control = 03 H
2 octets Protocol
n octets Information
The Information field is zero or more octets.
2 octets Frame Control Sequence

Control field

bits 1 _ _ _ _ _ _ 8 Control field
bits 1-2 1 1
bits 3-4 M M M: modifier function bit
bit 5 0 Poll/Final bit set to zero
bits 6-8 M M M M: modifier function bit

Bit 8 is the most significant bit.

bits M : 34 - 678 Command Response Frame designation
0 0 - 0 0 0 UI UI Unnumbered Information

PPP HDLC-like: octet-stuffed framing

Reference standard: RFC 1662

This topic summarizes the use of HDLC-like framing with 8-bit asynchronous and octet-synchronous links.

Flag Sequence

The Flag Sequence indicates the beginning or end of a frame. The octet stream is examined on an octet-by-octet basis for the value 01111110 (hexadecimal 0x7e).


An octet stuffing procedure is used. The Control Escape octet is defined as binary 01111101 (hexadecimal 0x7d), most significant bit first.

After FCS computation, the transmitter examines the entire frame between the two Flag Sequences. Each Flag Sequence, Control Escape octet, and any octet which is flagged in the sending Async-Control- Character-Map (ACCM), is replaced by a two octet sequence consisting of the Control Escape octet followed by the original octet exclusive-or'd with hexadecimal 0x20.

This is bit 5 complemented, where the bit positions are numbered 76543210 (the 6th bit as used in ISO numbered 87654321 -- BEWARE when comparing documents).

Receiving implementations MUST correctly process all Control Escape sequences.

On reception, prior to FCS computation, each octet with value less than hexadecimal 0x20 is checked. If it is flagged in the receiving ACCM, it is simply removed (it may have been inserted by intervening data communications equipment). Each Control Escape octet is also removed, and the following octet is exclusive-or'd with hexadecimal 0x20, unless it is the Flag Sequence (which aborts a frame).

A few examples may make this more clear. Escaped data is transmitted on the link as follows:

  • 0x7e is encoded as 0x7d, 0x5e. (Flag Sequence)
  • 0x7d is encoded as 0x7d, 0x5d. (Control Escape)
  • 0x03 is encoded as 0x7d, 0x23. (ETX)

Some modems with software flow control may intercept outgoing DC1 and DC3 ignoring the 8th (parity) bit. This data would be transmitted on the link as follows:

  • 0x11 is encoded as 0x7d, 0x31. (XON)
  • 0x13 is encoded as 0x7d, 0x33. (XOFF)
  • 0x91 is encoded as 0x7d, 0xb1. (XON with parity set)
  • 0x93 is encoded as 0x7d, 0xb3. (XOFF with parity set)

PPP encapsulation structure: fields

Reference standard: RFC 1661

length field
1 or 2 octets Protocol
n octets Information
m octets Padding

Frame field: Protocol

The protocol field is one or two octets and its value identifies the datagram encapsulated in the information field of the packet.

The structure of this field is consistent with the ISO-3309 extension mechanism for address field.

length Protocol field
octet 1 bits b16-b9 b9=0
octet 2 bits b8-b1 b1=1
This octet exists only if least significant bit of octet 1 is equal to 0.

Up-to-date values of the Protocol field are specified in the most recent "Assigned Numbers" RFC. This specification reserves the following values:

Value (in hex) Protocol Name
0001 Padding Protocol
0003 to 001f reserved (transparency inefficient)
007d reserved (Control Escape)
00cf reserved (PPP NLPID)
00ff reserved (compression inefficient)
8001 to 801f unused
807d unused
80cf unused
80ff unused
c021 Link Control Protocol
c023 Password Authentication Protocol
c025 Link Quality Report
c223 Challenge Handshake Authentication Protocol

Frame field: Information

The Information field is zero or more octets. The Information field contains the datagram for the protocol specified in the Protocol field.

The maximum length for the Information field, including Padding, but not including the Protocol field, is termed the Maximum Receive Unit (MRU), which defaults to 1500 octets. By negotiation, consenting PPP implementations may use other values for the MRU.

Frame field: Padding

On transmission, the Information field MAY be padded with an arbitrary number of octets up to the MRU. It is the responsibility of each protocol to distinguish padding octets from real information.


home     Quick start     Specifications     Connections     Features     How to?     Notes     Search     Site Map

updated:  27-Feb-04