INTERNET-DRAFT                                          Philippe Jacquet
IETF MANET Working Group                                Paul Muhlethaler
Expiration: 7 August 2000 18 January 2001                                  Amir Qayyum
							    Anis Laouiti
							 Laurent Viennot
							  Thomas Clausen
                                              INRIA Rocquencourt, France
                                                         7 February
                                                            18 July 2000

		Optimized Link State Routing Protocol
                    draft-ietf-manet-olsr-01.txt
                    draft-ietf-manet-olsr-02.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
   the
   selected nodes which forward the broadcast packets during the flooding
   process. This technique substantially reduces the packet overhead
   as compared to pure flooding mechanism where every node retransmits
   the packet when it receives the first copy of the packet. In OLSR
   protocol, the information flooded in the network "through" these
   multipoint relays is also "about" the multipoint relays. Hence, Thus a
   second optimization is achieved here by minimizing the "contents" of the
   control packet packets 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, and therefore
   calculation. As a consequence hereof, the routes contain only the
   MPRs as the intermediate nodes from a Source to a Destination. It results in
   providing the OLSR
   provides optimal routes (in terms of number of hops), and
   hence another optimization. hops). The protocol
   is particularly suitable for the large and dense networks as the
   technique of multipoint relays works well in this context.

			   Contents

Status of This Memo                                             1

Abstract                                                        1

 1. Introduction                                                2
 2. Changes							3
 3. OLSR terminology						4
 4. Applicability Section					5
     4.1 Networking Context					5
     4.2 Protocol Characteristics and Mechanisms		5
 5. Protocol Overview						7
 6. Multipoint relays						9
 7. Protocol functioning				       10
     7.1 Packet format					       10
          7.1.1 Packet Header				       11
	  7.1.2 Extension Header			       12
	  7.1.3 Packet Processing			       12
     7.2 Neighbor sensing				       13
          7.2.1 HELLO message broadcast			       13
	  7.2.2 HELLO message processing		       16
	  7.2.3 Link Notification			       18
     7.3 Multipoint relay selection			       19
     7.4 Multipoint relay information declaration	       20
          7.4.1 TC message broadcast			       20
	  7.4.2 TC message processing			       23
     7.5 Routing table calculation			       25
 8. Packet Forwarding					       27
     8.1 Data packet forwarding				       27
     8.2 Topology Control (TC) packet forwarding	       27
 9. Proposed values for constants			       27
10. References						       28
11. Authors' addresses					       29

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 the mobile adhoc ad hoc networks. It
   functions operates
   as a table driven or 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 to do facilitate
   efficient flooding of its control messages in the network. In route
   calculation, these are the multipoint relays which are used to form the route towards from
   a given node to any destination in the network.

   Multipoint relays are selected by a node among the its one hop
   neighbors with
   "symmetric" "symmetric", i.e. bi-directional bi-directional, link. Therefore,
   selecting the route through multipoint relays automatically avoids
   the problems associated with data packet transfer on
   uni-directional links; like links (such as the problem of getting the
   acknowledgement for the data packets at each hop, which cannot be received if there is a uni-directional
   link in the selected route. hop)

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

2. Changes

   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 Terminology

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECCOMENDED", "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 to with an entry in any table. That 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 its the holding time expires.

   multipoint relay (MPR)

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

   multipoint relay selector (MPR-S)

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

   node

      A MANET router that 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, 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.

3.

4. Applicability Section

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

3.1.

4.1. Networking Context

   The protocol is best suited to the large and dense networks, as the
   optimization done achieved using the multipoint relays works well in
   this context. More the network is dense The larger and large, more dense a network, the more
   optimization is can be achieved as compared to the normal link state
   algorithm. OLSR uses
   the hop-by-hop routing, i.e. each node uses its
   most recent information to route the packet. So 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 the packets to the destination.

   This protocol is best suited for the networks where the traffic is
   random and sporadic between "several" nodes instead of rather than being
   almost exclusively between a small specific set of nodes of in the
   network. The
   comparative performance of the protocol with when comparing to a
   reactive protocol is
   still even better if these [source, destination]
   pairs change with
   time. These 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.

3.2.

4.2. Protocol Characteristics and Mechanisms

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

      No. It uses only bi-directional links (like in 802.11), but
      these links may be composed of oppositely directed
      uni-directional "connections".

   * 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 send a message
      containing the addresses of its the neighbors who has which have selected
      that node as a multipoint relay. This information helps enables other
      nodes to build routes to that node through these the multipoint relay
      selectors.
      relays.

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

      No. As 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 a multi-
     technology routing fabric? (if so, how?)

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

   * 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 to the
      router.

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

      Yes.

   * 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 have dependence depend on a central entity? (if so, how?)

      No. All the routers in the network have their own routing tables
      and does 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 periodically sends the information about its multipoint
      relay selectors, which helps other nodes to build routes to it.

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

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

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

      Yes, it OLSR can provide support for sleep period operation. To
      enable this feature, the protocol a node should select its multipoint relays
      from only among the nodes those neighbors which can (or agree to) store its
      packets while it is in sleep mode.

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

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

      Yes. Each interface has a unique IP address.

4.

5. Protocol Overview

   OLSR is a proactive routing protocol for mobile adhoc 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 protocol is an optimization of over
   the pure link state protocol, tailored for the mobile adhoc ad hoc networks. First,

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

   Apart from its normal periodic control messages, the

   The protocol does
   not generate extra control traffic in response MAY optimize the reactivity to link failures and
   additions. Thus it is suitable for networks with a high rate of topological changes. As changes by
   reducing the time interval for periodic control message
   transmission. Furthermore, as OLSR protocol keeps the routes for
   all the destinations in the network so network, the protocol is beneficial for the
   traffic patterns where a large subset of network nodes are communicating
   with another large subset of nodes, and where the
   [source,destination] pairs are also changing with over time. The protocol is
   particularly suited to for large and dense networks, as the
   optimization done using the multipoint relays works well in this
   context. More dense The larger and large more dense a network is, network, the more optimization is
   can be achieved as compared to the normal link state algorithm.

   The protocol is designed to work in a completely distributed manner
   and thus does not depend upon on any central entity. The protocol does
   not require a
   NOT REQUIRE reliable transmission for its control messages: each node
   sends its control messages periodically, and can therefore sustain a an
   occasional loss of some packets from time to time, which arrives packets. Such losses occur very often in
   the radio networks due to collisions or other transmission errors and
   problems. The Also, the protocol also does not need a NOT REQUIRE sequenced delivery of its messages, as each
   messages. Each control message contains a sequence number of the most recent information. So the
   re-ordering at the receiving end can not affect which is
   incremented for each message. Thus the functioning recipient of
   the protocol. a control
   packet can easily identify which information is newer - even if
   messages have been re-ordered while in transmission.

   Furthermore, it OLSR provides support for the protocol extensions such as
   sleep mode operation, which is quite advantageous for multicast-routing etc. Such extensions may be
   introduced as additions to the battery operated
   small terminals.

   OLSR protocol does not do the source routing. Instead it without breaking backwards
   compatibility with earlier versions.

   OLSR performs hop by hop routing, i.e. each node uses its most
   recent information to route the packet. Hence, when a node is moving, its Hence for OLSR to be able
   to route packets, the speed of mobile nodes should be limited such
   that its movement could their movements can be followed in tracked, at least its
   neighborhood, to correctly route the packets to the
   destination.

   The protocol by their neighborhood.

   OLSR does not require NOT REQUIRE any change in changes to the IP format of
   packets and classical IP packets. Thus
   any existing IP stack can be used as it is, since is: the protocol only impacts the
   interacts with routing table management.

5.

6. Multipoint relays Relays

   The idea of multipoint relays is to minimize the flooding of broadcast
   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, neighborhood which may retransmit its packets. This set of
   selected neighbor nodes is called the multipoint relay (MPR) set of
   that node. The neighbors of node N which are *NOT* in its MPR set, read
   receive and process the packet broadcast messages but do not retransmit the
   broadcast message messages received from node N.

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

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

   OLSR protocol relies on the selection of multipoint relays, and calculates the
   routes to a destination through these nodes, i.e. nodes. I.e. MPR nodes are
   selected as intermediate nodes. nodes in the path between a source and a
   destination. To implement this, each node in the network
   periodically broadcast the information describing which neighbors
   have selected it as a multipoint relay.  Upon receipt of this "MPR
   Selectors" 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 from source to the
   destination.

   Multipoint relays are selected among the one hop neighbors with
   "symmetric" i.e. bi-directional link. Therefore, selecting the
   route through multipoint relays automatically avoids the problems
   associated with data packet transfer on uni-directional links such
   as the problem of getting an acknowledgement for the data packets
   at each hop which cannot be received if there is a uni-directional
   link in the selected route.

6. hop.

7. Protocol functioning

   OLSR protocol carry out different functions which are required to
   perform Functioning

   In this section we describe the task details of routing. Here we discuss these functionalities the protocol
   functioning. This includes descriptions of the protocol.

6.1. Neighbor sensing

6.1.1. HELLO message broadcast

   Each node must detect format and contents
   of the neighbor nodes with which it has a direct packets being exchanged by routers, the algorithms (e.g. for
   packet handling and symmetric link. The uncertainties over radio propagation may
   make some links asymmetric. Consequently, all links must be checked
   in both directions routing table calculation) and suggested data
   structures internally in order to be considered valid.

   To accomplish this, each node periodically broadcasts its HELLO
   messages, containing the information about its neighbors and their
   link status. These control packets are transmitted in the broadcast
   mode. These are received by router.

7.1. Packet Format

   OLSR communicates using an unified packet format for all one-hop neighbors, but they are
   *not relayed* data
   related to further nodes. A HELLO message contain:

      - list of addresses of the neighbors to which there exists a
        valid symmetric link;
      - list protocol. Inspired by the concept of addresses corresponding to heard nodes, i.e., "extension
   headers" from IPv6, the
        nodes which are heard by purpose of this node (a HELLO has been received)
        but the link is not yet validated to facilitate
   extensibility of the protocol without breaking backwards
   compatibility as symmetric
   The list well as to provide an easy way of neighbors piggybacking
   different "types" of information into a single transmission. These
   packets are embedded in UDP datagrams for transmission over the HELLO packet can be partial, the rule
   being that all neighbor nodes are cited at least once within a
   predetermined refreshing period (HELLO_INTERVAL).
   network.

   The proposed format basic layout of a HELLO any packet is 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Destination Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Source Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Packet Length         |     Packet Sequence Number    Reserved for future use    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Packet  Message Type |    Unused   Broadcast   |      MPR Sequence number          Next Message         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Neighbor Address                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :                            MESSAGE                            :
   :                                                               :
   |        Neighbor Status                                                               |           Neighbor
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Address
   |        Neighbor Status  Message Type |   Broadcast   |          Next Message         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                                                               |
   :                                                               :
   :                            MESSAGE                            :
   :                                                               :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.1.1.1. Description of the fields
   :                                                               :
            (etc)

7.1.1. Packet Header

   Destination Address

      The address

      For all of the HELLO packets, this 4-bytes address field is always
      set node(s) to receive this packet. This will
      often be the broadcast address of (i.e. all nodes in the network, so that when this
      packet is transmitted, each neighbor node get this information
      and hence update its neighbor table.

   Source address

      It is set to
      neighborhood) but may also be the unicast-address of a node.

   Source Address

      The address of the node which is transmitting this HELLO packet.

   Packet Length

      This field contains A
      packet may contain messages, which originate from other nodes
      (see section 7.4). In that case, the length message itself MUST contain
      an originator address, since the source address of the HELLO packet in bytes,
      starting from
      will be the Packet Type field, i.e., length of rest address of the
      packet.

   Packet Sequence Number

      While generating node retransmitting the HELLO packet, message.

   Packet Length

      The length (in bytes) of the node will assign a unique
      identification number packet

   Reserved for future use

      MUST be set to '0000000000000000' to this packet, and will put this number
      in the Sequence Number field. This sequence number will be
      different for all in compliance with this
      version of the packets originated by that node.

   Packet Type draft.

   The Packet Type field information in the header of this packet is set equivalent to the HELLO_PACKET value.

   Unused
   information obtainable from the UDP header.

7.1.2. Extension Header

   Message Type

      This unused one byte field is indicates which type of message are to be found in
      the "MESSAGE" partition. Message types in the range of 0-127 are
      reserved for the future use.

   MPR Sequence Number messages in this draft and in
      draft-ietf-manet-olsr-extensions-00.txt.

   Broadcast

      This field indicates to a node whether the sequence number with which the most
      recent multipoint relay set message is calculated by meant for
      diffusion into the sender node.

   [Neighbor Address, Neighbor Status]

      These pairs of fields contain, one by one, all entire network. This enables a node to
      forward messages correctly, even if it doesn't recognize the addresses of
      "Message Type".

   Next Message

      This field gives the neighbor nodes present in offset where the neighbor table, along with
      their link status.

6.1.2.  HELLO message processing

   The HELLO messages permit each next "extension header"
      can be found, allowing a node to learn skip through the knowledge of its
   neighborhood up to two hops. A node maintains messages.

7.1.3. Packet Processing

   Upon receiving such a Neighbor table in
   which it records basic packet, the information obtained from protocol parser examines
   each of the HELLO messages,
   about its one hop neighbors, "extension headers". Based on the status value of the link with these
   neighbors, and a list "Message
   Type" field, the parser can determine the faith of two hop neighbors that these one hop
   neighbors give access to. The information is recorded in the
   Neighbor table as a neighbor entry, which may have data portion
   of the following
   format to record these entries:

              N_MPR_seq message:

      1.  N_addr    N_status    N_2hop_list    N_time
      2.  N_addr    N_status    N_2hop_list    N_time
      3.    ,,         ,,            ,,          ,,
   Each entry in If the table consists data are of N_addr, N_status, N_2hop_list,
   and N_time, a type which specifies that the receiving node with address N_addr can
         process, then this data is processed.

      2. Otherwise, if the "Message Type" indicates a
   one-hop neighbor type, unknown to this
         the node, the status of "Broadcast" field MUST be examined.

         2.1 If the link between them "Broadcast" field indicates that the message is N_status, and this neighbor provides access
             to the two hop
   neighbors listed in N_2hop_list. The N_status can be ASYM_LINK,
   SYM_LINK or MPR_LINK. The link status as MPR_LINK implies that the
   link with the neighbor node N_addr retransmitted (i.e. is symmetric *AND* set to 'BROADCAST'), and if
             the node
   N_addr recipient is selected as a multipoint relay MPR of the sender, then the message
             MUST be retransmitted by this the node. Each
   neighbor entry has an associated holding time N_time, upon expiry

	 2.2 Otherwise, the message SHOULD silently be dropped.

   By defining a set of message types, which MUST be recognized by all
   implementations of OLSR, it is no longer valid and hence removed. will be possible to extend the protocol
   through introduction of additional message types, while still be
   able to maintain compatibility with older implementations. The neighbor table also contains a sequence number N_MPR_seq which
   specifies that two
   REQUIRED message types for OLSR are:

        - HELLO-messages, performing the node keeping this task of neighbor table has selected
   its most recent MPR set with sensing.
        - TC-messages, performing the sequence number N_MPR_seq. Every
   time a node selects or updates its task of multipoint relay set, this
   N_MPR_seq is incremented to a higher value.

   On reception of a
	  information declaration.

   Extensions 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 message, the message broadcast

   Each node updates MUST detect the neighbor
   entry corresponding to the sender node address:

      1. If the entry already exists:

         1.1 the holding time of the entry is refreshed to
             NEIGHB_HOLD_TIME
         1.2 if the node finds its own address nodes with which it has a direct
   and symmetric link. The uncertainties over radio propagation may
   make some links asymmetric. Consequently, all links MUST be checked
   in one of the
             [Neighbor, Status] pairs both directions in the order to be considered valid.

   To accomplish this, each node broadcasts HELLO message, it updates
             the messages, containing
   information about neighbors and their link status. The link status of
   may either be "symmetric", "heard" (asymmetric) or "MPR".
   "Symmetric" indicates, that the link has been verified to the sender node as SYM_LINK if be
   bi-directional, i.e. it was ASYM_LINK before.

      2. Otherwise a new entry is recorded in the Neighbor table with:

         2.1 N_addr is set possible to transmit data in both
   directions. "Heard" indicates that the sender node address
         2.2 N_status is set to the value of ASYM_LINK (asymmetric
             link)
         2.3 N_2hop_list is filled with the list of addresses
             contained in the HELLO message in the [Neighbor, Status]
             pairs for which the Status hearing from a
   neighbor, but it is *NOT* asymmetric and which
             are not already present in confirmed that this neighbor is also
   hearing from the Neighbor table (i.e., they
             are not one-hop neighbors). If node. "MPR" indicates, that a node finds its own
             address in the [Neighbor, Status] pair, it does not
             register itself in is selected by
   the N_2hop_list, and it changes sender as multipoint relay. MPR status implies that the link status is
   symmetric too.

   These control messages are broadcast to the sender node from ASYM_LINK to
             SYM_LINK.
         2.4 N_time is set all one-hop neighbors, but
   are *not relayed* to the value further nodes. A HELLO-message contains at a
   minimum:

      - a list of NEIGHB_HOLD_TIME
   With information obtained from the HELLO messages, each node also
   construct its MPR Selector table, in addresses of neighbors, to which it puts the there exists a
        symmetric link;
      - a list of addresses of
   its one hop neighbor nodes neighbors, which has have been "heard";

      - a list of neighbors, which have been selected it as a multipoint
   relay.
        relays.

   The MPR Selector table may have the following format list of neighbors in a HELLO message can be partial (e.g. due
   to
   record message size limitations, imposed by the entries:

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

   Each entry in network), the table consists of MS_addr, MS_seq_num and
   MS_time, which specifies rule
   being that all neighbor nodes are cited at least once within a
   predetermined refreshing period (HELLO_INTERVAL).

   To accommodate for the node with address MS_addr has
   selected this node above constraints, as well as its multipoint relay with the MPR sequence
   number equal to MS_seq_num. Each entry has accommodate
   for future extensions, an associated holding
   time MS_time, upon expiry of which it is no longer valid and hence
   removed.

   A sequence number MSSN is associated approach similar to this table which specifies
   that the multipoint relay selector set of the node keeping
   this MPR Selector table overall packet
   format (see section 6.1) is most recently modified with the sequence
   number MSSN. The node modifies its MPR Selector set according to
   the information it receives in the HELLO messages, and increment
   this sequence number on each modification.

   On taken. Thus the reception proposed format of a
   HELLO message, if a node finds its own
   address in 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    |      MPR Sequence number      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Link Type   |   Reserved    |         Next Link Type        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Neighbor Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Neighbor Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                             . . .                             :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Link Type   |   Reserved    |         Next Link Type        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Neighbor Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Neighbor Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :								   :
			         (etc)

   This is sent as the [Neighbor, Status] pair data-portion of the general packet format
   described in 6.1, with the Status field equal "Message Type" set to "MPR", then it updates HELLO_MESSAGE and
   the entry corresponding broadcast field set to NO_BROADCAST.

7.2.1.1. Description of the sender
   node's address in fields

   Message Sequence Number

      While generating a HELLO message, the MPR Selector table:

      1. If node will assign a unique
      identification number to this message. This number is put into
      the entry exists already:

         1.1 if Sequence Number field. This sequence number will be
      different for all the messages originated by that node.

   MPR Sequence Number

      This field of indicates the HELLO message is
             greater than or equal sequence number corresponding to the MS_seq_num field of that
             entry, then
      most recent multipoint relay set, calculated by the MS_time sender node.

   Reserved

      This field is refreshed reserved for future usage, and MUST be set to NEIGHB_HOLD_TIME.
         1.2 if the MPR Sequence Number
      00000000 for compliance with this draft.

   Link Type

      This field of the HELLO message is
             greater than specifies the MS_seq_num field type of that entry, link the
             MS_seq_num field is updated sending node has to
      the value following list of MPR Sequence
             Number field of the HELLO message.

      2. Otherwise, neighbors. As a new entry is recorded in minimum, the MPR Selector table,
         with:

         2.1 MS_addr is set to following
      three link types are REQUIRED by OLSR:

	   - ASYM_LINK - indicating that the links between the address of sender of
	     and the HELLO
             message
         2.2 MS_seq_num is set to neighbors in the MPR Sequence Number field of following list are asymmetric
	     (i.e. the
             HELLO message
         2.3 MS_time neighbor is set to "heard").

	   - SYM_LINK - indicating that the value of NEIGHB_HOLD_TIME

6.2. Multipoint relay selection

   Each node of links between the network selects independently its own set of
   multipoint relays. Multipoint relays are used to flood sender
	     and the control
   messages of that node. The MPR set is calculated in a manner to
   contain a subset of one hop neighbors which covers all in the two hop
   neighbors. By this we mean following list are symmetric.

	   - MPR_LINK - indicating, that the union of the neighbor sets of
   all MPRs contains the entire two hop neighbor set. In order to
   build nodes in the following
	     list of have been selected by the two hop nodes sender as multipoint
	     relays.
	     (Notice: this implies, that the links from a given node, it suffices
   to track the list sender
	     of symmetric link nodes found in the HELLO
   packets received by this node (this two-hop neighbor information is
   recorded in and to the neighbor table as N_2hop_list). 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.

   Neighbor Address

      The address of a neighbor.

7.2.2.  HELLO message processing

   The HELLO messages with the link status as "MPR". The multipoint relay
   set is re-calculated when:

      - permit each node to acquire information about
   its neighborhood up to two hops. A node maintains a change Neighbor table
   in which it records the information (obtained from the HELLO
   messages) about its one hop neighbors, the status of the neighborhood is detected when either a
        symmetric link with
   these neighbors, and a neighbor list of two hop neighbors that these one hop
   neighbors give access to. The information is failed, or recorded in the
   Neighbor table as a new neighbor
        with a symmetric link is added; or
      - a change entry, which may have the following
   format:

              N_MPR_seq

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

   Each entry in the two-hop neighbor set table consists of N_addr, N_status, N_2hop_list,
   and N_time. This specifies that the node with symmetric link address N_addr is
        detected.

   The MPR set need not be optimal, however it should be small enough a
   one-hop neighbor to achieve the benefit of this node, the multipoint relays. Multipoint relays
   is an optimization status of the pure flooding mechanism; it link between them
   is not
   essential that N_status, and this neighbor provides access to the multipoint relay set two hop
   neighbors listed in N_2hop_list. The N_status can be minimal ASYM_LINK,
   SYM_LINK or optimal. But
   it is essential MPR_LINK. A link status of MPR_LINK implies that it covers the two hop nodes. By default, the
   multipoint relay set can coincide
   link with the whole neighbor set. This
   will be node N_addr is symmetric *AND* the case at network initialization. Each node will manage
   N_addr is selected as a
   dedicated sequence number in order to track the changes in its multipoint relay set. This sequence number will also appear, along
   with the MPR list, in the HELLO messages.

   We propose here a heuristic for the selection of multipoint relays
   [2]. We use the following terminology in describing by this algorithm:

      MPR(x): Multipoint relay set node. Each
   neighbor entry has an associated holding time N_time, upon
   expiration of node x which it 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) ). no longer valid and hence MUST be
   removed.

   The two hop neighbor set
              N2(x) of node x does not contain any one hop neighbor of table also contains a sequence number N_MPR_seq. This
   specifies that the node x
      D(x,y): Degree of one hop keeping this neighbor table has selected
   its most recent MPR set with the sequence number N_MPR_seq. Every
   time a node y (where y selects or updates its multipoint relay set, N_MPR_seq
   is incremented to a member
              of N(x) ), higher value. This number is defined put into the HELLO
   messages as described in 6.2.1.

   Upon receiving a HELLO message, the number of symmetric one hop
              neighbors of node y EXCLUDING updates the neighbor entry
   corresponding to the sender node x and all address:

      1. If the
              symmetric one hop neighbors entry already exists:

         1.1 the holding time of the entry is refreshed to
             NEIGHB_HOLD_TIME
         1.2 if the node x which exit also finds its own address among the addresses
             listed in N(y), i.e.,
                 D(x,y) = N(y) - x - N(x)

   The proposed heuristic is the HELLO message, it updates the status of the
             link to the sender node as follows:

      1. Start with an empty MPR(x)
      2. Calculate D(x,y), where y SYM_LINK if it was ASYM_LINK
             before.

	 1.3 the N_2hop_list of the entry is a member updated to reflect the
	     contents of N(x), for all nodes
         in N(x)
      3. First select as MPRs those nodes the HELLO-message.

      2. Otherwise, a new entry is recorded in N(x) which provide the
         "only path" Neighbor table with:

         2.1 N_addr is set 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 the address of the sender node in N(x), calculate

         2.2 N_status is set to the number value of nodes ASYM_LINK (asymmetric
             link)

         2.3 N_2hop_list is filled with the list of addresses
             contained in
             N2(x) the HELLO message which are not yet covered by MPR(x) and are
             reachable through this one hop neighbor;
         4.2 Select as have a MPR that node link type of N(x)
             SYM_LINK or MPR_LINK, and which reaches the
             maximum number of uncovered nodes are not already present
             in N2(x). In case of the Neighbor table (i.e., they are not one-hop
             neighbors).

	     If a
             tie, select that node as MPR whose D(x,y) is greater.

      5. To optimize, remove each node finds its own address in MPR(x), one at a time, and
         check if MPR(x) still covers all nodes HELLO message with a
	     link type of ASYM_LINK, SYM_LINK or MPR_LINK, it does not
	     register itself in N2(x)

   After selecting the multipoint relays from among the neighbors, N_2hop_list. Rather, it changes
	     the link status to the sender of the corresponding one hop neighbors is changed HELLO from
   SYM_LINK ASYM_LINK
	     to SYM_LINK.

	 2.4 N_time is set to MPR_LINK in the neighbor table. MPR_Seq_Num value in of NEIGHB_HOLD_TIME

   Based on the Neighbor table is also incremented by one.

6.3. Multipoint relay information declaration

6.3.1. TC Packet Broadcast

   In order to build obtained from the topology information database needed for
   routing packets, HELLO messages, each relay node broadcasts specific service
   packets called Topology Control (TC) packets. TC packets are
   forwarded like usual broadcast packets to all nodes in the network
   and take advantage of multipoint relays. Multipoint relays enable a
   better scalability of topology information [1].

   A TC message is sent by a
   node in the network at regular intervals
   to declare construct its MPR Selector set, i.e., table. In this table, the message contains node
   registers the
   list addresses of neighbors who those one hop neighbor nodes which have
   selected the sender node as a multipoint relay. The MPR Selector table may
   have the following format:

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

   Each entry in the table consists 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 (MSSN) associated equal to MS_seq_num. Each entry has an associated holding
   time MS_time, upon expiation of 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 of the node
   keeping this MPR Selector table is also sent most recently modified with the list.
   sequence number MSSN. The list of
   addresses can be partial in each TC packet due node modifies its MPR Selector set
   according to maximum size
   limitation, but parsing must be complete within a certain
   refreshing period (TC_INTERVAL). The the information diffused it receives in the
   network by these TC packets will help HELLO messages, and
   increment this sequence number upon each node to calculate its
   routing table. A node which has an empty MPR Selector set, i.e.,
   nobody has selected it as modification.

   Upon receiving a multipoint relay, does NOT generate HELLO message, if a node finds its own address in
   the
   TC packet.

   The interval between the transmission address list with a link type of two TC packets depends
   upon whether "MPR", it MUST update the
   entry corresponding to the sender node's address in the MPR
   Selector set table:

      1. If the entry already exists:

         1.1 if the MPR Sequence Number field of the HELLO message is changed
             greater than or not, since equal to the last
   TC packet transmitted. If no change occur MS_seq_num field of the
             entry in the MPR Selector set, table, then the TC packet MS_time is sent after its normal interval (TC_INTERVAL). When
   a change occur in refreshed to
             NEIGHB_HOLD_TIME.

         1.2 if the MPR Selector set, Sequence Number field of the next TC packet HELLO message is sent
   after a pre-specified minimum interval (TC_MIN_INTERVAL),
   starting from the time
             greater than the last TC packet was sent. If this much
   time has already elapsed, MS_seq_num field of that entry, the next TC packet
             MS_seq_num field is transmitted
   immediately. After sending a TC packet with that minimum interval, updated to the default value for the interval again becomes of MPR Sequence
             Number field of the normal
   interval (TC_INTERVAL) for sending TC packets, until HELLO message.

      2. Otherwise, a new entry is recorded in the MPR Selector table,
         with:

         2.1 MS_addr is set to the address of sender of the HELLO
             message

         2.2 MS_seq_num is changed again.

   The proposed format set to the MPR Sequence Number field of a TC packet the
             HELLO message

         2.3 MS_time 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Destination Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Source Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Packet Length         |    Packet Sequence Number     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Packet Type  |   Hop Count   |              MSSN             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Originator Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Multipoint Relay Selector Address               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Multipoint Relay Selector Address               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3.1.1. Description of the fields

   Destination address

      For all the TC packets, this 4-bytes address field is always set to the broadcast address value of the network, so that when this
      packet NEIGHB_HOLD_TIME

7.2.3. Link Notification

   If link layer information describing connectivity to neighboring
   nodes is diffused available (i.e. loss of connectivity such as through
   absence of an acknowledgment), this SHOULD be used in addition to
   the network, every node get this information and hence update its topology table.

   Source address

      It is set from the HELLO-messages to maintain the address of neighbor
   table and the MPR selector table.

7.3. Multipoint relay selection

   Each node *transmitting*
      this TC packet. This field should not be confused with in the
      Originator Address network selects independently its own set of
   multipoint relays. Multipoint relays are used to flood the TC packet. Whenever a control
   messages of that node
      "re-transmit" into the TC packet, this field network. The MPR set is updated to calculated
   in a way such that
      transmitter node's address.

   Packet Length

      This field it contains the length a subset of one hop neighbors which
   covers all the TC packet in bytes,
      starting from the Packet Type field, i.e., two hop neighbors. This means, that the length union of rest the
   neighbor sets of all MPRs contains the packet.

   Packet Sequence Number

      While generating entire two hop neighbor
   set. In order to build the TC packet, list of the "originator" node will
      assign two hop nodes from a unique identification number to this packet, and will
      put this number in the Sequence Number field. This sequence
      number will be different for all the packets originated by that given
   node, which will help it suffices to recognize track the duplicate reception list of symmetric link nodes found
   in the packets.

   Packet Type

      The Packet Type field HELLO messages received by this node (this two-hop neighbor
   information is set to the TC_PACKET value.

   Hop Count

      This field will contain recorded in the maximum number neighbor table as
   N_2hop_list). Multipoint relays of hops a TC packet
      can attain. Every time a TC packet is re-transmitted, this field
      is decremented given node are declared in the
   subsequent HELLOs transmitted by 1. When this field node, so that the information
   reaches zero, the TC packet
      is no more re-transmitted and is discarded.

   MPR Selector Sequence Number (MSSN)

      A sequence number is associated with multipoint relays themselves. These selected multipoint
   relays are indicated in the HELLO messages with a link status of
   "MPR". The multipoint relay
      selector set and every time a node detects is re-calculated when:

      - a change in its
      multipoint relay selector set, it increments this sequence
      number. This number the neighborhood is sent 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 this MSSN field of the TC packet
      to keep track of the most recent information. When two-hop neighborhood such that
        a node
      receives symmetric link is either detected or broken between a TC packet,
	two-hop neighbor and a neighbor.

   The MPR set needs not be optimal. However it can decide on SHOULD be small enough
   to achieve the basis benefit of this MPR
      Sequence Number, whether the information about the multipoint
      relay selectors relays. The concept of the originator node
   multipoint relays is more recent than an optimization of a pure flooding mechanism.
   It is not essential that
      it already has, the multipoint relay set be minimal or not.

   Originator Address

      This field contains
   optimal. But it is essential that all two-hop neighbors can be
   reached through the address of selected MPR's. By default, the multipoint
   relay set can coincide with the entire neighbor set. This will be
   the case at network initialization. Each node which has originally
      generated this TC packet will manage a
   dedicated sequence number in order to declare track the changes in its
   multipoint relay selector's
      information. set. This field should not be confused sequence number will also appear, along
   with the Source
      Address field, which is changed each time to MPR list, in the address of HELLO messages.

   We propose a heuristic for the
      intermediate node which is "re-transmitting" this TC packet,
      while selection of multipoint relays
   [2]. We use the Originator Address field in never changed following terminology in the
      retransmissions. describing this algorithm:

      MPR(x): Multipoint Relay Selector Address (MPR-S)

      This field contains the address relay set of the node x which has selected
      the Originator is running this
              algorithm
      N(x):   One hop neighbor set of node (of the TC packet) as a multipoint relay.
      All the x (containing only symmetric
              neighbors)
      N2(x):  Two hop neighbor set of node addresses x (containing only symmetric
              neighbors of the multipoint relay selectors nodes in N(x) ). The two hop neighbor set
              N2(x) of the
      Originator node are put in the TC packet, x does not contain any one after another. If
      the maximum allowed packet size (of IP protocol) hop neighbor of
              node x

      D(x,y): Degree of one hop neighbor node y (where y is a member
              of N(x) ), is attained defined as the number of symmetric one hop
              neighbors of node y EXCLUDING the node x and
      there are still some multipoint relay selector addresses all the
              symmetric one hop neighbors of node x which
      remain exit also
              in the MPR Selector set, then more TC packets will be
      generated, until N(y), i.e.,
                 D(x,y) = N(y) - x - N(x)

   The proposed heuristic is as follows:

      1. Start with an empty MPR(x)
      2. Calculate D(x,y), where y is a member of N(x), for all addresses nodes
         in N(x)
      3. First select as MPRs those nodes in N(x) which provide the multipoint relay selector
      set are transmitted.

6.3.2. TC Packet Processing

   In OLSR protocol, TC packets are sent
         "only path" to reach some nodes in broadcast and N2(x)
      4. While there still exist some nodes in N2(x) that are
   retransmitted not
         covered by MPR(x):

         4.1 For each node in N(x), calculate the selected number of nodes to diffuse the packet in the
   whole network. In
             N2(x) which are not yet covered by MPR(x) and are
             reachable through this process, one hop neighbor;
         4.2 Select as a MPR that node may receive more than once
   the same TC packet. To avoid the re-processing of the TC packet
   which was already received and processed, each node maintains a
   Duplicate table in N(x) which it records the information about reaches the most
   recently received TC packets. The information is recorded
             maximum number of uncovered nodes in the
   Duplicate table as N2(x). In case of a Duplicate entry. The table may have
   the following format to record these entries:

      1.  D_addr    D_seq_num    D_time
      2.  D_addr    D_seq_num    D_time
      3.    ,,          ,,         ,,
   Each entry in the table consists of D_addr, D_seq_num and D_time,
   which specifies
             tie, select that a TC packet was received from the node with
   address D_addr, having the packet sequence number as D-seq_num.
   Each Duplicate entry has an associated holding time D_time, upon
   expiry of which it MPR whose D(x,y) is no longer valid and hence removed.

   On reception of a TC packet, a greater.

      5. To optimize, remove each node checks in its Duplicate table MPR(x), one at a time, and
         check if it has already received MPR(x) still covers all nodes in N2(x)

   After selecting the same packet or not. If it finds a
   corresponding entry, multipoint relays among the packet is discarded. Otherwise, a new
   entry is recorded in neighbors, the Duplicate table for this newly received TC
   packet, and link
   status of the packet corresponding one hop neighbors is then processed further. When a node
   receives a TC packet changed from its neighbor node with an asymmetric (or
   uni-directional) link, it does not register
   SYM_LINK to MPR_LINK in the packet neighbor table. MPR_Seq_Num value in
   the
   Duplicate Neighbor table neither it processes is also incremented by one.

7.4. Multipoint relay information declaration

7.4.1. TC Message Broadcast

   In order to build the packet.

   Each topology information database needed for
   routing the packets, each relay node of broadcasts specific service
   messages called Topology Control (TC) messages. TC messages are
   forwarded, like usual broadcast messages, to all nodes in the
   network maintains and take advantage of multipoint relays. Multipoint relays
   enable a topology table, better scalability in which it
   records the distribution of topology
   information about the topology of the network obtained
   from the [1].

   A TC packets. Based on this information, the routing table message is calculated. A sent by a node records information about the multipoint
   relays of other nodes in the network in to declare its topology table as a
   topology entry, which may have MPR
   Selector set. I.e., the following format:

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

   Each entry in TC message contains the table consists list of T_dest, T_last, T_seq, and
   T_time neighbors
   which specifies that the node T_dest has have selected the sender node
   T_last as a multipoint relay and that the node T_last has announced relay. The
   sequence number (MSSN) associated with this information of its multipoint relay
   selector set is also sent with the
   sequence number T_seq. Therefore, the node T_dest list. The list of addresses can
   be reached partial in each TC message (e.g. due to message size
   limitations, imposed by the last hop through the node T_last. Each topology entry has an
   associated holding time T_time, upon expiry network), but parsing of which it is no
   longer valid and hence removed. all TC
   messages describing a nodes MPR selector set MUST be complete
   within a certain refreshing period (TC_INTERVAL). The entries in the topology table are recorded with the topology information that is exchanged among
   diffused in the network nodes through by these TC
   packets. Upon receipt of 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 packet, message.

   A node MAY transmit additional TC-messages to increase its
   reactiveness to link failures. I.e. when a change to the following procedure MPR
   selector set is
   executed detected and this change can be attributed to record the information in the topology table:

      1. If there exist some entry in the topology table whose T_last
         corresponds to the originator address of the TC packet and
         whose T_seq is greater in value a
   link failure, a TC-message MAY be transmitted after a shorter
   interval than the MSSN in the received
         packet, then no further processing TC_INTERVAL.

   The proposed format of this a TC packet message is done
         and it

    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   |                    Unused                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Originator Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Multipoint Relay Selector Address               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Multipoint Relay Selector Address               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This is silently discarded (case: packet received out sent as the data-portion of
         order).

      2. If there exist some entry the general message format
   described in 6.1, with the topology table whose T_last
         corresponds "Message Type" set to TC_MESSAGE and
   the originator address broadcast field set to BROADCAST.

7.4.1.1. Description of the fields

   Message Sequence Number

      While generating the TC packet and
         whose T_seq is lesser in value than message, the MSSN "originator" node will
      assign a unique identification number to this message, and will
      put this number in the received
         packet, then Sequence Number field. This sequence
      number will be different for all messages originated by that topology entry is removed.

      3. For each
      node, and will be used to recognize duplicate reception of the
      messages.

   MPR Selector address received in Sequence Number (MSSN)

      A sequence number is associated with the TC
         packet:

         3.1 If there exist some entry multipoint relay
      selector set. Every time a node detects a change in its
      multipoint relay selector set, it increments this sequence
      number. This number is sent in this MSSN field of the topology table whose
             T_dest corresponds TC message
      to keep track of the most recent information. When a node
      receives a TC message, it can decide on the basis of this MPR Selector address and
      Sequence Number, whether or not the
             T_last corresponds to received information about
      the originator address multipoint relay selectors of the TC
             packet, then originator node is more
      recent than what it already has.

   Hop Count

      This field will contain the holding time T_time maximum number of that topology
             entry is refreshed to TOP_HOLD_TIME.

         3.2 Otherwise, hops a new topology entry TC message
      can attain. Every time a TC message is recorded in the
             topology table whereas:

                - T_dest re-transmitted, this
      field is set to decremented by 1. When this field reaches zero, the MPR Selector address,
                - T_last TC
      message is set to no more re-transmitted and is discarded.

   Originator Address

      This field contains the originator address of the node, which has
      originally generated this TC
                  packet,
                - T_seq message. This field MUST not be
      confused with the Source Address field, which is set changed each
      time to the value address of MSSN received in the intermediate node which is
      "re-transmitting" this TC
                  packet,
                - T_time message. The Originator Address field
      is set to *never* changed in the value retransmissions.

   Multipoint Relay Selector Address (MPR-S)

      This field contains the address of TOP_HOLD_TIME.

6.4. Routing table calculation

   Each node maintains a routing table node, which allows it to route the
   packets for has selected
      the other destinations in the network. The nodes which
   receive Originator node (of the TC packet parse and store some message) as a multipoint relay.
      All addresses of the connected pairs multipoint relay selectors of form [node, source] where "nodes" are identified with the
   addresses found
      Originator node are put in the TC packet list. The routing table message. If the maximum
      allowed message size (as imposed by the network) is built
   from this database reached
      while there are still multipoint relay 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.

7.4.2. TC Message Processing

   In the OLSR protocol, TC messages are broadcasted and are
   retransmitted by tracking the connected pairs multipoint relays in a descending
   order. To find a path from a given origin order to diffuse the
   messages in the entire network. In this process, a remote node R, one
   has to find a connected pair (R,X), then MAY receive
   the same TC message more than once. To avoid re-processing of a connected pair (X,Y), TC
   message which was already received and so forth until one finds a processed, each node Y in the neighbor set of the
   origin.
   maintains a Duplicate table. In order to restrict to optimal paths, the relay nodes will
   consider only this table, the connected pairs on node records
   information about the minimal path. This
   selection can be done dynamically and with minimal storage
   facilities. The sequence numbers are used to detect connected pairs
   which have been invalidated by further topology changes. most recently received TC messages. The
   information contained is recorded in the topology database, which has not been
   refreshed is discarded. Duplicate table as Duplicate
   entries.

    The routing table is based on the information contained in the
   neighbor table and the topology table. 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 may have the following format:

      1.  R_dest    R_next    R_dist  D_addr    D_seq_num    D_time
      2.  R_dest    R_next    R_dist  D_addr    D_seq_num    D_time
      3.    ,,          ,,         ,,

   Each entry in the table consists of R_dest, R_next D_addr, D_seq_num and R_dist, D_time,
   which specifies that the node identified by R_dest is estimated to
   be R_dist hops away a TC message was received from the local node, and that the one hop
   neighbor node with
   address R_next is D_addr, having the next hop message sequence number as D-seq_num.
   Each Duplicate entry also has an associated holding 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 in the route its Duplicate table
   to R_dest. Entries are see if it has already received the same message. If it finds a
   corresponding entry, the message is discarded. Otherwise, a new
   entry is recorded in the Duplicate table for each destination
   in the network for which this newly received TC
   message, and the route message is known. All the destinations
   for processed. When a node receives a TC
   message from a neighbor node with which it has an asymmetric (or
   uni-directional) link, it neither registers the route is broken or partially known are not entered message in the table.

   This routing
   Duplicate table information is updated when

      - a change nor it processes the message.

   Each node in the neighborhood is detected concerning a
        symmetric link;
      - network maintains a route to any destination is expired (because topology table, in which it
   records the information about the
        corresponding topology entry is expired) or
      - a better (e.g. shorter) route is found for a destination.

   Therefore, of the network as
   obtained from the TC messages. Based on this information, the
   routing table is re-calculated locally each time the
   neighbor table or calculated. A node records information about the topology table or both are changed. The
   update
   multipoint relays of this routing table does not generate or trigger any
   packets to be transmitted, neither other nodes in the network, nor network in its topology
   table as a topology entry, which may have the
   one-hop neighborhood.

   The following procedure is executed to calculate (or re-calculate)
   the routing table : format:

      1. All the entries of the routing table are removed.  T_dest    T_last    T_seq    T_time
      2. The new entries are recorded  T_dest    T_last    T_seq    T_time
      3.    ,,        ,,        ,,       ,,

   Each entry in the table starting with consists of T_dest, T_last, T_seq, and
   T_time, which specifies that the one
      hop neighbors (h=1) node T_dest has selected the node
   T_last as a multipoint relay and that the destination nodes. For each neighbor
      entry node T_last has announced
   this information of its multipoint relay selector set with the
   sequence number T_seq. Therefore, the node T_dest can be reached in
   the neighbor table, whose link status is not
      asymmetric, a new route last hop through the node T_last. Each topology entry has an
   associated holding time T_time, upon expiration of which it is recorded no
   longer valid and hence MUST be removed.

   The entries in the routing topology table
      where R_dest and R_next are both set to recorded with the address of topology
   information that is exchanged through TC messages.

   Upon receiving
   a TC message, the
      neighbor and R_dist following procedure is set executed to 1.

   3. Then record the new route entries for
   information in the destination nodes h+1 hops
      away are recorded topology table:

      1. If there exist some entry in the routing table. The following procedure topology table whose T_last
         corresponds to the originator address of the TC message and
         whose T_seq is executed for each greater in value than the MSSN in the received
         message, then no further processing of h, starting with h=1 this TC message is
         performed and
      incrementing it by 1 each time. The execution will stop if no
      new is silently discarded (case: message
         received out of order).

      2. If there exist some entry in the topology table whose T_last
         corresponds to the originator address of the TC message and
         whose T_seq is recorded lesser in an iteration.

         3.1 value than the MSSN in the received
         message, then that topology entry is removed.

      3. For each topology of the MPR Selector address received in the TC
         message:

         3.1 If there exist some entry in the topology table, if its table whose
             T_dest does not correspond corresponds to R_dest of any route entry
             in the routing table AND its MPR Selector address and the
             T_last corresponds to R_dest the originator address of a route the TC
             message, then the holding time T_time of that topology
             entry whose R_dist is equal refreshed to h, then TOP_HOLD_TIME.

         3.2 Otherwise, a new
             route topology entry is recorded in the routing
             topology table where : whereas:

                - R_dest T_dest is set to T_dest; the MPR Selector address,
                - R_next T_last is set to R_next the originator address of the route entry whose
                  R_dest TC
                  message,
                - T_seq is equal set to T_last; and the value of MSSN received in the TC
                  message,
                - R_dist T_time is set to h+1.

   4. After calculating the value of TOP_HOLD_TIME.

7.5. Routing table calculation

   Each node maintains a routing table, the topology table entries which are not used in calculating the routes may be removed, if
      there is a need allows it to save memory space. Otherwise, these entries
      may provide multiple routes.

7. Packet forwarding

7.1. Data packet forwarding

   Data packets are relayed on a hop by hop basis. In route the source
   router and
   messages for the other destinations in any intermediate router, the next hop router is
   identified by network. The nodes which
   receive TC messages parse and store some of the entry connected pairs of
   form [node, source] where "nodes" are identified with the destination addresses
   found in the host TC message. The routing
   table.

   Whenever a data packet table is received built from this
   database by tracking the connected pairs in a descending order. To
   find a path from a given origin to route a remote node R, one has to find
   a destination connected pair (R,X), then a connected pair (X,Y), and
   its TTL field (in IP header) is greater than zero, the so forth
   until one finds a node must
   look at the final destination field Y in the packet. If the route is
   known, i.e. an entry is found in neighbor set of the routing table in which R_dest
   corresponds origin. In
   order to the final destination, then the packet is
   transmitted restrict to optimal paths, the next hop node. While forwarding a unicast
   packet, the originator address, and relay nodes will consider
   only the final destination address
   of connected pairs on the packets minimal path. This selection can be
   done dynamically and with minimal storage facilities. The sequence
   numbers are not changed. used to detect connected pairs which have been
   invalidated by further topology changes. The packet traverses information contained
   in the
   intermediate source and destination pair, hop by hop, until it
   reaches its final destination.

7.2. Topology Control (TC) packet forwarding

   TC packets are relayed by the multipoint relays via the
   following rule:

      A node retransmits a TC packet only when it receives its first
      copy from a node topology database, which has not been refreshed is its multipoint relay selector.

   When a TC packet
   discarded.

   The routing table is received based on the information contained in the
   neighbor table and its hop count the topology table. Therefore, if any of these
   tables is greater than
   zero, then it changed, the routing table is retransmitted by re-calculated to update the multipoint relays of
   route information about each destination in the
   sender node. Before retransmitting, network. The route
   entries are recorded in the hop count is decremented by
   one.

8. Power Conservation or Sleep mode operation

   Power conservation mode is very desirable for routing table in the low capacity,
   battery operated small terminals. With following format:

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

   Each entry in the constraint on table consists of R_dest, R_next and R_dist,
   which specifies that the power
   consumption, nodes may wish to conserve their battery power node identified by
   going into "sleep mode". The sleep mode may simply R_dest is estimated to
   be a pause in R_dist hops away from the operation of a local node, or it may be some intermittent sleep and
   wake periods of a that the one hop
   neighbor node to economically use its battery resources.

8.1. Sleep mode initiation

   When a with address R_next is the next hop node plans to go in sleep mode, it has the route
   to stop sending its
   periodic control messages:

      - HELLO messages: so that it is no more selected as a multipoint
        relay by its neighbor nodes, and
      - TC messages: so that it is no more used as an intermediate
        node while calculating a route.

   Then it looks its MPR Selector set. If this set is not empty, it
   means that some of its neighbors R_dest. Entries are using it as a multipoint
   relay, and secondly, other nodes of the network may calculate the
   route to some destinations using this node as an intermediate
   node. In this case, the node can not go into sleep mode immediately
   because it is assumed to function as a multipoint relay of some
   node. The node must wait until its MPR Selector set becomes
   empty. As the node is sending no more HELLOs, so it will not be
   selected as a multipoint relay further more, and hence the entries
   in the MPR Selector set will be expired.

   After terminating the transmission of its periodic messages, the
   node has to negotiate with its multipoint relays to keep its data
   packets while it is in sleep mode. The node has to keep only those
   MPRs in its MPR set which agree to keep its packets.

   To initiate the negotiation for the power conservation mode, the
   node has to transmit a power conservation (PC) message. This PC
   message is broadcast to one hop neighbors only with packet type
   equal to PC_PACKET. It contains the list of the MPRs of the sender
   node, along with the intended duration of the sleep period (in
   milliseconds). The Request/Reply field is set to 1 by the sender
   node who is requesting to keep its packets while it is recorded in sleep
   mode.

   The proposed format of a PC packet 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Destination Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Source Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Packet Length         |     Packet Sequence Number    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Packet Type  | Request/Reply |     Sleep period (in msec)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MPR Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MPR Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   When a node receives a PC message with Request/Reply field equal to
   1, then:

      1. if its MPR set contains the sender node's address, this
         address must be removed from the MPR set and table for each destination
   in the receiver
         must re-calculate its MPR set;
      2. if network for which the receiver route is listed as an MPR address in the PC
         message, it will decide if it can keep known. All the packets destinations
   for which the
         sender node during route is broken or partially known are not entered in
   the sleep period mentioned table.

   This routing table information is updated when
      - a change in the PC
         message:

            2.1 if it does not agree to keep sender node's packets,
                then no further processing of PC message neighborhood is done;
            2.2 otherwise, if it agrees detected concerning a
        symmetric link;
      - a route to keep the packets of any destination is expired (because the
                sender node
        corresponding topology entry is expired) or
      - a better (e.g. shorter) route is found for a destination.

   Therefore, the intended sleep mode duration,
                then:

                   2.2.1 it will add the intended sleep period time to
                         the holding routing table is re-calculated locally each time of the entry in the MPR
                         Selector
   neighbor table corresponding to or the sender
                         node's address
                   2.2.2 it will reply topology table (or both) are changed. The
   update of this routing table does not generate or trigger any
   messages to be transmitted, neither in the sender node with a PC
                         message network, nor in unicast, with the Request/Reply
                         field set to 2.
   one-hop neighborhood.

   The sleep period field will
                         be equal following procedure is executed to that in calculate (or re-calculate)
   the received PC message
                         and there will be no list routing table :

   1. All the entries of MPR Addresses.

   When the node who intends to go routing table are removed.

   2. The new entries are recorded in sleep mode receives a reply of
   its PC message from one or more of its MPRs, it should keep only
   these addresses (of the MPRs) in its table starting with the one
      hop neighbors (h=1) as the destination nodes. For each neighbor table and remove all
   others. It can now go
      entry in sleep mode.

   If the node does neighbor table, whose link status is not receive
      asymmetric, a reply after one HELLO_INTERVAL, it
   can re-send its PC message and wait for the reply. If still no
   reply new route entry is received, the node can not go in sleep mode, OR, it can go recorded in sleep mode with a risk to loose its own packets. A "sleeping"
   node does not affect the routing of packets which table
      where R_dest and R_next are not destined both set to it. In OLSR, packets are routed hop-by-hop. So the neighbor
   nodes address of the sleeping node will not send the packets to it,
      neighbor and
   will R_dist is set to 1.

   3. Then the new route entries for the packet towards its destination according to their
   own most recent information.

8.2. Wake up procedure

8.2.1. Wake up to resume activities after sleep mode

   The sleeping node must wake up before the sleep period (mentioned nodes h+1 hops
      away are recorded in its PC message) expires. It should start its normal operation,
   i.e. sending periodic HELLO and TC messages. At the same time, routing table. The following procedure
      is executed for each value of h, starting with h=1 and
      incrementing it
   should look by 1 each time. The execution will stop if no
      new entry is recorded in an iteration.

         3.1 For each topology entry in its neighbor table the addresses of topology table, if its MPR nodes
   who agreed
             T_dest does not correspond to keep R_dest of any route entry
             in the routing table AND its packets. Then it should request those
   neighbors 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 send these kept packets, by sending a PC message T_dest;
                - R_next is set to
   all R_next of them, one after another. This PC message will have the
   Request/Reply field route entry whose
                  R_dest is equal to zero T_last; and the sleep period equal to
   zero. A node who receives a PC message containing Request/Reply
   field equal
                - R_dist is set to zero h+1.

   4. After calculating the sleep period equal to zero, should send all routing table, the packets, topology table entries
      which it has kept for are not used in calculating the sender node.

   This method of requesting its kept packets to its MPRs one by one,
   when routes MUST be removed, if
      there is a node wakes up, need to save memory space. Otherwise, these entries
      may avoid the high provide multiple routes.

8. Packet forwarding

8.1. Data packet flow towards a node
   who wakes up.

   If a node A is keeping forwarding

   Data packets for any node B, and the intended
   sleep period arrives at its expiration, node A should see if are relayed on a hop by hop basis. In the
   route to node B is known, i.e. if node B is alive or not. If source
   router and in any intermediate router, the
   route next hop router is known, all the packets are send to
   identified by the node B, otherwise,
   node A will discard all packets entry of node B.

8.2.2. Wake up in the intermittent wake-and-sleep periods

   The sleeping node must wake up before the sleep period (mentioned destination in its PC message) expires. As the node intends host routing
   table.

   Whenever a data packet is received to route to re-go into sleep
   mode after a small wake up period, it does not resume sending HELLO destination and TC packets. To collect its packets from
   its MPR neighbors, it
   will send a PC message with TTL field (in IP header) is greater than zero, the node MUST
   examine the final destination field in the Destination address set to packet. If the
   broadcast address, route is
   known, i.e. an entry is found in the Request/Reply field set routing table in which R_dest
   corresponds to zero and the
   Sleep period field set to zero. There will be no list of MPR
   addresses attached final destination, then the packet is
   transmitted to the PC packet. A node who receives this PC
   message will send all next hop node. While forwarding a unicast
   packet, the packets it has kept for originator address, and the sender node final destination address
   of the PC message.

   To go again into sleep mode after processing (and replying to, if
   necessary) the packets it receives, are not changed. The packet traverses the node has to re-negotiate
   with
   intermediate source and destination pairs, hop by hop, until it
   reaches its MPRs as mentioned in section 8.1. (Future versions of final destination.

8.2. Topology Control (TC) packet forwarding

   TC packets are relayed by the
   draft may explain if sending an intermittent wake-and-sleep pattern
   in multipoint relays via the following
   rule:

      A node retransmits a TC packet only when it receives its first negotiation could avoid the repetitive negotiations).

   To end the intermittent wake-and-sleep operation, the
      copy from a node should
   follow which is its multipoint relay selector.

   When a TC packet is received with a hop count is greater than zero,
   then it is retransmitted by the procedure multipoint relays of section 8.2.1 when it wakes up. the sender
   node. Before retransmitting, the hop count 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
   TOP_HOLD_TIME    = 15 seconds
   HELLO_PACKET     = 1
   TC_PACKET        = 2
   PC_PACKET        = 3

   ASYM_LINK        = 1
   SYM_LINK         = 2
   MPR_LINK         = 3

10. 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, 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.

11.

   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

   Paul Muhlethaler

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

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

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