Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: MANET

RFC 3626

Optimized Link State Routing Protocol (OLSR)

Pages: 75
Part 3 of 3 – Pages 51 to 75
First   Prev   None

Top   ToC   RFC3626 - Page 51   prevText
12.  Non OLSR Interfaces

   A node MAY be equipped with multiple interfaces, some of which do not
   participate in the OLSR MANET.  These non OLSR interfaces may be
   point to point connections to other singular hosts or may connect to
   separate networks.

   In order to provide connectivity from the OLSR MANET interface(s) to
   these non OLSR interface(s), a node SHOULD be able to inject external
   route information to the OLSR MANET.

   Injecting routing information from the OLSR MANET to non OLSR
   interfaces is outside the scope of this specification.  It should be
   clear, however, that the routing information for the OLSR MANET can
   be extracted from the topology table (see section 4.4) or directly
   from the routing table of OLSR, and SHOULD be injected onto the non
   OLSR interfaces following whatever mechanism (routing protocol,
   static configuration etc.) is provided on these interfaces.

   An example of such a situation could be where a node is equipped with
   a fixed network (e.g., an Ethernet) connecting to a larger network as
   well as a wireless network interface running OLSR.

   Notice that this is a different case from that of "multiple
   interfaces", where all the interfaces are participating in the MANET
   through running the OLSR protocol.

   In order to provide this capability of injecting external routing
   information into an OLSR MANET, a node with such non-MANET interfaces
   periodically issues a Host and Network Association (HNA) message,
   containing sufficient information for the recipients to construct an
   appropriate routing table.
Top   ToC   RFC3626 - Page 52
12.1.  HNA Message Format

   The proposed format of an HNA-message is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      |                         Network Address                       |
      |                             Netmask                           |
      |                         Network Address                       |
      |                             Netmask                           |
      |                              ...                              |

   This is sent as the data part of the general packet format with the
   "Message Type" set to HNA_MESSAGE, the TTL field set to 255 and Vtime
   set accordingly to the value of HNA_HOLD_TIME, as specified in
   section 18.3.

     Network Address

          The network address of the associated network


          The netmask, corresponding to the network address immediately

12.2.  Host and Network Association Information Base

   Each node maintains information concerning which nodes may act as
   "gateways" to associated hosts and networks by recording "association
   tuples" (A_gateway_addr, A_network_addr, A_netmask, A_time), where
   A_gateway_addr is the address of an OLSR interface of the gateway,
   A_network_addr and A_netmask specify the network address and netmask
   of a network, reachable through this gateway, and A_time specifies
   the time at which this tuple expires and hence *MUST* be removed.

   The set of all association tuples in a node is called the
   "association set".

   It should be noticed, that the HNA-message can be considered as a
   "generalized version" of the TC-message: the originator of both the
   HNA- and TC-messages announce "reachability" to some other host(s).
Top   ToC   RFC3626 - Page 53
   In the TC-message, no netmask is required, since all reachability is
   announced on a per-host basis.  In HNA-messages, announcing
   reachability to an address sequence through a network- and netmask
   address is typically preferred over announcing reachability to
   individual host addresses.

   An important difference between TC- and HNA-messages is, that a TC
   message may have a canceling effect on previous information (if the
   ANSN is incremented), whereas information in HNA-messages is removed
   only upon expiration.

12.3.  HNA Message Generation

   A node with associated hosts and/or networks SHOULD periodically
   generate a Host and Network Association (HNA) message, containing
   pairs of (network address, netmask) corresponding to the connected
   hosts and networks.  HNA-messages SHOULD be transmitted periodically
   every HNA_INTERVAL.  The Vtime is set accordingly to the value of
   HNA_HOLD_TIME, as specified in section 18.3.

   A node without any associated hosts and/or networks SHOULD NOT
   generate HNA-messages.

12.4.  HNA Message Forwarding

   Upon receiving a HNA message, and thus following the rules of section
   3, in this version of the specification, the message MUST be
   forwarded according to section 3.4.

12.5.  HNA Message Processing

   In this section, the term "originator address" is used to designate
   the main address on the OLSR MANET of the node which originally
   issued the HNA-message.

   Upon processing a HNA-message, the "validity time" MUST be computed
   from the Vtime field of the message header (see section 3.3.2).  The
   association base SHOULD then be updated as follows:

   1    If the sender interface (NB: not originator) of this message
        is not in the symmetric 1-hop neighborhood of this node, the
        message MUST be discarded.

   2    Otherwise, for each (network address, netmask) pair in the
Top   ToC   RFC3626 - Page 54
        2.1  if an entry in the association set already exists, where:

                  A_gateway_addr == originator address

                  A_network_addr == network address

                  A_netmask      == netmask

             then the holding time for that tuple MUST be set to:

                  A_time         =  current time + validity time

        2.2  otherwise, a new tuple MUST be recorded with:

                  A_gateway_addr =  originator address

                  A_network_addr =  network address

                  A_netmask      =  netmask

                  A_time         =  current time + validity time

12.6.  Routing Table Calculation

   In addition to the routing table computation as described in section
   10, the host and network association set MUST be added as follows:

   For each tuple in the association set,

     1    If there is no entry in the routing table with:

               R_dest_addr     == A_network_addr/A_netmask

          then a new routing entry is created.

     2    If a new routing entry was created at the previous step, or
          else if there existed one with:

               R_dest_addr     == A_network_addr/A_netmask

               R_dist          >  dist to A_gateway_addr of
                                  current association set tuple,

          then the routing entry is modified as follows:

               R_dest_addr     =  A_network_addr/A_netmask
Top   ToC   RFC3626 - Page 55
               R_next_addr     =  the next hop on the path
                                  from the node to A_gateway_addr

               R_dist          =  dist to A_gateway_addr

               R_next_addr and R_iface_addr MUST be set to the same
               values as the tuple from the routing set with R_dest_addr
               == A_gateway_addr.

12.7.  Interoperability Considerations

   Nodes, which do not implement support for non OLSR interfaces, can
   coexist in a network with nodes which do implement support for non
   OLSR interfaces: the generic packet format and message forwarding
   (section 3) ensures that HNA messages are correctly forwarded by all
   nodes.  Nodes which implement support for non OLSR interfaces may
   thus transmit and process HNA messages according to this section.

   Nodes, which do not implement support for non OLSR interfaces can not
   take advantage of the functionality specified in this section,
   however they will forward HNA messages correctly, as specified in
   section 3.

13.  Link Layer Notification

   OLSR is designed not to impose or expect any specific information
   from the link layer.  However, if information from the link-layer
   describing link breakage is available, a node MAY use this as
   described in this section.

   If link layer information describing connectivity to neighboring
   nodes is available (i.e., loss of connectivity such as through
   absence of a link layer acknowledgment), this information is used in
   addition to the information from the HELLO-messages to maintain the
   neighbor information base and the MPR selector set.

   Thus, upon receiving a link-layer notification that the link between
   a node and a neighbor interface is broken, the following actions are
   taken with respect to link sensing:

   Each link tuple in the local link set SHOULD, in addition to what is
   described in section 4.2, include a L_LOST_LINK_time field.
   L_LOST_LINK_time is a timer for declaring a link as lost when an
   established link becomes pending.  (Notice, that this is a subset of
   what is recommended in section 14, thus link hysteresis and link
   layer notifications can coexist).
Top   ToC   RFC3626 - Page 56
   HELLO message generation should consider those new fields as follows:

     1    if L_LOST_LINK_time is not expired, the link is advertised
          with a link type of LOST_LINK.  In addition, it is not
          considered as a symmetric link in the updates of the
          associated neighbor tuple (see section 8.1).

     2    if the link to a neighboring symmetric or asymmetric interface
          is broken, the corresponding link tuple is modified:
          L_LOST_LINK_time and L_time are set to current time +

     3    this is considered as a link loss and the appropriate
          processing described in section 8.5 should be

13.1.  Interoperability Considerations

   Link layer notifications provide, for a node, an additional criterion
   by which a node may determine if a link to a neighbor node is lost.
   Once a link is detected as lost, it is advertised, in accordance with
   the provisions described in the previous sections of this

14.  Link Hysteresis

   Established links should be as reliable as possible to avoid data
   packet loss.  This implies that link sensing should be robust against
   bursty loss or transient connectivity between nodes.  Hence, to
   enhance the robustness of the link sensing mechanism, the following
   implementation recommendations SHOULD be considered.

14.1.  Local Link Set

   Each link tuple in the local link set SHOULD, in addition to what is
   described in section 4.2, include a L_link_pending field, a
   L_link_quality field, and a L_LOST_LINK_time field.  L_link_pending
   is a boolean value specifying if the link is considered pending
   (i.e., the link is not considered established).  L_link_quality is a
   dimensionless number between 0 and 1 describing the quality of the
   link.  L_LOST_LINK_time is a timer for declaring a link as lost when
   an established link becomes pending.
Top   ToC   RFC3626 - Page 57
14.2.  Hello Message Generation

   HELLO message generation should consider those new fields as follows:

     1    if L_LOST_LINK_time is not expired, the link is advertised
          with a link type of LOST_LINK.

     2    otherwise, if L_LOST_LINK_time is expired and L_link_pending
          is set to "true", the link SHOULD NOT be advertised at all;

     3    otherwise, if L_LOST_LINK_time is expired and L_link_pending
          is set to "false", the link is advertised as described
          previously in section 6.

   A node considers that it has a symmetric link for each link tuple

     1    L_LOST_LINK_time is expired, AND

     2    L_link_pending is "false", AND

     3    L_SYM_time is not expired.

   This definition for "symmetric link" SHOULD be used in updating the
   associated neighbor tuple (see section 8.1) for computing the
   N_status of a neighbor node.  This definition SHOULD thereby also be
   used as basis for the symmetric neighborhood when computing the MPR
   set, as well as for "the symmetric neighbors" in the first steps of
   the routing table calculation.

   Apart from the above, what has been described previously does not
   interfere with the advanced link sensing fields in the link tuples.
   The L_link_quality, L_link_pending and L_LOST_LINK_time fields are
   exclusively updated according to the present section.  This section
   does not modify the function of any other fields in the link tuples.

14.3.  Hysteresis Strategy

   The link between a node and some of its neighbor interfaces might be
   "bad", i.e., from time to time let HELLOs pass through only to fade
   out immediately after.  In this case, the neighbor information base
   would contain a bad link for at least "validity time".  The following
   hysteresis strategy SHOULD be adopted to counter this situation.

   For each neighbor interface NI heard by interface I, the
   L_link_quality field of the corresponding Link Tuple determines the
   establishment of the link.  The value of L_link_quality is compared
   to two thresholds HYST_THRESHOLD_HIGH, HYST_THRESHOLD_LOW, fixed
Top   ToC   RFC3626 - Page 58
   between 0 and 1 and such that HYST_THRESHOLD_HIGH >=

   The L_link_pending field is set according to the following:

     1    if L_link_quality > HYST_THRESHOLD_HIGH:

               L_link_pending   = false

               L_LOST_LINK_time = current time - 1 (expired)

     2    otherwise, if L_link_quality < HYST_THRESHOLD_LOW:

               L_link_pending   = true

               L_LOST_LINK_time = min (L_time, current time +

               (the link is then considered as lost according to section
               8.5 and this may produce a neighbor loss).

     3    otherwise, if HYST_THRESHOLD_LOW <= L_link_quality
                                           <= HYST_THRESHOLD_HIGH:

               L_link_pending and L_LOST_LINK_time remain unchanged.

   The condition for considering a link established is thus stricter
   than the condition for dropping a link.  Notice thus, that a link can
   be dropped based on either timer expiration (as described in section
   7) or on L_link_quality dropping below HYST_THRESHOLD_LOW.

   Also notice, that even if a link is not considered as established by
   the link hysteresis, the link tuples are still updated for each
   received HELLO message (as described in section 7).  Specifically,
   this implies that, regardless of whether or not the link hysteresis
   considers a link as "established", tuples in the link set do not
   expire except as determined by the L_time field of the link tuples.

   As a basic implementation requirement, an estimation of the link
   quality must be maintained and stored in the L_link_quality field.
   If some measure of the signal/noise level on a received message is
   available (e.g., as a link layer notification), then it can be used
   as estimation after normalization.

   If no signal/noise information or other link quality information is
   available from the link layer, an algorithm such as the following can
   be utilized (it is an exponentially smoothed moving average of the
   transmission success rate).  The algorithm is parameterized by a
Top   ToC   RFC3626 - Page 59
   scaling parameter HYST_SCALING which is a number fixed between 0 and
   1.  For each neighbor interface NI heard by interface I, the first
   time NI is heard by I, L_link_quality is set to HYST_SCALING
   (L_link_pending is set to true and L_LOST_LINK_time to current time -

   A tuple is updated according to two rules.  Every time an OLSR packet
   emitted by NI is received by I, the stability rule is applied:

          L_link_quality = (1-HYST_SCALING)*L_link_quality
                           + HYST_SCALING.

     When an OLSR packet emitted by NI is lost by I, the instability
     rule is applied:

          L_link_quality = (1-HYST_SCALING)*L_link_quality.

   The loss of OLSR packet is detected by tracking the missing Packet
   Sequence Numbers on a per interface basis and by "long period of
   silence" from a node.  A "long period of silence may be detected
   thus: if no OLSR packet has been received on interface I from
   interface NI during HELLO emission interval of interface NI (computed
   from the Htime field in the last HELLO message received from NI), a
   loss of an OLSR packet is detected.

14.4.  Interoperability Considerations

   Link hysteresis determines, for a node, the criteria at which a link
   to a neighbor node is accepted or rejected.  Nodes in a network may
   have different criteria, according to the nature of the media over
   which they are communicating.  Once a link is accepted, it is
   advertised, in accordance with the provisions described in the
   previous sections of this specification.

15.  Redundant Topology Information

   In order to provide redundancy to topology information base, the
   advertised link set of a node MAY contain links to neighbor nodes
   which are not in MPR selector set of the node.  The advertised link
   set MAY contain links to the whole neighbor set of the node.  The
   minimal set of links that any node MUST advertise in its TC messages
   is the links to its MPR selectors.  The advertised link set can be
   built according to the following rule based on a local parameter
   called TC_REDUNDANCY parameter.
Top   ToC   RFC3626 - Page 60
15.1.  TC_REDUNDANCY Parameter

   The parameter TC_REDUNDANCY specifies, for the local node, the amount
   of information that MAY be included in the TC messages.  The
   parameter SHOULD be interpreted as follows:

     -    if the TC_REDUNDANCY parameter of the node is 0, then the
          advertised link set of the node is limited  to the MPR
          selector set (as described in section 8.3),

     -    if the TC_REDUNDANCY parameter of the node is 1, then the
          advertised link set of the node is the union of its MPR set
          and its MPR selector set,

     -    if the TC_REDUNDANCY parameter of the node is 2, then the
          advertised link set of the node is the full neighbor link set.

   A node with willingness equal to WILL_NEVER SHOULD have TC_REDUNDANCY
   also equal to zero.

15.2.  Interoperability Considerations

   A TC message is sent by a node in the network to declare a set of
   links, called advertised link set, which MUST include at least the
   links to all nodes of its MPR Selector set, i.e., the neighbors which
   have selected the sender node as a MPR.  This is sufficient
   information to ensure that routes can be computed in accordance with
   section 10.

   The provisions in this section specifies how additional information
   may be declared, as specified through a TC_REDUNDANCY parameter.
   TC_REDUNDANCY = 0 implies that the information declared corresponds
   exactly to the MPR Selector set, identical to section 9.  Other
   values of TC_REDUNDANCY specifies additional information to be
   declared, i.e., the contents of the MPR Selector set is always
   declared.  Thus, nodes with different values of TC_REDUNDANCY may
   coexist in a network: control messages are carried by all nodes in
   accordance with section 3, and all nodes will receive at least the
   link-state information required to construct routes as described in
   section 10.

16.  MPR Redundancy

   MPR redundancy specifies the ability for a node to select redundant
   MPRs.  Section 4.5 specifies that a node should select its MPR set to
   be as small as possible, in order to reduce protocol overhead.  The
   criteria for selecting MPRs is, that all strict 2-hop nodes must be
   reachable through, at least, one MPR node.  Redundancy of the MPR set
Top   ToC   RFC3626 - Page 61
   affects the overhead through affecting the amount of links being
   advertised, the amount of nodes advertising links and the efficiency
   of the MPR flooding mechanism.  On the other hand, redundancy in the
   MPR set ensures that reachability for a node is advertised by more
   nodes, thus additional links are diffused to the network.

   While, in general, a minimal MPR set provides the least overhead,
   there are situations in which overhead can be traded off for other
   benefits.  For example, a node may decide to increase its MPR
   coverage if it observes many changes in its neighbor information base
   caused by mobility, while otherwise keeping a low MPR coverage.

16.1.  MPR_COVERAGE Parameter

   The MPR coverage is defined by a single local parameter,
   MPR_COVERAGE, specifying by how many MPR nodes any strict 2-hop node
   should be covered.  MPR_COVERAGE=1 specifies that the overhead of the
   protocol is kept at a minimum and causes the MPR selection to operate
   as described in section 8.3.1.  MPR_COVERAGE=m ensures that, if
   possible, a node selects its MPR set such that all strict 2-hop nodes
   for an interface are reachable through at least m MPR nodes on that
   interface.  MPR_COVERAGE can assume any integer value > 0.  The
   heuristic MUST be applied per interface, I.  The MPR set for a node
   is the union of the MPR sets found for each interface.

   Notice that MPR_COVERAGE can be tuned locally without affecting the
   consistency of the protocol.  For example, nodes in a network may
   operate with different values of MPR_COVERAGE.

16.2.  MPR Computation

   Using MPR coverage, the MPR selection heuristics is extended from
   that described in the section 8.3.1 by one definition:

     Poorly covered node:

          A poorly covered node is a node in N2 which is covered by less
          than MPR_COVERAGE nodes in N.

   The proposed heuristic for selecting MPRs is then as follows:

     1    Start with an MPR set made of all members of N with
          willingness equal to WILL_ALWAYS

     2    Calculate D(y), where y is a member of N, for all nodes in N.
Top   ToC   RFC3626 - Page 62
     3    Select as MPRs those nodes in N which cover the poorly covered
          nodes in N2.  The nodes are then removed from N2 for the rest
          of the computation.

     4    While there exist nodes in N2 which are not covered by at
          least MPR_COVERAGE nodes in the MPR set:

          4.1  For each node in N, calculate the reachability, i.e.,
               the number of nodes in N2 which are not yet covered
               by at least MPR_COVERAGE nodes in the MPR set, and
               which are reachable through this 1-hop neighbor;

          4.2  Select as a MPR the node with highest willingness among
               the nodes in N with non-zero reachability.  In case of
               multiple choice select the node which provides
               reachability to the maximum number of nodes in N2.  In
               case of multiple nodes providing the same amount of
               reachability, select the node as MPR whose D(y) is
               greater.  Remove the nodes from N2 which are now covered
               by MPR_COVERAGE nodes in the MPR set.

     5    A node's MPR set is generated from the union of the MPR sets
          for each interface.  As an optimization, process each node, y,
          in the MPR set in increasing order of N_willingness.  If all
          nodes in N2 are still covered by at least MPR_COVERAGE nodes
          in the MPR set excluding node y, and if N_willingness of node
          y is smaller than WILL_ALWAYS, then node y MAY be removed from
          the MPR set.

   When the MPR set has been computed, all the corresponding main
   addresses are stored in the MPR Set.

16.3.  Interoperability Considerations

   The MPR set of a node MUST, according to section 8.3, be calculated
   by a node in such a way that it, through the neighbors in the MPR-
   set, can reach all symmetric strict 2-hop neighbors.  This is
   achieved by the heuristics in this section, for all values of
   MPR_COVERAGE > 0.  MPR_COVERAGE is a local parameter for each node.
   Setting this parameter affects only the amount of redundancy in part
   of the network.

   Notice that for MPR_COVERAGE=1, the heuristics in this section is
   identical to the heuristics specified in the section 8.3.1.
Top   ToC   RFC3626 - Page 63
   Nodes with different values of MPR_COVERAGE may coexist in a network:
   control messages are carried by all nodes in accordance with section
   3, and all nodes will receive at least the link-state information
   required to construct routes as described in sections 9 and 10.

17.  IPv6 Considerations

   All the operations and parameters described in this document used by
   OLSR for IP version 4 are the same as those used by OLSR for IP
   version 6.  To operate with IP version 6, the only required change is
   to replace the IPv4 addresses with IPv6 address.  The minimum packet
   and message sizes (under which there is rejection) should be adjusted
   accordingly, considering the greater size of IPv6 addresses.

18.  Proposed Values for Constants

   This section list the values for the constants used in the
   description of the protocol.

18.1.  Setting emission intervals and holding times

   The proposed constant for C is the following:

          C = 1/16 seconds (equal to 0.0625 seconds)

   C is a scaling factor for the "validity time" calculation ("Vtime"
   and "Htime" fields in message headers, see section 18.3).  The
   "validity time" advertisement is designed such that nodes in a
   network may have different and individually tuneable emission
   intervals, while still interoperate fully.  For protocol functioning
   and interoperability to work:

     -    the advertised holding time MUST always be greater than the
          refresh interval of the advertised information.  Moreover, it
          is recommended that the relation between the interval (from
          section 18.2), and the hold time is kept as specified
          in section 18.3, to allow for reasonable packet loss.

     -    the constant C SHOULD be set to the suggested value.  In order
          to achieve interoperability, C MUST be the same on all nodes.

     -    the emission intervals (section 18.2), along with the
          advertised holding times (subject to the above constraints)
          MAY be selected on a per node basis.

   Note that the timer resolution of a given implementation might not be
   sufficient to wake up the system on precise refresh times or on
   precise expire times: the implementation SHOULD round up the
Top   ToC   RFC3626 - Page 64
   'validity time' ("Vtime" and "Htime" of packets) to compensate for
   coarser timer resolution, at least in the case where "validity time"
   could be shorter than the sum of emission interval and maximum
   expected timer error.

18.2.  Emission Intervals

          HELLO_INTERVAL        = 2 seconds

          REFRESH_INTERVAL      = 2 seconds

          TC_INTERVAL           = 5 seconds

          MID_INTERVAL          = TC_INTERVAL

          HNA_INTERVAL          = TC_INTERVAL

18.3.  Holding Time


          TOP_HOLD_TIME         = 3 x TC_INTERVAL

          DUP_HOLD_TIME         = 30 seconds

          MID_HOLD_TIME         = 3 x MID_INTERVAL

          HNA_HOLD_TIME         = 3 x HNA_INTERVAL

   The Vtime in the message header (see section 3.3.2), and the Htime in
   the HELLO message (see section 6.1) are the fields which hold
   information about the above values in mantissa and exponent format
   (rounded up).  In other words:

     value = C*(1+a/16)*2^b [in seconds]

   where a is the integer represented by the four highest bits of the
   field and b the integer represented by the four lowest bits of the

   Notice, that for the previous proposed value of C, (1/16 seconds),
   the values, in seconds, expressed by the formula above can be stored,
   without loss of precision, in binary fixed point or floating point
   numbers with at least 8 bits of fractional part.  This corresponds
   with NTP time-stamps and single precision IEEE Standard 754 floating
   point numbers.
Top   ToC   RFC3626 - Page 65
   Given one of the above holding times, a way of computing the
   mantissa/exponent representation of a number T (of seconds) is the

     -    find the largest integer 'b' such that: T/C >= 2^b

     -    compute the expression 16*(T/(C*(2^b))-1), which may not be a
          integer, and round it up.  This results in the value for 'a'

     -    if 'a' is equal to 16: increment 'b' by one, and set 'a' to 0

     -    now, 'a' and 'b' should be integers between 0 and 15, and the
          field will be a byte holding the value a*16+b

   For instance, for values of 2 seconds, 6 seconds, 15 seconds, and 30
   seconds respectively, a and b would be: (a=0,b=5), (a=8,b=6),
   (a=14,b=7) and (a=14,b=8) respectively.

18.4.  Message Types

          HELLO_MESSAGE         = 1

          TC_MESSAGE            = 2

          MID_MESSAGE           = 3

          HNA_MESSAGE           = 4

18.5.  Link Types

          UNSPEC_LINK           = 0

          ASYM_LINK             = 1

          SYM_LINK              = 2

          LOST_LINK             = 3

18.6.  Neighbor Types

          NOT_NEIGH             = 0

          SYM_NEIGH             = 1

          MPR_NEIGH             = 2
Top   ToC   RFC3626 - Page 66
18.7.  Link Hysteresis

          HYST_THRESHOLD_HIGH   = 0.8

          HYST_THRESHOLD_LOW    = 0.3

          HYST_SCALING          = 0.5

18.8.  Willingness

          WILL_NEVER            = 0

          WILL_LOW              = 1

          WILL_DEFAULT          = 3

          WILL_HIGH             = 6

          WILL_ALWAYS           = 7

   The willingness of a node may be set to any integer value from 0 to
   7, and specifies how willing a node is to be forwarding traffic on
   behalf of other nodes.  Nodes will, by default, have a willingness
   WILL_DEFAULT.  WILL_NEVER indicates a node which does not wish to
   carry traffic for other nodes, for example due to resource
   constraints (like being low on battery).  WILL_ALWAYS indicates that
   a node always should be selected to carry traffic on behalf of other
   nodes, for example due to resource abundance (like permanent power
   supply, high capacity interfaces to other nodes).

   A node may dynamically change its willingness as its conditions

   One possible application would, for example, be for a node, connected
   to a permanent power supply and with fully charged batteries, to
   advertise a willingness of WILL_ALWAYS.  Upon being disconnected from
   the permanent power supply (e.g., a PDA being taken out of its
   charging cradle), a willingness of WILL_DEFAULT is advertised.  As
   battery capacity is drained, the willingness would be further
   reduced.  First to the intermediate value between WILL_DEFAULT and
   WILL_LOW, then to WILL_LOW and finally to WILL_NEVER, when the
   battery capacity of the node does no longer support carrying foreign
Top   ToC   RFC3626 - Page 67
18.9.  Misc. Constants

          TC_REDUNDANCY         = 0

          MPR COVERAGE          = 1

          MAXJITTER             = HELLO_INTERVAL / 4

19.  Sequence Numbers

   Sequence numbers are used in OLSR with the purpose of discarding
   "old" information, i.e., messages received out of order.  However
   with a limited number of bits for representing sequence numbers,
   wrap-around (that the sequence number is incremented from the maximum
   possible value to zero) will occur.  To prevent this from interfering
   with the operation of the protocol, the following MUST be observed.

   The term MAXVALUE designates in the following the largest possible
   value for a sequence number.

   The sequence number S1 is said to be "greater than" the sequence
   number S2 if:

          S1 > S2 AND S1 - S2 <= MAXVALUE/2 OR

          S2 > S1 AND S2 - S1 > MAXVALUE/2

   Thus when comparing two messages, it is possible - even in the
   presence of wrap-around - to determine which message contains the
   most recent information.

20.  Security Considerations

   Currently, OLSR does not specify any special security measures.  As a
   proactive routing protocol, OLSR makes a target for various attacks.
   The various possible vulnerabilities are discussed in this section.

20.1.  Confidentiality

   Being a proactive protocol, OLSR periodically diffuses topological
   information.  Hence, if used in an unprotected wireless network, the
   network topology is revealed to anyone who listens to OLSR control
Top   ToC   RFC3626 - Page 68
   In situations where the confidentiality of the network topology is of
   importance, regular cryptographic techniques such as exchange of OLSR
   control traffic messages encrypted by PGP [9] or encrypted by some
   shared secret key can be applied to ensure that control traffic can
   be read and interpreted by only those authorized to do so.

20.2.  Integrity

   In OLSR, each node is injecting topological information into the
   network through transmitting HELLO messages and, for some nodes, TC
   messages.  If some nodes for some reason, malicious or malfunction,
   inject invalid control traffic, network integrity may be compromised.
   Therefore, message authentication is recommended.

   Different such situations may occur, for instance:

     1    a node generates TC (or HNA) messages, advertising links to
          non-neighbor nodes:

     2    a node generates TC (or HNA) messages, pretending to be
          another node,

     3    a node generates HELLO messages, advertising non-neighbor

     4    a node generates HELLO messages, pretending to be another

     5    a node forwards altered control messages,

     6    a node does not broadcast control messages,

     7    a node does not select multipoint relays correctly.

     8    a node forwards broadcast control messages unaltered, but does
          not forward unicast data traffic;

     9    a node "replays" previously recorded control traffic from
          another node.

   Authentication of the originator node for control messages (for
   situation 2, 4 and 5) and on the individual links announced in the
   control messages (for situation 1 and 3) may be used as a
   countermeasure.  However to prevent nodes from repeating old (and
   correctly authenticated) information (situation 9) temporal
   information is required, allowing a node to positively identify such
   delayed messages.
Top   ToC   RFC3626 - Page 69
   In general, digital signatures and other required security
   information may be transmitted as a separate OLSR message type,
   thereby allowing that "secured" and "unsecured" nodes can coexist in
   the same network, if desired.

   Specifically, the authenticity of entire OLSR control messages can be
   established through employing IPsec authentication headers, whereas
   authenticity of individual links (situation 1 and 3) require
   additional security information to be distributed.

   An important consideration is, that all control messages in OLSR are
   transmitted either to all nodes in the neighborhood (HELLO messages)
   or broadcast to all nodes in the network (e.g., TC messages).

   For example, a control message in OLSR is always a point-to-
   multipoint transmission.  It is therefore important that the
   authentication mechanism employed permits that any receiving node can
   validate the authenticity of a message.  As an analogy, given a block
   of text, signed by a PGP private key, then anyone with the
   corresponding public key can verify the authenticity of the text.

20.3.  Interaction with External Routing Domains

   OLSR does, through the HNA messages specified in section 12, provide
   a basic mechanism for injecting external routing information to the
   OLSR domain.  Section 12 also specifies that routing information can
   be extracted from the topology table or the routing table of OLSR
   and, potentially, injected into an external domain if the routing
   protocol governing that domain permits.

   Other than as described in the section 20.2, when operating nodes,
   connecting OLSR to an external routing domain, care MUST be taken not
   to allow potentially insecure and un-trustworthy information to be
   injected from the OLSR domain to external routing domains.  Care MUST
   be taken to validate the correctness of information prior to it being
   injected as to avoid polluting routing tables with invalid

   A recommended way of extending connectivity from an existing routing
   domain to an OLSR routed MANET is to assign an IP prefix (under the
   authority of the nodes/gateways connecting the MANET with the exiting
   routing domain) exclusively to the OLSR MANET area, and to configure
   the gateways statically to advertise routes to that IP sequence to
   nodes in the existing routing domain.
Top   ToC   RFC3626 - Page 70
20.4.  Node Identity

   OLSR does not make any assumption about node addresses, other than
   that each node is assumed to have a unique IP address.

21.  Flow and congestion control

   Due to its proactive nature, the OLSR protocol has a natural control
   over the flow of its control traffic.  Nodes transmits control
   message at predetermined rates fixed by predefined refresh intervals.
   Furthermore the MPR optimization greatly saves on control overhead,
   and this is done on two sides.  First, the packets that advertise the
   topology are much shorter since only MPR selectors may be advertised.
   Second, the cost of flooding this information is greatly reduced
   since only MPR nodes forward the broadcast packets.  In dense
   networks, the reduction of control traffic can be of several orders
   of magnitude compared to routing protocols using classical flooding
   (such as OSPF) [10].  This feature naturally provides more bandwidth
   for useful data traffic and pushes further the frontier of
   congestion.  Since the control traffic is continuous and periodic, it
   keeps more stable the quality of the links used in routing, where
   reactive protocols, with bursty floodings for route discoveries and
   repairs, may damage the link qualities for short times by causing
   numerous collisions on those links, possibly provoking route repair
   cascades.  However, in certain OLSR options, some control messages
   may be intentionally sent in advance of their deadline(TC or Hello
   messages) in order to increase the reactiveness of the protocol
   against topology changes.  This may cause a small, temporary and
   local increase of control traffic.

22.  IANA Considerations

   OLSR defines a "Message Type" field for control messages.  A new
   registry has been created for the values for this Message Type field,
   and the following values assigned:

       Message Type             Value
      --------------------      -----
       HELLO_MESSAGE              1
       TC_MESSAGE                 2
       MID_MESSAGE                3
       HNA_MESSAGE                4

   Future values in the range 5-127 of the Message Type can be allocated
   using standards action [7].

   Additionally, values in the range 128-255 are reserved for
   private/local use.
Top   ToC   RFC3626 - Page 71
23.  Acknowledgments

   The authors would like to thank Joseph Macker
   <> and his team, including Justin Dean
   <>, for their valuable suggestions on the
   advanced neighbor sensing mechanism and other various aspects of the
   protocol, including careful review of the protocol specification.

   The authors would also like to thank Christopher Dearlove
   <> for valuable input on the MPR
   selection heuristics and for careful reviews of the protocol

24.  Contributors

   During the development of this specification, the following list of
   people contributed.  The contributors are listed alphabetically.

   Cedric Adjih
   Project HIPERCOM
   INRIA Rocquencourt, BP 105
   78153 Le Chesnay Cedex, France

   Phone: +33 1 3963 5215

   Thomas Heide Clausen
   Project HIPERCOM
   INRIA Rocquencourt, BP 105
   78153 Le Chesnay Cedex, France

   Phone: +33 1 3963 5133

   Philippe Jacquet
   Project HIPERCOM
   INRIA Rocquencourt, BP 105
   78153 Le Chesnay Cedex, France

   Phone: +33 1 3963 5263
Top   ToC   RFC3626 - Page 72
   Anis Laouiti
   Project HIPERCOM
   INRIA Rocquencourt, BP 105
   78153 Le Chesnay Cedex, France

   Phone: +33 1 3963 5088

   Pascale Minet
   Project HIPERCOM
   INRIA Rocquencourt, BP 105
   78153 Le Chesnay Cedex, France

   Phone: +33 1 3963 5233

   Paul Muhlethaler
   Project HIPERCOM
   INRIA Rocquencourt, BP 105
   78153 Le Chesnay Cedex, France

   Phone: +33 1 3963 5278

   Amir Qayyum
   Center for Advanced Research in Engineering Pvt. Ltd.
   19 Ataturk Avenue
   Islamabad, Pakistan

   Phone: +92-51-2874115

   Laurent Viennot
   Project HIPERCOM
   INRIA Rocquencourt, BP 105
   78153 Le Chesnay Cedex, France

   Phone: +33 1 3963 5225
Top   ToC   RFC3626 - Page 73
25.  References

25.1.  Normative References

   [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [7]   T.  Clausen, P.  Jacquet, A.  Laouiti, P.  Muhlethaler, A.
         Qayyum and L.  Viennot.  Optimized Link State Routing Protocol.
         IEEE INMIC Pakistan 2001.

25.2.  Informative References

   [1]   P. Jacquet, P. Minet, P. Muhlethaler, N. Rivierre.  Increasing
         reliability in cable free radio LANs: Low level forwarding in
         HIPERLAN.  Wireless Personal Communications, 1996.

   [2]   A.  Qayyum, L.  Viennot, A.  Laouiti.  Multipoint relaying: An
         efficient technique for flooding in mobile wireless networks.
         35th Annual Hawaii International Conference on System Sciences

   [3]   ETSI STC-RES10 Committee.  Radio equipment and systems:
         HIPERLAN type 1, functional specifications ETS 300-652, ETSI,
         June 1996.

   [4]   P. Jacquet and L. Viennot, Overhead in Mobile Ad-hoc Network
         Protocols, INRIA research report RR-3965, 2000.

   [6]   T. Clausen, G. Hansen, L. Christensen and G. Behrmann.  The
         Optimized Link State Routing Protocol, Evaluation through
         Experiments and Simulation.  IEEE Symposium on "Wireless
         Personal Mobile Communications", September 2001.

   [8]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs",  BCP 26, RFC 2434, October

   [9]   Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message
         Exchange Formats", RFC 1991, August 1996.

   [10]  P. Jacquet, A. Laouiti, P. Minet, L. Viennot.  Performance
         analysis of OLSR multipoint relay flooding in two ad hoc
         wireless network models, INRIA research report RR-4260, 2001.
Top   ToC   RFC3626 - Page 74
26.  Authors' Addresses

   Thomas Heide Clausen
   Project HIPERCOM
   INRIA Rocquencourt, BP 105
   78153 Le Chesnay Cedex, France

   Phone: +33 1 3963 5133

   Philippe Jacquet,
   Project HIPERCOM,
   INRIA Rocquencourt, BP 105
   78153 Le Chesnay Cedex, France

   Phone: +33 1 3963 5263,
Top   ToC   RFC3626 - Page 75
27.  Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an


   Funding for the RFC Editor function is currently provided by the
   Internet Society.