From ospf-manet-bounces@ietf.org Mon Mar 05 11:45:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOGJh-0007L5-Cj; Mon, 05 Mar 2007 11:45:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOGJf-0007Ky-OW for ospf-manet@ietf.org; Mon, 05 Mar 2007 11:45:39 -0500 Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOGJR-0005af-0P for ospf-manet@ietf.org; Mon, 05 Mar 2007 11:45:39 -0500 Received: from dialup-4.245.100.190.dial1.sanjose1.level3.net ([4.245.100.190]) by pop-savannah.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1HOGJO-000103-00 for ospf-manet@ietf.org; Mon, 05 Mar 2007 11:45:23 -0500 Message-ID: <45EC4923.2000600@earthlink.net> Date: Mon, 05 Mar 2007 08:45:23 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ospf-manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Subject: [Ospf-manet] Re: Regarding OSPF MDR X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org All, I ran some simulations using the modified min-cost LSA algorithm that is described in the updated MDR draft draft-ogier-manet-ospf-extension-09.txt (submitted yesterday). I announced plans to modify the min-cost LSA algorithm a few months ago, so this update is not in response to Philippe's recent comments regarding the old version. However, the new min-cost LSA algorithm does address some of Philippe's recent comments, for example: o Neighbor advertisements are symmetric: if a neighbor j advertises router i, then router i advertises neighbor j. o The updated min-cost LSA algorithm uses only information from Hellos received from neighbors, and no longer uses LSAs from neighboring routers. There is nothing wrong with using LSAs, except that using both Hellos and LSAs adds complexity, so this was done to keep the algorithm simple. o All links have the same cost; no penalty is added to the cost of links to neighbors that are not fully synchronized. This is not really a change, since routers still have the option of adding such as penalty, but I wanted to avoid any possible claims of unfairness. One criticism that Philippe might still have is that the algorithm requires O(d^3) time if run from scratch. However, it requires only O(d^2) time for a single topology change, so I think this is acceptable, since a router rarely needs to run the algorithm from scratch. I am still open to the possibility of using LSA reduction based on the "path-MPR" approach, since this can indeed reduce the size of LSAs as Philippe claims. However, based on the results for delivery ratio presented below, my main concern is that the path-MPR approach might not be as robust (possible reasons are given below). For the simulations, I used INRIA's GTNetS code with MPR LSA reduction and MPR adjacency reduction. I used the following parameters for both INRIA and MDR, to agree with INRIA's report. Both protocols also used the database exchange summary list optimization. Max velocity: 16 m/s Pause time: 1s HelloInterval: 2 s DeadInterval: 6 s RxmtInterval: 7 s MinLSInterval: 5 s MinLSArrival: 1 s As I mentioned previously, in INRIA's code, only the router with the largest RID in the network is a synch router. This does not agree with draft-baccelli-ospf-mpr-ext-02.txt, which says a router is a synch router if it has the largest (willingness, RID) in its neighborhood. The updated ospf6d directory and Makefile for OSPF-MDR can be found at home.earthlink.net/~ogier/ospf6d_mdr.tar.gz home.earthlink.net/~ogier/Makefile (All CFLAGS involving MPRs are commented out in the Makefile, since they might interfere with the operation of OSPF-MDR.) I ran simulations with 40, 60, 80, and 100 nodes, with range = 250 m. The results are summarized below, and detailed results for 100 nodes are given at the end of the message. MDR 40 nodes 60 nodes 80 nodes 100 nodes --- -------- -------- -------- -------- Total Overhead (kbps) 114.45 235.20 397.86 611.34 LSU overhead (kbps) 38.42 67.78 106.46 149.76 LS Ack overhead (kbps) 37.09 91.62 157.23 266.15 DD overhead (kbps) 10.06 21.14 39.37 57.58 Adjacencies/node 2.67 2.92 2.87 2.38 Adj changes/node/sec 0.04 0.04 0.05 0.04 Avg LSAs out of sync 0.81 0.69 0.43 0.43 Delivery ratio 0.931 0.934 0.936 0.934 INRIA 40 nodes 60 nodes 80 nodes 100 nodes ----- -------- -------- -------- -------- Total Overhead (kbps) 160.80 369.07 670.03 1174.08 LSU overhead (kbps) 27.97 58.66 100.02 177.27 LS Ack overhead (kbps) 49.15 109.55 183.28 294.12 DD overhead (kbps) 51.21 138.09 277.72 537.95 (9 x MDR) Adjacencies/node 16.37 21.08 26.49 31.78 Adj changes/node/sec 0.25 0.29 0.34 0.42 (10 x MDR) Avg LSAs out of sync 1.79 1.78 1.61 1.66 Delivery ratio 0.849 0.845 0.867 0.844 For 100 nodes, INRIA's DD overhead is 9.34 times that of MDR, resulting in almost 2 times as much total overhead. Also, INRIA's solution has a much lower delivery ratio (.844 versus .934 for 100 nodes). I don't know if this is a bug, but if not, my best guess is that this results from a combination of advertising barely enough links (no redundancy) and a longer delay to update LSAs following a link failure (due to the delay required to update and report MPRs as has been discussed). So, even though OSPF-MDR advertises more neighbors in LSAs, maybe these larger LSAs are necessary for robustness. The overhead for unicast LSUs is very low for MDR (13.65 kbps for 100 nodes), indicating that it will not help much to use multicast LSA retransmissions in MDR. In large networks, MDR's largest overhead component is LS Ack overhead, but this will be reduced to 0 if the non-ackable LSA option is used, at the cost of some additional multicast LSU transmissions. I plan to experiment with this option. Richard ------------------------------ Detailed results for 100 nodes MDR: ./random_waypoint_manet-opt seed=1 num_nodes=100 pktrate=10 wireless_interface=2 wireless_flooding=2 velocity=16 radio_range=250 pause_time=1 HelloInterval=2 RxmtInterval=7 DeadInterval=6 AckInterval=2000 BackupWaitInterval=500 TwoHopRefresh=3 AdjConnectivity=1 LSAFullness=1 start_time=1800 stop_time=2700 Neighbor statistics (at physical layer): -------------------------------------------------- Number of nodes: 100 Neighbor threshold distance (m): 250.00 Average neighbor density (neighbors/# of nodes): 0.65 Average neighbor changes/time (changes/sec/node): 0.84 OSPFv3 Statistics | Packets Bytes Kbps ---------------------------------------------------- Hello | 45000 15462092 137.44 LSAck | 43579 29941584 266.15 LSR | 664 46104 0.41 DBDESC | 9130 6478252 57.58 LSU | 53945 16848024 149.76 LSUfld | 47795 15312504 136.11 LSUuni | 6150 1535520 13.65 LSUcol | 38 15236 0.14 LSUrxmt | 5234 1205800 10.72 LSUdbex | 693 275356 2.45 LSUstale| 185 39128 0.35 | Total | 152318 68776056 611.34 OSPF Network Characteristics -------------------------------------------------- OSPF 2way_neighbors/node: 64.35 OSPF 2way_neighbor_changes/node/sec: 1.37 avg_sec/OSPF 2way neighbor_life: 102.29 OSPF adjacencies/node: 2.38 OSPF adjacency_changes/node/sec: 0.04 avg_LSAsOutSync: 0.43 Secs per router-LSA origination: 5.62 Router-LSA hopcount/Router-LSA installs: 2.33 Route changes/node/sec: 54.98 Accumulated adjacencies/node: 0.08 Flooding Statistics -------------------------------------------------- relaysel/node: 3.61 avg_sec/relaysel_life: 44.42 suppressed_LSAs: 1413794 relay_flood_LSAs: 91878 nonrelay_flood_LSAs: 5151 Topology Reduction Statistics -------------------------------------------------- Advertized neighbors: 112786 Total FULL neighbors: 1002857 User Traffic Analysis -------------------------------------------------- UDP sends: 8897 pkts, 604996 bytes UDP receives: 8311 pkts, 565148 bytes UDP forwards: 3191 pkts, 216988 bytes Delivery Ratio: 0.934 -------------------------------------------------- INRIA: ./random_waypoint_manet-opt seed=1 num_nodes=100 pktrate=10 wireless_interface=2 wireless_flooding=1 TopoReduc velocity=16 pause_time=1 radio_range=250 HelloInterval=2 RxmtInterval=7 DeadInterval=6 PushbackInterval=3500 AckInterval=500 MinLSInterval=5 start_time=1800 stop_time=2700 Neighbor statistics (at physical layer): -------------------------------------------------- Number of nodes: 100 Neighbor threshold distance (m): 250.00 Average neighbor density (neighbors/# of nodes): 0.65 Average neighbor changes/time (changes/sec/node): 0.84 OSPFv3 Statistics | Packets Bytes Kbps ---------------------------------------------------- Hello | 45000 15352104 136.46 LSAck | 111118 33088368 294.12 LSR | 38618 3180936 28.27 DBDESC | 77256 60519168 537.95 LSU | 102987 19943140 177.27 LSUfld | 40608 5252344 46.69 LSUuni | 62379 14690796 130.58 LSUcol | 20 6344 0.06 LSUrxmt | 0 0 0.00 LSUdbex | 38402 12007948 106.74 LSUstale| 23957 2676504 23.79 | Total | 374979 132083716 1174.08 OSPF Network Characteristics -------------------------------------------------- OSPF 2way_neighbors/node: 65.42 OSPF 2way_neighbor_changes/node/sec: 0.87 avg_sec/OSPF 2way neighbor_life: 163.41 OSPF adjacencies/node: 31.78 OSPF adjacency_changes/node/sec: 0.42 avg_LSAsOutSync: 1.66 Secs per router-LSA origination: 5.46 Router-LSA hopcount/Router-LSA installs: 1.92 Route changes/node/sec: 20.26 Accumulated adjacencies/node: 5.17 Sync Node changes: 0.00 Flooding Statistics -------------------------------------------------- relaysel/node: 1.99 avg_sec/relaysel_life: 7.08 suppressed_LSAs: 0 relay_flood_LSAs: 44823 nonrelay_flood_LSAs: 0 relay_flood_LSAs retransmissions: 4905 Neighborhood Statistics -------------------------------------------------- Hello received: 2617968 Inactivity calls: 35125 Topology Reduction Statistics -------------------------------------------------- Advertized neighbors: 51408 Total FULL neighbors: 1099248 User Traffic Analysis -------------------------------------------------- UDP sends: 8897 pkts, 604996 bytes UDP receives: 7510 pkts, 510680 bytes UDP forwards: 2183 pkts, 148444 bytes Delivery Ratio: 0.844 -------------------------------------------------- _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Mon Mar 12 17:36:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQsBf-0003BH-QI; Mon, 12 Mar 2007 17:36:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQsBe-0003BA-Gs for ospf-manet@ietf.org; Mon, 12 Mar 2007 17:36:10 -0400 Received: from mailgate-internal1.sri.com ([128.18.84.103]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HQsBd-0007Hc-4o for ospf-manet@ietf.org; Mon, 12 Mar 2007 17:36:10 -0400 Received: from localhost (HELO mailgate-internal1.SRI.COM) (127.0.0.1) by mailgate-internal1.sri.com with SMTP; 12 Mar 2007 21:36:05 -0000 Received: from mercury.esd.sri.com ([128.18.26.21]) by mailgate-internal1.SRI.COM (SMSSMTP 4.1.11.41) with SMTP id M2007031214360528193 for ; Mon, 12 Mar 2007 14:36:05 -0700 Received: from earthlink.net ([128.18.40.95]) by mercury.esd.sri.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JET00GTT80IV2@mercury.esd.sri.com> for ospf-manet@ietf.org; Mon, 12 Mar 2007 14:36:19 -0700 (PDT) Date: Mon, 12 Mar 2007 14:35:58 -0700 From: Richard Ogier To: ospf-manet@ietf.org Message-id: <45F5C7BE.6060505@earthlink.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Ospf-manet] Re: Regarding MPR-OSPF X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org Philippe and Emmanuel, You did not respond to my following comment posted on 2/19/07: > I noticed two possible problems with your GTNetS code for MPR-OSPF. > The first one regards the following code in need_adjacency(): > #ifdef OSPF6_MANET_MPR_ADJ_REDUC_OSPF_MPR > if (on->ospf6_if->synchNode) > return 1; > > if (ospf6_lookup_relay_selector(on->ospf6_if, on->router_id)) > return 1; > else > return 0; > #endif //OSPF6_MANET_MPR_ADJ_REDUC_OSPF_MPR > The above code code says that the router forms an adjacency with > a neighbor only if the router is a synch node or the neighbor > is an MPR selector. This can cause unidirectional adjacencies, > as explained below. (A similar problem with the OSPF-MDR code > was discovered and corrected over a year ago.) > ... > Therefore, it is necessary for the need_adjacency condition to be > symmetric. I.e., node i should consider node j adjacent if and only > if node j considers node i adjacent. More specifically, need_adjacency() > should also return true if the neighbor is a synch node or an MPR. > (Notice that the need_adjacency condition is symmetric in RFC 2328.) However, you *did* quietly modify your draft to incorporate my suggestion to make the need_adjacency condition symmetric, in Section 5.3.2 of your updated draft: > the state of this neighbor MUST be changed to (i) 2-WAY if the neighbor > is not in the MPR set or the MPR selector set, or (ii) ExStart if the > neighbor is in the MPR set or the MPR selector set, or if the > neighbor or the router itself is a synch router. You also added the S bit to TLV type 4 to allow a router to know whether a neighbor is a synch router. I guess I should be happy that you incorporated my suggestion. But I think I saved you significant effort, since it was not easy to find this bug in OSFP-MDR more than a year ago, so I think some sort of thanks would be appropriate. For consistency, you also need to modify the condition for forming an adjacency in Section 5.3 (to make the condition symmetric). Also, I see you modified the rule for selecting synch routers to be consistent with your code, i.e., o a MANET router decides it is a synch router if and only if the router has a higher ID than any other ID received in Hello packets or Router-LSAs. I see two possible problems with the above rule. First, you are now ignoring Willingness (or Router Priority), so a router that has very little remaining battery life might be selected to be the synch router (and thus become adjacent with all of its neighbors). I feel sorry for the router with the largest RID. Second, this does not work if the highest RID node in the area is a non-MANET router (does not have a MANET interface). You could select the synch router to be the MANET router with the largest RID (and indicate by a bit in the LSA whether a router is a MANET router), but even this does not work since the largest RID router might not be reachable via MANET links, or the route might have to use multiple MANET interfaces. Therefore, unless you have a way to fix this, I think it is necessary to select synch routers based on local information, possibly by looking at all 2-hop neighbors. Another possible solution is to identify the synch router for each interface in Hello packets, so a router can be sure that there is a MANET path to the synch router via the same MANET interface. However, this could take significant time to converge if the synch router for a given interface leaves the network or becomes unreachable. Richard _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Tue Mar 13 09:26:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR71c-0000nm-RR; Tue, 13 Mar 2007 09:26:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR71a-0000mp-Rh for ospf-manet@ietf.org; Tue, 13 Mar 2007 09:26:46 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR71Y-0001vx-CA for ospf-manet@ietf.org; Tue, 13 Mar 2007 09:26:46 -0400 Received: from [192.168.112.199] (sphinx.lix.polytechnique.fr [129.104.11.1]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l2DDQdkB017410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Mar 2007 14:26:39 +0100 Message-ID: <45F6A68D.2010008@inria.fr> Date: Tue, 13 Mar 2007 14:26:37 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: ospf-manet@ietf.org Subject: Re: [Ospf-manet] Re: Regarding MPR-OSPF References: <45F5C7BE.6060505@earthlink.net> In-Reply-To: <45F5C7BE.6060505@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 45F6A68F.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org Dear Richard, We're happy to see that you, subsequent to our long discussions, have been working towards improving MDR. The performance results in your email indicate important changes to the I-D, which merit study and further discussion -- will you be in Prague that we may do that together (at the OSPF meeting and otherwise)? As for the MPR-OSPF draft, as you observed, some minor details which were pointed out on the list and elsewhere have been clarified in the I-D -- this will, of course, be reflected in the status update in Prague. And by the way, here is the link to the update of the draft: http://www.ietf.org/internet-drafts/draft-baccelli-ospf-mpr-ext-03.txt To clarify a point which you indicate that you missed concerning the synch router: the willingness parameter influences a routers forwarding ability only. If a synch router is outside the MANET, then according to the I-D there exists a hybrid router which will synchronise with its whole neighbourhood, thus fulfilling the synch role. We agree that the synch alternatives which you propose are complex and potentially less performant, which is why we went with the above solution which does the same thing without these inconveniences. Emmanuel _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Tue Mar 13 17:31:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HREaQ-0000BC-4P; Tue, 13 Mar 2007 17:31:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HREaP-0000B4-72 for ospf-manet@ietf.org; Tue, 13 Mar 2007 17:31:13 -0400 Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HREaM-0008WL-UN for ospf-manet@ietf.org; Tue, 13 Mar 2007 17:31:13 -0400 Received: from dialup-4.245.102.214.dial1.sanjose1.level3.net ([4.245.102.214]) by pop-gadwall.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1HREaK-0005ix-00; Tue, 13 Mar 2007 17:31:08 -0400 Message-ID: <45F7181A.8030004@earthlink.net> Date: Tue, 13 Mar 2007 13:31:06 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Ospf-manet] Re: Regarding MPR-OSPF References: <45F5C7BE.6060505@earthlink.net> <45F6A68D.2010008@inria.fr> In-Reply-To: <45F6A68D.2010008@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ospf-manet@ietf.org X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org Emmanuel Baccelli wrote: > > To clarify a point which you indicate that you missed concerning the > synch router: the willingness parameter influences a routers > forwarding ability only. If a synch router is outside the MANET, then > according to the I-D there exists a hybrid router which will > synchronise with its whole neighbourhood, thus fulfilling the synch role. OK. I knew that a hybrid router must select all neighbors as path MPRs, but I missed the definition of the MPR set as the union of the path MPRs and the flooding MPRs. So a router must become adjacent with all of its flooding/path MPRs and flooding/path MPR selectors. This could result in a lot of adjacencies when unequal metrics are used (even more than you are obtaining in your GTNetS simulations). But still, if there is no hybrid router, then the router with largest RID is still treated unfairly since, as the synch router, it must become adjacent with all of its neighbors. In version 02, you used Willingness to select synch routers, but I realize you can't do that easily now, since you are now looking at all routers in the area. (Note that MDR selection uses Router Priority, so OSPF-MDR does not have this issue.) I won't be at the Prague meeting, but plan to present an update at the Chicago meeting in July. If you are going to present simulation results at the Prague meeting, can you provide your updated GTNetS code this week? Or if you did not make any changes to the code other than making the need_adjacency condition symmetric (as I suggested), then please let me know (since I can easily make this change). Richard > > We agree that the synch alternatives which you propose are complex and > potentially less performant, which is why we went with the above > solution which does the same thing without these inconveniences. > > Emmanuel > > _______________________________________________ > Ospf-manet mailing list > Ospf-manet@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf-manet > > _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Tue Mar 13 20:24:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRHI8-0007oy-DC; Tue, 13 Mar 2007 20:24:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRHI7-0007ot-Jr for ospf-manet@ietf.org; Tue, 13 Mar 2007 20:24:31 -0400 Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRHI6-0008Ne-Cl for ospf-manet@ietf.org; Tue, 13 Mar 2007 20:24:31 -0400 Received: from dialup-4.245.101.139.dial1.sanjose1.level3.net ([4.245.101.139]) by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1HRHI4-0006jx-00; Tue, 13 Mar 2007 20:24:28 -0400 Message-ID: <45F740BA.9080404@earthlink.net> Date: Tue, 13 Mar 2007 16:24:26 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Ospf-manet] Re: Regarding MPR-OSPF References: <45F5C7BE.6060505@earthlink.net> <45F6A68D.2010008@inria.fr> In-Reply-To: <45F6A68D.2010008@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ospf-manet@ietf.org X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org Emmanuel Baccelli wrote: > To clarify a point which you indicate that you missed concerning the > synch router: the willingness parameter influences a routers > forwarding ability only. If a synch router is outside the MANET, then > according to the I-D there exists a hybrid router which will > synchronise with its whole neighbourhood, thus fulfilling the synch role. Emmanuel, There still seems to be a problem when a router has multiple MANET interfaces. You define a hybrid router as follows. Hybrid router - a router which has OSPF interfaces of several types, including the MANET type. So a router with only MANET interfaces is not a hybrid router. Consider a router A that has only one MANET interface, but has only 1-hop neighbors and no 2-hop neighbors on this interface. (I.e., Hellos received from neighbors on this interface advertise only routers that are neighbors of router A itself.) As a result, router A has no MPRs. Assume it also has no MPR selectors. A ----- B ----- C Now suppose router A has a neighbor B which has two MANET interfaces, one of which connects it to router A, and the other of which connects it to router C, which is not a neighbor of A. Assume router C has the largest RID and is therefore the synch router. Therefore, since router A is not a synch router (nor a neighbor of a synch router) and has no MPRs or MPR selectors, it has no adjacencies! Therefore, it still looks like you need to select a synch router for each MANET interface, or redefine a hybrid router to include routers with multiple MANET interfaces. Am I missing something? Richard _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Sat Mar 24 22:49:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVInb-0008A1-26; Sat, 24 Mar 2007 22:49:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVIna-00089v-MS for ospf-manet@ietf.org; Sat, 24 Mar 2007 22:49:38 -0400 Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVInW-0004rc-CM for ospf-manet@ietf.org; Sat, 24 Mar 2007 22:49:38 -0400 Received: from dialup-4.245.96.56.dial1.sanjose1.level3.net ([4.245.96.56]) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1HVInV-0007Oa-00 for ospf-manet@ietf.org; Sat, 24 Mar 2007 22:49:33 -0400 Message-ID: <4605F16D.2050900@earthlink.net> Date: Sat, 24 Mar 2007 19:50:05 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ospf-manet@ietf.org Subject: [Fwd: Re: [Ospf-manet] Re: Regarding MPR-OSPF] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org Emmanuel, You did not respond to my question regarding your selection of a synch router, which I posted on March 13 and am repeating below. I think my question is valid, so can you please respond? This is important because your simulations assume that you can always select a *single* router to be the synch router, which may not be true in general. As you know, the number of synch routers affects overhead significantly in dense networks. If Emmanuel does not respond, can someone else respond who either agrees or disagrees with me? Richard Emmanuel Baccelli wrote: > To clarify a point which you indicate that you missed concerning the > synch router: the willingness parameter influences a routers > forwarding ability only. If a synch router is outside the MANET, then > according to the I-D there exists a hybrid router which will > synchronise with its whole neighbourhood, thus fulfilling the synch role. Emmanuel, There still seems to be a problem when a router has multiple MANET interfaces. You define a hybrid router as follows. Hybrid router - a router which has OSPF interfaces of several types, including the MANET type. So a router with only MANET interfaces is not a hybrid router. Consider a router A that has only one MANET interface, but has only 1-hop neighbors and no 2-hop neighbors on this interface. (I.e., Hellos received from neighbors on this interface advertise only routers that are neighbors of router A itself.) As a result, router A has no MPRs. Assume it also has no MPR selectors. A ----- B ===== C Now suppose router A has a neighbor B which has two MANET interfaces, one of which connects it to router A, and the other of which connects it to router C, which is not a neighbor of A. Assume router C has the largest RID and is therefore the synch router. Therefore, since router A is not a synch router (nor a neighbor of a synch router) and has no MPRs or MPR selectors, it has no adjacencies! Therefore, it still looks like you need to select a synch router for each MANET interface, or redefine a hybrid router to include routers with multiple MANET interfaces. Am I missing something? Richard _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Wed Mar 28 19:25:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWhWW-0008Gm-9g; Wed, 28 Mar 2007 19:25:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWhWV-0008EE-FZ for ospf-manet@ietf.org; Wed, 28 Mar 2007 19:25:47 -0400 Received: from enterprise58.opnet.com ([192.104.65.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWhWU-0007z4-31 for ospf-manet@ietf.org; Wed, 28 Mar 2007 19:25:47 -0400 Received: from wtn12131.opnet.com (wtn12131.opnet.com [172.16.12.131]) by enterprise58.opnet.com (8.13.6/8.12.10) with ESMTP id l2SNKfoi010633 for ; Wed, 28 Mar 2007 19:20:43 -0400 Message-Id: <6.2.3.4.2.20070328180826.03a319d0@mailserver.opnet.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 28 Mar 2007 18:25:29 -0500 To: ospf-manet@ietf.org From: Aniket Desai In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OPNET-MailScanner: Found to be clean X-MailScanner-From: adesai@opnet.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Subject: [Ospf-manet] Re: Ospf-manet Digest, Vol 15, Issue 5 X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org Hello, That's an interesting observation. I gave this problem some thought myself. The fundamental issue first of all is that the way in which the synch router is currently defined does not guarantee a connected adjacency graph. I think this is a serious hole, and the whole MPR draft needs to be rethought. I think fleshing out the draft more with details on how it fits in each part of RFCs 2328/2740 is of great importance, which is something I have found only in the MDR draft till date. Thus there never was a question of correct functionality in MDR, and all discussion centered around efficiency/complexity. Such does not look to be the case with MPR. In fact a while back, Dr. Ogier suggested another improvement to avoid unidirectional adjacencies in MPR draft as well. If I understand correctly, a synch interface should form adjacencies with all its neighbors regardless of MPR signaling. Thus the most obvious choice is to have the highest router ID synch interface to do this job. However the price of having to break and form new adjacencies if a new router with higher ID moves in the neighborhood is too high. I am not sure if a persistence feature is possible (the same way as MDRs are persistent). Also as Dr. Ogier pointed out, as the network size grows big (and worse yet, as number of interfaces increase), number of synch interfaces become high. Since a synch pays the price of establishing adjacencies with everyone in vicinity, this becomes a bottleneck. Thanks, Aniket At 11:00 AM 3/25/2007, you wrote: >Send Ospf-manet mailing list submissions to > ospf-manet@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/ospf-manet >or, via email, send a message with subject or body 'help' to > ospf-manet-request@ietf.org > >You can reach the person managing the list at > ospf-manet-owner@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Ospf-manet digest..." > > >Today's Topics: > > 1. [Fwd: Re: [Ospf-manet] Re: Regarding MPR-OSPF] (Richard Ogier) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Sat, 24 Mar 2007 19:50:05 -0800 >From: Richard Ogier >Subject: [Fwd: Re: [Ospf-manet] Re: Regarding MPR-OSPF] >To: ospf-manet@ietf.org >Message-ID: <4605F16D.2050900@earthlink.net> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >Emmanuel, > >You did not respond to my question regarding your selection >of a synch router, which I posted on March 13 and am repeating >below. I think my question is valid, so can you please respond? >This is important because your simulations assume that you can >always select a *single* router to be the synch router, which may >not be true in general. As you know, the number of synch routers >affects overhead significantly in dense networks. > >If Emmanuel does not respond, can someone else respond who either >agrees or disagrees with me? > >Richard > >Emmanuel Baccelli wrote: > > > To clarify a point which you indicate that you missed concerning the > > synch router: the willingness parameter influences a routers > > forwarding ability only. If a synch router is outside the MANET, then > > according to the I-D there exists a hybrid router which will > > synchronise with its whole neighbourhood, thus fulfilling the synch role. > > >Emmanuel, > >There still seems to be a problem when a router has multiple >MANET interfaces. You define a hybrid router as follows. > >Hybrid router - a router which has OSPF interfaces of several types, >including the MANET type. > >So a router with only MANET interfaces is not a hybrid router. >Consider a router A that has only one MANET interface, but has >only 1-hop neighbors and no 2-hop neighbors on this interface. >(I.e., Hellos received from neighbors on this interface advertise >only routers that are neighbors of router A itself.) As a result, >router A has no MPRs. Assume it also has no MPR selectors. > >A ----- B ===== C > >Now suppose router A has a neighbor B which has two MANET >interfaces, one of which connects it to router A, and the other >of which connects it to router C, which is not a neighbor of A. >Assume router C has the largest RID and is therefore the synch router. >Therefore, since router A is not a synch router (nor a neighbor of a >synch router) and has no MPRs or MPR selectors, it has no adjacencies! > >Therefore, it still looks like you need to select a synch router >for each MANET interface, or redefine a hybrid router to include >routers with multiple MANET interfaces. Am I missing something? > >Richard > > > >_______________________________________________ >Ospf-manet mailing list >Ospf-manet@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf-manet > > > > > > > > > >------------------------------ > >_______________________________________________ >Ospf-manet mailing list >Ospf-manet@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf-manet > > >End of Ospf-manet Digest, Vol 15, Issue 5 >***************************************** Aniket Desai Modeling Engineer, Models Research and Development OPNET Technologies Inc. 7255 Woodmont Avenue, suit 445, Bethesda, MD 20814 (240) 497 3000 (ext 2409) www.opnet.com ==================================================== Register for OPNETWORK 2007 (Aug 27 - 31, Washington, DC) http://www.opnet.com/opnetwork2007 ==================================================== ==================================================== Register for OPNET Technology Workshops! http://www.opnet.com/news/events/online_tech_wrkshop.html ==================================================== _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Fri Mar 30 03:09:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXBEW-0004I9-Lc; Fri, 30 Mar 2007 03:09:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXBEU-0004I4-P7 for ospf-manet@ietf.org; Fri, 30 Mar 2007 03:09:10 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXBES-0008FO-Ck for ospf-manet@ietf.org; Fri, 30 Mar 2007 03:09:10 -0400 Received: from [192.168.0.2] (ras75-3-82-226-221-97.fbx.proxad.net [82.226.221.97]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l2U78oKM029062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Mar 2007 09:08:51 +0200 Message-ID: <460CB782.8050602@inria.fr> Date: Fri, 30 Mar 2007 09:08:50 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: ospf-manet@ietf.org Subject: Re: [Fwd: Re: [Ospf-manet] Re: Regarding MPR-OSPF] References: <4605F16D.2050900@earthlink.net> In-Reply-To: <4605F16D.2050900@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 460CB783.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org Dear Richard, see answer below > So a router with only MANET interfaces is not a hybrid router. > Consider a router A that has only one MANET interface, but has > only 1-hop neighbors and no 2-hop neighbors on this interface. > (I.e., Hellos received from neighbors on this interface advertise > only routers that are neighbors of router A itself.) As a result, > router A has no MPRs. Assume it also has no MPR selectors. > > A ----- B ===== C > > Now suppose router A has a neighbor B which has two MANET > interfaces, one of which connects it to router A, and the other > of which connects it to router C, which is not a neighbor of A. > Assume router C has the largest RID and is therefore the synch router. > Therefore, since router A is not a synch router (nor a neighbor of a > synch router) and has no MPRs or MPR selectors, it has no adjacencies! > > Therefore, it still looks like you need to select a synch router > for each MANET interface, or redefine a hybrid router to include > routers with multiple MANET interfaces. Am I missing something? > Yes. According to section 5.2.4. Hello packets contain a TLV that will: "advertize the costs of links towards ALL its symmetric MANET neighbors. If the router has several MANET interfaces, links to ALL the symmetric MANET neigbors over ALL the MANET interfaces of the router MUST have their costs listed." Thus MPR selection algorithms take into account neighbors on multiple MANET interfaces, similar to the way OLSR works. Therefore in your example, A will select B as MPR, and will bring up an adjacency with B. Emmanuel _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Fri Mar 30 12:15:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJl0-00041M-Cz; Fri, 30 Mar 2007 12:15:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJkz-0003ur-Kc for ospf-manet@ietf.org; Fri, 30 Mar 2007 12:15:17 -0400 Received: from enterprise58.opnet.com ([192.104.65.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXJgK-0006Vn-3Q for ospf-manet@ietf.org; Fri, 30 Mar 2007 12:10:30 -0400 Received: from wtn12131.opnet.com (wtn12131.opnet.com [172.16.12.131]) by enterprise58.opnet.com (8.13.6/8.12.10) with ESMTP id l2UG5NoK031406; Fri, 30 Mar 2007 12:05:26 -0400 Message-Id: <6.2.3.4.2.20070330110357.02895f80@mailserver.opnet.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 30 Mar 2007 11:10:15 -0500 To: ospf-manet@ietf.org, ospf-manet@ietf.org From: Aniket Desai In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OPNET-MailScanner: Found to be clean X-MailScanner-From: adesai@opnet.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Subject: [Ospf-manet] Re: Ospf-manet Digest, Vol 15, Issue 7 X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org This means that all MANET neighbors should be advertised on all MANET interfaces? That's some serious scalability problem. I think it's a good design to keep the interfaces separate from each other, because the physical properties of wireless interfaces may be different. There can be a long range interface with hundreds of neighbors and a very short range low power interface with only a few neighbors. Why should the power constrained short range interface need to know about the neighbors that are far away from it on the long range interface? An OSPF interface does not need to know about neighbors on other interfaces. I think this is a much more serious design flaw than having to advertise routable neighbors in the LSA for min cost SPF (over which, there was way too much contention on this WG). Thanks, Aniket At 11:00 AM 3/30/2007, ospf-manet-request@ietf.org wrote: >Send Ospf-manet mailing list submissions to > ospf-manet@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/ospf-manet >or, via email, send a message with subject or body 'help' to > ospf-manet-request@ietf.org > >You can reach the person managing the list at > ospf-manet-owner@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Ospf-manet digest..." > > >Today's Topics: > > 1. Re: [Fwd: Re: [Ospf-manet] Re: Regarding MPR-OSPF] > (Emmanuel Baccelli) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 30 Mar 2007 09:08:50 +0200 >From: Emmanuel Baccelli >Subject: Re: [Fwd: Re: [Ospf-manet] Re: Regarding MPR-OSPF] >To: ospf-manet@ietf.org >Message-ID: <460CB782.8050602@inria.fr> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > >Dear Richard, > >see answer below > > > > So a router with only MANET interfaces is not a hybrid router. > > Consider a router A that has only one MANET interface, but has > > only 1-hop neighbors and no 2-hop neighbors on this interface. > > (I.e., Hellos received from neighbors on this interface advertise > > only routers that are neighbors of router A itself.) As a result, > > router A has no MPRs. Assume it also has no MPR selectors. > > > > A ----- B ===== C > > > > Now suppose router A has a neighbor B which has two MANET > > interfaces, one of which connects it to router A, and the other > > of which connects it to router C, which is not a neighbor of A. > > Assume router C has the largest RID and is therefore the synch router. > > Therefore, since router A is not a synch router (nor a neighbor of a > > synch router) and has no MPRs or MPR selectors, it has no adjacencies! > > > > Therefore, it still looks like you need to select a synch router > > for each MANET interface, or redefine a hybrid router to include > > routers with multiple MANET interfaces. Am I missing something? > > > > >Yes. According to section 5.2.4. Hello packets contain a TLV that will: > >"advertize the costs of links towards ALL its symmetric MANET neighbors. > If the router has several MANET interfaces, links to ALL the symmetric >MANET neigbors over ALL the MANET interfaces of the router MUST have >their costs listed." > >Thus MPR selection algorithms take into account neighbors on multiple >MANET interfaces, similar to the way OLSR works. Therefore in your >example, A will select B as MPR, and will bring up an adjacency with B. > >Emmanuel > > > >------------------------------ > >_______________________________________________ >Ospf-manet mailing list >Ospf-manet@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf-manet > > >End of Ospf-manet Digest, Vol 15, Issue 7 >***************************************** Aniket Desai Modeling Engineer, Models Research and Development OPNET Technologies Inc. 7255 Woodmont Avenue, suit 445, Bethesda, MD 20814 (240) 497 3000 (ext 2409) www.opnet.com ==================================================== Register for OPNETWORK 2007 (Aug 27 - 31, Washington, DC) http://www.opnet.com/opnetwork2007 ==================================================== ==================================================== Register for OPNET Technology Workshops! http://www.opnet.com/news/events/online_tech_wrkshop.html ==================================================== _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet