Date: Tue, 23 Jul 1996 11:07:21 -0400 (EDT) From: "Ron G. Minnich" <rminnich@Sarnoff.COM> To: freebsd-hackers@FreeBSD.ORG Subject: Re: freebsd-hackers ATM-FR virtual interface Message-ID: <Pine.SUN.3.91.960723091705.9002C-100000@terra> In-Reply-To: <199607231238.HAA19617@plains.nodak.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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?Pine.SUN.3.91.960723091705.9002C-100000>