From owner-freebsd-atm Tue Jul 23 11:58:31 1996 Return-Path: owner-atm Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA04453 for atm-outgoing; Tue, 23 Jul 1996 11:58:31 -0700 (PDT) Received: from plains.nodak.edu (tinguely@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA04441 for ; Tue, 23 Jul 1996 11:58:27 -0700 (PDT) Received: (from tinguely@localhost) by plains.nodak.edu (8.7.1/8.7.1) id NAA09046 for freebsd-atm@freebsd.org; Tue, 23 Jul 1996 13:58:08 -0500 (CDT) Date: Tue, 23 Jul 1996 13:58:08 -0500 (CDT) From: Mark Tinguely Message-Id: <199607231858.NAA09046@plains.nodak.edu> To: freebsd-atm@freebsd.org Subject: Re: freebsd-hackers ATM-FR virtual interface Sender: owner-atm@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [Insert: with the last mail, I meant to send Petri Helenius 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 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