possible enhancement to NHRP
Yakov Rekhter <yakov@cisco.com> Tue, 11 July 1995 22:58 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19613;
11 Jul 95 18:58 EDT
Received: from [204.249.96.18] by IETF.CNRI.Reston.VA.US id aa19609;
11 Jul 95 18:58 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 SAA09574;
Tue, 11 Jul 1995 18:44:53 -0400
Received: (from root@localhost) by maelstrom.acton.timeplex.com
(8.6.12/8.6.12) id SAA13285 for rolc-out; Tue, 11 Jul 1995 18:43:05 -0400
Received: from nexen.nexen.com ([204.249.96.18]) by
maelstrom.acton.timeplex.com (8.6.12/8.6.12) with ESMTP id SAA13275 for
<rolc@nexen.com>; Tue, 11 Jul 1995 18:43:02 -0400
Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by
nexen.nexen.com (8.6.12/8.6.12) with ESMTP id SAA09543 for <rolc@nexen.com>;
Tue, 11 Jul 1995 18:43:01 -0400
Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by
puli.cisco.com (8.6.8+c/8.6.5) with SMTP id PAA09096;
Tue, 11 Jul 1995 15:41:15 -0700
Message-Id: <199507112241.PAA09096@puli.cisco.com>
To: rolc@nexen.com
Cc: bcole@cisco.com
Subject: possible enhancement to NHRP
Date: Tue, 11 Jul 95 15:39:50 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Yakov Rekhter <yakov@cisco.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, Appended is a short draft that proposes a possible enhancement to NHRP. Your comments are welcomed. Yakov&Bruce. ----------------------------------------------------------- NHRP Request for Address Prefix The current format of NHRP Request allows the request to carry a complete destination IP address. This may be sufficient for the host-router, router-host, and host-host applications of NHRP, but imposes certain limitations on the use of NHRP for the router-router case. One could imagine a scenario where a router monitors usage of its routes (how many pkt/secs were forwarded via each route), and when the usage of a route exceeds a certain threshold the router originates an NHRP Request to discover a short-cut for all the destinations covered by the route. This would require an NHRP Request to carry not just an IP address, but an address prefix as well. If the ability to carry address prefix in NHRP Request is supported, then one interesting question is how a router that receives such a request handles it when the prefix carried in the request is formed by the router (as a result of some aggregation). Sending all the individual components (that formed the aggregate) may be one alternative. The originator, when it receives the components, may re-issue NHRP Requests for individual components. However, the number of components may be potentially quite large, which may be a problem. Alternatively, the router may send back just an NHRP Response that contains the original prefix. This avoids the issue of handling a large number of components. However, this also may preclude the ability to establish a 1 hop short-cuts in presence of routing information aggregation.
- possible enhancement to NHRP Yakov Rekhter