draft-ietf-manet-olsr-06.txt   draft-ietf-manet-olsr-07.txt 
INTERNET-DRAFT Thomas Clausen INTERNET-DRAFT Thomas Clausen
IETF MANET Working Group Philippe Jacquet IETF MANET Working Group Philippe Jacquet
Expiration: 1 September 2002 Anis Laouiti Expiration: 10 June 2003 Anis Laouiti
Pascale Minet Pascale Minet
Paul Muhlethaler Paul Muhlethaler
Amir Qayyum Amir Qayyum
Laurent Viennot Laurent Viennot
INRIA Rocquencourt, France INRIA Rocquencourt, France
1 September 2001 10 December 2002
Optimized Link State Routing Protocol Optimized Link State Routing Protocol
draft-ietf-manet-olsr-06.txt draft-ietf-manet-olsr-07.txt
Status of this Memo Status of this Memo
This document is a submission by the Mobile Ad Hoc Networking Working This document is a submission by the Mobile Ad Hoc Networking Working
Group of the Internet Engineering Task Force (IETF). Comments should Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the manet@itd.nrl.navy.mil mailing list. be submitted to the manet@itd.nrl.navy.mil mailing list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
skipping to change at page 2, line 8 skipping to change at page 2, line 9
Abstract Abstract
This document describes the Optimized Link State Routing (OLSR) This document describes the Optimized Link State Routing (OLSR)
protocol for mobile ad hoc networks. The protocol is an optimization protocol for mobile ad hoc networks. The protocol is an optimization
of the classical link state algorithm tailored to the requirements of of the classical link state algorithm tailored to the requirements of
a mobile wireless LAN. The key concept used in the protocol is that a mobile wireless LAN. The key concept used in the protocol is that
of multipoint relays (MPRs) [1], [2]. MPRs are selected nodes which of multipoint relays (MPRs) [1], [2]. MPRs are selected nodes which
forward broadcast messages during the flooding process. This forward broadcast messages during the flooding process. This
technique substantially reduces the message overhead as compared to a technique substantially reduces the message overhead as compared to a
classical flooding mechanism, where every node retransmits each classical flooding mechanism, where every node retransmits each
message when it receives the first copy of the message. In OLSR, message when it receives the first copy of the message. In OLSR, link
information flooded in the network "through" these MPRs is also state information is generated only by nodes elected as MPRs. Thus, a
"about" the MPRs. Thus, a second optimization is achieved by second optimization is achieved by minimizing the number of control
minimizing the "contents" of the control messages flooded in the messages flooded in the network. As a third optimization, an MPR node
network. Hence, as contrary to the classic link state algorithm, a may chose to report only links between itself and its MPR selectors.
node declares only a small subset of links to its neighbor nodes, Hence, as contrary to the classic link state algorithm, partial link
rather than all links to all neighbors. This information is then used state information is distributed in the network. This information is
by the OLSR protocol for route calculation. As a consequence hereof, then used by the OLSR protocol for route calculation. OLSR provides
routes contain only the MPRs as intermediate nodes from a Source to a optimal routes (in terms of number of hops). The protocol is
Destination. OLSR provides optimal routes (in terms of number of particularly suitable for large and dense networks as the technique
hops). The protocol is particularly suitable for large and dense of MPRs works well in this context.
networks as the technique of MPRs works well in this context.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. OLSR Terminology . . . . . . . . . . . . . . . . . . . . . 5 1.2. OLSR Terminology . . . . . . . . . . . . . . . . . . . . . 6
1.3. Applicability Section . . . . . . . . . . . . . . . . . . 7 1.3. Applicability Section . . . . . . . . . . . . . . . . . . 8
1.4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8 1.4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 8
1.5. Multipoint Relays . . . . . . . . . . . . . . . . . . . . 9 1.5. Multipoint Relays . . . . . . . . . . . . . . . . . . . . 9
2. Protocol Functioning . . . . . . . . . . . . . . . . . . . . 10 2. Protocol Functioning . . . . . . . . . . . . . . . . . . . . 10
2.1. Packet Format and Forwarding . . . . . . . . . . . . . . . 10 2.1. Packet Format and Forwarding . . . . . . . . . . . . . . . 10
2.1.1. Protocol and Port Number . . . . . . . . . . . . . . . . 11 2.1.1. Protocol and Port Number . . . . . . . . . . . . . . . . 11
2.1.2. Multiple Interfaces and Main Address . . . . . . . . . . 11 2.1.2. Multiple Interfaces and Main Address . . . . . . . . . . 11
2.1.3. Packet Format . . . . . . . . . . . . . . . . . . . . . 11 2.1.3. Packet Format . . . . . . . . . . . . . . . . . . . . . 12
2.1.3.1. Packet Header . . . . . . . . . . . . . . . . . . . . 12 2.1.3.1. Packet Header . . . . . . . . . . . . . . . . . . . . 12
2.1.3.2. Message Header . . . . . . . . . . . . . . . . . . . . 12 2.1.3.2. Message Header . . . . . . . . . . . . . . . . . . . . 13
2.1.4. Packet Processing and Message Flooding . . . . . . . . . 14 2.1.4. Packet Processing and Message Flooding . . . . . . . . . 14
2.1.5. Message Emission and Jitter . . . . . . . . . . . . . . 16 2.1.5. Message Emission and Jitter . . . . . . . . . . . . . . 16
2.2. Neighbor Sensing . . . . . . . . . . . . . . . . . . . . . 17 2.2. Neighbor Sensing . . . . . . . . . . . . . . . . . . . . . 17
2.2.1. HELLO Message Format . . . . . . . . . . . . . . . . . . 18 2.2.1. HELLO Message Format . . . . . . . . . . . . . . . . . . 18
2.2.2. Neighbor Sensing Information Base . . . . . . . . . . . 20 2.2.2. Neighbor Sensing Information Base . . . . . . . . . . . 21
2.2.2.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . 20 2.2.2.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . 21
2.2.2.2. 2-hop Neighbor Set . . . . . . . . . . . . . . . . . . 21 2.2.2.2. 2-hop Neighbor Set . . . . . . . . . . . . . . . . . . 21
2.2.2.3. MPR Set . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.2.3. MPR Set . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.2.4. MPR Selector Set . . . . . . . . . . . . . . . . . . . 21 2.2.2.4. MPR Selector Set . . . . . . . . . . . . . . . . . . . 22
2.2.3. HELLO Message Generation . . . . . . . . . . . . . . . . 22 2.2.3. HELLO Message Generation . . . . . . . . . . . . . . . . 22
2.2.4. HELLO Message Processing . . . . . . . . . . . . . . . . 23 2.2.4. HELLO Message Processing . . . . . . . . . . . . . . . . 23
2.2.5. Multipoint Relay Selection . . . . . . . . . . . . . . . 27 2.2.5. Multipoint Relay Selection . . . . . . . . . . . . . . . 27
2.2.5.1. Neighborhood and 2-hop Neighborhood Changes . . . . . 29 2.2.6. Neighborhood and 2-hop Neighborhood Changes . . . . . . 30
2.2.6. Advanced Neighbor Sensing Functioning . . . . . . . . . 30 2.2.7. Advanced Neighbor Sensing Functioning . . . . . . . . . 30
2.2.6.1. Link Hysteresis . . . . . . . . . . . . . . . . . . . 31 2.2.7.1. Link Hysteresis . . . . . . . . . . . . . . . . . . . 32
2.2.6.2. Optional Link layer notification . . . . . . . . . . . 32 2.2.7.2. Optional Link layer notification . . . . . . . . . . . 33
2.3. Topology Discovery . . . . . . . . . . . . . . . . . . . . 33 2.3. Topology Discovery . . . . . . . . . . . . . . . . . . . . 34
2.3.1. TC Message Format . . . . . . . . . . . . . . . . . . . 33 2.3.1. TC Message Format . . . . . . . . . . . . . . . . . . . 34
2.3.2. Topology Information Base . . . . . . . . . . . . . . . 34 2.3.2. Topology Information Base . . . . . . . . . . . . . . . 35
2.3.3. TC Message Generation . . . . . . . . . . . . . . . . . 35 2.3.3. Advertized Neighbor Set . . . . . . . . . . . . . . . . 35
2.3.4. TC Message Processing . . . . . . . . . . . . . . . . . 35 2.3.4. TC Message Generation . . . . . . . . . . . . . . . . . 36
2.3.5. Multiple Interface Association . . . . . . . . . . . . . 37 2.3.5. TC Message Processing . . . . . . . . . . . . . . . . . 37
2.3.5.1. Multiple Interface Association Information Base . . . 37 2.3.6. Multiple Interface Association . . . . . . . . . . . . . 39
2.3.5.2. MID Message Format . . . . . . . . . . . . . . . . . . 37 2.3.6.1. Multiple Interface Association Information Base . . . 39
2.3.5.3. MID Message Generation . . . . . . . . . . . . . . . . 38 2.3.6.2. MID Message Format . . . . . . . . . . . . . . . . . . 39
2.3.5.4. MID Message Processing . . . . . . . . . . . . . . . . 39 2.3.6.3. MID Message Generation . . . . . . . . . . . . . . . . 40
2.3.6. Associated Networks and Hosts . . . . . . . . . . . . . 40 2.3.6.4. MID Message Processing . . . . . . . . . . . . . . . . 40
2.3.6.1. HNA Message Format . . . . . . . . . . . . . . . . . . 41 2.3.7. Associated Networks and Hosts . . . . . . . . . . . . . 42
2.3.6.2. Host and Network Association Information Base . . . . 41 2.3.7.1. HNA Message Format . . . . . . . . . . . . . . . . . . 42
2.3.6.3. HNA Message Generation . . . . . . . . . . . . . . . . 42 2.3.7.2. Host and Network Association Information Base . . . . 43
2.3.6.4. HNA Message Processing . . . . . . . . . . . . . . . . 42 2.3.7.3. HNA Message Generation . . . . . . . . . . . . . . . . 43
2.3.7. Routing Table Calculation . . . . . . . . . . . . . . . 43 2.3.7.4. HNA Message Processing . . . . . . . . . . . . . . . . 43
2.3.8. Advanced Topology Discovery Functioning . . . . . . . . 46 2.3.8. Routing Table Calculation . . . . . . . . . . . . . . . 45
2.3.8.1. Reaction to Link Failure with a MPR Selector . . . . . 46 2.3.9. Advanced Topology Discovery Functioning . . . . . . . . 48
2.3.8.2. Advanced Fast Re-routing Mechanism . . . . . . . . . . 47 2.3.9.1. Reaction to Link Failure with a MPR Selector . . . . . 48
2.3.8.2.1. FRR Message Format . . . . . . . . . . . . . . . . . 48 2.3.9.2. Advanced Fast Re-routing Mechanism . . . . . . . . . . 48
2.3.8.2.2. FRR Message Generation . . . . . . . . . . . . . . . 48 2.3.9.2.1. FRR Message Format . . . . . . . . . . . . . . . . . 49
2.3.8.2.3. FRR Message Processing . . . . . . . . . . . . . . . 49 2.3.9.2.2. FRR Message Generation . . . . . . . . . . . . . . . 50
2.3.9.2.3. FRR Message Processing . . . . . . . . . . . . . . . 50
3. Node Configuration . . . . . . . . . . . . . . . . . . . . . 49 3. Node Configuration . . . . . . . . . . . . . . . . . . . . . 51
3.1. Address Assignment . . . . . . . . . . . . . . . . . . . . 49 3.1. Address Assignment . . . . . . . . . . . . . . . . . . . . 51
3.2. Routing Configuration . . . . . . . . . . . . . . . . . . 50 3.2. Routing Configuration . . . . . . . . . . . . . . . . . . 51
3.3. Data Packet Forwarding . . . . . . . . . . . . . . . . . . 50 3.3. Data Packet Forwarding . . . . . . . . . . . . . . . . . . 51
4. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 50 4. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 51
5. Proposed Values for the Constants . . . . . . . . . . . . . 50 5. Security Considerations . . . . . . . . . . . . . . . . . . 52
6. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . 51 5.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 52
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 52 5.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 52
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 52 6. Proposed Values for the Constants . . . . . . . . . . . . . 53
7. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . 54
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 55
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
The Optimized Link State Routing Protocol (OLSR) is developed for The Optimized Link State Routing Protocol (OLSR) is developed for
mobile ad hoc networks. It operates as a table driven, proactive pro- mobile ad hoc networks. It operates as a table driven, proactive pro-
tocol. I.e., exchanges topology information with other nodes of the tocol. I.e., exchanges topology information with other nodes of the
network regularly. Each node selects a set of its neighbor nodes as network regularly. Each node selects a set of its neighbor nodes as
"multipoint relays". These nodes which have been selected as a multi- "multipoint relays" (MPR). In OLSR, only nodes, selected as such
point relay by some neighbor nodes announce this information periodi- MPRs, are responsible for forwarding control traffic, intended for
cally in their control messages. Thereby, a node announces to the diffusion into the entire network. I.e. MPRs provide an efficient
network, that it has reachability to the nodes which have selected it mechanism for flooding control traffic by reducing the number of
as MPR. In route calculation, the MPRs are used to form the route transmissions required.
from a given node to any destination in the network. Furthermore, the
protocol uses the MPRs to facilitate efficient flooding of control Nodes, selected as MPRs, also have a special responsibility when
messages in the network. declaring link state information in the network. Indeed, the only
requirement for OLSR to provide routes to all destinations is that
MPR nodes declare link-state information for links between them self
and their MPR selectors. Additional available link-state information
may be utilized e.g. for redundancy.
These nodes which have been selected as a multipoint relay by some
neighbor nodes announce this information periodically in their con-
trol messages. Thereby, a node announces to the network, that it has
reachability to the nodes which have selected it as MPR. In route
calculation, the MPRs are used to form the route from a given node to
any destination in the network. Furthermore, the protocol uses the
MPRs to facilitate efficient flooding of control messages in the net-
work.
A node selects MPRs from among its one hop neighbors with "symmetri- A node selects MPRs from among its one hop neighbors with "symmetri-
cal", i.e. bi-directional, linkages. Therefore, selecting the route cal", i.e. bi-directional, linkages. Therefore, selecting the route
through MPRs automatically avoids the problems associated with data through MPRs automatically avoids the problems associated with data
packet transfer over uni-directional links (such as the problem of packet transfer over uni-directional links (such as the problem of
not getting link-layer acknowledgments for data packets at each hop) not getting link-layer acknowledgments for data packets at each hop)
OLSR is developed to work independently from other protocols. Like- OLSR is developed to work independently from other protocols. Like-
wise, OLSR makes no assumptions about the underlying link-layer. wise, OLSR makes no assumptions about the underlying link-layer.
OLSR inherits the concept of forwarding and relaying from HIPERLAN (a OLSR inherits the concept of forwarding and relaying from HIPERLAN (a
MAC layer protocol) which is standardized by ETSI [3]. The protocol MAC layer protocol) which is standardized by ETSI [3]. The protocol
is developed in the IPANEMA project (part of the Euclid program) and is developed in the IPANEMA project (part of the Euclid program) and
in the PRIMA project (part of the RNRT program). in the PRIMA project (part of the RNRT program).
1.1. Changes 1.1. Changes
Major changes from version 06 to version 07
- Introduction of relay willingness in hellos
- Introduction of redundant link set in TC messages
- Introduction of packet sequence number in order to clarify
link management
Major changes from version 05 to version 06 Major changes from version 05 to version 06
- Clarification of the usage of link layer notification and fast - Clarification of the usage of link layer notification and fast
rerouting re-routing
- Clarification of MPR selection - Clarification of MPR selection
- Clarification of multiple interfaces - Clarification of multiple interfaces
Major changes from version 04 to version 05 Major changes from version 04 to version 05
- Introduction of support for multiple interfaces - Introduction of support for multiple interfaces
- Introduction of support for associated hosts and networks. - Introduction of support for associated hosts and networks.
- Introduction of support for advanced neighbor sensing through - Introduction of support for advanced neighbor sensing through
hysteresis. hysteresis.
- Modularity between neighbor sensing and topology discovery - Modularity between neighbor sensing and topology discovery
emphasized. emphasized.
Major changes from version 03 to version 04 Major changes from version 03 to version 04
skipping to change at page 8, line 13 skipping to change at page 8, line 38
tained for each known destination all the time. tained for each known destination all the time.
1.4. Protocol Overview 1.4. Protocol Overview
OLSR is a proactive routing protocol for mobile ad hoc networks. The OLSR is a proactive routing protocol for mobile ad hoc networks. The
protocol inherits the stability of a link state algorithm and has the protocol inherits the stability of a link state algorithm and has the
advantage of having routes immediately available when needed due to advantage of having routes immediately available when needed due to
its proactive nature. OLSR is an optimization over the classical link its proactive nature. OLSR is an optimization over the classical link
state protocol, tailored for mobile ad hoc networks. state protocol, tailored for mobile ad hoc networks.
First, it reduces the size of the control messages: rather than OLSR minimizes the overhead from flooding of control traffic by using
declaring all links, a node declares only a subset of links with its only selected nodes, called MPRs, to retransmit control messages.
neighbors, namely the links to those nodes which are its MPR selec- This technique significantly reduces the number of retransmissions
tors. Second, OLSR minimizes the overhead from flooding of control required to flood a message to all nodes in the network. Secondly,
traffic by using only selected nodes, called MPRs, to retransmit con- OLSR requires only partial link state to be flooded in order to pro-
trol messages. This technique significantly reduces the number of vide optimal routes. The minimal set of link state information
retransmissions required to flood a message to all nodes in the net- required is, that all nodes, selected as MPRs, declare the links to
work. their MPR selectors. Additional topological information, if present,
may be utilized e.g. for redundancy purposes.
OLSR MAY optimize the reactivity to topological changes by reducing OLSR MAY optimize the reactivity to topological changes by reducing
the maximum time interval for periodic control message transmission. the maximum time interval for periodic control message transmission.
Furthermore, as OLSR continuously maintains routes to all destina- Furthermore, as OLSR continuously maintains routes to all destina-
tions in the network, the protocol is beneficial for traffic patterns tions in the network, the protocol is beneficial for traffic patterns
where a large subset of nodes are communicating with another large where a large subset of nodes are communicating with another large
subset of nodes, and where the [source, destination] pairs are chang- subset of nodes, and where the [source, destination] pairs are chang-
ing over time. The protocol is particularly suited for large and ing over time. The protocol is particularly suited for large and
dense networks, as the optimization done using MPRs works well in dense networks, as the optimization done using MPRs works well in
this context. The larger and more dense a network, the more optimiza- this context. The larger and more dense a network, the more optimiza-
skipping to change at page 9, line 37 skipping to change at page 10, line 19
Each node maintains information about the set of neighbors that have Each node maintains information about the set of neighbors that have
selected it as MPR. This set is called the "Multipoint Relay Selector selected it as MPR. This set is called the "Multipoint Relay Selector
set" (MPR selector set) of a node. A node obtains this information set" (MPR selector set) of a node. A node obtains this information
from periodic HELLO messages received from the neighbors. from periodic HELLO messages received from the neighbors.
A broadcast message, intended to be diffused in the whole network, 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 coming from any of the MPR selectors of node N is assumed to be
retransmitted by node N. This set can change over time (i.e. when a retransmitted by node N. This set can change over time (i.e. when a
node selects another MPR-set) and is indicated by the selector nodes node selects another MPR-set) and is indicated by the selector nodes
in their HELLO messages. Each node has a specific "Multipoint relay in their HELLO messages.
Selector Sequence Number" (MSSN) associated with this set. Whenever
the MPR selector set is updated, the node also increments its MSSN.
OLSR relies on selection of MPRs, and calculates routes through these
nodes. I.e., the path is made of links between MPR and MPR selector.
To enable this, each node in the network periodically floods informa-
tion describing which neighbors have selected it as a MPR. Upon
receipt of this "MPR Selector" information, each node calculates or
updates the route to each known destination. So principally, the
route is a sequence of hops through the MPRs from source to the des-
tination.
A nodes MPRs are selected among its symmetric neighborhood.
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 a link layer acknowledgment
for the data packets at each hop.
2. Protocol Functioning 2. Protocol Functioning
This section describes the details of the protocol functioning. This This section describes the details of the protocol functioning. This
includes descriptions of the format and contents of the packets being includes descriptions of the format and contents of the packets being
exchanged by routers and the algorithms (e.g. for packet handling and exchanged by routers and the algorithms (e.g. for packet handling and
routing table calculation). routing table calculation).
The "Packet Forwarding" and "Neighbor Sensing" mechanisms may be seen The "Packet Forwarding" and "Neighbor Sensing" mechanisms may be seen
as a transfer layer for the routing protocol. This provides nodes as a transfer layer for the routing protocol. This provides nodes
skipping to change at page 11, line 25 skipping to change at page 11, line 38
2.1.1. Protocol and Port Number 2.1.1. Protocol and Port Number
Packets in OLSR are communicated using UDP. Port 698 has been Packets in OLSR are communicated using UDP. Port 698 has been
assigned by IANA for exclusive usage by the OLSR protocol. assigned by IANA for exclusive usage by the OLSR protocol.
2.1.2. Multiple Interfaces and Main Address 2.1.2. Multiple Interfaces and Main Address
A node may have several wireless interfaces, each of them having a A node may have several wireless interfaces, each of them having a
distinct IP address. OLSR supports such nodes with multiple inter- distinct IP address. OLSR supports such nodes with multiple inter-
faces. For this reason, each node MUST choose one of its interface faces. For this reason, each node SHOULD choose one of its interface
addresses as its "main address". It is of no importance which address addresses as its "main address". It is of no importance which address
is chosen, however a node SHOULD always use the same address as its is chosen, however a node SHOULD always use the same address as its
main address. For example, the smallest interface address may be cho- main address. For example, the smallest interface address may be cho-
sen as the main interface. The main address MUST be used in OLSR con- sen as the main interface. The main address MUST be used in OLSR con-
trol traffic as the "originator address" of all messages emitted by a trol traffic as the "originator address" of all messages emitted by a
node. node.
A node must transmit and retransmit all control messages on all A node must transmit and retransmit all control messages on all
interfaces. The source address in the IP header must contain the IP- interfaces. The source address in the IP header must contain the IP-
address of the interface where the message is transmitted. This address of the interface where the message is transmitted. This
address will be denoted the "sender interface address". address will be denoted the "sender interface address".
2.1.3. Packet Format 2.1.3. Packet Format
The basic layout of any packet in OLSR is as follows (omitting the IP The basic layout of any packet in OLSR is as follows (omitting the IP
and UDP headers): and UDP headers):
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Length | Reserved | | Packet Length | Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reserved | Message Size | | Message Type | Reserved | Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time To Live | Hop Count | Message Sequence Number | | Time To Live | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: MESSAGE : : MESSAGE :
| | | |
skipping to change at page 12, line 39 skipping to change at page 12, line 44
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
(etc) (etc)
2.1.3.1. Packet Header 2.1.3.1. Packet Header
Packet Length Packet Length
The length (in bytes) of the packet The length (in bytes) of the packet
Reserved Packet Sequence Number
The Packet Sequence Number (PSN) MUST be incremented at each
MUST be set to "0000000000000000" to be in compliance with any new OLSR packet transmitted.
this version of the draft.
The sender information for a packet is obtainable from the UDP The sender information for a packet is obtainable from the IP header.
header.
2.1.3.2. Message Header 2.1.3.2. Message Header
Message Type Message Type
This field indicates which type of message is to be found in This field indicates which type of message is to be found in
the "MESSAGE" partition. Message types in the range of 0-127 the "MESSAGE" partition. Message types in the range of 0-127
are reserved for messages in this draft and in extension are reserved for messages in this draft and in extension
drafts. drafts.
Reserved Reserved
MUST be set to "00000000" to be in compliance with this ver- MUST be set to "00000000" to be in compliance with this ver-
sion of the draft. sion of the draft.
skipping to change at page 13, line 26 skipping to change at page 13, line 35
This field gives the size of this message, counted in bytes This field gives the size of this message, counted in bytes
and measured from the beginning of the "Message Type" field and measured from the beginning of the "Message Type" field
and until the beginning of the next "Message Type" field (or - and until the beginning of the next "Message Type" field (or -
if there are no following messages - until the end of the if there are no following messages - until the end of the
packet). packet).
Originator Address Originator Address
This field contains the main address of the node, which has This field contains the main address of the node, which has
originally generated this message. This field SHOULD NOT be originally generated this message. This field SHOULD NOT be
confused with the source address from the UDP header, which is confused with the source address from the IP header, which is
changed each time to the address of the intermediate interface changed each time to the address of the intermediate interface
which is re-transmitting this message. The Originator Address which is re-transmitting this message. The Originator Address
field MUST *NEVER* be changed in retransmissions. field MUST *NEVER* be changed in retransmissions.
Time To Live Time To Live
This field contains the maximum number of hops a message will This field contains the maximum number of hops a message will
be transmitted. Before a message is retransmitted, the Time To be transmitted. Before a message is retransmitted, the Time To
Live MUST be decremented by 1. When a node receives a message 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 with a Time To Live equal to 0 or 1, the message MUST NOT be
skipping to change at page 14, line 22 skipping to change at page 14, line 31
described in a later section. Message sequence numbers are described in a later section. Message sequence numbers are
used to ensure that a given message is not retransmitted more used to ensure that a given message is not retransmitted more
than once by any node. than once by any node.
2.1.4. Packet Processing and Message Flooding 2.1.4. Packet Processing and Message Flooding
Upon receiving a basic packet, the protocol parser examines each of Upon receiving a basic packet, the protocol parser examines each of
the "message headers". Based on the value of the "Message Type" the "message headers". Based on the value of the "Message Type"
field, the parser can determine the fate of the message. A node may field, the parser can determine the fate of the message. A node may
receive the same message several times. Thus, to avoid re-processing receive the same message several times. Thus, to avoid re-processing
of a message which was already received and processed, each node of some messages which were already received and processed, each node
maintains a Duplicate table. In this table, the node records informa- maintains a Duplicate table. In this table, the node records informa-
tion about the most recently received messages where the above condi- tion about the most recently received messages where duplicate pro-
tion holds. For each message, satisfying the above condition, a node cessing of a message is to be avoided. For such a message, a node
records a "Duplicate Tuple" (D_addr, D_seq_num, D_time), where D_addr records a "Duplicate Tuple" (D_addr, D_seq_num, D_time), where D_addr
is the originator address of the message, D_seq_num is the message is the originator address of the message, D_seq_num is the message
sequence number of the message and D_time specifies the time at which sequence number of the message and D_time specifies the time at which
a tuple expires and *MUST* be removed. a tuple expires and *MUST* be removed.
In a node, the set of Duplicate Tuples are denoted the "Duplicate In a node, the set of Duplicate Tuples are denoted the "Duplicate
set". set".
In this section, the term "Originator Address" will be used for the In this section, the term "Originator Address" will be used for the
main address of the node which sent the message. The term "Sender main address of the node which sent the message. The term "Sender
skipping to change at page 16, line 19 skipping to change at page 16, line 26
handled will simply rebroadcast the message, regardless of MPRs. handled will simply rebroadcast the message, regardless of MPRs.
By defining a set of message types, which MUST be recognized by all By defining a set of message types, which MUST be recognized by all
implementations of OLSR, it will be possible to extend the protocol implementations of OLSR, it will be possible to extend the protocol
through introduction of additional message types, while still be able through introduction of additional message types, while still be able
to maintain compatibility with older implementations. The REQUIRED to maintain compatibility with older implementations. The REQUIRED
message types for OLSR are: message types for OLSR are:
- HELLO-messages, performing the task of neighbor sensing. - HELLO-messages, performing the task of neighbor sensing.
- TC-messages, performing the task of MPR information declara- - TC-messages, performing the task of topology declaration
tion (OLSR topology declaration). (advertisement of link states)
- MID-messages, performing the task of multiple interface decla- - MID-messages, performing the task of multiple interface decla-
ration. ration.
- HNA-messages, performing the task of associated host and/or - HNA-messages, performing the task of associated host and/or
network declaration. network declaration.
- FRR-messages, performing the task of initiating fast rerouting - FRR-messages, performing the task of initiating fast re-rout-
in case of link failure. ing in case of link failure.
Extensions may for example be messages enabling power conservation / Extensions may for example be messages enabling power conservation /
sleep mode, multicast routing, support for unidirectional links, sleep mode, multicast routing, support for unidirectional links,
auto-configuration/address assignment etc. auto-configuration/address assignment etc.
2.1.5. Message Emission and Jitter 2.1.5. Message Emission and Jitter
As a basic implementation requirement, synchronization of control As a basic implementation requirement, synchronization of control
messages SHOULD be avoided. As a consequence, periodic OLSR messages messages SHOULD be avoided. As a consequence, periodic OLSR messages
SHOULD be emitted such that they avoid synchronization. SHOULD be emitted such that they avoid synchronization.
skipping to change at page 18, line 7 skipping to change at page 18, line 14
status. The link status may either be "symmetric", "heard" (asymmet- status. The link status may either be "symmetric", "heard" (asymmet-
ric), "MPR" or "lost". "Symmetric" indicates, that the link has been ric), "MPR" or "lost". "Symmetric" indicates, that the link has been
verified to be bi-directional, i.e. it is possible to transmit data verified to be bi-directional, i.e. it is possible to transmit data
in both directions. "Heard" indicates that the node can hear HELLO in both directions. "Heard" indicates that the node can hear HELLO
messages from a neighbor interface, but it is not confirmed that this messages from a neighbor interface, but it is not confirmed that this
neighbor interface is also able to receive messages from the node. neighbor interface is also able to receive messages from the node.
MPR indicates that the sender has selected the node as MPR. A status MPR indicates that the sender has selected the node as MPR. A status
of MPR further implies that the link is symmetric. "Lost" indicates of MPR further implies that the link is symmetric. "Lost" indicates
that the link with this neighbor interface is now lost. that the link with this neighbor interface is now lost.
HELLO messages are broadcasted to all one-hop neighbors and are emit- HELLO messages are broadcast to all one-hop neighbors and are emitted
ted on each MANET interface of the node. They are *not relayed* to on each MANET interface of the node. They are *not relayed* to fur-
further nodes. ther nodes.
More precisely, a HELLO message contains for each interface I: More precisely, a HELLO message contains for each interface I:
- a list of neighbor interface addresses, having a symmetric - a list of neighbor interface addresses, having a symmetric
link to interface I; link to interface I;
- a list of neighbor interface addresses, which are "heard" by - a list of neighbor interface addresses, which are "heard" by
interface I (for historical reasons, the term "asymmetric" is interface I (for historical reasons, the term "asymmetric" is
used for "heard"); used for "heard");
skipping to change at page 18, line 38 skipping to change at page 18, line 45
2.2.1. HELLO Message Format 2.2.1. HELLO Message Format
To accommodate the above requirements, as well as to accommodate for To accommodate the above requirements, as well as to accommodate for
future extensions, an approach similar to the overall packet format future extensions, an approach similar to the overall packet format
is taken. Thus the proposed format of a HELLO message is: is taken. Thus the proposed format of a HELLO message is:
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | # Interfaces | | Reserved | Willingness | # Interfaces |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Address | | Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Address | | Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . . . : : . . . :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Type | Interface # | Link Message Size | | Link Type | Interface # | Link Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line 28 skipping to change at page 19, line 35
: : : :
(etc) (etc)
This is sent as the data-portion of the general packet format This is sent as the data-portion of the general packet format
described in the Packet Format and Forwarding section, with the "Mes- described in the Packet Format and Forwarding section, with the "Mes-
sage Type" set to HELLO_MESSAGE and the TTL field set to 1 (one). sage Type" set to HELLO_MESSAGE and the TTL field set to 1 (one).
Reserved Reserved
This field is reserved for future usage, and MUST be set to This field is reserved for future usage, and MUST be set to
"000000000000000000000000" for compliance with this draft. "0000000000000000" for compliance with this draft.
Willingness
This field indicates the "willingness" of the sender to act as
a multipoint relay. The willingness parameter is an integer
between 0 and 7. The value 0 is for nodes which should never
forward packets to other destinations (e.g. because their
power supply is critical). The higher the willingness of a
node, the more likely is the node to be selected as MPR by its
neighbors. The value 7 is reserved for nodes which should
always be selected as multipoint relay (e.g. when the node
belongs to a pre-defined backbone). An OLSR router in normal
operation SHOULD have willingness equal to 3.
# Interfaces # Interfaces
This field indicates the number of additional MANET interfaces This field indicates the number of additional MANET interfaces
(excluding the main interface) possessed by the node. If the (in addition to the main interface) possessed by the node. If
node has only one interface, this number is 0. the node has only one interface, this number is 0.
Interface Address Interface Address
This field indicates the addresses of additional MANET inter- This field indicates the addresses of additional MANET inter-
faces. The first one will be referenced as interface address faces. The first one will be referenced as interface address
number 1, the second as interface address number 2, and so on. number 1, the second as interface address number 2, and so on.
The main address of the node (whose address is given in the The main address of the node (whose address is given in the
originator field of the message header) will be referenced as originator field of the message header) will be referenced as
interface address number 0. interface address number 0.
Link Message Size
The size of the link message, counted in bytes and measured
from the beginning of the "Link Type" field and until the next
"Link Type" field (or - if there are no more link types - the
end of the message).
Link Type Link Type
This field specifies the type of the link between the inter- This field specifies the type of the link between the inter-
face of the sender, as identified by the interface number, and face of the sender, as identified by the interface number, and
the following list of neighbor interfaces. As a minimum, the the following list of neighbor interfaces. As a minimum, the
following four link types are REQUIRED by OLSR: following four link types are REQUIRED by OLSR:
- ASYM_LINK - indicating that the links are asymmetric - ASYM_LINK, indicating that the links are asymmetric (i.e.
(i.e. the neighbor interface is "heard"). the neighbor interface is "heard").
- SYM_LINK - indicating that the links are symmetric. - SYM_LINK, indicating that the links are symmetric.
- MPR_LINK - indicating, that the links are symmetric AND - MPR_LINK, indicating, that the links are symmetric AND
that the neighbors have been selected as MPR by the that the neighbors have been selected as MPR by the
sender. sender.
- LOST_LINK - indicating that the links have been lost. - LOST_LINK, indicating that the links have been lost.
Interface # Interface #
This field indicates the number of the interface to which the This field indicates the number of the interface to which the
following list of neighbor interfaces corresponds. Number 0 following list of neighbor interfaces corresponds. Number 0
indicates the main interface (whose address is the main indicates the main interface (whose address is the main
address). address).
Link Message Size
The size of the link message, counted in bytes and measured
from the beginning of the "Link Type" field and until the next
"Link Type" field (or - if there are no more link types - the
end of the message).
Neighbor Interface Address Neighbor Interface Address
An address of a neighbor interface. An address of a neighbor interface.
Neighbor sensing is performed using HELLO message exchange, updating Neighbor sensing is performed using HELLO message exchange, updating
the neighbor sensing information base in each node. the neighbor sensing information base in each node.
2.2.2. Neighbor Sensing Information Base 2.2.2. Neighbor Sensing Information Base
The neighbor sensing information base stores information about neigh- The neighbor sensing information base stores information about neigh-
bor interfaces, 2-hop neighbors, MPRs and MPR selectors. bor interfaces, 2-hop neighbors, MPRs and MPR selectors.
2.2.2.1. Neighbor Set 2.2.2.1. Neighbor Set
For each of its interface I and for each neighbor interface NI, heard For each of its interface I and for each neighbor interface NI, heard
by I, a node records a "Neighbor Tuple" (N_if_id, N_if_addr, by I, a node records a "Neighbor Tuple" (N_if_id, N_if_addr,
N_main_addr, N_SYM_time, N_ASYM_time, N_time) where N_if_id is the N_main_addr, N_willing, N_SYM_time, N_ASYM_time, N_time) where
identifier number of the local interface I, N_if_addr is the address N_if_id is the identifier number of the local interface I, N_if_addr
of the neighbor interface NI, N_main_addr is the main address of the is the address of the neighbor interface NI, N_main_addr is the main
neighbor possessing NI, N_SYM_time is the time until which the link address of the neighbor possessing NI, N_willing is the willingness
is considered symmetric, N_ASYM_time is the time until which the of the neighbor possessing NI, N_SYM_time is the time until which the
link is considered symmetric, N_ASYM_time is the time until which the
neighbor interface is considered heard, and N_time specifies the time neighbor interface is considered heard, and N_time specifies the time
at which this record expires and *MUST* be removed. When N_SYM_time at which this record expires and *MUST* be removed. When N_SYM_time
and N_ASYM_time are expired, the link is considered lost. and N_ASYM_time are expired, the link is considered lost.
This information is used when declaring the neighbor interfaces in This information is used when declaring the neighbor interfaces in
the HELLO messages. the HELLO messages.
N_SYM_time and N_ASYM_time are used to decide the Link Type declared N_SYM_time and N_ASYM_time are used to decide the Link Type declared
for the neighbor interface. If N_SYM_time is not expired, the link is for the neighbor interface. If N_SYM_time is not expired, the link is
declared symmetric. If N_SYM_time is expired but N_ASYM_time is not, declared symmetric. If N_SYM_time is expired but N_ASYM_time is not,
the link is declared heard. If both N_SYM_time and N_ASYM_time are the link is declared heard. If both N_SYM_time and N_ASYM_time are
expired, the link is declared lost. expired, the link is declared lost.
In a node, the set of Neighbor Tuples are denoted the "Neighbor Set". In a node, the set of Neighbor Tuples are denoted the "Neighbor Set".
2.2.2.2. 2-hop Neighbor Set 2.2.2.2. 2-hop Neighbor Set
A node records a set of "2-hop tuples" (N_main_addr, N_if_addr, A node records a set of "2-hop tuples" (N_main_addr, N_if_addr,
N_2hop_addr, N_time), describing symmetric or MPR links between its N_2hop_addr, N_2hop_main_addr, N_time), describing symmetric or MPR
neighbors and the symmetric 2-hop neighborhood. N_main_addr and links between its neighbors and the symmetric 2-hop neighborhood.
N_if_addr are the main address and an interface address of a neigh- N_main_addr and N_if_addr are the main address and an interface
bor, N_2hop_addr is an interface address of a 2-hop neighbor with a address of a neighbor, N_2hop_addr is an interface address of a 2-hop
symmetric or MPR link to interface N_if_addr and N_time specifies the neighbor with a symmetric or MPR link to interface, N_2hop_main_addr
time at which the tuple expires and *MUST* be removed. is the main address of the 2-hop node,and N_time specifies the time
at which the tuple expires and *MUST* be removed.
This information is gathered from the HELLO messages received by a This information is gathered from the HELLO messages received by a
node from its neighbor nodes. node from its neighbor nodes. The N_2hop_main_addr is acquired
through the multiple interface association base.
In a node, the set of 2-hop tuples are denoted the "2-hop Neighbor In a node, the set of 2-hop tuples are denoted the "2-hop Neighbor
Set". Set".
2.2.2.3. MPR Set 2.2.2.3. MPR Set
A node maintains a set of neighbors which are selected as MPR. Their A node maintains a set of neighbors which are selected as MPR. Their
main addresses are listed in the so-called MPR Set. The Multipoint main addresses are listed in the so-called MPR Set. The Multipoint
relay selection section describes how MPRs are selected. relay selection section describes how MPRs are selected.
2.2.2.4. MPR Selector Set 2.2.2.4. MPR Selector Set
A node maintains information (obtained from the HELLO messages) about A node maintains information (obtained from the HELLO messages) about
the neighbors which have selected this node as a MPR. the neighbors which have selected this node as a MPR.
Thus, a node records an MPR-selector tuple (MS_if_addr, MS_main_addr, Thus, a node records an MPR-selector tuple (MS_if_addr, MS_main_addr,
MS_time), for interfaces of a neighbor which has selected the node as MS_time). MS_if_addr is the address of an interface of a node which
MPR. MS_if_addr is the address of an interface of a node which has has selected the node as MPR, MS_main_addr is the main address of the
selected the node as MPR for that interface, MS_main_addr is the main MPR selector and MS_time specifies the time at which a tuple expires
address of the MPR selector and MS_time specifies the time at which a and *MUST* be removed.
tuple expires and *MUST* be removed.
In a node, the set of MPR-selector tuples are denoted the "MPR Selec- In a node, the set of MPR-selector tuples are denoted the "MPR Selec-
tor Set". A sequence number, MSSN, is associated with this set. When- tor Set".
ever a tuple is added to or removed from this set, the MSSN is incre-
mented by 1.
2.2.3. HELLO Message Generation 2.2.3. HELLO Message Generation
The lists of addresses declared in a HELLO message are computed from The lists of addresses declared in a HELLO message are computed from
the Neighbor Set as follows: the Neighbor Set as follows:
- for each tuple where: - for each tuple where:
N_SYM_time < current time (expired) AND N_SYM_time < current time (i.e. expired) AND
N_ASYM_time <current time (expired) N_ASYM_time < current time (i.e. expired)
N_if_addr is declared with LOST_LINK Link Type for interface N_if_addr is declared with LOST_LINK Link Type for interface
N_if_id; N_if_id;
- for each tuple where: - for each tuple where:
N_SYM_time >= current time (not expired) N_SYM_time >= current time (not expired)
N_if_addr is declared with MPR_LINK Link Type if N_main_addr N_if_addr is declared with MPR_LINK Link Type if N_main_addr
is in the MPR set and SYM_LINK Link Type otherwise; is in the MPR set and SYM_LINK Link Type otherwise;
- for each tuple where: - for each tuple where:
N_SYM_time < current time (expired) AND N_SYM_time < current time (expired) AND
N_ASYM_time >= current time (not expired), N_ASYM_time >= current time (not expired),
N_if_addr is declared with ASYM_LINK Link Type. N_if_addr is declared with ASYM_LINK Link Type.
skipping to change at page 23, line 9 skipping to change at page 23, line 27
heard on, its address is cited with corresponding interface id at heard on, its address is cited with corresponding interface id at
least once within a predetermined refreshing period, REFRESH_INTER- least once within a predetermined refreshing period, REFRESH_INTER-
VAL. To keep track of fast connectivity change a HELLO message must VAL. To keep track of fast connectivity change a HELLO message must
be sent at least every HELLO_INTERVAL period, smaller than or equal be sent at least every HELLO_INTERVAL period, smaller than or equal
to REFRESH_INTERVAL. to REFRESH_INTERVAL.
Notice that for limiting the impact from loss of control messages, it Notice that for limiting the impact from loss of control messages, it
is desirable that a message (plus the generic package header) can fit is desirable that a message (plus the generic package header) can fit
into a single MAC frame. into a single MAC frame.
Each HELLO message generated is broadcasted on each MANET interface Each HELLO message generated is broadcast on each MANET interface of
of the node. the node.
2.2.4. HELLO Message Processing 2.2.4. HELLO Message Processing
In this section, the terms "Originator Address", "Sender Interface", In this section, the terms "Originator Address", "Sender Interface",
"Receiver Interface", and "Link Interface" are used. They are defined "Receiver Interface", and "Link Interface" are used. They are defined
bellow and illustrated in the following figure: bellow and illustrated in the following figure:
______________ _____________ ______________ _____________
| J1 |= -- = |I1 | | J1 |= -- = |I1 |
| Main -> J2 |= | = |I2 <- Main | | Main -> J2 |= = |I2 <- Main |
| J3 |= -- = |I3 | | J3 |= -- = |I3 |
-------------- | ------------- -------------- -------------
| |
______________ | ______________ /
| K1 |= | K1 |=
| Main -> K2 |= | Main -> K2 |=
| |
-------------- --------------
J1, J2 and J3 are the addresses of local interfaces on node J. Like- J1, J2 and J3 are the addresses of local interfaces on node J. Like-
wise, I1, I2 and I3 are addresses of local interfaces on node I and wise, I1, I2 and I3 are addresses of local interfaces on node I and
K1 and K2 are addresses of local interfaces on node K. There are sym- K1 and K2 are addresses of local interfaces on node K. There are
metric links between J1 and I3 and between J3 and K1. symmetric links between J1 and I3 and between J3 and K1.
The three nodes have selected, respectively, J2, I2 and K2 as their The three nodes have selected, respectively, J2, I2 and K2 as their
"main addresses". I.e. the Originator Address of all OLSR-messages "main addresses". I.e. the Originator Address of all OLSR-messages
sent by node J will have the Originator Address J2 (and likewise for sent by node J will have the Originator Address J2. For node I and K,
node I and K). the main addresses will be I2 and K2, respectively
A HELLO message, sent by node J, is transmitted on all node J's A HELLO message, sent by node J, is transmitted on all node J's
interfaces. Recieved by node I, the following naming conventions interfaces. Received by node I, the following naming conventions
apply: apply:
- The term "Originator Address" is the main address of the node, - The term "Originator Address" is the main address of the node,
originating a message. In the example above, the Originator originating a message. In the example above, the Originator
Address of the HELLO is J2. Address of the HELLO is J2.
- The term "Sender Interface" for the HELLO message is the - The term "Sender Interface" for the HELLO message is the
interface over which the HELLO was transmitted. In the example interface over which the HELLO was transmitted. In the example
above, the Sender Interface Address is J1. above, the Sender Interface Address is J1.
- The term "Receiver Interface" will be used for the interface - The term "Receiver Interface" will be used for the interface
which received the HELLO message. In the example above, node which received the HELLO message. In the example above, node
I's "Receiver Interface" for the HELLO generated by node J is I's "Receiver Interface" for the HELLO generated by node J is
I3. I3.
- The term "Link Interface" will be used to in a HELLO message - The term "Link Interface" will be used in a HELLO message to
to designate on which interface (of the sender of a HELLO mes- designate on which interface (of the sender of a HELLO mes-
sage) a neighbor is detected. In the example above, K1 is sage) a neighbor is detected. In the example above, K1 is
listed in the HELLO message of J with Link Interface J3. The listed in the HELLO message of J with Link Interface J3. The
"Link Interface" is calculated based on the Interface # in the "Link Interface" is calculated based on the Interface # in the
HELLO message). Notice that an interface address may be listed HELLO message. Notice that an interface address may be listed
several times with different Link Interfaces. several times with different Link Interfaces.
Upon receiving a HELLO message, the node SHOULD update the neighbor Upon receiving a HELLO message, the node SHOULD update the neighbor
information corresponding to the sender node address (a node may - information corresponding to the sender node address (a node may -
e.g. for security reasons - wish to restrict updating the neighbor- e.g. for security reasons - wish to restrict updating the neighbor-
table, i.e. ignoring HELLO messages from some nodes). table, i.e. ignoring HELLO messages from some nodes).
Notice, that a HELLO message MUST neither be forwarded nor be
recorded in the duplicate table.
The Neighbor Set should be updated as follows: The Neighbor Set should be updated as follows:
1 Upon receiving a HELLO message, if there exists no neighbor 1 Upon receiving a HELLO message, if there exists no neighbor
tuple with tuple with
N_if_addr == Sender Interface Address N_if_addr == Sender Interface Address
and and
N_if_id == identifier of the Receiver Interface, N_if_id == identifier of the Receiver Interface,
skipping to change at page 24, line 48 skipping to change at page 25, line 24
a new tuple is created with a new tuple is created with
N_if_addr = Sender Interface Address N_if_addr = Sender Interface Address
N_if_id = identifier of the Receiver Interface N_if_id = identifier of the Receiver Interface
N_SYM_time = current time - 1 (expired) N_SYM_time = current time - 1 (expired)
N_time = current time + NEIGHB_HOLD_TIME N_time = current time + NEIGHB_HOLD_TIME
2 The tuple is then modified as follows: 2 The tuple (existing or new) with:
N_if_addr == Sender Interface Address
and
N_if_id == identifier of the Receiver Interface,
is then modified as follows:
2.1 N_main_addr = Originator Address. 2.1 N_main_addr = Originator Address.
2.3 N_time = max (N_time, current time + 2.2 N_willing = Originator Willingness
2.4 N_time = max (N_time, current time +
NEIGHB_HOLD_TIME); NEIGHB_HOLD_TIME);
2.4 N_ASYM_time = current time + NEIGHB_HOLD_TIME; 2.5 N_ASYM_time = current time + NEIGHB_HOLD_TIME;
2.5 if the node finds the Receiver Interface Address among 2.6 if the node finds the Receiver Interface Address among
the addresses listed in the HELLO with: the addresses listed in the HELLO with:
Link Interface Address == Sender Interface Address, Link Interface Address == Sender Interface Address,
then, the tuple is modified as follows: then, the tuple is modified as follows:
if Link Type == LOST_LINK then if Link Type == LOST_LINK then
N_SYM_time = current time - 1 (i.e. expired)
N_SYM_time = current time - 1 (expired)
else: else:
N_SYM_time = current time + NEIGHB_HOLD_TIME, N_SYM_time = current time + NEIGHB_HOLD_TIME,
N_time = current time + 2 * N_time = current time + 2 *
NEIGHB_HOLD_TIME. NEIGHB_HOLD_TIME.
The rule for setting N_time is the following: a link loosing its sym- The rule for setting N_time is the following: a link loosing its sym-
metry should still be advertised at least NEIGHB_HOLD_TIME. This metry should still be advertised during at least NEIGHB_HOLD_TIME.
allows neighbors to detect the link breakage. This allows neighbors to detect the link breakage.
The 2-hop Neighbor Set is updated as follows: The 2-hop Neighbor Set is updated as follows:
1 for each 2-hop interface address listed in the HELLO message 1 for each 2-hop interface address listed in the HELLO message
with Link Type SYM_LINK or MPR_LINK, a 2-hop tuple is created with Link Type SYM_LINK or MPR_LINK, a 2-hop tuple is created
with: with:
N_main_addr = Originator Address; N_main_addr = Originator Address;
N_if_addr = Link Interface Address corresponding to the N_if_addr = Link Interface Address corresponding
2-hop interface address; to the 2-hop interface address;
N_2hop_addr = the interface address of the 2-hop neigh- N_2hop_addr = the interface address of the 2-hop
bor; neighbor;
N_time = current time + 2HOP_HOLD_TIME. N_time = current time + 2HOP_HOLD_TIME.
N_2hop_main_addr = the main address of the node,
extracted from the multiple interface association infor-
mation base; if no address is available, the interface
address N_if_addr is used.
This tuple may replace an older similar tuple with same This tuple may replace an older similar tuple with same
N_if_addr and N_2hop_addr values. N_if_addr and N_2hop_addr values.
2 For each 2-hop interface address listed in the HELLO message 2 For each 2-hop interface address listed in the HELLO message
with Link Type LOST_LINK or ASYM_LINK, all the 2-hop tuples with Link Type LOST_LINK or ASYM_LINK, all the 2-hop tuples
where: where:
N_if_addr == Link Interface Address corresponding to the N_if_addr == Link Interface Address corresponding to the
2-hop interface address, 2-hop interface address,
skipping to change at page 26, line 34 skipping to change at page 27, line 24
sender of the HELLO message: sender of the HELLO message:
1 If there exists no MPR selector tuple with: 1 If there exists no MPR selector tuple with:
MS_if_addr == Link Interface Address MS_if_addr == Link Interface Address
and and
MS_main_addr == Originator Address MS_main_addr == Originator Address
then MSSN is incremented to indicate that the MPR selector
table is going to change.
2 If there exists no MPR selector tuple with: 2 If there exists no MPR selector tuple with:
MS_if_addr == Link Interface Address MS_if_addr == Link Interface Address
then a new tuple is created with: then a new tuple is created with:
MS_if_addr = Link Interface Address MS_if_addr = Link Interface Address
3 The tuple is then modified as follows: 3 The tuple is then modified as follows:
skipping to change at page 27, line 23 skipping to change at page 28, line 10
a region. Thus, the concept of MPR is an optimization of a classical a region. Thus, the concept of MPR is an optimization of a classical
flooding mechanism. flooding mechanism.
Each node in the network selects, independently, its own set of MPRs Each node in the network selects, independently, its own set of MPRs
among its symmetric neighborhood. The symmetric links with MPRs are among its symmetric neighborhood. The symmetric links with MPRs are
advertised with Link Type MPR_LINK instead of SYM_LINK in HELLO mes- advertised with Link Type MPR_LINK instead of SYM_LINK in HELLO mes-
sages. sages.
The MPR set MUST be calculated by a node in such a way that it, The MPR set MUST be calculated by a node in such a way that it,
through the neighbors in the MPR-set, can reach all symmetric 2-hop through the neighbors in the MPR-set, can reach all symmetric 2-hop
neighbors which are not at the same time symmetric neighbors of the neighbors. (Notice that a node, a, which is a direct neighbor of
node. This means that the union of the symmetric neighborhoods of the another node, b, is not also a 2-hop neighbor of node b). This means
MPR nodes contains the symmetric 2-hop neighborhood. MPR set recalcu- that the union of the symmetric neighborhoods of the MPR nodes con-
lation should occur when changes are detected in the neighborhood or tains the symmetric 2-hop neighborhood. MPR set recalculation should
in the 2-hop neighborhood. occur when changes are detected in the neighborhood or in the 2-hop
neighborhood.
While it is not essential that the MPR set is minimal, it is essen- While it is not essential that the MPR set is minimal, it is essen-
tial that all 2-hop neighbors can be reached through the selected MPR tial that all 2-hop neighbors can be reached through the selected MPR
nodes. A node SHOULD select an MPR set such that any 2-hop neighbor nodes. A node SHOULD select an MPR set such that any 2-hop neighbor
is covered by at least MPR_COVERAGE MPR nodes. With MPR_COVERAGE=1 is covered by at least MPR_COVERAGE MPR nodes. With MPR_COVERAGE=1
the overhead of the protocol is kept at a minimum. In presence of the overhead of the protocol is kept at a minimum. In presence of
mobility and link failure, an MPR_COVERAGE=2 could provide a more mobility and link failure, an MPR_COVERAGE=2 could provide a more
redundant connectivity, for example to support a link failure without redundant connectivity, for example to support a link failure without
rerouting. re-routing.
Notice that MPR_COVERAGE can be tuned locally without affecting the Notice that MPR_COVERAGE can be tuned locally without affecting the
consistency of the protocol. For example, a node can set MPR_COVER- consistency of the protocol. For example, a node can set MPR_COVER-
AGE=2 if it observes many changes in its neighbor information base AGE=2 if it observes many changes in its neighbor information base
caused by mobility, while otherwise keeping MPR_COVERAGE=1. caused by mobility, while otherwise keeping MPR_COVERAGE=1.
By default, the MPR set can coincide with the entire symmetric neigh- By default, the MPR set can coincide with the entire symmetric neigh-
bor set. This will be the case at network initialization (and will bor set. This will be the case at network initialization (and will
correspond to classic link-state routing). correspond to classic link-state routing).
The following specifies a proposed heuristic for selection of MPRs The following specifies a proposed heuristic for selection of MPRs
[2] adapted for multiple interfaces support. It constructs an MPR-set [2] adapted for multiple interfaces support. It constructs an MPR-set
that enables it to reach any symmetrical 2-hop interface (i.e. any that enables it to reach any symmetrical 2-hop interface (i.e. any
interface of a 2-hop neighbor having a symmetrical link with a neigh- interface of a 2-hop neighbor having a symmetrical link with a neigh-
bor). The following terminology will be used in describing this bor). The following terminology will be used in describing this algo-
algorithm (neighbors are identified by their main address and 2-hop rithm:
interfaces by their address):
N: N:
The set of neighbors with which there exists a symmetric link. The set of neighbors with which there exists a symmetric link.
N2: N2:
The set made of the symmetric 2-hop interfaces excluding all The set made of the main addresses of the 2-hop neighbor set
the interfaces of members of N and the interfaces of the node excluding (i) the nodes only reachable by members of N with
willingness zero, (ii) all the nodes in N and (iii) the node
performing the computation. performing the computation.
D(y): D(y):
Degree of one hop neighbor node y (where y is a member of N),
defined as the number of symmetric neighbor interfaces of node
y, EXCLUDING all the interfaces of members of N and the inter-
faces of the node performing the computation.
Poorly covered interface: The degree of an one hop neighbor node y (where y is a member
A poorly covered interface is an interface in N2 which is cov- of N), is defined as the number of symmetric neighbors of node
ered by less than MPR_COVERAGE nodes in N. y, EXCLUDING all the members of N and EXCLUDING the node per-
forming the computation.
Poorly covered node:
A poorly covered node is a node in N2 which is covered by less
than MPR_COVERAGE nodes in N.
The proposed heuristic is as follows: The proposed heuristic is as follows:
1 Start with an empty MPR set 1 Start with an MPR set made of all members of N with willing-
ness equal to seven
2 Calculate D(y), where y is a member of N, for all nodes in N. 2 Calculate D(y), where y is a member of N, for all nodes in N.
3 Select as MPRs those nodes in N which cover the poorly covered 3 Select as MPRs those nodes in N which cover the poorly covered
interfaces in N2. The interfaces are then removed from N2 for nodes in N2. The nodes are then removed from N2 for the rest
the rest of the computation. of the computation.
4 While there exist interfaces in N2 which are not covered by at 4 While there exist nodes in N2 which are not covered by at
least MPR_COVERAGE nodes in the MPR set: least MPR_COVERAGE nodes in the MPR set:
4.1 For each node in N, calculate the number of interfaces in 4.1 For each node in N, calculate the reachability, i.e. the
N2 which are not yet covered by at least MPR_COVERAGE number of nodes in N2 which are not yet covered by at
nodes in the MPR set, and which are reachable through least MPR_COVERAGE nodes in the MPR set, and which are
this one hop neighbor; reachable through this one hop neighbor;
4.2 Select as a MPR the node from N which provides reachabil- 4.2 Select as a MPR the node with highest willingness among
ity to the maximum number of those interfaces in N2. In the nodes in N with non-zero reachability. In case of
case of multiple nodes providing the same amount of multiple choice select the node which provides reachabil-
reachability, select that node as MPR whose D(y) is ity to the maximum number of nodes in N2. In case of
greater. Remove from N2 the interfaces that are now cov- multiple nodes providing the same amount of reachability,
ered by MPR_COVERAGE node in the MPR set. select the node as MPR whose D(y) is greater. Remove the
nodes from N2 which are now covered by MPR_COVERAGE nodes
in the MPR set.
5 As an optimization, process each node y in the MPR set. If 5 As an optimization, process each node y in the MPR set in the
all interfaces in N2 are still covered by at least increasing order of their willingness. If all nodes in N2 are
MPR_COVERAGE nodes in the MPR set excluding y, node y is still covered by at least MPR_COVERAGE nodes in the MPR set
removed from the MPR set. excluding y and willingness of node y is smaller than seven,
then node y is removed from the MPR set.
When the MPR set has been computed, all the corresponding main When the MPR set has been computed, all the corresponding main
addresses are stored in the MPR Set. addresses are stored in the MPR Set.
2.2.5.1. Neighborhood and 2-hop Neighborhood Changes 2.2.6. Neighborhood and 2-hop Neighborhood Changes
A change in the neighborhood is detected when: A change in the neighborhood is detected when:
- The N_SYM_time field of a neighbor tuple expires. This is con- - The N_SYM_time field of a neighbor tuple expires. This is con-
sidered as a neighbor loss if it was the last link with a sidered as a neighbor loss if it was the last link with a
neighbor node (on the contrary, a link with an interface may neighbor node (on the contrary, a link with an interface may
break while a link with another interface of the neighbor node break while a link with another interface of the neighbor node
remains intact). remains).
- The N_ASYM_time field of a neighbor tuple expires and - The N_ASYM_time field of a neighbor tuple expires and
N_SYM_time is expired. The link is then considered lost. N_SYM_time is expired. The link is then considered lost.
- A new neighbor tuple is inserted in the Neighbor Set with a - A new neighbor tuple is inserted in the Neighbor Set with a
valid N_SYM_time or a tuple with expired N_SYM_time is modi- non-expired N_SYM_time or a tuple with expired N_SYM_time is
fied so that N_SYM_time becomes valid. This is considered as a modified so that N_SYM_time becomes non-expired. This is con-
neighbor appearance if there was previously no link with the sidered as a neighbor appearance if there was previously no
corresponding neighbor node. link with the corresponding neighbor node.
A change in the 2-hop neighborhood is detected when a 2-hop neighbor A change in the 2-hop neighborhood is detected when a 2-hop neighbor
tuple expires or is deleted according to the HELLO message processing tuple expires or is deleted according to the HELLO message processing
section. section.
The following processing should occur when changes in the neighbor- The following processing should occur when changes in the neighbor-
hood or the 2-hop neighborhood are detected: hood or the 2-hop neighborhood are detected:
- In case of neighbor loss, all the 2-hop tuples with - In case of neighbor loss, all the 2-hop tuples with
N_main_addr == Main Address of the neighbor are deleted. N_main_addr == Main Address of the neighbor are deleted.
- In case of neighbor loss, all the MPR selector tuples with - In case of neighbor loss, all the MPR selector tuples with
MS_main_addr == Main Address of the neighbor are deleted MS_main_addr == Main Address of the neighbor are deleted
- The MPR set is re-calculated when a neighbor appearance or - The MPR set is re-calculated when a neighbor appearance or
loss is detected, or when a change in the 2-hop neighborhood loss is detected, or when a change in the 2-hop neighborhood
is detected. is detected.
- An additional HELLO message may be sent when the MPR set - An additional HELLO message MAY be sent when the MPR set
changes. changes.
2.2.6. Advanced Neighbor Sensing Functioning 2.2.7. Advanced Neighbor Sensing Functioning
Established links should be as reliable as possible to avoid data Established links should be as reliable as possible to avoid data
packet loss. To enhance the reliability of the neighbor sensing mech- packet loss. To enhance the reliability of the neighbor sensing mech-
anism, the following implementation recommendations should be consid- anism, the following implementation recommendations should be consid-
ered. ered.
Each neighbor tuple in the neighbor set SHOULD, in addition to what Each neighbor tuple in the neighbor set SHOULD, in addition to what
is described in previous sections, include a N_pending field, a is described in previous sections, include a N_pending field, a
N_quality field, and a N_LOST_time field. N_pending is a boolean N_quality field, and a N_LOST_time field. N_pending is a boolean
value specifying if the link is considered pending (i.e. the link is value specifying if the link is considered pending (i.e. the link is
skipping to change at page 31, line 11 skipping to change at page 32, line 5
Apart from the above points, what has been described previously does Apart from the above points, what has been described previously does
not interfere with these advanced neighbor sensing fields in the not interfere with these advanced neighbor sensing fields in the
neighbor tuples. The N_quality, N_pending and N_LOST_time fields are neighbor tuples. The N_quality, N_pending and N_LOST_time fields are
exclusively updated according to the present section. Advanced neigh- exclusively updated according to the present section. Advanced neigh-
bor sensing does not modify the function of any other fields in the bor sensing does not modify the function of any other fields in the
neighbor tuples. neighbor tuples.
This advanced functioning is described as separately as possible to This advanced functioning is described as separately as possible to
increase readability. increase readability.
2.2.6.1. Link Hysteresis 2.2.7.1. Link Hysteresis
The link between a node and some of its neighbor interfaces might be The link between a node and some of its neighbor interfaces might be
"bad", i.e. from time to time let HELLOs pass through only to fade "bad", i.e. from time to time let HELLOs pass through only to fade
out immediately after. In this case, the neighbor information base out immediately after. In this case, the neighbor information base
would contain a bad link for at least NEIGHB_HOLD_TIME. In absence of would contain a bad link for at least NEIGHB_HOLD_TIME. In absence of
link layer notification, such a bad link might affect routing badly. link layer notification, such a bad link might affect routing badly.
To cope with such unstable links, the following hysteresis strategy To cope with such unstable links, the following hysteresis strategy
SHOULD be adopted. SHOULD be adopted.
For each neighbor interface NI heard by interface I, the N_quality For each neighbor interface NI heard by interface I, the N_quality
field of the corresponding Neighbor Tuple determines the establish- field of the corresponding Neighbor Tuple determines the establish-
ment of the link. The value of N_qualityis compared to two thresholds ment of the link. The value of N_quality is compared to two thresh-
HYST_THRESHOLD_HIGH, HYST_THRESHOLD_LOW, fixed between 0 and 1 and olds HYST_THRESHOLD_HIGH, HYST_THRESHOLD_LOW, fixed between 0 and 1
such that HYST_THRESHOLD_HIGH >= HYST_THRESHOLD_LOW. and such that HYST_THRESHOLD_HIGH >= HYST_THRESHOLD_LOW.
The N_pending field is set according to the following: The N_pending field is set according to the following:
1 if N_quality > HYST_THRESHOLD_HIGH: 1 if N_quality > HYST_THRESHOLD_HIGH:
N_pending = false N_pending = false
N_LOST_time = current time - 1 (expired) N_LOST_time = current time - 1 (expired)
2 otherwise, if N_quality < HYST_THRESHOLD_LOW: 2 otherwise, if N_quality < HYST_THRESHOLD_LOW:
skipping to change at page 32, line 24 skipping to change at page 33, line 15
tion after normalization. tion after normalization.
If no signal/noise information is available from the link layer, an If no signal/noise information is available from the link layer, an
algorithm such as the following can be utilized. The algorithm is algorithm such as the following can be utilized. The algorithm is
parameterized by a scaling parameter HYST_SCALING which is a number parameterized by a scaling parameter HYST_SCALING which is a number
fixed between 0 and 1. For each neighbor interface NI heard by inter- fixed between 0 and 1. For each neighbor interface NI heard by inter-
face I, the first time NI is heard by I, N_quality is set to face I, the first time NI is heard by I, N_quality is set to
HYST_SCALING (N_pending is set to true and N_LOST_time to current HYST_SCALING (N_pending is set to true and N_LOST_time to current
time - 1). time - 1).
A tuple is updated according to two rules. Every time an OLSR mes- A tuple is updated according to two rules. Every time an OLSR packet
sage emitted by NI is received by I, the stability rule is applied: emitted by NI is received by I, the stability rule is applied:
N_quality = (1-HYST_SCALING)*N_quality + HYST_SCALING. N_quality = (1-HYST_SCALING)*N_quality + HYST_SCALING.
When an OLSR message emitted by NI is lost by I, the instability When an OLSR packet emitted by NI is lost by I, the instability
rule is applied: rule is applied:
N_quality = (1-HYST_SCALING)*N_quality. N_quality = (1-HYST_SCALING)*N_quality.
The loss of OLSR messages is detected by tracking the missing Message The loss of OLSR packet is detected by tracking the missing Packet
Sequence Numbers and by long period of silence. If no HELLO message Sequence Numbers on a per interface basis and by long period of
has been received for a HELLO_INTERVAL period, a loss of HELLO mes- silence. If no HELLO message has been received for a HELLO_INTERVAL
sage is detected. period, a loss of HELLO message is detected.
2.2.6.2. Optional Link layer notification 2.2.7.2. Optional Link layer notification
OLSR is designed not to impose or expect any specific information OLSR is designed not to impose or expect any specific information
from the link layer. However, if information from the link-layer is from the link layer. However, if information from the link-layer is
available, a node MAY use this as described in this section. available, a node MAY use this as described in this section.
If link layer information describing connectivity to neighboring If link layer information describing connectivity to neighboring
nodes is available (i.e. loss of connectivity such as through absence nodes is available (i.e. loss of connectivity such as through absence
of a link layer acknowledgment), this information is used in addition of a link layer acknowledgment), this information is used in addition
to the information from the HELLO-messages to maintain the neighbor to the information from the HELLO-messages to maintain the neighbor
information base and the MPR selector set. information base and the MPR selector set.
skipping to change at page 33, line 28 skipping to change at page 34, line 19
2.3. Topology Discovery 2.3. Topology Discovery
The Neighbor Sensing part of the protocol basically offers to each The Neighbor Sensing part of the protocol basically offers to each
node a list of neighbors with which it can communicate directly and node a list of neighbors with which it can communicate directly and
an optimized flooding mechanism through MPRs. Based on this mecha- an optimized flooding mechanism through MPRs. Based on this mecha-
nism, topology information is disseminated through the network. The nism, topology information is disseminated through the network. The
present section describes what part of the information given by the present section describes what part of the information given by the
Neighbor Sensing is disseminated and how it is used to construct Neighbor Sensing is disseminated and how it is used to construct
routes. routes.
Routes are constructed through MPR-links and links with neighbors. A Routes are constructed through advertised links and links with neigh-
node thus basically disseminates its MPR-selector set. If a node has bors. A node must at least disseminate its MPR-selector set, in order
to provide sufficient information to enable routing. If a node has
multiple interfaces, it must also disseminate the list of its inter- multiple interfaces, it must also disseminate the list of its inter-
face addresses. face addresses.
2.3.1. TC Message Format 2.3.1. TC Message Format
The proposed format of a TC message is The proposed format of a TC message is
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSSN | Reserved | | MSSN | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipoint Relay Selector Main Address | | Advertized neighbor Main Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipoint Relay Selector Main Address | | Advertized neighbor Main Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is sent as the data-portion of the general message format with This is sent as the data-portion of the general message format with
the "Message Type" set to TC_MESSAGE. The time to live SHOULD be set the "Message Type" set to TC_MESSAGE. The time to live SHOULD be set
to 255 (maximum value) to diffuse the message into the entire net- to 255 (maximum value) to diffuse the message into the entire net-
work. work.
MPR Selector Sequence Number (MSSN) MPR Selector Sequence Number (MSSN)
A sequence number is associated with the MPR selector set. A sequence number is associated with the advertized neighbor
Every time a node detects a change in its MPR selector set, it set. Every time a node detects a change in its advertized
increments this sequence number. This number is sent in this neighbor set, it increments this sequence number. This number
MSSN field of the TC message to keep track of the most recent is sent in this MSSN field of the TC message to keep track of
information. When a node receives a TC message, it can decide the most recent information. When a node receives a TC mes-
on the basis of this MPR Sequence Number, whether or not the sage, it can decide on the basis of this MPR Selector Sequence
received information about the MPR selectors of the originator Number, whether or not the received information about the MPR
node is more recent than what it already has. selectors of the originator node is more recent than what it
already has.
Multipoint Relay Selector Main Address Advertized Neighbor Main Address
This field contains the main address of a node, which has This field contains the main address of a neighbor node. All
selected the Originator node (of the TC message) as a MPR. main addresses of the MPR selectors of the Originator node are
All addresses of the MPR selectors of the Originator node are
put in the TC message. If the maximum allowed message size (as put in the TC message. If the maximum allowed message size (as
imposed by the network) is reached while there are still MPR imposed by the network) is reached while there are still MPR
selector addresses which have not been inserted into the TC- selector addresses which have not been inserted into the TC-
message, more TC messages will be generated until the entire message, more TC messages will be generated until the entire
MPR selector set has been sent. MPR selector set has been sent. Extra main addresses of neigh-
bor nodes may be included, if redundancy is desired.
Reserved Reserved
This field is reserved for future usage, and MUST be set to This field is reserved for future usage, and MUST be set to
"0000000000000000" for compliance with this draft. "0000000000000000" for compliance with this draft.
2.3.2. Topology Information Base 2.3.2. Topology Information Base
Each node in the network maintains topological information about the Each node in the network maintains topological information about the
network. This information is acquired from TC-messages and is used network. This information is acquired from TC-messages and is used
skipping to change at page 35, line 5 skipping to change at page 35, line 43
Thus, for each destination in the network, a "Topology Tuple" Thus, for each destination in the network, a "Topology Tuple"
(T_dest, T_last, T_seq, T_time) is recorded. T_dest is the main (T_dest, T_last, T_seq, T_time) is recorded. T_dest is the main
address of a node, which may be reached in one hop from the node with address of a node, which may be reached in one hop from the node with
the main address T_last. Typically, T_last is a MPR of T_dest. T_seq the main address T_last. Typically, T_last is a MPR of T_dest. T_seq
is a sequence number, and T_time specifies the time at which this is a sequence number, and T_time specifies the time at which this
tuple expires and *MUST* be removed. tuple expires and *MUST* be removed.
In a node, the set of Topology Tuples are denoted the "Topology Set". In a node, the set of Topology Tuples are denoted the "Topology Set".
2.3.3. TC Message Generation 2.3.3. Advertized Neighbor Set
A TC message is sent by a node in the network to declare a set of
links, called the advertized neighbor set, which MUST include at
least the links to all nodes of its MPR Selector set, i.e., the
neighbors which have selected the sender node as a MPR.
The sequence number (MSSN) associated with the advertized neighbor
set is also sent with the list. The MSSN number MUST be incremented
when links are removed from the advertized neighbor set; the MSSN
number SHOULD be incremented when links are added to the advertized
neighbor set.
In order to provide redundancy to the topology information base, the
advertized neighbor set of a node can contain links to neighbor nodes
which are not in the MPR selector set of the node. The advertized
neighbor set can be the whole neighbor set of the node. In this case
the nodes receiving the TC message will get the knowledge of all the
adjacent links of the sender node. The advertized neighbor set can be
built according to the following rule based on a local parameter
called TC_REDUNDANCY.
1 if the TC_REDUNDANCY parameter of the node is zero, then its
advertized neighbor set is limited to the MPR selector set.
2 If the TC_REDUNDANCY parameter of the node is one, then its
advertized neighbor set is the union of its MPR set and its
MPR selector set.
3 If the TC_REDUNDANCY parameter of the node is two, then its
advertized neighbor set is its neighbor set.
A node with willingness equal to zero SHOULD have TC_REDUNDANCY also
equal to zero.
2.3.4. TC Message Generation
In order to build the topology information base needed, each node, In order to build the topology information base needed, each node,
which has been selected as MPR, broadcasts Topology Control (TC) mes- which has been selected as MPR, broadcasts Topology Control (TC) mes-
sages. TC messages are flooded to all nodes in the network and take sages. TC messages are flooded to all nodes in the network and take
advantage of MPRs. MPRs enable a better scalability in the distribu- advantage of MPRs. MPRs enable a better scalability in the distribu-
tion of topology information [1]. tion of topology information [1].
A TC message is sent by a node in the network to declare its MPR The list of addresses can be partial in each TC message (e.g. due to
Selector set. I.e., the TC message contains the list of neighbors message size limitations, imposed by the network), but parsing of all
which have selected the sender node as a MPR. The sequence number TC messages describing the advertized neighbor set of a node MUST be
(MSSN) associated with this MPR selector set is also sent with the
list. The list of addresses can be partial in each TC message (e.g.
due to message size limitations, imposed by the network), but parsing
of all TC messages describing the MPR selector set of a node MUST be
complete within a certain refreshing period (TC_INTERVAL). The infor- complete within a certain refreshing period (TC_INTERVAL). The infor-
mation diffused in the network by these TC messages will help each mation diffused in the network by these TC messages will help each
node calculate its routing table. node calculate its routing table.
A node which has an empty MPR selector set, i.e. nobody has selected A node which has an empty advertized neighbor set may not generate
it as a MPR, may not generate any TC message. Indeed, when its MPR any TC message. Indeed, when its advertized neighbor set becomes
selector set becomes empty, it SHOULD still send (empty) TC-messages empty, it SHOULD still send (empty) TC-messages during TOP_HOLD_TIME
during TOP_HOLD_TIME to invalidate the previous TC-messages. It MAY to invalidate the previous TC-messages. It MAY then stop sending TC-
then stop sending TC-messages until some node is inserted in its MPR messages until some node is inserted in its advertized neighbor set.
selector set.
A node MAY transmit additional TC-messages to increase its reactive- A node MAY transmit additional TC-messages to increase its reactive-
ness to link failures. I.e. when a change to the MPR selector set is ness to link failures. I.e. when a change to the MPR selector set is
detected and this change can be attributed to a link failure, a TC- detected and this change can be attributed to a link failure, a TC-
message SHOULD be transmitted after a shorter interval than TC_INTER- message SHOULD be transmitted after a shorter interval than TC_INTER-
VAL. VAL.
2.3.4. TC Message Processing 2.3.5. TC Message Processing
TC messages are broadcasted and retransmitted by the MPRs in order to TC messages are broadcasted and retransmitted by the MPRs in order to
diffuse the messages in the entire network. diffuse the messages in the entire network.
In this section, the term "originator" is used to designate the node In this section, the term "originator" is used to designate the node
from which the message originally originated, while the term "sender" from which the message originally originated, while the term "sender"
is used to designate the node from which the message was received is used to designate the node from which the message was received
(i.e. the "last hop" of the message). (i.e. the "last hop" of the message).
The tuples in the topology set are recorded with the topology infor- The tuples in the topology set are recorded with the topology infor-
skipping to change at page 36, line 36 skipping to change at page 38, line 13
of order). of order).
4 All tuples in the topology set where: 4 All tuples in the topology set where:
T_last == originator address AND T_last == originator address AND
T_seq < MSSN T_seq < MSSN
are removed from the topology set. are removed from the topology set.
5 For each of the MPR selector address received in the TC mes- 5 For each of the advertized neighbor main address received in
sage: the TC message:
5.1 If there exist some tuple in the topology set where: 5.1 If there exist some tuple in the topology set where:
T_dest == MPR selector address, AND T_dest == advertized neighbor main address, AND
T_last == originator address, T_last == originator address,
then the holding time of that tuple is set to: then the holding time of that tuple is set to:
T_time = current time + TOP_HOLD_TIME. T_time = current time + TOP_HOLD_TIME.
5.2 Otherwise, a new tuple is recorded in the topology set 5.2 Otherwise, a new tuple is recorded in the topology set
where: where:
T_dest = MPR selector address, T_dest = advertized neighbor main address,
T_last = originator address, T_last = originator address,
T_seq = MSSN, T_seq = MSSN,
T_time = current time + TOP_HOLD_TIME. T_time = current time + TOP_HOLD_TIME.
6 If the sender address is an interface address of a MPR selec- 6 If the sender address is an interface address of a MPR selec-
tor of this node and if the time to live of the message is tor of this node and if the time to live of the message is
greater than '1', the message MUST be forwarded according to greater than '1', the message MUST be forwarded according to
the following: the following:
6.1 The TTL of the message is reduced by one. 6.1 The TTL of the message is reduced by one.
6.2 The hop-count of the message is increased by one 6.2 The hop-count of the message is increased by one
6.3 The message is broadcasted on all interfaces (Notice: The 6.3 The message is broadcasted on all interfaces (Notice: The
remaining fields of the message header SHOULD be left remaining fields of the message header SHOULD be left
unmodified.) unmodified.)
2.3.5. Multiple Interface Association 2.3.6. Multiple Interface Association
Each node in the network maintains interface information about the Each node in the network maintains interface information about the
other nodes in the network. This information acquired from MID-mes- other nodes in the network. This information acquired from MID-mes-
sages, emitted by nodes with multiple interfaces participating in the sages, emitted by nodes with multiple interfaces participating in the
MANET, and is used for routing table calculations. MANET, and is used for routing table calculations.
2.3.5.1. Multiple Interface Association Information Base 2.3.6.1. Multiple Interface Association Information Base
For each destination in the network, "Interface association Tuples" For each destination in the network, "Interface association Tuples"
(I_if_addr, I_main_addr, I_time) are recorded. I_if_addr is an inter- (I_if_addr, I_main_addr, I_time) are recorded. I_if_addr is an inter-
face address of a node, I_main_addr is the main address of this node. face address of a node, I_main_addr is the main address of this node.
I_time specifies the time at which this tuple expires and *MUST* be I_time specifies the time at which this tuple expires and *MUST* be
removed. removed.
In a node, the set of Interface association Tuples is denoted the In a node, the set of Interface association Tuples is denoted the
"Interface association Set". "Interface association Set".
2.3.5.2. MID Message Format 2.3.6.2. MID Message Format
The proposed format of a MID message is The proposed format of a MID message is
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Address | | Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Address | | Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 38, line 31 skipping to change at page 40, line 9
This field contains the address of an interface of the node This field contains the address of an interface of the node
other than its main address (already indicated in the origina- other than its main address (already indicated in the origina-
tor address). All interface addresses other than the main tor address). All interface addresses other than the main
address of the Originator node are put in the MID message. If address of the Originator node are put in the MID message. If
the maximum allowed message size (as imposed by the network) the maximum allowed message size (as imposed by the network)
is reached while there are still interface addresses which is reached while there are still interface addresses which
have not been inserted into the MID-message, more MID messages have not been inserted into the MID-message, more MID messages
are generated until the entire interface addresses set has are generated until the entire interface addresses set has
been sent. been sent.
2.3.5.3. MID Message Generation 2.3.6.3. MID Message Generation
In order to build the interface association information base, each In order to build the interface association information base, each
node with multiple interfaces broadcast Multiple Interface Declara- node with multiple interfaces broadcast Multiple Interface Declara-
tion (MID) messages. MID messages are flooded to all nodes in the tion (MID) messages. MID messages are flooded to all nodes in the
network and take advantage of MPRs. network and take advantage of MPRs.
A MID message is sent by a node in the network to declare its multi- A MID message is sent by a node in the network to declare its multi-
ple interfaces (if any). I.e., the MID message contains the list of ple interfaces (if any). I.e., the MID message contains the list of
interface addresses which are associated to its main address. The interface addresses which are associated to its main address. The
list of addresses can be partial in each TC message (e.g. due to mes- list of addresses can be partial in each TC message (e.g. due to mes-
sage size limitations, imposed by the network), but parsing of all sage size limitations, imposed by the network), but parsing of all
MID messages describing a nodes interface set MUST be complete within MID messages describing a nodes interface set MUST be complete within
a certain refreshing period (MID_INTERVAL). The information diffused a certain refreshing period (MID_INTERVAL). The information diffused
in the network by these MID messages will help each node to calculate in the network by these MID messages will help each node to calculate
its routing table. A node which has only a single interface address its routing table. A node which has only a single interface address
participating in the MANET (i.e. running OLSR), MUST NOT generate any participating in the MANET (i.e. running OLSR) and this address is
MID message. its main address, MUST NOT generate any MID message.
A node with more interfaces, where only one is participating in the A node with more interfaces, where only one is participating in the
MANET and running OLSR (e.g. a node is connected to a wired network MANET and running OLSR (e.g. a node is connected to a wired network
as well as to a MANET) MUST NOT generate any MID messages. as well as to a MANET) MUST NOT generate any MID messages.
2.3.5.4. MID Message Processing 2.3.6.4. MID Message Processing
MID messages are broadcasted and retransmitted by the MPRs in order MID messages are broadcasted and retransmitted by the MPRs in order
to diffuse the messages in the entire network. to diffuse the messages in the entire network.
In this section, the term "originator" is used to designate the node In this section, the term "originator" is used to designate the node
from which the message originally originated, while the term "sender" from which the message originally originated, while the term "sender"
is used to designate the node from which the message was received is used to designate the node from which the message was received
(i.e. the "last hop" of the message). (i.e. the "last hop" of the message).
The tuples in the multiple interface association set are recorded The tuples in the multiple interface association set are recorded
skipping to change at page 40, line 27 skipping to change at page 42, line 5
the following: the following:
4.1 The TTL of the message is reduced by one. 4.1 The TTL of the message is reduced by one.
4.2 The hop-count of the message is increased by one 4.2 The hop-count of the message is increased by one
4.3 The message is broadcasted on all interfaces (Notice: The 4.3 The message is broadcasted on all interfaces (Notice: The
remaining fields of the message header SHOULD be left remaining fields of the message header SHOULD be left
unmodified.) unmodified.)
2.3.6. Associated Networks and Hosts 2.3.7. Associated Networks and Hosts
A node MAY provide access to a set of associated hosts. I.e., a node A node MAY provide access to a set of associated hosts. I.e., a node
may act as a "gateway" between the MANET and a number of associated may act as a "gateway" between the MANET and a number of associated
hosts and/or subnets, not running OLSR and thus not participating in hosts and/or subnets, not running OLSR and thus not participating in
the MANET. Thus, a node SHOULD be able to inject routing information the MANET. Thus, a node SHOULD be able to inject routing information
describing these associated hosts or networks into MANET, as SHOULD describing these associated hosts or networks into MANET, as SHOULD
all nodes be capable of interpreting such information. all nodes be capable of interpreting such information.
Notice that this is a different case from that of "multiple inter- Notice that this is a different case from that of "multiple inter-
faces", described previously. Where, in the "Multiple Interface Asso- faces", described previously. Where, in the "Multiple Interface Asso-
skipping to change at page 41, line 5 skipping to change at page 42, line 28
interfaces which do not participate. This is, e.g., the case where a interfaces which do not participate. This is, e.g., the case where a
node has both a wireless interface (participating in the MANET) and a node has both a wireless interface (participating in the MANET) and a
wired interface, through which a number of hosts statically connect wired interface, through which a number of hosts statically connect
(to the nodes in the MANET). (to the nodes in the MANET).
To accomplish this, a node, to which there are associated hosts To accomplish this, a node, to which there are associated hosts
and/or networks, periodically issues an Host and Network Association and/or networks, periodically issues an Host and Network Association
(HNA) message, containing sufficient information for the recipients (HNA) message, containing sufficient information for the recipients
to construct an appropriate routing table. to construct an appropriate routing table.
2.3.6.1. HNA Message Format 2.3.7.1. HNA Message Format
The proposed format of an HNA-message is: The proposed format of an HNA-message is:
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Address | | Network Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Netmask | | Netmask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 41, line 44 skipping to change at page 43, line 20
Network Address Network Address
The network address of the associated network The network address of the associated network
Netmask Netmask
The netmask, corresponding to the network address immediately The netmask, corresponding to the network address immediately
above. above.
2.3.6.2. Host and Network Association Information Base 2.3.7.2. Host and Network Association Information Base
Each node maintains information concerning which nodes may act as Each node maintains information concerning which nodes may act as
"gateways" to associated hosts and networks by recording "association "gateways" to associated hosts and networks by recording "association
tuples" (GW_main_addr, NET_addr, NET_mask, GS_time), where tuples" (GW_main_addr, NET_addr, NET_mask, GS_time), where
GW_main_addr is the main address of the gateway, NET_addr and GW_main_addr is the main address of the gateway, NET_addr and
NET_mask specifies the network address and netmask of a network, NET_mask specifies the network address and netmask of a network,
reachable through this gateway, and GS_time specifies the time at reachable through this gateway, and GS_time specifies the time at
which this tuple expires and hence *MUST* be removed. which this tuple expires and hence *MUST* be removed.
The set of all association tuples in a node is called the "associa- The set of all association tuples in a node is called the "associa-
tion set". tion set".
2.3.6.3. HNA Message Generation 2.3.7.3. HNA Message Generation
A node with associated hosts and/or networks SHOULD periodically gen- A node with associated hosts and/or networks SHOULD periodically gen-
erate a Host and Network Association (HNA) message, containing pairs erate a Host and Network Association (HNA) message, containing pairs
of (network address, netmask) corresponding to the connected hosts and of (network address, netmask) corresponding to the connected hosts and
networks. HNA-messages SHOULD be transmitted periodically every networks. HNA-messages SHOULD be transmitted periodically every
HNA_INTERVAL. HNA_INTERVAL.
A node without any associated hosts and/or networks SHOULD NOT gener- A node without any associated hosts and/or networks SHOULD NOT gener-
ate HNA-messages. ate HNA-messages.
2.3.6.4. HNA Message Processing 2.3.7.4. HNA Message Processing
In this section, the term "originator address" is used to designate In this section, the term "originator address" is used to designate
the main address of the node which originally issued the HNA-message. the main address of the node which originally issued the HNA-message.
Upon receiving a HNA-message, the node performs the following: Upon receiving a HNA-message, the node performs the following:
1 An entry in the duplicate set is recorded for this message 1 An entry in the duplicate set is recorded for this message
with: with:
D_addr = originator address D_addr = originator address
skipping to change at page 43, line 26 skipping to change at page 45, line 4
GW_time = current time + GW_HOLDING_TIME GW_time = current time + GW_HOLDING_TIME
3 If the sender address is an interface address of a MPR selec- 3 If the sender address is an interface address of a MPR selec-
tor of this node and if the time to live of the message is tor of this node and if the time to live of the message is
greater than '1', the message MUST be forwarded according to greater than '1', the message MUST be forwarded according to
the following: the following:
3.1 The TTL of the message is reduced by one. 3.1 The TTL of the message is reduced by one.
3.2 The hop-count of the message is increased by one 3.2 The hop-count of the message is increased by one
3.3 The message is broadcasted on all interfaces (Notice: The 3.3 The message is broadcasted on all interfaces (Notice: The
remaining fields of the message header SHOULD be left remaining fields of the message header SHOULD be left
unmodified.) unmodified.)
2.3.7. Routing Table Calculation 2.3.8. Routing Table Calculation
Each node maintains a routing table which allows it to route data, Each node maintains a routing table which allows it to route data,
destined for the other nodes in the network. The routing table is destined for the other nodes in the network. The routing table is
based on the information contained in the neighbor sensing informa- based on the information contained in the neighbor sensing informa-
tion base, the interface association set and the topology set. There- tion base, the interface association set, the topology set and the
fore, if any of these tables are changed, the routing table is re- host and network association set. Therefore, if any of these tables
calculated to update the route information about each destination in are changed, the routing table is re-calculated to update the route
the network. The route entries are recorded in the routing table in information about each destination in the network. The route entries
the following format: are recorded in the routing table in the following format:
1. R_dest R_next R_dist R_if_id 1. R_dest R_next R_dist R_if_id
2. R_dest R_next R_dist R_if_id 2. R_dest R_next R_dist R_if_id
3. ,, ,, ,, 3. ,, ,, ,,
Each entry in the table consists of R_dest, R_next, R_dist, and Each entry in the table consists of R_dest, R_next, R_dist, and
R_if_id which specifies that the node identified by R_dest is esti- R_if_id which specifies that the node identified by R_dest is esti-
mated to be R_dist hops away from the local node, and that the sym- mated to be R_dist hops away from the local node, and that the sym-
metric neighbor node with interface address R_next is the next hop metric neighbor node with interface address R_next is the next hop
node in the route to R_dest, and this one hop is reachable through node in the route to R_dest, and this one hop is reachable through
the local interface the local interface
R_if_id. Entries are recorded in the table for each destination in R_if_id. Entries are recorded in the table for each destination in
the network for which the route is known. All the destinations for the network for which the route is known. All the destinations for
which the route is broken or partially known are not entered in the which the route is broken or partially known are not entered in the
table. table.
skipping to change at page 44, line 16 skipping to change at page 45, line 35
mated to be R_dist hops away from the local node, and that the sym- mated to be R_dist hops away from the local node, and that the sym-
metric neighbor node with interface address R_next is the next hop metric neighbor node with interface address R_next is the next hop
node in the route to R_dest, and this one hop is reachable through node in the route to R_dest, and this one hop is reachable through
the local interface the local interface
R_if_id. Entries are recorded in the table for each destination in R_if_id. Entries are recorded in the table for each destination in
the network for which the route is known. All the destinations for the network for which the route is known. All the destinations for
which the route is broken or partially known are not entered in the which the route is broken or partially known are not entered in the
table. table.
This routing table is updated when a change is detected in the neigh- This routing table is updated when a change is detected in the neigh-
bor information base, or the topology set. More precisely, it is re- bor information base, the interface association set or the topology
calculated in case of neighbor appearance or loss, or when a topology set. More precisely, it is re-calculated in case of neighbor appear-
tuple is created or removed. The update of this routing information ance or loss, or when a topology tuple is created or removed. The
does not generate or trigger any messages to be transmitted, neither update of this routing information does not generate or trigger any
in the network, nor in the one-hop neighborhood. messages to be transmitted, neither in the network, nor in the one-
hop neighborhood.
To construct the routing table of node X, a shortest path algorithm To construct the routing table of node X, a shortest path algorithm
is run on the directed graph containing the arcs X -> Y where Y is is run on the directed graph containing the arcs X -> Y where Y is
any symmetric neighbor of X (with Link Type SYM_LINK or MPR_LINK) and any symmetric neighbor of X (with Link Type SYM_LINK or MPR_LINK) and
the arcs U -> V where there exists an entry in the topology set with the arcs U -> V where there exists an entry in the topology set with
V as T_dest and U as T_last. V as T_dest and U as T_last.
The following procedure is given as an example to calculate (or re- The following procedure is given as an example to calculate (or re-
calculate) the routing table : calculate) the routing table :
skipping to change at page 45, line 42 skipping to change at page 47, line 20
R_next = R_next of the recorded route entry whose R_next = R_next of the recorded route entry whose
R_dest == T_last R_dest == T_last
R_dist = h+1; and R_dist = h+1; and
R_if_id = R_if_id of the recorded route entry whose R_if_id = R_if_id of the recorded route entry whose
R_dest == T_last. R_dest == T_last.
3.2 Several topology entries may be used to select a next hop 3.2 Several topology entries may be used to select a next hop
R_next for reaching the node R_dest. When h=1, ties R_next for reaching the node R_dest. When h=1, ties
should be broken such that MPR selectors are preferred as should be broken such that nodes with highest willingness
next hop. and MPR selectors are preferred as next hop.
The routing table is further completed by using the multiple inter- The routing table is further completed by using the multiple inter-
face association set: face association set:
1 For each entry in the multiple interface association base 1 For each entry in the multiple interface association base for
where there exists a routing entry such that: which there exists a routing entry such that:
R_dest == I_main_addr (of the multiple interface inter- R_dest == I_main_addr (of the multiple interface inter-
face association entry) face association entry)
a route entry is created in the routing table with: a route entry is created in the routing table with:
R_dest = I_if_addr (of the multiple interface associa- R_dest = I_if_addr (of the multiple interface associa-
tion entry) tion entry)
R_next = R_next (of the recorded route entry) R_next = R_next (of the recorded route entry)
R_dist = R_dist (of the recorded route entry) R_dist = R_dist (of the recorded route entry)
R_if_id = R_if_id (of the recorded route entry). R_if_id = R_if_id (of the recorded route entry).
The routing table is finally completed by using the host and network The routing table is finally completed by using the host and network
association set: association set:
1 For each tuple in the routing set, record an entry in the 1 For each tuple in the host and network association set, record
routing table, with: an entry in the routing table, with:
R_dest = NET_addr/NET_mask R_dest = NET_addr/NET_mask
R_next = the next hop on the path from the node to R_next = the next hop on the path from the node to
GW_main_addr GW_main_addr
R_dist = dist to GW_main_addr R_dist = dist to GW_main_addr
R_next and R_if_id are set to the same values as the R_next and R_if_id are set to the same values as the
tuple from the routing set with R_dest == GW_main_addr. tuple from the routing set with R_dest == GW_main_addr.
2.3.8. Advanced Topology Discovery Functioning 2.3.9. Advanced Topology Discovery Functioning
Due to mobility, some links of the broadcasted topology may fail. Due to mobility, some links of the broadcasted topology may fail.
Additional messages may be sent to recover quickly. Ideally the load Additional messages may be sent to recover quickly. Ideally the load
of control messages should increase smoothly with mobility. This sec- of control messages should increase smoothly with mobility. This sec-
tion describes how this may be achieved in OLSR. tion describes how this may be achieved in OLSR.
2.3.8.1. Reaction to Link Failure with a MPR Selector 2.3.9.1. Reaction to Link Failure with a MPR Selector
Detection of a link failure between a node and one of its MPR selec- Detection of a link failure between a node and one of its MPR selec-
tors through a link-layer notification may trigger additional TC- tors through a link-layer notification may trigger additional TC-mes-
messages to increase the protocol reactiveness to link failures. I.e. sages to increase the protocol reactiveness to link failures. I.e.
when a change to the MPR selector set is detected and this change can when a change to the MPR selector set is detected and this change can
be attributed to a link failure, an additional TC-message MAY be be attributed to a link failure, an additional TC-message MAY be
transmitted. transmitted.
More precisely, if a link failure appears to be a neighbor loss with More precisely, if a link failure appears to be a neighbor loss with
a neighbor, which has selected this node as MPR, the MPR selector set a neighbor, which has selected this node as MPR, the MPR selector set
is updated (MSSN is thus incremented) and a TC message MAY be gener- is updated (MSSN is thus incremented) and a TC message MAY be gener-
ated. Moreover if it appears that data traffic was flowing through ated. Moreover if it appears that data traffic was flowing through
this link, a TC message SHOULD be generated. Notice, that a node may this link, a TC message SHOULD be generated. Notice, that a node may
be aware of data traffic flowing to the lost neighbor in case of a be aware of data traffic flowing to the lost neighbor in case of a
link layer notification coming from a missing acknowledgement or when link layer notification coming from a missing acknowledgement or when
statistics about packet forwarding is given by the IP stack. statistics about packet forwarding are given by the IP stack.
2.3.8.2. Advanced Fast Re-routing Mechanism 2.3.9.2. Advanced Fast Re-routing Mechanism
When a link breaks, information stored in the neighbor sensing infor- When a link breaks, information stored in the neighbor sensing infor-
mation base may be used to compute an alternative route immediately mation base may be used to compute an alternative route immediately
if necessary. if necessary.
If there exists a N_2hop_address listed in the 2-hop neighbor set, If there exists a N_2hop_address listed in the 2-hop neighbor set,
and for which no route exists, a route entry is created in the rout- and for which no route exists, a route entry is created in the rout-
ing table with: ing table with:
R_dest = N_2hop_address R_dest = N_2hop_address
skipping to change at page 48, line 8 skipping to change at page 49, line 31
greater than 2 according to the topology set then other entries may greater than 2 according to the topology set then other entries may
be added in the routing table with same R_next for these nodes. be added in the routing table with same R_next for these nodes.
The routing table is finally completed using the multiple interface The routing table is finally completed using the multiple interface
association set and the host and network association set as described association set and the host and network association set as described
in the routing table calculation section. in the routing table calculation section.
To allow other nodes to benefit from the alternative route, the node To allow other nodes to benefit from the alternative route, the node
MAY trigger a fast re-routing event by generating a FRR message. MAY trigger a fast re-routing event by generating a FRR message.
2.3.8.2.1. FRR Message Format 2.3.9.2.1. FRR Message Format
The proposed format of a FRR message is The proposed format of a FRR message is
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Address | | Next Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Two Hop Address | | Two Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 48, line 40 skipping to change at page 50, line 17
This field contains the main address of a node which is used This field contains the main address of a node which is used
as next hop by the Originator for reaching all the nodes iden- as next hop by the Originator for reaching all the nodes iden-
tified by the Two Hop Address fields. tified by the Two Hop Address fields.
Two Hop Address Two Hop Address
This field contain the main address of a 2-hop neighbor of the This field contain the main address of a 2-hop neighbor of the
Originator of the message. Originator of the message.
2.3.8.2.2. FRR Message Generation 2.3.9.2.2. FRR Message Generation
When the fast re-routing mechanism allows to reach 2-hop neighbors When the fast re-routing mechanism allows to reach 2-hop neighbors
through a neighbor which is not recorded as MPR of them in the topol- through a neighbor which is not recorded as MPR of them in the topol-
ogy set, the node MAY inform this next hop by generating a FRR Mes- ogy set, the node MAY inform this next hop by generating a FRR Mes-
sage with Next Hop Address containing the main address of this next sage with Next Hop Address containing the main address of this next
hop and listing the main addresses of these 2-hop neighbors. hop and listing the main addresses of these 2-hop neighbors.
If some information allows to deduce that some data traffic flows If some information allows to deduce that some data traffic flows
through the node to some of these 2-hop neighbors, such a FRR Message through the node to some of these 2-hop neighbors, such a FRR Message
SHOULD be generated. This can be the case if such a 2-hop neighbor SHOULD be generated. This can be the case if such a 2-hop neighbor
was previously a neighbor and a link layer notification of a missing was previously a neighbor and a link layer notification of a missing
acknowledgement has been received or statistics about packet forward- acknowledgment has been received or statistics about packet forward-
ing are provided by the IP stack. Otherwise, an FFR-message MAY be ing are provided by the IP stack. Otherwise, an FFR-message MAY be
generated. generated.
2.3.8.2.3. FRR Message Processing 2.3.9.2.3. FRR Message Processing
Upon reception of a FRR message a node performs the following: Upon reception of a FRR message a node performs the following:
1 If the Next Hop Address field is not the main address of the 1 If the Next Hop Address field is not the main address of the
node, the message is dropped. node, the message is dropped.
2 For each Two Hop Address listed in the FRR Message for which 2 For each Two Hop Address listed in the FRR Message for which
there exists a neighbor tuple with N_main_addr = the Two Hop there exists a neighbor tuple with N_main_addr = the Two Hop
Address and for which there exists no tuple in the MPR selec- Address and for which there exists no tuple in the MPR selec-
tor set with MS_main_addr = the Two Hop Addres, a new tuple is tor set with MS_main_addr = the Two Hop Address, a new tuple
inserted with: is inserted with:
MS_main_addr = the Two Hop Addres
MS_main_addr = the Two Hop Address
MS_if_addr = N_if_addr of the corresponding neighbor MS_if_addr = N_if_addr of the corresponding neighbor
tuple tuple
MS_time = current time + 2HOP_HOLD_TIME. MS_time = current time + 2HOP_HOLD_TIME.
If the MPR set has changed then the MSSN is incremented by 1 and a TC If the MPR set has changed and a TC message containing the new MPR
message containing the new MPR selector set SHOULD be generated. selector set SHOULD be generated.
3. Node Configuration 3. Node Configuration
3.1. Address Assignment 3.1. Address Assignment
The nodes in the MANET network SHOULD be assigned addresses within a The nodes in the MANET network SHOULD be assigned addresses within a
defined address sequence. I.e., the nodes in the MANET SHOULD be defined address sequence. I.e., the nodes in the MANET SHOULD be
addressable through a network address and a netmask. addressable through a network address and a netmask.
Likewise, the nodes in each associated network SHOULD be assigned Likewise, the nodes in each associated network SHOULD be assigned
skipping to change at page 50, line 24 skipping to change at page 52, line 5
the routing table in the underlying operating system, which is the routing table in the underlying operating system, which is
assumed to be forwarding packets as specified in RFC1812. assumed to be forwarding packets as specified in RFC1812.
4. IPv6 Considerations 4. IPv6 Considerations
All the operations and parameters described in this document used by All the operations and parameters described in this document used by
OLSR for IP version 4 are the same as those used by OLSR for IP ver- OLSR for IP version 4 are the same as those used by OLSR for IP ver-
sion 6. However, to operate with IP version 6, the only required sion 6. However, to operate with IP version 6, the only required
change is to replace the IPv4 addresses with Ipv6 address. change is to replace the IPv4 addresses with Ipv6 address.
5. Proposed Values for the Constants 5. Security Considerations
Currently, OLSR does not specify any security measures. However as a
proactive routing protocol, it makes a target for various attacks.
The various possible vulnerability are discussed in this section.
5.1. Confidentiality
Being a proactive protocol, OLSR periodically diffuses topological
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 can be applied to ensure
that control traffic can be read and interpreted by only those autho-
rized to do so.
5.2. Integrity
In OLSR, each node is injecting topological information into the net-
work through transmitting HELLO messages and, for some nodes, TC mes-
sages. If some nodes for some reason, malicious or malfunction,
injects invalid control traffic, network integrity may be compro-
mised.
Different such situations may occur:
1 a node generates TC messages, adverticing links to non-neigh-
bor nodes:
2 a node generates TC messages, pretending to be another node,
3 a node generate HELLO messages, adverticing non-neighbor
nodes,
4 a node generate HELLO messages, pretending to be another node.
5 a node forwards broadcast control messages unaltered, but does
not forward unicast data traffic
Authenticated signatures on control messages (for situation 2 and 4)
and on the individual links announced in the control messages (for
situation 1 and 3) may be used as a countermeasure. However to pre-
vent nodes from repeating old (and correctly authenticated) informa-
tion temporal information is required, allowing a node to positively
identify such delayed messages.
Signatures and other required security information may be transmitted
as a separate OLSR message type, thereby allowing that "secured" and
"unsecured" nodes can coexist in the same network, if desired.
6. Proposed Values for the Constants
This section list the values for the constants used in the descrip- This section list the values for the constants used in the descrip-
tion of the protocol. tion of the protocol.
HELLO_INTERVAL = 2 seconds HELLO_INTERVAL = 2 seconds
REFRESH_INTERVAL = 2 seconds REFRESH_INTERVAL = 2 seconds
TC_INTERVAL = 5 seconds TC_INTERVAL = 5 seconds
skipping to change at page 51, line 15 skipping to change at page 54, line 4
GW_TIME = 3 x HNA_INTERVAL GW_TIME = 3 x HNA_INTERVAL
HELLO_MESSAGE = 1 HELLO_MESSAGE = 1
TC_MESSAGE = 2 TC_MESSAGE = 2
MID_MESSAGE = 3 MID_MESSAGE = 3
HNA_MESSAGE = 4 HNA_MESSAGE = 4
FRR_MESSAGE = 5
MID_MESSAGE = 5
FRR_MESSAGE = 6
ASYM_LINK = 1 ASYM_LINK = 1
SYM_LINK = 2 SYM_LINK = 2
MPR_LINK = 3 MPR_LINK = 3
LOST_LINK = 4 LOST_LINK = 4
HYST_THRESHOLD_HIGH = 0.8 HYST_THRESHOLD_HIGH = 0.8
HYST_THRESHOLD_LOW = 0.3 HYST_THRESHOLD_LOW = 0.3
HYST_SCALING = 0.5 HYST_SCALING = 0.5
MPR COVERAGE = 1 MPR COVERAGE = 1
MAXJITTER = HELLO_INTERVAL / 4 MAXJITTER = HELLO_INTERVAL / 4
6. Sequence Numbers 7. Sequence Numbers
Sequence numbers are used in OLSR with the purpose of discarding Sequence numbers are used in OLSR with the purpose of discarding
"old" information, i.e. messages received out of order. However with "old" information, i.e. messages received out of order. However with
a limited number of bits for representing sequence numbers, wrap- a limited number of bits for representing sequence numbers, wrap-
arounds (that the sequence number is incremented from the maximum arounds (that the sequence number is incremented from the maximum
possible value to zero) will occur. To prevent this from interfering possible value to zero) will occur. To prevent this from interfering
with the operation of the protocol, the following MUST be observed. with the operation of the protocol, the following MUST be observed.
The term MAXVALUE designates in the following the largest possible The term MAXVALUE designates in the following the largest possible
value for a sequence number. value for a sequence number.
skipping to change at page 52, line 19 skipping to change at page 55, line 5
ber S2 iff: ber S2 iff:
S1 > S2 AND S1 - S2 <= MAXVALUE/2 OR S1 > S2 AND S1 - S2 <= MAXVALUE/2 OR
S2 > S1 AND S2 - S1 > MAXVALUE/2 S2 > S1 AND S2 - S1 > MAXVALUE/2
Thus when comparing two messages, it is possible - even in the pres- Thus when comparing two messages, it is possible - even in the pres-
ence of wrap-around - to determine which message contains the most ence of wrap-around - to determine which message contains the most
recent information. recent information.
7. Acknowledgments 8. Acknowledgments
The authors would like to thank Joseph Macker and his team The authors would like to thank Joseph Macker and his team
<macker@itd.nrl.navy.mil> for their valuable suggestions on the <macker@itd.nrl.navy.mil> for their valuable suggestions on the
advanced neighbor sensing mechanism. advanced neighbor sensing mechanism.
8. Authors' Addresses The authors would also like to thank Christopher Dearlove
<chris.dearlove@baesystems.com> for valueable input on the MPR selec-
tion heuristics.
9. Authors' Addresses
Thomas Heide Clausen Project HIPERCOM INRIA Rocquencourt BP 105 78153 Thomas Heide Clausen Project HIPERCOM INRIA Rocquencourt BP 105 78153
Le Chesnay Cedex, France Phone: +33 1 3963 5133 Email: Le Chesnay Cedex, France Phone: +33 1 3963 5133 Email:
Thomas.Clausen@inria.fr Thomas.Clausen@inria.fr
Philippe Jacquet Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le Philippe Jacquet Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le
Chesnay Cedex, France Phone: +33 1 3963 5263 Email: Chesnay Cedex, France Phone: +33 1 3963 5263 Email:
Philippe.Jacquet@inria.fr Philippe.Jacquet@inria.fr
Anis Laouiti Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le Anis Laouiti Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le
skipping to change at line 2339 skipping to change at page 55, line 36
Chesnay Cedex, France Phone: +33 1 3963 508832 Email: Chesnay Cedex, France Phone: +33 1 3963 508832 Email:
Anis.Laouiti@inria.fr Anis.Laouiti@inria.fr
Pascale Minet Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le Pascale Minet Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le
Chesnay Cedex, France Phone: +33 1 3963 508832 Email: Pas- Chesnay Cedex, France Phone: +33 1 3963 508832 Email: Pas-
cale.Minet@inria.fr cale.Minet@inria.fr
Paul Muhlethaler Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le Paul Muhlethaler Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le
Chesnay Cedex, France Phone: +33 1 3963 5278 Email: Paul.Muh- Chesnay Cedex, France Phone: +33 1 3963 5278 Email: Paul.Muh-
lethaler@inria.fr lethaler@inria.fr
Amir Qayyum Avaz Networks 5-A Constitution Avenue Islamabad, Pakistan Amir Qayyum Avaz Networks 5-A Constitution Avenue Islamabad, Pakistan
Phone: +92-51-2826160 Email: qayyum@avaznet.com Phone: +92-51-2826160 Email: qayyum@avaznet.com
Laurent Viennot Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le Laurent Viennot Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le
Chesnay Cedex, France Phone: +33 1 3963 5225 Email: Laurent.Vien- Chesnay Cedex, France Phone: +33 1 3963 5225 Email: Laurent.Vien-
not@inria.fr not@inria.fr
9. References 10. References
1. P. Jacquet, P. Minet, P. Muhlethaler, N. Rivierre. Increasing relia- 1. P. Jacquet, P. Minet, P. Muhlethaler, N. Rivierre. Increasing relia-
bility in cable free radio LANs: Low level forwarding in HIPERLAN. bility in cable free radio LANs: Low level forwarding in HIPERLAN.
Wireless Personal Communications, 1996 Wireless Personal Communications, 1996
2. A. Qayyum, L. Viennot, A. Laouiti. Multipoint relaying: An efficient 2. A. Qayyum, L. Viennot, A. Laouiti. Multipoint relaying: An efficient
technique for flooding in mobile wireless networks. 35th Annual technique for flooding in mobile wireless networks. 35th Annual
Hawaii International Conference on System Sciences (HICSS'2001). Hawaii International Conference on System Sciences (HICSS'2001).
3. ETSI STC-RES10 Committee. Radio equipment and systems: HIPERLAN type 3. ETSI STC-RES10 Committee. Radio equipment and systems: HIPERLAN type
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/