From owner-freebsd-atm Mon Jul 22 09:21:02 1996 Return-Path: owner-atm Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA14719 for atm-outgoing; Mon, 22 Jul 1996 09:21:02 -0700 (PDT) Received: from silver.sms.fi (root@silver.sms.fi [194.111.122.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA14712 for ; Mon, 22 Jul 1996 09:20:53 -0700 (PDT) Received: (from pete@localhost) by silver.sms.fi (8.7.5/8.6.9) id TAA11910; Mon, 22 Jul 1996 19:20:24 +0300 (EET DST) Date: Mon, 22 Jul 1996 19:20:24 +0300 (EET DST) Message-Id: <199607221620.TAA11910@silver.sms.fi> From: Petri Helenius To: Mark Tinguely Cc: freebsd-atm@freebsd.org Subject: freebsd-hackers ATM-FR virtual interface In-Reply-To: <199606271448.JAA06969@plains.nodak.edu> References: <199606271448.JAA06969@plains.nodak.edu> Sender: owner-atm@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mark Tinguely writes: > > list, I will not repost the digest file, but interested people can ftp > the file from: > > ftp://joy.cs.ndsu.nodak.edu/pub/hacker-atm-fr-mail > > I will leave the file on the above machine for a couple weeks. > To throw my opinion into the game since I consider that I've seen most what the boxes do today and how they are being used is that there is different scenarios where you want to either group (group == >=1 VC's) for a NBMA logical interface, have a point-to-point logical interface (with broadcast capability) on a single VC or have a point-to-point or NBMA interface with dynamically established connections. All these should have the possibility of having multiple VC's for a single destination with variance in QoS. Throwing LANE into the game you also have to support logical broadcast interface with ARP. Unclear enough? :-) Pete From owner-freebsd-atm Tue Jul 23 05:34:07 1996 Return-Path: owner-atm Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA10669 for atm-outgoing; Tue, 23 Jul 1996 05:34:07 -0700 (PDT) Received: from plains.nodak.edu (plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA10664; Tue, 23 Jul 1996 05:34:05 -0700 (PDT) Received: (from tinguely@localhost) by plains.nodak.edu (8.7.1/8.7.1) id HAA19304; Tue, 23 Jul 1996 07:33:27 -0500 (CDT) Date: Tue, 23 Jul 1996 07:33:27 -0500 (CDT) From: Mark Tinguely Message-Id: <199607231233.HAA19304@plains.nodak.edu> To: pete@sms.fi Subject: Re: freebsd-hackers ATM-FR virtual interface Cc: freebsd-atm@freebsd.org, freebsd-hacker@freebsd.org Sender: owner-atm@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > To throw my opinion into the game since I consider that I've seen most > what the boxes do today and how they are being used is that there is > different scenarios where you want to either group (group == >=1 VC's) > for a NBMA logical interface, have a point-to-point logical interface > (with broadcast capability) on a single VC or have a point-to-point or > NBMA interface with dynamically established connections. All these > should have the possibility of having multiple VC's for a single > destination with variance in QoS. Throwing LANE into the game you also > have to support logical broadcast interface with ARP. > > Unclear enough? :-) A single network session mapped into a single VC is a trend (Ipsilon licensed software with DEC, et al) to use the ATM switch as a IP switch. I think multiple IP VCs between two hosts will be very common. The original question was should: 1) each LANE/IP VC be viewed as a seperate addreable interface. If we have two paths between the same hosts, we have two adapters (atm0, atm1, etc) between the two hosts. 2) an ATM adapter be viewed as a mega-virtual IP adapter that can multiple IP/MAC address (ie., one adapter one name, no matter the LAN setup). 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. I switched my mind from option 2 to option 3. --mark. 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