INTERNET-DRAFT                                          Philippe Jacquet
IETF MANET Working Group                                Paul Muhlethaler
Expiration: 24 May 02 September 2001                                Amir Qayyum
							    Anis Laouiti
							 Laurent Viennot
							  Thomas Clausen
                                              INRIA Rocquencourt, France
                                                        24 November 2000
                                                            2 March 2001

		Optimized Link State Routing Protocol
                    draft-ietf-manet-olsr-03.txt
                    draft-ietf-manet-olsr-04.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026 except that the right to
   produce derivative works is not granted.

   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 pure 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 packets messages during the
   flooding process. This technique substantially reduces the packet message
   overhead as compared to pure flooding mechanism where every node
   retransmits
   the packet each message when it receives the first copy of the
   packet. In OLSR
   protocol, the OLSR, information flooded in the network "through"
   these
   multipoint relays MPRs is also "about" the multipoint relays. MPRs. Thus a
   second optimization is achieved by minimizing the "contents" of
   the control packets messages flooded in the network. Hence, as contrary to
   the classic link state algorithm, only a small subset of links
   with the neighbor nodes are declared instead of all the
   links. This information is then used by the OLSR protocol for
   route calculation. As a consequence hereof, the routes contain
   only the MPRs as intermediate nodes from a Source to a
   Destination. OLSR provides optimal routes (in terms of number of
   hops). The protocol is particularly suitable for large and dense
   networks as the technique of multipoint relays MPRs works well in this context.

			   Contents

Status of This Memo                                             1
Abstract                                                        1
 1. Introduction                                                3
 2. Changes							3
 3. OLSR terminology						4
 4. Applicability Section					5
     4.1 Networking Context					5
     4.2 Protocol Characteristics and Mechanisms		5		6
 5. Protocol Overview						7						8
 6. Multipoint relays						9
 7. Protocol functioning				       10
     7.1 Protocol and port number			       10
     7.2 Packet format					       10
          7.1.1
          7.2.1 Packet Header				       11
	  7.1.2				       12
	  7.2.2 Message Header				       12
	  7.1.3
	  7.2.3 Packet Processing			       12
     7.2			       13
     7.3 Neighbor sensing				       13
          7.2.1				       15
          7.3.1 Neighbor sensing information base	       15
          7.3.2 HELLO message broadcast			       13
	  7.2.2			       16
	  7.3.3 HELLO message processing		       16
     7.3		       19
     7.4 Multipoint relay selection			       19
     7.4			       21
     7.5 Multipoint relay information declaration	       20
          7.4.1	       22
          7.5.1 Topology information base		       22
          7.5.2 TC message broadcast			       20
	  7.4.2			       23
	  7.5.3 TC message processing			       23
     7.5			       24
     7.6 Routing table calculation			       25
     7.6.Link			       26
     7.7.Link layer notification			       27
 8. Packet Forwarding					       27					       28
     8.1 Data packet forwarding				       27				       28
     8.2 OLSR Control message forwarding			       28
 9. Proposed values for constants			       28			       29
10. References Sequence numbers					       29
11. References						       30
12. Authors' addresses					       30					       31

1. Introduction

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

   This protocol is developed for mobile ad hoc networks. It operates
   as a table driven or and proactive protocol and exchanges topology
   information with other nodes of the network at regular intervals.
   The nodes which are selected as a multipoint relay by some
   neighbor nodes announce this information periodically in their
   control messages. The protocol uses the multipoint relays MPRs to facilitate
   efficient flooding of control messages in the network. In route
   calculation, the multipoint relays MPRs are used to form the route from a given node
   to any destination in the network.

   Multipoint relays

   MPRs are selected by a node among its one hop neighbors with
   "symmetric", i.e. bi-directional, link. Therefore, selecting the
   route through multipoint relays MPRs automatically avoids the problems associated
   with data packet transfer on uni-directional links (such as the
   problem of not getting the link-layer acknowledgement acknowledgments for the data
   packets at each hop)

   The OLSR protocol is developed to work independently from other
   protocols. But it can be adapted to operate with a protocol (like
   IMEP [4]) which could provide common functionalities such as
   neighbor sensing, multipoint relaying, security authentication,
   etc.

2. Changes

   Major changes from version 03 to version 04

   - Finalized the generic packet/message format to
     include features for scope-limited (diameter-bound)
     flooding of messages and 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 OLSR.

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

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

   Major changes from version 01 to version 02

   -  Introduction of a unified packet format for encapsulation of
      all messages being exchanged between nodes. This also serves
      to facilitate extensions in future versions of the protocol
      (i.e. introduction of new protocol messages) without breaking
      backwards compatibility.

   -  Removal of "Power Conservation" from this draft. Power
      Conservation may be considered as an extension to the basic
      routing capabilities, and the information is therefore moved
      to draft-ietf-manet-olsr-extensions-00.txt.

3. OLSR Terminology

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECCOMENDED", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC2119 [9].
   The OLSR protocol uses the following terminology, in addition to
   the terms defined in [5].

   connection

      A communication channel or medium *on the same physical
      interface*, over which the nodes can communicate with each
      other.

   holding time

      The lifetime associated with an entry in any table. An entry is
      kept in the table for a period of time, equal to its holding
      time. If the entry is not refreshed during this period, it is
      removed from the table when the holding time expires.

   multipoint relay (MPR)

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

   multipoint relay selector (MPR-S) (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.

   node

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

   symmetric link

      A bi-directional *link* (not connection) between two neighbor nodes, i.e. node X
      and node Y where both can hear each other. This bi-directional link can be a union of two
      oppositely-directed uni-directional connections using different
      interfaces.

4. Applicability Section

   This section dictates the characteristics of the OLSR protocol as
   specified in the Applicability Statement draft [6].

4.1. Networking Context

   The protocol

   OLSR is best well suited to large and dense mobile networks, as the
   optimization
   optimi- zation achieved using the multipoint relays MPRs works well in this
   context. The larger and more dense a network, the more
   optimization can be achieved as compared to the normal link state
   algorithm. OLSR uses hop-by-hop routing, i.e. each node uses its
   most recent
   local information to route packets. Thus when a node is
   moving, its speed should be such that its movement could be
   followed in *at least* its neighborhood, in order to correctly
   route packets to the destination.

   This protocol

   OLSR is best well suited for networks networks, where the traffic is random and
   sporadic between "several" nodes rather than being almost
   exclusively between a small specific set of nodes in the
   network. nodes. The performance
   of the protocol when comparing protocol, compared to a reactive protocol protocol, is even better
   if these [source, destination] pairs change with time [8]. Such
   changes may initiate substantial traffic (Query flooding) in case
   of reactive protocol, but nothing in OLSR, as the routes are
   maintained for each known destination all the time.

4.2. Protocol Characteristics and Mechanisms

   * Does the protocol provide shortest path routes ?

      Yes.

   * Does the protocol provide support for unidirectional links? (if
     so, how?)

      No. It uses only bi-directional links (like in 802.11), but
      these However, the use of uni-directional links may easily be composed of oppositely directed
      uni-directional "connections".
      enabled through optional extensions to the protocol.

   * Does the protocol require the use of tunneling? (if so, how?)

      No.

   * Does the protocol require using some form of source routing? (if
     so, how?)

      No. The protocol uses hop-by-hop routing.

   * Does the protocol require the use of periodic messaging? (if so,
     how?)

      Yes. Periodically, each node in the network sends a message
      containing the addresses of the neighbors which have selected
      that node as a multipoint relay. MPR. This information enables other nodes to
      build routes to that node through the multipoint
      relays. MPRs.

   * Does the protocol require the use of reliable or sequenced packet
     delivery? (if so, how?)

      No. As

   * Does the packets are sent periodically, they need not be sent
      reliably. Each packet not only contains a unique Packet Sequence
      Number, but it also contains the sequence number for the most
      recent information (for example "MPR Sequence Number" in the TC
      packet), so un-sequenced delivery of packets will also not
      create any problem.

   * Does the protocol provide support for routing through protocol provide support for routing through a multi-
     technology routing fabric? (if so, how?)

      Yes. Each network interface is assigned a unique IP address.

     No. However, provisions for multiple interfaces may easily be
     enabled through extensions to the protocol.

   * Does the protocol provide support for multiple hosts per router?
     (if so, how?)

      Yes. The concept of RID [4] may be used to associate to a single
      RID (which can also be a unique IP address) more than one IP
      addresses which represent different hosts associated are added to the
      router. MPR selector set of the node
      (router), which will then announce that the hosts can be
      reached through that node.

   * Does the protocol support the IP addressing architecture? (if so,
     how?)

      Yes. Nodes are assigned and addressed by regular IP-addresses.

   * Does the protocol require link or neighbor status sensing (if so,
     how?)

      Yes. The protocol requires the link status sensing. This service is
      provided by sending/receiving periodic HELLO messages to/from
      one hop neighbors.

   * Does the protocol depend on a central entity? (if so, how?)

      No. All the routers in the network have their own routing tables
      and do not depend on any specific node.

   * Does the protocol function reactively? (if so, how?)

      No. But it decreases and increases the interval (within certain
      limits) of sending the TC packet periodically, depending upon
      the rate of link changes in its neighborhood.

   * Does the protocol function proactively? (if so, how?)

      Yes. It Each node periodically sends the information about its multipoint
      relay MPR
      selectors, which helps other enables the nodes to build construct routes to it. these
      MPR selectors through the node.

   * Does the protocol provide loop-free routing? (if so, how?)

       Yes. As the protocol uses a link state algorithm, the routing is
       loop-free when in a stable state.

   * Does the protocol provide for sleep period operation? (if so, how?)

      Yes, OLSR can provide support

     No. However, provisions for sleep period operation. To
      enable this feature, a node should select its multipoint relays
      from among those neighbors which can (or agree to) store its
      packets while it is in sleep mode. sleep-operation may easily be
     enabled through extensions to the protocol.

   * Does the protocol provide some form of security? (if so, how?)

      No, not itself. It can use other protocols (like IMEP [4]) which
      provide authentication and security.

      No.

   * Does the protocol provide support for utilizing multi-channel,
     link-layer technologies? (if so, how?)

      Yes. OLSR makes no assumptions on the underlying link-layer
      other, than that local broadcast must be available.

5. 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 the routes immediately available when
   needed due to its proactive nature. OLSR is an optimization over
   the pure link state protocol, tailored for mobile ad hoc networks.

   Firstly, it reduces the size of the control packets: messages: rather than
   declaring all links, a node declares only a subset of links with
   its neighbors, namely the links to those nodes which are its
   multipoint relay MPR
   selectors (see section 6 on Multipoint Relays). MPRs).  Secondly, OLSR minimizes
   flooding of control traffic by using only selected nodes, called multipoint relays,
   MPRs, to diffuse its messages.  This technique significantly
   reduces the number of retransmissions in a flooding or broadcast
   procedure.

   The protocol

   OLSR MAY optimize the reactivity to topological changes by
   reducing the time interval for periodic control message
   transmission. Furthermore, as OLSR protocol keeps the routes for all
   destinations 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 changing over time. The protocol is
   particularly suited for large and dense networks, as the
   optimization done using the multipoint relays MPRs works well in this context. The
   larger and more dense a network, the more optimization can be
   achieved as compared to the normal link state algorithm.

   The protocol

   OLSR is designed to work in a completely distributed manner and thus
   does thus not depend on any central entity. The protocol does NOT
   REQUIRE reliable transmission for control messages: each node
   sends control messages periodically, and can therefore sustain an
   occasional loss of some packets. such messages. Such losses occur very often frequent
   in
   the radio networks due to collisions or other transmission problems.

   Also, the protocol OLSR does NOT REQUIRE sequenced delivery of messages. Each
   control message contains a sequence number which is incremented
   for each message. Thus the recipient of a control
   packet message can
   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 performs hop by hop routing, i.e. each node uses its most
   recent local information to route the a packet. Hence for OLSR to be
   able to route packets, the frequency of control messages should be
   tuned to the speed of the mobile nodes should be limited such that their movements
   can be tracked, at least tracked by their neighborhood.

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

6. Multipoint Relays

   The idea of multipoint relays is to minimize flooding the overhead of broadcast
   flooding messages in the network by reducing duplicate
   retransmissions in the same region. Each node in the network
   selects a set of nodes in its neighborhood which may retransmit
   its packets. messages. This set of selected neighbor nodes is called the multipoint relay
   "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 broadcast messages received from
   node N.

   Each node selects its MPR set among its one hop neighbors. This
   set is selected such that it covers (in terms of radio range) all the
   nodes that are two hops away. The neighborhood of any node N can
   be defined as the set of nodes which have a symmetric link to
   N. The
   two hop 2-hop neighborhood of N can be defined as the set of nodes
   which don't have a symmetric link to N but have a symmetric link
   to the neighborhood of N. The multipoint relay MPR set of N, denoted as MPR(N), is
   then an arbitrary subset of the neighborhood of N which satisfies
   the following condition: every node in the two hop 2-hop neighborhood of N
   must have a symmetric link toward MPR(N). The smaller the multipoint relay MPR set
   is, the more optimal is the routing protocol. [2] gives an
   analysis and example about
   multipoint relay MPR selection algorithms.

   Each node maintains information about a set of its neighbors. This
   is the set of neighbors, called the "Multipoint Relay Selectors", Selector
   set" (MPR selector set), which have selected the node as a MPR. A
   node obtain obtains this information from the periodic HELLO messages
   received from the neighbors. A broadcast message, intended to be
   diffused in the whole network, coming from these MPR Selector selector
   neighbor nodes is assumed to be retransmitted by the node. 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. Each node has a specific Multipoint "Multipoint relay Selector
   Sequence Number Number" (MSSN) associated with this set. Whenever its MPR
   selector set is updated, the node also increments its MSSN.

   OLSR relies on selection of multipoint relays, MPRs, and calculates the routes to a destination through
   these nodes. I.e. MPR nodes are selected as intermediate nodes in
   the path between a source and a destination. To implement enable this, each
   node in the network periodically broadcast the information
   describing which neighbors have selected it as a multipoint relay. MPR.  Upon
   receipt of this "MPR
   Selectors" Selector" information, each node calculates
   or updates the route to each known destination. So principally,
   the route is a sequence of hops through the multipoint relays MPRs from source to
   the destination.

   Multipoint relays

   MPRs are selected among the one hop neighbors with "symmetric"
   i.e. bi-directional link. Therefore, selecting the route through multipoint relays
   MPRs automatically avoids the problems associated with data packet
   transfer on uni-directional links such as the problem of not
   getting an acknowledgement acknowledgment for the data packets at each hop.

7. Protocol Functioning

   In this

   This section we describe describes the details of the protocol functioning.
   This includes descriptions of the format and contents of the
   packets being exchanged by routers, the algorithms (e.g. for
   packet handling and routing table calculation) and suggested data
   structures internally in each router.

7.1. Protocol and Port Number

   Packages in OLSR are communicated using UDP. Port 698 has been
   assigned by IANA  for exclusive usage by the OLSR protocol.

7.1.

7.2. Packet Format

   OLSR communicates using an unified packet format for all data
   related to the protocol. Inspired by the concept of "extension
   headers" from IPv6, the The purpose of this is to facilitate
   extensibility of the protocol without breaking backwards
   compatibility as well as to provide an easy way of piggybacking
   different "types" of information into a single transmission. These
   packets are embedded in UDP datagrams for transmission over the
   network. The present draft uses IPv4 addresses. The support Support for IPv6
   will be described included in a future draft.

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

   Messages can be flooded onto the entire network, or flooding can
   be limited to nodes within a diameter (in terms of number of hops)
   from the originator of the message. Thus, broadcasting a message
   to a nodes neighborhood is just a special case of flooding. When
   flooding any control message, duplicate retransmissions will be
   eliminated locally (i.e. each node maintains a duplicate table to
   prevent transmitting the same message twice) and minimized in the
   entire network through the usage of MPRs as described in section 5
   and 6.

   Furthermore, a node can examine the header of a message to obtain
   information on the distance (in terms of number of hops) to the
   originator of the message. This feature may be useful in
   situations where, e.g., the time information from a recieved
   control messages is stored in a node depends on the distance to
   the originator.

   The basic layout of any packet in OLSR will be as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Packet Length         |    Reserved for future use    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Message Type |   Reserved  |B|         Message Size                      Originator Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Message Size          |
   :                                                               :
   :                            MESSAGE                            :
   :                                                               :  Time To Live |   Hop Count   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Message Type |   Reserved  |B|            Message Size Sequence Number            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                            MESSAGE                            :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Originator Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Message Size          |  Time To Live |   Hop Count   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Message Type |            Message Sequence Number            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                                                               :
   :                            MESSAGE                            :
   :                                                               :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
            (etc)

7.1.1.

7.2.1. Packet Header

   Packet Length

      The length (in bytes) of the packet

   Reserved for future use

      MUST be set to '0000000000000000' to be in compliance with this
      version of the draft.

   The sender information in the header of this for a packet is equivalent to the
   information obtainable from the UDP
   header.

7.1.2.

7.2.2. Message Header

   Message Type

   Originator Address

      This field indicates which type contains the address of message are to the node, which has
      originally generated this message. This field SHOULD NOT be found in
      confused with the "MESSAGE" partition. Message types in source address from the range UDP header, which is
      changed each time to the address of 0-127 are
      reserved for messages in the intermediate node which
      is "re-transmitting" this draft and message. The Originator Address field
      MUST *NEVER* be changed in
      draft-ietf-manet-olsr-extensions-00.txt.

   B the retransmissions.

   Message Sequence Number

      While generating the TC message, the "originator" node will
      assign a unique identification number to each message. This
      number is inserted into the Sequence Number field indicates to a node whether of the message
      message. The sequence number is meant increased by 1 (one) for
      diffusion into each
      message originating from the entire network. This enables a node to
      forward messages correctly, even if it doesn't recognize the
      "Message Type".

   Reserved
      MUST be set to '0000000' to be - "wrap-arounds" are handled
      as described in compliance with this
      version of the draft. section 10.

   Message Size

      This field gives the size of this message, measured from the
      beginning of the "Message Type" field and until the beginning
      of the next "Message Type" field (or - if there are no
      following messages - the end of the packet).

7.1.3. Packet Processing

   Upon receiving such a basic packet, the protocol parser examines
   each of the "extension headers". Based on the value

   Message Type

      This field indicates which type of message are to be found in
      the "Message
   Type" field, the parser can determine the faith of "MESSAGE" partition. Message types in the data portion range of the message:

      1. If the data 0-127 are of a type which the receiving node can
         process, then
      reserved for messages in this data draft and in
      draft-ietf-manet-olsr-extensions-00.txt.

   Time To Live

      This field contains the maximum number of hops a message will
      be retransmitted. Before a message is processed.

      2. Otherwise, if transmitted, the "Message Type" indicates Time To
      Live MUST be decremented by 1. When a type, unknown node receives a message
      with a Time To Live equal to
         the node, 0, the message SHOULD silently MUST NOT be dropped.

   By defining
      retransmitted under any circumstances.

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

   Hop Count

      This field will contain the number of hops a message types, which has
      attained. Before a message is (re-) transmitted, the Hop Count
      MUST be recognized incremented by all
   implementations of OLSR, it will be possible 1.

      Initially, this is set to extend '0' by the protocol
   through introduction originator of additional message types, while still the message.

   Reserved

      This field is reserved for future usage, and MUST be
   able set to maintain compatibility with older implementations. The two
   REQUIRED message types
      '00000000' for OLSR are:

        - HELLO-messages, performing compliance with this draft.

7.2.3. Packet Processing

   Upon receiving a basic packet, the task protocol parser examines each
   of neighbor sensing.
        - TC-messages, performing the task "message headers". Based on the value of multipoint relay
	  information declaration.

   Extensions the "Message Type"
   field, the parser can determine the faith of the message. A node
   may e.g. be PC-messages for enabling power conservation
   / sleep mode, multicast routing, gateway announcements etc.

7.2. Neighbor sensing

7.2.1. HELLO receive the same message broadcast

   Each node should detect in several packets. This can happen
   only if the neighbor message is retransmitted by two nodes with which it has a direct in the receivers
   neighborhood, i.e. the "Time To Live" and symmetric link. The uncertainties over radio propagation may
   make some links asymmetric. Consequently, all links MUST be checked
   in both directions the "Hop Count" fields
   in order to be considered valid. the message satisfies the following condition:

       Time To accomplish this, Live + Hop Count > 1

   Thus, to avoid re-processing of a message which was already
   received and processed, each node broadcasts HELLO messages, containing maintains a Duplicate table. In
   this table, the node records information about neighbors and their link status. The link status
   may either be "symmetric", "heard" (asymmetric) or "MPR".
   "Symmetric" indicates, that the link has been verified to be
   bi-directional, i.e. it is possible to transmit data in both
   directions. "Heard" indicates that most recently
   received messages where the node is hearing from a
   neighbor, but it is not confirmed that this neighbor is also
   hearing from above condition holds. For each
   message, satisfying the node. "MPR" indicates, that above condition, a node records a
   "Duplicate Tuple" (D_addr, D_seq_num, D_time), where D_addr is selected by the sender as multipoint relay. MPR status implies that
   originator address of the link message, D_seq_num is
   symmetric too.

   These control messages are broadcast to all one-hop neighbors, but
   are *not relayed* to further nodes. A HELLO-message contains at a
   minimum:

      - a list of addresses the message
   sequence number of neighbors, to the message and D_time specifies the time at
   which there exists a
        symmetric link;

      - tuple expires and *MUST* be removed.

   In a list of addresses node, the set of neighbors, which have been "heard";

      - Duplicate Tuples are denoted the "Duplicate
   set".

   Thus, upon receiving a list of neighbors, which have been selected as multipoint
        relays.

   The list of neighbors in basic packet, a HELLO message can be partial (e.g. due
   to message size limitations, imposed by the network), node performs the rule
   being that all neighbor nodes are cited at least once within a
   predetermined refreshing period (HELLO_INTERVAL).

   To accommodate for the above constraints, as well as to accommodate following
   tasks for future extensions, an approach similar to the overall packet
   format (see section 6.1) is taken. Thus the proposed format of each encapsulated message:

      1. If there exists 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | tuple in the duplicate set, where:

	    D_addr == Originator Address, AND

	    D_seq_num == Message Sequence Number    |      MPR Sequence number      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Link Type   |   Reserved    |       Link

	 then the message has already been completely processed
	 and MUST silently be ignored.

      2. Otherwise, if the Message Size       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Neighbor Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Neighbor Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                             . . .                             :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Link Type   |   Reserved    |       Link Message Size       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Neighbor Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Neighbor Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :								   :
			         (etc)

   This is sent as the data-portion of the general packet format
   described in 6.1, with the "Message Type" set message is known to HELLO_MESSAGE and
         the broadcast field set node, the message MUST be processed according to NO_BROADCAST.

7.2.1.1. Description the
	 specifications of such message type.

      3. Otherwise, If the fields Message Sequence Number

      While generating a HELLO message, Type of the node will assign a unique
      identification number to this message. This number message is put into not known
         to the Sequence Number field. This sequence number will node, the message MUST be
      different for all processed according to the messages originated by that node.

   MPR Sequence Number

      This field indicates the sequence number corresponding to the
      most recent multipoint relay set, calculated by
	 following algorithm:

	 3.1 If the sender node.

   Link Type

      This field specifies the type of link the sending node has to message is not in the following list MPR selector
	     set of neighbors. As a minimum, the following
      three link types are REQUIRED by OLSR:

	   - ASYM_LINK - indicating that the links between the sender
	     and node, the neighbors in message MUST silently be dropped.

	 3.2 If the following list are asymmetric
	     (i.e. time to live of the neighbor message is "heard").

	   - SYM_LINK - indicating that less than or equal
	     to '0' (zero), the links between message MUST silently be dropped.

	 3.3 Otherwise, if the sender of the message is an MPR
	     selector of this node and if the neighbors in time to live of the following list are symmetric.

	   - MPR_LINK - indicating, that
	     message is greater than '0' (zero), the nodes in message MUST be
	     forwarded according to the following
	     list have been selected by algorithm:

	     3.3.1 The time to live of the sender as multipoint
	     relays.
	     (Notice: this implies, that message is reduced by one.

	     3.3.2 The hop-count of the links from message is increased by one

	     3.3.3 An entry in the sender duplicate set is recorded with:

		      D_addr = originator address

		      D_seq_num = Message Sequence Number

		      D_time = current time + D_HOLD_TIME.

	     3.3.4 The message is retransmitted (Notice: The
		   remaining fields of the HELLO and to message header SHOULD
		   be left unmodified.)

   Notice: known message types are *not* forwarded "blindly" by this
   algorithm. Forwarding (and setting the nodes correct message header in
   the list are symmetric).

      It forwarded, known, message) is possible to provide additional information by specifying
      additional link-types, e.g. LOST_LINK - indicating that the link
      between the sender and responsibility of the neighbors in
   algorithm specifying how the following list has
      been lost. Upon processing a HELLO message, a node silently
      ignores link-types, which are unknown.

   Reserved

      This field message is reserved for future usage, and MUST to be set handled. This
   enables, e.g., a message type to
      00000000 for compliance with this draft.

   Link Message Size

      The size of the link message, measured from be specified such that the beginning of
   message can be modified while in transit (e.g. to reflect the "Link Type" field and until
   route the next "Link Type" field (or
      - if there are no more link types - message has taken). Further, it enables that the end of
   optimization through the message).

   Neighbor Address

      The address MPRs can be bypassed: if for some reason
   pure flooding of a neighbor.

7.2.2.  HELLO message processing

   The HELLO messages permit each node to acquire information about
   its neighborhood up type is required (e.g. to two hops. A node maintains a Neighbor table
   in which it records the transmit
   control information (obtained from the HELLO
   messages) about its one hop neighbors, over unidirectional links), the status algorithm
   specifying handling of the link with these neighbors, a list messages will simply rebroadcast
   the message, regardless of two hop neighbors MPR selectors.

   Finally, notice that these one hop
   neighbors give access to, and an associated holding time. The
   information a message, which is recorded to be broadcast in the Neighbor table as a neighbor entry,
   with
   neighborhood, but not flooded into the following field names:

      1.  N_addr    N_status    N_2hop_list    N_time
      2.  N_addr    N_status    N_2hop_list    N_time
      3.    ,,         ,,            ,,          ,,

   Each entry in entire network, (e.g. a
   HELLO-message) is simply specified by setting the table consists of N_addr, N_status, N_2hop_list, time to live to
   '0' (zero), and N_time. This specifies that the node with address N_addr is no duplicate entries are recorded for such
   messages.

   By defining a
   one-hop neighbor to this node, the status set of the link between them
   is N_status, and this neighbor provides access message types, which MUST be recognized by all
   implementations of OLSR, it will be possible to extend the protocol
   through introduction of additional message types, while still be
   able to maintain compatibility with older implementations. The two
   REQUIRED message types for OLSR are:

        - HELLO-messages, performing the task of neighbor sensing.
        - TC-messages, performing the task of MPR information declaration.

   Extensions may e.g. be PC-messages for enabling power conservation
   / sleep mode, multicast routing, gateway announcements,
   auto-configuration/address assignment etc.

7.3. Neighbor sensing

7.3.1. Neighbor sensing information base

7.3.1.1 Neighbor information

   A node maintains information (obtained from the HELLO messages)
   about its one hop
   neighbors listed in N_2hop_list. Each entry in N_2hop_list consists neighbors, the status of the link with these
   neighbors, a 2 list of 2-hop neighbors that these one hop neighbor address neighbors
   give access to, and an associated holding time. The

   Thus, for each neighbor, a node records a "Neighbor Tuple"
   (N_addr, N_status, N_time) where N_addr is the address of the
   neighbor, N_status can be ASYM_LINK, SYM_LINK or MPR_LINK. A link designates the status of
   MPR_LINK implies that the link with the that
   neighbor (MPR, symmetric, heard) and N_time specifies the time at
   which this record expires and *MUST* be removed.

   Likewise, a node N_addr is records a set of "2-hop tuples" (N_addr,
   N_2hop_addr, N_time), describing symmetric *AND* or MPR links between
   its neighbors and the node 2-hop neighborhood. N_addr is selected as the address of
   a multipoint relay
   by this node. Each neighbor, N_2hop_addr is the address of a 2-hop neighbor entry has an associated holding and
   N_time specifies the time
   N_time, upon expiration of at which it is no longer valid a tuple expires and hence
   MUST *MUST*
   be removed.

   The node also contains

   In a sequence number N_MPR_seq. This specifies
   that node, the node has selected its most recent MPR set with of Neighbor Tuples are denoted the
   sequence number N_MPR_seq. Every time a node selects or updates its
   multipoint relay set, N_MPR_seq is incremented to a higher
   value. This number is put into the HELLO messages as described in
   6.2.1.

   Upon receiving a HELLO message, "Neighbor
   Set" and the node should update set of 2-hop tuples are denoted the "2-hop neighbor entry corresponding to the sender node address (a
   set".

7.3.1.2 MPR Selector information

   A node
   may - e.g. for security reasons - wish to restrict updating the
   neighbor-table, i.e. ignoring HELLO messages maintains information (obtained from some nodes):

      1. If the entry already exists:

	 1.1 if HELLO messages)
   about the recipient of neighbors which have selected the HELLO node as a MPR.

   Thus, a node records a MPR-selector tuple (MS_addr, MS_time), for
   each neighbor which has recorded selected the sender node as
	     asymetric:

	     1.1.1 if MPR. MS_addr is the node finds its own
   address among the
	           addresses listed in the HELLO message (with Link
	           Type ASYM_LINK, SYM_LINK or MPR_LINK), it updates
	           the status of a node which has selected the link to the sender node as
	           SYM_LINK MPR, and refreshes the N_time to
	           NEIGHB_HOLDING_TIME.

             1.1.2 otherwise, if the node does not find its own
	           address among MS_time
   specifies the addresses listed in time at which a tuple expires and *MUST* be
   removed.

   In a node, the HELLO
		   message, it refreshes set of MPR-tuples are denoted the N_time "MPR selector
   set" A sequence number, MSSN, is associated with this
   set. Whenever a tuple is added or removed to
		   NEIGHB_HOLDING_TIME.

         1.2 otherwise, if the recipient of this set, the MSSN is
   incremented by 1.

7.3.2. HELLO has recorded
	     the sender as symetric (or MPR):

	     1.2.1 if the message broadcast

   Each node finds its own address among the addresses
                   listed in should detect the HELLO message (with Link Type
                   ASYM_LINK, SYM_LINK or MPR_LINK), neighbor nodes with which it refreshes the
                   N_time to NEIGHB_HOLDING_TIME.

      2. Otherwise, has a new entry is recorded direct
   and symmetric link. The uncertainties over radio propagation may
   make some links asymmetric. Consequently, all links MUST be checked
   in the Neighbor table with:

           - N_addr is set to the address of the sender node,

           - N_status is set both directions in order to the value of SYM_LINK if the be considered valid.

   To accomplish this, each node
             finds its own address (with Link Type ASYM_LINK, SYM_LINK
             or MPR_LINK) among the addresses listed in the broadcasts HELLO
             message, messages,
   containing information about neighbors and to the value of ASYM_LINK otherwise

	   - N_time is set to the value of NEIGHB_HOLD_TIME their link status. The N_2hop_list of the entry of
   link status may either be "symmetric", "heard" (asymmetric) or
   "MPR".  "Symmetric" indicates, that the sender link has been verified to
   be bi-directional, i.e. it is updated, as
   follows. For each address listed possible to transmit data in both
   directions. "Heard" indicates that the node can hear HELLO message with Link
   Type SYM_LINK or MPR_LINK:

      1. if an entry with this address exists in the N_2hop_list, then
         the associated holding time
   messages from a neighbor, but it is refreshed to NEIGHB_HOLD_TIME

      2. otherwise an entry with not confirmed that this address and holding time
         NEIGHB_HOLD_TIME
   neighbor is added also able to the N_2hop_list.

   Based on the information obtained receive messages from the HELLO messages, each
   node construct its MPR Selector table. In this table, the node. "MPR"
   indicates, that a node
   registers the addresses of those one hop neighbor nodes which have is selected by the node sender as a multipoint relay. The MPR. A
   status of MPR Selector table may
   have further implies that the following format:

      1.  MS_addr    MS_seq_num    MS_time
      2.  MS_addr    MS_seq_num    MS_time
      3.     ,,          ,,          ,,

   Each entry in the table consists link is symmetric.

   These control messages are broadcast to all one-hop neighbors, but
   are *not relayed* to further nodes. A HELLO-message contains:

      - a list of MS_addr, MS_seq_num and
   MS_time, which specifies that the node with address MS_addr has
   selected this node as its multipoint relay with the MPR sequence
   number equal addresses of neighbors, to MS_seq_num. Each entry has an associated holding
   time MS_time, upon expiation which there exists a
        symmetric link;

      - a list of addresses of neighbors, which it is no longer valid and
   hence removed.

   A sequence number, MSSN, is associated with this table. This number
   specifies that the multipoint relay selector set have been "heard";

      - a list of the node
   keeping this MPR Selector table is most recently modified with the
   sequence number MSSN. neighbors, which have been selected as MPRs.

   The node modifies its MPR Selector set
   according to the information it receives list of neighbors in the HELLO messages, and
   increment this sequence number upon each modification.

   Upon receiving a HELLO message, if a node finds its own address in message can be partial (e.g. due
   to message size limitations, imposed by the address list with network), the rule
   being that all neighbor nodes are cited at least once within a link type of "MPR", it MUST update
   predetermined refreshing period (HELLO_INTERVAL).

   To accommodate for the
   entry corresponding above constraints, as well as to accommodate
   for future extensions, an approach similar to the sender node's address in the MPR
   Selector table:

      1. If the entry already exists:

         1.1 if overall packet
   format (see section 6.1) is taken. Thus the MPR Sequence Number field proposed format of the a
   HELLO message is
             greater than or equal to 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Link Type   |   Reserved    |       Link Message Size       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Neighbor Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Neighbor Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                             . . .                             :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Link Type   |   Reserved    |       Link Message Size       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Neighbor Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Neighbor Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :								   :
			         (etc)
   This is sent as the MS_seq_num field data-portion of the
             entry general packet format
   described in 6.1, with the table, then the MS_time is refreshed "Message Type" set to
             NEIGHB_HOLD_TIME.

         1.2 if the MPR Sequence Number field of the HELLO message is
             greater than the MS_seq_num field of that entry, HELLO_MESSAGE and
   the
             MS_seq_num TTL field is updated set to the value 0.

7.3.2.1. Description of the fields

   MPR Sequence Number

      This field of indicates the HELLO message.

      2. Otherwise, a new entry is recorded in sequence number corresponding to the
      most recent MPR Selector table,
         with:

         2.1 MS_addr is set to set, calculated by the address of sender node.

   Link Message Size

      The size of the HELLO
             message

         2.2 MS_seq_num is set to link message, measured from the MPR Sequence Number beginning of
      the "Link Type" field and until the next "Link Type" field (or
      - if there are no more link types - the end of the
             HELLO message

         2.3 MS_time is set to message).

   Link Type

      This field specifies the value type of NEIGHB_HOLD_TIME

	 2.4 MSSN is incremented to indicate that link the MPR Selector
	     table sending node has been changed.

   If link layer information describing connectivity to neighboring
   nodes is available (i.e. loss of connectivity such as through
   absence
      the following list of an acknowledgment), this MAY be used in addition to neighbors. As a minimum, the information from following
      three link types are REQUIRED by OLSR:

	   - ASYM_LINK - indicating that the HELLO-messages to maintain links between the neighbor
   table sender
	     and the MPR selector table.

7.3. Multipoint relay selection

   Each node neighbors in the network selects independently its own set of
   multipoint relays. Multipoint relays following list are used to flood the control
   messages of that node into asymmetric
	     (i.e. the network. The MPR set neighbor is calculated
   in a way such "heard").

	   - SYM_LINK - indicating that it contains a subset of one hop neighbors which
   covers all the two hop neighbors. This means, that links between the union of sender
	     and the
   neighbor sets of all MPRs contains neighbors in the entire two hop neighbor
   set. In order to build following list are symmetric.

	   - MPR_LINK - indicating, that the nodes in the following
	     list of have been selected by the two hop nodes, make sender as MPR.
	     (Notice: this implies, that the
   union of N_2hop_lists of all neighbors (with Link Type SYM_LINK or
   MPR_LINK), then remove links from this union the one-hop neighbors (with
   Link Type SYM_LINK or MPR_LINK), sender
	     of the HELLO and finally remove to the node
   itself. Multipoint relays of a given node are declared nodes in the
   subsequent HELLOs transmitted list are symmetric).

      It is possible to provide additional information by this node, so specifying
      additional link-types, e.g. LOST_LINK - indicating that the information
   reaches link
      between the multipoint relays themselves. These selected multipoint
   relays are indicated sender and the neighbors in the following list has
      been lost. Upon processing a HELLO messages with message, a link status of
   "MPR". The multipoint relay set is re-calculated when:

      - a change in the neighborhood is detected, i.e. either a
        symmetric link with a neighbor is failed, or a new neighbor
        with a symmetric link is added; or
      - a change is detected in the two-hop neighborhood such that
        a symmetric link node silently
      ignores link-types, which are unknown.

   Reserved

      This field is either detected or broken between a
	two-hop neighbor reserved for future usage, and a neighbor.

   The MPR set needs not be optimal. However it SHOULD MUST be small enough set to achieve the benefit of the multipoint relays.
      000000000000000000000000 for compliance with this draft.

   Neighbor Address

      The concept of
   multipoint relays is an optimization address of a pure flooding mechanism.
   It is not essential that neighbor.

7.3.3.  HELLO message processing

   Upon receiving a HELLO message, the multipoint relay set be minimal or
   optimal. But it is essential that all two-hop neighbors can be
   reached through node SHOULD update the selected MPR's. By default,
   neighbor information corresponding to the multipoint
   relay set can coincide with sender node address (a
   node may - e.g. for security reasons - wish to restrict updating
   the entire neighbor set. This neighbor-table, i.e. ignoring HELLO messages from some nodes).

   In this section, the term "Originator Address" will be used for
   the address of the case at network initialization. Each node will manage which sent the HELLO-message.

      1. If there exists a
   dedicated sequence number in order to track neighbor tuple with N_addr = Originator
         Address:

	 1.1 if for that tuple N_status == ASYM_LINK:

	     1.1.1 if the changes in node finds its
   multipoint relay set. This sequence number will also appear, along
   with own address among the MPR list,
	           addresses listed in the HELLO messages.

   We propose a heuristic for message (with Link
	           Type ASYM_LINK, SYM_LINK or MPR_LINK), it updates
	           the selection N_status of multipoint relays
   [2]. We use the following terminology in describing this algorithm:

      MPR(x): Multipoint relay set of node x which is running this
              algorithm
      N(x):   One hop neighbor set of node x (containing only symmetric
              neighbors)
      N2(x):  Two hop neighbor set of node x (containing only symmetric
              neighbors of nodes in N(x) ). The two hop neighbor set
              N2(x) of tuple to SYM_LINK and sets
		   N_time = current time + NEIGHB_HOLDING_TIME.

	     1.1.2 otherwise, if the node x does not contain any one hop neighbor of
              node x

      D(x,y): Degree of one hop neighbor find its own
	           address among the addresses listed in the HELLO
		   message, it sets N_time = current time +
		   NEIGHB_HOLDING_TIME.

         1.2 otherwise, if for that tuple:

	     N_status == SYM_LINK OR
	     N_status == MPR_LINK

	     then:

	     1.2.1 if the node y (where y is finds its own address among the addresses
                   listed in the HELLO message (with Link Type
                   ASYM_LINK, SYM_LINK or MPR_LINK), it sets N_time =
                   current time NEIGHB_HOLDING_TIME.

      2. Otherwise, a member
              of N(x) ), new neighbor tuple is defined as created with:

           N_addr = Originator Address

           N_status with the number of symmetric one hop
              neighbors value of node y EXCLUDING SYM_LINK if the node x
           finds its own address (with Link Type ASYM_LINK, SYM_LINK
           or MPR_LINK) among the addresses listed in the HELLO
           message, and all to the
              symmetric one hop neighbors value of node x, i.e.,
                 D(x,y) ASYM_LINK otherwise

	   N_time = number of elements of N(y) - {x} - N(x) current time + NEIGHB_HOLD_TIME

   The proposed heuristic 2-hop neighbor set is updated as follows:

      1. Start with an empty MPR(x)
      2. Calculate D(x,y), where y is a member of N(x), for all nodes
         in N(x)
      3. First select as MPRs those nodes in N(x) which provide the
         "only path" to reach some nodes in N2(x)
      4. While there still exist some nodes in N2(x) that are not
         covered by MPR(x):

         4.1 For each node 2-hop
   neighbor address listed in N(x), calculate the number of nodes in
             N2(x) which are not yet covered by MPR(x) and are
             reachable through this one hop neighbor;
         4.2 Select as HELLO message with Link Type
   SYM_LINK or MPR_LINK:

      1. if a MPR that node of N(x) which reaches 2-hop tuple exists with:

            N_addr == Originator Address AND
	    N_2hop_address == the
             maximum number address of uncovered nodes in N2(x). In case the 2-hop neighbor,

	 then the N_time of a
             tie, select that node as MPR whose D(x,y) tuple is greater.

      5. To optimize, process set to:

	    N_time = current time + NEIGHB_HOLD_TIME

      2. otherwise a new 2-hop tuple is created with:

	    N_addr = Originator Address,

	    N_2hop_address = the address of the 2-hop neighbor,

	    N_time = current time + NEIGHB_HOLD_TIME.

   Based on the information obtained from the HELLO messages, each
   node y in MPR(x), one at construct its MPR selector set.

   Thus, upon receiving a time, and HELLO message, if MPR(x) - {y} still covers all nodes a node finds its own
   address in N2(x) then remove y from
         MPR(x)

   After selecting the multipoint relays among the neighbors, the address list with a link
   status type of "MPR", it MUST
   update the corresponding one hop neighbors is changed from
   SYM_LINK MPR selector set to MPR_LINK in contain updated information about
   the neighbor table. MPR_Seq_Num value in sender of the Neighbor table HELLO message:

      1. If a MPR selector tuple exists with:

	    MS_addr == Originator Address

	 then the expiration time of that tuple is set to:

	     MS_time = current time + NEIGHB_HOLD_TIME.

      2. Otherwise, a new MPR selector tuple is created with:

             MS_addr = Originator Address

             MS_time = current time + NEIGHB_HOLD_TIME

	 2.1 MSSN is also incremented by one.

7.4. Multipoint relay information declaration

7.4.1. TC Message Broadcast

   In order one to build indicate that the topology MPR
	     selector table has been changed.

   If link layer information database needed for
   routing the packets, each relay node broadcasts specific service
   messages called Topology Control (TC) messages. TC messages are
   forwarded, like usual broadcast messages, describing connectivity to all neighboring
   nodes in the
   network and take advantage is available (i.e. loss of multipoint relays. Multipoint relays
   enable a better scalability connectivity such as through
   absence of an acknowledgment), this MAY be used in addition to
   the distribution of topology information [1].

   A TC message is sent by a from the HELLO-messages to maintain the neighbor
   table and the MPR selector table as described in section 7.7.

7.4. Multipoint relay selection

   Each node in the network to declare selects independently its MPR
   Selector set. I.e., own set of
   MPRs. MPRs are used to flood control messages from that node into
   the TC message contains network while reducing the list number of neighbors
   which have selected retransmissions that will
   occur in a region. Thus, the sender node as concept of MPRs is an optimization
   of a multipoint relay. pure flooding mechanism.

   The
   sequence number (MSSN) associated with this multipoint relay
   selector MPR set is also sent with the list. The list of addresses can must be partial in each TC message (e.g. due to message size
   limitations, imposed calculated by a node in a way such that it,
   through the network), but parsing of neighbors in the MPR-set, can reach all TC
   messages describing a 2-hop
   neighbors. This means that the union of the neighbor sets the MPR
   nodes contains the entire 2-hop neighbor set. While it is not
   essential that the MPR selector set MUST is minimal, it is essential that all
   2-hop neighbors can be complete
   within a certain refreshing period (TC_INTERVAL). reached through the selected MPR nodes. The information
   diffused in
   smaller a MPR-set, however, the network by these TC messages will help each node to
   calculate its routing table. A node which has an empty MPR Selector
   set, i.e. nobody has selected it as a multipoint relay, MUST NOT
   generate any TC message.

   A node MAY transmit additional TC-messages to increase its
   reactiveness to link failures. I.e. when a change to more optimizations are achieved.

   By default, the MPR
   selector set is detected and this change can coincide with the entire neighbor
   set. This will be attributed to a
   link failure, the case at network initialization.

   The following specifies a TC-message SHOULD proposed heuristic for selection of MPRs
   [2]. The following terminology will be transmitted after a shorter
   interval than TC_INTERVAL. used in describing this
   algorithm:

      N:      The proposed format net of neighbors with which there exists 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Message Sequence Number     |              MSSN             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Hop Count   |                   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Originator Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Multipoint Relay Selector Address               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Multipoint Relay Selector Address               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	      symmetric link.

      N2:     The set of 2-hop neighbors. This set does not contain
	      any one hop neighbors.

      D(y):   Degree of one hop neighbor node y (where y is sent a member
              of N), is defined as the data-portion number of symmetric one hop
              neighbors of node y, EXCLUDING the general message format
   described in 6.1, with node performing the "Message Type" set to TC_MESSAGE
	      computation and
   the broadcast field all its direct neighbors.

   The proposed heuristic is as follows:

      1. Start with an empty MPR set to BROADCAST.

7.4.1.1. Description
      2. Calculate D(y), where y is a member of N, for all nodes
         in N.
      3. Select as MPRs those nodes in N which provide the fields

   Message Sequence Number
         "only path" to some nodes in N2
      4. While generating the TC message, the "originator" there exist nodes in N2 which are not covered by MPR:

         4.1 For each node will
      assign a unique identification in N, calculate the number to this message, of nodes in
             N2 which are not yet covered by MPR and will
      put are
             reachable through this one hop neighbor;
         4.2 Select as a MPR that node of N which reaches the
             maximum number of uncovered nodes in N2. In case of a
             tie, select that node as MPR whose D(y) is greater.

      5. As an optimization, process each node y in MPR.
         If MPR\{y} still covers all nodes in N2, Y SHOULD be
	 removed from the MPR set.

   After selecting the MPRs among the neighbors, the link status of
   the corresponding one hop neighbors is changed from SYM_LINK to
   MPR_LINK in the Sequence Number field. This sequence
      number will be different for all messages originated neighbor table. MPR_Seq_Num value in the Neighbor
   table is also incremented by that
      node, and will be used to recognize duplicate reception of
      messages. one.
   The MPR Selector Sequence Number (MSSN)

      A sequence number set is associated with re-calculated when:

      - a change in the multipoint relay
      selector set. Every time neighborhood is detected, i.e. either a node detects
        symmetric link with a neighbor is failed, or a new neighbor
        with a symmetric link is added; or
      - a change in its
      multipoint relay selector set, it increments this sequence
      number. This number is sent detected in this MSSN field of the TC message
      to keep track of the most recent information. When a node
      receives 2-hop neighborhood such that
        a TC message, it can decide on the basis of this MPR
      Sequence Number, whether symmetric link is either detected or not broken between a
	2-hop neighbor and a neighbor.

7.5. Multipoint relay information declaration

7.5.1 Topology information base

   Each node in the received network maintains topological information about
   the multipoint relay selectors of the originator node is more
      recent than what it already has.

   Hop Count network. This field will contain information is acquired from TC-messages and
   used for routing table calculations.

   Thus, for each destination in the maximum number of hops a TC message
      can attain. Every time network, a TC message "Topology Tuple"
   (T_dest, T_last, T_seq, T_time) is re-transmitted, this
      field recorded. T_dest is decremented by 1. When this field reaches zero, the TC
      message is no more re-transmitted and is discarded.

   Reserved

      This field is reserved for future usage, and MUST address
   of a node, which may be set to
      '000000000000000000000000' for compliance reached in one hop from the node with this draft.

   Originator Address

      This field contains the
   address of T_last. T_seq is a sequence number, and T_time specifies
   the node, time at which has
      originally generated this TC message. This field MUST not tuple expires and *MUST* be
      confused with removed.

   In a node, the source read in set of Topology Tuples are denoted the UDP header, which is
      changed "Topology
   Set".

7.5.2. TC Message Broadcast

   In order to build the topology information base needed, each time node,
   which has been selected as MPR, broadcasts Topology Control (TC)
   messages. TC messages are flooded to all nodes in the address network and
   take advantage of MPRs. MPRs enable a better scalability in the intermediate node which
      is "re-transmitting" this
   distribution of topology information [1].

   A TC message. The Originator Address
      field message is *never* changed sent by a node in the retransmissions.

   Multipoint Relay network to declare its MPR
   Selector Address (MPR-S)

      This field set. I.e., the TC message contains the address list of a node, neighbors
   which has have selected the Originator sender node (of the TC message) as a multipoint relay.
      All addresses of MPR. The sequence number
   (MSSN) associated with this MPR selector set is also sent with the multipoint relay selectors
   list. The list of the
      Originator node are put addresses can be partial in the each TC message. If the maximum
      allowed message
   (e.g. due to message size (as limitations, imposed by the network) is reached
      while there are still multipoint relay network),
   but parsing of all TC messages describing a nodes MPR selector addresses which
      which have not been inserted into set
   MUST be complete within a certain refreshing period
   (TC_INTERVAL). The information diffused in the TC-message, more network by these TC
   messages will be generated until the entire help each node to calculate its routing table. A
   node which has an empty MPR selector set set, i.e. nobody has
      been sent.

7.4.2. TC Message Processing

   In the OLSR protocol, selected
   it as a MPR, MUST NOT generate any TC messages are broadcasted and are
   retransmitted by the multipoint relays in order message.

   A node MAY transmit additional TC-messages to increase its
   reactiveness to link failures. I.e. when a change to diffuse the
   messages in the entire network. In MPR
   selector set is detected and this process, change can be attributed to a node MAY receive
   the same TC message more
   link failure, a TC-message SHOULD be transmitted after a shorter
   interval than once. To avoid re-processing TC_INTERVAL.

   The proposed format of a TC message which was already received and processed, each node
   maintains a Duplicate table. In this table, 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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Multipoint Relay Selector Address               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Multipoint Relay Selector Address               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This is sent as the node records
   information about data-portion of the most recently received TC messages. The
   information is recorded general message format
   described in 6.1, with the Duplicate table as Duplicate
   entries. "Message Type" set to TC_MESSAGE.  The table may have the following format:

      1.  D_addr    D_seq_num    D_time
      2.  D_addr    D_seq_num    D_time
      3.    ,,          ,,         ,,

   Each entry in
   time to live SHOULD be set to 255 (maximum value) to diffuse the table consists of D_addr, D_seq_num and D_time,
   which specifies that a TC
   message was received, originating from into the node with address D_addr, having entire network.

7.5.2.1. Description of the message fields

   MPR Selector Sequence Number (MSSN)

      A sequence number
   as D-seq_num.  Each Duplicate entry also has an is associated holding with the MPR selector
      set. Every time D_time, upon expiration of which it is no longer valid and
   hence MUST be removed.

   Upon receiving a TC message, a node checks detects a change in its Duplicate table
   to see if it has already received the same message. If MPR selector
      set, it finds a
   corresponding entry, the message is discarded. Otherwise, a new
   entry increments this sequence number. This number is recorded sent in the Duplicate table for
      this newly received TC
   message, and MSSN field of the TC message is processed. to keep track of the most
      recent information. When a node receives a TC
   message from a neighbor node with which it has an asymmetric (or
   uni-directional) link, message, it neither registers can
      decide on the message in basis of this MPR Sequence Number, whether or not
      the
   Duplicate table nor it processes received information about the message.

   Each MPR selectors of the
      originator node in is more recent than what it already has.

   Multipoint Relay Selector Address (MPR-S)

      This field contains the network maintains address of a topology table, in node, which it
   records has selected
      the information about Originator node (of the topology TC message) as a MPR.  All
      addresses of the network as
   obtained from MPR selectors of the Originator node are put
      in the TC messages. Based on message. If the maximum allowed message size (as
      imposed by the network) is reached while there are still MPR
      selector addresses which which have not been inserted into the
      TC-message, more TC messages will be generated until the entire
      MPR selector set has been sent.

   Reserved

      This field is reserved for future usage, and MUST be set to
      '0000000000000000' for compliance with this information, the
   routing table is calculated. A node records information about the
   multipoint relays of other nodes in draft.

7.5.3. TC Message Processing

   TC messages are broadcasted and retransmitted by the network MPRs in its topology
   table as a topology entry, which may have order
   to diffuse the following format:

      1.  T_dest    T_last    T_seq    T_time
      2.  T_dest    T_last    T_seq    T_time
      3.    ,,        ,,        ,,       ,,

   Each entry messages in the table consists of T_dest, T_last, T_seq, and
   T_time, which specifies that entire network.

   In this section, the node T_dest has selected term "originator" is used to designate the
   node
   T_last as a multipoint relay and that from which the node T_last has announced
   this information of its multipoint relay selector set with message originally originated, while the
   sequence number T_seq. Therefore, term
   "sender" is used to designate the node T_dest can be reached in from which the last hop through message was
   received (i.e. the node T_last. Each topology entry has an
   associated holding time T_time, upon expiration "last hop" of which it is no
   longer valid and hence MUST be removed. the message).

   The entries tuples in the topology table set are recorded with the topology
   information that is exchanged through TC messages.

   After registering a TC messages, following the
   following algorithm:

      1. If the sender (NB: not originator) of this message is not in
         the duplicate table, neighbor set of this node, the following
   procedure message is executed to record the information in discarded.

      2. A tuple is inserted into the topology
   table:

      1. duplicate table to prevent
	 being processed again with:

	   D_addr = originator address

	   D_seq_num = Message Sequence

	   D_time = current time + D_HOLD_TIME.

      3. If there exist some entry tuple in the topology table whose set where:

	   T_last
         corresponds to the == originator address of the TC message and
         whose AND
	   T_seq is greater in value than the MSSN in the received
         message, > MSSN,

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

      2.

      4. All entries tuples in the topology table with set where:

	    T_last corresponding
         to the == originator address of the TC message and whose AND
	    T_seq
         is lesser in value than the < MSSN in the received message,

	 are removed.

      3. removed from the topology set.

      5. For each of the MPR Selector selector address received in the TC
         message:

         3.1

         5.1 If there exist some entry tuple in the topology table whose set where:

                T_dest corresponds to the == MPR Selector address and the selector address, AND
                T_last corresponds to the == originator address of the TC
             message, address,

	     then the holding time T_time of that topology
             entry tuple is refreshed to set to:

	        T_time = current time + TOP_HOLD_TIME.

         3.2

         5.2 Otherwise, a new topology entry tuple is recorded in the topology table set
	     where:

                -

                T_dest is set to this = MPR Selector selector address,
                -

                T_last is set to the = originator address of the TC
                  message,
                - address,

                T_seq is set to the value of MSSN received in the TC
                  message,
                -  = MSSN,

                T_time is set to the value of = current time + TOP_HOLD_TIME.

7.5.

7.6. Routing table calculation

   Each node maintains a routing table which allows it to route the
   messages for the other destinations in the network. The routing
   table is based on the information contained in the neighbor table set
   and the topology table. set. Therefore, if any of these tables is
   changed, the routing table is re-calculated to update the route
   information about each destination in the network. The route
   entries are recorded in the routing table in the following format:

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

   Each entry in the table consists of R_dest, R_next and R_dist,
   which specifies that the node identified by R_dest is estimated to
   be R_dist hops away from the local node, and that the one hop
   neighbor node with address R_next is the next hop node in the route
   to R_dest. Entries are recorded in the table for each destination
   in the network for which the route is known. All the destinations
   for which the route is broken or partially known are not entered in
   the table.

   This routing table information is updated when a change is detected in
   the neighbor table, set, or the topology table. set. The update of this routing table
   information does not generate or trigger any messages to be
   transmitted, neither in the network, nor in the one-hop
   neighborhood.

   To construct the routing table of node X, a shortest path
   algorithm is run on the directed graph containing the arcs X -> Y
   where Y is any one hop neighbor of X (with Link Type SYM_LINK or
   MPR_LINK) and the arcs U -> V where there exists an entry in the
   topology table set with V as T_dest and U as T_last.

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

   1. All the entries of from the routing table are removed.

   2. The new routing entries are recorded in the table added starting with the one
      hop neighbors (h=1) as the destination nodes. For each neighbor
      entry in the neighbor table, whose Link Type is SYM_LINK or
      MPR_LINK, a new route routing entry is recorded in the routing table
      where R_dest and R_next are both set to the address of the
      neighbor and R_dist is set to 1.

   3. Then the The new route entries for the destination nodes h+1 hops
      away are recorded in the routing table. The following procedure
      is executed for each value of h, starting with h=1 and
      incrementing 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 the topology table, if its
             T_dest does not correspond to R_dest of any route entry
             in the routing table AND its T_last corresponds to R_dest
             of a route entry whose R_dist is equal to h, then a new
             route entry is recorded in the routing table where :

                - R_dest is set to T_dest;
                - R_next is set to R_next of the route entry whose
                  R_dest is equal to T_last; and
                - R_dist is set to h+1.

7.6

7.7 Link layer notification

   OLSR is designed to operate entirely alone, i.e. does not to impose or expect any specific information
   from the 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 information from the HELLO-messages to
   maintain the neighbor table set and the MPR selector
   table. set.

   Subsequently, detection of a link failure through a link-layer
   notification may trigger additional TC-messages to increase the
   protocols reactiveness to link failures. I.e. when a change to the
   MPR selector set is detected and this change can be attributed to
   a link failure, a TC-message SHOULD be transmitted.

   Thus, upon recieving receiving a link-layer notification that the link
   between a node and any neighbor is broken, the following actions
   are taken:

   1. if the link is broken to either a symetric symmetric or asymetric asymmetric
      neighbor, the entry tuple for that neighbor is removed from the
      neighbor table, set,

   2. if the link is broken to a neighbor, which is selected as MPR,
      the entry tuple for that neighbor is removed from the neighbor
      table
      set and the MPR set is recalculated,

   3. if the link is broken to a neighbor, which has selected this
      node as MPR, the Multipoint Selector Set is updated and a
      TC message SHOULD be generated.

8. Packet forwarding

8.1. Data packet forwarding

   Data packets are relayed on a hop by hop basis. In the source
   router and in any intermediate router, the next hop router is
   identified by the entry of the destination in the host routing
   table.

   Whenever a data packet is received to route to a destination and
   its TTL field (in IP header) is greater than zero, the node MUST
   examine the final destination field in the packet. If the route is
   known, i.e. an entry broken to a neighbor, which has selected this
      node as MPR, the MPR selector set is found in updated and a
      TC message SHOULD be generated.

8. Packet forwarding

8.1. Data packet forwarding

   OLSR itself does not perform packet forwarding. Rather, it
   maintains the routing table in which R_dest
   corresponds to the final destination, then the packet underlying operating system,
   which is
   transmitted assumed to the next hop node.

   While be forwarding a unicast packet, the originator address, and the
   final destination address of the packets are not changed. The
   packet traverses the intermediate source and destination pairs,
   hop by hop, until it reaches its final destination. as specified in RFC1812.

8.2. Topology Control message forwarding

   TC messages are

   Control messages, destined for flooding into the entire network,
   SHOULD be relayed by the multipoint relays MPR via the following rule:

      A node retransmits a TC message only when it is received from one
      of its multipoint relay MPR selector AND it is not before registered in the
      duplicate table for the first time AND the hop count time to live is greater than zero.

   Before retransmitting, the hop count is incremented by one and the
   time to live is decremented by one.

9.  Proposed values for the constants

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

   HELLO_INTERVAL   = 2 seconds
   TC_INTERVAL      = 5 seconds
   TC_MIN_INTERVAL  = 2 seconds

   NEIGHB_HOLD_TIME = 6 seconds 3 x HELLO_INTERVAL
   TOP_HOLD_TIME    = 15 seconds 3 x TC_INTERVAL
   D_TIME           = 30 seconds

   HELLO_PACKET

   HELLO_MESSAGE    = 1
   TC_PACKET
   TC_MESSAGE       = 2

   ASYM_LINK        = 1
   SYM_LINK         = 2
   MPR_LINK         = 3

10. 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 (that the sequence number is incremented from the
  maximum possible value to zero) will occur. To prevent this from
  interfering with the operation of the protocol, the following
  MUST be observed.

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

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

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

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

11. References

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

   2. A. Qayyum, L. Viennot, A. Laouiti.  Multipoint relaying: An
      efficient technique for flooding in mobile wireless networks.
      INRIA research report RR-3898, 2000

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

   4. Corson et al.  Internet MANET Encapsulation Protocol. Internet
      draft, draft-ietf-manet-imep-spec-01.txt, Work in progress.

   5. Perkins, C.E.,  Mobile Ad Hoc Networking Terminology, Internet
      draft, draft-ietf-manet-term-00.txt, work in progress.

   6. Corson, S.,  MANET Routing Protocol Applicability Statement,
      Internet draft, draft-ietf-manet-appl-00.txt, Work in progress.

   7. S. Bradner.  Key words for use in RFCs to Indicate Requirement
      Levels.  Request for Comments (Best Current Practice) 2119,
      Internet Engineering Task Force, March 1997.

   8. Philippe Jacquet and Laurent Viennot, Overhead in Mobile Ad-hoc
      Network Protocols, INRIA research report RR-3965, 2000

12. Authors' Addresses

   Amir Qayyum
   Project HIPERCOM
   INRIA Rocquencourt
   BP 105
   78153 Le Chesnay Cedex, France
   Phone: +33 1 3963 5273
   Email: Amir.Qayyum@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 5278 508832
   Email: Anis.Laouiti@inria.fr

   Laurent Viennot
   Project HIPERCOM
   INRIA Rocquencourt
   BP 105
   78153 Le Chesnay Cedex, France
   Phone: +33 1 3963 5278 5225
   Email: Laurent.Viennot@inria.fr

   Paul Muhlethaler
   Project HIPERCOM
   INRIA Rocquencourt
   BP 105
   78153 Le Chesnay Cedex, France
   Phone: +33 1 3963 5278
   Email: Thomas.Clausen@inria.fr

   Thomas Clausen
   Project HIPERCOM
   INRIA Rocquencourt
   BP 105
   78153 Le Chesnay Cedex, France
   Phone: +33 1 3963 5278 5133
   Email: Thomas.Clausen@inria.fr