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

* 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

* 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