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.