Subject: (ION) Re: Checking NHRP cache information

From: Diane Schuster <[email-masked]>
Date: Mon, 12 Jan 1998 11:18:45 -0500

Yu Ning wrote:
> 
> Hi friends,
> I've got a question about NHRP.
> In NHRP draft, page 6:
> 
>    example). Station S first determines the next hop to station D
>                        ^^^^^^^
>    through normal routing processes (for a host, the next hop may simply
>    be the default router; for routers, this is the "next hop" to the
>    destination internetwork layer address).  If the destination's
>    address resolution information is already available in S's cache then
>    that information is used to forward the packet.  Otherwise, if the
>    next hop is reachable through one of its NBMA interfaces, S
>    constructs an NHRP Resolution Request packet (see Section 5.2.1)
>    ....
> 
> Why should S use normal routing processes to determines the next hop
> to station D? I don't think the intermediate IP address is useful for
> creating a cut-through NBMA link. Instead, I think S should check its
> cache first to see if the dest IP address has already its NBMA address
> in the cache. Then, if not hit, it should send NHRP req to preconfigured
> NHS for resolution.
> 

One has to look at the bigger picture, not just the NBMA subnetwork when
reading this paragraph. S cannot assume that the station it wishes to
reach is reached via the NBMA network. It may be connected to other
subnetworks (e.g. Ethernet) and station D could be reachable via one of
those subnetworks. Once it determines that it should use the NBMA
network as the next hop, then it would check its cache before sending
the NHRP Resolution Request.

This section is just an overview and does not provide the detailed
operation of the NHC's and NHS's. In an effort to explain how the NHRP
protocol is used to accomplish the overall purpose of getting a packet
from point S to point D, the checking of the cache was left out of the
description. Also, checking the cache is not actually part of the
protocol itself so it need not be described in the document. How entries
are placed in the cache and the aging of entries is part of the protocol
so that is described in the document.

> That's just like what the ATM ARP dose, and the only diff is ARP relay was
> restricted within LIS, while NHRP req/replay can be send via routing
> path to the des.
> 

Once the host/router ATMARP client determines that the destination is
reachable via the ATM network, then it checks the cache and if not
there, sends the ARP request packet to the ATMARP server. 

> Is there any misunderstanding(because of non-native English speaker)?
> Please let me know.
> 
> Thanks a lot.
> 
> Yu Ning
> ATM R&D Center of BUPT
> Beijing, P.R.C.
> email: [email-masked]
> 
> X-Info: To unsubscribe, email [email-masked]' with
> X-Info: 'unsubscribe ion' in the body of the message.

-- 
Schuster Consulting	
[email-masked]
(919) 831-9019
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: "Yu Ning" <[email-masked]>
Date: Mon, 12 Jan 1998 22:07:21 +0800

Hi friends,

Thanks a lot.

Yu Ning
ATM R&D Center of BUPT
Beijing, P.R.C.

---

From: Albert Manfredi <[email-masked]>
Date: Mon, 12 Jan 1998 14:21:30 -0500

> in the cache. Then, if not hit, it should send NHRP req to preconfigured

I think that use of a cached ATM destination address by the source
host is perfectly fine, as well as similar information cached within
the NHSs themselves, if that's what you're asking. The only
stipulation is that cached information be identified as
"non-authoritative," so that if a shortcut is not possible with this
information, the source knows that perhaps it's simply dealing with
obsolete information, and knows to try again, this time starting
from scratch. See the excerpt below.

   "A transit NHS receiving an NHRP Resolution Reply may cache the
   address resolution information contained therein.  To a
subsequent
   NHRP Resolution Request, this NHS may respond with the cached,
"non-
   authoritative" address resolution information if the NHS is
permitted
   to do so (see Sections 5.2.2 and 6.2 for more information on non-
   authoritative versus authoritative NHRP Resolution Replies). 
Non-
   authoritative NHRP Resolution Replies are distinguished from
   authoritative NHRP Resolution Replies so that if a communication
   attempt based on non-authoritative information fails, a source
   station can choose to send an authoritative NHRP Resolution
Request.
   NHSs MUST NOT respond to authoritative NHRP Resolution Requests
with
   cached information."

Also this:
 
   "NHRP optionally provides a mechanism to send a NHRP Resolution
Reply
   which contains aggregated address resolution information. For
   example, suppose that router X is the next hop from station S to
   station D and that X is an egress router for all stations sharing
an
   internetwork layer address prefix with station D.  When an NHRP
   Resolution Reply is generated in response to a NHRP Resolution
   Request, the responder may augment the internetwork layer address
of
   station D with a prefix length (see Section 5.2.0.1).  A
subsequent
   (non-authoritative) NHRP Resolution Request for some destination
that
   shares an internetwork layer address prefix (for the number of
bits
   specified in the prefix length) with D may be satisfied with this
   cached information."

> Is there any misunderstanding(because of non-native English speaker)?

I think that what you ask for is already implemented.

Bert
[email-masked]
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.