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