How PPP
Utilizes the HDLC Format ?
Table of Contents:
Modification of the
Basic Frame
The Use of Bit-synchronous
HDLC
The Use of
Octet-synchronous HDLC
Both PPP and HDLC provide a
data-link layer (layer 2) service, according to the Open Systems
Interconnection (OSI) reference model.
The HDLC protocol is defined by ISO
for use on both point-to-point and multipoint (multidrop) data links. It
supports full duplex transparent-mode operation and is now extensively used in
both multipoint and computer networks. The PPP, on the other hand, is a
protocol for communication only over point-to-point links, typically between a
personal computer and a server which are connected by a phone line. The PPP's
links provide as well full-duplex simultaneous bi-directional operation, and
are assumed to deliver packets in order.
In many networks implementations
PPP uses HDLC as a basis for the framing. In these occasions we talk about
framing over both bit-oriented and octet-oriented synchronous links, and
asynchronous links with 8 bits of data and no parity. These links MUST be full-duplex, but MAY be either dedicated
or circuit-switched.
Nevertheless, PPP uses the HDLC
Frame Check Sequence for error detection. This is commonly available in
hardware implementations, and a software implementation is provided.
The purpose of this web-page is not
to document about HDLC or PPP protocols.
It is assumed that the reader is already familiar with HDLC and
PPP. Instead, this document
attempts to give a concise summary and point out specific options and features
used by PPP.
A summary of the PPP's HDLC frame
structure is shown in the table below:
|
Flag |
Address |
Control |
Protocol |
Information |
Padding |
FCS |
Flag |
|
01111110 |
11111111 |
00000011 |
2 Bytes |
Variable |
* |
2 Bytes |
01111110 |
This table does not include
start/stop bits (for asynchronous links), nor any bits or octets inserted for
transparency. The fields are transmitted from left to right.
The Protocol, Information and
Padding fields are described in the Point-to-Point Protocol Encapsulation (see
in our PPP page).
Flag Sequence
The Flag Sequence indicates the
beginning or end of a frame, and always consists of the binary sequence
01111110 (hexadecimal 0x7e).
Te Flag Sequence is a frame
separator. Only one Flag Sequence
is required between two frames.
Two consecutive Flag Sequences constitute an empty frame, which is
ignored, and not counted as a FCS error.
Address Field
The Address field is a single octet
and contains the binary sequence 11111111 (hexadecimal 0xff), the All-Stations
address.
PPP does not assign individual
station addresses. The
All-Stations address MUST always be recognized and received. The use of other address lengths and
values may be defined at a later time, or by prior agreement. Frames with
unrecognized Addresses SHOULD be silently discarded.
Control Field
The Control field is a single octet
and contains the binary sequence 00000011 (hexadecimal 0x03), the Unnumbered
Information (UI) command with the 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)
The Frame Check Sequence field is
normally 16 bits (two octets). The use of other FCS lengths may be defined at a
later time, or by prior agreement.
The FCS is transmitted with the coefficient of the highest term first.
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.
The end of the Information and
Padding fields is found by locating the closing Flag Sequence and removing the
Frame Check Sequence field.
Modified frames will always
be clearly distinguishable from standard frames. The method for distinguishing
is Address-and-Control-Field-Compression
When using the default HDLC
framing, the Address and Control fields contain the hexadecimal values 0xff and
0x03 respectively.
On transmission, compressed
Address and Control fields are formed by simply omitting them.
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.
When other Address or
Control field values are in use, Address-and-Control-Field-Compression MUST NOT
be negotiated.
This section summarizes the
PPP use of HDLC with 8-bit asynchronous links.
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) where the bit positions are numbered 87654321.
Each end of the link maintains two Async-Control-Character-Maps. The
receiving ACCM is 32 bits, but the sending ACCM may be up to 256 bits. This results in four distinct ACCMs,
two in each direction of the link.
The default receiving ACCM is 0xffffffff. The default sending ACCM is 0xffffffff, plus the Control
Escape and Flag Sequence characters themselves, plus whatever other outgoing
characters are known to be intercepted.
After FCS computation, the transmitter examines the entire frame
between the two Flag Sequences.
Each Flag Sequence, Control Escape octet, and octet with value less than
hexadecimal 0x20 which is flagged in the sending Async-Control-Character-Map,
is replaced by a two octet sequence consisting of the Control Escape octet and
the original octet with bit 6 complemented (exclusive-or with hexadecimal
0x20).
Prior to FCS computation, the receiver examines the entire frame
between the two Flag Sequences.
Each octet with value less than hexadecimal 0x20 is checked. If it is flagged in the receiving
Async-Control-Character-Map, it is simply removed (it may have been inserted by
intervening data communications equipment). For each Control Escape octet, that octet is also removed,
but bit 6 of the following octet is complemented, unless it is the Flag
Sequence.
The transmitter may also send octets with value in the range 0x40
through 0xff (except 0x5e) in Control Escape format. Since these octet values are not negotiable, this does not
solve the problem of receivers which cannot handle all non-control characters.
On asynchronous links, frames may be aborted by transmitting a
"0" stop bit where a "1" bit is expected (framing error) or
by transmitting a Control Escape octet followed immediately by a closing Flag
Sequence.
For asynchronous links, inter-octet and inter-frame time fill MUST be
accomplished by transmitting continuous "1" bits (mark-hold state).
Inter-frame time fill can be viewed as extended inter-octet time
fill. Doing so can save one octet
for every frame, decreasing delay and increasing bandwidth. This is possible since a Flag Sequence
may serve as both a frame close and a frame begin. After having received any frame, an idle receiver will
always be in a frame begin state.
Robust transmitters should avoid using this trick over-zealously, since
the price for decreased delay is decreased reliability. Noisy links may cause
the receiver to receive garbage characters and interpret them as part of an
incoming frame. If the transmitter
does not send a new opening Flag Sequence before sending the next frame, then
that frame will be appended to the noise characters causing an invalid frame
(with high reliability). It is suggested that implementations will achieve the
best results by always sending an opening Flag Sequence if the new frame is not
back-to-back with the last.
Transmitters SHOULD send an open Flag Sequence whenever
"appreciable time" has elapsed after the prior closing Flag
Sequence. The maximum value for
"appreciable time" is likely to be no greater than the typing rate of
a slow typist, say 1 second.
All octets are transmitted with one start bit, eight bits of data, and
one stop bit. There is no
provision for seven bit asynchronous links.
This section summarizes the PPP use of HDLC with bit-synchronous links.
Flag Sequence
The Flag Sequence indicates the beginning or end of a frame, and is
used for frame synchronization.
The bit stream is examined on a bit-by-bit basis for the binary sequence
01111110 (hexadecimal 0x7e).
Transparency
The transmitter examines the entire frame between the two Flag
Sequences. A "0" bit is inserted after all sequences of five
contiguous "1" bits (including the last 5 bits of the FCS) to ensure
that a Flag Sequence is not simulated.
When receiving, any "0" bit that directly follows five
contiguous "1" bits is discarded.
There may be some use of synchronous-to-asynchronous converters (some
built into modems) in point-to-point links resulting in a synchronous PPP
implementation on one end of a link, and an asynchronous implementation on the
other. It is the responsibility of
the converter to do all mapping conversions during operation.
Aborting a Transmission
A sequence of more than six "1" bits indicates an invalid
frame, which is ignored, and not counted as a FCS error.
Inter-frame Time Fill
For bit-synchronous links, the Flag Sequence SHOULD be transmitted
during inter-frame time fill.
There is no provision for inter-octet time fill.
Encoding
The definition of various encodings and scrambling is the
responsibility of the DTE/DCE equipment in use, and is not specified in the
RFCs.
This section summarizes the PPP use of HDLC with octet-synchronous
links, such as SONET and optionally ISDN B or H channels.
Although the bit rate is synchronous, there is no bit-stuffing.
Instead, the octet-stuffing feature of 8-bit asynchronous HDLC is used.
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).
Transparency
An octet stuffing procedure is used. The Control Escape octet is defined as binary 01111101
(hexadecimal 0x7d).
The
octet stuffing procedure is described above in the chapter The Use of
Asynchronous HDLC.
Considerations
concerning the use of converters are described in above in the chapter The Use of
Bit-synchronous HDLC.
Aborting a Transmission
Frames may be aborted by transmitting a Control Escape octet followed
immediately by a closing Flag Sequence.
The preceding frame is ignored, and not counted as a FCS error.
Inter-frame Time Fill
The Flag Sequence MUST be transmitted during inter-frame time
fill. There is no provision for
inter-octet time fill.
Encoding
The definition of various encodings and scrambling is the
responsibility of the DTE/DCE equipment in use, and is not specified in the
RFCs.
RFC 1549 - PPP in HDLC Framing
RFC 1662 - PPP in HDLC-like Framing