• BattleMeshV3
• BMX

OUTLINE BMX@WBMv3

• Background
• Propagating Reachability Information:
  • learning about other nodes exitence and profile

  • Metrics: identifying best routes
    (Distributed Hashes and Individual IDentifiers)

• Demonstration
  

  • Realtime, emulating a ~40 nodes virtual mesh network

  • configurable packet loss and delay
    - experiment demands from the audience
    
    

  (sorry for technical nature of this talk)

BACKGROUND BMX@WBMv3

• BMX (acronym for B.a.t.M.a.n - eXperimental)
• historically: experimental branch for testing new features for BATMAN
  • more configuration options, new mechanisms, ...
  • always executable as # batmand ath0
• generation III-IV temporary compatible to BATMAN

  • BMX v0.3 evolved towards an independent routing protocol:
    

    • some communities selected BMX for meshinh

      • (LugroMesh, GraciaSensefills, FFLeipzig, FFDresden, Nicaragua,..)

    • larges BATMAN/BMX network in Leipzig (~200 nodes) is BMX
  • Winner of Merakas' Routing Protocol Evalutation is BMX (comparing OLSR, BATMAN, BMX)
  • Since WBMv3 BMX v0.4 implementation...

Propagating Reachability Information Motivation and Ideas

• New Messages and logic to reduce Protocol Traffic Overhead and CPU load

  • Reduce traditional OriginatorMessage size to 4 bytes !!
    (<=> BABEL route update: SQN, Metric, IPv4/IPv6 Prefixes)

  • Use Hashes and Individual IDentifiers as node aliases

• Metrics
  • Individual Metrics for each node (at the same time!)

  • Roling Metric (like Ubuntu roloing releases)
    

Propagating Reachability Information

* General Objectives:

• - minimize Packet Loss -> find best end-to-end path between each nodes - minimize Convergence Time -> find it as fast as possible - minimize Protocol-Traffic Overhead -> with the least cost

* Typical Approach:

• - propagate Reachability Information (e.g. route updates)
  • .. causing Protocol-Traffic Overhead
  - use this Information to calculate best routes

* Typical Tradeoff:

• - send Routing Updates more often

  • -> reduce Convergence Time -> increase Protocol-Traffic Overhead

* Design Challenge for propagation:

• - summarize Reachability Information efficiently (into few bytes)

  • ( e.g. data-compression -> less data vs more CPU load )

  - roboustness against losses

* New Messages and logic to reduce Protocol Traffic Overhead and CPU load

Motivation for redesign of propagation mechanism (triggered by IPv6 support requests)

* Motivation for redesign of propagation mechanism

• (triggered by IPv6 support requests)

* Reachability Information contains

• - Node description (quite constant - not changing)
  • - IP address - Network Announcements (HNA) - service announcements
  - Metric Information (always changing)
  • - Sequence number - Path cost
  - Other logic: header, flags, ttl, timeouts, window-size, ...

* Example:

• Previously: Each BMX Originator Messages contained - Unique ID IPv4 32 bits | - Announcements [0,64,128,..] bits | description - flags, header, window-size,... 48 bits |

  - Sequence Number & path cost 16 bits | metricUpdate

• Best case 96 bits Typical case (IPv6, 1HNA..) ~ 300 bits

* Even in best case, 80 bits of each OGM is usually the same !! Useless??

1. Idea: Use Hash instead of constant description

2. Idea: Use Individual Identifier (IID) instead of Hash

Metric

Demonstration

Testbed