[Olsr-users] OLSR configuration for mobility.

Dan O'Keeffe (spam-protected)
Tue Aug 25 19:35:40 CEST 2015


Hello,
I have a few questions regarding the best version of OLSRd to use in a
mobile scenario, and also whether there are any best practices for
configuring OLSRd for mobility.

I'm currently using OLSRv1 0.6.3 (from the ppa at from ppa at
https://launchpad.net/~guardianproject/+archive/ubuntu/commotion). My
olsrd.conf is included at the end of this email.

1) Is OLSRv2 stable and if so is it now recommended to use OLSRv2 over
OLSRv1? Is the feature set of OLSRv2 strictly better than that of OLSRv1
(I'm only interested in features related to routing in a standalone MANET)?

2) Do OLSRv2 and/or versions of OLSRv1 > 0.6.3 offer any potential
performance improvements relevant to a mobile scenario? I'm thinking in
particular of a properly tested implementation of optimized flooding of
topology control/MPR selection messages (this forum post seems to
indicate OLSRv1 0.6.x is configured to flood messages by default:
http://olsr-users.olsr.narkive.com/pmZC1pta/doubts-about-willingness-mpr-selection-and-routing
). Any other major (routing related) bugfixes in OLSRv2 or OLSRv1 >
0.6.3 would also be of interest.

3) I'm doing some emulation experiments with a distributed application
in a MANET on top of the CORE/EMANE wireless network emulator. For my
experiments I use the OLSR version above as the routing protocol. I'm
having problems with OLSR performance where I see long periods with
effectively 0 bitrate between two nodes communicating over a TCP socket.
I suspect it is because the MANET routing is taking a long time to
converge after routes change, since my network is dense enough that
partitions shouldn't be that much of an issue. I made some changes to
the default 0.6.3 conf to reduce the validity times of various control
messages (HelloValidityTime 600.0 -> 60.0, TcValidityTime 300.0 -> 30.0,
MidValidityTime 300.0 -> 30.0). This seemed to make the routing more
responsive, but is this discourage for any reason? Are there any similar
configuration tips that I should be aware of to help cope with mobility?

Thanks for your help!
Dan


DebugLevel      0
InterfaceDefaults
{
  # Olsrd can autodetect changes in NIC configurations (IP address
  # changes etc.).  This is enabled by default and the interval to
  # poll for changes on is defined by NicChgsPollInt.  This polling
  # can be disabled pr. NIC by setting AutoDetectChanges to no.

  #AutoDetectChanges            no

  # IPv4 broadcast address to use. The
  # one usefull example would be 255.255.255.255
  # If not defined the broadcastaddress
  # every card is configured with is used

  Ip4Broadcast          255.255.255.255

  # IPv6 address scope to use.
  # Must be 'site-local' or 'global'

  #Ip6AddrType          site-local

  # IPv6 multicast address to use when
  # using site-local addresses.
  # If not defined, ff05::15 is used

  #Ip6MulticastSite             ff05::11

  # IPv6 multicast address to use when
  # using global addresses
  # If not defined, ff0e::1 is used

  #Ip6MulticastGlobal   ff0e::1


  # Emission intervals.
  # If not defined, RFC proposed values will
  # be used in most cases.

  # Hello interval in seconds(float)
    HelloInterval               6.0

  # HELLO validity time
    HelloValidityTime           60.0

  # TC interval in seconds(float)
    TcInterval                  0.5

  # TC validity time
    TcValidityTime              30.0

  # MID interval in seconds(float)
    MidInterval                 10.0

  # MID validity time
    MidValidityTime             30.0

  # HNA interval in seconds(float)
    HnaInterval                 10.0

  # HNA validity time
    HnaValidityTime             30.0

  # When multiple links exist between hosts
  # the weight of interface is used to determine
  # the link to use. Normally the weight is
  # automatically calculated by olsrd based
  # on the characteristics of the interface,
  # but here you can specify a fixed value.
  # Olsrd will choose links with the lowest value.

  #Weight 0


  # If a certain route should be preferred
  # or ignored by the mesh, the Link Quality
  # value of a node can be multiplied with a factor
  # entered here. In the example the route
  # using 192.168.0.1 would rather be ignored.
  # A multiplier of 0.5 will result in a small
  # (bad) LinkQuality value and a high (bad)
  # ETX value.

  #LinkQualityMult 192.168.0.1 0.5

  # This multiplier applies to all other nodes
  # LinkQualityMult default 0.8
}

## these settings should work for funkfeuer, freifunk, etc.
# Fisheye mechanism for TC messages 0=off, 1=on
LinkQualityFishEye 1
LinkQualityAlgorithm "etx_ff"

## if using commotionwireless.net, comment the line above and uncomment
these:
#LinkQualityFishEye 0


                                    #LinkQualityAlgorithm "etx_ffeth"

# IP version to use (4 or 6)

IpVersion       4

# Clear the screen each time the internal state changes

ClearScreen     yes

# HNA IPv4 routes
# syntax: netaddr netmask
# Example Internet gateway:
# 0.0.0.0 0.0.0.0

Hna4
{
#   Internet gateway:
#   0.0.0.0      0.0.0.0
#   more entries can be added:
#   192.168.1.0  255.255.255.0
}

# HNA IPv6 routes
# syntax: netaddr prefix
# Example Internet gateway:
Hna6
{
#   Internet gateway:
#   ::              0
#   more entries can be added:
#   fec0:2200:106:: 48
}


# Should olsrd keep on running even if there are
# no interfaces available? This is a good idea
# for a PCMCIA/USB hotswap environment.
# "yes" OR "no"

AllowNoInt      yes

# TOS(type of service) value for
# the IP header of control traffic.
# If not set it will default to 16

#TosValue       16

# The fixed willingness to use(0-7)
# If not set willingness will be calculated
# dynamically based on battery/power status
# if such information is available

Willingness     3


                                           109,1         39%

Willingness     3

# Allow processes like the GUI front-end
# to connect to the daemon.

IpcConnect
{
     # Determines how many simultaneously
     # IPC connections that will be allowed
     # Setting this to 0 disables IPC

     MaxConnections  0

     # By default only 127.0.0.1 is allowed
     # to connect. Here allowed hosts can
     # be added

     Host            127.0.0.1
     #Host            10.0.0.5

     # You can also specify entire net-ranges
     # that are allowed to connect. Multiple
     # entries are allowed

     #Net             192.168.1.0 255.255.255.0
}

# Wether to use hysteresis or not
# Hysteresis adds more robustness to the
# link sensing but delays neighbor registration.
# Used by default. 'yes' or 'no'
# Do not use hysteresis with ETX!

UseHysteresis   no

# Hysteresis parameters
# Do not alter these unless you know
# what you are doing!
# Set to auto by default. Allowed
# values are floating point values
# in the interval 0,1
# THR_LOW must always be lower than
# THR_HIGH.

#HystScaling    0.50
#HystThrHigh    0.80
#HystThrLow     0.30


# Link quality level
# 0 = do not use link quality
# 1 = use link quality for MPR selection
# 2 = use link quality for MPR selection and routing
# Defaults to 0

LinkQualityLevel        2

# Polling rate in seconds(float).
# Default value 0.05 sec

Pollrate        0.1


# TC redundancy
# Specifies how much neighbor info should
# be sent in TC messages
# Possible values are:
# 0 - only send MPR selectors
# 1 - send MPR selectors and MPRs
# 2 - send all neighbors
#
# defaults to 0

TcRedundancy    2


#
# MPR coverage
# Specifies how many MPRs a node should
# try select to reach every 2 hop neighbor
#
# Can be set to any integer >0
#
# defaults to 1

MprCoverage     5




~


~


~


~




More information about the Olsr-users mailing list