[Ospf-wireless-design] OSPF Flooding and Higher Mobility
Acee Lindem <acee@cisco.com> Fri, 04 November 2005 21:03 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 1EY8iw-0003NE-Rz; Fri, 04 Nov 2005 16:03:46 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY8YW-0001WE-LA for ospf-wireless-design@megatron.ietf.org; Fri, 04 Nov 2005 15:53:00 -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 PAA12943 for <ospf-wireless-design@ietf.org>; Fri, 4 Nov 2005 15:52:36 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY8nX-0002C1-IF for ospf-wireless-design@ietf.org; Fri, 04 Nov 2005 16:08:35 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 04 Nov 2005 12:52:48 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA4KqCOH002439 for <ospf-wireless-design@ietf.org>; Fri, 4 Nov 2005 12:52:46 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 12:52:43 -0800
Received: from [10.21.90.69] ([10.21.90.69]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 12:52:41 -0800
Message-ID: <436BCA18.2000102@cisco.com>
Date: Fri, 04 Nov 2005 15:52:40 -0500
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ospf-wireless-design@ietf.org
Content-Type: multipart/mixed; boundary="------------050702070908000303020601"
X-OriginalArrivalTime: 04 Nov 2005 20:52:41.0499 (UTC) FILETIME=[B2B256B0:01C5E181]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 871367014a9fe468a1d3cdefa3a481eb
X-Mailman-Approved-At: Fri, 04 Nov 2005 16:03:44 -0500
Cc:
Subject: [Ospf-wireless-design] OSPF Flooding and Higher Mobility
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
Based on the INRIA reports and attendant E-mail threads, we (Cisco) have recently gone down the path of doing some simulations with higher mobility. The attached spread sheets show the results for 16 m/sec velocity and varying radio range. The pause time is still 40 seconds. We found the results to be more drastic with a smaller pause time but had some problems getting a complete set of runs. MPRs have the following improvements over the base provided with GTNetS: - Smart Peering is fixed to avoid instability by running a second SPF to determine if a potential peer is available via a real adjacency or unsynchronized adjacency. The adjacency is only suppressed in the case of connectivity to the SPT via real adjacencies. This is discussed in the Boeing report but wasn't implemented. Also, we have enabled promiscuous LSA caching enabled with the LSA cache timeout extended to 100 seconds. We are attempting to get some runs with this disabled as well some with a shorter pause time. For MDRs we used the standard bi-connected topology. We will provide the diffs for the code changes supporting smart peering. We have also been investigating using the MDR strategy of reducing adjacencies by taking advantage of the flooding topology. However, doing this effectively is more complex than it first seemed. Stan Ratliff, a Cisco Software Engineer, will be presenting these results. Thanks and Sorry for the Short Notice, 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