|
|
|
| PPPStandard reference:
PPP framingThe PPP encapsulation is used to disambiguate multiprotocol datagrams. This encapsulation requires framing to indicate beginning or end of the encapsulation over different link types:
PPP frame structure: fieldsBasic FrameThe 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.
Flag SequenceEach 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 FieldThe 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 FieldThe 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) FieldThe 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-CompressionThe 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
Control field
Bit 8 is the most significant bit.
PPP HDLC-like: octet-stuffed framingReference standard: RFC 1662 This topic summarizes the use of HDLC-like framing with 8-bit asynchronous and octet-synchronous links. Flag SequenceThe 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). TransparencyAn 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:
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:
PPP encapsulation structure: fieldsReference standard: RFC 1661
Frame field: ProtocolThe 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.
Up-to-date values of the Protocol field are specified in the most recent "Assigned Numbers" RFC. This specification reserves the following values:
Frame field: InformationThe 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: PaddingOn 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 |