1 / 14

OSPF Extension for MANET based on MPR: Improving Efficiency and Convergence Time

This document discusses the OSPF extension for MANETs based on MPR (Multi-Point Relays), which allows for flooding optimization, adjacency reduction, and topology reduction. Recent developments and simulations show significant gains in overhead reduction, packet rates, and topology reduction. The document also highlights the need for further research, better wireless models, and real-world experience to evaluate deployment challenges.

mohrd
Download Presentation

OSPF Extension for MANET based on MPR: Improving Efficiency and Convergence Time

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. OSPF extension for MANET based on MPR draft-baccelli-ospf-mpr-ext-02.txt Emmanuel Baccelli 67th IETF OSPF WG in San Diego, Nov. 7th 2006

  2. Agenda • Overview of the extension for MANETs • Recent Developments • GTNetS simulation • Next steps

  3. OSPF MANET interface type • Addresses mobile ad hoc specificities • Wireless link issues • Highly dynamic topology • MANET interface type properties • Overhead reduction (flooding, adjacency, topology) • Convergence time • OSPF legacy preserved over MANET • MPR approach allows • flooding optimization • adjacency reduction • topology reduction

  4. MPR: Multi-Point Relays • What are they? • - subset of links covering the network • MPR Properties: • 2-hop neighborhood coverage • shortest paths coverage MPR MPR MPR • ... allows for: • - Flooding Optimization • - Adjacency Reduction • - Topology Reduction Works very well in sparse, dense, slow, fast mobility (Mathematical models, real world deployments)

  5. Recent Developments • As discussed in Design Team: • Modified structure to match better RFC 2740 and 2328 • Heuristic for MPR selection taking into account link costs • Carried out GTNetS simulations • Inside common framework provided by Boeing • Code base derived from OR code

  6. Flooding efficiency with the MPR extension full LSA full synchronization Packet Rates 100 x less Overhead in Kbits per sec. 1000x1000 square network

  7. Flooding Efficiency with the MPR extension full LSA full synchronization Packet Rates 100x less Overhead in Kbits per sec. 500x500 square network

  8. Topology Reduction with the MPR extension reduced LSA full synchronization Packet Rates similar Overhead in Kbits per sec. 30% gain 1000x1000 square network

  9. Topology Reduction with the MPR extension reduced LSA full synchronization Packet Rates more packets but Overhead in Kbits per sec. 50% gain in Kbps 500x500 square network

  10. Comparison full LSA versus reduced LSA in packets/s in Kbps 75% Gain in # advertized links/s 500x500 square network

  11. Confirming with Independent simulations (Maple) Random walk mobility model full LSA versus reduced LSA #packets/s #links/s 500x500 square network

  12. Confirming with Independent simulations (Maple) Random walk mobility model full LSA versus reduced LSA #packets/s #links/s 1000x1000 square network

  13. Analytic Model: Why LSA flooding overhead is larger than synchronization overhead • Random walk model, full synchro, full LSA • average link lifetime • links creation frequency (N network size, M average neighbor size) • # nodes ID exchanged in synchro • # links advertized in flooding • : number of retransmissions per neighborhood • : frequency of link creation and dying

  14. Next Steps • Simulations are necessary step, but: • No satisfying wireless model known to date • Scenarii are too restrictive • Not sufficient to evaluate real deployment problems • Experimental status • To leverage the work of the design team so far • To gather real world experience

More Related