From owner-freebsd-isdn Sun Apr 8 12:35:42 2001 Delivered-To: freebsd-isdn@freebsd.org Received: from smtp.kdt.de (ns2.kdt.de [195.8.224.2]) by hub.freebsd.org (Postfix) with ESMTP id 46A4937B422 for ; Sun, 8 Apr 2001 12:35:27 -0700 (PDT) (envelope-from is@beverly.kleinbus.org) Received: from jocelyn.sub-etha.wtal.de (line0632.kdt.de [213.240.147.50]) by smtp.kdt.de (8.8.8/8.8.8) with ESMTP id VAA11901 for ; Sun, 8 Apr 2001 21:35:25 +0200 Received: from marie.sub-etha.wtal.de (marie.sub-etha.wtal.de [213.240.145.124]) by jocelyn.sub-etha.wtal.de (Postfix) with ESMTP id 670092A8 for ; Sun, 8 Apr 2001 21:20:47 +0200 (CEST) Received: by marie.sub-etha.wtal.de (Postfix, from userid 1501) id BC04E64DE; Sun, 8 Apr 2001 21:19:42 +0200 (CEST) Date: Sun, 8 Apr 2001 21:19:42 +0200 From: Ignatios Souvatzis Cc: freebsd-isdn@FreeBSD.ORG Subject: Re: PPP encapsulation Message-ID: <20010408211942.A10788@beverly.kleinbus.org> References: <200104071129.f37BTjl55848@hak.lan.Awfulhak.org> <20010408132900.H89922@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010408132900.H89922@uriah.heep.sax.de>; from j@uriah.heep.sax.de on Sun, Apr 08, 2001 at 01:29:00PM +0200 Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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