Dynamic Routing Lecturer: Carlos Rey-Moreno carlos.reymoreno@gmail.com Networking Course Honors on Computer Science University of the Western Cape 18 Feb - 2013
Static vs Dynamic Routing Static Routing Dynamic Routing Creation of routing table Manual Automatic Difficulty High Low Control over the routes High (static) Limited (dynamic) Share routing information No Yes Memory /CPU overhead Low Medium Bandwidth overhead Low Medium Fault Tolerant No Yes Administrative Distance 1 Protocol specific
Dynamic Routing Categories There are two distinct categories of dynamic routing protocols: Distance-vector protocols Examples: RIP and IGRP Link-state protocols Examples: OSPF and IS-IS.
Distance Vector Protocols Key characteristics: Periodic updates of the full routing table (connected and learned routes) are sent to routing neighbors. Some form of distance is used to calculate a route s metric. RIP uses hopcount, and IGRP uses a composite of bandwidth and delay. Suffer from slow convergence 'Route by rumor' -> are highly susceptible to loops.
Distance Vector Protocols
Link-state Protocols Were developed to alleviate the convergence and loop issues of distance-vector protocols. It maintains three separate tables: Neighbor table contains a list of all neighbors, and the interface each neighbor is connected off of. Neighbors are formed by sending Hello packets. Topology table otherwise known as the linkstate table, contains a map of all links within an area, including each link s status. Shortest-Path table contains the best routes to each particular destination (otherwise known as the routing table )
Link-State Protocols
Wireless Dynamic Routing Protocols Classical routing protocols is that they are typically not well suited for wireless ad-hoc networks. Ad-hoc (mesh) networks are unstructured, dynamically change their topology, and are based on an inherently unreliable medium. Two types: Reactive (on demand): AODV and DSR Proactive: OLSR and B.A.T.M.A.N. 8
OLSR It is the currently most employed protocol for such scenarios Hello packets to discover 2-hop neighbors Distributed election of Multipoinf Relays (MPR) There exists a path to each of its 2-hop neighbors via a node selected as an MPR. MPR nodes then source and forward TC (topology control) messages that contain the MPR selectors. Not all links are advertised, not everyone advertise (only MPRs) Unreliable flooding 9
OLSR Limits of this algorithm Nodes need to be up all the time to keep the real routing table Use of resources (Hello and TC pcakets) Big mesh networks and requirement of a linkstate algorithm to recalculate the whole topology-graph Recalculating the whole topology graph once in an actual mesh with 450 nodes takes several seconds on a small embedded CPU (the normal one on wireless routers) 10
B.A.T.M.A.N. B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is a routing protocol for multi-hop ad-hoc mesh networks. The approach is to divide the knowledge about the best endto-end paths between nodes in the mesh to all participating nodes. Each node perceives and maintains only the information about the best next hop towards all other nodes. An event-based flooding mechanism prevents the accruement of contradicting topology information and limits the amount of topology messages flooding the mesh Avoids loops, overhead of control traffic & optimizes routing decisions Info, documentation, downloads: http://www.open-mesh.org/ 11
B.A.T.M.A.N algorithm Each node transmits broadcast messages (originator messages or OGMs) to inform the neighboring nodes about it's existence. Neighbors re-broadcast the OGMs according to specific rules to inform their neighbors about the existence of the original initiator of this message and so on. Thus the network is flooded with OGMs messages. OGMs are small, the typical raw packet size is 28 byte OGMs contain at least the address of the originator, the address of the node transmitting the packet, a TTL and a sequence number. A node sends an OGM by default each 1000 ms (1 second). 12
Processing the OGMs OGMs from a path with low quality will suffer more from packetloss or delay than those through faster and more reliable links. The sequence number tells it the OGM has been received once or more than once. Only the first one will be kept. Each node re-broadcasts each received OGM at most once and only those received from the neighbor which has been identified as the currently best next hop (best ranking neighbor) towards the original initiator of the OGM. The algorithm selects this neighbor as the currently best next hop to the originator of the message and configures its routing table respectively 13
Administrative Distance in BATMAN In B.A.T.M.A.N the concept is Transmission Quality (TQ). But how do we calculate it? With the Receive Quality (Received vs Expected) EQ= TQ*RQ => Local TQ=EQ/RQ And the Echo Quality (Generated vs Received in rebroadcast) 14
Path TQ OGM are generated with TQ 100% (255) Each node applies its own (local) TQ to the neighbor which sent the packet, before retransmitting Path TQ = Local TQ * Path TQ 15
OGM rebroadcast It only retransmits info about the best next node towards a destination. OGMs received within 100ms are aggregated 16
Penalization to TQ Asymmetry of links (on the Tx side) Interference on the Rx side (accounted in TQ) High RQ, low EQ (OGM dropped by interference) TQ low Interference on the Tx side. Similar RQ and similar EQ TQ High Hop Penalty Path TQ = Path TQ * (1 - HopPenalty) (default is 0.03) 17
Visualizing routing table (batctl o) [B.A.T.M.A.N. adv 2011.2.0, MainIF/MAC: ath0/00:09:45:5b:69:ae (bat0)] Originator last-seen (#/255) Nexthop [outgoingif]: Potential nexthops... 10.130.1.31 0.220s ( 76) 10.130.1.29 [ ath0]: 10.130.1.24 ( 29) 10.130.1.28 ( 37) 10.130.1.29 ( 76) 10.130.1.22 0.600s ( 86) 10.130.1.29 [ ath0]: 10.130.1.24 ( 32) 10.130.1.29 ( 86) 10.130.1.28 ( 43) 10.130.1.20 0.560s (177) 10.130.1.29 [ ath0]: 10.130.1.24 ( 58) 10.130.1.29 (177) 10.130.1.28 ( 77) 10.130.1.23 0.480s ( 93) 10.130.1.29 [ ath0]: 10.130.1.24 ( 34) 10.130.1.29 ( 93) 10.130.1.28 ( 43) 10.130.1.1 0.590s ( 73) 10.130.1.29 [ ath0]: 10.130.1.24 ( 28) 10.130.1.28 ( 32) 10.130.1.29 ( 73) 10.1.130.25 0.100s (207) 10.130.1.29 [ ath0]: 10.130.1.24 ( 0) 10.130.1.29 (207) 10.130.1.28 ( 77) 10.130.1.21 0.730s (100) 10.130.1.29 [ ath0]: 10.130.1.24 ( 39) 10.130.1.29 (100) 10.130.1.28 ( 47) 10.130.1.24 0.590s (217) 10.130.1.29 [ ath0]: 10.130.1.28 (107) 10.130.1.29 (217) 10.130.1.24 ( 84) 10.130.1.28 0.450s (220) 10.130.1.29 [ ath0]: 10.130.1.24 ( 71) 10.130.1.29 (220) 10.130.1.28 (115) 10.130.1.29 0.220s (242) 10.130.1.29 [ ath0]: 10.130.1.24 ( 71) 10.130.1.28 ( 89) 10.130.1.29 (242) 18
Real example 19
What do we see? Nowayilesi's MP (26) is down The connection with Headman's MP (20) is as weak as for getting OGMs through All the communications go through Scooter's MP (29) It has very good TQ to 24, 28 and 28 (even through 29, remember Hop Penalty) and week with the rest. 20
An small issue (default mtu not enough) batman-adv inserts an additional header of 28 bytes into each data packet being send over the mesh. We are increasing the maximum size of a packet over the plain interfaces to 1528, so that packets with the standard MTU of 1500 can pass normaly through bat0. That means that the mtu option need to be change in the physical interface running batman-adv. In our case is over the WiFi interface, which name is wifi0. 21
Parameters we can tweak By default (in /etc/config/batman-adv): orig_interval Default : 1s. No need for so many if nodes are not going to move aggregated_ogms Default: enables. It should reduce bandwidth overhead and collisions. hop_penalty Default: 30. It should be ok for most scenarios. 22
Parameters we can tweak Inside the code (main.h) BATADV_MAX_AGGREGATION_MS 100 The bigger the period the smaller the number of packets BATADV_TQ_LOCAL_WINDOW_SIZE 64 The bigger the window, the bigger the influence of the past (bad for mobility) BATADV_TQ_GLOBAL_WINDOW_SIZE 5.. For averaging the TQ to a given node from distinct neighbors. 23
Other ideas Variable Hop Penalty depending on the rate Not taking 30 all the time, but checking the rate you can use with the neighbor and penalize more for slower rates. Reward routes that avoid the hidden node problem. Penalizing those routes where the hidden node problem may happen 24
Ways of implementing it Batman has been implemented via: batmand, a daemon running at IP layer doing traditional dynamic routing Batman-adv, a kernel module above the MAC layer that creates bridged networks among the batman-adv interfaces. We are going to focus in batman-adv that is the one getting more support and updates (batmand stop 3 years ago) 25