Subject: (ION) [Q] request/reply procedure on NHRP

From: kim young yuk <[email-masked]>
Date: Tue, 31 Mar 1998 12:31:06 +0900

hi all...

Is there anyone who could make me clear on nhrp,
especially about a nhrp request/reply procedure

I have looked through a draft-ietf-rolc-nhrp-15.txt which is recently
issued ( expires June 1998 )
if i am wrong in my scenario of the procedure, just point me out what is
misunderstood ...

1. request procedure....( hop by hop procedure)

NHS which is serving a source NHC sends a nhrp request packet to next
hop (which is determined by a normal routing scheme such as rip, ospf).
Prior to do that action, the NHS adds its own address information to
mandatory part as a CIEs of the request packet.
and  a very next hop which received the packet will cache the previous
NHS's address information (this information is going to be used for a
reply packet to determine the next hop to the original source) then, the
NHS replaces the previous node's address information (CIEs) with its own
one in the packet.
this procedure is going on and on until the packet arrives at an NHS
which serves a destination.

the most important thing i mentioned here...  intermediate NHSs know the
previous NHS's address (NBMA address ,  Protocol address ), which is
going to be the next hop address on the reverse path when a reply packet
traces back to a source.

No need of routing decision of reply packet  so, much short time to wait
for a reply packet.

2. reply procedure (hop-by-hop procedure)

this procedure is quite easier than request procedure because most of
the job had done.
A NHS which servces a destination sends authoritative NHRP Resolution
reply packet to a next hop which is already known in its cache, thanks
to the request procedure.

Along the path, a transit NHS caches the address information (
destination's NBMA address and protocol ddress ) in the reply packet ,
then forwards a reply packet to the next hop, according to the cache
table without routing decision.

what i have to say here is there is no need of CIEs part  in the reply
packet.
<== my suggestion ..but , actually in the draft there are one or more
CIEs ....

Finally when reply packet arrives at the expectator( NHS ), then the
source ( NHC )  is trying to make a cut-through connection using a
destination's NBMA address.

so far, i described request/reply procedure according to the draft
mentioned above, and also add my suggestion  to the procedure....
i'm not quite sure it souds reasonable ...

your comments will be welcomed...

best ragards
young yuk Kim

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

---

From: srinies <[email-masked]>
Date: Wed, 01 Apr 98 11:11:00 PST

[ES>]  Even though Caching of the previous hop NHS addresses is done by   
the transit NHS's in the request path, it can not be used directly by the   
NHS in the reply phase for one reason. All the cache contains the   
mappings of the network address and NBMA address of the NHS, In the reply   
phase, a transit NHS has to make a routing decision based on the source   
address towards which the reply is being sent, which is necessary since,   
both your request and replies may travel different paths. Once NHS gets   
the next hop address for the destination address, it can look in its   
cache for the NMBA address and then forward the packet.
This is always better since the NHS which was operational in the request   
phase might be inoperational in the reply phase, but the mapping could   
still be valid in your cache . So if you send based on the cache mapping,   
you might end up in the wrong route. In this case, your routing protocol   
would have given some other next hop.

what i have to say here is there is no need of CIEs part  in the reply
packet
[ES>]  CIEs are necessary since they are the ones which gives mapping   
information to thew source NHC/source stations. I think, you got confused   
with the Reverse Transit and forward transit extensions. Both these   
things are necessary and have been providec for flexcibility. A source   
station may want either Fwd Transit Or Reverse Transit or Both.   
Necessary, incase, there is a change in the intermediate set of routers   
between the Fwd & Reverse path.

.

best ragards
young yuk Kim

//#####################################################//

       Srinivasan.E.S,
       Senior Software Engineer,
       Future Software Pvt Ltd,
       Chennai (Madras) -35.
       INDIA, (Pin:- 600 035)
       Ph :- +91 - 044 - 4330550.
                       [
                         MailTo:- [email-masked]
                                      [email-masked]
                       ]
//#####################################################//
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.