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.