Subject: Re: Changes to networking code for token ring
To: John Messenger <John.Messenger@proteon.com>
From: Matt Thomas <matt@lkg.dec.com>
List: tech-net
Date: 05/23/1995 16:29:41
> I am writing a driver for a Proteon token ring card. It is based on
> NetBSD-1.0, and I don't know if -current has any more generic
> networking code. Initially the aim includes IP and ARP only.
> I am basing the implementation on RFC1042.
I have similar issues with my FDDI driver for the DEC DEFPA and DEFEA.
> This requires some changes to the networking code:
> * providing analagous routines to some in if_ethersubr.c
> (token_input, token_output, token_ipattach, maybe others later).
> * changing the ARP code (if_ether.c) to receive and send frames from
> 802 networks (there seems no point in duplicating this as the code
> almost supports 802 networks already)
Nothing in ARP should need to change (except the storing of the source
router). The if_tokensubr.c should automagically insert the SNAP SAP.
> * Other stuff I haven't even though of.
>
> Has Anyone Done This Already?
>
> Source Routing
> --------------
>
> My initial implementations of the above do not implement source
> routing except to throw it away when received. RFC1042 (in its "For
> IEEE 802.5" section) talks about how to use SR in this context. Has
> anyone implemented this, in a publically available way? The RFC asks
> whether RIF information should be stored in an extended ARP cache (for
> speed) or separately (for memory efficiency - RIF information is not
> needed in Ethernet).
I'd make it part of the llinfo with the llinfo be variable sized. This
would be a change to if_ether.c (which really should be if_arp.c but I
digress).
> Bear in mind when thinking about these issues that FDDI now defines
> source routing, and that 100VG-AnyLAN does too. The same mechanism as
> is suitable for token ring will also serve for those network types.
Source routing over FDDI - don't remind me.
> Who else might I ask about these issues?
In ULTRIX and Digital UNIX we use a common net_output/ether_output which
can deal with all the 802.2 compatible medias. This eliminates a lot of
common code.
An alternative method to break apart ether_input and ether_output into
common and media-specific parts and still have media-specific if_xxxsubr.c
files.
Matt Thomas Internet: matt@lkg.dec.com
U*X Networking WWW URL: http://ftp.dec.com/%7Ethomas/
Digital Equipment Corporation Disclaimer: This message reflects my
Littleton, MA own warped views, etc.