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
- [Ospf-wireless-design] OSPF Flooding and Higher M… Acee Lindem
- Re: [Ospf-wireless-design] OSPF Flooding and High… Richard Ogier
- RE: [Ospf-wireless-design] OSPF Flooding and High… Spagnolo, Phillip A
- Re: [Ospf-wireless-design] OSPF Flooding and High… Acee Lindem
- RE: [Ospf-wireless-design] OSPF Flooding and High… Alvaro Retana
- RE: [Ospf-wireless-design] OSPF Flooding and High… Henderson, Thomas R
- Re: [Ospf-wireless-design] OSPF Flooding and High… Acee Lindem
- Re: [Ospf-wireless-design] OSPF Flooding and High… Acee Lindem
- RE: [Ospf-wireless-design] OSPF Flooding and High… Henderson, Thomas R
- Re: [Ospf-wireless-design] OSPF Flooding and High… Acee Lindem
- Re: [Ospf-wireless-design] OSPF Flooding and High… Richard Ogier
- Re: [Ospf-wireless-design] OSPF Flooding and High… Acee Lindem
- Re: [Ospf-wireless-design] OSPF Flooding and High… Richard Ogier
- Re: [Ospf-wireless-design] OSPF Flooding and High… Richard Ogier
- [Ospf-wireless-design] Smart Peering draft update Abhay Roy