Remote Access Server

PPP Encapsulation

PPP encapsulation uses a variant of the ISO High Level Data Link Control (HDLC) protocol to encapsulate multi-protocol datagrams as the payload of PPP frames. The PPP header and trailer is shown in Figure 7.10 and contains the following fields:

Flag - Set to 0x7E (bit sequence 011111110) to signify the start and end of a PPP frame. In successive PPP frames only a single Flag character is used.
Address - In HDLC environments, the Address field is used to address the frame to the destination node. On a point-to-point link, the destination node does not need to be addressed. Therefore, for PPP, the Address field is set to 0xFF, the broadcast address. If both PPP peers agree to perform address and control field compression during LCP negotiation, the Address field is not included.
Control - In HDLC environments, the Control field is used for data-link layer sequencing and acknowledgments. PPP does not provided link-to-link reliable data transfer. Therefore, for all PPP frames, the Control field is set to 0x03 to indicate an unnumbered information (UI) frame. If both PPP peers agree to perform address and control field compression during LCP negotiation, the Control field is not included.
Protocol ID - The 2-byte Protocol ID field identifies the protocol of the PPP payload. If both PPP peers agree to perform protocol field compression during LCP negotiation, the Protocol ID field is one byte for Protocol IDs in the range 0x00-00 to 0x00-FF.
Frame Check Sequence (FCS) - A 16-bit checksum that is used to check for bit level errors in the PPP frame. If the receiver's calculation of the FCS does not match the FCS in the PPP frame, the PPP frame is silently discarded.

The maximum size of a PPP frame, known as the maximum receive unit (MRU), is determined during the negotiation of the logical link. The default MRU is 1,500 bytes. If negotiated lower, a PPP host must still have the ability to receive 1,500-byte frames in the event of link synchronization failure.

Enlarge figure

Figure 7.10 PPP Encapsulation

Typical values for the PPP protocol ID are listed in Table 7.6.

Table 7.6 PPP Protocol IDs

Protocol	Protocol ID/Compressed Value
Internet Protocol (IP)	0x00-21 / 0x21
AppleTalk	0x00-29 / 0x29
IPX	0x00-2B / 0x2B
Van Jacobsen Compressed TCP/IP	0x00-2D / 0x2D
Multilink	0x00-3D / 0x3D
NetBEUI	0x00-3F / 0x3F
Microsoft Point-to-Point Compression Protocol (MPPC)	0x00-FD / 0xFD
Microsoft Point-to-Point Encryption Protocol (MPPE)	0x00-FD / 0xFD

If MPPE or MPPC are negotiated, then the PPP protocol ID is set to 0x00-FD. With MPPE and MPPC both using the same PPP Protocol ID, each peer must know that the resulting PPP payload either is encrypted or compressed, or both.

If only MPPC is negotiated, then the PPP Protocol ID is set to 0x00-FD and the PPP payload is compressed.
If only MPPE is negotiated, then the PPP Protocol ID is set to 0x00-FD and the PPP payload is encrypted.
If both MPPC and MPPE are negotiated, then compression always occurs before encryption. The compressed PPP frame, consisting of the PPP protocol ID field set to 0xFD and the compressed data, is then encrypted and encapsulated with another PPP header consisting of the protocol ID field set to 0xFD and a 2-byte MPPE header.

Preventing the Occurrence of the Flag Character

The use of the Flag character introduces a problem. What if the Flag character (0x7E) appears elsewhere in the PPP frame besides the beginning or end of the PPP frame? PPP employs two different methods to prevent the occurrence of the Flag character depending on whether PPP is being used on an asynchronous link or a synchronous link.

PPP on Asynchronous Links

On asynchronous links, such as analog phone lines, PPP uses a technique called character stuffing to prevent the occurrence of the Flag character within the PPP frame. If the Flag character (0x7E) occurs elsewhere in the PPP frame, the sender replaces it with the sequence 0x7D-5E. The 0x7D character is known as the PPP Escape character. If the PPP Escape character occurs, the sender replaces it with the sequence 0x7D-5D. The receiver translates 0x7D-5E sequences back to 0x7E and 0x7D-5D sequences back to 0x7D.

Additionally, character values less than 0x20 can be modified to prevent the serial drivers from interpreting them as control characters. If negotiated by LCP, characters below 0x20 are modified by sending the sequence: 0x7D-[Original character with the 6th bit complemented]. For example, the byte 0x01 would be transmitted as 0x7D-0x21.

PPP on Synchronous Links

With synchronous links, such as T-Carrier, ISDN, or other digital links, a technique called bit stuffing is used to prevent the occurrence of the Flag character within the PPP frame. Recall that the Flag character is the bit sequence 01111110. Bit stuffing ensures that six 1 bits in a row occur only when the Flag character is sent. To accomplish this, bit stuffing sends the Flag character unmodified and elsewhere inserts a 0 bit whenever a sequence of five 1 bits occurs. Therefore, the bit sequence 111111 is encoded on the medium as 1111101 and the bit sequence 111110 is encoded as 1111100 (the stuffed bits are underlined). Bit stuffing means that a byte can be encoded on the medium as more than eight bits, but the stuffed bits are added and removed by the synchronous link hardware.