James Luciani <luciani@nexen.com> Wed, 25 October 1995 16:10 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13129; 25 Oct 95 12:10 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa13125; 25 Oct 95 12:10 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id LAA15261; Wed, 25 Oct 1995 11:37:28 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id LAA24800 for rolc-out; Wed, 25 Oct 1995 11:45:52 -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 LAA24786 for <rolc@nexen.com>; Wed, 25 Oct 1995 11:45:47 -0400
Received: from localhost (luciani@localhost) by shovel.nexen.com (8.6.12/8.6.12) with SMTP id LAA05466; Wed, 25 Oct 1995 11:45:15 -0400
Message-Id: <199510251545.LAA05466@shovel.nexen.com>
To: rolc@nexen.com
cc: luciani@nexen.com
Date: Wed, 25 Oct 1995 11:45:15 -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 am looking at the new NHRP which does not contain layer 3 encapsulation and 
I'd like to make some modifications regarding the Error and Purge packets.
  It is difficult to justify the need for an acknowledgement for a purge 
when there are timers to age out entries.  I would like to suggest that a purge 
become a unidirectional request and there be no acknowledgement.  At best, 
a purge is an optimization in this scenario. I would not, for example, keep 
a station around that is going off-line merely to time out and retry a purge 
if I do not get an ack.  It is also desirable to have the source ATM address 
in the packet since this will make sure that the purge comes back to exactly the 
original requester's interface.  
  When the IP encapsulation was dropped, there became no easy way to send 
an error packet back to its originator and it became impossible to tell from
where an error packet originated.  It is possible to extract return information
from the information in the packet which is in error but this is somewhat 
cumbersome.  Also, errors type 6 and 7 do not seem to make sense any longer in 
a world without server mode and there is no accompanying text in the spec.  
As a result, I suggest they be deleted unless someone generates a use.
  Given the above suggestions the purge packet and error packet would 
look like the following:
===============================================================================
5.4 NHRP Purge

   The NHRP Purge packet has a type code of 4.  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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Unused    | Proto Length  |         Protocol ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Protocol ID (Cntd)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Request ID                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                               (IPv4-Specific)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Destination IP Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Source IP Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Unused              | Source NBMA Address Type      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Unused      |  NBMA Length  | Source NBMA Address (variable)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Proto Length
     This is the length of the internetwork layer protocol address.

   Protocol ID
     Specifies the internetwork layer protocol for which a Error packet
     is being sent.  This value also qualifies the structure of the 
     remainder of the Mandatory Part.  For IPv4, the Protocol ID 
     is hexadecimal 800 (decimal 2048).  Protocol ID values
     for other internetwork layer protocols are for future study.

   Request ID
     Copied from the corresponding NHRP Request.  This is used by the
     station receiving the purge to unambiguously identify which cache
     entry to purge.  If set to zero, this packet is a packet sent from
     a client to its NHS in order to de-register the client (e.g., when
     the client is about to go down and wants to do so gracefully).


   Destination IP Address
     The address of the target station (as if copied from the original
     NHRP address resolution Request).  This field holds the address 
     of the client whose routing information has (or is about to be) 
     changed.

     In the case when the purge request comes from a client,
     this is the address of the client.  In this case, when the NHS 
     receives the purge its removes its entry for that client.  The 
     NHS then initiates a purge request to each station which 
     requested address resolution information for that client.

     In the case when the NHS notices a change in routing information 
     for a client which has registered with it, the NHS removes its 
     entry for that client.  It then creates a purge packet in which 
     the Destination IP Address field is set to the address of the client.
     The NHS then initiates a purge request to each station which 
     requested address resolution information for that client.

   Source IP Address
     In the case when the purge request comes from a client, this field
     contains the address of the client.

     When a client sends a purge request to its NHS, the NHS removes the
     client's entry from the NHS's cache.  The NHS then initiates a 
     purge request to each station which requested address resolution 
     information for that client.

     When an NHS initiates a purge (as a result of a client's request
     or as a result of noticing a routing change), the Source IP Address 
     field contains the address of the initiator of an NHRP address 
     resolution Request.

   Source NBMA Address Type
     The Source NBMA Address Type field specifies the type of Source 
     NBMA address (qualifying the NBMA address).  Possible address 
     types are listed in [6].

   NBMA Length
     The NBMA Length field is the length of the NBMA address of the
     source station in bits.  

   Source NBMA Address

     The Source NBMA Address field is the NBMA address corresponding
     to the Source internetworking layer address (e.g., the NBMA address
     corresponding to the Source IP Address).
     This field is zero-filled to the nearest 32-bit boundary.

   An NHRP Purge request packet is sent from an NHS to a station to
   cause it to delete previously cached information.  This is done when
   the information may be no longer valid (typically when the NHS has
   previously provided next hop information for a destination that is
   not directly connected to the NBMA subnetwork, and the egress point
   to that destination may have changed).

   An NHRP Purge request packet may also be sent from a client to an NHS
   with which the client had previously registered.  This allows for a
   client to invalidate its NHRP registration before it would otherwise 
   expire.  In this case, the Request ID field is ignored, and should 
   be zero-filled.
   
   When a station receives an NHRP Purge request, it MUST discard any
   previously cached information that matches the Source Address and
   Request ID (when the Request ID is zero filled the match is made
   based only on the Source Address).

   If a station receives a purge request when it does not contain a cache
   entry for the client being purged, the receiving station MUST silently
   discard the packet.

   If the station wishes to reestablish communication with the
   destination shortly after receiving a Purge request, it should make
   an authoritative request in order to avoid any stale cache entries
   that might be present in intermediate NHSs.  (See section 6.2.2.)  It
   is recommended that authoritative requests be made for the duration
   of the holding time of the old information.


5.5  NHRP Error Indication

   The NHRP Error Indication is used to convey error indications to the
   initiator of an NHRP Request packet.  It has a type code of 5.  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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Unused    | Proto Length  |         Protocol ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Protocol ID (Cntd)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Error Code          |        Error Offset           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                               (IPv4-Specific)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Destination IP Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Source IP Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Unused              | Source NBMA Address Type      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Unused      |  NBMA Length  | Source NBMA Address (variable)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+  Contents of NHRP Packet in error +-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Proto Length
     This is the length of the internetwork layer protocol address.

   Protocol ID
     Specifies the internetwork layer protocol for which a Error packet
     is being sent.  This value also qualifies the structure of the 
     remainder of the Mandatory Part.  For IPv4, the Protocol ID 
     is hexadecimal 800 (decimal 2048).  Protocol ID values
     for other internetwork layer protocols are for future study.

   Error Code
     An error code indicating the type of error detected, chosen from
     the following list:

       1 - Unrecognized Extension
           When the Discretionary bit of an extension is clear (equal to,
           zero) the NHRP request cannot be satisfied unless the extension 
           is processed, so THE responder MUST return an Error Indication 
           of type Unrecognized Extension.  However, if a transit NHS (one 
           which is not going to generate a reply) detects an unrecognized 
           extension, it SHALL ignore the extension.

       2 - Subnetwork ID Mismatch
           This error occurs when the current station receives a packet from
           NBMA subnet which is different from that specified in the 
           NBMA Subnetwork ID Extension of the packet.

       3 - NHRP Loop Detected
           This error occurs when a loop has been detected while using NHRP
           to perform address resolution.

       4 - Can't Serve This Address
           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.

       5 - Registration Overflow
           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.

       8 - NHRP SDU Size Exceeded
           If the SDU size of the NHRP packet exceeds the MTU of the routed path
           this error is returned.
           
       9 - Invalid Extension
           If an NHS finds an extension in a packet which is inappropriate for
           the packet type, an error is sent back to the sender with Invalid 
           Extension as the code.

       10- Invalid Reply Received
           If a client receives a reply for a request it believes it did not
           make then an error packet is sent to the station making the reply
           with an error code of Invalid Reply Received.

   Error Offset
     The offset in octets into the original NHRP packet, starting at the
     NHRP Fixed Header, at which the error was detected.

   Destination IP Address
     The IP address of the station sending the error message.

   Source IP Address
     The IP address of the station that sent the packet which is in error.
  
   Source NBMA Address Type
     The Source NBMA Address Type field specifies the type of Source 
     NBMA address (qualifying the NBMA address).  Possible address 
     types are listed in [6].

   NBMA Length
     The NBMA Length field is the length of the NBMA address of the
     Source NBMA Address in bits.
     If this field is set to zero then the packet is directed toward any 
     interface associated with the Source IP Address (e.g., the reply will
     not necessarily carry the NBMA address of the replying station).

   Source NBMA Address
     The NBMA address of the station that sent the packet which is in error.
     This field is zero-filled to the nearest 32-bit boundary.

   An Error Indication packet SHALL NEVER be generated in response to
   another Error Indication packet.  When an Error Indication packet is
   generated, the offending NHRP packet SHALL be discarded.  In no case
   should more than one Error Indication packet be generated for a
   single NHRP packet.



Regards,
-- Jim Luciani
__________________________________________________________________________
James V. Luciani    ascom nexion                    voice: +1 508 266-4522
luciani@nexen.com   289 Great Rd., Acton MA 01720   FAX: +1 508 266-2300
  •   James Luciani