Subject: FW: [Ospf-manet] new software snapshot

From: "Stan Ratliff \(sratliff\)" <[email-masked]>
Date: Wed, 8 Feb 2006 14:21:59 -0500

All, 

Yes, based on some of the bug fixes noted below, and the 
change to comparing OR/SP to Uni-Connected MDR's, 
the charts I presented at IETF-64 (Vancouver) are no 
longer correct. 

Regards,
Stan

>-----Original Message-----
>From: Richard Ogier [mailto:[email-masked]] 
>Sent: Wednesday, February 08, 2006 9:20 AM
>To: Henderson, Thomas R; [email-masked]
>Subject: Re: [Ospf-manet] new software snapshot
>
>All,
>
>I ran one case from the script file, which attempts to recreate the
>simulations that Stan presented at the last IETF meeting.  I ran 50
>nodes with range = 200.
>This time the results are quite different!
>
>For OR/SP the overhead is 1117.68 kbps and the delivery ratio is 0.819.
>For MDR, the overhead is 530.30 kbps and the delivery ratio is 0.826.
>
> From a message posted 12/15/2005:
>Richard wrote:
>
> > I think this is a significant advantage of OSPF-MDR.  The pruning is
>straightforward  > and is similar to what OSPF does in a broadcast
>network.  I.e., it is based  > on the requirement that each adjacency
>must have an MDR or BMDR as one endpoint.
>
>Acee wrote:
>
> >> I agree that pruning is more simpler and more intuitive than with
>smart peering.  However,  >> what matters the most are the 
>other metrics
>(overhead, delivery ratio, stretch factor) in  >> the various mobility
>scenarios.
>
>I agree.  But OSPF-MDR is pretty much the same as it was almost a year
>ago, and so far I have not seen any proposal that performs better than
>it.
>Maybe you are implying that Cisco (or someone) will eventually find a
>better solution?
>
>Richard
>
>
>
>Henderson, Thomas R wrote:
>
>>We've posted a new snapshot of the simulator (and 
>corresponding quagga 
>>implementation patch) at the following URL:
>>http://hipserver.mct.phantomworks.org/ietf/ospf/
>>
>>I've posted some release notes below.  We are going to 
>continue to work
>
>>on adding Pratik's proposed changes to the simulator in the meantime, 
>>and will release that as soon as available.  I'll send a 
>separate mail 
>>later this week describing our near-term simulation plans.  We're 
>>putting this snapshot out now for the benefit of those who might want 
>>to experiment with it themselves.
>>
>>Tom and Phil
>>
>>
>>
>>RELEASE NOTES: OSPF MANET version 0.8 (February 1, 2006)
>>
>>Changes to the MANET code since 0.7 release (Oct. 25, 2005):
>>
>>Quagga 0.98.5
>>-------------
>>We have upgraded the code base from Quagga 0.98.4 to 0.98.5
>>
>>Overlapping Relays and Smart Peering
>>------------------------------------
>>
>>1. Added changes to the Smart Peering code provided by Stan Ratliff
>>   from Cisco.  Code added by Stan is noted in the code.  The largest
>>   change was to add an additional SPF calculation that is performed
>>   only over synchronized adjacencies.
>>2. Section 4.4 of the SP draft was previously not 
>implemented.  It has 
>>   now been implemented with the method where flooding is not 
>performed
>
>>   over non-adjacent links.  Therefore, the MPR selection algorithm 
>>only
>>
>>   uses adjacent links for one and 2-hop neighbors.
>>3. Bug fix:  Router-LSAs were not being originated as often as 
>>necessary
>>
>>   because routeability of unsynchronized adjacencies was 
>being checked
>
>>   against the unsynchronized spf table.  The synchronized 
>(adjacencies
>
>>   only) spf table is now used to determine when a router-LSA 
>should be
>
>>   originated.
>>4. Bug fix:  The synchronized spf table (spf_table_sync) was being 
>>built
>>
>>   using links in its own router-LSA that were 
>unsynchronized.  The SPF
>
>>   calculation was changed to use only synchronized links when the 
>>   synchronized SPF table is calculated.
>>5. Bug fix:  Each time an LSA was installed with ospf6_spf_install() 
>>the
>>
>>   neighbors were checked for routeability and adjacencies where 
>>updated.
>>   However, it was found that this method was not working because the 
>>SPF
>>   was not being run prior to checking for routeability.  Therefore,
>the
>>   routeability check and the adjacency update was moved to after each
>>   SPF calculation.
>>6. Optimization:  If a new router-LSA is originated due to a neighbor 
>>down
>>   event then the router-LSA is not flooded until after any necessary 
>>   adjacencies are formed or the minLSInterval has passed.  This 
>>corrects
>>   the possible problem that a neighbor down event causes an 
>LSA flood,
>
>>but
>>   then the OSPF router has to wait MinLSInterval before 
>announcing any
>
>>new
>>   adjacencies (formed from previously unsynchronized neighbors).
>>
>>MANET Designated Routers
>>------------------------
>>
>>1. Bug fix:  In the MDR protocol,
>>   if an adjacency forms between nodes A and B, and then node A
>>   drops B because of the inactivity timer and then receives
>>   a Hello from B, while node B never drops A, then node A may
>>   not bring the adjacency back up.  The reason has to do with
>>   the neighbor variable dependent_selector, which node A will
>>   set to 0 when it loses node B.  To fix this, a Dependent Neighbor
>>   List (DNL) TLV is used.  The DNL TLV is included in each Hello,
>along
>>   with the RNL, so a router always knows whether a neighbor considers
>>   the router to be dependent.
>>2. The backup dependent neighbors are no longer selected, since there
>>   is no longer any reason to distinguish between them and dependent
>>   neighbors. Related to this, need_adjacency()is greatly simplified
>>   and no longer depends on AdjConnectivity.  Instead dependent 
>>neighbors
>>   depend on AdjConnectivity, and only neighboring MDR/BMDRs that
>should
>>   be adjacent are now dependent. (This is analogous to parents, since
>>   parents are also MDR/BMDR neighbors that should be adjacent.)
>>
>>3. For equal comparison with Overlapping Relays and Smart Peering, 
>>   adjacencies are never torn down.
>>
>>New statistics
>>--------------
>>- Sec/Router-LSA Origination/Node:  The number of seconds 
>that a router
>
>>waits before reoriginating its router-LSA.
>>- Route changes/node/sec: We are now printing out the number 
>of times a
>
>>route changes per node per second, as observed in the 
>forwarding table,
>
>>to get a sense of route stability of the various approaches.
>>- Accumulated adjacencies/node:  We are printing the number of 
>>adjacencies that are accumlated per node from the start of statitics 
>>gathering to the end of the simulation.  A negative value indicates 
>>that there are fewer adjacencies at the end of the simulation than at 
>>the start of the statisics gathering.
>>
>>New scripts for random_waypoint_manet directory
>>----------------------------------------
>>
>>1. comp_density_or.pl:  This script runs random_waypoint_manet with 
>>Overlapping
>>   Relays (OR)s and varies the radio range and number of nodes.  The 
>>results
>>   provide information on the performance of ORs with varying density.
>>
>>2. comp_density_mdr.pl:  This script runs random_waypoint_manet with 
>>MANET
>>   Designated Routers (MDR)s and varies the radio range and number of 
>>nodes.
>>   The results provide information on the performance of MDRs with 
>>varying
>>   density. 
>>
>>3. comp_mdr_or-sp.pl:  This script runs random_waypoint_manet and
>>compares:
>>   1. MDRs with uniconnected adjacencies and full LSAs  
>>   2. MDRs with biconnected adjacencies and min-cost LSAs  
>>   3. ORs with smart peering and full LSAs. 
>>
>>NOTE:  Script 1 and 2 attempt to recreate the scenarios shown by
>>       Stan Ratliff at IETF-64 OSPF WG meeting.  
>>
>>
>>_______________________________________________
>>Ospf-manet mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/ospf-manet
>>
>>
>

_______________________________________________
Ospf-manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf-manet