draft-ietf-manet-olsr-09.txt   draft-ietf-manet-olsr-10.txt 
INTERNET-DRAFT Cedric Adjih INTERNET-DRAFT Thomas Clausen, Editor
IETF MANET Working Group Thomas Clausen IETF MANET Working Group Philippe Jacquet, Editor
Expiration: 15 October 2003 Philippe Jacquet Expiration: 02 November 2003 Project Hipercom
Anis Laouiti
Pascale Minet
Paul Muhlethaler
Amir Qayyum
Laurent Viennot
INRIA Rocquencourt, France INRIA Rocquencourt, France
15 April 2003 02 May 2003
Optimized Link State Routing Protocol Optimized Link State Routing Protocol
draft-ietf-manet-olsr-09.txt draft-ietf-manet-olsr-10.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 5, line 11 skipping to change at page 5, line 11
18.7. Link Hysteresis . . . . . . . . . . . . . . . . . . . . . . . 71 18.7. Link Hysteresis . . . . . . . . . . . . . . . . . . . . . . . 71
18.8. Willingness . . . . . . . . . . . . . . . . . . . . . . . . . 71 18.8. Willingness . . . . . . . . . . . . . . . . . . . . . . . . . 71
18.9. Misc. Constants . . . . . . . . . . . . . . . . . . . . . . . 72 18.9. Misc. Constants . . . . . . . . . . . . . . . . . . . . . . . 72
19. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . . 72 19. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . . 72
20. Security Considerations . . . . . . . . . . . . . . . . . . . . 72 20. Security Considerations . . . . . . . . . . . . . . . . . . . . 72
20.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 73 20.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 73
20.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . 73 20.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . 73
20.3. Interaction with External Routing Domains . . . . . . . . . . 74 20.3. Interaction with External Routing Domains . . . . . . . . . . 74
20.4. Node Identity . . . . . . . . . . . . . . . . . . . . . . . . 74 20.4. Node Identity . . . . . . . . . . . . . . . . . . . . . . . . 74
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 75 21. Flow and congestion control . . . . . . . . . . . . . . . . . . 75
22. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 75 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 75
23. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75 23. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 75
24. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 24. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 76
25. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77
26. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
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 mobile ad hoc networks. It operates as a table driven, proactive
protocol, i.e exchanges topology information with other nodes of the protocol, 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" (MPR). In OLSR, only nodes, selected as such "multipoint relays" (MPR). In OLSR, only nodes, selected as such
MPRs, are responsible for forwarding control traffic, intended for MPRs, are responsible for forwarding control traffic, intended for
diffusion into the entire network. MPRs provide an efficient mecha- diffusion into the entire network. MPRs provide an efficient mecha-
skipping to change at page 7, line 7 skipping to change at page 7, line 7
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 08 to version 09 Major changes from version 09 to version 10
- Merged multiple interface
- Further separated link sensing, neighbor sensing and hello - Designated editors included
message generation
- Collected information repositories in single section - Flow-control section added
- Misc. editorial changes. - Misc. editorial changes.
1.2. OLSR Terminology 1.2. OLSR Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [5]. Addi- document are to be interpreted as described in RFC2119 [5]. Addi-
tionally, this document uses the following terminology: tionally, this document uses the following terminology:
skipping to change at page 7, line 39 skipping to change at page 7, line 36
OLSR interface OLSR interface
A network device participating in a MANET running OLSR. A A network device participating in a MANET running OLSR. A
node may have several OLSR interfaces, each interface assigned node may have several OLSR interfaces, each interface assigned
an unique IP address. an unique IP address.
non OLSR interface non OLSR interface
A network device, not participating in a MANET running OLSR. A network device, not participating in a MANET running OLSR.
A node may have several OLSR interfaces (wireless and/or A node may have several non OLSR interfaces (wireless and/or
wired). Routing information from these interfaces MAY be wired). Routing information from these interfaces MAY be
injected into the OLSR routing domain. injected into the OLSR routing domain.
single OLSR interface node single OLSR interface node
A node which has a single OLSR interface, participating in an A node which has a single OLSR interface, participating in an
OLSR routing domain. OLSR routing domain.
multiple OLSR interface node multiple OLSR interface node
A node which has multiple OLSR interfaces, participating in an A node which has multiple OLSR interfaces, participating in an
OLSR routing domain. OLSR routing domain.
main address main address
The main address of a node, which will be used in OLSR control The main address of a node, which will be used in OLSR control
traffic as the "originator address" of all messages emitted by traffic as the "originator address" of all messages emitted by
this node. It is the address of one of the interfaces of the this node. It is the address of one of the OLSR interfaces of
node. the node.
A single OLSR interface node uses the address of its only OLSR A single OLSR interface node MUST use the address of its only
interface as the main address. OLSR interface as the main address.
A multiple OLSR interface node MUST choose one of its OLSR A multiple OLSR interface node MUST choose one of its OLSR
interface addresses as its "main address" (equivalent of interface addresses as its "main address" (equivalent of
"router ID" or "node identifier"). It is of no importance "router ID" or "node identifier"). It is of no importance
which address is chosen, however a node SHOULD always use the which address is chosen, however a node SHOULD always use the
same address as its main address. same address as its main address.
neighbor node neighbor node
A node X is a neighbor node of node Y if node Y can hear node A node X is a neighbor node of node Y if node Y can hear node
X (i.e. one of X OLSR interfaces is a neighbor interface of X (i.e. a bidirectional link exists between an OLSR inter-
some OLSR interface of Y). faces on node X and an OLSR interface on Y).
2-hop neighbor 2-hop neighbor
A node heard by a neighbor. A node heard by a neighbor.
strict 2-hop neighbor strict 2-hop neighbor
a 2-hop neighbor which is not the node itself or a neighbor of a 2-hop neighbor which is not the node itself or a neighbor of
the node, and in addition is a neighbor of a neighbor, with the node, and in addition is a neighbor of a neighbor, with
willingness different from WILL_NEVER, of the node. willingness different from WILL_NEVER, of the node.
skipping to change at page 9, line 25 skipping to change at page 9, line 19
receive traffic from the other). A node is said to have a receive traffic from the other). A node is said to have a
link to another node when one of its interface has a link to link to another node when one of its interface has a link to
one of the interfaces of the other node. one of the interfaces of the other node.
symmetric link symmetric link
A verified bi-directional link between two OLSR interfaces. A verified bi-directional link between two OLSR interfaces.
asymmetric link asymmetric link
A link between two OLSR interfaces I and J, verified in only A link between two OLSR interfaces, verified in only one
one direction. direction.
symmetric 1-hop neighborhood symmetric 1-hop neighborhood
The symmetric 1-hop neighborhood of any node X is the set of The symmetric 1-hop neighborhood of any node X is the set of
nodes which have at least one symmetric link to X. nodes which have at least one symmetric link to X.
symmetric 2-hop neighborhood symmetric 2-hop neighborhood
The symmetric 2-hop neighborhood of X is the set of nodes, The symmetric 2-hop neighborhood of X is the set of nodes,
excluding X itself, which have a symmetric link to the sym- excluding X itself, which have a symmetric link to the sym-
skipping to change at page 10, line 9 skipping to change at page 9, line 51
OLSR is a proactive routing protocol for mobile ad-hoc networks OLSR is a proactive routing protocol for mobile ad-hoc networks
(MANETs). It is well suited to large and dense mobile networks, as (MANETs). It is well suited to large and dense mobile networks, as
the optimization achieved using the MPRs works well in this context. the optimization achieved using the MPRs works well in this context.
The larger and more dense a network, the more optimization can be The larger and more dense a network, the more optimization can be
achieved as compared to the classic link state algorithm. OLSR uses achieved as compared to the classic link state algorithm. OLSR uses
hop-by-hop routing, i.e. each node uses its local information to hop-by-hop routing, i.e. each node uses its local information to
route packets. route packets.
OLSR is well suited for networks, where the traffic is random and OLSR is well suited for networks, where the traffic is random and
sporadic between a larger set of nodes nodes rather than being almost sporadic between a larger set of nodes rather than being almost
exclusively between a small specific set of nodes. As a proactive exclusively between a small specific set of nodes. As a proactive
protocol, OLSR is also suitable for scenarios where the communicating protocol, OLSR is also suitable for scenarios where the communicating
pairs change over time: no additional control traffic is generated in pairs change over time: no additional control traffic is generated in
this situation since routes are maintained for all known destinations this situation since routes are maintained for all known destinations
at all times. at all times.
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
skipping to change at page 10, line 31 skipping to change at page 10, line 25
its proactive nature. OLSR is an optimization over the classical its proactive nature. OLSR is an optimization over the classical
link state protocol, tailored for mobile ad hoc networks. link state protocol, tailored for mobile ad hoc networks.
OLSR minimizes the overhead from flooding of control traffic by using OLSR minimizes the overhead from flooding of control traffic by using
only selected nodes, called MPRs, to retransmit control messages. only selected nodes, called MPRs, to retransmit control messages.
This technique significantly reduces the number of retransmissions This technique significantly reduces the number of retransmissions
required to flood a message to all nodes in the network. Secondly, required to flood a message to all nodes in the network. Secondly,
OLSR requires only partial link state to be flooded in order to pro- OLSR requires only partial link state to be flooded in order to pro-
vide shortest path routes. The minimal set of link state information vide shortest path routes. The minimal set of link state information
required is, that all nodes, selected as MPRs, MUST declare the links required is, that all nodes, selected as MPRs, MUST declare the links
to their MPR selectors. Additional topological information, if pre- to their MPR selectors. Additional topological information, if
sent, MAY be utilized e.g. for redundancy purposes. 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 opti- this context. The larger and more dense a network, the more opti-
skipping to change at page 11, line 34 skipping to change at page 11, line 28
messages in the network by reducing redundant retransmissions in the messages in the network by reducing redundant retransmissions in the
same region. Each node in the network selects a set of nodes in its same region. Each node in the network selects a set of nodes in its
symmetric 1-hop neighborhood which may retransmit its messages. This symmetric 1-hop neighborhood which may retransmit its messages. This
set of selected neighbor nodes is called the "Multipoint Relay" (MPR) set of selected neighbor nodes is called the "Multipoint Relay" (MPR)
set of that node. The neighbors of node N which are *NOT* in its MPR set of that node. The neighbors of node N which are *NOT* in its MPR
set, receive and process broadcast messages but do not retransmit set, receive and process broadcast messages but do not retransmit
broadcast messages received from node N. broadcast messages received from node N.
Each node selects its MPR set from among its one hop symmetric neigh- Each node selects its MPR set from among its one hop symmetric neigh-
bors. This set is selected such that it covers (in terms of radio bors. This set is selected such that it covers (in terms of radio
range) all nodes that are two hops away. The MPR set of N, denoted range) all symmetric strict 2-hop nodes. The MPR set of N, denoted
as MPR(N), is then an arbitrary subset of the symmetric 1-hop neigh- as MPR(N), is then an arbitrary subset of the symmetric 1-hop neigh-
borhood of N which satisfies the following condition: every node in borhood of N which satisfies the following condition: every node in
the symmetric strict 2-hop neighborhood of N must have a symmetric the symmetric strict 2-hop neighborhood of N must have a symmetric
link towards MPR(N). The smaller a MPR set, the less control traffic link towards MPR(N). The smaller a MPR set, the less control traffic
overhead results from the routing protocol. [2] gives an analysis overhead results from the routing protocol. [2] gives an analysis
and example of MPR selection algorithms. and example of MPR selection algorithms.
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 Selec- selected it as MPR. This set is called the "Multipoint Relay Selec-
tor set" (MPR selector set) of a node. A node obtains this informa- tor set" (MPR selector set) of a node. A node obtains this informa-
skipping to change at page 12, line 21 skipping to change at page 12, line 20
required for the protocol to operate, and a set of auxiliary func- required for the protocol to operate, and a set of auxiliary func-
tions. tions.
The core specifies, in its own right, a protocol able to provide The core specifies, in its own right, a protocol able to provide
routing in a stand-alone MANET. routing in a stand-alone MANET.
Each auxiliary function provides additional functionality, which may Each auxiliary function provides additional functionality, which may
be applicable in specific scenarios. E.g. in case a node is provid- be applicable in specific scenarios. E.g. in case a node is provid-
ing connectivity between the MANET and another routing domain. ing connectivity between the MANET and another routing domain.
All auxiliary functions are compatible, to the extend where any All auxiliary functions are compatible, to the extent where any
(sub)set of auxiliary functions may be implemented with the core. (sub)set of auxiliary functions may be implemented with the core.
Furthermore, the protocol allows heterogeneous nodes, i.e. nodes Furthermore, the protocol allows heterogeneous nodes, i.e. nodes
which implement different subsets of the auxiliary functions, to which implement different subsets of the auxiliary functions, to
coexist in the network. coexist in the network.
The purpose of dividing the functioning of OLSR into a core function- The purpose of dividing the functioning of OLSR into a core function-
ality and a set of auxiliary functions is to provide a simple and ality and a set of auxiliary functions is to provide a simple and
easy-to-comprehend protocol, and to provide a way of only adding com- easy-to-comprehend protocol, and to provide a way of only adding com-
plexity where specific additional functionality is required. plexity where specific additional functionality is required.
skipping to change at page 13, line 40 skipping to change at page 13, line 37
mation is required in order to map interface addresses to main mation is required in order to map interface addresses to main
addresses (and, thereby, to nodes). This additional informa- addresses (and, thereby, to nodes). This additional informa-
tion is acquired through multiple interface declaration (MID) tion is acquired through multiple interface declaration (MID)
messages, described in section 5. messages, described in section 5.
MPR Selection and MPR Signaling MPR Selection and MPR Signaling
The objective of MPR selection is for a node to select a sub- The objective of MPR selection is for a node to select a sub-
set of its neighbors such that a broadcast message, retrans- set of its neighbors such that a broadcast message, retrans-
mitted by these selected neighbors, will be received by all mitted by these selected neighbors, will be received by all
nodes 2 hops away. A node will thus compute its MPR set such nodes 2 hops away. The MPR set of a node is computed such
that it, for each interface, satisfies this condition. The that it, for each interface, satisfies this condition. The
information required to perform this calculation is acquired information required to perform this calculation is acquired
throuth the periodic exchange of HELLO messages, as described throuth the periodic exchange of HELLO messages, as described
in section 6. MPR selection procedures are in section 6. MPR selection procedures are
detailed in section 8.3. detailed in section 8.3.
MPR signaling is provided in correspondence with the provi- MPR signaling is provided in correspondence with the provi-
sions in the section 6. sions in the section 6.
Topology Control Message Diffusion Topology Control Message Diffusion
skipping to change at page 14, line 40 skipping to change at page 14, line 37
Hello messages | 6 Hello messages | 6
Link sensing | 7 Link sensing | 7
Neighbor detection | 8 Neighbor detection | 8
Topology discovery | 9 Topology discovery | 9
Routing table computation | 10 Routing table computation | 10
Node configuration | 11 Node configuration | 11
2.2. Auxiliary Functioning 2.2. Auxiliary Functioning
In addition to the core functioning of OLSR, there are situations In addition to the core functioning of OLSR, there are situations
where additional functionality is needed. This includes situations where additional functionality is desired. This includes situations
where a node has multiple interfaces, some of which participate in where a node has multiple interfaces, some of which participate in
another routing domain, where the programming interface to the net- another routing domain, where the programming interface to the net-
working hardware provides additional information in form of link- working hardware provides additional information in form of link-
layer notifications and where it is desired to provide redundant layer notifications and where it is desired to provide redundant
topological information to the network on expense of protocol over- topological information to the network on expense of protocol over-
head. head.
The following table specifies auxiliary functions and their relation The following table specifies auxiliary functions and their relation
to this document. to this document.
skipping to change at page 15, line 19 skipping to change at page 15, line 19
Advanced link sensing | 14 Advanced link sensing | 14
Redundant topology | 15 Redundant topology | 15
Redundant MPR flooding | 16 Redundant MPR flooding | 16
The interpretation of the above table is as follows: if the feature The interpretation of the above table is as follows: if the feature
listed is required, it SHOULD be provided as specified in the corre- listed is required, it SHOULD be provided as specified in the corre-
sponding section. sponding section.
3. Packet Format and Forwarding 3. Packet Format and Forwarding
OLSR communicates using an unified packet format for all data related OLSR communicates using a unified packet format for all data related
to the protocol. The purpose of this is to facilitate extensibility to the protocol. The purpose of this is to facilitate extensibility
of the protocol without breaking backwards compatibility. Also, this of the protocol without breaking backwards compatibility. This also
provides an easy way of piggybacking different "types" of information provides an easy way of piggybacking different "types" of information
into a single transmission, and thus for a given implementation to into a single transmission, and thus for a given implementation to
optimize towards utilizing the maximal frame-size, provided by the optimize towards utilizing the maximal frame-size, provided by the
network. These packets are embedded in UDP datagrams for transmis- network. These packets are embedded in UDP datagrams for transmis-
sion over the network. The present draft is presented with IPv4 sion over the network. The present draft is presented with IPv4
addresses. Considerations regarding IPv6 are given in section addresses. Considerations regarding IPv6 are given in section
17. 17.
Each packet encapsulates one or more messages. The messages share a Each packet encapsulates one or more messages. The messages share a
common header format, which enables nodes to correctly accept and (if common header format, which enables nodes to correctly accept and (if
skipping to change at page 23, line 14 skipping to change at page 23, line 14
relates to using the content of the messages, while forwarding is relates to using the content of the messages, while forwarding is
related to retransmitting the same message for other nodes of the related to retransmitting the same message for other nodes of the
network. network.
Notice that this specification includes a description for both the Notice that this specification includes a description for both the
forwarding and the processing of each known message type. Messages forwarding and the processing of each known message type. Messages
with known message types MUST *NOT* be forwarded "blindly" by this with known message types MUST *NOT* be forwarded "blindly" by this
algorithm. Forwarding (and setting the correct message header in the algorithm. Forwarding (and setting the correct message header in the
forwarded, known, message) is the responsibility of the algorithm forwarded, known, message) is the responsibility of the algorithm
specifying how the message is to be handled and, if necessary, specifying how the message is to be handled and, if necessary,
retransmitted. This enables, e.g., a message type to be specified retransmitted. This enables a message type to be specified such that
such that the message can be modified while in transit (e.g. to the message can be modified while in transit (e.g. to reflect the
reflect the route the message has taken). Further, it enables that route the message has taken). It also enables bypassing of the MPR
the optimization through the MPRs can be bypassed: if for some reason flooding mechanism if for some reason classical flooding of a message
classical flooding of a message type is required, the algorithm which type is required, the algorithm which specifies how such messages
specifies how such messages should be handled will simply rebroadcast should be handled will simply rebroadcast the message, regardless of
the message, regardless of MPRs. 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 being through introduction of additional message types, while still being
able to maintain compatibility with older implementations. The able to maintain compatibility with older implementations. The
REQUIRED message types for the core functionality of OLSR are: REQUIRED message types for the core functionality of OLSR are:
- HELLO-messages, performing the task of link sensing, neighbor - HELLO-messages, performing the task of link sensing, neighbor
detection and MPR signaling, detection and MPR signaling,
- TC-messages, performing the task of topology declaration - TC-messages, performing the task of topology declaration
(advertisement of link states). (advertisement of link states).
- MID-messages, performing the task of declaring the presence of - MID-messages, performing the task of declaring the presence of
multiple interfaces on a node. multiple interfaces on a node.
Other message types include those specified in later sections, as Other message types include those specified in later sections, as
well as possible future extensions such as for example messages well as possible future extensions such as messages enabling power
enabling power conservation / sleep mode, multicast routing, support conservation / sleep mode, multicast routing, support for unidirec-
for unidirectional links, auto-configuration/address assignment etc. tional links, auto-configuration/address assignment etc.
3.5. Message Emission and Jitter 3.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, OLSR control messages messages SHOULD be avoided. As a consequence, OLSR control messages
SHOULD be emitted such that they avoid synchronization. SHOULD be emitted such that they avoid synchronization.
Emission of control traffic from neighboring nodes may, for various Emission of control traffic from neighboring nodes may, for various
reasons (mainly timer interactions with packet processing), become reasons (mainly timer interactions with packet processing), become
synchronized such that several neighbor nodes attempt to transmit synchronized such that several neighbor nodes attempt to transmit
skipping to change at page 26, line 24 skipping to change at page 26, line 24
a 2-hop neighbor with a symmetric link to N_neighbor_main_addr, and a 2-hop neighbor with a symmetric link to N_neighbor_main_addr, and
N_time specifies the time at which the tuple expires and *MUST* be N_time specifies the time at which the tuple expires and *MUST* be
removed. removed.
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".
4.3.3. MPR Set 4.3.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. main addresses are listed in the MPR Set.
4.3.4. MPR Selector Set 4.3.4. MPR Selector Set
A node records a set of MPR-selector tuples (MS_main_addr, MS_time), A node records a set of MPR-selector tuples (MS_main_addr, MS_time),
describing the neighbors which have selected this node as a MPR. describing the neighbors which have selected this node as a MPR.
MS_main_addr is the main address of a node, which has selected this MS_main_addr is the main address of a node, which has selected this
node as MPR. MS_time specifies the time at which a tuple expires and node as MPR. MS_time specifies the time at which a tuple expires and
*MUST* be removed. *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". tor Set".
4.4. Topology Information Base 4.4. Topology Information Base
Each node in the network maintains topological information about the Each node in the network maintains topology 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
for routing table calculations. for routing table calculations.
Thus, for each destination in the network, a "Topology Tuple" Thus, for each destination in the network, at least one "Topology
(T_dest_addr, T_last_addr, T_seq, T_time) is recorded. T_dest_addr Tuple" (T_dest_addr, T_last_addr, T_seq, T_time) is recorded.
is the main address of a node, which may be reached in one hop from T_dest_addr is the main address of a node, which may be reached in
the node with the main address T_last_addr. Typically, T_last_addr one hop from the node with the main address T_last_addr. Typically,
is a MPR of T_dest_addr. T_seq is a sequence number, and T_time T_last_addr is a MPR of T_dest_addr. T_seq is a sequence number, and
specifies the time at which this tuple expires and *MUST* be removed. T_time specifies the time at which this tuple expires and *MUST* be
removed.
In a node, the set of Topology Tuples are denoted the "Topology Set". In a node, the set of Topology Tuples are denoted the "Topology Set".
5. Main Addresses and Multiple Interfaces 5. Main Addresses and Multiple Interfaces
For single OLSR interface nodes, the relationship between an OLSR For single OLSR interface nodes, the relationship between an OLSR
interface address and the corresponding main address is trivial: the interface address and the corresponding main address is trivial: the
main address is the OLSR interface address. For multiple OLSR inter- main address is the OLSR interface address. For multiple OLSR inter-
face nodes, the relationship between OLSR interface addresses and face nodes, the relationship between OLSR interface addresses and
main addresses is defined through the exchange of Multiple Interface main addresses is defined through the exchange of Multiple Interface
skipping to change at page 27, line 50 skipping to change at page 28, line 4
| OLSR Interface Address | | OLSR Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OLSR Interface Address | | OLSR Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 section 3.4, with the "Message Type" set to described in section 3.4, with the "Message Type" set to
MID_MESSAGE. The time to live SHOULD be set to 255 (maximum value) MID_MESSAGE. The time to live SHOULD be set to 255 (maximum value)
to diffuse the message into the entire network and Vtime set to diffuse the message into the entire network and Vtime set accord-
accordingly to the value of MID_HOLD_TIME, as specified in section ingly to the value of MID_HOLD_TIME, as specified in section
18.3. 18.3.
OLSR Interface Address OLSR Interface Address
This field contains the address of an OLSR interface of the This field contains the address of an OLSR interface of the
node, excluding the nodes main address (which already indi- node, excluding the nodes main address (which already indi-
cated in the originator address). cated in the originator address).
All interface addresses other than the main address of the originator All interface addresses other than the main address of the originator
node are put in the MID message. If the maximum allowed message size node are put in the MID message. If the maximum allowed message size
skipping to change at page 75, line 5 skipping to change at page 75, line 5
the gateways statically to advertise routes to that IP sequence to the gateways statically to advertise routes to that IP sequence to
nodes in the existing routing domain. nodes in the existing routing domain.
20.4. Node Identity 20.4. Node Identity
OLSR does not make any assumption about node addresses, other than OLSR does not make any assumption about node addresses, other than
that each node is assumed to have an unique IP addresses. Therefore, that each node is assumed to have an unique IP addresses. Therefore,
no special considerations can be made about the applicability of no special considerations can be made about the applicability of
IPsec authentication headers or key exchange mechanisms. IPsec authentication headers or key exchange mechanisms.
21. IANA Considerations 21. Flow and congestion control
Due to its proactive nature, the OLSR protocol has a natural control
over the flow of its control traffic. Nodes transmits control mes-
sage at predetermined rates fixed by predefined refresh intervals.
In certain options some control messages may be intentionnaly sent in
advance of their deadline(TC or Hello messages) in order to increase
the reactiveness of the protocol against certain events. This may
cause a small, temporary and local increase of control traffic.
22. IANA Considerations
OLSR defines a "Message Type" field for control messages. A new reg- OLSR defines a "Message Type" field for control messages. A new reg-
istry is to be created for the values for this Message Type field, istry is to be created for the values for this Message Type field,
and the following values assigned: and the following values assigned:
Message Type Value Message Type Value
-------------------- ----- -------------------- -----
HELLO_MESSAGE 1 HELLO_MESSAGE 1
TC_MESSAGE 2 TC_MESSAGE 2
MID_MESSAGE 3 MID_MESSAGE 3
HNA_MESSAGE 4 HNA_MESSAGE 4
Future values in the range 5-127 of the Message Type can be allocated Future values in the range 5-127 of the Message Type can be allocated
using standards action [7]. using standards action [7].
Additionally, values in the range 128-255 are reserved for pri- Additionally, values in the range 128-255 are reserved for pri-
vate/local use. vate/local use.
22. Acknowledgments 23. Acknowledgments
The authors would like to thank Joseph Macker The authors would like to thank Joseph Macker
<macker@itd.nrl.navy.mil> and his team, including Justin Dean <macker@itd.nrl.navy.mil> and his team, including Justin Dean
<jdean@itd.nrl.navy.mil>, for their valuable suggestions on the <jdean@itd.nrl.navy.mil>, for their valuable suggestions on the
advanced neighbor sensing mechanism and other various aspects of the advanced neighbor sensing mechanism and other various aspects of the
protocol, including careful review of the protocol specification. protocol, including careful review of the protocol specification.
The authors would also like to thank Christopher Dearlove The authors would also like to thank Christopher Dearlove
<chris.dearlove@baesystems.com> for valuable input on the MPR selec- <chris.dearlove@baesystems.com> for valuable input on the MPR selec-
tion heuristics and for careful reviews of the protocol specifica- tion heuristics and for careful reviews of the protocol specifica-
tion. tion.
23. Authors' Addresses 24. Contributors
Cedric Adjih Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le During the development of this specification, the following list of
Chesnay Cedex, France Phone: +33 1 3963 5215 Email: people contributed. The contributors are listed alphabetically.
Cedric Adjih, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le
Chesnay Cedex, France, Phone: +33 1 3963 5215, Email:
Cedric.Adjih@inria.fr Cedric.Adjih@inria.fr
Thomas Heide Clausen Project HIPERCOM INRIA Rocquencourt BP 105 78153 Thomas Heide Clausen, Project HIPERCOM, INRIA Rocquencourt, BP 105,
Le Chesnay Cedex, France Phone: +33 1 3963 5133 Email: 78153 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
Chesnay Cedex, France Phone: +33 1 3963 5263 Email: Philippe Jacquet, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153
Le 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
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
Chesnay Cedex, France Phone: +33 1 3963 5278 Email: Paul.Muh- Le Chesnay Cedex, France, Phone: +33 1 3963 5278, Email: Paul.Muh-
lethaler@inria.fr lethaler@inria.fr
Amir Qayyum Center for Advanced Research in Engineering Pvt. Ltd. Amir Qayyum, Center for Advanced Research in Engineering Pvt. Ltd.,
19, Ataturk Avenue Islamabad, Pakistan Phone: +92-51-2874115 Email: 19, Ataturk Avenue, Islamabad, Pakistan, Phone: +92-51-2874115,
amir@carepvtltd.com Email: amir@carepvtltd.com
Laurent Viennot Project HIPERCOM INRIA Rocquencourt BP 105 78153 Le Laurent Viennot, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153
Chesnay Cedex, France Phone: +33 1 3963 5225 Email: Laurent.Vien- Le Chesnay Cedex, France, Phone: +33 1 3963 5225, Email: Lau-
not@inria.fr rent.Viennot@inria.fr
24. References 25. Authors' Addresses
Thomas Heide Clausen, Project HIPERCOM, INRIA Rocquencourt, BP 105,
78153 Le Chesnay Cedex, France, Phone: +33 1 3963 5133, Email:
Thomas.Clausen@inria.fr
Philippe Jacquet, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153
Le Chesnay Cedex, France, Phone: +33 1 3963 5263, Email:
Philippe.Jacquet@inria.fr
26. References
1. P. Jacquet, P. Minet, P. Muhlethaler, N. Rivierre. Increasing 1. P. Jacquet, P. Minet, P. Muhlethaler, N. Rivierre. Increasing
reliability in cable free radio LANs: Low level forwarding in reliability in cable free radio LANs: Low level forwarding in
HIPERLAN. Wireless Personal Communications, 1996 HIPERLAN. Wireless Personal Communications, 1996
2. A. Qayyum, L. Viennot, A. Laouiti. Multipoint relaying: An effi- 2. A. Qayyum, L. Viennot, A. Laouiti. Multipoint relaying: An effi-
cient technique for flooding in mobile wireless networks. 35th cient technique for flooding in mobile wireless networks. 35th
Annual Hawaii International Conference on System Sciences Annual Hawaii International Conference on System Sciences
(HICSS'2001). (HICSS'2001).
 End of changes. 

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