Date: Sun, 8 Apr 2001 21:19:42 +0200 From: Ignatios Souvatzis <is@beverly.kleinbus.org> Cc: freebsd-isdn@FreeBSD.ORG Subject: Re: PPP encapsulation Message-ID: <20010408211942.A10788@beverly.kleinbus.org> In-Reply-To: <20010408132900.H89922@uriah.heep.sax.de>; from j@uriah.heep.sax.de on Sun, Apr 08, 2001 at 01:29:00PM %2B0200 References: <martin@duskware.de> <200104071129.f37BTjl55848@hak.lan.Awfulhak.org> <20010408132900.H89922@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 08, 2001 at 01:29:00PM +0200, J Wunsch wrote:
> The RFCs are a bit vague at this. RFC 1618 talks about
> bit-synchronous HDLC to be used by default, with a reference to RFC
> 1549 (which has been obsoleted by 1662 later). RFC 1662 describes the
> framing in section 3, and then describes the octet stuffing in section
> 4 (which is used e. g. for asynchronous links), and the bit stuffing
> in section 5. I read this the way that section 3 always applies,
> while the methods described in section 4 and 5 are being used as
> alternatives, depending on the features of the underlying transport.
right.
Please forgive me if I iterate stuff that all of you know.
Basically, HDLC consists of several layers...
a) some sort of bit/byte stuffing and framing and basic data integrity.
a1) On sync links, a frame is delimited by 01111110 .... 01111110.
After each 5 consecutive 1 in the data, a 0 is inserted on the wire
(and removed on reception), so that 0x7E can be transmitted.
A packet is (usually) ended by a 16 bit crc using the polynomial we
all love.
a2) On async, character-oriented links, the character-stuffing rules apply:
0x7E ... 0x7E are the frame delimiters
0x7E is used to escape 0x7E (and others that need it), and the escaped
octet is xored with 0x20.
crc is applied as above.
a3) in theory, HDLC could be done over any other transport that gives you
known-sized, crc-or-similar-secured (in the sense of "known to be good
or ignored if known to be bad") data packets. PPP over some media makes
use of this, most infamous being PPPoE.
b) above that, HDLC gives you:
- addressing. a HDLC packet starts with an address, which is
potentially variable sized... the first n-1 bytes are even, the last one
is odd. In theory, HDLC could be applied to links with more than 2 stations.
especially, there is the all-stations address, 0xff, which is received by
any station that sees it.
- a control byte distinguishing several types of packets.
1. connection state control packets for link state control, if you need
this.
2. sequence numbered data packets with retransmission and flow control,
vaguely similar to a simplified TCP. (e.g. X.25 uses this to transmits
its control and data reliably to the next station; I think ISDN D-channel
communication uses this, too, to talk to the switch at the other end).
3. unnumbered data packets, (officially: unnumbered information), whose
code is --- surprise surprise --- 0x03.
- the data following is packet type dependent, with unnumbered information
packets you have only the user data.
Now, _usually_, PPP uses the all-stations addressing, and puts the
higher level data (be it LCP, IPCP, IP, ...) inside UI frames,
resulting in the ff 03 at the start of packets.
If and only if this is the case, LCP makes it possible to negotiate with your
peer that you want to compress those bytes by eliminating them. LCP is always
sent with address and control in front, so that it always works even if the
peers have somehow lost synchronization. (btw, PPP (RFC 1662 again)
discourages this (as well as compressing the PPP packet type into one byte)
because ff, 03, and two bytes of packet type give you longword alignment, which
is nice for DMA hardware).
Synchronoous HDLC hardware usually handles bit stuffing, framing and CRC
detection. (If I recall right, adding TWO crcs might work, you only end up
with 2 bytes of garbage before the next frame delimiting flag, or rather,
at the end of the data.)
Regards,
Ignatios
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isdn" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010408211942.A10788>