Date: Tue, 23 Jul 1996 13:58:08 -0500 (CDT) From: Mark Tinguely <tinguely@plains.nodak.edu> To: freebsd-atm@freebsd.org Subject: Re: freebsd-hackers ATM-FR virtual interface Message-ID: <199607231858.NAA09046@plains.nodak.edu>
next in thread | raw e-mail | index | archive | help
[Insert: with the last mail, I meant to send Petri Helenius <pete@sms.fi>
to freebsd-hackers as well as to freebsd-atm so that people on hackers that
originally raised the topic could see the comment from freebsd-atm, but I
misspelled freebsd-hackers (freebsd-hacker). Anyway he replied, so I will
relay this to freebsd-atm. I will get some sleep before I answer this, but
those that want to jump in, please carbon to the freebsd-hacker group also]
----- forward ---
Ron G. Minnich <rminnich@Sarnoff.COM> says:
> 3) the ATM virtual IP adapter has a single IP/MAC number which is made up
> of all the VC that contain that local IP/MAC address. It is possible for a
> single ATM card could have multiple virtual IP adapters. This combines
> all VCs that make a emulated IP conection into a single virtual adapter.
> Multiple VC beween hosts will use the same virtual adapter; If you
> use different emulated networks for two sessions they belong to different
> virtual adapters eventhough they bot use the same ATM adpater.
>
wish we could draw pictures in email. I'll do this for MINI.
In hardware, mini looks like 4096 atm adapters. We call these virtual
ATM interfaces, in the same sense that we call memory virtual memory:
there's a physical artifact backing the virtual one. Thus MINI virtual
interfaces are real. I'll call them VAMs, for Virtual AtM interfaces. A
single VAM needs a single VC.
Here are some scenarios.
1) Multiple IP connections over one VAM
2) one IP connection on one VAM
3) one IP connection that uses several VAMs, i.e. for striping.
[[ see Traw@cis.upenn.edu's thesis on striping for an example of multiple
ATM interfaces for one connection. How would IP handle this? ]]
4) one raw ATM connection (and one VAM) for a user program.
Still calls send/recv
but it's not going via IP, but direct to the ATM layer. protosw
handles this quite nicely.
5) multiple VAMs per user program for striped I/O.
6) Direct-access VAM (i.e. VAM mapped into user space)
either single or multiple
Note that for MINI, as opposed to other direct-map interfaces, all 6 of
these can exist concurrently. Can the structure you describe above
acommodate it? I'm not sure what you mean by
>single IP/MAC number which is made up
>of all the VC that contain that local IP/MAC address
Does this mean some kind of bit-field?
Here's what I'm looking at now:
There's one physical interface struct for each MINI physical interface
(/dev/mini). add a protosw entry for PF_ATM. This will support VC
creation, setup, teardown, etc. PF_INET can call this for services. Routes
from the IP to the ATM layer point to the correct VAM.
So we have:
1) [[ multiple IP connections per VAM, or one IP connection per VAM]]
users open socket with PF_INET. The bind will use the ATM interface
if the user's sockaddr hashes to an interface. A route is created to
the interface, with VC, VP etc. set correctly. When the interface
first starts being used an ATM connection is made to the host.
2) [[ IP connection per multiple VAMs ]]
Need to define a 'VAM group' for striping. This would include
a set of VAMs. Note that you need this even if you're not using
MINI -- suppose you are driving four FORE cards for one IP
connection?
3) [[one or more VAMs per user]]
use the 'interface group' described above.
4) [[direct access to onr or more VAMs]]
a) you can mmap the socket to get the VAM(s) mapped in
b) send/recv/etc. are disabled for as long as the
VAMs are mmap'ed.
How's this? what we need are descriptors for sets of VAMs. This is a
fundamental difference from IP -- in IP, one IP entity maps to one
interface, not one or more.
ron
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607231858.NAA09046>