Acknowledgment of registration requests
James Luciani <luciani@nexen.com> Wed, 13 September 1995 02:19 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21239;
12 Sep 95 22:19 EDT
Received: from nexen.nexen.com by IETF.CNRI.Reston.VA.US id aa21235;
12 Sep 95 22:19 EDT
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by
nexen.nexen.com (8.6.12/8.6.12) with ESMTP id WAA13924;
Tue, 12 Sep 1995 22:05:40 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id
VAA21173 for rolc-out; Tue, 12 Sep 1995 21:51:43 -0400
Received: from shovel.nexen.com (shovel.nexen.com [204.249.98.39]) by
maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id VAA21164 for
<rolc@nexen.com>; Tue, 12 Sep 1995 21:51:40 -0400
Received: from localhost (luciani@localhost) by shovel.nexen.com
(8.6.12/8.6.12) with SMTP id VAA03546; Tue, 12 Sep 1995 21:51:38 -0400
Message-Id: <199509130151.VAA03546@shovel.nexen.com>
To: rolc@nexen.com
cc: luciani@nexen.com
Subject: Acknowledgment of registration requests
Date: Tue, 12 Sep 1995 21:51:38 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: James Luciani <luciani@nexen.com>
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/
Folks,
I'd like to suggest a few simplifications to NHRP which in addition to
simplifying the protocol would also more closely align it with other
protocols such as RFC1577 and MARS.
I would like to remove the register packet which does not currently have
an acknowledgment. In its place, I would suggest having the given client
make a request for itself in the same way that 1577 clients do (that
is SA=DA=client address) and the reply would serve as the acknowledgment.
This solves the ACK problem, removes the need for another packet format,
and may make it easier to reuse existing code from Classical IP.
It would also be nice to align the Request and Reply packet types
(with the exception of the multiple potential responses) to look the same
so that there is only one form of packet to parse for request, reply,
and register. The cost for this is 32 bits of "next hop address" which
would then be an unused field in the request packet.
Thus the packet format and text would then be as follows:
=============================================================================
5.2 NHRP Request
The NHRP Request packet has a Type code of 1. The NHRP Request packet
is used to register a client with the clients NHS by making a request for
itself. This is done by setting the source address equal the destination
address (which also equals client address) and the reply received serves
as the acknowledgment for the registration.
The Mandatory Part has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|S|A|P|B| Unused | Protocol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(IPv4-Specific)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holding Time | Address Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused | NBMA Length | NBMA Address (variable length)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
etc.......
The Request packet may be used to register a station's IP and NBMA addresses
with its neighboring NHSs. This is done by specifying both the source and
destination address to be the client's address. Registering a clients
address with its NHS allows the amount of static configuration
information to be reduced; the NHSs need not be configured with the
identities of all of the stations that they serve.
It is possible that a misconfigured station will attempt to register
with the wrong NHS (i.e., one that cannot serve it due to policy
constraints or routing state). If this is the case, the NHS MUST
reply with an Error Indication of type Can't Serve This Address.
If an NHS cannot serve a station due to a lack of resources, the NHS
MUST reply with an Error Indication of type Registration Overflow.
In order to keep the registration entry from being discarded, the
station MUST re-register often enough to refresh the entry. It is
recommended that the re-registration be sent at an interval equal
to one-third of the Holding Time specified therein.
5.3 NHRP Reply
The NHRP Reply packet has a type code of 2. The NHRP Reply packet also
serves to acknowledge the registration of a client with its server
That occurs when the request received has the source address equal
to the destination address.
The Mandatory Part has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|S|A|P|B| Unused | Protocol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(IPv4-Specific)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holding Time | Address Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | NBMA Length | NBMA Address (variable length)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holding Time | Address Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | NBMA Length | NBMA Address (variable length)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
etc...
The Request packet may be used to register a station's IP and NBMA addresses
with its neighboring NHSs. This is done by specifying both the source and
destination address to be the client's address. This registration is
acknowledged by sending a Reply packet in response to the Request packet.
It is possible that a misconfigured station will attempt to register
with the wrong NHS (i.e., one that cannot serve it due to policy
constraints or routing state). If this is the case, the NHS MUST
respond with an Error Indication of type Can't Serve This Address not
simply with a NAK.
If an NHS cannot serve a station due to a lack of resources, the NHS
MUST respond with an Error Indication of type Registration Overflow and
not simply with a NAK.
- Acknowledgment of registration requests James Luciani
- Re: Acknowledgment of registration requests Mark Laubach