Re: NHRP protocol modifications and clarifications

[David Horton <[e-mail]>]

>There are a number of error conditions for which you just cannot test without a demux 
>mechanism.  If you get an error message, how do you intuit for whom it was sent?...  Lets say
>it is an error case of incorrect message type.

Can't you just look inside the returned erroneous packet that is 
enclosed in the error packet?

>
>What about the case when you have 2 or more NHCs which are co-resident with their NHS?  
>You can't figure out for whom the packet was sent in this case without burdening all 
>NHCs to check to their database.  Even then, it is not clear that you could resolve
>the who sent the request.

It seems to me that having multiple NHCs at a device, and each keeping
their own cache and request ID sequence is not in keeping with the spirit
of "Request ID" on page 14.  of the draft 4. i.e. each NHC can send 
requests for the same target address when there is an implication 
that the device should be conservative in how many requests  it sends.
Further each NHC has to register with the NHS. This will lead to
larger caches with multiple entries for the 'same' device (as 
identified by ATM address). Also aren't we trying to conserve IP addresses
these days.

>
>I have received several notes saying that others have run into this problem and have 
>either done what I suggested or used another form of demux (usually complex as opposed to 
>something as simple as a separate IP address).  

I am not sure that all OS will support multiple IP addresses on 
one interface. 

We are exploring various options on our prototype
with regards to flexibility, efficiency and deployability.
We currently use a separate protocol number for clients to listen to.
This means that a NHS has to know the type of peer it is talking to,
and is not compliant with the spec as it stands. However it
is not expensive in execution nor configuration nor coding time.
Another option we considered was having clients slaved to the server on a 
device.  This was compliant, but had limitations with performance and
reliability where a NHC required access to multiple NHS.

:
:

>I think it is much cleaner administratively to have one IP addresses for each NHS and NHC.  
>Also, let's keep in mind this is only an issue when they are co-resident.

IMHO, this is an implementors problem, not a true protocol problem. 
Suggestions made recently seem to reflect particular implementations
and what is easiest in them. (Including our own).

The de-muxing within the device is the job of the local device 
software since all the 'required' information is in the packet. Perhaps
NHRP is not yet as tightly integrated with the Unix OS as 
ethernet ARP, and UDP and that is what is causing the problem.

(I can't resist fiddling with the protocol either, so here is another hack).
Perhaps a local 'port' number could be added to the protocol to 
make it easier to have multiple NHRP entities on a device.
This port number would be an adjunct to  the source client, 
NHS and responder to allow the protocol to carry some local identification.
The NHRP spec would additionally have to indicate when these are copied (e.g. request->reply, request->purge and purge->purge ack).
However the 'other' side of the client/server should not try
to make any meaning of the value.
This could give an implementation the freedom to dispatch packets
to local entities based on the port, or to completely ignore the value
if their particular implementation was designed to have only the 
one NHRP entity per device.
I know there are problems with this model too, e.g. in the case where 
a particular local client goes away and an NHS sends purge 
packets specifically to that client.


>- -- Jim Luciani

regards,
David


- -------------------------------------------------------------------
David Horton
Centre for Information Technology Research
University of Queensland, 4072
Australia

Email: [e-mail]           Phone [phone]     Fax [phone]