Date: Fri, 28 Jun 1996 11:45:14 -0400 (EDT) From: "Ron G. Minnich" <rminnich@Sarnoff.COM> To: hackers@FreeBSD.ORG Subject: Re: Frame relay and ATM support: virtual interface per vpi? Message-ID: <Pine.SUN.3.91.960628100148.16297B-100000@terra> In-Reply-To: <199606281338.IAA29637@plains.nodak.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
OK, I'm finding this whole atm discussion interesting, but there's some
conceptual problems cropping up. So I want to address these, since they
impact how atm is integrated.
I'm going to ignore UDP for the moment. Finding a useful analog to UDP in
the ATM world is somewhat interesting, since ATM is VC-based. It seems
to me that UDP will always be based on some sort of LAN emulation over
VCs.
Here's the picture the way things are now, roughly: Using a file
descriptor, clients talk to a stream service provided by TCP. Kernel
uses fd to get info, then passes it to the socket layer. Socket layer
goes via protosw to tcp. TCP does its thing, using stored per-stream
info, drops to ip_output. ip_output finds the interface via route if
needed, passes mbufs to the interface. The IP layer is not really
stream-conscious. Interface is a thing that knows how to push packets
onto the 'wire', whatever that is (i.e. fiber, packet radio, real wire,
etc.). [Golly, no wonder things take 300 microseconds. - ed.]
Ok, what about ATM? well, there's a number of choices. I'll enumerate
the ones we have for MINI, which is basicallyh one more than we have
for everything else.
1) Use tcp. Same as above. Kind of weird, because TCP is supporting
a multiple reliable byte stream model for applications, and using
a multiple unreliable byte stream model from the interface.
Doesn't sound
as weird as it starts to look when you start to jam the driver in.
2) VC access by some form of 'open("/dev/atm", ); and other magic.
application does writes and reads to FDs, which go to the interface.
Making this work is "interesting" on some interfaces. Making it not
impact TCP has got to somehow be more interesting.
3) Direct access to a virtual interface. No OS involvement. Application
diddles CSRs directly. Application might even run TCP internally.
Now, if (1) were the only thing you want to do, you could probably hide
the VC as part of the routing table (Anyone? am i nuts?). If you want to
do (2) as well, you could always use something like DLPI (AGGGGGHHHHH!
NO! NO! NO!). But (3) sort of breaks the rules. Applications can use
that interface any way they want. They can run TCP half the time, or
not. They may send MPEG. Either way, the OS has no way of knowing what's
happening, other than being able to see the raw amount of data being
sent. Which, by implication, means that the kernel TCP also much less
knowledge of what's really happening on the interface.
I kind of like having the atm virtual interfaces which are active visible
at the file system level in some way (i.e. /dev/atm012, etc.) *or* as a
net interface. I personally don't really like this 'open up a generic
thing and push bytecodes down it' business (i.e. DLPI-like). I suppose
you can write a set of programs to pull out the relevant data from the
relevant structs, or use sysctl somehow. But when i tried writing the
first MINI driver for IRIX, though, I found myself recreating much of the
structure that's in an 'if' struct anyway.
Sorry this seems so random. My thoughts on this are pretty random
anyways, revealing my basic confusion at this point.
So the choices for ATM VC management:
1) as added info for routes (wouldn't this cover the TCP case?).
fails for mini in both indirect and direct VC access modes.
2) DLPI-like mode. But then you need programs or 'sysctl' to traverse the
kernel structures. DLPI-like interfaces make me ill.
3) interface-per-active VC. This was my first cut on IRIX. After dennis'
comments I'm rethinking it.
4) /dev/ node per active VC. or some sort of devfs entry. This would
be nice in many ways.
5) /proc-like setup. Sort of like the plan9 'net' file system. This may
be the way to go. I like it more and more, compared to the alternative.
Good paper on this in the plan9 archives.
Comments?
ron
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.960628100148.16297B-100000>