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
- Proposal of NHRP modifications Koichi Horikawa
- Re: Proposal of NHRP modifications James Luciani