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

                 Optimized Link State Routing Protocol

                      draft-ietf-manet-olsr-07.txt

                      draft-ietf-manet-olsr-08.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 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 the OLSR protocol 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 . . . . . . . . . . . . . . . . . . . . . . . .   4   6
     1.1. Changes  . . . . . . . . . . . . . . . . . . . . . . . . .   5   7
     1.2. OLSR Terminology . . . . . . . . . . . . . . . . . . . . .   6   7
     1.3. Applicability Section  . . . . . . . . . . . . . . . . . .   8 . . . .   9
     1.4. Protocol Overview  . . . . . . . . . . . . . . . . . . . .   8   9
     1.5. Multipoint Relays  . . . . . . . . . . . . . . . . . . . .   9  10

     2. Protocol Functioning . . . . . . . . . . . . . . . . . . . .  10  11
     2.1. Packet Format and Forwarding . . Core Functioning . . . . . . . . . . . . .  10
     2.1.1. Protocol and Port Number . . . . . . . .  12
     2.2. Auxiliary Functioning  . . . . . . . .  11
     2.1.2. Multiple Interfaces and Main Address . . . . . . . . . .  11
     2.1.3.  12

     3. Packet Format and Forwarding . . . . . . . . . . . . . . . .  13
     3.1. Protocol and Port Number . . . . .  12
     2.1.3.1. Packet Header  . . . . . . . . . . . . .  14
     3.2. Main Address . . . . . . .  12
     2.1.3.2. Message Header . . . . . . . . . . . . . . . .  14
     3.3. Packet Format  . . . .  13
     2.1.4. Packet Processing and Message Flooding . . . . . . . . .  14
     2.1.5. Message Emission and Jitter . . . . . . . . .  14
     3.3.1. Packet Header  . . . . .  16

     2.2. Neighbor Sensing . . . . . . . . . . . . . . . .  15
     3.3.2. Message Header . . . . .  17
     2.2.1. HELLO Message Format . . . . . . . . . . . . . . . .  15
     3.4. Packet Processing and Message Flooding . .  18
     2.2.2. Neighbor Sensing Information Base . . . . . . . .  17
     3.4.1. Default Forwarding Algorithm . . .  21
     2.2.2.1. Neighbor Set . . . . . . . . . . .  18
     3.4.2. Considerations on Processing and Forwarding  . . . . . .  19
     3.5. Message Emission and Jitter  . . . .  21
     2.2.2.2. 2-hop Neighbor Set . . . . . . . . . . .  20

     4. Link Sensing and Neighbor Detection  . . . . . . .  21
     2.2.2.3. MPR Set . . . . .  21
     4.1. Local Link Information Base  . . . . . . . . . . . . . . .  21
     4.1.1. Link Set . . .  22
     2.2.2.4. MPR Selector Set . . . . . . . . . . . . . . . . . . .  22
     2.2.3. HELLO Message Generation . .  21
     4.1.2. Neighbor Set . . . . . . . . . . . . . .  22
     2.2.4. HELLO Message Processing . . . . . . . .  22
     4.1.3. 2-hop Neighbor Set . . . . . . . .  23
     2.2.5. Multipoint Relay Selection . . . . . . . . . . .  22
     4.1.4. MPR Set  . . . .  27
     2.2.6. Neighborhood and 2-hop Neighborhood Changes . . . . . .  30
     2.2.7. Advanced Neighbor Sensing Functioning . . . . . . . . .  30
     2.2.7.1. Link Hysteresis . . . . .  22
     4.1.5. MPR Selector Set . . . . . . . . . . . . . .  32
     2.2.7.2. Optional Link layer notification . . . . . .  22
     4.2. HELLO Message Format . . . . .  33

     2.3. Topology Discovery . . . . . . . . . . . . . .  23
     4.2.1. Link Code as Link Type and Neighbor Type . . . . . .  34
     2.3.1. TC Message Format . .  25
     4.3. HELLO Message Generation . . . . . . . . . . . . . . . . .  34
     2.3.2. Topology Information Base  26
     4.4. Populating the Link Set  . . . . . . . . . . . . . . .  35
     2.3.3. Advertized Neighbor Set . .  28
     4.4.1. HELLO Message Processing . . . . . . . . . . . . . .  35
     2.3.4. TC Message Generation . .  29
     4.5. Populating the Neighbor Set  . . . . . . . . . . . . . . .  36
     2.3.5. TC  30
     4.5.1. HELLO Message Processing . . . . . . . . . . . . . . . . .  37
     2.3.6. Multiple Interface Association .  32
     4.6. Populating the 2-hop Neighbor Set  . . . . . . . . . . . .  39
     2.3.6.1. Multiple Interface Association Information Base  32
     4.6.1. Hello Message Processing . . .  39
     2.3.6.2. MID Message Format . . . . . . . . . . . . .  32
     4.6.2. Populating the MPR set . . . . .  39
     2.3.6.3. MID Message Generation . . . . . . . . . . . .  34
     4.6.3. MPR Computation  . . . .  40
     2.3.6.4. MID Message Processing . . . . . . . . . . . . . . . .  40
     2.3.7. Associated Networks and Hosts  34
     4.7. Populating the MPR Selector Set  . . . . . . . . . . . . .  42
     2.3.7.1. HNA  35
     4.7.1. Hello Message Format Processing . . . . . . . . . . . . . . . .  35
     4.8. Neighborhood and 2-hop Neighborhood Changes  . .  42
     2.3.7.2. Host and Network Association Information Base . . . .  43
     2.3.7.3. HNA Message Generation .  36

     5. Topology Discovery . . . . . . . . . . . . . . . .  43
     2.3.7.4. HNA Message Processing . . . . .  37
     5.1. TC Message Format  . . . . . . . . . . .  43
     2.3.8. Routing Table Calculation . . . . . . . . .  37
     5.2. Topology Information Base  . . . . . .  45
     2.3.9. Advanced Topology Discovery Functioning . . . . . . . .  48
     2.3.9.1. Reaction to Link Failure with a MPR Selector . .  38
     5.3. Advertised Neighbor Set  . . . .  48
     2.3.9.2. Advanced Fast Re-routing Mechanism . . . . . . . . . .  48
     2.3.9.2.1. FRR . . .  39
     5.4. TC Message Format Generation  . . . . . . . . . . . . . . . . .  49
     2.3.9.2.2. FRR .  39
     5.5. TC Message Generation Forwarding.   . . . . . . . . . . . . . . .  50
     2.3.9.2.3. FRR . .  39
     5.6. TC Message Processing  . . . . . . . . . . . . . . .  50

     3. . . .  40
     5.7. Routing Table Calculation  . . . . . . . . . . . . . . . .  41

     6. Node Configuration . . . . . . . . . . . . . . . . . . . . .  51
     3.1.  43
     6.1. Address Assignment . . . . . . . . . . . . . . . . . . . .  51
     3.2.  43
     6.2. Routing Configuration  . . . . . . . . . . . . . . . . . .  51
     3.3.  43
     6.3. Data Packet Forwarding . . . . . . . . . . . . . . . . . .  51

     4. IPv6 Considerations  44

     7. Multiple OLSR Interfaces . . . . . . . . . . . . . . . . . .  44
     7.1. Terminology  . .  51
     5. Security Considerations . . . . . . . . . . . . . . . . . .  52
     5.1. Confidentiality . . .  44
     7.2. Multiple Interface Functioning . . . . . . . . . . . . . .  45
     7.3. Multiple Interface Declaration . . . .  52
     5.2. Integrity . . . . . . . . . .  47
     7.3.1. Multiple Interface Association Information Base  . . . .  47
     7.3.2. MID Message Format . . . . . . . . . .  52
     6. Proposed Values for the Constants . . . . . . . . .  47
     7.3.3. MID Message Generation . . . .  53
     7. Sequence Numbers . . . . . . . . . . . . .  48
     7.3.4. MID Message Forwarding . . . . . . . . .  54
     8. Acknowledgments . . . . . . . .  48
     7.3.5. MID Message Processing . . . . . . . . . . . . . .  55
     9. Authors' . . .  48
     7.4. Main Addresses vs. Interface Addresses . . . . . . . . . .  49
     7.5. Populating the Neighbor Set  . . . . . . . . . . .  55

1.  Introduction

   The Optimized 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 with other nodes of . . . .  50
     7.6. Populating the MPR Set . . . . . . . . . . . . . . . . . .  50
     7.6.1. MPR Computation  . . . . . . . . . . . . . . . . . . . .  51
     7.7. Routing Table Calculation  . . . . . . . . . . . . . . . .  51
     7.8. Changes to the "Default Forwarding Algorithm"  . . . . . .  52

     8. Non OLSR Interfaces  . . . . . . . . . . . . . . . . . . . .  55
     8.1. HNA Message Format . . . . . . . . . . . . . . . . . . . .  55
     8.2. Host and Network Association Information Base  . . . . . .  56
     8.3. HNA Message Generation . . . . . . . . . . . . . . . . . .  57
     8.4. HNA Message Forwarding . . . . . . . . . . . . . . . . . .  57
     8.5. HNA Message Processing . . . . . . . . . . . . . . . . . .  57
     8.6. Routing Table Calculation  . . . . . . . . . . . . . . . .  58

     9. Link Layer Notification  . . . . . . . . . . . . . . . . . .  58

     10. Link Hysteresis . . . . . . . . . . . . . . . . . . . . . .  59
     10.1. Local Link Set  . . . . . . . . . . . . . . . . . . . . .  59
     10.2. Hello Message Generation  . . . . . . . . . . . . . . . .  60
     10.3. Hysteresis Strategy . . . . . . . . . . . . . . . . . . .  61

     11. Distributing Redundant Topology Information . . . . . . . .  62
     11.1. TC_REDUNDANCY Parameter . . . . . . . . . . . . . . . . .  62

     12. MPR Redundancy  . . . . . . . . . . . . . . . . . . . . . .  63
     12.1. MPR_COVERAGE Parameter  . . . . . . . . . . . . . . . . .  63
     12.2. MPR Computation . . . . . . . . . . . . . . . . . . . . .  64

     13. IPv6 Considerations . . . . . . . . . . . . . . . . . . . .  65
     14. Security Considerations . . . . . . . . . . . . . . . . . .  65
     14.1. Confidentiality . . . . . . . . . . . . . . . . . . . . .  65
     14.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . .  65
     14.3. Interaction with External Routing Domains . . . . . . . .  66

     15. Proposed Values for Constants . . . . . . . . . . . . . . .  67
     15.1. Setting emission interval and holding times . . . . . . .  67
     15.2. Emission Interval . . . . . . . . . . . . . . . . . . . .  68
     15.3. Holding time  . . . . . . . . . . . . . . . . . . . . . .  68
     15.4. Message Types . . . . . . . . . . . . . . . . . . . . . .  69
     15.5. Link Types  . . . . . . . . . . . . . . . . . . . . . . .  69
     15.6. Neighbor Types  . . . . . . . . . . . . . . . . . . . . .  69
     15.7. Link Hysteresis . . . . . . . . . . . . . . . . . . . . .  69
     15.8. Willingness . . . . . . . . . . . . . . . . . . . . . . .  70
     15.9. Misc. Constants . . . . . . . . . . . . . . . . . . . . .  70

     16. Sequence Numbers  . . . . . . . . . . . . . . . . . . . . .  71

     17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . .  71

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

     19. References  . . . . . . . . . . . . . . . . . . . . . . . .  72

1.  Introduction

   The Optimized 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 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 is said to have a link to
          another node when one of its interface has a link to one of
          the interfaces of the 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 of any node X is the set of nodes
          which have at least one symmetric link to X.

     symmetric 2-hop neighborhood

          The symmetric 2-hop neighborhood of X is the set of nodes,
          excluding X itself, which  have a symmetric link to the sym-
          metric neighborhood of X.

     symmetric strict 2-hop neighborhood

          The symmetric 2-hop neighborhood of X is the set of nodes,
          excluding X itself and its neighbor, which  have a symmetric
          link to the symmetric neighborhood of X.

1.3.  Applicability

   OLSR is a proactive routing protocol for mobile ad-hoc networks
   (MANETs). It is well suited to large and dense mobile networks, as
   the optimization achieved using the MPRs works well in this context.
   The larger and more dense a network, the more optimization can be
   achieved as compared to the classic link state algorithm. OLSR uses
   hop-by-hop routing, i.e. each node uses its local information to
   route packets.

   OLSR is well suited for networks, where the traffic is random and
   sporadic between "several" nodes rather than being almost exclusively
   between a small specific set of nodes. As a proactive protocol, OLSR
   is also suitable for scenarios where the communicating pairs change
   over time: no additional control traffic is generated in this situa-
   tion since routes are maintained for all known destinations at all
   times.

1.4.  Protocol Overview

   OLSR is a proactive routing protocol for mobile ad hoc networks. The
   protocol inherits the stability of a link state algorithm and has the
   advantage 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 the overhead from flooding of control traffic by using
   only selected nodes, called MPRs, to retransmit control messages.
   This technique significantly reduces the number of retransmissions
   required to flood a message to all nodes in the network. Secondly,
   OLSR requires only partial link state to be flooded in order to pro-
   vide optimal routes. The minimal set of link state information
   required is, that all nodes, selected as MPRs, MUST declare the links
   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, as OLSR continuously maintains routes to all destina-
   tions in 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 the [source, destination] pairs are chang-
   ing over time. The protocol is particularly suited for large and
   dense networks, as the optimization done using MPRs works well 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.

   OLSR is designed to work 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 node sends control
   messages periodically, and can therefore sustain an occasional loss
   of some such messages. Such losses occur frequently in radio networks
   due to collisions or other transmission problems.

   Also, OLSR does not require sequenced delivery of messages. Each con-
   trol message contains a sequence number which is incremented for each
   message. Thus the recipient of a control message can, if required,
   easily identify which information is newer - 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 protocol without breaking backwards
   compatibility with earlier versions.

   OLSR does not require any changes to the format of IP packets. Thus
   any existing IP stack can be used as is: the protocol only interacts
   with routing table management.

1.5.  Multipoint Relays

   The idea of multipoint relays is to minimize the overhead of flooding
   messages in the network regularly. by reducing duplicate retransmissions in the
   same region. Each node in the network selects a set of nodes in its
   symmetric neighborhood which may retransmit its messages. This set of
   selected neighbor nodes as
   "multipoint relays" (MPR). In OLSR, only nodes, is called the "Multipoint Relay" (MPR) set of
   that node. The neighbors of node N which are *NOT* in its MPR set,
   receive and process broadcast messages but do not retransmit broad-
   cast messages received from node N.

   Each node selects its MPR set from among its one hop symmetric
   neighbors. This set is selected as such
   MPRs, that it covers (in terms of
   radio range) all nodes that are responsible for forwarding control traffic, intended for
   diffusion into two hops away. The MPR set of N,
   denoted as MPR(N), is then an arbitrary subset of the entire network. I.e. MPRs provide symmetric
   neighborhood 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 smaller an efficient
   mechanism for flooding MPR set, the less control traffic by reducing
   overhead results from the number routing protocol. [2] gives an analysis and
   example of
   transmissions required.

   Nodes, MPR selection algorithms.

   Each node maintains information about the set of neighbors that have
   selected it as MPRs, also have MPR. This set is called the "Multipoint Relay Selector
   set" (MPR selector set) of a special responsibility when
   declaring link state node. A node obtains this information
   from periodic HELLO messages received from the neighbors.

   A broadcast message, intended to be diffused in the network. Indeed, whole network,
   coming from any of 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 selectors of node N is assumed to be utilized e.g. for redundancy.

   These nodes which have been selected as
   retransmitted by node N. This set can change over time (i.e. when a multipoint relay
   node selects another MPR-set) and is indicated by some
   neighbor the selector nodes announce this information periodically
   in their con-
   trol HELLO messages. Thereby, a node announces to

2.  Protocol Functioning

   This section outlines the network, that it has
   reachability to overall the nodes protocol functioning.

   OLSR is modularized into a "core" of functionality, which have selected it as MPR. In route
   calculation, is always
   required for the MPRs are used protocol to form the route from 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 may
   be applicable in specific scenarios. E.g. in case a given node is providing
   connectivity between the MANET and another routing domain.

   All auxiliary functions are compatible, to the extend where any destination in
   (sub)set of auxiliary functions may be implemented with the network. core.
   Furthermore, the protocol uses the
   MPRs to facilitate efficient flooding of control messages in the net-
   work.

   A node selects MPRs from among its one hop neighbors with "symmetri-
   cal", allows heterogeneous nodes, i.e. bi-directional, linkages. Therefore, selecting nodes
   which implement different subsets of the route
   through MPRs automatically avoids auxiliary functions, to
   coexist in the problems associated with data
   packet transfer over uni-directional links (such as network.

   The purpose of dividing the problem functioning of
   not getting link-layer acknowledgments for data packets at each hop) OLSR into a core function-
   ality and a set of auxiliary functions is developed to work independently from other protocols. Like-
   wise, provide a simple and
   easy-to-comprehend protocol, and to provide a way of only adding com-
   plexity where specific additional functionality is required.

2.1.  Core Functioning

   The core functionality of OLSR makes no assumptions about specifies the underlying link-layer. behavior of a node,
   equipped with OLSR inherits interfaces participating in the concept MANET and running
   OLSR as routing protocol. This includes an universal specification of forwarding
   OLSR protocol messages and relaying from HIPERLAN (a
   MAC layer protocol) which is standardized by ETSI [3]. their transmission through the network, as
   well as link sensing, topology diffusion and route calculation.

   The protocol
   is developed in "Link Sensing and Neighbor Detection" mechanism provides nodes
   with information about their neighbors and offers an optimized mecha-
   nism for flooding messages through the IPANEMA project (part concept of MPRs. It completely
   relies on the Euclid program) and
   in the PRIMA project (part exchange of HELLO messages.

   The "Topology Discovery" mechanism relies on the RNRT program).

1.1.  Changes

   Major changes "Packet Forwarding"
   and "Link Sensing and Neighbor Discovery" mechanisms. A node uses
   neighbor and MPR information from version 06 to version 07

     -    Introduction of relay willingness in hellos

     -    Introduction of redundant link set in TC messages

     -    Introduction of packet sequence number the "Link Sensing" mechanism in order
   diffusing local topology information to clarify
          link management

   Major changes the larger network. Topology
   information is diffused through the "Packet Forwarding" mechanism,
   and relies on TC messages. Resulting from version 05 to version 06

     -    Clarification the "Topology Discovery"
   mechanism is information which allows routing table calculation.

   The key notion for these mechanisms is the MPR relationship.

   The following table specifies the component of the usage core functionality
   of link layer notification OLSR, as well as their relations to this document.

             Feature                      |  Section
            ------------------------------+--------------
             Packet format and fast
          re-routing

     -    Clarification of MPR selection forwarding |     3
             Link sensing                 |     4
             Topology discovery           |     5
             Node configuration           |     6
             Multiple OLSR interfaces     |     7

   Multiple interface compliance is needed when:

     -    Clarification of    a node has multiple interfaces

   Major changes from version 04 to version 05 which participate in the OLSR
          domain,

     -    Introduction of support for    a node exists in a domain where other nodes with multiple OLSR
          interfaces

     -    Introduction are present.

2.2.  Auxiliary Functioning

   In addition to the core functioning of support for associated hosts and networks.

     -    Introduction OLSR, there are situations
   where additional functionality is needed. This includes situations
   where a node has multiple interfaces, some of support for advanced neighbor sensing through
          hysteresis.

     -    Modularity between neighbor sensing and topology discovery
          emphasized.

   Major changes from version 03 to version 04

     -    Finalized which participate in
   another routing domain, where the generic packet/message format programming interface to include fea-
          tures for scope-limited (diameter-bound) flooding the net-
   working hardware provides additional information in form of messages link-
   layer notifications and where it is desired to handle duplicate messages.

     -    Editorial changes towards language consistency.

   Major changes from version 02 to version 03

     -    Introduction of assigned port number for use with OLSR.

     -    The packet format now uses "message length" rather than an
          offset provide redundant
   topological information to the next message.

     -    Optional section describing how link-layer notifications can
          be utilized included.

   Major changes from version 01 to version 02

     -    Introduction network on expense of protocol over-
   head.

   The following table specifies auxiliary functions and their relation
   to this document.

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

3.  Packet Format and Forwarding

   OLSR communicates using a unified packet format for encapsulation of all messages being exchanged between nodes. This also serves data related
   to the protocol. The purpose of this is to facilitate extensions in future versions extensibility
   of the protocol
          (i.e. introduction of new protocol messages) without breaking backwards compatibility.

     -    Removal of "Power Conservation" from Also, this draft. Power Conser-
          vation may be considered as
   provides an extension easy way of piggybacking different "types" of information
   into a single transmission, and thus for a given implementation to
   optimize towards utilizing the basic routing
          capabilities.

1.2.  OLSR Terminology

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" maximal frame-size, provided by the
   network. These packets are embedded in this
   document UDP datagrams for transmission
   over the network. The present draft is presented with IPv4 addresses.
   Considerations regarding IPv6 are to be interpreted as described given in RFC2119 [5]. section 13.

   Each packet encapsulates one or more messages. The OLSR
   protocol uses the following terminology:

     multipoint relay (MPR)

          A node messages share a
   common header format, which is selected by its one-hop neighbor, node X, enables nodes to
          "re-transmit" all the broadcast messages that it receives from
          X, provided that the same message is not already received, correctly accept and
          the time to live field (if
   applicable) retransmit messages of an unknown type.

   Messages can be flooded onto 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 entire network, or flooding can be called
   limited to nodes within a multipoint relay selector diameter (in terms of node X.

     node

          A MANET router which implements this Optimized Link State
          Routing protocol.

     interface

          A network device participating in number of hops) from
   the MANET (usually originator of the message. Thus transmitting a message to the
   neighborhood of a wire-
          less device). A node may have several interfaces, each inter-
          face assigned an unique IP address.

     link

          A link is just a pair special case of interfaces (from two different nodes) sus-
          ceptible to hear one another (i.e. one may flooding. When
   flooding any control message, duplicate retransmissions will be able to receive
          traffic from the other).  A elim-
   inated locally (i.e. each node is said to have maintains a link duplicate table to
          another prevent
   transmitting the same message twice) and minimized in the entire net-
   work through the usage of MPRs as described in later sections.

   Furthermore, a node when one can examine the header of its interface has a link message to one of obtain
   information on the interfaces distance (in terms of the other node.

     neighbor interface

          An interface I is a neighbor interface number of an interface J if J
          can hear I (i.e. it is possible to send traffic from I hops) to J).

     sender interface

          The sender interface the orig-
   inator of a control message is the neighbor
          interface over which message. This feature may be useful in situations
   where, e.g., the message has been transmitted.

     receiver interface

          The receiver interface of time information from a received control message is the (local)
          interface, over which messages
   stored in a control message node depends on the distance to the originator.

3.1.  Protocol and Port Number

   Packets in OLSR are communicated using UDP. Port 698 has been received.

     neighbor node

          A node X is
   assigned by IANA for exclusive usage by the OLSR protocol.

3.2.  Main Address

   For a neighbor node of node Y if node Y can hear node
          X (i.e. with one interface, the main address of X interfaces is a neighbor interface of some
          interface of Y).

     2-hop interface

          An interface heard by a neighbor.

     symmetric link

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

     symmetric neighborhood
          The symmetric neighborhood of any node X is the node, as defined
   in "OLSR Terminology", MUST be set of nodes
          which have at least one symmetric link to X.

     symmetric 2-hop neighborhood the address of that interface.

3.3.  Packet Format

   The symmetric 2-hop neighborhood basic layout of X any packet in OLSR is the set 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    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      :                            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 (in bytes) of nodes
          which don't have a symmetric link to X but have a symmetric
          link to the symmetric neighborhood of X.

     main address packet

     Packet Sequence Number

          The main address of a node, which will Packet Sequence Number (PSN) MUST be used in OLSR control
          traffic as the "originator address" of all messages emitted incremented by
          this node. It is the address of one of its interfaces.

1.3.  Applicability Section
          each time a new OLSR packet is a proactive routing protocol for mobile ad-hoc networks
   (MANETs). It transmitted. "Wrap-around" is well suited to large and dense mobile networks,
          handled as
   the optimization achieved using the MPRs works well described in this context. section 16.

   The larger and more dense a network, the more optimization can be
   achieved as compared to the classic link state algorithm. OLSR uses
   hop-by-hop routing, i.e. each node uses its local sender information to
   route packets.

   OLSR is well suited for networks, where the traffic is random and
   sporadic between "several" nodes rather than being almost exclusively
   between a small specific set of nodes. The performance of packet is obtainable from the proto-
   col, compared IP header.
   Any received packet whose "Packet Length" is less or equal to a reactive protocol, 12
   (i.e. the packet contains no messages), MUST be silently dropped.

3.3.2.  Message Header

     Message Type

          This field indicates which type of message is even better if these
   [source, destination] pairs change over time [4]. Such changes may
   initiate substantial traffic (query flooding) to be found in case
          the "MESSAGE" part. Message types in the range 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 reactive
   protocol, but no additional traffic in OLSR, as node
          must consider the routes are main-
   tained for each known destination all information contained in the time.

1.4.  Protocol Overview

   OLSR is a proactive routing protocol message for mobile ad hoc networks.
          valid. The
   protocol inherits the stability validity time is represented by its mantissa (four
          highest bits of a link state algorithm Vtime field) and has the
   advantage of having routes immediately available when needed due to by its proactive nature. OLSR exponent (four lowest
          bits of Vtime field).  In other words:

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

          where a is an optimization over the classical link
   state protocol, tailored for mobile ad hoc networks.

   OLSR minimizes integer represented by the overhead from flooding four highest bits of control traffic
          Vtime field and b the integer represented by using
   only selected nodes, called MPRs, to retransmit control messages.
   This technique significantly reduces the number four lowest
          bits of retransmissions
   required to flood a message to all nodes Vtime field. The proposed value of the scaling factor
          C is specified in section 15.

     Message Size

          This field gives the network. Secondly,
   OLSR requires only partial link state to be flooded size of this message, counted in order to pro-
   vide optimal routes. The minimal set bytes
          and measured from the beginning of link state information
   required is, that all nodes, selected as MPRs, declare the links to
   their MPR selectors. Additional topological information, "Message Type" field
          and until the beginning of the next "Message Type" field (or -
          if present,
   may be utilized e.g. for redundancy purposes.

   OLSR MAY optimize there are no following messages - until the end of the
          packet).

     Originator Address

          This field contains the main address of the node, which has
          originally generated this message. This field SHOULD NOT be
          confused with the reactivity to topological changes by reducing source address from the maximum IP header, which is
          changed each time interval for periodic control message transmission.
   Furthermore, as OLSR continuously maintains routes to all destina-
   tions in the network, the protocol is beneficial for traffic patterns
   where a large subset of nodes are communicating with another large
   subset address of nodes, and where the [source, destination] pairs are chang-
   ing over time. The protocol intermediate interface
          which is particularly suited for large and
   dense networks, as the optimization done using MPRs works well in re-transmitting this context. message. The larger and more dense Originator Address
          field MUST *NEVER* be changed in retransmissions.

     Time To Live

          This field contains the maximum number of hops a network, message will
          be transmitted. Before a message is retransmitted, the more optimiza-
   tion can Time To
          Live MUST be achieved as compared decremented by 1. When a node receives a message
          with a Time To Live equal to 0 or 1, the classic link state algorithm.

   OLSR is designed to work in message MUST NOT be
          retransmitted under any circumstances. Normally, a completely distributed manner and does
   thus node would
          not depend on any central entity. The protocol does NOT REQUIRE
   reliable transmission receive a message with a TTL of control messages: each node sends control
   messages periodically, and can therefore sustain an occasional loss zero.

          Thus, by setting this field, the originator of some such messages. Such losses occur frequently in radio networks
   due to collisions or other transmission problems.

   Also, OLSR does not require sequenced delivery a message can
          limit the flooding radius.

     Hop Count

          This field contains the number of messages. Each con-
   trol hops a message contains has attained.
          Before a sequence number which message is retransmitted, the Hop Count MUST be
          incremented for by 1.

          Initially, this is set to '0' by the originator of the mes-
          sage.

     Message Sequence Number

          While generating a message, the "originator" node will assign
          a unique identification number to each message. Thus This number is
          inserted into the recipient Sequence Number field of a control message can, if required,
   easily identify which information the message. The
          sequence number is newer - even if messages have
   been re-ordered while in transmission.

   Furthermore, OLSR provides support increased by 1 (one) for protocol extensions such as
   sleep mode operation, multicast-routing etc. Such extensions may be
   introduced each message orig-
          inating from the node.  "Wrap-around" is handled as additions described
          in section 16.  Message sequence numbers are used to the protocol without breaking backwards
   compatibility with earlier versions.

   OLSR does
          ensure that a given message is not require retransmitted more than
          once by any changes to node.

3.4.  Packet Processing and Message Flooding

   Upon receiving a basic packet, a node examines each of the format "message
   headers". Based on the value of IP packets. Thus
   any existing IP stack the "Message Type" field, the node
   can be used as is: determine the protocol only interacts
   with routing table management.

1.5.  Multipoint Relays

   The idea fate of the message. A node 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 Table. In this table, the node records information about
   the most recently received messages where duplicate processing of multipoint relays a
   message is to minimize be avoided. For such a message, a node records a
   "Duplicate Tuple" (D_addr, D_seq_num, D_time), where D_addr is the overhead
   originator address of flooding
   messages in the network by reducing duplicate retransmissions in the
   same region. Each node in message, D_seq_num is the network selects a set message sequence
   number of nodes in its
   symmetric neighborhood the message and D_time specifies the time at which may retransmit its messages. This set of
   selected neighbor nodes is called a tuple
   expires and *MUST* be removed.

   In a node, the "Multipoint Relay" (MPR) set of
   that node. The neighbors Duplicate Tuples are denoted the "Duplicate
   set".

   In this section, the term "Originator Address" will be used for the
   main address of the node N which are *NOT* sent the message. The term "Sender
   Interface Address" will be used for the sender address (given in its MPR set,
   receive and process broadcast messages but do not retransmit broad-
   cast messages received from node N.

   Each node selects its MPR set among its one hop symmetric neighbors.
   This set is selected such that it covers (in terms the
   IP header of radio range)
   all nodes that are two hops away. The MPR set the packet containing the message) of N, denoted as
   MPR(N), the 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 is less than or equal to
          '0' (zero), the message MUST silently be dropped.

     2    If the packet contains no messages (i.e. the Packet Length is then an arbitrary subset of
          less than or equal to the symmetric neighborhood size of
   N which satisfies the following packet header), the
          packet MUST silently be discarded.

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

     3    Processing condition: every node

          3.1  if there exists a tuple in the symmet-
   ric 2-hop neighborhood duplicate set, where:

                             D_addr == Originator Address, AND

                             D_seq_num == Message Sequence Number

               then the message has already been completely processed
               and MUST not be processed again.

          3.2  Otherwise, if the node implements the Message Type of N must have a symmetric link towards
   MPR(N). The smaller the MPR set is,
               message, the more optimal is message MUST be processed according to the routing
   protocol. [2] gives an analysis
               specifications for the message type.

     4    Forwarding condition:

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

                             D_addr == Originator Address, AND

                             D_seq_num == Message Sequence Number

               then the message has already been considered for forward-
               ing and example SHOULD NOT be retransmitted again.

          4.2  Otherwise:

               4.2.1
                    If the node implements the Message Type of MPR selection algo-
   rithms.

   Each the mes-
                    sage, the message MUST be considered for forwarding
                    according to the specifications for the message
                    type.

               4.2.2
                    Otherwise, if the node maintains information about does not implement the set Mes-
                    sage Type of neighbors that have
   selected it as MPR. This set the message, the message SHOULD be pro-
                    cessed according to the default forwarding algorithm
                    described below.

3.4.1.  Default Forwarding Algorithm

   The default forwarding algorithm is called the "Multipoint Relay Selector
   set" (MPR selector set) of a node. A node obtains this information
   from periodic HELLO messages received from following:

     1    If the neighbors.

   A broadcast message, intended sender interface address of the message is not detected
          to be diffused in the whole network,
   coming from any symmetric neighborhood of the MPR selectors node, the message
          MUST silently be dropped.

     2    If the sender interface address of node N the message is assumed detected to
          be
   retransmitted by node N. This set can change over time (i.e. when a
   node selects another MPR-set) and is indicated by the selector nodes in their HELLO messages.

2.  Protocol Functioning

   This section describes the details of the protocol functioning. This
   includes descriptions of the format and contents symmetric neighborhood of the packets being
   exchanged by routers and node, an entry in the algorithms (e.g. for packet handling and
   routing table calculation).

   The "Packet Forwarding" and "Neighbor Sensing" mechanisms may be seen
   as a transfer layer for
          duplicate set is recorded with:

               D_addr = originator address

               D_seq_num = Message Sequence Number

               D_time = current time + D_HOLD_TIME.

     3    If the routing protocol. This provides nodes
   with information about their neighbors and offers sender interface address is an optimized mecha-
   nism for flooding messages through the concept interface address of MPRs. It completely
   relies on the exchange a
          MPR selector of HELLO messages.

   The "Topology Discovery" mechanism relies on the "Packet Forwarding"
   and "Neighbor Sensing" mechanisms. A this node uses neighbor and MPR
   information from if the "Neighbor Sensing" mechanism in diffusing local
   topology information time to live of the larger network. Topology information mes-
          sage is
   diffused through greater than '1', the "Packet Forwarding" mechanism, and relies on TC,
   MID and HNA messages. Resulting from message MUST be forwarded
          according to the following:

          3.1  The TTL of the message is reduced by one.

          3.2  The hop-count of the "Topology Discovery" mecha-
   nism message is information which allows routing table calculation. increased by one

          3.3  The key notion for these mechanisms message is broadcasted on all interfaces running
               OLSR. Notice: The remaining fields of the MPR relationship.

2.1.  Packet Format message header
               SHOULD be left unmodified.

3.4.2.  Considerations on Processing and Forwarding

   OLSR communicates using a unified packet format for all data related

   It should be noted that processing and forwarding messages are two
   different actions, conditioned by different rules. Processing relates
   to using the protocol. The purpose content of this the messages, while forwarding is related to facilitate extensibility
   retransmitting the same message for other nodes of the protocol without breaking backwards compatibility. Also, network.

   Notice that this
   provides an easy way of piggybacking different "types" of information
   into specification includes a single transmission, and thus description for a given implementation to
   optimize towards utilizing both the maximal frame-size, provided
   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
   network. These packets are embedded correct message header in UDP datagrams for transmission
   over the network. The present draft
   forwarded, known, message) is presented with IPv4 addresses.
   Considerations regarding IPv6 are given in section 4.

   Each packet encapsulates one or more messages. The messages share the responsibility of the algorithm
   specifying how the message is to be handled and, if necessary,
   retransmitted. This enables, e.g., a
   common header format, which enables nodes message type to correctly accept and (if
   applicable) retransmit messages of an unknown type.

   Messages be specified
   such that the message can be flooded onto modified while in transit (e.g. to
   reflect the route the message has taken). Further, it enables that
   the entire network, or flooding optimization through the MPRs can be
   limited to nodes within a diameter (in terms of number of hops) from
   the originator bypassed: if for some reason
   classical flooding of the message. Thus transmitting a message to type is required, the
   neighborhood algorithm which
   specifies how such messages should be handled will simply rebroadcast
   the message, regardless of MPRs.

   By defining a node is just a special case set of flooding. When
   flooding any control message, duplicate retransmissions message types, which MUST be recognized by all
   implementations of OLSR, it will be elim-
   inated locally (i.e. each node maintains a duplicate table possible to prevent
   transmitting extend the same protocol
   through introduction of additional message twice) types, while still be able
   to maintain compatibility with older implementations.  The REQUIRED
   message types for the core functionality of OLSR are:

     -    HELLO-messages, performing the task of link sensing, neighbor
          detection and minimized in MPR signaling,

     -    TC-messages, performing the entire net-
   work through task of topology declaration
          (advertisement of link states).

     -    MID-messages, performing the usage task of MPRs as described declaring the presence of
          multiple interfaces on a node.

   Other message types include those specified in later sections.

   Furthermore, 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.  Message Emission and Jitter

   As a node can examine the header basic implementation requirement, synchronization of control
   messages SHOULD be avoided. As a message consequence, periodic OLSR messages
   SHOULD be emitted such that they avoid synchronization.

   Emission of control traffic from neighboring nodes may, for various
   reasons (mainly timer interactions with packet processing), become
   synchronized such that several neighbor nodes attempt to obtain
   information transmit
   control traffic simultaneously. Depending on the distance (in terms of number nature of hops) to the orig-
   inator under-
   lying link-layer, this may or may not lead to collisions and hence
   message loss - possibly loss of several subsequent messages of the message. This feature may be useful in situations
   where, e.g.,
   same type.

   To avoid such synchronizations, the time information from a received following simple strategy for
   emitting control messages
   stored in a is proposed. A node depends on the distance MAY add an amount of
   jitter to the originator.

2.1.1.  Protocol and Port Number

   Packets in OLSR interval at which messages are communicated using UDP. Port 698 has been
   assigned by IANA generated. The jitter
   must be a random value for exclusive usage by the OLSR protocol.

2.1.2.  Multiple Interfaces and Main Address

   A node may have several wireless interfaces, each of them having message generated. Thus, for a
   distinct IP address. OLSR supports such nodes with multiple inter-
   faces. For this reason, each node SHOULD choose one of its interface
   addresses as its "main address". It is of no importance which address
   utilizing jitter:

        Actual message interval = MESSAGE_INTERVAL - jitter

   Where jitter is chosen, however a node SHOULD always use the same address as its
   main address. For example, the smallest interface address may be cho-
   sen as the main interface. The main address MUST be used in OLSR con-
   trol traffic as value, randomly selected from the "originator address" of all messages emitted by a
   node.

   A node must transmit interval
   [0,MAXJITTER] and retransmit all control messages on all
   interfaces.  The source address in the IP header must contain MESSAGE_INTERVAL is the IP-
   address value of the interface where 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 transmitted. This
   address will to be denoted forwarded
   by a node, it should be kept in the "sender interface address".

2.1.3.  Packet Format

   The basic layout node during a short period of any packet
   time :

           Keep message period = jitter

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

   Notice that when the node sends a control message, the opportunity to
   piggyback other messages (before their keeping period is as follows (omitting expired) may
   be taken to reduce the 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 |    Reserved   |         Message Size          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Originator Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Time To Live |   Hop Count   |    Message Sequence Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      :                            MESSAGE                            :
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Message Type |    Reserved   |         Message Size          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Originator Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Time To Live |   Hop Count   |    Message Sequence Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      :                            MESSAGE                            :
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
               (etc)

2.1.3.1.  Packet Header

     Packet Length

          The length (in bytes) number of the packet

     Packet Sequence Number
          The Packet Sequence Number (PSN) MUST transmissions.

   It should be incremented noticed that the present draft imposes a minimal rate of
   control message emission. However a node MAY send control messages at each
          any new OLSR packet transmitted.

   The sender information for
   a packet is obtainable from higher rate (e.g. for better reacting to high mobility). Tuning the IP header.

2.1.3.2.  Message Header

     Message Type

          This field indicates which type
   rate of message is control traffic to be found in the "MESSAGE" partition. Message types in actual conditions under which the range pro-
   tocol is to operate is an implementation issue.

4.  Link Sensing and Neighbor Detection

   This section describes how a node discovers its immediate topology,
   known as its "neighborhood". This implies detecting the quality of 0-127
   links to neighbor nodes, as well as discovering which nodes are reserved for messages in this draft
   the neighborhood and in extension
          drafts.

     Reserved

          MUST be set two-hop neighborhood.

   Specifically, link sensing and neighbor detection populates the local
   link information base.

4.1.  Local Link Information Base

   The local link information base stores information about neighbors,
   links to "00000000" neighbors, links to be in compliance with this ver-
          sion of the draft.

     Message Size

          This field gives 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 the size (interface) address of this message, counted in bytes
          and measured from the beginning local node (i.e. one endpoint of
   the "Message Type" field
          and until link), L_neighbor_iface_addr is the beginning (interface) address of the next "Message Type" field (or -
          if there are no following messages - until
   neighbor node (i.e. the end other endpoint of the
          packet).

     Originator Address

          This field contains link), L_SYM_time is
   the main address of time until which the node, link is considered symmetric, L_ASYM_time is
   the time until which the neighbor interface is considered heard, and
   L_time specifies the time at which has
          originally generated this message. This field SHOULD NOT record expires and *MUST* be
          confused with
   removed. When L_SYM_time and L_ASYM_time are expired, the source address from link is
   considered lost.

   This information is used when declaring the IP header, which neighbor interfaces in
   the HELLO messages.

   L_SYM_time is
          changed each time used to decide the address of Link Type declared for the intermediate interface
          which neighbor
   interface. If L_SYM_time is re-transmitting this message. The Originator Address
          field MUST *NEVER* be changed in retransmissions.

     Time To Live

          This field contains not expired, the maximum number of hops a message will link MUST be transmitted. Before a message declared
   symmetric. If L_SYM_time is retransmitted, expired, the Time To
          Live link MUST be decremented by 1. When a node receives a message
          with a Time To Live equal to 0 or 1, declared asym-
   metric. If both L_SYM_time and L_ASYM_time are expired, the message link MUST NOT
   be
          retransmitted under any circumstances. Normally, a node would
          not receive a message with a TTL of zero.

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

     Hop Count

          This field contains the number of hops a message has attained.
          Before declared lost.

   In a message is retransmitted, node, the Hop Count MUST be
          incremented by 1.

          Initially, this is set to '0' by the originator of Link Tuples are denoted the mes-
          sage.

     Message Sequence Number

          While generating a message, the "originator" "Link Set".

4.1.2.  Neighbor Set

   A node will assign records a unique identification number to each message. This number is
          inserted into the Sequence Number field set of the message. The
          sequence number "neighbor tuples" (N_neighbor_main_addr,
   N_status, N_willingness), describing symmetric neighbors.  N_neigh-
   bor_main_addr is increased by 1 (one) for each message orig-
          inating from the main address of a neighbor, N_status specifies
   if the node - "wrap-arounds" are handled as
          described is NOT_SYM or SYM. N_willingness in an integer between 0
   and 7, and specifies a later section. Message sequence numbers are
          used nodes willingness to ensure that carry traffic on behalf
   of other nodes.

4.1.3.  2-hop Neighbor Set

   A node records a given message is not retransmitted more
          than once set of "2-hop tuples" (N_neighbor_main_addr,
   N_2hop_addr, N_time), describing symmetric (and, since MPR links by any node.

2.1.4.  Packet Processing
   definition are also symmetric, thereby also MPR) links between its
   neighbors and Message Flooding

   Upon receiving a basic packet, the protocol parser examines each of symmetric 2-hop neighborhood. N_neighbor_main_addr
   is the "message headers". Based on main address of a neighbor, N_2hop_addr is the value main address of
   a 2-hop neighbor with a symmetric link to N_neighbor_main_addr, and
   N_time specifies the "Message Type"
   field, time at which the parser can determine tuple expires and *MUST* be
   removed.

   This information is gathered from the fate HELLO messages received by a
   node from its neighbor nodes.

   In a node, the set of 2-hop tuples are denoted the message. "2-hop Neighbor
   Set".

4.1.4.  MPR Set

   A node may
   receive the same message several times. Thus, to avoid re-processing maintains a set of some messages neighbors which were already received and processed, each 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 a Duplicate table. In this table, information (obtained from the node records informa-
   tion HELLO messages) about
   the most recently received messages where duplicate pro-
   cessing of a message is to be avoided. For such neighbors which have selected this node as a message, MPR.

   Thus, a node records a "Duplicate Tuple" (D_addr, D_seq_num, D_time), where D_addr an MPR-selector tuple (MS_main_addr, MS_time).
   MS_main_addr is the originator main address of the message, D_seq_num is the message
   sequence number of the message and D_time a node, which has selected this
   node as MPR.  MS_time specifies the time at which a tuple expires and
   *MUST* be removed.

   In a node, the set of Duplicate Tuples are denoted set of MPR-selector tuples are denoted the "MPR Selec-
   tor Set".

4.2.  HELLO Message Format

   A common mechanism is employed for populating the local link informa-
   tion base, namely periodic exchange of HELLO messages. Thus this sec-
   tion describes the general HELLO message mechanism, followed by a
   description of link sensing and topology detection, respectively.

   To accommodate for link sensing and neighbor detection, as well as to
   accommodate for future extensions, an approach similar to the overall
   packet format is taken. Thus 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 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 Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Neighbor Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                             . . .                             :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Link Code   |   Reserved    |       Link Message Size       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Neighbor Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Neighbor Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                                       :
   (etc)

   This is sent as the data-portion of the general packet format
   described in section 3.4, with the "Message Type" set to
   HELLO_MESSAGE, the TTL field set to 1 (one) and Vtime set accordingly
   to the value of NEIGHB_HOLD_TIME, specified in section 15.3.

     Reserved

          This field must be set to "0000000000000" to be in compliance
          with this specification.

     HTime

          This field specifies the HELLO emission interval used by the "Duplicate
   set".

   In
          node on this section, particular interface, i.e. the term "Originator Address" will be used for time before the
   main address
          transmission of the node which sent the message. The term "Sender
   Interface Address" will be next HELLO (this information is used for the sender address (given in the
   IP header
          advanced link sensing).  The HELLO emission interval is repre-
          sented by its mantissa (four highest bits of the packet containing the message) Htime field) and
          by its exponent (four lowest bits of Htime field).  In other
          words:

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

          where a is the interface
   which sent integer represented by the message.

   Thus, upon receiving a basic packet, a node performs four highest bits of
          Htime field and b the following
   tasks for each encapsulated message:

     1    If integer represented by the time to live four lowest
          bits of Htime field. The proposed value of the message scaling factor
          C is less than or equal to
          '0' (zero), the message MUST silently be dropped.

     2    If there exists a tuple specified in section 15.

     Willingness

          This field specifies the duplicate set, where:

                        D_addr == Originator Address, AND

                        D_seq_num == Message Sequence Number

          then the message has already been completely processed willingness of a node to carry and
          forward traffic for other nodes.

          A node with willingness WILL_NEVER (see section 15.8, for
          willingness constants) MUST silently never be ignored.

     3    Otherwise, if the selected as MPR by any
          node. A node implements the Message Type of the mes-
          sage, the message with willingness WILL_ALWAYS MUST always be processed according to the specifi-
          cations for the message type.

     4    Otherwise, if the
          selected as MPR. By default, a node does not implement the Message Type of
          the message the message SHOULD be processed according to advertise a will-
          ingness of WILL_DEFAULT.

     Link Code

          This field specifies informations about the
          following algorithm:

          4.1  If link between the sender
          interface address of the message is not
               detected to be in sender and the symmetric neighborhood following list of neighbor
          interfaces. It also specifies informations about the node, status of
          the message MUST neighbor.

          Link codes, not known by a node, are silently be dropped.

          4.2  If the sender interface address discarded.

     Link Message Size

          The size of the message is
               detected to be link message, counted in bytes and measured
          from the symmetric neighborhood beginning of the node,
               an entry in "Link Code" field and until the duplicate set is recorded with:

                    D_addr = originator address

                    D_seq_num = Message Sequence Number

                    D_time = current time + D_HOLD_TIME.

          4.3  If next
          "Link Code" field (or - if there are no more link types - the sender interface address is an interface
          end of the message).

     Neighbor Address

          An address of a MPR selector of this node neighbor node.

4.2.1.  Link Code as Link Type and if the time to live Neighbor Type

   This document specifies processing only of Link Codes < 16.

   If the message Link Code value is greater than '1', the message less or equal to 15, then it MUST be for-
               warded according to the following:

               4.3.1
                    The TTL of the message is reduced by one.

               4.3.2
                    The hop-count inter-
   preted as holding two different fields, of the message is increased by one

               4.3.3
                    The message is broadcasted on all interfaces
                    (Notice: two bits each:

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

   The remaining fields of the message header
                    SHOULD be left unmodified.)

   Notice: known message types following four "Link Types" are *not* forwarded "blindly" REQUIRED by this
   algorithm. Forwarding (and setting OLSR:

     -    UNSPEC_LINK - indicating that no specific information about
          the correct message header in links is given.

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

     -    SYM_LINK - indicating that the responsibility of links are symmetric with the algorithm
   specifying how
          interface.

     -    LOST_LINK - indicating that the message is to be handled. This enables, e.g., a
   message type to be specified such links have been lost.

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

     -    SYM_NEIGH - indicating that the message can be modified
   while in transit (e.g. to reflect neighbors have at least one
          symmetrical link with this node.

     -    MPR_NEIGH - indicating that the route neighbors have at least one
          symmetrical link AND have been been selected as MPR by the message has taken).
   Further, it enables
          sender.

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

   Note that the MPRs can implementation should be
   bypassed: if careful in not confusing Link
   Type with Neighbor Type nor the constants (confusing SYM_NEIGH with
   SYM_LINK for some reason classical flooding of a message instance).

   A link code advertising:

          Link Type     == SYM_LINK AND

          Neighbor type == NOT_NEIGH

   is
   required (e.g. to transmit control information over unidirectional
   links), the algorithm which specifies how invalid, and any links listed as such messages should be
   handled will simply rebroadcast the message, regardless of MPRs.

   By defining a set of message types, which MUST be recognized by all
   implementations of OLSR, it will be possible to extend silently discarded
   without any processing.

4.3.  HELLO Message Generation

   This involves transmitting the protocol
   through introduction of additional message types, while still be able
   to maintain compatibility with older implementations. The REQUIRED Link Set, the Neighbor Set and the MPR
   Set. In principle, a HELLO message types for OLSR are: serves three independent tasks:

     -    link sensing

     -    HELLO-messages, performing the task of    neighbor sensing. detection

     -    TC-messages, performing    MPR selection signaling

   Three tasks are all are based on periodic information exchange within
   a nodes neighborhood, and serve the task common purpose of "local topology declaration
          (advertisement of link states)

     -    MID-messages, performing
   discovery". A HELLO message is therefore generated based on the task of multiple interface decla-
          ration.

     -    HNA-messages, performing
   information stored in the task of associated host and/or
          network declaration.

     -    FRR-messages, performing Local Link Set, the task of initiating fast re-rout-
          ing in case of Neighbor Set and the
   MPR Set from the local link failure.

   Extensions may for example be messages enabling power conservation /
   sleep mode, multicast routing, support for unidirectional links,
   auto-configuration/address assignment etc.

2.1.5.  Message Emission information base.

   A node must perform link sensing on each interface, in order to
   detect links between the interface and Jitter

   As neighbor interfaces. Further-
   more, a basic implementation requirement, synchronization of control
   messages SHOULD be avoided. As node must advertise its entire symmetric neighborhood on each
   interface in order to perform neighbor detection. Hence, for a consequence, periodic OLSR messages
   SHOULD be emitted such that they avoid synchronization.

   Emission given
   interface, a HELLO message will contain a list of control traffic 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 links on the nature that
   interface (with associated link types), as well as a list of the under-
   lying link-layer, this may or may not lead to collisions and hence
   message loss - possibly loss of several subsequent messages
   entire neighborhood (with an associated neighbor types).

   The Vtime field is set such that it corresponds to the value of the
   same type.

   To avoid
   node's NEIGHB_HOLD_TIME parameter. The Htime field is set such synchronizations, that
   it corresponds to the following simple strategy for
   emitting control messages value of the node's HELLO_INTERVAL parameter
   (see section 15.3).

   The Willingness field is proposed. set such that it corresponds to the nodes
   willingness to forward traffic on behalf of other nodes (see section
   15.8). A node MAY add an amount of
   jitter to MUST advertise the interval at which messages are generated. same willingness on all inter-
   faces.

   The jitter
   must be a random value for each message generated. Thus, for lists of addresses declared in a node
   utilizing jitter:

        Actual HELLO message interval = MESSAGE_INTERVAL - jitter

   Where jitter is a value, randomly selected from are computed as
   follows:

   For each tuple in the interval
   [0,MAXJITTER] and MESSAGE_INTERVAL Link Set, where L_local_iface_addr is the value of the message inter-
   val specified for
   interface where 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 to be forwarded
   by a node, it should be kept in transmitted, and where L_time >=
   current time (i.e. not expired), L_neighbor_iface_addr is advertised
   with:

     1    The Link Type set according to the node during a short period of following:

               if L_SYM_time >= current time :

           Keep message period (not expired) AND

                  L_time >= current time (not expired)

                    Link Type = SYM_LINK

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

                             L_SYM_time < current time (expired) AND

                             L_time >= current time (not expired)

                    Link Type = ASYM_LINK

               Otherwise, if L_ASYM_time < current time (expired) AND

                             L_SYM_time < current time (expired) AND

                             L_time >= current time (not expired)

                    Link Type = jitter

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

   Notice that when the node sends a control message, the opportunity to
   piggyback other messages (before their keeping period LOST_LINK

     2    The Neighbor Type is expired) may
   be taken set according to reduce the number of packet transmissions.

   It should be noticed that the present draft imposes a minimal rate of
   control message emission. However a node MAY send control messages at
   a higher rate (e.g. for better reacting to high mobility). Tuning following:

          2.1  If the
   rate of control traffic main address, corresponding to L_neigh-
               bor_iface_addr, is included in the actual conditions under which MPR set:

                    Neighbor Type = MPR_NEIGH

          2.2  Otherwise, if the pro-
   tocol is main address, corresponding to operate L_neigh-
               bor_iface_addr, is an implementation issue.

2.2.  Neighbor Sensing

   Each node should detect the neighbor interfaces with which it has a
   direct and symmetric link. Uncertainties over radio propagation may
   make some links unidirectional. Consequently, all links MUST be
   checked in both directions included in order to be considered valid.

   To perform the neighbor detection, set:

                    if N_status == SYM

                         Neighbor Type = SYM_NEIGH
                    Otherwise, if N_status == NOT_SYM

                         Neighbor Type = NOT_NEIGH

   For each node broadcasts HELLO messages,
   containing information about heard neighbor interfaces and their link
   status. The link status may either be "symmetric", "heard" (asymmet-
   ric), "MPR" or "lost". "Symmetric" indicates, that tuple in the Neighbor Set, for which no L_neigh-
   bor_iface_addr from an associated link tuple has been
   verified to be bi-directional, i.e. it is possible to transmit data
   in both directions. "Heard" indicates that advertised by
   the node can hear HELLO
   messages from a neighbor interface, but it is not confirmed that this
   neighbor interface previous algorithm,  N_neighbor_main_addr is also able advertised with:

     - Link Type = UNSPEC_LINK

     - Neighbor Type set according to receive messages from the node.
   MPR indicates that the sender has selected the way described above, in step 2

   For a node as MPR.  A status
   of MPR further implies that with a single OLSR interface, the link main address is symmetric.  "Lost" indicates
   that simply
   the link with this neighbor interface is now lost.

   HELLO messages are broadcast to all one-hop neighbors and are emitted
   on each MANET interface address of the node. They are *not relayed* to fur-
   ther nodes.

   More precisely, a HELLO message contains OLSR interface. I.e. for each interface I:

     -    a list of neighbor interface addresses, having a symmetric
          link to interface I;

     - node with a list of neighbor interface addresses, which are "heard" by
          interface I (for historical reasons, single OLSR
   interface, the term "asymmetric" main address, corresponding to L_neighbor_iface_addr
   is
          used for "heard");

     -    a simply L_neighbor_iface_addr.

   The list of neighbor interface addresses of neighbors selected
          as MPRs, AND having in a symmetric link HELLO message can be partial (e.g. due to interface I;

     -    a list of
   message size limitations, imposed by the network), the rule being the
   following: each neighbor interface addresses, which have been lost.

   These lists are computed node MUST be cited at least once within a
   predetermined refreshing period, REFRESH_INTERVAL: at least once with
   the correct "Link Type", and at least once with the correct "Neighbor
   Type" (and, as described in implemented above, preferably both at the same time).
   To keep track of fast connectivity changes, a HELLO message generation
   section.

2.2.1.  HELLO Message Format

   To accommodate the above requirements, as well as must be
   sent at least every HELLO_INTERVAL period, smaller than or equal to accommodate
   REFRESH_INTERVAL.

   Notice that for
   future extensions, an approach similar to limiting the overall packet format impact from loss of control messages, it
   is taken. Thus desirable that a message (plus the proposed format of generic package header) can fit
   into a single MAC frame.

   Each 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

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Reserved              |  Willingness  |  # Interfaces |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Interface Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Interface Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                             . . .                             :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Link Type   |  Interface #  |       Link Message Size       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Neighbor Interface Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Neighbor Interface Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                             . . .                             :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | generated is broadcast by the node to its neigh-
   bors.

4.4.  Populating the Link Type   |  Interface #  | Set

   The Link Message Size       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Neighbor Interface Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Neighbor Interface Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                                       :
   (etc)

   This Set is sent as the data-portion populated with information on links to neighbor
   nodes. The process of the general packet format
   described populating this set is denoted "link sensing"
   and is performed using HELLO message exchange, updating a local link
   information base in each node.

   Each node should detect the Packet Format links between itself and Forwarding section, with 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 described by a pair of interfaces: a local and a remote
   interface.

   For the "Mes-
   sage Type" set purpose of link sensing, each neighbor node (more specifi-
   cally, the link to HELLO_MESSAGE and each neighbor) has an associated status of either
   "symmetric" or "asymmetric". "Symmetric" indicates, that the TTL field set link to
   that neighbor node has been verified to 1 (one).

     Reserved

          This field is reserved for future usage, and MUST be set bi-directional, i.e. it is
   possible to
          "0000000000000000" for compliance with this draft.

     Willingness

          This field transmit data in both directions. "Asymmetric" indicates
   that HELLO messages from the "willingness" of node have been heard (i.e. communication
   from the sender to act as
          a multipoint relay. The willingness parameter neighbor node is an integer
          between 0 and 7. The value 0 possible), however it is for nodes which should never
          forward packets not confirmed that
   this node is also able to other destinations (e.g. because their
          power supply receive messages (i.e. communication to the
   neighbor node is critical). not confirmed).

   The higher the willingness of a
          node, information, acquired through and used by the more likely link sensing is
   accumulated in the node to be selected as MPR by its
          neighbors. link set.

4.4.1.  HELLO Message Processing

   The value 7 is reserved for nodes which should
          always be selected as multipoint relay (e.g. when the node
          belongs to "Originator Address" of a pre-defined backbone). An OLSR router in normal
          operation SHOULD have willingness equal to 3.

     # Interfaces

          This field indicates HELLO message is the number (main) address of additional MANET interfaces
          (in addition to
   the main interface) possessed by node, which has emitted the node. If message. In the node has case where only one interface, this number
   interface of a node is 0.

     Interface Address

          This field indicates participating in the addresses of additional MANET inter-
          faces.  The first one will be referenced as interface running OLSR, this
   address
          number 1, is equivalent of the second "Source Address" as interface address number 2, and so on.
          The main address can be found in the
   IP header of the packet containing the message.

   Upon receiving a HELLO message, a node (whose address is given SHOULD update its Link Set.
   Notice, that a HELLO message MUST neither be forwarded nor be
   recorded in the
          originator duplicate table.

   Upon receiving a HELLO message, the "validity time" MUST be computed
   from the Vtime field of the message header) will header (see section 3.3.2).
   Then, the Link Set SHOULD be referenced updated as
          interface address number 0.
     Link Type

          This field specifies the type of the follows:

     1    Upon receiving a HELLO message, if there exists no link between the inter-
          face 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 the sender, as identified by the interface number, and
          the following list of neighbor interfaces. As a minimum, which
               received the
          following four link types are REQUIRED by OLSR: HELLO message

               L_SYM_time            = current time -    ASYM_LINK, indicating that 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 links are asymmetric (i.e. node finds the address of the neighbor interface is "heard").

          -    SYM_LINK, indicating that which
               received the links are symmetric.

          -    MPR_LINK, indicating, that HELLO message among the links are symmetric AND
               that addresses listed in
               the neighbors have been selected as MPR by link message then the
               sender. tuple is modified as follows:

                    if Link Type is equal to LOST_LINK then

                         L_SYM_time = current time -    LOST_LINK, indicating that 1 (i.e. expired)

                    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 the links have been lost.

     Interface #

          This field indicates following: a link losing its
   symmetry SHOULD still be advertised during at least the number duration of
   the interface "validity time" advertised in the generated HELLO.  This allows
   neighbors to which detect the
          following list link breakage.

4.5.  Populating the Neighbor Set

   A node maintains a set of neighbor interfaces corresponds.  Number 0
          indicates tuples, based on the main interface (whose address link tuples.
   This information is updated according to changes in the main
          address). Link Message Size Set.

   The size of Link Set keeps the link message, counted in bytes and measured
          from information about the beginning of links, while the "Link Type" field and until Neigh-
   bor Set keeps the next
          "Link Type" field (or - information about the neighbors. There is a clear
   association between those two sets, since a node is a neighbor of
   another if and only if there are no more is at least one link types - between the
          end two
   nodes. With multiple interface nodes, there might even be several
   links between two nodes.

   In any case, the formal correspondence between links and neighbors is
   defined as follows:

          The "associated neighbor tuple" of a link tuple, is, if it
          exists, the message).

     Neighbor Interface Address

          An neighbor tuple such as:

               N_neighbor_main_addr == main address of L_neigh-
               bor_iface_addr

          The "associated link tuples" of a neighbor interface.

   Neighbor sensing is performed using HELLO message exchange, updating tuple, are all the neighbor sensing information base in each node.

2.2.2.  Neighbor Sensing Information Base
          link tuples, such as the same condition applies:

               N_neighbor_main_addr == main address of L_neigh-
               bor_iface_addr

   The neighbor sensing information base stores information about neigh-
   bor interfaces, 2-hop neighbors, MPRs and MPR selectors.

2.2.2.1. Neighbor Set

   For each of its interface I MUST populated by maintaining the proper correspon-
   dence between link tuples and for each associated neighbor interface NI, heard
   by I, a node records tuples, as follows:

     Creation

          Each time a "Neighbor Tuple" (N_if_id, N_if_addr,
   N_main_addr, N_willing, N_SYM_time, N_ASYM_time, N_time) where
   N_if_id is the identifier number of the local interface I, N_if_addr link appears, that is, each time a link tuple is
          created, the address of the associated neighbor interface NI, N_main_addr is tuple MUST be created with
          the following values:

               N_neighbor_main_addr = main address of L_neigh-
               bor_iface_addr (from the neighbor possessing NI, N_willing is the willingness
   of the neighbor possessing NI, N_SYM_time is link tuple)

          The N_status MUST then computed as described in the next step

     Update

          Each time until which the a link is considered symmetric, N_ASYM_time is the changes, that is, each time until which the
   neighbor interface information
          of a link tuple is considered heard, and N_time specifies modified, the time
   at which this record expires and *MUST* be removed. When N_SYM_time
   and N_ASYM_time are expired, node MUST ensure that the link is considered lost.

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

   N_SYM_time and N_ASYM_time are used to decide tuple respects the Link Type declared
   for prop-
          erty:

               If the neighbor interface. If N_SYM_time has any associated link which is not expired, the a sym-
               metrical link (i.e. with L_SYM_time >= current time),
               then

                    N_status is
   declared symmetric. If N_SYM_time set to SYM

               else N_status is expired but N_ASYM_time set to NOT_SYM

     Removal

          Each time a link is not,
   the deleted, that is, each time a link tuple
          is declared heard. If both N_SYM_time and N_ASYM_time are
   expired, removed, the link associated neighbor tuple MUST be removed if
          it has no longer any associated links.

   Those rules ensure that there is declared lost.

   In exactly one associated neighbor
   tuple for a node, the set link tuple, and that every neighbor tuple has at least
   one associated link tuple.

4.5.1.  HELLO Message Processing

   The "Originator Address" of Neighbor Tuples are denoted the "Neighbor Set".

2.2.2.2.  2-hop Neighbor Set

   A node records a set of "2-hop tuples" (N_main_addr, N_if_addr,
   N_2hop_addr, N_2hop_main_addr, N_time), describing symmetric or MPR
   links between its neighbors and the symmetric 2-hop neighborhood.
   N_main_addr and N_if_addr are HELLO message is the main address and an interface (main) address of a neighbor, N_2hop_addr is an
   the node, which has emitted the message. In the case where only one
   interface address of a 2-hop
   neighbor with a symmetric or MPR link to interface, N_2hop_main_addr node is participating in the main MANET running OLSR, this
   address is equivalent of the 2-hop node,and N_time specifies "Source Address" as can be found in the time
   at which
   IP header of the tuple expires and *MUST* packet containing the message.  Likewise, the "will-
   ingness" MUST be removed.

   This information is gathered computed from the Willingness field of the HELLO messages received by
   message (see section 4.2).

   Upon receiving a HELLO message, a node from SHOULD first update its neighbor nodes. The N_2hop_main_addr Link
   Set as described before It SHOULD then update its Neighbor Set as
   follows:

     -    if the Originator Address is acquired
   through the multiple interface association base.

   In N_neighbor_main_addr from a node, the set of 2-hop tuples are denoted
          neighbor tuple included in the "2-hop Neighbor
   Set".

2.2.2.3.  MPR Set

   A node maintains a set of neighbors which are selected as MPR. Their
   main addresses are listed in Set:

               then, the so-called MPR Set. The Multipoint
   relay selection section describes how MPRs are selected.

2.2.2.4.  MPR Selector Set

   A node maintains information (obtained neighbor tuple SHOULD be updated as follows:
               N_willingness = willingness from the HELLO messages) about message

4.6.  Populating the neighbors 2-hop Neighbor Set

   The 2-hop neighbor set describes the set of nodes which have selected this node as a MPR.

   Thus, sym-
   metric link to a node records an MPR-selector tuple (MS_if_addr, MS_main_addr,
   MS_time). MS_if_addr symmetric neighbor. This information set is main-
   tained through periodic exchange of HELLO messages as described in
   this section.

4.6.1.  HELLO Message Processing

   The "Originator Address" of a HELLO message is the (main) address of an
   the node, which has emitted the message. In the case where only one
   interface of a node which
   has selected is participating in the node as MPR, MS_main_addr MANET running OLSR, this
   address is equivalent of the main address "Source Address" as can be found in the
   IP header of the
   MPR selector and MS_time specifies packet containing the time at which message.

   Upon receiving a tuple expires
   and *MUST* HELLO message from a symmetric neighbor, a node
   SHOULD update its 2-hop Neighbor Set. Notice, that a HELLO message
   MUST neither be removed.

   In forwarded nor be recorded in the duplicate table.

   Upon receiving a node, HELLO message, the set "validity time" MUST be computed
   from the Vtime field of MPR-selector tuples are denoted the "MPR Selec-
   tor Set".

2.2.3.  HELLO Message Generation

   The lists message header (see section 3.3.2).

   If the Originator Address is the main address of addresses declared in a HELLO message are computed L_neigh-
   bor_iface_addr from a link tuple included in the Neighbor Link Set as follows:

     -    for each tuple where:

               N_SYM_time  < current time (i.e. expired) AND
               N_ASYM_time < current time (i.e. expired)

          N_if_addr is declared with LOST_LINK Link Type for interface
          N_if_id;

     -    for each tuple where:

               N_SYM_time

          L_SYM_time >= current time (not expired)
          N_if_addr is declared with MPR_LINK Link Type

   (in other words: if N_main_addr the Originator Address is included in the MPR set and SYM_LINK Link Type otherwise;

     - Neigh-
   bor Set with N_status = SYM) then the 2-hop Neighbor Set SHOULD then
   be updated as follows:

     1    for each tuple where:

               N_SYM_time < current time (expired) AND
               N_ASYM_time >= current time (not expired),

          N_if_addr is declared with ASYM_LINK Link Type.

   The list of address (henceforth: 2-hop neighbor interfaces address), listed
          in a the HELLO message can be partial
   (e.g. due with Neighbor Type equal to message size limitations, imposed by the network), the
   rule being SYM_NEIGH or
          MPR_NEIGH:

          1.1  if 2-hop neighbor address = main address of receiving
               node:

                    silently discard the following: for each interface a 2-hop neighbor interface address.

               (in other words: a node is
   heard on, not its address is cited with corresponding interface id at
   least once within own 2-hop neighbor).

          1.2  Otherwise, a predetermined refreshing period, REFRESH_INTER-
   VAL. To keep track 2-hop tuple is created with:

                    N_neighbor_main_addr  = Originator Address;

                    N_2hop_addr    = main address of fast connectivity change a 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 in the HELLO message must
   be sent at least every HELLO_INTERVAL period, smaller than or with Neighbor
          Type equal to REFRESH_INTERVAL.

   Notice that for limiting the impact from loss 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.

4.6.2.  Populating the MPR set

   MPRs are used to flood control messages, it
   is desirable that messages from a message (plus the generic package header) can fit node into a single MAC frame.

   Each HELLO message generated is broadcast on each MANET interface of the node.

2.2.4.  HELLO Message Processing

   In this section, network
   while reducing the terms "Originator Address", "Sender Interface",
   "Receiver Interface", and "Link Interface" are used. They are defined
   bellow and illustrated number of retransmissions that will occur in a
   region. Thus, the following figure:

        ______________            _____________
       |           J1 |= --    = |I1           |
       | Main ->   J2 |=      = |I2   <- Main |
       |           J3 |=    -- = |I3           |
        --------------           -------------
                         |
        ______________  /
       |           K1 |=
       | Main ->   K2 |=
       |              |
        --------------

   J1, J2 and J3 are the addresses concept of local interfaces on node J. Like-
   wise, I1, I2 and I3 are addresses MPR is an optimization of local interfaces on a classical
   flooding mechanism.

   Each node I and
   K1 and K2 are addresses in the network selects, independently, its own set of local interfaces on node K. There are MPRs
   among its symmetric links between J1 and I3 and between J3 and K1. neighborhood. The three nodes have selected, respectively, J2, I2 and K2 as their
   "main addresses". I.e. the Originator Address symmetric links with MPRs are
   advertised with Link Type MPR_NEIGH instead of all OLSR-messages
   sent SYM_NEIGH in HELLO
   messages.

   The MPR set MUST be calculated by a node J will have in such a way that it,
   through the Originator Address J2. For node I and K, neighbors in the main addresses will be I2 and K2, respectively

   A HELLO message, sent by node J, is transmitted on MPR-set, can reach all node J's
   interfaces. Received by node I, the following naming conventions
   apply:

     -    The term "Originator Address" symmetric strict
   2-hop neighbors. (Notice that a node, a, which is the main address a direct neighbor
   of the another node,
          originating b, is not also a message. In the example above, the Originator
          Address strict 2-hop neighbor of node b).
   This means that the HELLO is J2.

     -    The term "Sender Interface" for union of the HELLO message is symmetric neighborhoods of the
          interface over which MPR
   nodes contains the HELLO was transmitted. In symmetric strict 2-hop neighborhood. MPR set
   recalculation should occur when changes are detected in the example
          above, neighbor-
   hood or in the Sender Interface Address 2-hop neighborhood.

   While it is J1.

     -    The term "Receiver Interface" will be used for the interface
          which received the HELLO message. In the example above, node
          I's "Receiver Interface" for not essential that the HELLO generated by node J MPR set is
          I3.

     -    The term "Link Interface" will minimal, it is essen-
   tial that all strict 2-hop neighbors can be used in a HELLO message to
          designate on which interface (of reached through the sender of a HELLO mes-
          sage) a
   selected MPR nodes. A node SHOULD select an MPR set such that any
   strict 2-hop neighbor is detected. In the example above, K1 is
          listed in the HELLO message of J with Link Interface J3.  The
          "Link Interface" is calculated based on covered by at least one MPR node. This
   ensures that the Interface # in overhead of the
          HELLO message. Notice that an interface address may be listed
          several times with different Link Interfaces.

   Upon receiving protocol is kept at a HELLO message, minimum.

   By default, the node SHOULD update MPR set can coincide with the neighbor
   information corresponding to entire symmetric neigh-
   bor set. This will be the sender node address (a node may -
   e.g. for security reasons - wish case at network initialization (and will
   correspond to restrict updating the neighbor-
   table, i.e. ignoring HELLO messages from some nodes).

   Notice, 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 a HELLO message MUST neither be forwarded nor be
   recorded node to reach any node in the duplicate table.
   symmetrical strict 2-hop neighborhood through relaying by one MPR
   node. The Neighbor Set should following terminology will be updated as follows:

     1    Upon receiving a HELLO message, if used in describing this algo-
   rithm:

     N:
          The set of neighbors with which there exists no neighbor
          tuple with

               N_if_addr == Sender Interface Address

          and

               N_if_id == identifier a symmetric link.
     N2:
          The set made of the Receiver Interface,

          a new tuple is created with

               N_if_addr   = Sender Interface Address

               N_if_id     = identifier nodes in the symmetric 2-hop neighbor set
          excluding (i) the nodes only reachable by members of N with
          N_willingness WILL_NEVER, (ii) all the Receiver Interface

               N_SYM_time  = current time - 1 (expired)

               N_time      = current time + NEIGHB_HOLD_TIME

     2    The tuple (existing or new) with:

               N_if_addr == Sender Interface Address nodes in N and

               N_if_id == identifier of (iii)
          the Receiver Interface,

          is then modified as follows:

          2.1  N_main_addr = Originator Address.

          2.2  N_willing = Originator Willingness

          2.4  N_time      = max (N_time, current time +
               NEIGHB_HOLD_TIME);

          2.5  N_ASYM_time = current time + NEIGHB_HOLD_TIME;

          2.6  if node performing the computation.
     D(y):

          The degree of an one hop neighbor node finds y (where y is a member
          of N), is defined as the Receiver Interface Address among number of symmetric neighbors of node
          y, EXCLUDING all the addresses listed in members of N and EXCLUDING the HELLO with:

                    Link Interface Address == Sender Interface Address,

               then, node per-
          forming the tuple computation.

   The proposed heuristic is modified as follows:

                    if Link Type == LOST_LINK then
                         N_SYM_time = current time -

     1 (i.e. expired)

                    else:

                         N_SYM_time = current time + NEIGHB_HOLD_TIME,

                         N_time     = current time +    Start with an MPR set made of all members of N with N_willing-
          ness equal to WILL_ALWAYS

     2 *
                         NEIGHB_HOLD_TIME.

   The rule for setting N_time    Calculate D(y), where y is the following: a link loosing its sym-
   metry should still be advertised during member of N, for all nodes in N.

     3    While there exist nodes in N2 which are not covered by at
          least NEIGHB_HOLD_TIME.
   This allows neighbors to detect one node in the link breakage.

   The 2-hop Neighbor Set is updated as follows:

     1    for MPR set:

          3.1  For each 2-hop interface address listed node in N, calculate the HELLO message
          with Link Type SYM_LINK or MPR_LINK, reachability, i.e. the
               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 one hop neighbor;

          3.2  Select as a 2-hop tuple is created
          with:

               N_main_addr      = Originator Address;

               N_if_addr        = Link Interface Address corresponding
               to MPR the 2-hop interface address;

               N_2hop_addr      = node with highest N_willingness among
               the interface address nodes in N with non-zero reachability. In case of
               multiple choice select the 2-hop
               neighbor;

               N_time           = current time + 2HOP_HOLD_TIME.

               N_2hop_main_addr = node which provides reachabil-
               ity to the main address maximum number of nodes in N2.  In case of
               multiple nodes providing the node,
               extracted from same amount of reachability,
               select the multiple interface association infor-
               mation base; if no address node as MPR whose D(y) is available, greater. Remove the interface
               address N_if_addr is used.

          This tuple may replace
               nodes from N2 which are now covered by a node in the MPR
               set.

     4    As an older similar tuple with same
          N_if_addr and N_2hop_addr values.

     2    For optimization, process each 2-hop interface address listed node y in the HELLO message
          with Link Type LOST_LINK or ASYM_LINK, all the 2-hop tuples
          where:

               N_if_addr == Link Interface Address corresponding to the
               2-hop interface address,

          and
               N_2hop_addr == MPR set in the 2-hop interface address
          increasing order of their willingness.  If all nodes in N2 are deleted.

   Based on
          still covered by at least one node in the information obtained MPR set excluding y
          and N_willingness of node y is smaller than WILL_ALWAYS, then
          node y is removed from the HELLO messages, each node
   constructs its MPR selector set.

   Thus, upon

4.7.  Populating the MPR Selector Set

   The MPR selector set of a node, n, is populated by the main addresses
   of the nodes which have selected n as MPR. MPR selection is signaled
   through HELLO messages.

4.7.1.  HELLO Message Processing

   Upon receiving a HELLO message, if a node finds one of its
   interface own inter-
   face addresses in a the list with a link type of "MPR", it MUST
   update the MPR selector set Neighbor Type equal to contain updated MPR_NEIGH,
   information about the
   sender of from the HELLO message:

     1    If there exists no message must be recorded in the MPR selector tuple with:

                    MS_if_addr   == Link Interface Address

               and

                    MS_main_addr == Originator Address

     2
   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_if_addr

                    MS_main_addr   == Link Interface Originator Address

               then a new tuple is created with:

               MS_if_addr

                    MS_main_addr   = Link Interface Originator Address

          3    The tuple is then modified as follows:

               MS_main_addr = Originator Address,

                    MS_time      = current time + NEIGHB_HOLD_TIME. validity time.

   Deletion of MPR selector tuples occurs in case of expiration of the
   timer or in case of link breakage as described in the neighborhood "Neighborhood
   and 2-hop neighborhood changes section.

2.2.5.  Multipoint Relay Selection

   MPRs are used to flood control messages from that node into the net-
   work while reducing the number of retransmissions that will occur Neighborhood Changes".

4.8.  Neighborhood and 2-hop Neighborhood Changes

   A change in
   a region. Thus, the concept of MPR neighborhood is an optimization detected when:

     -    The L_SYM_time field of a classical
   flooding mechanism.

   Each link tuple expires. This is consid-
          ered as a neighbor loss if it was the last link with a neigh-
          bor node in (on the network selects, independently, its own set of MPRs
   among its symmetric neighborhood. The symmetric links contrary, a link with MPRs are
   advertised an interface may break
          while a link with Link Type MPR_LINK instead another interface of SYM_LINK in HELLO mes-
   sages.

   The MPR set MUST be calculated by a the neighbor node
          remains).

     -    A new link tuple is inserted in such the Link Set with a way non-
          expired L_SYM_time or a tuple with expired L_SYM_time is modi-
          fied so that it,
   through L_SYM_time becomes non-expired. This is consid-
          ered as a neighbor appearance if there was previously no link
          with the neighbors corresponding neighbor node.

   A change in the MPR-set, can reach all symmetric 2-hop
   neighbors. (Notice that a node, a, which is a direct neighbor of
   another node, b, neighborhood is not also detected when a 2-hop neighbor of node b). This means
   that the union of the symmetric neighborhoods of the MPR nodes con-
   tains the symmetric 2-hop neighborhood. MPR set recalculation should
   occur
   tuple expires or is deleted according to section 4.6.

   The following processing occurs when changes are detected in the neighborhood or in
   the 2-hop
   neighborhood.

   While it is not essential that the MPR set is minimal, it is essen-
   tial that neighborhood are detected:

     -    In case of neighbor loss, all 2-hop neighbors can be reached through the selected MPR
   nodes. A node SHOULD select an MPR set such that any 2-hop neighbor
   is covered by at least MPR_COVERAGE MPR nodes. With MPR_COVERAGE=1
   the overhead tuples with N_neigh-
          bor_main_addr == Main Address of the protocol is kept at a minimum. In presence of
   mobility and link failure, an MPR_COVERAGE=2 could provide a more
   redundant connectivity, for example to support a link failure without
   re-routing.

   Notice that MPR_COVERAGE can neighbor MUST be tuned locally without affecting the
   consistency deleted.

     -    In case of the protocol. For example, a node can set MPR_COVER-
   AGE=2 if it observes many changes in its neighbor information base
   caused by mobility, while otherwise keeping MPR_COVERAGE=1.

   By default, loss, all the MPR set can coincide selector tuples with
          MS_main_addr == Main Address of the entire symmetric neigh-
   bor set. This will neighbor MUST be the case at network initialization (and will
   correspond to classic link-state routing). deleted

     -    The following specifies a proposed heuristic for selection of MPRs
   [2] adapted for multiple interfaces support. It constructs an MPR-set
   that enables it to reach any symmetrical 2-hop interface (i.e. any
   interface of MPR set MUST be re-calculated when a 2-hop neighbor having a symmetrical link with appearance
          or loss is detected, or when a neigh-
   bor). The following terminology will be used change in describing this algo-
   rithm:

     N: the 2-hop neighbor-
          hood is detected.

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

5.  Topology Discovery

   The set link sensing and neighbor detection part of the protocol basi-
   cally offers, to each node, a list of neighbors with which there exists a symmetric link.

     N2: it can
   communicate directly and, in combination with the Packet Format and
   Forwarding part, an optimized flooding mechanism through MPRs. Based
   on this, topology information is disseminated through the network.
   The set made present section describes what part of the main addresses of information given by
   the 2-hop link sensing and neighbor set
          excluding (i) detection is disseminated to the nodes only reachable by members of N entire
   network and how it is used to construct routes.

   Routes are constructed through advertised links and links with
          willingness zero, (ii) all neigh-
   bors. A node must at least disseminate links between itself and the
   nodes in N and (iii) its MPR-selector set, in order to provide sufficient infor-
   mation to enable routing.

5.1.  TC Message Format

   The proposed format of a TC 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 node
          performing data-portion of the computation.

     D(y): general message format with
   the "Message Type" set to TC_MESSAGE.  The degree 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 an one hop TOP_HOLD_TIME, as specified
   in section 15.3.

     Advertised Neighbor Sequence Number (ANSN)

          A sequence number is associated with the advertised neighbor
          set.  Every time a node y (where y is detects a member
          of N), change in its advertised
          neighbor set, it increments this sequence number ("Wrap-
          around" is defined handled as the described in section 16). This
          number is sent in this ANSN field of symmetric neighbors the TC message to keep
          track of the most recent information. When a node
          y, EXCLUDING all receives a
          TC message, it can decide on the members basis of N and EXCLUDING this Advertised
          Neighbor Sequence Number, whether or not the node per-
          forming received informa-
          tion about the computation.

     Poorly covered node:
          A poorly covered node is a advertised neighbors of the originator node in N2 which is covered by less
          more recent than MPR_COVERAGE nodes in N.

   The proposed heuristic is as follows:

     1    Start with an MPR set made of all members what it already has.

     Advertised Neighbor Main Address

          This field contains the main address of N with willing-
          ness equal to seven

     2    Calculate D(y), where y is a member neighbor node. All
          main addresses 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 advertised neighbors of the Originator
          node are then removed from N2 for put in the rest
          of TC message. If the computation.

     4    While maximum allowed message
          size (as imposed by the network) is reached while there exist nodes in N2 which are
          still advertised neighbor addresses which have not covered by at
          least MPR_COVERAGE been
          inserted into the TC-message, more TC messages will be gener-
          ated until the entire advertised neighbor set has been sent.
          Extra main addresses of neighbor nodes may be included, if
          redundancy is desired.

     Reserved

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

5.2.  Topology Information Base

   Each node in the MPR set:

          4.1  For network maintains topological information about the
   network. This information is acquired from TC-messages and is used
   for routing table calculations.

   Thus, for each node destination in N, calculate the reachability, i.e. network, a "Topology Tuple"
   (T_dest_addr, T_last_addr, T_seq, T_time) is recorded. T_dest_addr is
   the
               number main address of nodes in N2 a node, which are not yet covered by at
               least MPR_COVERAGE nodes may be reached in the MPR set, and which are
               reachable through this one hop neighbor;

          4.2  Select as a MPR from the
   node with highest willingness among the nodes in N with non-zero reachability. In case main address T_last_addr. Typically, T_last_addr is a
   MPR of
               multiple choice select T_dest_addr. T_seq is a sequence number, and T_time specifies
   the node time at which provides reachabil-
               ity to the maximum number of nodes in N2. this tuple expires and *MUST* be removed.

   In case of
               multiple nodes providing a node, the same amount set of reachability,
               select Topology Tuples are denoted the node as MPR whose D(y) "Topology Set".

5.3.  Advertised Neighbor Set

   A TC message is greater. Remove the
               nodes from N2 which are now covered sent by MPR_COVERAGE nodes
               in the MPR set.

     5    As an optimization, process each a node y in the MPR network to declare a set in the
          increasing order of their willingness.  If all nodes in N2 are
          still covered by
   links, called advertised link set which MUST include at least MPR_COVERAGE nodes in the MPR set
          excluding y and willingness
   links to all nodes of its MPR Selector set, i.e., the neighbors which
   have selected the sender node y as a MPR. If, for some reason, it is smaller than seven,
          then node y
   required to distribute redundant TC information, refer to section
   11.

   The sequence number (ANSN) associated with the advertised neighbor
   set is also sent with the list. The ANSN number MUST be incremented
   when links are removed from the MPR advertised neighbor set; the ANSN
   number SHOULD be incremented when links are added to the advertised
   neighbor set.

   When

5.4.  TC Message Generation

   In order to build the MPR set topology information base needed, each node,
   which has been computed, all the corresponding main
   addresses selected as MPR, broadcasts Topology Control (TC) mes-
   sages. TC messages are stored flooded to all nodes in the MPR Set.

2.2.6.  Neighborhood network and 2-hop Neighborhood Changes

   A change take
   advantage of MPRs. MPRs enable a better scalability in the neighborhood is detected when:

     - distribu-
   tion of topology information [1].

   The N_SYM_time field list of addresses can be partial in each TC message (e.g. due to
   message size limitations, imposed by the network), but parsing of all
   TC messages describing the advertised link set of a neighbor tuple expires. This is con-
          sidered as node MUST be com-
   plete within a neighbor loss if it was certain refreshing period (TC_INTERVAL). The informa-
   tion diffused in the last network by these TC messages will help each node
   calculate its routing table.

   When the advertised link with set of a
          neighbor node (on becomes empty, it SHOULD still
   send (empty) TC-messages during the contrary, a link with an interface may
          break while a link with another interface duration equal to "validity
   time" of its TC-messages to invalidate the neighbor node
          remains).

     -    The N_ASYM_time field of a neighbor tuple expires and
          N_SYM_time is expired. The link is previous TC-messages. It
   SHOULD then considered lost.

     -    A new neighbor tuple stop sending TC-messages until some node is inserted in the Neighbor Set with a
          non-expired N_SYM_time or a tuple with expired N_SYM_time is
          modified so that N_SYM_time becomes non-expired. This is con-
          sidered as a neighbor appearance if there was previously no
   its advertised link with the corresponding neighbor node. set.

   A node MAY transmit additional TC-messages to increase its reactive-
   ness to link failures. When a change in to the 2-hop neighborhood MPR selector set is
   detected when and this change can be attributed to a 2-hop neighbor
   tuple expires or is deleted according link failure, a TC-
   message SHOULD be transmitted after a shorter interval than TC_INTER-
   VAL.

5.5.  TC Message Forwarding

   TC messages are broadcasted and retransmitted by the MPRs in order to
   diffuse the HELLO message processing
   section.

   The following processing should occur when changes messages in the neighbor-
   hood or entire network. TC messages MUST be
   forwarded according to the 2-hop neighborhood are detected:

     -    In case "default forwarding algorithm".

5.6.  TC Message Processing

   Upon receiving a TC message, the "validity time" MUST be computed
   from the Vtime field of neighbor loss, all the 2-hop tuples with
          N_main_addr == Main Address message header (see section 3.3.2).
   The topology set SHOULD then be updated as follows (using section
   16 for comparison of ANSN):

     1    If the neighbor are deleted.

     -    In case sender interface (NB: not originator) of neighbor loss, all this message
          is not in the MPR selector tuples with
          MS_main_addr == Main Address symmetric neighborhood of this node, the neighbor are deleted

     -    The MPR set is re-calculated when a neighbor appearance or
          loss is detected, or when a change message
          MUST be discarded.

     2    If there exist some tuple in the 2-hop neighborhood
          is detected.

     -    An additional HELLO 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 MAY MUST be sent when silently discarded (case: mes-
          sage received out of order).

     3    All tuples in the MPR topology set
          changes.

2.2.7.  Advanced Neighbor Sensing Functioning

   Established links should where:

               T_last_addr == originator address AND

               T_seq       <  ANSN

          MUST be as reliable as possible to avoid data
   packet loss. To enhance removed from the reliability topology set.

     4    For each of the advertised neighbor sensing mech-
   anism, main address received in
          the following implementation recommendations should be consid-
   ered.

   Each neighbor 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 SHOULD, to:

                    T_time      =  current time + validity time.

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

                    T_dest_addr = advertised neighbor main address,

                    T_last_addr = originator address,

                    T_seq       = ANSN,

                    T_time      = current time + validity time.

5.7.  Routing Table Calculation

   Each node maintains a routing table which allows it to what
   is described route data,
   destined for the other nodes in previous sections, include a N_pending field, a
   N_quality field, and a N_LOST_time field.  N_pending is a boolean
   value specifying if the link network. The routing table is considered pending (i.e.
   based on the information contained in the link is
   not considered established). N_quality is a dimensionless number
   between 0 set and 1 describing the quality of the link. N_LOST_time is a
   timer for declaring a link as lost when an established link becomes
   pending.

   HELLO message generation should consider those new fields as follows:

     1 topology
   set. Therefore, if N_LOST_time is not expired, any of these sets are changed, the link routing table
   is advertised with a
          link type re-calculated to update the route information about each destina-
   tion in the network. 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 the table consists of LOST_LINK;

     2    otherwise, if N_LOST_time is expired R_dest_addr, R_next_addr, R_dist,
   and N_pending R_iface_addr which specifies that the node identified by
   R_dest_addr is set estimated to
          "true", the link SHOULD NOT be advertised at all;

     3    otherwise, if N_LOST_time is expired R_dist hops away from the local node,
   and N_pending that the symmetric neighbor node with interface address
   R_next_addr is set to
          "false", the link next hop node in the route to R_dest_addr, and
   this one hop is advertised as described reachable through the local interface R_iface_addr.
   Entries are recorded in the HELLO mes-
          sage generation section.

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

     1    N_LOST_time is expired, AND

     2    N_pending is "false", AND

     3    N_SYM_time is not expired.

   This should be taken as definition destination in the network
   for computing which the symmetric neigh-
   borhood when computing route is known. All the MPR set.

   Apart from destinations for which the above points, what has been described previously does
   route is broken or partially known are not interfere with these advanced neighbor sensing fields entered in the
   neighbor tuples. table.

   The N_quality, N_pending and N_LOST_time fields are
   exclusively routing table is updated according to when a change is detected in the present section. Advanced neigh-
   bor sensing does not modify information base and the topology set (and also the Multiple
   Interface Association Information Base, section 7.3.1, and the
   Host and Network Association Information Base, section 8,
   if applicable). More precisely, the function of any other fields routing table is re-calculated in the
   case of neighbor tuples.

   This advanced functioning appearance or loss, or when a topology tuple is described as separately as possible to
   increase readability.

2.2.7.1.  Link Hysteresis cre-
   ated or removed. The link between a node and some update 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 following hysteresis strategy
   SHOULD information does not gen-
   erate or trigger any messages to be adopted.

   For each neighbor interface NI heard by interface I, transmitted, neither in the N_quality
   field of net-
   work, nor in the corresponding Neighbor Tuple determines one-hop neighborhood.

   To construct the establish-
   ment routing table of node X, a shortest path algorithm
   is run on the link. The value of N_quality directed graph containing the arcs X -> Y where Y is compared
   any symmetric neighbor of X (with Link Type equal to two thresh-
   olds HYST_THRESHOLD_HIGH, HYST_THRESHOLD_LOW, fixed between 0 SYM_LINK) and 1
   the arcs U -> V where there exists an entry in the topology set with
   V as T_dest_addr and such that HYST_THRESHOLD_HIGH >= HYST_THRESHOLD_LOW. U as T_last_addr.

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

     1    All the entries from the routing table are removed.

     2    The new routing entries are added starting with the symmetric
          neighbors (h=1) as the destination nodes. I.e. for each link
          tuple in the following:

     1    if N_quality > HYST_THRESHOLD_HIGH:

               N_pending = false

               N_LOST_time = current time - 1 (expired)

     2    otherwise, if N_quality < HYST_THRESHOLD_LOW:

               N_pending = true

               N_LOST_time = min (N_time, link set where:

               L_SYM_time   >= current time +
               NEIGHB_HOLD_TIME)

               (the link

          (there is then considered as lost according a symmetric link to the
               Neighborhood and 2-hop neighborhood changes section and
               this may produce a neighbor loss).

     3    otherwise, if HYST_THRESHOLD_LOW <= N_quality <= HYST_THRESH-
          OLD_HIGH:

               N_pending and N_LOST_time remain unchanged.

   The condition for considering neighbor), a link established new routing
          entry is thus stricter
   than recorded in the condition for loosing it.

   As a basic implementation requirement, an estimation routing table with:

               R_dest_addr  = main address of the link
   quality must be maintained and stored in the N_quality field. If some
   measure 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 the signal/noise level on a received message is available
   (e.g. as a link layer notification), then it can be used as estima-
   tion after normalization. entry.

          If no signal/noise information in the above, R_dest_addr is available distinct from R_next, another
          new routing entry with MUST 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 new route entries for the link layer, an
   algorithm such as destination nodes h+1 hops away
          are recorded in the routing table. The following can procedure
          MUST be utilized. The algorithm is
   parameterized executed for each value of h, starting with h=1 and
          incrementing it by a scaling parameter HYST_SCALING which 1 each time. The execution will stop if no
          new entry is a number
   fixed between 0 and 1. recorded in an iteration.

          3.1  For each neighbor interface NI heard by inter-
   face I, the first time NI is heard by I, N_quality is set to
   HYST_SCALING (N_pending is set topology entry in the topology table, if its
               T_dest_addr does not correspond to true and N_LOST_time R_dest_addr of any
               route entry in the routing table AND its T_last_addr cor-
               responds to current
   time - 1).

   A tuple R_dest_addr of a route entry whose R_dist is updated according
               equal to two rules.  Every time an OLSR packet
   emitted by NI is received by I, h, then a new route entry MUST be recorded in
               the stability rule is applied:

          N_quality routing table (if it does not already exist) where:

                    R_dest_addr = (1-HYST_SCALING)*N_quality + HYST_SCALING.

     When an OLSR packet emitted by NI is lost by I, T_dest_addr;

                    R_next_addr = R_next_addr of the instability
     rule is applied:

          N_quality recorded route
                    entry whose R_dest_addr == T_last_addr

                    R_dist = (1-HYST_SCALING)*N_quality.

   The loss h+1; and

                    R_iface_addr = R_iface_addr of OLSR packet is detected by tracking the missing Packet
   Sequence Numbers on recorded route
                    entry whose R_dest_addr == T_last_addr.

          3.2  Several topology entries may be used to select a per interface basis next hop
               R_next_addr for reaching the node R_dest_addr.  When h=1,
               ties should be broken such that nodes with highest will-
               ingness and by long period of
   silence. MPR selectors are preferred as next hop.

   If no HELLO message the MPR set has been received for a HELLO_INTERVAL
   period, changed, a loss of HELLO TC message is detected.

2.2.7.2.  Optional Link layer notification

   OLSR is designed not to impose or expect any specific information
   from the link layer. However, if information from containing the link-layer is
   available, new MPR
   selector set SHOULD be generated.

6.  Node Configuration

   This section outlines how a node MAY use this as described should be configured, in this section.

   If link layer information describing connectivity order to neighboring
   nodes is available (i.e. loss of connectivity such as through absence
   of a link layer acknowledgment), this information is used
   operate in an OLSR manet.

6.1.  Address Assignment

   The nodes in addition
   to the information from MANET network SHOULD be assigned addresses within a
   defined address sequence. I.e., the HELLO-messages to maintain nodes in the neighbor
   information base MANET SHOULD be
   addressable through a network address and a netmask.

   Likewise, the MPR selector set.

   Thus, upon receiving nodes in each associated network SHOULD be assigned
   addresses from a link-layer notification defined address sequence, distinct from that being
   used in the link between
   a MANET.

6.2.  Routing Configuration

   Any MANET node and a neighbor interface is broken, the following actions are
   taken with respect associated networks or hosts SHOULD be configured
   such that it has routes set up to neighbor sensing:

     1    if the link to a neighboring symmetric interfaces with associated
   hosts or asymmetric interface
          is broken, network.

6.3.  Data Packet Forwarding

   OLSR itself does not perform packet forwarding. Rather, it maintains
   the corresponding neighbor tuple routing table in the underlying operating system, which is modified:
          N_LOST_time and N_time are set
   assumed to current time +
          NEIGHB_HOLD_TIME.

     2    this is considered be forwarding packets as specified in RFC1812.

7.  Multiple OLSR Interfaces

   A node may have multiple interfaces, each with a link loss and distinct IP address.
   These interfaces may either participate in the appropriate process-
          ing OLSR routing domain -
   or they may participate in other routing domains. Integrating infor-
   mation from non-OLSR routing domains into OLSR is described in the neighborhood and 2-hop neighborhood
          changes section should be performed.

2.3.  Topology Discovery

   The Neighbor Sensing part of the protocol basically offers to each sec-
   tion 8.

   A node with only a list single OLSR interface, which wishes to participate
   in a network of neighbors nodes with which it can communicate directly multiple OLSR interfaces SHOULD implement
   the provisions described in section #REF:midmf and
   an optimized flooding mechanism through MPRs. Based on this mecha-
   nism, topology information is disseminated through 7.7.

   For nodes with multiple OLSR interfaces, participating in the network. The
   present OLSR
   routing domain, the provisions in this section describes what part of MUST be applied.

7.1.  Terminology

   For the information given by purpose of Multiple OLSR Interfaces, the
   Neighbor Sensing is disseminated and how it following terminol-
   ogy is used to construct
   routes.

   Routes are constructed through advertised links and links with neigh-
   bors. introduced or refined:

     Multiple Interface Node

               A node must at least disseminate its MPR-selector set, which has multiple interfaces, participating in order
   to provide sufficient information to enable routing. If a an
               OLSR routing domain.

     Single Interface Node

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

   Notice, that both a "Multiple Interface Node" and a "Single Interface
   Node" may have additional interfaces, it must also disseminate not participating in the list of its OLSR
   routing domain. Integrating information from these non OLSR inter-
   face addresses.

2.3.1.  TC Message Format

   The proposed format of a TC message
   faces 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              MSSN             |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Advertized neighbor Main Address                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Advertized neighbor described in section 8.

     Main Address                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This is sent

               The main address of a node, which will be used in OLSR
               control traffic as the data-portion "originator address" of all mes-
               sages emitted by this node. It is the address of one of
               the interfaces of the node.

               A multiple interface node MUST choose one of its inter-
               face addresses as its "main address". It is of no impor-
               tance which address is chosen, however a node SHOULD
               always use the general message format same address as its main address.

7.2.  Multiple Interface Functioning

   A node with multiple interfaces functions like a node with a single
   interface, i.e. through performing link-sensing, neighbor- and 2-hop
   neighbor detection, MPR selection and signaling, diffusion of topol-
   ogy control messages and route calculation.

   This section outlines the "Message Type" set to TC_MESSAGE.  The time to live SHOULD few additional provisions which must be set
   to 255 (maximum value)
   made to diffuse the message into the entire net-
   work.

     MPR Selector accommodate for multiple interfaces in OLSR.

     Packet Sequence Number (MSSN)

          A sequence number
          The Packet Sequence Number (PSN), is associated with now maintained per inter-
          face.  Each interface has its own PSN, which is put in the advertized neighbor
          set.  Every
          packet header as specified in section 3.3.1, and incre-
          mented each time a node detects a change in its advertized
          neighbor set, it increments this sequence number. This number packet is sent in on this MSSN field interface.

     Link Sensing

          Link Sensing is accomplished through periodic emission of
          HELLO messages over the TC interfaces through which connectivity
          is checked. A separate HELLO message to keep track of is generated per inter-
          face and emitted in correspondence with the most recent information. When a node receives provisions in sec-
          tion 4.4.

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

     Neighbor detection

          Given a network with only single interface nodes, a node may
          deduct the basis of this MPR Selector Sequence
          Number, whether or not neighbor set directly from the received information about the MPR
          selectors
          exchanged as part of link sensing: the originator "main address" of a
          single interface node is more recent than what it
          already has.

     Advertized Neighbor Main Address

          This field contains is, by definition, the main address of a neighbor the
          only interface on that node. All

          In a network with multiple interface nodes, additional infor-
          mation is 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, as described in section 7.3

          Thus, in the presence of multiple interfaces, the neighbor set
          MUST be computed based on the information acquired through
          HELLO messages and MID messages, as described in section
          7.5.

     MPR selectors Selection and MPR Signaling

          The objective of the Originator MPR selection is for a node to select a sub-
          set 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. This is
          detailed in section 7.6.

          MPR signaling is provided in correspondence with the provi-
          sions in the previous section 4.3.

     Topology Control Message Diffusion

          Topology Control messages are
          put diffused in correspondence with
          the TC message. If provisions in the maximum allowed message size (as
          imposed by previous section 5.5

     Route Calculation

          Multiple interfaces per node corresponds, effectively, to mul-
          tiple network destinations per node. Hence, the network) is reached while there are still MPR
          selector addresses which have not been inserted into interface
          association informations acquired through the TC-
          message, more TC multiple inter-
          face declaration messages will be generated until the entire
          MPR selector set has been sent. Extra main addresses of neigh-
          bor nodes may must be included, if redundancy is desired.

     Reserved taken into account when pop-
          ulating the routing table. This field is reserved for future usage, and detailed in section
          7.7

7.3.  Multiple Interface Declaration

   Each node with multiple interfaces MUST be set announce, periodically,
   information describing its interface configuration to
          "0000000000000000" for compliance with this draft.

2.3.2.  Topology Information Base other nodes in
   the network. This is accomplished through flooding a Multiple Inter-
   face Declaration message to all nodes in the network through the MPR
   flooding mechanism.

   Each node in the network maintains topological interface information about the
   other nodes in the network. This information is acquired from TC-messages MID-mes-
   sages, emitted by nodes with multiple interfaces participating in the
   MANET, and is used for routing table calculations.

   Thus, for each destination in the network, a "Topology Tuple"
   (T_dest, T_last, T_seq, T_time) is recorded. T_dest is the main
   address of a node, which may be reached in one hop from the node with
   the main address T_last. Typically, T_last is a MPR of T_dest. T_seq
   is a sequence number, and T_time specifies the time at which this
   tuple expires and *MUST* be removed.

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

2.3.3.  Advertized Neighbor Set

   A TC message is sent by a node in the network to declare a set of
   links, called the advertized neighbor 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.

   The sequence number (MSSN) associated with the advertized neighbor
   set is also sent with the list. The MSSN number MUST be incremented
   when links are removed from the advertized neighbor set; the MSSN
   number SHOULD be incremented when links are added to the advertized
   neighbor set.

   In order to provide redundancy

   Specifically, multiple interface declaration associates multiple
   interfaces to the topology information base, the
   advertized neighbor set of a node can contain links (and to neighbor nodes
   which are not a main address) through populating the
   multiple interface association base in each node.

7.3.1.  Multiple Interface Association Information Base

   For each destination in the MPR selector set 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 the main address of this
   node. The advertized
   neighbor set can  I_time specifies the time at which this tuple expires and
   *MUST* be removed.

   In a node, the whole neighbor set of Interface association Tuples is denoted the node. In this case
   the nodes receiving the TC
   "Interface association Set".

7.3.2.  MID Message Format

   The proposed format of a MID message will get 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Interface Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Interface Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This is sent as the knowledge data-portion of all the
   adjacent links of general packet format
   described in section 3.4, with the sender node. The advertized neighbor "Message Type" set can to
   MID_MESSAGE. The time to live SHOULD be
   built according set to 255 (maximum value) to
   diffuse the following rule based on a local parameter
   called TC_REDUNDANCY.

     1    if message into the TC_REDUNDANCY parameter entire network and Vtime set accordingly
   to the value of MID_HOLD_TIME, as specified in section 15.3.

     Interface Address

          This field contains the address of an interface of the node is zero, then
          other than its
          advertized neighbor set is limited to the MPR selector set.

     2    If main address (which already indicated in the TC_REDUNDANCY parameter
          originator address).

   All interface addresses other than the main address of the Originator
   node is one, then its
          advertized neighbor set is are put in the union of its MPR set and its
          MPR selector set.

     3 MID message. If the TC_REDUNDANCY parameter of maximum allowed message size
   (as imposed by the node is two, then its
          advertized neighbor set network) is its neighbor set.

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

2.3.4.  TC Message Generation

   In order to build the topology information base needed, each node, reached while there are still inter-
   face addresses which has have not been selected as MPR, broadcasts Topology Control (TC) mes-
   sages. TC inserted into the MID-message,
   more MID messages are flooded to all nodes in generated until the network and take
   advantage of MPRs. MPRs enable entire interface addresses
   set has been sent.

7.3.3.  MID Message Generation

   A MID message is sent by a better scalability node in the distribu-
   tion network to declare its multi-
   ple interfaces (if any). I.e., the MID message contains the list of topology information [1].
   interface addresses which are associated to its main address.  The
   list of addresses can be partial in each TC MID message (e.g. due to
   message size limitations, imposed by the network), but parsing of all
   TC
   MID messages describing the advertized neighbor interface set of from a node MUST be
   complete com-
   plete within a certain refreshing period (TC_INTERVAL). (MID_INTERVAL). The infor-
   mation informa-
   tion diffused in the network by these TC MID messages will help each
   node to calculate its routing table. A node which has an empty advertized neighbor set may not generate
   any TC message.  Indeed, when its advertized neighbor set becomes
   empty, it SHOULD still send (empty) TC-messages during TOP_HOLD_TIME
   to invalidate the previous TC-messages. It MAY then stop sending TC-
   messages until some node is inserted in its advertized neighbor set.

   A node MAY transmit additional TC-messages to increase its reactive-
   ness to link failures. I.e. when has only a change to single
   interface address participating in the MPR selector set MANET (i.e. running OLSR),
   MUST NOT generate any MID message.

   A node with more interfaces, where only one is
   detected participating in the
   MANET and this change can be attributed to running OLSR (e.g. a link failure, node is connected to a TC-
   message SHOULD be transmitted after wired network
   as well as to a shorter interval than TC_INTER-
   VAL.

2.3.5.  TC MANET) MUST NOT generate any MID messages.

7.3.4.  MID Message Processing

   TC Forwarding

   MID messages are broadcasted and retransmitted by the MPRs in order
   to diffuse the messages in the entire network.

   In this section, The "default forward-
   ing algorithm" (described in section 3.4.1) MUST be used
   for forwarding of MID messages.

7.3.5.  MID Message Processing

   The tuples in the term "originator" multiple interface association set are recorded
   with the information that is used to designate exchanged through MID messages.

   Upon receiving a MID message, the node "validity time" MUST be computed
   from which the Vtime field of the message originally originated, while header (as described in the term "sender" sec-
   tion 4.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 used to designate set to:

                    I_time = current time + validity time.

          2    Otherwise, a new tuple is recorded in the interface asso-
               ciation 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 from is its "node id" - which for convenience corresponds to the message was received
   (i.e.
   address of one of its interfaces). In a network with only single
   interface nodes, the "last hop" main address of a node will, by definition, be
   equal to the message).

   The tuples in interface address of the topology set are recorded node. In networks with the topology infor-
   mation that multiple
   interface nodes, it is exchanged through TC messages, according required to be able to map any interface
   address to the fol-
   lowing algorithm:

     1    If the sender corresponding main address.

   Section 7.3 provides a way in which interface (NB: not originator) of this message information is not
   acquired by nodes in the symmetric neighborhood network. This permits identification of this node, the message
          is discarded.

     2    A tuple is inserted into the duplicate table to prevent it
          from being processed again with:

               D_addr = originator address

               D_seq_num = Message Sequence

               D_time = current time + D_HOLD_TIME.

     3    If a
   nodes "main address", given one of its interface addresses.

   Given an interface address:

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

               T_last

               I_iface_addr == originator interface address AND

               T_seq > MSSN,

          then no further processing the result of this TC message is performed and the message main address search is silently discarded (case: message received out
          of order).

     4    All tuples in the topology set where:

               T_last == originator
          address AND

               T_seq < MSSN

          are removed from I_main_addr of the topology set.

     5    For each tuple.

     2    Otherwise, the result of the advertized neighbor main address received 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 in
   section 4.4, with the precision that for each interface
   address, the corresponding Main Address for creating the neighbor
   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 set MUST be calculated by a node in such a way that it,
   through the TC message:

          5.1  If there exist some tuple neighbors in the topology set where:

                    T_dest == advertized neighbor main address, AND

                    T_last == originator address,

               then MPR-set, can reach all symmetric strict
   2-hop neighbors.

   For the holding time purpose of that tuple is computing the MPR set to:

                    T_time = current time + TOP_HOLD_TIME.

          5.2  Otherwise, a new tuple is recorded in a node with multiple
   interfaces, the topology set
               where:

                    T_dest = advertized following additional definitions are required:

     neighbor main address,

                    T_last = originator address,

                    T_seq  = MSSN,

                    T_time = current time + TOP_HOLD_TIME.

     6    If the sender address is of an interface address of

               a MPR selec-
          tor of this node and if the time to live of the message is
          greater than '1', the message MUST be forwarded according to
          the following:

          6.1  The TTL a "neighbor of an interface" if the message is reduced by one.

          6.2  The hop-count of interface
               (on the message is increased by local node) has a link to any one

          6.3  The message is broadcasted on all interfaces (Notice: The
               remaining fields interface of
               the message header SHOULD be left
               unmodified.)

2.3.6.  Multiple Interface Association

   Each node in the network maintains neighbor node.

     two-hop neighbors reachable from an interface information about

               the
   other nodes in list of two-hop neighbors of the network. This information acquired node that can be
               reached from MID-mes-
   sages, emitted by nodes with multiple interfaces participating in neighbors of this interface.

     MPR set of an interface

               A (sub)set of the
   MANET, and is used for routing table calculations.

2.3.6.1.  Multiple Interface Association Information Base

   For each destination neighbors of an interface, selected
               such that through these selected nodes, all two-hop
               neighbors reachable from that interface are reachable.

7.6.1.  MPR Computation

   The heuristics, proposed in section 4.6.2, is applied, with the network, "Interface association Tuples"
   (I_if_addr, I_main_addr, I_time) are recorded. I_if_addr
   following changes:

     -    The algorithm is an inter-
   face address of a node, I_main_addr applied per interface I.

     -    N is the main address now defined as "The subset of neighbors of this node.
   I_time specifies the time at which this tuple expires and *MUST* be
   removed.

   In a node, the set
          which are neighbor of Interface association Tuples is denoted the
   "Interface association Set".

2.3.6.2.  MID Message Format

   The proposed format of a MID 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Interface Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Interface Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This interface I".

     -    N2 is sent now defined as the data-portion "The set of two-hop neighbors reachable
          from the general message format interface I, excluding:

          (i)  the nodes only reachable by members of N with willingness
               WILL_NEVER

          (ii) the "Message Type" set to MID_MESSAGE.  The time to live SHOULD be
   set to 255 (maximum value) to diffuse node performing the message into computation

          (iii)
               all the entire
   network.

     Interface Address

          This field contains symmetric neighbors: the address of an interface nodes for which there
               exists a symmetric link to this node on some interface."

   The MPR set of the a node
          other than its main address (already indicated in the origina-
          tor address).  All interface addresses other than is then the main
          address union of the Originator node MPR sets found for
   each interface.

   Note that other algorithms and improvements are put in possible. For exam-
   ple, when the MPRs of the MID message. If first m interfaces have already been iden-
   tified, for each of them which is also neighbor of the maximum allowed message size (as imposed (m+1)th inter-
   face, it is possible to ignore its two-hop neighbors (i.e. it is
   assumed to be chosen as MPR again by the network)
          is reached while there are still (m+1)th interface addresses which
          have not been inserted into 'for
   free').

7.7.  Routing Table Calculation

   A multiple interface compliant implementation MUST complement further
   the MID-message, more MID messages
          are generated until routing table using the entire multiple interface addresses set association set, after
   it has been sent.

2.3.6.3.  MID Message Generation

   In order to build (re)calculated:

     1    For each entry in the multiple interface association information base, each
   node with multiple interfaces broadcast Multiple Interface Declara-
   tion (MID) messages. MID messages are flooded to all nodes in base
          where there exists a routing entry such that:

               R_dest_addr == I_main_addr (of the
   network and take advantage of MPRs.

   A MID message is sent by multiple interface
               interface association entry)
          a node route entry is created in the network to declare its multi-
   ple interfaces (if any). I.e., the MID message contains routing table with:

               R_dest_addr  = I_iface_addr (of the list of multiple interface addresses which are associated to its main address.  The
   list of addresses can be partial in each TC message (e.g. due to mes-
   sage size limitations, imposed
               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 the recorded route
               entry).

   In addition, now, the routing table is updated by recalculating also
   when the network), but parsing of all
   MID messages describing a nodes multiple interface association set has changed.

7.8.  Changes to the "Default Forwarding Algorithm"

   When a node as several interfaces, both the "Forwarding condition" of
   section 3.4 (step 4.1), and the "default forwarding algo-
   rithm" described previously in section 3.4.1 MUST be complete within
   a certain refreshing period (MID_INTERVAL).
   changed.

   The information diffused
   in the network by these MID Forwarding condition of section 3.4 (step 4.1) MUST be
   changed for all messages will help each node to calculate
   its routing table. A node which has only the following:

     4    Forwarding condition:

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

                                D_addr == Originator Address, AND

                                D_seq_num == Message Sequence Number,
                    AND

                                the sender interface address
   participating is in
                    D_interface_list

               then the MANET (i.e. running OLSR) message has already been considered for forward-
               ing and this address is
   its main address, MUST SHOULD NOT generate any MID message.

   A node with more interfaces, where only one is participating be retransmitted again.

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

   Additionality, the
   MANET and running OLSR (e.g. a node is connected "default forwarding algorithm" described previ-
   ously in section 3.4.1 MUST be changed.  This change
   applies to a wired network
   as well as unknown message types, but also to a MANET) MUST NOT generate any MID messages.

2.3.6.4.  MID Message Processing

   MID all known messages
   which are broadcasted and retransmitted by the MPRs in order explicitly documented to diffuse use the messages "default forwarding algo-
   rithm" in the entire network.

   In this section, the term "originator" is used specification.

   First two new fields must be added to designate the node
   from which duplicate set:

     D_retransmitted

          A boolean indicating whether the message originally originated, while has been already
          retransmitted.

     D_interface_list

          A list of the term "sender"
   is used to designate addresses of the node from interfaces on which the message was received
   (i.e. the "last hop" of the message).
          has been received.

   The tuples in the multiple interface association set are recorded
   with the information that default forwarding algorithm is exchanged through MID messages, follow-
   ing the following algorithm: following:

     1    If the sender (NB: not originator) interface address of this the message is not detected
          to be in the symmetric neighborhood of this the node, the forward-
          ing algorithm MUST silently stop here (and the message is dis-
          carded. will
          not be forwarded).

     2    A tuple is inserted into    If an entry exists in the duplicate table to prevent it
          from being processed again set with:

               D_addr = originator address

               D_seq_num = Message Sequence

               D_time = current time + D_HOLD_TIME.

     3    For each of Number

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

               D_retransmitted is false

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

     3    Otherwise, if such an entry doesn't exist, the MID message:

          3.1 message is fur-
          ther considered for forwarding.

   If there exist some tuple in after those steps, the interface association
               set where:

                    I_if_addr == interface address, AND

                    I_main_addr == originator address, message is not considered for forwarding,
   then the holding time processing of that tuple is set to:

                    I_time = current time + MID_HOLD_TIME.

          3.2  Otherwise, a new tuple this section stops (i.e. steps 4 to 7 are
   ignored), otherwise, if it is recorded in still considered for forwarding then
   the interface asso-
               ciation set where:

                    I_if_addr = interface address,

                    I_main_addr = originator address,

                    I_time = current time + MID_HOLD_TIME. following algorithm is used:

     4    If the sender interface address is an interface address of a
          MPR selec-
          tor selector of this node and if the time to live of the message mes-
          sage is greater than '1', the message MUST MUST be retransmitted
          (as described later).

     5    If entry in the duplicate set exists, with same originator
          address, and same message sequence number

          Then it is updated:

               D_time = current time + D_HOLD_TIME.

               The receiving interface address is added to D_inter-
               face_list.

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

          Otherwise an entry in the duplicate set is recorded with:

               D_addr = originator address

               D_seq_num = Message Sequence Number

               D_time = current time + D_HOLD_TIME.

               D_interface_list contains the receiving interface
               address.

               D_retransmitted is set to true if and only if the message
               will be forwarded retransmitted according to step 4.

   If, and only if, according to step 4, the following:

          4.1 message must be retransmit-
   ted then the following steps are followed:

     5    The TTL of the message is reduced by one.

          4.2

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

          4.3

     7    The message is broadcasted on all interfaces (Notice: The
          remaining fields of the message header SHOULD be left
               unmodified.)

2.3.7.  Associated Networks and Hosts unmodi-
          fied.)

8.  Non OLSR Interfaces

   A node MAY provide access to a set of associated hosts. I.e., a node
   may act as a "gateway" between the MANET and a number be equipped with multiple interfaces, some of associated
   hosts and/or subnets, not running OLSR and thus which do not participating
   participate in the MANET. Thus, OLSR manet. These non-OLSR interfaces may be point
   to point connections to other singular hosts or may connect to sepa-
   rate networks.

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

   Injecting routing information
   describing these associated hosts from the OLSR 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 can be
   extracted from the topology table (see section 5.2) or networks into MANET, as SHOULD
   all nodes directly
   from the routing table of OLSR, and must be capable injected onto the non-
   OLSR interfaces following whatever mechanism (routing protocol,
   static configuration etc.) is provided on these interfaces.

   An example of interpreting such information. 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", described previously. Where, in the "Multiple Interface Asso-
   ciations", where all the described interfaces were are participating in the MANET
   through running the OLSR protocol, this section addresses the protocol. Multiple interfaces which do not participate. This is, e.g., the case where a
   node has both a wireless interface (participating participating
   in the MANET) and a
   wired interface, through which a number of hosts statically connect
   (to the nodes OLSR manet is described in the MANET).

   To accomplish this, section 7.

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

2.3.7.1.

8.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 and HNA_MESSAGE, the TTL field set to 255. 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
   HNA- and TC messages 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 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 cancelling effect on previous information (if the
   MSSN is incremented), whereas information in HNA-messages is removed
   only upon expiration.

     Network Address

          The network address of the associated network

     Netmask

          The netmask, corresponding to the network address immediately
          above.

2.3.7.2.

8.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" (GW_main_addr, NET_addr, NET_mask, GS_time), (A_gateway_addr, A_network_addr, A_netmask, A_time), where
   GW_main_addr
   A_gateway_addr is the main address of a OLSR interface of the gateway, NET_addr
   A_network_addr and
   NET_mask A_netmask specifies the network address and netmask net-
   mask of a network, reachable through this gateway, and GS_time specifies A_time speci-
   fies 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".

2.3.7.3.

8.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.

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

2.3.7.4.

8.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.  HNA Message Processing

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

   Upon receiving processing a HNA-message, the node performs "validity time" MUST be computed
   from the following:

     1    An entry in Vtime field of the duplicate set is recorded for this message
          with:

               D_addr = originator address

               D_seq_num = Message Sequence Number

               D_time = current time + D_HOLD_TIME.

     2 header (see section 3.3.2).
   The association base SHOULD then be updated as follows:

     1    For each (network address, netmask) pair in the message:

          2.1

          1.1  if an entry in the association set already exists, where:

                    GW_main_addr

                    A_gateway_addr == originator address

                    NET_addr

                    A_network_addr == network address

                    NET_mask

                    A_netmask      == netmask

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

                    GW_time

                    A_time = current time + GW_HOLDING_TIME

          2.2 validity time

          1.2  otherwise, a new tuple is MUST be recorded with:

                    GW_main_addr  ==

                    A_gateway_addr = originator address

                    NET_addr == network address

                    NET_mask == netmask

                    GW_time

                    A_network_addr = current time + GW_HOLDING_TIME

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

          3.1  The TTL of the message is reduced by one.

          3.2  The hop-count of the message is increased by one
          3.3  The message is broadcasted on all interfaces (Notice: The
               remaining fields of the message header SHOULD be left
               unmodified.)

2.3.8. network address

                    A_netmask      = netmask

                    A_time         = current time + validity time

8.6.  Routing Table Calculation

   Each node maintains a routing table which allows it

   In addition to route data,
   destined for the other nodes in the network. The routing table is
   based on the information contained computation as described in the neighbor sensing informa-
   tion base, the interface association set, the topology set and section
   5.7, the host and network association set. Therefore, if any of these tables
   are changed, the routing table is re-calculated to update the route
   information about set MUST be added as
   follows:

     1    For each destination tuple in the network. The route entries
   are recorded routing set, an entry in the routing
          table in MUST be recorded, with:

               R_dest_addr     = A_network_addr/A_netmask

               R_next_addr     = the following format:

         1.  R_dest    R_next    R_dist   R_if_id
         2.  R_dest    R_next    R_dist   R_if_id
         3.    ,,        ,,        ,,

   Each entry in next hop on the table consists of R_dest, R_next, R_dist, and
   R_if_id which specifies that path from the node identified by R_dest is esti-
   mated
               to be A_gateway_addr

               R_dist hops away from the local node,     = dist to A_gateway_addr

               R_next_addr and that R_iface_addr MUST be set to the sym-
   metric neighbor node same val-
               ues as the tuple from the routing set with interface address R_next R_dest_addr ==
               A_gateway_addr.

9.  Link Layer Notification

   OLSR is designed not to impose or expect any specific information
   from the next hop link layer. However, if information from the link-layer 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 route information from the HELLO-messages to R_dest, maintain the neighbor
   information base and this one hop the MPR selector set.

   Thus, upon receiving a link-layer notification that the link between
   a node and a neighbor interface is reachable through broken, the local interface
    R_if_id.  Entries following actions are recorded
   taken with respect to link sensing:

   Each link tuple in the table for each destination local link set SHOULD, in
   the network for which the route is known. All the destinations for
   which the route addition to what is broken or partially known are not entered
   described in the
   table.

   This routing table section 4.1, include a L_LOST_LINK_time field.
   L_LOST_LINK_time is updated a timer for declaring a link as lost when an
   established link becomes pending. (Notice, that this is a change subset of
   what is detected reccomended in section 10.3, 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 neigh-
   bor information base, the interface association set or the topology
   set. More precisely, it link is re-calculated in case advertised
          with a link type of LOST_LINK and neighbor appear-
   ance or loss, or when type NOT_NEIGH ;

     1    if the link to a topology neighboring symmetric or asymmetric interface
          is broken, the corresponding link tuple is created or removed.  The
   update of this routing information does not generate or trigger any
   messages modified:
          L_LOST_LINK_time and L_time are set to be transmitted, neither in current time +
          NEIGHB_HOLD_TIME.

     2    this is considered as a link loss and the network, nor appropriate process-
          ing described in the one-
   hop neighborhood. section 4.8 should be performed.

10.  Link Hysteresis

   Established links should be as reliable as possible to avoid data
   packet loss. To construct enhance the routing table reliability of node X, the link sensing mecha-
   nism, the following implementation recommendations should be consid-
   ered.

10.1.  Local Link Set

   Each link tuple in the local link set SHOULD, in addition to what is
   described in section 4.1, include a shortest path algorithm L_link_pending field, a
   L_link_quality field, and a L_LOST_LINK_time field.  L_link_pending
   is run on a boolean value specifying if the directed graph containing link is considered pending (i.e.
   the arcs X -> Y where Y link is
   any symmetric neighbor of X (with Link Type SYM_LINK or MPR_LINK) not considered established). L_link_quality is a dimen-
   sionless number between 0 and 1 describing the arcs U -> V where there exists an entry in quality of the topology set with
   V as T_dest and U as T_last.

   The following procedure link.
   L_LOST_LINK_time is given a timer for declaring a link as lost when an example to calculate (or re-
   calculate) the routing table :
   established link becomes pending.

10.2.  Hello Message Generation

   HELLO message generation should consider those new fields as follows:

     1    All the entries from    if L_LOST_LINK_time is not expired, the routing table are removed.

     2    The new routing entries are added starting link is advertised
          with a link type of LOST_LINK and neighbor type NOT_NEIGH ;

     2    otherwise, if L_LOST_LINK_time is expired and L_link_pending
          is set to "true", the symmetric
          neighbors (h=1) as 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 destination nodes. I.e. link is advertised as described previ-
          ously in section 4.

   A node considers that it has a symmetric link for each neigh-
          bor link tuple in the neighbor set where:

               N_LOST_time < current time
   where

     1    L_LOST_LINK_time is expired, AND

               N_pending   == false

     2    L_link_pending is "false", AND

               N_SYM_time  >= current time

          (there

     3    L_SYM_time is a symmetric link to not expired.

   This should be taken as definition for computing the neighbor), a new routing
          entry is recorded in symmetric neigh-
   borhood when computing the routing table with:

               R_dest  =  N_main_addr of MPR set. This should also be taken as the neighbor;

               R_next  = N_if_addr
   definition of "the symmetric neighbors" in the neighbor interface;

               R_dist  = 1;

               R_if_id = N_if_id first steps of the entry.

          If N_if_addr is distinct from N_main_addr, another new
   routing
          entry with is added, with:

               R_dest  = N_main_addr;

               R_next  = N_if_addr;

               R_dist = 1;

               R_if_id = N_if_id.

     3    The new route entries for table calculation.

   Apart from the destination nodes h+1 hops away
          are recorded above points, what has been described previously does
   not interfere with these advanced link sensing fields in the routing table. link
   tuples. The following procedure is
          executed for each value of h, starting with h=1 L_link_quality, L_link_pending and increment-
          ing it by 1 each time. The execution will stop if no new entry
          is recorded in an iteration.

          3.1  For each topology entry in L_LOST_LINK_time
   fields are exclusively updated according to the topology table, if its
               T_dest present section. This
   section does not correspond to R_dest modify the function of any route entry other fields in the routing table AND link
   tuples.

10.3.  Hysteresis Strategy

   The link between a node and some of its T_last corresponds neighbor interfaces might be
   "bad", i.e. from time to time let HELLOs pass through only to R_dest 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 route entry whose R_dist bad link might affect routing badly.
   To cope with such unstable links, the following hysteresis strategy
   SHOULD be adopted.

   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 equal compared to h, then a new
               route entry 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 recorded in set according to the routing table (if it does
               not already exist) where:

                    R_dest following:

     1    if L_link_quality > HYST_THRESHOLD_HIGH:

               L_link_pending = T_dest;

                    R_next false

               L_LOST_LINK_time = R_next of the recorded route entry whose
                    R_dest == T_last

                    R_dist current time - 1 (expired)

     2    otherwise, if L_link_quality < HYST_THRESHOLD_LOW:

               L_link_pending = h+1; and

                    R_if_id true

               L_LOST_LINK_time = R_if_id of the recorded route entry whose
                    R_dest == T_last.

          3.2  Several topology entries may be used min (L_time, current time +
               NEIGHB_HOLD_TIME)

               (the link is then considered as lost according to select section
               4.8 and this may produce a next hop
               R_next for reaching the node R_dest.  When h=1, ties
               should be broken such that nodes with highest willingness neighbor loss).

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

               L_link_pending and MPR selectors are preferred as next hop. L_LOST_LINK_time remain unchanged.

   The routing table condition for considering a link established is further completed by using the multiple inter-
   face association set:

     1    For each entry in thus stricter
   than the multiple interface association base condition for
          which there exists loosing it.

   As a routing entry such that:

               R_dest == I_main_addr (of basic implementation requirement, an estimation of the multiple interface inter-
               face association entry)

          a route entry is created link
   quality must be maintained and stored in the routing table with:

               R_dest  = I_if_addr (of L_link_quality field. If
   some measure of the multiple interface associa-
               tion entry)

               R_next  = R_next (of 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 is available from the recorded route entry)

               R_dist  = R_dist (of link layer, an
   algorithm such as the recorded route entry)

               R_if_id = R_if_id (of following can be utilized (it is an exponen-
   tially smoothed moving average of the recorded route entry). transmission success rate).
   The routing table algorithm is finally completed parameterized by using the host a scaling parameter HYST_SCALING
   which is a number fixed between 0 and network
   association set:

     1 1. For each tuple in neighbor interface
   NI heard by interface I, the host first time NI is heard by I,
   L_link_quality is set to HYST_SCALING (L_link_pending is set to true
   and network association set, record L_LOST_LINK_time to current time - 1).

   A tuple is updated according to two rules.  Every time an entry in OLSR packet
   emitted by NI is received by I, the routing table, with:

               R_dest stability rule is applied:

          L_link_quality = NET_addr/NET_mask

               R_next (1-HYST_SCALING)*L_link_quality + HYST_SCAL-
          ING.

     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 next hop missing Packet
   Sequence Numbers on the path from the node to
               GW_main_addr

               R_dist     = dist to GW_main_addr

               R_next a per interface basis and R_if_id are set to the same values as the
               tuple by long period of
   silence.  If no OLSR packet has been received on interface I from the routing set with R_dest == GW_main_addr.

2.3.9.  Advanced Topology Discovery Functioning

   Due to mobility, some links
   interface NI during hello emission interval of interface NI (computed
   from the broadcasted topology may fail.
   Additional messages may be sent to recover quickly. Ideally the load
   of control messages should increase smoothly with mobility. This sec-
   tion describes how this may be achieved Htime field in OLSR.

2.3.9.1.  Reaction to Link Failure with a MPR Selector

   Detection of a link failure between the last hello message received from NI), a node and one
   loss of its MPR selec-
   tors through a link-layer notification may trigger additional TC-mes-
   sages an OLSR packet is detected.

11.  Distributing Redundant Topology Information

   In order to increase the protocol reactiveness provide redundancy to link failures. I.e.
   when topology information base, the
   advertised link set of a change node can contain links to the neighbor nodes
   which are not in MPR selector set is detected and of the node. The advertised link
   set can be the whole neighbor set of the node. In this change case the nodes
   receiving the TC message will get the knowledge of all the adjacent
   links of the sender node. The advertised link set can be attributed built
   according to the following rule based on a link failure, an additional TC-message MAY be
   transmitted.

   More precisely, local parameter called
   TC_REDUNDANCY parameter.

11.1.  TC_REDUNDANCY Parameter

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

     -    if a the TC_REDUNDANCY parameter of the node is 0, then its
          advertised link failure appears set is limited to be a neighbor loss with
   a neighbor, which has selected this node as MPR, the MPR selector set (as
          described in section 4.6.2),

     -    if the TC_REDUNDANCY parameter of the node is updated (MSSN 1, then its
          advertised set is thus incremented) the union of its MPR set and a TC message MAY be gener-
   ated.  Moreover its MPR selec-
          tor set,

     -    if it appears that data traffic was flowing through
   this link, a TC message SHOULD be generated. Notice, that a node may
   be aware of data traffic flowing to the lost neighbor in case TC_REDUNDANCY parameter of a
   link layer notification coming from a missing acknowledgement or when
   statistics about packet forwarding are given by the IP stack.

2.3.9.2.  Advanced Fast Re-routing Mechanism

   When a link breaks, information stored in the node is 2, then its
          advertised set is neighbor sensing infor-
   mation base may be used set (full link-state information is
          diffused).

   A node with willingness equal to zero SHOULD have TC_REDUNDANCY also
   equal to compute an alternative route immediately
   if necessary.

   If there exists a N_2hop_address listed in zero.

12.  MPR Redundancy

   MPR redundancy specifies the 2-hop neighbor set,
   and ability for which no route exists, a route entry is created node to select redundant
   MPRs. Section 4.5 specifies that a node should select its MPR set to
   be as small as possible, in the rout-
   ing table with:

          R_dest  = N_2hop_address

          R_next  = R_next of the recorded route entry whose R_dest is
          equal order to N_main_addr reduce protocol overhead. The
   criteria for selecting MPRs being, that all strict 2-hop nodes must
   be reachable through, at least, one MPR node. Redundancy of the corresponding 2-hop tuple

          R_dist  = 2

          R_if_id = R_if_id MPR
   set affects the overhead through affecting the amount of links being
   advertised, the recorded route entry whose R_dest is
          equal amount of nodes advertising links to N_main_addr the MPR selector
   and the efficiency of the corresponding 2-hop tuple.

   If an entry MPR flooding mechanism. On the other hand,
   redundancy in the multiple interface association base records MPR set ensures that reachability for a main
   address I_main_addr reporting an interface I_if_addr =
   N_2hop_address, then R_dest node is set to I_main_addr instead of
   N_2hop_address.

   If the two hop neighbor allows to reach other nodes at distance
   greater than 2 according
   advertised by more nodes, thus additional links are diffused to the topology
   network.

   While, in general, a minimal MPR set then provides the least overhead,
   there are situations in which overhead can be traded off for other entries
   benefits. E.g. a node can may
   be added decide to increase its MPR coverage if
   it observes many changes in the routing table with same R_next for these nodes. its neighbor information base caused by
   mobility, while otherwise keeping a low MPR coverage.

12.1.  MPR_COVERAGE Parameter

   The routing table MPR coverage is finally completed using 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 multiple interface
   association set protocol
   is kept at a minimum and causes the host and network association set MPR selection to operate as
   described in section 4.6.3. MPR_COVERAGE=m ensures that, if
   possible, a node selects its MPR set such that all strict 2-hop nodes
   are reachable through at least m MPR nodes.

   Notice that MPR_COVERAGE can be tuned locally without affecting the routing table calculation section.

   To allow other
   consistency of the protocol. I.e. nodes to benefit from in a network may operate with
   different values of MPR_COVERAGE.

12.2.  MPR Computation

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

     Poorly covered node:
          A poorly covered node
   MAY trigger is a fast re-routing event node in N2 which is covered by generating a FRR message.

2.3.9.2.1.  FRR Message Format less
          than MPR_COVERAGE nodes in N.

   The proposed format of a FRR message heuristic for selecting MPRs 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 then as follows:

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

     2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Next Hop Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Two Hop Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Two Hop Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This    Calculate D(y), where y is sent 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 data-portion reachability, i.e. the
               number of nodes in N2 which are not yet covered by at
               least MPR_COVERAGE nodes in the general message format MPR set, and which are
               reachable through this one hop neighbor;

          4.2  Select as a MPR the node with highest willingness among
               the "Message Type" set to FRR_MESSAGE.  The time to live SHOULD be
   set nodes in N with non-zero reachability. In case of
               multiple choice select the node which provides reachabil-
               ity to 1, ensuring that the message is only received by one-hop
   neighbors.

     Next Hop Address

          This field contains maximum number of nodes in N2.  In case of
               multiple nodes providing the main address same amount of a reachability,
               select the node which is used as next hop by the Originator for reaching all MPR whose D(y) is greater. Remove the
               nodes iden-
          tified from N2 which are now covered by MPR_COVERAGE nodes
               in the Two Hop Address fields.

     Two Hop Address

          This field contain MPR set.

     5    As an optimization, process each node y in the main address of a 2-hop neighbor MPR set in the
          increasing order of their willingness.  If all nodes in N2 are
          still covered by at least MPR_COVERAGE nodes in the
          Originator MPR set
          excluding y and willingness of node y is smaller than
          WILL_ALWAYS, then node y is removed from the message.

2.3.9.2.2.  FRR Message Generation MPR set.

   When the fast re-routing mechanism allows MPR set has been computed, all the corresponding main
   addresses are stored in the MPR Set.

   Notice, that for MPR_COVERAGE=1, this heuristics is identical to the
   heuristics specified in the section 4.6.3.

13.  IPv6 Considerations

   All the operations and parameters described in this document used by
   OLSR for IP version 4 are the same as those used by OLSR for IP ver-
   sion 6.  However, to reach 2-hop neighbors
   through a neighbor which operate with IP version 6, the only required
   change is to replace the IPv4 addresses with IPv6 address.

14.  Security Considerations

   Currently, OLSR does not recorded specify any security measures. However as MPR of them a
   proactive routing protocol, it makes a target for various attacks.
   The various possible vulnerability are discussed in the topol-
   ogy set, the node MAY inform this next hop by generating section.

14.1.  Confidentiality

   Being a FRR Mes-
   sage with Next Hop Address containing proactive protocol, OLSR periodically diffuses topological
   information. Hence, if used in an unprotected wireless network, the main address
   network topology is revealed to anyone who listens to OLSR control
   messages.

   In situations where the confidentiality of this next
   hop and listing the main addresses network topology is of these 2-hop neighbors.

   If some information allows
   importance, regular cryptographic techniques can be applied to deduce ensure
   that some data control traffic flows
   through the node can be read and interpreted 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 of these 2-hop neighbors, nodes, TC mes-
   sages. If some nodes for some reason, malicious or malfunction,
   injects invalid control traffic, network integrity may be compro-
   mised.

   Different such situations may occur:

     1    a FRR Message
   SHOULD be generated. This can node generates TC (or HNA) messages, advertising links to
          non-neighbor nodes:

     2    a node generates TC (or HNA) messages, pretending to be the case if such
          another node,

     3    a 2-hop neighbor
   was previously node generate HELLO messages, advertising non-neighbor
          nodes,

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

     5    a link layer notification of node forwards altered control messages,

     6    a missing
   acknowledgment has been received or statistics about packet forward-
   ing are provided by the IP stack. Otherwise, an FFR-message MAY be
   generated.

2.3.9.2.3.  FRR Message Processing

   Upon reception of node does not broadcast control messages,

     7    a FRR message node does not select multipoint relays correctly.

     8    a node performs the following:

     1    If the Next Hop Address field is 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 main address of the
          node, the message is dropped.

     2    For each Two Hop Address listed individual links announced in the FRR Message for which
          there exists a neighbor tuple with N_main_addr = the Two Hop
          Address control messages (for
   situation 1 and for which there exists no tuple in the MPR selec-
          tor set with MS_main_addr = the Two Hop Address, 3) may be used as a new tuple countermeasure. However to pre-
   vent nodes from repeating old (and correctly authenticated) informa-
   tion temporal information is inserted with:

               MS_main_addr = the Two Hop Address
               MS_if_addr = N_if_addr of the corresponding neighbor
               tuple

               MS_time = current time + 2HOP_HOLD_TIME.

If the MPR set has changed and required, allowing a TC message containing the new MPR
selector set SHOULD be generated.

3.  Node Configuration

3.1.  Address Assignment

   The nodes in the MANET network SHOULD node to positively
   identify such delayed messages.

   Signatures and other required security information may be assigned addresses within transmitted
   as a
   defined address sequence. I.e., the separate OLSR message type, thereby allowing that "secured" and
   "unsecured" nodes can coexist in the MANET SHOULD be
   addressable same network, if desired.

14.3.  Interaction with External Routing Domains

   OLSR does, through a network address and a netmask.

   Likewise, the nodes HNA messages specified in each associated network SHOULD be assigned
   addresses from section 8,
   provide a defined address sequence, distinct from that being
   used in basic mechanism for injecting external routing information
   to the MANET.

3.2.  Routing Configuration

   Any MANET node with associated networks or hosts SHOULD
    be configured such OLSR domain. Section 8 also specifies that it has routes set up to routing
   information can be extracted from the interfaces with
   associated hosts or network.

3.3.  Data Packet Forwarding topology table of OLSR itself does not perform packet forwarding. Rather, it maintains and,
   potentially, injected into an external domain if the routing table protocol
   governing that domain permits.

   Other than as described in the underlying section 14.2, when operating system, which is
   assumed
   nodes, connecting OLSR to an external routing domain, care MUST be forwarding packets as specified in RFC1812.

4.  IPv6 Considerations

   All the operations
   taken not to allow potentially insecure and parameters described in this document used by
   OLSR for IP version 4 are the same as those used by OLSR for IP ver-
   sion 6.  However, un-trustworthy informa-
   tion to operate with IP version 6, be injected from the only required
   change is OLSR domain to replace external routing domains.
   I.e. a node MUST NOT take raw and invalidated information from the IPv4 addresses with Ipv6 address.

5.  Security Considerations

   Currently,
   OLSR does not specify topology tables and inject into any security measures. However as a
   proactive external routing protocol, domain.
   Care MUST be taken to validate the correctness of information prior
   to it makes a target for various attacks.
   The various possible vulnerability are discussed in this section.

5.1.  Confidentiality

   Being a proactive protocol, OLSR periodically diffuses topological being injected as to avoid polluting routing tables with
   invalid information. Hence, if used in

   A recommended way of extending connectivity from an unprotected wireless network, the
   network topology is revealed to anyone who listens existing routing
   domain to an OLSR control
   messages.

   In situations where routed manet is to assign an IP sequence (under the confidentiality
   authority of the network topology is of
   importance, regular cryptographic techniques can be applied nodes/gateways connecting the manet with the exiting
   routing domain) exclusively to ensure
   that control traffic can be read the OLSR manet, and interpreted by only those autho-
   rized to do so.

5.2.  Integrity

   In OLSR, each node configure the
   gateways statically to advertise routes to that IP sequence to nodes
   in the existing routing domain.

15.  Proposed Values for Constants

   This section list the values for the constants used in the descrip-
   tion of the protocol.

15.1.  Setting emission intervals and holding times

   The proposed constant for C is injecting topological information into the net-
   work through transmitting HELLO messages and, following:

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

   C is a scaling factor for some nodes, TC mes-
   sages. If some the "validity time" calculation ("Vtime"
   and "Htime" fields in message headers, see section 15.3).
   The "validity time" advertisement is designed such that nodes for some reason, malicious or malfunction,
   injects invalid control traffic, in a
   network integrity may be compro-
   mised.

   Different such situations may occur:

     1    a node generates TC messages, adverticing links to non-neigh-
          bor nodes:

     2    a node generates TC messages, pretending 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 another node,

     3    a node generate HELLO messages, adverticing non-neighbor
          nodes,

     4    a node generate HELLO messages, pretending greater than the
          refresh interval of the advertised information. Moreover, it
          is recommended that the relation between the interval (from
          section 15.2), and the hold time is kept as specified
          in section 15.3, to allow for reasonable packet loss.

     -    the constant C SHOULD be set to the suggested value. In order
          to achieve interoperability, C MUST be another node.

     5 the same on all nodes.

     -    the emission intervals (section 15.2), along with the
          advertised holding times (subject to the above constraints)
          MAY be selected on a per node forwards broadcast control messages unaltered, but does
          not forward unicast data traffic

   Authenticated signatures on control messages (for situation 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

   The Vtime in the message header (see section 3.3.2), and 4)
   and on the individual links announced
   Htime in the control messages (for
   situation 1 HELLO message (see section 4.2) are the
   fields which hold information about the above values in mantissa and 3) may be used as
   exponent format (rounded up). In other words:
     value = C*(1+a/16)*2^b

   where a countermeasure. However to pre-
   vent nodes from repeating old (and correctly authenticated) informa-
   tion temporal information is required, allowing a node the integer represented by the four highest bits of the
   field and b the integer represented by the four lowest bits of the
   field.

   Given one of the above holding times, one way to positively
   identify compute the man-
   tissa/exponent representation of a number T (of seconds) is the fol-
   lowing:

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

   Signatures and other required security information as: 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 round it up.  The result gives 'a'

     -     'a' and 'b' should now be integers between 0 and 15, and
   "unsecured" nodes can coexist in the same network, if desired.

6.  Proposed Values for the Constants

   This section list the values for the constants used in
          field will be a byte holding the descrip-
   tion value a*16+b
   For instance, for values of the protocol.

          HELLO_INTERVAL        = 2 seconds

          REFRESH_INTERVAL      = 2 seconds

          TC_INTERVAL           = 5 seconds

          MID_INTERVAL          = TC_INTERVAL

          HNA_INTERVAL          = TC_INTERVAL

          NEIGHB_HOLD_TIME      = 3 x HELLO_INTERVAL

          2HOP_HOLD_TIME        = 3 x REFRESH_INTERVAL

          TOP_HOLD_TIME         = 3 x TC_INTERVAL

          D_TIME                = 6 seconds, 15 seconds, and 30 seconds

          I_TIME                = 3 x MID_INTERVAL

          GW_TIME               = 3 x HNA_INTERVAL
   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
          FRR_MESSAGE

15.5.  Link Types

          UNSPEC_LINK           = 5 0

          ASYM_LINK             = 1

          SYM_LINK              = 2

          MPR_LINK

          LOST_LINK             = 3

          LOST_LINK

15.6.  Neighbor Types

          NOT_NEIGH             = 4 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              = 1

          WILL_DEFAULT          = 3

          WILL_HIGH             = 6

          WILL_ALWAYS           = 7

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

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

   One possible application would, for example, be for a node, connected
   to a permanent power supply and with fully charged batteries, to
   advertise a willingness of WILL_ALWAYS. Upon being disconnected from
   the permanent power supply (e.g. a PDA being taken out of its charg-
   ing cradle), a willingness of WILL_DEFAULT is advertised. As battery
   capacity is drained, the willingness would be further reduced. First
   to the intermediate value between WILL_DEFAULT and WILL_LOW, then to
   WILL_LOW and finallt to WILL_NEVER, when the battery capacity of the
   node does no longer support carrying forigen traffic.

15.9.  Misc. Constants

          TC_REDUNDANCY         = 0

          MPR COVERAGE          = 1

          MAXJITTER             = HELLO_INTERVAL / 4

7.

16.  Sequence Numbers

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

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

   The sequence number S1 is said to be "greater than" the sequence 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 pres-
   ence of wrap-around - to determine which message contains the most
   recent information.

8.

17.  Acknowledgments

   The authors would like to thank Joseph Macker and his team
   <macker@itd.nrl.navy.mil> for their valuable suggestions on the
   advanced neighbor sensing mechanism.

   The authors would also like to thank Christopher Dearlove
   <chris.dearlove@baesystems.com> for valueable valuable input on the MPR selec-
   tion heuristics.

9.

18.  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 Avenue Islamabad, Pakistan
   Phone: +92-51-2826160 Email: qayyum@avaznet.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

10.

19.  References

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

2. A. Qayyum, L. Viennot, A. Laouiti.  Multipoint relaying: An efficient
     technique for flooding in mobile wireless networks.  35th Annual
     Hawaii International Conference on System Sciences (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 and
     Simulation. IEEE Symposium on "Wireless Personal Mobile Communica-
     tions", september 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.