Re: ARP and NHRP question

Grenville Armitage <gja@thumper.bellcore.com> Tue, 28 November 1995 00:53 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05093; 27 Nov 95 19:53 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa05089; 27 Nov 95 19:53 EST
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.98.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id TAA13115; Mon, 27 Nov 1995 19:19:51 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id TAA05792 for rolc-out; Mon, 27 Nov 1995 19:33:00 -0500
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id TAA05783 for <rolc@nexen.com>; Mon, 27 Nov 1995 19:32:58 -0500
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id TAA13107 for <rolc@nexen.com>; Mon, 27 Nov 1995 19:18:41 -0500
Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id TAA16559; Mon, 27 Nov 1995 19:30:16 -0500
Message-Id: <199511280030.TAA16559@thumper.bellcore.com>
To: ip-atm@matmos.hpl.hp.com, rolc@nexen.com
cc: gja@thumper.bellcore.com
Subject: Re: ARP and NHRP question
In-reply-to: Your message of Mon, 27 Nov 1995 17:39:08 -0600. <199511272339.RAA15099@uh.msc.edu>
Date: Mon, 27 Nov 1995 19:30:15 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Grenville Armitage <gja@thumper.bellcore.com>
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/

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