Re: Latest NHRP draft
Bruce Cole <bcole@cisco.com> Thu, 25 May 1995 21:05 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08401;
25 May 95 17:05 EDT
Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US
id aa08397; 25 May 95 17:05 EDT
Received: (from root@localhost) by maelstrom.acton.timeplex.com
(8.6.12/ACTON-MAIN-1.2) id RAA01697 for rolc-out;
Thu, 25 May 1995 17:01:41 -0400
Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by
maelstrom.acton.timeplex.com (8.6.12/ACTON-MAIN-1.2) with ESMTP id RAA01692
for <rolc@maelstrom.Timeplex.COM>; Thu, 25 May 1995 17:01:37 -0400
Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by
greatdane.cisco.com (8.6.8+c/8.6.5) with ESMTP id OAA14935;
Thu, 25 May 1995 14:01:32 -0700
Message-Id: <199505252101.OAA14935@greatdane.cisco.com>
To: dhc2@gte.com
Cc: bcole@cisco.com, Robert.G.Cole@att.com, dkatz@cisco.com,
rolc@maelstrom.timeplex.com
Subject: Re: Latest NHRP draft
In-Reply-To: Your message of "Thu, 25 May 1995 16:29:05 EDT."
<9505252029.AA04417@minuteman.gte.com>
Date: Thu, 25 May 1995 14:01:31 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bruce Cole <bcole@cisco.com>
X-Orig-Sender: owner-rolc@maelstrom.timeplex.com
Precedence: bulk
X-Info: Submissions to rolc@maelstrom.timeplex.com
X-Info: [Un]Subscribe requests to rolc-request@maelstrom.timeplex.com
X-Info: Archives for rolc via
ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/
> Can you elaborate on how rate limiting would prevent > multiple VCs from occuring when the NHRP request goes through multiple > NHSs towards its destination. First: I was not arguing that rate limiting prevents multiple VCs in general. In this particular case, multiple VCs can be avoided through rate limiting. Specifically: router B receives an NHRP request from router A. Depending upon packet ordering, B may or may not have already received the original IP packet which A is trying to forward to D. If the original IP packet has not yet been received when B receives the NHRP request, then B may suppress sending an NHRP request of its own, to provide rate limiting. If the original IP packet came first, then B probably already sent an NHRP request of its own. When the NHRP packet from A comes along, B may then drop A's request due to rate limiting. C behaves similarly. End result is only 1 NHRP request to resolve, so only 1 VC is established. > Does this method guarantee that multiple VCs will not occur? No. > If the source has multiple NHRP requests within a short period of time, > would rate limiting affect the subsequent requests? Yes or no depending upon rate limiting policy. If the policy is to allow X NHRP packet within interval Y, then subsequent requests may or may not be dropped depending upon the values for X and Y.
- Latest NHRP draft Dave Katz
- Re: Latest NHRP draft Andrew Smith
- Re: Latest NHRP draft Robert G. Cole
- Re: Latest NHRP draft Bruce Cole
- Re: Latest NHRP draft Curtis Villamizar
- Re: Latest NHRP draft Robert G. Cole
- Re: Latest NHRP draft Bruce Cole
- Re: Latest NHRP draft Robert G. Cole
- Re: Latest NHRP draft Curtis Villamizar
- Re: Latest NHRP draft dhc2
- Re: Latest NHRP draft Bruce Cole