Date: Wed, 15 Nov 2000 12:36:07 -0800 From: Julian Elischer <julian@elischer.org> To: Alex Pilosov <alex@pilosoft.com>, "Gary T. Corcoran" <gcorcoran@lucent.com>, freebsd-net@FreeBSD.ORG Subject: Re: netgraph/atm Message-ID: <3A12F3B7.CA569AAA@elischer.org> References: <Pine.BSO.4.10.10011150129250.26018-100000@spider.pilosoft.com> <3A126A2D.7F43B120@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I just realised that you could even do this without changing the ATM
code,
as the ATM code can be attached to by sockets and the netgraph
system knows how to make socket-like endpoints into nodes.
So you using the netgraph "ksocket" type one could open
an ATM socket on some channel
and attach it via netgraph to the eiface type of node.
this effectively gives you an ethernet interface, attached to
a PVC (or whatever you open the socket as.)
Just a thought..
(though a native Netgraph interface to the ATM code would be cooler).
Julian Elischer wrote:
>
> Alex Pilosov wrote:
> >
> > 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.
>
> My question is whether there are any boards that can give us the
> physical
> interface to a DSL line so that we can run this ATM code over a DSL
> line?
> It's one thing having the software but the bits need to get out of the
> system somehow.
>
> One thing I just thought about, is that if we are simulating an
> ethernet interface and bridging the packets using mac/llc
> then wouldn;t we require that we have some unique MAC address
> for that virtual interface so that things don't break?
> (can we just always use broadcast?) are the packets multiplexed
> using destination MAC address?
>
> Also which of the two ATM stacks in FreeBSD is the most suitable?
> I'm guessing HARP, but NATM, because it is such a very basic
> framework, might be suitable for netgraphification..
>
> (I have no idea if I'm talking rubish but
> a simple netgraph node that does aal1/aal5
> would fit into the netgraph world very well.)
>
> >
> --
> __--_|\ Julian Elischer
> / \ julian@elischer.org
> ( OZ ) World tour 2000
> ---> X_.---._/ presently in: Budapest
> v
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000
---> X_.---._/ presently in: Budapest
v
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A12F3B7.CA569AAA>