draft-ietf-manet-olsrv2-04.txt   draft-ietf-manet-olsrv2-05.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique, France Internet-Draft LIX, Ecole Polytechnique, France
Intended status: Standards Track C. Dearlove Intended status: Standards Track C. Dearlove
Expires: January 10, 2008 BAE Systems Advanced Technology Expires: August 28, 2008 BAE Systems Advanced Technology
Centre Centre
P. Jacquet P. Jacquet
Project Hipercom, INRIA Project Hipercom, INRIA
The OLSRv2 Design Team The OLSRv2 Design Team
MANET Working Group MANET Working Group
July 9, 2007 February 25, 2008
The Optimized Link State Routing Protocol version 2 The Optimized Link State Routing Protocol version 2
draft-ietf-manet-olsrv2-04 draft-ietf-manet-olsrv2-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes version 2 of the Optimized Link State Routing This document describes version 2 of the Optimized Link State Routing
(OLSRv2) protocol for mobile ad hoc networks. The protocol embodies (OLSRv2) protocol for mobile ad hoc networks. The protocol embodies
an optimization of the classical link state algorithm tailored to the an optimization of the classical link state algorithm tailored to the
requirements of a mobile ad hoc network (MANET). requirements of a mobile ad hoc network (MANET).
The key optimization of OLSRv2 is that of multipoint relays, The key optimization of OLSRv2 is that of multipoint relays,
providing an efficient mechanism for network-wide broadcast of link providing an efficient mechanism for network-wide broadcast of link
skipping to change at page 3, line 9 skipping to change at page 3, line 9
the only interaction between OLSRv2 and the IP stack is routing table the only interaction between OLSRv2 and the IP stack is routing table
management. management.
OLSRv2 is particularly suitable for large and dense networks as the OLSRv2 is particularly suitable for large and dense networks as the
technique of MPRs works well in this context. technique of MPRs works well in this context.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 9 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 10
5. Protocol Parameters and Constants . . . . . . . . . . . . . . 11 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 13
5.1. Message Intervals . . . . . . . . . . . . . . . . . . . . 11 5.1. Local History Times . . . . . . . . . . . . . . . . . . . 13
5.2. Advertised Information Validity Times . . . . . . . . . . 12 5.2. Message Intervals . . . . . . . . . . . . . . . . . . . . 13
5.3. Received Message Validity Times . . . . . . . . . . . . . 12 5.3. Advertised Information Validity Times . . . . . . . . . . 14
5.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. Received Message Validity Times . . . . . . . . . . . . . 15
5.5. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 14 5.5. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.6. Willingness . . . . . . . . . . . . . . . . . . . . . . . 14 5.6. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 16
5.7. Parameter Change Constraints . . . . . . . . . . . . . . . 14 5.7. Willingness . . . . . . . . . . . . . . . . . . . . . . . 16
6. Information Repositories . . . . . . . . . . . . . . . . . . . 17 5.8. Parameter Change Constraints . . . . . . . . . . . . . . . 17
6.1. Local Information Base . . . . . . . . . . . . . . . . . . 17 6. Information Bases . . . . . . . . . . . . . . . . . . . . . . 19
6.1.1. Local Attached Network Set . . . . . . . . . . . . . . 17 6.1. Local Information Base . . . . . . . . . . . . . . . . . . 19
6.2. Neighborhood Information Base . . . . . . . . . . . . . . 18 6.1.1. Originator Set . . . . . . . . . . . . . . . . . . . . 20
6.3. Topology Information Base . . . . . . . . . . . . . . . . 18 6.1.2. Local Attached Network Set . . . . . . . . . . . . . . 20
6.3.1. Advertised Neighbor Set . . . . . . . . . . . . . . . 19 6.2. Node Information Base . . . . . . . . . . . . . . . . . . 20
6.3.2. Advertising Remote Node Set . . . . . . . . . . . . . 19 6.3. Topology Information Base . . . . . . . . . . . . . . . . 21
6.3.3. Topology Set . . . . . . . . . . . . . . . . . . . . . 19 6.3.1. Advertised Neighbor Set . . . . . . . . . . . . . . . 21
6.3.4. Attached Network Set . . . . . . . . . . . . . . . . . 20 6.3.2. Advertising Remote Node Set . . . . . . . . . . . . . 21
6.3.5. Routing Set . . . . . . . . . . . . . . . . . . . . . 21 6.3.3. Topology Set . . . . . . . . . . . . . . . . . . . . . 22
6.4. Processing and Forwarding Information Base . . . . . . . . 21 6.3.4. Attached Network Set . . . . . . . . . . . . . . . . . 22
6.4.1. Received Set . . . . . . . . . . . . . . . . . . . . . 21 6.3.5. Routing Set . . . . . . . . . . . . . . . . . . . . . 23
6.4.2. Processed Set . . . . . . . . . . . . . . . . . . . . 22 6.4. Processing and Forwarding Information Base . . . . . . . . 23
6.4.3. Forwarded Set . . . . . . . . . . . . . . . . . . . . 22 6.4.1. Received Set . . . . . . . . . . . . . . . . . . . . . 23
6.4.4. Relay Set . . . . . . . . . . . . . . . . . . . . . . 23 6.4.2. Processed Set . . . . . . . . . . . . . . . . . . . . 24
7. Packet Processing and Message Forwarding . . . . . . . . . . . 24 6.4.3. Forwarded Set . . . . . . . . . . . . . . . . . . . . 24
7.1. Actions when Receiving an OLSRv2 Packet . . . . . . . . . 24 6.4.4. Relay Set . . . . . . . . . . . . . . . . . . . . . . 25
7.2. Actions when Receiving an OLSRv2 Message . . . . . . . . . 24 7. Packet Processing and Message Forwarding . . . . . . . . . . . 26
7.3. Message Considered for Processing . . . . . . . . . . . . 25 7.1. Actions when Receiving an OLSRv2 Packet . . . . . . . . . 26
7.4. Message Considered for Forwarding . . . . . . . . . . . . 26 7.2. Actions when Receiving an OLSRv2 Message . . . . . . . . . 26
8. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 29 7.3. Message Considered for Processing . . . . . . . . . . . . 27
8.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 30 7.4. Message Considered for Forwarding . . . . . . . . . . . . 28
8.1.1. HELLO Message TLVs . . . . . . . . . . . . . . . . . . 30 8. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 31
8.1.2. HELLO Message Address Block TLVs . . . . . . . . . . . 31 8.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 31
8.2. TC Messages . . . . . . . . . . . . . . . . . . . . . . . 31 8.1.1. HELLO Message TLVs . . . . . . . . . . . . . . . . . . 32
8.2.1. TC Message TLVs . . . . . . . . . . . . . . . . . . . 32 8.1.2. HELLO Message Address Block TLVs . . . . . . . . . . . 32
8.2.2. TC Message Address Block TLVs . . . . . . . . . . . . 32 8.2. TC Messages . . . . . . . . . . . . . . . . . . . . . . . 32
9. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 33 8.2.1. TC Message TLVs . . . . . . . . . . . . . . . . . . . 33
9.1. HELLO Message: Transmission . . . . . . . . . . . . . . . 33 8.2.2. TC Message Address Block TLVs . . . . . . . . . . . . 34
10. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 34 9. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 35
10.1. Updating Willingness . . . . . . . . . . . . . . . . . . . 34 9.1. HELLO Message: Transmission . . . . . . . . . . . . . . . 35
10.2. Updating MPR Selectors . . . . . . . . . . . . . . . . . . 34 10. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 36
10.3. Symmetric 1-Hop and 2-Hop Neighborhood Changes . . . . . . 34 10.1. Updating Willingness . . . . . . . . . . . . . . . . . . . 36
11. TC Message Generation . . . . . . . . . . . . . . . . . . . . 36 10.2. Updating MPR Selectors . . . . . . . . . . . . . . . . . . 36
11.1. TC Message: Transmission . . . . . . . . . . . . . . . . . 37 10.3. Symmetric 1-Hop and 2-Hop Neighborhood Changes . . . . . . 36
12. TC Message Processing . . . . . . . . . . . . . . . . . . . . 39 11. TC Message Generation . . . . . . . . . . . . . . . . . . . . 38
12.1. Initial TC Message Processing . . . . . . . . . . . . . . 39 11.1. TC Message: Transmission . . . . . . . . . . . . . . . . . 39
12.1.1. Populating the Advertising Remote Node Set . . . . . . 40 12. TC Message Processing . . . . . . . . . . . . . . . . . . . . 41
12.1.2. Populating the Topology Set . . . . . . . . . . . . . 41 12.1. Initial TC Message Processing . . . . . . . . . . . . . . 41
12.1.3. Populating the Attached Network Set . . . . . . . . . 41 12.1.1. Populating the Advertising Remote Node Set . . . . . . 42
12.2. Completing TC Message Processing . . . . . . . . . . . . . 42 12.1.2. Populating the Topology Set . . . . . . . . . . . . . 43
12.2.1. Purging the Topology Set . . . . . . . . . . . . . . . 42 12.1.3. Populating the Attached Network Set . . . . . . . . . 43
12.2.2. Purging the Attached Network Set . . . . . . . . . . . 42 12.2. Completing TC Message Processing . . . . . . . . . . . . . 44
13. Selecting MPRs . . . . . . . . . . . . . . . . . . . . . . . . 43 12.2.1. Purging the Topology Set . . . . . . . . . . . . . . . 44
14. Populating Derived Sets . . . . . . . . . . . . . . . . . . . 45 12.2.2. Purging the Attached Network Set . . . . . . . . . . . 44
14.1. Populating the Relay Set . . . . . . . . . . . . . . . . . 45 13. Information Base Changes . . . . . . . . . . . . . . . . . . . 45
14.2. Populating the Advertised Neighbor Set . . . . . . . . . . 45 14. Selecting MPRs . . . . . . . . . . . . . . . . . . . . . . . . 46
15. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 46 15. Populating Derived Sets . . . . . . . . . . . . . . . . . . . 48
15.1. Network Topology Graph . . . . . . . . . . . . . . . . . . 46 15.1. Populating the Relay Set . . . . . . . . . . . . . . . . . 48
15.2. Populating the Routing Set . . . . . . . . . . . . . . . . 47 15.2. Populating the Advertised Neighbor Set . . . . . . . . . . 48
15.3. Routing Set Updates . . . . . . . . . . . . . . . . . . . 48 16. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 49
16. Proposed Values for Parameters and Constants . . . . . . . . . 49 16.1. Network Topology Graph . . . . . . . . . . . . . . . . . . 49
16.1. Message Interval Parameters . . . . . . . . . . . . . . . 49 16.2. Populating the Routing Set . . . . . . . . . . . . . . . . 50
16.2. Advertised Information Validity Time Parameters . . . . . 49 16.3. Routing Set Updates . . . . . . . . . . . . . . . . . . . 51
16.3. Received Message Validity Time Parameters . . . . . . . . 49 17. Proposed Values for Parameters and Constants . . . . . . . . . 52
16.4. Jitter Time Parameters . . . . . . . . . . . . . . . . . . 49 17.1. Local History Time Parameters . . . . . . . . . . . . . . 52
16.5. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 49 17.2. Message Interval Parameters . . . . . . . . . . . . . . . 52
16.6. Willingness Parameter and Constants . . . . . . . . . . . 49 17.3. Advertised Information Validity Time Parameters . . . . . 52
17. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . 51 17.4. Received Message Validity Time Parameters . . . . . . . . 52
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 17.5. Jitter Time Parameters . . . . . . . . . . . . . . . . . . 52
18.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 52 17.6. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 52
18.2. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 52 17.7. Willingness Parameter and Constants . . . . . . . . . . . 53
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 18. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . 54
19.1. Normative References . . . . . . . . . . . . . . . . . . . 54 19. Security Considerations . . . . . . . . . . . . . . . . . . . 55
19.2. Informative References . . . . . . . . . . . . . . . . . . 54 19.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 55
Appendix A. Node Configuration . . . . . . . . . . . . . . . . . 56 19.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 55
Appendix B. Example Algorithm for Calculating MPRs . . . . . . . 57 19.3. Interaction with External Routing Domains . . . . . . . . 56
B.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 57 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
B.2. MPR Selection Algorithm for each OLSRv2 Interface . . . . 58 20.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 58
Appendix C. Example Algorithm for Calculating the Routing Set . 59 20.2. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 58
C.1. Add Local Symmetric Links . . . . . . . . . . . . . . . . 59 21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
C.2. Add Remote Symmetric Links . . . . . . . . . . . . . . . . 60 21.1. Normative References . . . . . . . . . . . . . . . . . . . 60
C.3. Add Attached Networks . . . . . . . . . . . . . . . . . . 61 21.2. Informative References . . . . . . . . . . . . . . . . . . 60
Appendix D. Packet and Message Layout . . . . . . . . . . . . . 62 Appendix A. Node Configuration . . . . . . . . . . . . . . . . . 62
Appendix D.1. Packet and Message Options . . . . . . . . . . . . . 62 Appendix B. Example Algorithm for Calculating MPRs . . . . . . . 63
Appendix D.2. Example HELLO Message . . . . . . . . . . . . . . . 64 B.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 63
Appendix D.3. Example TC Message . . . . . . . . . . . . . . . . . 65 B.2. MPR Selection Algorithm for each OLSRv2 Interface . . . . 64
Appendix E. Constraints . . . . . . . . . . . . . . . . . . . . 68 Appendix C. Example Algorithm for Calculating the Routing Set . . 65
Appendix F. Security Considerations . . . . . . . . . . . . . . 72 C.1. Add Local Symmetric Links . . . . . . . . . . . . . . . . 65
Appendix F.1. Confidentiality . . . . . . . . . . . . . . . . . . 72 C.2. Add Remote Symmetric Links . . . . . . . . . . . . . . . . 66
Appendix F.2. Integrity . . . . . . . . . . . . . . . . . . . . . 72 C.3. Add Attached Networks . . . . . . . . . . . . . . . . . . 67
Appendix F.3. Interaction with External Routing Domains . . . . . 73 Appendix D. Example Message Layout . . . . . . . . . . . . . . . 68
Appendix F.4. Node Identity . . . . . . . . . . . . . . . . . . . 74 Appendix E. Constraints . . . . . . . . . . . . . . . . . . . . . 70
Appendix G. Flow and Congestion Control . . . . . . . . . . . . 75 Appendix F. Flow and Congestion Control . . . . . . . . . . . . . 74
Appendix H. Contributors . . . . . . . . . . . . . . . . . . . . 76 Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 75
Appendix I. Acknowledgements . . . . . . . . . . . . . . . . . . 77 Appendix H. Acknowledgements . . . . . . . . . . . . . . . . . . 76
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77
Intellectual Property and Copyright Statements . . . . . . . . . . 79 Intellectual Property and Copyright Statements . . . . . . . . . . 78
1. Introduction 1. Introduction
The Optimized Link State Routing protocol version 2 (OLSRv2) is an The Optimized Link State Routing protocol version 2 (OLSRv2) is an
update to OLSRv1 as published in RFC3626 [8]. Compared to RFC3626, update to OLSRv1 as published in RFC3626 [7]. Compared to RFC3626,
OLSRv2 retains the same basic mechanisms and algorithms, while OLSRv2 retains the same basic mechanisms and algorithms, while
providing a more flexible signaling framework and some simplification providing a more flexible signaling framework and some simplification
of the messages being exchanged. Also, OLSRv2 accommodates both IPv4 of the messages being exchanged. Also, OLSRv2 accommodates either
and IPv6 addresses in a compact manner. IPv4 and IPv6 addresses in a compact manner.
OLSRv2 is developed for mobile ad hoc networks. It operates as a OLSRv2 is developed for mobile ad hoc networks. It operates as a
table driven, proactive protocol, i.e. it exchanges topology table driven, proactive protocol, i.e. it exchanges topology
information with other nodes in the network regularly. Each node information with other nodes in the network regularly. Each node
selects a set of its neighbor nodes as "MultiPoint Relays" (MPRs). selects a set of its neighbor nodes as "MultiPoint Relays" (MPRs).
Control traffic may be diffused through the network using hop by hop Control traffic may be flooded through the network using hop by hop
forwarding; a node only needs to forward control traffic directly forwarding, but where a node only needs to forward control traffic
received from its MPR selectors (nodes which have selected it as an directly received from its MPR selectors (nodes which have selected
MPR). MPRs thus provide an efficient mechanism for diffusing control it as an MPR). This mechanism, denoted "MPR flooding", provides an
traffic by reducing the number of transmissions required. efficient mechanism for global information exchange within the MANET
by reducing the number of 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. A sufficient declaring link state information in the network. A sufficient
requirement for OLSRv2 to provide shortest path routes to all requirement for OLSRv2 to provide shortest (lowest hop count) path
destinations is that nodes declare link state information for their routes to all destinations is that nodes declare link state
MPR selectors, if any. Additional available link state information information for their MPR selectors, if any. Additional available
may be transmitted, e.g. for redundancy. Thus, as well as being used link state information may be transmitted, e.g. for redundancy.
to facilitate efficient flooding, MPRs are also allow the reduction Thus, as well as being used to facilitate MPR flooding, use of MPRs
of the number and size of link state messages. MPRs are also thus allows the reduction of the number and size of link state messages,
used as intermediate nodes in multi-hop route calculations. and MPRs are used as intermediate nodes in multi-hop routes.
A node selects MPRs from among its one hop neighbors connected by A node selects MPRs from among its one hop neighbors connected by
"symmetric", i.e. bi-directional, links. Therefore, selecting routes "symmetric", i.e. bi-directional, links. Therefore, selecting routes
through MPRs automatically avoids the problems associated with data through MPRs automatically avoids the problems associated with data
packet transfer over uni-directional links (such as the problem of packet transfer over uni-directional links (such as the problem of
not getting link layer acknowledgments at each hop, for link layers not getting link layer acknowledgments at each hop, for link layers
employing this technique). employing this technique).
OLSRv2 is developed to work independently from other protocols. OLSRv2 is developed to work independently from other protocols.
(Parts of OLSRv2 have been published separately as [1], [2], [3] and (Parts of OLSRv2 have been published separately as [1], [2], [3] and
[4] for wider use.) Likewise, OLSRv2 makes no assumptions about the [4] for wider use.) Likewise, OLSRv2 makes no assumptions about the
underlying link layer. However, OLSRv2 may use link layer underlying link layer. However, OLSRv2 may use link layer
information and notifications when available and applicable, as information and notifications when available and applicable, as
described in [4]. described in [4].
OLSRv2, as OLSRv1, inherits its concept of forwarding and relaying OLSRv2, as OLSRv1, inherits its concept of forwarding and relaying
from HIPERLAN (a MAC layer protocol) which is standardized by ETSI from HIPERLAN (a MAC layer protocol) which is standardized by ETSI
[10], [11]. [9], [10].
2. Terminology 2. 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].
MANET specific terminology is to be interpreted as described in [1] MANET specific terminology is to be interpreted as described in [1]
and [4]. and [4].
Additionally, this document uses the following terminology: Additionally, this document uses the following terminology:
Node - A MANET router which implements the Optimized Link State Node - A MANET router which implements the Optimized Link State
Routing protocol version 2 as specified in this document. Routing protocol version 2 as specified in this document.
OLSRv2 interface - A MANET interface, running OLSRv2. Willingness - The willingness of a node is a nummerical value
between WILL_NEVER and WILL_ALWAYS (both inclusive), which
represents the nodes willingess to be selected as an MPR. A node
with willingness greater than WILL_NEVER is said to be a "willing
node".
OLSRv2 interface - A MANET interface, running OLSRv2. Note that all
references to MANET interfaces in [4] refer to OLSRv2 interfaces
when using [4] as part of OLSRv2.
Symmetric strict 2-hop neighbor - A symmetric 2-hop neighbor which Symmetric strict 2-hop neighbor - A symmetric 2-hop neighbor which
is not a symmetric 1-hop neighbor and is not a 2-hop neighbor only is not a symmetric 1-hop neighbor and is not a 2-hop neighbor only
through a symmetric 1-hop neighbor with willingness WILL_NEVER. A through a symmetric 1-hop neighbor with willingness WILL_NEVER. A
node Z is a symmetric strict 2-hop neighbor of a node X if it is node Z is a symmetric strict 2-hop neighbor of a node X if it is
not a symmetric 1-hop neighbor of node X and if there is a node Y not a symmetric 1-hop neighbor of node X and if there is a node Y
with willingness not equal to WILL_NEVER and such that there is a with willingness not equal to WILL_NEVER and such that there is a
symmetric link from node X to node Y, and a symmetric link from symmetric link from node X to node Y, and a symmetric link from
node Y to node Z. A node Z is a symmetric strict 2-hop neighbor of node Y to node Z. A node Z is a symmetric strict 2-hop neighbor of
a node X by an OLSRv2 interface I of node X if in addition the a node X by an OLSRv2 interface I of node X if in addition the
skipping to change at page 8, line 5 skipping to change at page 8, line 5
Multipoint relay (MPR) - A node which is selected by its symmetric Multipoint relay (MPR) - A node which is selected by its symmetric
1-hop neighbor, node X, to "re-transmit" all the broadcast 1-hop neighbor, node X, to "re-transmit" all the broadcast
messages that it receives from node X, provided that the message messages that it receives from node X, provided that the message
is not a duplicate, and that the hop limit field of the message is is not a duplicate, and that the hop limit field of the message is
greater than one. greater than one.
MPR selector - A node which has selected its symmetric 1-hop MPR selector - A node which has selected its symmetric 1-hop
neighbor, node X, as one of its MPRs is an MPR selector of node X. neighbor, node X, as one of its MPRs is an MPR selector of node X.
MPR flooding - The optimized global information exchange mechanism,
employed by this protocol, in which a message is relayed by only a
reduced subset of the nodes in the network.
3. Applicability Statement 3. Applicability Statement
OLSRv2 is a proactive routing protocol for mobile ad hoc networks OLSRv2 is a proactive routing protocol for mobile ad hoc networks
(MANETs) [13]. The larger and more dense a network, the more (MANETs) [12]. The larger and more dense a network, the more
optimization can be achieved by using MPRs compared to the classic optimization can be achieved by using MPRs compared to the classic
link state algorithm. OLSRv2 enables hop-by-hop routing, i.e. each link state algorithm. OLSRv2 enables hop-by-hop routing, i.e. each
node using its local information provided by OLSRv2 to route packets. node using its local information provided by OLSRv2 to route packets.
As OLSRv2 continuously maintains routes to all destinations in the As OLSRv2 continuously maintains routes to all destinations in the
network, the protocol is beneficial for traffic patterns where the network, the protocol is beneficial for traffic patterns where the
traffic is random and sporadic between a large subset of nodes, and traffic is random and sporadic between a large subset of nodes, and
where the [source, destination] pairs are changing over time. No where the [source, destination] pairs are changing over time. No
additional control traffic need be generated in this case since additional control traffic need be generated in this case since
routes are maintained for all known destinations at all times. Also, routes are maintained for all known destinations at all times. Also,
skipping to change at page 8, line 43 skipping to change at page 9, line 43
forwarded and delivered correctly even by nodes which do not support forwarded and delivered correctly even by nodes which do not support
that extension. Internal extensibility allows a protocol extension that extension. Internal extensibility allows a protocol extension
to define additional attributes to be carried embedded in the to define additional attributes to be carried embedded in the
standard OLSRv2 control messages detailed in this specification (or standard OLSRv2 control messages detailed in this specification (or
any new message types defined by other protocol extensions) using the any new message types defined by other protocol extensions) using the
TLV mechanism specified in [1], while still allowing nodes not TLV mechanism specified in [1], while still allowing nodes not
supporting that extension to forward messages including the extension supporting that extension to forward messages including the extension
and to process messages ignoring the extension. and to process messages ignoring the extension.
The OLSRv2 neighborhood discovery protocol using HELLO messages is The OLSRv2 neighborhood discovery protocol using HELLO messages is
specified in [4]; note that all references to MANET interfaces in [4] specified in [4]. This neighborhood discovery protocol serves to
refer to OLSRv2 interfaces when using [4] as part of OLSRv2. This ensure that each OLSRv2 node has available continuously updated
neighborhood discovery protocol serves to ensure that each OLSRv2 Information Bases describing the node's 1-hop and symmetric 2-hop
node has available continuously updated information repositories neighbors. This neighborhood discovery protocol, which also uses
describing the node's 1-hop and symmetric 2-hop neighbors. This [1], is extended in this document by the addition of MPR information.
neighborhood discovery protocol, which also uses [1], is extended in
this document by the addition of MPR information. OLSRv2 does not make any assumption about node addresses, other than
that each node is assumed to have at least one unique and routable IP
address for each interface that it has which participates in the
MANET.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
OLSRv2 is a proactive routing protocol for mobile ad hoc networks. OLSRv2 is a proactive routing protocol for mobile ad hoc networks.
The protocol inherits the stability of a link state algorithm and has The protocol inherits the stability of a link state algorithm and has
the advantage of having routes immediately available when needed due the advantage of having routes immediately available when needed due
to its proactive nature. OLSRv2 is an optimization of the classical to its proactive nature. OLSRv2 is an optimization of the classical
link state protocol, tailored for mobile ad hoc networks. The main link state protocol, tailored for mobile ad hoc networks. The main
tailoring and optimizations of OLSRv2 are: tailoring and optimizations of OLSRv2 are:
o periodic, unacknowledged transmission of all control messages; o periodic, unacknowledged transmission of all control messages;
o optimized flooding for global link state information diffusion; o MPR flooding for global link state information declaration;
o partial topology maintenance - each node knows only a subset of o partial topology maintenance - each node knows only a subset of
the links in the network, sufficient for a minimum hop route to the links in the network, sufficient for a minimum hop route to
all destinations. all destinations.
The optimized flooding and partial topology maintenance are based on The MPR flooding and partial topology maintenance are based on the
the concept on MultiPoint Relays (MPRs), selected independently by concept on MultiPoint Relays (MPRs), selected independently by nodes
nodes based on the symmetric 1-hop and 2-hop neighbor information based on the symmetric 1-hop and 2-hop neighbor information
maintained using [4]. maintained using [4].
Using the message exchange format [1] and the neighborhood discovery Using the message exchange format [1] and the neighborhood discovery
protocol [4], OLSRv2 also contains the following main components: protocol [4], OLSRv2 also contains the following main components:
o A TLV, to be included within the HELLO messages of [4], allowing a o A TLV, to be included within the HELLO messages of [4], allowing a
node to signal MPR selection. node to signal MPR selection.
o An optimized flooding mechanism for global information exchange, o The optimized mechanism for global information exchange, denoted
denoted "MPR flooding". "MPR flooding".
o A specification of global signaling, denoted TC (Topology Control) o A specification of global signaling, denoted TC (Topology Control)
messages. TC messages in OLSRv2 serve to: messages. TC messages in OLSRv2 serve to:
* inject link state information into the entire network; * inject link state information into the entire network;
* inject addresses of hosts and networks for which they may serve * inject addresses of hosts and networks for which they may serve
as a gateway into the entire network. as a gateway into the entire network.
TC messages are emitted periodically, thereby allowing nodes to TC messages are emitted periodically, thereby allowing nodes to
continuously track global changes in the network. Incomplete TC continuously track global changes in the network. Incomplete TC
messages may be used to report additions to advertised information messages may be used to report additions to advertised information
without repeating unchanged information. Some TC messages may be without repeating unchanged information. Some TC messages may be
flooded over only part of the network, allowing a node to ensure MPR flooded over only part of the network, allowing a node to
that nearer nodes are kept more up to date than distant nodes. ensure that nearer nodes are kept more up to date than distant
nodes, such as is used in Fisheye State Routing [13] and Fuzzy-
sighted link-state routing [14].
Each node in the network selects a set of MPRs. The MPRs of a node X Each node in the network selects a set of MPRs. The MPRs of a node X
may be any subset of the willing nodes in node X's symmetric 1-hop may be any subset of the willing nodes in node X's symmetric 1-hop
neighborhood such that every node in the symmetric strict 2-hop neighborhood such that every node in the symmetric strict 2-hop
neighborhood of node X has a symmetric link to at least one of node neighborhood of node X has a symmetric link to at least one of node
X's MPRs. The MPRs of a node may thus be said to "cover" the node's X's MPRs. The MPRs of a node may thus be said to "cover" the node's
symmetric strict 2-hop neighborhood. Each node also maintains symmetric strict 2-hop neighborhood. Each node also maintains
information about the set of symmetric 1-hop neighbors that have information about the set of symmetric 1-hop neighbors that have
selected it as MPR, its MPR selectors. selected it as an MPR, its MPR selectors.
Note that as long as the condition above is satisfied, any algorithm As long as the condition above is satisfied, any algorithm selecting
selecting MPRs is acceptable in terms of implementation MPRs is acceptable in terms of implementation interoperability.
interoperability. However if smaller sets of MPRs are selected then However if smaller sets of MPRs are selected then the greater the
the greater the efficiency gains that are possible. Note that [12] efficiency gains that are possible. An analysis and examples of MPR
gives an analysis and example of MPR selection algorithms. selection algorithms is given in [11].
A node may independently determine and advertise its willingness to
be selected as an MPR. A node may advertise that it always should be
selected as an MPR or that it should never be selected as an MPR. In
the latter case, the node will neither relay control messages, nor
will that node be included as an intermediate node in any routing
table calculations. Use of variable willingness is most effective in
dense networks.
In OLSRv2, actual efficiency gains are based on the sizes of each In OLSRv2, actual efficiency gains are based on the sizes of each
node's Relay Set, the set of symmetric 1-hop neighbors for which it node's Relay Set, the set of symmetric 1-hop neighbors for which it
is to relay broadcast traffic, and its Advertised Neighbor Set, the is to relay broadcast traffic, and its Advertised Neighbor Set, the
set of symmetric 1-hop neighbors for which it is to advertise link set of symmetric 1-hop neighbors for which it is to advertise link
state information into the network in TC messages. Each of these state information into the network in TC messages. Each of these
sets MUST contain all MPR selectors, and MAY contain additional sets MUST contain all MPR selectors, and MAY contain additional
nodes. If the Advertised Neighbor Set is empty, TC messages are not nodes. If the Advertised Neighbor Set is empty, TC messages are not
generated by that node, unless needed for gateway reporting, or for a generated by that node, unless needed for gateway reporting, or for a
short period to accelerate the removal of unwanted links. short period to accelerate the removal of unwanted links.
OLSRv2 is designed to work in a completely distributed manner and OLSRv2 is designed to work in a completely distributed manner and
does not depend on any central entity. The protocol does not require does not depend on any central entity. The protocol does not require
reliable transmission of control messages: each node sends control reliable transmission of control messages: each node sends control
messages periodically, and can therefore sustain a reasonable loss of messages periodically, and can therefore sustain a reasonable loss of
some such messages. Such losses may occur frequently in radio some such messages. Such losses may occur frequently in radio
networks due to collisions or other transmission problems. OLSRv2 networks due to collisions or other transmission problems. OLSRv2
may use "jitter", randomized adjustments to message transmission MAY use "jitter", randomized adjustments to message transmission
times, to reduce the incidence of collisions [3]. times, to reduce the incidence of collisions [3].
OLSRv2 does not require sequenced delivery of messages. Each control OLSRv2 does not require sequenced delivery of messages. Each TC
message contains a sequence number which is incremented for each message contains a sequence number which is incremented for each
message. Thus the recipient of a control message can, if required, message. Thus the recipient of a TC message can, if required, easily
easily identify which information is more recent - even if messages identify which information is more recent - even if messages have
have been re-ordered while in transmission. been re-ordered while in transmission.
OLSRv2 does not require any changes to the format of IP packets, any OLSRv2 does not require any changes to the format of IP packets, any
existing IP stack can be used as is: OLSRv2 only interacts with existing IP stack can be used as is: OLSRv2 only interacts with
routing table management. OLSR sends its control messages using UDP. routing table management. OLSR sends its control messages as
described in [1] and [4].
5. Protocol Parameters and Constants 5. Protocol Parameters and Constants
The parameters and constants used in this specification are those The parameters and constants used in this specification are those
defined in [4] plus those defined in this section. The separation in defined in [4] plus those defined in this section. The separation in
[4] into interface parameters, node parameters and constants is also [4] into interface parameters, node parameters and constants is also
used in OLSRv2, however all but one (RX_HOLD_TIME) of the parameters used in OLSRv2, however all but one (RX_HOLD_TIME) of the parameters
added in this section are node parameters. They may be classified added by OLSRv2 are node parameters. They may be classified into the
into the following categories: following categories:
o Local history times
o Message intervals o Message intervals
o Advertised information validity times o Advertised information validity times
o Received message validity times o Received message validity times
o Jitter times o Jitter times
o Hop limits o Hop limits
o Willingness o Willingness
In addition constants for particular cases of a node's willingness to In addition constants for particular cases of a node's willingness to
be an MPR are defined. These parameters and constants are detailed be an MPR are defined. These parameters and constants are detailed
in the following sections. As for the parameters in [4], parameters in the following sections. As for the parameters in [4], parameters
defined in this document may be changed dynamically by a node, and defined in this document may be changed dynamically by a node, and
need not be the same on different nodes. need not be the same on different nodes, or on different interfaces
(for interface parameters).
5.1. Message Intervals 5.1. Local History Times
The following parameter manages the time for which local information
is retained:
O_HOLD_TIME - is used to define the time for which a recently used
and replaced originator address is used to recognise the node's
own messages.
The following constraint applies to this parameter:
o O_HOLD_TIME >= 0
5.2. Message Intervals
The following interface parameters regulate TC message transmissions The following interface parameters regulate TC message transmissions
by a node. TC messages are usually sent periodically, but MAY also by a node. TC messages are usually sent periodically, but MAY also
be sent in response to changes in the node's Advertised Neighbor Set be sent in response to changes in the node's Advertised Neighbor Set
and Local Attached Network Set. With a larger value of parameter and Local Attached Network Set. With a larger value of parameter
TC_INTERVAL, and a smaller value of parameter TC_MIN_INTERVAL, TC TC_INTERVAL, and a smaller value of parameter TC_MIN_INTERVAL, TC
messages may often be transmitted in response to changes in a highly messages may more often be transmitted in response to changes in a
dynamic network. However because a node has no knowledge of, for highly dynamic network. However because a node has no knowledge of,
example, nodes remote to it joining the network, TC messages MUST NOT for example, nodes remote to it joining the network, TC messages MUST
be sent purely responsively. NOT be sent purely responsively.
TC_INTERVAL - is the maximum time between the transmission of two TC_INTERVAL - is the maximum time between the transmission of two
successive TC messages by this node. When no TC messages are sent successive TC messages by this node. When no TC messages are sent
in response to local network changes (by design, or because the in response to local network changes (by design, or because the
local network is not changing) then TC messages SHOULD be sent at local network is not changing) then TC messages SHOULD be sent at
a regular interval TC_INTERVAL, possibly modified by jitter as a regular interval TC_INTERVAL, possibly modified by jitter as
specified in [3]. specified in [3].
TC_MIN_INTERVAL - is the minimum interval between transmission of TC_MIN_INTERVAL - is the minimum interval between transmission of
two successive TC messages by this node. (This minimum interval two successive TC messages by this node. (This minimum interval
MAY be modified by jitter, as defined in [3].) MAY be modified by jitter, as specified in [3].)
The following constraints apply to these parameters: The following constraints apply to these parameters:
o TC_INTERVAL > 0 o TC_INTERVAL > 0
o TC_MIN_INTERVAL >= 0 o TC_MIN_INTERVAL >= 0
o TC_INTERVAL >= TC_MIN_INTERVAL o TC_INTERVAL >= TC_MIN_INTERVAL
o If INTERVAL_TIME TLVs as defined in [2] are included in TC o If INTERVAL_TIME TLVs as defined in [2] are included in TC
messages, then TC_INTERVAL MUST be representable as described in messages, then TC_INTERVAL MUST be representable as described in
[2]. [2].
5.2. Advertised Information Validity Times 5.3. Advertised Information Validity Times
The following parameters manage the validity time of information The following parameters manage the validity time of information
advertised in TC messages: advertised in TC messages:
T_HOLD_TIME - is used to define the minimum value in the T_HOLD_TIME - is used to define the minimum value in the
VALIDITY_TIME TLV included in all TC messages sent by this node. VALIDITY_TIME TLV included in all TC messages sent by this node.
If a single value of parameter TC_HOP_LIMIT is used then this will If a single value of parameter TC_HOP_LIMIT (see Section 5.6) is
be the only value in that TLV. used then this will be the only value in that TLV.
A_HOLD_TIME - is the period during which TC messages are sent after A_HOLD_TIME - is the period during which TC messages are sent after
they no longer have any advertised information to report, but are they no longer have any advertised information to report, but are
sent in order to accelerate outdated information removal by other sent in order to accelerate outdated information removal by other
nodes. nodes.
The following constraints apply to these parameters: The following constraints apply to these parameters:
o T_HOLD_TIME > 0 o T_HOLD_TIME > 0
o A_HOLD_TIME >= 0 o A_HOLD_TIME >= 0
o If TC messages can be lost then both SHOULD be significantly o T_HOLD_TIME >= TC_INTERVAL
greater than TC_INTERVAL.
o If TC messages can be lost then both T_HOLD_TIME and A_HOLD_TIME
SHOULD be significantly greater than TC_INTERVAL; a value >= 3*
TC_INTERVAL is RECOMMENDED.
o T_HOLD_TIME MUST be representable as described in [2]. o T_HOLD_TIME MUST be representable as described in [2].
5.3. Received Message Validity Times 5.4. Received Message Validity Times
The following parameters manage the validity time of recorded The following parameters manage the validity time of recorded
received message information: received message information:
RX_HOLD_TIME - is an interface parameter, and is the period after RX_HOLD_TIME - is an interface parameter, and is the period after
receipt of a message by the appropriate OLSRv2 interface of this receipt of a message by the appropriate OLSRv2 interface of this
node for which that information is recorded in order that the node for which that information is recorded, in order that the
message is recognized as having been previously received on this message is recognized as having been previously received on this
OLSRv2 interface. OLSRv2 interface.
P_HOLD_TIME - is the period after receipt of a message which is P_HOLD_TIME - is the period after receipt of a message which is
processed by this node for which that information is recorded in processed by this node for which that information is recorded, in
order that the message is not processed again if received again. order that the message is not processed again if received again.
F_HOLD_TIME - is the period after receipt of a message which is F_HOLD_TIME - is the period after receipt of a message which is
forwarded by this node for which that information is recorded in forwarded by this node for which that information is recorded, in
order that the message is not forwarded again if received again. order that the message is not forwarded again if received again.
The following constraints apply to these parameters: The following constraints apply to these parameters:
o RX_HOLD_TIME > 0 o RX_HOLD_TIME > 0
o P_HOLD_TIME > 0 o P_HOLD_TIME > 0
o F_HOLD_TIME > 0 o F_HOLD_TIME > 0
o All of these parameters SHOULD be greater than the maximum o All of these parameters SHOULD be greater than the maximum
variation in time that a message may take to traverse the MANET, difference in time that a message may take to traverse the MANET,
taking into account any message forwarding jitter as well as taking into account any message forwarding jitter as well as
propagation, queuing, and processing delays. propagation, queuing, and processing delays.
5.4. Jitter 5.5. Jitter
If jitter, as defined in [3], is used then these parameters are as If jitter, as defined in [3], is used then these parameters are as
follows: follows:
TP_MAXJITTER - represents the value of MAXJITTER used in [3] for TP_MAXJITTER - represents the value of MAXJITTER used in [3] for
periodically generated TC messages sent by this node. periodically generated TC messages sent by this node.
TT_MAXJITTER - represents the value of MAXJITTER used in [3] for TT_MAXJITTER - represents the value of MAXJITTER used in [3] for
externally triggered TC messages sent by this node. externally triggered TC messages sent by this node.
F_MAXJITTER - represents the default value of MAXJITTER used in [3] F_MAXJITTER - represents the default value of MAXJITTER used in [3]
for messages forwarded by this node. However before using for messages forwarded by this node. However before using
F_MAXJITTER a node MAY attempt to deduce a more appropriate value F_MAXJITTER a node MAY attempt to deduce a more appropriate value
of MAXJITTER, for example based on any INTERVAL_TIME or of MAXJITTER, for example based on any INTERVAL_TIME or
VALIDITY_TIME TLVs contained in the message to be forwarded. VALIDITY_TIME TLVs contained in the message to be forwarded.
For constraints on these parameters see [3]. For constraints on these parameters see [3].
5.5. Hop Limit Parameter 5.6. Hop Limit Parameter
The parameter TC_HOP_LIMIT is the hop limit set in each TC message. The parameter TC_HOP_LIMIT is the hop limit set in each TC message.
TC_HOP_LIMIT MAY be a single fixed value, or MAY be different in TC TC_HOP_LIMIT MAY be a single fixed value, or MAY be different in TC
messages sent by the same node. However each other node SHOULD see a messages sent by the same node. However each other node SHOULD see a
regular pattern of TC messages, in order that meaningful values of regular pattern of TC messages, in order that meaningful values of
INTERVAL_TIME and VALIDITY_TIME TLVs at each hop count distance can INTERVAL_TIME and VALIDITY_TIME TLVs at each hop count distance can
be included as defined in [2]. Thus the pattern of TC_HOP_LIMIT be included as defined in [2]. Thus the pattern of TC_HOP_LIMIT
SHOULD be defined to have this property. For example the repeating SHOULD be defined to have this property. For example the repeating
pattern (255 4 4) satisfies this property (having period TC_INTERVAL pattern (255 4 4) satisfies this property (having period TC_INTERVAL
at hop counts up to 4, inclusive, and 3 x TC_INTERVAL at hop counts at hop counts up to 4, inclusive, and 3 x TC_INTERVAL at hop counts
greater than 4), but the repeating pattern (255 255 4 4) does not greater than 4), but the repeating pattern (255 255 4 4) does not
satisfy this property. satisfy this property.
The maximum value of TC_HOP_LIMIT used MUST least equal the network The following constraints apply to this parameter:
diameter in hops, a value of 255 is RECOMMENDED. All values of
TC_HOP_LIMIT MUST satisfy TC_HOP_LIMIT >= 2.
5.6. Willingness o The maximum value of TC_HOP_LIMIT >= the network diameter in hops,
a value of 255 is RECOMMENDED.
o All values of TC_HOP_LIMIT >= 2.
5.7. Willingness
Each node has a WILLINGNESS parameter, which MUST be in the range Each node has a WILLINGNESS parameter, which MUST be in the range
WILL_NEVER to WILL_ALWAYS, inclusive, and represents its willingness WILL_NEVER to WILL_ALWAYS, inclusive, and represents its willingness
to be an MPR, and hence its willingness to forward messages and be an to be an MPR, and hence its willingness to forward messages and be an
intermediate node on routes. If a node has WILLINGNESS == WILL_NEVER intermediate node on routes. If a node has WILLINGNESS == WILL_NEVER
it does not perform these tasks. A MANET using OLSRv2 with too many it does not perform these tasks. A MANET using OLSRv2 with too many
nodes with WILLINGNESS == WILL_NEVER will not function; it MUST be nodes with WILLINGNESS == WILL_NEVER will not function; it MUST be
ensured, by administrative or other means, that this does not happen. ensured, by administrative or other means, that this does not happen.
Nodes MAY have different WILLINGNESS values; however the three Nodes MAY have different WILLINGNESS values; however the three
constants WILL_NEVER, WILL_DEFAULT and WILL_ALWAYS MUST have the constants WILL_NEVER, WILL_DEFAULT and WILL_ALWAYS MUST have the
values defined in Section 16.6. (Use of WILLINGNESS == WILL_DEFAULT values defined in Section 5.7. (Use of WILLINGNESS == WILL_DEFAULT
allows a node to avoid including a WILLINGNESS TLV in its TC allows a node to avoid including a WILLINGNESS TLV in its TC
messages, use of WILLINGNESS == WILL_ALWAYS means that a node will messages, use of WILLINGNESS == WILL_ALWAYS means that a node will
always be selected as an MPR by all symmetric 1-hop neighbors.) always be selected as an MPR by all symmetric 1-hop neighbors.)
5.7. Parameter Change Constraints The following constraints apply to this parameter:
o WILLINGNESS &gt=; WILL_NEVER
o WILLINGNESS &lt=; WILL_ALWAYS
5.8. Parameter Change Constraints
This section presents guidelines, applicable if protocol parameters This section presents guidelines, applicable if protocol parameters
are changed dynamically. are changed dynamically.
TC_INTERVAL TC_INTERVAL
* If the TC_INTERVAL for a node increases, then the next TC * If the TC_INTERVAL for a node increases, then the next TC
message generated by this node MUST be generated according to message generated by this node MUST be generated according to
the previous, shorter, TC_INTERVAL. Additional subsequent TC the previous, shorter, TC_INTERVAL. Additional subsequent TC
messages MAY be generated according to the previous, shorter, messages MAY be generated according to the previous, shorter,
TC_INTERVAL. TC_INTERVAL.
* If the TC_INTERVAL for a node decreases, then the following TC * If the TC_INTERVAL for a node decreases, then the following TC
messages from this node SHOULD be generated according to the messages from this node MUST be generated according to the
current, shorter, TC_INTERVAL. current, shorter, TC_INTERVAL.
T_HOLD_TIME
* If T_HOLD_TIME changes, then T_time for all Topology Tuples,
AN_time for all Attached Network Tuples and AR_time for all
Advertising Remote Node Tuples SHOULD be changed.
RX_HOLD_TIME RX_HOLD_TIME
* If RX_HOLD_TIME for an OLSRv2 interface changes, then RX_time * If RX_HOLD_TIME for an OLSRv2 interface changes, then RX_time
for all Received Tuples for that OLSRv2 interface MAY be for all Received Tuples for that OLSRv2 interface MAY be
changed. changed.
P_HOLD_TIME P_HOLD_TIME
* If P_HOLD_TIME changes, then P_time for all Processed Tuples * If P_HOLD_TIME changes, then P_time for all Processed Tuples
MAY be changed. MAY be changed.
skipping to change at page 17, line 5 skipping to change at page 19, line 5
rescheduled. rescheduled.
TC_HOP_LIMIT TC_HOP_LIMIT
* If TC_HOP_LIMIT changes, and the node uses multiple values * If TC_HOP_LIMIT changes, and the node uses multiple values
after the change, then message intervals and validity times after the change, then message intervals and validity times
included in TC messages MUST be respected. The simplest way to included in TC messages MUST be respected. The simplest way to
do this is to start any new repeating pattern of TC_HOP_LIMIT do this is to start any new repeating pattern of TC_HOP_LIMIT
values with its largest value. values with its largest value.
6. Information Repositories 6. Information Bases
Each node maintains the Information Bases described in the following
sections. These are used for describing the protocol in this
document. An implementation of this protocol MAY maintain this
information in the indicated form, or in any other organization which
offers access to this information. Regardless of how information is
organised, from the time at which a tuple is indicated to be expired,
the information contained herein MUST be ignored in any further
processing.
The purpose of OLSRv2 is to determine the Routing Set, which may be The purpose of OLSRv2 is to determine the Routing Set, which may be
used to update IP's Routing Table, providing "next hop" routing used to update IP's Routing Table, providing "next hop" routing
information for IP datagrams. OLSRv2 maintains four information information for IP datagrams. OLSRv2 maintains the following
repositories: Information Bases:
Local Information Base - as defined in [4], extended by the addition Local Information Base - as defined in [4], extended by the addition
of a Local Attached Network Set, defined in Section 6.1.1. of a Local Attached Network Set, defined in Section 6.1.2.
Neighborhood Information Base - as defined in [4], extended by the Interface Information Bases - as defined in [4], one Interface
addition of 3 elements to each Neighbor Tuple, as defined in Information Base for each OLSRv2 interface.
Node Information Base - as defined in [4], extended by the addition
of three elements to each Neighbor Tuple, as defined in
Section 6.2. Section 6.2.
Topology Information Base - this information base is specific to Topology Information Base - this information base is specific to
OLSRv2, defined in Section 6.3. OLSRv2, and is defined in Section 6.3.
Processing and Forwarding Information Base - this information base Processing and Forwarding Information Base - this information base
is specific to OLSRv2, defined in Section 6.4. is specific to OLSRv2, and is defined in Section 6.4.
All addresses, other than originator addresses, recorded in the All addresses, other than originator addresses, recorded in the
information repositories MUST all be recorded with prefix lengths, in Information Bases MUST all be recorded with prefix lengths, in order
order to allow comparison with addresses received in HELLO and TC to allow comparison with addresses received in HELLO and TC messages.
messages.
The ordering of sequence numbers, when considering which is the The ordering of sequence numbers, when considering which is the
greatest, is as defined in Section 17. greater, is as defined in Section 18.
6.1. Local Information Base 6.1. Local Information Base
The Local Information Base as defined in [4] is extended by the The Local Information Base as defined in [4] is extended by the
addition of a Local Attached Network Set, defined in Section 6.1.1. addition of an Originator Set, defined in Section 6.1.1, and a Local
Attached Network Set, defined in Section 6.1.2.
6.1.1. Local Attached Network Set 6.1.1. Originator Set
A node's Originator Set records addresses that were recently
originator addresses. If a node's originator address is immutable
then this set is always empty and MAY be omitted. It consists of
Originator Tuples:
(O_orig_addr, O_time)
where:
O_orig_addr is a recently used originator address;
O_time specifies the time at which this Tuple expires and MUST be
removed.
6.1.2. Local Attached Network Set
A node's Local Attached Network Set records its local non-OLSRv2 A node's Local Attached Network Set records its local non-OLSRv2
interfaces that can act as gateways to other networks. The Local interfaces that can act as gateways to other networks. The Local
Attached Network Set is not modified by this protocol. This protocol Attached Network Set is not modified by this protocol. This protocol
MAY respond to changes to the Local Attached Network Set, which MUST MAY respond to changes to the Local Attached Network Set, which MUST
reflect corresponding changes in the node's status. It consists of reflect corresponding changes in the node's status. It consists of
Local Attached Network Tuples: Local Attached Network Tuples:
(AL_net_addr, AL_dist) (AL_net_addr, AL_dist)
where: where:
AL_net_addr is the network address of an attached network which can AL_net_addr is the network address of an attached network which can
be reached via this node. be reached via this node.
AL_dist is the number of hops to the network with address AL_dist is the number of hops to the network with address
AL_net_addr from this node. AL_net_addr from this node.
Attached networks with AL_dist == 0 MUST be local to this node and Attached networks local to this node SHOULD be treated as local non-
MUST NOT be attached to any other node. Attached networks with MANET interfaces, and added to the Local Interface Set, as specified
AL_dist > 0 MAY also be attached to other nodes. in [4], rather than being added to the Local Attached Network Set.
Attached networks with AL_dist > 0 MUST be advertised in TC messages An attached network MAY also be attached to other nodes.
generated by this node, this may result in the node originating TC
messages when it has no other reason to do so. Attached networks
with AL_dist == 0 MAY be advertised in HELLO messages (which causes
the MPRs of this node to advertise them in their TC messages) or MAY
be advertised in TC messages; they MUST be advertised in one type of
message and SHOULD NOT be advertised in both. If a node is sending
TC messages for any other reason, then advertising attached networks
in TC messages is more efficient. A node MAY decide which form of
advertisement to use depending on its circumstances.
It is not the responsibility of OLSRv2 to maintain routes to networks It is not the responsibility of OLSRv2 to maintain routes to networks
recorded in the Local Attached Network Set. recorded in the Local Attached Network Set.
6.2. Neighborhood Information Base 6.2. Node Information Base
Each Neighbor Tuple in the Neighbor Set has these additional Each Neighbor Tuple in the Neighbor Set has these additional
elements: elements:
N_willingness is the node's willingness to be selected as an MPR, in N_willingness is the node's willingness to be selected as an MPR, in
the range from WILL_NEVER to WILL_ALWAYS, both inclusive; the range from WILL_NEVER to WILL_ALWAYS, both inclusive;
N_mpr is a boolean flag, describing if the neighbor is selected as N_mpr is a boolean flag, describing if the neighbor is selected as
an MPR by this node; an MPR by this node;
N_mpr_selector is a boolean flag, describing if this neighbor has N_mpr_selector is a boolean flag, describing if this neighbor has
selected this node as an MPR, i.e. is an MPR selector of this selected this node as an MPR, i.e. is an MPR selector of this
node. node.
6.3. Topology Information Base 6.3. Topology Information Base
The Topology Information Base stores information required for the The Topology Information Base stores information required for the
generation and processing of TC messages, and received in TC generation and processing of TC messages, and received in TC
messages. The Advertised Neighbor Set contains interface addresses messages. The Advertised Neighbor Set contains interface addresses
of symmetric 1-hop neighbors which are to be reported in TC messages. of symmetric 1-hop neighbors which are to be reported in TC messages.
The Topology Set and Attached Network Set both record information The Advertising Remote Node Set, the Topology Set and the Attached
received in TC messages. The Advertising Remote Node Set is both Network Set record information received in TC messages.
used and populated when processing TC messages.
Additionally, a Routing Set is maintained, derived from the Additionally, a Routing Set is maintained, derived from the
information recorded in the Neighborhood Information Base, Topology information recorded in the Neighborhood Information Base, Topology
Set, Attached Network Set and Advertising Remote Node Set. Set, Attached Network Set and Advertising Remote Node Set.
6.3.1. Advertised Neighbor Set 6.3.1. Advertised Neighbor Set
A node's Advertised Neighbor Set contains interface addresses of A node's Advertised Neighbor Set contains interface addresses of
symmetric 1-hop neighbors which are to be advertised through TC symmetric 1-hop neighbors which are to be advertised through TC
messages: messages:
skipping to change at page 21, line 24 skipping to change at page 23, line 36
R_dest_addr is the address of the destination, either the address of R_dest_addr is the address of the destination, either the address of
an interface of a destination node, or the network address of an an interface of a destination node, or the network address of an
attached network; attached network;
R_next_iface_addr is the OLSRv2 interface address of the "next hop" R_next_iface_addr is the OLSRv2 interface address of the "next hop"
on the selected path to the destination; on the selected path to the destination;
R_dist is the number of hops on the selected path to the R_dist is the number of hops on the selected path to the
destination; destination;
R_local_iface_addr is the address of the local interface over which R_local_iface_addr is the address of the local OLSRv2 interface over
a packet MUST be sent to reach the destination by the selected which a packet MUST be sent to reach the destination by the
path. selected path.
6.4. Processing and Forwarding Information Base 6.4. Processing and Forwarding Information Base
The Processing and Forwarding Information Base records information The Processing and Forwarding Information Base records information
required to ensure that a message is processed at most once and is required to ensure that a message is processed at most once and is
forwarded at most once per interface of a node. forwarded at most once per OLSRv2 interface of a node.
6.4.1. Received Set 6.4.1. Received Set
A node's Received Sets, one per local OLSRv2 interface, each record A node has a Received Set per local OLSRv2 interface. Each Received
the signatures of messages which have been received over that Set records the signatures of messages which have been received over
interface. Each consists of Received Tuples: that OLSRv2 interface. Each consists of Received Tuples:
(RX_type, RX_orig_addr, RX_seq_number, RX_time) (RX_type, RX_orig_addr, RX_seq_number, RX_time)
where: where:
RX_type is the received message type, or zero if the received RX_type is the received message type, or zero if the received
message sequence number is not type-specific; message sequence number is not type-specific;
RX_orig_addr is the originator address of the received message; RX_orig_addr is the originator address of the received message;
RX_seq_number is the message sequence number of the received RX_seq_number is the message sequence number of the received
message; message;
RX_time specifies the time at which this Tuple expires and MUST be RX_time specifies the time at which this Tuple expires and MUST be
removed. removed.
6.4.2. Processed Set 6.4.2. Processed Set
skipping to change at page 22, line 43 skipping to change at page 25, line 4
A node's Forwarded Set records signatures of messages which have been A node's Forwarded Set records signatures of messages which have been
processed by the node. It consists of Forwarded Tuples: processed by the node. It consists of Forwarded Tuples:
(F_type, F_orig_addr, F_seq_number, F_time) (F_type, F_orig_addr, F_seq_number, F_time)
where: where:
F_type is the forwarded message type, or zero if the forwarded F_type is the forwarded message type, or zero if the forwarded
message sequence number is not type-specific; message sequence number is not type-specific;
F_orig_addr is the originator address of the forwarded message; F_orig_addr is the originator address of the forwarded message;
F_seq_number is the message sequence number of the forwarded F_seq_number is the message sequence number of the forwarded
message; message;
F_time specifies the time at which this Tuple expires and MUST be F_time specifies the time at which this Tuple expires and MUST be
removed. removed.
6.4.4. Relay Set 6.4.4. Relay Set
A node's Relay Sets, one per local OLSRv2 interface, each records the A node has a Relay Set per local OLSRv2 interface. Each Relay Set
OLSRv2 interface addresses of symmetric 1-hop neighbors, such that records the OLSRv2 interface addresses of symmetric 1-hop neighbors,
the node is to forward messages received from those neighbor's OLSRv2 such that the node is to forward messages received from those
interfaces, on that local OLSRv2 interface, if not otherwise excluded neighbors' OLSRv2 interfaces, on that local OLSRv2 interface, if not
from forwarding that message (e.g. by it having been previously otherwise excluded from forwarding that message (e.g. by it having
forwarded): been previously forwarded):
{RY_neighbor_iface_addr} {RY_neighbor_iface_addr}
7. Packet Processing and Message Forwarding 7. Packet Processing and Message Forwarding
On receiving a packet, as defined in [1], a node examines the packet On receiving a packet, as defined in [1], a node examines the packet
header and each of the message headers. If the message type is known header and each of the message headers. If the message type is known
to the node, the message is processed locally according to the to the node, the message is processed locally according to the
specifications for that message type. The message is also specifications for that message type. The message is also
independently evaluated for forwarding. independently evaluated for forwarding.
skipping to change at page 24, line 29 skipping to change at page 26, line 29
parse the packet header, or determine its absence, without parse the packet header, or determine its absence, without
parsing any messages. It is possible to divide the packet into parsing any messages. It is possible to divide the packet into
messages without even fully parsing their headers. It is messages without even fully parsing their headers. It is
possible to determine whether a message is to be forwarded, and possible to determine whether a message is to be forwarded, and
to forward it, without parsing its body. It is possible to to forward it, without parsing its body. It is possible to
determine whether a message is to be processed without parsing determine whether a message is to be processed without parsing
its body.) its body.)
2. If parsing fails at any point the relevant entity (packet or 2. If parsing fails at any point the relevant entity (packet or
message) MUST be silently discarded, other parts of the packet message) MUST be silently discarded, other parts of the packet
(up to the whole packet) MAY be silently discarded; (up to the whole packet) MAY be silently discarded.
3. Otherwise if the packet header is present and it contains a 3. Otherwise if the packet header is present and it contains a
packet TLV block, then each TLV in it is processed according to packet TLV block, then each TLV in it is processed according to
its type if recognized, otherwise the TLV is ignored; its type if recognized, otherwise the TLV is ignored.
4. Otherwise each message in the packet, if any, is treated 4. Otherwise each message in the packet, if any, is treated
according to Section 7.2. according to Section 7.2.
7.2. Actions when Receiving an OLSRv2 Message 7.2. Actions when Receiving an OLSRv2 Message
A node MUST perform the following tasks for each received message: A node MUST perform the following tasks for each received message:
1. If the message header cannot be correctly parsed according to the 1. If the message header cannot be correctly parsed according to the
specification in [1], or if the node recognizes from the specification in [1], or if the node recognizes from the
originator address of the message that the message is one which originator address of the message that the message is one which
the receiving node itself originated, then the message MUST be the receiving node itself originated (i.e. is the current
silently discarded. originator address of the node, or is an O_orig_addr in an
Originator Tuple) then the message MUST be silently discarded.
2. Otherwise: 2. Otherwise:
1. If the message is a HELLO message, then the message is 1. If the message is a HELLO message, then the message is
processed according to Section 10. processed according to Section 10.
2. Otherwise: 2. Otherwise:
1. If the message is of a known type, then the message is 1. If the message is of a known type, including being a TC
considered for processing according to Section 7.3, AND; message, then the message is considered for processing
according to Section 7.3, AND;
2. If for the message (<hop-limit> + <hop-count>) > 1, then 2. If for the message:
the message is considered for forwarding according to
Section 7.4. - <hop-limit> is present and <hop-limit> > 1, AND;
- <hop-count> is not present or <hop-count> < 255
then the message is considered for forwarding according
to Section 7.4.
7.3. Message Considered for Processing 7.3. Message Considered for Processing
If a message (the "current message") is considered for processing, If a message (the "current message") is considered for processing,
then the following tasks MUST be performed: then the following tasks MUST be performed:
1. If a Processed Tuple exists with: 1. If a Processed Tuple exists with:
* P_type == the message type of the current message, or 0 if the * P_type == the message type of the current message, or 0 if the
typedep bit in the message semantics octet in the message typedep bit in the message semantics octet in the message
skipping to change at page 29, line 11 skipping to change at page 31, line 11
F_MAXJITTER. A node MAY reduce the jitter applied to F_MAXJITTER. A node MAY reduce the jitter applied to
a message in order to more efficiently combine a message in order to more efficiently combine
messages in packets. messages in packets.
8. Packets and Messages 8. Packets and Messages
Nodes using OLSRv2 exchange information through messages. One or Nodes using OLSRv2 exchange information through messages. One or
more messages sent by a node at the same time SHOULD be combined into more messages sent by a node at the same time SHOULD be combined into
a single packet. These messages may have originated at the sending a single packet. These messages may have originated at the sending
node, or have originated at another node and are forwarded by the node, or have originated at another node and are forwarded by the
sending node. Messages with different originators MAY be combined in sending node. Messages with different originating nodes MAY be
the same packet. Messages from other protocols defined using [1] MAY combined in the same packet. Messages from other protocols defined
be combined in the same packet. using [1] MAY be combined in the same packet.
OLSRv2 packets are sent using UDP, on the port "manet" defined in
[6]. Their IP datagrams are transmitted using the well-known
multicast address "LL MANET Routers" defined in [6].
The packet and message format used by OLSRv2 is defined in [1].
However this specification contains some options which are not used
by OLSRv2. In particular (using the syntactical entities defined in
[1]):
o All OLSRv2 packets, not limited to those defined in this document,
include a <packet-header>.
o All OLSRv2 packets, not limited to those defined in this document, The packet and message format used by OLSRv2 is defined in [1],
have the pseqnum bit of <packet-semantics> cleared ('0'), i.e. where:
they include a packet sequence number.
o OLSRv2 packets MAY include packet TLVs, however OLSRv2 itself does o OLSRv2 packets MAY include packet TLVs, however OLSRv2 itself does
not specify any packet TLVs. not specify any packet TLVs.
o All OLSRv2 messages, not limited to those defined in this o All references in this specification to TLVs that do not indicate
document, include a full <msg-header> and hence have the noorig, a type extension, assume Type Extension == 0. TLVs in processed
nohoplimit, nohopcount and noseqnum bits of <msg-semantics> messages with a non-zero type extension, or with a type extension
cleared ('0'). which is not specifically indicated, as appropriate, are ignored.
o All OLSRv2 messages defined in this document have the typedep bit
of <msg-semantics> cleared ('0').
o All references in this document to specific TLVs in generating and
processing HELLO and TC messages refer to TLVs with Subtype == 0.
TLVs with nonzero subtype are treated as of unknown type when
processing messages, i.e. they are ignored.
Other options defined in [1] may be freely used, in particular any Other options defined in [1] may be freely used, in particular any
other values of <packet-semantics>, <addr-semantics> or <tlv- other values of <pkt-semantics>, <msg-semantics>, <addr-semantics> or
semantics> consistent with their specifications. <tlv-semantics> consistent with their specifications.
The remainder of this section defines, within the framework of [1], The remainder of this section defines, within the framework of [1],
message types and TLVs specific to OLSRv2. message types and TLVs specific to OLSRv2.
8.1. HELLO Messages 8.1. HELLO Messages
A HELLO message in OLSRv2 is generated as specified in [4]. A HELLO message in OLSRv2 is generated as specified in [4].
Additionally, an OLSRv2 node: Additionally, an OLSRv2 node:
o MUST include TLV(s) with Type == MPR associated with all OLSRv2 o MUST include TLV(s) with Type == MPR associated with all OLSRv2
skipping to change at page 30, line 30 skipping to change at page 32, line 11
o MAY include a message TLV with Type == WILLINGNESS, indicating the o MAY include a message TLV with Type == WILLINGNESS, indicating the
node's willingness to be selected as an MPR. node's willingness to be selected as an MPR.
8.1.1. HELLO Message TLVs 8.1.1. HELLO Message TLVs
In a HELLO message, a node MAY include a WILLINGNESS message TLV as In a HELLO message, a node MAY include a WILLINGNESS message TLV as
specified in Table 1. A node MUST NOT include more than one specified in Table 1. A node MUST NOT include more than one
WILLINGNESS message TLV. WILLINGNESS message TLV.
+-------------+------+---------+--------+---------------------------+ +-------------+--------+--------------------------------------------+
| Name | Type | Subtype | Length | Value | | Name | Value | Value |
+-------------+------+---------+--------+---------------------------+ | | Length | |
| WILLINGNESS | TBD | 0 | 8 bits | The node's willingness to | +-------------+--------+--------------------------------------------+
| | | | | be selected as MPR; | | WILLINGNESS | 8 bits | The node's willingness to be selected as |
| | | | | unused bits (based on the | | | | MPR; unused bits (based on the maximum |
| | | | | maximum willingness value | | | | willingness value WILL_ALWAYS) are |
| | | | | WILL_ALWAYS) are RESERVED | | | | RESERVED and SHOULD be set to zero. |
| | | | | and SHOULD be set to zero | +-------------+--------+--------------------------------------------+
+-------------+------+---------+--------+---------------------------+
Table 1 Table 1
A node's willingness to be selected as MPR ranges from WILL_NEVER A node's willingness to be selected as MPR ranges from WILL_NEVER
(indicating that a node MUST NOT be selected as MPR by any node) to (indicating that a node MUST NOT be selected as MPR by any node) to
WILL_ALWAYS (indicating that a node MUST always be selected as MPR). WILL_ALWAYS (indicating that a node MUST always be selected as MPR).
If a node does not advertise a Willingness TLV in HELLO messages, If a node does not advertise a Willingness TLV in HELLO messages,
then the node MUST be assumed to have a willingness of WILL_DEFAULT. then the node MUST be assumed to have a willingness of WILL_DEFAULT.
8.1.2. HELLO Message Address Block TLVs 8.1.2. HELLO Message Address Block TLVs
In a HELLO message, a node MAY include MPR address block TLV(s) as In a HELLO message, a node MAY include MPR address block TLV(s) as
specified in Table 2. specified in Table 2.
+------+------+---------+--------+-------+ +------+--------------+-------+
| Name | Type | Subtype | Length | Value | | Name | Value Length | Value |
+------+------+---------+--------+-------+ +------+--------------+-------+
| MPR | TBD | 0 | 0 bits | None | | MPR | 0 bits | None. |
+------+------+---------+--------+-------+ +------+--------------+-------+
Table 2 Table 2
8.2. TC Messages 8.2. TC Messages
A TC message MUST contain: A TC message MUST contain:
o A message TLV with Type == CONT_SEQ_NUM, as specified in o <msg-orig-addr>, <msg-seq-num> and <msg-hop-limit> elements in its
message header, as specified in [1].
o A <msg-hop-count> element in its message header if the message
contsins either a VALIDITY_TIME or an INTERVAL_TIME TLV indicating
more than one time value according to distance.
o A single message TLV with Type == CONT_SEQ_NUM, and Type Extension
== COMPLETE or Type Extension == INCOMPLETE, as specified in
Section 8.2.1. Section 8.2.1.
o A message TLV with Type == VALIDITY_TIME, as specified in [2]. o A message TLV with Type == VALIDITY_TIME, as specified in [2].
The options included in [2] for representing zero and infinite
times MUST NOT be used.
o A first address block (the Local Address Block) containing all of o All of the node's interface addresses. These MUST be included in
the node's interface addresses. This is similar to the Local the message's address blocks, unless:
Interface Block included in HELLO messages as specified in [4],
however in a TC message these addresses MUST be included in the
same order in all copies of a given TC message, regardless of
which OLSRv2 interface it is transmitted on, and no OTHER_IF
address block TLVs are required.
o Except when they would be empty, or when including a message TLV * the node has a single interface, with a single interface
with Type == INCOMPLETE (in which case the TC message does not address with maximum prefix length, and
satisfy the necessary transmission constraints defined by
TC_INTERVAL and T_HOLD_TIME), address block(s) (Advertised Address * that address is the node's originator address.
Blocks) containing addresses in the Advertised Address Set and
selected addresses in the Local Attached Network Set, the latter In this exceptional case, the address will be included as the
(only) with associated GATEWAY address block TLV(s), as specified message's originator address.
in Section 8.2.2.
o TLV(s) with Type == LOCAL_IF and Value == UNSPEC_IF associated
with all of the node's interface addresses.
o A complete TC message MUST include all addresses in the Advertised
Address Set and selected addresses in the Local Attached Network
Set, the latter (only) with associated GATEWAY address block
TLV(s), as specified in Section 8.2.2.
A TC message SHOULD have the mistypedep bit of <msg-semantics>, as
defined in [1] cleared ('0').
A TC message MAY contain: A TC message MAY contain:
o A message TLV with Type == INTERVAL_TIME, as specified in [2]. o A message TLV with Type == INTERVAL_TIME, as specified in [2].
The options included in [2] for representing zero and infinite
o A message TLV with Type == INCOMPLETE, as specified in times MUST NOT be used.
Section 8.2.1.
8.2.1. TC Message TLVs 8.2.1. TC Message TLVs
In a TC message, a node MUST include a CONT_SEQ_NUM message TLV, and In a TC message, a node MUST include a single CONT_SEQ_NUM message
MAY contain an INCOMPLETE message TLV, as specified in Table 3. A TLV, as specified in Table 3, and with Type Extension == COMPLETE or
node MUST NOT include more than one CONT_SEQ_NUM message TLV or Type Extension == INCOMPLETE.
INCOMPLETE message TLV.
+--------------+------+---------+--------+--------------------------+ +--------------+------------+---------------------------------------+
| Name | Type | Subtype | Length | Value | | Name | Value | Value |
+--------------+------+---------+--------+--------------------------+ | | Length | |
| CONT_SEQ_NUM | TBD | 0 | 8 bits | The ANSN contained in | +--------------+------------+---------------------------------------+
| | | | | the Advertised Neighbor | | CONT_SEQ_NUM | 8 bits | The ANSN contained in the Advertised |
| | | | | Set | | | | Neighbor Set. |
| | | | | | +--------------+------------+---------------------------------------+
| INCOMPLETE | TBD | 0 | 0 bits | None |
+--------------+------+---------+--------+--------------------------+
Table 3 Table 3
8.2.2. TC Message Address Block TLVs 8.2.2. TC Message Address Block TLVs
In a TC message, a node MAY include GATEWAY address block TLV(s) as In a TC message, a node MAY include GATEWAY address block TLV(s) as
specified in Table 4. specified in Table 4.
+---------+------+---------+--------+-------------------------------+ +---------+--------------+-------------------------------------+
| Name | Type | Subtype | Length | Value | | Name | Value Length | Value |
+---------+------+---------+--------+-------------------------------+ +---------+--------------+-------------------------------------+
| GATEWAY | TBD | 0 | 8 bits | Number of hops to attached | | GATEWAY | 8 bits | Number of hops to attached network. |
| | | | | network | +---------+--------------+-------------------------------------+
+---------+------+---------+--------+-------------------------------+
Table 4 Table 4
9. HELLO Message Generation 9. HELLO Message Generation
An OLSRv2 HELLO message is composed as defined in [4], with the An OLSRv2 HELLO message is composed as defined in [4], with the
following additions: following additions:
o A message TLV with Type == WILLINGNESS and Value == the node's o A message TLV with Type == WILLINGNESS and Value == the node's
willingness to act as an MPR, MAY be included. willingness to act as an MPR, MAY be included.
skipping to change at page 33, line 26 skipping to change at page 35, line 26
N_neighbor_iface_addr_list of a Neighbor Tuple with N_mpr == N_neighbor_iface_addr_list of a Neighbor Tuple with N_mpr ==
true), an address block TLV with Type == MPR MUST be included; true), an address block TLV with Type == MPR MUST be included;
this TLV MUST be associated with the same copy of the address as this TLV MUST be associated with the same copy of the address as
is the TLV with Type == LINK_STATUS. is the TLV with Type == LINK_STATUS.
o For each address which is included in the message and is not o For each address which is included in the message and is not
associated with a TLV with Type == LINK_STATUS and Value == associated with a TLV with Type == LINK_STATUS and Value ==
SYMMETRIC, or is not of an MPR (i.e. the address is not in the SYMMETRIC, or is not of an MPR (i.e. the address is not in the
N_neighbor_iface_addr_list of a Neighbor Tuple with N_mpr == N_neighbor_iface_addr_list of a Neighbor Tuple with N_mpr ==
true), an address block TLV with Type == MPR MUST NOT be true), an address block TLV with Type == MPR MUST NOT be
associated wit this address. associated with this address.
o For each Local Attached Tuple with AL_dist == 0, a node MAY
include AL_net_addr in the Local Interface Block of the message,
with an associated TLV with Type == OTHER_IF.
9.1. HELLO Message: Transmission 9.1. HELLO Message: Transmission
HELLO messages are included in packets as specified in [1]. These HELLO messages are included in packets as specified in [1]. These
packets may contain other messages, including TC messages. packets may contain other messages, including TC messages.
10. HELLO Message Processing 10. HELLO Message Processing
Subsequent to the processing of HELLO messages, as specified in [4], Subsequent to the processing of HELLO messages, as specified in [4],
the node MUST identify the Neighbor Tuple which was created or the node MUST identify the Neighbor Tuple which was created or
skipping to change at page 35, line 27 skipping to change at page 37, line 27
and N_mpr == false changes to WILL_ALWAYS from any other and N_mpr == false changes to WILL_ALWAYS from any other
value. value.
3. Otherwise the set of MPRs of a node MAY be recalculated if the 3. Otherwise the set of MPRs of a node MAY be recalculated if the
N_willingness of a Neighbor Tuple with N_symmetric == true N_willingness of a Neighbor Tuple with N_symmetric == true
changes in any other way; it SHOULD be recalculated if N_mpr == changes in any other way; it SHOULD be recalculated if N_mpr ==
false and this is an increase in N_willingness or if N_mpr == false and this is an increase in N_willingness or if N_mpr ==
true and this is a decrease in N_willingness. true and this is a decrease in N_willingness.
If the set of MPRs of a node is recalculated, this MUST be as If the set of MPRs of a node is recalculated, this MUST be as
described in Section 13. Before that calculation the N_mpr of all described in Section 14. Before that calculation the N_mpr of all
Neighbor Tuples are set false, after that calculation the N_mpr of Neighbor Tuples are set false, after that calculation the N_mpr of
all Neighbor Tuples representing symmetric 1-hop neighbors which are all Neighbor Tuples representing symmetric 1-hop neighbors which are
chosen as MPRs, are set true. chosen as MPRs, are set true.
A node MAY recognize the previous set of MPRs in the calculation of a
new set of MPRs in order to minimise unnecessary changes to this set.
An additional HELLO message MAY be sent when the node's set of MPRs An additional HELLO message MAY be sent when the node's set of MPRs
changes, in addition to the cases specified in [4], and subject to changes, in addition to the cases specified in [4], and subject to
the same constraints. the same constraints.
11. TC Message Generation 11. TC Message Generation
A node with one or more OLSRv2 interfaces, and with a non-empty A node with one or more OLSRv2 interfaces, and with a non-empty
Advertised Neighbor Set or which acts as a gateway to an attached Advertised Neighbor Set or a non-empty Local Attached Network Set
network which is to be advertised in the MANET by this node, MUST MUST generate TC messages. A node with an empty Advertised Neighbor
generate TC messages. A node with an empty Advertised Neighbor Set Set and and empty Local Attached Network Set SHOULD also generate
and which is not acting as such a gateway SHOULD also generate
"empty" TC messages for a period A_HOLD_TIME after it last generated "empty" TC messages for a period A_HOLD_TIME after it last generated
a non-empty TC message. TC messages (non-empty and empty) are a non-empty TC message. TC messages (non-empty and empty) are
generated according to the following: generated according to the following:
1. The message hop count MUST be set to zero. 1. The message hop count, if included, MUST be set to zero.
2. The message hop limit MAY be set to any positive value, this 2. The message hop limit MUST be set to a value greater than 1. A
SHOULD be at least two. A node MAY: node MAY:
* use the same hop limit TC_HOP_LIMIT in all TC messages, this * use the same hop limit TC_HOP_LIMIT in all TC messages, this
MUST be at least equal to the network diameter in hops; OR MUST be at least equal to the network diameter in hops; OR
* use different values of the hop limit TC_HOP_LIMIT in TC * use different values of the hop limit TC_HOP_LIMIT in TC
messages, this MUST regularly include messages with hop limit messages, this MUST regularly include messages with hop limit
as defined above, other, lower, hop limits SHOULD use a as defined above, other, lower, hop limits SHOULD use a
regular pattern with a regular message interval at any given regular pattern with a regular message interval at any given
number of hops distance. number of hops distance.
3. The message MUST contain a message TLV with Type == CONT_SEQ_NUM 3. The message MUST contain a message TLV with Type == CONT_SEQ_NUM
and Value == ANSN from the Advertised Neighbor Set. and Value == ANSN from the Advertised Neighbor Set. If the TC
message is complete then this message TLV MUST have Type
Extension == COMPLETE, otherwise it MUST have Type Extension ==
INCOMPLETE.
4. The message MUST contain a message TLV with Type == 4. The message MUST contain a message TLV with Type ==
VALIDITY_TIME, as specified in [2]. If all TC messages are sent VALIDITY_TIME, as specified in [2]. If all TC messages are sent
with the same hop limit then this TLV MUST have Value == with the same hop limit then this TLV MUST have Value ==
T_HOLD_TIME. If TC messages are sent with different hop limits, T_HOLD_TIME. If TC messages are sent with different hop limits
then this TLV MUST specify times which vary with the number of (more than one value of TC_HOP_LIMIT) then this TLV MUST specify
hops distance appropriate to the chosen pattern of TC message hop times which vary with the number of hops distance appropriate to
limits, these times SHOULD be appropriate multiples of the chosen pattern of TC message hop limits, as specified in [2],
T_HOLD_TIME. these times SHOULD be appropriate multiples of T_HOLD_TIME.
5. The message MAY contain a message TLV with Type == INTERVAL_TIME, 5. The message MAY contain a message TLV with Type == INTERVAL_TIME,
as specified in [2]. If all TC messages are sent with the same as specified in [2]. If all TC messages are sent with the same
hop limit then this TLV MUST have Value == TC_INTERVAL. If TC hop limit then this TLV MUST have Value == TC_INTERVAL. If TC
messages are sent with different hop limits, then this TLV MUST messages are sent with different hop limits, then this TLV MUST
specify times which vary with the number of hops distance specify times which vary with the number of hops distance
appropriate to the chosen pattern of TC message hop limits, these appropriate to the chosen pattern of TC message hop limits, as
times SHOULD be appropriate multiples of TC_INTERVAL. specified in [2], these times SHOULD be appropriate multiples of
TC_INTERVAL.
6. The message MUST contain the addresses of all of its interfaces
in its first address block (the "Local Address Block"). Note
that the TC message generated on all OLSRv2 interfaces MUST be
identical (including having identical message sequence number)
and hence these addresses are not ordered or otherwise identified
according to the interface on which the TC message is
transmitted.
7. The message MUST contain, in address blocks other than its first 6. Unless the node has a single interface, with a single interface
("Advertised Address Blocks"): address with maximum prefix length, and that address is the
node's originator address, the message MUST contain all of the
node's interface addresses (i.e. all addresses in an
I_local_iface_addr_list) in its address blocks.
1. A_neighbor_iface_addr from each Advertised Neighbor Tuple; 7. All addresses of the node's interfaces included in an address
block MUST be associated with a TLV with Type == LOCAL_IF and
Value == UNSPEC_IF.
2. AL_net_addr from each Local Attached Neighbor Tuple with 8. The message MUST include in its address blocks:
AL_dist > 0, each associated with a TLV with Type == GATEWAY
and Value == AL_dist.
8. The message MAY contain, in address blocks other than its first: 1. A_neighbor_iface_addr from each Advertised Neighbor Tuple;
1. AL_net_addr from each Local Attached Neighbor Tuple with 2. AL_net_addr from each Local Attached Neighbor Tuple, each
AL_dist == 0, each associated with a TLV with Type == GATEWAY associated with a TLV with Type == GATEWAY and Value ==
and Value == 0. AL_dist.
11.1. TC Message: Transmission 11.1. TC Message: Transmission
TC messages are generated and transmitted periodically on all OLSRv2 Complete TC messages are generated and transmitted periodically on
interfaces, with a default interval between two consecutive TC all OLSRv2 interfaces, with a default interval between two
emissions by the same node of TC_INTERVAL. consecutive TC transmissions by the same node of TC_INTERVAL.
TC messages MAY be generated in response to a change of contents, TC messages MAY be generated in response to a change of contents,
indicated by a change in ANSN. In this case a node MAY send a indicated by a change in ANSN. In this case a node MAY send a
complete TC message, and if so MAY re-start its TC message schedule. complete TC message, and if so MAY re-start its TC message schedule.
Alternatively a node MAY send only new content in its address blocks Alternatively a node MAY send an incomplete TC message with only new
(with appropriate associated TLVs) in which case it MUST include a content in its address blocks. Note that a node cannot report
message TLV with Type == INCOMPLETE, and MUST NOT re-start its TC removal of advertised content using an incomplete TC message.
message schedule. This TC message MUST include its usual message
TLVs. Note that a node cannot report removal of advertised content
using an incomplete TC message.
When sending a TC message in response to a change of contents, a node When sending a TC message in response to a change of contents, a node
must respect a minimum interval of TC_MIN_INTERVAL between generated must respect a minimum interval of TC_MIN_INTERVAL between generated
TC messages. Sending an incomplete TC message MUST NOT cause the TC messages. Sending an incomplete TC message MUST NOT cause the
interval between complete TC messages to be increased, and thus a interval between complete TC messages to be increased, and thus a
node MUST NOT send an incomplete TC message if within TC_MIN_INTERVAL node MUST NOT send an incomplete TC message if within TC_MIN_INTERVAL
of the next scheduled complete TC message. of the next scheduled complete TC message.
The generation of TC messages, whether scheduled or triggered by a The generation of TC messages, whether scheduled or triggered by a
change of contents MAY be jittered as described in [3]. The values change of contents MAY be jittered as described in [3]. The values
of MAXJITTER used SHOULD be: of MAXJITTER used SHOULD be:
o TP_MAXJITTER for periodic TC message generation; o TP_MAXJITTER for periodic TC message generation;
o TT_MAXJITTER for triggered TC message generation. o TT_MAXJITTER for triggered TC message generation.
TC messages are included in packets as specified in [1]. These TC messages are included in packets as specified in [1]. These
packets may contain other messages, including HELLO messages and TC packets MAY contain other messages, including HELLO messages and TC
messages with different originator addresses. TC messages are messages with different originator addresses. TC messages are
forwarded according to the specification in Section 7.4. forwarded according to the specification in Section 7.4.
12. TC Message Processing 12. TC Message Processing
When according to Section 7.3 a TC message is to be processed When according to Section 7.3 a TC message is to be processed
according to its type, this means that: according to its type, this means that:
o if the message does not contain a message TLV with Type == o If any address associated with a TLV with Type == LOCAL_IF is one
INCOMPLETE, then processing according to Section 12.1 and then of the receiving node's current or recently used interface
according to Section 12.2 is carried out; addresses (i.e. is in any I_local_iface_addr_list in the Local
Interface Set or is equal to any IR_local_iface_addr in the
Removed Interface Address Set), then the TC message MUST be
discarded.
o if the message contains a message TLV with Type == INCOMPLETE, o If the TC message does not contain exactly one message TLV with
then only processing according to Section 12.1 is carried out. Type == CONT_SEQ_NUM and Type Extension == COMPLETE or Type
Extension == INCOMPLETE, then the TC message MUST be discarded.
For all processing purposes, "ANSN" is defined as being the value of o If the TC message contains a message TLV with Type == CONT_SEQ_NUM
the message TLV with Type == CONT_SEQ_NUM in the TC message. If a TC and Type Extension == COMPLETE, then processing according to
message has no such TLV then it MUST NOT be processed. Section 12.1 and then according to Section 12.2 is carried out.
12.1. Initial TC Message Processing o If the TC message contains a message TLV with Type == CONT_SEQ_NUM
and Type Extension == INCOMPLETE, then only processing according
to Section 12.1 is carried out.
For the purposes of this section, note the following: 12.1. Initial TC Message Processing
o "validity time" is calculated from the VALIDITY_TIME message TLV For the purposes of this section:
in the TC message according to the specification in [2];
o "originator address" refers to the originator address in the TC o "originator address" refers to the originator address in the TC
message header; message header.
o "Local Address Block" refers to the Local Address Block (i.e. the o "validity time" is calculated from the VALIDITY_TIME message TLV
first address block) in the TC message; in the TC message according to the specification in [2]. All
information in the TC message has the same validity time.
o "sending address list" refers to the list of addresses in the o "ANSN" is defined as being the value of the message TLV with Type
Local Address Block. == CONT_SEQ_NUM.
o "Advertised Address Block" refers to an Advertised Address Block o "sending address list" refers to the list of addresses in all
(i.e. the an address block other than the first address block) in address blocks which have associated TLV with Type == LOCAL_IF and
the TC message; Value == UNSPEC_IF. If the sending address list is otherwise
empty, then the message's originator address is added to the
sending address list, with maximum prefix length.
o comparisons of sequence numbers are carried out as specified in o Comparisons of sequence numbers are carried out as specified in
Section 17. Section 18.
The TC message is processed as follows: The TC message is processed as follows:
1. the Advertising Remote Node Set is updated according to 1. The Advertising Remote Node Set is updated according to
Section 12.1.1; if the TC message is indicated as discarded in Section 12.1.1; if the TC message is indicated as discarded in
that processing then the following steps are not carried out; that processing then the following steps are not carried out.
2. the Topology Set is updated according to Section 12.1.2; 2. The Topology Set is updated according to Section 12.1.2.
3. the Attached Network Set is updated according to Section 12.1.3.
3. The Attached Network Set is updated according to Section 12.1.3.
12.1.1. Populating the Advertising Remote Node Set 12.1.1. Populating the Advertising Remote Node Set
The node MUST update its Advertising Remote Node Set as follows: The node MUST update its Advertising Remote Node Set as follows:
1. If there is an Advertising Remote Node Tuple with: 1. If there is an Advertising Remote Node Tuple with:
* AR_orig_addr == originator address; AND * AR_orig_addr == originator address; AND
* AR_seq_number > ANSN * AR_seq_number > ANSN
skipping to change at page 40, line 37 skipping to change at page 42, line 44
2. This Advertising Remote Node Tuple (existing or new, the 2. This Advertising Remote Node Tuple (existing or new, the
"current tuple") is then modified as follows: "current tuple") is then modified as follows:
+ AR_seq_number = ANSN; + AR_seq_number = ANSN;
+ AR_time = current time + validity time. + AR_time = current time + validity time.
+ AR_iface_addr_list = sending address list + AR_iface_addr_list = sending address list
3. for each other Advertising Remote Node Tuple (with a 3. For each other Advertising Remote Node Tuple (with a
different AR_orig_addr, the "other tuple") whose different AR_orig_addr, the "other tuple") whose
AR_iface_addr_list contains any address in the AR_iface_addr_list contains any address in the
AR_iface_addr_list of the current tuple: AR_iface_addr_list of the current tuple:
1. remove all Topology Tuples with T_orig_addr == 1. remove all Topology Tuples with T_orig_addr ==
AR_orig_addr of the other tuple; AR_orig_addr of the other tuple;
2. remove all Attached Network Tuples with AN_orig_addr == 2. remove all Attached Network Tuples with AN_orig_addr ==
AR_orig_addr of the other tuple; AR_orig_addr of the other tuple;
3. remove the other tuple. 3. remove the other tuple.
12.1.2. Populating the Topology Set 12.1.2. Populating the Topology Set
The node MUST update its Topology Set as follows: The node MUST update its Topology Set as follows:
1. For each address (henceforth advertised address) in an Advertised 1. For each address (henceforth advertised address) in an address
Address Block which does not have an associated TLV with Type == block which does not have an associated TLV with Type ==
GATEWAY: LOCAL_IF, or an associated TLV with Type == GATEWAY:
1. If there is no Topology Tuple such that: 1. If there is no Topology Tuple such that:
+ T_dest_iface_addr == advertised address; AND + T_dest_iface_addr == advertised address; AND
+ T_orig_addr == originator address + T_orig_addr == originator address
then create a new Topology Tuple with: then create a new Topology Tuple with:
+ T_dest_iface_addr = advertised address; + T_dest_iface_addr = advertised address;
skipping to change at page 41, line 36 skipping to change at page 43, line 40
follows: follows:
+ T_seq_number = ANSN; + T_seq_number = ANSN;
+ T_time = current time + validity time. + T_time = current time + validity time.
12.1.3. Populating the Attached Network Set 12.1.3. Populating the Attached Network Set
The node MUST update its Attached Network Set as follows: The node MUST update its Attached Network Set as follows:
1. For each address (henceforth network address) in an Advertised 1. For each address (henceforth network address) in an address block
Address Block which has an associated TLV with Type == GATEWAY: which does not have an associated TLV with Type == LOCAL_IF, and
does have an associated TLV with Type == GATEWAY:
1. If there is no Attached Network Tuple such that: 1. If there is no Attached Network Tuple such that:
+ AN_net_addr == network address; AND + AN_net_addr == network address; AND
+ AN_orig_addr == originator address + AN_orig_addr == originator address
then create a new Attached Network Tuple with: then create a new Attached Network Tuple with:
+ AN_net_addr = network address; + AN_net_addr = network address;
skipping to change at page 42, line 17 skipping to change at page 44, line 22
+ AN_dist = the value of the associated GATEWAY TLV; + AN_dist = the value of the associated GATEWAY TLV;
+ AN_seq_number = ANSN; + AN_seq_number = ANSN;
+ AN_time = current time + validity time. + AN_time = current time + validity time.
12.2. Completing TC Message Processing 12.2. Completing TC Message Processing
The TC message is processed as follows: The TC message is processed as follows:
1. the Topology Set is updated according to Section 12.2.1; 1. The Topology Set is updated according to Section 12.2.1.
2. the Attached Network Set is updated according to Section 12.2.2. 2. The Attached Network Set is updated according to Section 12.2.2.
12.2.1. Purging the Topology Set 12.2.1. Purging the Topology Set
The Topology Set MUST be updated as follows: The Topology Set MUST be updated as follows:
Any Topology Tuples with: Any Topology Tuples with:
o T_orig_addr == originator address; AND o T_orig_addr == originator address; AND
o T_seq_number < ANSN o T_seq_number < ANSN
skipping to change at page 43, line 5 skipping to change at page 45, line 5
The Attached Network Set MUST be updated as follows: The Attached Network Set MUST be updated as follows:
1. Any Attached Network Tuples with: 1. Any Attached Network Tuples with:
* AN_orig_addr == originator address; AND * AN_orig_addr == originator address; AND
* AN_seq_number < ANSN * AN_seq_number < ANSN
MUST be removed. MUST be removed.
13. Selecting MPRs 13. Information Base Changes
The Originator Set in the Local Information Base MUST be updated when
the node changes originator address. If there is no Originator Tuple
with:
o O_orig_addr == old originator address
then create an Originator Tuple with:
o O_orig_addr = old originator address
This Originator Tuple (existing or new) is then modified as follows:
o O_time = current time + O_HOLD_TIME
The Topology Information Base MUST be changed when an Advertising
Remote Node Tuple expires (AR_time is reached). The following
changes are required before the Advertising Remote Node Tuple is
removed:
1. All Topology Tuples with:
* T_orig_addr == AR_orig_addr of the Advertising Remote Node
Tuple
are removed.
2. All Attached Network Tuples with:
* AN_orig_addr == AR_orig_addr of the Advertising Remote Node
Tuple
are removed.
14. Selecting MPRs
Each node MUST select, from among its symmetric 1-hop neighbors, a Each node MUST select, from among its symmetric 1-hop neighbors, a
subset of nodes as MPRs. MPRs are used to flood control messages subset of nodes as MPRs. MPRs are used to flood control messages
from a node into the network while reducing the number of from a node into the network, while reducing the number of
retransmissions that will occur in a region. Thus, the concept of retransmissions that will occur in a region. Thus, the concept of
MPR is an optimization of a classical flooding mechanism. MPRs MAY MPR flooding is an optimization of a classical flooding mechanism.
also be used to reduce the shared topology information in the MPRs MAY also be used to reduce the shared topology information in
network. Consequently, while it is not essential that the set of the network. Consequently, while it is not essential that the set of
MPRs is minimal, keeping the number of MPRs small ensures that the MPRs is minimal, keeping the number of MPRs small ensures that the
overhead of OLSRv2 is kept at a minimum. overhead of OLSRv2 is kept at a minimum.
A node MUST select MPRs for each of its OLSRv2 interfaces, but then A node MUST select MPRs for each of its OLSRv2 interfaces, but then
forms the union of those sets as its single set of MPRs. This union forms the union of those sets as its single set of MPRs. This union
MUST include all symmetric 1-hop neighbors with willingness MUST include all symmetric 1-hop neighbors with willingness
WILL_ALWAYS. Only this overall set of MPRs is relevant and recorded, WILL_ALWAYS. Only this overall set of MPRs is relevant and recorded,
the MPR relationship is one of nodes, not interfaces. Nodes MAY the MPR relationship is one of nodes, not interfaces. Nodes MAY
select their MPRs by any process which satisfies the conditions which select their MPRs by any process which satisfies the conditions which
follow. Nodes can freely interoperate whether they use the same or follow. Nodes can freely interoperate whether they use the same or
skipping to change at page 44, line 10 skipping to change at page 47, line 10
nodes that either are, or are not, already selected as MPRs by other nodes that either are, or are not, already selected as MPRs by other
nodes. nodes.
The set of MPRs for each OLSRv2 interface can be selected using The set of MPRs for each OLSRv2 interface can be selected using
information from the Link Set and 2-Hop Set of that OLSRv2 interface, information from the Link Set and 2-Hop Set of that OLSRv2 interface,
and the Neighbor Set of the node (specifically the N_willingness and the Neighbor Set of the node (specifically the N_willingness
elements). The selection of MPRs (overall, not per OLSRv2 interface) elements). The selection of MPRs (overall, not per OLSRv2 interface)
is recorded in the Neighbor Set of the node (using the N_mpr is recorded in the Neighbor Set of the node (using the N_mpr
elements). A selected MPR MUST be in the node's symmetric 1-hop elements). A selected MPR MUST be in the node's symmetric 1-hop
neighborhood (i.e. the corresponding N_symmetric == true) and MUST neighborhood (i.e. the corresponding N_symmetric == true) and MUST
not have the corresponding N_willingness == WILL_NEVER. NOT have the corresponding N_willingness == WILL_NEVER.
A node MUST recalculate its MPRs whenever the currently selected set A node MUST recalculate its MPRs whenever the currently selected set
of MPRs does not still satisfy the required conditions. It MAY of MPRs does not still satisfy the required conditions. It MAY
recalculate its MPRs if the current set of MPRs is still valid, but recalculate its MPRs if the current set of MPRs is still valid, but
could be more efficient. It is sufficient to recalculate a node's could be more efficient. It is sufficient to recalculate a node's
MPRs when there is a change to any of the node's Link Sets affecting MPRs when there is a change to any of the node's Link Sets affecting
the symmetry of any link (addition or removal of a Link Tuple with the symmetry of any link (addition or removal of a Link Tuple with
L_status == SYMMETRIC, or change of any L_status to or from L_status == SYMMETRIC, or change of any L_status to or from
SYMMETRIC), any change to any of the node's 2-Hop Sets, or a change SYMMETRIC), any change to any of the node's 2-Hop Sets, or a change
of the N_willingness (to or from WILL_NEVER or to WILL_ALWAYS is of the N_willingness (to or from WILL_NEVER or to WILL_ALWAYS is
sufficient) of any Neighbor Tuple with N_symmetric == true. sufficient) of any Neighbor Tuple with N_symmetric == true.
An algorithm that creates a set of MPRs that satisfies the required An algorithm that creates a set of MPRs that satisfies the required
conditions is given in Appendix B. conditions is given in Appendix B.
14. Populating Derived Sets 15. Populating Derived Sets
The Relay Sets and the Advertised Neighbor Set of a node are denoted The Relay Sets and the Advertised Neighbor Set of a node are denoted
derived sets, since updates to these sets are not directly a function derived sets, since updates to these sets are not directly a function
of message exchanges, but rather are derived from updates to other of message exchanges, but rather are derived from updates to other
sets, in particular to the MPR selector status of other nodes sets, in particular to the MPR selector status of other nodes
recorded in the Neighbor Set. recorded in the Neighbor Set.
14.1. Populating the Relay Set 15.1. Populating the Relay Set
The Relay Set for an OLSRv2 interface contains the set of OLSRv2 The Relay Set for an OLSRv2 interface contains the set of OLSRv2
interface addresses of those symmetric 1-hop neighbors for which this interface addresses of those symmetric 1-hop neighbors for which this
OLSRv2 interface is to relay broadcast traffic. It MUST contain only OLSRv2 interface is to relay broadcast traffic. This set MUST
addresses of OLSRv2 interfaces with which this OLSRv2 interface has a contain only addresses of OLSRv2 interfaces with which this OLSRv2
symmetric link. It MUST include all such addresses of all such interface has a symmetric link. This set MUST include all such
OLSRv2 interfaces of nodes which are MPR selectors of this node. The addresses of all such OLSRv2 interfaces of nodes which are MPR
Relay Set for an OLSRv2 interface of this node is thus created by: selectors of this node. The Relay Set for an OLSRv2 interface of
this node is thus created by:
1. For each Link Tuple in the Link Set for this OLSRv2 interface 1. For each Link Tuple in the Link Set for this OLSRv2 interface
with L_status == SYMMETRIC, and the corresponding Neighbor Tuple with L_status == SYMMETRIC, and the corresponding Neighbor Tuple
with N_neighbor_iface_addr_list containing with N_neighbor_iface_addr_list containing
L_neighbor_iface_addr_list: L_neighbor_iface_addr_list:
1. All addresses from L_neighbor_iface_addr_list MUST be 1. All addresses from L_neighbor_iface_addr_list MUST be
included in the Relay Set of this OLSRv2 interface if included in the Relay Set of this OLSRv2 interface if
N_mpr_selector == true, and otherwise MAY be so included. N_mpr_selector == true, and otherwise MAY be so included.
14.2. Populating the Advertised Neighbor Set 15.2. Populating the Advertised Neighbor Set
The Advertised Neighbor Set of a node contains all interface The Advertised Neighbor Set of a node contains all interface
addresses of those symmetric 1-hop neighbors to which the node addresses of those symmetric 1-hop neighbors to which the node
advertises a link in its TC messages. This set MUST at least contain advertises a link in its TC messages. This set MUST include all
all addresses in all MPR selector of this node. The Advertised addresses in all MPR selector of this node. The Advertised Neighbor
Neighbor Set for this node is thus created by: Set for this node is thus created by:
1. For each Neighbor Tuple with N_symmetric == true: 1. For each Neighbor Tuple with N_symmetric == true:
1. All addresses from N_neighbor_iface_addr_list MUST be 1. All addresses from N_neighbor_iface_addr_list MUST be
included in the Advertised Neighbor Set if N_mpr_selector == included in the Advertised Neighbor Set if N_mpr_selector ==
true, and otherwise MAY be so included. true, and otherwise MAY be so included.
Whenever address(es) are added to or removed from the Advertised Whenever address(es) are added to or removed from the Advertised
Neighbor Set, its ANSN MUST be incremented. Neighbor Set, its ANSN MUST be incremented.
15. Routing Set Calculation 16. Routing Set Calculation
The Routing Set of a node is populated with Routing Tuples that The Routing Set of a node is populated with Routing Tuples that
represent paths from that node to all destinations in the network. represent paths from that node to all destinations in the network.
These paths are calculated based on the Network Topology Graph, which These paths are calculated based on the Network Topology Graph, which
is constructed from information in the information repositories, is constructed from information in the Information Bases, obtained
obtained via HELLO and TC message exchange. via HELLO and TC message exchange.
15.1. Network Topology Graph 16.1. Network Topology Graph
The Network Topology Graph is formed from information taken from the The Network Topology Graph is formed from information taken from the
node's Link Sets, Neighbor Set, Topology Set and Attached Network node's Link Sets, Neighbor Set, Topology Set and Attached Network
Set. The Network Topology Graph SHOULD also use information taken Set. The Network Topology Graph SHOULD also use information taken
from the node's 2-Hop Sets. The Network Topology Graph forms that from the node's 2-Hop Sets. The Network Topology Graph forms that
node's topological view of the network in form of a directed graph, node's topological view of the network in form of a directed graph,
containing the following arcs: containing the following arcs:
o Local symmetric links - all arcs X -> Y such that: o Local symmetric links - all arcs X -> Y such that:
skipping to change at page 47, line 30 skipping to change at page 50, line 30
* U is in the AR_iface_addr_list of the Advertising Remote Node * U is in the AR_iface_addr_list of the Advertising Remote Node
Tuple, AND; Tuple, AND;
* T is the AN_net_addr of the Attached Network Tuple. * T is the AN_net_addr of the Attached Network Tuple.
All links in the first three cases above have a hop count of one, the All links in the first three cases above have a hop count of one, the
symmetric 1-hop neighbor addresses have a hop count of zero, and the symmetric 1-hop neighbor addresses have a hop count of zero, and the
attached network addresses have a hop count given by the appropriate attached network addresses have a hop count given by the appropriate
value of AN_dist. value of AN_dist.
15.2. Populating the Routing Set 16.2. Populating the Routing Set
The Routing Set MUST contain the shortest paths for all destinations The Routing Set MUST contain the shortest paths for all destinations
from all local OLSRv2 interfaces using the Network Topology Graph. from all local OLSRv2 interfaces using the Network Topology Graph.
This calculation MAY use any algorithm, including any means of This calculation MAY use any algorithm, including any means of
choosing between paths of equal length. choosing between paths of equal length.
Using the notation of Section 15.1, each path will have as its first Using the notation of Section 16.1, each path will have as its first
arc a local symmetric link X -> Y. There will be a path for each arc a local symmetric link X -> Y. There will be a path for each
terminating Y, Z, V, W and T which can be connected to local OLSRv2 terminating Y, Z, V, W and T which can be connected to local OLSRv2
interface address X using the indicated arcs. The corresponding interface address X using the indicated arcs. The corresponding
Routing Tuple for this path will have: Routing Tuple for this path will have:
o R_dest_addr = the terminating Y, Z, V, W or T; o R_dest_addr = the terminating Y, Z, V, W or T;
o R_next_iface_addr = the first arc's Y; o R_next_iface_addr = the first arc's Y;
o R_dist = the total hop count of the path; o R_dist = the total hop count of the path;
o R_local_iface_addr = the first arc's X. o R_local_iface_addr = the first arc's X.
An example algorithm for calculating the Routing Set of a node is An example algorithm for calculating the Routing Set of a node is
given in Appendix C. given in Appendix C.
15.3. Routing Set Updates 16.3. Routing Set Updates
The Routing Set MUST be updated when changes in the Neighborhood The Routing Set MUST be updated when changes in the Neighborhood
Information Base or the Topology Information Base indicate a change Information Base or the Topology Information Base indicate a change
of the known symmetric links and/or attached networks in the MANET. of the known symmetric links and/or attached networks in the MANET.
It is sufficient to consider only changes which affect at least one It is sufficient to consider only changes which affect at least one
of: of:
o The Link Set of any OLSRv2 interface, and to consider only Link o The Link Set of any OLSRv2 interface, and to consider only Link
Tuples which have, or just had, L_status == SYMMETRIC (including Tuples which have, or just had, L_status == SYMMETRIC (including
removal of such Link Tuples). removal of such Link Tuples).
o The Neighbor Set of the node, and to consider only Neighbor Tuples o The Neighbor Set of the node, and to consider only Neighbor Tuples
that have, or just had, N_symmetric == true. that have, or just had, N_symmetric == true.
o The 2-Hop Set of any OLSRv2 interface. o The 2-Hop Set of any OLSRv2 interface.
o The Advertising Remote Node Set of the node.
o The Topology Set of the node. o The Topology Set of the node.
o The Attached Network Set of the node. o The Attached Network Set of the node.
Updates to the Routing Set do not generate or trigger any messages to Updates to the Routing Set do not generate or trigger any messages to
be transmitted. The state of the Routing Set SHOULD, however, be be transmitted. The state of the Routing Set SHOULD, however, be
reflected in the IP routing table by adding and removing entries from reflected in the IP routing table by adding and removing entries from
the IP routing table as appropriate. the IP routing table as appropriate.
16. Proposed Values for Parameters and Constants 17. Proposed Values for Parameters and Constants
OLSRv2 uses all parameters and constants defined in [4] and OLSRv2 uses all parameters and constants defined in [4] and
additional parameters and constants defined in this document. All additional parameters and constants defined in this document. All
but one (RX_HOLD_TIME) of these additional parameters are node but one (RX_HOLD_TIME) of these additional parameters are node
parameters as defined in [4]. These proposed values of the parameters as defined in [4]. These proposed values of the
additional parameters are appropriate to the case where all additional parameters are appropriate to the case where all
parameters (including those defined in [4]) have a single value. parameters (including those defined in [4]) have a single value.
Proposed values for parameters defined in [4] are given in that Proposed values for parameters defined in [4] are given in that
document. document.
16.1. Message Interval Parameters 17.1. Local History Time Parameters
o O_HOLD_TIME = 30 seconds
17.2. Message Interval Parameters
o TC_INTERVAL = 5 seconds o TC_INTERVAL = 5 seconds
o TC_MIN_INTERVAL = TC_INTERVAL/4 o TC_MIN_INTERVAL = TC_INTERVAL/4
16.2. Advertised Information Validity Time Parameters 17.3. Advertised Information Validity Time Parameters
o T_HOLD_TIME = 3 x TC_INTERVAL o T_HOLD_TIME = 3 x TC_INTERVAL
o A_HOLD_TIME = T_HOLD_TIME o A_HOLD_TIME = T_HOLD_TIME
16.3. Received Message Validity Time Parameters 17.4. Received Message Validity Time Parameters
o RX_HOLD_TIME = 30 seconds o RX_HOLD_TIME = 30 seconds
o P_HOLD_TIME = 30 seconds o P_HOLD_TIME = 30 seconds
o F_HOLD_TIME = 30 seconds o F_HOLD_TIME = 30 seconds
16.4. Jitter Time Parameters 17.5. Jitter Time Parameters
o TP_MAXJITTER = HP_MAXJITTER o TP_MAXJITTER = HP_MAXJITTER
o TT_MAXJITTER = HT_MAXJITTER o TT_MAXJITTER = HT_MAXJITTER
o F_MAXJITTER = TT_MAXJITTER o F_MAXJITTER = TT_MAXJITTER
16.5. Hop Limit Parameter 17.6. Hop Limit Parameter
o TC_HOP_LIMIT = 255 o TC_HOP_LIMIT = 255
16.6. Willingness Parameter and Constants 17.7. Willingness Parameter and Constants
o WILLINGNESS = WILL_DEFAULT o WILLINGNESS = WILL_DEFAULT
o WILL_NEVER = 0 o WILL_NEVER = 0
o WILL_DEFAULT = 3 o WILL_DEFAULT = 3
o WILL_ALWAYS = 7 o WILL_ALWAYS = 7
17. Sequence Numbers 18. Sequence Numbers
Sequence numbers are used in OLSRv2 with the purpose of discarding Sequence numbers are used in OLSRv2 with the purpose of discarding
"old" information, i.e. messages received out of order. However with "old" information, i.e. messages received out of order. However with
a limited number of bits for representing sequence numbers, wrap- a limited number of bits for representing sequence numbers, wrap-
around (that the sequence number is incremented from the maximum 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 OLSRv2, the following MUST be observed when with the operation of OLSRv2, the following MUST be observed when
determining the ordering of sequence numbers. determining the ordering of sequence numbers.
The term MAXVALUE designates in the following one more than the The term MAXVALUE designates in the following one more than the
skipping to change at page 52, line 5 skipping to change at page 55, line 5
o S2 > S1 AND S2 - S1 > MAXVALUE/2 o S2 > S1 AND S2 - S1 > MAXVALUE/2
When sequence numbers S1 and S2 differ by MAXVALUE/2 their ordering When sequence numbers S1 and S2 differ by MAXVALUE/2 their ordering
cannot be determined. In this case, which should not occur, either cannot be determined. In this case, which should not occur, either
ordering may be assumed. ordering may be assumed.
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.
18. IANA Considerations 19. Security Considerations
18.1. Message Types Currently, OLSRv2 does not specify any special security measures. As
a proactive routing protocol, OLSRv2 makes a target for various
attacks. The various possible vulnerabilities are discussed in this
section.
19.1. Confidentiality
Being a proactive protocol, OLSRv2 periodically MPR floods
topological information to all nodes in the network. Hence, if used
in an unprotected wireless network, the network topology is revealed
to anyone who listens to OLSRv2 control messages.
In situations where the confidentiality of the network topology is of
importance, regular cryptographic techniques, such as exchange of
OLSRv2 control traffic messages encrypted by PGP [8] or encrypted by
some shared secret key, can be applied to ensure that control traffic
can be read and interpreted by only those authorized to do so.
19.2. Integrity
In OLSRv2, each node is injecting topological information into the
network through transmitting HELLO messages and, for some nodes, TC
messages. If some nodes for some reason, malicious or malfunction,
inject invalid control traffic, network integrity may be compromised.
Therefore, message authentication is recommended.
Different such situations may occur, for instance:
1. a node generates TC messages, advertising links to non-neighbor
nodes;
2. a node generates TC messages, pretending to be another node;
3. a node generates HELLO messages, advertising non-neighbor nodes;
4. a node generates HELLO messages, pretending to be another node;
5. a node forwards altered control messages;
6. a node does not forward control messages;
7. a node does not select multipoint relays correctly;
8. a node forwards broadcast control messages unaltered, but does
not forward unicast data traffic;
9. a node "replays" previously recorded control traffic from another
node.
Authentication of the originator node for control messages (for
situations 2, 4 and 5) and on the individual links announced in the
control messages (for situations 1 and 3) may be used as a
countermeasure. However to prevent nodes from repeating old (and
correctly authenticated) information (situation 9) temporal
information is required, allowing a node to positively identify such
delayed messages.
In general, digital signatures and other required security
information may be transmitted as a separate OLSRv2 message type, or
signatures and security information may be transmitted within the
OLSRv2 HELLO and TC messages, using the TLV mechanism. Either option
permits that "secured" and "unsecured" nodes can coexist in the same
network, if desired,
Specifically, the authenticity of entire OLSRv2 control packets can
be established through employing IPsec authentication headers,
whereas authenticity of individual links (situations 1 and 3) require
additional security information to be distributed.
An important consideration is that all control messages in OLSRv2 are
transmitted either to all nodes in the neighborhood (HELLO messages)
or broadcast to all nodes in the network (TC messages).
For example, a control message in OLSRv2 is always a point-to-
multipoint transmission. It is therefore important that the
authentication mechanism employed permits that any receiving node can
validate the authenticity of a message. As an analogy, given a block
of text, signed by a PGP private key, then anyone with the
corresponding public key can verify the authenticity of the text.
19.3. Interaction with External Routing Domains
OLSRv2 does, through the use of TC messages, provide a basic
mechanism for injecting external routing information to the OLSRv2
domain. Appendix A also specifies that routing information can be
extracted from the topology table or the routing table of OLSRv2 and,
potentially, injected into an external domain if the routing protocol
governing that domain permits.
Other than as described in Appendix A, when operating nodes
connecting OLSRv2 to an external routing domain, care MUST be taken
not to allow potentially insecure and untrustworthy information to be
injected from the OLSRv2 domain to external routing domains. Care
MUST be taken to validate the correctness of information prior to it
being injected as to avoid polluting routing tables with invalid
information.
A recommended way of extending connectivity from an existing routing
domain to an OLSRv2 routed MANET is to assign an IP prefix (under the
authority of the nodes/gateways connecting the MANET with the exiting
routing domain) exclusively to the OLSRv2 MANET area, and to
configure the gateways statically to advertise routes to that IP
sequence to nodes in the existing routing domain.
20. IANA Considerations
20.1. Message Types
OLSRv2 defines one message type, which must be allocated from the OLSRv2 defines one message type, which must be allocated from the
"Assigned Message Types" repository of [1]. "Assigned Message Types" repository of [1].
+------+-------+--------------------------------------+ +------+-------+-------------------------------------+
| Name | Value | Description | | Name | Value | Description |
+------+-------+--------------------------------------+ +------+-------+-------------------------------------+
| TC | TBD | Topology Control (global signaling) | | TC | TBD1 | Topology Control (global signaling) |
+------+-------+--------------------------------------+ +------+-------+-------------------------------------+
Table 5 Table 5
18.2. TLV Types 20.2. TLV Types
OLSRv2 defines three message TLV types, which must be allocated from OLSRv2 defines two message TLV types, which must be allocated from
the "Assigned message TLV Types" repository of [1]. the "Assigned message TLV Types" repository of [1].
+--------------+------+---------+-----------------------------------+ +--------------+------+----------------+----------------------------+
| Name | Type | Subtype | Description | | Name | Type | Type extension | Description |
+--------------+------+---------+-----------------------------------+ +--------------+------+----------------+----------------------------+
| WILLINGNESS | TBD | 0 | Specifies the originating node's | | WILLINGNESS | TBD2 | 0 | Specifies the originating |
| | | | willingness to act as a relay and | | | | | node's willingness to act |
| | | | to partake in network formation | | | | | as a relay and to partake |
| | | | | | | | | in network formation |
| | TBD | 1-255 | RESERVED |
| | | | | | | | | |
| CONT_SEQ_NUM | TBD | 0 | Specifies a content sequence | | | | 1-255 | RESERVED |
| | | | number for this message |
| | | | | | | | | |
| | TBD | 1-255 | RESERVED | | CONT_SEQ_NUM | TBD3 | 0 (COMPLETE) | Specifies a content |
| | | | sequence number for this |
| | | | complete message |
| | | | | | | | | |
| INCOMPLETE | TBD | 0 | Specifies that this message is | | | | 1 (INCOMPLETE) | Specifies a content |
| | | | incomplete | | | | | sequence number for this |
| | | | incomplete message |
| | | | | | | | | |
| | TBD | 1-255 | RESERVED | | | | 2-255 | RESERVED |
+--------------+------+---------+-----------------------------------+ +--------------+------+----------------+----------------------------+
Table 6 Table 6
Subtypes indicated as RESERVED may be allocated by standards action, Type extensions indicated as RESERVED may be allocated by standards
as specified in [7]. action, as specified in [6].
OLSRv2 defines two Address Block TLV types, which must be allocated OLSRv2 defines two Address Block TLV types, which must be allocated
from the "Assigned address block TLV Types" repository of [1]. from the "Assigned address block TLV Types" repository of [1].
+---------+------+---------+----------------------------------------+ +---------+------+-----------+--------------------------------------+
| Name | Type | Subtype | Description | | Name | Type | Type | Description |
+---------+------+---------+----------------------------------------+ | | | extension | |
| MPR | TBD | 0 | Specifies that a given address is of a | +---------+------+-----------+--------------------------------------+
| | | | node selected as an MPR | | MPR | TBD4 | 0 | Specifies that a given address is of |
| | | | a node selected as an MPR |
| | | | | | | | | |
| | TBD | 1-255 | RESERVED | | | | 1-255 | RESERVED |
| | | | | | | | | |
| GATEWAY | TBD | 0 | Specifies that a given address is | | GATEWAY | TBD5 | 0 | Specifies that a given address is |
| | | | reached via a gateway on the | | | | | reached via a gateway on the |
| | | | originating node | | | | | originating node |
| | | | | | | | | |
| | TBD | 1-255 | RESERVED | | | | 1-255 | RESERVED |
+---------+------+---------+----------------------------------------+ +---------+------+-----------+--------------------------------------+
Table 7 Table 7
Subtypes indicated as RESERVED may be allocated by standards action, Type extensions indicated as RESERVED may be allocated by standards
as specified in [7]. action, as specified in [6].
19. References 21. References
19.1. Normative References 21.1. Normative References
[1] Clausen, T., Dean, J., Dearlove, C., and C. Adjih, "Generalized [1] Clausen, T., Dean, J., Dearlove, C., and C. Adjih, "Generalized
MANET Packet/Message Format", work in MANET Packet/Message Format", work in
progress draft-ietf-manet-packetbb-08.txt, July 2007. progress draft-ietf-manet-packetbb-11.txt, November 2007.
[2] Clausen, T. and C. Dearlove, "Representing multi-value time in [2] Clausen, T. and C. Dearlove, "Representing multi-value time in
MANETs", Work In Progress draft-ietf-manet-timetlv-01.txt, MANETs", Work In Progress draft-ietf-manet-timetlv-04.txt,
June 2007. November 2007.
[3] Clausen, T., Dearlove, C., and B. Adamson, "Jitter [3] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
considerations in MANETs", Work In considerations in MANETs", Work In
Progress draft-ietf-manet-jitter-01.txt, June 2007. Progress draft-ietf-manet-jitter-04.txt, December 2007.
[4] Clausen, T., Dean, J., and C. Dearlove, "MANET Neighborhood [4] Clausen, T., Dean, J., and C. Dearlove, "MANET Neighborhood
Discovery Protocol (NHDP)", work in Discovery Protocol (NHDP)", work in
progress draft-ietf-manet-nhdp-04.txt, June 2007. progress draft-ietf-manet-nhdp-05.txt, December 2007.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[6] Chakeres, I., "Internet Assigned Numbers Authority (IANA) [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Allocations for the Mobile Ad hoc Networks (MANET) Working Considerations Section in RFCs", RFC 2434, BCP 26,
Group", Work In Progress draft-ietf-manet-iana-05.txt, October 1998.
June 2007.
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", October 1998.
19.2. Informative References 21.2. Informative References
[8] Clausen, T. and P. Jacquet, "The Optimized Link State Routing [7] Clausen, T. and P. Jacquet, "The Optimized Link State Routing
Protocol", RFC 3626, October 2003. Protocol", RFC 3626, October 2003.
[9] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message [8] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
Exchange Formats", RFC 1991, August 1996. "OpenPGP message format", RFC 4880, November 2007.
[10] ETSI, "ETSI STC-RES10 Committee. Radio equipment and systems: [9] ETSI, "ETSI STC-RES10 Committee. Radio equipment and systems:
HIPERLAN type 1, functional specifications ETS 300-652", HIPERLAN type 1, functional specifications ETS 300-652",
June 1996. June 1996.
[11] Jacquet, P., Minet, P., Muhlethaler, P., and N. Rivierre, [10] Jacquet, P., Minet, P., Muhlethaler, P., and N. Rivierre,
"Increasing reliability in cable free radio LANs: Low level "Increasing reliability in cable free radio LANs: Low level
forwarding in HIPERLAN.", 1996. forwarding in HIPERLAN.", 1996.
[12] Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint relaying: [11] Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint relaying:
An efficient technique for flooding in mobile wireless An efficient technique for flooding in mobile wireless
networks.", 2001. networks.", 2001.
[13] Macker, J. and S. Corson, "Mobile Ad hoc Networking (MANET): [12] Macker, J. and S. Corson, "Mobile Ad hoc Networking (MANET):
Routing Protocol Performance Issues and Evaluation Routing Protocol Performance Issues and Evaluation
Considerations", RFC 2501, January 1999. Considerations", RFC 2501, January 1999.
[13] Pei, G., Gerla, M., and T. Chen, "Fisheye state routing in
mobile ad hoc networks", 2000.
[14] Santivanez, C., Ramanathan, R., and I. Stavrakakis, "Making
link-state routing scale for ad hoc networks", 2000.
Appendix A. Node Configuration Appendix A. Node Configuration
OLSRv2 does not make any assumption about node addresses, other than OLSRv2 does not make any assumption about node addresses, other than
that each node is assumed to have at least one unique and routable IP that each node is assumed to have at least one unique and routable IP
address for each interface that it has which participates in the address for each interface that it has which participates in the
MANET. MANET.
When applicable, a recommended way of connecting an OLSRv2 network to When applicable, a recommended way of connecting an OLSRv2 network to
an existing IP routing domain is to assign an IP prefix (under the an existing IP routing domain is to assign an IP prefix (under the
authority of the nodes/gateways connecting the MANET with the routing authority of the nodes/gateways connecting the MANET with the routing
skipping to change at page 58, line 10 skipping to change at page 64, line 10
OLSRv2 interface I: OLSRv2 interface I:
N(I) - The set of symmetric 1-hop neighbors which have a symmetric N(I) - The set of symmetric 1-hop neighbors which have a symmetric
link to I. link to I.
N2(I) - The set of addresses of interfaces of a node with a N2(I) - The set of addresses of interfaces of a node with a
symmetric link to a node in N(I) (i.e. the set of symmetric link to a node in N(I) (i.e. the set of
N2_2hop_iface_addr in 2-Hop Tuples in the 2-Hop Set for OLSRv2 N2_2hop_iface_addr in 2-Hop Tuples in the 2-Hop Set for OLSRv2
interface I). interface I).
Connected to I via Y - An address A in D2(I) is connected to I via a Connected to I via Y - An address A in N2(I) is connected to I via a
node Y in N(I) if A is an address of an interface of a symmetric node Y in N(I) if A is an address of an interface of a symmetric
1-hop neighbor of Y (i.e. A is the N2_2hop_iface_addr in a 2-Hop 1-hop neighbor of Y (i.e. A is the N2_2hop_iface_addr in a 2-Hop
Tuple in the 2-Hop Set for OLSRv2 interface I, and whose Tuple in the 2-Hop Set for OLSRv2 interface I, and whose
N2_neighbor_iface_addr_list is contained in the set of interface N2_neighbor_iface_addr_list is contained in the set of interface
addresses of Y). addresses of Y).
D(Y, I) - For a node Y in N(I), the number of addresses in D2(I) D(Y, I) - For a node Y in N(I), the number of addresses in N2(I)
which are connected to I via Y. which are connected to I via Y.
R(Y, I): - For a node Y in N(I), the number of addresses in D2(I) R(Y, I): - For a node Y in N(I), the number of addresses in N2(I)
which are connected to I via Y, but are not connected to I via any which are connected to I via Y, but are not connected to I via any
node which has already been selected as an MPR. node which has already been selected as an MPR.
B.2. MPR Selection Algorithm for each OLSRv2 Interface B.2. MPR Selection Algorithm for each OLSRv2 Interface
When selecting MPRs for the OLSRv2 interface I: When selecting MPRs for the OLSRv2 interface I:
1. For each address A in N2(I) for which there is only one node Y in 1. For each address A in N2(I) for which there is only one node Y in
N(I) such that A is connected to I via Y, select that node Y as N(I) such that A is connected to I via Y, select that node Y as
an MPR (i.e. set N_mpr = true in the Neighbor Tuple corresponding an MPR (i.e. set N_mpr = true in the Neighbor Tuple corresponding
skipping to change at page 58, line 45 skipping to change at page 64, line 45
1. Select a node Y in N(I) with R(Y, I) > 0 in the following 1. Select a node Y in N(I) with R(Y, I) > 0 in the following
order of priority: order of priority:
+ greatest N_willingness in the Neighbor Tuple corresponding + greatest N_willingness in the Neighbor Tuple corresponding
to Y, THEN; to Y, THEN;
+ greatest R(Y, I), THEN; + greatest R(Y, I), THEN;
+ greatest D(Y, I), THEN; + greatest D(Y, I), THEN;
+ N_mpr_selector is equal to true, if possible, THEN;
+ any choice. + any choice.
2. Select Y as an MPR (i.e. set N_mpr = true in the Neighbor 2. Select Y as an MPR (i.e. set N_mpr = true in the Neighbor
Tuple corresponding to Y). Tuple corresponding to Y).
Appendix C. Example Algorithm for Calculating the Routing Set Appendix C. Example Algorithm for Calculating the Routing Set
The following procedure is given as an example for calculating the The following procedure is given as an example for calculating the
Routing Set using a variation of Dijkstra's algorithm. First all Routing Set using a variation of Dijkstra's algorithm. First all
Routing Tuples are removed, and then the procedures in the following Routing Tuples are removed, and then the procedures in the following
skipping to change at page 60, line 35 skipping to change at page 66, line 35
* R_next_iface_addr = R_next_iface_addr of the previous Routing * R_next_iface_addr = R_next_iface_addr of the previous Routing
Tuple; Tuple;
* R_dist = h+1; * R_dist = h+1;
* R_local_iface_addr = R_local_iface_addr of the previous * R_local_iface_addr = R_local_iface_addr of the previous
Routing Tuple. Routing Tuple.
More than one Topology Tuple may be usable to select the next hop More than one Topology Tuple may be usable to select the next hop
R_next_iface_addr for reaching the address R_dest_addr. When h R_next_iface_addr for reaching the address R_dest_addr. Ties
== 1, ties should be broken such that nodes with greater should be broken such that nodes with greater willingness are
willingness are preferred, and between nodes of equal preferred, and between nodes of equal willingness, MPR selectors
willingness, MPR selectors are preferred over non-MPR selectors. are preferred over non-MPR selectors.
2. After the above iteration has completed, if h == 1, for each 2. After the above iteration has completed, if h == 1, for each
2-Hop Neighbor Tuple where: 2-Hop Neighbor Tuple where:
* N2_2hop_iface_addr is not equal to R_dest_addr of any Routing * N2_2hop_iface_addr is not equal to R_dest_addr of any Routing
Tuple, AND; Tuple, AND;
* The Neighbor Tuple whose N_neighbor_iface_addr_list contains * The Neighbor Tuple whose N_neighbor_iface_addr_list contains
N2_neighbor_iface_addr_list has N_willingness not equal to N2_neighbor_iface_addr_list has N_willingness not equal to
WILL_NEVER WILL_NEVER
skipping to change at page 61, line 15 skipping to change at page 67, line 15
* R_dest_addr = N2_2hop_iface_addr; * R_dest_addr = N2_2hop_iface_addr;
* R_next_iface_addr = R_next_iface_addr of the previous Routing * R_next_iface_addr = R_next_iface_addr of the previous Routing
Tuple; Tuple;
* R_dist = 2; * R_dist = 2;
* R_local_iface_addr = R_local_iface_addr of the previous * R_local_iface_addr = R_local_iface_addr of the previous
Routing Tuple. Routing Tuple.
More than one 2-Hop Neighbor Tuple may be usable to select the
next hop R_next_iface_addr for reaching the address R_dest_addr.
Ties should be broken such that nodes with greater willingness
are preferred, and between nodes of equal willingness, MPR
selectors are preferred over non-MPR selectors.
C.3. Add Attached Networks C.3. Add Attached Networks
1. For each Attached Network Tuple, if for the Advertising Remote 1. For each Attached Network Tuple, if for the Advertising Remote
Node Tuple with AR_orig_addr == AN_orig_addr, there is an address Node Tuple with AR_orig_addr == AN_orig_addr, there is an address
in the AR_iface_addr_list which is equal to the R_dest_addr of a in the AR_iface_addr_list which is equal to the R_dest_addr of a
Routing Tuple (the "previous Routing Tuple"), then: Routing Tuple (the "previous Routing Tuple"), then:
1. If there is no Routing Tuple with R_dest_addr == AN_net_addr, 1. If there is no Routing Tuple with R_dest_addr == AN_net_addr,
then add a new Routing Tuple with: then add a new Routing Tuple with:
skipping to change at page 62, line 5 skipping to change at page 68, line 5
the current Routing Tuple by: the current Routing Tuple by:
+ R_next_iface_addr = R_next_iface_addr of the previous + R_next_iface_addr = R_next_iface_addr of the previous
Routing Tuple; Routing Tuple;
+ R_dist = (R_dist of the previous Routing Tuple) + AN_dist; + R_dist = (R_dist of the previous Routing Tuple) + AN_dist;
+ R_local_iface_addr = R_local_iface_addr of the previous + R_local_iface_addr = R_local_iface_addr of the previous
Routing Tuple. Routing Tuple.
Appendix D. Packet and Message Layout Appendix D. Example Message Layout
This appendix illustrates the translation from the abstract
descriptions of packets employed in the protocol specification, and
the bit-layout packets actually exchanged between the nodes.
Appendix D.1. Packet and Message Options
The basic layout of an OLSRv2 packet is as described in [1]. However
the following points should be noted.
In the following figures, reserved bits marked Reserved or Resv MUST
be cleared ('0'). Octets indicated as Padding are optional and MAY
be omitted; if not omitted they SHOULD be used to pad to a 32 bit
boundary and MUST all be zero.
OLSRv2 uses only packets with a packet header including a packet
sequence number, either with or without a packet TLV block. Thus all
OLSRv2 packets have the layout of either
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Reserved |0|0| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message + Padding |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message + Padding |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Reserved |1|0| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Packet TLV Block |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message + Padding |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message + Padding |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OLSRv2 uses only messages with a complete message header. Thus all
OLSRv2 messages, plus padding if any, have the following layout.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Rsv |N|0|0|0|0| Message Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In standard OLSRv2 messages (HELLO and TC) the type dependent
sequence number bit marked N MUST be cleared ('0').
The layouts of the message body, address block, TLV block and TLV are
as in [1], allowing all options. Standard (HELLO and TC) messages
contain a first address block which contains local interface address
information, all other address blocks contain neighbor interface
address information (or, for a TC message, address information for
which it is a gateway) specific to the message type.
Appendix D.2. Example HELLO Message
An example HELLO message, using IPv4 (four octet) addresses is as
follows. The overall message length is 58 octets. The message has a
hop limit of 1 and a hop count of 0, as sent by its originator.
The message has a message TLV block with content length 12 octets
containing three message TLVs. These TLVs represent message validity
time, message interval time and willingness. Each uses a TLV with
semantics value 8, indicating no start and stop indexes are included,
and each has a value length of 1 octet.
The first address block contains 1 local interface address. The
semantics octet 2 indicates it has no tail section. It has head
length 4, this is equal to the address length, it thus has no mid
section. This address block has no TLVs (TLV block content length is
0 octets).
The second, and last, address block includes 4 neighbor interface
addresses. The semantics octet 2 indicates they have no tail
section. The addresses have head length 3 octets, thus each mid
section is of length one octet. The following address TLV block
(content length 11 octets) includes two TLVs.
The first of these TLVs reports the link status of all four neighbors
in a single multivalue TLV, the first two addresses are HEARD, the
last two addresses are SYMMETRIC. The TLV semantics octet value of
40 indicates, in addition to that this is a multivalue TLV, that no
start index and stop index are included, hence values for all
addresses are included. The TLV value length of 4 octets indicates
one octet per value per address.
The second of these TLVs indicates that the last address (start index
3, stop index 3) is an MPR. This TLV has no value, or value length,
fields, as indicated by its semantics octet being equal to 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HELLO |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 1 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0| VALIDITY_TIME |0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Value | INTERVAL_TIME |0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Value | WILLINGNESS |0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Value |0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 1| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid |0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1| LINK_STATUS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 1 0 0 0|0 0 0 0 0 1 0 0| HEARD | HEARD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SYMMETRIC | SYMMETRIC | MPR |0 0 0 0 0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1|0 0 0 0 0 0 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix D.3. Example TC Message
An example TC message, using IPv4 (four octet) addresses, is as An example TC message, using IPv4 (four octet) addresses, is as
follows. The overall message length is 67 octets. follows. The overall message length is 65 octets.
The message has a message TLV block with content length 13 octets The message has a message TLV block with content length 13 octets
containing three TLVs. The first two TLVs are validity and interval containing three TLVs. The first two TLVs are validity and interval
times as for the HELLO message above. The third TLV is a content times for the message. The third TLV is the content sequence number
sequence number TLV used to carry the 2 octet ANSN. The semantics TLV used to carry the 2 octet ANSN, and (with default type extension
value is also 8. zero, i.e. COMPLETE) indicating that the TC message is complete.
Each TLV uses a TLV with semantics value 8, indicating no type
extension or start and stop indexes are included. The first two TLVs
have a value length of 1 octet, the last has a value length of 2
octets.
The message has three address blocks. The first address block The message has two address blocks. The first address block contains
contains 3 local interface addresses (with semantics octet 2, hence 6 addresses (with semantics octet 2, hence no tail section, head
no tail section, head length 2 octets, and hence mid sections with length 2 octets, and hence mid sections with length two octets). The
length two octets) and has no TLVs (TLV block content length 0 following TLV block (content length 6 octets) contains a single
octets). LOCAL_IF TLV (semantics value 0) indicating that the first three
addresses (indexes 0 to 2) are associated with the value (length 1
octet) UNSPEC_IF, i.e. they are the originating node's local
interface addresses. The remaining three addresses have no
associated TLV, they are the interface addresses of advertised
neighbors.
The other two address blocks contain neighbor interface addresses. The second address block contains 1 address, with semantics octet 12
The first contains 3 addresses (semantics octet 2, no tail section, indicating that the tail section, length 2 octets, consists of zero
head length 2 octets, hence mid sections length two octets) and has valued octets (not included), and that there is a single prefix
no TLVs (TLV block content length 0 octets). The second contains 1 length, 16. The network address is thus Head.0.0/16. The following
address, with semantics octet 4 indicating that the tail section, TLV block (content length 8 octets) includes one TLV that indicates
length 2 octets, consists of zero valued octets (not included). The that the originating node is a gateway to this network, at a given
following TLV block (content length 6 octets) includes two TLVs, the number of hops distance (value length 1 octet). The TLV semantics
first (semantics value 8 indicating no indexes are needed) indicates value of 8 indicates that no indexes are needed.
that the address has a netmask, with length given by the value (of
length 1 octet) of 16. Thus this address is Head.0.0/16. The second
TLV indicates that the originating node is a gateway to this network,
at a given number of hops distance. The TLV semantics value of 8
indicates that no indexes are needed.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TC |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0| | TC |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address | | Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | Hop Count | Message Sequence Number | | Hop Limit | Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1| VALIDITY_TIME |0 0 0 0 1 0 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1| VALIDITY_TIME |0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Value | INTERVAL_TIME |0 0 0 0 1 0 0 0| |0 0 0 0 0 0 0 1| Value | INTERVAL_TIME |0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1| Value | CONT_SEQ_NUM |0 0 0 0 1 0 0 0| |0 0 0 0 0 0 0 1| Value | CONT_SEQ_NUM |0 0 0 0 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Value (ANSN) |0 0 0 0 0 0 1 1| |0 0 0 0 0 0 1 0| Value (ANSN) |0 0 0 0 0 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 |0 0 0 0 0 0 1 0| Head | |0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 0| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Mid | | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1| 0x02 |0 0 0 0 0 0 1 0| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (cont) | Mid | Mid | | Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid (cont) | Mid |0 0 0 0 0 0 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0| LOCAL_IF |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0|0 0 0 0 0 0 1 0| |0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1| UNSPEC_IF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head |0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 0| |0 0 0 0 0 0 0 1|0 0 0 0 1 1 0 0|0 0 0 0 0 0 1 0| Head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 1| PREFIX_LENGTH |0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 1| | Head (cont) |0 0 0 0 0 0 1 0|0 0 0 1 0 0 0 0|0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 0 0 0| GATEWAY |0 0 0 0 1 0 0 0| Number Hops | |0 0 0 0 0 1 0 0| GATEWAY |0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number Hops |
+-+-+-+-+-+-+-+-+
Appendix E. Constraints Appendix E. Constraints
Any process which updates the Local Information Base, the Any process which updates the Local Information Base, the
Neighborhood Information Base or the Topology Information Base MUST Neighborhood Information Base or the Topology Information Base MUST
ensure that all constraints specified in this appendix are ensure that all constraints specified in this appendix are
maintained, as well as those specified in [4]. maintained, as well as those specified in [4].
In each Originator Tuple:
o O_orig_addr MUST NOT equal any other O_orig_addr.
o O_orig_addr MUST NOT equal this node's originator address.
In each Local Attached Network Tuple: In each Local Attached Network Tuple:
o AL_net_addr MUST NOT equal any other AL_net_addr.
o AL_net_addr MUST NOT be in the I_local_iface_addr_list of any o AL_net_addr MUST NOT be in the I_local_iface_addr_list of any
Local Interface Tuple. Local Interface Tuple or be equal to the IR_local_iface_addr of
any Removed Interface Address Tuple.
o AL_dist MUST NOT be less than zero. o AL_dist MUST NOT be less than zero.
In each Link Tuple: In each Link Tuple:
o L_neighbor_iface_addr_list MUST NOT contain the AL_net_addr of any o L_neighbor_iface_addr_list MUST NOT contain the AL_net_addr of any
Local Attached Network Tuple. Local Attached Network Tuple.
o If L_status == SYMMETRIC and the Neighbor Tuple whose o If L_status == SYMMETRIC and the Neighbor Tuple whose
N_neighbor_iface_addr_list contains L_neighbor_iface_addr_list has N_neighbor_iface_addr_list contains L_neighbor_iface_addr_list has
skipping to change at page 69, line 15 skipping to change at page 71, line 23
o NL_neighbor_iface_addr MUST NOT equal the AL_net_addr of any Local o NL_neighbor_iface_addr MUST NOT equal the AL_net_addr of any Local
Attached Network Tuple. Attached Network Tuple.
In each 2-Hop Tuple: In each 2-Hop Tuple:
o N2_2hop_iface_addr MUST NOT equal the AL_net_addr of any Local o N2_2hop_iface_addr MUST NOT equal the AL_net_addr of any Local
Attached Network Tuple. Attached Network Tuple.
In each Received Tuple: In each Received Tuple:
o RX_orig_addr SHOULD NOT be in the I_local_iface_addr_list of any o RX_orig_addr MUST NOT equal this node's originator address or any
Local Interface Tuple. O_orig_addr.
o RX_orig_addr SHOULD NOT equal the AL_net_addr of any Local
Attached Network Tuple.
o Each ordered triple (RX_type, RX_orig_addr, RX_seq_number) SHOULD o Each ordered triple (RX_type, RX_orig_addr, RX_seq_number) MUST
NOT equal the corresponding triple in any other Received Tuple in NOT equal the corresponding triple in any other Received Tuple in
the same Received Set. the same Received Set.
In each Processed Tuple: In each Processed Tuple:
o P_orig_addr SHOULD NOT be in the I_local_iface_addr_list of any o P_orig_addr MUST NOT equal this node's originator address or any
Local Interface Tuple. O_orig_addr.
o P_orig_addr SHOULD NOT equal the AL_net_addr of any Local Attached
Network Tuple.
o Each ordered triple (P_type, P_orig_addr, P_seq_number) SHOULD NOT o Each ordered triple (P_type, P_orig_addr, P_seq_number) MUST NOT
equal the corresponding triple in any other Processed Tuple. equal the corresponding triple in any other Processed Tuple.
In each Forwarded Tuple: In each Forwarded Tuple:
o F_orig_addr SHOULD NOT be in the I_local_iface_addr_list of any o F_orig_addr MUST NOT equal this node's originator address or any
Local Interface Tuple. O_orig_addr.
o F_orig_addr SHOULD NOT equal the AL_net_addr of any Local Attached
Network Tuple.
o Each ordered triple (F_type, F_orig_addr, F_seq_number) SHOULD NOT o Each ordered triple (F_type, F_orig_addr, F_seq_number) MUST NOT
equal the corresponding triple in any other Forwarded Tuple. equal the corresponding triple in any other Forwarded Tuple.
In each Relay Set: In each Relay Tuple:
o Each RY_neighbor_iface_addr SHOULD NOT equal any other o RY_neighbor_iface_addr MUST NOT equal the RY_neighbor_iface_addr
RY_neighbor_iface_addr. in any other Relay Tuple in the same Relay Set.
o Each RY_neighbor_iface_addr MUST be in the o RY_neighbor_iface_addr MUST be in the L_neighbor_iface_addr_list
L_neighbor_iface_addr_list of a Link Tuple with L_status == of a Link Tuple with L_status == SYMMETRIC.
SYMMETRIC.
In the Advertised Neighbor Set: In each Advertised Neighbor Tuple:
o Each A_neighbor_iface_addr MUST NOT equal any other o A_neighbor_iface_addr MUST NOT equal the A_neighbor_iface_addr of
A_neighbor_iface_addr. any other Advertised Neighbor Tuple.
o Each A_neighbor_iface_addr MUST be in the o A_neighbor_iface_addr MUST be in the N_neighbor_iface_addr_list of
N_neighbor_iface_addr_list of a Neighbor Tuple with N_symmetric == a Neighbor Tuple with N_symmetric == true.
true.
In each Advertising Remote Node Tuple: In each Advertising Remote Node Tuple:
o AR_orig_addr SHOULD NOT be in the I_local_iface_addr_list of any o AR_orig_addr MUST NOT equal this node's originator address or any
Local Interface Tuple. O_orig_addr.
o AR_orig_addr SHOULD NOT equal the AL_net_addr of any Local o AR_orig_addr MUST NOT equal the AR_orig_addr in any other ANSN
Attached Network Tuple. History Tuple.
o Each AR_orig_addr MUST NOT equal the AR_orig_addr in any other o AR_iface_addr_list MUST NOT be empty.
ANSN History Tuple.
o AR_iface_addr_list MUST NOT contain any duplicated addresses.
o AR_iface_addr_list MUST NOT contain any address which is in the o AR_iface_addr_list MUST NOT contain any address which is in the
I_local_iface_addr_list of any Local Interface Tuple. I_local_iface_addr_list of any Local Interface Tuple or be equal
to the IR_local_iface_addr of any Removed Interface Address Tuple.
o AR_iface_addr_list MUST NOT contain any address which is the o AR_iface_addr_list MUST NOT contain any address which is the
AL_net_addr of any Local Attached Network Tuple. AL_net_addr of any Local Attached Network Tuple.
In each Topology Tuple: In each Topology Tuple:
o T_dest_iface_addr MUST NOT be in the I_local_iface_addr_list of o T_dest_iface_addr MUST NOT be in the I_local_iface_addr_list of
any Local Interface Tuple. any Local Interface Tuple or be equal to the IR_local_iface_addr
of any Removed Interface Address Tuple.
o T_dest_iface_addr MUST NOT equal the AL_net_addr of any Local o T_dest_iface_addr MUST NOT equal the AL_net_addr of any Local
Attached Network Tuple. Attached Network Tuple.
o There MUST be an Advertising Remote Node Tuple with AR_orig_addr o There MUST be an Advertising Remote Node Tuple with AR_orig_addr
== T_orig_addr. == T_orig_addr.
o T_dest_iface_addr MUST NOT be in the AR_iface_addr_list of the o T_dest_iface_addr MUST NOT be in the AR_iface_addr_list of the
Advertising Remote Node Tuple with AR_orig_addr == T_orig_addr. Advertising Remote Node Tuple with AR_orig_addr == T_orig_addr.
o T_seq_number MUST NOT be greater than AR_seq_number of the o T_seq_number MUST NOT be greater than AR_seq_number of the
Advertising Remote Node Tuple with AR_orig_addr == T_orig_addr. Advertising Remote Node Tuple with AR_orig_addr == T_orig_addr.
o The ordered pair (T_dest_iface_addr, T_orig_addr) MUST NOT equal o The ordered pair (T_dest_iface_addr, T_orig_addr) MUST NOT equal
the corresponding pair in any other Topology Tuple. the corresponding pair in any other Topology Tuple.
In each Attached Network Tuple: In each Attached Network Tuple:
o AN_net_addr MUST NOT be in the I_local_iface_addr_list of any o AN_net_addr MUST NOT be in the I_local_iface_addr_list of any
Local Interface Tuple. Local Interface Tuple or be equal to the IR_local_iface_addr of
any Removed Interface Address Tuple.
o AN_net_addr MUST NOT equal the AL_net_addr of any Local Attached o AN_net_addr MUST NOT equal the AL_net_addr of any Local Attached
Network Tuple. Network Tuple.
o There MUST be an Advertising Remote Node Tuple with AR_orig_addr o There MUST be an Advertising Remote Node Tuple with AR_orig_addr
== AN_orig_addr. == AN_orig_addr.
o AN_seq_number MUST NOT be greater than AR_seq_number of the o AN_seq_number MUST NOT be greater than AR_seq_number of the
Advertising Remote Node Tuple with AR_orig_addr == AN_orig_addr. Advertising Remote Node Tuple with AR_orig_addr == AN_orig_addr.
o AN_dist MUST NOT be less than zero. o AN_dist MUST NOT be less than zero.
o The ordered pair (AN_net_addr, AN_orig_addr) MUST NOT equal the o The ordered pair (AN_net_addr, AN_orig_addr) MUST NOT equal the
corresponding pair in any other Attached Network Tuple. corresponding pair in any other Attached Network Tuple.
Appendix F. Security Considerations Appendix F. Flow and Congestion Control
Currently, OLSRv2 does not specify any special security measures. As
a proactive routing protocol, OLSRv2 makes a target for various
attacks. The various possible vulnerabilities are discussed in this
section.
Appendix F.1. Confidentiality
Being a proactive protocol, OLSRv2 periodically diffuses topological
information. Hence, if used in an unprotected wireless network, the
network topology is revealed to anyone who listens to OLSRv2 control
messages.
In situations where the confidentiality of the network topology is of
importance, regular cryptographic techniques, such as exchange of
OLSRv2 control traffic messages encrypted by PGP [9] or encrypted by
some shared secret key, can be applied to ensure that control traffic
can be read and interpreted by only those authorized to do so.
Appendix F.2. Integrity
In OLSRv2, each node is injecting topological information into the
network through transmitting HELLO messages and, for some nodes, TC
messages. If some nodes for some reason, malicious or malfunction,
inject invalid control traffic, network integrity may be compromised.
Therefore, message authentication is recommended.
Different such situations may occur, for instance:
1. a node generates TC messages, advertising links to non-neighbor
nodes;
2. a node generates TC messages, pretending to be another node;
3. a node generates HELLO messages, advertising non-neighbor nodes;
4. a node generates HELLO messages, pretending to be another node;
5. a node forwards altered control messages;
6. a node does not forward control messages;
7. a node does not select multipoint relays correctly;
8. a node forwards broadcast control messages unaltered, but does
not forward unicast data traffic;
9. a node "replays" previously recorded control traffic from another
node.
Authentication of the originator node for control messages (for
situations 2, 4 and 5) and on the individual links announced in the
control messages (for situations 1 and 3) may be used as a
countermeasure. However to prevent nodes from repeating old (and
correctly authenticated) information (situation 9) temporal
information is required, allowing a node to positively identify such
delayed messages.
In general, digital signatures and other required security
information may be transmitted as a separate OLSRv2 message type, or
signatures and security information may be transmitted within the
OLSRv2 HELLO and TC messages, using the TLV mechanism. Either option
permits that "secured" and "unsecured" nodes can coexist in the same
network, if desired,
Specifically, the authenticity of entire OLSRv2 control messages can
be established through employing IPsec authentication headers,
whereas authenticity of individual links (situations 1 and 3) require
additional security information to be distributed.
An important consideration is, that all control messages in OLSRv2
are transmitted either to all nodes in the neighborhood (HELLO
messages) or broadcast to all nodes in the network (TC messages).
For example, a control message in OLSRv2 is always a point-to-
multipoint transmission. It is therefore important that the
authentication mechanism employed permits that any receiving node can
validate the authenticity of a message. As an analogy, given a block
of text, signed by a PGP private key, then anyone with the
corresponding public key can verify the authenticity of the text.
Appendix F.3. Interaction with External Routing Domains
OLSRv2 does, through the use of TC messages, provide a basic
mechanism for injecting external routing information to the OLSRv2
domain. Appendix A also specifies that routing information can be
extracted from the topology table or the routing table of OLSRv2 and,
potentially, injected into an external domain if the routing protocol
governing that domain permits.
Other than as described in Appendix A, when operating nodes
connecting OLSRv2 to an external routing domain, care MUST be taken
not to allow potentially insecure and untrustworthy information to be
injected from the OLSRv2 domain to external routing domains. Care
MUST be taken to validate the correctness of information prior to it
being injected as to avoid polluting routing tables with invalid
information.
A recommended way of extending connectivity from an existing routing
domain to an OLSRv2 routed MANET is to assign an IP prefix (under the
authority of the nodes/gateways connecting the MANET with the exiting
routing domain) exclusively to the OLSRv2 MANET area, and to
configure the gateways statically to advertise routes to that IP
sequence to nodes in the existing routing domain.
Appendix F.4. Node Identity
OLSRv2 does not make any assumption about node addresses, other than
that each node is assumed to have at least one a unique and routable
IP address for each interface that it has which participates in the
MANET.
Appendix G. Flow and Congestion Control
Due to its proactive nature, the OLSRv2 protocol has a natural Due to its proactive nature, the OLSRv2 protocol has a natural
control over the flow of its control traffic. Nodes transmit control control over the flow of its control traffic. Nodes transmit control
messages at predetermined rates specified and bounded by message messages at predetermined rates specified and bounded by message
intervals. intervals.
OLSRv2 employs [4] for local signaling, embedding MPR selection OLSRv2 employs [4] for local signaling, embedding MPR selection
advertisement through a simple address block TLV, and node advertisement through a simple address block TLV, and node
willingness advertisement (if any) as a single message TLV. OLSRv2 willingness advertisement (if any) as a single message TLV. OLSRv2
local signaling, therefore, shares the characteristics and local signaling, therefore, shares the characteristics and
constraints of [4]. constraints of [4].
Furthermore, the MPR optimization greatly constrains global signaling Furthermore, MPR flooding greatly reduces global signaling overhead
overhead from link state diffusion in two ways. First, the messages from global link state declaration in two ways. First, the amount of
that advertise the topology need only contain MPR selectors, reducing link state information for a node to declare is reduced to only
their size as compared to full link state. Second, the cost of contain that node's MPR selectors. This reduces the size of a link
diffusing these messages throughout the network is greatly reduced as state declaration as compared to declaring full link state
information. In particular some nodes may not need to declare any
such information. Second, using MPR flooding, the cost of declaring
link state information throughout the network is greatly reduced, as
compared to when using classic flooding, since only MPRs need to compared to when using classic flooding, since only MPRs need to
forward broadcast messages. In dense networks, the reduction of forward link state declaration messages. In dense networks, the
control traffic can be of several orders of magnitude compared to reduction of control traffic can be of several orders of magnitude
routing protocols using classical flooding [12]. This feature compared to routing protocols using classical flooding [11]. This
naturally provides more bandwidth for useful data traffic and pushes feature naturally provides more bandwidth for useful data traffic and
further the frontier of congestion. pushes further the frontier of congestion.
Since the control traffic is continuous and periodic, it keeps the Since the control traffic is continuous and periodic, it keeps the
quality of the links used in routing more stable. However, using quality of the links used in routing more stable. However, using
certain OLSRv2 options, some control messages (HELLO messages or TC certain OLSRv2 options, some control messages (HELLO messages or TC
messages) may be intentionally sent in advance of their deadline in messages) may be intentionally sent in advance of their deadline in
order to increase the responsiveness of the protocol to topology order to increase the responsiveness of the protocol to topology
changes. This may cause a small, temporary, and local increase of changes. This may cause a small, temporary, and local increase of
control traffic, however this is at all times bounded by the use of control traffic, however this is at all times bounded by the use of
minimum message intervals. minimum message intervals.
Appendix H. Contributors Appendix G. Contributors
This specification is the result of the joint efforts of the This specification is the result of the joint efforts of the
following contributors -- listed alphabetically. following contributors -- listed alphabetically.
o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr> o Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
o Emmanuel Baccelli, INRIA , France, <Emmanuel.Baccelli@inria.fr> o Emmanuel Baccelli, INRIA , France, <Emmanuel.Baccelli@inria.fr>
o Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org> o Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>
o Justin Dean, NRL, USA<jdean@itd.nrl.navy.mil> o Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
o Christopher Dearlove, BAE Systems, UK, o Christopher Dearlove, BAE Systems, UK,
<Chris.Dearlove@baesystems.com> <chris.dearlove@baesystems.com>
o Satoh Hiroki, Hitachi SDL, Japan, <hiroki.satoh.yj@hitachi.com> o Satoh Hiroki, Hitachi SDL, Japan, <hiroki.satoh.yj@hitachi.com>
o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr> o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
o Monden Kazuya, Hitachi SDL, Japan, <kazuya.monden.vw@hitachi.com> o Monden Kazuya, Hitachi SDL, Japan, <kazuya.monden.vw@hitachi.com>
o Kenichi Mase, Niigata University, Japan, <mase@ie.niigata-u.ac.jp> o Kenichi Mase, Niigata University, Japan, <mase@ie.niigata-u.ac.jp>
o Ryuji Wakikawa, KEIO University, Japan, <ryuji@sfc.wide.ad.jp> o Ryuji Wakikawa, KEIO University, Japan, <ryuji@sfc.wide.ad.jp>
Appendix I. Acknowledgements Appendix H. Acknowledgements
The authors would like to acknowledge the team behind OLSRv1, The authors would like to acknowledge the team behind OLSRv1,
specified in RFC3626, including Anis Laouiti, Pascale Minet, Laurent specified in RFC3626, including Anis Laouiti (INT, Paris), Pascale
Viennot (all at INRIA, France), and Amir Qayyum (Center for Advanced Minet (INRIA, France), Laurent Viennot (INRIA, France), and Amir
Research in Engineering, Pakistan) for their contributions. Qayyum (M.A. Jinnah University, Islamabad) for their contributions.
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews and comments on the for intense technical discussions, early reviews and comments on the
specification and its components: Li Li (CRC), Louise Lamont (CRC), specification and its components: Li Li (CRC), Louise Lamont (CRC),
Joe Macker (NRL), Alan Cullen (BAE Systems), Philippe Jacquet Joe Macker (NRL), Alan Cullen (BAE Systems), Khaldoun Al Agha (LRI),
(INRIA), Khaldoun Al Agha (LRI), Richard Ogier (SRI), Song-Yean Cho Richard Ogier (SRI), Song-Yean Cho (LIX), Shubhranshu Singh (Samsung
(Samsung Software Center), Shubhranshu Singh (Samsung AIT), Charles AIT), Charles E. Perkins, and the entire IETF MANET working group.
E. Perkins (Nokia) and the entire IETF MANET working group.
Authors' Addresses Authors' Addresses
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique, France LIX, Ecole Polytechnique, France
Phone: +33 6 6058 9349 Phone: +33 6 6058 9349
Email: T.Clausen@computer.org Email: thomas@thomasclausen.org
URI: http://www.ThomasClausen.org/ URI: http://www.ThomasClausen.org/
Christopher M. Dearlove Christopher Dearlove
BAE Systems Advanced Technology Centre BAE Systems Advanced Technology Centre
Phone: +44 1245 242194 Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com Email: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/ URI: http://www.baesystems.com/
Philippe Jacquet Philippe Jacquet
Project Hipercom, INRIA Project Hipercom, INRIA
Phone: +33 1 3963 5263 Phone: +33 1 3963 5263
Email: philippe.jacquet@inria.fr Email: philippe.jacquet@inria.fr
The OLSRv2 Design Team The OLSRv2 Design Team
MANET Working Group MANET Working Group
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 236 change blocks. 
877 lines changed or deleted 838 lines changed or added

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