Subject: Re: Changes to networking code for token ring
To: John Messenger <>
From: Matt Thomas <>
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

> 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

Matt Thomas                          Internet:
U*X Networking                       WWW URL:
Digital Equipment Corporation        Disclaimer: This message reflects my
Littleton, MA                                    own warped views, etc.