Jason Thorpe wrote:
> 
> 	- 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 :-)

So, if you'll bear with me for a little gedanken experament here,
because I want to learn more about these issues....

Say I was writing a SANA-II ATM driver (because, you know, there are
just tons of Zorro-III ATM bords on the market, being that there's a
huge market for them and all ;->).  Or any sort of driver for a network
stack that doesn't want to deal directly with the vagaries of ATM. 
Consider the following approach using a fake interface that sits atop
the real ATM interface:

Network driver pretends to be for a standard-ish network type, with
LLA's of sizeof(void *) bytes.  IP stack wants to send a packet to a ATM
machine, so it sends an ARP packet to the driver, requesting the LLA. 
Driver knows that ARP packet is an ARP packet (by the packet type),
extracts the information, uses the real ATM interface to ATMARP, opens a
SVC (Somethingorother Virtual Circuit?), allocates a block of memory to
contain the SVC's state, and returns a fake ARP reply with the address
of the SVC state block as the LLA. 

Now the IP stack wants to send a packet to that ATM machine, so it takes
the phony LLA it ARP'd, and sends off a packet to that LLA.  The
network driver looks up the SVC by the LLA, and sends the packet over
the SVC on the real interface. 

Danger: user can manipulate arp cache manually. So maybe use hash table
keys rather than pointers in the above.

Am I off my rocker, or is this an at least halfway sane method of coping
with ATM? It uses a layered approach where the stack doesn't have to
suddently acquire a lot more knowledge of the link level protocols, and
has the advantage of supporting several methods of IP-over-ATM at once
(one fake interface per type) on the same real interface.

For that matter it could work for any sort of "IP over
non-Point-to-Point Virtual-Circuit" deal, like IP over TCP without
predetermined point-to-point connections.