NHRP protocol modifications and clarifications

[James Luciani <[e-mail]>]

ROLCers,

  In developing NHRP, I have come up with a few proposals for protocol
changes and a few clarifications I'd like to see in the draft.

1) The client and server, even in the same box, should have different IP addresses
otherwise there is no easy way to differentiate where received messages should go.

On p. 11, it already says that "An NHS is configured with its own identity ...".

This statement does not preclude a co-resident client from having the same 
IP address and might also imply that both a different layer 3 address and 
different NBMA address need to be allocated to server an client.
A separate NBMA address is not necessary in this case.

I suggest we add the following on p. 11, as the last paragraph in Section 4:

Even if an NHRP client (NHC) and an NHS are co-resident in the same
physical box, they must each be configured with different IP
addresses, so that incoming NHRP messages can be delivered to the
proper entity.  If the box has only one ATM physical interface, this
requires the ability to configure more than one IP address on the same
interface.

2) The NHRP Purge packet currently has two fields of interest: the Source
Address, and the Request ID, which is matched to the corresponding
NHRP request from that particular source.  When a source receives a
Purge packet, it must then search its cache to find the entry with the
matching Request ID.  This is the only time that the cache must be
searched using the Request ID.  Unless you build an index of request
IDs as a part of the cache, this can potentially be an expensive
search.  And the Purge is probably something you won't see unless
things are already going wrong and you really need those cycles
elsewhere ...

I would like to propose adding the Destination Address to the Purge
packet format, using the same exact syntax as the Request and Reply
packets (Request ID, Destination Address, and Source Address, in that
order).  That way, an implementation only has to search on, and index,
one field, the Destination Address, which you already have to be able
to quickly search on anyway.


3) Responder address extension and prefix extension are requested differently
than reverse and forward NHS record extension: in the former two, the responder
address is set to zero and the length is fixed at four bytes while the 
latter two record extensions have length set to zero and no data is present.  
A consistent approach saves code.  Basically, it is desirable to have a 
single method of dealing with TLV entries (in this case, "extensions")
when one is developing parsers and the state machines that use them.

Actually, the most general thing to do is to make the
responder address extension and prefix extension protocol independent,
using the same coding as the record extension.  It's less efficient,
but more general.

4) If an NHS finds an extension in a packet for a given type when that type of 
packet is not supposed to have that extension what is supposed to happen?  
send error message? if send error message then none of the errors is really 
appropriate:
       1) unrecognized extension - this is not necessarily true.. in fact the 
          idea above is generated from the case where the extension is 
          recognized but should not be there
       7) protocol error - well... kinda... I think of this as having 2 extensions
          of the same type though (which is a no no) or you receive a reply
          when you never sent a request (see this point later).

Of the two, I think Protocol Error fits the bill best, especially when combined
with the Error Offset to point to the incorrect extension.

I would prefer to see an error code "9 - invalid extension" which would be added 
to the list on page 21.   

And in part 5.7 a statement would be placed saying:

"In the event that an NHRP packet is received which has an extension which is
incorrect for the packet type (e.g., Register packet with a 'prefix extension')
then an error indication will be returned with error code 9 - invalid extension."

5) A protocol mechanism is needed for client to send purge to server because it 
is going offline... i.e., it wants a graceful death.  The semantics of this
would propagate to purge being sent to all those stations which received
an address resolution (just like if the NHS had initiated it).
I am suggesting no packet modification at this point other than to allow a 
client to send a purge for itself to its server(s).  If it is deemed necessary
to differentiate when a client initiates a purge for itself or an NHS sends
a purge (as a result of a topology change or whatever) then a "C" bit could be
used (as in C=1=> client initiated) which would be located immediately after
the "A" bit in the purge packet.

The text on page 20 would be augmented to read:

"An NHRP Purge request packet MAY also be sent from an NHC to the NHS with 
which it registered.  This packet is then sent to a station to
cause it to delete previously cached information. This is done 
when a NHC is leaving the net and wants to propagate this fact
to any station that might have cached the NHC's next hop information.

6) Extensions should be in numerical order to facilitate parsing.  The spec 
says it need not be. You cannot have 2 extensions of the same type in the same
packet so you need to keep track of exactly which TLVs you have seen already.
This is not a problem when there are only 8 of them but when we have 
multiprotocol on L3 and L2 we might see this number balloon somewhat quickly 
as we deal with the multitude of special case extensions.  Further, in the
vast majority of cases there will not be many extensions since certainly
code will be optimized for the "fast path" in the same way that IP has been
optimized for the case where there are no options.  This point is primarily
for extensibility.  If the extensions are in order, the only additional state
that is needed is the number of the previous extension type rather than the set
of all types already parsed (which IS necessary to prevent redundant extensions
from being passed if the extensions are not in order).

7) Prefix Length Extension should be followed by a 24 bit unused field because
"Each extension is padded with zero octets to a 32 bit boundary."

8) What do we do when we receive a reply when no request seems to have been
sent?  We probably don't want to cache the data for a number of reasons.
We might want to send an error message but what kind of error?  Protocol error?

I would like to see this stated explicitly in the REPLY section (5.3) and in the 
ERROR Indication section (5.6).
I would suggest something like:

"In the event that a reply is received when no request seems to have been
sent, an error indication packet is sent with error code 10 - Invalid Reply 
Received."