Subject: Re: ATM NIC support
To: Ignatios Souvatzis <>
From: Jason Thorpe <>
List: tech-net
Date: 02/27/1997 11:05:07
On Thu, 27 Feb 1997 18:56:47 +0100 (MET) 
 Ignatios Souvatzis <> 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
 > addresses.

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                             
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