'''OUTLINE'''                                                              BMX@WBMv3

 * Background

 * Propagating Reachability Information:
  * learning about other nodes exitence and profile
  * Metrics: identifying best routes<<BR>>  (Distributed Hashes and Individual IDentifiers)

 * Demonstration<<BR>>
  * Realtime, emulating a ~40 nodes virtual mesh network
  * configurable packet loss and delay<<BR>>  - experiment demands from the audience<<BR>><<BR>>
 (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:<<BR>>
   * 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 !!'''<<BR>>     (<=> 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)<<BR>>

'''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'''