'''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 '''I'''ndividual '''ID'''entifiers 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'''