draft-ietf-manet-olsr-11.txt   rfc3626.txt 
INTERNET-DRAFT Thomas Clausen, Editor Network Working Group T. Clausen, Ed.
IETF MANET Working Group Philippe Jacquet, Editor Request for Comments: 3626 P. Jacquet, Ed.
Expiration: 03 Janyary 2003 Project Hipercom Category: Experimental Project Hipercom, INRIA
INRIA Rocquencourt, France October 2003
03 July 2003
Optimized Link State Routing Protocol
draft-ietf-manet-olsr-11.txt Optimized Link State Routing Protocol (OLSR)
Status of this Memo Status of this Memo
This document is a submission by the Mobile Ad Hoc Networking Working This memo defines an Experimental Protocol for the Internet
Group of the Internet Engineering Task Force (IETF). Comments should community. It does not specify an Internet standard of any kind.
be submitted to the manet@itd.nrl.navy.mil mailing list. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with Copyright Notice
all provisions of Section 10 of RFC 2026.
Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2003). All Rights Reserved.
http://www.ietf.org/shadow.html.
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). MPRs are selected nodes which forward of multipoint relays (MPRs). MPRs are selected nodes which forward
broadcast messages during the flooding process. This technique broadcast messages during the flooding process. This technique
substantially reduces the message overhead as compared to a classical substantially reduces the message overhead as compared to a classical
flooding mechanism, where every node retransmits each message when it flooding mechanism, where every node retransmits each message when it
receives the first copy of the message. In OLSR, link state receives the first copy of the message. In OLSR, link state
information is generated only by nodes elected as MPRs. Thus, a information is generated only by nodes elected as MPRs. Thus, a
second optimization is achieved by minimizing the number of control second optimization is achieved by minimizing the number of control
messages flooded in the network. As a third optimization, an MPR messages flooded in the network. As a third optimization, an MPR
node may chose to report only links between itself and its MPR node may chose to report only links between itself and its MPR
selectors. Hence, as contrary to the classic link state algorithm, selectors. Hence, as contrary to the classic link state algorithm,
partial link state information is distributed in the network. This partial link state information is distributed in the network. This
information is then used by for route calculation. OLSR provides information is then used for route calculation. OLSR provides
optimal routes (in terms of number of hops). The protocol is optimal routes (in terms of number of hops). The protocol is
particularly suitable for large and dense networks as the technique particularly suitable for large and dense networks as the technique
of MPRs works well in this context. of MPRs works well in this context.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. OLSR Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.1. OLSR Terminology. . . . . . . . . . . . . . . . . . . . 5
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2. Applicability. . . . . . . . . . . . . . . . . . . . . . 7
1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 10 1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . 8
1.4. Multipoint Relays . . . . . . . . . . . . . . . . . . . . . . . 11 1.4. Multipoint Relays . . . . . . . . . . . . . . . . . . . 9
2. Protocol Functioning . . . . . . . . . . . . . . . . . . . . . . 12 2. Protocol Functioning . . . . . . . . . . . . . . . . . . . . 9
2.1. Core Functioning . . . . . . . . . . . . . . . . . . . . . . . 12 2.1. Core Functioning . . . . . . . . . . . . . . . . . . . 10
2.2. Auxiliary Functioning . . . . . . . . . . . . . . . . . . . . . 14 2.2. Auxiliary Functioning . . . . . . . . . . . . . . . . . 12
3. Packet Format and Forwarding . . . . . . . . . . . . . . . . . . 15 3. Packet Format and Forwarding . . . . . . . . . . . . . . . . 13
3.1. Protocol and Port Number . . . . . . . . . . . . . . . . . . . 16 3.1. Protocol and Port Number. . . . . . . . . . . . . . . . 13
3.2. Main Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2. Main Address . . . . . . . . . . . . . . . . . . . . . 13
3.3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3. Packet Format . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. Packet Header . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3.1. Packet Header . . . . . . . . . . . . . . . . . . 14
3.3.2. Message Header . . . . . . . . . . . . . . . . . . . . . . . 17 3.3.2. Message Header . . . . . . . . . . . . . . . . . 15
3.4. Packet Processing and Message Flooding . . . . . . . . . . . . 19 3.4. Packet Processing and Message Flooding . . . . . . . . . 16
3.4.1. Default Forwarding Algorithm . . . . . . . . . . . . . . . . 21 3.4.1. Default Forwarding Algorithm. . . . . . . . . . . 18
3.4.2. Considerations on Processing and Forwarding . . . . . . . . . 22 3.4.2. Considerations on Processing and Forwarding . . . 20
3.5. Message Emission and Jitter . . . . . . . . . . . . . . . . . . 23 3.5. Message Emission and Jitter. . . . . . . . . . . . . . . 21
4. Information Repositories . . . . . . . . . . . . . . . . . . . . 24 4. Information Repositories . . . . . . . . . . . . . . . . . . 22
4.1. Multiple Interface Association Information Base . . . . . . . . 24 4.1. Multiple Interface Association Information Base . . . . 22
4.2. Link sensing: Local Link Information Base . . . . . . . . . . . 25 4.2. Link sensing: Local Link Information Base. . . . . . . . 22
4.2.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2.1. Link Set. . . . . . . . . . . . . . . . . . . . . 22
4.3. Neighbor Detection: Neighborhood Information Base . . . . . . . 25 4.3. Neighbor Detection: Neighborhood Information Base. . . . 23
4.3.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . . 25 4.3.1. Neighbor Set. . . . . . . . . . . . . . . . . . . 23
4.3.2. 2-hop Neighbor Set . . . . . . . . . . . . . . . . . . . . . 26 4.3.2. 2-hop Neighbor Set. . . . . . . . . . . . . . . . 23
4.3.3. MPR Set . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3.3. MPR Set . . . . . . . . . . . . . . . . . . . . . 23
4.3.4. MPR Selector Set . . . . . . . . . . . . . . . . . . . . . . 26 4.3.4. MPR Selector Set. . . . . . . . . . . . . . . . . 23
4.4. Topology Information Base . . . . . . . . . . . . . . . . . . . 26 4.4. Topology Information Base . . . . . . . . . . . . . . . 24
5. Main Addresses and Multiple Interfaces . . . . . . . . . . . . . 27 5. Main Addresses and Multiple Interfaces . . . . . . . . . . . 24
5.1. MID Message Format . . . . . . . . . . . . . . . . . . . . . . 27 5.1. MID Message Format . . . . . . . . . . . . . . . . . . . 25
5.2. MID Message Generation . . . . . . . . . . . . . . . . . . . . 28 5.2. MID Message Generation . . . . . . . . . . . . . . . . . 25
5.3. MID Message Forwarding . . . . . . . . . . . . . . . . . . . . 28 5.3. MID Message Forwarding . . . . . . . . . . . . . . . . . 26
5.4. MID Message Processing . . . . . . . . . . . . . . . . . . . . 29 5.4. MID Message Processing . . . . . . . . . . . . . . . . . 26
5.5. Resolving a Main Address from an Interface Address . . . . . . 29 5.5. Resolving a Main Address from an Interface Address . . . 27
6. HELLO Message Format and Generation . . . . . . . . . . . . . . . 30 6. HELLO Message Format and Generation . . . . . . . . . . . . . 27
6.1. HELLO Message Format . . . . . . . . . . . . . . . . . . . . . 30 6.1. HELLO Message Format . . . . . . . . . . . . . . . . . . 27
6.1.1. Link Code as Link Type and Neighbor Type . . . . . . . . . . 33 6.1.1. Link Code as Link Type and Neighbor Type. . . . . 29
6.2. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 34 6.2. HELLO Message Generation . . . . . . . . . . . . . . . . 30
6.3. HELLO Message Forwarding . . . . . . . . . . . . . . . . . . . 36 6.3. HELLO Message Forwarding . . . . . . . . . . . . . . . . 33
6.4. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 36 6.4. HELLO Message Processing . . . . . . . . . . . . . . . . 33
7. Link Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7. Link Sensing . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Populating the Link Set . . . . . . . . . . . . . . . . . . . . 37 7.1. Populating the Link Set . . . . . . . . . . . . . . . . 33
7.1.1. HELLO Message Processing . . . . . . . . . . . . . . . . . . 37 7.1.1. HELLO Message Processing . . . . . . . . . . . . 34
8. Neighbor Detection . . . . . . . . . . . . . . . . . . . . . . . 39 8. Neighbor Detection . . . . . . . . . . . . . . . . . . . . . 35
8.1. Populating the Neighbor Set . . . . . . . . . . . . . . . . . . 39 8.1. Populating the Neighbor Set . . . . . . . . . . . . . . . 35
8.1.1. HELLO Message Processing . . . . . . . . . . . . . . . . . . 40 8.1.1. HELLO Message Processing . . . . . . . . . . . . 37
8.2. Populating the 2-hop Neighbor Set . . . . . . . . . . . . . . . 41
8.2.1. HELLO Message Processing . . . . . . . . . . . . . . . . . . 41 8.2. Populating the 2-hop Neighbor Set. . . . . . . . . . . . 37
8.3. Populating the MPR set . . . . . . . . . . . . . . . . . . . . 42 8.2.1. HELLO Message Processing. . . . . . . . . . . . . 37
8.3.1. MPR Computation . . . . . . . . . . . . . . . . . . . . . . . 43 8.3. Populating the MPR set . . . . . . . . . . . . . . . . . 38
8.4. Populating the MPR Selector Set . . . . . . . . . . . . . . . . 45 8.3.1. MPR Computation . . . . . . . . . . . . . . . . . 39
8.4.1. HELLO Message Processing . . . . . . . . . . . . . . . . . . 45 8.4. Populating the MPR Selector Set. . . . . . . . . . . . . 41
8.5. Neighborhood and 2-hop Neighborhood Changes . . . . . . . . . . 46 8.4.1. HELLO Message Processing. . . . . . . . . . . . . 41
9. Topology Discovery . . . . . . . . . . . . . . . . . . . . . . . 47 8.5. Neighborhood and 2-hop Neighborhood Changes. . . . . . . 42
9.1. TC Message Format . . . . . . . . . . . . . . . . . . . . . . . 47 9. Topology Discovery . . . . . . . . . . . . . . . . . . . . . 43
9.2. Advertised Neighbor Set . . . . . . . . . . . . . . . . . . . . 48 9.1. TC Message Format. . . . . . . . . . . . . . . . . . . . 43
9.3. TC Message Generation . . . . . . . . . . . . . . . . . . . . . 49 9.2. Advertised Neighbor Set. . . . . . . . . . . . . . . . . 44
9.4. TC Message Forwarding. . . . . . . . . . . . . . . . . . . . . 49 9.3. TC Message Generation. . . . . . . . . . . . . . . . . . 45
9.5. TC Message Processing . . . . . . . . . . . . . . . . . . . . . 49 9.4. TC Message Forwarding. . . . . . . . . . . . . . . . . . 45
10. Routing Table Calculation . . . . . . . . . . . . . . . . . . . 51 9.5. TC Message Processing. . . . . . . . . . . . . . . . . . 45
11. Node Configuration . . . . . . . . . . . . . . . . . . . . . . . 54 10. Routing Table Calculation . . . . . . . . . . . . . . . . . . 47
11.1. Address Assignment . . . . . . . . . . . . . . . . . . . . . . 54 11. Node Configuration. . . . . . . . . . . . . . . . . . . . . . 50
11.2. Routing Configuration . . . . . . . . . . . . . . . . . . . . 55 11.1. Address Assignment. . . . . . . . . . . . . . . . . . . 50
11.3. Data Packet Forwarding . . . . . . . . . . . . . . . . . . . . 55 11.2. Routing Configuration . . . . . . . . . . . . . . . . . 51
12. Non OLSR Interfaces . . . . . . . . . . . . . . . . . . . . . . 55 11.3. Data Packet Forwarding. . . . . . . . . . . . . . . . . 51
12.1. HNA Message Format . . . . . . . . . . . . . . . . . . . . . . 56 12. Non OLSR Interfaces . . . . . . . . . . . . . . . . . . . . . 51
12.2. Host and Network Association Information Base . . . . . . . . 56 12.1. HNA Message Format. . . . . . . . . . . . . . . . . . . 52
12.3. HNA Message Generation . . . . . . . . . . . . . . . . . . . . 57 12.2. Host and Network Association Information Base . . . . . 52
12.4. HNA Message Forwarding . . . . . . . . . . . . . . . . . . . . 57 12.3. HNA Message Generation. . . . . . . . . . . . . . . . . 53
12.5. HNA Message Processing . . . . . . . . . . . . . . . . . . . . 57 12.4. HNA Message Forwarding. . . . . . . . . . . . . . . . . 53
12.6. Routing Table Calculation . . . . . . . . . . . . . . . . . . 58 12.5. HNA Message Processing. . . . . . . . . . . . . . . . . 53
12.7. Interoperability Considerations . . . . . . . . . . . . . . . 59 12.6. Routing Table Calculation . . . . . . . . . . . . . . . 54
13. Link Layer Notification . . . . . . . . . . . . . . . . . . . . 59 12.7. Interoperability Considerations . . . . . . . . . . . . 55
13.1. Interoperability Considerations . . . . . . . . . . . . . . . 60 13. Link Layer Notification . . . . . . . . . . . . . . . . . . . 55
14. Link Hysteresis . . . . . . . . . . . . . . . . . . . . . . . . 60 13.1. Interoperability Considerations . . . . . . . . . . . . 56
14.1. Local Link Set . . . . . . . . . . . . . . . . . . . . . . . . 61 14. Link Hysteresis . . . . . . . . . . . . . . . . . . . . . . . 56
14.2. Hello Message Generation . . . . . . . . . . . . . . . . . . . 61 14.1. Local Link Set . . . . . . . . . . . . . . . . . . . . 56
14.3. Hysteresis Strategy . . . . . . . . . . . . . . . . . . . . . 62 14.2. Hello Message Generation . . . . . . . . . . . . . . . 57
14.4. Interoperability Considerations . . . . . . . . . . . . . . . 64 14.3. Hysteresis Strategy . . . . . . . . . . . . . . . . . . 57
15. Redundant Topology Information . . . . . . . . . . . . . . . . . 64 14.4. Interoperability Considerations . . . . . . . . . . . . 59
15.1. TC_REDUNDANCY Parameter . . . . . . . . . . . . . . . . . . . 64 15. Redundant Topology Information. . . . . . . . . . . . . . . . 59
15.2. Interoperability Considerations . . . . . . . . . . . . . . . 65 15.1. TC_REDUNDANCY Parameter . . . . . . . . . . . . . . . . 60
16. MPR Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . 65 15.2. Interoperability Considerations . . . . . . . . . . . . 60
16.1. MPR_COVERAGE Parameter . . . . . . . . . . . . . . . . . . . . 65 16. MPR Redundancy. . . . . . . . . . . . . . . . . . . . . . . . 60
16.2. MPR Computation . . . . . . . . . . . . . . . . . . . . . . . 66 16.1. MPR_COVERAGE Parameter. . . . . . . . . . . . . . . . . 61
16.3. Interoperability Considerations . . . . . . . . . . . . . . . 67 16.2. MPR Computation . . . . . . . . . . . . . . . . . . . . 61
17. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . 67 16.3. Interoperability Considerations . . . . . . . . . . . . 62
18. Proposed Values for Constants . . . . . . . . . . . . . . . . . 68 17. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 63
18.1. Setting emission interval and holding times . . . . . . . . . 68 18. Proposed Values for Constants . . . . . . . . . . . . . . . . 63
18.2. Emission Interval . . . . . . . . . . . . . . . . . . . . . . 68 18.1. Setting emission interval and holding times . . . . . . 63
18.3. Holding time . . . . . . . . . . . . . . . . . . . . . . . . . 69 18.2. Emission Interval . . . . . . . . . . . . . . . . . . . 64
18.4. Message Types . . . . . . . . . . . . . . . . . . . . . . . . 70 18.3. Holding time . . . . . . . . . . . . . . . . . . . . . 64
18.5. Link Types . . . . . . . . . . . . . . . . . . . . . . . . . . 70 18.4. Message Types . . . . . . . . . . . . . . . . . . . . . 65
18.6. Neighbor Types . . . . . . . . . . . . . . . . . . . . . . . . 70 18.5. Link Types. . . . . . . . . . . . . . . . . . . . . . . 65
18.7. Link Hysteresis . . . . . . . . . . . . . . . . . . . . . . . 70 18.6. Neighbor Types . . . . . . . . . . . . . . . . . . . . 65
18.8. Willingness . . . . . . . . . . . . . . . . . . . . . . . . . 71 18.7. Link Hysteresis . . . . . . . . . . . . . . . . . . . . 66
18.9. Misc. Constants . . . . . . . . . . . . . . . . . . . . . . . 72 18.8. Willingness . . . . . . . . . . . . . . . . . . . . . . 66
19. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . . 72 18.9. Misc. Constants . . . . . . . . . . . . . . . . . . . . 67
20. Security Considerations . . . . . . . . . . . . . . . . . . . . 72 19. Sequence Numbers. . . . . . . . . . . . . . . . . . . . . . . 67
20.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 72 20. Security Considerations . . . . . . . . . . . . . . . . . . . 67
20.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . 73 20.1. Confidentiality . . . . . . . . . . . . . . . . . . . . 67
20.3. Interaction with External Routing Domains . . . . . . . . . . 74 20.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . 68
20.4. Node Identity . . . . . . . . . . . . . . . . . . . . . . . . 75 20.3. Interaction with External Routing Domains . . . . . . . 69
21. Flow and congestion control . . . . . . . . . . . . . . . . . . 75 20.4. Node Identity . . . . . . . . . . . . . . . . . . . . . 70
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 75 21. Flow and congestion control . . . . . . . . . . . . . . . . . 70
23. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 76 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70
24. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 76 23. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71
25. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 24. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 71
26. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 25. References. . . . . . . . . . . . . . . . . . . . . . . . . . 73
26. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 74
27. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 75
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
network regularly. Each node selects a set of its neighbor nodes as the network regularly. Each node selects a set of its neighbor nodes
"multipoint relays" (MPR). In OLSR, only nodes, selected as such as "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 diffusion into the entire network. MPRs provide an efficient
mechanism for flooding control traffic by reducing the number of mechanism for flooding control traffic by reducing the number of
transmissions required. transmissions required.
Nodes, selected as MPRs, also have a special responsibility when Nodes, selected as MPRs, also have a special responsibility when
declaring link state information in the network. Indeed, the only declaring link state information in the network. Indeed, the only
requirement for OLSR to provide shortest path routes to all requirement for OLSR to provide shortest path routes to all
destinations is that MPR nodes declare link-state information for destinations is that MPR nodes declare link-state information for
their MPR selectors. Additional available link-state information may their MPR selectors. Additional available link-state information may
be utilized, e.g. for redundancy. be utilized, e.g., for redundancy.
Nodes which have been selected as multipoint relays by some neighbor Nodes which have been selected as multipoint relays by some neighbor
node(s) announce this information periodically in their control node(s) announce this information periodically in their control
messages. Thereby a node announces to the network, that it has messages. Thereby a node announces to the network, that it has
reachability to the nodes which have selected it as an MPR. In route reachability to the nodes which have selected it as an MPR. In route
calculation, the MPRs are used to form the route from a given node to calculation, the MPRs are used to form the route from a given node to
any destination in the network. Furthermore, the protocol uses the any destination in the network. Furthermore, the protocol uses the
MPRs to facilitate efficient flooding of control messages in the MPRs to facilitate efficient flooding of control messages in the
network. network.
A node selects MPRs from among its one hop neighbors with A node selects MPRs from among its one hop neighbors with
"symmetrical", i.e. bi-directional, linkages. Therefore, selecting "symmetric", i.e., bi-directional, linkages. Therefore, selecting
the route through MPRs automatically avoids the problems associated the route through MPRs automatically avoids the problems associated
with data packet transfer over uni-directional links (such as the with data packet transfer over uni-directional links (such as the
problem of not getting link-layer acknowledgments for data packets at problem of not getting link-layer acknowledgments for data packets at
each hop, for link-layers employing this technique for unicast each hop, for link-layers employing this technique for unicast
traffic). traffic).
OLSR is developed to work independently from other protocols. OLSR is developed to work independently from other protocols.
Likewise, OLSR makes no assumptions about the underlying link-layer. Likewise, 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
skipping to change at page 7, line 10 skipping to change at page 5, line 22
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. OLSR Terminology 1.1. 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]. document are to be interpreted as described in RFC2119 [5].
Additionally, this document uses the following terminology: Additionally, this document uses the following terminology:
node node
A MANET router which implements the Optimized Link State A MANET router which implements the Optimized Link State
Routing protocol as specified in this document. Routing protocol as specified in this document.
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
node may have several OLSR interfaces, each interface assigned may have several OLSR interfaces, each interface assigned an
an unique IP address. 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
A node may have several non OLSR interfaces (wireless and/or 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 OLSR interfaces of this node. It is the address of one of the OLSR interfaces of
the node. the node.
A single OLSR interface node MUST use the address of its only A single OLSR interface node MUST use the address of its only
OLSR 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
X (i.e. a bidirectional link exists between an OLSR (i.e., a link exists between an OLSR interface on node X and an
interfaces on node X and an OLSR interface on Y). 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.
multipoint relay (MPR) multipoint relay (MPR)
A node which is selected by its one-hop neighbor, node X, to A node which is selected by its 1-hop neighbor, node X, to
"re-transmit" all the broadcast messages that it receives from "re-transmit" all the broadcast messages that it receives from
X, provided that the message is not a duplicate, and that the X, provided that the message is not a duplicate, and that the
time to live field of the message is greater than one. time to live field of the message is greater than one.
multipoint relay selector (MPR selector, MS) multipoint relay selector (MPR selector, MS)
A node which has selected its one-hop neighbor, node X, as its A node which has selected its 1-hop neighbor, node X, as its
multipoint relay, will be called a multipoint relay selector multipoint relay, will be called a multipoint relay selector of
of node X. node X.
link link
A link is a pair of OLSR interfaces (from two different nodes) A link is a pair of OLSR interfaces (from two different nodes)
susceptible to hear one another (i.e. one may be able to susceptible to hear one another (i.e., one may be able to
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
link to another node when one of its interface has a link to to another node when one of its interface has a link to one of
one of the interfaces of the other node. 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, verified in only one A link between two OLSR interfaces, verified in only 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 excluding X itself, which have a symmetric link to the
symmetric 1-hop neighborhood of X. symmetric 1-hop neighborhood of X.
symmetric strict 2-hop neighborhood symmetric strict 2-hop neighborhood
The symmetric 2-hop neighborhood of X is the set of nodes, The symmetric strict 2-hop neighborhood of X is the set of
excluding X itself and its neighbors, which have a symmetric nodes, excluding X itself and its neighbors, which have a
link to some symmetric 1-hop neighbor, with willingness symmetric link to some symmetric 1-hop neighbor, with
different of WILL_NEVER, of X. willingness different of WILL_NEVER, of X.
1.2. Applicability 1.2. Applicability
OLSR is a proactive routing protocol for mobile ad-hoc networks OLSR is a proactive routing protocol for mobile ad-hoc networks
(MANETs) [1], [2]. It is well suited to large and dense mobile (MANETs) [1], [2]. It is well suited to large and dense mobile
networks, as the optimization achieved using the MPRs works well in networks, as the optimization achieved using the MPRs works well in
this context. The larger and more dense a network, the more this context. The larger and more dense a network, the more
optimization can be achieved as compared to the classic link state optimization can be achieved as compared to the classic link state
algorithm. OLSR uses hop-by-hop routing, i.e. each node uses its algorithm. OLSR uses hop-by-hop routing, i.e., each node uses its
local information to route packets. local information to 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 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.
skipping to change at page 10, line 26 skipping to change at page 8, line 25
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 OLSR requires only partial link state to be flooded in order to
provide shortest path routes. The minimal set of link state provide shortest path routes. The minimal set of link state
information required is, that all nodes, selected as MPRs, MUST information required is, that all nodes, selected as MPRs, MUST
declare the links to their MPR selectors. Additional topological declare the links to their MPR selectors. Additional topological
information, if present, MAY be utilized e.g. for redundancy information, if present, MAY be utilized e.g., for redundancy
purposes. 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 Furthermore, as OLSR continuously maintains routes to all
destinations in the network, the protocol is beneficial for traffic destinations in the network, the protocol is beneficial for traffic
patterns where a large subset of nodes are communicating with another patterns where a large subset of nodes are communicating with another
large subset of nodes, and where the [source, destination] pairs are large subset of nodes, and where the [source, destination] pairs are
changing over time. The protocol is particularly suited for large changing over time. The protocol is particularly suited for large
and dense networks, as the optimization done using MPRs works well in and dense networks, as the optimization done using MPRs works well in
skipping to change at page 11, line 27 skipping to change at page 9, line 25
The idea of multipoint relays is to minimize the overhead of flooding The idea of multipoint relays is to minimize the overhead of flooding
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 Each node selects its MPR set from among its 1-hop symmetric
neighbors. This set is selected such that it covers (in terms of neighbors. This set is selected such that it covers (in terms of
radio range) all symmetric strict 2-hop nodes. The MPR set of N, radio range) all symmetric strict 2-hop nodes. The MPR set of N,
denoted as MPR(N), is then an arbitrary subset of the symmetric 1-hop denoted as MPR(N), is then an arbitrary subset of the symmetric 1-hop
neighborhood of N which satisfies the following condition: every node neighborhood of N which satisfies the following condition: every node
in the symmetric strict 2-hop neighborhood of N must have a symmetric in the symmetric strict 2-hop neighborhood of N must have a symmetric
link towards MPR(N). The smaller a MPR set, the less control traffic 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 selected it as MPR. This set is called the "Multipoint Relay
Selector set" (MPR selector set) of a node. A node obtains this Selector set" (MPR selector set) of a node. A node obtains this
information from periodic HELLO messages received from the neighbors. information 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, if N has not received it yet. This set can retransmitted by node N, if N has not received it yet. This set can
change over time (i.e. when a node selects another MPR-set) and is change over time (i.e., when a node selects another MPR-set) and is
indicated by the selector nodes in their HELLO messages. indicated by the selector nodes in their HELLO messages.
2. Protocol Functioning 2. Protocol Functioning
This section outlines the overall protocol functioning. This section outlines the overall protocol functioning.
OLSR is modularized into a "core" of functionality, which is always OLSR is modularized into a "core" of functionality, which is always
required for the protocol to operate, and a set of auxiliary required for the protocol to operate, and a set of auxiliary
functions. functions.
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 be applicable in specific scenarios, e.g., in case a node is
providing connectivity between the MANET and another routing domain. providing connectivity between the MANET and another routing domain.
All auxiliary functions are compatible, to the extent 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 The purpose of dividing the functioning of OLSR into a core
functionality and a set of auxiliary functions is to provide a simple functionality and a set of auxiliary functions is to provide a simple
and easy-to-comprehend protocol, and to provide a way of only adding and easy-to-comprehend protocol, and to provide a way of only adding
complexity where specific additional functionality is required. complexity where specific additional functionality is required.
2.1. Core Functioning 2.1. Core Functioning
The core functionality of OLSR specifies the behavior of a node, The core functionality of OLSR specifies the behavior of a node,
equipped with OLSR interfaces participating in the MANET and running equipped with OLSR interfaces participating in the MANET and running
OLSR as routing protocol. This includes a universal specification of OLSR as routing protocol. This includes a universal specification of
OLSR protocol messages and their transmission through the network, as OLSR protocol messages and their transmission through the network, as
well as link sensing, topology diffusion and route calculation. well as link sensing, topology diffusion and route calculation.
Specifically, the core is made up from the following components: Specifically, the core is made up from the following components:
Packet Format and Forwarding Packet Format and Forwarding
An universal specification of the packet format and an A universal specification of the packet format and an optimized
optimized flooding mechanism serves as the transport mechanism flooding mechanism serves as the transport mechanism for all
for all OLSR control traffic. OLSR control traffic.
Link Sensing Link Sensing
Link Sensing is accomplished through periodic emission of
HELLO messages over the interfaces through which connectivity
is checked. A separate HELLO message is generated for each
interface and emitted in correspondence with the provisions in
section 7.
Resulting from Link Sensing is a local link set, describing Link Sensing is accomplished through periodic emission of HELLO
links between "local interfaces" and "remote interfaces" - messages over the interfaces through which connectivity is
i.e. interfaces on neighbor nodes. checked. A separate HELLO message is generated for each
interface and emitted in correspondence with the provisions in
section 7.
If sufficient information is provided by the link-layer, this Resulting from Link Sensing is a local link set, describing
may be utilized to populate the local link set instead of links between "local interfaces" and "remote interfaces" -
HELLO message exchange. i.e., interfaces on neighbor nodes.
Neighbor detection If sufficient information is provided by the link-layer, this
may be utilized to populate the local link set instead of HELLO
message exchange.
Given a network with only single interface nodes, a node may Neighbor detection
deduct the neighbor set directly from the information
exchanged as part of link sensing: the "main address" of a
single interface node is, by definition, the address of the
only interface on that node.
In a network with multiple interface nodes, additional Given a network with only single interface nodes, a node may
information is required in order to map interface addresses to deduct the neighbor set directly from the information exchanged
main addresses (and, thereby, to nodes). This additional as part of link sensing: the "main address" of a single
information is acquired through multiple interface declaration interface node is, by definition, the address of the only
(MID) messages, described in section 5. interface on that node.
MPR Selection and MPR Signaling In a network with multiple interface nodes, additional
information is required in order to map interface addresses to
main addresses (and, thereby, to nodes). This additional
information is acquired through multiple interface declaration
(MID) messages, described in section 5.
The objective of MPR selection is for a node to select a MPR Selection and MPR Signaling
subset of its neighbors such that a broadcast message,
retransmitted by these selected neighbors, will be received by
all nodes 2 hops away. The MPR set of a node is computed such
that it, for each interface, satisfies this condition. The
information required to perform this calculation is acquired
throuth the periodic exchange of HELLO messages, as described
in section 6. MPR selection procedures are
detailed in section 8.3.
MPR signaling is provided in correspondence with the The objective of MPR selection is for a node to select a subset
provisions in the section 6. of its neighbors such that a broadcast message, retransmitted
by these selected neighbors, will be received by all nodes 2
hops away. The MPR set of a node is computed such that it, for
each interface, satisfies this condition. The information
required to perform this calculation is acquired through the
periodic exchange of HELLO messages, as described in section 6.
MPR selection procedures are detailed in section 8.3.
Topology Control Message Diffusion MPR signaling is provided in correspondence with the provisions
Topology Control messages are diffused with the purpose of in the section 6.
providing each node in the network with sufficient link-state
information to allow route calculation. Topology Control
messages are diffused in correspondence with the provisions in
section 9.
Route Calculation Topology Control Message Diffusion
Given the link state information acquired through periodic Topology Control messages are diffused with the purpose of
message exchange, as well as the interface configuration of providing each node in the network with sufficient link-state
the nodes, the routing table for each node can be computed. information to allow route calculation. Topology Control
This is detailed in section 10 messages are diffused in correspondence with the provisions in
section 9.
Route Calculation
Given the link state information acquired through periodic
message exchange, as well as the interface configuration of the
nodes, the routing table for each node can be computed. This
is detailed in section 10.
The key notion for these mechanisms is the MPR relationship. The key notion for these mechanisms is the MPR relationship.
The following table specifies the component of the core functionality The following table specifies the component of the core functionality
of OLSR, as well as their relations to this document. of OLSR, as well as their relations to this document.
Feature | Section Feature | Section
------------------------------+-------------- ------------------------------+--------------
Packet format and forwarding | 3 Packet format and forwarding | 3
Information repositories | 4 Information repositories | 4
Main addr and multiple if. | 5 Main addr and multiple if. | 5
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 desired. 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 another routing domain, where the programming interface to the
networking hardware provides additional information in form of link networking 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 topological information to the network on expense of protocol
overhead. overhead.
The following table specifies auxiliary functions and their relation The following table specifies auxiliary functions and their relation
to this document. to this document.
Feature | Section Feature | Section
------------------------------+-------------- ------------------------------+--------------
Non-OLSR interfaces | 12 Non-OLSR interfaces | 12
Link-layer notifications | 13 Link-layer notifications | 13
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 listed is required, it SHOULD be provided as specified in the
corresponding section. corresponding section.
3. Packet Format and Forwarding 3. Packet Format and Forwarding
OLSR communicates using a 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. This also 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 network. These packets are embedded in UDP datagrams for
transmission over the network. The present draft is presented with transmission over the network. The present document is presented
IPv4 addresses. Considerations regarding IPv6 are given in section with IPv4 addresses. Considerations regarding IPv6 are given in
17. section 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
applicable) retransmit messages of an unknown type. applicable) retransmit messages of an unknown type.
Messages can be flooded onto the entire network, or flooding can be Messages can be flooded onto the entire network, or flooding can be
limited to nodes within a diameter (in terms of number of hops) from limited to nodes within a diameter (in terms of number of hops) from
the originator of the message. Thus transmitting a message to the the originator of the message. Thus transmitting a message to the
neighborhood of a node is just a special case of flooding. When neighborhood of a node is just a special case of flooding. When
flooding any control message, duplicate retransmissions will be flooding any control message, duplicate retransmissions will be
eliminated locally (i.e. each node maintains a duplicate set to eliminated locally (i.e., each node maintains a duplicate set to
prevent transmitting the same OLSR control message twice) and prevent transmitting the same OLSR control message twice) and
minimized in the entire network through the usage of MPRs as minimized in the entire network through the usage of MPRs as
described in later sections. described in later sections.
Furthermore, a node can examine the header of a message to obtain Furthermore, a node can examine the header of a message to obtain
information on the distance (in terms of number of hops) to the information on the distance (in terms of number of hops) to the
originator of the message. This feature may be useful in situations originator of the message. This feature may be useful in situations
where, e.g., the time information from a received control messages where, e.g., the time information from a received control messages
stored in a node depends on the distance to the originator. stored in a node depends on the distance to the originator.
skipping to change at page 16, line 46 skipping to change at page 14, line 36
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time To Live | Hop Count | Message Sequence Number | | Time To Live | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: MESSAGE : : MESSAGE :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
(etc) (etc.)
3.3.1. Packet Header 3.3.1. Packet Header
Packet Length Packet Length
The length (in bytes) of the packet The length (in bytes) of the packet
Packet Sequence Number Packet Sequence Number
The Packet Sequence Number (PSN) MUST be incremented by one The Packet Sequence Number (PSN) MUST be incremented by one
each time a new OLSR packet is transmitted. "Wrap-around" is each time a new OLSR packet is transmitted. "Wrap-around" is
handled as described in section 19. A separate Packet handled as described in section 19. A separate Packet Sequence
Sequence Number is maintained for each interface such that Number is maintained for each interface such that packets
packets transmitted over an interface are sequentially transmitted over an interface are sequentially enumerated.
enumerated.
The IP address of the interface over which a packet was transmitted The IP address of the interface over which a packet was transmitted
is obtainable from the IP header of the packet. is obtainable from the IP header of the packet.
If the packet contains no messages (i.e. the Packet Length is less If the packet contains no messages (i.e., the Packet Length is less
than or equal to the size of the packet header), the packet MUST than or equal to the size of the packet header), the packet MUST
silently be discarded. silently be discarded.
For IPv4 addresses, this implies that packets, where the Packet For IPv4 addresses, this implies that packets, where the Packet
Length < 16 MUST silently be discarded. Length < 16 MUST silently be discarded.
3.3.2. Message Header 3.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" part. Message types in the range of 0-127 are the "MESSAGE" part. Message types in the range of 0-127 are
reserved for messages in this document and in possible reserved for messages in this document and in possible
extensions. extensions.
Vtime Vtime
This field indicates for how long time after reception a node This field indicates for how long time after reception a node
MUST consider the information contained in the message as MUST consider the information contained in the message as
valid, unless a more recent update to the information is valid, unless a more recent update to the information is
received. The validity time is represented by its mantissa received. The validity time is represented by its mantissa
(four highest bits of Vtime field) and by its exponent (four (four highest bits of Vtime field) and by its exponent (four
lowest bits of Vtime field). In other words: lowest bits of Vtime field). In other words:
validity time = C*(1+a/16)* 2^b [in seconds] validity time = C*(1+a/16)* 2^b [in seconds]
where a is the integer represented by the four highest bits of where a is the integer represented by the four highest bits of
Vtime field and b the integer represented by the four lowest Vtime field and b the integer represented by the four lowest
bits of Vtime field. The proposed value of the scaling factor bits of Vtime field. The proposed value of the scaling factor
C is specified in section 18. C is specified in section 18.
Message Size Message Size
This field gives the size of this message, counted in bytes This gives the size of this message, counted in bytes and
and measured from the beginning of the "Message Type" field measured from the beginning of the "Message Type" field and
and until the beginning of the next "Message Type" field (or - until the beginning of the next "Message Type" field (or - if
if there are no following messages - until the end of the 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 IP 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 be transmitted. Before a message is retransmitted, the Time To
To Live MUST be decremented by 1. When a node receives a Live MUST be decremented by 1. When a node receives a message
message with a Time To Live equal to 0 or 1, the message MUST with a Time To Live equal to 0 or 1, the message MUST NOT be
NOT be retransmitted under any circumstances. Normally, a retransmitted under any circumstances. Normally, a node would
node would not receive a message with a TTL of zero. not receive a message with a TTL of zero.
Thus, by setting this field, the originator of a message can Thus, by setting this field, the originator of a message can
limit the flooding radius. limit the flooding radius.
Hop Count Hop Count
This field contains the number of hops a message has attained. This field contains the number of hops a message has attained.
Before a message is retransmitted, the Hop Count MUST be Before a message is retransmitted, the Hop Count MUST be
incremented by 1. incremented by 1.
Initially, this is set to '0' by the originator of the Initially, this is set to '0' by the originator of the message.
message.
Message Sequence Number Message Sequence Number
While generating a message, the "originator" node will assign While generating a message, the "originator" node will assign a
a unique identification number to each message. This number unique identification number to each message. This number is
is inserted into the Sequence Number field of the message. inserted into the Sequence Number field of the message. The
The sequence number is increased by 1 (one) for each message sequence number is increased by 1 (one) for each message
originating from the node. "Wrap-around" is handled as originating from the node. "Wrap-around" is handled as
described in section 19. Message sequence numbers are described in section 19. Message sequence numbers are used to
used to ensure that a given message is not retransmitted more ensure that a given message is not retransmitted more than once
than once by any node. by any node.
3.4. Packet Processing and Message Flooding 3.4. Packet Processing and Message Flooding
Upon receiving a basic packet, a node examines each of the "message Upon receiving a basic packet, a node examines each of the "message
headers". Based on the value of the "Message Type" field, the node headers". Based on the value of the "Message Type" field, the node
can determine the fate of the message. A node may receive the same can determine the fate of the message. A node may receive the same
message several times. Thus, to avoid re-processing of some messages message several times. Thus, to avoid re-processing of some messages
which were already received and processed, each node maintains a which were already received and processed, each node maintains a
Duplicate Set. In this set, the node records information about the Duplicate Set. In this set, the node records information about the
most recently received messages where duplicate processing of a most recently received messages where duplicate processing of a
skipping to change at page 20, line 9 skipping to change at page 17, line 22
main address of the node which sent the message. The term "Sender main address of the node which sent the message. The term "Sender
Interface Address" will be used for the sender address (given in the Interface Address" will be used for the sender address (given in the
IP header of the packet containing the message) of the interface IP header of the packet containing the message) of the interface
which sent the message. The term "Receiving Interface Address" will which sent the message. The term "Receiving Interface Address" will
be used for the address of the interface of the node which received be used for the address of the interface of the node which received
the message. the message.
Thus, upon receiving a basic packet, a node MUST perform the Thus, upon receiving a basic packet, a node MUST perform the
following tasks for each encapsulated message: following tasks for each encapsulated message:
1 If the packet contains no messages (i.e. the Packet Length is 1 If the packet contains no messages (i.e., the Packet Length is
less than or equal to the size of the packet header), the less than or equal to the size of the packet header), the
packet MUST silently be discarded. packet MUST silently be discarded.
For IPv4 addresses, this implies that packets, where the For IPv4 addresses, this implies that packets, where the
Packet Length < 16 MUST silently be discarded. Packet Length < 16 MUST silently be discarded.
2 If the time to live of the message is less than or equal to 2 If the time to live of the message is less than or equal to
'0' (zero), or if the message was sent by the receiving node '0' (zero), or if the message was sent by the receiving node
(i.e. the Originator Address of the message is the main (i.e., the Originator Address of the message is the main
address of the receiving node): the message MUST silently be address of the receiving node): the message MUST silently be
dropped. dropped.
3 Processing condition: 3 Processing condition:
3.1 if there exists a tuple in the duplicate set, where: 3.1 if there exists a tuple in the duplicate set, where:
D_addr == Originator Address, AND D_addr == Originator Address, AND
D_seq_num == Message Sequence Number D_seq_num == Message Sequence Number
skipping to change at page 21, line 5 skipping to change at page 18, line 20
D_seq_num == Message Sequence Number, D_seq_num == Message Sequence Number,
AND AND
the receiving interface (address) is the receiving interface (address) is
in D_iface_list in D_iface_list
then the message has already been considered for then the message has already been considered for
forwarding and SHOULD NOT be retransmitted again. forwarding and SHOULD NOT be retransmitted again.
4.2 Otherwise: 4.2 Otherwise:
4.2.1 4.2.1
If the node implements the Message Type of the If the node implements the Message Type of the
message, the message MUST be considered for message, the message MUST be considered for
forwarding according to the specifications for forwarding according to the specifications for
the message type. the message type.
4.2.2 4.2.2
Otherwise, if the node does not implement the Otherwise, if the node does not implement the
Message Type of the message, the message SHOULD Message Type of the message, the message SHOULD
be processed according to the default be processed according to the default
forwarding algorithm described below. forwarding algorithm described below.
3.4.1. Default Forwarding Algorithm 3.4.1. Default Forwarding Algorithm
The default forwarding algorithm is the following: The default forwarding algorithm is the following:
1 If the sender interface address of the message is not detected 1 If the sender interface address of the message is not detected
to be in the symmetric 1-hop neighborhood of the node, the to be in the symmetric 1-hop neighborhood of the node, the
forwarding algorithm MUST silently stop here (and the message forwarding algorithm MUST silently stop here (and the message
MUST NOT be forwarded). MUST NOT be forwarded).
skipping to change at page 21, line 38 skipping to change at page 19, line 4
2 If there exists a tuple in the duplicate set where: 2 If there exists a tuple in the duplicate set where:
D_addr == Originator Address D_addr == Originator Address
D_seq_num == Message Sequence Number D_seq_num == Message Sequence Number
Then the message will be further considered for forwarding if Then the message will be further considered for forwarding if
and only if: and only if:
D_retransmitted is false, AND D_retransmitted is false, AND
the (address of the) interface which received the message the (address of the) interface which received the message
is not included among the addresses in D_iface_list is not included among the addresses in D_iface_list
3 Otherwise, if such an entry doesn't exist, the message is 3 Otherwise, if such an entry doesn't exist, the message is
further considered for forwarding. further considered for forwarding.
If after those steps, the message is not considered for forwarding, If after those steps, the message is not considered for forwarding,
then the processing of this section stops (i.e. steps 4 to 8 are then the processing of this section stops (i.e., steps 4 to 8 are
ignored), otherwise, if it is still considered for forwarding then ignored), otherwise, if it is still considered for forwarding then
the following algorithm is used: the following algorithm is used:
4 If the sender interface address is an interface address of a 4 If the sender interface address is an interface address of a
MPR selector of this node and if the time to live of the MPR selector of this node and if the time to live of the
message is greater than '1', the message MUST be retransmitted message is greater than '1', the message MUST be retransmitted
(as described later in steps 6 to 8). (as described later in steps 6 to 8).
5 If an entry in the duplicate set exists, with same Originator 5 If an entry in the duplicate set exists, with same Originator
Address, and same Message Sequence Number, the entry is Address, and same Message Sequence Number, the entry is
skipping to change at page 23, line 15 skipping to change at page 20, line 23
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 a message type to be specified such that retransmitted. This enables a message type to be specified such that
the message can be modified while in transit (e.g. to reflect the the message can be modified while in transit (e.g., to reflect the
route the message has taken). It also enables bypassing of the MPR route the message has taken). It also enables bypassing of the MPR
flooding mechanism if for some reason classical flooding of a message flooding mechanism if for some reason classical flooding of a message
type is required, the algorithm which specifies how such messages type is required, the algorithm which specifies how such messages
should be handled will simply rebroadcast the message, regardless of should be handled will simply rebroadcast 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
skipping to change at page 24, line 19 skipping to change at page 21, line 29
To avoid such synchronizations, the following simple strategy for To avoid such synchronizations, the following simple strategy for
emitting control messages is proposed. A node SHOULD add an amount emitting control messages is proposed. A node SHOULD add an amount
of jitter to the interval at which messages are generated. The of jitter to the interval at which messages are generated. The
jitter must be a random value for each message generated. Thus, for jitter must be a random value for each message generated. Thus, for
a node utilizing jitter: a node utilizing jitter:
Actual message interval = MESSAGE_INTERVAL - jitter Actual message interval = MESSAGE_INTERVAL - jitter
Where jitter is a value, randomly selected from the interval Where jitter is a value, randomly selected from the interval
[0,MAXJITTER] and MESSAGE_INTERVAL is the value of the message [0,MAXJITTER] and MESSAGE_INTERVAL is the value of the message
interval specified for the message being emitted (e.g. interval specified for the message being emitted (e.g.,
HELLO_INTERVAL for HELLO messages, TC_INTERVAL for TC-messages etc.). HELLO_INTERVAL for HELLO messages, TC_INTERVAL for TC-messages etc.).
Jitter SHOULD also be introduced when forwarding messages. The Jitter SHOULD also be introduced when forwarding messages. The
following simple strategy may be adopted: when a message is to be following simple strategy may be adopted: when a message is to be
forwarded by a node, it should be kept in the node during a short forwarded by a node, it should be kept in the node during a short
period of time : period of time :
Keep message period = jitter Keep message period = jitter
Where jitter is a random value in [0,MAXJITTER]. Where jitter is a random value in [0,MAXJITTER].
skipping to change at page 25, line 18 skipping to change at page 22, line 31
4.2. Link Sensing: Local Link Information Base 4.2. Link Sensing: Local Link Information Base
The local link information base stores information about links to The local link information base stores information about links to
neighbors. neighbors.
4.2.1. Link Set 4.2.1. Link Set
A node records a set of "Link Tuples" (L_local_iface_addr, A node records a set of "Link Tuples" (L_local_iface_addr,
L_neighbor_iface_addr, L_SYM_time, L_ASYM_time, L_time). L_neighbor_iface_addr, L_SYM_time, L_ASYM_time, L_time).
L_local_iface_addr is the interface address of the local node (i.e. L_local_iface_addr is the interface address of the local node (i.e.,
one endpoint of the link), L_neighbor_iface_addr is the interface one endpoint of the link), L_neighbor_iface_addr is the interface
address of the neighbor node (i.e. the other endpoint of the link), address of the neighbor node (i.e., the other endpoint of the link),
L_SYM_time is the time until which the link is considered symmetric, L_SYM_time is the time until which the link is considered symmetric,
L_ASYM_time is the time until which the neighbor interface is L_ASYM_time is the time until which the neighbor interface is
considered heard, and L_time specifies the time at which this record considered heard, and L_time specifies the time at which this record
expires and *MUST* be removed. When L_SYM_time and L_ASYM_time are expires and *MUST* be removed. When L_SYM_time and L_ASYM_time are
expired, the link is considered lost. 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.
L_SYM_time is used to decide the Link Type declared for the neighbor L_SYM_time is used to decide the Link Type declared for the neighbor
skipping to change at page 25, line 46 skipping to change at page 23, line 13
In a node, the set of Link Tuples are denoted the "Link Set". In a node, the set of Link Tuples are denoted the "Link Set".
4.3. Neighbor Detection: Neighborhood Information Base 4.3. Neighbor Detection: Neighborhood Information Base
The neighborhood information base stores information about neighbors, The neighborhood information base stores information about neighbors,
2-hop neighbors, MPRs and MPR selectors. 2-hop neighbors, MPRs and MPR selectors.
4.3.1. Neighbor Set 4.3.1. Neighbor Set
A node records a set of "neighbor tuples" (N_neighbor_main_addr, A node records a set of "neighbor tuples" (N_neighbor_main_addr,
N_status, N_willingness), describing symmetric neighbors. N_status, N_willingness), describing neighbors. N_neighbor_main_addr
N_neighbor_main_addr is the main address of a neighbor, N_status is the main address of a neighbor, N_status specifies if the node is
specifies if the node is NOT_SYM or SYM. N_willingness in an integer NOT_SYM or SYM. N_willingness in an integer between 0 and 7, and
between 0 and 7, and specifies a nodes willingness to carry traffic specifies the node's willingness to carry traffic on behalf of other
on behalf of other nodes. nodes.
4.3.2. 2-hop Neighbor Set 4.3.2. 2-hop Neighbor Set
A node records a set of "2-hop tuples" (N_neighbor_main_addr, A node records a set of "2-hop tuples" (N_neighbor_main_addr,
N_2hop_addr, N_time), describing symmetric (and, since MPR links by N_2hop_addr, N_time), describing symmetric (and, since MPR links by
definition are also symmetric, thereby also MPR) links between its definition are also symmetric, thereby also MPR) links between its
neighbors and the symmetric 2-hop neighborhood. N_neighbor_main_addr neighbors and the symmetric 2-hop neighborhood. N_neighbor_main_addr
is the main address of a neighbor, N_2hop_addr is the main address of is the main address of a neighbor, N_2hop_addr is the main address of
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
skipping to change at page 26, line 31 skipping to change at page 23, line 43
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 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 the tuple expires
*MUST* be removed. and *MUST* be removed.
In a node, the set of MPR-selector tuples are denoted the "MPR In a node, the set of MPR-selector tuples are denoted the "MPR
Selector Set". Selector Set".
4.4. Topology Information Base 4.4. Topology Information Base
Each node in the network maintains topology 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.
skipping to change at page 27, line 49 skipping to change at page 25, line 20
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
MID_MESSAGE. The time to live SHOULD be set to 255 (maximum value) The time to live SHOULD be set to 255 (maximum value) to diffuse the
to diffuse the message into the entire network and Vtime set message into the entire network and Vtime set accordingly to the
accordingly to the value of MID_HOLD_TIME, as specified in section 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 node, excluding the nodes main address (which already
indicated in the originator address). indicated 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
(as imposed by the network) is reached while there are still (as imposed by the network) is reached while there are still
interface addresses which have not been inserted into the MIDmessage, interface addresses which have not been inserted into the MIDmessage,
more MID messages are generated until the entire interface addresses more MID messages are generated until the entire interface addresses
set has been sent. set has been sent.
5.2. MID Message Generation 5.2. MID Message Generation
A MID message is sent by a node in the network to declare its A MID message is sent by a node in the network to declare its
multiple interfaces (if any). I.e., the MID message contains the multiple interfaces (if any). I.e., the MID message contains the
list of interface addresses which are associated to its main address. list of interface addresses which are associated to its main address.
The list of addresses can be partial in each MID message (e.g. due The list of addresses can be partial in each MID message (e.g., due
to message size limitations, imposed by the network), but parsing of to message size limitations, imposed by the network), but parsing of
all MID messages describing the interface set from a node MUST be all MID messages describing the interface set from a node MUST be
complete within a certain refreshing period (MID_INTERVAL). The complete within a certain refreshing period (MID_INTERVAL). The
information diffused in the network by these MID messages will help information diffused in the network by these MID messages will help
each node to calculate its routing table. A node which has only a each node to calculate its routing table. A node which has only a
single interface address participating in the MANET (i.e. running single interface address participating in the MANET (i.e., running
OLSR), MUST NOT generate any MID message. OLSR), MUST NOT generate any MID message.
A node with more interfaces, where only one is participating in the A node with several interfaces, where only one is participating in
MANET and running OLSR (e.g. a node is connected to a wired network the MANET and running OLSR (e.g., a node is connected to a wired
as well as to a MANET) MUST NOT generate any MID messages. network as well as to a MANET) MUST NOT generate any MID messages.
A node with more interfaces, where more than one is participating in A node with several interfaces, where more than one is participating
the MANET and running OLSR MUST generate MID messages as specified. in the MANET and running OLSR MUST generate MID messages as
specified.
5.3. MID Message Forwarding 5.3. MID Message Forwarding
MID messages are broadcast and retransmitted by the MPRs in order to MID messages are broadcast and retransmitted by the MPRs in order to
diffuse the messages in the entire network. The "default forwarding diffuse the messages in the entire network. The "default forwarding
algorithm" (described in section 3.4) MUST be used for algorithm" (described in section 3.4) MUST be used for forwarding of
forwarding of MID messages. MID messages.
5.4. MID Message Processing 5.4. MID Message Processing
The tuples in the multiple interface association set are recorded The tuples in the multiple interface association set are recorded
with the information that is exchanged through MID messages. with the information that is exchanged through MID messages.
Upon receiving a MID message, the "validity time" MUST be computed Upon receiving a MID message, the "validity time" MUST be computed
from the Vtime field of the message header (as described in section from the Vtime field of the message header (as described in section
3.3.2). The Multiple Interface Association Information Base 3.3.2). The Multiple Interface Association Information Base SHOULD
SHOULD then be updated as follows: then be updated as follows:
1 If the sender interface (NB: not originator) of this message 1 If the sender interface (NB: not originator) of this message
is not in the symmetric 1-hop neighborhood of this node, the is not in the symmetric 1-hop neighborhood of this node, the
message MUST be discarded. message MUST be discarded.
2 For each interface address listed in the MID message: 2 For each interface address listed in the MID message:
2.1 If there exist some tuple in the interface association 2.1 If there exist some tuple in the interface association
set where: set where:
skipping to change at page 30, line 9 skipping to change at page 27, line 21
the main address of a node is its "node id" - which for convenience the main address of a node is its "node id" - which for convenience
corresponds to the address of one of its interfaces). In a network corresponds to the address of one of its interfaces). In a network
with only single interface nodes, the main address of a node will, by with only single interface nodes, the main address of a node will, by
definition, be equal to the interface address of the node. In definition, be equal to the interface address of the node. In
networks with multiple interface nodes operating within a common OLSR networks with multiple interface nodes operating within a common OLSR
area, it is required to be able to map any interface address to the area, it is required to be able to map any interface address to the
corresponding main address. corresponding main address.
The exchange of MID messages provides a way in which interface The exchange of MID messages provides a way in which interface
information is acquired by nodes in the network. This permits information is acquired by nodes in the network. This permits
identification of a nodes "main address", given one of its interface identification of a node's "main address", given one of its interface
addresses. addresses.
Given an interface address: Given an interface address:
1 if there exists some tuple in the interface association set 1 if there exists some tuple in the interface association set
where: where:
I_iface_addr == interface address I_iface_addr == interface address
then the result of the main address search is the originator then the result of the main address search is the originator
skipping to change at page 31, line 17 skipping to change at page 28, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Htime | Willingness | | Reserved | Htime | Willingness |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Code | Reserved | Link Message Size | | Link Code | Reserved | Link Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address | | Neighbor Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address | | Neighbor Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . . . : . . . :
:
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Code | Reserved | Link Message Size | | Link Code | Reserved | Link Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address | | Neighbor Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface Address | | Neighbor Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: : : :
(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 section 3.4, with the "Message Type" set to described in section 3.4, with the "Message Type" set to
HELLO_MESSAGE, the TTL field set to 1 (one) and Vtime set accordingly HELLO_MESSAGE, the TTL field set to 1 (one) and Vtime set accordingly
to the value of NEIGHB_HOLD_TIME, specified in section 18.3. to the value of NEIGHB_HOLD_TIME, specified in section 18.3.
Reserved Reserved
This field must be set to "0000000000000" to be in compliance This field must be set to "0000000000000" to be in compliance
with this specification. with this specification.
HTime HTime
This field specifies the HELLO emission interval used by the This field specifies the HELLO emission interval used by the
node on this particular interface, i.e. the time before the node on this particular interface, i.e., the time before the
transmission of the next HELLO (this information may be used transmission of the next HELLO (this information may be used in
in advanced link sensing, see section 14). The advanced link sensing, see section 14). The HELLO emission
HELLO emission interval is represented by its mantissa (four interval is represented by its mantissa (four highest bits of
highest bits of Htime field) and by its exponent (four lowest Htime field) and by its exponent (four lowest bits of Htime
bits of Htime field). In other words: field). In other words:
HELLO emission interval=C*(1+a/16)*2^b [in seconds] HELLO emission interval=C*(1+a/16)*2^b [in seconds]
where a is the integer represented by the four highest bits of where a is the integer represented by the four highest bits of
Htime field and b the integer represented by the four lowest Htime field and b the integer represented by the four lowest
bits of Htime field. The proposed value of the scaling factor bits of Htime field. The proposed value of the scaling factor
C is specified in section 18. C is specified in section 18.
Willingness Willingness
This field specifies the willingness of a node to carry and This field specifies the willingness of a node to carry and
forward traffic for other nodes. forward traffic for other nodes.
A node with willingness WILL_NEVER (see section 18.8, for A node with willingness WILL_NEVER (see section 18.8, for
willingness constants) MUST never be selected as MPR by any willingness constants) MUST never be selected as MPR by any
node. A node with willingness WILL_ALWAYS MUST always be node. A node with willingness WILL_ALWAYS MUST always be
selected as MPR. By default, a node SHOULD advertise a selected as MPR. By default, a node SHOULD advertise a
willingness of WILL_DEFAULT. willingness of WILL_DEFAULT.
Link Code Link Code
This field specifies informations about the link between the This field specifies information about the link between the
interface of the sender and the following list of neighbor interface of the sender and the following list of neighbor
interfaces. It also specifies informations about the status interfaces. It also specifies information about the status of
of the neighbor. the neighbor.
Link codes, not known by a node, are silently discarded. Link codes, not known by a node, are silently discarded.
Link Message Size Link Message Size
The size of the link message, counted in bytes and measured The size of the link message, counted in bytes and measured
from the beginning of the "Link Code" field and until the next from the beginning of the "Link Code" field and until the next
"Link Code" field (or - if there are no more link types - the "Link Code" field (or - if there are no more link types - the
end of the message). end of the message).
Neighbor Interface Address Neighbor Interface Address
An address of the interface of a neighbor node. The address of an interface of a neighbor node.
6.1.1. Link Code as Link Type and Neighbor Type 6.1.1. Link Code as Link Type and Neighbor Type
This document only specifies processing of Link Codes < 16. This document only specifies processing of Link Codes < 16.
If the Link Code value is less or equal to 15, then it MUST be If the Link Code value is less than or equal to 15, then it MUST be
interpreted as holding two different fields, of two bits each: interpreted as holding two different fields, of two bits each:
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
| 0 | 0 | 0 | 0 | Neighbor Type | Link Type | | 0 | 0 | 0 | 0 | Neighbor Type | Link Type |
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
The following four "Link Types" are REQUIRED by OLSR: The following four "Link Types" are REQUIRED by OLSR:
- UNSPEC_LINK - indicating that no specific information about - UNSPEC_LINK - indicating that no specific information about
the links is given. the links is given.
- ASYM_LINK - indicating that the links are asymmetric (i.e. - ASYM_LINK - indicating that the links are asymmetric (i.e.,
the neighbor interface is "heard"). the neighbor interface is "heard").
- SYM_LINK - indicating that the links are symmetric with the - SYM_LINK - indicating that the links are symmetric with the
interface. interface.
- LOST_LINK - indicating that the links have been lost. - LOST_LINK - indicating that the links have been lost.
The following three "Neighbor Types" are REQUIRED by OLSR: The following three "Neighbor Types" are REQUIRED by OLSR:
- SYM_NEIGH - indicating that the neighbors have at least one - SYM_NEIGH - indicating that the neighbors have at least one
symmetrical link with this node. symmetrical link with this node.
- MPR_NEIGH - indicating that the neighbors have at least one - MPR_NEIGH - indicating that the neighbors have at least one
symmetrical link AND have been been selected as MPR by the symmetrical link AND have been selected as MPR by the sender.
sender.
- NOT_NEIGH - indicating that the nodes are either no longer or - NOT_NEIGH - indicating that the nodes are either no longer or
have not yet become symmetrical neighbors. have not yet become symmetric neighbors.
Note that an implementation should be careful in not confusing Link Note that an implementation should be careful in confusing neither
Type with Neighbor Type nor the constants (confusing SYM_NEIGH with Link Type with Neighbor Type nor the constants (confusing SYM_NEIGH
SYM_LINK for instance). with SYM_LINK for instance).
A link code advertising: A link code advertising:
Link Type == SYM_LINK AND Link Type == SYM_LINK AND
Neighbor Type == NOT_NEIGH Neighbor Type == NOT_NEIGH
is invalid, and any links adverticed as such MUST be silently is invalid, and any links advertised as such MUST be silently
discarded without any processing. discarded without any processing.
Likewise a Neighbor Type field advertising a numerical value which is Likewise a Neighbor Type field advertising a numerical value which is
not one of the constants SYM_NEIGH, MPR_NEIGH, NOT_NEIGH, is invalid, not one of the constants SYM_NEIGH, MPR_NEIGH, NOT_NEIGH, is invalid,
and any links adverticed as such MUST be silently discarded without and any links advertised as such MUST be silently discarded without
any processing. any processing.
6.2. HELLO Message Generation 6.2. HELLO Message Generation
This involves transmitting the Link Set, the Neighbor Set and the MPR This involves transmitting the Link Set, the Neighbor Set and the MPR
Set. In principle, a HELLO message serves three independent tasks: Set. In principle, a HELLO message serves three independent tasks:
- link sensing - link sensing
- neighbor detection - neighbor detection
- MPR selection signaling - MPR selection signaling
Three tasks are all are based on periodic information exchange within Three tasks are all are based on periodic information exchange within
a nodes neighborhood, and serve the common purpose of "local topology a nodes neighborhood, and serve the common purpose of "local topology
discovery". A HELLO message is therefore generated based on the discovery". A HELLO message is therefore generated based on the
information stored in the Local Link Set, the Neighbor Set and the information stored in the Local Link Set, the Neighbor Set and the
MPR Set from the local link information base. MPR Set from the local link information base.
skipping to change at page 35, line 4 skipping to change at page 31, line 30
types), as well as a list of the entire neighborhood (with an types), as well as a list of the entire neighborhood (with an
associated neighbor types). associated neighbor types).
The Vtime field is set such that it corresponds to the value of the The Vtime field is set such that it corresponds to the value of the
node's NEIGHB_HOLD_TIME parameter. The Htime field is set such that node's NEIGHB_HOLD_TIME parameter. The Htime field is set such that
it corresponds to the value of the node's HELLO_INTERVAL parameter it corresponds to the value of the node's HELLO_INTERVAL parameter
(see section 18.3). (see section 18.3).
The Willingness field is set such that it corresponds to the node's The Willingness field is set such that it corresponds to the node's
willingness to forward traffic on behalf of other nodes (see section willingness to forward traffic on behalf of other nodes (see section
18.8). A node MUST advertise the same willingness on all 18.8). A node MUST advertise the same willingness on all interfaces.
interfaces.
The lists of addresses declared in a HELLO message is a list of The lists of addresses declared in a HELLO message is a list of
neighbor interface addresses computed as follows: neighbor interface addresses computed as follows:
For each tuple in the Link Set, where L_local_iface_addr is the For each tuple in the Link Set, where L_local_iface_addr is the
interface where the HELLO is to be transmitted, and where L_time >= interface where the HELLO is to be transmitted, and where L_time >=
current time (i.e. not expired), L_neighbor_iface_addr is advertised current time (i.e., not expired), L_neighbor_iface_addr is advertised
with: with:
1 The Link Type set according to the following: 1 The Link Type set according to the following:
1.1 if L_SYM_time >= current time (not expired) 1.1 if L_SYM_time >= current time (not expired)
Link Type = SYM_LINK Link Type = SYM_LINK
1.2 Otherwise, if L_ASYM_time >= current time (not expired) 1.2 Otherwise, if L_ASYM_time >= current time (not expired)
AND AND
skipping to change at page 36, line 16 skipping to change at page 32, line 40
For each tuple in the Neighbor Set, for which no For each tuple in the Neighbor Set, for which no
L_neighbor_iface_addr from an associated link tuple has been L_neighbor_iface_addr from an associated link tuple has been
advertised by the previous algorithm, N_neighbor_main_addr is advertised by the previous algorithm, N_neighbor_main_addr is
advertised with: advertised with:
- Link Type = UNSPEC_LINK, - Link Type = UNSPEC_LINK,
- Neighbor Type set as described in step 2 above - Neighbor Type set as described in step 2 above
For a node with a single OLSR interface, the main address is simply For a node with a single OLSR interface, the main address is simply
the address of the OLSR interface. I.e. for a node with a single the address of the OLSR interface, i.e., for a node with a single
OLSR interface, the main address, corresponding to OLSR interface the main address, corresponding to
L_neighbor_iface_addr is simply L_neighbor_iface_addr. L_neighbor_iface_addr is simply L_neighbor_iface_addr.
A HELLO message can be partial (e.g. due to message size A HELLO message can be partial (e.g., due to message size
limitations, imposed by the network), the rule being the following, limitations, imposed by the network), the rule being the following,
on each interface: each link and each neighbor node MUST be cited at on each interface: each link and each neighbor node MUST be cited at
least once within a predetermined refreshing period, least once within a predetermined refreshing period,
REFRESH_INTERVAL. To keep track of fast connectivity changes, a REFRESH_INTERVAL. To keep track of fast connectivity changes, a
HELLO message must be sent at least every HELLO_INTERVAL period, HELLO message must be sent at least every HELLO_INTERVAL period,
smaller than or equal to REFRESH_INTERVAL. smaller than or equal 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 packet header) can fit is desirable that a message (plus the generic packet header) can fit
into a single MAC frame. into a single MAC frame.
6.3. HELLO Message Forwarding 6.3. HELLO Message Forwarding
Each HELLO message generated is broadcast by the node on one Each HELLO message generated is broadcast by the node on one
interface to its neighbors. HELLO messages MUST never be forwarded. interface to its neighbors (i.e. the interface for which the HELLO
was generated). HELLO messages MUST never be forwarded.
6.4. HELLO Message Processing 6.4. HELLO Message Processing
A node processes incoming HELLO messages for the purpose of A node processes incoming HELLO messages for the purpose of
conducting link sensing (detailed in section 7), neighbor conducting link sensing (detailed in section 7), neighbor detection
detection and MPR selector set population (detailed in section and MPR selector set population (detailed in section 8)
8)
7. Link Sensing 7. Link Sensing
Link sensing populates the local link information base. Link sensing Link sensing populates the local link information base. Link sensing
is exclusively concerned with OLSR interface addresses and the is exclusively concerned with OLSR interface addresses and the
ability to exchange packets between such OLSR interfaces. ability to exchange packets between such OLSR interfaces.
The mechanism for link sensing is the periodic exchange of HELLO The mechanism for link sensing is the periodic exchange of HELLO
messages. messages.
skipping to change at page 37, line 27 skipping to change at page 33, line 49
unidirectional. Consequently, all links MUST be checked in both unidirectional. Consequently, all links MUST be checked in both
directions in order to be considered valid. directions in order to be considered valid.
A "link" is described by a pair of interfaces: a local and a remote A "link" is described by a pair of interfaces: a local and a remote
interface. interface.
For the purpose of link sensing, each neighbor node (more For the purpose of link sensing, each neighbor node (more
specifically, the link to each neighbor) has an associated status of specifically, the link to each neighbor) has an associated status of
either "symmetric" or "asymmetric". "Symmetric" indicates, that the either "symmetric" or "asymmetric". "Symmetric" indicates, that the
link to that neighbor node has been verified to be bi-directional, link to that neighbor node has been verified to be bi-directional,
i.e. it is possible to transmit data in both directions. i.e., it is possible to transmit data in both directions.
"Asymmetric" indicates that HELLO messages from the node have been "Asymmetric" indicates that HELLO messages from the node have been
heard (i.e. communication from the neighbor node is possible), heard (i.e., communication from the neighbor node is possible),
however it is not confirmed that this node is also able to receive however it is not confirmed that this node is also able to receive
messages (i.e. communication to the neighbor node is not confirmed). messages (i.e., communication to the neighbor node is not confirmed).
The information, acquired through and used by the link sensing, is The information, acquired through and used by the link sensing, is
accumulated in the link set. accumulated in the link set.
7.1.1. HELLO Message Processing 7.1.1. HELLO Message Processing
The "Originator Address" of a HELLO message is the main address of The "Originator Address" of a HELLO message is the main address of
the node, which has emitted the message. the node, which has emitted the message.
Upon receiving a HELLO message, a node SHOULD update its Link Set. Upon receiving a HELLO message, a node SHOULD update its Link Set.
skipping to change at page 38, line 37 skipping to change at page 35, line 8
2.1 L_ASYM_time = current time + validity time; 2.1 L_ASYM_time = current time + validity time;
2.2 if the node finds the address of the interface which 2.2 if the node finds the address of the interface which
received the HELLO message among the addresses listed in received the HELLO message among the addresses listed in
the link message then the tuple is modified as follows: the link message then the tuple is modified as follows:
2.2.1 2.2.1
if Link Type is equal to LOST_LINK then if Link Type is equal to LOST_LINK then
L_SYM_time = current time - 1 (i.e. expired) L_SYM_time = current time - 1 (i.e., expired)
2.2.2 2.2.2
else if Link Type is equal to SYM_LINK or ASYM_LINK else if Link Type is equal to SYM_LINK or ASYM_LINK
then then
L_SYM_time = current time + validity time, L_SYM_time = current time + validity time,
L_time = L_SYM_time + NEIGHB_HOLD_TIME L_time = L_SYM_time + NEIGHB_HOLD_TIME
2.3 L_time = max(L_time, L_ASYM_time) 2.3 L_time = max(L_time, L_ASYM_time)
skipping to change at page 40, line 20 skipping to change at page 36, line 39
in the next step in the next step
Update Update
Each time a link changes, that is, each time the information Each time a link changes, that is, each time the information
of a link tuple is modified, the node MUST ensure that the of a link tuple is modified, the node MUST ensure that the
N_status of the associated neighbor tuple respects the N_status of the associated neighbor tuple respects the
property: property:
If the neighbor has any associated link tuple which If the neighbor has any associated link tuple which
indicates a symmetrical link (i.e. with L_SYM_time >= indicates a symmetric link (i.e., with L_SYM_time >=
current time), then current time), then
N_status is set to SYM N_status is set to SYM
else N_status is set to NOT_SYM else N_status is set to NOT_SYM
Removal Removal
Each time a link is deleted, that is, each time a link tuple Each time a link is deleted, that is, each time a link tuple
is removed, the associated neighbor tuple MUST be removed if is removed, the associated neighbor tuple MUST be removed if
skipping to change at page 41, line 41 skipping to change at page 38, line 10
L_SYM_time >= current time (not expired) L_SYM_time >= current time (not expired)
(in other words: if the Originator Address is a symmetric neighbor) (in other words: if the Originator Address is a symmetric neighbor)
then the 2-hop Neighbor Set SHOULD be updated as follows: then the 2-hop Neighbor Set SHOULD be updated as follows:
1 for each address (henceforth: 2-hop neighbor address), listed 1 for each address (henceforth: 2-hop neighbor address), listed
in the HELLO message with Neighbor Type equal to SYM_NEIGH or in the HELLO message with Neighbor Type equal to SYM_NEIGH or
MPR_NEIGH: MPR_NEIGH:
1.1 if the main address of the 2-hop neighbor address = main 1.1 if the main address of the 2-hop neighbor address = main
address of receiving node: address of the receiving node:
silently discard the 2-hop neighbor address. silently discard the 2-hop neighbor address.
(in other words: a node is not its own 2-hop neighbor). (in other words: a node is not its own 2-hop neighbor).
1.2 Otherwise, a 2-hop tuple is created with: 1.2 Otherwise, a 2-hop tuple is created with:
N_neighbor_main_addr = Originator Address; N_neighbor_main_addr = Originator Address;
N_2hop_addr = main address of the N_2hop_addr = main address of the
skipping to change at page 42, line 44 skipping to change at page 39, line 11
among its symmetric 1-hop neighborhood. The symmetric links with among its symmetric 1-hop neighborhood. The symmetric links with
MPRs are advertised with Link Type MPR_NEIGH instead of SYM_NEIGH in MPRs are advertised with Link Type MPR_NEIGH instead of SYM_NEIGH in
HELLO messages. HELLO messages.
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 strict through the neighbors in the MPR-set, can reach all symmetric strict
2-hop neighbors. (Notice that a node, a, which is a direct neighbor 2-hop neighbors. (Notice that a node, a, which is a direct neighbor
of another node, b, is not also a strict 2-hop neighbor of node b). of another node, b, is not also a strict 2-hop neighbor of node b).
This means that the union of the symmetric 1-hop neighborhoods of the This means that the union of the symmetric 1-hop neighborhoods of the
MPR nodes contains the symmetric strict 2-hop neighborhood. MPR set MPR nodes contains the symmetric strict 2-hop neighborhood. MPR set
recalculation should occur when changes are detected in the recalculation should occur when changes are detected in the symmetric
neighborhood or in the 2-hop neighborhood. neighborhood or in the symmetric strict 2-hop neighborhood.
MPRs are computed per interface, the union of the MPR sets of each MPRs are computed per interface, the union of the MPR sets of each
interface make up the MPR set for the node. interface make up the MPR set for the node.
While it is not essential that the MPR set is minimal, it is While it is not essential that the MPR set is minimal, it is
essential that all strict 2-hop neighbors can be reached through the essential that all strict 2-hop neighbors can be reached through the
selected MPR nodes. A node SHOULD select an MPR set such that any selected MPR nodes. A node SHOULD select an MPR set such that any
strict 2-hop neighbor is covered by at least one MPR node. This strict 2-hop neighbor is covered by at least one MPR node. Keeping
ensures that the overhead of the protocol is kept at a minimum. the MPR set small ensures that the overhead of the protocol is kept
at a minimum.
The MPR set can coincide with the entire symmetric neighbor set. The MPR set can coincide with the entire symmetric neighbor set.
This could be the case at network initialization (and will correspond This could be the case at network initialization (and will correspond
to classic link-state routing). to classic link-state routing).
8.3.1. MPR Computation 8.3.1. MPR Computation
The following specifies a proposed heuristic for selection of MPRs. The following specifies a proposed heuristic for selection of MPRs.
It constructs an MPR-set that enables a node to reach any node in the It constructs an MPR-set that enables a node to reach any node in the
symmetrical strict 2-hop neighborhood through relaying by one MPR symmetrical strict 2-hop neighborhood through relaying by one MPR
node with willingness different from WILL_NEVER. The heuristic MUST node with willingness different from WILL_NEVER. The heuristic MUST
be applied per interface, I. The MPR set for a node is the union of be applied per interface, I. The MPR set for a node is the union of
the MPR sets found for each interface. The following terminology the MPR sets found for each interface. The following terminology
will be used in describing the heuristics: will be used in describing the heuristics:
neighbor of an interface neighbor of an interface
a node is a "neighbor of an interface" if the interface
(on the local node) has a link to any one interface of
the neighbor node.
2-hop neighbors reachable from an interface
the list of 2-hop neighbors of the node that can be
reached from neighbors of this interface.
MPR set of an interface a node is a "neighbor of an interface" if the interface
(on the local node) has a link to any one interface of
the neighbor node.
a (sub)set of the neighbors of an interface with a 2-hop neighbors reachable from an interface
willingness different from WILL_NEVER, selected such that
through these selected nodes, all strict 2-hop neighbors
reachable from that interface are reachable.
N: the list of 2-hop neighbors of the node that can be
reached from neighbors of this interface.
N is the subset of neighbors of the node, which are MPR set of an interface
neighbor of the interface I.
N2: a (sub)set of the neighbors of an interface with a
willingness different from WILL_NEVER, selected such that
through these selected nodes, all strict 2-hop neighbors
reachable from that interface are reachable.
The set of two-hop neighbors reachable from the interface N:
I, excluding: N is the subset of neighbors of the node, which are
neighbor of the interface I.
(i) the nodes only reachable by members of N with N2:
willingness WILL_NEVER The set of 2-hop neighbors reachable from the interface
I, excluding:
(ii) the node performing the computation (i) the nodes only reachable by members of N with
willingness WILL_NEVER
(iii) (ii) the node performing the computation
all the symmetric neighbors: the nodes for which
there exists a symmetric link to this node on some
interface.
D(y): (iii) all the symmetric neighbors: the nodes for which
there exists a symmetric link to this node on some
interface.
The degree of an one hop neighbor node y (where y is a D(y):
member of N), is defined as the number of symmetric The degree of a 1-hop neighbor node y (where y is a
neighbors of node y, EXCLUDING all the members of N and member of N), is defined as the number of symmetric
EXCLUDING the node performing the computation. neighbors of node y, EXCLUDING all the members of N and
EXCLUDING the node performing the computation.
The proposed heuristic is as follows: The proposed heuristic is as follows:
1 Start with an MPR set made of all members of N with 1 Start with an MPR set made of all members of N with
N_willingness equal to WILL_ALWAYS N_willingness equal to WILL_ALWAYS
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 Add to the MPR set those nodes in N, which are the *only* 3 Add to the MPR set those nodes in N, which are the *only*
nodes to provide reachability to a node in N2. I.e. if node nodes to provide reachability to a node in N2. For example,
b in N2 can be reached only through a symmetric link to node a if node b in N2 can be reached only through a symmetric link
in N, then add node a to the MPR set. Remove the nodes from to node a in N, then add node a to the MPR set. Remove the
N2 which are now covered by a node in the MPR set. nodes from N2 which are now covered by a node in the MPR set.
4 While there exist nodes in N2 which are not covered by at 4 While there exist nodes in N2 which are not covered by at
least one node in the MPR set: least one node in the MPR set:
4.1 For each node in N, calculate the reachability, i.e. the 4.1 For each node in N, calculate the reachability, i.e., the
number of nodes in N2 which are not yet covered by at number of nodes in N2 which are not yet covered by at
least one node in the MPR set, and which are reachable least one node in the MPR set, and which are reachable
through this one hop neighbor; through this 1-hop neighbor;
4.2 Select as a MPR the node with highest N_willingness among 4.2 Select as a MPR the node with highest N_willingness among
the nodes in N with non-zero reachability. In case of the nodes in N with non-zero reachability. In case of
multiple choice select the node which provides multiple choice select the node which provides
reachability to the maximum number of nodes in N2. In reachability to the maximum number of nodes in N2. In
case of multiple nodes providing the same amount of case of multiple nodes providing the same amount of
reachability, select the node as MPR whose D(y) is reachability, select the node as MPR whose D(y) is
greater. Remove the nodes from N2 which are now covered greater. Remove the nodes from N2 which are now covered
by a node in the MPR set. by a node in the MPR set.
skipping to change at page 45, line 39 skipping to change at page 41, line 48
through HELLO messages. through HELLO messages.
8.4.1. HELLO Message Processing 8.4.1. HELLO Message Processing
Upon receiving a HELLO message, if a node finds one of its own Upon receiving a HELLO message, if a node finds one of its own
interface addresses in the list with a Neighbor Type equal to interface addresses in the list with a Neighbor Type equal to
MPR_NEIGH, information from the HELLO message must be recorded in the MPR_NEIGH, information from the HELLO message must be recorded in the
MPR Selector Set. MPR Selector Set.
The "validity time" MUST be computed from the Vtime field of the The "validity time" MUST be computed from the Vtime field of the
message header (see section 3.3.2). The MPR Selector Set message header (see section 3.3.2). The MPR Selector Set SHOULD then
SHOULD then be updated as follows: be updated as follows:
1 If there exists no MPR selector tuple with: 1 If there exists no MPR selector tuple with:
MS_main_addr == Originator Address MS_main_addr == Originator Address
then a new tuple is created with: then a new tuple is created with:
MS_main_addr = Originator Address MS_main_addr = Originator Address
2 The tuple (new or otherwise) with 2 The tuple (new or otherwise) with
skipping to change at page 47, line 16 skipping to change at page 43, line 22
- An additional HELLO message MAY be sent when the MPR set - An additional HELLO message MAY be sent when the MPR set
changes. changes.
9. Topology Discovery 9. Topology Discovery
The link sensing and neighbor detection part of the protocol The link sensing and neighbor detection part of the protocol
basically offers, to each node, a list of neighbors with which it can basically offers, to each node, a list of neighbors with which it can
communicate directly and, in combination with the Packet Format and communicate directly and, in combination with the Packet Format and
Forwarding part, an optimized flooding mechanism through MPRs. Based Forwarding part, an optimized flooding mechanism through MPRs. Based
on this, topology information is disseminated through the network. on this, topology information is disseminated through the network.
The present section describes what part of the information given by The present section describes which part of the information given by
the link sensing and neighbor detection is disseminated to the entire the link sensing and neighbor detection is disseminated to the entire
network and how it is used to construct routes. network and how it is used to construct routes.
Routes are constructed through advertised links and links with Routes are constructed through advertised links and links with
neighbors. A node must at least disseminate links between itself and neighbors. A node must at least disseminate links between itself and
the nodes in its MPR-selector set, in order to provide sufficient the nodes in its MPR-selector set, in order to provide sufficient
information to enable routing. information to enable routing.
9.1. TC Message Format 9.1. TC Message Format
skipping to change at page 48, line 10 skipping to change at page 44, line 10
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 network to 255 (maximum value) to diffuse the message into the entire network
and Vtime set accordingly to the value of TOP_HOLD_TIME, as specified and Vtime set accordingly to the value of TOP_HOLD_TIME, as specified
in section 18.3. in section 18.3.
Advertised Neighbor Sequence Number (ANSN) Advertised Neighbor Sequence Number (ANSN)
A sequence number is associated with the advertised neighbor A sequence number is associated with the advertised neighbor
set. Every time a node detects a change in its advertised set. Every time a node detects a change in its advertised
neighbor set, it increments this sequence number ("Wraparound" neighbor set, it increments this sequence number ("Wraparound"
is handled as described in section 19). This number is handled as described in section 19). This number is sent
is sent in this ANSN field of the TC message to keep track of in this ANSN field of the TC message to keep track of the most
the most recent information. When a node receives a TC recent information. When a node receives a TC message, it can
message, it can decide on the basis of this Advertised decide on the basis of this Advertised Neighbor Sequence
Neighbor Sequence Number, whether or not the received Number, whether or not the received information about the
information about the advertised neighbors of the originator advertised neighbors of the originator node is more recent
node is more recent than what it already has. than what it already has.
Advertised Neighbor Main Address Advertised Neighbor Main Address
This field contains the main address of a neighbor node. All This field contains the main address of a neighbor node. All
main addresses of the advertised neighbors of the Originator main addresses of the advertised neighbors of the Originator
node are put in the TC message. If the maximum allowed node are put in the TC message. If the maximum allowed
message size (as imposed by the network) is reached while message size (as imposed by the network) is reached while
there are still advertised neighbor addresses which have not there are still advertised neighbor addresses which have not
been inserted into the TC-message, more TC messages will be been inserted into the TC-message, more TC messages will be
generated until the entire advertised neighbor set has been generated until the entire advertised neighbor set has been
skipping to change at page 49, line 13 skipping to change at page 45, line 13
neighbor set. neighbor set.
9.3. TC Message Generation 9.3. TC Message Generation
In order to build the topology information base, each node, which has In order to build the topology information base, each node, which has
been selected as MPR, broadcasts Topology Control (TC) messages. TC been selected as MPR, broadcasts Topology Control (TC) messages. TC
messages are flooded to all nodes in the network and take advantage messages are flooded to all nodes in the network and take advantage
of MPRs. MPRs enable a better scalability in the distribution of of MPRs. MPRs enable a better scalability in the distribution of
topology information [1]. topology information [1].
The list of addresses can be partial in each TC message (e.g. due to 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 message size limitations, imposed by the network), but parsing of all
TC messages describing the advertised link set of a node MUST be TC messages describing the advertised link set of a node MUST be
complete within a certain refreshing period (TC_INTERVAL). The complete within a certain refreshing period (TC_INTERVAL). The
information diffused in the network by these TC messages will help information diffused in the network by these TC messages will help
each node calculate its routing table. each node calculate its routing table.
When the advertised link set of a node becomes empty, it SHOULD still When the advertised link set of a node becomes empty, this node
send (empty) TC-messages during the a duration equal to the "validity SHOULD still send (empty) TC-messages during the a duration equal to
time" (typically, this will be equal to TC_HOLD_TIME) of its the "validity time" (typically, this will be equal to TOP_HOLD_TIME)
previously emitted TC-messages, in order to invalidate the previous of its previously emitted TC-messages, in order to invalidate the
TC-messages. It SHOULD then stop sending TC-messages until some node previous TC-messages. It SHOULD then stop sending TC-messages until
is inserted in its advertised link set. some node is inserted in its advertised link set.
A node MAY transmit additional TC-messages to increase its A node MAY transmit additional TC-messages to increase its
reactiveness to link failures. When a change to the MPR selector set reactiveness to link failures. When a change to the MPR selector set
is detected and this change can be attributed to a link failure, a is detected and this change can be attributed to a link failure, a
TC-message SHOULD be transmitted after a shorter interval than TC-message SHOULD be transmitted after an interval shorter than
TC_INTERVAL. TC_INTERVAL.
9.4. TC Message Forwarding 9.4. TC Message Forwarding
TC messages are broadcast and retransmitted by the MPRs in order to TC messages are broadcast and retransmitted by the MPRs in order to
diffuse the messages in the entire network. TC messages MUST be diffuse the messages in the entire network. TC messages MUST be
forwarded according to the "default forwarding algorithm". forwarded according to the "default forwarding algorithm" (described
in section 3.4).
9.5. TC Message Processing 9.5. TC Message Processing
Upon receiving a TC message, the "validity time" MUST be computed Upon receiving a TC message, the "validity time" MUST be computed
from the Vtime field of the message header (see section 3.3.2). from the Vtime field of the message header (see section 3.3.2). The
The topology set SHOULD then be updated as follows (using section topology set SHOULD then be updated as follows (using section 19 for
19 for comparison of ANSN): comparison of ANSN):
1 If the sender interface (NB: not originator) of this message 1 If the sender interface (NB: not originator) of this message
is not in the symmetric 1-hop neighborhood of this node, the is not in the symmetric 1-hop neighborhood of this node, the
message MUST be discarded. message MUST be discarded.
2 If there exist some tuple in the topology set where: 2 If there exist some tuple in the topology set where:
T_last_addr == originator address AND T_last_addr == originator address AND
T_seq > ANSN, T_seq > ANSN,
skipping to change at page 51, line 9 skipping to change at page 47, line 9
T_last_addr = originator address, T_last_addr = originator address,
T_seq = ANSN, T_seq = ANSN,
T_time = current time + validity time. T_time = current time + validity time.
10. Routing Table Calculation 10. 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 link set and the topology based on the information contained in the local link information base
set. Therefore, if any of these sets are changed, the routing table and the topology set. Therefore, if any of these sets are changed,
is recalculated to update the route information about each the routing table is recalculated to update the route information
destination in the network. The route entries are recorded in the about each destination in the network. The route entries are
routing table in the following format: recorded in the routing table in the following format:
1. R_dest_addr R_next_addr R_dist R_iface_addr 1. R_dest_addr R_next_addr R_dist R_iface_addr
2. R_dest_addr R_next_addr R_dist R_iface_addr 2. R_dest_addr R_next_addr R_dist R_iface_addr
3. ,, ,, ,, ,, 3. ,, ,, ,, ,,
Each entry in the table consists of R_dest_addr, R_next_addr, R_dist, Each entry in the table consists of R_dest_addr, R_next_addr, R_dist,
and R_iface_addr. Such entry specifies that the node identified by and R_iface_addr. Such entry specifies that the node identified by
R_dest_addr is estimated to be R_dist hops away from the local node, R_dest_addr is estimated to be R_dist hops away from the local node,
that the symmetric neighbor node with interface address R_next_addr that the symmetric neighbor node with interface address R_next_addr
is the next hop node in the route to R_dest_addr, and that this is the next hop node in the route to R_dest_addr, and that this
symmetric neighbor node is reachable through the local interface with symmetric neighbor node is reachable through the local interface with
the address R_iface_addr. Entries are recorded in the routing table the address R_iface_addr. Entries are recorded in the routing table
for each destination in the network for which a route is known. All for each destination in the network for which a route is known. All
the destinations, for which a route is broken or only partially the destinations, for which a route is broken or only partially
known, are not recorded in the table. known, are not recorded in the table.
The routing table is updated when a change is detected in either: More precisely, the routing table is updated when a change is
detected in either:
- the link set, - the link set,
- the neighbor set, - the neighbor set,
- the 2-hop neighbor set, - the 2-hop neighbor set,
- the topology set, - the topology set,
- the Multiple Interface Association Information Base, - the Multiple Interface Association Information Base,
More precisely, the routing table is recalculated in case of neighbor More precisely, the routing table is recalculated in case of neighbor
appearance or loss, when a 2-hop tuple is created or removed,when a appearance or loss, when a 2-hop tuple is created or removed, when a
topology tuple is created or removed or when multiple interface topology tuple is created or removed or when multiple interface
association information changes. The update of this routing association information changes. The update of this routing
information does not generate or trigger any messages to be information does not generate or trigger any messages to be
transmitted, neither in the network, nor in the 1-hop neighborhood. transmitted, neither in the network, nor in the 1-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 Neighbor Type equal to SYM), the any symmetric neighbor of X (with Neighbor Type equal to SYM), the
arcs Y -> Z where Y is a neighbor node with willingness different of arcs Y -> Z where Y is a neighbor node with willingness different of
WILL_NEVER and there exists an entry in the 2-hop Neighbor set with Y WILL_NEVER and there exists an entry in the 2-hop Neighbor set with Y
as N_neighbor_main_addr and Z as N_2hop_addr, and the arcs U -> V, as N_neighbor_main_addr and Z as N_2hop_addr, and the arcs U -> V,
where there exists an entry in the topology set with V as T_dest_addr where there exists an entry in the topology set with V as T_dest_addr
and U as T_last_addr. and U as T_last_addr.
The following procedure is given as an example to calculate (or The following procedure is given as an example to calculate (or
recalculate) the routing table : recalculate) the routing table:
1 All the entries from the routing table are removed. 1 All the entries from the routing table are removed.
2 The new routing entries are added starting with the symmetric 2 The new routing entries are added starting with the
neighbors (h=1) as the destination nodes. I.e. for each symmetric neighbors (h=1) as the destination nodes. Thus, for
neighbor tuple in the neighbor set where: each neighbor tuple in the neighbor set where:
N_status = SYM N_status = SYM
(there is a symmetric link to the neighbor), and for each (there is a symmetric link to the neighbor), and for each
associated link tuple of the neighbor node such that L_time >= associated link tuple of the neighbor node such that L_time >=
current time, a new routing entry is recorded in the routing current time, a new routing entry is recorded in the routing
table with: table with:
R_dest_addr = L_neighbor_iface_addr, of the R_dest_addr = L_neighbor_iface_addr, of the
associated link tuple; associated link tuple;
skipping to change at page 53, line 5 skipping to change at page 49, line 5
R_next_addr = L_neighbor_iface_addr of one of the R_next_addr = L_neighbor_iface_addr of one of the
associated link tuple with L_time >= associated link tuple with L_time >=
current time; current time;
R_dist = 1; R_dist = 1;
R_iface_addr = L_local_iface_addr of the R_iface_addr = L_local_iface_addr of the
associated link tuple. associated link tuple.
3 for each node in N2, i.e a 2-hop neighbor which is not a 3 for each node in N2, i.e., a 2-hop neighbor which is not a
neighbor node or the node itself, and such that there exist at neighbor node or the node itself, and such that there exist at
least one entry in the 2-hop neighbor set where least one entry in the 2-hop neighbor set where
N_neighbor_main_addr correspond to a neighbor node with N_neighbor_main_addr correspond to a neighbor node with
willingness different of WILL_NEVER, one selects one 2-hop willingness different of WILL_NEVER, one selects one 2-hop
tuple and creates one entry in the routing table with: tuple and creates one entry in the routing table with:
R_dest_addr = the main address of the two hop neighbor; R_dest_addr = the main address of the 2-hop neighbor;
R_next_addr = the R_next_addr of the entry in the R_next_addr = the R_next_addr of the entry in the
routing table with: routing table with:
R_dest_addr == N_neighbor_main_addr R_dest_addr == N_neighbor_main_addr
of the 2-hop tuple; of the 2-hop tuple;
R_dist = 2; R_dist = 2;
R_iface_addr = the R_iface_addr of the entry in the R_iface_addr = the R_iface_addr of the entry in the
skipping to change at page 54, line 36 skipping to change at page 50, line 36
R_dest_addr = I_iface_addr (of the multiple interface R_dest_addr = I_iface_addr (of the multiple interface
association entry) association entry)
R_next_addr = R_next_addr (of the recorded R_next_addr = R_next_addr (of the recorded
route entry) route entry)
R_dist = R_dist (of the recorded R_dist = R_dist (of the recorded
route entry) route entry)
R_iface_addr = R_iface_addr (of the recorded R_iface_addr = R_iface_addr (of the recorded
route entry). route entry).
11. Node Configuration 11. Node Configuration
This section outlines how a node should be configured, in order to This section outlines how a node should be configured, in order to
operate in an OLSR MANET. operate in an OLSR MANET.
11.1. Address Assignment 11.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
addresses from a defined address sequence, distinct from that being addresses from a defined address sequence, distinct from that being
used in the MANET. used in the MANET.
11.2. Routing Configuration 11.2. Routing Configuration
Any MANET node with associated networks or hosts SHOULD be configured Any MANET node with associated networks or hosts SHOULD be configured
such that it has routes set up to the interfaces with associated such that it has routes set up to the interfaces with associated
skipping to change at page 55, line 35 skipping to change at page 51, line 35
point to point connections to other singular hosts or may connect to point to point connections to other singular hosts or may connect to
separate networks. separate networks.
In order to provide connectivity from the OLSR MANET interface(s) to In order to provide connectivity from the OLSR MANET interface(s) to
these non OLSR interface(s), a node SHOULD be able to inject external these non OLSR interface(s), a node SHOULD be able to inject external
route information to the OLSR MANET. route information to the OLSR MANET.
Injecting routing information from the OLSR MANET to non OLSR Injecting routing information from the OLSR MANET to non OLSR
interfaces is outside the scope of this specification. It should be interfaces is outside the scope of this specification. It should be
clear, however, that the routing information for the OLSR MANET can clear, however, that the routing information for the OLSR MANET can
be extracted from the topology table (see section 4.4) or be extracted from the topology table (see section 4.4) or directly
directly from the routing table of OLSR, and SHOULD be injected onto from the routing table of OLSR, and SHOULD be injected onto the non
the non OLSR interfaces following whatever mechanism (routing OLSR interfaces following whatever mechanism (routing protocol,
protocol, static configuration etc.) is provided on these interfaces. static configuration etc.) is provided on these interfaces.
An example of such a situation could be where a node is equipped with An example of such a situation could be where a node is equipped with
a fixed network (e.g. an Ethernet) connecting to a larger network a fixed network (e.g., an Ethernet) connecting to a larger network as
running, as well as a wireless network interface running OLSR. well as a wireless network interface running OLSR.
Notice that this is a different case from that of "multiple Notice that this is a different case from that of "multiple
interfaces", where all the interfaces are participating in the MANET interfaces", where all the interfaces are participating in the MANET
through running the OLSR protocol. through running the OLSR protocol.
In order to provide this capability of injecting external routing In order to provide this capability of injecting external routing
information into an OLSR MANET, a node with such non-MANET interfaces information into an OLSR MANET, a node with such non-MANET interfaces
periodically issues a Host and Network Association (HNA) message, periodically issues a Host and Network Association (HNA) message,
containing sufficient information for the recipients to construct an containing sufficient information for the recipients to construct an
appropriate routing table. appropriate routing table.
skipping to change at page 56, line 44 skipping to change at page 52, line 42
Netmask Netmask
The netmask, corresponding to the network address immediately The netmask, corresponding to the network address immediately
above. above.
12.2. Host and Network Association Information Base 12.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" (A_gateway_addr, A_network_addr, A_netmask, A_time), where tuples" (A_gateway_addr, A_network_addr, A_netmask, A_time), where
A_gateway_addr is the address of a OLSR interface of the gateway, A_gateway_addr is the address of an OLSR interface of the gateway,
A_network_addr and A_netmask specify the network address and netmask A_network_addr and A_netmask specify the network address and netmask
of a network, reachable through this gateway, and A_time specifies of a network, reachable through this gateway, and A_time specifies
the time at which this tuple expires and hence *MUST* be removed. the time at which this tuple expires and hence *MUST* be removed.
The set of all association tuples in a node is called the The set of all association tuples in a node is called the
"association set". "association set".
It should be noticed, that the HNA-message can be considered as a It should be noticed, that the HNA-message can be considered as a
"generalized version" of the TC-message: the originator of both the "generalized version" of the TC-message: the originator of both the
HNA- and TC-messages announce "reachability" to some other host(s). HNA- and TC-messages announce "reachability" to some other host(s).
skipping to change at page 57, line 47 skipping to change at page 53, line 41
3, in this version of the specification, the message MUST be 3, in this version of the specification, the message MUST be
forwarded according to section 3.4. forwarded according to section 3.4.
12.5. HNA Message Processing 12.5. 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 on the OLSR MANET of the node which originally the main address on the OLSR MANET of the node which originally
issued the HNA-message. issued the HNA-message.
Upon processing a HNA-message, the "validity time" MUST be computed Upon processing a HNA-message, the "validity time" MUST be computed
from the Vtime field of the message header (see section 3.3.2). from the Vtime field of the message header (see section 3.3.2). The
The association base SHOULD then be updated as follows: association base SHOULD then be updated as follows:
1 If the sender interface (NB: not originator) of this message 1 If the sender interface (NB: not originator) of this message
is not in the symmetric 1-hop neighborhood of this node, the is not in the symmetric 1-hop neighborhood of this node, the
message MUST be discarded. message MUST be discarded.
2 Otherwise, for each (network address, netmask) pair in the 2 Otherwise, for each (network address, netmask) pair in the
message: message:
2.1 if an entry in the association set already exists, where: 2.1 if an entry in the association set already exists, where:
A_gateway_addr == originator address A_gateway_addr == originator address
A_network_addr == network address A_network_addr == network address
A_netmask == netmask A_netmask == netmask
then the holding time for that tuple MUST be set to: then the holding time for that tuple MUST be set to:
A_time = current time + validity time A_time = current time + validity time
2.2 otherwise, a new tuple MUST be recorded with: 2.2 otherwise, a new tuple MUST be recorded with:
A_gateway_addr = originator address A_gateway_addr = originator address
A_network_addr = network address A_network_addr = network address
A_netmask = netmask A_netmask = netmask
A_time = current time + validity time A_time = current time + validity time
12.6. Routing Table Calculation 12.6. Routing Table Calculation
In addition to the routing table computation as described in section In addition to the routing table computation as described in section
10, the host and network association set MUST be added as 10, the host and network association set MUST be added as follows:
follows:
For each tuple in the association set, For each tuple in the association set,
1 If there is no entry in the routing table with: 1 If there is no entry in the routing table with:
R_dest_addr == A_network_addr/A_netmask R_dest_addr == A_network_addr/A_netmask
then a new routing entry is created is created. then a new routing entry is created.
2 If a new routing entry was created at the previous step, or 2 If a new routing entry was created at the previous step, or
else if there existed one with: else if there existed one with:
R_dest_addr == A_network_addr/A_netmask R_dest_addr == A_network_addr/A_netmask
R_dist > dist to A_gateway_addr of R_dist > dist to A_gateway_addr of
current association set tuple, current association set tuple,
then the routing entry is modified as follows: then the routing entry is modified as follows:
skipping to change at page 59, line 31 skipping to change at page 55, line 18
R_next_addr and R_iface_addr MUST be set to the same R_next_addr and R_iface_addr MUST be set to the same
values as the tuple from the routing set with R_dest_addr values as the tuple from the routing set with R_dest_addr
== A_gateway_addr. == A_gateway_addr.
12.7. Interoperability Considerations 12.7. Interoperability Considerations
Nodes, which do not implement support for non OLSR interfaces, can Nodes, which do not implement support for non OLSR interfaces, can
coexist in a network with nodes which do implement support for non coexist in a network with nodes which do implement support for non
OLSR interfaces: the generic packet format and message forwarding OLSR interfaces: the generic packet format and message forwarding
(section 3) ensures that HNA messages are correctly (section 3) ensures that HNA messages are correctly forwarded by all
forwarded by all nodes . Nodes which implement support for non OLSR nodes. Nodes which implement support for non OLSR interfaces may
interfaces may thus transmit and process HNA messages according to thus transmit and process HNA messages according to this section.
this section.
Nodes, which do not implement support for non OLSR interfaces can not Nodes, which do not implement support for non OLSR interfaces can not
take advantage of the functionality specified in this section, take advantage of the functionality specified in this section,
however will forward HNA messages correctly, as specified in section however they will forward HNA messages correctly, as specified in
3. section 3.
13. Link Layer Notification 13. 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 from the link layer. However, if information from the link-layer
describing link breakage is available, a node MAY use this as describing link breakage is available, a node MAY use this as
described in this section. 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 nodes is available (i.e., loss of connectivity such as through
absence of a link layer acknowledgment), this information is used in absence of a link layer acknowledgment), this information is used in
addition to the information from the HELLO-messages to maintain the addition to the information from the HELLO-messages to maintain the
neighbor information base and the MPR selector set. neighbor information base and the MPR selector set.
Thus, upon receiving a link-layer notification that the link between Thus, upon receiving a link-layer notification that the link between
a node and a neighbor interface is broken, the following actions are a node and a neighbor interface is broken, the following actions are
taken with respect to link sensing: taken with respect to link sensing:
Each link tuple in the local link set SHOULD, in addition to what is Each link tuple in the local link set SHOULD, in addition to what is
described in section 4.2, include a L_LOST_LINK_time field. described in section 4.2, include a L_LOST_LINK_time field.
L_LOST_LINK_time is a timer for declaring a link as lost when an L_LOST_LINK_time is a timer for declaring a link as lost when an
established link becomes pending. (Notice, that this is a subset of established link becomes pending. (Notice, that this is a subset of
what is recommended in section 14, thus link hysteresis what is recommended in section 14, thus link hysteresis and link
and link layer notifications can coexist). layer notifications can coexist).
HELLO message generation should consider those new fields as follows: HELLO message generation should consider those new fields as follows:
1 if L_LOST_LINK_time is not expired, the link is advertised 1 if L_LOST_LINK_time is not expired, the link is advertised
with a link type of LOST_LINK. In addition, it is not with a link type of LOST_LINK. In addition, it is not
considered as a symmetrical link in the updates of the considered as a symmetric link in the updates of the
associated neighbor tuple (see section 8.1). associated neighbor tuple (see section 8.1).
2 if the link to a neighboring symmetric or asymmetric interface 2 if the link to a neighboring symmetric or asymmetric interface
is broken, the corresponding link tuple is modified: is broken, the corresponding link tuple is modified:
L_LOST_LINK_time and L_time are set to current time + L_LOST_LINK_time and L_time are set to current time +
NEIGHB_HOLD_TIME. NEIGHB_HOLD_TIME.
3 this is considered as a link loss and the appropriate 3 this is considered as a link loss and the appropriate
processing described in section 8.5 should be processing described in section 8.5 should be
performed. performed.
skipping to change at page 61, line 11 skipping to change at page 56, line 42
packet loss. This implies that link sensing should be robust against packet loss. This implies that link sensing should be robust against
bursty loss or transient connectivity between nodes. Hence, to bursty loss or transient connectivity between nodes. Hence, to
enhance the robustness of the link sensing mechanism, the following enhance the robustness of the link sensing mechanism, the following
implementation recommendations SHOULD be considered. implementation recommendations SHOULD be considered.
14.1. Local Link Set 14.1. Local Link Set
Each link tuple in the local link set SHOULD, in addition to what is Each link tuple in the local link set SHOULD, in addition to what is
described in section 4.2, include a L_link_pending field, a described in section 4.2, include a L_link_pending field, a
L_link_quality field, and a L_LOST_LINK_time field. L_link_pending L_link_quality field, and a L_LOST_LINK_time field. L_link_pending
is a boolean value specifying if the link is considered pending (i.e. is a boolean value specifying if the link is considered pending
the link is not considered established). L_link_quality is a (i.e., the link is not considered established). L_link_quality is a
dimensionless number between 0 and 1 describing the quality of the dimensionless number between 0 and 1 describing the quality of the
link. L_LOST_LINK_time is a timer for declaring a link as lost when link. L_LOST_LINK_time is a timer for declaring a link as lost when
an established link becomes pending. an established link becomes pending.
14.2. Hello Message Generation 14.2. Hello Message Generation
HELLO message generation should consider those new fields as follows: HELLO message generation should consider those new fields as follows:
1 if L_LOST_LINK_time is not expired, the link is advertised 1 if L_LOST_LINK_time is not expired, the link is advertised
with a link type of LOST_LINK. with a link type of LOST_LINK.
skipping to change at page 61, line 40 skipping to change at page 57, line 28
A node considers that it has a symmetric link for each link tuple A node considers that it has a symmetric link for each link tuple
where: where:
1 L_LOST_LINK_time is expired, AND 1 L_LOST_LINK_time is expired, AND
2 L_link_pending is "false", AND 2 L_link_pending is "false", AND
3 L_SYM_time is not expired. 3 L_SYM_time is not expired.
This definition for "symmetric link" SHOULD be used the updates of This definition for "symmetric link" SHOULD be used in updating the
the associated neighbor tuple (see section 8.1) for computing associated neighbor tuple (see section 8.1) for computing the
the N_status of a neighbor node. This definition SHOULD thereby also N_status of a neighbor node. This definition SHOULD thereby also be
be used as basis for the symmetric neighborhood when computing the used as basis for the symmetric neighborhood when computing the MPR
MPR set, as well as for "the symmetric neighbors" in the first steps set, as well as for "the symmetric neighbors" in the first steps of
of the routing table calculation. the routing table calculation.
Apart from the above, what has been described previously does not Apart from the above, what has been described previously does not
interfere with the advanced link sensing fields in the link tuples. interfere with the advanced link sensing fields in the link tuples.
The L_link_quality, L_link_pending and L_LOST_LINK_time fields are The L_link_quality, L_link_pending and L_LOST_LINK_time fields are
exclusively updated according to the present section. This section exclusively updated according to the present section. This section
does not modify the function of any other fields in the link tuples. does not modify the function of any other fields in the link tuples.
14.3. Hysteresis Strategy 14.3. Hysteresis Strategy
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 "validity time". The following would contain a bad link for at least "validity time". The following
hysteresis strategy SHOULD be adopted to counter this situation. hysteresis strategy SHOULD be adopted to counter this situation.
For each neighbor interface NI heard by interface I, the For each neighbor interface NI heard by interface I, the
L_link_quality field of the corresponding Link Tuple determines the L_link_quality field of the corresponding Link Tuple determines the
establishment of the link. The value of L_link_quality is compared establishment of the link. The value of L_link_quality is compared
to two thresholds HYST_THRESHOLD_HIGH, HYST_THRESHOLD_LOW, fixed to two thresholds HYST_THRESHOLD_HIGH, HYST_THRESHOLD_LOW, fixed
between 0 and 1 and such that HYST_THRESHOLD_HIGH >= between 0 and 1 and such that HYST_THRESHOLD_HIGH >=
HYST_THRESHOLD_LOW. HYST_THRESHOLD_LOW.
skipping to change at page 63, line 9 skipping to change at page 58, line 37
L_link_pending and L_LOST_LINK_time remain unchanged. L_link_pending and L_LOST_LINK_time remain unchanged.
The condition for considering a link established is thus stricter The condition for considering a link established is thus stricter
than the condition for dropping a link. Notice thus, that a link can than the condition for dropping a link. Notice thus, that a link can
be dropped based on either timer expiration (as described in section be dropped based on either timer expiration (as described in section
7) or on L_link_quality dropping below HYST_THRESHOLD_LOW. 7) or on L_link_quality dropping below HYST_THRESHOLD_LOW.
Also notice, that even if a link is not considered as established by Also notice, that even if a link is not considered as established by
the link hysteresis, the link tuples are still updated for each the link hysteresis, the link tuples are still updated for each
received HELLO message (as described in section 7). received HELLO message (as described in section 7). Specifically,
Specifically, this implies that, regardless of whether or not the this implies that, regardless of whether or not the link hysteresis
link hysteresis considers a link as "established", tuples in the link considers a link as "established", tuples in the link set do not
set do not expire except as determined by the L_time field of the expire except as determined by the L_time field of the link tuples.
link tuples.
As a basic implementation requirement, an estimation of the link As a basic implementation requirement, an estimation of the link
quality must be maintained and stored in the L_link_quality field. quality must be maintained and stored in the L_link_quality field.
If some measure of the signal/noise level on a received message is If some measure of the signal/noise level on a received message is
available (e.g. as a link layer notification), then it can be used available (e.g., as a link layer notification), then it can be used
as estimation after normalization. as estimation after normalization.
If no signal/noise information or other link quality information is If no signal/noise information or other link quality information is
available from the link layer, an algorithm such as the following can available from the link layer, an algorithm such as the following can
be utilized (it is an exponentially smoothed moving average of the be utilized (it is an exponentially smoothed moving average of the
transmission success rate). The algorithm is parameterized by a transmission success rate). The algorithm is parameterized by a
scaling parameter HYST_SCALING which is a number fixed between 0 and scaling parameter HYST_SCALING which is a number fixed between 0 and
1. For each neighbor interface NI heard by interface I, the first 1. For each neighbor interface NI heard by interface I, the first
time NI is heard by I, L_link_quality is set to HYST_SCALING time NI is heard by I, L_link_quality is set to HYST_SCALING
(L_link_pending is set to true and L_LOST_LINK_time to current time - (L_link_pending is set to true and L_LOST_LINK_time to current time -
skipping to change at page 64, line 9 skipping to change at page 59, line 33
silence" from a node. A "long period of silence may be detected silence" from a node. A "long period of silence may be detected
thus: if no OLSR packet has been received on interface I from thus: if no OLSR packet has been received on interface I from
interface NI during HELLO emission interval of interface NI (computed interface NI during HELLO emission interval of interface NI (computed
from the Htime field in the last HELLO message received from NI), a from the Htime field in the last HELLO message received from NI), a
loss of an OLSR packet is detected. loss of an OLSR packet is detected.
14.4. Interoperability Considerations 14.4. Interoperability Considerations
Link hysteresis determines, for a node, the criteria at which a link Link hysteresis determines, for a node, the criteria at which a link
to a neighbor node is accepted or rejected. Nodes in a network may to a neighbor node is accepted or rejected. Nodes in a network may
have different criteria, according to e.g. the nature of the media have different criteria, according to the nature of the media over
over which they are communicating. Once a link is accepted, it is which they are communicating. Once a link is accepted, it is
advertised, in accordance with the provisions described in the advertised, in accordance with the provisions described in the
previous sections of this specification. previous sections of this specification.
15. Redundant Topology Information 15. Redundant Topology Information
In order to provide redundancy to topology information base, the In order to provide redundancy to topology information base, the
advertised link set of a node MAY contain links to neighbor nodes advertised link set of a node MAY contain links to neighbor nodes
which are not in MPR selector set of the node. The advertised link which are not in MPR selector set of the node. The advertised link
set MAY contain links to the whole neighbor set of the node. The set MAY contain links to the whole neighbor set of the node. The
minimal set of links that any node MUST advertise in its TC messages minimal set of links that any node MUST advertise in its TC messages
is the links to the nodes MPR selectors. The advertised link set can is the links to its MPR selectors. The advertised link set can be
be built according to the following rule based on a local parameter built according to the following rule based on a local parameter
called TC_REDUNDANCY parameter. called TC_REDUNDANCY parameter.
15.1. TC_REDUNDANCY Parameter 15.1. TC_REDUNDANCY Parameter
The parameter TC_REDUNDANCY specifies, for the local node, the amount The parameter TC_REDUNDANCY specifies, for the local node, the amount
of information that MAY be included in the TC messages. The of information that MAY be included in the TC messages. The
parameter SHOULD be interpreted as follows: parameter SHOULD be interpreted as follows:
- if the TC_REDUNDANCY parameter of the node is 0, then the - if the TC_REDUNDANCY parameter of the node is 0, then the
advertised link set of the node set is limited to the MPR advertised link set of the node is limited to the MPR
selector set (as described in section 8.3), selector set (as described in section 8.3),
- if the TC_REDUNDANCY parameter of the node is 1, then the - if the TC_REDUNDANCY parameter of the node is 1, then the
advertised link set of the node is the union of its MPR set advertised link set of the node is the union of its MPR set
and its MPR selector set, and its MPR selector set,
- if the TC_REDUNDANCY parameter of the node is 2, then the - if the TC_REDUNDANCY parameter of the node is 2, then the
advertised link set of the node is the full neighbor link set. advertised link set of the node is the full neighbor link set.
A node with willingness equal to WILL_NEVER SHOULD have TC_REDUNDANCY A node with willingness equal to WILL_NEVER SHOULD have TC_REDUNDANCY
also equal to zero. also equal to zero.
15.2. Interoperability Considerations 15.2. Interoperability Considerations
A TC message is sent by a node in the network to declare a set of A TC message is sent by a node in the network to declare a set of
links, called advertised link set which MUST include at least the links, called advertised link set, which MUST include at least the
links to all nodes of its MPR Selector set, i.e., the neighbors which links to all nodes of its MPR Selector set, i.e., the neighbors which
have selected the sender node as a MPR. This is sufficient have selected the sender node as a MPR. This is sufficient
information to ensure that routes can be computed in accordance with information to ensure that routes can be computed in accordance with
section 10. section 10.
The provisions in this section specifies how additional information The provisions in this section specifies how additional information
may be declared, as specified through a TC_REDUNDANCY parameter. may be declared, as specified through a TC_REDUNDANCY parameter.
TC_REDUNDANCY = 0 implies that the information declared corresponds TC_REDUNDANCY = 0 implies that the information declared corresponds
exactly to the MPR Selector set, identical to section 9. Other exactly to the MPR Selector set, identical to section 9. Other
values of TC_REDUNDANCY specifies additional information to be values of TC_REDUNDANCY specifies additional information to be
declared, i.e. the contents of the MPR Selector set is always declared, i.e., the contents of the MPR Selector set is always
declared. Thus, nodes with different values of TC_REDUNDANCY may declared. Thus, nodes with different values of TC_REDUNDANCY may
coexist in a network: control messages are carried by all nodes in coexist in a network: control messages are carried by all nodes in
accordance with section 3, and all nodes will receive at accordance with section 3, and all nodes will receive at least the
least the link-state information required to construct routes as link-state information required to construct routes as described in
described in section 10. section 10.
16. MPR Redundancy 16. MPR Redundancy
MPR redundancy specifies the ability for a node to select redundant MPR redundancy specifies the ability for a node to select redundant
MPRs. Section 4.5 specifies that a node should select its MPR set to MPRs. Section 4.5 specifies that a node should select its MPR set to
be as small as possible, in order to reduce protocol overhead. The be as small as possible, in order to reduce protocol overhead. The
criteria for selecting MPRs is, that all strict 2-hop nodes must be criteria for selecting MPRs is, that all strict 2-hop nodes must be
reachable through, at least, one MPR node. Redundancy of the MPR set reachable through, at least, one MPR node. Redundancy of the MPR set
affects the overhead through affecting the amount of links being affects the overhead through affecting the amount of links being
advertised, the amount of nodes advertising links and the efficiency advertised, the amount of nodes advertising links and the efficiency
of the MPR flooding mechanism. On the other hand, redundancy in the of the MPR flooding mechanism. On the other hand, redundancy in the
MPR set ensures that reachability for a node is advertised by more MPR set ensures that reachability for a node is advertised by more
nodes, thus additional links are diffused to the network. nodes, thus additional links are diffused to the network.
While, in general, a minimal MPR set provides the least overhead, While, in general, a minimal MPR set provides the least overhead,
there are situations in which overhead can be traded off for other there are situations in which overhead can be traded off for other
benefits. E.g. a node can may decide to increase its MPR coverage benefits. For example, a node may decide to increase its MPR
if it observes many changes in its neighbor information base caused coverage if it observes many changes in its neighbor information base
by mobility, while otherwise keeping a low MPR coverage. caused by mobility, while otherwise keeping a low MPR coverage.
16.1. MPR_COVERAGE Parameter 16.1. MPR_COVERAGE Parameter
The MPR coverage is defined by a single local parameter, The MPR coverage is defined by a single local parameter,
MPR_COVERAGE, specifying by how many MPR nodes any strict 2-hop node MPR_COVERAGE, specifying by how many MPR nodes any strict 2-hop node
should be covered. MPR_COVERAGE=1 specifies that the overhead of the should be covered. MPR_COVERAGE=1 specifies that the overhead of the
protocol is kept at a minimum and causes the MPR selection to operate protocol is kept at a minimum and causes the MPR selection to operate
as described in section 8.3.1. MPR_COVERAGE=m ensures that, as described in section 8.3.1. MPR_COVERAGE=m ensures that, if
if possible, a node selects its MPR set such that all strict 2-hop possible, a node selects its MPR set such that all strict 2-hop nodes
nodes for an interface are reachable through at least m MPR nodes on for an interface are reachable through at least m MPR nodes on that
that interface. MPR_COVERAGE can assume any integer value > 0. The interface. MPR_COVERAGE can assume any integer value > 0. The
heuristic MUST be applied per interface, I. The MPR set for a node heuristic MUST be applied per interface, I. The MPR set for a node
is the union of the MPR sets found for each interface. is the union of the MPR sets found for each interface.
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. I.e. nodes in a network may operate consistency of the protocol. For example, nodes in a network may
with different values of MPR_COVERAGE. operate with different values of MPR_COVERAGE.
16.2. MPR Computation 16.2. MPR Computation
Using MPR coverage, the MPR selection heuristics is extended from Using MPR coverage, the MPR selection heuristics is extended from
that described in the section 8.3.1 by one definition: that described in the section 8.3.1 by one definition:
Poorly covered node: Poorly covered node:
A poorly covered node is a node in N2 which is covered by less A poorly covered node is a node in N2 which is covered by less
than MPR_COVERAGE nodes in N. than MPR_COVERAGE nodes in N.
skipping to change at page 66, line 41 skipping to change at page 62, line 12
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
nodes in N2. The nodes are then removed from N2 for the rest nodes in N2. The nodes are then removed from N2 for the rest
of the computation. of the computation.
4 While there exist nodes 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 reachability, i.e. the 4.1 For each node in N, calculate the reachability, i.e.,
number of nodes in N2 which are not yet covered by at the number of nodes in N2 which are not yet covered
least MPR_COVERAGE nodes in the MPR set, and which are by at least MPR_COVERAGE nodes in the MPR set, and
reachable through this one hop neighbor; which are reachable through this 1-hop neighbor;
4.2 Select as a MPR the node with highest willingness among 4.2 Select as a MPR the node with highest willingness among
the nodes in N with non-zero reachability. In case of the nodes in N with non-zero reachability. In case of
multiple choice select the node which provides multiple choice select the node which provides
reachability to the maximum number of nodes in N2. In reachability to the maximum number of nodes in N2. In
case of multiple nodes providing the same amount of case of multiple nodes providing the same amount of
reachability, select the node as MPR whose D(y) is reachability, select the node as MPR whose D(y) is
greater. Remove the nodes from N2 which are now covered greater. Remove the nodes from N2 which are now covered
by MPR_COVERAGE nodes in the MPR set. by MPR_COVERAGE nodes in the MPR set.
skipping to change at page 67, line 21 skipping to change at page 62, line 39
nodes in N2 are still covered by at least MPR_COVERAGE nodes nodes in N2 are still covered by at least MPR_COVERAGE nodes
in the MPR set excluding node y, and if N_willingness of node in the MPR set excluding node y, and if N_willingness of node
y is smaller than WILL_ALWAYS, then node y MAY be removed from y is smaller than WILL_ALWAYS, then node y MAY be removed from
the MPR set. 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.
16.3. Interoperability Considerations 16.3. Interoperability Considerations
The MPR set of a node MUST, according to section 8.3, be The MPR set of a node MUST, according to section 8.3, be calculated
calculated by a node in such a way that it, through the neighbors in by a node in such a way that it, through the neighbors in the MPR-
the MPR-set, can reach all symmetric strict 2-hop neighbors. This is set, can reach all symmetric strict 2-hop neighbors. This is
achieved by the heuristics in this section, for all values of achieved by the heuristics in this section, for all values of
MPR_COVERAGE > 0. MPR_COVERAGE is a local parameter for each node. MPR_COVERAGE > 0. MPR_COVERAGE is a local parameter for each node.
Setting this parameter affects only the amount of redundancy in part Setting this parameter affects only the amount of redundancy in part
of the network. of the network.
Notice that for MPR_COVERAGE=1, the heuristics in this section is Notice that for MPR_COVERAGE=1, the heuristics in this section is
identical to the heuristics specified in the section 8.3.1. identical to the heuristics specified in the section 8.3.1.
Nodes with different values of MPR_COVERAGE may coexist in a network: Nodes with different values of MPR_COVERAGE may coexist in a network:
control messages are carried by all nodes in accordance with section control messages are carried by all nodes in accordance with section
3, and all nodes will receive at least the link-state 3, and all nodes will receive at least the link-state information
information required to construct routes as described in sections required to construct routes as described in sections 9 and 10.
#REF:td and 10.
17. IPv6 Considerations 17. 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 OLSR for IP version 4 are the same as those used by OLSR for IP
version 6. To operate with IP version 6, the only required change is version 6. To operate with IP version 6, the only required change is
to replace the IPv4 addresses with IPv6 address. The minimum packet to replace the IPv4 addresses with IPv6 address. The minimum packet
and message sizes (under which there is rejection) should be adjusted and message sizes (under which there is rejection) should be adjusted
accordingly, considering the greater size of IPv6 addresses. accordingly, considering the greater size of IPv6 addresses.
skipping to change at page 68, line 17 skipping to change at page 63, line 31
This section list the values for the constants used in the This section list the values for the constants used in the
description of the protocol. description of the protocol.
18.1. Setting emission intervals and holding times 18.1. Setting emission intervals and holding times
The proposed constant for C is the following: The proposed constant for C is the following:
C = 1/16 seconds (equal to 0.0625 seconds) C = 1/16 seconds (equal to 0.0625 seconds)
C is a scaling factor for the "validity time" calculation ("Vtime" C is a scaling factor for the "validity time" calculation ("Vtime"
and "Htime" fields in message headers, see section 18.3). and "Htime" fields in message headers, see section 18.3). The
The "validity time" advertisement is designed such that nodes in a "validity time" advertisement is designed such that nodes in a
network may have different and individually tuneable emission network may have different and individually tuneable emission
intervals, while still interoperate fully. For protocol functioning intervals, while still interoperate fully. For protocol functioning
and interoperability to work: and interoperability to work:
- the advertised holding time MUST always be greater than the - the advertised holding time MUST always be greater than the
refresh interval of the advertised information. Moreover, it refresh interval of the advertised information. Moreover, it
is recommended that the relation between the interval (from is recommended that the relation between the interval (from
section 18.2), and the hold time is kept as specified section 18.2), and the hold time is kept as specified
in section 18.3, to allow for reasonable packet loss. in section 18.3, to allow for reasonable packet loss.
skipping to change at page 69, line 24 skipping to change at page 64, line 33
NEIGHB_HOLD_TIME = 3 x REFRESH_INTERVAL NEIGHB_HOLD_TIME = 3 x REFRESH_INTERVAL
TOP_HOLD_TIME = 3 x TC_INTERVAL TOP_HOLD_TIME = 3 x TC_INTERVAL
DUP_HOLD_TIME = 30 seconds DUP_HOLD_TIME = 30 seconds
MID_HOLD_TIME = 3 x MID_INTERVAL MID_HOLD_TIME = 3 x MID_INTERVAL
HNA_HOLD_TIME = 3 x HNA_INTERVAL HNA_HOLD_TIME = 3 x HNA_INTERVAL
The Vtime in the message header (see section 3.3.2), and the The Vtime in the message header (see section 3.3.2), and the Htime in
Htime in the HELLO message (see section 6.1) are the the HELLO message (see section 6.1) are the fields which hold
fields which hold information about the above values in mantissa and information about the above values in mantissa and exponent format
exponent format (rounded up). In other words: (rounded up). In other words:
value = C*(1+a/16)*2^b [in seconds] value = C*(1+a/16)*2^b [in seconds]
where a is the integer represented by the four highest bits of the where a is the integer represented by the four highest bits of the
field and b the integer represented by the four lowest bits of the field and b the integer represented by the four lowest bits of the
field. field.
Notice, that for the previous proposed value of C, (1/16 seconds), Notice, that for the previous proposed value of C, (1/16 seconds),
the values, in seconds, expressed by the formula above can be stored, the values, in seconds, expressed by the formula above can be stored,
without loss of precision, in binary fixed point or floating point without loss of precision, in binary fixed point or floating point
skipping to change at page 71, line 26 skipping to change at page 66, line 29
WILL_DEFAULT = 3 WILL_DEFAULT = 3
WILL_HIGH = 6 WILL_HIGH = 6
WILL_ALWAYS = 7 WILL_ALWAYS = 7
The willingness of a node may be set to any integer value from 0 to The willingness of a node may be set to any integer value from 0 to
7, and specifies how willing a node is to be forwarding traffic on 7, and specifies how willing a node is to be forwarding traffic on
behalf of other nodes. Nodes will, by default, have a willingness behalf of other nodes. Nodes will, by default, have a willingness
WILL_DEFAULT. WILL_NEVER indicates a node which does not wish to WILL_DEFAULT. WILL_NEVER indicates a node which does not wish to
carry traffic for other nodes, e.g. due to resource constraints carry traffic for other nodes, for example due to resource
(e.g. low on battery). WILL_ALWAYS indicates that a node always constraints (like being low on battery). WILL_ALWAYS indicates that
should be selected to carry traffic on behalf of other nodes, e.g. a node always should be selected to carry traffic on behalf of other
due to resource abundance (e.g. permanent power supply, high nodes, for example due to resource abundance (like permanent power
capacity interfaces to other nodes). supply, high capacity interfaces to other nodes).
A node may dynamically change its willingness as its conditions A node may dynamically change its willingness as its conditions
change. change.
One possible application would, for example, be for a node, connected One possible application would, for example, be for a node, connected
to a permanent power supply and with fully charged batteries, to to a permanent power supply and with fully charged batteries, to
advertise a willingness of WILL_ALWAYS. Upon being disconnected from advertise a willingness of WILL_ALWAYS. Upon being disconnected from
the permanent power supply (e.g. a PDA being taken out of its the permanent power supply (e.g., a PDA being taken out of its
charging cradle), a willingness of WILL_DEFAULT is advertised. As charging cradle), a willingness of WILL_DEFAULT is advertised. As
battery capacity is drained, the willingness would be further battery capacity is drained, the willingness would be further
reduced. First to the intermediate value between WILL_DEFAULT and reduced. First to the intermediate value between WILL_DEFAULT and
WILL_LOW, then to WILL_LOW and finally to WILL_NEVER, when the WILL_LOW, then to WILL_LOW and finally to WILL_NEVER, when the
battery capacity of the node does no longer support carrying foreign battery capacity of the node does no longer support carrying foreign
traffic. traffic.
18.9. Misc. Constants 18.9. Misc. Constants
TC_REDUNDANCY = 0 TC_REDUNDANCY = 0
MPR COVERAGE = 1 MPR COVERAGE = 1
MAXJITTER = HELLO_INTERVAL / 4 MAXJITTER = HELLO_INTERVAL / 4
19. Sequence Numbers 19. 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 "old" information, i.e., messages received out of order. However
with a limited number of bits for representing sequence numbers, with a limited number of bits for representing sequence numbers,
wrap-around (that the sequence number is incremented from the maximum wrap-around (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.
The sequence number S1 is said to be "greater than" the sequence The sequence number S1 is said to be "greater than" the sequence
number S2 iff: number S2 if:
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 Thus when comparing two messages, it is possible - even in the
presence of wrap-around - to determine which message contains the presence of wrap-around - to determine which message contains the
most recent information. most recent information.
20. Security Considerations 20. Security Considerations
Currently, OLSR does does not specify any special security measures. Currently, OLSR does not specify any special security measures. As a
As a proactive routing protocol, OLSR makes a target for various proactive routing protocol, OLSR makes a target for various attacks.
attacks. The various possible vulnerability are discussed in this The various possible vulnerabilities are discussed in this section.
section.
20.1. Confidentiality 20.1. Confidentiality
Being a proactive protocol, OLSR periodically diffuses topological Being a proactive protocol, OLSR periodically diffuses topological
information. Hence, if used in an unprotected wireless network, the information. Hence, if used in an unprotected wireless network, the
network topology is revealed to anyone who listens to OLSR control network topology is revealed to anyone who listens to OLSR control
messages. messages.
In situations where the confidentiality of the network topology is of In situations where the confidentiality of the network topology is of
importance, regular cryptographic techniques such as exchange of OLSR importance, regular cryptographic techniques such as exchange of OLSR
control traffic messages encrypted by pgp [9] or by encrypted by some control traffic messages encrypted by PGP [9] or encrypted by some
shared secret key can be applied to ensure that control traffic can shared secret key can be applied to ensure that control traffic can
be read and interpreted by only those authorized to do so. be read and interpreted by only those authorized to do so.
20.2. Integrity 20.2. Integrity
In OLSR, each node is injecting topological information into the In OLSR, each node is injecting topological information into the
network through transmitting HELLO messages and, for some nodes, TC network through transmitting HELLO messages and, for some nodes, TC
messages. If some nodes for some reason, malicious or malfunction, messages. If some nodes for some reason, malicious or malfunction,
inject invalid control traffic, network integrity may be compromised. inject invalid control traffic, network integrity may be compromised.
Therefore, message authentication is recommended. Therefore, message authentication is recommended.
skipping to change at page 74, line 8 skipping to change at page 69, line 5
another node. another node.
Authentication of the originator node for control messages (for Authentication of the originator node for control messages (for
situation 2, 4 and 5) and on the individual links announced in the situation 2, 4 and 5) and on the individual links announced in the
control messages (for situation 1 and 3) may be used as a control messages (for situation 1 and 3) may be used as a
countermeasure. However to prevent nodes from repeating old (and countermeasure. However to prevent nodes from repeating old (and
correctly authenticated) information (situation 9) temporal correctly authenticated) information (situation 9) temporal
information is required, allowing a node to positively identify such information is required, allowing a node to positively identify such
delayed messages. delayed messages.
Signatures and other required security information may be transmitted In general, digital signatures and other required security
as a separate OLSR message type, thereby allowing that "secured" and information may be transmitted as a separate OLSR message type,
"unsecured" nodes can coexist in the same network, if desired. thereby allowing that "secured" and "unsecured" nodes can coexist in
the same network, if desired.
Specifically, the authenticity of entire OLSR control messages can be
established through employing IPsec authentication headers, whereas
authenticity of individual links (situation 1 and 3) require
additional security information to be distributed.
An important consideration is, that all control messages in OLSR are An important consideration is, that all control messages in OLSR are
transmitted either to all nodes in the neighborhood (HELLO messages) transmitted either to all nodes in the neighborhood (HELLO messages)
or broadcast to all nodes in the network (e.g. TC messages). I.e. or broadcast to all nodes in the network (e.g., TC messages).
a control message in OLSR is always a point-to-multipoint
transmission. It is therefore important that the authentication For example, a control message in OLSR is always a point-to-
mechanism employed permits that any receiving node can validate the multipoint transmission. It is therefore important that the
authenticity of a message. As an analogy, given a block of text, authentication mechanism employed permits that any receiving node can
signed by a PGP private key, then anyone with the corresponding validate the authenticity of a message. As an analogy, given a block
public key can verify the authenticiy of the text. of text, signed by a PGP private key, then anyone with the
corresponding public key can verify the authenticity of the text.
20.3. Interaction with External Routing Domains 20.3. Interaction with External Routing Domains
OLSR does, through the HNA messages specified in section 12, OLSR does, through the HNA messages specified in section 12, provide
provide a basic mechanism for injecting external routing information a basic mechanism for injecting external routing information to the
to the OLSR domain. Section 12 also specifies that routing OLSR domain. Section 12 also specifies that routing information can
information can be extracted from the topology table or the routing be extracted from the topology table or the routing table of OLSR
table of OLSR and, potentially, injected into an external domain if and, potentially, injected into an external domain if the routing
the routing protocol governing that domain permits. protocol governing that domain permits.
Other than as described in the section 20.2, when operating Other than as described in the section 20.2, when operating nodes,
nodes, connecting OLSR to an external routing domain, care MUST be connecting OLSR to an external routing domain, care MUST be taken not
taken not to allow potentially insecure and un-trustworthy to allow potentially insecure and un-trustworthy information to be
information to be injected from the OLSR domain to external routing injected from the OLSR domain to external routing domains. Care MUST
domains. Care MUST be taken to validate the correctness of be taken to validate the correctness of information prior to it being
information prior to it being injected as to avoid polluting routing injected as to avoid polluting routing tables with invalid
tables with invalid information. information.
A recommended way of extending connectivity from an existing routing A recommended way of extending connectivity from an existing routing
domain to an OLSR routed MANET is to assign an IP prefix (under the domain to an OLSR routed MANET is to assign an IP prefix (under the
authority of the nodes/gateways connecting the MANET with the exiting authority of the nodes/gateways connecting the MANET with the exiting
routing domain) exclusively to the OLSR MANET area, and to configure routing domain) exclusively to the OLSR MANET area, and to configure
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 a unique IP address.
no special considerations can be made about the applicability of
IPsec authentication headers or key exchange mechanisms.
21. Flow and congestion control 21. Flow and congestion control
Due to its proactive nature, the OLSR protocol has a natural control Due to its proactive nature, the OLSR protocol has a natural control
over the flow of its control traffic. Nodes transmits control over the flow of its control traffic. Nodes transmits control
message at predetermined rates fixed by predefined refresh intervals. message at predetermined rates fixed by predefined refresh intervals.
Furthermore the MPR optimization greatly saves on control overhead, Furthermore the MPR optimization greatly saves on control overhead,
and this is done on two sides. First, the packets that advertize the and this is done on two sides. First, the packets that advertise the
topology are much shorter since only MPR selectors may be advertized. topology are much shorter since only MPR selectors may be advertised.
Second, the cost of flooding this information is greatly reduced Second, the cost of flooding this information is greatly reduced
since only MPR nodes forward the broadcast packets. In dense since only MPR nodes forward the broadcast packets. In dense
networks, the reduction of control traffic can be of several orders networks, the reduction of control traffic can be of several orders
of magnitude compared to routing protocols using classical flooding of magnitude compared to routing protocols using classical flooding
(such as OSPF) [10]. This feature naturally provides more bandwidth (such as OSPF) [10]. This feature naturally provides more bandwidth
for useful data traffic and pushes further the frontier of for useful data traffic and pushes further the frontier of
congestion. Since the control traffic is continuous and periodic, it congestion. Since the control traffic is continuous and periodic, it
keeps more stable the quality of the links used in routing, where keeps more stable the quality of the links used in routing, where
reactive protocols, with bursty floodings for route discoveries and reactive protocols, with bursty floodings for route discoveries and
repairs, may damage the link qualities for short times by causing repairs, may damage the link qualities for short times by causing
numerous collisions on those links, possibly provoking route repair numerous collisions on those links, possibly provoking route repair
cascades. However, in certain OLSR options, some control messages cascades. However, in certain OLSR options, some control messages
may be intentionnaly sent in advance of their deadline(TC or Hello may be intentionally sent in advance of their deadline(TC or Hello
messages) in order to increase the reactiveness of the protocol messages) in order to increase the reactiveness of the protocol
against topology changes. This may cause a small, temporary and against topology changes. This may cause a small, temporary and
local increase of control traffic. local increase of control traffic.
22. IANA Considerations 22. IANA Considerations
OLSR defines a "Message Type" field for control messages. A new OLSR defines a "Message Type" field for control messages. A new
registry is to be created for the values for this Message Type field, registry has been 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 Additionally, values in the range 128-255 are reserved for
private/local use. private/local use.
23. 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 <chris.dearlove@baesystems.com> for valuable input on the MPR
selection heuristics and for careful reviews of the protocol selection heuristics and for careful reviews of the protocol
specification. specification.
skipping to change at page 76, line 25 skipping to change at page 71, line 23
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 <chris.dearlove@baesystems.com> for valuable input on the MPR
selection heuristics and for careful reviews of the protocol selection heuristics and for careful reviews of the protocol
specification. specification.
24. Contributors 24. Contributors
During the development of this specification, the following list of During the development of this specification, the following list of
people contributed. The contributors are listed alphabetically. people contributed. The contributors are listed alphabetically.
Cedric Adjih, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le Cedric Adjih
Chesnay Cedex, France, Phone: +33 1 3963 5215, Email: Project HIPERCOM
Cedric.Adjih@inria.fr INRIA Rocquencourt, BP 105
78153 Le Chesnay Cedex, France
Thomas Heide Clausen, Project HIPERCOM, INRIA Rocquencourt, BP 105, Phone: +33 1 3963 5215
78153 Le Chesnay Cedex, France, Phone: +33 1 3963 5133, Email: EMail: Cedric.Adjih@inria.fr
Thomas.Clausen@inria.fr
Philippe Jacquet, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Thomas Heide Clausen
Le Chesnay Cedex, France, Phone: +33 1 3963 5263, Email: Project HIPERCOM
Philippe.Jacquet@inria.fr INRIA Rocquencourt, BP 105
78153 Le Chesnay Cedex, France
Anis Laouiti, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le Phone: +33 1 3963 5133
Chesnay Cedex, France, Phone: +33 1 3963 508832, Email: EMail: T.Clausen@computer.org
Anis.Laouiti@inria.fr
Pascale Minet, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le Philippe Jacquet
Chesnay Cedex, France, Phone: +33 1 3963 508832, Email: Project HIPERCOM
Pascale.Minet@inria.fr INRIA Rocquencourt, BP 105
Paul Muhlethaler, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 78153 Le Chesnay Cedex, France
Le Chesnay Cedex, France, Phone: +33 1 3963 5278, Email:
Paul.Muhlethaler@inria.fr
Amir Qayyum, Center for Advanced Research in Engineering Pvt. Ltd., Phone: +33 1 3963 5263
19, Ataturk Avenue, Islamabad, Pakistan, Phone: +92-51-2874115, EMail: Philippe.Jacquet@inria.fr
Email: amir@carepvtltd.com Anis Laouiti
Project HIPERCOM
INRIA Rocquencourt, BP 105
78153 Le Chesnay Cedex, France
Laurent Viennot, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Phone: +33 1 3963 5088
Le Chesnay Cedex, France, Phone: +33 1 3963 5225, Email: EMail: Anis.Laouiti@inria.fr
Laurent.Viennot@inria.fr
25. Authors' Addresses Pascale Minet
Project HIPERCOM
INRIA Rocquencourt, BP 105
78153 Le Chesnay Cedex, France
Thomas Heide Clausen, Project HIPERCOM, INRIA Rocquencourt, BP 105, Phone: +33 1 3963 5233
78153 Le Chesnay Cedex, France, Phone: +33 1 3963 5133, Email: EMail: Pascale.Minet@inria.fr
Thomas.Clausen@inria.fr
Philippe Jacquet, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Paul Muhlethaler
Le Chesnay Cedex, France, Phone: +33 1 3963 5263, Email: Project HIPERCOM
Philippe.Jacquet@inria.fr INRIA Rocquencourt, BP 105
78153 Le Chesnay Cedex, France
26. References Phone: +33 1 3963 5278
EMail: Paul.Muhlethaler@inria.fr
1. P. Jacquet, P. Minet, P. Muhlethaler, N. Rivierre. Increasing Amir Qayyum
reliability in cable free radio LANs: Low level forwarding in Center for Advanced Research in Engineering Pvt. Ltd.
HIPERLAN. Wireless Personal Communications, 1996 19 Ataturk Avenue
Islamabad, Pakistan
2. A. Qayyum, L. Viennot, A. Laouiti. Multipoint relaying: An Phone: +92-51-2874115
efficient technique for flooding in mobile wireless networks. 35th EMail: amir@carepvtltd.com
Annual Hawaii International Conference on System Sciences
(HICSS'2001).
3. ETSI STC-RES10 Committee. Radio equipment and systems: HIPERLAN Laurent Viennot
type 1, functional specifications ETS 300-652, ETSI, June 1996 Project HIPERCOM
INRIA Rocquencourt, BP 105
78153 Le Chesnay Cedex, France
4. P. Jacquet and L. Viennot, Overhead in Mobile Ad-hoc Network Phone: +33 1 3963 5225
Protocols, INRIA research report RR-3965, 2000 EMail: Laurent.Viennot@inria.fr
5. S. Bradner. Key words for use in RFCs to Indicate Requirement 25. References
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
6. T. Clausen, G. Hansen, L. Christensen and G. Behrmann. The 25.1. Normative References
Optimized Link State Routing Protocol, Evaluation through
Experiments and Simulation. IEEE Symposium on "Wireless Personal
Mobile Communications", September 2001.
7. T. Clausen, P. Jacquet, A. Laouiti, P. Muhlethaler, A. Qayyum [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
and L. Viennot. Optimized Link State Routing Protocol. IEEE Levels", BCP 14, RFC 2119, March 1997.
INMIC Pakistan 2001.
8. T. Narten and H. Alvestrand. Guidelines for Writing an IANA [7] T. Clausen, P. Jacquet, A. Laouiti, P. Muhlethaler, A.
Considerations Section in RFCs. Request for Comments (Best Current Qayyum and L. Viennot. Optimized Link State Routing Protocol.
Practice) 2434, Internet Engineering Task Force, October 1998. IEEE INMIC Pakistan 2001.
9. D. Atkins, W. Stallings and P. Zimmermann, PGP Message Exchange 25.2. Informative References
Formats. Request for Comments (Informational) 1991, August 1996.
10. P. Jacquet, A. Laouiti, P. Minet, L. Viennot. Performance [1] P. Jacquet, P. Minet, P. Muhlethaler, N. Rivierre. Increasing
analysis of OLSR multipoint relay flooding in two ad hoc wireless reliability in cable free radio LANs: Low level forwarding in
network models, INRIA research report RR-4260, 2001. HIPERLAN. Wireless Personal Communications, 1996.
Reference [5] and [7] are normative; all others are informative. [2] A. Qayyum, L. Viennot, A. Laouiti. Multipoint relaying: An
efficient technique for flooding in mobile wireless networks.
35th Annual Hawaii International Conference on System Sciences
(HICSS'2001).
[3] ETSI STC-RES10 Committee. Radio equipment and systems:
HIPERLAN type 1, functional specifications ETS 300-652, ETSI,
June 1996.
[4] P. Jacquet and L. Viennot, Overhead in Mobile Ad-hoc Network
Protocols, INRIA research report RR-3965, 2000.
[6] T. Clausen, G. Hansen, L. Christensen and G. Behrmann. The
Optimized Link State Routing Protocol, Evaluation through
Experiments and Simulation. IEEE Symposium on "Wireless
Personal Mobile Communications", September 2001.
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[9] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message
Exchange Formats", RFC 1991, August 1996.
[10] P. Jacquet, A. Laouiti, P. Minet, L. Viennot. Performance
analysis of OLSR multipoint relay flooding in two ad hoc
wireless network models, INRIA research report RR-4260, 2001.
26. Authors' Addresses
Thomas Heide Clausen
Project HIPERCOM
INRIA Rocquencourt, BP 105
78153 Le Chesnay Cedex, France
Phone: +33 1 3963 5133
EMail: T.Clausen@computer.org
Philippe Jacquet,
Project HIPERCOM,
INRIA Rocquencourt, BP 105
78153 Le Chesnay Cedex, France
Phone: +33 1 3963 5263,
EMail: Philippe.Jacquet@inria.fr
27. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 271 change blocks. 
749 lines changed or deleted 725 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/