From owner-freebsd-hackers  Mon Jun 24 16:56:27 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id QAA24799
          for hackers-outgoing; Mon, 24 Jun 1996 16:56:27 -0700 (PDT)
Received: from etinc.com (etinc.com [204.141.244.98])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA24794
          for <hackers@freebsd.org>; Mon, 24 Jun 1996 16:56:24 -0700 (PDT)
Received: from dialup-usr11.etinc.com (dialup-usr11.etinc.com [204.141.95.132]) by etinc.com (8.6.12/8.6.9) with SMTP id UAA17778; Mon, 24 Jun 1996 20:04:12 -0400
Date: Mon, 24 Jun 1996 20:04:12 -0400
Message-Id: <199606250004.UAA17778@etinc.com>
X-Sender: dennis@etinc.com
X-Mailer: Windows Eudora Version 2.0.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Julian Elischer <julian@ref.tfs.com>
From: dennis@etinc.com (Dennis)
Subject: Re: Frame relay and ATM support
Cc: hackers@freebsd.org
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>
>I'm looking into the support needed in FreeBNSD to support 
>ATM and Frame relay services in a generic manner.
>
>mostly this would suggest a file equivalent to if_ethersubr.c
>but if_framesubr.c or something, that knows how to 
>associate DLCI's (or VPI's) with
>addresses, in the same way that ARP does for ethernet,
>with a convenient method for controlling such entries.
>
>ET inc. (hi Dennis) seem to associate a virtual interface
>with each DLCI in their frame realy product, and this actually
>makes some sense, but I rather dislike the idea of intefaces that
>don't really associate with the hardware they are running on,
>and would RATHER do it in such a way that 
>ifconfig -a would return:
>
>
>fr0: flags=c010<NBMA,MULTICAST> mtu 552
>	inet 3.3.3.3 --> 4.4.4.4 netmask 0xff000000 
>	inet 3.3.3.3 --> 140.5.5.5 netmask 0xffffff00 
>note: that this doesn't work at the moment because
>the addition of the alias wipes out the original if the local address
>is the same..
>
>(BTW NBMA == non broadcast multiple access)
>
>I bring this up because Iwas hired to write a driver for a frame relay
>interface for a proprietary project, and want to make sure that as much of 
>what I write can be brought back to FreeBSD as being of general use.
>

I like the addition of an NBMA type, except why should it be necessary?
It seems that any non-PTP interface with the broadcast flag not set
should be NBMA by default.

As for the other stuff...beware, things are not always as they appear.
Enough said.

Dennis

PS: Please dont hack up the O/S too much before you're really sure that
what  you are doing is what you want to do....its such a nice little O/S :-)

----------------------------------------------------------------------------
Emerging Technologies, Inc.      http://www.etinc.com

Synchronous Communications Cards and Routers For
Discriminating Tastes. 56k to T1 and beyond. Frame
Relay, PPP, HDLC, and X.25 for BSD/OS, FreeBSD 
and LINUX