[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-manet-olsrv2

Mobile Ad hoc Networking (MANET)                              T. Clausen
Internet-Draft                          LIX, Ecole Polytechnique, France
Expires: February 2, 2006                                    August 2005


          The Optimized Link-State Routing Protocol version 2
                     draft-clausen-manet-olsrv2-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on February 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes version 2 of the Optimized Link State Routing
   (OLSRv2) protocol for mobile ad hoc networks.  The protocol is an
   optimization of the classical link state algorithm tailored to the
   requirements of a mobile wireless LAN.

   The key optimization of OLSRv2 is that of multipoint relays,
   providing an efficient mechanism for network-wide broadcast of link-
   state information.  A secondary optimization is, that OLSRv2 employs
   partial link-state information: each node maintains information of



Clausen                 Expires February 2, 2006                [Page 1]

Internet-Draft                   OLSRv2                      August 2005


   all destinations, but only a subset of links.  This allows that only
   select nodes diffuse link-state advertisements (i.e. reduces the
   number of network-wide broadcasts) and that these advertisements
   contain only a subset of links (i.e. reduces the size of each
   network-wide broadcast).  The partial link-state information thus
   obtained allows each OLSRv2 node to at all times maintain optimal (in
   terms of number of hops) routes to all destinations in the network.

   OLSRv2 imposes minimum requirements to the network by not requiring
   sequenced or reliable transmission of control traffic.  Furthermore,
   the only interaction between OLSRv2 and the IP stack is routing table
   management.

   OLSRv2 is particularly suitable for large and dense networks as the
   technique of MPRs works well in this context.




































Clausen                 Expires February 2, 2006                [Page 2]

Internet-Draft                   OLSRv2                      August 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
     1.2   Applicability Statement  . . . . . . . . . . . . . . . . .  7
   2.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  8
   3.  OLSRv2 Signaling Framework . . . . . . . . . . . . . . . . . . 11
     3.1   OLSRv2 Packet Format . . . . . . . . . . . . . . . . . . . 11
     3.2   OLSR Messages  . . . . . . . . . . . . . . . . . . . . . . 12
       3.2.1   Address Blocks . . . . . . . . . . . . . . . . . . . . 14
       3.2.2   TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 14
     3.3   Message Content Fragmentation  . . . . . . . . . . . . . . 15
   4.  Packet Processing and Message Forwarding . . . . . . . . . . . 17
     4.1   Processing and Forwarding Repositories . . . . . . . . . . 17
       4.1.1   Received Message Set . . . . . . . . . . . . . . . . . 17
       4.1.2   Processed Set  . . . . . . . . . . . . . . . . . . . . 17
       4.1.3   Forwarded Set  . . . . . . . . . . . . . . . . . . . . 18
       4.1.4   Relay Set  . . . . . . . . . . . . . . . . . . . . . . 18
     4.2   Fragment Set . . . . . . . . . . . . . . . . . . . . . . . 18
     4.3   Actions when Receiving an OLSRv2-Message . . . . . . . . . 19
     4.4   Message Considered for Processing  . . . . . . . . . . . . 20
     4.5   Message Considered for Forwarding  . . . . . . . . . . . . 21
   5.  Information Repositories . . . . . . . . . . . . . . . . . . . 22
     5.1   Local Link  Information Base . . . . . . . . . . . . . . . 22
       5.1.1   Link Set . . . . . . . . . . . . . . . . . . . . . . . 22
       5.1.2   2-hop Neighbor Set . . . . . . . . . . . . . . . . . . 23
       5.1.3   Neighborhood Address Association Set . . . . . . . . . 23
       5.1.4   MPR Set  . . . . . . . . . . . . . . . . . . . . . . . 23
       5.1.5   Advertised Neighbor Set  . . . . . . . . . . . . . . . 24
     5.2   Topology Information Base  . . . . . . . . . . . . . . . . 24
   6.  OLSRv2 Control Messages  . . . . . . . . . . . . . . . . . . . 25
     6.1   HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 25
     6.2   TC Messages  . . . . . . . . . . . . . . . . . . . . . . . 25
     6.3   MA Messages  . . . . . . . . . . . . . . . . . . . . . . . 25
   7.  Populating the MPR Set . . . . . . . . . . . . . . . . . . . . 26
   8.  Populating the Advertised Neighbor Set . . . . . . . . . . . . 27
   9.  HELLO Message Generation . . . . . . . . . . . . . . . . . . . 28
     9.1   HELLO Message: Message TLVs  . . . . . . . . . . . . . . . 28
     9.2   HELLO Message: Address Blocks and Address TLVs . . . . . . 28
   10.   HELLO Message Processing . . . . . . . . . . . . . . . . . . 30
     10.1  Populating the Link Set  . . . . . . . . . . . . . . . . . 30
     10.2  Populating the 2-Hop Neighbor Set  . . . . . . . . . . . . 32
     10.3  Populating the Relay Set . . . . . . . . . . . . . . . . . 33
     10.4  Neighborhood and 2-hop Neighborhood Changes  . . . . . . . 33
   11.   TC Message Generation  . . . . . . . . . . . . . . . . . . . 35
     11.1  TC Message: Message TLVs . . . . . . . . . . . . . . . . . 35
     11.2  TC Message: Address Blocks and Address TLVs  . . . . . . . 35
   12.   TC Message Processing  . . . . . . . . . . . . . . . . . . . 36



Clausen                 Expires February 2, 2006                [Page 3]

Internet-Draft                   OLSRv2                      August 2005


   13.   MA Message Generation  . . . . . . . . . . . . . . . . . . . 38
   14.   MA Message Processing  . . . . . . . . . . . . . . . . . . . 39
   15.   Routing Table Calculation  . . . . . . . . . . . . . . . . . 40
   16.   Proposed Values for Constants  . . . . . . . . . . . . . . . 43
     16.1  Message Types  . . . . . . . . . . . . . . . . . . . . . . 43
     16.2  Message Intervals  . . . . . . . . . . . . . . . . . . . . 43
     16.3  Holding Times  . . . . . . . . . . . . . . . . . . . . . . 43
     16.4  Willingness  . . . . . . . . . . . . . . . . . . . . . . . 43
   17.   Representing Time  . . . . . . . . . . . . . . . . . . . . . 44
   18.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 45
   A.  Example Heuristic for Calculating MPRs . . . . . . . . . . . . 46
   B.  Example Algorithms for Generating Control Traffic  . . . . . . 49
     B.1   Example Algorithm for Generating HELLO messages  . . . . . 49
     B.2   Example Algorithm for Generating TC messages . . . . . . . 50
   C.  Protocol and Port Number . . . . . . . . . . . . . . . . . . . 52
   D.  OLSRv2 Packet and Message Layout . . . . . . . . . . . . . . . 53
     D.1   General OLSR Packet Format . . . . . . . . . . . . . . . . 53
       D.1.1   Message TLVs . . . . . . . . . . . . . . . . . . . . . 54
       D.1.2   Address Block  . . . . . . . . . . . . . . . . . . . . 54
       D.1.3   Address Block TLV  . . . . . . . . . . . . . . . . . . 56
     D.2   Layout of OLSRv2 Specified Messages  . . . . . . . . . . . 56
       D.2.1   Layout of HELLO Messages . . . . . . . . . . . . . . . 57
       D.2.2   Layout of TC messages  . . . . . . . . . . . . . . . . 57
   E.  Node Configuration . . . . . . . . . . . . . . . . . . . . . . 59
     E.1   IPv6 Specific Considerations . . . . . . . . . . . . . . . 59
   F.  Security Considerations  . . . . . . . . . . . . . . . . . . . 60
     F.1   Confidentiality  . . . . . . . . . . . . . . . . . . . . . 60
     F.2   Integrity  . . . . . . . . . . . . . . . . . . . . . . . . 60
     F.3   Interaction with External Routing Domains  . . . . . . . . 61
     F.4   Node Identity  . . . . . . . . . . . . . . . . . . . . . . 62
   G.  Flow and Congestion Control  . . . . . . . . . . . . . . . . . 63
   H.  Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . 64
   I.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 65
   J.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 66
   K.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 67
       Intellectual Property and Copyright Statements . . . . . . . . 68














Clausen                 Expires February 2, 2006                [Page 4]

Internet-Draft                   OLSRv2                      August 2005


1.  Introduction

   The Optimized Link State Routing Protocol version 2 (OLSRv2) is
   developed for mobile ad hoc networks.  It operates as a table driven,
   proactive protocol, i.e., exchanges topology information with other
   nodes of the network regularly.  Each node selects a set of its
   neighbor nodes as "multipoint relays" (MPR).  In OLSRv2, only nodes
   that are selected as such MPRs are then responsible for forwarding
   control traffic intended for diffusion into the entire network.  MPRs
   provide an efficient mechanism for flooding control traffic by
   reducing the number of transmissions required.

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

   Nodes which have been selected as multipoint relays by some neighbor
   node(s) announce this information periodically in their control
   messages.  Thereby a node announces to the network, that it has
   reachability to the nodes which have selected it as an MPR.  Then,
   aside from being used to facilitate efficient flooding, MPRs are also
   used for route calculation from any given node to any destination in
   the network.

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

   OLSRv2 is developed to work independently from other protocols.
   Likewise, OLSRv2 makes no assumptions about the underlying link-
   layer.  However, OLSRv2 may use link-layer information and
   notifications when available and applicable.

   OLSRv2, as OLSRv1, inherits the concept of forwarding and relaying
   from HIPERLAN (a MAC layer protocol) which is standardized by ETSI
   [3].

1.1  Terminology

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this



Clausen                 Expires February 2, 2006                [Page 5]

Internet-Draft                   OLSRv2                      August 2005


   document are to be interpreted as described in RFC2119 [5].

   Additionally, this document uses the following terminology:

   node - a MANET router which implements the Optimized Link State
      Routing protocol as specified in this document.

   OLSRv2 interface - A network device participating in a MANET running
      OLSRv2.  A node may have several OLSRv2 interfaces, each interface
      assigned an unique IP address.

   neighbor - A node X is a neighbor of node Y if node Y can hear node X
      (i.e., a link exists from an OLSRv2 interface on node X to an
      OLSRv2 interface on Y).  A neighbor may also be called a 1-hop
      neighbor.

   2-hop neighbor - A node X is a 2-hop neighbor of node Y if node X is
      a neighbor of a neighbor of node Y.

   strict 2-hop neighbor - a 2-hop neighbor which is (i) not the node
      itself, (ii) not a neighbor of the node, and (iii) not a 2-hop
      neighbor only through a neighbor with willingness WILL_NEVER.

   multipoint relay (MPR) - A node which is selected by its 1-hop
      neighbor, node X, to "re-transmit" all the broadcast messages that
      it receives from X, provided that the message is not a duplicate,
      and that the time to live field of the message is greater than
      one.

   multipoint relay selector (MPR selector, MS) - A node which has
      selected its 1-hop neighbor, node X, as its multipoint relay, will
      be called an MPR selector of node X.

   link - A link is a pair of OLSRv2 interfaces from two different
      nodes, where at least one interface is able to hear (i.e. receive
      traffic from) the other.  A node is said to have a link to another
      node when one of its interfaces has a link to one of the
      interfaces of the other node.

   symmetric link - A link where both interfaces have verified they are
      able to hear the other.

   asymmetric link - A link which is not symmetric.

   symmetric 1-hop neighborhood - The symmetric 1-hop neighborhood of
      any node X is the set of nodes which have at least one symmetric
      link to X.




Clausen                 Expires February 2, 2006                [Page 6]

Internet-Draft                   OLSRv2                      August 2005


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

   symmetric strict 2-hop neighborhood - The symmetric strict 2-hop
      neighborhood of X is the set of nodes in its symmetric 2-hop
      neighborhood that are neither in its symmetric 1-hop neighborhood
      nor reachable only through a symmetric 1-hop neighbor of X with
      willingness WILL_NEVER.


1.2  Applicability Statement

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

   As OLSRv2 continuously maintains routes to all destinations in the
   network, the protocol is beneficial for traffic patterns where the
   traffic is random and sporadic between a large subset of nodes, and
   where the [source, destination] pairs are changing over time: no
   additional control traffic is generated in this situation since
   routes are maintained for all known destinations at all times.
























Clausen                 Expires February 2, 2006                [Page 7]

Internet-Draft                   OLSRv2                      August 2005


2.  Protocol Overview and Functioning

   OLSRv2 is a proactive routing protocol for mobile ad hoc networks.
   The protocol inherits the stability of a link state algorithm and has
   the advantage of having routes immediately available when needed due
   to its proactive nature.  OLSRv2 is an optimization over the
   classical link state protocol, tailored for mobile ad hoc networks.
   The main tailoring and optimizations of OLSRv2 are:

   o  periodic, unacknowledged transmission of all control messages;

   o  optimized flooding for global link-state information diffusion;

   o  partial topology maintenance -- each node will know of all
      destinations and a subset of links in the network.

   More specifically, OLSRv2 consists of the following main components:

   o  A general and flexible signaling framework, allowing for
      information exchange between OLSRv2 nodes.  This framework allows
      for both local information exchange (between neighboring nodes)
      and global information exchange using an optimized flooding
      mechanism denoted "MPR flooding".

   o  A specification of local signaling, denoted HELLO messages.  HELLO
      messages in OLSRv2 serve to:

      *  discover links to adjacent OLSR nodes;

      *  perform bidirectionality check on the discovered links;

      *  advertise neighbors and hence discover 2-hop neighbors;

      *  signal MPR selection.

      HELLO messages are emitted periodically, thereby allowing nodes to
      continuously track changes in their local neighborhoods.

   o  A specification of global signaling, denoted TC messages.  TC
      messages in OLSRv2 serve to:

      *  inject link-state information into the entire network.

      TC messages are emitted periodically, thereby allowing nodes to
      continuously track global changes in the network.

   Thus, through periodic exchange of HELLO messages, a node is able to
   acquire and maintain information about its immediate neighborhood.



Clausen                 Expires February 2, 2006                [Page 8]

Internet-Draft                   OLSRv2                      August 2005


   This includes information about immediate neighbors, as well as nodes
   which are two hops away.  By HELLO messages being exchanged
   periodically, a node learns about changes in the neighborhood (new
   nodes emerging, old nodes disappearing) without requiring explicit
   mechanisms for doing so.

   Based on the local topology information, acquired through the
   periodic exchange of HELLO messages, an OLSRv2 node is able to make
   provisions for ensuring optimized flooding, denoted "MPR flooding",
   as well as injection of link-state information into the network.
   This is done through the notion of Multipoint Relays.

   The idea of multipoint relays is to minimize the overhead of flooding
   messages in the network by reducing redundant retransmissions in the
   same region.  Each node in the network selects a set of nodes in its
   symmetric 1-hop neighborhood which may retransmit its messages.  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, receive and process broadcast messages but do not retransmit
   broadcast messages received from node N. The MPR set of a node is
   selected such that it covers (in terms of radio range) all symmetric
   strict 2-hop nodes.  The MPR set of N, denoted as MPR(N), is then an
   arbitrary subset of the symmetric 1-hop neighborhood of N which
   satisfies the following condition: every node in the symmetric strict
   2-hop neighborhood of N MUST have a symmetric link towards MPR(N).
   The smaller a MPR set, the less control traffic overhead results from
   the routing protocol. [2] gives an analysis and example of MPR
   selection algorithms.  Notice, that as long as the condition above is
   satisfied, any algorithm selecting MPR sets is acceptable in terms of
   implementation interoperability.

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

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

   Using the MPR flooding mechanism, link-state information can be
   injected into the network using TC messages: a node evaluates
   periodically if it is required to generate TC messages and, if so,
   which information is to be included in these TC messages.

   OLSRv2 is designed to work in a completely distributed manner and



Clausen                 Expires February 2, 2006                [Page 9]

Internet-Draft                   OLSRv2                      August 2005


   does not depend on any central entity.  The protocol does NOT REQUIRE
   reliable transmission of control messages: each node sends control
   messages periodically, and can therefore sustain a reasonable loss of
   some such messages.  Such losses occur frequently in radio networks
   due to collisions or other transmission problems.

   Also, OLSRv2 does NOT REQUIRE sequenced delivery of messages.  Each
   control message contains a sequence number which is incremented for
   each message.  Thus the recipient of a control message can, if
   required, easily identify which information is more recent - even if
   messages have been re-ordered while in transmission.  Furthermore,
   OLSRv2 provides support for protocol extensions such as sleep mode
   operation, multicast-routing etc.  Such extensions may be introduced
   as additions to the protocol without breaking backwards compatibility
   with earlier versions.

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
































Clausen                 Expires February 2, 2006               [Page 10]

Internet-Draft                   OLSRv2                      August 2005


3.  OLSRv2 Signaling Framework

   In OLSRv2, signaling serves as a way for a node to express its
   relationships with other nodes -- or more precisely, a control-
   message in OLSRv2 states that "the address X has the following
   special relationship with addresses W, Y and Z".  This "special
   relationship" may be advertisement of an adjacency between interface
   X and interfaces WYZ, advertisement of an associated cost,
   advertisement of selection as designated router etc.

   In an OLSRv2 MANET, signaling may be either "local", intended only
   for nodes adjacent to the originator of the signal or "global",
   intended for all nodes in the OLSRv2 MANET.

   In this section, the general mechanism employed for all OLSRv2
   signaling is described.

   This section provides abstract descriptions of message- and packet
   formats.  It is exclusively concerned with the content of messages
   and packets relevant for OLSRv2 semantics.  The precise lay-out of
   OLSRv2 control messages and packets can be found in the complementary
   Appendix D, including all details of the format of messages on the
   wire (i.e. additional necessary fields exclusively used for
   formatting and parsing, encoding of values, size of the fields,
   padding, ...).

3.1  OLSRv2 Packet Format

   OLSRv2 messages are carried in a general packet format, allowing:

   o  piggybacking of several independent messages (originated or
      forwarded) in a single transmission;

   o  external extensibility -- i.e. new message types can be introduced
      for auxiliary functions, while still being delivered and forwarded
      correctly even by nodes not capable of interpreting the message;

   o  controlled-scope diffusion of messages.

   The packet format is inherited directly from OLSRv1 [RFC3626] and
   conforms to the following specification:

   packet = <packet-length><packet seq. number>{<message>}*

   with the usual notion of "*" indicating "zero or more" occurrences of
   the preceding element, and the elements defined thus:





Clausen                 Expires February 2, 2006               [Page 11]

Internet-Draft                   OLSRv2                      August 2005


   <packet-length> is an 8 bit field, which specifies the length (in
      bytes) of the packet;

   <packet seq. number> is an 16 bit field, which specifies the packet
      sequence number (PSN), which MUST be be incremented by one each
      time a new OLSRv2 packet is transmitted.  "Wrap-around" is handled
      as described in Appendix H.  A separate Packet Sequence Number is
      maintained for each OLSRv2 interface such that packets transmitted
      over an interface are sequentially enumerated.

   <message> is the message as defined in Section 3.2.


3.2  OLSR Messages

   Signals in OLSRv2 are carried through "messages".  The primary
   content of a message is a set of addresses about which the
   originating node wishes to convey information.  These addresses may
   be divided into one or more address blocks.  Each address SHALL
   appear only once in a message.  Each address block is followed by
   zero or more TLVs, explained with more details in section
   Section 3.2.2, which convey information (e.g. cost, link-status, ...)
   about the addresses in that address block.  A message MAY also
   contain zero or more TLVs, associated with the whole message.

   Message content MAY (e.g. due to size limitations) be fragmented.
   Each fragment is transmitted such that it makes up a syntactically
   correct message (i.e. all headers are set as if each fragment is a
   message in its own right, and each message contains all message
   TLVs).  Content fragmentation is detailed in Section 3.3.

   A message has the following general layout

   message    = <msg-header><tlv-block>{<addr-block><tlv-block>}*

   msg-header = <type><vtime><msg-size><originator-address>
                <ttl><hopcount><msg-seq-number>

   tlv-block  = <tlv-length><tlv;>*

   with the usual notion of "*" indicating "zero or more" occurrences of
   the preceding element, and the elements defined thus:

   <tlv-length> is a 16 bit field, which contains the total length (in
      octets) of the immediately following TLV(s).  If no TLV follows,
      this field contains zero;





Clausen                 Expires February 2, 2006               [Page 12]

Internet-Draft                   OLSRv2                      August 2005


   <tlv> is a TLV, providing information regarding the entire message or
      the address block which it follows.  TLVs are specified in
      Section 3.2.2;

   <addr-block> is a block of addresses, with which the originator of
      the message has a special relationship.  Address blocks are
      specified in Section 3.2.1;

   <type> is an 8 bit field, which specifies the type of message;

   <vtime> is an 8 bit field, which specifies for how long time after
      reception a node MUST consider the information contained in the
      message as valid, unless a more recent update to the information
      is received;

   <msg-size> is an 8 bit field, which specifies the size of the <msg-
      header> and the following <msg-body>, counted in bytes;

   <originator-address> is the address of an interface of the node,
      which originated the message.  Each node SHOULD select one
      interface address and utilize consistently as "originator address"
      for all messages it generates;

   <ttl> is an 8 bit field, which contains the maximum number of hops a
      message will be transmitted.  Before a message is retransmitted,
      the Time To Live MUST be decremented by 1.  When a node receives a
      message with a Time To Live equal to 0 or 1, the message MUST NOT
      be retransmitted under any circumstances.  Normally, a node would
      not receive a message with a TTL of zero.

   <hopcount> is an 8 bit field, which contains the number of hops a
      message has attained.  Before a message is retransmitted, the Hop
      Count MUST be incremented by 1.  Initially, this is set to '0' by
      the originator of the message;

   <msg-seq-number> is a 16 bit field, which contains an unique number,
      generated by the originator node to uniquely identify each message
      in the network.  "Wrap-around" is handled as described in
      Appendix H.

   TLVs associated with a message or an address block SHALL be included
   in numerically ascending order within each TLV block.  Note that this
   means that all TLVs defined in this document appear before all other
   TLVs in that TLV block.


   with the elements defined thus:




Clausen                 Expires February 2, 2006               [Page 13]

Internet-Draft                   OLSRv2                      August 2005


3.2.1  Address Blocks

   An address block represents a set of addresses in a compact form.
   Assuming that an address can be specified as a sequence of bits of
   the form  'head:tail', then an address-block is a set of addresses
   sharing the same 'head' and having different 'tails'.  Specifically,
   an address block conforms to the following specification:

   address-block = {<head-length><head>{<tail>*}}

   with the usual notion of "*" indicating "zero or more" occurrences of
   the preceding element, and the elements defined thus:

   <head-length> is the number of "common leftmost bits" in a set of
      addresses, akin to a "prefix", however with the only restriction
      on the head-length that 0 <= head-length <= the length of the
      address;

   <head> is the longest sequence of leftmost bits, which the addresses
      in the address block have in common.  Akin to a prefix;

   <tail> is the sequence of bits which, when concatenated to the head,
      makes up a single, complete, unique address.

   This representation aims at providing a flexible, yet compact, way of
   representing sets of interface addresses.

3.2.2  TLVs

   A TLV is a carrier of information, relative to a message or to
   addresses in an address block.  A TLV, associated to an address-
   block, specifies some attribute(s), which associate with address(ses)
   in the address-block.  In order to provide the largest amount of
   flexibility to benefit from address aggregation as described in
   Section 3.2.1, a TLV associated to an address block can apply to:

   o  a single address in the address block;

   o  all addresses in the address block;

   o  any continuous sequence of addresses in the address block;

   Specifically, a TLV conforms to the following specification:

   tlv = <type><length><index-start><index-stop><value>

   where the elements are defined thus:




Clausen                 Expires February 2, 2006               [Page 14]

Internet-Draft                   OLSRv2                      August 2005


   <type> is an 8 bit field, which specifies the type of the TLV.  The
      two most significant bits are allocated with the following
      semantics:

   bit 7 is the "user" bit.  Types with this bit unset are defined in
      this specification or can be allocated via standards action.
      Types with this bit set are reserved for private/local use.

   bit 6 is the "multivalue" bit.  TLVs with types with this bit unset
      include a single value, which applies to each of the addresses
      defined by <index-start> and <index-stop>.  TLVs with types with
      this bit set include seperate values for each of the addresses in
      the interval defined by <index-start> and <index-stop>;

   <length> is an 8 bit field which specifies the length, counted in
      octets, of the data contained in <value>.  If the multivalue bit
      is set, this MUST be an integral multiple of (<index-stop>-<index-
      start>+1);

   <index-start> is an 8 bit field.  For a TLV associated with an
      address block, specifies the index of the first address in the
      address-block (starting at zero), for which this TLV applies.  For
      a TLV associated with a message, this field SHALL be set to zero;

   <index-stop> is an 8 bit field.  For a TLV associated with an address
      block, specifies the index of the last address in the address-
      block (starting at zero) for which this TLV applies.  For a TLV
      associated with a message, this field SHALL be set to zero;

   <value> contains a payload, of the length specified in <length>,
      which is to be processed according to the specification indexed by
      the <type> field.  If this is a TLV for an address block and the
      multivalue bit is set, this field is divided into (<index-stop>-
      <index-start>+1) equal-sized fields which are applied in turn to
      each address described by <index-start> and <index-stop>

   Two or more TLVs of the same type SHALL NOT apply to the same
   address.

3.3  Message Content Fragmentation

   An OLSRv2 messagemay be larger than is desirable to include, with the
   OLSR packet and other headers (UDP, IP) in a MAC frame.  In this case
   the TC message SHOULD be fragmented.

   An OLSRv2 message may be fragmented by dividing the address blocks
   plus following TLVs among its fragments.  It MAY be necessary to use
   more address blocks than might otherwise be chosen without



Clausen                 Expires February 2, 2006               [Page 15]

Internet-Draft                   OLSRv2                      August 2005


   fragmentation.  Each message fragment may carry any number of these
   address blocks plus following TLVs, however they must be divided in
   order, that is if the fragments are numbered from zero, then the
   address blocks should be reassembled from those in fragment 0 in
   order, followed by those in fragment 1 in order and so on.

   All message TLVs  MUST be included identically in each fragment.

   When transmitting fragmented content, each message containing a
   fragment MUST include a message TLVs of type Content Sequence Number.
   The value of this Content Sequence Number TLV is a 16 bit field
   uniquely identifying the "version" of the content of the message.  If
   the content does not have an inherent sequence number or version
   number, the value of the Content Sequence Number TLV SHOULD be set to
   the message sequence number of the message containing the first
   fragment.

   A message containing a fragment MUST include a message TLV of type
   Fragmentation.  The value of this Fragmentation TLV is a 16 bit field
   consisting  of two 8 bit sub-fields describing the number of
   fragments, and the fragment number (counting from zero).

   If the same content with the same Content Sequence Number is sent
   more than once by a node, the content MUST be fragmented and
   transmitted in identically each time it is sent.


























Clausen                 Expires February 2, 2006               [Page 16]

Internet-Draft                   OLSRv2                      August 2005


4.  Packet Processing and Message Forwarding

   Upon receiving a basic packet, a node examines each of the "message
   headers".  If the "message type" is known to the node, the message is
   processed locally according to the specifications for that message
   type -- otherwise, the message is treated as "unknown", and is
   evaluated for forwarding.

4.1  Processing and Forwarding Repositories

   The following data-structures are employed in order to ensure that a
   message is processed at most once and is forwarded at most once per
   interface of a node, and that fragmented content is treated
   correctly.

4.1.1  Received Message Set

   Each node maintains, for each OLSRv2 interface it possesses, a set of
   messages received over that interface:

      (R_addr, R_seq_number, R_time)

   where:

   R_addr is the originator address of the received message;

   R_seq_number is the message sequence number of the received message;

   R_time specifies the time at which this record expires and *MUST* be
      removed.


4.1.2  Processed Set

   Each node maintains a set of messages, which have been processed by
   the node:


      (P_addr, P_seq_number, P_time)

   where:

   P_addr is the originator address of the received message;

   P_seq_number is the message sequence number of the received message;






Clausen                 Expires February 2, 2006               [Page 17]

Internet-Draft                   OLSRv2                      August 2005


   P_time specifies the time at which this record expires and *MUST* be
      removed.


4.1.3  Forwarded Set

   Each node maintains a set of messages, which have been retransmitted/
   forwarded by the node:


      (F_addr, F_seq_number, F_time)

   where:

   F_addr is the originator address of the received message;

   F_seq_number is the message sequence number of the received message;

   F_time specifies the time at which this record expires and *MUST* be
      removed.


4.1.4  Relay Set

   A node maintains a set of neighbor interfaces, in the form of "relay
   tuples", for which it is to relay flooded messages:


      (RS_if_addr, Rs_if_time)

   where:

   RS_if_addr is the address of the neighbor interface, for which a node
      SHOULD relay flooded messages;

   RS_if_time specifies the time at which this record expires and *MUST*
      be removed.

   In a node, this is denoted the "relay set".

4.2  Fragment Set

   A node stores messages containing fragmented content in form of
   "fragment tuples" until all fragments are received and the messages
   can be processed:

           (F_message, F_time)




Clausen                 Expires February 2, 2006               [Page 18]

Internet-Draft                   OLSRv2                      August 2005


   where:

   F_message is the message containing a fragment;

   F_time specifies the time at which this record expires and MUST be
      removed.

   In a node, this is denoted the "fragment set".

4.3  Actions when Receiving an OLSRv2-Message

   Upon receiving a basic packet, a node MUST perform the following
   tasks for each encapsulated OLSRv2-message:

   1.  If the packet contains no messages (i.e., the Packet Length is
       less than or equal to the size of the packet header), the packet
       MUST silently be discarded.

   2.  If for the message TTL <= 0 or if the Originator Address of the
       message is an interface address of the receiving node, then the
       message MUST silently be dropped.

   3.  If an entry exists in the received set for the receiving
       interface, where:

       *  R_addr == the originator of the received message, AND;

       *  R_seq_number == the sequence number of the received message.

       then the message MUST be discarded

   4.  Otherwise:

       1.  Create an entry in the Received Set for the receiving
           interface with:

           +  R_addr = originator address of the received message;

           +  R_seq_number = sequence number of the received message;

           +  R_time = current time + R_HOLD_TIME.

       2.  If the message type is known to the receiving node, then:

           1.  if the message contains a message TLV of type Fragment:

               1.  if the Fragment Set contains all remaining fragments
                   necessary to reconstitute the content, the messages



Clausen                 Expires February 2, 2006               [Page 19]

Internet-Draft                   OLSRv2                      August 2005


                   containing these fragments MUST be removed from the
                   fragment set and received message MUST be considered
                   for processing according to Section 4.4;

               2.  otherwise, the message is added to the Fragment Set
                   with a F_time of XXXX (possibly replacing an
                   identical and previous received instance of the same
                   fragment of the same content).

           2.  Otherwise, if the message does not contain a message TLV
               of type Fragment,the message is considered for processing
               according to Section 4.4;

           Otherwise, if the message type is unknown to the receiving
           node, the message is considered for forwarding according to
           Section 4.5.

   Notice that known message types are not automatically considered for
   forwarding.  Forwarding of known message types MUST be specified as a
   property of processing of that message type.

4.4  Message Considered for Processing

   If a message is considered for processing, the following tasks MUST
   be performed:

   1.  If an entry exists in the Processed Set where:

       *  P_addr == the originator address of the received message, AND;

       *  P_seq_number == the sequence number of the received message.

       the message MUST be discarded.

   2.  Otherwise:

       1.  Create an entry in the Processed Set with:

           +  P_addr = originator address of the received message;

           +  P_seq_number = sequence number of the received message;

           +  P_time = current time + P_HOLD_TIME.

       2.  Process message locally, according to the specification for
           the received message type.





Clausen                 Expires February 2, 2006               [Page 20]

Internet-Draft                   OLSRv2                      August 2005


       3.  If a message of a known message type is to be forwarded, the
           algorithm in Section 4.5 MAY be performed.


4.5  Message Considered for Forwarding

   If a message is considered for forwarding, the following tasks MUST
   be performed:

   1.  If an entry exists in the Forwarded Set where:

       *  F_addr == the originator address of the received message, AND;

       *  F_seq_number == the sequence number of the received message.

       then the message MUST be discarded

   2.  Otherwise:

       1.  If an entry exists in the relay set, where:

           +  RS_if_addr == originator address of the received message

           2.  Create an entry in the Forwarded Set with:

               -  F_addr = originator address of the received message;

               -  F_seq_number = sequence number of the received
                  message;

               -  F_time = current time + F_HOLD_TIME.

           3.  Transmit the message on all OLSRv2 interfaces of the node


















Clausen                 Expires February 2, 2006               [Page 21]

Internet-Draft                   OLSRv2                      August 2005


5.  Information Repositories

   The signaling of OLSRv2 populates a set of information repositories,
   specified in this section.

5.1  Local Link  Information Base

   The local link information base stores information about links
   between local interfaces and interfaces on adjacent nodes.

5.1.1  Link Set

   A node records a set of "Link Tuples":

     (L_local_iface_addr, L_neighbor_iface_addr,
      L_SYM_time, L_ASYM_time, L_willingness, L_time).

   where:

   L_local_iface_addr is the interface address of the local node;

   L_neighbor_iface_addr is the interface address of the neighbor node ;

   L_SYM_time is the time until which the link is considered symmetric;

   L_ASYM_time is the time until which the neighbor interface is
      considered heard;

   L_willingness is the nodes willingness to be selected as MPR;

   L_time specifies when this record expires and *MUST* be removed.

              +-------------+-------------+--------------+
              | L_SYM_time  | L_ASYM_time | L_STATUS     |
              +-------------+-------------+--------------+
              | Expired     | Expired     | LOST         |
              |             |             |              |
              | Not Expired | Expired     | SYMMETRIC    |
              |             |             |              |
              | Not Expired | Not Expired | SYMMETRIC    |
              |             |             |              |
              | Expired     | Not Expired | ASYMMETRIC   |
              +-------------+-------------+--------------+

                                  Table 1

   The status of the link, denoted L_STATUS, can be derived based on the
   fields L_SYM_time and L_ASYM_time as defined in Table 1.



Clausen                 Expires February 2, 2006               [Page 22]

Internet-Draft                   OLSRv2                      August 2005


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

5.1.2  2-hop Neighbor Set

   A node records a set of "2-hop tuples"

    (N_local_iface_addr, N_neighbor_iface_addr, N_2hop_iface_addr, N_time)

   describing symmetric links between its neighbors and the symmetric
   2-hop neighborhood.

   N_local_iface_addr is the address  of the local interface over which
      the information was received;

   N_neighbor_iface_addr is the interface address of a neighbor;

   N_2hop_iface_addr is the interface address of a 2-hop neighbor with a
      symmetric link to N_neighbor_iface_addr;

      specifies the time at which the tuple expires and *MUST* be
      removed.

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

5.1.3  Neighborhood Address Association Set

   A node maintains, for each 1-hop and 2-hop neighbor with multiple
   addresses participating in the OLSRv2 network, a "Neighborhood
   Address Association Tuple", representing that "these n addresses
   belong to the same node".

       (I_neighbor_addr_list, I_time)

   I_neighbor_iface_addr_list is the list of addresses of the 1-hop or
      2-hop neighbor node;

   I_time specifies the time at which the tuple expires and *MUST* be
      removed.

   In a node, the set of Neighborhood Address Association Tuples is
   denoted the "Neighborhood Address Association Set".

5.1.4  MPR Set

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




Clausen                 Expires February 2, 2006               [Page 23]

Internet-Draft                   OLSRv2                      August 2005


5.1.5  Advertised Neighbor Set

   A node maintains a set of neighbor interface addresses, which are to
   be advertised through TC messages:

           (A_neighbor_iface_addr)

   For this set, an Advertised Neighbor Set Sequence Number (ASSN) is
   maintained.  Each time the Advertised Neighbor Set is updated, the
   ASSN MUST be incremented.

5.2  Topology Information Base

   Each node in the network maintains topology information about the
   network.

   For each destination in the network, at least one "Topology Tuple"

       (T_dest_iface_addr, T_last_iface_addr, T_seq, T_time)

   is recorded.

   T_dest_iface_addr is the interface address of a node, which may be
      reached in one hop from the node with the interface address
      T_last_iface_addr;

   T_last_iface_addr is, conversely, the last hop towards
      T_dest_iface_addr.  Typically, T_last_iface_addr is a MPR of
      T_dest_iface_addr;

   T_seq is a sequence number, and T_time specifies the time at which
      this tuple expires and *MUST* be removed.

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

















Clausen                 Expires February 2, 2006               [Page 24]

Internet-Draft                   OLSRv2                      August 2005


6.  OLSRv2 Control Messages

   OLSRv2 employs two different message types for exchanging protocol
   information.  Those are HELLO messages, which are locally scoped, and
   TC messages, which are globally scoped.

6.1  HELLO Messages

   HELLO messages are, in OLSRv2, exchanged  between neighbor nodes with
   the purpose of populating the local link information base:

   o  Link Sensing: detecting new and lost adjacent interfaces and
      performing bidirectionality check of links;

   o  2-hop Neighbor Discovery: detecting the 2-hop symmetric
      neighborhood of a node;

   o  MPR Signaling: signal MPR selection to neighbor nodes and detect
      selection of MPRs

   HELLO messages are exchanged between neighbor nodes only, i.e. they
   are never forwarded by any node.

6.2  TC Messages

   TC messages are, in OLSRv2, transmitted to the entire network with
   the purpose of populating the topology information base:

   o  Topology Discovery: ensure that information is present in each
      node describing all destinations and (at least) a sufficient
      subset of links in order to provide least-hop paths to all
      destinations.

   TC messages are exchanged within the entire network, i.e. they are
   forwarded according to the specification in section Section 4.5.

6.3  MA Messages

   MA messages are, in OLSRv2, transmitted by nodes with more than one
   address participating in the OLSRv2 network with the purpose of
   populating the Neighborhood Address Association Set (NAAS).

   MA messages are exchanged within the 2-hop neighborhood of the
   originator - i.e. are transmitted with a TTL=2 and are forwarded
   according to the specification in section Section 4.5.






Clausen                 Expires February 2, 2006               [Page 25]

Internet-Draft                   OLSRv2                      August 2005


7.  Populating the MPR Set

   Each node MUST select, from among its one-hop neighbors, a subset of
   nodes as MPR.  This subset MUST be selected such that a message
   transmitted by the node, and retransmitted by all its MPR nodes, will
   be received by all nodes 2 hops away.

   Each node selects its MPR-set individually, utilizing the information
   in then neighbor set.  Initially, a node will have an empty neighbor-
   set, thus, initially the MPR set is empty.  A node SHOULD recalculate
   its MPR set when a change is detected to the neighbor set or 2-hop
   neighbor set.

   More specifically, a node MUST calculate MPRs per interface, the
   union of the MPR sets of each interface make up the MPR set for the
   node.

   MPRs are used to flood control messages from a node into the network
   while reducing the number of retransmissions that will occur in a
   region.  Thus, the concept of MPR is an optimization of a classical
   flooding mechanism.  While it is not essential that the MPR set is
   minimal, it is essential that all strict 2-hop neighbors can be
   reached through the selected MPR nodes.  A node MUST select an MPR
   set such that any strict 2-hop neighbor is covered by at least one
   MPR node.  A node MAY select additional MPRs beyond the minimum set.
   Keeping the MPR set small ensures that the overhead of OLSRv2 is kept
   at a minimum.

   Appendix A contains an example heuristic for selecting MPRs.






















Clausen                 Expires February 2, 2006               [Page 26]

Internet-Draft                   OLSRv2                      August 2005


8.  Populating the Advertised Neighbor Set

   The Advertised Neighbor Set contains the set of neighbor addresses,
   to which a node advertises links through TC messages.  This set
   SHOULD at least contain the addresses of the MPR Selector set (i.e.
   all addresses, associated with a MPR selector through the
   Neighborhood Adverticed Address Set).  This set MAY contain
   additional neighbor addresses.

   Each time an address is removed from the Advertised Neighbor Set, the
   ASSN MUST be incremented.  When an address is added to the Advertised
   Neighbor Set, the ASSN SHOULD be incremented.







































Clausen                 Expires February 2, 2006               [Page 27]

Internet-Draft                   OLSRv2                      August 2005


9.  HELLO Message Generation

   An OLSRv2 HELLO message is composed as described in Section 3.2: a
   set of message TLVs, describing general properties of the message and
   the node emitting the HELLO, and a set of address blocks (with
   associated TLV sets), describing the links and their associated
   properties.

   OLSRv2 HELLO messages are generated and transmitted per interface,
   i.e. different HELLO messages are generated and transmitted per
   OLSRv2 interface of a node.

   OLSRv2 HELLO messages are generated and transmitted periodically,
   with a default interval between two consecutive HELLO emissions on
   the same interface of HELLO_INTERVAL.

   This section specifies the requirements, which HELLO message
   generation MUST fulfill.  An example algorithm is proposed in
   Appendix B.1.

9.1  HELLO Message: Message TLVs

   For each OLSRv2 interface a node MUST generate a HELLO message.  In
   that HELLO message, a node MAY include a message TLV as specified in
   Table 2.

 +-------------+-------------------------------------+---------------+
 | TLV Type    | TLV Value                           | Default Value |
 +-------------+-------------------------------------+---------------+
 | Willingness | willingness to be selected as MPR.  | WILL_DEFAULT  |
 +-------------+-------------------------------------+---------------+

                                  Table 2

   If a node does not advertise a Willingness TLV in HELLO messages, the
   node MUST be assumed to have a willingness of WILL_DEFAULT.

9.2  HELLO Message: Address Blocks and Address TLVs

   For each OLSRv2 interface a node MUST generate a HELLO message with
   address blocks and address TLVs according to Table 3.










Clausen                 Expires February 2, 2006               [Page 28]

Internet-Draft                   OLSRv2                      August 2005


   +---------------------------+---------------------------------------+
   | The set of neighbor       | TLV (Type = Value)                    |
   | interfaces which are....  |                                       |
   +---------------------------+---------------------------------------+
   | HEARD over the interface  | (Link Status=HEARD);                  |
   | over which the HELLO is   | (Interface=TransmittingInterface)     |
   | being transmitted         |                                       |
   |                           |                                       |
   | SYMMETRIC over the        | (Link Status=SYMMETRIC);              |
   | interface over which the  | (Interface=TransmittingInterface)     |
   | HELLO is being            |                                       |
   | transmitted               |                                       |
   |                           |                                       |
   | LOST over the interface   | (Link Status=LOST);                   |
   | over which the HELLO is   | (Interface=TransmittingInterface)     |
   | being transmitted         |                                       |
   |                           |                                       |
   | SYMMETRIC over ANY        | (Link Status=SYMMETRIC);              |
   | interface of the node     | (Interface=Other)                     |
   | other than the interface  |                                       |
   | over which the HELLO is   |                                       |
   | being transmitted         |                                       |
   |                           |                                       |
   | selected as MPR for the   | (Link Status=SYMMETRIC);              |
   | interface over which the  | (Interface=TransmittingInterface);    |
   | HELLO is transmitted      | (MPR Selection=True)                  |
   +---------------------------+---------------------------------------+

                                  Table 3






















Clausen                 Expires February 2, 2006               [Page 29]

Internet-Draft                   OLSRv2                      August 2005


10.  HELLO Message Processing

   Upon receiving a HELLO message, a node will update its local link
   information base according to the specification given in this
   section.

   For the purpose of this section, please notice the following:

   o  the "validity time" of a message is calculated from the Vtime
      field of the message header as specified in Section 17;

   o  the "originator address" refers to the address, contained in the
      "originator address" field of the OLSRv2 message header specified
      in Section 3.1;

   o  a HELLO message MUST neither be forwarded nor be recorded in the
      duplicate set;

   o  the address blocks considered exclude the originator address
      block, unless explicitly specified;

   o  a HELLO message is valid when, for each address listed in the
      address blocks:

      *  the address is associated with at least one TLV with Type=Link
         Status, AND

      *  the address is associated with at least one TLV with
         Type=Interface, AND

      *  all the TLVs with identical type, that the address is
         associated with, have identical values (e.g.
         Interface=TransmittingInterface is not compatible with
         Interface=Other for instance), AND

      *  if the address is associated with one TLV "MPR Selection=True",
         then it MUST be associated also with one TLV "Link
         Status=SYMMETRIC".

      Invalid HELLO messages are not processed.


10.1  Populating the Link Set

   Upon receiving a HELLO message, a node SHOULD update its Link Set
   with the information contained in the HELLO.  Thus, for each address,
   listed in the HELLO message address blocks (see Section 6):




Clausen                 Expires February 2, 2006               [Page 30]

Internet-Draft                   OLSRv2                      August 2005


   1.  if there exists no link tuple with

       *  L_neighbor_iface_addr == Source Address

       a new tuple is created with

       *  L_neighbor_iface_addr = Source Address;

       *  L_local_iface_addr    = Address of the interface which
          received the HELLO message;

       *  L_SYM_time            = current time - 1 (expired);

       *  L_time                = current time + validity time.

   2.  The tuple (existing or new) with:

       *  L_neighbor_iface_addr == Source Address

       is then modified as follows:

       2.  if the node finds the address of the interface, which
           received the HELLO message, in one of the address blocks
           included in message, then the tuple is modified as follows:

           1.  if the occurrence of L_local_iface_addr in the HELLO
               message is associated with a TLV with Type="Link Status"
               and value=LOST, and it is also associated with an TLV
               with Type="Interface" and Value="TransmittingInterface"
               then

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

           2.  else if the occurrence of L_local_iface_addr in the HELLO
               message is associated with a TLV with Type="Link Status"
               and value=SYMMETRIC or HEARD, and it is also associated
               with an TLV with Type="Interface" and
               Value="TransmittingInterface" then

               -  L_SYM_time = current time + validity time,

               -  L_time     = L_SYM_time + NEIGHB_HOLD_TIME.

       3.  L_ASYM_time = current time + validity time;

       4.  L_time = max(L_time, L_ASYM_time)





Clausen                 Expires February 2, 2006               [Page 31]

Internet-Draft                   OLSRv2                      August 2005


   3.  Additionally, the willingness field is updated as follows:

          If a TLV with Type="Willingness" is present in the message
          TLVs, then

          +  L_willingness = Value of the TLV

          otherwise:

          +  L_willingness = WILL_DEFAULT

   The rule for setting L_time is the following: a link losing its
   symmetry SHOULD still be advertised in HELLOs (with the remaining
   status as defined by Table 1) during at least the duration of the
   "validity time".  This  allows neighbors to detect the link breakage.

10.2  Populating the 2-Hop Neighbor Set

   Upon receiving a HELLO message from a symmetric neighbor interface, a
   node SHOULD update its 2-hop Neighbor Set.

   If the Originator Address is the L_local_iface_addr from a link tuple
   included in the Link Set with L_STATUS equal to SYMMETRIC (in other
   words: if the Originator Address is a symmetric neighbor interface)
   then the 2-hop Neighbor Set SHOULD be updated as follows:

   1.  for each address (henceforth: 2-hop neighbor address), listed in
       the HELLO message with a Link Status TLV equal to SYMMETRIC:

       1.  if the 2-hop neighbor address is an address of the receiving
           node:

              silently discard the 2-hop neighbor address.

           (in other words: a node is not its own 2-hop neighbor).

       2.  Otherwise, a 2-hop tuple is created with:

           +  N_local_iface_addr    = address of the interface over
              which the HELLO message was received;

           +  N_neighbor_iface_addr = Originator Address of the message;

           +  N_2hop_iface_addr     = 2-hop neighbor address;

           +  N_time                = current time + validity time.

           This tuple may replace an older similar tuple with same



Clausen                 Expires February 2, 2006               [Page 32]

Internet-Draft                   OLSRv2                      August 2005


           N_local_iface_addr, N_neighbor_iface_addr and
           N_2hop_iface_addr values.


10.3  Populating the Relay Set

   Upon receiving a HELLO message, if a node finds one of its own
   interface addresses, listed with an MPR TLV (indicating that the
   originator node has selected one of the receiving nodes interfaces as
   MPR), the  Relay Set SHOULD be updated as follows:

   For each address in the originator address block:

   1.  If there exists no Relay tuple with:

       *  RS_if_addr   == that address

       then a new tuple is created with:

       *  RS_if_addr   =  that address

   2.  The tuple (new or otherwise) with

       *  RS_if_addr   == that address

       is then modified as follows:

       *  RS_time       =  current time + validity time.

   Relay tuples are removed upon expiration of RS_time, or upon link
   breakage as described in Section 10.4.

10.4  Neighborhood and 2-hop Neighborhood Changes

   A change in the neighborhood is detected when:

   o  The L_SYM_time field of a link tuple expires.  This is considered
      as a link loss.

   o  A new link tuple is inserted in the Link Set with a non expired
      L_SYM_time or a tuple with expired L_SYM_time is modified so that
      L_SYM_time becomes non-expired.  This is considered as a link
      appearance if there was previously no such link tuple.

   A change in the 2-hop neighborhood is detected when a 2-hop neighbor
   tuple expires or is deleted according to section Section 10.2.

   The following processing occurs when changes in the neighborhood or



Clausen                 Expires February 2, 2006               [Page 33]

Internet-Draft                   OLSRv2                      August 2005


   the 2-hop neighborhood are detected:

   o  In case of link loss, all 2-hop tuples with

      *  N_local_iface_addr == interface address of the node where the
         link was lost

      *  N_neighbor_iface_addr == interface address of the neighbor

      MUST be deleted.

   o  In case of neighbor interface loss, if there exists no link left
      to this neighbor node, all MPR selector tuples associated with
      that neighbor are deleted.  More precisely:

      *  If there exists an entry in the neighbor address iface
         association set where

         +  I_neighbor_iface_addr_list includes the
            N_neighbor_iface_addr of the lost link tuple

         AND such has there exists a link tuple such has

         +  L_neighbor_iface_addr is one of the addresses in
            I_neighbor_iface_addr_list

         then a link to the neighbor interface was lost, but the
         neighbor node itself is still a neighbor (with another link),
         and the mpr selector set is not changed,

      *  otherwise, the neighbor node is lost, and all MPR selector
         tuples with MS_iface_addr == interface address of the neighbor
         MUST be deleted, along with any interface address associated in
         the neighbor address iface association set.

   o  The MPR set MUST be re-calculated when a link appearance or loss
      is detected, or when a change in the 2-hop neighborhood is
      detected.

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

   Additionally, proper update of the sets describing local topology
   should be made when a neighbor association address tuple has a list
   of addresses which is modified.







Clausen                 Expires February 2, 2006               [Page 34]

Internet-Draft                   OLSRv2                      August 2005


11.  TC Message Generation

   An OLSRv2 TC message is composed as described in  Section 3.2: a set
   of message TLVs, describing general properties of the message and the
   node emitting the TC, and a set of address blocks (with associated
   TLV sets), describing the links and their associated properties.

   OLSRv2 TC messages are generated and transmitted per node, i.e. the
   same TC messages are generated and transmitted on all OLSRv2
   interfaces of a node.

   OLSRv2 TC messages are generated and transmitted periodically, with a
   default interval between two consecutive TC emissions by the same
   node of TC_INTERVAL.

11.1  TC Message: Message TLVs

   Each OLSRv2 node, selected as MPR (i.e. a node with a non-empty MPR
   Selector Set) MUST generate TC messages with message TLVs according
   to the following table:

   +----------------------+----------------------+---------------------+
   | TLV Type             | TLV Value            | Default Value       |
   +----------------------+----------------------+---------------------+
   | Content Seq. no      | <the current value   | N/A                 |
   |                      | of the ASSN of the   |                     |
   |                      | node>                |                     |
   +----------------------+----------------------+---------------------+

                                  Table 4


11.2  TC Message: Address Blocks and Address TLVs

   Each OLSRv2 node, selected as MPR (i.e. a node with a non-empty MPR
   Selector Set) MUST generate TC messages with address blocks and
   address TLVs according to the following table:

   +---------------------------------+---------------------------------+
   | Addresses                       | TLVs                            |
   +---------------------------------+---------------------------------+
   | The set of neighbor interfaces, |                                 |
   | which have selected the node as |                                 |
   | MPR                             |                                 |
   +---------------------------------+---------------------------------+

                                  Table 5




Clausen                 Expires February 2, 2006               [Page 35]

Internet-Draft                   OLSRv2                      August 2005


12.  TC Message Processing

   Upon receiving a TC message, a node will update its topology
   information base according to the specification given in this
   section.

   For the purpose of this section, please notice the following:

   o  the "validity time" of a message is calculated from the Vtime
      field of the message header as specified in Section 17;

   o  the "originator address" refers to the address, contained in the
      "originator address" field of the OLSRv2 message header specified
      in Section 3.1;

   o  the ASSN of the node, originating the TC message, is recovered as
      the value of the Content Seq. no message TLV in the TC message;

   Upon receiving a TC message, a node SHOULD update its topology set as
   follows:

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

   2.  otherwise, if the TC message does not contain a message-TLV of
       type Content Seq. no., the message SHOULD be discarded;

   3.  otherwise, if there exist some tuple in the topology set where:

       T_last_iface_addr == originator address in the message AND

       T_seq > ASSN;

       then the TC message SHOULD be discarded.

   4.  The topology set is then updated in two steps:

       1.  any topology tuple where:

           T_last_iface_addr == originator address in the message AND

           T_seq < ASSN

           SHOULD be removed.

       2.  For each address, listed in the TC message:




Clausen                 Expires February 2, 2006               [Page 36]

Internet-Draft                   OLSRv2                      August 2005


           1.  if there exists a tuple in the topology set where:

               T_dest_iface_addr == advertised neighbor address, AND

               T_last_iface_addr == originator address;

               then the tuple is updated as follows:

               T_time = current time + validity time.

               (Note that necessarily: T_seq == ASSN).

           2.  Otherwise, a new topology tuple is created with:

               T_dest_iface_addr == advertised neighbor main address,
                  AND

               T_last_iface_addr == originator address in the message
                  AND

               T_seq == ASSN;






























Clausen                 Expires February 2, 2006               [Page 37]

Internet-Draft                   OLSRv2                      August 2005


13.  MA Message Generation

   An OLSRv2 MA message is composed as described in Section 3.2: a set
   of message TLVs, describing general properties of the message and the
   node emitting the MA, and a set of address blocks (with associated
   TLV sets).  These address blocks MUST list all addresses of the node
   which are participating in the OLSRv2 network.  Other addresses of
   the node MAY also be included.

   An OLSRv2 MA message describes the set of addresses, associated to a
   given node.  Nodes with a single address SHOULD NOT generate MA
   messages.  Nodes with multiple addresses, participating in the OLSRv2
   network SHOULD generate MA messages.

   OLSRv2 MA messages are generated and transmitted per node, i.e. the
   same MA messages are generated and transmitted on all OLSRv2
   interfaces of a node.

   OLSRv2 TC messages are generated and transmitted periodically, with a
   default interval between two consecutive MA emissions by the same
   node of TC_INTERVAL.






























Clausen                 Expires February 2, 2006               [Page 38]

Internet-Draft                   OLSRv2                      August 2005


14.  MA Message Processing

   Upon receiving a MA message the node SHOULD update its Neighborhood
   Address Association Set as follows:

   1.  All neighborhood address association tuples where

       *  I_neighbor_addr_list contains at least one address which is
          listed in the received MA message,

       SHOULD be removed, and a new neighborhood address association
       tuple SHOULD be created with:

       *  I_neighbor_addr_list = list of all addresses contained in the
          received MA message;

       *  I_time = current time + validity time.


































Clausen                 Expires February 2, 2006               [Page 39]

Internet-Draft                   OLSRv2                      August 2005


15.  Routing Table Calculation

   A node records a set of "routing tuples":

      (R_dest_iface_addr, R_next_iface_addr, R_dist, R_iface_addr)

   describing the next hop and distance of the path to each destination
   in the network for which a route is known.

   R_dest_iface_addr is the interface address of the destination node;

   R_next_iface_addr is the interface address of the "next hop" on the
      path towards R_dest_iface_addr;

   R_dist is the number of hops on the path to R_dest_iface_addr;

   R_iface_addr is the address of the local interface over which a
      packet MUST be sent to reach R_next_iface_addr.

   In a node, the set of routing tuples is denoted the "routing set".

   The routing set is updated when a change (an entry appearing/
   disappearing) is detected in:

   o  the link set,

   o  the neighbor address association set,

   o  the 2-hop neighbor set,

   o  the topology set,

   Updates to the routing set does not generate or trigger any messages
   to be transmitted.  The state of the routing set SHOULD, however, be
   reflected in the IP routing table by adding and removing entries from
   the routing table as appropriate.

   To construct the routing set of node X, a shortest path algorithm is
   run on the directed graph containing the arcs X -> Y where Y is any
   symmetric neighbor of X (with Link Type equal to SYM), the arcs Y ->
   Z where Y is a neighbor node with willingness different of WILL_NEVER
   and there exists an entry in the 2-hop Neighbor set with Y as
   N_neighbor_iface_addr and Z as N_2hop_iface_addr, and the arcs U ->
   V, where there exists an entry in the topology set with V as
   T_dest_iface_addr and U as T_last_iface_addr.  The graph is
   complemented with the arcs W0 -> W1 where W0 and W1 are two addresses
   of interfaces of a same neighbor (in a neighbor address association
   tuple).



Clausen                 Expires February 2, 2006               [Page 40]

Internet-Draft                   OLSRv2                      August 2005


   The following procedure is given as an example for (re-)calculating
   the routing set (with a breadth-first algorithm):

   1.  All the tuples from the routing set are removed.

   2.  The new routing tuples are added starting with the symmetric
       neighbors (h=1) as the destinations.  Thus, for each tuple in the
       link set where:

       *  L_STATUS           = SYMMETRIC

       a new routing tuple is recorded in the routing set with:

       *  R_dest_iface_addr  = L_neighbor_iface_addr, of the link tuple;

       *  R_next_iface_addr  = L_neighbor_iface_addr, of the link tuple;

       *  R_dist             = 1;

       *  R_iface_addr       = L_local_iface_addr of the link tuple.

   3.  for each neighbor address association tuple, for which two
       addresses A1 and A2 exist in I_neighbor_iface_addr_list where:

       *  there exists a routing tuple with:

          +  R_dest_iface_addr = A1

       *  there is no routing tuple with:

          +  R_dest_iface_addr = A2

       then a tuple in the routing set is created with:

       *  R_dest_iface_addr = A2;

       *  R_next_iface_addr = R_next_iface_addr of the route tuple of
          A1;

       *  R_dist            = R_dist of the route tuple of A1 (e.g. 1);

       *  R_iface_addr      = R_iface_addr of the route tuple of A1.

   4.  for each symmetric strict 2-hop neighbor where the
       N_neighbor_iface_addr has a willingness different from WILL_NEVER
       a tuple in the routing set is created with:





Clausen                 Expires February 2, 2006               [Page 41]

Internet-Draft                   OLSRv2                      August 2005


       *  R_dest_iface_addr = N_2hop_iface_addr of the 2-hop neighbor;

       *  R_next_iface_addr = the R_next_iface_addr of the route tuple
          with:

          +  R_dest_iface_addr == N_neighbor_iface_addr of the 2-hop
             tuple;

       *  R_dist            = 2;

       *  R_iface_addr      = the R_iface_addr of the route tuple with:

          +  R_dest_iface_addr == N_neighbor_iface_addr of the 2-hop
             tuple;

   5.  The new route tuples for the destination nodes h+1 hops away are
       recorded in the routing table.  The following procedure MUST be
       executed for each value of h, starting with h=2 and incrementing
       by 1 for each iteration.  The execution will stop if no new tuple
       is recorded in an iteration.

       1.  For each topology tuple in the topology set, if its
           T_dest_iface_addr does not correspond to R_dest_iface_addr of
           any route tuple in the routing set AND its T_last_iface_addr
           corresponds to R_dest_iface_addr of a route tuple whose
           R_dist is equal to h, then a new route tuple MUST be recorded
           in the routing set (if it does not already exist) where:

           +  R_dest_iface_addr = T_dest_iface_addr;

           +  R_next_iface_addr = R_next_iface_addr of the route tuple
              where:

              -  R_dest_iface_addr == T_last_iface_addr

           +  R_dist           = h+1; and

           +  R_iface_addr     = R_iface_addr of the route tuple where:

              -  R_dest_iface_addr == T_last_iface_addr.

       2.  Several topology tuples may be used to select a next hop
           R_next_iface_addr for reaching the node R_dest_iface_addr.
           When h=1, ties should be broken such that nodes with highest
           willingness and MPR selectors are preferred as next hop.






Clausen                 Expires February 2, 2006               [Page 42]

Internet-Draft                   OLSRv2                      August 2005


16.  Proposed Values for Constants

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

16.1  Message Types

   o  HELLOv2 = 5

   o  TCv2 = 6


16.2  Message Intervals

   o  HELLO_INTERVAL        = 2 seconds

   o  REFRESH_INTERVAL      = 2 seconds

   o  TC_INTERVAL           = 5 seconds


16.3  Holding Times

   o  NEIGHB_HOLD_TIME      = 3 x REFRESH_INTERVAL

   o  TOP_HOLD_TIME         = 3 x TC_INTERVAL

   o  DUP_HOLD_TIME         = 30 seconds


16.4  Willingness

   o  WILL_NEVER            = 0

   o  WILL_LOW              = 1

   o  WILL_DEFAULT          = 3

   o  WILL_HIGH             = 6

   o  WILL_ALWAYS           = 7










Clausen                 Expires February 2, 2006               [Page 43]

Internet-Draft                   OLSRv2                      August 2005


17.  Representing Time

   In HELLO messages, the 4 highest bits of the value of the TLV with
   Type="Htime" (see Appendix D.2.1) represent the mantissa (a) and the
   four lowest bits the exponent (b), yielding that the HELLO interval
   is expressed thus: C*(1+a/16)*2^b [in seconds]

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

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

   where a is the integer represented by the four highest bits of Vtime
   field and b the integer represented by the four lowest bits of Vtime
   field.  The proposed value of the scaling factor C is specified in
   Section 16


































Clausen                 Expires February 2, 2006               [Page 44]

Internet-Draft                   OLSRv2                      August 2005


18.  IANA Considerations

   OLSRv2 defines a TLV "Type" field for message TLVs and address block
   TLVs respectively.  Two new registries MUST be created for values for
   this TLV type field, with initial assignments as specified in Table 6
   and Table 7

   Assigned message TLV Types

   +--------------------+--------+-------------------------------------+
   |      Mnemonic      |  Value | Description                         |
   +--------------------+--------+-------------------------------------+
   |    Fragmentation   |    0   | Specifies behavior in case of       |
   |                    |        | content fragmentation               |
   |                    |        |                                     |
   |  Content Sequence  |    1   | A sequence number, associated with  |
   |       Number       |        | the content of the message          |
   |                    |        |                                     |
   |     Willingness    |    2   | Specifies a nodes willingness [0-7] |
   |                    |        | to act as a relay and to parttake   |
   |                    |        | in network formation                |
   +--------------------+--------+-------------------------------------+

                                  Table 6

   Assigned address block TLV Types

   +--------------------+--------+-------------------------------------+
   |      Mnemonic      |  Value | Description                         |
   +--------------------+--------+-------------------------------------+
   |     Link Status    |    0   | Specifies a given link's status     |
   |                    |        | (asymmetric, verified               |
   |                    |        | bidirectional, lost)                |
   |                    |        |                                     |
   |         MPR        |    1   | Specifies that a given address is   |
   |                    |        | selected as MPR                     |
   +--------------------+--------+-------------------------------------+

                                  Table 7

   OLSRv2 message types MUST be assigned from the OLSRv2 repository
   (HELLOv2, TCv2)









Clausen                 Expires February 2, 2006               [Page 45]

Internet-Draft                   OLSRv2                      August 2005


Appendix A.  Example Heuristic for Calculating MPRs

   The following specifies a proposed heuristic for selection of MPRs.

   In graph theory terms, MPR computation is a "set cover" problem,
   which is a difficult optimization problem, but for which an easy and
   efficient heuristics exist: the so-called "Greedy Heuristic", a
   variant of which is described here.  In simple terms, MPR computation
   constructs an MPR-set that enables a node to reach any 2-hop
   interfaces through relaying by one MPR node.

   There are several peripheral issues that the algorithm need to
   address.  The first one is that some nodes have some willingness
   WILL_NEVER.  The second one is that some nodes may have several
   interfaces.

   The algorithm hence need to be precised in the following way:

   o  All neighbor nodes with willingness equal to WILL_NEVER MUST
      ignored in the following algorithm: they are not considered as
      neighbors (hence not used as MPR), nor as 2-hop neighbors (hence
      no attempt to cover them is made).

   o  Because link sensing is performed by interface, the local network
      topology, is best described in terms of links: hence the algorithm
      is considering neighbor interfaces, and 2-hop neighbor interfaces
      (and their addresses).  Additionally, asymmetric links are
      ignored.  This is reflected in the definitions below.

   o  MPR computation is performed on each interface of the node: on
      each interface I, the node MUST select some neighbor interface, so
      that all 2-hop interfaces are reached.

   >From now on, MPR calculation will be described for one interface I
   on the node, and the following terminology will be used in describing
   the heuristics:

   neighbor interface (of I) - An interface of a neighbor to which there
      exist a symmetrical link on interface I.

   N  - the set of such neighbor interfaces

   2-hop neighbor interface (of I) An interface of a symmetric strict
      2-hop neighbor and which can be reached from a neighbor interface
      for I.






Clausen                 Expires February 2, 2006               [Page 46]

Internet-Draft                   OLSRv2                      August 2005


   N2 - the set of such 2-hop neighbor interfaces

   D(y): - the degree of a 1-hop neighbor interface y (where y is a
      member of N), is defined as the number of symmetric neighbor
      interfaces of node y which are in N2

   MPR set - the set of the neighbor interfaces selected as MPR.

   The proposed heuristic selects iteratively some interfaces from N as
   MPR in order to cover 2-hop neighbor interfaces from N2, as follows:

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

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

   3.  Add to the MPR set those interfaces in N, which are the *only*
       nodes to provide reachability to an interface in N2.  For
       example, if interface B in N2 can be reached only through a
       symmetric link to interface A in N, then add interface B to the
       MPR set.  Remove the interfaces from N2 which are now covered by
       a interface in the MPR set.

   4.  While there exist interfaces in N2 which are not covered by at
       least one interface in the MPR set:

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

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

   Other algorithms, as well as improvements over this algorithm, are
   possible.  For example:

   o  Some 2-hop neighbors may have several interfaces.  The described
      algorithm attempts to reach every such interface of the nodes.
      However, whenever information that several 2-hop interfaces are,
      in fact, interfaces of the same 2-hop neighbor, is available, it



Clausen                 Expires February 2, 2006               [Page 47]

Internet-Draft                   OLSRv2                      August 2005


      can be used: only one of the interfaces of the 2-hop neighbor
      needs to be covered.

   o  Assume that in a multiple-interface scenario there exists more
      than one link between nodes 'a' and 'b'.  If node 'a' has selected
      node 'b' as MPR for one of its interfaces, then node 'b' can be
      selected as MPR with minimal performance loss by any other
      interfaces on node 'a'.











































Clausen                 Expires February 2, 2006               [Page 48]

Internet-Draft                   OLSRv2                      August 2005


Appendix B.  Example Algorithms for Generating Control Traffic

   The proposed generation of the control messages proceeds in four
   steps.  HELLO messages, like TC messages consist essentially in a
   list of advertised addresses of neighbors (some part of the
   topology).

   Hence, a first step is to collect the set of relevant of addresses
   which are to be advertised.  Because there are a number of TLVs which
   can be associated to each address (including mandatory ones), this
   steps results into a list of addresses, each associated with a
   certain number of TLVs.

   Thus, the second step is then to regroup the addresses which share
   exactly the same TLVs (same Type and same Value), into an address
   block which will be associated with a list of TLVs.

   The third step is to pack the message header and message TLVs into a
   string of bytes.

   The fourth step consists in packing every address block obtained in
   the second step: by finding the longest common prefix of the
   addresses in the address block (the head), then, packing the list of
   the tail of the addresses into a string of bytes, followed by the
   TLVs of the address block.

   This generation method can be used for TC generation and HELLO
   generation: in each case, all what need to be specified is the
   message headers, message TLVs, and the list of each address with its
   associated TLVs.

   The message headers are identical to RFC 3626, and should be filled
   in the same way.  The orginator address block MUST include all the
   addresses of the node (including the one of chosen for originator
   address in the message header)

Appendix B.1  Example Algorithm for Generating HELLO messages

   This section proposes an algorithm for generating HELLOs
   Periodically, on every interface I, the node generates a HELLO
   message different on each interface, as follows:

   1.  First, the list of the links of the interface is collected.  It
       is the list of the link tuples where:

       *  L_local_iface_addr == address of the interface

       Each corresponding address L_neighbor_iface_addr is then



Clausen                 Expires February 2, 2006               [Page 49]

Internet-Draft                   OLSRv2                      August 2005


       advertized with the following TLVs:

       *  Type="Link Status", Value=L_STATUS, status of the link (see
          Section 5.1.1)

       *  Type="Interface" Value="TransmittingInterface"

       *  Type="MPR Selection", Value="True", if and only of the address
          L_neighbor_iface_addr is one interface address in the MPR set.

   2.  Second, if the node has several interfaces, for each address
       which was not previously advertised, and for which there exists a
       link tuple on another interface where:

       *  L_local_iface_addr is different from address of the interface
          I

       *  L_STATUS == SYMMETRIC

       the corresponding address L_neighbor_iface_addr is advertized
       with the following TLVs:

       *  Type="Link Status", Value=L_STATUS, status of the link (see
          Section 5.1.1)

       *  Type="Interface" Value="Other"

   3.  Then a HELLO message is generated using the previous method, with
       the proper headers and TLVs:

       *  a message TLV with Type="Htime" and Value=encoding of the
          HELLO generation interval, is added

       *  a message TLV with Type="Willingness" and Value=the
          willingness of the node.  If a node has a willingness of
          WILL_DEFAULT, a node SHOULD NOT include a TLV with
          type="Willingness";

       *  the message header including Vtime, which MUST be set to a
          value higher than this generation interval, typically 3 times
          the generation interval, to allow for message losses.


Appendix B.2  Example Algorithm for Generating TC messages

   Periodically, the node generates TC messages, broadcast on all the
   interfaces of the node, as follows:




Clausen                 Expires February 2, 2006               [Page 50]

Internet-Draft                   OLSRv2                      August 2005


   1.  Each A_iface_addr in the Advertised Neighbor set, will be
       included in the TC message.

   2.  The TC message is generated using the previous method with the
       proper headers, and including the mandatory TC message TLV,
       Type="ASSN" Value=the current value of the ASSN of the node.













































Clausen                 Expires February 2, 2006               [Page 51]

Internet-Draft                   OLSRv2                      August 2005


Appendix C.  Protocol and Port Number

   Packets in OLSRv2 are communicated using UDP.  Port 698 has been
   assigned by IANA for exclusive usage by the OLSR (v1 and v2)
   protocol.














































Clausen                 Expires February 2, 2006               [Page 52]

Internet-Draft                   OLSRv2                      August 2005


Appendix D.  OLSRv2 Packet and Message Layout

   This section specifies the translation from the abstract descriptions
   of OLSRv2 control signals, employed in the protocol specification,
   and the bit-layout in the control-frames actually exchanged between
   the nodes.

Appendix D.1  General OLSR Packet Format

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


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Packet Length         |    Packet Sequence Number     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Message Type |     Vtime     |         Message Size          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Originator Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Time To Live |   Hop Count   |    Message Sequence Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Number of Msg TLVs      |    Number of Address Blocks   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Msg TLV   |   Msg TLV   |                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                   +
      |                                                               |
      :                             ...                               :
      |                                                               |
      +                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   |   Msg TLV   |           Padding           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |          Originator Address Block: Addr Block 1               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                       Addr Block 2                            |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      :                                                               :
      |                                                               |
               (etc.)

   The generic packet format defined in RFC3626 encapsulates messages,



Clausen                 Expires February 2, 2006               [Page 53]

Internet-Draft                   OLSRv2                      August 2005


   similarly to OLSRv1.  OLSRv2 messages are defined as new message
   types.  These messages contain the same header as OLSRv1 messages,
   with address blocks and TLVs, as described below.

Appendix D.1.1  Message TLVs

   The TLV format (Type-Length-Value) is used to introduce information
   in a flexible way.  A message TLV associates some information
   (depending on the type) with the node/address that originated the
   message.


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |  Length     |                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                 +
      :                                    Value ...                  :
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Appendix D.1.2  Address Block

   An address block is a way of representing addresses, as well as
   information associated with addresses, in a compact and flexible way.
   The proposed format of an address block is as follows:
























Clausen                 Expires February 2, 2006               [Page 54]

Internet-Draft                   OLSRv2                      August 2005


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  # addresses  |  Addr. length | Head length |      #TLV     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      :                             Head                              :
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Tail      |       Tail      |                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                           +
      |                                                               |
      :                              ...                              :
      |                                                               |
      +                                             +-+-+-+-+-+-+-+-+-+
      |                                             |       Tail      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Addr. Block TLV | Addr. Block TLV |                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                           +
      |                                                               |
      :                             ...                               :
      |                                                               |
      +                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   | Addr. Block TLV |           Padding       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   # addresses - The number of addresses in the address block

   Addr. length - The length, in bits, of an individual address.  For
      IPv4 addresses, this field MUST be set to 32 For IPv6 addresses,
      this field MUST be set to 128

   Prefix length - The length of the common prefix of all the addresses
      in the address block. 0 <= Prefix length < Addr. length A prefix
      length of 0 indicates, that the prefix field (following) is
      absent.

   #TLV - The number of TLV's in the address block.

   Prefix The longest sequence of bits which is common among all the
      addresses, included in the address block.  This field is of a
      fixed length, as specified in the field "prefix length"

   Host The host fields specifies the unique part of all the addresses,
      included in the address block.  Indeed, letting + denote the
      concatenation operator, the expression prefix+host will yield a
      unique address.  This field os of a fixed length = "Addr. length"
      - "Prefix length"



Clausen                 Expires February 2, 2006               [Page 55]

Internet-Draft                   OLSRv2                      August 2005


   TLV A TLV carries the information, associated to one, or a set of,
      addresses in the classic type-length-value format.  This format is
      explicitly given below.

   Padding A variable-length field of all-zero's, to achieve 32-bit
      alignment of the packet.

   Note that no alignments are attempted -- all alignments happen in the
   address block listed above.

Appendix D.1.3  Address Block TLV

   Again, the TLV format (Type-Length-Value) is used to introduce
   information in a flexible way inside Address Blocks.  An Address
   Block TLV associates some information with some address(s) listed in
   the Address Block.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |  Index Start  |   Index Stop  |     Length    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Value        ...
      +-+-+-+-+-+-+-+-+


   Type This field specifies the type of the TLV.

   Addr Start This field specifies to which address the TLV applies: the
      addresses listed between Index Start and Index Stop.

   Addr Stop This field specifies to which address the TLV applies: the
      addresses listed between Index Start and Index Stop.

   Length This field specifies the length of the data contained in
      "Value"

   Value This field is a field of the length specified in Length, which
      contains data -- information, which is to be interpreted according
      to the specification by the "Type" field, and in the context given
      by the "addr#" and "Offset" fields.


Appendix D.2  Layout of OLSRv2 Specified Messages

   The message format specified for OLSRv2 allows a great deal of
   flexibility in how control messages are organized.  For example,
   while it is possible to represent a sequence of addresses as an



Clausen                 Expires February 2, 2006               [Page 56]

Internet-Draft                   OLSRv2                      August 2005


   address-block, it is also possible -- although possibly less optimal
   -- to represent the same sequence as individual addresses in an
   OLSRv2 control message.

   This section will, therefore, give an example of how OLSRv2 HELLO and
   TC messages typically can be be generated.  It is, however, important
   to keep in mind that this section presents one possible instance of
   HELLO and TC messages.

Appendix D.2.1  Layout of HELLO Messages

   HELLO TLVs

 +-------------+---------------+------------+-------------------------+
 | Type        | Scope         | Importance | Description             |
 +-------------+---------------+------------+-------------------------+
 | Status      | Address Block | MUST       | SYM, ASYM, LOST         |
 |             |               |            |                         |
 | MPR         | Address Block | MUST       | Nodes selected as MPR   |
 |             |               |            |                         |
 | Willingness | Message       | MAY        | Willingness information |
 |             |               |            |                         |
 | Htime       | Message       | MUST       | Htime information       |
 +-------------+---------------+------------+-------------------------+

                                  Table 8


Appendix D.2.2  Layout of TC messages

   TC TLVs

  +------+-------+------------+-------------------------------------+
  | Type | Scope | Importance | Description                         |
  +------+-------+------------+-------------------------------------+
  | ASSN | Msg   | MUST       | Advertised Neighbor Sequence Number |
  +------+-------+------------+-------------------------------------+

                                  Table 9












Clausen                 Expires February 2, 2006               [Page 57]

Internet-Draft                   OLSRv2                      August 2005


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  TC Msg  Type |     Vtime     |         Message Size          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Originator Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Time To Live |   Hop Count   |    Message Sequence Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Number of Msg TLVs   (1)   |  Number of Address Blocks (1) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   ANSN (Message TLV)                          |


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |# addresses(17)|Addr lgth (32) |Prefx lgth (28)|    #TLV  (2)  |


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        IP Prefix                      | Host1 |


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Host2 | Host3 | Host4 | Host5 | Host6 | Host7 | Host8 | Host9 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Host10| Host11| Host12| Host13| Host14| Host15| Host16| Host17|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Same Node (Addr. Block TLV)                |


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




















Clausen                 Expires February 2, 2006               [Page 58]

Internet-Draft                   OLSRv2                      August 2005


Appendix E.  Node Configuration

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

   When applicable, a recommended way of connecting an OLSR network to
   an existing IP routing domain is to assign an IP prefix (under the
   authority of the nodes/gateways connecting the MANET with the routing
   domain) exclusively to the OLSR area, and to configure the gateways
   statically to advertise routes to that IP sequence to nodes in the
   existing routing domain.

Appendix E.1  IPv6 Specific Considerations

   In the case of IPv6, a node's routable IP address can either be a
   global address, or a manet-local address (as described in
   draft-wakikawa-manet-ipv6).  Typically an OLSRv2 may have several
   addresses, for example: a link-local address and a routable address.
   However the link-local address is only valid within the 1-hop
   neighborhood.  It may be used to resolve neighbor state with the
   Neighbor Discovery Protocol, but routes to link-local addresses MUST
   NOT be advertized and MUST NOT be inserted in routing tables.  Only
   routable addresses are stored in routing tables, and a routable
   address MUST be used for the originator address in HELLO messages and
   in TC messages.

   OLSRv2 uses a specific flooding address (ff02::3) called the All-
   OLSRv2-Multicast address.  This address is similar to all nodes/
   routers multicast address in IPv6 specification  (i.e. ff02::1 or
   ff02::2).  The difference is that All-OLSRv2-Multicast specifies that
   intended receivers are OLSRv2 nodes.  Since the All-OLSRv2-Multicast
   address is a link-local address, the message sent to the multicast
   address can not reach further than 1 hop.  Each OLSRv2 node MUST
   process flooding packets and possibly re-flood the packets to the
   same destination (ff02::3), if they are designated forwarders.  Note
   that although ff02::3 is a link-local address, each flooded message
   MUST be transmitted with a routable address as originator address.














Clausen                 Expires February 2, 2006               [Page 59]

Internet-Draft                   OLSRv2                      August 2005


Appendix F.  Security Considerations

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

Appendix F.1  Confidentiality

   Being a proactive protocol, OLSR periodically diffuses topological
   information.  Hence, if used in an unprotected wireless network, the
   network topology is revealed to anyone who listens to OLSR control
   messages.

   In situations where the confidentiality of the network topology is of
   importance, regular cryptographic techniques such as exchange of OLSR
   control traffic messages encrypted by PGP [9] or encrypted by some
   shared secret key can be applied to ensure that control traffic can
   be read and interpreted by only those authorized to do so.

Appendix F.2  Integrity

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

   Different such situations may occur, for instance:

   1.  a node generates TC messages, advertising links to non-neighbor
       nodes;

   2.  a node generates TC messages, pretending to be another node;

   3.  a node generates HELLO messages, advertising non-neighbor nodes;

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

   5.  a node forwards altered control messages;

   6.  a node does not broadcast control messages;

   7.  a node does not select multipoint relays correctly;

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





Clausen                 Expires February 2, 2006               [Page 60]

Internet-Draft                   OLSRv2                      August 2005


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

   Authentication of the originator node for control messages (for
   situation 2, 4 and 5) and on the individual links announced in the
   control messages (for situation 1 and 3) may be used as a
   countermeasure.  However to prevent nodes from repeating old (and
   correctly authenticated) information (situation 9) temporal
   information is required, allowing a node to positively identify such
   delayed messages.

   In general, digital signatures and other required security
   information may be transmitted as a separate OLSRv2 message type,
   thereby allowing that "secured" and "unsecured" nodes can coexist in
   the same network, if desired, or signatures and security information
   may be transmitted within the OLSRv2 HELLO and TC messages, using the
   TLV mechanism.

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

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

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

Appendix F.3  Interaction with External Routing Domains

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

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



Clausen                 Expires February 2, 2006               [Page 61]

Internet-Draft                   OLSRv2                      August 2005


   being injected as to avoid polluting routing tables with invalid
   information.

   A recommended way of extending connectivity from an existing routing
   domain to an OLSRv2 routed MANET is to assign an IP prefix (under the
   authority of the nodes/gateways connecting the MANET with the exiting
   routing domain) exclusively to the OLSRv2 MANET area, and to
   configure the gateways statically to advertise routes to that IP
   sequence to nodes in the existing routing domain.

Appendix F.4  Node Identity

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





































Clausen                 Expires February 2, 2006               [Page 62]

Internet-Draft                   OLSRv2                      August 2005


Appendix G.  Flow and Congestion Control

   TBD
















































Clausen                 Expires February 2, 2006               [Page 63]

Internet-Draft                   OLSRv2                      August 2005


Appendix H.  Sequence Numbers

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

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

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

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

   o  S2 > S1 AND S2 - S1 > MAXVALUE/2

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





























Clausen                 Expires February 2, 2006               [Page 64]

Internet-Draft                   OLSRv2                      August 2005


Appendix I.  References

   o  [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.

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

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

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

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

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

   o  [7]   T. Clausen, P. Jacquet, A. Laouiti, P. Muhlethaler, A.
      Qayyum and L. Viennot.  Optimized Link State Routing Protocol.
      IEEE INMIC Pakistan 2001. [8]   Narten, T. and H. Alvestrand,
      "Guidelines for Writing an IANA Considerations Section in RFCs",
      BCP 26, RFC 2434, October 1998.

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

   o  [10]  P. Jacquet, A. Laouiti, P. Minet, L. Viennot.  Performance
      analysis of OLSR multipoint relay flooding in two ad hoc wireless
      network models, INRIA research report RR-4260, 2001.













Clausen                 Expires February 2, 2006               [Page 65]

Internet-Draft                   OLSRv2                      August 2005


Appendix J.  Contributors

   This specification is the result of the joint efforts of the
   following contributers -- listed alphabetically.

   o  Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>

   o  Emmanuel Baccelli, INRIA, France, <Emmanuel.Baccelli@inria.fr>

   o  Thomas Heide Clausen, PCRI, <T.Clausen@computer.org>

   o  Justin Dean, NRL, <jdean@itd.nrl.navy.mil>

   o  Christopher Dearlove, BAE Systems, UK,
      <Chris.Dearlove@baesystems.com>

   o  Satoh Hiroki, Hitachi SDL, Japan, <h-satoh@sdl.hitachi.co.jp>

   o  Monden Kazuya, Hitachi SDL, Japan, <monden@sdl.hitachi.co.jp>

   o  Kenichi Mase, University, Japan, <mase@ie.niigata-u.ac.jp>

   o  Ryuji Wakikawa, KEIO University, Japan, <ryuji@sfc.wide.ad.jp>




























Clausen                 Expires February 2, 2006               [Page 66]

Internet-Draft                   OLSRv2                      August 2005


Appendix K.  Acknowledgements

   The authors would like to acknowledge the team behind OLSRv1,
   specified in RFC3626, including Paul Muhlethaler, Philippe Jacquet,
   Anis Laouiti, Pascale Minet, Laurent Viennot (all at INRIA, France),
   and Amir Qayuum (Center for Advanced Research in Engineering) for
   their contributions.

   The authors would like to gratefully acknowledge the following people
   for intense technical discussions, early reviews and comments on the
   specification and its components: Kenichi Mase (Niigata University),
   Li Li (CRC), Louise Lamont (CRC), Joe Macker (NRL), Alan Cullen (BAE
   Systems), Philippe Jacquet (INRIA), Khaldoun Al Agha (LRI), Richard
   Ogier (?), Song-Yean Cho (Samsung Software Center), Shubhranshu Singh
   (Samsung AIT) and the entire IETF MANET working group.


Author's Address

   Thomas Heide Clausen
   LIX, Ecole Polytechnique, France

   Phone: +33 6 6058 9349
   Email: T.Clausen@computer.org
   URI:   http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/


























Clausen                 Expires February 2, 2006               [Page 67]

Internet-Draft                   OLSRv2                      August 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

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




Clausen                 Expires February 2, 2006               [Page 68]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/