Re: Proposal of NHRP modifications

[James Luciani <[e-mail]>]

Koichi,

> James Luciani <[e-mail]> said...
> 
> >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.
> >...
> >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.

 ... stuff deleted ...

Koichi Horikawa <[e-mail]> said...
> In the case of multi-server environment, a server might forward a NHRP
> Request packet to another server if it couldn't resolve an IP address
> within a local next-hop-address database. So the server must know the
> IP address of the next hop "server"(not that of the "client") to which
> the NHRP Request packet would be forwarded. If NHRP runs in "server"
> mode, there seems to be no problem because the information of the
> other servers could be just manually configured.

There is a problem.  How does a packet destined for IP@=X get demuxed to 
the client or server without a method to differentiae them?  There is no concept
of port as in TCP or UDP.  In any case, on page 6 section 2.2 the spec reads:
    :[Note: An NHRP reply can be returned directly to the NHRP request
    :initiator, i.e., without traversing the list of NHSs that forwarded
    :the request, if all of the following criteria are satisfied:
    :
    :  (a) Direct communication is available via datagram transfer
    :      (e.g., SMDS) or the NHS has an existing virtual circuit
    :      connection to the NHRP request initiator or is permitted
    :      to open one.
    :  (b) The NHRP request initiator has not included the NHRP
    :      Reverse NHS record Extension (see Section 5.7.5).
    :  (c) The authentication policy in force permits direct
    :      communication between the NHS and the NHRP request
    :      initiator.
    :
    :The purpose of allowing an NHS to reply directly is to reduce
    :response time.  A consequence of allowing a direct reply is that
    :NHSs that would under normal circumstances be traversed by the
    :reply would not cache next hop information contained therein.]

This means that the NHC (the initiator) must be distinct from the
NHS; which generally means that it should have its own IP address.

> However there seems to be a problem in the case of "fabric" mode. In
> order to obtain the next hop server's address information, stations
> where the servers run must exchange the "server"s' IP addresses since
> the IP addresses are necessary to forward NHRP Request packets to the
> other servers. 

There is no problem.  Servers "exchange" IP address information via normal
routing protocol exchange. See page 9 section 3 - Fabric Mode (the first 
paragraph of which is below):
    :"In "fabric" mode, it is expected that NHRP-capable routers are
    :ubiquitous throughout the NBMA subnetwork, and that NHSs acquire
    :knowledge about destinations other NHSs serve as a direct
    :consequence of participating in intradomain and interdomain routing
    :protocol exchange.  In particular, the NHS serving a particular
    :destination must lie along the routed path to that destination.  In
    :practice, this means that all egress routers must double as NHSs
    :serving the destinations beyond them, and that hosts on the NBMA
    :subnetwork are served by routers that double as NHSs."

> On the other hand, the IP address of the "client" must
> be registered because the upper layer on this station would recognize
> the "client"'s IP address as this station's IP address.
> 
> Then, who could register the "server"'s IP address which is different
> from that of "client"'s and how? It is possible that the address could
> be configured staticly, but that is NOT "fabric" mode.

Having multiple IP addresses per interface is not a problem; in BSD land
this means you have two or more in_ifaddr structures hung off an interface.
So both NHS and next hop client (NHC) addresses would be known to the router/NHS.
The router, as the spec says, is itself likely to be co-resident with the NHS
and, in this case, an NHC (all three of which could have separate IP addresses).

> 
> Then I suggest that "NHRP should use two protocol numbers". 
> 

I see no reason for this asymmetry when we can just assign separate 
IP addresses.  Also, what if you want to have more than one NHC in 
the same box with the NHS?  How would you tell for which NHC a packet 
was destined?

... stuff deleted ...

> b) NHRP Purge packet should have "Sender's IP Address" field
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> The draft says "The IP destination address of the Purge
> acknowledgement MUST be set to the IP source address of the Purge
> request" on Page 20.
> 
> According to above, the receiver of the NHRP Purge packet should get
> the IP destination address of the Purge acknowledgement from the
> header part of the IP packet which contains the NHRP Purge packet
> itself.
> 
> I suppose that some part of the receiver would be implemented on IP
> layer and should not depend on the lower layer's feature.
> 
> So I suggest that the NHRP Purge packet should have "Sender's IP
> Address" field (after/before "Source IP Address" field).

... stuff deleted ...

> Thus a receiver could determine where to send the acknowledgement even
> if it doesn't know IP layer's feature.

Why is it that a station forming a Purge Ack would not have access 
to the sender's IP address?  It seems to me that, regardless of what 
mechanism you use, that mechanism must give you a way to know 
what the sender's IP address is.  Otherwise, how do you know to whom 
you are talking at IP layer?  If you are implementing below IP or parallel
to IP (e.g., similar to the way ARP is done) then you still need to add the
IP header since NHRP is a protocol with an IP data point.  If you are
implementing above IP (e.g.,  NHC and NHS are actually above TCP or UDP
with a shim layer above IP that does the appropriate demux and reformat 
of the packet) then you still have access to the sender's address 
(e.g., via sockaddr struct in sockets or ?? the t_call structure in TLI??).
By the way, I am not for or against this addition; I just don't see why you 
are asking for it.


Regards,
-- Jim Luciani
__________________________________________________________________________
James V. Luciani    ascom nexion                    voice: [phone]
[e-mail]   289 Great Rd., Acton MA 01720   FAX: [phone]