The IP over ATM Mailing List Archive by date

[gja@thumper.bellcore.com]

(Apologies if this is seen twice anywhere....)

	[..]
>>I think that the
>>expectation is that an entity with an IP address will accept IP traffic.
>>
>>> What host would send IP traffic to the ARP Server, and why?
>>
>>Well, the ARP server has an IP address, thus I can say "telnet arpserver"
>>and I will send IP packets.  It's reasonable to assume that you can connect
>>to a system with an IP address.

Well, we'll just have to be clearer about why an entity might "have
an IP address". In 'conventional' networks we have never had to
divorce an ARP entity from an IP entity. As Craig Partridge noted
a few days ago, rfc1577 poses a new scenario of ARP clients and
servers where in the past they were all pretty much peer clients.

In the past an ARP entity might be considered to inherit the IP address
of its coresident IP entity, but this need not be the case in the 
rfc1577 LIS. The ARP Server "has" an IP address ONLY so it can tell hosts
it is InARPing with just what subnet it is interested in - no other reason.
We should not follow through with the expectation that there MUST
a coresident IP entity. (rfc1577 only "recommends" coresidency, btw)

Anyway, I don't see the problem with doing "telnet arpserver". Sure you
can 'connect' to the system. Your rfc1577 compliant host will establish
a VC to the LLC entity at the ARP Server quite happily, and the LLC
entity at the ARP Server will even more happily turf your IP packets
into /dev/null. No problem. The 'standalone ARP Server' looks just like
an IP host that is switched off as far as the usual swag of TCP or UDP
apps are concerned.

	[...]

>>> Routes
>>> out of the LIS are configured into hosts using the router's IP address.
>>> The host ARPs for the router's IP address, gets back a LIS ATM address
>>> distinct from that of the ARP Server, and goes merrily on its way.
>>
>>But aren't the ARP server and the IP router (in this case) the same
>>(as long as they share an IP address and use LLC encapsulation)?

No. I was talking about Craig's model - where he appeared to have
physically co-resident ARP Server and IP router with different
LIS addresses. I am simply pointing out there is no interop problem
with Craig's model, because it is little different to the completely
non-co-resident case.

>>If they
>>are at separate NSAPAs then LLC/SNAP encapsulation is redundant (and
>>useless on at least one of the VCs)

Quite true, but we are digressing here (at least from the observations
I was making). LLC/SNAP encapsulation is _required_ by default, so
I am not currently questioning its worth.

	[..]

>>Introducing LLC means that you
>>differentiate between IP and ARP at the LLC layer rather than at the ATM
>>(VC) layer and make them reachable via the same LLC entity.  Yes?  No?

Quite true.

	[....]

I couldn't really find reason to comment on the rest of your post because
it contained essentially truthful information that I didn't think
was in question. (And my reply is already too long :-)

Craig, do _you_ think your implementation will have interop problems?

regards,
gja