Date: Wed, 26 Jun 1996 08:32:42 -0700 From: bmah@cs.berkeley.edu (Bruce A. Mah) To: "Ron G. Minnich" <rminnich@sarnoff.com> Cc: JULIAN Elischer <julian@ref.tfs.com>, hackers@freebsd.org Subject: Re: Frame relay and ATM support: virtual interface per vpi? Message-ID: <199606261532.IAA20514@premise.CS.Berkeley.EDU> In-Reply-To: Your message of "Tue, 25 Jun 1996 21:56:00 EDT." <Pine.SUN.3.91.960625212948.28491B-100000@terra>
next in thread | previous in thread | raw e-mail | index | archive | help
"Ron G. Minnich" writes: > No, one might as well not. Making a case for a virtual interface for each > ATM VCI has no correspondance to an interface per arp table entry. > Ethernet and atm are really very different, given the packet vs. vc model. > You may find what i found, that trying to screw the vc model into the > existing bsd net layer gets somewhat weird. To date, most companies > selling software for atm have made the atm interface work like an ethernet > interface, only a little different. Not a great idea, long term. I'm jumping into this discussion a little late, but: Doesn't it seem that if you do the VIF per VCI model, you're restricting yourself to having only a single VC to any given destination? In other words, it seems that this model would preclude my being able to have multiple VCs to another host. Why might you want to do this? Think of having VCs with different qualities of service for different traffic types. This might not make sense in the environment that MINI is designed for, though. Bruce.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606261532.IAA20514>