INTERNET-DRAFT                                              Cedric Adjih
IETF MANET Working Group                                  Thomas Clausen
Expiration: 03 September 15 October 2003                             Philippe Jacquet
                                                            Anis Laouiti
                                                           Pascale Minet
                                                        Paul Muhlethaler
                                                             Amir Qayyum
                                                         Laurent Viennot
                                              INRIA Rocquencourt, France
                                                           03 March
                                                           15 April 2003

                 Optimized Link State Routing Protocol

                      draft-ietf-manet-olsr-08.txt

                      draft-ietf-manet-olsr-09.txt

Status of this Memo

   This document is a submission by the Mobile Ad Hoc Networking Working
   Group of the Internet Engineering Task Force (IETF).  Comments should
   be submitted to the manet@itd.nrl.navy.mil mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts. Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document describes the Optimized Link State Routing (OLSR)
   protocol for mobile ad hoc networks.  The protocol is an optimization
   of the classical link state algorithm tailored to the requirements of
   a mobile wireless LAN.  The key concept used in the protocol is that
   of multipoint relays (MPRs) [1], [2].  MPRs are selected nodes which
   forward broadcast messages during the flooding process.  This
   technique substantially reduces the message overhead as compared to a
   classical flooding mechanism, where every node retransmits each
   message when it receives the first copy of the message.  In OLSR,
   link state information is generated only by nodes elected as MPRs.
   Thus, a second optimization is achieved by minimizing the number of
   control messages flooded in the network.  As a third optimization, an
   MPR node may chose to report only links between itself and its MPR
   selectors.  Hence, as contrary to the classic link state algorithm,
   partial link state information is distributed in the network.  This
   information is then used by for route calculation.  OLSR provides
   optimal routes (in terms of number of hops).  The protocol is
   particularly suitable for large and dense networks as the technique
   of MPRs works well in this context.

Table of Contents

1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
1.1. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
1.2. OLSR Terminology  . . . . . . . . . . . . . . . . . . . . . . .   7
1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . .   9
1.4. Protocol Overview . . . . . . . . . . . . . . . . . . . .   9 . . .  10
1.5. Multipoint Relays . . . . . . . . . . . . . . . . . . . .  10 . . .  11
2. Protocol Functioning  . . . . . . . . . . . . . . . . . . . .  11 . .  12
2.1. Core Functioning  . . . . . . . . . . . . . . . . . . . . . . .  12
2.2. Auxiliary Functioning . . . . . . . . . . . . . . . . . .  12 . . .  14
3. Packet Format and Forwarding  . . . . . . . . . . . . . . . .  13 . .  15
3.1. Protocol and Port Number  . . . . . . . . . . . . . . . . .  14 . .  16
3.2. Main Address  . . . . . . . . . . . . . . . . . . . . . . .  14 . .  16
3.3. Packet Format . . . . . . . . . . . . . . . . . . . . . .  14 . . .  16
3.3.1. Packet Header . . . . . . . . . . . . . . . . . . . . .  15 . . .  17
3.3.2. Message Header  . . . . . . . . . . . . . . . . . . . . .  15 . .  17
3.4. Packet Processing and Message Flooding  . . . . . . . . . .  17 . .  19
3.4.1. Default Forwarding Algorithm  . . . . . . . . . . . . . .  18 . .  21
3.4.2. Considerations on Processing and Forwarding . . . . . .  19 . . .  22
3.5. Message Emission and Jitter . . . . . . . . . . . . . . .  20

     4. Link Sensing and Neighbor Detection . . .  23
4. Information Repositories  . . . . . . . . .  21
     4.1. Local Link Information Base . . . . . . . . . . .  24
4.1. Multiple Interface Association Information Base . . . . .  21
     4.1.1. Link Set . . .  24
4.2. Link sensing: Local Link Information Base . . . . . . . . . . .  25
4.2.1. Link Set  . . . . . . . . . .  21
     4.1.2. Neighbor Set . . . . . . . . . . . . . . . .  25
4.3. Neighbor Detection: Neighborhood Information Base . . . . . .  22
     4.1.3. 2-hop .  25
4.3.1. Neighbor Set  . . . . . . . . . . . . . . . . . . .  22
     4.1.4. MPR Set . . . . .  25
4.3.2. 2-hop Neighbor Set  . . . . . . . . . . . . . . . . . . . . .  22
     4.1.5.  26
4.3.3. MPR Selector Set . . . . . . . . . . . . . . . . . . . .  22
     4.2. HELLO Message Format . . . . . . .  26
4.3.4. MPR Selector Set  . . . . . . . . . . . .  23
     4.2.1. Link Code as Link Type and Neighbor Type . . . . . . . .  25
     4.3. HELLO Message Generation . .  26
4.4. Topology Information Base . . . . . . . . . . . . . . .  26
     4.4. Populating the Link Set . . . .  26
5. Main Addresses and Multiple Interfaces  . . . . . . . . . . . . .  28
     4.4.1. HELLO  27
5.1. MID Message Processing Format  . . . . . . . . . . . . . . . .  29
     4.5. Populating the Neighbor Set . . . . . .  27
5.2. MID Message Generation  . . . . . . . . . .  30
     4.5.1. HELLO Message Processing . . . . . . . . . .  28
5.3. MID Message Forwarding  . . . . . . .  32
     4.6. Populating the 2-hop Neighbor Set . . . . . . . . . . . .  32
     4.6.1. Hello .  28
5.4. MID Message Processing  . . . . . . . . . . . . . . . .  32
     4.6.2. Populating the MPR set . . . .  29
5.5. Resolving a Main Address from an Interface Address  . . . . . .  29
6. HELLO Message Format and Generation . . . . . . .  34
     4.6.3. MPR Computation . . . . . . . .  30
6.1. HELLO Message Format  . . . . . . . . . . . .  34
     4.7. Populating the MPR Selector Set . . . . . . . . .  30
6.1.1. Link Code as Link Type and Neighbor Type  . . . .  35
     4.7.1. Hello Message Processing . . . . . .  33
6.2. HELLO Message Generation  . . . . . . . . . .  35
     4.8. Neighborhood and 2-hop Neighborhood Changes . . . . . . .  36

     5. Topology Discovery . .  34
6.3. HELLO Message Forwarding  . . . . . . . . . . . . . . . . . . .  37
     5.1. TC  36
6.4. HELLO Message Format  . . . . . . Processing  . . . . . . . . . . . . . .  37
     5.2. Topology Information Base . . . . .  36
7. Link Sensing  . . . . . . . . . . .  38
     5.3. Advertised Neighbor Set . . . . . . . . . . . . . . .  36
7.1. Populating the Link Set . .  39
     5.4. TC Message Generation . . . . . . . . . . . . . . . . . .  39
     5.5. TC  37
7.1.1. HELLO Message Forwarding. Processing  . . . . . . . . . . . . . . . . .  39
     5.6. TC Message Processing .  37
8. Neighbor Detection  . . . . . . . . . . . . . . . . .  40
     5.7. Routing Table Calculation . . . . . .  39
8.1. Populating the Neighbor Set . . . . . . . . . .  41

     6. Node Configuration . . . . . . . .  39
8.1.1. HELLO Message Processing  . . . . . . . . . . . . .  43
     6.1. Address Assignment . . . . .  40
8.2. Populating the 2-hop Neighbor Set . . . . . . . . . . . . . . .  43
     6.2. Routing Configuration  41

8.2.1. HELLO Message Processing  . . . . . . . . . . . . . . . . . .  43
     6.3. Data Packet Forwarding  41
8.3. Populating the MPR set  . . . . . . . . . . . . . . . . . .  44

     7. Multiple OLSR Interfaces . .  42
8.3.1. MPR Computation . . . . . . . . . . . . . . . .  44
     7.1. Terminology . . . . . . .  43
8.4. Populating the MPR Selector Set . . . . . . . . . . . . . . . .  44
     7.2. Multiple Interface Functioning  45
8.4.1. HELLO Message Processing  . . . . . . . . . . . . . .  45
     7.3. Multiple Interface Declaration . . . .  45
8.5. Neighborhood and 2-hop Neighborhood Changes . . . . . . . . . .  47
     7.3.1. Multiple Interface Association Information Base  46
9. Topology Discovery  . . . .  47
     7.3.2. MID Message Format . . . . . . . . . . . . . . . . . . .  47
     7.3.3. MID
9.1. TC Message Generation . . . . . . . . Format . . . . . . . . .  48
     7.3.4. MID Message Forwarding . . . . . . . . . . . . . .  47
9.2. Advertised Neighbor Set . . .  48
     7.3.5. MID Message Processing . . . . . . . . . . . . . . . . .  48
     7.4. Main Addresses vs. Interface Addresses .
9.3. TC Message Generation . . . . . . . . .  49
     7.5. Populating the Neighbor Set . . . . . . . . . . . .  49
9.4. TC Message Forwarding.  . . .  50
     7.6. Populating the MPR Set . . . . . . . . . . . . . . . . .  49
9.5. TC Message Processing .  50
     7.6.1. MPR Computation . . . . . . . . . . . . . . . . . . . .  51
     7.7.  49
10. Routing Table Calculation  . . . . . . . . . . . . . . . .  51
     7.8. Changes to the "Default Forwarding Algorithm" . . .  51
11. Node Configuration . . .  52

     8. Non OLSR Interfaces . . . . . . . . . . . . . . . . . . . .  55
     8.1. HNA Message Format  54
11.1. Address Assignment . . . . . . . . . . . . . . . . . . . .  55
     8.2. Host and Network Association Information Base . .  54
11.2. Routing Configuration  . . . .  56
     8.3. HNA Message Generation . . . . . . . . . . . . . . . . . .  57
     8.4. HNA Message  55
11.3. Data Packet Forwarding . . . . . . . . . . . . . . . . . .  57
     8.5. HNA Message Processing . . .  55
12. Non OLSR Interfaces  . . . . . . . . . . . . . . .  57
     8.6. Routing Table Calculation . . . . . . .  55
12.1. HNA Message Format . . . . . . . . .  58

     9. Link Layer Notification . . . . . . . . . . . . .  56
12.2. Host and Network Association Information Base  . . . . .  58

     10. Link Hysteresis . . .  56
12.3. HNA Message Generation . . . . . . . . . . . . . . . . . . .  59
     10.1. Local Link Set .  57
12.4. HNA Message Forwarding . . . . . . . . . . . . . . . . . . . .  59
     10.2. Hello  57
12.5. HNA Message Generation Processing . . . . . . . . . . . . . . . .  60
     10.3. Hysteresis Strategy . . . .  57
12.6. Routing Table Calculation  . . . . . . . . . . . . . . .  61

     11. Distributing Redundant Topology Information . . .  58
12.7. Interoperability Considerations  . . . . .  62
     11.1. TC_REDUNDANCY Parameter . . . . . . . . . .  59
13. Link Layer Notification  . . . . . . .  62

     12. MPR Redundancy . . . . . . . . . . . . .  59
13.1. Interoperability Considerations  . . . . . . . . .  63
     12.1. MPR_COVERAGE Parameter . . . . . .  60
14. Link Hysteresis  . . . . . . . . . . .  63
     12.2. MPR Computation . . . . . . . . . . . . .  60
14.1. Local Link Set . . . . . . . .  64

     13. IPv6 Considerations . . . . . . . . . . . . . . . .  61
14.2. Hello Message Generation . . . .  65
     14. Security Considerations . . . . . . . . . . . . . . .  61
14.3. Hysteresis Strategy  . . .  65
     14.1. Confidentiality . . . . . . . . . . . . . . . . . .  62
14.4. Interoperability Considerations  . . .  65
     14.2. Integrity . . . . . . . . . . . .  64
15. Redundant Topology Information . . . . . . . . . . . .  65
     14.3. Interaction with External Routing Domains . . . . .  64
15.1. TC_REDUNDANCY Parameter  . . .  66

     15. Proposed Values for Constants . . . . . . . . . . . . . . .  67
     15.1. Setting emission interval and holding times .  64
15.2. Interoperability Considerations  . . . . . .  67
     15.2. Emission Interval . . . . . . . . .  65
16. MPR Redundancy . . . . . . . . . . .  68
     15.3. Holding time . . . . . . . . . . . . . .  65
16.1. MPR_COVERAGE Parameter . . . . . . . .  68
     15.4. Message Types . . . . . . . . . . . .  66
16.2. MPR Computation  . . . . . . . . . .  69
     15.5. Link Types . . . . . . . . . . . . .  66
16.3. Interoperability Considerations  . . . . . . . . . .  69
     15.6. Neighbor Types . . . . .  67
17. IPv6 Considerations  . . . . . . . . . . . . . . . .  69
     15.7. Link Hysteresis . . . . . .  67
18. Proposed Values for Constants  . . . . . . . . . . . . . . . .  69
     15.8. Willingness .  68
18.1. Setting emission interval and holding times  . . . . . . . . .  68
18.2. Emission Interval  . . . . . . . . . . . . .  70
     15.9. Misc. Constants . . . . . . . . .  68
18.3. Holding time . . . . . . . . . . . .  70

     16. Sequence Numbers . . . . . . . . . . . . .  69
18.4. Message Types  . . . . . . . .  71

     17. Acknowledgments . . . . . . . . . . . . . . . .  70
18.5. Link Types . . . . . .  71

     18. Authors' Addresses . . . . . . . . . . . . . . . . . . . .  71

     19. References  70
18.6. Neighbor Types . . . . . . . . . . . . . . . . . . . . . . . .  72

1.  Introduction

   The Optimized  70
18.7. Link State Routing Protocol (OLSR) is developed for
   mobile ad hoc networks. It operates as a table driven, proactive pro-
   tocol, i.e exchanges topology information Hysteresis  . . . . . . . . . . . . . . . . . . . . . . .  71
18.8. Willingness  . . . . . . . . . . . . . . . . . . . . . . . . .  71
18.9. Misc.  Constants . . . . . . . . . . . . . . . . . . . . . . .  72

19. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . .  72
20. Security Considerations  . . . . . . . . . . . . . . . . . . . .  72
20.1. Confidentiality  . . . . . . . . . . . . . . . . . . . . . . .  73
20.2. Integrity  . . . . . . . . . . . . . . . . . . . . . . . . . .  73
20.3. Interaction with other nodes of the
   network regularly. Each node selects a set of its neighbor nodes as
   "multipoint relays" (MPR). In OLSR, only nodes, selected as such
   MPRs, are responsible for forwarding control traffic, intended for
   diffusion into the entire network. I.e. MPRs provide an efficient
   mechanism for flooding control traffic by reducing the number of
   transmissions required.

   Nodes, selected as MPRs, also have a special responsibility when
   declaring link state information in the network. Indeed, the only
   requirement for OLSR to provide routes to all destinations is that
   MPR nodes declare link-state information for links between them self
   and their MPR selectors. Additional available link-state information
   may be utilized, e.g. for redundancy.

   Nodes which have been selected as a multipoint relay by some neighbor
   node(s) announce this information periodically in their control mes-
   sages. Thereby a node announces to the network, that it has reacha-
   bility to the nodes which have selected it as MPR. In route calcula-
   tion, the MPRs are used to form the route from a given node to any
   destination in the network. Furthermore, the protocol uses the MPRs
   to facilitate efficient flooding of control messages in the network.

   A node selects MPRs from among its one hop neighbors with "symmetri-
   cal", i.e. bi-directional, linkages. Therefore, selecting the route
   through MPRs automatically avoids the problems associated with data
   packet transfer over uni-directional links (such as the problem of
   not getting link-layer acknowledgments for data packets at each hop)

   OLSR is developed to work independently from other protocols. Like-
   wise, OLSR makes no assumptions about the underlying link-layer.

   OLSR inherits the concept of forwarding and relaying from HIPERLAN (a
   MAC layer protocol) which is standardized by ETSI [3]. The protocol
   is developed in the IPANEMA project (part of the Euclid program) and
   in the PRIMA project (part of the RNRT program).

1.1.  Changes

   Major changes from version 07 to version 08

     -    Restructured draft in order to improve readability and modu-
          larity: core protocol functionality contained in the main part
          of the draft. Advanced features (multiple interfaces, redun-
          dant MPR flooding and tc-redundancy) are moved to later sec-
          tions.

     -    Small change to message format.

     -    "Neighbor sensing" changed to "link sensing and neighbor
          detection" to improve readability and modularity.

     -    Non-core functions moved from the core part of the draft.

1.2.  OLSR Terminology

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [5]. Addition-
   ally, this doccument uses the following terminology:

     node

          A MANET router which implements the Optimized Link State Rout-
          ing protocol as specified in this document.

     main address

          The main address of a node, which will be used in OLSR control
          traffic as the "originator address" of all messages emitted by
          this node. It is the address of one of its interfaces. If a
          node has only one interface, the main address is the address
          of that interface.

     neighbor node

          A node X is a neighbor node of node Y if node Y can hear node
          X (i.e. one of X interfaces is a neighbor interface of some
          interface of Y).

     2-hop neighbor

          An node heard by a neighbor.

     strict 2-hop neighbor

          a 2-hop neighbor which is not the node itself or a neighbor of
          the node

     multipoint relay (MPR)

          A node which is selected by its one-hop neighbor, node X, to
          "re-transmit" all the broadcast messages that it receives from
          X, provided that the same message is not already received, and
          the time to live field of the message is greater than one.

     multipoint relay selector (MPR selector, MS)

          A node which has selected its one-hop neighbor, node X, as its
          multipoint relay, will be called a multipoint relay selector
          of node X.

     interface

          A network device participating in the MANET (usually a wire-
          less device). A node may have several interfaces, each inter-
          face assigned an unique IP address.

     link

          A link is a pair of interfaces (from two different nodes) sus-
          ceptible to hear one another (i.e. one may be able to receive
          traffic from the other).  A node External Routing Domains  . . . . . . . . . .  74
20.4. Node Identity  . . . . . . . . . . . . . . . . . . . . . . . .  74
21. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . .  75
22. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . .  75
23. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  75
24. References . . . . . . . . . . . . . . . . . . . . . . . . . . .  76

1.  Introduction

   The Optimized Link State Routing Protocol (OLSR) is said to have a link to
          another node when one of its interface has developed for
   mobile ad hoc networks.  It operates as a link to one of
          the interfaces of the table driven, proactive
   protocol, i.e exchanges topology information with other node.

     symmetric link

          A bi-directional link between two interfaces, i.e. interface I
          and interface J where both can hear each other.

     asymmetric link

          A link between two interfaces I and J, where it is confirmed
          that I can hear J but not confirmed if J can hear I.

     symmetric neighborhood

          The symmetric neighborhood nodes of any node X is the
   network regularly.  Each node selects a set of its neighbor nodes
          which have at least one symmetric link to X.

     symmetric 2-hop neighborhood

          The symmetric 2-hop neighborhood of X is as
   "multipoint relays" (MPR).  In OLSR, only nodes, selected as such
   MPRs, are responsible for forwarding control traffic, intended for
   diffusion into the set entire network.  MPRs provide an efficient mecha-
   nism for flooding control traffic by reducing the number of nodes,
          excluding X itself, which transmis-
   sions required.

   Nodes, selected as MPRs, also have a symmetric special responsibility when
   declaring link to state information in the sym-
          metric neighborhood of X.

     symmetric strict 2-hop neighborhood

          The symmetric 2-hop neighborhood of X network.  Indeed, the only
   requirement for OLSR to provide shortest path routes to all destina-
   tions is that MPR nodes declare link-state information for their MPR
   selectors.  Additional available link-state information may be uti-
   lized, e.g.  for redundancy.

   Nodes which have been selected as multipoint relays by some neighbor
   node(s) announce this information periodically in their control mes-
   sages.  Thereby a node announces to the set of nodes,
          excluding X itself and its neighbor, network, that it has reacha-
   bility to the nodes which have a symmetric
          link selected it as an MPR.  In route cal-
   culation, the MPRs are used to form the symmetric neighborhood of X.

1.3.  Applicability

   OLSR is route from a proactive routing protocol for mobile ad-hoc networks
   (MANETs). It is well suited given node to large and dense mobile networks, as
   any destination in the optimization achieved using network.  Furthermore, the MPRs works well in this context.
   The larger and more dense a network, protocol uses the more optimization can be
   achieved as compared
   MPRs to facilitate efficient flooding of control messages in the classic link state algorithm. OLSR uses
   hop-by-hop routing, i.e. each net-
   work.

   A node uses selects MPRs from among its local information to one hop neighbors with "symmetri-
   cal", i.e.  bi-directional, linkages.  Therefore, selecting the route packets.

   OLSR is well suited for networks, where
   through MPRs automatically avoids the traffic is random and
   sporadic between "several" nodes rather than being almost exclusively
   between a small specific set problems associated with data
   packet transfer over uni-directional links (such as the problem of nodes. As a proactive protocol, OLSR
   is also suitable
   not getting link-layer acknowledgments for scenarios where the communicating pairs change
   over time: no additional control traffic is generated in data packets at each hop,
   for link-layers employing this situa-
   tion since routes are maintained technique for all known destinations at all
   times.

1.4.  Protocol Overview unicast traffic).

   OLSR is a proactive routing protocol for mobile ad hoc networks. The
   protocol developed to work independently from other protocols.  Like-
   wise, OLSR makes no assumptions about the underlying link-layer.

   OLSR inherits the stability concept of a link state algorithm forwarding and has relaying from HIPERLAN (a
   MAC layer protocol) which is standardized by ETSI [3].  The protocol
   is developed in the
   advantage IPANEMA project (part of having routes immediately available when needed due to
   its proactive nature. OLSR is an optimization over the classical link
   state protocol, tailored for mobile ad hoc networks.

   OLSR minimizes Euclid program) and
   in the overhead from flooding PRIMA project (part of control traffic by using
   only selected nodes, called MPRs, to retransmit control messages.
   This technique significantly reduces the number of retransmissions
   required RNRT program).

1.1.  Changes

   Major changes from version 08 to flood a version 09

     -    Merged multiple interface

     -    Further separated link sensing, neighbor sensing and hello
          message to all nodes generation

     -    Collected information repositories in the network. Secondly, single section

     -    Misc.  editorial changes.

1.2.  OLSR requires only partial link state to be flooded in order to pro-
   vide optimal routes. Terminology

   The minimal set of link state information
   required is, that all nodes, selected as MPRs, MUST declare the links keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to their MPR selectors. Additional topological information, if
   present, MAY be utilized e.g. for redundancy purposes.

   OLSR MAY optimize the reactivity to topological changes by reducing
   the maximum time interval for periodic control message transmission.
   Furthermore, interpreted as OLSR continuously maintains routes to all destina-
   tions described in RFC2119 [5].  Addi-
   tionally, this document uses the network, the protocol is beneficial for traffic patterns
   where a large subset of nodes are communicating with another large
   subset of nodes, and where following terminology:

     node

          A MANET router which implements the [source, destination] pairs are chang- Optimized Link State Rout-
          ing over time. The protocol is particularly suited for large and
   dense networks, as the optimization done using MPRs works well specified in this context. The larger and more dense a network, the more optimiza-
   tion can be achieved as compared to the classic link state algorithm. document.

     OLSR is designed to work interface

          A network device participating in a completely distributed manner and does
   thus not depend on any central entity. The protocol does NOT REQUIRE
   reliable transmission of control messages: each MANET running OLSR.  A
          node sends control
   messages periodically, and can therefore sustain may have several OLSR interfaces, each interface assigned
          an occasional loss
   of some such messages. Such losses occur frequently in radio networks
   due to collisions or other transmission problems.

   Also, unique IP address.

     non OLSR does interface

          A network device, not require sequenced delivery of messages. Each con-
   trol message contains a sequence number which is incremented for each
   message. Thus the recipient of participating in a control message can, if required,
   easily identify which information is newer - even if messages MANET running OLSR.
          A node may have
   been re-ordered while in transmission.

   Furthermore, several OLSR provides support for protocol extensions such as
   sleep mode operation, multicast-routing etc. Such extensions may interfaces (wireless and/or
          wired).  Routing information from these interfaces MAY be
   introduced as additions to
          injected into the protocol without breaking backwards
   compatibility with earlier versions. OLSR does not require any changes to the format routing domain.

     single OLSR interface node

          A node which has a single OLSR interface, participating in an
          OLSR routing domain.

     multiple OLSR interface node

          A node which has multiple OLSR interfaces, participating in an
          OLSR routing domain.

     main address

          The main address of IP packets. Thus
   any existing IP stack can a node, which will be used in OLSR control
          traffic as is: the protocol only interacts
   with routing table management.

1.5.  Multipoint Relays

   The idea "originator address" of multipoint relays all messages emitted by
          this node.  It is to minimize the overhead address of one of flooding
   messages in the network by reducing duplicate retransmissions in interfaces of the
   same region. Each
          node.

          A single OLSR interface node in uses the network selects a set address of nodes in its
   symmetric neighborhood which may retransmit only OLSR
          interface as the main address.

          A multiple OLSR interface node MUST choose one of its messages. This set OLSR
          interface addresses as its "main address" (equivalent of
   selected neighbor nodes
          "router ID" or "node identifier").  It is called the "Multipoint Relay" (MPR) set of
   that node. The neighbors of node N no importance
          which are *NOT* in address is chosen, however a node SHOULD always use the
          same address as its MPR set,
   receive and process broadcast messages but do not retransmit broad-
   cast messages received from main address.

     neighbor node N.

   Each

          A node selects its MPR set from among its one hop symmetric
   neighbors. This set X is selected such that it covers (in terms a neighbor node of
   radio range) all nodes that are two hops away. The MPR set node Y if node Y can hear node
          X (i.e.  one of N,
   denoted as MPR(N), X OLSR interfaces is then an arbitrary subset of the symmetric
   neighborhood a neighbor interface of N which satisfies the following condition: every
          some OLSR interface of Y).

     2-hop neighbor

          A node
   in the symmetric heard by a neighbor.

     strict 2-hop neighborhood of N must have neighbor

          a symmetric
   link towards MPR(N). The smaller an MPR set, the less control traffic
   overhead results from 2-hop neighbor which is not the routing protocol. [2] gives an analysis and
   example of MPR selection algorithms.

   Each node maintains information about the set itself or a neighbor of neighbors that have
   selected it as MPR. This set is called
          the "Multipoint Relay Selector
   set" (MPR selector set) node, and in addition is a neighbor of a node. A node obtains this information
   from periodic HELLO messages received neighbor, with
          willingness different from WILL_NEVER, of the neighbors. node.

     multipoint relay (MPR)

          A broadcast message, intended node which is selected by its one-hop neighbor, node X, to be diffused in
          "re-transmit" all the whole network,
   coming broadcast messages that it receives from any of
          X, provided that the MPR selectors of node N message is assumed to be
   retransmitted by node N. This set can change over time (i.e. when not a
   node selects another MPR-set) duplicate, and is indicated by the selector nodes
   in their HELLO messages.

2.  Protocol Functioning

   This section outlines that the overall
          time to live field of the protocol functioning.

   OLSR message is modularized into greater than one.

     multipoint relay selector (MPR selector, MS)

          A node which has selected its one-hop neighbor, node X, as its
          multipoint relay, will be called a "core" multipoint relay selector
          of functionality, which node X.

     link

          A link is always
   required for a pair of OLSR interfaces (from two different nodes)
          susceptible to hear one another (i.e.  one may be able to
          receive traffic from the protocol other).  A node is said to operate, and have a set
          link to another node when one of auxiliary func-
   tions.

   The core specifies, in its own right, interface has a protocol able link to provide
   routing in a stand-alone MANET.

   Each auxiliary function provides additional functionality, which may
   be applicable in specific scenarios. E.g.
          one of the interfaces of the other node.

     symmetric link

          A verified bi-directional link between two OLSR interfaces.

     asymmetric link

          A link between two OLSR interfaces I and J, verified in case a only
          one direction.

     symmetric 1-hop neighborhood

          The symmetric 1-hop neighborhood of any node X is providing
   connectivity between the MANET and another routing domain.

   All auxiliary functions are compatible, to the extend where any
   (sub)set set of auxiliary functions may be implemented with the core.
   Furthermore, the protocol allows heterogeneous nodes, i.e.
          nodes which implement different subsets of the auxiliary functions, have at least one symmetric link to
   coexist in the network. X.

     symmetric 2-hop neighborhood

          The purpose symmetric 2-hop neighborhood of dividing X is the functioning of OLSR into a core function-
   ality and a set of auxiliary functions is to provide nodes,
          excluding X itself, which  have a simple and
   easy-to-comprehend protocol, and symmetric link to provide a way the sym-
          metric 1-hop neighborhood of only adding com-
   plexity where specific additional functionality is required.

2.1.  Core Functioning X.

     symmetric strict 2-hop neighborhood

          The core functionality symmetric 2-hop neighborhood of OLSR specifies X is the behavior set of nodes,
          excluding X itself and its neighbors, which have a node,
   equipped symmetric
          link to some symmetric 1-hop neighbor, with OLSR interfaces participating in the MANET and running
   OLSR as routing protocol. This includes an universal specification willingness dif-
          ferent of WILL_NEVER, of X.

1.3.  Applicability

   OLSR is a proactive routing protocol messages for mobile ad-hoc networks
   (MANETs).  It is well suited to large and their transmission through the network, dense mobile networks, as
   the optimization achieved using the MPRs works well as link sensing, topology diffusion and route calculation. in this context.
   The "Link Sensing and Neighbor Detection" mechanism provides nodes
   with information about their neighbors larger and offers an optimized mecha-
   nism for flooding messages through the concept of MPRs. It completely
   relies on more dense a network, the exchange of HELLO messages.

   The "Topology Discovery" mechanism relies on more optimization can be
   achieved as compared to the "Packet Forwarding"
   and "Link Sensing and Neighbor Discovery" mechanisms. A classic link state algorithm.  OLSR uses
   hop-by-hop routing, i.e.  each node uses
   neighbor and MPR information from the "Link Sensing" mechanism in
   diffusing its local topology information to the larger network. Topology
   information
   route packets.

   OLSR is diffused through well suited for networks, where the "Packet Forwarding" mechanism, traffic is random and relies on TC messages. Resulting from the "Topology Discovery"
   mechanism
   sporadic between a larger set of nodes nodes rather than being almost
   exclusively between a small specific set of nodes.  As a proactive
   protocol, OLSR is information which allows routing table calculation.

   The key notion also suitable for these mechanisms is the MPR relationship.

   The following table specifies the component of scenarios where the core functionality
   of OLSR, as well as their relations to communicating
   pairs change over time: no additional control traffic is generated in
   this document.

             Feature                      |  Section
            ------------------------------+--------------
             Packet format and forwarding |     3
             Link sensing                 |     4
             Topology discovery           |     5
             Node configuration           |     6
             Multiple situation since routes are maintained for all known destinations
   at all times.

1.4.  Protocol Overview

   OLSR interfaces     |     7

   Multiple interface compliance is needed when:

     - a node proactive routing protocol for mobile ad hoc networks.  The
   protocol inherits the stability of a link state algorithm and has multiple interfaces which participate in the
   advantage of having routes immediately available when needed due to
   its proactive nature.  OLSR
          domain,

     -    a node exists in a domain where other nodes with multiple is an optimization over the classical
   link state protocol, tailored for mobile ad hoc networks.

   OLSR
          interfaces are present.

2.2.  Auxiliary Functioning

   In addition to minimizes the core functioning overhead from flooding of OLSR, there are situations
   where additional functionality is needed. control traffic by using
   only selected nodes, called MPRs, to retransmit control messages.
   This includes situations
   where a node has multiple interfaces, some technique significantly reduces the number of which participate retransmissions
   required to flood a message to all nodes in
   another routing domain, where the programming interface network.  Secondly,
   OLSR requires only partial link state to the net-
   working hardware provides additional information be flooded in form of link-
   layer notifications and where it is desired to provide redundant
   topological information order to the network on expense of protocol over-
   head. pro-
   vide shortest path routes.  The following table specifies auxiliary functions and their relation
   to this document.

             Feature                      |  Section
            ------------------------------+--------------
             Non-OLSR interfaces          |     8
             Link-layer notifications     |     9
             Advanced minimal set of link sensing        |    10
             Redundant topology           |    11
             Redundant MPR flooding       |    12

3.  Packet Format and Forwarding

   OLSR communicates using a unified packet format state information
   required is, that all nodes, selected as MPRs, MUST declare the links
   to their MPR selectors.  Additional topological information, if pre-
   sent, MAY be utilized e.g.  for all data related redundancy purposes.

   OLSR MAY optimize the reactivity to topological changes by reducing
   the protocol. The purpose of this is maximum time interval for periodic control message transmission.
   Furthermore, as OLSR continuously maintains routes to facilitate extensibility
   of all destina-
   tions in the network, the protocol without breaking backwards compatibility. Also, this
   provides an easy way is beneficial for traffic patterns
   where a large subset of piggybacking different "types" nodes are communicating with another large
   subset of information
   into a single transmission, nodes, and thus for a given implementation to
   optimize towards utilizing the maximal frame-size, provided by where the
   network. These packets [source, destination] pairs are embedded in UDP datagrams for transmission chang-
   ing over the network. time.  The present draft protocol is presented with IPv4 addresses.
   Considerations regarding IPv6 are given particularly suited for large and
   dense networks, as the optimization done using MPRs works well in section 13.

   Each packet encapsulates one or more messages.
   this context.  The messages share a
   common header format, which enables nodes to correctly accept larger and (if
   applicable) retransmit messages of an unknown type.

   Messages can be flooded onto the entire more dense a network, or flooding the more opti-
   mization can be
   limited to nodes within a diameter (in terms of number of hops) from
   the originator of the message. Thus transmitting a message achieved as compared to the
   neighborhood of a node classic link state algo-
   rithm.

   OLSR is just designed to work in a special case completely distributed manner and does
   not depend on any central entity.  The protocol does NOT REQUIRE
   reliable transmission of flooding. When
   flooding any control message, duplicate retransmissions will be elim-
   inated locally (i.e. messages: each node maintains a duplicate table to prevent
   transmitting the same message twice) sends control
   messages periodically, and minimized in the entire net-
   work through the usage can therefore sustain a reasonable loss of MPRs as described
   some such messages.  Such losses occur frequently in later sections.

   Furthermore, radio networks
   due to collisions or other transmission problems.

   Also, OLSR does not require sequenced delivery of messages.  Each
   control message contains a node can examine sequence number which is incremented for
   each message.  Thus the header recipient of a control message to obtain can, if
   required, easily identify which information on is more recent - even if
   messages have been re-ordered while in transmission.

   Furthermore, OLSR provides support for protocol extensions such as
   sleep mode operation, multicast-routing etc.  Such extensions may be
   introduced as additions to the distance (in terms of number of hops) protocol without breaking backwards
   compatibility with earlier versions.

   OLSR does not require any changes to the orig-
   inator format of the message. This feature may IP packets.  Thus
   any existing IP stack can be useful in situations
   where, e.g., the time information from a received control messages
   stored in a node depends on used as is: the distance protocol only interacts
   with routing table management.

1.5.  Multipoint Relays

   The idea of multipoint relays is to minimize the originator.

3.1.  Protocol and Port Number

   Packets overhead of flooding
   messages in OLSR are communicated using UDP. Port 698 has been
   assigned by IANA for exclusive usage by the OLSR protocol.

3.2.  Main Address

   For a network by reducing redundant retransmissions in the
   same region.  Each node with one interface, in the main address of network selects a node, as defined set of nodes in "OLSR Terminology", MUST be its
   symmetric 1-hop neighborhood which may retransmit its messages.  This
   set to of selected neighbor nodes is called the address "Multipoint Relay" (MPR)
   set of that interface.

3.3.  Packet Format node.  The basic layout neighbors of any packet node N which are *NOT* in OLSR is as follows (omitting IP its MPR
   set, receive and
   UDP headers):

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Packet Length         |    Packet Sequence Number     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Message Type |     Vtime     |         Message Size          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Originator Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Time To Live |   Hop Count   |    Message Sequence Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      :                            MESSAGE                            :
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Message Type |     Vtime     |         Message Size          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Originator Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Time To Live |   Hop Count   |    Message Sequence Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      :                            MESSAGE                            :
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
               (etc)

3.3.1.  Packet Header

     Packet Length

          The length process broadcast messages but do not retransmit
   broadcast messages received from node N.

   Each node selects its MPR set from among its one hop symmetric neigh-
   bors.  This set is selected such that it covers (in bytes) terms of radio
   range) all nodes that are two hops away.  The MPR set of N, denoted
   as MPR(N), is then an arbitrary subset of the packet

     Packet Sequence Number symmetric 1-hop neigh-
   borhood of N which satisfies the following condition: every node in
   the symmetric strict 2-hop neighborhood of N must have a symmetric
   link towards MPR(N).  The Packet Sequence Number (PSN) MUST smaller a MPR set, the less control traffic
   overhead results from the routing protocol.  [2] gives an analysis
   and example of MPR selection algorithms.

   Each node maintains information about the set of neighbors that have
   selected it as MPR.  This set is called the "Multipoint Relay Selec-
   tor set" (MPR selector set) of a node.  A node obtains this informa-
   tion from periodic HELLO messages received from the neighbors.

   A broadcast message, intended to be incremented diffused in the whole network,
   coming from any of the MPR selectors of node N is assumed to be
   retransmitted by one
          each node N, if N has not received it yet.  This set can
   change over time (i.e.  when a new OLSR packet is transmitted. "Wrap-around" node selects another MPR-set) and is
          handled as described
   indicated by the selector nodes in their HELLO messages.

2.  Protocol Functioning

   This section 16.

   The sender information for outlines the overall protocol functioning.

   OLSR is modularized into a packet "core" of functionality, which is obtainable from always
   required for the IP header.
   Any received packet whose "Packet Length" is less or equal protocol to 12
   (i.e. the packet contains no messages), MUST be silently dropped.

3.3.2.  Message Header

     Message Type

          This field indicates operate, and a set of auxiliary func-
   tions.

   The core specifies, in its own right, a protocol able to provide
   routing in a stand-alone MANET.

   Each auxiliary function provides additional functionality, which type of message may
   be applicable in specific scenarios.  E.g.  in case a node is provid-
   ing connectivity between the MANET and another routing domain.

   All auxiliary functions are compatible, to the extend where any
   (sub)set of auxiliary functions may be found in implemented with the "MESSAGE" part. Message types in core.
   Furthermore, the range protocol allows heterogeneous nodes, i.e.  nodes
   which implement different subsets of 0-127 are
          reserved for messages in this document and in possible exten-
          sions.

     Vtime

          This field indicates for how long time after reception a node
          must consider the information contained auxiliary functions, to
   coexist in the message for
          valid. network.

   The validity time is represented by its mantissa (four
          highest bits purpose of Vtime field) and by its exponent (four lowest
          bits dividing the functioning of Vtime field).  In other words:

               validity time = C*(1+a/16)* 2^b

          where OLSR into a is the integer represented by the four highest bits core function-
   ality and a set of
          Vtime field auxiliary functions is to provide a simple and b the integer represented by the four lowest
          bits
   easy-to-comprehend protocol, and to provide a way of Vtime field. only adding com-
   plexity where specific additional functionality is required.

2.1.  Core Functioning

   The proposed value core functionality of OLSR specifies the scaling factor
          C is specified in section 15.

     Message Size

          This field gives the size behavior of this message, counted a node,
   equipped with OLSR interfaces participating in bytes
          and measured from the beginning MANET and running
   OLSR as routing protocol.  This includes a universal specification of
   OLSR protocol messages and their transmission through the "Message Type" field network, as
   well as link sensing, topology diffusion and until route calculation.

   Specifically, the beginning of core is made up from the next "Message Type" field (or -
          if there are no following messages - until the end components:

     Packet Format and Forwarding

          An universal specification of the
          packet).

     Originator Address

          This field contains packet format and an opti-
          mized flooding mechanism serves as the main address transport mechanism for
          all OLSR control traffic.

     Link Sensing

          Link Sensing is accomplished through periodic emission of
          HELLO messages over the node, which has
          originally generated this message. This field SHOULD NOT be
          confused with the source address from the IP header, interfaces through which connectivity
          is
          changed checked.  A separate HELLO message is generated for each time to the address of the intermediate
          interface
          which is re-transmitting this message. The Originator Address
          field MUST *NEVER* be changed and emitted in retransmissions.

     Time To Live

          This field contains correspondence with the maximum number of hops a message will
          be transmitted. Before provisions in
          section 7.

          Resulting from Link Sensing is a message local link set, describing
          links between "local interfaces" and "remote interfaces" -
          i.e.  interfaces on neighbor nodes.

          If sufficient information is retransmitted, the Time To
          Live MUST be decremented provided by 1. When a node receives a message
          with a Time To Live equal to 0 or 1, the message MUST NOT be
          retransmitted under any circumstances. Normally, a node would
          not receive a message with a TTL of zero.

          Thus, by setting link-layer, this field, the originator of a message can
          limit the flooding radius.

     Hop Count

          This field contains
          may be utilized to populate the number local link set instead of hops a
          HELLO message has attained.
          Before exchange.

     Neighbor detection

          Given a message is retransmitted, network with only single interface nodes, a node may
          deduct the Hop Count MUST be
          incremented by 1.

          Initially, this is neighbor set to '0' by directly from the originator information
          exchanged as part of link sensing: the mes-
          sage.

     Message Sequence Number

          While generating "main address" of a message, the "originator"
          single interface node will assign
          a unique identification number to each message. This number is
          inserted into is, by definition, the Sequence Number field address of the message. The
          sequence number is increased by 1 (one) for each message orig-
          inating from the
          only interface on that node.  "Wrap-around"

          In a network with multiple interface nodes, additional infor-
          mation is handled as required in order to map interface addresses to main
          addresses (and, thereby, to nodes).  This additional informa-
          tion is acquired through multiple interface declaration (MID)
          messages, described in section 16.  Message sequence numbers are used 5.

     MPR Selection and MPR Signaling

          The objective of MPR selection is for a node to
          ensure select a sub-
          set of its neighbors such that a given message is not retransmitted more than
          once broadcast message, retrans-
          mitted by any node.

3.4.  Packet Processing and Message Flooding

   Upon receiving a basic packet, a these selected neighbors, will be received by all
          nodes 2 hops away.  A node examines will thus compute its MPR set such
          that it, for each of the "message
   headers". Based on interface, satisfies this condition.  The
          information required to perform this calculation is acquired
          throuth the value periodic exchange of HELLO messages, as described
          in section 6.  MPR selection procedures are
          detailed in section 8.3.

          MPR signaling is provided in correspondence with the "Message Type" field, the node
   can determine the fate of provi-
          sions in the message. A node may receive section 6.

     Topology Control Message Diffusion

          Topology Control messages are diffused with the same
   message several times. Thus, to avoid re-processing purpose of some messages
   which were already received and processed,
          providing each node maintains a
   Duplicate Table. In this table, in the node records network with sufficient link-state
          information about
   the most recently received messages where duplicate processing of a
   message is to be avoided. For such a message, a node records a
   "Duplicate Tuple" (D_addr, D_seq_num, D_time), where D_addr is the
   originator address of allow route calculation.  Topology Control mes-
          sages are diffused in correspondence with the message, D_seq_num is provisions in
          section 9.

     Route Calculation

          Given the link state information acquired through periodic
          message sequence
   number exchange, as well as the interface configuration of
          the message and D_time specifies nodes, the time at which a tuple
   expires and *MUST* routing table for each node can be removed.

   In a node, computed.
          This is detailed in section 10

   The key notion for these mechanisms is the set MPR relationship.

   The following table specifies the component of Duplicate Tuples are denoted the "Duplicate
   set".

   In core functionality
   of OLSR, as well as their relations to this section, the term "Originator Address" will be used for document.

             Feature                      |  Section
            ------------------------------+--------------
             Packet format and forwarding |     3
             Information repositories     |     4
             Main addr and multiple if.   |     5
             Hello messages               |     6
             Link sensing                 |     7
             Neighbor detection           |     8
             Topology discovery           |     9
             Routing table computation    |    10
             Node configuration           |    11

2.2.  Auxiliary Functioning

   In addition to the
   main address core functioning of the OLSR, there are situations
   where additional functionality is needed.  This includes situations
   where a node has multiple interfaces, some of which sent the message. The term "Sender
   Interface Address" will be used for the sender address (given participate in
   another routing domain, where the
   IP header of the packet containing the message) of the programming interface
   which sent the message.

   Thus, upon receiving a basic packet, a node MUST perform the follow-
   ing tasks for each encapsulated message:

     1    If the time to live of the message net-
   working hardware provides additional information in form of link-
   layer notifications and where it is less than or equal desired to
          '0' (zero), the message MUST silently be dropped.

     2    If the packet contains no messages (i.e. the Packet Length is
          less than or equal provide redundant
   topological information to the size network on expense of the packet header), the
          packet MUST silently be discarded.

          For IPv4 addresses, protocol over-
   head.

   The following table specifies auxiliary functions and their relation
   to this implies that packets, where the
          Packet Length < document.

             Feature                      |  Section
            ------------------------------+--------------
             Non-OLSR interfaces          |    12
             Link-layer notifications     |    13
             Advanced link sensing        |    14
             Redundant topology           |    15
             Redundant MPR flooding       |    16 MUST silently be discarded.

     3    Processing condition:

          3.1  if there exists a tuple in the duplicate set, where:

                             D_addr == Originator Address, AND

                             D_seq_num == Message Sequence Number

               then

   The interpretation of the message has already been completely processed
               and MUST not be processed again.

          3.2  Otherwise, above table is as follows: if the node implements the Message Type of feature
   listed is required, it SHOULD be provided as specified in the
               message, corre-
   sponding section.

3.  Packet Format and Forwarding

   OLSR communicates using an unified packet format for all data related
   to the message MUST be processed according protocol.  The purpose of this is to facilitate extensibility
   of the
               specifications protocol without breaking backwards compatibility.  Also, this
   provides an easy way of piggybacking different "types" of information
   into a single transmission, and thus for the message type.

     4    Forwarding condition:

          4.1  if there exists a tuple in given implementation to
   optimize towards utilizing the duplicate set, where:

                             D_addr == Originator Address, AND

                             D_seq_num == Message Sequence Number

               then maximal frame-size, provided by the message has already been considered
   network.  These packets are embedded in UDP datagrams for forward-
               ing and SHOULD NOT be retransmitted again.

          4.2  Otherwise:

               4.2.1
                    If the node implements transmis-
   sion over the Message Type network.  The present draft is presented with IPv4
   addresses.  Considerations regarding IPv6 are given in section
   17.

   Each packet encapsulates one or more messages.  The messages share a
   common header format, which enables nodes to correctly accept and (if
   applicable) retransmit messages of an unknown type.

   Messages can be flooded onto the mes-
                    sage, the message MUST entire network, or flooding can be considered for forwarding
                    according
   limited to nodes within a diameter (in terms of number of hops) from
   the specifications for originator of the message.  Thus transmitting a message
                    type.

               4.2.2
                    Otherwise, if to the
   neighborhood of a node does not implement the Mes-
                    sage Type is just a special case of the flooding.  When
   flooding any control message, the message SHOULD duplicate retransmissions will be pro-
                    cessed according elim-
   inated locally (i.e.  each node maintains a duplicate set to prevent
   transmitting the default forwarding algorithm
                    described below.

3.4.1.  Default Forwarding Algorithm

   The default forwarding algorithm is same OLSR control message twice) and minimized in
   the following:

     1    If entire network through the sender interface address usage of MPRs as described in later
   sections.

   Furthermore, a node can examine the header of a message is not detected to be in obtain
   information on the symmetric neighborhood distance (in terms of number of hops) to the node, orig-
   inator of the message
          MUST silently message.  This feature may be dropped.

     2    If useful in situations
   where, e.g., the sender interface address of time information from a received control messages
   stored in a node depends on the message is detected distance to
          be the originator.

3.1.  Protocol and Port Number

   Packets in OLSR are communicated using UDP.  Port 698 has been
   assigned by IANA for exclusive usage by the symmetric neighborhood of OLSR protocol.

3.2.  Main Address

   For a node with one interface, the main address of a node, an entry as defined
   in the
          duplicate "OLSR Terminology", MUST be set is recorded with:

               D_addr = originator to the address

               D_seq_num = of that interface.

3.3.  Packet Format

   The basic layout of any packet in OLSR is as follows (omitting IP and
   UDP headers):

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Packet Length         |    Packet Sequence Number     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Message Type |     Vtime     |         Message Size          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Originator Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Time To Live |   Hop Count   |    Message Sequence Number

               D_time = current time + D_HOLD_TIME.

     3    If the sender interface address is an interface address of a
          MPR selector of this node and if the time to live of the mes-
          sage is greater than '1', the message MUST be forwarded
          according to the following:

          3.1    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      :                            MESSAGE                            :
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Message Type |     Vtime     |         Message Size          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Originator Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Time To Live |   Hop Count   |    Message Sequence Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      :                            MESSAGE                            :
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
               (etc)

3.3.1.  Packet Header

     Packet Length

          The TTL length (in bytes) of the message is reduced by one.

          3.2 packet

     Packet Sequence Number

          The hop-count of the message is increased Packet Sequence Number (PSN) MUST be incremented by one

          3.3  The message
          each time a new OLSR packet is broadcasted on all interfaces running
               OLSR. Notice: The remaining fields of the message header
               SHOULD be left unmodified.

3.4.2.  Considerations on Processing and Forwarding

   It should be noted that processing and forwarding messages are two
   different actions, conditioned by different rules. Processing relates
   to using the content of the messages, while forwarding transmitted.  "Wrap-around" is related to
   retransmitting the same message for other nodes of the network.

   Notice that this specification includes a description
          handled as described in section 19.  A separate Packet
          Sequence Number is maintained for both the
   forwarding and the processing of each known message type. Messages
   with known message types MUST *NOT* be forwarded "blindly" by this
   algorithm. Forwarding (and setting the correct message header in interface such that
          packets transmitted over an interface are sequentially enumer-
          ated.

   The IP address of the
   forwarded, known, message) interface over which a packet was transmitted
   is obtainable from the responsibility IP header of the algorithm
   specifying how packet.

   If the message packet contains no messages (i.e.  the Packet Length is less
   than or equal to be handled and, if necessary,
   retransmitted. This enables, e.g., a message type to be specified
   such that the message can be modified while in transit (e.g. to
   reflect size of the route packet header), the message has taken). Further, it enables packet MUST
   silently be discarded.

   For IPv4 addresses, this implies that packets, where the optimization through the MPRs can Packet
   Length < 16 MUST silently be bypassed: if for some reason
   classical flooding discarded.

3.3.2.  Message Header

     Message Type

          This field indicates which type of a message type is required, the algorithm which
   specifies how such messages should to be handled will simply rebroadcast found in
          the message, regardless "MESSAGE" part.  Message types in the range of MPRs.

   By defining 0-127 are
          reserved for messages in this document and in possible exten-
          sions.

     Vtime

          This field indicates for how long time after reception a set of message types, which node
          MUST be recognized by all
   implementations of OLSR, it will be possible to extend consider the information contained in the protocol
   through introduction of additional message types, while still be able as
          valid, unless a more recent update to maintain compatibility with older implementations. the information is
          received.  The REQUIRED
   message types for validity time is represented by its mantissa
          (four highest bits of Vtime field) and by its exponent (four
          lowest bits of Vtime field).  In other words:

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

          where a is the core functionality of OLSR are:

     -    HELLO-messages, performing integer represented by the task four highest bits of link sensing, neighbor
          detection
          Vtime field and MPR signaling,

     -    TC-messages, performing b the task of topology declaration
          (advertisement of link states).

     -    MID-messages, performing integer represented by the task four lowest
          bits of declaring the presence Vtime field.  The proposed value of
          multiple interfaces on a node.

   Other message types include those the scaling factor
          C is specified in later sections, as
   well as possible future extensions such as for example messages
   enabling power conservation / sleep mode, multicast routing, support
   for unidirectional links, auto-configuration/address assignment etc.

3.5. section 18.

     Message Emission and Jitter

   As a basic implementation requirement, synchronization of control
   messages SHOULD be avoided. As a consequence, periodic OLSR messages
   SHOULD be emitted such that they avoid synchronization.

   Emission Size

          This field gives the size of control traffic this message, counted in bytes
          and measured from neighboring nodes may, for various
   reasons (mainly timer interactions with packet processing), become
   synchronized such that several neighbor nodes attempt to transmit
   control traffic simultaneously. Depending on the nature beginning of the under-
   lying link-layer, this may or may not lead to collisions "Message Type" field
          and hence
   message loss - possibly loss until the beginning of several subsequent the next "Message Type" field (or -
          if there are no following messages - until the end of the
   same type.

   To avoid such synchronizations,
          packet).

     Originator Address

          This field contains the following simple strategy for
   emitting control messages is proposed. A node MAY add an amount main address of
   jitter to the interval at node, which messages are generated. The jitter
   must has
          originally generated this message.  This field SHOULD NOT be a random value for each message generated. Thus, for a node
   utilizing jitter:

        Actual message interval = MESSAGE_INTERVAL - jitter

   Where jitter is a value, randomly selected
          confused with the source address from the interval
   [0,MAXJITTER] and MESSAGE_INTERVAL IP header, which is
          changed each time to the value address of the message inter-
   val specified for intermediate interface
          which is re-transmitting this message.  The Originator Address
          field MUST *NEVER* be changed in retransmissions.

     Time To Live

          This field contains the maximum number of hops a message being emitted (e.g. HELLO_INTERVAL for
   HELLO messages, TC_INTERVAL for TC-messages etc.).

   Jitter MAY also be introduced when forwarding messages.  The follow-
   ing simple strategy may will
          be adopted: when transmitted.  Before a message is to retransmitted, the Time
          To Live MUST be forwarded decremented by 1.  When a node, it should be kept in node receives a mes-
          sage with a Time To Live equal to 0 or 1, the message MUST NOT
          be retransmitted under any circumstances.  Normally, a node during
          would not receive a short period of
   time :

           Keep message period = jitter

   Where jitter is with a random value in [0,MAXJITTER].

   Notice that when TTL of zero.

          Thus, by setting this field, the node sends originator of a control message, message can
          limit the opportunity to
   piggyback other messages (before their keeping period is expired) may
   be taken to reduce flooding radius.

     Hop Count

          This field contains the number of packet transmissions.

   It should hops a message has attained.
          Before a message is retransmitted, the Hop Count MUST be noticed that
          incremented by 1.

          Initially, this is set to '0' by the present draft imposes a minimal rate originator of
   control message emission. However the mes-
          sage.

     Message Sequence Number

          While generating a message, the "originator" node MAY send control messages at will assign
          a higher rate (e.g. for better reacting unique identification number to high mobility). Tuning each message.  This number
          is inserted into the
   rate Sequence Number field of control traffic to the actual conditions under which message.
          The sequence number is increased by 1 (one) for each message
          originating from the pro-
   tocol node.  "Wrap-around" is handled as
          described in section 19.  Message sequence numbers are
          used to operate ensure that a given message is an implementation issue.

4.  Link Sensing not retransmitted more
          than once by any node.

3.4.  Packet Processing and Neighbor Detection

   This section describes how Message Flooding

   Upon receiving a basic packet, a node discovers its immediate topology,
   known as its "neighborhood". This implies detecting examines each of the quality "message
   headers".  Based on the value of
   links to neighbor nodes, as well as discovering which nodes are in the neighborhood and two-hop neighborhood.

   Specifically, link sensing and neighbor detection populates "Message Type" field, the local
   link information base.

4.1.  Local Link Information Base

   The local link information base stores information about neighbors,
   links to neighbors, links to 2-hop neighbors, MPRs and MPR selectors.

4.1.1.  Link Set

   A node records a "Link Tuple" (L_local_iface_addr, L_neigh-
   bor_iface_addr, L_SYM_time, L_ASYM_time, L_time). L_local_iface_addr
   is
   can determine the (interface) address fate of the local message.  A node (i.e. one endpoint may receive the same
   message several times.  Thus, to avoid re-processing of some messages
   which were already received and processed, each node maintains a
   Duplicate Set.  In this set, the link), L_neighbor_iface_addr node records information about the
   most recently received messages where duplicate processing of a mes-
   sage is to be avoided.  For such a message, a node records a "Dupli-
   cate Tuple" (D_addr, D_seq_num, D_retransmitted, D_iface_list,
   D_time), where D_addr is the (interface) originator address of the
   neighbor node (i.e. message,
   D_seq_num is the other endpoint message sequence number of the link), L_SYM_time message, D_retrans-
   mitted is a boolean indicating whether the time until which the link is considered symmetric, L_ASYM_time message has been already
   retransmitted, D_iface_list is a list of the time until addresses of the inter-
   faces on which the neighbor interface is considered heard, message has been received and
   L_time D_time specifies the
   time at which this record a tuple expires and *MUST* be removed. When L_SYM_time and L_ASYM_time

   In a node, the set of Duplicate Tuples are expired, denoted the link is
   considered lost.

   This information is "Duplicate
   set".

   In this section, the term "Originator Address" will be used when declaring for the neighbor interfaces in
   main address of the HELLO messages.

   L_SYM_time is node which sent the message.  The term "Sender
   Interface Address" will be used to decide for the Link Type declared sender address (given in the
   IP header of the packet containing the message) of the interface
   which sent the message.  The term "Receiving Interface Address" will
   be used for the neighbor
   interface. If L_SYM_time is not expired, address of the link interface of the node which received
   the message.

   Thus, upon receiving a basic packet, a node MUST be declared
   symmetric. perform the follow-
   ing tasks for each encapsulated message:

     1    If L_SYM_time the packet contains no messages (i.e.  the Packet Length is expired,
          less than or equal to the link MUST be declared asym-
   metric. If both L_SYM_time and L_ASYM_time are expired, size of the link packet header), the
          packet MUST silently be declared lost.

   In a node, discarded.

          For IPv4 addresses, this implies that packets, where the
          Packet Length < 16 MUST silently be discarded.

     2    If the set time to live of Link Tuples are denoted the "Link Set".

4.1.2.  Neighbor Set

   A message is less than or equal to
          '0' (zero), or if the message was sent by the receiving node records a set
          (i.e.  the Originator Address of "neighbor tuples" (N_neighbor_main_addr,
   N_status, N_willingness), describing symmetric neighbors.  N_neigh-
   bor_main_addr the message is the main
          address of a neighbor, N_status specifies
   if the node is NOT_SYM or SYM. N_willingness receiving node): the message MUST silently be
          dropped.

     3    Processing condition:

          3.1  if there exists a tuple in an integer between 0
   and 7, the duplicate set, where:

                             D_addr    == Originator Address, AND

                             D_seq_num == Message Sequence Number

               then the message has already been completely processed
               and specifies a nodes willingness to carry traffic on behalf
   of other nodes.

4.1.3.  2-hop Neighbor Set

   A MUST not be processed again.

          3.2  Otherwise, if the node records a set implements the Message Type of "2-hop tuples" (N_neighbor_main_addr,
   N_2hop_addr, N_time), describing symmetric (and, since MPR links by
   definition are also symmetric, thereby also MPR) links between its
   neighbors and the symmetric 2-hop neighborhood. N_neighbor_main_addr
   is
               message, the main address of message MUST be processed according to the
               specifications for the message type.

     4    Forwarding condition:

          4.1  if there exists a neighbor, N_2hop_addr tuple in the duplicate set, where:

                                D_addr    == Originator Address, AND

                                D_seq_num == Message Sequence Number,
                    AND

                                the receiving interface (address) is
                                in D_iface_list

               then the main address of
   a 2-hop neighbor with a symmetric link to N_neighbor_main_addr, message has already been considered for forward-
               ing and
   N_time specifies SHOULD NOT be retransmitted again.

               4.2  Otherwise:

                    4.2.1
                         If the node implements the Message Type of the time at which
                         message, the tuple expires and *MUST* message MUST be
   removed.

   This information is gathered from considered for
                         forwarding according to the HELLO messages received by a
   node from its neighbor nodes.

   In a node, specifications for
                         the set of 2-hop tuples are denoted message type.

                    4.2.2
                         Otherwise, if the "2-hop Neighbor
   Set".

4.1.4.  MPR Set

   A node maintains a set does not implement the
                         Message Type of neighbors which are selected as MPR. Their
   main addresses are listed in the so-called MPR Set.

   Section 4.6.2 describes how MPRs are selected.

4.1.5.  MPR Selector Set

   A node maintains information (obtained from message, the HELLO messages) about message SHOULD
                         be processed according to the neighbors which have selected this node as a MPR.

   Thus, a node records an MPR-selector tuple (MS_main_addr, MS_time).
   MS_main_addr default forward-
                         ing algorithm described below.

3.4.1.  Default Forwarding Algorithm

   The default forwarding algorithm is the main following:

     1    If the sender interface address of a the message is not detected
          to be in the symmetric 1-hop neighborhood of the node, which has selected this
   node as MPR.  MS_time specifies the time at which a tuple expires and
   *MUST*
          forwarding algorithm MUST silently stop here (and the message
          MUST NOT be removed.

   In forwarded).

     2    If there exists a node, tuple in the duplicate set where:

               D_addr    == Originator Address

               D_seq_num == Message Sequence Number

          Then the message will be further considered for forwarding if
          and only if:

               D_retransmitted is false, AND

               the (address of MPR-selector tuples are denoted the) interface which received the message
               is not included among the addresses in D_iface_list

     3    Otherwise, if such an entry doesn't exist, the message is fur-
          ther considered for forwarding.

   If after those steps, the "MPR Selec-
   tor Set".

4.2.  HELLO Message Format

   A common mechanism message is employed not considered for populating forwarding,
   then the local link informa-
   tion base, namely periodic exchange processing of HELLO messages. Thus this sec-
   tion describes section stops (i.e.  steps 4 to 8 are
   ignored), otherwise, if it is still considered for forwarding then
   the general HELLO message mechanism, followed by following algorithm is used:

     4    If the sender interface address is an interface address of a
   description
          MPR selector of link sensing and topology detection, respectively.

   To accommodate for link sensing this node and neighbor detection, as well as to
   accommodate for future extensions, an approach similar if the time to live of the overall
   packet format mes-
          sage is taken. Thus greater than '1', the proposed format of a HELLO message
   is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 MUST be retransmitted
          (as described later in steps 6 7 8 9 0 1 2 3 4 to 8).

     5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Reserved             |    Htime      |  Willingness  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Link Code   |   Reserved    |       Link Message Size       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Neighbor Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Neighbor Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                             . . .                             :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Link Code   |   Reserved    |       Link    If an entry in the duplicate set exists, with same Originator
          Address, and same Message Size       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Neighbor Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Neighbor Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                                       :
   (etc)

   This Sequence Number, the entry is
          updated as follows:

               D_time    = current time + DUP_HOLD_TIME.

               The receiving interface (address) is sent as the data-portion of added to
               D_iface_list.

               D_retransmitted is set to true if and only if the general packet format
   described message
               will be retransmitted according to step 4.

          Otherwise an entry in section 3.4, with the "Message Type" duplicate set to
   HELLO_MESSAGE, is recorded with:

               D_addr    = Originator Address

               D_seq_num = Message Sequence Number

               D_time    = current time + DUP_HOLD_TIME.

               D_iface_list contains the TTL field receiving interface address.

               D_retransmitted is set to 1 (one) true if and Vtime set accordingly
   to only if the value of NEIGHB_HOLD_TIME, specified in section 15.3.

     Reserved

          This field must message
               will be set retransmitted according to "0000000000000" step 4.

   If, and only if, according to step 4, the message must be in compliance
          with this specification.

     HTime

          This field specifies retransmit-
   ted then:

     6    The TTL of the HELLO emission interval used message is reduced by the
          node on this particular interface, i.e. the time before the
          transmission one.

     7    The hop-count of the next HELLO (this information message is used in
          advanced link sensing). increased by one

     8    The HELLO emission interval message is repre-
          sented by its mantissa (four highest bits broadcast on all interfaces (Notice: The
          remaining fields of Htime field) the message header SHOULD be left unmodi-
          fied.)

3.4.2.  Considerations on Processing and Forwarding

   It should be noted that processing and forwarding messages are two
   different actions, conditioned by its exponent (four lowest bits different rules.  Processing
   relates to using the content of Htime field).  In other
          words:

               HELLO emission interval=C*(1+a/16)*2^b

          where a is the integer represented by messages, while forwarding is
   related to retransmitting the four highest bits same message for other nodes of
          Htime field the
   network.

   Notice that this specification includes a description for both the
   forwarding and b the integer represented processing of each known message type.  Messages
   with known message types MUST *NOT* be forwarded "blindly" by this
   algorithm.  Forwarding (and setting the four lowest
          bits of Htime field. The proposed value of correct message header in the scaling factor
          C
   forwarded, known, message) is specified in section 15.

     Willingness

          This field specifies the willingness responsibility of the algorithm
   specifying how the message is to be handled and, if necessary,
   retransmitted.  This enables, e.g., a node message type to carry and
          forward traffic for other nodes.

          A node with willingness WILL_NEVER (see section 15.8, for
          willingness constants) MUST never be selected as MPR by any
          node. A node with willingness WILL_ALWAYS MUST always specified
   such that the message can be
          selected as MPR. By default, a node SHOULD advertise a will-
          ingness of WILL_DEFAULT.

     Link Code

          This field specifies informations about modified while in transit (e.g.  to
   reflect the link between route the
          interface of message has taken).  Further, it enables that
   the sender and optimization through the following list MPRs can be bypassed: if for some reason
   classical flooding of neighbor
          interfaces. It also a message type is required, the algorithm which
   specifies informations about how such messages should be handled will simply rebroadcast
   the status message, regardless of
          the neighbor.

          Link codes, not known by MPRs.

   By defining a node, are silently discarded.

     Link Message Size set of message types, which MUST be recognized by all
   implementations of OLSR, it will be possible to extend the protocol
   through introduction of additional message types, while still being
   able to maintain compatibility with older implementations.  The size
   REQUIRED message types for the core functionality of OLSR are:

     -    HELLO-messages, performing the task of link message, counted in bytes sensing, neighbor
          detection and measured
          from MPR signaling,

     -    TC-messages, performing the beginning task of topology declaration
          (advertisement of the "Link Code" field and until the next
          "Link Code" field (or - if there are no more link types states).

     -    MID-messages, performing the
          end task of declaring the message).

     Neighbor Address

          An address presence of
          multiple interfaces on a neighbor node.

4.2.1.  Link Code

   Other message types include those specified in later sections, as Link Type
   well as possible future extensions such as for example messages
   enabling power conservation / sleep mode, multicast routing, support
   for unidirectional links, auto-configuration/address assignment etc.

3.5.  Message Emission and Neighbor Type

   This document specifies processing only Jitter

   As a basic implementation requirement, synchronization of Link Codes < 16.

   If the Link Code value is less or equal to 15, then it MUST control
   messages SHOULD be inter-
   preted as holding two different fields, of two bits each:

          7       6       5       4       3       2       1       0
      +-------+-------+-------+-------+-------+-------+-------+-------+
      |   0   |   0   |   0   |   0   | Neighbor Type |   Link Type   |
      +-------+-------+-------+-------+-------+-------+-------+-------+

   The following four "Link Types" are REQUIRED by OLSR:

     -    UNSPEC_LINK - indicating that no specific information about
          the links is given.

     -    ASYM_LINK - indicating that the links are asymmetric (i.e. the
          neighbor interface is "heard").

     -    SYM_LINK - indicating that the links are symmetric with the
          interface.

     -    LOST_LINK - indicating that the links have been lost.

   The following three "Neighbor Types" are REQUIRED by OLSR:

     -    SYM_NEIGH - indicating avoided.  As a consequence, OLSR control messages
   SHOULD be emitted such that the neighbors have at least one
          symmetrical link they avoid synchronization.

   Emission of control traffic from neighboring nodes may, for various
   reasons (mainly timer interactions with this node.

     -    MPR_NEIGH - indicating packet processing), become
   synchronized such that several neighbor nodes attempt to transmit
   control traffic simultaneously.  Depending on the neighbors have at least one
          symmetrical link AND have been been selected as MPR by the
          sender.

     -    NOT_NEIGH - indicating that nature of the nodes are either no longer
   underlying link-layer, this may or
          have may not yet become symmetrical neighbors.

   Note that lead to collisions and
   hence message loss - possibly loss of several subsequent messages of
   the implementation should be careful in not confusing Link
   Type with Neighbor Type nor same type.

   To avoid such synchronizations, the constants (confusing SYM_NEIGH with
   SYM_LINK following simple strategy for instance).

   A link code advertising:

          Link Type     == SYM_LINK AND

          Neighbor type == NOT_NEIGH
   emitting control messages is invalid, and any links listed as such MUST be silently discarded
   without any processing.

4.3.  HELLO Message Generation

   This involves transmitting the Link Set, the Neighbor Set and proposed.  A node MAY add an amount of
   jitter to the MPR
   Set. In principle, interval at which messages are generated.  The jitter
   must be a HELLO random value for each message serves three independent tasks:

     -    link sensing

     -    neighbor detection generated.  Thus, for a node
   utilizing jitter:

        Actual message interval = MESSAGE_INTERVAL -    MPR selection signaling

   Three tasks are all are based on periodic information exchange within jitter

   Where jitter is a nodes neighborhood, value, randomly selected from the interval
   [0,MAXJITTER] and serve MESSAGE_INTERVAL is the common purpose value of "local topology
   discovery". A the message inter-
   val specified for the message being emitted (e.g.  HELLO_INTERVAL for
   HELLO messages, TC_INTERVAL for TC-messages etc.).

   Jitter MAY also be introduced when forwarding messages.  The follow-
   ing simple strategy may be adopted: when a message is therefore generated based on the
   information stored to be forwarded
   by a node, it should be kept in the Local Link Set, node during a short period of
   time :

           Keep message period = jitter

   Where jitter is a random value in [0,MAXJITTER].

   Notice that when the Neighbor Set and node sends a control message, the
   MPR Set from opportunity to
   piggyback other messages (before their keeping period is expired) may
   be taken to reduce the local link information base. number of packet transmissions.

   Notice, that a minimal rate of control messages is imposed.  A node must perform link sensing on
   MAY send control messages at a higher rate, if beneficial for a spe-
   cific deployment.

4.  Information Repositories

   Through the exchange of OLSR control messages, each interface, in order node accumulates
   information about the network.  This information is stored according
   to
   detect links between the interface and neighbor interfaces. Further-
   more, a node must advertise its entire symmetric neighborhood on descriptions in this section.

4.1.  Multiple Interface Association Information Base

   For each
   interface destination in order to perform neighbor detection. Hence, for a given
   interface, a HELLO message will contain a list of links on that
   interface (with associated link types), as well as a list of the
   entire neighborhood (with an associated neighbor types).

   The Vtime field network, "Interface Association Tuples"
   (I_iface_addr, I_main_addr, I_time) are recorded.  I_iface_addr is an
   interface address of a node, I_main_addr is set such that it corresponds to the value main address of this
   node.  I_time specifies the
   node's NEIGHB_HOLD_TIME parameter. The Htime field is set such that
   it corresponds to time at which this tuple expires and
   *MUST* be removed.

   In a node, the value set of the node's HELLO_INTERVAL parameter
   (see section 15.3).

   The Willingness field Interface Association Tuples is set such that it corresponds to denoted the nodes
   willingness
   "Interface Association Set".

4.2.  Link Sensing: Local Link Information Base

   The local link information base stores information about links to forward traffic on behalf of other nodes (see section
   15.8).
   neighbors.

4.2.1.  Link Set

   A node MUST advertise the same willingness on all inter-
   faces.

   The lists of addresses declared in records a HELLO message are computed as
   follows:

   For each tuple in the Link Set, where set of "Link Tuples" (L_local_iface_addr, L_neigh-
   bor_iface_addr, L_SYM_time, L_ASYM_time, L_time).  L_local_iface_addr
   is the interface where address of the HELLO is to be transmitted, and where L_time >=
   current time local node (i.e. not expired),  one endpoint of the
   link), L_neighbor_iface_addr is advertised
   with:

     1    The Link Type set according to the following:

               if interface address of the neighbor
   node (i.e.  the other endpoint of the link), L_SYM_time >= current time (not expired) AND

                  L_time >= current is the time (not expired)

                    Link Type = SYM_LINK

               Otherwise, if
   until which the link is considered symmetric, L_ASYM_time >= current time (not expired)
               AND

                             L_SYM_time < current is the time (expired) AND
   until which the neighbor interface is considered heard, and L_time >= current
   specifies the time (not expired)

                    Link Type = ASYM_LINK

               Otherwise, if at which this record expires and *MUST* be
   removed.  When L_SYM_time and L_ASYM_time < current time (expired) AND are expired, the link is
   considered lost.

   This information is used when declaring the neighbor interfaces in
   the HELLO messages.

   L_SYM_time < current time (expired) AND

                             L_time >= current time (not expired)

                    Link Type = LOST_LINK

     2    The Neighbor Type is set according used to decide the following:

          2.1 Link Type declared for the neighbor
   interface.  If L_SYM_time is not expired, the main address, corresponding to L_neigh-
               bor_iface_addr, link MUST be declared
   symmetric.  If L_SYM_time is included in expired, the link MUST be declared asym-
   metric.  If both L_SYM_time and L_ASYM_time are expired, the link
   MUST be declared lost.

   In a node, the set of Link Tuples are denoted the "Link Set".

4.3.  Neighbor Detection: Neighborhood Information Base

   The neighborhood information base stores information about neighbors,
   2-hop neighbors, MPRs and MPR set: selectors.

4.3.1.  Neighbor Type = MPR_NEIGH

          2.2  Otherwise, if the main address, corresponding to L_neigh-
               bor_iface_addr, Set

   A node records a set of "neighbor tuples" (N_neighbor_main_addr,
   N_status, N_willingness), describing symmetric neighbors.  N_neigh-
   bor_main_addr is included in the neighbor set:

                    if main address of a neighbor, N_status == SYM

                         Neighbor Type = SYM_NEIGH
                    Otherwise, specifies
   if N_status == the node is NOT_SYM

                         Neighbor Type = NOT_NEIGH

   For each tuple or SYM.  N_willingness in the Neighbor Set, for which no L_neigh-
   bor_iface_addr from an associated link tuple has been advertised integer between 0
   and 7, and specifies a nodes willingness to carry traffic on behalf
   of other nodes.

4.3.2.  2-hop Neighbor Set

   A node records a set of "2-hop tuples" (N_neighbor_main_addr,
   N_2hop_addr, N_time), describing symmetric (and, since MPR links by
   definition are also symmetric, thereby also MPR) links between its
   neighbors and the previous algorithm, symmetric 2-hop neighborhood.  N_neighbor_main_addr
   is advertised with:

     - Link Type = UNSPEC_LINK

     - Neighbor Type set according to the way described above, in step 2

   For a node with a single OLSR interface, the main address of a neighbor, N_2hop_addr is simply the main address of the OLSR interface. I.e. for
   a node 2-hop neighbor with a single OLSR
   interface, the main address, corresponding to L_neighbor_iface_addr
   is simply L_neighbor_iface_addr.

   The list of neighbors in a HELLO message can be partial (e.g. due symmetric link to
   message size limitations, imposed by the network), N_neighbor_main_addr, and
   N_time specifies the rule being time at which the
   following: each neighbor node MUST tuple expires and *MUST* be cited at least once within
   removed.

   In a
   predetermined refreshing period, REFRESH_INTERVAL: at least once with node, the correct "Link Type", and at least once with set of 2-hop tuples are denoted the correct "Neighbor
   Type" (and, "2-hop Neighbor
   Set".

4.3.3.  MPR Set

   A node maintains a set of neighbors which are selected as implemented above, preferably both at MPR.  Their
   main addresses are listed in the same time).
   To keep track so-called MPR Set.

4.3.4.  MPR Selector Set

   A node records a set of fast connectivity changes, MPR-selector tuples (MS_main_addr, MS_time),
   describing the neighbors which have selected this node as a HELLO message must be
   sent at least every HELLO_INTERVAL period, smaller than or equal to
   REFRESH_INTERVAL.

   Notice that for limiting MPR.
   MS_main_addr is the impact from loss main address of control messages, it
   is desirable that a message (plus node, which has selected this
   node as MPR.  MS_time specifies the generic package header) can fit
   into time at which a single MAC frame.

   Each HELLO message generated is broadcast by tuple expires and
   *MUST* be removed.

   In a node, the node to its neigh-
   bors. set of MPR-selector tuples are denoted the "MPR Selec-
   tor Set".

4.4.  Populating  Topology Information Base

   Each node in the Link Set

   The Link Set is populated with network maintains topological information about the
   network.  This information on links to neighbor
   nodes. The process of populating this set is denoted "link sensing" acquired from TC-messages and is performed using HELLO message exchange, updating a local link
   information base in used
   for routing table calculations.

   Thus, for each node.

   Each node should detect destination in the links between itself and neighbor nodes.
   Uncertainties over radio propagation network, a "Topology Tuple"
   (T_dest_addr, T_last_addr, T_seq, T_time) is recorded.  T_dest_addr
   is the main address of a node, which may make some links unidirec-
   tional. Consequently, all links MUST be checked in both directions reached in
   order to be considered valid.

   A "link" one hop from
   the node with the main address T_last_addr.  Typically, T_last_addr
   is described by a pair MPR of interfaces: T_dest_addr.  T_seq is a local sequence number, and T_time
   specifies the time at which this tuple expires and *MUST* be removed.

   In a remote
   interface.

   For node, the purpose set of link sensing, each neighbor node (more specifi-
   cally, Topology Tuples are denoted the link to each neighbor) has "Topology Set".

5.  Main Addresses and Multiple Interfaces

   For single OLSR interface nodes, the relationship between an associated status of either
   "symmetric" or "asymmetric". "Symmetric" indicates, that OLSR
   interface address and the corresponding main address is trivial: the
   main address is the OLSR interface address.  For multiple OLSR inter-
   face nodes, the relationship between OLSR interface addresses and
   main addresses is defined through the link to
   that neighbor exchange of Multiple Interface
   Declaration (MID) messages.  This section describes how MID messages
   are exchanged and processed.

   Each node has been verified with multiple interfaces MUST announce, periodically,
   information describing its interface configuration to be bi-directional, i.e. it other nodes in
   the network.  This is
   possible accomplished through flooding a Multiple Inter-
   face Declaration message to transmit data all nodes in both directions. "Asymmetric" indicates
   that HELLO messages from the network through the MPR
   flooding mechanism.

   Each node have been heard (i.e. communication in the network maintains interface information about the
   other nodes in the network.  This information acquired from MID-mes-
   sages, emitted by nodes with multiple interfaces participating in the neighbor node is possible), however it is not confirmed that
   this node
   MANET, and is also able used for routing table calculations.

   Specifically, multiple interface declaration associates multiple
   interfaces to receive messages (i.e. communication a node (and to a main address) through populating the
   neighbor node
   multiple interface association base in each node.

5.1.  MID Message Format

   The proposed format of a MID message is not confirmed). as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    OLSR Interface Address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    OLSR Interface Address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This is sent as the data-portion of the general packet format
   described in section 3.4, with the "Message Type" set to
   MID_MESSAGE.  The information, acquired through and used by time to live SHOULD be set to 255 (maximum value)
   to diffuse the link sensing is
   accumulated in message into the link set.

4.4.1.  HELLO Message Processing

   The "Originator Address" entire network and Vtime set
   accordingly to the value of a HELLO message is MID_HOLD_TIME, as specified in section
   18.3.

     OLSR Interface Address

          This field contains the (main) address of an OLSR interface of the
          node, which has emitted excluding the message. In nodes main address (which already indi-
          cated in the case where only one originator address).

   All interface of a node is participating in addresses other than the MANET running OLSR, this main address is equivalent of the "Source Address" as can be found in the
   IP header of the packet containing the message.

   Upon receiving a HELLO message, a originator
   node SHOULD update its Link Set.
   Notice, that a HELLO message MUST neither be forwarded nor be
   recorded are put in the duplicate table.

   Upon receiving a HELLO message, the "validity time" MUST be computed
   from the Vtime field of MID message.  If the maximum allowed message header (see section 3.3.2).
   Then, size
   (as imposed by the Link Set SHOULD be updated as follows:

     1    Upon receiving a HELLO message, if there exists no link tuple
          with

               L_neighbor_iface_addr == Source Address

          a new tuple network) is created with

               L_neighbor_iface_addr = Source Address

               L_local_iface_addr    = Address of the interface reached while there are still inter-
   face addresses which
               received have not been inserted into the HELLO message

               L_SYM_time            = current time - 1 (expired)
               L_time                = current time + validity time

     2    The tuple (existing or new) with:

               L_neighbor_iface_addr == Source Address

          is then modified as follows:

          2.1  L_ASYM_time = current time + validity time;

          2.2  if MID-message,
   more MID messages are generated until the entire interface addresses
   set has been sent.

5.2.  MID Message Generation

   A MID message is sent by a node finds in the address of network to declare its multi-
   ple interfaces (if any).  I.e., the MID message contains the list of
   interface addresses which
               received the HELLO are associated to its main address.  The
   list of addresses can be partial in each MID message among (e.g.  due to
   message size limitations, imposed by the addresses listed network), but parsing of all
   MID messages describing the interface set from a node MUST be com-
   plete within a certain refreshing period (MID_INTERVAL).  The infor-
   mation diffused in the link message then network by these MID messages will help each
   node to calculate its routing table.  A node which has only a single
   interface address participating in the tuple MANET (i.e.  running OLSR),
   MUST NOT generate any MID message.

   A node with more interfaces, where only one is modified as follows:

                    if Link Type participating in the
   MANET and running OLSR (e.g.  a node is equal connected to LOST_LINK then

                         L_SYM_time = current time - 1 (i.e. expired)

                    else if Link Type a wired network
   as well as to a MANET) MUST NOT generate any MID messages.

   A node with more interfaces, where more than one is equal participating in
   the MANET and running OLSR MUST generate MID messages as specified.

5.3.  MID Message Forwarding

   MID messages are broadcast and retransmitted by the MPRs in order to SYM_LINK or ASYM_LINK
                    then

                         L_SYM_time = current time + validity time,

                         L_time     = L_SYM_time + NEIGHB_HOLD_TIME

          2.3  L_time = max(L_time, L_ASYM_time)
   diffuse the messages in the entire network.  The above rule "default forwarding
   algorithm" (described in section 3.4) MUST be used for setting L_time is for-
   warding of MID messages.

5.4.  MID Message Processing

   The tuples in the following: a link losing its
   symmetry SHOULD still be advertised during at least multiple interface association set are recorded
   with the duration of information that is exchanged through MID messages.

   Upon receiving a MID message, the "validity time" advertised in the generated HELLO.  This allows
   neighbors to detect the link breakage.

4.5.  Populating MUST be computed
   from the Neighbor Set

   A node maintains a set Vtime field of neighbor tuples, based on the link tuples.
   This information is updated according to changes message header (as described in the Link Set. section
   3.3.2).  The Link Set keeps Multiple Interface Association Information Base
   SHOULD then be updated as follows:

     1    If the information about sender interface (NB: not originator) of this message
          is not in the links, while symmetric 1-hop neighborhood of this node, the Neigh-
   bor Set keeps
          message MUST be discarded.

     2    For each interface address listed in the information about MID message:

          2.1  If there exist some tuple in the neighbors. There is a clear interface association between those two sets, since a node
               set where:

                    I_iface_addr == interface address, AND

                    I_main_addr  == originator address,

               then the holding time of that tuple is set to:

                    I_time       = current time + validity time.

          2.2  Otherwise, a neighbor of
   another if and only if there new tuple is at least one link between recorded in the two
   nodes. With multiple interface nodes, there might even be several
   links between two nodes. asso-
               ciation set where:

                    I_iface_addr = interface address,

                    I_main_addr  = originator address,

                    I_time       = current time + validity time.

5.5.  Resolving a Main Address from an Interface Address

   In any case, general, the formal correspondence between links and neighbors only part of OLSR requiring use of "interface
   addresses" is
   defined as follows: link sensing.  The "associated neighbor tuple" remaining parts of a link tuple, is, if it
          exists, OLSR operate on
   nodes, uniquely identified by their "main addresses" (effectively,
   the neighbor tuple such as:

               N_neighbor_main_addr == main address of L_neigh-
               bor_iface_addr

          The "associated link tuples" of a neighbor tuple, are all node is its "node id" - which for convenience
   corresponds to the
          link tuples, such as address of one of its interfaces).  In a network
   with only single interface nodes, the same condition applies:

               N_neighbor_main_addr == main address of L_neigh-
               bor_iface_addr

   The Neighbor Set MUST populated a node will, by maintaining
   definition, be equal to the proper correspon-
   dence between link tuples and associated neighbor tuples, as follows:

     Creation

          Each time a link appears, that is, each time interface address of the node.  In net-
   works with multiple interface nodes operating within a link tuple common OLSR
   area, it is
          created, the associated neighbor tuple MUST required to be created with
          the following values:

               N_neighbor_main_addr = main able to map any interface address of L_neigh-
               bor_iface_addr (from to the link tuple)
   corresponding main address.

   The N_status MUST then computed as described exchange of MID messages provides a way in which interface infor-
   mation is acquired by nodes in the next step

     Update

          Each time network.  This permits identifica-
   tion of a link changes, that is, each time nodes "main address", given one of its interface addresses.

   Given an interface address:

     1    if there exists some tuple in the interface association set
          where:

               I_iface_addr == interface address

          then the information result of a link tuple the main address search is modified, the node MUST ensure that originator
          address I_main_addr of the
          N_status tuple.

     2    Otherwise, the result of the associated neighbor tuple respects main address search is the prop-
          erty:

               If inter-
          face address itself.

6.  HELLO Message Format and Generation

   A common mechanism is employed for populating the neighbor has any associated local link which is informa-
   tion base and the neighborhood information base, namely periodic
   exchange of HELLO messages.  Thus this section describes the general
   HELLO message mechanism, followed by a sym-
               metrical description of link (i.e. with L_SYM_time >= current time),
               then

                    N_status is set sensing
   and topology detection, respectively.

6.1.  HELLO Message Format

   To accommodate for link sensing, neighborhood detection and MPR
   selection signalling, as well as to SYM

               else N_status is set accommodate for future exten-
   sions, an approach similar to NOT_SYM

     Removal

          Each time a link is deleted, that is, each time a link tuple
          is removed, the associated neighbor tuple MUST be removed if
          it has no longer any associated links.

   Those rules ensure that there overall packet format is exactly one associated neighbor
   tuple for taken.
   Thus the proposed format of a link tuple, and that every neighbor tuple has at least
   one associated link tuple.

4.5.1. HELLO message is as follows:

       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

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Reserved             |     Htime     |  Willingness  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Link Code   |   Reserved    |       Link Message Size       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Neighbor Interface Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Neighbor Interface Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                             .  .  .
   :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Link Code   |   Reserved    |       Link Message Processing

   The "Originator Address" of a HELLO message is the (main) address of
   the node, which has emitted the message. In the case where only one
   interface of a node is participating in the MANET running OLSR, this
   address Size       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Neighbor Interface Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Neighbor Interface Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                                       :
   (etc)

   This is equivalent of the "Source Address" sent as can be found in the
   IP header data-portion of the general packet containing the message.  Likewise, format
   described in section 3.4, with the "will-
   ingness" MUST be computed from "Message Type" set to
   HELLO_MESSAGE, the Willingness TTL field of the HELLO
   message (see section 4.2).

   Upon receiving a HELLO message, a node SHOULD first update its Link
   Set as described before It SHOULD then update its Neighbor Set as
   follows:

     -    if the Originator Address is set to 1 (one) and Vtime set accordingly
   to the N_neighbor_main_addr from a
          neighbor tuple included value of NEIGHB_HOLD_TIME, specified in the Neighbor Set:

               then, the neighbor tuple SHOULD section 18.3.

     Reserved

          This field must be updated as follows:
               N_willingness = willingness from set to "0000000000000" to be in compliance
          with this specification.

     HTime

          This field specifies the HELLO message

4.6.  Populating emission interval used by the 2-hop Neighbor Set

   The 2-hop neighbor set describes
          node on this particular interface, i.e.  the set of nodes which have a sym-
   metric link to a symmetric neighbor. This information set is main-
   tained through periodic exchange time before the
          transmission of the next HELLO messages as described (this information may be used
          in
   this section.

4.6.1.  HELLO Message Processing advanced link sensing, see section 14).  The "Originator Address" of a
          HELLO message emission interval is the (main) address represented by its mantissa (four
          highest bits of
   the node, which has emitted the message. Htime field) and by its exponent (four lowest
          bits of Htime field).  In the case other words:

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

          where only one
   interface of a node is participating in the MANET running OLSR, this
   address is equivalent integer represented by the four highest bits of
          Htime field and b the "Source Address" as can be found in integer represented by the
   IP header four lowest
          bits of Htime field.  The proposed value of the packet containing scaling factor
          C is specified in section 18.

     Willingness

          This field specifies the message.

   Upon receiving a HELLO message from a symmetric neighbor, willingness of a node
   SHOULD update its 2-hop Neighbor Set. Notice, that a HELLO message to carry and
          forward traffic for other nodes.

          A node with willingness WILL_NEVER (see section 18.8, for
          willingness constants) MUST neither be forwarded nor never be recorded in the duplicate table.

   Upon receiving a HELLO message, the "validity time" selected as MPR by any
          node.  A node with willingness WILL_ALWAYS MUST always be computed
   from the Vtime field of the message header (see section 3.3.2).

   If the Originator Address is the main address of
          selected as MPR.  By default, a L_neigh-
   bor_iface_addr from node SHOULD advertise a link tuple included in the will-
          ingness of WILL_DEFAULT.

     Link Set with

          L_SYM_time >= current time (not expired)

   (in other words: if Code

          This field specifies informations about the Originator Address is included in link between the Neigh-
   bor Set with N_status = SYM) then
          interface of the 2-hop Neighbor Set SHOULD then
   be updated as follows:

     1    for each address (henceforth: 2-hop neighbor address), listed
          in sender and the HELLO message with Neighbor Type equal to SYM_NEIGH or
          MPR_NEIGH:

          1.1  if 2-hop following list of neighbor address = main address
          interfaces.  It also specifies informations about the status
          of receiving
               node:

                    silently discard the 2-hop neighbor address.

               (in other words: a node is neighbor.

          Link codes, not its own 2-hop neighbor).

          1.2  Otherwise, known by a 2-hop tuple is created with:

                    N_neighbor_main_addr  = Originator Address;

                    N_2hop_addr    = main address node, are silently discarded.

     Link Message Size

          The size of the 2-hop neighbor;

                    N_time         = current time + validity time.

               This tuple may replace an older similar tuple with same
               N_neighbor_main_addr and N_2hop_addr values.

     2    For each 2-hop node listed link message, counted in bytes and measured
          from the HELLO message with Neighbor
          Type equal to NOT_NEIGH, all 2-hop tuples where:

               N_neighbor_main_addr == Originator Address AND

               N_2hop_addr     == main address beginning of the 2-hop neighbor

          are deleted.

4.6.2.  Populating "Link Code" field and until the MPR set

   MPRs next
          "Link Code" field (or - if there are used to flood control messages from a node into the network
   while reducing no more link types - the number
          end of retransmissions that will occur in a
   region. Thus, the concept of MPR is an optimization message).

     Neighbor Interface Address

          An address of a classical
   flooding mechanism.

   Each node in the network selects, independently, its own set interface of MPRs
   among its symmetric neighborhood. The symmetric links with MPRs are
   advertised with a neighbor node.

6.1.1.  Link Code as Link Type MPR_NEIGH instead and Neighbor Type

   This document only specifies processing of SYM_NEIGH in HELLO
   messages.

   The MPR set Link Codes < 16.

   If the Link Code value is less or equal to 15, then it MUST be calculated inter-
   preted as holding two different fields, of two bits each:

          7       6       5       4       3       2       1       0
      +-------+-------+-------+-------+-------+-------+-------+-------+
      |   0   |   0   |   0   |   0   | Neighbor Type |   Link Type   |
      +-------+-------+-------+-------+-------+-------+-------+-------+

   The following four "Link Types" are REQUIRED by a node in such a way OLSR:

     -    UNSPEC_LINK - indicating that it,
   through the neighbors in no specific information about
          the MPR-set, can reach all symmetric strict
   2-hop neighbors. (Notice that a node, a, which links is a direct given.

     -    ASYM_LINK - indicating that the links are asymmetric (i.e.
          the neighbor
   of another node, b, interface is not also a strict 2-hop neighbor of node b).
   This means "heard").

     -    SYM_LINK - indicating that the union of the links are symmetric neighborhoods of with the MPR
   nodes contains
          interface.

     -    LOST_LINK - indicating that the symmetric strict 2-hop neighborhood. MPR set
   recalculation should occur when changes links have been lost.

   The following three "Neighbor Types" are detected in the neighbor-
   hood or in REQUIRED by OLSR:

     -    SYM_NEIGH - indicating that the 2-hop neighborhood.

   While it is not essential neighbors have at least one
          symmetrical link with this node.

     -    MPR_NEIGH - indicating that the neighbors have at least one
          symmetrical link AND have been been selected as MPR set is minimal, it is essen-
   tial by the
          sender.

     -    NOT_NEIGH - indicating that the nodes are either no longer or
          have not yet become symmetrical neighbors.

   Note that all strict 2-hop neighbors can an implementation should be reached through careful in not confusing Link
   Type with Neighbor Type nor the
   selected MPR nodes. constants (confusing SYM_NEIGH with
   SYM_LINK for instance).

   A node SHOULD select an MPR set link code advertising:

          Link Type     == SYM_LINK AND

          Neighbor Type == NOT_NEIGH

   is invalid, and any links adverticed as such that MUST be silently dis-
   carded without any
   strict 2-hop neighbor processing.

   Likewise a Neighbor Type field advertising a numerical value which is covered by at least
   not one MPR node. This
   ensures that the overhead of the protocol constants SYM_NEIGH, MPR_NEIGH, NOT_NEIGH, is kept at a minimum.

   By default, invalid,
   and any links adverticed as such MUST be silently discarded without
   any processing.

6.2.  HELLO Message Generation

   This involves transmitting the MPR set can coincide with Link Set, the entire symmetric neigh-
   bor set. This will be Neighbor Set and the case at network initialization (and will
   correspond to classic link-state routing).

4.6.3. MPR Computation

   The following specifies a proposed heuristic for selection of MPRs.
   It constructs an MPR-set that enables
   Set.  In principle, a node to reach any node in the
   symmetrical strict 2-hop neighborhood through relaying by one HELLO message serves three independent tasks:

     -    link sensing

     -    neighbor detection

     -    MPR
   node. The following terminology will be used in describing this algo-
   rithm:

     N:
          The set of neighbors with which there exists selection signaling

   Three tasks are all are based on periodic information exchange within
   a symmetric link.
     N2:
          The set made of the nodes in the symmetric 2-hop neighbor set
          excluding (i) neighborhood, and serve the nodes only reachable by members common purpose of N with
          N_willingness WILL_NEVER, (ii) all "local topology
   discovery".  A HELLO message is therefore generated based on the nodes
   information stored in N the Local Link Set, the Neighbor Set and (iii) the
   MPR Set from the local link information base.

   A node performing must perform link sensing on each interface, in order to
   detect links between the computation.
     D(y):

          The degree of an one hop interface and neighbor interfaces.  Further-
   more, a node y (where y is must advertise its entire symmetric 1-hop neighborhood
   on each interface in order to perform neighbor detection.  Hence, for
   a member given interface, a HELLO message will contain a list of N), is defined links on
   that interface (with associated link types), as the number of symmetric neighbors of node
          y, EXCLUDING all the members well as a list of N and EXCLUDING the node per-
          forming the computation.
   entire neighborhood (with an associated neighbor types).

   The proposed heuristic Vtime field is as follows:

     1    Start with an MPR set made of all members of N with N_willing-
          ness equal such that it corresponds to WILL_ALWAYS

     2    Calculate D(y), where y is a member of N, for all nodes in N.

     3    While there exist nodes in N2 which are not covered by at
          least one node in the MPR set:

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

          3.2  Select as a MPR the node with highest N_willingness among
   node's NEIGHB_HOLD_TIME parameter.  The Htime field is set such that
   it corresponds to the nodes in N with non-zero reachability. In case value of
               multiple choice select the node which provides reachabil-
               ity node's HELLO_INTERVAL parameter
   (see section 18.3).

   The Willingness field is set such that it corresponds to the maximum number of nodes in N2.  In case node's
   willingness to forward traffic on behalf of
               multiple other nodes providing (see section
   18.8).  A node MUST advertise the same amount willingness on all
   interfaces.

   The lists of reachability,
               select the node as MPR whose D(y) addresses declared in a HELLO message is greater. Remove the
               nodes from N2 which are now covered by a node in the MPR
               set.

     4    As an optimization, process list of
   neighbor interface addresses computed as follows:

   For each node y tuple in the MPR set in Link Set, where L_local_iface_addr is the
          increasing order of their willingness.  If all nodes in N2 are
          still covered by at least one node in
   interface where the MPR set excluding y
          and N_willingness of node y HELLO is smaller than WILL_ALWAYS, then
          node y to be transmitted, and where L_time >=
   current time (i.e.  not expired), L_neighbor_iface_addr is removed from the MPR set.

4.7.  Populating the MPR Selector Set advertised
   with:

     1    The MPR selector Link Type set of a node, n, according to the following:

          1.1  if L_SYM_time >= current time (not expired)

                    Link Type = SYM_LINK

          1.2  Otherwise, if L_ASYM_time >= current time (not expired)
               AND

                             L_SYM_time  <  current time (expired)

                    Link Type = ASYM_LINK

          1.3  Otherwise, if L_ASYM_time < current time (expired) AND

                             L_SYM_time  < current time (expired)

                    Link Type = LOST_LINK

     2    The Neighbor Type is populated by set according to the following:

          2.1  If the main addresses
   of the nodes which have selected n as MPR. MPR selection address, corresponding to L_neigh-
               bor_iface_addr, is signaled
   through HELLO messages.

4.7.1.  HELLO Message Processing

   Upon receiving a HELLO message, if a node finds one of its own inter-
   face addresses included in the list with a MPR set:

                    Neighbor Type equal to MPR_NEIGH,
   information from = MPR_NEIGH

          2.2  Otherwise, if the HELLO message must be recorded main address, corresponding to L_neigh-
               bor_iface_addr, is included in the MPR
   Selector Set.

   The "validity time" MUST be computed from the Vtime field of the mes-
   sage header (see section 3.3.2). The MPR Selector Set SHOULD
   then be updated as follows:

     1    If there exists no MPR selector tuple with:

                    MS_main_addr neighbor set:

               2.2.1
                    if N_status == Originator Address

               then a new tuple is created with:

                    MS_main_addr SYM

                         Neighbor Type = Originator Address

          3    The tuple is then modified as follows:

                    MS_time SYM_NEIGH

               2.2.2
                    Otherwise, if N_status == NOT_SYM
                         Neighbor Type = current time + validity time.

   Deletion of MPR selector tuples occurs NOT_NEIGH

   For each tuple in case of expiration of the
   timer or in case of Neighbor Set, for which no L_neigh-
   bor_iface_addr from an associated link breakage as described in the "Neighborhood
   and 2-hop Neighborhood Changes".

4.8.  Neighborhood and 2-hop Neighborhood Changes

   A change in tuple has been advertised by
   the neighborhood previous algorithm,  N_neighbor_main_addr is detected when: advertised with:

     -    The L_SYM_time field of a link tuple expires. This is consid-
          ered Link Type = UNSPEC_LINK,

     - Neighbor Type set as described in step 2 above

   For a neighbor loss if it was the last link with a neigh-
          bor node (on the contrary, a link with an interface may break
          while a link node with another interface of a single OLSR interface, the neighbor node
          remains).

     -    A new link tuple main address is inserted in simply
   the Link Set with a non-
          expired L_SYM_time or address of the OLSR interface.  I.e.  for a tuple node with expired L_SYM_time is modi-
          fied so that L_SYM_time becomes non-expired. This is consid-
          ered as a neighbor appearance if there was previously no link
          with single
   OLSR interface, the main address, corresponding neighbor node. to L_neigh-
   bor_iface_addr is simply L_neighbor_iface_addr.

   A change in HELLO message can be partial (e.g.  due to message size limita-
   tions, imposed by the 2-hop neighborhood is detected when a 2-hop network), the rule being the following, on each
   interface: each link and each neighbor
   tuple expires node MUST be cited at least
   once within a predetermined refreshing period, REFRESH_INTERVAL.  To
   keep track of fast connectivity changes, a HELLO message must be sent
   at least every HELLO_INTERVAL period, smaller than or is deleted according equal to section 4.6.

   The following processing occurs when changes in the neighborhood or
   REFRESH_INTERVAL.

   Notice that for limiting the 2-hop neighborhood are detected:

     -    In case impact from loss of neighbor loss, all control messages, it
   is desirable that a message (plus the 2-hop tuples with N_neigh-
          bor_main_addr == Main Address of generic packet header) can fit
   into a single MAC frame.

6.3.  HELLO Message Forwarding

   Each HELLO message generated is broadcast by the neighbor node on one inter-
   face to its neighbors.  HELLO messages MUST never be deleted.

     -    In case of neighbor loss, all forwarded.

6.4.  HELLO Message Processing

   A node processes incoming HELLO messages for the MPR selector tuples with
          MS_main_addr == Main Address purpose of the conduct-
   ing link sensing (detailed in section 7), neighbor MUST be deleted

     -    The detection
   and MPR selector set MUST be re-calculated when a neighbor appearance
          or loss is detected, or when a change population (detailed in section 8)

7.  Link Sensing

   Link sensing populates the 2-hop neighbor-
          hood local link information base.  Link sensing
   is detected.

     -    An additional HELLO message MAY be sent when exclusively concerned with OLSR interface addresses and the MPR set
          changes.

5.  Topology Discovery abil-
   ity to exchange packets between such OLSR interfaces.

   The mechanism for link sensing and neighbor detection part is the periodic exchange of HELLO
   messages.

7.1.  Populating the protocol basi-
   cally offers, Link Set

   The Link Set is populated with information on links to each node, a list neighbor
   nodes.  The process of neighbors with which it can
   communicate directly and, populating this set is denoted "link sensing"
   and is performed using HELLO message exchange, updating a local link
   information base in combination with each node.

   Each node should detect the Packet Format links between itself and
   Forwarding part, an optimized flooding mechanism through MPRs. Based
   on this, topology information neighbor nodes.
   Uncertainties over radio propagation may make some links unidirec-
   tional.  Consequently, all links MUST be checked in both directions
   in order to be considered valid.

   A "link" is disseminated through described by a pair of interfaces: a local and a remote
   interface.

   For the network.
   The present section describes what part purpose of link sensing, each neighbor node (more specifi-
   cally, the link to each neighbor) has an associated status of either
   "symmetric" or "asymmetric".  "Symmetric" indicates, that the link to
   that neighbor node has been verified to be bi-directional, i.e.  it
   is possible to transmit data in both directions.  "Asymmetric" indi-
   cates that HELLO messages from the information given by node have been heard (i.e.  commu-
   nication from the link sensing and neighbor detection node is disseminated to the entire
   network and how possible), however it is used not con-
   firmed that this node is also able to construct routes.

   Routes are constructed through advertised links and links with neigh-
   bors. A receive messages (i.e.  commu-
   nication to the neighbor node must at least disseminate links between itself is not confirmed).

   The information, acquired through and used by the
   nodes in its MPR-selector set, link sensing, is
   accumulated in order to provide sufficient infor-
   mation to enable routing.

5.1.  TC the link set.

7.1.1.  HELLO Message Format Processing

   The proposed format "Originator Address" of a TC HELLO 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              ANSN             |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Advertised neighbor Main Address                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Advertised neighbor Main Address                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This is sent as the data-portion main address of
   the general message format with node, which has emitted the "Message Type" set to TC_MESSAGE.  The time to live message.

   Upon receiving a HELLO message, a node SHOULD be set
   to 255 (maximum value) to diffuse the update its Link Set.
   Notice, that a HELLO message into the entire network
   and Vtime set accordingly to the value of TOP_HOLD_TIME, as specified
   in section 15.3.

     Advertised Neighbor Sequence Number (ANSN)

          A sequence number is associated with MUST neither be forwarded nor be
   recorded in the advertised neighbor duplicate set.  Every time a node detects

   Upon receiving a change in its advertised
          neighbor set, it increments this sequence number ("Wrap-
          around" is handled as described in section 16). This
          number is sent in this ANSN HELLO message, the "validity time" MUST be computed
   from the Vtime field of the TC message to keep
          track of header (see section 3.3.2).
   Then, the most recent information. When a node receives Link Set SHOULD be updated as follows:

     1    Upon receiving a
          TC HELLO message, it can decide on the basis if there exists no link tuple
          with

               L_neighbor_iface_addr == Source Address

          a new tuple is created with

               L_neighbor_iface_addr = Source Address

               L_local_iface_addr    = Address of this Advertised
          Neighbor Sequence Number, whether or not the interface
                                       which received informa-
          tion about the advertised neighbors of
                                       HELLO message

               L_SYM_time            = current time - 1 (expired)

               L_time                = current time + validity time

     2    The tuple (existing or new) with:

               L_neighbor_iface_addr == Source Address

          is then modified as follows:

          2.1  L_ASYM_time = current time + validity time;

          2.2  if the originator node is
          more recent than what it already has.

     Advertised Neighbor Main Address

          This field contains finds the main address of a neighbor node. All
          main addresses of the advertised neighbors of interface which
               received the Originator
          node are put in HELLO message among the TC message. If addresses listed in
               the maximum allowed link message
          size (as imposed by then the network) tuple is modified as follows:

               2.2.1
                    if Link Type is equal to LOST_LINK then

                         L_SYM_time = current time - 1 (i.e.  expired)

               2.2.2
                    else if Link Type is equal to SYM_LINK or ASYM_LINK
                    then

                         L_SYM_time = current time + validity time,

                         L_time     = L_SYM_time + NEIGHB_HOLD_TIME

          2.3  L_time = max(L_time, L_ASYM_time)

   The above rule for setting L_time is reached while there are the following: a link losing its
   symmetry SHOULD still be advertised neighbor addresses which have not been
          inserted into during at least the TC-message, more TC messages will be gener-
          ated until duration of
   the entire "validity time" advertised neighbor set has been sent.
          Extra main addresses of neighbor nodes may be included, if
          redundancy is desired.

     Reserved in the generated HELLO.  This field is reserved, and MUST be set allows
   neighbors to "0000000000000000"
          for compliance with this document.

5.2.  Topology Information Base

   Each node in detect the network maintains topological information about link breakage.

8.  Neighbor Detection

   Neighbor detection populates the
   network. This neighborhood information is acquired from TC-messages base and
   concerns itself with nodes and node main addresses.  The relationship
   between OLSR interface addresses and main addresses is used
   for routing table calculations.

   Thus, for each destination described in the network, a "Topology Tuple"
   (T_dest_addr, T_last_addr, T_seq, T_time) is recorded. T_dest_addr
   section 5.

   The mechanism for neighbor detection is the main address periodic exchange of a node, which may be reached in one hop from
   HELLO messages.

8.1.  Populating the Neighbor Set

   A node with the main address T_last_addr. Typically, T_last_addr is maintains a
   MPR set of T_dest_addr. T_seq neighbor tuples, based on the link tuples.
   This information is a sequence number, and T_time specifies updated according to changes in the time at which this tuple expires and *MUST* be removed.

   In a node, Link Set.

   The Link Set keeps the set of Topology Tuples are denoted information about the "Topology Set".

5.3.  Advertised Neighbor links, while the Neigh-
   bor Set

   A TC message keeps the information about the neighbors.  There is sent by a clear
   association between those two sets, since a node in the network to declare is a set neighbor of
   links, called advertised link set which MUST include
   another node if and only if there is at least one link between the
   links to all nodes of its MPR Selector set, i.e.,
   two nodes.

   In any case, the formal correspondence between links and neighbors which
   have selected the sender node is
   defined as follows:

          The "associated neighbor tuple" of a MPR. If, for some reason, link tuple, is, if it is
   required to distribute redundant TC information, refer to section
   11.

   The sequence number (ANSN) associated with
          exists, the advertised neighbor
   set is also sent with the list. tuple where:

               N_neighbor_main_addr == main address of
                                       L_neighbor_iface_addr

          The ANSN number MUST be incremented
   when links are removed from the advertised "associated link tuples" of a neighbor set; tuple, are all the ANSN
   number SHOULD
          link tuples, where:

               N_neighbor_main_addr == main address of
                                       L_neighbor_iface_addr

   The Neighbor Set MUST be incremented when links are added to populated by maintaining the advertised proper corre-
   spondence between link tuples and associated neighbor set.

5.4.  TC Message Generation

   In order to build the topology information base needed, each node,
   which has been selected tuples, as MPR, broadcasts Topology Control (TC) mes-
   sages. TC messages are flooded to all nodes in the network and take
   advantage of MPRs. MPRs enable fol-
   lows:

     Creation

          Each time a better scalability in link appears, that is, each time a link tuple is
          created, the distribu-
   tion of topology information [1].

   The list of addresses can associated neighbor tuple MUST be partial in each TC message (e.g. due to
   message size limitations, imposed by created, if it
          doesn't already exist, with the network), but parsing following values:

               N_neighbor_main_addr = main address of all
   TC messages describing
                                      L_neighbor_iface_addr
                                      (from the advertised link set of a node tuple)

          In any case, the N_status MUST then be com-
   plete within a certain refreshing period (TC_INTERVAL). The informa-
   tion diffused computed as described
          in the network by these TC messages will help next step

     Update

          Each time a link changes, that is, each node
   calculate its routing table.

   When time the advertised link set information
          of a link tuple is modified, the node becomes empty, it SHOULD still
   send (empty) TC-messages during MUST ensure that the a duration equal to "validity
   time"
          N_status of its TC-messages to invalidate the previous TC-messages. It
   SHOULD then stop sending TC-messages until some node is inserted in
   its advertised link set.

   A node MAY transmit additional TC-messages to increase its reactive-
   ness to associated neighbor tuple respects the prop-
          erty:

               If the neighbor has any associated link failures. When tuple which indi-
               cates a change to the MPR selector symmetrical link (i.e.  with L_SYM_time >= cur-
               rent time), then

                    N_status is set to SYM

               else N_status is
   detected and this change can be attributed set to NOT_SYM

     Removal

          Each time a link failure, is deleted, that is, each time a TC-
   message SHOULD link tuple
          is removed, the associated neighbor tuple MUST be transmitted after removed if
          it has no longer any associated link tuples.

   These rules ensure that there is exactly one associated neighbor
   tuple for a shorter interval than TC_INTER-
   VAL.

5.5.  TC link tuple, and that every neighbor tuple has at least
   one associated link tuple.

8.1.1.  HELLO Message Forwarding

   TC messages are broadcasted and retransmitted by the MPRs in order to
   diffuse Processing

   The "Originator Address" of a HELLO message is the messages in main address of
   the entire network. TC messages MUST be
   forwarded according to node, which has emitted the "default forwarding algorithm".

5.6.  TC Message Processing

   Upon receiving a TC message, message.  Likewise, the "validity time" "willingness"
   MUST be computed from the Vtime Willingness field of the HELLO message header (see
   section 3.3.2).
   The topology set 6.1).

   Upon receiving a HELLO message, a node SHOULD first update its Link
   Set as described before.  It SHOULD then be updated update its Neighbor Set as follows (using section
   16 for comparison of ANSN):

     1    If
   follows:

     -    if the sender interface (NB: not originator) of this message Originator Address is not in the symmetric neighborhood of this node, the message
          MUST be discarded.

     2    If there exist some tuple in the topology set where:

               T_last_addr == originator address AND

               T_seq       >  ANSN,

          then further processing of this TC message MUST NOT be per-
          formed and the message MUST be silently discarded (case: mes-
          sage received out of order).

     3    All tuples in the topology set where:

               T_last_addr == originator address AND

               T_seq       <  ANSN

          MUST be removed N_neighbor_main_addr from the topology set.

     4    For each of the advertised neighbor main address received in
          the TC message:

          4.1  If there exist some tuple in the topology set where:

                    T_dest_addr == advertised neighbor main address, AND

                    T_last_addr == originator address,

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

                    T_time      =  current time + validity time.

          4.2  Otherwise, a new
          neighbor tuple MUST be recorded included in the topology
               set where:

                    T_dest_addr = advertised Neighbor Set:

               then, the neighbor main address,

                    T_last_addr = originator address,

                    T_seq       = ANSN,

                    T_time tuple SHOULD be updated as follows:

               N_willingness = current time + validity time.

5.7.  Routing Table Calculation

   Each node maintains a routing table which allows it to route data,
   destined for willingness from the other nodes in HELLO message

8.2.  Populating the network. 2-hop Neighbor Set

   The routing table is
   based on the information contained in the link 2-hop neighbor set and describes the topology
   set. Therefore, if any set of these sets are changed, the routing table
   is re-calculated nodes which have a sym-
   metric link to update the route a symmetric neighbor.  This information about each destina-
   tion set is main-
   tained through periodic exchange of HELLO messages as described in the network.
   this section.

8.2.1.  HELLO Message Processing

   The route entries are recorded in the routing
   table in the following format:

         1.  R_dest_addr    R_next_addr    R_dist   R_iface_addr
         2.  R_dest_addr    R_next_addr    R_dist   R_iface_addr
         3.      ,,             ,,           ,,          ,,

   Each entry in "Originator Address" of a HELLO message is the table consists main address of R_dest_addr, R_next_addr, R_dist,
   and R_iface_addr
   the node, which specifies that has emitted the message.

   Upon receiving a HELLO message from a symmetric neighbor, a node identified by
   R_dest_addr is estimated to
   SHOULD update its 2-hop Neighbor Set.  Notice, that a HELLO message
   MUST neither be R_dist hops away forwarded nor be recorded in the duplicate set.

   Upon receiving a HELLO message, the "validity time" MUST be computed
   from the local node,
   and that Vtime field of the symmetric neighbor node with interface address
   R_next_addr message header (see section 3.3.2).

   If the Originator Address is the next hop node main address of a L_neigh-
   bor_iface_addr from a link tuple included in the route to R_dest_addr, and
   this one hop is reachable through Link Set with

          L_SYM_time >= current time (not expired)

   (in other words: if the local interface R_iface_addr.
   Entries are recorded in Originator Address is a symmetric neighbor)
   then the table 2-hop Neighbor Set SHOULD be updated as follows:

     1    for each destination address (henceforth: 2-hop neighbor address), listed
          in the network
   for which HELLO message with Neighbor Type equal to SYM_NEIGH or
          MPR_NEIGH:

          1.1  if the route is known. All main address of the destinations for which 2-hop neighbor address = main
               address of receiving node:

                    silently discard the
   route 2-hop neighbor address.

               (in other words: a node is broken or partially known are not entered in the table.

   The routing table is updated when its own 2-hop neighbor).

          1.2  Otherwise, a change 2-hop tuple is detected in created with:

                    N_neighbor_main_addr =  Originator Address;

                    N_2hop_addr          =  main address of the neigh-
   bor information base
                                            2-hop neighbor;

                    N_time               =  current time
                                            + validity time.

               This tuple may replace an older similar tuple with same
               N_neighbor_main_addr and N_2hop_addr values.

     2    For each 2-hop node listed in the topology HELLO message with Neighbor
          Type equal to NOT_NEIGH, all 2-hop tuples where:

               N_neighbor_main_addr == Originator Address AND

               N_2hop_addr          == main address of the
                                       2-hop neighbor

          are deleted.

8.3.  Populating the MPR set (and also

   MPRs are used to flood control messages from a node into the Multiple
   Interface Association Information Base, section 7.3.1, and network
   while reducing the
   Host and Network Association Information Base, section 8,
   if applicable). More precisely, number of retransmissions that will occur in a
   region.  Thus, the routing table concept of MPR is re-calculated in
   case an optimization of neighbor appearance or loss, or when a topology tuple is cre-
   ated or removed. classical
   flooding mechanism.

   Each node in the network selects, independently, its own set of MPRs
   among its symmetric 1-hop neighborhood.  The update symmetric links with
   MPRs are advertised with Link Type MPR_NEIGH instead of this routing information does not gen-
   erate or trigger any messages to SYM_NEIGH in
   HELLO messages.

   The MPR set MUST be transmitted, neither calculated by a node in such a way that it,
   through the net-
   work, nor neighbors in the one-hop neighborhood.

   To construct the routing table of node X, MPR-set, can reach all symmetric strict
   2-hop neighbors.  (Notice that a shortest path algorithm node, a, which is run on a direct neighbor
   of another node, b, is not also a strict 2-hop neighbor of node b).
   This means that the directed graph containing union of the arcs X -> Y where Y is
   any symmetric neighbor 1-hop neighborhoods of X (with Link Type equal to SYM_LINK) and the arcs U -> V where there exists an entry in
   MPR nodes contains the topology symmetric strict 2-hop neighborhood.  MPR set with
   V as T_dest_addr and U as T_last_addr.

   The following procedure is given as an example to calculate (or re-
   calculate) the routing table :

     1    All
   recalculation should occur when changes are detected in the entries from neighbor-
   hood or in the routing table are removed.

     2    The new routing entries 2-hop neighborhood.

   MPRs are added starting with computed per interface, the symmetric
          neighbors (h=1) as union of the destination nodes. I.e. for MPR sets of each link
          tuple in
   interface make up the link MPR set where:

               L_SYM_time   >= current time

          (there is a symmetric link to for the neighbor), a new routing
          entry node.

   While it is recorded in not essential that the routing table with:

               R_dest_addr  = main address of MPR set is minimal, it is
   essential that all strict 2-hop neighbors can be reached through the
   selected MPR nodes.  A node SHOULD select an MPR set such that any
   strict 2-hop neighbor with inter-
               face L_neighbor_iface_addr;

               R_next_addr  = L_neighbor_iface_addr;

               R_dist       = 1;

               R_iface_addr = L_local_iface_addr of is covered by at least one MPR node.  This
   ensures that the entry.

          If in overhead of the above, R_dest_addr protocol is distinct from R_next, another
          new routing entry kept at a minimum.

   The MPR set can coincide with MUST the entire symmetric neighbor set.
   This could be added, with:

               R_dest_addr  = L_neighbor_iface_addr;

               R_next_addr  = L_neighbor_iface_addr;

               R_dist       = 1;

               R_iface_addr = L_local_iface_addr.

     3 the case at network initialization (and will correspond
   to classic link-state routing).

8.3.1.  MPR Computation

   The new route entries following specifies a proposed heuristic for the destination nodes h+1 hops away
          are recorded selection of MPRs.
   It constructs an MPR-set that enables a node to reach any node in the routing table.
   symmetrical strict 2-hop neighborhood through relaying by one MPR
   node with willingness different from WILL_NEVER.  The following procedure heuristic MUST
   be executed for each value of h, starting with h=1 and
          incrementing it by 1 each time. applied per interface, I.  The execution will stop if no
          new entry MPR set for a node is recorded in an iteration.

          3.1  For each topology entry in the topology table, if its
               T_dest_addr does not correspond to R_dest_addr union of any
               route entry
   the MPR sets found for each interface.  The following terminology
   will be used in describing the routing table AND its T_last_addr cor-
               responds to R_dest_addr heuristics:

     neighbor of an interface

               a route entry whose R_dist node is
               equal to h, then a new route entry MUST be recorded in "neighbor of an interface" if the routing table (if it does not already exist) where:

                    R_dest_addr = T_dest_addr;

                    R_next_addr = R_next_addr interface
               (on the local node) has a link to any one interface of
               the recorded route
                    entry whose R_dest_addr == T_last_addr

                    R_dist = h+1; and

                    R_iface_addr = R_iface_addr neighbor node.

     2-hop neighbors reachable from an interface

               the list of 2-hop neighbors of the recorded route
                    entry whose R_dest_addr == T_last_addr.

          3.2  Several topology entries may node that can be used to select
               reached from neighbors of this interface.

     MPR set of an interface

               a next hop
               R_next_addr for reaching (sub)set of the node R_dest_addr.  When h=1,
               ties should be broken such that nodes neighbors of an interface with highest a will-
               ingness and MPR selectors different from WILL_NEVER, selected such that
               through these selected nodes, all strict 2-hop neighbors
               reachable from that interface are preferred as next hop.

   If reachable.

     N:

               N is the MPR set has changed, a TC message containing subset of neighbors of the new MPR
   selector set SHOULD be generated.

6.  Node Configuration

   This section outlines how a node should be configured, in order to
   operate in an OLSR manet.

6.1.  Address Assignment node, which are
               neighbor of the interface I.

     N2:

               The nodes in set of two-hop neighbors reachable from the MANET network SHOULD be assigned addresses within a
   defined address sequence. I.e., interface
               I, excluding:

               (i)  the nodes only reachable by members of N with will-
                    ingness WILL_NEVER

               (ii) the nodes in node performing the MANET SHOULD be
   addressable through a network address and a netmask.

   Likewise, computation

               (iii)
                    all the symmetric neighbors: the nodes in each associated network SHOULD be assigned
   addresses from for which
                    there exists a symmetric link to this node on some
                    interface.

     D(y):

               The degree of an one hop neighbor node y (where y is a
               member of N), is defined address sequence, distinct from that being
   used in as the MANET.

6.2.  Routing Configuration

   Any MANET number of symmetric
               neighbors of node with associated networks or hosts SHOULD be configured
   such that it has routes set up to y, EXCLUDING all the interfaces with associated
   hosts or network.

6.3.  Data Packet Forwarding

   OLSR itself does not perform packet forwarding. Rather, it maintains members of N and
               EXCLUDING the routing table in node performing the underlying operating system, which computation.

   The proposed heuristic is
   assumed to be forwarding packets as specified in RFC1812.

7.  Multiple OLSR Interfaces

   A node may have multiple interfaces, each follows:

     1    Start with an MPR set made of all members of N with N_willing-
          ness equal to WILL_ALWAYS

     2    Calculate D(y), where y is a distinct IP address.
   These interfaces may either participate member of N, for all nodes in N.

     3    Add to the OLSR routing domain -
   or they may participate MPR set those nodes in other routing domains. Integrating infor-
   mation from non-OLSR routing domains into OLSR is described N, which are the *only*
          nodes to provide reachability to a node in sec-
   tion 8.

   A N2.  I.e.  if node with
          b in N2 can be reached only through a single OLSR interface, which wishes symmetric link to participate node a
          in N, then add node a network of to the MPR set.  Remove the nodes with multiple OLSR interfaces SHOULD implement from
          N2 which are now covered by a node in the provisions described MPR set.

     4    While there exist nodes in section #REF:midmf and 7.7. N2 which are not covered by at
          least one node in the MPR set:

          4.1  For nodes with multiple OLSR interfaces, participating each node in N, calculate the OLSR
   routing domain, reachability, i.e.  the provisions
               number of nodes in N2 which are not yet covered by at
               least one node in the MPR set, and which are reachable
               through this section MUST be applied.

7.1.  Terminology

   For one hop neighbor;

          4.2  Select as a MPR the purpose node with highest N_willingness among
               the nodes in N with non-zero reachability.  In case of Multiple OLSR Interfaces,
               multiple choice select the following terminol-
   ogy is introduced or refined:

     Multiple Interface Node

               A node which has multiple interfaces, participating provides
               reachability to the maximum number of nodes in an
               OLSR routing domain.

     Single Interface Node

               A 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 has a single interface, participating in an
               OLSR routing domain.

   Notice, that both a "Multiple Interface Node" and are now covered
               by a "Single Interface
   Node" may have additional interfaces, not participating node in the OLSR
   routing domain. Integrating information from these non OLSR inter-
   faces MPR set.

     5    A node's MPR set is described in section 8.

     Main Address

               The main address generated from the union of a the MPR sets
          for each interface.  As an optimization, process each node, which will be used y,
          in OLSR
               control traffic as the "originator address" MPR set in increasing order of N_willingness.  If all mes-
               sages emitted
          nodes in N2 are still covered by this node. It is the address of at least one of
               the interfaces of node in the node.

               A multiple interface MPR
          set excluding node MUST choose one of its inter-
               face addresses as its "main address". It is y, and if N_willingness of no impor-
               tance which address node y is chosen, however a
          smaller than WILL_ALWAYS, then node SHOULD
               always use y MAY be removed from the same address
          MPR set.

   Other algorithms, as its main address.

7.2.  Multiple Interface Functioning

   A node with multiple interfaces functions like a node with well as improvements over this algorithm, are
   possible.  For example, assume that in a single
   interface, i.e. through performing link-sensing, neighbor- multiple-interface scenario
   there exists more than one link between nodes 'a' and 2-hop
   neighbor detection, 'b'.  If node
   'a' has selected node 'b' as MPR selection and signaling, diffusion for one of topol-
   ogy control messages and route calculation.

   This section outlines the few additional provisions which must its interfaces, then node
   'b' can be
   made to accommodate for multiple selected as MPR without additional performance loss by any
   other interfaces in OLSR.

     Packet Sequence Number on node 'a'.

8.4.  Populating the MPR Selector Set

   The Packet Sequence Number (PSN), is now maintained per inter-
          face.  Each interface has its own PSN, which MPR selector set of a node, n, is put in populated by the
          packet header main addresses
   of the nodes which have selected n as specified in section 3.3.1, and incre-
          mented each time a packet is sent on this interface.

     Link Sensing

          Link Sensing MPR.  MPR selection is accomplished signaled
   through periodic emission of HELLO messages over the interfaces through which connectivity
          is checked. A separate messages.

8.4.1.  HELLO message is generated per Message Processing

   Upon receiving a HELLO message, if a node finds one of its own inter-
   face and emitted addresses in correspondence with the provisions in sec-
          tion 4.4.

          Resulting from Link Sensing is a local link set, describing
          links between "local interfaces" and "remote interfaces" -
          i.e. interfaces on neighbor nodes.

     Neighbor detection

          Given a network list with only single interface nodes, a node may
          deduct the neighbor set directly Neighbor Type equal to MPR_NEIGH,
   information from the information
          exchanged as part of link sensing: HELLO message must be recorded in the "main address" of a
          single interface node is, by definition, MPR Selec-
   tor Set.

   The "validity time" MUST be computed from the address Vtime field of the
          only interface on that node.

          In mes-
   sage header (see section 3.3.2).  The MPR Selector Set SHOULD
   then be updated as follows:

     1    If there exists no MPR selector tuple with:

                    MS_main_addr   == Originator Address

               then a network with multiple interface nodes, additional infor-
          mation new tuple is required in order to map interface addresses to main
          addresses (and, thereby, to nodes). This additional informa-
          tion created with:

                    MS_main_addr   =  Originator Address

     2    The tuple (new or otherwise) with

               MS_main_addr   == Originator Address

          is acquired through multiple interface declaration (MID)
          messages, then modified as described in section 7.3

          Thus, in the presence follows:

               MS_time        =  current time + validity time.

   Deletion of multiple interfaces, the neighbor set
          MUST be computed based on the information acquired through
          HELLO messages and MID messages, MPR selector tuples occurs in case of expiration of the
   timer or in case of link breakage as described in section
          7.5.

     MPR Selection the "Neighborhood
   and MPR Signaling

          The objective of MPR selection 2-hop Neighborhood Changes".

8.5.  Neighborhood and 2-hop Neighborhood Changes

   A change in the neighborhood is for a node to select a sub-
          set detected when:

     -    The L_SYM_time field of its neighbors such that a broadcasted message, retrans-
          mitted by these select neighbors, will be received by all
          nodes 2 hops away. A node will thus compute its MPR set such
          that it, for each interface, satisfies this condition. link tuple expires.  This is
          detailed in section 7.6.

          MPR signaling is provided in correspondence with the provi-
          sions in consid-
          ered as a neighbor loss if the previous section 4.3.

     Topology Control Message Diffusion

          Topology Control messages are diffused in correspondence with link described by the provisions in expired
          tuple was the previous section 5.5

     Route Calculation

          Multiple interfaces per last link with a neighbor node corresponds, effectively, to mul-
          tiple network destinations per node. Hence, (on the contrary,
          a link with an interface
          association informations acquired through the multiple inter-
          face declaration messages must be taken into account when pop-
          ulating may break while a link with another
          interface of the routing table. This neighbor node remains without being observed
          as a neighborhood change).

     -    A new link tuple is detailed inserted in section
          7.7

7.3.  Multiple Interface Declaration

   Each node the Link Set with multiple interfaces MUST announce, periodically,
   information describing its interface configuration to other nodes a non-
          expired L_SYM_time or a tuple with expired L_SYM_time is modi-
          fied so that L_SYM_time becomes non-expired.  This is consid-
          ered as a neighbor appearance if there was previously no link
          tuple describing a link with the corresponding neighbor node.

   A change in the network. This 2-hop neighborhood is accomplished through flooding detected when a Multiple Inter-
   face Declaration message 2-hop neighbor
   tuple expires or is deleted according to all nodes section 8.2.

   The following processing occurs when changes in the network through neighborhood or
   the MPR
   flooding mechanism.

   Each node in 2-hop neighborhood are detected:

     -    In case of neighbor loss, all 2-hop tuples with N_neigh-
          bor_main_addr == Main Address of the network maintains interface information about neighbor MUST be deleted.

     -    In case of neighbor loss, all MPR selector tuples with
          MS_main_addr == Main Address of the
   other nodes neighbor MUST be deleted

     -    The MPR set MUST be re-calculated when a neighbor appearance
          or loss is detected, or when a change in the network. This information acquired from MID-mes-
   sages, emitted by nodes with multiple interfaces participating in 2-hop neighbor-
          hood is detected.

     -    An additional HELLO message MAY be sent when the
   MANET, MPR set
          changes.

9.  Topology Discovery

   The link sensing and is used for routing table calculations.

   Specifically, multiple interface declaration associates multiple
   interfaces to a node (and to a main address) through populating neighbor detection part of the
   multiple interface association base in each node.

7.3.1.  Multiple Interface Association Information Base

   For protocol basi-
   cally offers, to each destination node, a list of neighbors with which it can
   communicate directly and, in combination with the network, "Interface association Tuples"
   (I_iface_addr, I_main_addr, I_time) are recorded. I_iface_addr is Packet Format and
   Forwarding part, an
   interface address of a node, I_main_addr optimized flooding mechanism through MPRs.  Based
   on this, topology information is disseminated through the main address network.
   The present section describes what part of this
   node.  I_time specifies the time at which this tuple expires information given by
   the link sensing and
   *MUST* be removed.

   In a node, neighbor detection is disseminated to the set of Interface association Tuples entire
   network and how it is denoted used to construct routes.

   Routes are constructed through advertised links and links with neigh-
   bors.  A node must at least disseminate links between itself and the
   "Interface association Set".

7.3.2.  MID
   nodes in its MPR-selector set, in order to provide sufficient infor-
   mation to enable routing.

9.1.  TC Message Format

   The proposed format of a MID TC message is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Interface              ANSN             |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Advertised Neighbor Main Address                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Interface               Advertised Neighbor Main Address                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This is sent as the data-portion of the general message format with
   the "Message Type" set to TC_MESSAGE.  The time to live SHOULD be set
   to 255 (maximum value) to diffuse the message into the entire network
   and Vtime set accordingly to the value of TOP_HOLD_TIME, as specified
   in section 18.3.

     Advertised Neighbor Sequence Number (ANSN)

          A sequence number is associated with the advertised neighbor
          set.  Every time a node detects a change in its advertised
          neighbor set, it increments this sequence number ("Wrap-
          around" is handled as described in section 19).  This
          number is sent in this ANSN field of the TC message to keep
          track of the most recent information.  When a node receives a
          TC message, it can decide on the basis of this Advertised
          Neighbor Sequence Number, whether or not the received informa-
          tion about the advertised neighbors of the originator node is
          more recent than what it already has.

     Advertised Neighbor Main Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          This is sent as field contains the data-portion main address of a neighbor node.  All
          main addresses of the general packet format
   described advertised neighbors of the Originator
          node are put in section 3.4, with the "Message Type" set to
   MID_MESSAGE. The time to live SHOULD be set to 255 (maximum value) to
   diffuse TC message.  If the message maximum allowed mes-
          sage size (as imposed by the network) is reached while there
          are still advertised neighbor addresses which have not been
          inserted into the TC-message, more TC messages will be gener-
          ated until the entire network and Vtime advertised neighbor set accordingly
   to the value has been sent.
          Extra main addresses of MID_HOLD_TIME, as specified in section 15.3.

     Interface Address neighbor nodes may be included, if
          redundancy is desired.

     Reserved

          This field contains is reserved, and MUST be set to "0000000000000000"
          for compliance with this document.

9.2.  Advertised Neighbor Set

   A TC message is sent by a node in the address network to declare a set of an interface
   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
          other than its main address (which already indicated in as a MPR.

   If, for some reason, it is required to distribute redundant TC infor-
   mation, refer to section 15.

   The sequence number (ANSN) associated with the
          originator address).

   All interface addresses other than advertised neighbor
   set is also sent with the list.  The ANSN number MUST be incremented
   when links are removed from the main address of advertised neighbor set; the Originator
   node ANSN
   number SHOULD be incremented when links are put in the MID message. If added to the maximum allowed message size
   (as imposed by advertised
   neighbor set.

9.3.  TC Message Generation

   In order to build the network) is reached while there are still inter-
   face addresses topology information base, each node, which have not has
   been inserted into the MID-message,
   more MID selected as MPR, broadcasts Topology Control (TC) messages.  TC
   messages are generated until the entire interface addresses
   set has been sent.

7.3.3.  MID Message Generation

   A MID message is sent by a node flooded to all nodes in the network to declare its multi-
   ple interfaces (if any). I.e., the MID message contains and take advantage
   of MPRs.  MPRs enable a better scalability in the list distribution of
   interface addresses which are associated to its main address.
   topology information [1].

   The list of addresses can be partial in each MID TC message (e.g.  due to
   message size limitations, imposed by the network), but parsing of all
   MID
   TC messages describing the interface advertised link set from of a node MUST be com-
   plete within a certain refreshing period (MID_INTERVAL). (TC_INTERVAL).  The informa-
   tion diffused in the network by these MID TC messages will help each node to
   calculate its routing table. A

   When the advertised link set of a node which has only becomes empty, it SHOULD still
   send (empty) TC-messages during the a single
   interface address participating duration equal to the "validity
   time" (typically, this will be equal to TC_HOLD_TIME) of its previ-
   ously emitted TC-messages, in order to invalidate the MANET (i.e. running OLSR),
   MUST NOT generate any MID message.

   A previous TC-
   messages.  It SHOULD then stop sending TC-messages until some node with more interfaces, where only one is participating
   inserted in the
   MANET and running OLSR (e.g. a its advertised link set.

   A node MAY transmit additional TC-messages to increase its reactive-
   ness to link failures.  When a change to the MPR selector set is connected
   detected and this change can be attributed to a wired network
   as well as to link failure, a MANET) MUST NOT generate any MID messages.

7.3.4.  MID TC-
   message SHOULD be transmitted after a shorter interval than TC_INTER-
   VAL.

9.4.  TC Message Forwarding

   MID

   TC messages are broadcasted broadcast and retransmitted by the MPRs in order to
   diffuse the messages in the entire network. The "default forward-
   ing algorithm" (described in section 3.4.1)  TC messages MUST be used
   for for-
   warded according to the "default forwarding of MID messages.

7.3.5.  MID algorithm".

9.5.  TC Message Processing

   The tuples in the multiple interface association set are recorded
   with the information that is exchanged through MID messages.

   Upon receiving a MID TC message, the "validity time" MUST be computed
   from the Vtime field of the message header (as described in the sec-
   tion 4.2). (see section 3.3.2).
   The Multiple Interface Association Informa-
   tion Base SHOULD then be updated as follows:

          For each interface address listed in the MID message:

          1    If there exist some tuple in the interface association
               set where:

                    I_iface_addr == interface address, AND

                    I_main_addr == originator address,

               then the holding time of that tuple is set to:

                    I_time = current time + validity time.

          2    Otherwise, a new tuple is recorded in the interface asso-
               ciation topology set where:

                    I_iface_addr = interface address,

                    I_main_addr = originator address,

                    I_time = current time + validity time.

7.4.  Main Addresses vs. Interface Addresses

   In general, the only part of OLSR concerning "interface addresses" is
   link sensing. The remaining parts of OLSR operates on nodes, uniquely
   identified by their "main addresses" (effectively, the main address
   of a node is its "node id" - which for convenience corresponds to the
   address of one of its interfaces). In a network with only single
   interface nodes, the main address of a node will, by definition, SHOULD then be
   equal to the interface address updated as follows (using section
   19 for comparison of ANSN):

     1    If the node. In networks with multiple
   interface nodes, it is required to be able to map any interface
   address to the corresponding main address.

   Section 7.3 provides a way in which sender interface information (NB: not originator) of this message
          is
   acquired by nodes not in the network. This permits identification of a
   nodes "main address", given one symmetric 1-hop neighborhood of its interface addresses.

   Given an interface address:

     1    if this node, the
          message MUST be discarded.

     2    If there exists exist some tuple in the interface association topology set where:

               I_iface_addr

               T_last_addr == interface originator address AND

               T_seq       >  ANSN,

          then the result further processing of this TC message MUST NOT be per-
          formed and the main address search is message MUST be silently discarded (case: mes-
          sage received out of order).

     3    All tuples in the topology set where:

               T_last_addr == originator address I_main_addr of the tuple.

     2    Otherwise, AND

               T_seq       <  ANSN

          MUST be removed from the result topology set.

     4    For each of the advertised neighbor main address search is the inter-
          face address itself.

7.5.  Populating the Neighbor Set

   The Neighbor Set is populated in accordance with the provisions received in
   section 4.4, with the precision that for each interface
   address, the corresponding Main Address for creating
          the neighbor TC message:

          4.1  If there exist some tuple is obtained through the mechanism described in section
   7.4 and inserted into the Neighbor Set.

7.6.  Populating the MPR Set

   The MPR topology set MUST 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.

   For where:

                    T_dest_addr == advertised neighbor main address, AND

                    T_last_addr == originator address,

               then the purpose holding time of computing the MPR that tuple MUST be set in to:

                    T_time      =  current time + validity time.

          4.2  Otherwise, a node with multiple
   interfaces, new tuple MUST be recorded in the following additional definitions are required: topology
               set where:

                    T_dest_addr = advertised neighbor of an interface

               a main address,

                    T_last_addr = originator address,

                    T_seq       = ANSN,

                    T_time      = current time + validity time.

10.  Routing Table Calculation

   Each node is a "neighbor of an interface" if the interface
               (on the local node) has maintains a link routing table which allows it to any one interface of route data,
   destined for the neighbor node.

     two-hop neighbors reachable from an interface other nodes in the list of two-hop neighbors of network.  The routing table is
   based on the node that can be
               reached from neighbors of this interface.

     MPR information contained in the link set of an interface

               A (sub)set of and the neighbors topology
   set.  Therefore, if any of an interface, selected
               such that through these selected nodes, all two-hop
               neighbors reachable from that interface sets are reachable.

7.6.1.  MPR Computation changed, the routing table
   is re-calculated to update the route information about each destina-
   tion in the network.  The heuristics, proposed route entries are recorded in the routing
   table in section 4.6.2, is applied, with the following changes:

     -    The algorithm is applied per interface I.

     -    N is now defined as "The subset of neighbors format:

         1.  R_dest_addr    R_next_addr    R_dist   R_iface_addr
         2.  R_dest_addr    R_next_addr    R_dist   R_iface_addr
         3.      ,,             ,,           ,,          ,,

   Each entry in the table consists of R_dest_addr, R_next_addr, R_dist,
   and R_iface_addr.  Such entry specifies that the node identified by
   R_dest_addr is estimated to be R_dist hops away from the local node,
          which are neighbor of
   that the symmetric neighbor node with interface I".

     -    N2 address R_next_addr
   is now defined as "The set of two-hop neighbors reachable
          from the interface I, excluding:

          (i) next hop node in the nodes only route to R_dest_addr, and that this sym-
   metric neighbor node is reachable by members of N through the local interface with willingness
               WILL_NEVER

          (ii)
   the node performing address R_iface_addr.  Entries are recorded in the computation

          (iii)
               all routing table
   for each destination in the symmetric neighbors: network for which a route is known.  All
   the nodes destinations, for which there
               exists a symmetric link to this node on some interface." route is broken or only partially
   known, are not recorded in the table.

   The MPR set of routing table is updated when a node change is then detected in either:

     -    the union of link set,

     -    the MPR sets found for
   each interface.

   Note that other algorithms and improvements are possible. For exam-
   ple, when neighbor set,

     -    the MPRs 2-hop neighbor set,

     -    the topology set,

     -    the Multiple Interface Association Information Base,

   More precisely, the routing table is re-calculated in case of neigh-
   bor appearance or loss, when a 2-hop tuple is created or removed,when
   a topology tuple is created or removed or when multiple interface
   association information changes.  The update of this routing informa-
   tion does not generate or trigger any messages to be transmitted,
   neither in the first m interfaces have already been iden-
   tified, for each network, nor in the 1-hop neighborhood.

   To construct the routing table of them which node X, a shortest path algorithm
   is run on the directed graph containing the arcs X -> Y where Y is also
   any symmetric neighbor of the (m+1)th inter-
   face, it is possible to ignore its two-hop neighbors (i.e. it is
   assumed X (with Neighbor Type equal to be chosen as MPR again by the (m+1)th interface 'for
   free').

7.7.  Routing Table Calculation

   A multiple interface compliant implementation MUST complement further
   the routing table using SYM), the multiple interface association set, after
   it has been (re)calculated:

     1    For each
   arcs Y -> Z where Y is a neighbor node with willingness different of
   WILL_NEVER and there exists an entry in the multiple interface association base 2-hop Neighbor set with Y
   as N_neighbor_main_addr and Z as N_2hop_addr, and the arcs U -> V,
   where there exists a routing an entry such that:

               R_dest_addr == I_main_addr (of in the multiple interface
               interface association entry)
          a route entry topology set with V as T_dest_addr
   and U as T_last_addr.

   The following procedure is created in given as an example to calculate (or re-
   calculate) the routing table with:

               R_dest_addr  = I_iface_addr (of the multiple interface
               association entry)

               R_next_addr  = R_next_addr (of the recorded route entry)

               R_dist       = R_dist (of the recorded route entry)

               R_iface_addr = R_iface_addr (of :

     1    All the recorded route
               entry).

   In addition, now, entries from the routing table is updated by recalculating also
   when are removed.

     2    The new routing entries are added starting with the multiple interface association set has changed.

7.8.  Changes to symmetric
          neighbors (h=1) as the "Default Forwarding Algorithm"

   When destination nodes.  I.e.  for each
          neighbor tuple in the neighbor set where:

               N_status   = SYM

          (there is a node as several interfaces, both symmetric link to the "Forwarding condition" of
   section 3.4 (step 4.1), neighbor), and the "default forwarding algo-
   rithm" described previously in section 3.4.1 MUST be
   changed.

   The Forwarding condition of section 3.4 (step 4.1) MUST be
   changed for all messages to each
          associated link tuple of the following:

     4    Forwarding condition:

          4.1  if there exists neighbor node such that L_time >=
          current time, a tuple new routing entry is recorded in the duplicate set, where:

                                D_addr == Originator Address, AND

                                D_seq_num == Message Sequence Number,
                    AND routing
          table with:

               R_dest_addr  = L_neighbor_iface_addr, of the sender interface address is in
                    D_interface_list

               then
                              associated link tuple;

               R_next_addr  = L_neighbor_iface_addr, of the message has already been considered for forward-
               ing and SHOULD NOT be retransmitted again.

          4.2  Otherwise: do as specified before in step 4.2 in section
               3.4 ...

   Additionality,
                              associated link tuple;

               R_dist       = 1;

               R_iface_addr = L_local_iface_addr of the "default forwarding algorithm" described previ-
   ously
                              associated link tuple.

          If in section 3.4.1 MUST be changed.  This change
   applies to unknown message types, but also to all known messages
   which are explicitly documented the above, no R_dest_addr is equal to use the "default forwarding algo-
   rithm" in this specification.

   First two main address
          of the neighbor, then another new fields must routing entry with MUST be added to the duplicate set:

     D_retransmitted

          A boolean indicating whether
          added, with:

               R_dest_addr  = main address of the message has been already
          retransmitted.

     D_interface_list

          A list neighbor;

               R_next_addr  = L_neighbor_iface_addr of one of the addresses
                              associated link tuple with L_time >= cur-
               rent time;

               R_dist       = 1;

               R_iface_addr = L_local_iface_addr of the interfaces on
                              associated link tuple.

     3    for each node in N2, i.e a 2-hop neighbor which the message
          has been received.

   The multiple interface default forwarding algorithm is not a
          neighbor node or the node itself, and such that there exist at
          least one entry in the 2-hop neighbor set where N_neigh-
          bor_main_addr correspond to a neighbor node with willingness
          different of WILL_NEVER, one selects one 2-hop tuple and cre-
          ates one entry in the following:

     1    If routing table with:

               R_dest_addr  =  the sender interface main address of the message is not detected
          to be two hop neighbor;

               R_next_addr  = the R_next_addr of the entry in the symmetric neighborhood
                              routing table with:

                                  R_dest_addr == N_neighbor_main_addr
                                                 of the node, 2-hop tuple;

               R_dist       = 2;

               R_iface_addr = the forward-
          ing algorithm MUST silently stop here (and R_iface_addr of the message will
          not be forwarded).

     2    If an entry exists in the duplicate set
                              routing table with:

               D_addr = originator address

               D_seq_num = Message Sequence Number

          Then

                                  R_dest_addr == N_neighbor_main_addr
                                                 of the message will 2-hop tuple;

     3    The new route entries for the destination nodes h+1 hops away
          are recorded in the routing table.  The following procedure
          MUST be further considered executed for forwarding if each value of h, starting with h=2 and only if:

               D_retransmitted
          incrementing it by 1 each time.  The execution will stop if no
          new entry is false

               and the (address of the) interface which received the
               message isn't recorded in D_interface_list

     3    Otherwise, if such an iteration.

          3.1  For each topology entry doesn't exist, in the message is fur-
          ther considered for forwarding.

   If after those steps, topology table, if its
               T_dest_addr does not correspond to R_dest_addr of any
               route entry in the message routing table AND its T_last_addr cor-
               responds to R_dest_addr of a route entry whose R_dist is not considered for forwarding,
               equal to h, then a new route entry MUST be recorded in
               the processing routing table (if it does not already exist) where:

                    R_dest_addr  = T_dest_addr;

                    R_next_addr  = R_next_addr of this section stops (i.e. steps 4 the recorded
                                   route entry where:

                                   R_dest_addr == T_last_addr

                    R_dist       = h+1; and
                    R_iface_addr = R_iface_addr of the recorded
                                   route entry where:

                                      R_dest_addr == T_last_addr.

          3.2  Several topology entries may be used to 7 are
   ignored), otherwise, if it is still considered select a next hop
               R_next_addr for forwarding then reaching the following algorithm is used: node R_dest_addr.  When h=1,
               ties should be broken such that nodes with highest will-
               ingness and MPR selectors are preferred as next hop.

     4    If    For each entry in the sender interface address is an multiple interface address of association base
          where there exists a
          MPR selector of this node and if the time to live of routing entry such that:

               R_dest_addr  == I_main_addr  (of the mes-
          sage multiple interface
                                            association entry)

          AND there is greater than '1', the message MUST be retransmitted
          (as described later).

     5    If no routing entry such that:

               R_dest_addr  == I_iface_addr

          then a route entry is created in the duplicate set exists, with same originator
          address, and same message sequence number

          Then it is updated:

               D_time routing table with:

               R_dest_addr  = current time + D_HOLD_TIME.

               The receiving  I_iface_addr (of the multiple interface address is added to D_inter-
               face_list.

               D_retransmitted is set to true if and only if
                                             association entry)

               R_next_addr  =  R_next_addr  (of the message
               will recorded
                                             route entry)

               R_dist       =  R_dist       (of the recorded
                                             route entry)

               R_iface_addr =  R_iface_addr (of the recorded
                                             route entry).

11.  Node Configuration

   This section outlines how a node should be retransmitted according configured, in order to step 4.

          Otherwise
   operate in an entry OLSR MANET.

11.1.  Address Assignment

   The nodes in the duplicate set is recorded with:

               D_addr = originator MANET network SHOULD be assigned addresses within a
   defined address

               D_seq_num = Message Sequence Number

               D_time = current time + D_HOLD_TIME.

               D_interface_list contains sequence.  I.e., the nodes in the receiving interface
               address.

               D_retransmitted is set to true if MANET SHOULD be
   addressable through a network address and only if a netmask.

   Likewise, the message
               will nodes in each associated network SHOULD be retransmitted according to step 4.

   If, and only if, according to step 4, assigned
   addresses from a defined address sequence, distinct from that being
   used in the message must MANET.

11.2.  Routing Configuration

   Any MANET node with associated networks or hosts SHOULD be retransmit-
   ted then configured
   such that it has routes set up to the following steps are followed:

     5    The TTL of interfaces with associated
   hosts or network.

11.3.  Data Packet Forwarding

   OLSR itself does not perform packet forwarding.  Rather, it maintains
   the message is reduced by one.

     6    The hop-count of routing table in the message is increased by one

     7    The message underlying operating system, which is broadcasted on all interfaces (Notice: The
          remaining fields of the message header SHOULD
   assumed to be left unmodi-
          fied.)

8. forwarding packets as specified in RFC1812.

12.  Non OLSR Interfaces

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

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

   Injecting routing information from the OLSR manet MANET to non-OLSR inter-
   faces is outside the scope of this specification.  It should be
   clear, however, that the routing information for the OLSR manet MANET can
   be extracted from the topology table (see section 5.2) 4.4) or
   directly from the routing table of OLSR, and must SHOULD be injected onto
   the non-
   OLSR non-OLSR interfaces following whatever mechanism (routing protocol, proto-
   col, 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
   running, as well as a wireless network interface running OLSR.

   Notice that this is a different case from that of "multiple inter-
   faces", where all the interfaces are participating in the MANET
   through running the OLSR protocol. Multiple interfaces participating
   in the OLSR manet is described in section 7.

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

8.1.

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 sec-
   tion 15.3.

   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).
   In the TC-message, no netmask is required, since all reachability is
   announced on a per-host basis. In HNA-messages, announcing reachabil-
   ity field set to an address sequence through a network- 255 and netmask address is
   typically preferred over announcing reachability Vtime
   set accordingly to individual host
   addresses.

   An important difference between TC- and HNA-messages is, that a TC
   message may have a cancelling effect on previous information (if the
   MSSN is incremented), whereas information value of HNA_HOLD_TIME, as specified in HNA-messages is removed
   only upon expiration. sec-
   tion 18.3.

     Network Address

          The network address of the associated network

     Netmask

          The netmask, corresponding to the network address immediately
          above.

8.2.

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 a OLSR interface of the gateway,
   A_network_addr and A_netmask specifies specify the network address and net-
   mask netmask
   of a network, reachable through this gateway, and A_time speci-
   fies 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 "associa-
   tion set".

8.3.

   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).
   In the TC-message, no netmask is required, since all reachability is
   announced on a per-host basis.  In HNA-messages, announcing reacha-
   bility 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 gen-
   erate 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 15.3. 18.3.

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

8.4.

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.

8.5.

12.5.  HNA Message Processing

   In this section, the term "originator address" is used to designate
   the main address on the OLSR manet 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    For    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
          message:

          1.1

          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

          1.2

          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

8.6.

12.6.  Routing Table Calculation

   In addition to the routing table computation as described in section
   5.7,
   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 is created.

     2    If a new routing entry was created at the host and network 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 MUST be added as
   follows:

     1    For each tuple in tuple,

          then the routing set, an entry in the routing
          table MUST be recorded, with: is modified as follows:

               R_dest_addr     =  A_network_addr/A_netmask

               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 val-
               ues as the tuple from the routing set with R_dest_addr ==
               A_gateway_addr.

9.

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 for-
   warded 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, how-
   ever 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.1, 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 reccomended recommended in section 10.3, 14, thus link hysteresis
   and link layer notifications can coexist).

   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 and LOST_LINK.  In addition, it is not consid-
          ered as a symmetrical link in the updates of the associated
          neighbor type NOT_NEIGH ;

     1 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 +
          NEIGHB_HOLD_TIME.

     2

     3    this is considered as a link loss and the appropriate process-
          ing described in section 4.8 8.5 should be performed.

10.

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 specifica-
   tion.

14.  Link Hysteresis

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

10.1. considered.

14.1.  Local Link Set

   Each link tuple in the local link set SHOULD, in addition to what is
   described in section 4.1, 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 dimen-
   sionless 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.

10.2.

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 and neighbor type NOT_NEIGH ; 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 previ-
          ously in section 4. 6.

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

     1    L_LOST_LINK_time is expired, AND

     2    L_link_pending is "false", AND

     3    L_SYM_time is not expired.

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

   Apart from the above points, above, what has been described previously does not
   interfere with these 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.

10.3.

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 NEIGHB_HOLD_TIME. In absence of
   link layer notification, such a bad link might affect routing badly.
   To cope with such unstable links, the "validity time".  The following
   hysteresis strategy SHOULD be adopted. adopted to counter this situation.

   For each neighbor interface NI heard by interface I, the L_link_qual-
   ity field of the corresponding Link Tuple determines the establish-
   ment of the link.  The value of L_link_quality is compared to two
   thresholds HYST_THRESHOLD_HIGH, HYST_THRESHOLD_LOW, fixed between 0
   and 1 and such that HYST_THRESHOLD_HIGH >= HYST_THRESHOLD_LOW.

   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 +
               NEIGHB_HOLD_TIME)

               (the link is then considered as lost according to section
               4.8
               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 loosing it. 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).  Specif-
   ically, this implies that, regardless of whether or not the link hys-
   teresis 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 exponen-
   tially exponentially smoothed moving average of the
   transmission success rate).  The algorithm is parameterized by a
   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 -
   1).

   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_SCAL-
          ING. 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 "long period of
   silence.  If
   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 inter-
   face NI during hello HELLO emission interval of interface NI (computed from
   the Htime field in the last hello HELLO message received from NI), a loss
   of an OLSR packet is detected.

11.  Distributing

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 e.g.  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 previ-
   ous sections of this specification.

15.  Redundant Topology Information

   In order to provide redundancy to topology information base, the
   advertised link set of a node can MAY contain links to neighbor nodes
   which are not in MPR selector set of the node.  The advertised link
   set can be MAY contain links to the whole neighbor set of the node. In this case the nodes
   receiving the TC message will get the knowledge  The
   minimal set of all links that any node MUST advertise in its TC messages
   is the adjacent links of to the sender node. nodes MPR selectors.  The advertised link set can
   be built according to the following rule based on a local parameter
   called TC_REDUNDANCY parameter.

11.1.

15.1.  TC_REDUNDANCY Parameter

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

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

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

     -    if the TC_REDUNDANCY parameter of the node is 2, then its the
          advertised link set of the node is the full neighbor set (full link-state information is
          diffused). link set.

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

12.

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 informa-
   tion 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 being, is, that all strict 2-hop nodes must be
   reachable through, at least, one MPR node.  Redundancy of the MPR set
   affects the overhead through affecting the amount of links being
   advertised, the amount of nodes advertising links to the MPR selector 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.  E.g.  a node can 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.

12.1.

16.1.  MPR_COVERAGE Parameter

   The MPR coverage is defined by a single local parameter, MPR_COVER-
   AGE, 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 4.6.3. 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. 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.  I.e.  nodes in a network may operate
   with different values of MPR_COVERAGE.

12.2.

16.2.  MPR Computation

   Using MPR coverage, the MPR selection heuristics is extended from
   that described in the section 4.6.3 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 willing-
          ness equal to WILL_ALWAYS

     2    Calculate D(y), where y is a member of N, for all nodes in N.

     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 one 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 reachabil-
               ity to the maximum number of nodes 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 cal-
   culated 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.

   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 infor-
   mation required to construct routes as described in sections 9
   and 10.

17.  IPv6 Considerations

   All the operations and parameters described in N2.  In case of
               multiple nodes providing this document used by
   OLSR for IP version 4 are the same amount of reachability,
               select the node as MPR whose D(y) those used by OLSR for IP ver-
   sion 6.  To operate with IP version 6, the only required change is greater. Remove to
   replace the
               nodes from N2 IPv4 addresses with IPv6 address.  The minimum packet and
   message sizes (under which are now covered by MPR_COVERAGE nodes
               in there is rejection) should be adjusted
   accordingly, considering the MPR set.

     5    As an optimization, process each node y in greater size of IPv6 addresses.

18.  Proposed Values for Constants

   This section list the MPR set values for the constants used in the
          increasing order descrip-
   tion of their willingness.  If all nodes in N2 are
          still covered by at least MPR_COVERAGE nodes in the MPR set
          excluding y protocol.

18.1.  Setting emission intervals and willingness of node y is smaller than
          WILL_ALWAYS, then node y holding times

   The proposed constant for C is removed from the MPR set.

   When the MPR set has been computed, all following:

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

   C is a scaling factor for the corresponding main
   addresses are stored "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 inter-
   vals, while still interoperate fully.  For protocol functioning and
   interoperability to work:

     -    the advertised holding time MUST always be greater than the MPR Set.

   Notice, that for MPR_COVERAGE=1, this heuristics
          refresh interval of the advertised information.  Moreover, it
          is identical to recommended that the
   heuristics specified in relation between the interval (from
          section 4.6.3.

13.  IPv6 Considerations

   All the operations 18.2), and parameters described in this document used by
   OLSR for IP version 4 are the same hold time is kept as those used by OLSR specified
          in section 18.3, to allow for IP ver-
   sion 6.  However, reasonable packet loss.

     -    the constant C SHOULD be set to operate with IP version 6, the only required
   change is suggested value.  In order
          to replace achieve interoperability, C MUST be the IPv4 addresses same on all nodes.

     -    the emission intervals (section 18.2), along with IPv6 address.

14.  Security Considerations

   Currently, OLSR does not specify any security measures. However as the
          advertised holding times (subject to the above constraints)
          MAY be selected on a
   proactive routing protocol, it makes per node basis.

   Note that the timer resolution of a target given implementation might not be
   sufficient to wake up the system on precise refresh times or on pre-
   cise expire times: the implementation SHOULD round up the 'validity
   time' ("Vtime" and "Htime" of packets) to compensate for various attacks.
   The various possible vulnerability are discussed coarser
   timer resolution, at least in this section.

14.1.  Confidentiality

   Being a proactive protocol, OLSR periodically diffuses topological
   information. Hence, if used 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

          NEIGHB_HOLD_TIME      = 3 x REFRESH_INTERVAL

          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 an unprotected wireless network, the
   network topology is revealed to anyone who listens to OLSR control
   messages. 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 situations other words:

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

   where a is the confidentiality of integer represented by the network topology is four highest bits of
   importance, regular cryptographic techniques can be applied to ensure
   that control traffic can be read the
   field and interpreted b the integer represented by only those autho-
   rized to do so.

14.2.  Integrity

   In OLSR, each node is injecting topological information into the net-
   work through transmitting HELLO messages and, for some nodes, TC mes-
   sages. If some nodes four lowest bits of the
   field.

   Notice, that for some reason, malicious or malfunction,
   injects invalid control traffic, network integrity may be compro-
   mised.

   Different such situations may occur:

     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 generate HELLO messages, advertising non-neighbor
          nodes,

     4    a node generate HELLO messages, pretending to be another node.

     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

   Authenticated signatures on control messages (for situation 2, 4 and
   5) and on the individual links announced previous proposed value of C, (1/16 seconds),
   the values, in seconds, expressed by the control messages (for
   situation 1 and 3) may formula above can be used as 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.

   Given one of the above holding times, a countermeasure. However to pre-
   vent nodes from repeating old (and correctly authenticated) informa-
   tion temporal information is required, allowing way of computing the man-
   tissa/exponent representation of a node to positively
   identify number T (of seconds) is the fol-
   lowing:

     -    find the largest integer 'b' such delayed messages.

   Signatures and other required security information that: T/C >= 2^b
     -    compute the expression 16*(T/(C*(2^b))-1), which may not be transmitted
   as a separate OLSR message type, thereby allowing that "secured"
          integer, and
   "unsecured" nodes can coexist round it up.  This results in the same network, value for 'a'

     -    if desired.

14.3.  Interaction with External Routing Domains

   OLSR does, through '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 HNA messages specified in section 8,
   provide
          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

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 basic mechanism for injecting external routing information
   to the OLSR domain. Section 8 also specifies that routing
   information can node may be extracted from the topology 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 14.2, when operating
   nodes, connecting OLSR set to an external routing domain, care MUST be
   taken not any integer value from 0 to allow potentially insecure
   7, and un-trustworthy informa-
   tion specifies how willing a node is to be injected from the OLSR domain 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 external routing domains.
   I.e.
   carry traffic for other nodes, e.g.  due to resource constraints
   (e.g.  low on battery).  WILL_ALWAYS indicates that a node MUST NOT take raw and invalidated information from the
   OLSR topology tables and inject into any external routing domain.
   Care MUST always
   should be taken selected to validate the correctness carry traffic on behalf of information prior other nodes, e.g.
   due to it being injected as resource abundance (e.g.  permanent power supply, high-capac-
   ity interfaces to avoid polluting routing tables with
   invalid information. other nodes).

   A recommended way of extending connectivity from an existing routing
   domain node may dynamically change its willingness as its conditions
   change.

   One possible application would, for example, be for a node, connected
   to an OLSR routed manet is a permanent power supply and with fully charged batteries, to assign an IP sequence (under the
   authority
   advertise a willingness of WILL_ALWAYS.  Upon being disconnected from
   the nodes/gateways connecting the manet with permanent power supply (e.g.  a PDA being taken out of its charg-
   ing cradle), a willingness of WILL_DEFAULT is advertised.  As battery
   capacity is drained, the exiting
   routing domain) exclusively willingness would be further reduced.  First
   to the OLSR manet, intermediate value between WILL_DEFAULT and WILL_LOW, then to configure the
   gateways statically to advertise routes to that IP sequence
   WILL_LOW and finally to nodes
   in the existing routing domain.

15.  Proposed Values for Constants

   This section list WILL_NEVER, when the values for battery capacity of the constants
   node does no longer support carrying foreign traffic.

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 descrip-
   tion purpose of the protocol.

15.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 discarding
   "old" information, i.e.  messages received out of order.  However
   with a scaling factor limited number of bits for representing sequence numbers,
   wrap-around (that the "validity time" calculation ("Vtime"
   and "Htime" fields in message headers, see section 15.3).
   The "validity time" advertisement sequence number is designed such that nodes in a
   network may have different and individually tuneable emmision inter-
   vals, while still interoperate fully. For protocol functionning and
   interoperability to work:

     -    the advertised holding time MUST always be greater than the
          refresh interval of incremented from the advertised information. Moreover, it
          is recommended that maximum
   possible value to zero) will occur.  To prevent this from interfering
   with the relation between operation of the interval (from
          section 15.2), and protocol, the hold time is kept as specified following MUST be observed.

   The term MAXVALUE designates in section 15.3, to allow for reasonable packet loss.

     - the constant C SHOULD be set to following the suggested value. In order largest possible
   value for a sequence number.

   The sequence number S1 is said to achieve interoperability, C MUST be "greater than" the same on all nodes. sequence num-
   ber S2 iff:

          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 emission intervals (section 15.2), along with the
          advertised holding times (subject pres-
   ence of wrap-around - to determine which message contains the above constraints)
          MAY be selected on most
   recent information.

20.  Security Considerations

   Currently, OLSR does does not specify any special security measures.
   As a per node basis.

15.2.  Emission Intervals

          HELLO_INTERVAL        = 2 seconds

          REFRESH_INTERVAL      = 2 seconds

          TC_INTERVAL           = 5 seconds

          MID_INTERVAL          = TC_INTERVAL

          HNA_INTERVAL          = TC_INTERVAL

15.3.  Holding Time

          NEIGHB_HOLD_TIME      = 3 x REFRESH_INTERVAL

          TOP_HOLD_TIME         = 3 x TC_INTERVAL

          D_TIME                = 30 seconds

          MID_HOLD_TIME         = 3 x MID_INTERVAL

          HNA_HOLD_TIME         = 3 x HNA_INTERVAL proactive routing protocol, OLSR makes a target for various
   attacks.  The Vtime in the message header (see section 3.3.2), and the
   Htime in the HELLO message (see section 4.2) various possible vulnerability are the
   fields which hold information about the above values discussed in mantissa and
   exponent format (rounded up). 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
   messages.

   In other words:
     value = C*(1+a/16)*2^b situations where a is the integer represented by the four highest bits confidentiality of the
   field network topology is of
   importance, regular cryptographic techniques can be applied to ensure
   that control traffic can be read and b the integer represented interpreted by the four lowest bits of the
   field.

   Given one of the above holding times, one way only those autho-
   rized to compute the man-
   tissa/exponent representation of a number T (of seconds) do so.

20.2.  Integrity

   In OLSR, each node is injecting topological information into the fol-
   lowing:

     -    find the biggest integer 'b' such as: T/C > 2^b

     -    compute the expression 16*(T/(C*(2^b))-1), which net-
   work through transmitting HELLO messages and, for some nodes, TC mes-
   sages.  If some nodes for some reason, malicious or malfunction,
   inject invalid control traffic, network integrity may not be a
          integer, and round it up.  The result gives 'a'

     -     'a' and 'b' should now be integers between 0 and 15, and the
          field will be a byte holding the value a*16+b
   For instance, for values of 6 seconds, 15 seconds, and 30 seconds
   respectively, a and b would be: (a=8,b=6), (a=14,b=7) and (a=14,b=8)
   respectively.

15.4.  Message Types

          HELLO_MESSAGE         = 1

          TC_MESSAGE            = 2

          MID_MESSAGE           = 3

          HNA_MESSAGE           = 4

15.5.  Link Types

          UNSPEC_LINK           = 0

          ASYM_LINK             = 1

          SYM_LINK              = 2

          LOST_LINK             = 3

15.6.  Neighbor Types

          NOT_NEIGH             = 0

          SYM_NEIGH             = 1

          MPR_NEIGH             = 2

15.7.  Link Hysteresis

          HYST_THRESHOLD_HIGH   = 0.8

          HYST_THRESHOLD_LOW    = 0.3

          HYST_SCALING          = 0.5

15.8.  Willingness

          WILL_NEVER            = 0

          WILL_LOW              = compromised.
   Therefore, message authentication is recommended.

   Different such situations may occur, for instance:

     1

          WILL_DEFAULT          =    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

          WILL_HIGH             =    a node generates HELLO messages, advertising non-neighbor
          nodes,

     4    a node generates HELLO messages, pretending to be another
          node.

     5    a node forwards altered control messages,

     6

          WILL_ALWAYS           =    a node does not broadcast control messages,

     7

   The willingness of    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.

   Authenticated signatures on 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 set used as a countermeasure.  However to any integer value pre-
   vent nodes from 0 to
   7, and specifies how willing repeating old (and correctly authenticated) informa-
   tion (situation 9) temporal information is required, allowing a node is
   to be forwarding traffic on
   behalf of positively identify such delayed messages.

   Signatures and other nodes. Nodes will, by default, have required security information may be transmitted
   as a willingness
   WILL_DEFAULT. WILL_NEVER indicates separate OLSR message type, thereby allowing that "secured" and
   "unsecured" nodes can coexist in the same network, if desired.

20.3.  Interaction with External Routing Domains

   OLSR does, through the HNA messages specified in section 12,
   provide a node which does not wish to
   carry traffic basic mechanism for other nodes, e.g. due injecting external routing information
   to ressource constraints
   (e.g. low on battery). WILL_ALWAYS indicates the OLSR domain.  Section 12 also specifies that a node always
   should routing
   information can be selected to carry traffic on behalf extracted from the topology table or the routing
   table of other 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, e.g.
   due to ressource abundance (e.g. permanent power supply, high-capac-
   ity interfaces connecting OLSR to other nodes).

   A node may dynamically change its willingness as its conditions
   change.

   One possible application would, for example, an external routing domain, care MUST be for a node, connected
   taken not to a permanent power supply allow potentially insecure and with fully charged batteries, un-trustworthy informa-
   tion to
   advertise a willingness of WILL_ALWAYS. Upon being disconnected be injected from the permanent power supply (e.g. a PDA being taken out of its charg-
   ing cradle), a willingness of WILL_DEFAULT is advertised. As battery
   capacity is drained, the willingness would OLSR domain to external routing domains.
   Care MUST be further reduced. First taken to validate the intermediate value between WILL_DEFAULT and WILL_LOW, then correctness of information prior
   to
   WILL_LOW and finallt it being injected as to WILL_NEVER, when the battery capacity avoid polluting routing tables with
   invalid information.

   A recommended way of the
   node does no longer support carrying forigen traffic.

15.9.  Misc. Constants

          TC_REDUNDANCY         = 0

          MPR COVERAGE          = 1

          MAXJITTER             = HELLO_INTERVAL / 4

16.  Sequence Numbers

   Sequence numbers are used in extending connectivity from an existing routing
   domain to an OLSR with routed MANET is to assign an IP prefix (under the purpose of discarding
   "old" information, i.e. messages received out of order. However with
   a limited number
   authority of bits for representing sequence numbers, wrap-
   around (that the sequence number is incremented from nodes/gateways connecting the maximum pos-
   sible value to zero) will occur. To prevent this from interfering MANET with the operation of exiting
   routing domain) exclusively to the protocol, OLSR MANET area, and to configure
   the following MUST be observed.

   The term MAXVALUE designates gateways statically to advertise routes to that IP sequence to
   nodes in the following existing routing domain.

20.4.  Node Identity

   OLSR does not make any assumption about node addresses, other than
   that each node is assumed to have an unique IP addresses.  Therefore,
   no special considerations can be made about the largest possible
   value for applicability of
   IPsec authentication headers or key exchange mechanisms.

21.  IANA Considerations

   OLSR defines a sequence number.

   The sequence number S1 "Message Type" field for control messages.  A new reg-
   istry is said to be "greater than" created for the sequence num-
   ber S2 iff:

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

          S2 > S1 AND S2 - S1 > MAXVALUE/2

   Thus when comparing two messages, it is possible - even 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 pres-
   ence range 5-127 of wrap-around - to determine which message contains the most
   recent information.

17. Message Type can be allocated
   using standards action [7].

   Additionally, values in the range 128-255 are reserved for pri-
   vate/local use.

22.  Acknowledgments

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

   The authors would also like to thank Christopher Dearlove
   <chris.dearlove@baesystems.com> for valuable input on the MPR selec-
   tion heuristics.

18. heuristics and for careful reviews of the protocol specifica-
   tion.

23.  Authors' Addresses

   Cedric Adjih Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le
   Chesnay Cedex, France Phone: +33 1 3963 5215 Email:
   Cedric.Adjih@inria.fr

   Thomas Heide Clausen Project HIPERCOM INRIA Rocquencourt BP 105 78153
   Le Chesnay Cedex, France Phone: +33 1 3963 5133 Email:
   Thomas.Clausen@inria.fr
   Philippe Jacquet Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le
   Chesnay Cedex, France Phone: +33 1 3963 5263 Email:
   Philippe.Jacquet@inria.fr

   Anis Laouiti Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le
   Chesnay Cedex, France Phone: +33 1 3963 508832 Email:
   Anis.Laouiti@inria.fr

   Pascale Minet Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le
   Chesnay Cedex, France Phone: +33 1 3963 508832 Email: Pas-
   cale.Minet@inria.fr

   Paul Muhlethaler Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le
   Chesnay Cedex, France Phone: +33 1 3963 5278 Email: Paul.Muh-
   lethaler@inria.fr

   Amir Qayyum Avaz Networks 5-A Constitution Center for Advanced Research in Engineering Pvt.  Ltd.
   19, Ataturk Avenue Islamabad, Pakistan Phone: +92-51-2826160 +92-51-2874115 Email: qayyum@avaznet.com
   amir@carepvtltd.com

   Laurent Viennot Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le
   Chesnay Cedex, France Phone: +33 1 3963 5225 Email: Laurent.Vien-
   not@inria.fr

19.

24.  References

1.  P.  Jacquet, P.  Minet, P.  Muhlethaler, N.  Rivierre.  Increasing relia-
     bility
     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 effi-
     cient technique for flooding in mobile wireless networks.  35th
     Annual Hawaii International Conference on System Sciences
     (HICSS'2001).

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

4.  Philippe Jacquet and Laurent Viennot, Overhead in Mobile Ad-hoc Net-
     work Protocols, INRIA research report RR-3965, 2000

5.  S.  Bradner.  Key words for use in RFCs to Indicate Requirement Lev-
     els.  Request for Comments (Best Current Practice) 2119, Internet
     Engineering Task Force, March 1997.

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

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

8.  T.  Narten and H.  Alvestrand.  Guidelines for Writing an IANA Con-
     siderations Section in RFCs.  Request for Comments (Best Current
     Practice) 2434, Internet Engineering Task Force, October 1998.

   Reference [5] and [7] are normative; all others are informative.