From owner-freebsd-net Wed Nov 15 6:24:16 2000 Delivered-To: freebsd-net@freebsd.org Received: from gomer.august.net (gomer.august.net [216.87.128.131]) by hub.freebsd.org (Postfix) with ESMTP id E71E837B479 for ; Wed, 15 Nov 2000 06:24:14 -0800 (PST) Received: from localhost (1987 bytes) by gomer.august.net via send-mail with P:stdio/R:inet_hosts/T:smtp (sender: ) (ident using unix) id for ; Wed, 15 Nov 2000 08:24:08 -0600 (CST) (Smail-3.2.0.108 1999-Sep-19 #1 built 1999-Oct-11) Message-Id: Date: Wed, 15 Nov 2000 08:24:08 -0600 (CST) From: lgfausak@august.net (Greg Fausak) To: alex@pilosoft.com, gcorcoran@lucent.com Subject: Re: netgraph/atm Cc: freebsd-net@FreeBSD.ORG Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >On Tue, 14 Nov 2000, Gary T. Corcoran wrote: > >> > yep.. If that's what rfc1483 (the rfc) treats as input and output. >> >> Actually RFC1483 has four "flavors", two of which support "bridging" >> of complete 802.3 ethernet frames including the MAC addresses - either >> encapsulated with an LLC/SNAP header or "raw" with just a two byte >> (0x00, 0x00) pad for alignment purposes. Another flavor removes the >> MAC addresses, prepends a 6-byte LLC/OUI header, and preserves the >> EtherType and the rest of the frame. The other flavor just routes >> a PDU (raw packet with no MAC addressses or EtherType) across a VC >> (ATM virtual channel) with no encapsulation at all. >Yeah. I'm just implementing it to scratch my itch, and I'll see about >support of everything else later. I'm definitely going to try to support >llc/snap and raw mode. Without the ethertype, its 'routed PDU', and is >already handled just fine by existing ATM stacks. > >> Alex - if you intend to make your code public, and if you feel >> ambititious, it would be nice if you could support all four flavors >> of RFC1483. Then we could replace our Win2000 server with a FreeBSD >> server for testing our DSL implementations of RFC1483... ;-) >Yes, we are also doing it for DSL. Its quite unfortunate that telcos chose >'bridged mac/llc' as preferred method of delivery of DSL, since it has the >biggest overhead...But I guess for them transparency was the biggest >issue. Oh well. FWIW: One of the guys I work with did the DSL implementation for GTE. I asked him about the choice of bridging. He indicated that there are some legal reasons that bridged connections are delivered rather than routed connections. ---greg Greg Fausak August.Net Services, LLC greg@august.net 972-323-6598 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message