Subject: Re: ATM NIC support
To: Ignatios Souvatzis <email@example.com>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 02/27/1997 11:05:07
On Thu, 27 Feb 1997 18:56:47 +0100 (MET)
Ignatios Souvatzis <email@example.com> wrote:
> Don't know myself; have to check docs. If it uses the same packet
> structure, it can share the code. If not, it can't; or at least, only
> the route table manipulation.
...the packet structure is somewhat similar, actually... I have some
changes to the ARP-related headers that add the ATMARP fields... I'll
dig those up..
In any case, ATMARP is a little strange in a couple of ways:
- In ATM, this is no broadcast domain, really. To
do ATMARP, you must communicate with an ATMARP server.
You must have, at the very least, a PVC to the server to
do this. This means that you need to "prime" your arp
code with the server at run-time somehow.. not hard, just
need a sane interface to do it.
- The reply of an ATMARP request is not something you can
use immediately to communicate with the target host. The
reply consists of 1 or 2 20-byte MAC addresses in some
combination of NSAP or E.164 formats (the combinations
are well-defined ... I just don't recall them at the moment;
it's been a while :-) The host must then signal with the
switch to establish an SVC for that MAC address. (At least,
that's how I remember it; someone who's mucked with it more
recently than I may want to correct me if I'm wrong :-)
> The ARP protocol does not really support variable length
> addresses. There is only one length field for sender and receiver
> hardware addresses, and another one for sender and receiver protocol
ATMARP replies are fixed-length ... the structure that holds the MAC
address for the target host must have room for 2 20-byte NSAP/E.164
addresses, plus some flags, _plus_ room for the SVC "stuff".
If you also want to support ATM QoS stuff, you also need to be able
to store multiple SVCs for a given target host MAC address, but
that would be a long-term goal...
I think that implementing ATMARP (without support for QoS) would be
a reasonably straightforward thing... it's mostly a matter of taking
the time to do it...
Jason R. Thorpe firstname.lastname@example.org
NASA Ames Research Center Home: 408.866.1912
NAS: M/S 258-6 Work: 415.604.0935
Moffett Field, CA 94035 Pager: 415.428.6939