From owner-freebsd-hackers Fri Jun 28 08:45:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA09141 for hackers-outgoing; Fri, 28 Jun 1996 08:45:55 -0700 (PDT) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA09135 for ; Fri, 28 Jun 1996 08:45:52 -0700 (PDT) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id LAA17007; Fri, 28 Jun 1996 11:45:15 -0400 Date: Fri, 28 Jun 1996 11:45:14 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: hackers@FreeBSD.ORG Subject: Re: Frame relay and ATM support: virtual interface per vpi? In-Reply-To: <199606281338.IAA29637@plains.nodak.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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