Re: [Ospf-wireless-design] OSPF Flooding and Higher Mobility

Richard Ogier <rich.ogier@earthlink.net> Tue, 08 November 2005 00:08 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZH2T-00032C-G2; Mon, 07 Nov 2005 19:08:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZH2S-00031u-Db for ospf-wireless-design@megatron.ietf.org; Mon, 07 Nov 2005 19:08:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23411 for <ospf-wireless-design@ietf.org>; Mon, 7 Nov 2005 19:08:10 -0500 (EST)
Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZHI7-00076R-KY for ospf-wireless-design@ietf.org; Mon, 07 Nov 2005 19:24:50 -0500
Received: from dialup-4.243.134.188.dial1.sanfrancisco1.level3.net ([4.243.134.188] helo=earthlink.net) by pop-canoe.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EZH2H-00050x-00; Mon, 07 Nov 2005 19:08:25 -0500
Message-ID: <436FEC76.1020403@earthlink.net>
Date: Mon, 07 Nov 2005 16:08:22 -0800
From: Richard Ogier <rich.ogier@earthlink.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202)
X-Accept-Language: en-us
MIME-Version: 1.0
To: Acee Lindem <acee@cisco.com>
Subject: Re: [Ospf-wireless-design] OSPF Flooding and Higher Mobility
References: <77F357662F8BFA4CA7074B0410171B6DC9E60E@XCH-NW-5V1.nw.nos.boeing.com> <436EB634.1000200@cisco.com> <436EBC7D.5030407@earthlink.net> <436FE92E.8020309@cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Content-Transfer-Encoding: 7bit
Cc: ospf-wireless-design@ietf.org
X-BeenThere: ospf-wireless-design@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: OSPF Wireless Design Team <ospf-wireless-design.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf-wireless-design>, <mailto:ospf-wireless-design-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <https://www1.ietf.org/mailman/private/ospf-wireless-design>
List-Post: <mailto:ospf-wireless-design@lists.ietf.org>
List-Help: <mailto:ospf-wireless-design-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf-wireless-design>, <mailto:ospf-wireless-design-request@lists.ietf.org?subject=subscribe>
Sender: ospf-wireless-design-bounces@lists.ietf.org
Errors-To: ospf-wireless-design-bounces@lists.ietf.org

Acee,

Thanks for your answers.  I was about to send out the following
related message.

I took a closer look at Cisco's simulation results.  Below are the
UDP sends/receives/forwards for 50 nodes, for MDRs and for MPRs.
The most important thing to notice is that the number of UDP forwards
for MPRs is MUCH larger than for MDRs, even though the number of UDP
receives is slightly larger for MDRs.
For example, for 160m, the number of UDP forwards is 3.75 times as
large for MPRs.  This means that the paths computed for MPRs are
much longer than those computed for MDRs.

MDR 50 nodes
------------
Stat/Radio Range        100m    120m    140m    160m    180m    200m
----------------                --------------------------------------------
UDP sends (pkts)        8927    8964    8927    8927    8927    8964
UDP receives (pkts)        4076    5697    6205    6803    7360    7767
UDP Forwards (pkts)        12185    9968    9038    7498    6310    5047

MPR 50 nodes
------------
Stat/Radio Range        100m    120m    140m    160m    180m    200m
----------------                --------------------------------------------
UDP sends (pkts)        8927    8927    8927    8927    8927    8927
UDP receives (pkts)        3446    4839    5697    6262    6964    7436
UDP Forwards (pkts)        40694    30503    26808    28110    22401    
10627


I'm not sure why there is such a big difference in path length,
but it probably means that MDR is advertising more neighbors
in LSAs than MPR. (Maybe MPR is advertising only adjacent neighbors?)
It would be better to compare the two methods using comparable
LSAs that both provide min-hop paths.

In any case, because of the much longer paths obtained with the MPR
method, not much can be concluded from the results.
Also, as Phil pointed out, the number of LSAs out of sync
is much greater for MPRs, which needs to be investigated.

Richard



Acee Lindem wrote:

> Hi Richard,
>
> See below.
>
> Richard Ogier wrote:
>
>> Acee,
>>
>> Can you answer my questions below?
>>
>> Thanks,
>> Richard
>>
>>> In the simulations for Smart Peering, what neighbors were included in
>>> the router-LSAs?  If only adjacent neighbors were included,
>>> then that could explain the lower overhead obtained for Smart Peering,
>>> and would also result in highly suboptimal paths
>>> (much longer than shortest paths).  That is why simulation
>>> results are not very meaningful unless other measures such
>>> as average path length and delivery ratio are also presented.
>>> (The average path length can be obtained from the numbers of UDP
>>> packets sent/forwarded/received, but I did not see those numbers.)
>>
>>
> All routable neighbor are advertised.
>
>
>>>
>>> Also, since Cisco is running SPF twice, once for real adjacencies
>>> and once for all acceptable links, I would like to know how
>>> a router knows which non-local links are real adjacencies.
>>> Does the LSA somehow indicate this?  
>>
>>
> A U bit is defined in the unused 8 bits in the LSA link.
>
>>> Is a different Link State ID
>>> used for real adjacenies versus non-adjacencies?
>>
>>
> Nope.
>
>>
>>
> Thanks,
> Acee
>
>



_______________________________________________
Ospf-wireless-design mailing list
Ospf-wireless-design@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ospf-wireless-design