The Routing Over Large Clouds Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1995-Nov> msg00158



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

ARP and NHRP question

  • From: Bryan Gleeson <bryang@eng.adaptec.com>
  • Date: Mon, 27 Nov 95 19:33:54 PST
  • Cc: ip-atm@matmos.hpl.hp.com, rolc@nexen.com
  • X-Orig-Sender: owner-rolc@nexen.com

Tim

>Are you saying that an NHRP server and an ATMARP server should co-reside,
>perhaps even share a common database, but support two protocols for
>resolving IP addresses into ATM addresses?
>
>Or, should the "NHRP server be the ATMARP server" in the sense that
>the server and clients support only one protocol for resolving IP
>addresses into ATM addresses, namely the NHPR protocol?
>
>By the way, I prefer the latter solution: migrate to using the NHRP
>protocol (or any other other _single_ protocol that works, for that
>matter) for resolving both intra-LIS and inter-LIS IP addresses.
>

Yes I agree with this, and with Grenville's and other postings that have 
already agreed with this. We should allow clients to use _one_ address
resolution protocol, namely NHRP. We should require that NHRP servers
also implement ATMARP server functionality, so that a client can use
either ATMARP or NHRP. There should definitely not be a requirement
that a client must try ATMARP first, and then NHRP, or NHRP first
and then ATMARP. This is just the principle of pushing the complexity
into a small number of servers rather than a large number of clients.

I think it would be OK to require that these NHRP+ATMARP servers
only implement the ability to respond to ATMARP requests, and don't
have to bother with issuing InATMARP requests everytime a new VCC
is established, behaviour which I guess is obsoleted by 1577+. It 
depends on how far back you want to go in backwards compatibility.
I think most clients today actually register themselves rather than
just respond to InATMARPs issued by the ATMARP server. This is because
there is no other way for a client to know that it has actually registered
successfully.

It also brings up the applicability of the distributed ARP server
functionality in 1577+. It seems that we should be looking at having
one approach for both ATMARP servers and NHSs, and I agree with Andrew
that we need to start looking at server redundancy for NHRP soon if
it is going to be really useful.


Regards,
Bryan Gleeson
Adaptec.