 |
|
Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
|
|
|
Custom Search
|
|
PPP General Frame Format
(Page 1 of 4)
All messages sent using PPP can be considered either data or control information. The word “data” describes the higher-layer datagrams we are trying to transport here at layer two; this is what our “customers” are giving us to send. Control information is used to manage the operation of the various protocols within PPP itself. Even though different protocols in the PPP suite use many types of frames, at the highest level they all fit into a single, general frame format.
In the overview of PPP I mentioned that the basic operation of the suite is based on the ISO High-Level Data Link Control (HDLC) protocol. This becomes very apparent when we look at the structure of PPP frames overall—they use the same basic format as HDLC, even to the point of including certain fields that aren't strictly necessary for PPP itself. The only major change is the addition of a new field to specify the protocol of the encapsulated data. The general structure of PPP frames is defined in RFC 1662, a “companion” to the main PPP standard RFC 1661.
The general frame format for PPP, showing how the HDLC framing is applied to PPP, is described in Table 32 and illustrated in Figure 32.
Field Name |
Size (bytes) |
Description |
Flag |
1 |
Flag: Indicates the start of a PPP frame. Always has the value “01111110” binary (0x7E hexadecimal, or 126 decimal). |
Address |
1 |
Address: In HDLC this is the address of the destination of the frame. But in PPP we are dealing with a direct link between two devices, so this field has no real meaning. It is thus always set to “11111111” (0xFF or 255 decimal), which is equivalent to a broadcast (it means “all stations”). |
Control |
1 |
Control: This field is used in HDLC for various control purposes, but in PPP it is set to “00000011” (3 decimal). |
Protocol |
2 |
Protocol: Identifies the protocol of the datagram encapsulated in the Information field of the frame. See below for more information on the Protocol field. |
Information |
Variable |
Information: Zero or more bytes of payload that contains either data or control information, depending on the frame type. For regular PPP data frames the network-layer datagram is encapsulated here. For control frames, the control information fields are placed here instead. |
Padding |
Variable |
Padding: In some cases, additional dummy bytes may be added to pad out the size of the PPP frame. |
FCS |
2 (or 4) |
Frame Check Sequence (FCS):
A checksum computed over the frame to provide basic protection against
errors in transmission. This is a CRC code similar to the one used for
other layer two protocol error protection schemes such as the one used
in Ethernet. It can be either 16 bits or 32 bits in size (default is
16 bits). |
Flag |
1 |
Flag: Indicates the end of a PPP frame. Always has the value “01111110” binary (0x7E hexadecimal, or 126 decimal). |
|
Figure 33 shows one common application of the PPP general frame format: carrying data.The value 0x0021 in the Protocol field marks this as an IPv4 datagram. This sample has one byte of Padding and a 2-byte FCS as well. (Obviously real IP datagrams are longer than the 23 bytes shown here! These bytes are arbitrary and don’t represent a real datagram.) See Figure 43 for an illustration of how this same data frame is formatted and then fragmented for transmission over multiple links using the PPP Multilink Protocol.
|
|
| |||||||||||||||||||
Home - Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.