Proposal of NHRP modifications

Koichi Horikawa <horikawa@nwk.cl.nec.co.jp> Tue, 04 July 1995 09:38 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00933; 4 Jul 95 5:38 EDT
Received: from [204.249.96.18] by IETF.CNRI.Reston.VA.US id aa00929; 4 Jul 95 5:38 EDT
Received: from maelstrom.acton.timeplex.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id FAA16234; Tue, 4 Jul 1995 05:25:04 -0400
Received: (from root@localhost) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) id EAA20179 for rolc-out; Tue, 4 Jul 1995 04:41:44 -0400
Received: from nexen.nexen.com ([204.249.96.18]) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) with ESMTP id EAA20169; Tue, 4 Jul 1995 04:41:34 -0400
Received: from research.gate.nec.co.jp (research.gate.nec.co.jp [202.32.8.49]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id EAA15643; Tue, 4 Jul 1995 04:41:21 -0400
Received: from tomato.nwk.cl.nec.co.jp by research.gate.nec.co.jp (8.6.10+2.4W/941202) with SMTP id RAA04180; Tue, 4 Jul 1995 17:37:59 +0900
Received: by nwk.cl.nec.co.jp (5.65c/6.4JAIN-nwk-gw+2.1) id AA15068; Tue, 4 Jul 1995 17:37:53 +0900
Received: by lettuce.nwk.cl.nec.co.jp (8.6.12+2.4W/NWK-950509) id RAA24659; Tue, 4 Jul 1995 17:37:46 +0900
Date: Tue, 4 Jul 1995 17:37:46 +0900
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Koichi Horikawa <horikawa@nwk.cl.nec.co.jp>
Message-Id: <199507040837.RAA24659@lettuce.nwk.cl.nec.co.jp>
To: luciani@nexen.com, dkatz@cisco.com, dave@corecom.com
Cc: rolc@nexen.com
Subject: Proposal of NHRP modifications
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/

Hello, ROLCers,

I suggest some NHRP modifications described below.

a) NHRP should use two protocol numbers.

b) NHRP Purge packet should have "Sender's IP Address" field.

--

a) NHRP should use two protocol numbers
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
James Luciani <luciani@nexen.com> 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.

According to above, all stations which might have both client and
server must be assigned two IP addresses for themselves.

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.

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. 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.

So I suppose that the "different IP address approach" might not be so
good as described above.

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

- A client uses protocol number 54 to send NHRP packets to a
  server (as described in the draft).

- But A CLIENT USES OTHER PROTOCOL NUMBER THAN 54 (for example 55) TO
  RECEIVE NHRP PACKETS.

- A server uses protocol number 54 to receive NHRP packets from
  clients or other servers, and also to send NHRP packets to the
  other servers (as described in the draft).

- But A SERVER USES OTHER PROTOCOL NUMBER THAN 54 (for example 55) TO
  SEND NHRP PACKETS TO ANY CLIENTS.

These rules are applied to all clients and servers regardless of
whether the client and the server run on an identical host or not.

In this approach, there is no inconsistency on IP addresses described
above and we can distinguish perfectly which (server or client) should
handle an NHRP packet addressed to this host's IP address.

It is not possible to determine which (server or client on an
identical host) should handle a NHRP Reply packet received from a
common interface. The packet might have to be received by the client
directly, or might have to be received by the server once and
forwarded to the client on the same host. In the case of NHRP Error
Indication packet, as well.

So we have to implement some means to determine which (client or
server) should process the packet.


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).

- A sender of an NHRP Purge packet MUST set "Sender's IP Address"
  field to its IP address.

- A receiver MUST return the acknowledgement to the station whose IP
  address is the "Sender's IP Address".

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


What do you think?

Regards,
 ----------------------------------------------------------------------
                        Koichi Horikawa (^o^)
                     Network Research Laboratory,
                 C&C Research Laboratories, NEC Corp.
             FAX: +81-44-856-2230   TEL: +81-44-856-2123