The Routing Over Large Clouds Mailing List Archive by date

[Grenville Armitage <gja@thumper.bellcore.com>]

I'd observe that it should be an _implementation_ issue how one
combines NHRP and ATMARP within LIS hosts.

I cant see a reason why NHRP cannot be used to request the
resolution of intra-LIS and inter-LIS IP addresses.

If an NHS knows all the mappings for the LIS(s) it serves,
there seems to be nothing wrong with it replying to ARP_REQUEST
messages (with the proviso that it doesn't run off and try
to query other NHSs for mappings it doesn't have an immediate
answer for).

On a practical level it is trivial for an NHS to act as a
ATMARP Server. The VC a client establishes to its NHS can
carry NHRP or ATMARP control messages. If it gets ARP_REQUEST,
it returns ARP_REPLY. If it gets NHRP-Request, it returns
NHRP-Reply. (Indeed, it can also carry MARS messages. I have
a functioning MARS/ARPServer combo running on my ATM network
now - one app, two functions. ARP_REQUESTs get ARP_REPLYs,
while MARS_REQUESTs get MARS_MULTIs.)

If you implement such a beast, your migration strategy is
relatively painless - 1577-only hosts will not notice when
their ATMARPServer becomes an NHS (because it still responds
to ATMARP messages at expected), and NHRP-only clients are
possible if you allow the NHRP side of the NHS to dabble in
its intra-LIS database to answer intra-LIS NHRP-Requests.

Clients that use ATMARP for intra-LIS queries, and NHRP
for inter-LIS queries are also supportable with such an NHS
(Although its hardly likely anyone would implement such a
client once we allow NHRP for intra-LIS queries).

Is there a 'gotcha' in the client registration aspect that I've
forgotten?

cheers,
gja