4/11/02 OSPF and MANET WG meetings, IETF64 OSPF MANET Design Team outbrief November, 2005 Tom Henderson {thomas.r.henderson@boeing.com} Design team members: Emmanuel Baccelli, Madhavi Chandra, Thomas Clausen, Padma Pillay-Esnault, David Green, Acee Lindem, Joe Macker, Richard Ogier, Tony Przygienda, Abhay Roy, Phil Spagnolo 1 Outline • Brief History • Problem Overview • Current Status • Recommendation 2 1
4/11/02 MANET and OSPF • A Mobile Ad Hoc Network (MANET) is a wireless network operating in absence of (much) fixed infrastructure – multi-hop, time-varying wireless channels • MANET WG produced four Experimental RFCs – none integrated with a commercial IGP • Why MANET and OSPF? – Interest in using MANETs in transit network scenarios (requiring redistribution) – Layer-2 MANET routing/bridging not always possible or optimal 3 A brief history • Initial problem statement drafted – draft-baker-manet-ospf-problem-statement-00 (expired) • Initial drafts on an OLSR-like adaptation of OSPF, and database exchange optimizations • WG decides to charter a design team (2004) – Meetings in San Diego and Washington, and design-team mailing list •Note: Expired drafts available at http://hipserver.mct.phantomworks.org/ietf/ospf/ 4 2
4/11/02 Initial problem statement 1. Focus on OSPFv3 and not OSPFv2 2. Compatibility with non-wireless OSPFv3 3. Intra-area extensions only 4. Not focusing on transit network case, but should not be precluded 5. Scaling goal is 50-100 nodes on wireless channel 6. Leverage existing MANET work where possible 7. Use RFC 3668 guidance on dealing with IPR claims 5 Benchmark results • Current OSPF benchmarked in MANET environment – draft-spagnolo-manet-ospf-design-00 (expired) LSU overhead evenly divided between floods and retransmissions 180 160 140 Overhead (Kb/s) 120 100 80 60 40 20 0 Hello LSU LSAck LSR D_DESC 6 3
4/11/02 Consensus reached • Working on defining a new MANET interface type rather than a MANET area type – in parallel with existing OSPF interface types • Focusing first on designing an optimized flooding mechanism for new LSA generation – using acknowledged (reliable) flooding – use Link Local Signaling (LLS) hello extensions • Focus on two active I-Ds – draft-chandra-ospf-manet-ext-03.txt – draft-ogier-manet-ospf-extension-05.txt • New complementary draft: – draft-roy-ospf-smart-peering-00.txt 7 Current status • Two developed approaches, no consensus on single approach forward – Not a lot of debate, either • Let’s look at the two approaches... 8 4
4/11/02 Overview of different approaches • Both drafts focus on selecting more efficient Relay Node Sets (RNS) for flooding – A “Connected Dominating Set” (CDS) • Both approaches perform topology reduction – MANET Designated Routers uses the CDS – Overlapping Relays via Smart Peering extension • Differences – Source Independent vs. Source Dependent CDS – Use of Hellos or LSAs for dissemination of two- hop neighborhood information – Differential (Incremental) Hello implementations 9 Review of draft-chandra* * from Proceedings of OSPF WG, IETF-60 10 5
4/11/02 Review of draft-ogier* * from Proceedings of OSPF WG, IETF 62 11 Design team evaluation software • Based on quagga open source OSPFv3 routing daemon – http://www.quagga.net • Runs as Unix implementation, or as GTNetS simulation (same quagga code) – http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/ • Implements both drafts, plus July version of Smart Peering Same Code quagga glue to quagga modified GTNets ospf6d modified User Space ospf6d zebra modified lib files netlink, sysctl, ioctl GTNetS I P (discrete event Kernel network simulator) drivers Simulation 12 Implementation 6
4/11/02 Simulation findings • Note: Technical Report and software available at – http://hipserver.mct.phantomworks.org/ietf/ospf • Combination of flooding efficiency and topology control seems necessary – Both approaches produce comparable gains in flooding efficiency – Topology reduction can make overhead scaling nearly linear with number of nodes • Topology reduction more straightforward with MDRs – MDR adjacencies anchored by CDS, similar to OSPF DR – Smart Peering uses heuristics to accomplish this, but currently published approach has limitations 13 Simulation findings • OSPF MANET Interface overhead improvements • GTNetS simulations Routing Traffic Overhead 6000 5000 Overhead (kbps) Legacy OSPF PTMP 4000 Gains due Cisco’s Overlapping Relays to efficient Efficient 3000 flooding flooding plus MDRs with full only adjacency adjacencies and full LSAs reduction 2000 MDRs with bi-connected adjacencies and full LSAs 1000 0 10 20 30 40 50 60 Number of Nodes 14 7
4/11/02 Simulation findings • Improvements do not sacrifice routing performance. User Data Delivery Ratio Route Quality 1 3 (Recv pkt + Fwd pkt)/(Recv Pkt) 0.96 2.6 Cisco’s Overlapping Relays Legacy OSPF PTMP Delivery Ratio 0.92 2.2 MDRs with bi-connected Legacy OSPF PTMP adjacencies and full LSAs Cisco’s Overlapping Relays 0.88 1.8 MDRs with bi-connected adjacencies and full LSAs 0.84 1.4 0.8 1 10 20 30 40 50 60 10 20 30 40 50 60 Number of Nodes Number of Nodes User data delivery ratio is high Reduced topology still with all three proposals yields good routes 15 Simulation findings • Nearly linear overhead scaling made possible by controlling the density of neighbor adjacencies Routing Traffic Overhead Neighbor Adjacencies 6000 30 Number of Adjacencies per Node 5000 25 4000 20 Overhead (kbps) MDRs with full MDRs with full adjacencies and full LSAs adjacencies and full LSAs 3000 15 2000 10 MDRs with bi-connected MDRs with bi-connected adjacencies and (B)MDR full LSAs adjacencies and (B)MDR full LSAs 1000 5 0 0 10 20 30 40 50 60 70 80 90 100 110 10 20 30 40 50 60 70 80 90 100 110 Number of Nodes Number of Nodes User data delivery ratio is high Reduced topology still with all three proposals yields good routes 16 8
4/11/02 Next steps recommended to OSPF WG • Design team not making further progress – Two viable approaches have been specified to a level of interoperability – Lack of agreement on the core approach for flooding (MDR vs. Overlapping Relays) – Either approach could consider some orthogonal elements from the other • e.g. two-hop neighbor discovery – Suggest to open this discussion somehow to broader OSPF/MANET WG community 17 OSPF WG discussion summary • Overall sentiment was that more evaluation of the two proposals is needed – Concern that simulation may not be comprehensive or accurate enough – Need to consider broader range of applicable mobility scenarios, stability of routes, robustness – This discussion will be on the OSPF WG main list, going forward 18 9
4/11/02 Links • Design Team software and Boeing technical report: – http://hipserver.mct.phantomworks.org/ietf/ospf/ • OSPF WG mailing list: – http://www.ietf.org/html.charters/ospf-charter.html 19 10
Recommend
More recommend