Date: Wed, 15 Nov 2000 15:56:13 -0500 (EST) From: Alex Pilosov <alex@pilosoft.com> To: Julian Elischer <julian@elischer.org> Cc: "Gary T. Corcoran" <gcorcoran@lucent.com>, freebsd-net@FreeBSD.ORG Subject: Re: netgraph/atm Message-ID: <Pine.BSO.4.10.10011151553270.29472-100000@spider.pilosoft.com> In-Reply-To: <3A12F3B7.CA569AAA@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Excellent point. Only thing to change will be ng_ksocket, and making it understand ATM address family. Thanks :) On Wed, 15 Nov 2000, Julian Elischer wrote: > 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 > > 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?Pine.BSO.4.10.10011151553270.29472-100000>