draft-ietf-manet-olsrv2-19.txt   rfc7181.txt 
Mobile Ad hoc Networking (MANET) T. Clausen Internet Engineering Task Force (IETF) T. Clausen
Internet-Draft LIX, Ecole Polytechnique Request for Comments: 7181 LIX, Ecole Polytechnique
Intended status: Standards Track C. Dearlove Category: Standards Track C. Dearlove
Expires: September 24, 2013 BAE Systems ATC ISSN: 2070-1721 BAE Systems ATC
P. Jacquet P. Jacquet
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
U. Herberg U. Herberg
Fujitsu Laboratories of America Fujitsu Laboratories of America
March 23, 2013 April 2014
The Optimized Link State Routing Protocol version 2 The Optimized Link State Routing Protocol Version 2
draft-ietf-manet-olsrv2-19
Abstract Abstract
This specification describes version 2 of the Optimized Link State This specification describes version 2 of the Optimized Link State
Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). Routing Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on September 24, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7181.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 21 skipping to change at page 2, line 19
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction ....................................................5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology .....................................................6
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9 3. Applicability Statement .........................................9
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 10 4. Protocol Overview and Functioning ..............................10
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Overview ..................................................10
4.2. Routers and Interfaces . . . . . . . . . . . . . . . . . 13 4.2. Routers and Interfaces ....................................12
4.3. Information Base Overview . . . . . . . . . . . . . . . . 14 4.3. Information Base Overview .................................13
4.3.1. Local Information Base . . . . . . . . . . . . . . . 14 4.3.1. Local Information Base .............................13
4.3.2. Interface Information Bases . . . . . . . . . . . . . 14 4.3.2. Interface Information Base .........................14
4.3.3. Neighbor Information Base . . . . . . . . . . . . . . 15 4.3.3. Neighbor Information Base ..........................14
4.3.4. Topology Information Base . . . . . . . . . . . . . . 15 4.3.4. Topology Information Base ..........................14
4.3.5. Received Message Information Base . . . . . . . . . . 16 4.3.5. Received Message Information Base ..................16
4.4. Signaling Overview . . . . . . . . . . . . . . . . . . . 16 4.4. Signaling Overview ........................................16
4.5. Link Metrics . . . . . . . . . . . . . . . . . . . . . . 18 4.5. Link Metrics ..............................................17
4.6. Flooding MPRs and Routing MPR . . . . . . . . . . . . . . 19 4.6. Flooding MPRs and Routing MPR .............................18
4.7. Routing Set Use . . . . . . . . . . . . . . . . . . . . . 19 4.7. Routing Set Use ...........................................19
5. Protocol Parameters and Constants . . . . . . . . . . . . . . 19 5. Protocol Parameters and Constants ..............................19
5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 20 5.1. Protocol and Port Numbers .................................19
5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 20 5.2. Multicast Address .........................................20
5.3. Interface Parameters . . . . . . . . . . . . . . . . . . 20 5.3. Interface Parameters ......................................20
5.3.1. Received Message Validity Time . . . . . . . . . . . 20 5.3.1. Received Message Validity Time .....................20
5.4. Router Parameters . . . . . . . . . . . . . . . . . . . . 21 5.4. Router Parameters .........................................20
5.4.1. Local History Times . . . . . . . . . . . . . . . . . 21 5.4.1. Local History Times ................................20
5.4.2. Link Metric Parameters . . . . . . . . . . . . . . . 21 5.4.2. Link Metric Parameters .............................21
5.4.3. Message Intervals . . . . . . . . . . . . . . . . . . 21 5.4.3. Message Intervals ..................................21
5.4.4. Advertised Information Validity Times . . . . . . . . 22 5.4.4. Advertised Information Validity Times ..............22
5.4.5. Processing and Forwarding Validity Times . . . . . . 23 5.4.5. Processing and Forwarding Validity Times ...........22
5.4.6. Jitter . . . . . . . . . . . . . . . . . . . . . . . 23 5.4.6. Jitter .............................................23
5.4.7. Hop Limit . . . . . . . . . . . . . . . . . . . . . . 24 5.4.7. Hop Limit ..........................................23
5.4.8. Willingness . . . . . . . . . . . . . . . . . . . . . 24 5.4.8. Willingness ........................................24
5.5. Parameter Change Constraints . . . . . . . . . . . . . . 25 5.5. Parameter Change Constraints ..............................25
5.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 27 5.6. Constants .................................................27
5.6.1. Link Metric Constants . . . . . . . . . . . . . . . . 27 5.6.1. Link Metric Constants ..............................27
5.6.2. Willingness Constants . . . . . . . . . . . . . . . . 27 5.6.2. Willingness Constants ..............................28
5.6.3. Time Constant . . . . . . . . . . . . . . . . . . . . 28 5.6.3. Time Constant ......................................28
6. Link Metric Values . . . . . . . . . . . . . . . . . . . . . 28 6. Link Metric Values .............................................28
6.1. Link Metric Representation . . . . . . . . . . . . . . . 28 6.1. Link Metric Representation ................................28
6.2. Link Metric Compressed Form . . . . . . . . . . . . . . . 29 6.2. Link Metric Compressed Form ...............................29
7. Local Information Base . . . . . . . . . . . . . . . . . . . 29 7. Local Information Base .........................................29
7.1. Originator Set . . . . . . . . . . . . . . . . . . . . . 30 7.1. Originator Set ............................................30
7.2. Local Attached Network Set . . . . . . . . . . . . . . . 30 7.2. Local Attached Network Set ................................30
8. Interface Information Base . . . . . . . . . . . . . . . . . 31 8. Interface Information Base .....................................31
8.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . 31 8.1. Link Set ..................................................31
8.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 32 8.2. 2-Hop Set .................................................32
9. Neighbor Information Base . . . . . . . . . . . . . . . . . . 32 9. Neighbor Information Base ......................................32
10. Topology Information Base . . . . . . . . . . . . . . . . . . 34 10. Topology Information Base .....................................34
10.1. Advertising Remote Router Set . . . . . . . . . . . . . . 34 10.1. Advertising Remote Router Set ............................34
10.2. Router Topology Set . . . . . . . . . . . . . . . . . . . 34 10.2. Router Topology Set ......................................35
10.3. Routable Address Topology Set . . . . . . . . . . . . . . 35 10.3. Routable Address Topology Set ............................35
10.4. Attached Network Set . . . . . . . . . . . . . . . . . . 36 10.4. Attached Network Set .....................................36
10.5. Routing Set . . . . . . . . . . . . . . . . . . . . . . . 36 10.5. Routing Set ..............................................37
11. Received Message Information Base . . . . . . . . . . . . . . 37 11. Received Message Information Base .............................37
11.1. Received Set . . . . . . . . . . . . . . . . . . . . . . 37 11.1. Received Set .............................................38
11.2. Processed Set . . . . . . . . . . . . . . . . . . . . . . 38 11.2. Processed Set ............................................38
11.3. Forwarded Set . . . . . . . . . . . . . . . . . . . . . . 38 11.3. Forwarded Set ............................................39
12. Information Base Properties . . . . . . . . . . . . . . . . . 39 12. Information Base Properties ...................................39
12.1. Corresponding Protocol Tuples . . . . . . . . . . . . . . 39 12.1. Corresponding Protocol Tuples ............................39
12.2. Address Ownership . . . . . . . . . . . . . . . . . . . . 40 12.2. Address Ownership ........................................40
13. Packets and Messages . . . . . . . . . . . . . . . . . . . . 40 13. Packets and Messages ..........................................41
13.1. Messages . . . . . . . . . . . . . . . . . . . . . . . . 41 13.1. Messages .................................................41
13.2. Packets . . . . . . . . . . . . . . . . . . . . . . . . . 41 13.2. Packets ..................................................41
13.3. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 42 13.3. TLVs .....................................................42
13.3.1. Message TLVs . . . . . . . . . . . . . . . . . . . . 42 13.3.1. Message TLVs ......................................42
13.3.2. Address Block TLVs . . . . . . . . . . . . . . . . . 42 13.3.2. Address Block TLVs ................................42
14. Message Processing and Forwarding . . . . . . . . . . . . . . 44 14. Message Processing and Forwarding .............................45
14.1. Actions when Receiving a Message . . . . . . . . . . . . 45 14.1. Actions When Receiving a Message .........................45
14.2. Message Considered for Processing . . . . . . . . . . . . 46 14.2. Message Considered for Processing ........................46
14.3. Message Considered for Forwarding . . . . . . . . . . . . 47 14.3. Message Considered for Forwarding ........................47
15. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . . 49 15. HELLO Messages ................................................49
15.1. HELLO Message Generation . . . . . . . . . . . . . . . . 49 15.1. HELLO Message Generation .................................49
15.2. HELLO Message Transmission . . . . . . . . . . . . . . . 51 15.2. HELLO Message Transmission ...............................51
15.3. HELLO Message Processing . . . . . . . . . . . . . . . . 51 15.3. HELLO Message Processing .................................51
15.3.1. HELLO Message Discarding . . . . . . . . . . . . . . 51 15.3.1. HELLO Message Discarding ..........................51
15.3.2. HELLO Message Usage . . . . . . . . . . . . . . . . . 52 15.3.2. HELLO Message Usage ...............................52
16. TC Messages . . . . . . . . . . . . . . . . . . . . . . . . . 55 16. TC Messages ...................................................56
16.1. TC Message Generation . . . . . . . . . . . . . . . . . . 55 16.1. TC Message Generation ....................................56
16.2. TC Message Transmission . . . . . . . . . . . . . . . . . 57 16.2. TC Message Transmission ..................................58
16.3. TC Message Processing . . . . . . . . . . . . . . . . . . 58 16.3. TC Message Processing ....................................59
16.3.1. TC Message Discarding . . . . . . . . . . . . . . . . 58 16.3.1. TC Message Discarding .............................59
16.3.2. TC Message Processing Definitions . . . . . . . . . . 60 16.3.2. TC Message Processing Definitions .................61
16.3.3. Initial TC Message Processing . . . . . . . . . . . . 61 16.3.3. Initial TC Message Processing .....................61
16.3.4. Completing TC Message Processing . . . . . . . . . . 64 16.3.4. Completing TC Message Processing ..................65
17. Information Base Changes . . . . . . . . . . . . . . . . . . 65
17.1. Originator Address Changes . . . . . . . . . . . . . . . 65 17. Information Base Changes ......................................66
17.2. Link State Changes . . . . . . . . . . . . . . . . . . . 66 17.1. Originator Address Changes ...............................66
17.3. Neighbor State Changes . . . . . . . . . . . . . . . . . 66 17.2. Link State Changes .......................................66
17.4. Advertised Neighbor Changes . . . . . . . . . . . . . . . 67 17.3. Neighbor State Changes ...................................67
17.5. Advertising Remote Router Tuple Expires . . . . . . . . . 67 17.4. Advertised Neighbor Changes ..............................67
17.6. Neighborhood Changes and MPR Updates . . . . . . . . . . 68 17.5. Advertising Remote Router Tuple Expires ..................68
17.7. Routing Set Updates . . . . . . . . . . . . . . . . . . . 70 17.6. Neighborhood Changes and MPR Updates .....................68
18. Selecting MPRs . . . . . . . . . . . . . . . . . . . . . . . 70 17.7. Routing Set Updates ......................................70
18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 71 18. Selecting MPRs ................................................71
18.2. Neighbor Graph . . . . . . . . . . . . . . . . . . . . . 72 18.1. Overview .................................................72
18.3. MPR Properties . . . . . . . . . . . . . . . . . . . . . 73 18.2. Neighbor Graph ...........................................72
18.4. Flooding MPRs . . . . . . . . . . . . . . . . . . . . . . 73 18.3. MPR Properties ...........................................73
18.5. Routing MPRs . . . . . . . . . . . . . . . . . . . . . . 75 18.4. Flooding MPRs ............................................74
18.6. Calculating MPRs . . . . . . . . . . . . . . . . . . . . 77 18.5. Routing MPRs .............................................76
19. Routing Set Calculation . . . . . . . . . . . . . . . . . . . 77 18.6. Calculating MPRs .........................................77
19.1. Network Topology Graph . . . . . . . . . . . . . . . . . 77 19. Routing Set Calculation .......................................78
19.2. Populating the Routing Set . . . . . . . . . . . . . . . 79 19.1. Network Topology Graph ...................................78
20. Proposed Values for Parameters . . . . . . . . . . . . . . . 80 19.2. Populating the Routing Set ...............................80
20.1. Local History Time Parameters . . . . . . . . . . . . . . 81 20. Proposed Values for Parameters ................................81
20.2. Message Interval Parameters . . . . . . . . . . . . . . . 81 20.1. Local History Time Parameters ............................82
20.3. Advertised Information Validity Time Parameters . . . . . 81 20.2. Message Interval Parameters ..............................82
20.4. Received Message Validity Time Parameters . . . . . . . . 81 20.3. Advertised Information Validity Time Parameters ..........82
20.5. Jitter Time Parameters . . . . . . . . . . . . . . . . . 81 20.4. Received Message Validity Time Parameters ................82
20.6. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 81 20.5. Jitter Time Parameters ...................................82
20.7. Willingness Parameter . . . . . . . . . . . . . . . . . . 82 20.6. Hop Limit Parameter ......................................82
21. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . 82 20.7. Willingness Parameters ...................................82
22. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 82 21. Sequence Numbers ..............................................83
23. Security Considerations . . . . . . . . . . . . . . . . . . . 83 22. Extensions ....................................................83
23.1. Security Architecture . . . . . . . . . . . . . . . . . . 83 23. Security Considerations .......................................84
23.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 84 23.1. Security Architecture ....................................84
23.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 86 23.2. Integrity ................................................85
23.4. Interaction with External Routing Domains . . . . . . . . 86 23.3. Confidentiality ..........................................86
23.5. Mandatory Security Mechanisms . . . . . . . . . . . . . . 87 23.4. Interaction with External Routing Domains ................87
23.6. Key Management . . . . . . . . . . . . . . . . . . . . . 87 23.5. Mandatory Security Mechanisms ............................87
24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 90 23.6. Key Management ...........................................88
24.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 90 24. IANA Considerations ...........................................90
24.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 90 24.1. Expert Review: Evaluation Guidelines .....................91
24.3. Message-Type-Specific TLV Type Registries . . . . . . . . 90 24.2. Message Types ............................................91
24.4. Message TLV Types . . . . . . . . . . . . . . . . . . . . 91 24.3. Message-Type-Specific TLV Type Registries ................91
24.5. Address Block TLV Types . . . . . . . . . . . . . . . . . 92 24.4. Message TLV Types ........................................92
24.6. NBR_ADDR_TYPE and MPR Values . . . . . . . . . . . . . . 95 24.5. Address Block TLV Types ..................................93
25. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 95 24.6. NBR_ADDR_TYPE and MPR Values .............................96
26. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 96 25. Contributors ..................................................96
27. References . . . . . . . . . . . . . . . . . . . . . . . . . 96 26. Acknowledgments ...............................................97
27.1. Normative References . . . . . . . . . . . . . . . . . . 96 27. References ....................................................97
27.2. Informative References . . . . . . . . . . . . . . . . . 97 27.1. Normative References .....................................97
Appendix A. Constraints . . . . . . . . . . . . . . . . . . . . 98 27.2. Informative References ...................................98
Appendix B. Example Algorithm for Calculating MPRs . . . . . . . 102 Appendix A. Constraints .........................................100
B.1. Additional Notation . . . . . . . . . . . . . . . . . . . 102 Appendix B. Example Algorithm for Calculating MPRs ..............104
B.2. MPR Selection Algorithm . . . . . . . . . . . . . . . . . 103 B.1. Additional Notation ......................................104
Appendix C. Example Algorithm for Calculating the Routing Set . 104 B.2. MPR Selection Algorithm ................................. 105
C.1. Local Interfaces and Neighbors . . . . . . . . . . . . . 104 Appendix C. Example Algorithm for Calculating the Routing Set ...105
C.2. Add Neighbor Routers . . . . . . . . . . . . . . . . . . 105 C.1. Local Interfaces and Neighbors ...........................106
C.3. Add Remote Routers . . . . . . . . . . . . . . . . . . . 105 C.2. Add Neighbor Routers .....................................107
C.4. Add Neighbor Addresses . . . . . . . . . . . . . . . . . 107 C.3. Add Remote Routers .......................................107
C.5. Add Remote Routable Addresses . . . . . . . . . . . . . . 107 C.4. Add Neighbor Addresses ...................................108
C.6. Add Attached Networks . . . . . . . . . . . . . . . . . . 108 C.5. Add Remote Routable Addresses ............................109
C.7. Add 2-Hop Neighbors . . . . . . . . . . . . . . . . . . . 108 C.6. Add Attached Networks ....................................110
Appendix D. TC Message Example . . . . . . . . . . . . . . . . . 109 C.7. Add 2-Hop Neighbors ......................................110
Appendix E. Flow and Congestion Control . . . . . . . . . . . . 111 Appendix D. TC Message Example ..................................111
Appendix E. Flow and Congestion Control .........................114
1. Introduction 1. Introduction
The Optimized Link State Routing protocol version 2 (OLSRv2) is the The Optimized Link State Routing Protocol version 2 (OLSRv2) is the
successor to OLSR (version 1) as published in [RFC3626]. Compared to successor to OLSR (version 1) as published in [RFC3626]. Compared to
[RFC3626], OLSRv2 retains the same basic mechanisms and algorithms, [RFC3626], OLSRv2 retains the same basic mechanisms and algorithms,
enhanced by the ability to use a link metric other than hop count in enhanced by the ability to use a link metric other than hop count in
the selection of shortest routes. OLSRv2 also uses a more flexible the selection of shortest routes. OLSRv2 also uses a more flexible
and efficient signaling framework, and includes some simplification and efficient signaling framework and includes some simplification of
of the messages being exchanged. the messages being exchanged.
OLSRv2 is developed for mobile ad hoc networks (MANETs). It operates OLSRv2 is developed for Mobile Ad Hoc Networks (MANETs). It operates
as a table driven, proactive protocol, i.e., it exchanges topology as a table-driven, proactive protocol, i.e., it exchanges topology
information with other routers in the network regularly. OLSRv2 is information with other routers in the network regularly. OLSRv2 is
an optimization of the classic link state routing protocol. Its key an optimization of the classic link state routing protocol. Its key
concept is that of MultiPoint Relays (MPRs). Each router selects two concept is that of multipoint relays (MPRs). Each router selects two
sets of MPRs, each being a set of its neighbor routers that "cover" sets of MPRs, each being a set of its neighbor routers that "cover"
all of its symmetrically connected 2-hop neighbor routers. These two all of its symmetrically connected 2-hop neighbor routers. These two
sets are of "flooding MPRs" and "routing MPRs", and are used to sets are "flooding MPRs" and "routing MPRs", which are used to
achieve flooding reduction and topology reduction, respectively. achieve flooding reduction and topology reduction, respectively.
Flooding reduction is achieved by control traffic being flooded Flooding reduction is achieved by control traffic being flooded
through the network using hop by hop forwarding, but with a router through the network using hop-by-hop forwarding, but with a router
only needing to forward control traffic that is first received only needing to forward control traffic that is first received
directly from one of the routers that have selected it as a flooding directly from one of the routers that have selected it as a flooding
MPR (its "flooding MPR selectors"). This mechanism, denoted "MPR MPR (its "flooding MPR selectors"). This mechanism, denoted "MPR
flooding", provides an efficient mechanism for information flooding", provides an efficient mechanism for information
distribution within the MANET by reducing the number of transmissions distribution within the MANET by reducing the number of transmissions
required [MPR]. required [MPR].
Topology reduction is achieved by assigning a special responsibility Topology reduction is achieved by assigning a special responsibility
to routers selected as routing MPRs when declaring link state to routers selected as routing MPRs when declaring link state
information. A sufficient requirement for OLSRv2 to provide shortest information. A sufficient requirement for OLSRv2 to provide shortest
routes to all destinations is that routers declare link state routes to all destinations is that routers declare link state
information for their routing MPR selectors, if any. Routers that information for their routing MPR selectors, if any. Routers that
are not selected as routing MPRs need not send any link state are not selected as routing MPRs need not send any link state
information. Based on this reduced link state information, routing information. Based on this reduced link state information, routing
MPRs are used as intermediate routers in multi-hop routes. MPRs are used as intermediate routers in multi-hop routes.
Thus the use of MPRs allows reduction of the number and the size of Thus, the use of MPRs allows reduction of the number and the size of
link state messages, and in the amount of link state information link state messages and reduction in the amount of link state
maintained in each router. When possible (in particular if using a information maintained in each router. When possible (in particular
hop count metric) the same routers may be picked as both flooding if using a hop count metric), the same routers may be picked as both
MPRs and routing MPRs. flooding MPRs and routing MPRs.
A router selects both routing and flooding MPRs from among its one A router selects both routing and flooding MPRs from among its one-
hop neighbors connected by "symmetric", i.e., bidirectional, links. hop neighbors connected by "symmetric", i.e., bidirectional, links.
Therefore, selecting routes through routing MPRs avoids the problems Therefore, selecting routes through routing MPRs avoids the problems
associated with data packet transfer over unidirectional links (e.g., associated with data packet transfer over unidirectional links (e.g.,
the problem of not getting link layer acknowledgments at each hop, the problem of not getting link-layer acknowledgments at each hop,
for link layers employing this technique). for link layers employing this technique).
OLSRv2 uses and extends the MANET NeighborHood Discovery Protocol OLSRv2 uses and extends the MANET Neighborhood Discovery Protocol
(NHDP) defined in [RFC6130] and also uses the Generalized MANET (NHDP) defined in [RFC6130] and also uses the Generalized MANET
Packet/Message Format [RFC5444], the TLVs specified in [RFC5497] and, Packet/Message Format [RFC5444], the TLVs specified in [RFC5497] and,
optionally, message jitter as specified in [RFC5148]. These four optionally, message jitter as specified in [RFC5148]. These four
other protocols and specifications were all originally created as other protocols and specifications were all originally created as
part of OLSRv2, but have been specified separately for wider use. part of OLSRv2 but have been specified separately for wider use.
OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, OLSRv2 makes no assumptions about the underlying link layer. OLSRv2,
through its use of [RFC6130], may use link layer information and through its use of [RFC6130], may use link-layer information and
notifications when available and applicable. In addition, OLSRv2 notifications when available and applicable. In addition, OLSRv2
uses link metrics that may be derived from link layer or any other uses link metrics that may be derived from link layer or any other
information. OLSRv2 does not specify the physical meaning of link information. OLSRv2 does not specify the physical meaning of link
metrics, but specifies a means by which new types of link metrics may metrics but specifies a means by which new types of link metrics may
be specified in the future, but used by OLSRv2 without modification. be specified in the future but used by OLSRv2 without modification.
OLSRv2, as OLSR [RFC3626], inherits its concept of forwarding and OLSRv2, like OLSR [RFC3626], inherits its concept of forwarding and
relaying from HIPERLAN (a MAC layer protocol) which is standardized relaying from the High Performance Radio Local Area Network
by ETSI [HIPERLAN], [HIPERLAN2]. This document does not obsolete (HIPERLAN) (a MAC-layer protocol), which is standardized by ETSI
[RFC3626] which is left in place for further experimentation. [HIPERLAN] [HIPERLAN2]. This document does not obsolete [RFC3626],
which is left in place for further experimentation.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
All terms introduced in [RFC5444], including "packet", "Packet All terms introduced in [RFC5444], including "packet", "Packet
Header", "message", "Message Header", "Message Body", "Message Type", Header", "message", "Message Header", "Message Body", "Message Type",
skipping to change at page 8, line 6 skipping to change at page 7, line 19
All terms introduced in [RFC6130], including "interface", "MANET All terms introduced in [RFC6130], including "interface", "MANET
interface", "network address", "link", "symmetric link", "symmetric interface", "network address", "link", "symmetric link", "symmetric
1-hop neighbor", "symmetric 2-hop neighbor", "symmetric 1-hop 1-hop neighbor", "symmetric 2-hop neighbor", "symmetric 1-hop
neighborhood" "constant", "interface parameter", "router parameter", neighborhood" "constant", "interface parameter", "router parameter",
"Information Base", and "HELLO message" are to be interpreted as "Information Base", and "HELLO message" are to be interpreted as
described there. described there.
Additionally, this specification uses the following terminology: Additionally, this specification uses the following terminology:
Router: Router:
A MANET router which implements this protocol. A MANET router that implements this protocol.
OLSRv2 interface: OLSRv2 interface:
A MANET interface running this protocol. A router running this A MANET interface running this protocol. A router running this
protocol MUST have at least one OLSRv2 interface. protocol MUST have at least one OLSRv2 interface.
Routable address: Routable address:
A network address which may be used as the destination of a data A network address that may be used as the destination of a data
packet. A router which implements this protocol will need to packet. A router that implements this protocol will need to
distinguish a routable address from a non-routable address by distinguish a routable address from a non-routable address by
direct inspection of the network address, based on global scope direct inspection of the network address, based on global-scope
address allocations by IANA and/or administrative configuration address allocations by IANA and/or administrative configuration
(consistently across the MANET). Broadcast and multicast (consistently across the MANET). Broadcast and multicast
addresses, and addresses which are limited in scope to less than addresses, and addresses that are limited in scope to less than
the entire MANET, MUST NOT be considered as routable addresses. the entire MANET, MUST NOT be considered as routable addresses.
Anycast addresses may be considered as routable addresses. Anycast addresses may be considered as routable addresses.
Originator address: Originator address:
An address which is unique (within the MANET) to a router. A An address that is unique (within the MANET) to a router. A
router MUST select an originator address; it MAY choose one of its router MUST select an originator address; it MAY choose one of its
interface addresses as its originator address; it MAY select interface addresses as its originator address; and it MAY select
either a routable or non-routable address. A broadcast, multicast either a routable or non-routable address. A broadcast,
or anycast address MUST NOT be chosen as an originator address. multicast, or anycast address MUST NOT be chosen as an originator
If the router selects a routable address then this MUST be one address. If the router selects a routable address, then it MUST
which the router will accept as destination. An originator be one that the router will accept as destination. An originator
address MUST NOT have a prefix length, except for when included in address MUST NOT have a prefix length, except when included in an
an Address Block where it MAY be associated with a prefix of Address Block where it MAY be associated with a prefix of maximum
maximum prefix length (e.g., if the originator address is an IPv6 prefix length (e.g., if the originator address is an IPv6 address,
address, it MUST have either no prefix length, or have a prefix it MUST have either no prefix length or have a prefix length of
length of 128). 128).
Message originator address: Message originator address:
The originator address of the router which created a message, as The originator address of the router that created a message, as
deduced from that message by its recipient. For all messages used deduced from that message by its recipient. For all messages used
in this specification, including HELLO messages defined in in this specification, including HELLO messages defined in
[RFC6130], the recipient MUST be able to deduce an originator [RFC6130], the recipient MUST be able to deduce an originator
address. The message originator address will usually be included address. The message originator address will usually be included
in the message as its <msg-orig-addr> element as defined in in the message as its <msg-orig-addr> element as defined in
[RFC5444]. However, an exceptional case, which does not add a [RFC5444]. However, an exceptional case, which does not add a
<msg-orig-addr> element to a HELLO message, may be used by a <msg-orig-addr> element to a HELLO message, may be used by a
router that only has a single address. router that only has a single address.
Willingness: Willingness:
A numerical value between WILL_NEVER and WILL_ALWAYS (both A numerical value between WILL_NEVER and WILL_ALWAYS (both
inclusive), that represents the router's willingness to be inclusive) that represents the router's willingness to be selected
selected as an MPR. A router has separate willingness values to as an MPR. A router has separate willingness values to be a
be a flooding MPR and a routing MPR. flooding MPR and a routing MPR.
Willing symmetric 1-hop neighbor: Willing symmetric 1-hop neighbor:
A symmetric 1-hop neighbor that has willingness not equal to A symmetric 1-hop neighbor that has willingness not equal to
WILL_NEVER. WILL_NEVER.
Multipoint relay (MPR): Multipoint relay (MPR):
A router, X, is an MPR for a router, Y, if router Y has indicated A router, X, is an MPR for a router, Y, if router Y has indicated
its selection of router X as an MPR in a recent HELLO message. its selection of router X as an MPR in a recent HELLO message.
Router X may be a flooding MPR for Y if it is indicated to Router X may be a flooding MPR for Y if it is indicated to
participate in the flooding process of messages received from participate in the flooding process of messages received from
router Y, or it may be a routing MPR for Y, if it is indicated to router Y, or it may be a routing MPR for Y if it is indicated to
declare link-state information for the link from X to Y. It may declare link state information for the link from X to Y. It may
also be both at the same time. also be both at the same time.
MPR selector: MPR selector:
A router, Y, is a flooding/routing MPR selector of router X if A router, Y, is a flooding/routing MPR selector of router X if
router Y has selected router X as a flooding/routing MPR. router Y has selected router X as a flooding/routing MPR.
MPR flooding: MPR flooding:
The optimized MANET-wide information distribution mechanism, The optimized MANET-wide information distribution mechanism,
employed by this protocol, in which a message is relayed by only a employed by this protocol, in which a message is relayed by only a
reduced subset of the routers in the network. MPR flooding is the reduced subset of the routers in the network. MPR flooding is the
mechanism by which flooding reduction is achieved. mechanism by which flooding reduction is achieved.
EXPIRED: EXPIRED:
Indicates that a timer is set to a value clearly preceding the Indicates that a timer is set to a value clearly preceding the
current time (e.g., current time - 1). current time (e.g., current time - 1).
This specification employs the same notational conventions as in This specification employs the same notational conventions as
[RFC5444] and [RFC6130]. [RFC5444] and [RFC6130].
3. Applicability Statement 3. Applicability Statement
This document specifies OLSRv2, a proactive routing protocol intended This document specifies OLSRv2, a proactive routing protocol intended
for use in mobile ad hoc networks (MANETs) [RFC2501]. The protocol's for use in Mobile Ad Hoc Networks (MANETs) [RFC2501]. The protocol's
applicability is determined by its characteristics, which are that applicability is determined by its characteristics, which are that
this protocol: this protocol:
o Is designed to work in networks with a dynamic topology, and in o Is designed to work in networks with a dynamic topology and in
which messages may be lost, such as due to collisions over which messages may be lost, such as due to collisions over
wireless media. wireless media.
o Supports routers that each have one or more participating OLSRv2 o Supports routers that each have one or more participating OLSRv2
interfaces, which will consist of some or all of its MANET interfaces, which will consist of some or all of its MANET
interfaces using [RFC6130]. The set of a router's OLSRv2 interfaces using [RFC6130]. The set of a router's OLSRv2
interfaces, and the sets of its other MANET and non-MANET interfaces, and the sets of its other MANET and non-MANET
interfaces, may change over time. Each interface may have one or interfaces, may change over time. Each interface may have one or
more network addresses (which may have prefix lengths), and these more network addresses (which may have prefix lengths), and these
may also be dynamically changing. may also be dynamically changing.
skipping to change at page 10, line 28 skipping to change at page 9, line 47
metrics). Incoming link metric values are to be determined by a metrics). Incoming link metric values are to be determined by a
process outside this specification. process outside this specification.
o Is optimized for large and dense networks; the larger and more o Is optimized for large and dense networks; the larger and more
dense a network, the more optimization can be achieved by using dense a network, the more optimization can be achieved by using
MPRs, compared to the classic link state algorithm [MPR]. MPRs, compared to the classic link state algorithm [MPR].
o Uses [RFC5444] as described in its "Intended Usage" appendix and o Uses [RFC5444] as described in its "Intended Usage" appendix and
by [RFC5498]. by [RFC5498].
o Allows "external" and "internal" extensibility (adding new message o Allows "external" and "internal" extensibility (adding new Message
types and adding information to existing messages) as enabled by Types and adding information to existing messages) as enabled by
[RFC5444]. [RFC5444].
o Is designed to work in a completely distributed manner, and does o Is designed to work in a completely distributed manner and does
not depend on any central entity. not depend on any central entity.
4. Protocol Overview and Functioning 4. Protocol Overview and Functioning
The objectives of this protocol are for each router to: The objectives of this protocol are for each router to:
o Identify all destinations in the network. o Identify all destinations in the network.
o Identify a sufficient subset of links in the network, in order o Identify a sufficient subset of links in the network, in order
that shortest routes can be calculated to all available that shortest routes can be calculated to all available
destinations. destinations.
o Provide a Routing Set, containing these shortest routes from this o Provide a Routing Set containing these shortest routes from this
router to all destinations (routable addresses and local links). router to all destinations (routable addresses and local links).
4.1. Overview 4.1. Overview
These objectives are achieved, for each router, by: These objectives are achieved, for each router, by:
o Using [RFC6130] to identify symmetric 1-hop neighbors and o Using NHDP [RFC6130] to identify symmetric 1-hop neighbors and
symmetric 2-hop neighbors. symmetric 2-hop neighbors.
o Reporting its participation in OLSRv2, and its willingness to be a o Reporting its participation in OLSRv2, and its willingness to be a
flooding MPR and to be a routing MPR, by extending the HELLO flooding MPR and to be a routing MPR, by extending the HELLO
messages defined in [RFC6130], by the addition of an MPR_WILLING messages defined in [RFC6130] by the addition of an MPR_WILLING
Message TLV. The router's "flooding willingness" indicates how Message TLV. The router's "flooding willingness" indicates how
willing it is to participate in MPR flooding. The router's willing it is to participate in MPR flooding. The router's
"routing willingness" indicates how willing it is to be an "routing willingness" indicates how willing it is to be an
intermediate router for routing. Note that a router is still able intermediate router for routing. Note that a router is still able
to be a routing source or destination, even if unwilling to to be a routing source or destination, even if unwilling to
perform either function. perform either function.
o Extending the HELLO messages defined in [RFC6130] to allow the o Extending the HELLO messages defined in [RFC6130] to allow the
addition of directional link metrics to advertised links with addition of directional link metrics to advertised links with
other routers participating in OLSRv2, and to indicate which link other routers participating in OLSRv2 and to indicate which link
metric type is being used by those routers. Both incoming and metric type is being used by those routers. Both incoming and
outgoing link metrics may be reported, the former determined by outgoing link metrics may be reported, the former determined by
the advertising router. the advertising router.
o Selecting flooding MPRs and routing MPRs from among its willing o Selecting flooding MPRs and routing MPRs from among its willing
symmetric 1-hop neighbors such that, for each set of MPRs, all symmetric 1-hop neighbors such that, for each set of MPRs, all
symmetric 2-hop neighbors are reachable either directly or via at symmetric 2-hop neighbors are reachable either directly or via at
least one selected MPR, using a path of appropriate minimum total least one selected MPR, using a path of appropriate minimum total
metric for at least routing MPR selection. An analysis and metric for at least routing MPR selection. An analysis and
examples of MPR selection algorithms are given in [MPR]; a examples of MPR selection algorithms are given in [MPR]; a
skipping to change at page 13, line 8 skipping to change at page 12, line 22
received TC messages. received TC messages.
o The MPR flooding mechanism, including the inclusion of message o The MPR flooding mechanism, including the inclusion of message
originator address and sequence number to manage duplicate originator address and sequence number to manage duplicate
messages, using information recorded in the Received Message messages, using information recorded in the Received Message
Information Base. Information Base.
o The response to other events, such as the expiration of o The response to other events, such as the expiration of
information in the Information Bases. information in the Information Bases.
This protocol inherits the stability of a link state algorithm, and This protocol inherits the stability of a link state algorithm and
has the advantage of having routes immediately available when needed, has the advantage of having routes immediately available when needed,
due to its proactive nature. due to its proactive nature.
This protocol only interacts with IP through routing table This protocol only interacts with IP through routing table management
management, and the use of the sending IP address for IP datagrams and the use of the sending IP address for IP datagrams containing
containing messages used by this specification. messages used by this specification.
4.2. Routers and Interfaces 4.2. Routers and Interfaces
In order for a router to participate in a MANET using this protocol In order for a router to participate in a MANET using this protocol,
it must have at least one, and possibly more, OLSRv2 interfaces. it must have at least one, and possibly more, OLSRv2 interfaces.
Each OLSRv2 interface: Each OLSRv2 interface:
o Is a MANET interface, as specified in [RFC6130]. In particular it o Is a MANET interface, as specified in [RFC6130]. In particular,
must be configured with one or more network addresses; these it must be configured with one or more network addresses; these
addresses must each be specific to this router, and must include addresses must each be specific to this router and must include
any address that will be used as the sending address of any IP any address that will be used as the sending address of any IP
packet sent on this OLSRv2 interface. packet sent on this OLSRv2 interface.
o Has a number of interface parameters, adding to those specified in o Has a number of interface parameters, adding to those specified in
[RFC6130]. [RFC6130].
o Has an Interface Information Base, extending that specified in o Has an Interface Information Base, extending that specified in
[RFC6130]. [RFC6130].
o Generates and processes HELLO messages according to [RFC6130], o Generates and processes HELLO messages according to [RFC6130],
extended as specified in Section 15. extended as specified in Section 15.
In addition to a set of OLSRv2 interfaces as described above, each In addition to a set of OLSRv2 interfaces as described above, each
router: router:
o May have one or more non-OLSRv2 interfaces (which may include o May have one or more non-OLSRv2 interfaces (which may include
MANET interfaces and/or non-MANET interfaces) and/or local MANET interfaces and/or non-MANET interfaces) and/or local
attached networks for which this router can accept IP packets. attached networks for which this router can accept IP packets.
All routable addresses for which the router is to accept IP All routable addresses for which the router is to accept IP
packets must be used as an (OLSRv2 or non-OLSRv2) interface packets must be used as an (OLSRv2 or non-OLSRv2) interface
network address, or as an address of a local attached network of network address or as an address of a local attached network of
the router. the router.
o Has a number of router parameters, adding to those specified in o Has a number of router parameters, adding to those specified in
[RFC6130]. [RFC6130].
o Has a Local Information Base, extending that specified in o Has a Local Information Base, extending that specified in
[RFC6130], including selection of an originator address and [RFC6130], including selection of an originator address and
recording any locally attached networks. recording any locally attached networks.
o Has a Neighbor Information Base, extending that specified in o Has a Neighbor Information Base, extending that specified in
skipping to change at page 14, line 24 skipping to change at page 13, line 41
processed once, and forwarded at most once on each OLSRv2 processed once, and forwarded at most once on each OLSRv2
interface, by a router. interface, by a router.
o Generates, receives, and processes TC messages. o Generates, receives, and processes TC messages.
4.3. Information Base Overview 4.3. Information Base Overview
Each router maintains the Information Bases described in the Each router maintains the Information Bases described in the
following sections. These are used for describing the protocol in following sections. These are used for describing the protocol in
this specification. An implementation of this protocol may maintain this specification. An implementation of this protocol may maintain
this information in the indicated form, or in any other organization this information in the indicated form or in any other organization
which offers access to this information. In particular, note that it that offers access to this information. In particular, note that it
is not necessary to remove Tuples from Sets at the exact time is not necessary to remove Tuples from Sets at the exact time
indicated, only to behave as if the Tuples were removed at that time. indicated, only to behave as if the Tuples were removed at that time.
4.3.1. Local Information Base 4.3.1. Local Information Base
The Local Information Base is specified in [RFC6130], and contains a The Local Information Base is specified in [RFC6130] and contains a
router's local configuration. It is extended in this specification router's local configuration. It is extended in this specification
to also record an originator address, and to include a router's: to also record an originator address and to include a router's:
o Originator Set, containing addresses that were recently used as o Originator Set, containing addresses that were recently used as
this router's originator address, and is used, together with the this router's originator address, that is used, together with the
router's current originator address, to enable a router to router's current originator address, to enable a router to
recognize and discard control traffic which was originated by the recognize and discard control traffic that was originated by the
router itself. router itself.
o Local Attached Network Set, containing network addresses of o Local Attached Network Set, containing network addresses of
networks to which this router can act as a gateway, and advertises networks to which this router can act as a gateway, that it
in its TC messages. advertises in its TC messages.
4.3.2. Interface Information Bases 4.3.2. Interface Information Base
The Interface Information Base for each OLSRv2 interface is as The Interface Information Base for each OLSRv2 interface is as
specified in [RFC6130], extended to also record, in each Link Set, specified in [RFC6130], extended to also record, in each Link Set,
link metric values (incoming and outgoing) and flooding MPR selector link metric values (incoming and outgoing) and flooding MPR selector
information. information.
4.3.3. Neighbor Information Base 4.3.3. Neighbor Information Base
The Neighbor Information Base is specified in [RFC6130], and is The Neighbor Information Base is specified in [RFC6130] and is
extended to also record, in the Neighbor Tuple for each neighbor: extended to also record, in the Neighbor Tuple for each neighbor:
o Its originator address. o Its originator address.
o Neighbor metric values, these being the minimum of the link metric o Neighbor metric values, these being the minimum of the link metric
values in the indicated direction for all symmetric 1-hop links values in the indicated direction for all symmetric 1-hop links
with that neighbor. with that neighbor.
o Its willingness to be a flooding MPR and to be a routing MPR. o Its willingness to be a flooding MPR and to be a routing MPR.
o Whether it has been selected by this router as a flooding MPR or o Whether it has been selected by this router as a flooding MPR or
as a routing MPR, and whether it is a routing MPR selector of this as a routing MPR and whether it is a routing MPR selector of this
router. (Whether it is a flooding MPR selector of this neighbor router. (Whether it is a flooding MPR selector of this neighbor
is recorded in the Interface Information Base.) is recorded in the Interface Information Base.)
o Whether it is to be advertised in TC messages sent by this router. o Whether it is to be advertised in TC messages sent by this router.
4.3.4. Topology Information Base 4.3.4. Topology Information Base
The Topology Information Base in each router contains: The Topology Information Base in each router contains:
o An Advertising Remote Router Set, recording each remote router o An Advertising Remote Router Set, recording each remote router
skipping to change at page 15, line 50 skipping to change at page 15, line 18
(i.e., in a single IP hop from that remote router), as reported by (i.e., in a single IP hop from that remote router), as reported by
received TC messages. received TC messages.
o An Attached Network Set, recording networks to which a remote o An Attached Network Set, recording networks to which a remote
router has advertised that it may act as a gateway. These router has advertised that it may act as a gateway. These
networks may be reached in one or more IP hops from that remote networks may be reached in one or more IP hops from that remote
router. router.
o A Routing Set, recording routes from this router to all available o A Routing Set, recording routes from this router to all available
destinations. The IP routing table is to be updated using this destinations. The IP routing table is to be updated using this
Routing Set. (A router may choose to use any or all destination Routing Set. (A router may choose to use any or all destination
network addresses in the Routing Set to update the IP routing network addresses in the Routing Set to update the IP routing
table, this selection is outside the scope of this specification.) table. This selection is outside the scope of this
specification.)
The purpose of the Topology Information Base is to record information The purpose of the Topology Information Base is to record information
used, in addition to that in the Local Information Base, the used, in addition to that in the Local Information Base, the
Interface Information Bases and the Neighbor Information Base, to Interface Information Bases, and the Neighbor Information Base, to
construct the Routing Set (which is also included in the Topology construct the Routing Set (which is also included in the Topology
Information Base). Information Base).
This specification describes the calculation of the Routing Set based This specification describes the calculation of the Routing Set based
on a Topology Graph constructed in two phases. First, a "backbone" on a Topology Graph constructed in two phases. First, a "backbone"
graph representing the routers in the MANET, and the connectivity graph representing the routers in the MANET, and the connectivity
between them, is constructed from the Local Information Base, the between them, is constructed from the Local Information Base, the
Neighbor Information Base and the Router Topology Set. Second, this Neighbor Information Base, and the Router Topology Set. Second, this
graph is "decorated" with additional destination network addresses graph is "decorated" with additional destination network addresses
using the Local Information Base, the Routable Address Topology Set using the Local Information Base, the Routable Address Topology Set,
and the Attached Network Set. and the Attached Network Set.
The Topology Graph does not need to be recorded in the Topology The Topology Graph does not need to be recorded in the Topology
Information Base, it can either be constructed as required when the Information Base; it can either be constructed as required when the
Routing Set is to be changed, or need not be explicitly constructed Routing Set is to be changed or need not be explicitly constructed
(as illustrated in Appendix C). An implementation may however (as illustrated in Appendix C). An implementation may, however,
construct and retain the Topology Graph if preferred. construct and retain the Topology Graph if preferred.
4.3.5. Received Message Information Base 4.3.5. Received Message Information Base
The Received Message Information Base in each router contains: The Received Message Information Base in each router contains:
o A Received Set for each OLSRv2 interface, describing TC messages o A Received Set for each OLSRv2 interface, describing TC messages
received by this router on that OLSRv2 interface. received by this router on that OLSRv2 interface.
o A Processed Set, describing TC messages processed by this router. o A Processed Set, describing TC messages processed by this router.
o A Forwarded Set, describing TC messages forwarded by this router. o A Forwarded Set, describing TC messages forwarded by this router.
The Received Message Information Base serves the MPR flooding The Received Message Information Base serves the MPR flooding
mechanism by ensuring that received messages are forwarded at most mechanism by ensuring that received messages are forwarded at most
once by a router, and also ensures that received messages are once by a router and also ensures that received messages are
processed exactly once by a router. The Received Message Information processed exactly once by a router. The Received Message Information
Base may also record information about other Message Types that use Base may also record information about other Message Types that use
the MPR flooding mechanism. the MPR flooding mechanism.
4.4. Signaling Overview 4.4. Signaling Overview
This protocol generates and processes HELLO messages according to This protocol generates and processes HELLO messages according to
[RFC6130]. HELLO messages transmitted on OLSRv2 interfaces are [RFC6130]. HELLO messages transmitted on OLSRv2 interfaces are
extended according to Section 15 of this specification to include an extended according to Section 15 of this specification to include an
originator address, link metrics, and MPR selection information. originator address, link metrics, and MPR selection information.
This specification defines a single Message Type, the TC message. TC This specification defines a single Message Type, the TC message. TC
messages are sent by their originating router proactively, at a messages are sent by their originating router proactively, at a
regular interval, on all OLSRv2 interfaces. This interval may be regular interval, on all OLSRv2 interfaces. This interval may be
fixed, or may be dynamic, for example it may be backed off due to fixed or dynamic, for example, it may be backed off due to congestion
congestion or network stability. TC messages may also be sent as a or network stability. TC messages may also be sent as a response to
response to a change in the router itself, or its advertised a change in the router itself, or its advertised symmetric 1-hop
symmetric 1-hop neighborhood, for example on first being selected as neighborhood, for example, on first being selected as a routing MPR.
a routing MPR.
Because TC messages are sent periodically, this protocol is tolerant Because TC messages are sent periodically, this protocol is tolerant
of unreliable transmissions of TC messages. Message losses may occur of unreliable transmissions of TC messages. Message losses may occur
more frequently in wireless networks due to collisions or other more frequently in wireless networks due to collisions or other
transmission problems. This protocol may use "jitter", randomized transmission problems. This protocol may use "jitter", randomized
adjustments to message transmission times, to reduce the incidence of adjustments to message transmission times, to reduce the incidence of
collisions, as specified in [RFC5148]. collisions, as specified in [RFC5148].
This protocol is tolerant of out of sequence delivery of TC messages This protocol is tolerant of out-of-sequence delivery of TC messages
due to in transit message reordering. Each router maintains an due to in-transit message reordering. Each router maintains an
Advertised Neighbor Sequence Number (ANSN) that is incremented when Advertised Neighbor Sequence Number (ANSN) that is incremented when
its recorded neighbor information that is to be included in its TC its recorded neighbor information that is to be included in its TC
messages changes. This ANSN is included in the router's TC messages. messages changes. This ANSN is included in the router's TC messages.
The recipient of a TC message can use this included ANSN to identify The recipient of a TC message can use this included ANSN to identify
which of the information it has received is most recent, even if which of the information it has received is most recent, even if
messages have been reordered while in transit. Only the most recent messages have been reordered while in transit. Only the most recent
information received is used, older information received later is information received is used; older information received later is
discarded. discarded.
TC messages may be "complete" or "incomplete". A complete TC message TC messages may be "complete" or "incomplete". A complete TC message
advertises all of the originating router's routing MPR selectors, it advertises all of the originating router's routing MPR selectors; it
may also advertise other symmetric 1-hop neighbors. Complete TC may also advertise other symmetric 1-hop neighbors. Complete TC
messages are generated periodically (and also, optionally, in messages are generated periodically (and also, optionally, in
response to symmetric 1-hop neighborhood changes). Incomplete TC response to symmetric 1-hop neighborhood changes). 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. without repeating unchanged information.
TC messages, and HELLO messages as extended by this specification, TC messages, and HELLO messages as extended by this specification,
define (by inclusion, or by deduction when having a single address) define (by inclusion or by deduction when having a single address) an
an originator address for the router that created the message. A TC originator address for the router that created the message. A TC
message reports both the originator addresses and routable addresses message reports both the originator addresses and routable addresses
of its advertised neighbors, distinguishing the two using an Address of its advertised neighbors, distinguishing the two using an Address
Block TLV (an address may be both routable and an originator Block TLV (an address may be both routable and an originator
address). TC messages also report the originator's locally attached address). TC messages also report the originator's locally attached
networks. networks.
TC messages are MPR flooded throughout the MANET. A router TC messages are MPR flooded throughout the MANET. A router
retransmits a TC message received on an OLSRv2 interface if and only retransmits a TC message received on an OLSRv2 interface if and only
if the message did not originate at this router and has not been if the message did not originate at this router and has not been
previously forwarded by this router, this is the first time the previously forwarded by this router, this is the first time the
skipping to change at page 18, line 17 skipping to change at page 17, line 44
e.g., allowing a router to ensure that nearer routers are kept more e.g., allowing a router to ensure that nearer routers are kept more
up to date than distant routers, such as is used in Fisheye State up to date than distant routers, such as is used in Fisheye State
Routing [FSR] and Fuzzy Sighted Link State routing [FSLS]. This is Routing [FSR] and Fuzzy Sighted Link State routing [FSLS]. This is
enabled using [RFC5497]. enabled using [RFC5497].
TC messages include outgoing neighbor metrics that will be used in TC messages include outgoing neighbor metrics that will be used in
the selection of routes. the selection of routes.
4.5. Link Metrics 4.5. Link Metrics
OLSRv1 [RFC3626] created minimum hop routes to destinations. However OLSRv1 [RFC3626] created minimum hop routes to destinations.
in many, if not most, circumstances, better routes (in terms of However, in many, if not most, circumstances, better routes (in terms
quality of service for end users) can be created by use of link of quality of service for end users) can be created by use of link
metrics. metrics.
OLSRv2, as defined in this specification, supports metric-based OLSRv2, as defined in this specification, supports metric-based
routing, i.e., it allows links to each have a chosen metric. Link routing, i.e., it allows links to each have a chosen metric. Link
metrics as defined in OLSRv2 are additive, and the routes that are to metrics as defined in OLSRv2 are additive, and the routes that are to
be created are those with the minimum sum of the link metrics along be created are those with the minimum sum of the link metrics along
that route. that route.
Link metrics are defined to be directional; the link metric from one Link metrics are defined to be directional; the link metric from one
router to another may be different from that on the reverse link. router to another may be different from that on the reverse link.
The link metric is assessed at the receiver, as on a (typically) The link metric is assessed at the receiver, as on a (typically)
wireless link, that is the better informed as to link information. wireless link, that is the better informed as to link information.
Both incoming and outgoing link information is used by OLSRv2, the Both incoming and outgoing link information is used by OLSRv2; the
distinctions in this specification must be clearly followed. distinctions in this specification must be clearly followed.
This specification also defines both incoming and outgoing neighbor This specification also defines both incoming and outgoing neighbor
metrics for each symmetric 1-hop neighbor, these being the minimum metrics for each symmetric 1-hop neighbor, these being the minimum
value of the link metrics in the same direction for all symmetric value of the link metrics in the same direction for all symmetric
links with that neighbor. Note that this means that all neighbor links with that neighbor. Note that this means that all neighbor
metric values are link metric values and that specification of, for metric values are link metric values and that specification of, for
example, link metric value encoding also includes encoding of example, link metric value encoding also includes encoding of
neighbor metric values. neighbor metric values.
skipping to change at page 19, line 7 skipping to change at page 18, line 38
of a defined Address Block TLV, for link metrics with specific of a defined Address Block TLV, for link metrics with specific
meanings to be defined and either allocated by IANA or privately meanings to be defined and either allocated by IANA or privately
used. Each HELLO or TC message carrying link (or neighbor) metrics used. Each HELLO or TC message carrying link (or neighbor) metrics
thus indicates which link metric information it is carrying, allowing thus indicates which link metric information it is carrying, allowing
routers to determine if they can interoperate. If link metrics routers to determine if they can interoperate. If link metrics
require additional signaling to determine their values, whether in require additional signaling to determine their values, whether in
HELLO messages or otherwise, then this is permitted but is outside HELLO messages or otherwise, then this is permitted but is outside
the scope of this specification. the scope of this specification.
Careful consideration should be given to how to use link metrics. In Careful consideration should be given to how to use link metrics. In
particular it is advisable to not simply default to use of all links particular, it is advisable to not simply default to use of all links
with equal metrics (i.e., hop count) for routing without careful with equal metrics (i.e., hop count) for routing without careful
consideration of whether that is appropriate or not. consideration of whether that is appropriate or not.
4.6. Flooding MPRs and Routing MPR 4.6. Flooding MPRs and Routing MPR
This specification uses two sets of MPRs: flooding MPRs and routing This specification uses two sets of MPRs: flooding MPRs and routing
MPRs. These are selected separately, because: MPRs. These are selected separately, because:
o Flooding MPRs may use metrics, routing MPRs must use metrics. o Flooding MPRs may use metrics; routing MPRs must use metrics.
o When flooding MPRs use metrics, these are outgoing link metrics, o When flooding MPRs use metrics, these are outgoing link metrics;
routing MPRs use incoming neighbor metrics. routing MPRs use incoming neighbor metrics.
o Flooding MPRs need not be selected per OLSRv2 interface, routing o Flooding MPRs must be selected per OLSRv2 interface; routing MPRs
MPRs must be selected per OLSRv2 interface. need not be selected per OLSRv2 interface.
4.7. Routing Set Use 4.7. Routing Set Use
The purpose of the Routing Set is to determine and record routes The purpose of the Routing Set is to determine and record routes
(local interface network address and next hop interface network (local interface network address and next-hop interface network
address) to all possible routable addresses advertised by this address) to all possible routable addresses advertised by this
protocol, as well as of all destinations that are local, i.e., within protocol as well as all destinations that are local, i.e., within one
one hop, to the router (whether using routable addresses or not). hop, to the router (whether using routable addresses or not). Only
Only symmetric links are used in such routes. symmetric links are used in such routes.
It is intended that the Routing Set can be used for IP packet It is intended that the Routing Set can be used for IP packet
routing, by using its contents to update the IP routing table. That routing, by using its contents to update the IP routing table. That
update, and whether any Routing Tuples are not used in the IP routing update, and whether any Routing Tuples are not used when updating the
table, is outside the scope of this specification. IP routing table, is outside the scope of this specification.
The signaling in this specification has been designed so that a The signaling in this specification has been designed so that a
"backbone" Topology Graph of routers, each identified by its "backbone" Topology Graph of routers, each identified by its
originator address, with at most one direct connection between any originator address, with at most one direct connection between any
pair of routers, can be constructed (from the Neighbor Set and the pair of routers, can be constructed (from the Neighbor Set and the
Router Topology Set) using a suitable minimum path length algorithm. Router Topology Set) using a suitable minimum path length algorithm.
This Topology Graph can then have other network addresses (routable, This Topology Graph can then have other network addresses (routable
or of symmetric 1-hop neighbors) added to it (using the Interface or of symmetric 1-hop neighbors) added to it (using the Interface
Information Bases, the Routable Address Topology Set and the Attached Information Bases, the Routable Address Topology Set, and the
Network Set). Attached Network Set).
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 [RFC6130] plus those defined in this section. The defined in [RFC6130] plus those defined in this section. The
separation in [RFC6130] into interface parameters, router parameters separation in [RFC6130] into interface parameters, router parameters,
and constants is also used in this specification. and constants is also used in this specification.
As for the parameters in [RFC6130], parameters defined in this Similarly to the parameters in [RFC6130], parameters defined in this
specification MAY be changed dynamically by a router, and need not be specification MAY be changed dynamically by a router and need not be
the same on different routers, even in the same MANET, or, for the same on different routers, even in the same MANET, or, for
interface parameters, on different interfaces of the same router. interface parameters, on different interfaces of the same router.
5.1. Protocol and Port Numbers 5.1. Protocol and Port Numbers
This protocol specifies TC messages, which are included in packets as This protocol specifies TC messages, which are included in packets as
defined by [RFC5444]. These packets MUST be sent either using the defined by [RFC5444]. These packets MUST be sent either using the
"manet" protocol number or the "manet" UDP well-known port number, as "manet" protocol number or the "manet" UDP well-known port number, as
specified in [RFC5498]. specified in [RFC5498].
TC messages and HELLO messages [RFC6130] MUST, in a given MANET, TC messages and HELLO messages [RFC6130] MUST, in a given MANET,
either both be using IP or both be using UDP, in order that it is either both use IP or both use UDP, in order for it to be possible to
possible to combine messages of both protocols into the same combine messages of both protocols into the same [RFC5444] packet for
[RFC5444] packet for transmission. transmission.
5.2. Multicast Address 5.2. Multicast Address
This protocol specifies TC messages, which are included in packets as This protocol specifies TC messages, which are included in packets as
defined by [RFC5444]. These packets MAY be transmitted using the defined by [RFC5444]. These packets MAY be transmitted using the
Link-Local multicast address "LL-MANET-Routers", as specified in Link-Local multicast address "LL-MANET-Routers", as specified in
[RFC5498]. [RFC5498].
5.3. Interface Parameters 5.3. Interface Parameters
skipping to change at page 21, line 35 skipping to change at page 21, line 22
5.4.2. Link Metric Parameters 5.4.2. Link Metric Parameters
All routes found using this specification use a single link metric All routes found using this specification use a single link metric
type that is specified by the router parameter LINK_METRIC_TYPE, type that is specified by the router parameter LINK_METRIC_TYPE,
which may take any value from 0 to 255, both inclusive. which may take any value from 0 to 255, both inclusive.
5.4.3. Message Intervals 5.4.3. Message Intervals
The following parameters regulate TC message transmissions by a The following parameters regulate TC message transmissions by a
router. TC messages are usually sent periodically, but MAY also be router. TC messages are usually sent periodically but MAY also be
sent in response to changes in the router's Neighbor Set and/or Local sent in response to changes in the router's Neighbor Set and/or Local
Attached Network Set. In a highly dynamic network, and with a larger Attached Network Set. In a highly dynamic network, and with a larger
value of the parameter TC_INTERVAL and a smaller value of the value of the parameter TC_INTERVAL and a smaller value of the
parameter TC_MIN_INTERVAL, TC messages MAY be transmitted more often parameter TC_MIN_INTERVAL, TC messages MAY be transmitted more often
in response to changes than periodically. However, because a router in response to changes than periodically. However, because a router
has no knowledge of, for example, routers remote to it (i.e., beyond has no knowledge of, for example, routers remote to it (i.e., beyond
two hops away) joining the network, TC messages MUST NOT be sent two hops away) joining the network, TC messages MUST NOT be sent
purely responsively. purely responsively.
TC_INTERVAL: TC_INTERVAL:
The maximum time between the transmission of two successive TC The maximum time between the transmission of two successive TC
messages by this router. When no TC messages are sent in response messages by this router. When no TC messages are sent in response
to local network changes (by design, or because the local network to local network changes (by design or because the local network
is not changing) then TC messages MUST be sent at a regular is not changing), then TC messages MUST be sent at a regular
interval TC_INTERVAL, possibly modified by jitter as specified in interval TC_INTERVAL, possibly modified by jitter, as specified in
[RFC5148]. [RFC5148].
TC_MIN_INTERVAL: TC_MIN_INTERVAL:
The minimum interval between transmission of two successive TC The minimum interval between transmission of two successive TC
messages by this router. (This minimum interval MAY be modified messages by this router. (This minimum interval MAY be modified
by jitter, as specified in [RFC5148].) by jitter, as specified in [RFC5148].)
The following constraints apply to these parameters: The following constraints apply to these parameters:
o TC_INTERVAL > 0 o TC_INTERVAL > 0
skipping to change at page 22, line 29 skipping to change at page 22, line 17
[RFC5497]. [RFC5497].
5.4.4. Advertised Information Validity Times 5.4.4. 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: T_HOLD_TIME:
Used as the minimum value in the TLV with Type = VALIDITY_TIME Used as the minimum value in the TLV with Type = VALIDITY_TIME
included in all TC messages sent by this router. If a single included in all TC messages sent by this router. If a single
value of parameter TC_HOP_LIMIT (see Section 5.4.7) is used then value of parameter TC_HOP_LIMIT (see Section 5.4.7) is used, then
this will be the only value in that TLV. this will be the only value in that TLV.
A_HOLD_TIME: A_HOLD_TIME:
The period during which TC messages are sent after they no longer The period during which TC messages are sent after they no longer
have any advertised information to report, but are sent in order have any advertised information to report but are sent in order to
to accelerate outdated information removal by other routers. accelerate outdated information removal by other routers.
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 T_HOLD_TIME >= TC_INTERVAL o T_HOLD_TIME >= TC_INTERVAL
o If TC messages can be lost, then both T_HOLD_TIME and A_HOLD_TIME o If TC messages can be lost, then both T_HOLD_TIME and A_HOLD_TIME
skipping to change at page 23, line 33 skipping to change at page 23, line 23
o F_HOLD_TIME > 0 o F_HOLD_TIME > 0
o Both of these parameters SHOULD be greater than the maximum o Both of these parameters SHOULD be greater than the maximum
difference 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.6. Jitter 5.4.6. Jitter
If jitter, as defined in [RFC5148], is used then the governing jitter If jitter, as defined in [RFC5148], is used, then the governing
parameters are as follows: jitter parameters are as follows:
TP_MAXJITTER: TP_MAXJITTER:
Represents the value of MAXJITTER used in [RFC5148] for Represents the value of MAXJITTER used in [RFC5148] for
periodically generated TC messages sent by this router. periodically generated TC messages sent by this router.
TT_MAXJITTER: TT_MAXJITTER:
Represents the value of MAXJITTER used in [RFC5148] for externally Represents the value of MAXJITTER used in [RFC5148] for externally
triggered TC messages sent by this router. triggered TC messages sent by this router.
F_MAXJITTER: F_MAXJITTER:
Represents the default value of MAXJITTER used in [RFC5148] for Represents the default value of MAXJITTER used in [RFC5148] for
messages forwarded by this router. However, before using messages forwarded by this router. However, before using
F_MAXJITTER a router MAY attempt to deduce a more appropriate F_MAXJITTER, a router MAY attempt to deduce a more appropriate
value of MAXJITTER, for example based on any TLVs with Type = value of MAXJITTER, for example, based on any TLVs with Type =
INTERVAL_TIME or Type = VALIDITY_TIME contained in the message to INTERVAL_TIME or Type = VALIDITY_TIME contained in the message to
be forwarded. be forwarded.
For constraints on these parameters see [RFC5148]. For constraints on these parameters, see [RFC5148].
5.4.7. Hop Limit 5.4.7. Hop Limit
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 router. However each other router, at any messages sent by the same router. However, each other router, at any
hop count distance, MUST see a regular pattern of TC messages in hop count distance, MUST see a regular pattern of TC messages in
order that meaningful values of TLVs with Type = INTERVAL_TIME and order that meaningful values of TLVs with Type = INTERVAL_TIME and
Type = VALIDITY_TIME at each hop count distance can be included as Type = VALIDITY_TIME at each hop count distance can be included as
defined in [RFC5497]. Thus the pattern of TC_HOP_LIMIT MUST be defined in [RFC5497]. Thus, the pattern of TC_HOP_LIMIT MUST be
defined to have this property. For example the repeating pattern defined to have this property. For example, the repeating pattern
(255 4 4) satisfies this property (having period TC_INTERVAL at hop (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 greater 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 satisfy than 4), but the repeating pattern (255 255 4 4) does not satisfy
this property because at hop counts greater than 4, message intervals this property because at hop counts greater than 4, message intervals
are alternately TC_INTERVAL and 3 x TC_INTERVAL. are alternately TC_INTERVAL and 3 x TC_INTERVAL.
The following constraints apply to this parameter: The following constraints apply to this parameter:
o The maximum value of TC_HOP_LIMIT >= the network diameter in hops, o The maximum value of TC_HOP_LIMIT >= the network diameter in hops;
a value of 255 is RECOMMENDED. Note that if using a pattern of a value of 255 is RECOMMENDED. Note that if using a pattern of
different values of TC_HOP_LIMIT as described above, then only the different values of TC_HOP_LIMIT as described above, then only the
maximum value in the pattern is so constrained. maximum value in the pattern is so constrained.
o All values of TC_HOP_LIMIT >= 2. o All values of TC_HOP_LIMIT >= 2.
5.4.8. Willingness 5.4.8. Willingness
Each router has two willingness parameters: WILL_FLOODING and Each router has two willingness parameters: WILL_FLOODING and
WILL_ROUTING, each of which MUST be in the range WILL_NEVER to WILL_ROUTING, each of which MUST be in the range WILL_NEVER to
WILL_ALWAYS, inclusive. WILL_ALWAYS, inclusive.
WILL_FLOODING represents the router's willingness to be selected as a WILL_FLOODING represents the router's willingness to be selected as a
flooding MPR and hence to participate in MPR flooding, in particular flooding MPR and hence to participate in MPR flooding, in particular
of TC messages. of TC messages.
WILL_ROUTING represents the router's willingness to be selected as a WILL_ROUTING represents the router's willingness to be selected as a
routing MPR and hence to be an intermediate router on routes. routing MPR and hence to be an intermediate router on routes.
In either case, the higher the value, the greater the router's In either case, the higher the value, the greater the router's
willingness to be a flooding or routing MPR, respectively. If a willingness to be a flooding or routing MPR, as appropriate. If a
router has a willingness value of WILL_NEVER (the lowest possible router has a willingness value of WILL_NEVER (the lowest possible
value) it does not perform the corresponding task. A MANET using value), it does not perform the corresponding task. A MANET using
this protocol with too many routers having either willingness value this protocol with too many routers having either of the willingness
equal to WILL_NEVER will not function; it MUST be ensured, by parameters WILL_FLOODING or WILL_ROUTING equal to WILL_NEVER will not
administrative or other means, that this does not happen. function; it MUST be ensured, by administrative or other means, that
this does not happen.
Note that how many routers having either willingness value equal to Note that the proportion at which the routers having a willingness
WILL_NEVER is "too many" depends on the network topology - which, in value equal to WILL_NEVER is "too many" depends on the network
a MANET may change dynamically. Willingness is intended to enable topology -- which, in a MANET, may change dynamically. Willingness
that certain routers (e.g., routers that have generous resources, is intended to enable that certain routers (e.g., routers that have
such as a permanent power supply) can be configured to assume more of generous resources, such as a permanent power supply) can be
the network operation, while others (e.g., routers that have lesser configured to assume more of the network operation, while others
resources, such as are battery operated) can avoid such tasks. A (e.g., routers that have lesser resources, such as are battery
general guideline would be that only if a router is not actually able operated) can avoid such tasks. A general guideline would be that
to assume the task (flooding or routing) should it be configured with only if a router is not actually able to assume the task (flooding or
the corresponding willingness WILL_NEVER. routing) should it be configured with the corresponding willingness
WILL_NEVER.
If a router has a willingness value equal to WILL_ALWAYS (the highest If a router has a willingness value equal to WILL_ALWAYS (the highest
possible value) then it will always be selected as a flooding or possible value), then it will always be selected as a flooding or
routing MPR, respectively, by all symmetric 1-hop neighbors. routing MPR, as appropriate, by all symmetric 1-hop neighbors.
In a MANET in which all routers have WILL_FLOODING = WILL_ALWAYS, In a MANET in which all routers have WILL_FLOODING = WILL_ALWAYS,
flooding reduction will effectively be disabled, and flooding will flooding reduction will effectively be disabled, and flooding will
perform as blind flooding. perform as blind flooding.
In a MANET in which all routers have WILL_ROUTING = WILL_ALWAYS, In a MANET in which all routers have WILL_ROUTING = WILL_ALWAYS,
topology reduction will effectively be disabled, and all routers will topology reduction will effectively be disabled, and all routers will
advertise all of their links in TC messages. advertise all of their links in TC messages.
A router that has WILL_ROUTING = WILL_NEVER will not act as an A router that has WILL_ROUTING = WILL_NEVER will not act as an
intermediate router in the MANET. Such a router can, act as a intermediate router in the MANET. Such a router can act as a source,
source, destination or gateway to another routing domain. destination, or gateway to another routing domain.
Different routers MAY have different values for WILL_FLOODING and/or Different routers MAY have different values for WILL_FLOODING and/or
WILL_ROUTING. WILL_ROUTING.
The following constraints apply to these parameters: The following constraints apply to these parameters:
o WILL_NEVER <= WILL_FLOODING <= WILL_ALWAYS o WILL_NEVER <= WILL_FLOODING <= WILL_ALWAYS
o WILL_NEVER <= WILL_ROUTING <= WILL_ALWAYS o WILL_NEVER <= WILL_ROUTING <= WILL_ALWAYS
skipping to change at page 26, line 14 skipping to change at page 26, line 9
O_HOLD_TIME O_HOLD_TIME
* If O_HOLD_TIME changes, then the expiry time for all Originator * If O_HOLD_TIME changes, then the expiry time for all Originator
Tuples MAY be changed. Tuples MAY be changed.
TC_INTERVAL TC_INTERVAL
* If TC_INTERVAL increases, then the next TC message generated by * If TC_INTERVAL increases, then the next TC message generated by
this router MUST be generated according to the previous, this router MUST be generated according to the previous,
shorter, TC_INTERVAL. Additional subsequent TC messages MAY be shorter TC_INTERVAL. Additional subsequent TC messages MAY be
generated according to the previous, shorter, TC_INTERVAL. generated according to the previous, shorter, TC_INTERVAL.
* If TC_INTERVAL decreases, then the following TC messages from * If TC_INTERVAL decreases, then the following TC messages from
this router MUST be generated according to the current, this router MUST be generated according to the current,
shorter, TC_INTERVAL. shorter, TC_INTERVAL.
P_HOLD_TIME P_HOLD_TIME
* If P_HOLD_TIME changes, then the expiry time for all Processed * If P_HOLD_TIME changes, then the expiry time for all Processed
Tuples MAY be changed. Tuples MAY be changed.
skipping to change at page 27, line 10 skipping to change at page 27, line 9
* If TC_HOP_LIMIT changes, and the router uses multiple values * If TC_HOP_LIMIT changes, and the router 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.
LINK_METRIC_TYPE LINK_METRIC_TYPE
* If LINK_METRIC_TYPE changes, then all link metric information * If LINK_METRIC_TYPE changes, then all link metric information
recorded by the router is invalid. The router MUST take the recorded by the router is invalid. The router MUST take the
following actions, and all consequent actions described in following actions and all consequent actions described in
Section 17 and [RFC6130]. Section 17 and [RFC6130].
+ For each Link Tuple in any Link Set for an OLSRv2 interface, + For each Link Tuple in any Link Set for an OLSRv2 interface,
either update L_in_metric (the value MAXIMUM_METRIC MAY be either update L_in_metric (the value MAXIMUM_METRIC MAY be
used) or remove the Link Tuple from the Link Set. used) or remove the Link Tuple from the Link Set.
+ For each Link Tuple that is not removed, set: + For each Link Tuple that is not removed, set:
- L_out_metric := UNKNOWN_METRIC; - L_out_metric := UNKNOWN_METRIC;
- L_SYM_time := EXPIRED; - L_SYM_time := EXPIRED;
- L_MPR_selector := false. - L_MPR_selector := false.
+ Remove all Router Topology Tuples, Routable Address Topology + Remove all Router Topology Tuples, Routable Address Topology
Tuples, Attached Network Tuples and Routing Tuples from Tuples, Attached Network Tuples, and Routing Tuples from
their respective Protocol Sets in the Topology Information their respective Protocol Sets in the Topology Information
Base. Base.
5.6. Constants 5.6. Constants
The following constants are specified for routers. Unlike router The following constants are specified for routers. Unlike router
parameters, constants MUST NOT change, and MUST be the same on all parameters, constants MUST NOT change and MUST be the same on all
routers. routers.
5.6.1. Link Metric Constants 5.6.1. Link Metric Constants
The constant minimum and maximum link metric values are defined by: The constant minimum and maximum link metric values are defined by:
o MINIMUM_METRIC := 1 o MINIMUM_METRIC := 1
o MAXIMUM_METRIC := 16776960 o MAXIMUM_METRIC := 16776960
The symbolic value UNKNOWN_METRIC is defined in Section 6.1. The symbolic value UNKNOWN_METRIC is defined in Section 6.1.
5.6.2. Willingness Constants 5.6.2. Willingness Constants
The constant minimum, RECOMMENDED default, and maximum, willingness The constant minimum, RECOMMENDED default, and maximum willingness
values are defined by: values are defined by:
o WILL_NEVER := 0 o WILL_NEVER := 0
o WILL_DEFAULT := 7 o WILL_DEFAULT := 7
o WILL_ALWAYS := 15 o WILL_ALWAYS := 15
5.6.3. Time Constant 5.6.3. Time Constant
The constant C (time granularity) is used as specified in [RFC5497]. The constant C (time granularity) is used as specified in [RFC5497].
It MUST be the same as is used by [RFC6130], with RECOMMENDED value: It MUST be the same as is used by [RFC6130], with RECOMMENDED value:
o C := 1/1024 second o C := 1/1024 second
Note that this parameter is used in the representation of time Note that this constant is used in the representation of time
intervals. Time values (such as are stored in Protocol Tuples) are intervals. Time values (such as are stored in Protocol Tuples) are
not so represented. A resolution of C in such values is sufficient not so represented. A resolution of C in such values is sufficient
(but not necessary) for such values. (but not necessary) for such values.
6. Link Metric Values 6. Link Metric Values
A router records a link metric value for each direction of a link of A router records a link metric value for each direction of a link of
which it has knowledge. These link metric values are used to create which it has knowledge. These link metric values are used to create
metrics for routes by the addition of link metric values. metrics for routes by the addition of link metric values.
6.1. Link Metric Representation 6.1. Link Metric Representation
Link metrics are reported in messages using a compressed Link metrics are reported in messages using a compressed
representation that occupies 12 bits, consisting of a 4 bit field and representation that occupies 12 bits, consisting of a 4-bit field and
an 8 bit field. The compressed representation represents positive an 8-bit field. The compressed representation represents positive
integer values with a minimum value of 1 and a maximum value that is integer values with a minimum value of 1 and a maximum value that is
slightly smaller than the maximum 24 bit value. Only those values slightly smaller than the maximum 24-bit value. Only those values
that have exact representation in the compressed form are used. that have exact representation in the compressed form are used.
Route metrics are the summation of no more than 255 link metric Route metrics are the summation of no more than 256 link metric
values, and can therefore be represented using no more than 32 bits. values and can therefore be represented using no more than 32 bits.
Link and route metrics used in the Information Bases defined in this Link and route metrics used in the Information Bases defined in this
specification refer to the uncompressed values, and arithmetic specification refer to the uncompressed values, and arithmetic
involving them does likewise, and assumes full precision in the involving them does likewise and assumes full precision in the
result. (How an implementation records the values is not part of result. (How an implementation records the values is not part of
this specification, as long as it behaves as if recording this specification, as long as it behaves as if recording
uncompressed values. An implementation can, for example, use 32 bit uncompressed values. An implementation can, for example, use 32-bit
values for all link and route metrics.) values for all link and route metrics.)
In some cases, a link metric value may be unknown. This is indicated
In some cases a link metric value may be unknown. This is indicated
in this specification by the symbolic value UNKNOWN_METRIC. An in this specification by the symbolic value UNKNOWN_METRIC. An
implementation may use any representation of UNKNOWN_METRIC as it is implementation may use any representation of UNKNOWN_METRIC as it is
never included in messages, or used in any computation. (Possible never included in messages or used in any computation. (Possible
representations are zero, or any value greater than the maximum representations are zero or any value greater than the maximum
representable metric value.) representable metric value.)
6.2. Link Metric Compressed Form 6.2. Link Metric Compressed Form
The 12-bit compressed form of a link metric uses a modified form of a The 12-bit compressed form of a link metric uses a modified form of a
representation with an 8-bit mantissa (denoted a) and a 4-bit representation with an 8-bit mantissa (denoted a) and a 4-bit
exponent (denoted b). Note that if represented as the 12 bit value exponent (denoted b). Note that if represented as the 12-bit value
256b+a then the ordering of those 12 bit values is identical to the 256b+a, then the ordering of those 12-bit values is identical to the
ordering of the represented values. ordering of the represented values.
The value so represented is (257+a)2^b - 256, where ^ denotes The value so represented is (257+a)2^b - 256, where ^ denotes
exponentiation. This has a minimum value (when a = 0 and b = 0) of exponentiation. This has a minimum value (when a = 0 and b = 0) of
MINIMUM_METRIC = 1 and a maximum value (when a = 255 and b = 15) of MINIMUM_METRIC = 1 and a maximum value (when a = 255 and b = 15) of
MAXIMUM_METRIC = 2^24 - 256. MAXIMUM_METRIC = 2^24 - 256.
An algorithm for computing a and b for the smallest representable An algorithm for computing a and b for the smallest representable
value not less than a link metric value v such that MINIMUM_METRIC <= value not less than a link metric value v such that MINIMUM_METRIC <=
v <= MAXIMUM_METRIC is: v <= MAXIMUM_METRIC is:
skipping to change at page 29, line 36 skipping to change at page 29, line 41
nearest integer. nearest integer.
7. Local Information Base 7. Local Information Base
The Local Information Base, as defined for each router in [RFC6130], The Local Information Base, as defined for each router in [RFC6130],
is extended by this protocol by: is extended by this protocol by:
o Recording the router's originator address. The originator address o Recording the router's originator address. The originator address
MUST be unique to this router. It MUST NOT be used by any other MUST be unique to this router. It MUST NOT be used by any other
router as an originator address. It MAY be included in any router as an originator address. It MAY be included in any
network address in any I_local_iface_addr_list of this router, it network address in any I_local_iface_addr_list of this router; it
MUST NOT be included in any network address in any MUST NOT be included in any network address in any
I_local_iface_addr_list of any other router. It MAY be included I_local_iface_addr_list of any other router. It MAY be included
in, but MUST NOT be equal to, the AL_net_addr in any Local in, but MUST NOT be equal to, the AL_net_addr in any Local
Attached Network Tuple in this or any other router. Attached Network Tuple in this or any other router.
o The addition of an Originator Set, defined in Section 7.1, and a o The addition of an Originator Set, defined in Section 7.1, and a
Local Attached Network Set, defined in Section 7.2. Local Attached Network Set, defined in Section 7.2.
All routable addresses of the router for which it is to accept IP All routable addresses of the router for which it is to accept IP
packets as destination MUST be included in the Local Interface Set or packets as destination MUST be included in the Local Interface Set or
the Local Attached Network Set. the Local Attached Network Set.
7.1. Originator Set 7.1. Originator Set
A router's Originator Set records addresses that were recently used A router's Originator Set records addresses that were recently used
as originator addresses by this router. If a router's originator as originator addresses by this router. If a router's originator
address is immutable then the Originator Set is always empty and MAY address is immutable, then the Originator Set is always empty and MAY
be omitted. It consists of Originator Tuples: be omitted. It consists of Originator Tuples:
(O_orig_addr, O_time) (O_orig_addr, O_time)
where: where:
O_orig_addr is a recently used originator address; note that this O_orig_addr is a recently used originator address; note that this
does not include a prefix length. does not include a prefix length.
O_time specifies the time at which this Tuple expires and MUST be O_time specifies the time at which this Tuple expires and MUST be
removed. removed.
7.2. Local Attached Network Set 7.2. Local Attached Network Set
A router's Local Attached Network Set records its local non-OLSRv2 A router's Local Attached Network Set records its local non-OLSRv2
interfaces via which it can act as a gateway to other networks. The interfaces via which it can act as a gateway to other networks. The
Local Attached Network Set MUST be provided to this protocol and MUST Local Attached Network Set MUST be provided to this protocol and MUST
reflect any changes in the router's status. (In cases where the reflect any changes in the router's status. (In cases where the
router's configuration is static, the Local Attached Network Set will router's configuration is static, the Local Attached Network Set will
be constant; in cases where the router has no non-OLSRv2 interfaces, be constant; in cases where the router has no such non-OLSRv2
the Local Attached Network Set will be empty.) The Local Attached interfaces, the Local Attached Network Set will be empty.) The Local
Network Set is not modified by this protocol. This protocol will Attached Network Set is not modified by this protocol. This protocol
respond to (externally provided) changes to the Local Attached will respond to (externally provided) changes to the Local Attached
Network Set. It consists of Local Attached Network Tuples: Network Set. It consists of Local Attached Network Tuples:
(AL_net_addr, AL_dist, AL_metric) (AL_net_addr, AL_dist, AL_metric)
where: where:
AL_net_addr is the network address of an attached network which AL_net_addr is the network address of an attached network that can
can be reached via this router. This SHOULD be a routable be reached via this router. This SHOULD be a routable address.
address. It is constrained as described below. It is constrained as described below.
AL_dist is the number of hops to the network with network address AL_dist is the number of hops to the network with network address
AL_net_addr from this router. AL_net_addr from this router.
AL_metric is the metric of the link to the attached network with AL_metric is the metric of the link to the attached network with
address AL_net_addr from this router. address AL_net_addr from this router.
Attached networks local to this router only (i.e., not reachable Attached networks local to this router only (i.e., not reachable
except via this router) SHOULD be treated as local non-MANET except via this router) SHOULD be treated as local non-MANET
interfaces, and added to the Local Interface Set, as specified in interfaces and added to the Local Interface Set, as specified in
[RFC6130], rather than be added to the Local Attached Network Set. [RFC6130], rather than added to the Local Attached Network Set.
Because an attached network is not specific to the router, and may be Because an attached network is not specific to the router and may be
outside the MANET, an attached network MAY also be attached to other outside the MANET, an attached network MAY also be attached to other
routers. Routing to an AL_net_addr will use maximum prefix length routers. Routing to an AL_net_addr will use maximum prefix length
matching; consequently an AL_net_addr MAY include, but MUST NOT equal matching; consequently, an AL_net_addr MAY include, but MUST NOT
or be included in, any network address which is of any interface of equal or be included in, any network address that is of any interface
any router (i.e., is included in any I_local_iface_addr_list) or of any router (i.e., is included in any I_local_iface_addr_list) or
equal any router's originator address. equal any router's originator address.
It is not the responsibility of this protocol to maintain routes from It is not the responsibility of this protocol to maintain routes from
this router to networks recorded in the Local Attached Network Set. this router to networks recorded in the Local Attached Network Set.
Local Attached Neighbor Tuples are removed from the Local Attached Local Attached Network Tuples are removed from the Local Attached
Network Set only when the router's local attached network Network Set only when the router's local attached network
configuration changes, i.e., they are not subject to timer-based configuration changes, i.e., they are not subject to timer-based
expiration or changes due to received messages. expiration or changes due to received messages.
8. Interface Information Base 8. Interface Information Base
An Interface Information Base, as defined in [RFC6130], is maintained An Interface Information Base, as defined in [RFC6130], is maintained
for each MANET interface. The Link Set and 2-Hop Set in the for each MANET interface. The Link Set and 2-Hop Set in the
Interface Information Base for an OLSRv2 interface are modified by Interface Information Base for an OLSRv2 interface are modified by
this protocol. In some cases it may be convenient to consider these this protocol. In some cases, it may be convenient to consider these
Sets as also containing these additional elements for other MANET Sets as also containing these additional elements for other MANET
interfaces, taking the indicated values on creation, but never being interfaces, taking the indicated values on creation but never being
updated. updated.
8.1. Link Set 8.1. Link Set
The Link Set is modified by adding these additional elements to each The Link Set is modified by adding these additional elements to each
Link Tuple: Link Tuple:
L_in_metric is the metric of the link from the OLSRv2 interface L_in_metric is the metric of the link from the OLSRv2 interface
with addresses L_neighbor_iface_addr_list to this OLSRv2 with addresses L_neighbor_iface_addr_list to this OLSRv2
interface; interface;
skipping to change at page 32, line 36 skipping to change at page 32, line 41
A 2-Hop Tuple created (but not updated) by [RFC6130] MUST set: A 2-Hop Tuple created (but not updated) by [RFC6130] MUST set:
o N2_in_metric := UNKNOWN_METRIC; o N2_in_metric := UNKNOWN_METRIC;
o N2_out_metric := UNKNOWN_METRIC. o N2_out_metric := UNKNOWN_METRIC.
9. Neighbor Information Base 9. Neighbor Information Base
A Neighbor Information Base, as defined in [RFC6130], is maintained A Neighbor Information Base, as defined in [RFC6130], is maintained
for each router. It is modified by this protocol by adding these for each router. It is modified by this protocol by adding these
additional elements to each Neighbor Tuple in the Neighbor Set. In additional elements to each Neighbor Tuple in the Neighbor Set. In
some cases it may be convenient to consider these Sets as also some cases, it may be convenient to consider these Sets as also
containing these additional elements for other MANET interfaces, containing these additional elements for other MANET interfaces,
taking the indicated values on creation, but never being updated. taking the indicated values on creation but never being updated.
N_orig_addr is the neighbor's originator address, which may be N_orig_addr is the neighbor's originator address, which may be
unknown. Note that this originator address does not include a unknown. Note that this originator address does not include a
prefix length; prefix length;
N_in_metric is the neighbor metric of any link from this neighbor N_in_metric is the neighbor metric of any link from this neighbor
to an OLSRv2 interface of this router, i.e., the minimum of all to an OLSRv2 interface of this router, i.e., the minimum of all
corresponding L_in_metric with L_status = SYMMETRIC and corresponding L_in_metric with L_status = SYMMETRIC and
L_in_metric != UNKNOWN_METRIC, UNKNOWN_METRIC if there are no such L_in_metric != UNKNOWN_METRIC, UNKNOWN_METRIC if there are no such
Link Tuples; Link Tuples;
N_out_metric is the neighbor metric of any link from an OLSRv2 N_out_metric is the neighbor metric of any link from an OLSRv2
interface of this router to this neighbor, i.e., the minimum of interface of this router to this neighbor, i.e., the minimum of
all corresponding L_out_metric with L_status = SYMMETRIC and all corresponding L_out_metric with L_status = SYMMETRIC and
L_out_metric != UNKNOWN_METRIC, UNKNOWN_METRIC if there are no L_out_metric != UNKNOWN_METRIC, UNKNOWN_METRIC if there are no
skipping to change at page 33, line 10 skipping to change at page 33, line 18
Link Tuples; Link Tuples;
N_out_metric is the neighbor metric of any link from an OLSRv2 N_out_metric is the neighbor metric of any link from an OLSRv2
interface of this router to this neighbor, i.e., the minimum of interface of this router to this neighbor, i.e., the minimum of
all corresponding L_out_metric with L_status = SYMMETRIC and all corresponding L_out_metric with L_status = SYMMETRIC and
L_out_metric != UNKNOWN_METRIC, UNKNOWN_METRIC if there are no L_out_metric != UNKNOWN_METRIC, UNKNOWN_METRIC if there are no
such Link Tuples; such Link Tuples;
N_will_flooding is the neighbor's willingness to be selected as a N_will_flooding is the neighbor's willingness to be selected as a
flooding MPR, in the range from WILL_NEVER to WILL_ALWAYS, both flooding MPR, in the range from WILL_NEVER to WILL_ALWAYS, both
inclusive, taking the value WILL_NEVER if no OLSRv2 specific inclusive, taking the value WILL_NEVER if no OLSRv2-specific
information is received from this neighbor; information is received from this neighbor;
N_will_routing is the neighbor's willingness to be selected as a N_will_routing is the neighbor's willingness to be selected as a
routing MPR, in the range from WILL_NEVER to WILL_ALWAYS, both routing MPR, in the range from WILL_NEVER to WILL_ALWAYS, both
inclusive, taking the value WILL_NEVER if no OLSRv2 specific inclusive, taking the value WILL_NEVER if no OLSRv2-specific
information is received from this neighbor; information is received from this neighbor;
N_flooding_mpr is a boolean flag, describing if this neighbor is N_flooding_mpr is a boolean flag, describing if this neighbor is
selected as a flooding MPR by this router; selected as a flooding MPR by this router;
N_routing_mpr is a boolean flag, describing if this neighbor is N_routing_mpr is a boolean flag, describing if this neighbor is
selected as a routing MPR by this router; selected as a routing MPR by this router;
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 router as a routing MPR, i.e., is a routing MPR selected this router as a routing MPR, i.e., is a routing MPR
skipping to change at page 34, line 8 skipping to change at page 34, line 15
o N_mpr_selector := false; o N_mpr_selector := false;
o N_advertised := false. o N_advertised := false.
The Neighbor Information Base also includes a variable, the The Neighbor Information Base also includes a variable, the
Advertised Neighbor Sequence Number (ANSN), whose value is included Advertised Neighbor Sequence Number (ANSN), whose value is included
in TC messages to indicate the freshness of the information in TC messages to indicate the freshness of the information
transmitted. The ANSN is incremented whenever advertised information transmitted. The ANSN is incremented whenever advertised information
(the originator and routable addresses included in Neighbor Tuples (the originator and routable addresses included in Neighbor Tuples
with N_advertised = true, and local attached networks recorded in the with N_advertised = true and local attached networks recorded in the
Local Attached Network Set in the Local Information Base) changes, Local Attached Network Set in the Local Information Base) changes,
including addition or removal of such information. including addition or removal of such information.
10. Topology Information Base 10. Topology Information Base
The Topology Information Base, defined for each router by this The Topology Information Base, defined for each router by this
specification, stores information received in TC messages, in the specification, stores information received in TC messages in the
Advertising Remote Router Set, the Router Topology Set, the Routable Advertising Remote Router Set, the Router Topology Set, the Routable
Address Topology Set and the Attached Network Set. Address Topology Set, and the Attached Network Set.
Additionally, a Routing Set is maintained, derived from the Additionally, a Routing Set is maintained, derived from the
information recorded in the Local Information Base, the Interface information recorded in the Local Information Base, the Interface
Information Bases, the Neighbor Information Base and the rest of the Information Bases, the Neighbor Information Base, and the rest of the
Topology Information Base. Topology Information Base.
10.1. Advertising Remote Router Set 10.1. Advertising Remote Router Set
A router's Advertising Remote Router Set records information A router's Advertising Remote Router Set records information
describing each remote router in the network that transmits TC describing each remote router in the network that transmits TC
messages, allowing outdated TC messages to be recognized and messages, allowing outdated TC messages to be recognized and
discarded. It consists of Advertising Remote Router Tuples: discarded. It consists of Advertising Remote Router Tuples:
(AR_orig_addr, AR_seq_number, AR_time) (AR_orig_addr, AR_seq_number, AR_time)
where: where:
AR_orig_addr is the originator address of a received TC message, AR_orig_addr is the originator address of a received TC message,
note that this does not include a prefix length; note that this does not include a prefix length;
AR_seq_number is the greatest ANSN in any TC message received AR_seq_number is the greatest ANSN in any TC message received that
which originated from the router with originator address originated from the router with originator address AR_orig_addr
AR_orig_addr (i.e., which contributed to the information contained (i.e., that contributed to the information contained in this
in this Tuple); Tuple);
AR_time is the time at which this Tuple expires and MUST be AR_time is the time at which this Tuple expires and MUST be
removed. removed.
10.2. Router Topology Set 10.2. Router Topology Set
A router's Topology Set records topology information about the links A router's Topology Set records topology information about the links
between routers in the MANET. It consists of Router Topology Tuples: between routers in the MANET. It consists of Router Topology Tuples:
(TR_from_orig_addr, TR_to_orig_addr, TR_seq_number, TR_metric, (TR_from_orig_addr, TR_to_orig_addr, TR_seq_number, TR_metric,
TR_time) TR_time)
where: where:
TR_from_orig_addr is the originator address of a router which can TR_from_orig_addr is the originator address of a router that can
reach the router with originator address TR_to_orig_addr in one reach the router with originator address TR_to_orig_addr in one
hop, note that this does not include a prefix length; hop (note that this does not include a prefix length);
TR_to_orig_addr is the originator address of a router which can be TR_to_orig_addr is the originator address of a router that can be
reached by the router with originator address TR_to_orig_addr in reached by the router with originator address TR_from_orig_addr in
one hop, note that this does not include a prefix length; one hop (note that this does not include a prefix length);
TR_seq_number is the greatest ANSN in any TC message received TR_seq_number is the greatest ANSN in any TC message received that
which originated from the router with originator address originated from the router with originator address
TR_from_orig_addr (i.e., which contributed to the information TR_from_orig_addr (i.e., that contributed to the information
contained in this Tuple); contained in this Tuple);
TR_metric is the neighbor metric from the router with originator TR_metric is the neighbor metric from the router with originator
address TR_from_orig_addr to the router with originator address address TR_from_orig_addr to the router with originator address
TR_to_orig_addr; TR_to_orig_addr;
TR_time specifies the time at which this Tuple expires and MUST be TR_time specifies the time at which this Tuple expires and MUST be
removed. removed.
10.3. Routable Address Topology Set 10.3. Routable Address Topology Set
A router's Routable Address Topology Set records topology information A router's Routable Address Topology Set records topology information
about the routable addresses within the MANET, and via which routers about the routable addresses within the MANET, including via which
they may be reached. It consists of Routable Address Topology routers they may be reached. It consists of Routable Address
Tuples: Topology Tuples:
(TA_from_orig_addr, TA_dest_addr, TA_seq_number, TA_metric, (TA_from_orig_addr, TA_dest_addr, TA_seq_number, TA_metric,
TA_time) TA_time)
where: where:
TA_from_orig_addr is the originator address of a router which can TA_from_orig_addr is the originator address of a router that can
reach the router with routable address TA_dest_addr in one hop, reach the router with routable address TA_dest_addr in one hop
note that this does not include a prefix length; (note that this does not include a prefix length);
TA_dest_addr is a routable address of a router that can be reached
TA_dest_addr is a routable address of a router which can be by the router with originator address TA_from_orig_addr in one
reached by the router with originator address TA_from_orig_addr in hop;
one hop;
TA_seq_number is the greatest ANSN in any TC message received TA_seq_number is the greatest ANSN in any TC message received that
which originated from the router with originator address originated from the router with originator address
TA_from_orig_addr (i.e., which contributed to the information TA_from_orig_addr (i.e., that contributed to the information
contained in this Tuple); contained in this Tuple);
TA_metric is the neighbor metric from the router with originator TA_metric is the neighbor metric from the router with originator
address TA_from_orig_addr to the router with OLSRv2 interface address TA_from_orig_addr to the router with OLSRv2 interface
address TA_dest_addr; address TA_dest_addr;
TA_time specifies the time at which this Tuple expires and MUST be TA_time specifies the time at which this Tuple expires and MUST be
removed. removed.
10.4. Attached Network Set 10.4. Attached Network Set
A router's Attached Network Set records information about networks A router's Attached Network Set records information about networks
skipping to change at page 36, line 22 skipping to change at page 36, line 31
A router's Attached Network Set records information about networks A router's Attached Network Set records information about networks
(which may be outside the MANET) attached to other routers and their (which may be outside the MANET) attached to other routers and their
routable addresses. It consists of Attached Network Tuples: routable addresses. It consists of Attached Network Tuples:
(AN_orig_addr, AN_net_addr, AN_seq_number, AN_dist, AN_metric, (AN_orig_addr, AN_net_addr, AN_seq_number, AN_dist, AN_metric,
AN_time) AN_time)
where: where:
AN_orig_addr is the originator address of a router which can act AN_orig_addr is the originator address of a router that can act as
as gateway to the network with network address AN_net_addr, note gateway to the network with network address AN_net_addr (note that
that this does not include a prefix length; this does not include a prefix length);
AN_net_addr is the network address of an attached network, which AN_net_addr is the network address of an attached network that may
may be reached via the router with originator address be reached via the router with originator address AN_orig_addr;
AN_orig_addr;
AN_seq_number is the greatest ANSN in any TC message received AN_seq_number is the greatest ANSN in any TC message received that
which originated from the router with originator address originated from the router with originator address AN_orig_addr
AN_orig_addr (i.e., which contributed to the information contained (i.e., that contributed to the information contained in this
in this Tuple); Tuple);
AN_dist is the number of hops to the network with network address AN_dist is the number of hops to the network with network address
AN_net_addr from the router with originator address AN_orig_addr; AN_net_addr from the router with originator address AN_orig_addr;
AN_metric is the metric of the link from the router with AN_metric is the metric of the link from the router with
originator address AN_orig_addr to the attached network with originator address AN_orig_addr to the attached network with
address AN_net_addr; address AN_net_addr;
AN_time specifies the time at which this Tuple expires and MUST be AN_time specifies the time at which this Tuple expires and MUST be
removed. removed.
skipping to change at page 37, line 9 skipping to change at page 37, line 17
A router's Routing Set records the first hop along a selected path to A router's Routing Set records the first hop along a selected path to
each destination for which any such path is known. It consists of each destination for which any such path is known. It consists of
Routing Tuples: Routing Tuples:
(R_dest_addr, R_next_iface_addr, R_local_iface_addr, R_dist, (R_dest_addr, R_next_iface_addr, R_local_iface_addr, R_dist,
R_metric) R_metric)
where: where:
R_dest_addr is the network address of the destination, either the R_dest_addr is the network address of the destination, either the
network address of an interface of a destination router, or the network address of an interface of a destination router or the
network address of an attached network; network address of an attached network;
R_next_iface_addr is the network address of the "next hop" on the R_next_iface_addr is the network address of the "next hop" on the
selected path to the destination; selected path to the destination;
R_local_iface_addr is an address of the local interface over which R_local_iface_addr is an address of the local interface over which
an IP packet MUST be sent to reach the destination by the selected an IP packet MUST be sent to reach the destination by the selected
path. path.
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
skipping to change at page 37, line 46 skipping to change at page 38, line 8
The Received Message Information Base, defined by this specification, The Received Message Information Base, defined by this specification,
records information required to ensure that a message is processed at records information required to ensure that a message is processed at
most once and is forwarded at most once per OLSRv2 interface of a most once and is forwarded at most once per OLSRv2 interface of a
router, using MPR flooding. Messages are recorded using their router, using MPR flooding. Messages are recorded using their
"signature", consisting of their type, originator address, and "signature", consisting of their type, originator address, and
message sequence number. message sequence number.
11.1. Received Set 11.1. Received Set
A router has a Received Set per OLSRv2 interface. Each Received Set A router has a Received Set per OLSRv2 interface. Each Received Set
records the signatures of messages which have been received over that records the signatures of messages that have been received over that
OLSRv2 interface. Each consists of Received Tuples: 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; RX_type is the received Message Type;
RX_orig_addr is the originator address of the received message, RX_orig_addr is the originator address of the received message
note that this does not include a prefix length; (note that this does not include a prefix length);
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.
11.2. Processed Set 11.2. Processed Set
A router has a single Processed Set which records signatures of A router has a single Processed Set that records signatures of
messages which have been processed by the router. It consists of messages that have been processed by the router. It consists of
Processed Tuples: Processed Tuples:
(P_type, P_orig_addr, P_seq_number, P_time) (P_type, P_orig_addr, P_seq_number, P_time)
where: where:
P_type is the processed Message Type; P_type is the processed Message Type;
P_orig_addr is the originator address of the processed message, P_orig_addr is the originator address of the processed message
note that this does not include a prefix length; (note that this does not include a prefix length);
P_seq_number is the message sequence number of the processed P_seq_number is the message sequence number of the processed
message; message;
P_time specifies the time at which this Tuple expires and MUST be P_time specifies the time at which this Tuple expires and MUST be
removed. removed.
11.3. Forwarded Set 11.3. Forwarded Set
A router has a single Forwarded Set which records signatures of A router has a single Forwarded Set that records signatures of
messages which have been forwarded by the router. It consists of messages that have been forwarded by the router. It consists of
Forwarded Tuples: 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; F_type is the forwarded Message Type;
F_orig_addr is the originator address of the forwarded message, F_orig_addr is the originator address of the forwarded message
note that this does not include a prefix length; (note that this does not include a prefix length);
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.
12. Information Base Properties 12. Information Base Properties
This section describes some additional properties of Information This section describes some additional properties of Information
Bases and their contents. Bases and their contents.
12.1. Corresponding Protocol Tuples 12.1. Corresponding Protocol Tuples
As part of this specification, in a number of cases there is a As part of this specification, in a number of cases, there is a
natural correspondence from a Protocol Tuple in one Protocol Set to a natural correspondence from a Protocol Tuple in one Protocol Set to a
single Protocol Tuple in another Protocol Set, in the same or another single Protocol Tuple in another Protocol Set, in the same or another
Information Base. The latter Protocol Tuple is referred to as Information Base. The latter Protocol Tuple is referred to as
"corresponding" to the former Protocol Tuple. "corresponding" to the former Protocol Tuple.
Specific examples of corresponding Protocol Tuples include: Specific examples of corresponding Protocol Tuples include:
o There is a Local Interface Tuple corresponding to each Link Tuple, o There is a Local Interface Tuple corresponding to each Link Tuple,
where the Link Tuple is in the Link Set for a MANET interface, and where the Link Tuple is in the Link Set for a MANET interface and
the Local Interface Tuple represents that MANET interface. the Local Interface Tuple represents that MANET interface.
o There is a Neighbor Tuple corresponding to each Link Tuple which o There is a Neighbor Tuple corresponding to each Link Tuple that
has L_HEARD_time not EXPIRED, such that N_neighbor_addr_list has L_HEARD_time not EXPIRED, such that N_neighbor_addr_list
contains L_neighbor_iface_addr_list. contains L_neighbor_iface_addr_list.
o There is a Link Tuple (in the Link Set in the same Interface o There is a Link Tuple (in the Link Set in the same Interface
Information Base) corresponding to each 2-Hop Tuple such that Information Base) corresponding to each 2-Hop Tuple such that
L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list. L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list.
o There is a Neighbor Tuple corresponding to each 2-Hop Tuple, such o There is a Neighbor Tuple corresponding to each 2-Hop Tuple, such
that N_neighbor_addr_list contains N2_neighbor_iface_addr_list. that N_neighbor_addr_list contains N2_neighbor_iface_addr_list.
(This is the Neighbor Tuple corresponding to the Link Tuple (This is the Neighbor Tuple corresponding to the Link Tuple
skipping to change at page 40, line 14 skipping to change at page 40, line 29
o There is a Neighbor Tuple corresponding to each Routing Tuple such o There is a Neighbor Tuple corresponding to each Routing Tuple such
that N_neighbor_addr_list contains R_next_iface_addr. that N_neighbor_addr_list contains R_next_iface_addr.
12.2. Address Ownership 12.2. Address Ownership
Addresses or network addresses with the following properties are Addresses or network addresses with the following properties are
considered as "fully owned" by a router when processing a received considered as "fully owned" by a router when processing a received
message: message:
o Equaling its originator address, OR; o Equaling its originator address; OR
o Equaling the O_orig_addr in an Originator Tuple, OR; o Equaling the O_orig_addr in an Originator Tuple; OR
o Equaling or being a sub-range of the I_local_iface_addr_list in a o Equaling or being a sub-range of the I_local_iface_addr_list in a
Local Interface Tuple, OR; Local Interface Tuple; OR
o Equaling or being a sub-range of the IR_local_iface_addr in a o Equaling or being a sub-range of the IR_local_iface_addr in a
Removed Interface Address Tuple, OR; Removed Interface Address Tuple; OR
o Equaling an AL_net_addr in a Local Attached Network Tuple. o Equaling an AL_net_addr in a Local Attached Network Tuple.
Addresses or network addresses with the following properties are Addresses or network addresses with the following properties are
considered as "partially owned" (which may include being fully owned) considered as "partially owned" (which may include being fully owned)
by a router when processing a received message: by a router when processing a received message:
o Overlapping (equaling or containing) its originator address, OR; o Overlapping (equaling or containing) its originator address; OR
o Overlapping (equaling or containing) the O_orig_addr in an o Overlapping (equaling or containing) the O_orig_addr in an
Originator Tuple, OR; Originator Tuple; OR
o Overlapping the I_local_iface_addr_list in a Local Interface o Overlapping the I_local_iface_addr_list in a Local Interface
Tuple, OR; Tuple; OR
o Overlapping the IR_local_iface_addr in a Removed Interface Address o Overlapping the IR_local_iface_addr in a Removed Interface Address
Tuple, OR; Tuple; OR
o Equaling or having as a sub-range an AL_net_addr in a Local o Equaling or having as a sub-range an AL_net_addr in a Local
Attached Network Tuple. Attached Network Tuple.
13. Packets and Messages 13. Packets and Messages
The packet and message format used by this protocol is defined in The packet and message format used by this protocol is defined in
[RFC5444]. Except as otherwise noted, options defined in [RFC5444] [RFC5444]. Except as otherwise noted, options defined in [RFC5444]
may be freely used, in particular alternative formats defined by may be freely used, in particular alternative formats defined by
packet, message, Address Block and TLV flags. packet, message, Address Block, and TLV flags.
This section describes the usage of the packets and messages defined This section describes the usage of the packets and messages defined
in [RFC5444] by this specification, and the TLVs defined by, and used in [RFC5444] by this specification and the TLVs defined by, and used
in, this specification. in, this specification.
13.1. Messages 13.1. Messages
Routers using this protocol exchange information through messages. Routers using this protocol exchange information through messages.
The message types used by this protocol are the HELLO message and the The Message Types used by this protocol are the HELLO message and the
TC message. The HELLO message is defined by [RFC6130] and extended TC message. The HELLO message is defined by [RFC6130] and extended
by this specification, see Section 15. The TC message is defined by by this specification (see Section 15). The TC message is defined by
this specification, see Section 16. this specification (see Section 16).
13.2. Packets 13.2. Packets
One or more messages sent by a router at the same time SHOULD be One or more messages sent by a router at the same time SHOULD be
combined into a single packet, subject to any constraints on maximum combined into a single packet, subject to any constraints on maximum
packet size (such as derived from the MTU over a local single hop) packet size (such as derived from the MTU over a local single hop)
that MAY be imposed. These messages may have originated at the that MAY be imposed. These messages may have originated at the
sending router, or have originated at another router and are being sending router or at another router and are being forwarded by the
forwarded by the sending router. Messages with different originating sending router. Messages with different originating routers MAY be
routers MAY be combined for transmission within the same packet. combined for transmission within the same packet. Messages from
Messages from other protocols defined using [RFC5444], including but other protocols defined using [RFC5444], including but not limited to
not limited to [RFC6130], MAY be combined for transmission within the NHDP [RFC6130], MAY be combined for transmission within the same
same packet. This specification does not define or use any contents packet. This specification does not define or use any contents of
of the Packet Header. the Packet Header.
Forwarded messages MAY be jittered as described in [RFC5148], Forwarded messages MAY be jittered as described in [RFC5148],
including the observation that the forwarding jitter of all messages including the observation that the forwarding jitter of all messages
received in a single packet SHOULD be the same. The value of received in a single packet SHOULD be the same. The value of
MAXJITTER used in jittering a forwarded message MAY be based on MAXJITTER used in jittering a forwarded message MAY be based on
information in that message (in particular any Message TLVs with Type information in that message (in particular any Message TLVs with Type
= INTERVAL_TIME or Type = VALIDITY_TIME) or otherwise SHOULD be with = INTERVAL_TIME or Type = VALIDITY_TIME) or otherwise SHOULD be with
a maximum delay of F_MAXJITTER. A router MAY modify the jitter a maximum delay of F_MAXJITTER. A router MAY modify the jitter
applied to a message in order to more efficiently combine messages in applied to a message in order to more efficiently combine messages in
packets, as long as the maximum jitter is not exceeded. packets, as long as the maximum jitter is not exceeded.
13.3. TLVs 13.3. TLVs
This specification defines two Message TLVs and four Address Block This specification defines two Message TLVs and four Address Block
TLVs. TLVs.
All references in this specification to TLVs that do not indicate a All references in this specification to TLVs that do not indicate a
type extension, assume Type Extension = 0. TLVs in processed type extension assume Type Extension = 0. TLVs in processed messages
messages with a type extension which is neither zero as so assumed, with a type extension that is neither zero as so assumed, nor a
nor a specifically indicated non-zero type extension, are ignored. specifically indicated non-zero type extension, are ignored.
Note that, following [RFC5444] and network byte order, bits in an
octet are numbered from 0 (most significant) to 7 (least
significant).
13.3.1. Message TLVs 13.3.1. Message TLVs
The MPR_WILLING TLV is used in HELLO messages. A message MUST NOT The MPR_WILLING TLV is used in HELLO messages. A message MUST NOT
contain more than one MPR_WILLING TLV. contain more than one MPR_WILLING TLV.
+-------------+--------------+--------------------------------------+ +-------------+--------------+--------------------------------------+
| Type | Value Length | Value | | Type | Value Length | Value |
+-------------+--------------+--------------------------------------+ +-------------+--------------+--------------------------------------+
| MPR_WILLING | 1 octet | Bits 0-3 encode the parameter | | MPR_WILLING | 1 octet | Bits 0-3 encode the parameter |
| | | WILL_FLOODING; bits 4-7 encode the | | | | WILL_FLOODING; bits 4-7 encode the |
| | | parameter WILL_ROUTING. | | | | parameter WILL_ROUTING. |
+-------------+--------------+--------------------------------------+ +-------------+--------------+--------------------------------------+
Table 1: MPR_WILLING TLV definition Table 1: MPR_WILLING TLV Definition
The CONT_SEQ_NUM TLV is used in TC messages. A message MUST NOT The CONT_SEQ_NUM TLV is used in TC messages. A message MUST NOT
contain more than one CONT_SEQ_NUM TLV. contain more than one CONT_SEQ_NUM TLV.
+--------------+--------------+-------------------------------------+ +--------------+--------------+-------------------------------------+
| Type | Value Length | Value | | Type | Value Length | Value |
+--------------+--------------+-------------------------------------+ +--------------+--------------+-------------------------------------+
| CONT_SEQ_NUM | 2 octets | The ANSN contained in the Neighbor | | CONT_SEQ_NUM | 2 octets | The ANSN contained in the Neighbor |
| | | Information Base. | | | | Information Base. |
+--------------+--------------+-------------------------------------+ +--------------+--------------+-------------------------------------+
Table 2: CONT_SEQ_NUM TLV definition Table 2: CONT_SEQ_NUM TLV Definition
13.3.2. Address Block TLVs 13.3.2. Address Block TLVs
The LINK_METRIC TLV is used in HELLO messages and TC messages. It The LINK_METRIC TLV is used in HELLO messages and TC messages. It
MAY use any type extension; only LINK_METRIC TLVs with type extension MAY use any type extension; only LINK_METRIC TLVs with type extension
equal to LINK_METRIC_TYPE will be used by this specification. An equal to LINK_METRIC_TYPE will be used by this specification. An
address MUST NOT be associated with more than one link metric value address MUST NOT be associated with more than one link metric value
for any given type extension, kind (link or neighbor) and direction for any given type extension, kind (link or neighbor), and direction
using this TLV. using this TLV.
+-------------+--------------+--------------------------------------+ +-------------+--------------+--------------------------------------+
| Type | Value Length | Value | | Type | Value Length | Value |
+-------------+--------------+--------------------------------------+ +-------------+--------------+--------------------------------------+
| LINK_METRIC | 2 octets | Bits 0-3 indicates kind(s) and | | LINK_METRIC | 2 octets | Bits 0-3 indicate kind(s) and |
| | | direction(s), bits 4-7 indicate | | | | direction(s); bits 4-7 indicate |
| | | exponent (a), bits 8-15 indicate | | | | exponent (b); and bits 8-15 indicate |
| | | mantissa (b) | | | | mantissa (a). |
+-------------+--------------+--------------------------------------+ +-------------+--------------+--------------------------------------+
Table 3: LINK_METRIC TLV definition Table 3: LINK_METRIC TLV Definition
The exponent and mantissa use the representation defined in The exponent and mantissa use the representation defined in
Section 6. Each bit of the types and directions sub-field, if set Section 6. Each bit of the types and directions sub-field, if set
('1') indicates that the link metric is of the indicated kind and ('1'), indicates that the link metric is of the indicated kind and
direction. Any combination of these bits MAY be used. direction. Any combination of these bits MAY be used.
+-----+-----------------+-----------+ +-----+-----------------+-----------+
| Bit | Kind | Direction | | Bit | Kind | Direction |
+-----+-----------------+-----------+ +-----+-----------------+-----------+
| 0 | Link metric | Incoming | | 0 | Link metric | Incoming |
| 1 | Link metric | Outgoing | | 1 | Link metric | Outgoing |
| 2 | Neighbor metric | Incoming | | 2 | Neighbor metric | Incoming |
| 3 | Neighbor metric | Outgoing | | 3 | Neighbor metric | Outgoing |
+-----+-----------------+-----------+ +-----+-----------------+-----------+
Table 4: LINK_METRIC TLV types and directions Table 4: LINK_METRIC TLV Types and Directions
The MPR TLV is used in HELLO messages, and indicates that an address The MPR TLV is used in HELLO messages and indicates that an address
with which it is associated is of a symmetric 1-hop neighbor that has with which it is associated is of a symmetric 1-hop neighbor that has
been selected as an MPR. been selected as an MPR.
+------+--------------+---------------------------------------------+ +------+--------------+---------------------------------------------+
| Type | Value Length | Value | | Type | Value Length | Value |
+------+--------------+---------------------------------------------+ +------+--------------+---------------------------------------------+
| MPR | 1 octet | FLOODING indicates that the corresponding | | MPR | 1 octet | FLOODING indicates that the corresponding |
| | | address is of a neighbor selected as a | | | | address is of a neighbor selected as a |
| | | flooding MPR, ROUTING indicates that the | | | | flooding MPR; ROUTING indicates that the |
| | | corresponding address is of a neighbor | | | | corresponding address is of a neighbor |
| | | selected as a routing MPR, FLOOD_ROUTE | | | | selected as a routing MPR; and FLOOD_ROUTE |
| | | indicates both (see Section 24.6). | | | | indicates both (see Section 24.6). |
+------+--------------+---------------------------------------------+ +------+--------------+---------------------------------------------+
Table 5: MPR TLV definition Table 5: MPR TLV Definition
The NBR_ADDR_TYPE TLV is used in TC messages. The NBR_ADDR_TYPE TLV is used in TC messages.
+---------------+--------------+------------------------------------+ +---------------+--------------+------------------------------------+
| Type | Value Length | Value | | Type | Value Length | Value |
+---------------+--------------+------------------------------------+ +---------------+--------------+------------------------------------+
| NBR_ADDR_TYPE | 1 octet | ORIGINATOR indicates that the | | NBR_ADDR_TYPE | 1 octet | ORIGINATOR indicates that the |
| | | corresponding address (which MUST | | | | corresponding address (which MUST |
| | | have maximum prefix length) is an | | | | have maximum prefix length) is an |
| | | originator address, ROUTABLE | | | | originator address; ROUTABLE |
| | | indicates that the corresponding | | | | indicates that the corresponding |
| | | network address is a routable | | | | network address is a routable |
| | | address of an interface, | | | | address of an interface; and |
| | | ROUTABLE_ORIG indicates that the | | | | ROUTABLE_ORIG indicates that the |
| | | corresponding address is both (see | | | | corresponding address is both (see |
| | | Section 24.6). | | | | Section 24.6). |
+---------------+--------------+------------------------------------+ +---------------+--------------+------------------------------------+
Table 6: NBR_ADDR_TYPE TLV definition Table 6: NBR_ADDR_TYPE TLV Definition
If an address is both an originator address and a routable address, If an address is both an originator address and a routable address,
then it may be associated with either one Address Block TLV with Type then it may be associated with either one Address Block TLV with Type
:= NBR_ADDR_TYPE and Value := ROUTABLE_ORIG, or with two Address := NBR_ADDR_TYPE and Value := ROUTABLE_ORIG, or with two Address
Block TLVs with Type:= NBR_ADDR_TYPE, one with Value := ORIGINATOR Block TLVs with Type:= NBR_ADDR_TYPE, one with Value := ORIGINATOR
and one with Value := ROUTABLE. and one with Value := ROUTABLE.
The GATEWAY TLV is used in TC messages. An address MUST NOT be The GATEWAY TLV is used in TC messages. An address MUST NOT be
associated with more than one hop count value using this TLV. associated with more than one hop count value using this TLV.
+---------+--------------+-------------------------------------+ +---------+--------------+-------------------------------------+
| Type | Value Length | Value | | Type | Value Length | Value |
+---------+--------------+-------------------------------------+ +---------+--------------+-------------------------------------+
| GATEWAY | 1 octet | Number of hops to attached network. | | GATEWAY | 1 octet | Number of hops to attached network. |
+---------+--------------+-------------------------------------+ +---------+--------------+-------------------------------------+
Table 7: GATEWAY TLV definition Table 7: GATEWAY TLV Definition
All address objects included in a TC message according to this All address objects included in a TC message according to this
specification MUST be associated either with at least one TLV with specification MUST be associated either with at least one TLV with
Type := NBR_ADDR_TYPE or with a TLV with Type := GATEWAY, but not Type := NBR_ADDR_TYPE or with a TLV with Type := GATEWAY, but not
both. Any other address objects MAY be included in Address Blocks in both. Any other address objects MAY be included in Address Blocks in
a TC message, but are ignored by this specification. a TC message but are ignored by this specification.
14. Message Processing and Forwarding 14. Message Processing and Forwarding
This section describes the optimized flooding operation (MPR This section describes the optimized flooding operation (MPR
flooding) used when control messages, as instances of [RFC5444], are flooding) used when control messages, as instances of [RFC5444], are
intended for MANET wide distribution. This flooding mechanism intended for MANET-wide distribution. This flooding mechanism
defines when a received message is, or is not, processed and/or defines when a received message is, or is not, processed and/or
forwarded. forwarded.
This flooding mechanism is used by this protocol and MAY be used by This flooding mechanism is used by this protocol and MAY be used by
extensions to this protocol which define, and hence own, other extensions to this protocol that define, and hence own, other Message
Message Types, to manage processing and/or forwarding of these Types, to manage processing and/or forwarding of these messages.
messages. This specification contains elements (P_type, RX_type, This specification contains elements (P_type, RX_type, F_type)
F_type) required only for such usage. required only for such usage.
This flooding mechanism is always used for TC messages (see This flooding mechanism is always used for TC messages (see
Section 16). Received HELLO messages (see Section 15) are, unless Section 16). Received HELLO messages (see Section 15) are, unless
invalid, always processed, and never forwarded by this flooding invalid, always processed and never forwarded by this flooding
mechanism. They thus do not need to be recorded in the Received mechanism. They thus do not need to be recorded in the Received
Message Information Base. Message Information Base.
The processing selection and forwarding mechanisms are designed to The processing selection and forwarding mechanisms are designed to
only need to parse the Message Header in order to determine whether a only need to parse the Message Header in order to determine whether a
message is to be processed and/or forwarded, and not to have to parse message is to be processed and/or forwarded and not to have to parse
the Message Body even if the message is forwarded (but not the Message Body even if the message is forwarded (but not
processed). An implementation MAY only parse the Message Body if processed). An implementation MAY only parse the Message Body if
necessary, or MAY always parse the Message Body and reject the necessary or MAY always parse the Message Body and reject the message
message if it cannot be so parsed, or any other error is identified. if it cannot be so parsed or any other error is identified.
An implementation MUST discard the message silently if it is unable An implementation MUST discard the message silently if it is unable
to parse the Message Header or (if attempted) the Message Body, or if to parse the Message Header or (if attempted) the Message Body, or if
a message (other than a HELLO message) does not include a message a message (other than a HELLO message) does not include a message
sequence number. sequence number.
14.1. Actions when Receiving a Message 14.1. Actions When Receiving a Message
On receiving, on an OLSRv2 interface, a message of a type specified On receiving, on an OLSRv2 interface, a message of a type specified
to be using this mechanism, which includes the TC messages defined in to be using this mechanism, which includes the TC messages defined in
this specification, a router MUST perform the following: this specification, a router MUST perform the following:
1. If the router recognizes from the originator address of the 1. If the router recognizes from the originator address of the
message that the message is one which the receiving router itself message that the message is one that the receiving router itself
originated (i.e., the message originator address is the originated (i.e., the message originator address is the
originator address of this router, or is an O_orig_addr in an originator address of this router or is an O_orig_addr in an
Originator Tuple) then the message MUST be silently discarded. Originator Tuple), then the message MUST be silently discarded.
2. Otherwise: 2. Otherwise:
1. If the message is of a type which may be processed, then the 1. If the message is of a type that may be processed, then the
message is considered for processing according to message is considered for processing according to
Section 14.2. Section 14.2.
2. If the message is of a type which may be forwarded, AND: 2. If the message is of a type that may be forwarded, AND:
+ <msg-hop-limit> is present and <msg-hop-limit> > 1; AND + <msg-hop-limit> is present and <msg-hop-limit> > 1; AND
+ <msg-hop-count> is not present or <msg-hop-count> < 255; + <msg-hop-count> is not present or <msg-hop-count> < 255,
then the message is considered for forwarding according to then the message is considered for forwarding according to
Section 14.3. Section 14.3.
14.2. Message Considered for Processing 14.2. 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 the sending address (i.e., the source address of the IP 1. If the sending address (i.e., the source address of the IP
datagram containing the current message) does not match (taking datagram containing the current message) does not match (taking
into account any address prefix) a network address in an into account any address prefix) a network address in an
L_neighbor_iface_addr_list of a Link Tuple, with L_status = L_neighbor_iface_addr_list of a Link Tuple, with L_status =
SYMMETRIC, in the Link Set for the OLSRv2 interface on which the SYMMETRIC, in the Link Set for the OLSRv2 interface on which the
current message was received (the "receiving interface") then current message was received (the "receiving interface"), then
processing the current message is OPTIONAL. If the current processing the current message is OPTIONAL. If the current
message is not processed then the following steps are not carried message is not processed, then the following steps are not
out. carried out.
2. If a Processed Tuple exists with: 2. If a Processed Tuple exists with:
* P_type = the Message Type of the current message; AND * P_type = the Message Type of the current message; AND
* P_orig_addr = the originator address of the current message; * P_orig_addr = the originator address of the current message;
AND AND
* P_seq_number = the message sequence number of the current * P_seq_number = the message sequence number of the current
message; message,
then the current message MUST NOT be processed. then the current message MUST NOT be processed.
3. Otherwise: 3. Otherwise:
1. Create a Processed Tuple in the Processed Set with: 1. Create a Processed Tuple in the Processed Set with:
+ P_type := the Message Type of the current message; + P_type := the Message Type of the current message;
+ P_orig_addr := the originator address of the current + P_orig_addr := the originator address of the current
message; message;
+ P_seq_number := the sequence number of the current + P_seq_number := the sequence number of the current
message; message;
+ P_time := current time + P_HOLD_TIME. + P_time := current time + P_HOLD_TIME.
2. Process the current message according to its Message Type. 2. Process the current message according to its Message Type.
For a TC message this is as defined in Section 16.3. For a TC message, this is as defined in Section 16.3.
14.3. Message Considered for Forwarding 14.3. Message Considered for Forwarding
If a message (the "current message") is considered for forwarding, If a message (the "current message") is considered for forwarding,
then the following tasks MUST be performed: then the following tasks MUST be performed:
1. If the sending address (i.e., the source address of the IP 1. If the sending address (i.e., the source address of the IP
datagram containing the current message) does not match (taking datagram containing the current message) does not match (taking
into account any address prefix) a network address in an into account any address prefix) a network address in an
L_neighbor_iface_addr_list of a Link Tuple, with L_status = L_neighbor_iface_addr_list of a Link Tuple, with L_status =
SYMMETRIC, in the Link Set for the OLSRv2 interface on which the SYMMETRIC, in the Link Set for the OLSRv2 interface on which the
current message was received (the "receiving interface") then the current message was received (the "receiving interface"), then
current message MUST be silently discarded. the current message MUST be silently discarded.
2. Otherwise: 2. Otherwise:
1. If a Received Tuple exists in the Received Set for the 1. If a Received Tuple exists in the Received Set for the
receiving interface, with: receiving interface, with:
+ RX_type = the Message Type of the current message; AND + RX_type = the Message Type of the current message; AND
+ RX_orig_addr = the originator address of the current + RX_orig_addr = the originator address of the current
message; AND message; AND
+ RX_seq_number = the sequence number of the current + RX_seq_number = the sequence number of the current
message; message,
then the current message MUST be silently discarded. then the current message MUST be silently discarded.
2. Otherwise: 2. Otherwise:
1. Create a Received Tuple in the Received Set for the 1. Create a Received Tuple in the Received Set for the
receiving interface with: receiving interface with:
- RX_type := the Message Type of the current message; - RX_type := the Message Type of the current message;
skipping to change at page 48, line 13 skipping to change at page 48, line 18
- RX_time := current time + RX_HOLD_TIME. - RX_time := current time + RX_HOLD_TIME.
2. If a Forwarded Tuple exists with: 2. If a Forwarded Tuple exists with:
- F_type = the Message Type of the current message; AND - F_type = the Message Type of the current message; AND
- F_orig_addr = the originator address of the current - F_orig_addr = the originator address of the current
message; AND message; AND
- F_seq_number = the sequence number of the current - F_seq_number = the sequence number of the current
message. message,
then the current message MUST be silently discarded. then the current message MUST be silently discarded.
3. Otherwise if the sending address matches (taking account 3. Otherwise, if the sending address matches (taking account
of any address prefix) any network address in an of any address prefix), any network address in an
L_neighbor_iface_addr_list of a Link Tuple in the Link L_neighbor_iface_addr_list of a Link Tuple in the Link
Set for the receiving OLSRv2 interface that has L_status Set for the receiving OLSRv2 interface that has L_status
= SYMMETRIC and whose corresponding Neighbor Tuple has = SYMMETRIC and L_mpr_selector = true, then:
N_mpr_selector = true, then:
1. Create a Forwarded Tuple in the Forwarded Set with: 1. Create a Forwarded Tuple in the Forwarded Set with:
o F_type := the Message Type of the current message; o F_type := the Message Type of the current message;
o F_orig_addr := originator address of the current o F_orig_addr := originator address of the current
message; message;
o F_seq_number := sequence number of the current o F_seq_number := sequence number of the current
message; message;
skipping to change at page 49, line 7 skipping to change at page 49, line 10
Message Header by 1. Message Header by 1.
3. The message is transmitted over all OLSRv2 3. The message is transmitted over all OLSRv2
interfaces, as described in Section 13. interfaces, as described in Section 13.
4. Otherwise, the current message MUST be silently 4. Otherwise, the current message MUST be silently
discarded. discarded.
15. HELLO Messages 15. HELLO Messages
The HELLO Message Type is owned by [RFC6130], and thus HELLO messages The HELLO Message Type is owned by NHDP [RFC6130], and HELLO messages
are generated, transmitted, received and processed by [RFC6130]. are thus generated, transmitted, received, and processed by NHDP.
This protocol, as permitted by [RFC6130], also uses HELLO messages, This protocol, as permitted by [RFC6130], also uses HELLO messages,
including adding to HELLO message generation, and implementing including adding to HELLO message generation and implementing
additional processing based on received HELLO messages. HELLO additional processing based on received HELLO messages. HELLO
messages are not forwarded by [RFC6130] or by this specification. messages are not forwarded by NHDP [RFC6130] or by OLSRv2.
15.1. HELLO Message Generation 15.1. HELLO Message Generation
HELLO messages sent over OLSRv2 interfaces are generated as defined HELLO messages sent over OLSRv2 interfaces are generated as defined
in [RFC6130], and then modified as described in this section. HELLO in [RFC6130] and then modified as described in this section. HELLO
messages sent on other MANET interfaces are not modified by this messages sent on other MANET interfaces are not modified by this
specification. specification.
HELLO messages sent over OLSRv2 interfaces are extended by adding the HELLO messages sent over OLSRv2 interfaces are extended by adding the
following elements: following elements:
o A message originator address, recording this router's originator o A message originator address, recording this router's originator
address. This MUST use a <msg-orig-addr> element, unless: address. This MUST use a <msg-orig-addr> element, unless:
* The message specifies only a single local interface address * The message specifies only a single local interface address
(i.e., contains only one address object that is associated with (i.e., contains only one address object that is associated with
an Address Block TLV with Type = LOCAL_IF, and which has no an Address Block TLV with Type = LOCAL_IF and that has no
prefix length, or a maximum prefix length) which will then be prefix length or a maximum prefix length) that will then be
used as the message originator address, OR; used as the message originator address; OR
* The message does not include any local interface network * The message does not include any local interface network
addresses (i.e., has no address objects associated with an addresses (i.e., has no address objects associated with an
Address Block TLV with Type = LOCAL_IF), as permitted by the Address Block TLV with Type = LOCAL_IF), as permitted by the
specification in [RFC6130], when the router that generated the specification in [RFC6130], when the router that generated the
HELLO message has only one interface address and will use that HELLO message has only one interface address and will use that
as the sending address of the IP datagram in which the HELLO as the sending address of the IP datagram in which the HELLO
message is contained. In this case, that address will be used message is contained. In this case, that address will be used
as the message originator address. as the message originator address.
skipping to change at page 50, line 4 skipping to change at page 50, line 7
o The following cases associate Address Block TLVs with one or more o The following cases associate Address Block TLVs with one or more
addresses from a Link Tuple or a Neighbor Tuple if these are addresses from a Link Tuple or a Neighbor Tuple if these are
included in the HELLO message. In each case, the TLV MUST be included in the HELLO message. In each case, the TLV MUST be
associated with at least one address object for an address from associated with at least one address object for an address from
the relevant Tuple; the TLV MAY be associated with more such the relevant Tuple; the TLV MAY be associated with more such
addresses (including a copy of that address object, possibly not addresses (including a copy of that address object, possibly not
itself associated with any other indicated TLVs, in the same or a itself associated with any other indicated TLVs, in the same or a
different Address Block). These additional TLVs MUST NOT be different Address Block). These additional TLVs MUST NOT be
associated with any other addresses in a HELLO message that will associated with any other addresses in a HELLO message that will
be processed by [RFC6130]. be processed by NHDP [RFC6130].
* For each Link Tuple for which L_in_metric != UNKNOWN_METRIC, * For each Link Tuple for which L_in_metric != UNKNOWN_METRIC and
and for which one or more addresses in its for which one or more addresses in its
L_neighbor_iface_addr_list are included as address objects with L_neighbor_iface_addr_list are included as address objects with
an associated Address Block TLV with Type = LINK_STATUS and an associated Address Block TLV with Type = LINK_STATUS and
Value = HEARD or Value = SYMMETRIC, at least one of these Value = HEARD or Value = SYMMETRIC, at least one of these
addresses MUST be associated with an Address Block TLV with addresses MUST be associated with an Address Block TLV with
Type := LINK_METRIC indicating an incoming link metric with Type := LINK_METRIC indicating an incoming link metric with
value L_in_metric. value L_in_metric.
* For each Link Tuple for which L_out_metric != UNKNOWN_METRIC, * For each Link Tuple for which L_out_metric != UNKNOWN_METRIC
and for which one or more addresses in its and for which one or more addresses in its
L_neighbor_iface_addr_list are included as address objects with L_neighbor_iface_addr_list are included as address objects with
an associated Address Block TLV with Type = LINK_STATUS and an associated Address Block TLV with Type = LINK_STATUS and
Value = SYMMETRIC, at least one of these addresses MUST be Value = SYMMETRIC, at least one of these addresses MUST be
associated with an Address Block TLV with Type := LINK_METRIC associated with an Address Block TLV with Type := LINK_METRIC
indicating an outgoing link metric with value L_out_metric. indicating an outgoing link metric with value L_out_metric.
* For each Neighbor Tuple for which N_symmetric = true, and for * For each Neighbor Tuple for which N_symmetric = true and for
which one or more addresses in its N_neighbor_addr_list are which one or more addresses in its N_neighbor_addr_list are
included as address objects with an associated Address Block included as address objects with an associated Address Block
TLV with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value = TLV with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value =
SYMMETRIC, at least one of these addresses MUST be associated SYMMETRIC, at least one of these addresses MUST be associated
with an Address Block TLV with Type := LINK_METRIC indicating with an Address Block TLV with Type := LINK_METRIC indicating
an incoming neighbor metric with value N_in_metric. an incoming neighbor metric with value N_in_metric.
* For each Neighbor Tuple for which N_symmetric = true, and for * For each Neighbor Tuple for which N_symmetric = true and for
which one or more addresses in its N_neighbor_addr_list are which one or more addresses in its N_neighbor_addr_list are
included as address objects with an associated Address Block included as address objects with an associated Address Block
TLV with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value = TLV with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value =
SYMMETRIC, at least one of these addresses MUST be associated SYMMETRIC, at least one of these addresses MUST be associated
with an Address Block TLV with Type := LINK_METRIC indicating with an Address Block TLV with Type := LINK_METRIC indicating
an outgoing neighbor metric with value N_out_metric. an outgoing neighbor metric with value N_out_metric.
* For each Neighbor Tuple with N_flooding_mpr = true, and for * For each Neighbor Tuple with N_flooding_mpr = true and for
which one or more network addresses in its N_neighbor_addr_list which one or more network addresses in its N_neighbor_addr_list
are included as address objects in the HELLO message with an are included as address objects in the HELLO message with an
associated Address Block TLV with Type = LINK_STATUS and Value associated Address Block TLV with Type = LINK_STATUS and Value
= SYMMETRIC, at least one of these addresses MUST be associated = SYMMETRIC, at least one of these addresses MUST be associated
with an Address Block TLV with Type := MPR and Value := with an Address Block TLV with Type := MPR and Value :=
FLOODING or Value := FLOOD_ROUTE. FLOODING or Value := FLOOD_ROUTE.
* For each Neighbor Tuple with N_routing_mpr = true, and for * For each Neighbor Tuple with N_routing_mpr = true and for which
which one or more network addresses in its N_neighbor_addr_list one or more network addresses in its N_neighbor_addr_list are
are included as address objects in the HELLO message with an included as address objects in the HELLO message with an
associated Address Block TLV with Type = LINK_STATUS and Value associated Address Block TLV with Type = LINK_STATUS and Value
= SYMMETRIC, at least one of these addresses MUST be associated = SYMMETRIC, at least one of these addresses MUST be associated
with an Address Block TLV with Type := MPR and Value := ROUTING with an Address Block TLV with Type := MPR and Value := ROUTING
or Value := FLOOD_ROUTE. or Value := FLOOD_ROUTE.
15.2. HELLO Message Transmission 15.2. HELLO Message Transmission
HELLO messages are scheduled and transmitted by [RFC6130]. This HELLO messages are scheduled and transmitted by NHDP [RFC6130]. This
protocol MAY require that an additional HELLO message is sent on each protocol MAY require that an additional HELLO message be sent on each
OLSRv2 interface when either of the router's sets of MPRs changes, in OLSRv2 interface when either of the router's sets of MPRs changes, in
addition to the cases specified in [RFC6130], and subject to the addition to the cases specified in [RFC6130] and subject to the
constraints specified in [RFC6130] (notably on minimum HELLO message constraints specified in [RFC6130] (notably on minimum HELLO message
transmission intervals). transmission intervals).
15.3. HELLO Message Processing 15.3. HELLO Message Processing
When received on an OLSRv2 interface, HELLO messages are made When received on an OLSRv2 interface, HELLO messages are made
available to this protocol in two ways, both as permitted by available to this protocol in two ways, both as permitted by
[RFC6130]: [RFC6130]:
o Such received HELLO messages MUST be made available to this o Such received HELLO messages MUST be made available to this
protocol on reception, which allows them to be discarded before protocol on reception, which allows them to be discarded before
being processed by [RFC6130], for example if the information added being processed by NHDP [RFC6130], for example, if the information
to the HELLO message by this specification is inconsistent. added to the HELLO message by this specification is inconsistent.
o Such received HELLO messages MUST be made available to OLSRv2 o Such received HELLO messages MUST be made available to OLSRv2
after [RFC6130] has completed its processing thereof, unless after NHDP [RFC6130] has completed its processing thereof, unless
discarded as malformed by [RFC6130], for processing by this discarded as malformed by NHDP, for processing by OLSRv2.
specification.
15.3.1. HELLO Message Discarding 15.3.1. HELLO Message Discarding
In addition to the reasons specified in [RFC6130] for discarding a In addition to the reasons specified in [RFC6130] for discarding a
HELLO message on reception, a HELLO message received on an OLSRv2 HELLO message on reception, a HELLO message received on an OLSRv2
interface MUST be discarded before processing by [RFC6130] or this interface MUST be discarded before processing by NHDP [RFC6130] or
specification if it: this specification if it:
o Has more than one Message TLV with Type = MPR_WILLING. o Has more than one Message TLV with Type = MPR_WILLING.
o Has a message originator address, or a network address o Has a message originator address, or a network address
corresponding to an address object associated with an Address corresponding to an address object associated with an Address
Block TLV with Type = LOCAL_IF, that is partially owned by this Block TLV with Type = LOCAL_IF, that is partially owned by this
router. (Some of these cases are already excluded by [RFC6130].) router. (Some of these cases are already excluded by [RFC6130].)
o Includes any address object associated with an Address Block TLV o Includes any address object associated with an Address Block TLV
with Type = LINK_STATUS or Type = OTHER_NEIGHB that overlaps the with Type = LINK_STATUS or Type = OTHER_NEIGHB that overlaps the
message's originator address. message's originator address.
o Contains any address that will be processed by [RFC6130] that is o Contains any address that will be processed by NHDP [RFC6130] that
associated, using the same or different address objects, with two is associated, using the same or different address objects, with
different values of link metric with the same kind and direction two different values of link metric with the same kind and
using a TLV with Type = LINK_METRIC and Type Extension = direction using a TLV with Type = LINK_METRIC and Type Extension =
LINK_METRIC_TYPE. This also applies to different addresses that LINK_METRIC_TYPE. This also applies to different addresses that
are both of the OLSRv2 interface on which the HELLO message was are both of the OLSRv2 interface on which the HELLO message was
received. received.
o Contains any address object associated with an Address Block TLV o Contains any address object associated with an Address Block TLV
with Type = MPR that is not also associated with an Address Block with Type = MPR that is not also associated with an Address Block
TLV with Type = LINK_STATUS and Value = SYMMETRIC (including using TLV with Type = LINK_STATUS and Value = SYMMETRIC (including using
a different copy of that address object, in the same or a a different copy of that address object in the same or a different
different Address Block). Address Block).
15.3.2. HELLO Message Usage 15.3.2. HELLO Message Usage
HELLO messages are first processed as specified in [RFC6130]. That HELLO messages are first processed as specified in [RFC6130]. That
processing includes identifying (or creating) a Link Tuple and a processing includes identifying (or creating) a Link Tuple and a
Neighbor Tuple corresponding to the originator of the HELLO message Neighbor Tuple corresponding to the originator of the HELLO message
(the "current Link Tuple" and the "current Neighbor Tuple"). After (the "current Link Tuple" and the "current Neighbor Tuple"). After
this, the following processing MUST also be performed if the HELLO this, the following processing MUST also be performed if the HELLO
message is received on an OLSRv2 interface and contains a TLV with message is received on an OLSRv2 interface and contains a TLV with
Type = MPR_WILLING: Type = MPR_WILLING:
1. If the HELLO message has a well-defined message originator 1. If the HELLO message has a well-defined message originator
address, i.e., has an <msg-orig-addr> element, or has zero or one address, i.e., has an <msg-orig-addr> element or has zero or one
network addresses associated with a TLV with Type = LOCAL_IF: network addresses associated with a TLV with Type = LOCAL_IF:
1. Remove any Neighbor Tuple, other than the current Neighbor 1. Remove any Neighbor Tuple, other than the current Neighbor
Tuple, with N_orig_addr = message originator address, taking Tuple, with N_orig_addr = message originator address, taking
any consequent action (including removing one or more Link any consequent action (including removing one or more Link
Tuples) as specified in [RFC6130]. Tuples) as specified in [RFC6130].
2. The current Link Tuple is then updated according to: 2. The current Link Tuple is then updated according to:
1. Update L_in_metric and L_out_metric as described in 1. Update L_in_metric and L_out_metric as described in
skipping to change at page 52, line 45 skipping to change at page 53, line 4
2. The current Link Tuple is then updated according to: 2. The current Link Tuple is then updated according to:
1. Update L_in_metric and L_out_metric as described in 1. Update L_in_metric and L_out_metric as described in
Section 15.3.2.1; Section 15.3.2.1;
2. Update L_mpr_selector as described in Section 15.3.2.3. 2. Update L_mpr_selector as described in Section 15.3.2.3.
3. The current Neighbor Tuple is then updated according to: 3. The current Neighbor Tuple is then updated according to:
1. N_orig_addr := message originator address; 1. N_orig_addr := message originator address;
2. Update N_in_metric and N_out_metric as described in 2. Update N_in_metric and N_out_metric as described in
Section 15.3.2.1; Section 15.3.2.1;
3. Update N_will_flooding and N_will_routing as described in 3. Update N_will_flooding and N_will_routing as described in
Section 15.3.2.2; Section 15.3.2.2;
4. Update N_mpr_selector as described in Section 15.3.2.3. 4. Update N_mpr_selector as described in Section 15.3.2.3.
4. All 2-Hop Tuples that were updated as described in [RFC6130]
are then updated according to:
1. Update N2_in_metric and N2_out_metric as described in
Section 15.3.2.1.
2. If there are any changes to the router's Information Bases, then 2. If there are any changes to the router's Information Bases, then
perform the processing defined in Section 17. perform the processing defined in Section 17.
15.3.2.1. Updating Metrics 15.3.2.1. Updating Metrics
For each address in a received HELLO message with an associated TLV For each address in a received HELLO message with an associated TLV
with Type = LINK_STATUS and Value = HEARD or Value = SYMMETRIC, an with Type = LINK_STATUS and Value = HEARD or Value = SYMMETRIC, an
incoming (to the message originator) link metric value is defined incoming (to the message originator) link metric value is defined.
either using an associated TLV with Type = LINK_METRIC and Type If the HELLO message contains a TLV with Type = LINK_METRIC and Type
Extension = LINK_METRIC_TYPE that indicates the appropriate kind Extension = LINK_METRIC_TYPE that associates that address value with
(link) and direction (incoming) of metric, or as UNKNOWN_METRIC. a metric value of the appropriate kind (link) and direction
(incoming) of metric, then the incoming link metric is that metric
value; otherwise, the incoming link metric is defined as
UNKNOWN_METRIC.
For each address in a received HELLO message with an associated TLV For each address in a received HELLO message with an associated TLV
with Type = LINK_STATUS and Value = SYMMETRIC, an outgoing (from the with Type = LINK_STATUS and Value = SYMMETRIC, an outgoing (from the
message originator) link metric value is defined either using an message originator) link metric value is defined. If the HELLO
associated TLV with Type = LINK_METRIC and Type Extension = message contains a TLV with Type = LINK_METRIC and Type Extension =
LINK_METRIC_TYPE that indicates the appropriate kind (link) and LINK_METRIC_TYPE that associates that address value with a metric
direction (outgoing) of metric, or as UNKNOWN_METRIC. value of the appropriate kind (link) and direction (outgoing) of
metric, then the outgoing link metric is that metric value;
otherwise, the outgoing link metric is defined as UNKNOWN_METRIC.
For each address in a received HELLO message with an associated TLV For each address in a received HELLO message with an associated TLV
with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value = SYMMETRIC, with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value = SYMMETRIC,
an incoming (to the message originator) neighbor metric value is an incoming (to the message originator) neighbor metric value is
defined either using an associated TLV with Type = LINK_METRIC and defined. If the HELLO message contains a TLV with Type = LINK_METRIC
Type Extension = LINK_METRIC_TYPE that indicates the appropriate kind and Type Extension = LINK_METRIC_TYPE that associates that address
(neighbor) and direction (incoming) of metric, or as UNKNOWN_METRIC. value with a metric value of the appropriate kind (neighbor) and
direction (incoming) of metric, then the incoming neighbor metric is
that metric value; otherwise, the incoming neighbor metric is defined
as UNKNOWN_METRIC.
For each address in a received HELLO message with an associated TLV For each address in a received HELLO message with an associated TLV
with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value = SYMMETRIC, with Type = LINK_STATUS or Type = OTHER_NEIGHB and Value = SYMMETRIC,
an outgoing (from the message originator) neighbor metric value is an outgoing (from the message originator) neighbor metric value is
defined either using an associated TLV with Type = LINK_METRIC and defined. If the HELLO message contains a TLV with Type = LINK_METRIC
Type Extension = LINK_METRIC_TYPE that indicates the appropriate kind and Type Extension = LINK_METRIC_TYPE that associates that address
(neighbor) and direction (outgoing) of metric, or as UNKNOWN_METRIC. value with a metric value of the appropriate kind (neighbor) and
direction (outgoing) of metric, then the outgoing neighbor metric is
that metric value; otherwise, the outgoing neighbor metric is defined
as UNKNOWN_METRIC.
The link metric elements L_in_metric and L_out_metric in a Link Tuple The link metric elements L_in_metric and L_out_metric in a Link Tuple
are updated according to the following: are updated according to the following:
o For any Link Tuple, L_in_metric MAY be set to any representable o For any Link Tuple, L_in_metric MAY be set to any representable
value, by a process outside this specification, at any time. value by a process outside this specification at any time.
L_in_metric MUST be so set whenever L_status becomes equal to L_in_metric MUST be so set whenever L_status becomes equal to
HEARD or SYMMETRIC (if no other value is available then the value HEARD or SYMMETRIC (if no other value is available, then the value
MAXIMUM_METRIC MUST be used). Setting L_in_metric MAY use MAXIMUM_METRIC MUST be used). Setting L_in_metric MAY use
information based on the receipt of a packet including a HELLO information based on the receipt of a packet including a HELLO
message that causes the creation or updating of the Link Tuple. message that causes the creation or updating of the Link Tuple.
o When, as specified in [RFC6130], a Link Tuple is updated (possibly o When, as specified in [RFC6130], a Link Tuple is updated (possibly
immediately after being created) due to the receipt of a HELLO immediately after being created) due to the receipt of a HELLO
message, if L_status = SYMMETRIC, then L_out_metric is set equal message, if L_status = SYMMETRIC, then L_out_metric is set equal
to the incoming link metric for any included address of the to the incoming link metric for any included address of the
interface on which the HELLO message was received. (Note that the interface on which the HELLO message was received. (Note that the
rules for discarding HELLO messages in Section 15.3.1 make this rules for discarding HELLO messages in Section 15.3.1 make this
value unambiguous.) If there is no such link metric then value unambiguous.) If there is any such address, but no such
L_out_metric is set to UNKNOWN_METRIC. link metric, then L_out_metric is set to UNKNOWN_METRIC.
The neighbor metric elements N_in_metric and N_out_metric in a The neighbor metric elements N_in_metric and N_out_metric in a
Neighbor Tuple are updated according to Section 17.3. Neighbor Tuple are updated according to Section 17.3.
The metric elements N2_in_metric and N2_out_metric in any 2-Hop Tuple The metric elements N2_in_metric and N2_out_metric in any 2-Hop Tuple
updated as defined in [RFC6130] are updated to equal the incoming updated as defined in [RFC6130] are updated to equal the incoming
neighbor metric and outgoing neighbor metric, respectively, neighbor metric and outgoing neighbor metric, respectively,
associated with the corresponding N2_2hop_addr. If there are no such associated with the corresponding N2_2hop_addr. If there are no such
metrics then these elements are set to UNKNOWN_METRIC. metrics, then these elements are set to UNKNOWN_METRIC.
15.3.2.2. Updating Willingness 15.3.2.2. Updating Willingness
N_will_flooding and N_will_routing in the current Neighbor Tuple are N_will_flooding and N_will_routing in the current Neighbor Tuple are
updated using the Message TLV with Type = MPR_WILLING (note that this updated using the Message TLV with Type = MPR_WILLING (note that this
must be present) as follows: must be present) as follows:
o N_will_flooding := bits 0-3 of the value of that TLV; AND o N_will_flooding := bits 0-3 of the value of that TLV; AND
o N_will_routing := bits 4-7 of the value of that TLV. o N_will_routing := bits 4-7 of the value of that TLV.
skipping to change at page 54, line 42 skipping to change at page 55, line 21
15.3.2.3. Updating MPR Selector Status 15.3.2.3. Updating MPR Selector Status
L_mpr_selector is updated as follows: L_mpr_selector is updated as follows:
1. If a router finds an address object representing any of its 1. If a router finds an address object representing any of its
relevant local interface network addresses (i.e., those contained relevant local interface network addresses (i.e., those contained
in the I_local_iface_addr_list of an OLSRv2 interface) with an in the I_local_iface_addr_list of an OLSRv2 interface) with an
associated Address Block TLV with Type = MPR and Value = FLOODING associated Address Block TLV with Type = MPR and Value = FLOODING
or Value = FLOOD_ROUTE in the HELLO message (indicating that the or Value = FLOOD_ROUTE in the HELLO message (indicating that the
originating router has selected the receiving router as a originating router has selected the receiving router as a
flooding MPR) then, for the current Link Tuple: flooding MPR), then, for the current Link Tuple:
* L_mpr_selector := true. * L_mpr_selector := true.
2. Otherwise (i.e., if no such address object and Address Block TLV 2. Otherwise (i.e., if no such address object and Address Block TLV
was found), if a router finds an address object representing any was found), if a router finds an address object representing any
of its relevant local interface network addresses (i.e., those of its relevant local interface network addresses (i.e., those
contained in the I_local_iface_addr_list of an OLSRv2 interface) contained in the I_local_iface_addr_list of an OLSRv2 interface)
with an associated Address Block TLV with Type = LINK_STATUS and with an associated Address Block TLV with Type = LINK_STATUS and
Value = SYMMETRIC in the HELLO message, then for the current Link Value = SYMMETRIC in the HELLO message, then, for the current
Tuple: Link Tuple:
* L_mpr_selector := false. * L_mpr_selector := false.
N_mpr_selector is updated as follows: N_mpr_selector is updated as follows:
1. If a router finds an address object representing any of its 1. If a router finds an address object representing any of its
relevant local interface network addresses (those contained in relevant local interface network addresses (those contained in
the I_local_iface_addr_list of an OLSRv2 interface) with an the I_local_iface_addr_list of an OLSRv2 interface) with an
associated Address Block TLV with Type = MPR and Value = ROUTING associated Address Block TLV with Type = MPR and Value = ROUTING
or Value = FLOOD_ROUTE in the HELLO message (indicating that the or Value = FLOOD_ROUTE in the HELLO message (indicating that the
originating router has selected the receiving router as a routing originating router has selected the receiving router as a routing
MPR) then, for the current Neighbor Tuple: MPR), then, for the current Neighbor Tuple:
* N_mpr_selector := true; * N_mpr_selector := true;
* N_advertised := true. * N_advertised := true.
2. Otherwise (i.e., if no such address object and Address Block TLV 2. Otherwise (i.e., if no such address object and Address Block TLV
was found), if a router finds an address object representing any was found), if a router finds an address object representing any
of its relevant local interface network addresses (those of its relevant local interface network addresses (those
contained in the I_local_iface_addr_list of an OLSRv2 interface) contained in the I_local_iface_addr_list of an OLSRv2 interface)
with an associated Address Block TLV with Type = LINK_STATUS and with an associated Address Block TLV with Type = LINK_STATUS and
Value = SYMMETRIC in the HELLO message, then for the current Value = SYMMETRIC in the HELLO message, then, for the current
Neighbor Tuple: Neighbor Tuple:
* N_mpr_selector := false; * N_mpr_selector := false;
* The router MAY also set N_advertised := false. * The router MAY also set N_advertised := false.
16. TC Messages 16. TC Messages
This protocol defines, and hence owns, the TC Message Type (see This protocol defines, and hence owns, the TC Message Type (see
Section 24). Thus, as specified in [RFC5444], this protocol Section 24). Thus, as specified in [RFC5444], this protocol
generates and transmits all TC messages, receives all TC messages and generates and transmits all TC messages, receives all TC messages,
is responsible for determining whether and how each TC message is to and is responsible for determining whether and how each TC message is
be processed (updating the Topology Information Base) and/or to be processed (updating the Topology Information Base) and/or
forwarded, according to this specification. forwarded, according to this specification.
16.1. TC Message Generation 16.1. TC Message Generation
A TC message is a message as defined in [RFC5444]. A generated TC A TC message is a message as defined in [RFC5444]. A generated TC
message MUST contain the following elements as defined in [RFC5444]: message MUST contain the following elements as defined in [RFC5444]:
o A message originator address, recording this router's originator o A message originator address, recording this router's originator
address. This MUST use a <msg-orig-addr> element. address. This MUST use a <msg-orig-addr> element.
o <msg-seq-num> element containing the message sequence number. o <msg-seq-num> element containing the message sequence number.
o A <msg-hop-limit> element, containing TC_HOP_LIMIT. A router MAY o A <msg-hop-limit> element, containing TC_HOP_LIMIT. A router MAY
use the same or different values of TC_HOP_LIMIT in its TC use the same or different values of TC_HOP_LIMIT in its TC
messages, see Section 5.4.7. messages (see Section 5.4.7).
o A <msg-hop-count> element, containing zero, if the message o A <msg-hop-count> element, containing zero, if the message
contains a TLV with either Type = VALIDITY_TIME or Type = contains a TLV with either Type = VALIDITY_TIME or Type =
INTERVAL_TIME (as specified in [RFC5497]) indicating more than one INTERVAL_TIME (as specified in [RFC5497]) indicating more than one
time value according to distance. A TC message MAY contain such a time value according to distance. A TC message MAY contain such a
<msg-hop-count> element even if it does not need to. <msg-hop-count> element even if it does not need to.
o A single Message TLV with Type := CONT_SEQ_NUM and Value := ANSN o A single Message TLV with Type := CONT_SEQ_NUM and Value := ANSN
from the Neighbor Information Base. If the TC message is complete from the Neighbor Information Base. If the TC message is
then this Message TLV MUST have Type Extension := COMPLETE, complete, then this Message TLV MUST have Type Extension :=
otherwise it MUST have Type Extension := INCOMPLETE. (Exception: COMPLETE; otherwise, it MUST have Type Extension := INCOMPLETE.
a TC message MAY omit such a Message TLV if the TC message does (Exception: a TC message MAY omit such a Message TLV if the TC
not include any address objects with an associated Address Block message does not include any address objects with an associated
TLV with Type = NBR_ADDR_TYPE or Type = GATEWAY.) Address Block TLV with Type = NBR_ADDR_TYPE or Type = GATEWAY.)
o A single Message TLV with Type := VALIDITY_TIME, as specified in o A single Message TLV with Type := VALIDITY_TIME, as specified in
[RFC5497]. If all TC messages are sent with the same hop limit [RFC5497]. If all TC messages are sent with the same hop limit,
then this TLV MUST have a value encoding the period T_HOLD_TIME. then this TLV MUST have a value encoding the period T_HOLD_TIME.
If TC messages are sent with different hop limits (more than one If TC messages are sent with different hop limits (more than one
value of TC_HOP_LIMIT) then this TLV MUST specify times that vary value of TC_HOP_LIMIT), then this TLV MUST specify times that vary
with the number of hops appropriate to the chosen pattern of TC with the number of hops appropriate to the chosen pattern of TC
message hop limits, as specified in [RFC5497]; these times SHOULD message hop limits, as specified in [RFC5497]; these times SHOULD
be appropriate multiples of T_HOLD_TIME. The options included in be appropriate multiples of T_HOLD_TIME. The options included in
[RFC5497] for representing zero and infinite times MUST NOT be [RFC5497] for representing zero and infinite times MUST NOT be
used. used.
o If the TC message is complete, all network addresses which are the o If the TC message is complete, all network addresses that are the
N_orig_addr of a Neighbor Tuple with N_advertised = true, MUST be N_orig_addr of a Neighbor Tuple with N_advertised = true, MUST be
represented by address objects in one or more Address Blocks. If represented by address objects in one or more Address Blocks. If
the TC message is incomplete then any such address objects MAY be the TC message is incomplete, then any such address objects MAY be
included. At least one copy of each such address object that is included. At least one copy of each such address object that is
included MUST be associated with an Address Block TLV with Type := included MUST be associated with an Address Block TLV with Type :=
NBR_ADDR_TYPE, and Value := ORIGINATOR, or with Value := NBR_ADDR_TYPE and Value := ORIGINATOR or with Value :=
ROUTABLE_ORIG if that address object is also to be associated with ROUTABLE_ORIG if that address object is also to be associated with
Value = ROUTABLE. Value = ROUTABLE.
o If the TC message is complete, all routable addresses which are in o If the TC message is complete, all routable addresses that are in
the N_neighbor_addr_list of a Neighbor Tuple with N_advertised = the N_neighbor_addr_list of a Neighbor Tuple with N_advertised =
true MUST be represented by address objects in one or more Address true MUST be represented by address objects in one or more Address
Blocks. If the TC message is incomplete then any such address Blocks. If the TC message is incomplete, then any such address
objects MAY be included. At least one copy of each such address objects MAY be included. At least one copy of each such address
object MUST be associated with an Address Block TLV with Type = object MUST be associated with an Address Block TLV with Type =
NBR_ADDR_TYPE, and Value = ROUTABLE, or with Value = ROUTABLE_ORIG NBR_ADDR_TYPE and Value = ROUTABLE or with Value = ROUTABLE_ORIG
if also to be associated with Value = ORIGINATOR. At least one if also to be associated with Value = ORIGINATOR. At least one
copy of each such address object MUST be associated with an copy of each such address object MUST be associated with an
Address Block TLV with Type = LINK_METRIC and Type Extension = Address Block TLV with Type = LINK_METRIC and Type Extension =
LINK_METRIC_TYPE indicating an outgoing neighbor metric with value LINK_METRIC_TYPE indicating an outgoing neighbor metric with value
equal to the corresponding N_out_metric. equal to the corresponding N_out_metric.
o If the TC message is complete, all network addresses which are the o If the TC message is complete, all network addresses that are the
AL_net_addr of a Local Attached Network Tuple MUST be represented AL_net_addr of a Local Attached Network Tuple MUST be represented
by address objects in one or more Address Blocks. If the TC by address objects in one or more Address Blocks. If the TC
message is incomplete then any such address objects MAY be message is incomplete, then any such address objects MAY be
included. At least one copy of each such address object MUST be included. At least one copy of each such address object MUST be
associated with an Address Block TLV with Type := GATEWAY, and associated with an Address Block TLV with Type := GATEWAY and
Value := AN_dist. At least one copy of each such address object Value := AN_dist. At least one copy of each such address object
MUST be associated with an Address Block TLV with Type = MUST be associated with an Address Block TLV with Type =
LINK_METRIC and Type Extension = LINK_METRIC_TYPE indicating an LINK_METRIC and Type Extension = LINK_METRIC_TYPE indicating an
outgoing neighbor metric equal to the corresponding AL_metric. outgoing neighbor metric equal to the corresponding AL_metric.
A TC message MAY contain: A TC message MAY contain:
o A single Message TLV with Type := INTERVAL_TIME, as specified in o A single Message TLV with Type := INTERVAL_TIME, as specified in
[RFC5497]. If all TC messages are sent with the same hop limit [RFC5497]. If all TC messages are sent with the same hop limit,
then this TLV MUST have a value encoding the period TC_INTERVAL. then this TLV MUST have a value encoding the period TC_INTERVAL.
If TC messages are sent with different hop limits, then this TLV If TC messages are sent with different hop limits, then this TLV
MUST specify times that vary with the number of hops appropriate MUST specify times that vary with the number of hops appropriate
to the chosen pattern of TC message hop limits, as specified in to the chosen pattern of TC message hop limits, as specified in
[RFC5497]; these times MUST be appropriate multiples of [RFC5497]; these times MUST be appropriate multiples of
TC_INTERVAL. The options included in [RFC5497] for representing TC_INTERVAL. The options included in [RFC5497] for representing
zero and infinite times MUST NOT be used. zero and infinite times MUST NOT be used.
16.2. TC Message Transmission 16.2. TC Message Transmission
A router with one or more OLSRv2 interfaces, and with any Neighbor A router with one or more OLSRv2 interfaces, and with any Neighbor
Tuples with N_advertised = true, or with a non-empty Local Attached Tuples with N_advertised = true, or with a non-empty Local Attached
Network Set MUST generate TC messages. A router which does not have Network Set MUST generate TC messages. A router that does not have
such information to advertise MUST also generate "empty" TC messages such information to advertise MUST also generate "empty" TC messages
for a period A_HOLD_TIME after it last generated a non-empty TC for a period A_HOLD_TIME after it last generated a non-empty TC
message. message.
Complete TC messages are generated and transmitted periodically on Complete TC messages are generated and transmitted periodically on
all OLSRv2 interfaces, with a default interval between two all OLSRv2 interfaces, with a default interval between two
consecutive TC message transmissions by the same router of consecutive TC message transmissions by the same router of
TC_INTERVAL. TC_INTERVAL.
TC messages MAY be generated in response to a change in the TC messages MAY be generated in response to a change in the
information which they are to advertise, indicated by a change in the information that they are to advertise, indicated by a change in the
ANSN in the Neighbor Information Base. In this case a router MAY ANSN in the Neighbor Information Base. In this case, a router MAY
send a complete TC message, and if so MAY re-start its TC message send a complete TC message and, if so, MAY restart its TC message
schedule. Alternatively, a router MAY send an incomplete TC message schedule. Alternatively, a router MAY send an incomplete TC message
with at least the newly advertised network addresses (i.e., not with at least the newly advertised network addresses (i.e., not
previously, but now, an N_orig_addr or in an N_neighbor_addr_list in previously, but now, an N_orig_addr or in an N_neighbor_addr_list in
a Neighbor Tuple with N_advertised = true, or an AL_net_addr) in its a Neighbor Tuple with N_advertised = true or an AL_net_addr) in its
Address Blocks, with associated Address Block TLV(s). Note that a Address Blocks, with associated Address Block TLV(s). Note that a
router cannot report removal of advertised content using an router cannot report removal of advertised content using an
incomplete TC message. incomplete TC message.
When sending a TC message in response to a change of advertised When sending a TC message in response to a change of advertised
network addresses, a router MUST respect a minimum interval of network addresses, a router MUST respect a minimum interval of
TC_MIN_INTERVAL between sending TC messages (complete or incomplete), TC_MIN_INTERVAL between sending TC messages (complete or incomplete)
and a maximum interval of TC_INTERVAL between sending complete TC and a maximum interval of TC_INTERVAL between sending complete TC
messages. Thus a router MUST NOT send an incomplete TC message if messages. Thus, a router MUST NOT send an incomplete TC message if
within TC_MIN_INTERVAL of the next scheduled time to send a complete within TC_MIN_INTERVAL of the next scheduled time to send a complete
TC message. 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 [RFC5148]. The change of contents, MAY be jittered as described in [RFC5148]. The
values of MAXJITTER used MUST be: values of MAXJITTER used MUST be:
o TP_MAXJITTER for periodic TC message generation; o TP_MAXJITTER for periodic TC message generation;
o TT_MAXJITTER for responsive TC message generation. o TT_MAXJITTER for responsive TC message generation.
16.3. TC Message Processing 16.3. TC Message Processing
On receiving a TC message on an OLSRv2 interface, the receiving On receiving a TC message on an OLSRv2 interface, the receiving
router MUST then follow the processing and forwarding procedures, router MUST then follow the processing and forwarding procedures
defined in Section 14. defined in Section 14.
If the message is considered for processing (Section 14.2), then a If the message is considered for processing (Section 14.2), then a
router MUST first check if the message is invalid for processing by router MUST first check if the message is invalid for processing by
this router, as defined in Section 16.3.1. A router MAY make a this router, as defined in Section 16.3.1. A router MAY make a
similar check before considering a message for forwarding, it MUST similar check before considering a message for forwarding; it MUST
make those aspects of the check that apply to elements in the Message check the aspects that apply to elements in the Message Header.
Header.
If the TC message is not invalid, then the TC Message Type specific If the TC message is not invalid, then the processing specific to TC
processing, described in Section 16.3.2 MUST be applied. This will Message Type, described in Section 16.3.2, MUST be applied. This
update its appropriate Interface Information Bases and its Router will update its appropriate Interface Information Bases and its
Information Base. Following this, if there are any changes in these Router Information Base. Following this, if there are any changes in
Information Bases, then the processing in Section 17 MUST be these Information Bases, then the processing in Section 17 MUST be
performed. performed.
16.3.1. TC Message Discarding 16.3.1. TC Message Discarding
A received TC message is invalid for processing by this router if the A received TC message is invalid for processing by this router if the
message: message:
o Has an address length specified in the Message Header that is not o Has an address length specified in the Message Header that is not
equal to the length of the addresses used by this router. equal to the length of the addresses used by this router.
o Does not include a message originator address and a message o Does not include a message originator address and a message
sequence number. sequence number.
o Does not include a hop count, and contains a multi-value TLV with o Does not include a hop count and contains a multi-value TLV with
Type = VALIDITY_TIME or Type = INTERVAL_TIME, as defined in Type = VALIDITY_TIME or Type = INTERVAL_TIME, as defined in
[RFC5497]. [RFC5497].
o Does not have exactly one Message TLV with Type = VALIDITY_TIME. o Does not have exactly one Message TLV with Type = VALIDITY_TIME.
o Has more than one Message TLV with Type = INTERVAL_TIME. o Has more than one Message TLV with Type = INTERVAL_TIME.
o Does not have a Message TLV with Type = CONT_SEQ_NUM and Type o Does not have a Message TLV with Type = CONT_SEQ_NUM and Type
Extension = COMPLETE or Type Extension = INCOMPLETE, and contains Extension = COMPLETE or Type Extension = INCOMPLETE and contains
at least one address object associated with an Address Block TLV at least one address object associated with an Address Block TLV
with Type = NBR_ADDR_TYPE or Type = GATEWAY. with Type = NBR_ADDR_TYPE or Type = GATEWAY.
o Has more than one Message TLV with Type = CONT_SEQ_NUM and Type o Has more than one Message TLV with Type = CONT_SEQ_NUM and Type
Extension = COMPLETE or Type Extension = INCOMPLETE. Extension = COMPLETE or Type Extension = INCOMPLETE.
o Has a message originator address that is partially owned by this o Has a message originator address that is partially owned by this
router. router.
o Includes any address object with a prefix length which is not o Includes any address object with a prefix length that is not
maximal (equal to the address length, in bits), associated with an maximal (equal to the address length, in bits), associated with an
Address Block TLV with Type = NBR_ADDR_TYPE and Value = ORIGINATOR Address Block TLV with Type = NBR_ADDR_TYPE and Value = ORIGINATOR
or Value = ROUTABLE_ORIG. or Value = ROUTABLE_ORIG.
o Includes any address object that represents a non-routable o Includes any address object that represents a non-routable
address, associated with an Address Block TLV with Type = address, associated with an Address Block TLV with Type =
NBR_ADDR_TYPE and Value = ROUTABLE or Value = ROUTABLE_ORIG. NBR_ADDR_TYPE and Value = ROUTABLE or Value = ROUTABLE_ORIG.
o Includes any address object associated with an Address Block TLV o Includes any address object associated with an Address Block TLV
with Type = NBR_ADDR_TYPE or Type = GATEWAY that also represents with Type = NBR_ADDR_TYPE or Type = GATEWAY that also represents
the message's originator address. the message's originator address.
o Includes any address object (including different copies of an o Includes any address object (including different copies of an
address object, in the same or different Address Blocks) that is address object in the same or different Address Blocks) that is
associated with an Address Block TLV with Type = NBR_ADDR_TYPE or associated with an Address Block TLV with Type = NBR_ADDR_TYPE or
Type = GATEWAY, that is also associated with more than one Type = GATEWAY that is also associated with more than one outgoing
outgoing neighbor metric using a TLV with Type = LINK_METRIC and neighbor metric using a TLV with Type = LINK_METRIC and Type
Type Extension = LINK_METRIC_TYPE. Extension = LINK_METRIC_TYPE.
o Associates any address object (including different copies of an o Associates any address object (including different copies of an
address object, in the same or different Address Blocks) with more address object in the same or different Address Blocks) with more
than one single hop count value using one or more Address Block than one single hop count value using one or more Address Block
TLV(s) with Type = GATEWAY. TLV(s) with Type = GATEWAY.
o Associates any address object (including different copies of an o Associates any address object (including different copies of an
address object, in the same or different Address Blocks) with address object in the same or different Address Blocks) with
Address Block TLVs with Type = NBR_ADDR_TYPE and Type = GATEWAY. Address Block TLVs with Type = NBR_ADDR_TYPE and Type = GATEWAY.
A router MAY recognize additional reasons for identifying that a A router MAY recognize additional reasons for identifying that a
message is invalid. An invalid message MUST be silently discarded, message is invalid. An invalid message MUST be silently discarded,
without updating the router's Information Bases. without updating the router's Information Bases.
Note that a router that acts inconsistently, for example rejecting TC Note that a router that acts inconsistently, for example, rejecting
messages "at random", may cause parts of the network to not be able TC messages "at random", may cause parts of the network to not be
to communicate with other parts of the network. It is RECOMMENDED able to communicate with other parts of the network. It is
that such "additional reasons for identifying that a message is RECOMMENDED that such "additional reasons for identifying that a
invalid" be a consistent network-wide policy (e.g., as part of a message is invalid" be a consistent network-wide policy (e.g., as
security policy), implemented on all participating routers. part of a security policy), implemented on all participating routers.
16.3.2. TC Message Processing Definitions 16.3.2. TC Message Processing Definitions
When, according to Section 14.2, a TC message is to be "processed When, according to Section 14.2, a TC message is to be "processed
according to its type", this means that: according to its type", this means that:
o If the TC message contains a Message TLV with Type = CONT_SEQ_NUM o If the TC message contains a Message TLV with Type = CONT_SEQ_NUM
and Type Extension = COMPLETE, then processing according to and Type Extension = COMPLETE, then processing according to
Section 16.3.3 and then according to Section 16.3.4 is carried Section 16.3.3 and then according to Section 16.3.4 is carried
out. out.
skipping to change at page 60, line 49 skipping to change at page 61, line 33
the TC message according to the specification in [RFC5497]. All the TC message according to the specification in [RFC5497]. All
information in the TC message has the same validity time. information in the TC message has the same validity time.
o "received ANSN" is defined as being the value of a Message TLV o "received ANSN" is defined as being the value of a Message TLV
with Type = CONT_SEQ_NUM. with Type = CONT_SEQ_NUM.
o "associated metric value" is defined for any address in the TC o "associated metric value" is defined for any address in the TC
message as being either the outgoing neighbor metric value message as being either the outgoing neighbor metric value
indicated by a TLV with Type = LINK_METRIC and Type Extension = indicated by a TLV with Type = LINK_METRIC and Type Extension =
LINK_METRIC_TYPE that is associated with any address object in the LINK_METRIC_TYPE that is associated with any address object in the
TC message that is equal to that address, or as UNKNOWN_METRIC TC message that is equal to that address or as UNKNOWN_METRIC
otherwise. (Note that the rules in Section 16.3.1 make this otherwise. (Note that the rules in Section 16.3.1 make this
definition unambiguous.) definition unambiguous.)
o Comparisons of sequence numbers are carried out as specified in o Comparisons of sequence numbers are carried out as specified in
Section 21. Section 21.
16.3.3. Initial TC Message Processing 16.3.3. Initial TC Message Processing
The TC message is processed as follows: The TC message is processed as follows:
1. The Advertising Remote Router Set is updated according to 1. The Advertising Remote Router Set is updated according to
Section 16.3.3.1. If the TC message is indicated as discarded in Section 16.3.3.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 Router Topology Set is updated according to Section 16.3.3.2. 2. The Router Topology Set is updated according to Section 16.3.3.2.
3. The Routable Address Topology Set is updated according to 3. The Routable Address Topology Set is updated according to
Section 16.3.3.3. Section 16.3.3.3.
4. The Attached Network Set is updated according to 4. The Attached Network Set is updated according to
Section 16.3.3.4. Section 16.3.3.4.
16.3.3.1. Populating the Advertising Remote Router Set 16.3.3.1. Populating the Advertising Remote Router Set
skipping to change at page 62, line 9 skipping to change at page 62, line 41
then modified as follows: then modified as follows:
+ AR_seq_number := received ANSN; + AR_seq_number := received ANSN;
+ AR_time := current time + validity time. + AR_time := current time + validity time.
16.3.3.2. Populating the Router Topology Set 16.3.3.2. Populating the Router Topology Set
The router MUST update its Router Topology Set as follows: The router MUST update its Router Topology Set as follows:
1. For each address (henceforth advertised address) corresponding to 1. For each address (henceforth, advertised address) that
one or more address objects with an associated Address Block TLV corresponds to one or more address objects with an associated
with Type = NBR_ADDR_TYPE and Value = ORIGINATOR or Value = Address Block TLV with Type = NBR_ADDR_TYPE and Value =
ROUTABLE_ORIG, and that is not partially owned by this router, ORIGINATOR or Value = ROUTABLE_ORIG and that is not partially
perform the following processing: owned by this router, perform the following processing:
1. If the associated metric is UNKNOWN_METRIC then remove any 1. If the associated metric is UNKNOWN_METRIC, then remove any
Router Topology Tuple such that: Router Topology Tuple such that:
+ TR_from_orig_addr = message originator address; AND + TR_from_orig_addr = message originator address; AND
+ TR_to_orig_addr = advertised address, + TR_to_orig_addr = advertised address.
2. Otherwise if there is no Router Topology Tuple such that: 2. Otherwise, if there is no Router Topology Tuple such that:
+ TR_from_orig_addr = message originator address; AND + TR_from_orig_addr = message originator address; AND
+ TR_to_orig_addr = advertised address, + TR_to_orig_addr = advertised address,
then create a new Router Topology Tuple with: then create a new Router Topology Tuple with:
+ TR_from_orig_addr := message originator address; + TR_from_orig_addr := message originator address;
+ TR_to_orig_addr := advertised address. + TR_to_orig_addr := advertised address.
skipping to change at page 62, line 47 skipping to change at page 63, line 30
+ TR_seq_number := received ANSN; + TR_seq_number := received ANSN;
+ TR_metric := associated link metric; + TR_metric := associated link metric;
+ TR_time := current time + validity time. + TR_time := current time + validity time.
16.3.3.3. Populating the Routable Address Topology Set 16.3.3.3. Populating the Routable Address Topology Set
The router MUST update its Routable Address Topology Set as follows: The router MUST update its Routable Address Topology Set as follows:
1. For each network address (henceforth advertised address) 1. For each network address (henceforth, advertised address) that
corresponding to one or more address objects with an associated corresponds to one or more address objects with an associated
Address Block TLV with Type = NBR_ADDR_TYPE and Value = ROUTABLE Address Block TLV with Type = NBR_ADDR_TYPE and Value = ROUTABLE
or Value = ROUTABLE_ORIG, and that is not partially owned by this or Value = ROUTABLE_ORIG and that is not partially owned by this
router, perform the following processing: router, perform the following processing:
1. If the associated metric is UNKNOWN_METRIC then remove any 1. If the associated metric is UNKNOWN_METRIC, then remove any
Routable Address Topology Tuple such that: Routable Address Topology Tuple such that:
+ TA_from_orig_addr = message originator address; AND + TA_from_orig_addr = message originator address; AND
+ TA_dest_addr = advertised address. + TA_dest_addr = advertised address.
2. Otherwise if there is no Routable Address Topology Tuple such 2. Otherwise, if there is no Routable Address Topology Tuple
that: such that:
+ TA_from_orig_addr = message originator address; AND + TA_from_orig_addr = message originator address; AND
+ TA_dest_addr = advertised address, + TA_dest_addr = advertised address,
then create a new Routable Address Topology Tuple with: then create a new Routable Address Topology Tuple with:
+ TA_from_orig_addr := message originator address; + TA_from_orig_addr := message originator address;
+ TA_dest_addr := advertised address. + TA_dest_addr := advertised address.
3. This Routable Address Topology Tuple (existing or new) is 3. This Routable Address Topology Tuple (existing or new) is
then modified as follows: then modified as follows:
+ TA_seq_number := received ANSN; + TA_seq_number := received ANSN;
skipping to change at page 63, line 38 skipping to change at page 64, line 23
+ TA_seq_number := received ANSN; + TA_seq_number := received ANSN;
+ TA_metric := associated link metric; + TA_metric := associated link metric;
+ TA_time := current time + validity time. + TA_time := current time + validity time.
16.3.3.4. Populating the Attached Network Set 16.3.3.4. Populating the Attached Network Set
The router MUST update its Attached Network Set as follows: The router MUST update its Attached Network Set as follows:
1. For each network address (henceforth attached address) 1. For each network address (henceforth, attached address) that
corresponding to one or more address objects with an associated corresponds to one or more address objects with an associated
Address Block TLV with Type = GATEWAY, and that is not fully Address Block TLV with Type = GATEWAY and that is not fully owned
owned by this router, perform the following processing: by this router, perform the following processing:
1. If the associated metric is UNKNOWN_METRIC then remove any 1. If the associated metric is UNKNOWN_METRIC, then remove any
Attached Network Tuple such that: Attached Network Tuple such that:
+ AN_net_addr = attached address; AND + AN_net_addr = attached address; AND
+ AN_orig_addr = message originator address. + AN_orig_addr = message originator address.
2. Otherwise if there is no Attached Network Tuple such that: 2. Otherwise, if there is no Attached Network Tuple such that:
+ AN_net_addr = attached address; AND + AN_net_addr = attached address; AND
+ AN_orig_addr = message originator address, + AN_orig_addr = message originator address,
then create a new Attached Network Tuple with: then create a new Attached Network Tuple with:
+ AN_net_addr := attached address; + AN_net_addr := attached address;
+ AN_orig_addr := message originator address. + AN_orig_addr := message originator address.
skipping to change at page 66, line 29 skipping to change at page 67, line 17
the case. the case.
17.3. Neighbor State Changes 17.3. Neighbor State Changes
The consistency of a Neighbor Tuple MUST be maintained according to The consistency of a Neighbor Tuple MUST be maintained according to
the following rules, in addition to those in [RFC6130]: the following rules, in addition to those in [RFC6130]:
1. If N_symmetric = true, then N_in_metric MUST equal the minimum 1. If N_symmetric = true, then N_in_metric MUST equal the minimum
value of all L_in_metric of corresponding Link Tuples with value of all L_in_metric of corresponding Link Tuples with
L_status = SYMMETRIC and L_in_metric != UNKNOWN_METRIC. If there L_status = SYMMETRIC and L_in_metric != UNKNOWN_METRIC. If there
are no such Link Tuples then N_in_metric MUST equal are no such Link Tuples, then N_in_metric MUST equal
UNKNOWN_METRIC. UNKNOWN_METRIC.
2. If N_symmetric = true, then N_out_metric MUST equal the minimum 2. If N_symmetric = true, then N_out_metric MUST equal the minimum
value of all L_out_metric of corresponding Link Tuples with value of all L_out_metric of corresponding Link Tuples with
L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC. If L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC. If
there are no such Link Tuples then N_out_metric MUST equal there are no such Link Tuples, then N_out_metric MUST equal
UNKNOWN_METRIC. UNKNOWN_METRIC.
3. If N_symmetric = false, then N_flooding_mpr, N_routing_mpr, 3. If N_symmetric = false, then N_flooding_mpr, N_routing_mpr,
N_mpr_selector and N_advertised MUST all be equal to false. N_mpr_selector, and N_advertised MUST all be equal to false.
4. If N_mpr_selector = true, then N_advertised MUST be equal to 4. If N_mpr_selector = true, then N_advertised MUST be equal to
true. true.
5. If N_symmetric = true, N_out_metric != UNKNOWN_METRIC and 5. If N_symmetric = true, N_out_metric != UNKNOWN_METRIC and
N_mpr_selector = false, then a router MAY select N_advertised = N_mpr_selector = false, then a router MAY select N_advertised =
true or N_advertised = false. The more neighbors that are true or N_advertised = false. The more neighbors that are
advertised, the larger TC messages become, but the more advertised, the larger TC messages become, but the more
redundancy is available for routing. A router SHOULD consider redundancy is available for routing. A router SHOULD consider
the nature of its network in making such a decision, and SHOULD the nature of its network in making such a decision and SHOULD
avoid unnecessary changes in advertising status, which may result avoid unnecessary changes in advertising status, which may result
both in additional TC messages having to be sent by its in unnecessary changes to routing.
neighbors, and in unnecessary changes to routing, which will have
similar effects to other forms of topology changes in the MANET.
17.4. Advertised Neighbor Changes 17.4. Advertised Neighbor Changes
The router MUST increment the ANSN in the Neighbor Information Base The router MUST increment the ANSN in the Neighbor Information Base
whenever: whenever:
1. Any Neighbor Tuple changes its N_advertised value, or any 1. Any Neighbor Tuple changes its N_advertised value, or any
Neighbor Tuple with N_advertised = true is removed. Neighbor Tuple with N_advertised = true is removed.
2. Any Neighbor Tuple with N_advertised = true changes its 2. Any Neighbor Tuple with N_advertised = true changes its
N_orig_addr, or has any routable address is added to or removed N_orig_addr or has any routable address added to or removed from
from N_neighbor_addr_list. N_neighbor_addr_list.
3. Any Neighbor Tuple with N_advertised = true has N_out_metric 3. Any Neighbor Tuple with N_advertised = true has N_out_metric
changed. changed.
4. There is any change to the Local Attached Network Set. 4. There is any change to the Local Attached Network Set.
17.5. Advertising Remote Router Tuple Expires 17.5. Advertising Remote Router Tuple Expires
The Router Topology Set, the Routable Address Topology Set and the The Router Topology Set, the Routable Address Topology Set, and the
Attached Network Set MUST be changed when an Advertising Remote Attached Network Set MUST be changed when an Advertising Remote
Router Tuple expires (AR_time is reached). The following changes are Router Tuple expires (AR_time is reached). The following changes are
required before the Advertising Remote Router Tuple is removed: required before the Advertising Remote Router Tuple is removed:
1. All Router Topology Tuples with: 1. All Router Topology Tuples with:
* TR_from_orig_addr = AR_orig_addr of the Advertising Remote * TR_from_orig_addr = AR_orig_addr of the Advertising Remote
Router Tuple Router Tuple
are removed. are removed.
skipping to change at page 68, line 14 skipping to change at page 68, line 47
17.6. Neighborhood Changes and MPR Updates 17.6. Neighborhood Changes and MPR Updates
The sets of symmetric 1-hop neighbors selected as flooding MPRs and The sets of symmetric 1-hop neighbors selected as flooding MPRs and
routing MPRs MUST satisfy the conditions defined in Section 18. To routing MPRs MUST satisfy the conditions defined in Section 18. To
ensure this: ensure this:
1. The set of flooding MPRs of a router MUST be recalculated if: 1. The set of flooding MPRs of a router MUST be recalculated if:
* A Link Tuple is added with L_status = SYMMETRIC and * A Link Tuple is added with L_status = SYMMETRIC and
L_out_metric != UNKNOWN_METRIC, OR; L_out_metric != UNKNOWN_METRIC; OR
* A Link Tuple with L_status = SYMMETRIC and L_out_metric != * A Link Tuple with L_status = SYMMETRIC and L_out_metric !=
UNKNOWN_METRIC is removed, OR; UNKNOWN_METRIC is removed; OR
* A Link Tuple with L_status = SYMMETRIC and L_out_metric != * A Link Tuple with L_status = SYMMETRIC and L_out_metric !=
UNKNOWN_METRIC changes to having L_status = HEARD, L_status = UNKNOWN_METRIC changes to having L_status = HEARD, L_status =
LOST or L_out_metric = UNKNOWN_METRIC, OR; LOST, or L_out_metric = UNKNOWN_METRIC; OR
* A Link Tuple with L_status = HEARD or L_status = LOST changes * A Link Tuple with L_status = HEARD or L_status = LOST changes
to having L_status = SYMMETRIC and L_out_metric != to having L_status = SYMMETRIC and L_out_metric !=
UNKNOWN_METRIC, OR; UNKNOWN_METRIC; OR
* The flooding MPR selection process uses metric values (see * The flooding MPR selection process uses metric values (see
Section 18.4) and the L_out_metric of any Link Tuple with Section 18.4) and the L_out_metric of any Link Tuple with
L_status = SYMMETRIC changes, OR; L_status = SYMMETRIC changes; OR
* The N_will_flooding of a Neighbor Tuple with N_symmetric = * The N_will_flooding of a Neighbor Tuple with N_symmetric =
true and N_out_metric != UNKNOWN_METRIC changes from true and N_out_metric != UNKNOWN_METRIC changes from
WILL_NEVER to any other value, OR; WILL_NEVER to any other value; OR
* The N_will_flooding of a Neighbor Tuple with N_flooding_mpr = * The N_will_flooding of a Neighbor Tuple with N_flooding_mpr =
true changes to WILL_NEVER from any other value, OR; true changes to WILL_NEVER from any other value; OR
* The N_will_flooding of a Neighbor Tuple with N_symmetric = * The N_will_flooding of a Neighbor Tuple with N_symmetric =
true, N_out_metric != UNKNOWN_METRIC, and N_flooding_mpr = true, N_out_metric != UNKNOWN_METRIC, and N_flooding_mpr =
false changes to WILL_ALWAYS from any other value, OR; false changes to WILL_ALWAYS from any other value; OR
* A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC is added or * A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC is added or
removed, OR; removed; OR
* The flooding MPR selection process uses metric values (see * The N2_out_metric of any 2-Hop Tuple changes and either the
Section 18.4) and the N2_out_metric of any 2-Hop Tuple flooding MPR selection process uses metric values (see
changes. Section 18.4) or the change is to or from UNKNOWN_METRIC.
2. Otherwise, the set of flooding MPRs of a router MAY be 2. Otherwise, the set of flooding MPRs of a router MAY be
recalculated if the N_will_flooding of a Neighbor Tuple with recalculated if the N_will_flooding of a Neighbor Tuple with
N_symmetric = true changes in any other way; it SHOULD be N_symmetric = true changes in any other way; it SHOULD be
recalculated if N_flooding_mpr = false and this is an increase in recalculated if N_flooding_mpr = false and this is an increase in
N_will_flooding or if N_flooding_mpr = true and this is a N_will_flooding or if N_flooding_mpr = true and this is a
decrease in N_will_flooding. decrease in N_will_flooding.
3. The set of routing MPRs of a router MUST be recalculated if: 3. The set of routing MPRs of a router MUST be recalculated if:
* A Neighbor Tuple is added with N_symmetric = true and * A Neighbor Tuple is added with N_symmetric = true and
N_in_metric != UNKNOWN_METRIC, OR; N_in_metric != UNKNOWN_METRIC; OR
* A Neighbor Tuple with N_symmetric = true and N_in_metric != * A Neighbor Tuple with N_symmetric = true and N_in_metric !=
UNKNOWN_METRIC is removed, OR; UNKNOWN_METRIC is removed; OR
* A Neighbor Tuple with N_symmetric = true and N_in_metric != * A Neighbor Tuple with N_symmetric = true and N_in_metric !=
UNKNOWN_METRIC changes to having N_symmetric = false, OR; UNKNOWN_METRIC changes to having N_symmetric = false; OR
* A Neighbor Tuple with N_symmetric = false changes to having * A Neighbor Tuple with N_symmetric = false changes to having
N_symmetric = true and N_in_metric != UNKNOWN_METRIC, OR; N_symmetric = true and N_in_metric != UNKNOWN_METRIC; OR
* The N_in_metric of any Neighbor Tuple with N_symmetric = true * The N_in_metric of any Neighbor Tuple with N_symmetric = true
changes, OR; changes; OR
* The N_will_routing of a Neighbor Tuple with N_symmetric = true * The N_will_routing of a Neighbor Tuple with N_symmetric = true
and N_in_metric != UNKNOWN_METRIC changes from WILL_NEVER to and N_in_metric != UNKNOWN_METRIC changes from WILL_NEVER to
any other value, OR; any other value; OR
* The N_will_routing of a Neighbor Tuple with N_routing_mpr = * The N_will_routing of a Neighbor Tuple with N_routing_mpr =
true changes to WILL_NEVER from any other value, OR; true changes to WILL_NEVER from any other value; OR
* The N_will_routing of a Neighbor Tuple with N_symmetric = * The N_will_routing of a Neighbor Tuple with N_symmetric =
true, N_in_metric != UNKNOWN_METRIC and N_routing_mpr = false true, N_in_metric != UNKNOWN_METRIC and N_routing_mpr = false
changes to WILL_ALWAYS from any other value, OR; changes to WILL_ALWAYS from any other value; OR
* A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC is added or * A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC is added or
removed, OR; removed; OR
* The N2_in_metric of any 2-Hop Tuple changes. * The N2_in_metric of any 2-Hop Tuple changes.
4. Otherwise, the set of routing MPRs of a router MAY be 4. Otherwise, the set of routing MPRs of a router MAY be
recalculated if the N_will_routing of a Neighbor Tuple with recalculated if the N_will_routing of a Neighbor Tuple with
N_symmetric = true changes in any other way; it SHOULD be N_symmetric = true changes in any other way; it SHOULD be
recalculated if N_routing_mpr = false and this is an increase in recalculated if N_routing_mpr = false and this is an increase in
N_will_routing or if N_routing_mpr = true and this is a decrease N_will_routing or if N_routing_mpr = true and this is a decrease
in N_will_routing. in N_will_routing.
If either set of MPRs of a router is recalculated, this MUST be as If either set of MPRs of a router is recalculated, this MUST be as
described in Section 18. described in Section 18.
17.7. Routing Set Updates 17.7. Routing Set Updates
The Routing Set MUST be updated, as described in Section 19, when The Routing Set MUST be updated, as described in Section 19, when
changes in the Local Information Base, the Neighborhood Information changes in the Local Information Base, the Neighborhood Information
Base or the Topology Information Base indicate a change (including of Base, or the Topology Information Base indicate a change (including
any potentially used outgoing neighbor metric values) of the known of any potentially used outgoing neighbor metric values) of the known
symmetric links and/or attached networks in the MANET, hence changing symmetric links and/or attached networks in the MANET, hence changing
the Topology Graph. It is sufficient to consider only changes which the Topology Graph. It is sufficient to consider only changes that
affect at least one of: affect at least one of:
o The Local Interface Set for an OLSRv2 interface, if the change o The Local Interface Set for an OLSRv2 interface, if the change
removes any network address in an I_local_iface_addr_list. In removes any network address in an I_local_iface_addr_list. In
this case, unless the OLSRv2 interface is removed, it may not be this case, unless the OLSRv2 interface is removed, it may not be
necessary to do more than replace such network addresses, if used, necessary to do more than replace such network addresses, if used,
by an alternative network address from the same by an alternative network address from the same
I_local_iface_addr_list. I_local_iface_addr_list.
o The Local Attached Set, if the change removes any AL_net_addr o The Local Attached Set, if the change removes any AL_net_addr that
which is also an AN_net_addr. In this case it may not be is also an AN_net_addr. In this case, it may not be necessary to
necessary to do more than add Routing Tuples with R_dest_addr do more than add Routing Tuples with R_dest_addr equal to that
equal to that AN_net_addr. AN_net_addr.
o The Link Set of any OLSRv2 interface, considering only Link Tuples o The Link Set of any OLSRv2 interface, considering only Link Tuples
which have, or just had, L_status = SYMMETRIC and L_out_metric != that have, or just had, L_status = SYMMETRIC and L_out_metric !=
UNKNOWN_METRIC (including removal of such Link Tuples). UNKNOWN_METRIC (including removal of such Link Tuples).
o The Neighbor Set of the router, considering only Neighbor Tuples o The Neighbor Set of the router, considering only Neighbor Tuples
that have, or just had, N_symmetric = true and N_out_metric != that have, or just had, N_symmetric = true and N_out_metric !=
UNKNOWN_METRIC, and do not have N_orig_addr = unknown. UNKNOWN_METRIC and do not have N_orig_addr = unknown.
o The 2-Hop Set of any OLSRv2 interface, if used in the creation of o The 2-Hop Set of any OLSRv2 interface, if used in the creation of
the Routing Set, and if the change affects any 2-Hop Tuples with the Routing Set and if the change affects any 2-Hop Tuples with
N2_out_metric != UNKNOWN_METRIC. N2_out_metric != UNKNOWN_METRIC.
o The Router Topology Set of the router. o The Router Topology Set of the router.
o The Routable Address Topology Set of the router. o The Routable Address Topology Set of the router.
o The Attached Network Set of the router. o The Attached Network Set of the router.
18. Selecting MPRs 18. Selecting MPRs
Each router MUST select, from among its willing symmetric 1-hop Each router MUST select, from among its willing symmetric 1-hop
neighbors, two subsets of these routers, as flooding and routing neighbors, two subsets of these routers, as flooding and routing
MPRs. This selection is recorded in the router's Neighbor Set, and MPRs. This selection is recorded in the router's Neighbor Set and
reported in the router's HELLO messages. Routers MAY select their reported in the router's HELLO messages. Routers MAY select their
MPRs by any process that satisfies the conditions which follow, which MPRs by any process that satisfies the conditions that follow, which
may, but need not, use the organization of the data described. may, but need not, use the organization of the data described.
Routers can freely interoperate whether they use the same or Routers can freely interoperate whether they use the same or
different MPR selection algorithms. different MPR selection algorithms.
Only flooding MPRs forward control messages flooded through the Only flooding MPRs forward control messages flooded through the
MANET, thus effecting a flooding reduction, an optimization of the MANET, thus effecting a flooding reduction, an optimization of the
flooding mechanism, known as MPR flooding. Routing MPRs are used to flooding mechanism, known as MPR flooding. Routing MPRs are used to
effect a topology reduction in the MANET. (If no such reduction is effect a topology reduction in the MANET. (If no such reduction is
required then a router can select all of its relevant neighbors as required, then a router can select all of its relevant neighbors as
routing MPRs.) Consequently, while it is not essential that these routing MPRs.) Consequently, while it is not essential that these
two sets of MPRs are minimal, keeping the numbers of MPRs small two sets of MPRs are minimal, keeping the numbers of MPRs small
ensures that the overhead of this protocol is kept to a minimum. ensures that the overhead of this protocol is kept to a minimum.
18.1. Overview 18.1. Overview
MPRs are selected according to the following steps, defined in the MPRs are selected according to the following steps, defined in the
following sections: following sections:
o A data structure known as a Neighbor Graph is defined. o A data structure known as a Neighbor Graph is defined.
o The properties of an MPR Set derived from a Neighbor Graph are o The properties of an MPR Set derived from a Neighbor Graph are
defined. Any algorithm that creates an MPR Set that satisfies defined. Any algorithm that creates an MPR Set that satisfies
these properties is a valid MPR selection algorithm. An example these properties is a valid MPR selection algorithm. An example
algorithm that creates such an MPR Set is given in Appendix B. algorithm that creates such an MPR Set is given in Appendix B.
o How to create a Neighbor Graph for each interface based on the o How to create a Neighbor Graph for each interface based on the
corresponding Interface Information Base is defined, and how to corresponding Interface Information Base is defined, and how to
combine the resulting MPR Sets to determine the router's flooding combine the resulting MPR Sets to determine the router's flooding
MPRs and record those in the router's Neighbor Set. MPRs and record those in the router's Neighbor Set are described.
o How to create a single Neighbor Graph based on all Interface o How to create a single Neighbor Graph based on all Interface
Information Bases and the Neighbor Information Base is defined, Information Bases and the Neighbor Information Base is defined,
and how to record the resulting MPR Set as the router's routing and how to record the resulting MPR Set as the router's routing
MPRs in the router's Neighbor Set. MPRs in the router's Neighbor Set is described.
o A specification as to when MPRs MUST be calculated is given. o A specification as to when MPRs MUST be calculated is given.
When a router selects its MPRs it MAY consider any characteristics of When a router selects its MPRs, it MAY consider any characteristics
its neighbors that it is aware of. In particular it SHOULD consider of its neighbors that it is aware of. In particular, it SHOULD
the willingness of the neighbor, as recorded by the corresponding consider the willingness of the neighbor, as recorded by the
N_will_flooding or N_will_routing value, as appropriate, preferring corresponding N_will_flooding or N_will_routing value, as
neighbors with higher values. (Note that willingness values equal to appropriate, preferring neighbors with higher values. (Note that
WILL_NEVER and WILL_ALWAYS are always considered, as described.) willingness values equal to WILL_NEVER and WILL_ALWAYS are always
However, a router MAY consider other characteristics to have a considered, as described.) However, a router MAY consider other
greater significance. characteristics to have a greater significance.
Each router MAY select its flooding and routing MPRs independently Each router MAY select its flooding and routing MPRs independently of
from each other, or coordinate its selections. A router MAY make its each other or coordinate its selections. A router MAY make its MPR
MPR selections independently of the MPR selection by other routers, selections independently of the MPR selection by other routers, or it
or it MAY, for example, give preference to routers that either are, MAY, for example, give preference to routers that either are, or are
or are not, already selected as MPRs by other routers. not, already selected as MPRs by other routers.
18.2. Neighbor Graph 18.2. Neighbor Graph
A Neighbor Graph is a structure defined here as consisting of sets N1 A Neighbor Graph is a structure defined here as consisting of sets N1
and N2 and some associated metric and willingness values. Elements and N2 and some associated metric and willingness values. Elements
of set N1 represent willing symmetric 1-hop neighbors, and elements of set N1 represent willing symmetric 1-hop neighbors, and elements
of set N2 represent addresses of a symmetric 2-hop neighbor. of set N2 represent addresses of a symmetric 2-hop neighbor.
A Neighbor Graph has the following properties: A Neighbor Graph has the following properties:
o It contains two disjoint sets N1 and N2. o It contains two disjoint sets N1 and N2.
o For each element x in N1 there is an associated willingness value o For each element x in N1, there is an associated willingness value
W(x) such that WILL_NEVER < W(x) <= WILL_ALWAYS. W(x) such that WILL_NEVER < W(x) <= WILL_ALWAYS.
o For each element x in N1 there is an associated metric d1(x) > 0. o For each element x in N1, there is an associated metric d1(x) > 0.
o For some elements y in N2 there is an associated metric d1(y) > 0. o For some elements y in N2, there is an associated metric d1(y) >
(Other elements y in N2 have undefined d1(y), this may be 0. (Other elements y in N2 have undefined d1(y); this may be
considered to be infinite.) considered to be infinite.)
o For each element x in N1 there is a subset N2(x) of elements of o For each element x in N1, there is a subset N2(x) of elements of
N2; this subset may be empty. For each x in N1 and each y in N2; this subset may be empty. For each x in N1 and each y in
N2(x) there is an associated metric d2(x,y) > 0. (For other x in N2(x), there is an associated metric d2(x,y) > 0. (For other x in
N1 and y in N2, d2(x,y) is undefined, and may be considered N1 and y in N2, d2(x,y) is undefined and may be considered
infinite.) infinite.)
o N2 is equal to the union of all the N2(x) for all x in N1, i.e. o N2 is equal to the union of all the N2(x) for all x in N1, i.e.,
for each y in N2 there is at least one x in N1 such that y is in for each y in N2, there is at least one x in N1 such that y is in
N2(x). N2(x).
It is convenient to also define: It is convenient to also define:
o For each y in N2 the set N1(y) that contains x in N1 if and only o For each y in N2, the set N1(y) that contains x in N1 if and only
if y is in N2(x). From the final property above, N1(y) is not if y is in N2(x). From the final property above, N1(y) is not
empty. empty.
o For each x in N1 and y in N2, if d2(x,y) is defined then d(x,y) := o For each x in N1 and y in N2, if d2(x,y) is defined, then d(x,y)
d1(x)+d2(x,y), otherwise d(x,y) is not defined. (Thus d(x,y) is := d1(x)+d2(x,y); otherwise, d(x,y) is not defined. (Thus, d(x,y)
defined if y is in N2(x), or equivalently if x is in N1(y).) is defined if y is in N2(x) or, equivalently, if x is in N1(y).)
o For any subset S of N1, and for each y in N2, the metric d(y,S) is o For any subset S of N1 and for each y in N2, the metric d(y,S) is
the minimum value of d1(y), if defined, and of all d(x,y) for x in the minimum value of d1(y), if defined, and of all d(x,y) for x in
N1(y) and in S. If there are no such metrics to take the minimum N1(y) and in S. If there are no such metrics to take the minimum
value of, then d(y,S) is undefined (may be considered to be value of, then d(y,S) is undefined (may be considered to be
infinite). From the final property above, d(y,N1) is defined for infinite). From the final property above, d(y,N1) is defined for
all y. all y.
18.3. MPR Properties 18.3. MPR Properties
Given a Neighbor Graph as defined in Section 18.2, an MPR Set for Given a Neighbor Graph as defined in Section 18.2, an MPR Set for
that Neighbor Graph is a subset M of the set N1 that satisfies the that Neighbor Graph is a subset M of the set N1 that satisfies the
following properties: following properties:
o If x in N1 has W(x) = WILL_ALWAYS then x is in M. o If x in N1 has W(x) = WILL_ALWAYS, then x is in M.
o For any y in N2 that does not have a defined d1(y), there is at o For any y in N2 that does not have a defined d1(y), there is at
least one element in M that is also in N1(y). This is equivalent least one element in M that is also in N1(y). This is equivalent
to the requirement that d(y,M) is defined. to the requirement that d(y,M) is defined.
o For any y in N2, d(y,M) = d(y,N1). o For any y in N2, d(y,M) = d(y,N1).
These two properties correspond first to that the MPR Set consists of These properties reflect that the MPR Set consists of a set of
a set of symmetric 1-hop neighbors that cover all the symmetric 2-hop symmetric 1-hop neighbors that cover all the symmetric 2-hop
neighbors, and second that they do so retaining a minimum distance neighbors and that they do so retaining a minimum distance route
route (1-hop, if present, or 2-hop) to each symmetric 2-hop neighbor. (1-hop, if present, or 2-hop) to each symmetric 2-hop neighbor.
Note that if M is an MPR Set, then so is any subset of N1 that Note that if M is an MPR Set, then so is any subset of N1 that
contains M, and also that N1 is always an MPR Set. An MPR Set may be contains M; also note that N1 is always an MPR Set. An MPR Set may
empty, but cannot be empty if N2 contains any elements y that do not be empty but cannot be empty if N2 contains any elements y that do
have a defined d1(y). not have a defined d1(y).
18.4. Flooding MPRs 18.4. Flooding MPRs
Whenever flooding MPRs are to be calculated, an implementation MUST Whenever flooding MPRs are to be calculated, an implementation MUST
determine and record a set of flooding MPRs that is equivalent to one determine and record a set of flooding MPRs that is equivalent to one
calculated as described in this section. calculated as described in this section.
The calculation of flooding MPRs need not use link metrics, or The calculation of flooding MPRs need not use link metrics or,
equivalently may use link metrics with a fixed value, here taken to equivalently, may use link metrics with a fixed value, here taken to
be 1. However, links with unknown metric (L_out_metric = be 1. However, links with unknown metric (L_out_metric =
UNKNOWN_METRIC) MUST NOT be used even if link metrics are otherwise UNKNOWN_METRIC) MUST NOT be used even if link metrics are otherwise
not used. not used.
Routers MAY make individual decisions as to whether to use link Routers MAY make individual decisions as to whether to use link
metrics for the calculation of flooding MPRs. A router MUST use the metrics for the calculation of flooding MPRs. A router MUST use the
same approach to the choice of whether to use link metrics for all same approach to the choice of whether to use link metrics for all
links, i.e., in the cases indicated by A or B, the same choice MUST links, i.e., in the cases indicated by A or B, the same choice MUST
be made in each case. be made in each case.
For each OLSRv2 interface (the "current interface") define a Neighbor For each OLSRv2 interface (the "current interface"), define a
Graph as defined in Section 18.2 according to the following: Neighbor Graph as defined in Section 18.2 according to the following:
o Define a reachable Link Tuple to be a Link Tuple in the Link Set o Define a reachable Link Tuple to be a Link Tuple in the Link Set
for the current interface with L_status = SYMMETRIC and for the current interface with L_status = SYMMETRIC and
L_out_metric != UNKNOWN_METRIC. L_out_metric != UNKNOWN_METRIC.
o Define an allowed Link Tuple to be a reachable Link Tuple whose o Define an allowed Link Tuple to be a reachable Link Tuple whose
corresponding Neighbor Tuple has N_will_flooding > WILL_NEVER. corresponding Neighbor Tuple has N_will_flooding > WILL_NEVER.
o Define an allowed 2-Hop Tuple to be a 2-Hop Tuple in the 2-Hop Set o Define an allowed 2-Hop Tuple to be a 2-Hop Tuple in the 2-Hop Set
for the current interface for which N2_out_metric != for the current interface for which N2_out_metric !=
skipping to change at page 74, line 27 skipping to change at page 75, line 20
o Define an element of N1 for each allowed Link Tuple. This then o Define an element of N1 for each allowed Link Tuple. This then
defines the corresponding Link Tuple for each element of N1 and defines the corresponding Link Tuple for each element of N1 and
the corresponding Neighbor Tuple for each element of N1, being the the corresponding Neighbor Tuple for each element of N1, being the
Neighbor Tuple corresponding to that Link Tuple. Neighbor Tuple corresponding to that Link Tuple.
o For each element x in N1, define W(x) := N_will_flooding of the o For each element x in N1, define W(x) := N_will_flooding of the
corresponding Neighbor Tuple. corresponding Neighbor Tuple.
o For each element x in N1, define d1(x) as either: o For each element x in N1, define d1(x) as either:
A. L_out_metric of the corresponding Link Tuple, OR; A. L_out_metric of the corresponding Link Tuple; OR
B. 1. B. 1.
o Define an element of N2 for each network address that is the o Define an element of N2 for each network address that is the
N2_2hop_addr of one or more allowed 2-Hop Tuples. This then N2_2hop_addr of one or more allowed 2-Hop Tuples. This then
defines the corresponding address for each element of N2. defines the corresponding address for each element of N2.
o For each element y in N2, if the corresponding address is in the o For each element y in N2, if the corresponding address is in the
N_neighbor_addr_list of a Neighbor Tuple that corresponds to one N_neighbor_addr_list of a Neighbor Tuple that corresponds to one
or more reachable Link Tuples, then define d1(y) as either: or more reachable Link Tuples, then define d1(y) as either:
A. the minimum value of the L_out_metric of those Link Tuples, A. the minimum value of the L_out_metric of those Link Tuples; OR
OR;
B. 1. B. 1.
Otherwise d1(y) is not defined. In the latter case, where d1(y) Otherwise, d1(y) is not defined. In the latter case, where d1(y)
:= 1, all such y in N2 may instead be removed from N2. := 1, all such y in N2 may instead be removed from N2.
o For each element x in N1, define N2(x) as the set of elements y in o For each element x in N1, define N2(x) as the set of elements y in
N2 whose corresponding address is the N2_2hop_addr of an allowed N2 whose corresponding address is the N2_2hop_addr of an allowed
2-Hop Tuple that has N2_neighbor_iface_addr_list = 2-Hop Tuple that has N2_neighbor_iface_addr_list =
L_neighbor_iface_addr_list of the Link Tuple corresponding to x. L_neighbor_iface_addr_list of the Link Tuple corresponding to x.
For all such x and y, define d2(x,y) as either: For all such x and y, define d2(x,y) as either:
A. N2_out_metric of that 2-Hop Tuple, OR; A. N2_out_metric of that 2-Hop Tuple; OR
B. 1. B. 1.
It is up to an implementation to decide how to label each element of It is up to an implementation to decide how to label each element of
N1 or N2. For example an element of N1 may be labeled with one or N1 or N2. For example, an element of N1 may be labeled with one or
more addresses from the corresponding L_neighbor_iface_addr_list, or more addresses from the corresponding L_neighbor_iface_addr_list or
with a pointer or reference to the corresponding Link Tuple. with a pointer or reference to the corresponding Link Tuple.
Using these Neighbor Graphs, flooding MPRs are selected and recorded Using these Neighbor Graphs, flooding MPRs are selected and recorded
by: by:
o For each OLSRv2 interface, determine an MPR Set as specified in o For each OLSRv2 interface, determine an MPR Set as specified in
Section 18.3. Section 18.3.
o A Neighbor Tuple represents a flooding MPR and has N_flooding_mpr o A Neighbor Tuple represents a flooding MPR and has N_flooding_mpr
:= true (otherwise N_flooding_mpr := false) if and only if that := true (otherwise, N_flooding_mpr := false) if and only if that
Neighbor Tuple corresponds to an element in an MPR Set created for Neighbor Tuple corresponds to an element in an MPR Set created for
any interface as described above. That is, the overall set of any interface as described above. That is, the overall set of
flooding MPRs is the union of the sets of flooding MPRs for all flooding MPRs is the union of the sets of flooding MPRs for all
OLSRv2 interfaces. OLSRv2 interfaces.
A router MAY select its flooding MPRs for each OLSRv2 interface A router MAY select its flooding MPRs for each OLSRv2 interface
independently, or it MAY coordinate its MPR selections across its independently, or it MAY coordinate its MPR selections across its
OLSRv2 interfaces, as long as the required condition is satisfied for OLSRv2 interfaces, as long as the required condition is satisfied for
each OLSRv2 interface. One such coordinated approach is to process each OLSRv2 interface. One such coordinated approach is to process
the OLSRv2 interfaces sequentially, and for each OLSRv2 interface the OLSRv2 interfaces sequentially and, for each OLSRv2 interface,
start with flooding MPRs selected (and not removable) if the neighbor start with flooding MPRs selected (and not removable) if the neighbor
has been already selected as an MPR for an OLSRv2 interface that has has been already selected as an MPR for an OLSRv2 interface that has
already been processed. The algorithm specified in Appendix B can be already been processed. The algorithm specified in Appendix B can be
used in this way. used in this way.
18.5. Routing MPRs 18.5. Routing MPRs
Whenever routing MPRs are to be calculated, an implementation MUST Whenever routing MPRs are to be calculated, an implementation MUST
determine and record a set of routing MPRs that is equivalent to one determine and record a set of routing MPRs that is equivalent to one
calculated as described in this section. calculated as described in this section.
skipping to change at page 76, line 26 skipping to change at page 77, line 17
o For each element x in N1, define d1(x) := N_in_metric of the o For each element x in N1, define d1(x) := N_in_metric of the
corresponding Neighbor Tuple. corresponding Neighbor Tuple.
o Define an element of N2 for each network address that is the o Define an element of N2 for each network address that is the
N2_2hop_addr of one or more allowed 2-Hop Tuples. This then N2_2hop_addr of one or more allowed 2-Hop Tuples. This then
defines the corresponding address for each element of N2. defines the corresponding address for each element of N2.
o For each element y in N2, if the corresponding address is in the o For each element y in N2, if the corresponding address is in the
N_neighbor_addr_list of a reachable Neighbor Tuple, then define N_neighbor_addr_list of a reachable Neighbor Tuple, then define
d1(y) to be the N_in_metric of that Neighbor Tuple, otherwise d1(y) to be the N_in_metric of that Neighbor Tuple; otherwise,
d1(y) is not defined. d1(y) is not defined.
o For each element x in N1, define N2(x) as the set of elements y in o For each element x in N1, define N2(x) as the set of elements y in
N2 whose corresponding address is the N2_2hop_addr of an allowed N2 whose corresponding address is the N2_2hop_addr of an allowed
2-Hop Tuple that has N2_neighbor_iface_addr_list contained in 2-Hop Tuple that has N2_neighbor_iface_addr_list contained in
N_neighbor_addr_list of the Neighbor Tuple corresponding to x. N_neighbor_addr_list of the Neighbor Tuple corresponding to x.
For all such x and y, define d2(x,y) := N2_out_metric of that For all such x and y, define d2(x,y) := N2_out_metric of that
2-Hop Tuple. 2-Hop Tuple.
It is up to an implementation to decide how to label each element of It is up to an implementation to decide how to label each element of
N1 or N2. For example an element of N1 may be labeled with one or N1 or N2. For example, an element of N1 may be labeled with one or
more addresses from the corresponding N_neighbor_addr_list, or with a more addresses from the corresponding N_neighbor_addr_list or with a
pointer or reference to the corresponding Neighbor Tuple. pointer or reference to the corresponding Neighbor Tuple.
Using these Neighbor Graphs, routing MPRs are selected and recorded Using these Neighbor Graphs, routing MPRs are selected and recorded
according to the following: according to the following:
o Determine an MPR Set as specified in Section 18.3. o Determine an MPR Set as specified in Section 18.3.
o A Neighbor Tuple represents a routing MPR and has N_routing_mpr := o A Neighbor Tuple represents a routing MPR and has N_routing_mpr :=
true (otherwise N_routing_mpr := false) if and only if that true (otherwise, N_routing_mpr := false) if and only if that
Neighbor Tuple corresponds to an element in the MPR Set created as Neighbor Tuple corresponds to an element in the MPR Set created as
described above. described above.
18.6. Calculating MPRs 18.6. Calculating MPRs
A router MUST recalculate each of its sets of MPRs whenever the A router MUST recalculate each of its sets of MPRs whenever the
currently selected set of MPRs does not still satisfy the required currently selected set of MPRs does not still satisfy the required
conditions. It MAY recalculate its MPRs if the current set of MPRs conditions. It MAY recalculate its MPRs if the current set of MPRs
is still valid, but could be more efficient. Sufficient conditions is still valid but could be more efficient. Sufficient conditions to
to recalculate a router's sets of MPRs are given in Section 17.6. recalculate a router's sets of MPRs are given in Section 17.6.
19. Routing Set Calculation 19. Routing Set Calculation
The Routing Set of a router is populated with Routing Tuples that The Routing Set of a router is populated with Routing Tuples that
represent paths from that router to all destinations in the network. represent paths from that router 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 Bases, obtained is constructed from information in the Information Bases, obtained
via HELLO and TC message exchange. via HELLO and TC message exchange.
Changes to the Routing Set do not require any messages to be Changes to the Routing Set do not require any messages to be
transmitted. The state of the Routing Set SHOULD, however, 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
that routing table as appropriate. Only appropriate Routing Tuples that routing table as appropriate. Only appropriate Routing Tuples
(in particular only those that represent local links or paths to (in particular only those that represent local links or paths to
routable addresses) need be reflected in the IP routing table. routable addresses) need be reflected in the IP routing table.
19.1. Network Topology Graph 19.1. Network Topology Graph
The Network Topology Graph is formed from information from the The Network Topology Graph is formed from information from the
router's Local Interface Set, Link Sets for OLSRv2 interfaces, router's Local Interface Set, Link Sets for OLSRv2 interfaces,
Neighbor Set, Router Topology Set, Routable Address Topology Set and Neighbor Set, Router Topology Set, Routable Address Topology Set, and
Attached Network Set. The Network Topology Graph MAY also use Attached Network Set. The Network Topology Graph MAY also use
information from the router's 2-Hop Sets for OLSRv2 interfaces. The information from the router's 2-Hop Sets for OLSRv2 interfaces. The
Network Topology Graph forms the router's topological view of the Network Topology Graph forms the router's topological view of the
network in form of a directed graph. Each edge in that graph has a network in the form of a directed graph. Each edge in that graph has
metric value. The Network Topology Graph has a "backbone" (within a metric value. The Network Topology Graph has a "backbone" (within
which minimum total metric routes will be constructed) containing the which minimum total metric routes will be constructed) containing the
following edges: following edges:
o Edges X -> Y for all possible Y, and one X per Y, such that: o Edges X -> Y for all possible Y, and one X per Y, such that:
* Y is the N_orig_addr of a Neighbor Tuple; AND * Y is the N_orig_addr of a Neighbor Tuple; AND
* N_orig_addr is not unknown; * N_orig_addr is not unknown; AND
* X is in the I_local_iface_addr_list of a Local Interface Tuple; * X is in the I_local_iface_addr_list of a Local Interface Tuple;
AND AND
* There is a Link Tuple with L_status = SYMMETRIC and * There is a Link Tuple with L_status = SYMMETRIC and
L_out_metric != UNKNOWN_METRIC such that this Neighbor Tuple L_out_metric != UNKNOWN_METRIC such that this Neighbor Tuple
and this Local Interface Tuple correspond to it. A network and this Local Interface Tuple correspond to it. A network
address from L_neighbor_iface_addr_list will be denoted R in address from L_neighbor_iface_addr_list will be denoted R in
this case. this case.
It SHOULD be preferred, where possible, to select R = S and X from It SHOULD be preferred, where possible, to select R = Y and to
the Local Interface Tuple corresponding to the Link Tuple from select X from the Local Interface Tuple corresponding to the Link
which R was selected. The metric for such an edge is the Tuple from which R was selected. The metric for such an edge is
corresponding N_out_metric. the corresponding N_out_metric.
o All edges W -> U such that: o All edges W -> U such that:
* W is the TR_from_orig_addr of a Router Topology Tuple; AND * W is the TR_from_orig_addr of a Router Topology Tuple; AND
* U is the TR_to_orig_addr of the same Router Topology Tuple. * U is the TR_to_orig_addr of the same Router Topology Tuple.
The metric of such an edge is the corresponding TR_metric. The metric of such an edge is the corresponding TR_metric.
The Network Topology Graph is further "decorated" with the following The Network Topology Graph is further "decorated" with the following
edges. If a network address S, V, Z or T equals a network address Y edges. If a network address S, V, Z, or T equals a network address Y
or W, then the edge terminating in the network address S, V, Z or T or W, then the edge terminating in the network address S, V, Z, or T
MUST NOT be used in any path. MUST NOT be used in any path.
o Edges X -> S for all possible S, and one X per S, such that: o Edges X -> S for all possible S, and one X per S, such that:
* S is in the N_neighbor_addr_list of a Neighbor Tuple; AND * S is in the N_neighbor_addr_list of a Neighbor Tuple; AND
* X is in the I_local_iface_addr_list of a Local Interface Tuple; * X is in the I_local_iface_addr_list of a Local Interface Tuple;
AND AND
* There is a Link Tuple with L_status = SYMMETRIC and * There is a Link Tuple with L_status = SYMMETRIC and
L_out_metric != UNKNOWN_METRIC such that this Neighbor Tuple L_out_metric != UNKNOWN_METRIC such that this Neighbor Tuple
and this Local Interface Tuple correspond to it. A network and this Local Interface Tuple correspond to it. A network
address from L_neighbor_iface_addr_list will be denoted R in address from L_neighbor_iface_addr_list will be denoted R in
this case. this case.
It SHOULD be preferred, where possible, to select R = S and X from It SHOULD be preferred, where possible, to select R = S and to
the Local Interface Tuple corresponding to the Link Tuple from select X from the Local Interface Tuple corresponding to the Link
which R was selected. The metric for such an edge is the Tuple from which R was selected. The metric for such an edge is
corresponding N_out_metric. the corresponding N_out_metric.
o All edges W -> V such that: o All edges W -> V such that:
* W is the TA_from_orig_addr of a Routable Address Topology * W is the TA_from_orig_addr of a Routable Address Topology
Tuple; AND Tuple; AND
* V is the TA_dest_addr of the same Routable Address Topology * V is the TA_dest_addr of the same Routable Address Topology
Tuple. Tuple.
The metric for such an edge is the corresponding TA_metric. The metric for such an edge is the corresponding TA_metric.
skipping to change at page 79, line 26 skipping to change at page 80, line 18
Tuple with N2_out_metric != UNKNOWN_METRIC; AND Tuple with N2_out_metric != UNKNOWN_METRIC; AND
* Y is the N_orig_addr of the corresponding Neighbor Tuple; AND * Y is the N_orig_addr of the corresponding Neighbor Tuple; AND
* This Neighbor Tuple has N_will_routing not equal to WILL_NEVER. * This Neighbor Tuple has N_will_routing not equal to WILL_NEVER.
A path terminating with such an edge MUST NOT be used in A path terminating with such an edge MUST NOT be used in
preference to any other path. The metric for such an edge is the preference to any other path. The metric for such an edge is the
corresponding N2_out_metric. corresponding N2_out_metric.
Any part of the Topology Graph which is not connected to a local Any part of the Topology Graph that is not connected to a local
network address X is not used. Only one selection X SHOULD be made network address X is not used. Only one selection X SHOULD be made
from each I_local_iface_addr_list, and only one selection R SHOULD be from each I_local_iface_addr_list, and only one selection R SHOULD be
made from any L_neighbor_iface_addr_list. All edges have a hop count made from any L_neighbor_iface_addr_list. All edges have a hop count
of 1, except edges W -> T that have a hop count of the corresponding of 1, except edges W -> T that have a hop count of the corresponding
value of AN_dist. value of AN_dist.
19.2. Populating the Routing Set 19.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.
skipping to change at page 80, line 10 skipping to change at page 81, line 4
Each path will correspond to a Routing Tuple. These will be of two Each path will correspond to a Routing Tuple. These will be of two
types. The first type will represent single edge paths, of type X -> types. The first type will represent single edge paths, of type X ->
S or X -> Y, by: S or X -> Y, by:
o R_local_iface_addr := X; o R_local_iface_addr := X;
o R_next_iface_addr := R; o R_next_iface_addr := R;
o R_dest_addr := S or Y; o R_dest_addr := S or Y;
o R_dist := 1; o R_dist := 1;
o R_metric := edge metric, o R_metric := edge metric,
where R is as defined in Section 19.1 for these types of edges. where R is as defined in Section 19.1 for these types of edge.
The second type will represent a multiple edge path, which will The second type will represent a multiple edge path, which will
always have first edge of type X -> Y, and will have final edge of always have first edge of type X -> Y, and will have final edge of
type W -> U, W -> V, W -> T or Y -> Z. The Routing Tuple will be: type W -> U, W -> V, W -> T, or Y -> Z. The Routing Tuple will be:
o R_local_iface_addr := X; o R_local_iface_addr := X;
o R_next_iface_addr := Y; o R_next_iface_addr := Y;
o R_dest_addr := U, V, T or Z; o R_dest_addr := U, V, T or Z;
o R_dist := the total hop count of all edges in the path; o R_dist := the total hop count of all edges in the path;
o R_metric := the total metric of all edges in the path. o R_metric := the total metric of all edges in the path.
Finally, Routing Tuples of the second type whose R_dest_addr is not Finally, Routing Tuples of the second type whose R_dest_addr is not
routable MAY be discarded. routable MAY be discarded.
An example algorithm for calculating the Routing Set of a router is An example algorithm for calculating the Routing Set of a router is
given in Appendix C. given in Appendix C.
20. Proposed Values for Parameters 20. Proposed Values for Parameters
This protocol uses all parameters defined in [RFC6130] and additional This protocol uses all parameters defined in [RFC6130] and additional
parameters and defined in this specification. All but one parameters defined in this specification. All but one (RX_HOLD_TIME)
(RX_HOLD_TIME) of these additional parameters are router parameters of these additional parameters are router parameters as defined in
as defined in [RFC6130]. The proposed values of the additional [RFC6130]. The proposed values of the additional parameters defined
parameters defined in the following sections are appropriate to the in the following sections are appropriate to the case where all
case where all parameters (including those defined in [RFC6130]) have parameters (including those defined in [RFC6130]) have a single
a single value. Proposed values for parameters defined in [RFC6130] value. Proposed values for parameters defined in [RFC6130] are given
are given in that specification. in that specification.
The following proposed values are based on experience with [RFC3626] The following proposed values are based on experience with [RFC3626]
deployments (such as documented in [McCabe]), and are considered deployments (such as documented in [McCabe]) and are considered
typical. They can be changed to accommodate different deployment typical. They can be changed to accommodate different deployment
requirements - for example, a network with capacity-limited network requirements -- for example, a network with capacity-limited network
interfaces would be expected to use greater values for message interfaces would be expected to use greater values for message
intervals, whereas a highly mobile network would be expected to use intervals, whereas a highly mobile network would be expected to use
lower values for message intervals. When determining these values, lower values for message intervals. When determining these values,
the constraints specified in Section 5 MUST be respected. the constraints specified in Section 5 MUST be respected.
Note that routers in a MANET need not all use the same set of Note that routers in a MANET need not all use the same set of
parameters, and those parameters that are indicated as interface parameters, and those parameters that are indicated as interface
parameters need not be the same on all OLSRv2 interfaces of a single parameters need not be the same on all OLSRv2 interfaces of a single
router. router.
skipping to change at page 82, line 5 skipping to change at page 82, line 46
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
20.6. Hop Limit Parameter 20.6. Hop Limit Parameter
o TC_HOP_LIMIT := 255 o TC_HOP_LIMIT := 255
20.7. Willingness Parameter 20.7. Willingness Parameters
o WILL_FLOODING := WILL_DEFAULT o WILL_FLOODING := WILL_DEFAULT
o WILL_ROUTING := WILL_DEFAULT o WILL_ROUTING := WILL_DEFAULT
21. Sequence Numbers 21. Sequence Numbers
Sequence numbers are used in this specification for the purpose of Sequence numbers are used in this specification for the purpose of
discarding "old" information, i.e., messages received out of order. discarding "old" information, i.e., messages received out of order.
However with a limited number of bits for representing sequence However, with a limited number of bits for representing sequence
numbers, wrap-around (that the sequence number is incremented from numbers, wraparound (in which the sequence number is incremented from
the maximum possible value to zero) will occur. To prevent this from the maximum possible value to zero) will occur. To prevent this from
interfering with the operation of this protocol, the following MUST interfering with the operation of this protocol, the following MUST
be observed when determining the ordering of sequence numbers. be observed when 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
largest possible value for a sequence number. For a 16 bit sequence largest possible value for a sequence number. For a 16-bit sequence
number (as are those defined in this specification) MAXVALUE is number (like those defined in this specification), MAXVALUE is 65536.
65536.
The sequence number S1 is said to be "greater than" the sequence The sequence number S1 is said to be "greater than" the sequence
number S2 if: number S2 if:
o S1 > S2 AND S1 - S2 < MAXVALUE/2 OR o S1 > S2 AND S1 - S2 < MAXVALUE/2, OR
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 wraparound -- to determine which message contains the
most recent information. most recent information.
22. Extensions 22. Extensions
An extension to this protocol will need to interact with this An extension to this protocol will need to interact with this
specification, and possibly also with [RFC6130]. This protocol is specification and possibly also with [RFC6130]. This protocol is
designed to permit such interactions, in particular: designed to permit such interactions, in particular:
o Through accessing, and possibly extending, the information in the o Through accessing, and possibly extending, the information in the
Information Bases. All updates to the elements specified in this Information Bases. All updates to the elements specified in this
specification are subject to the normative constraints specified specification are subject to the normative constraints specified
in [RFC6130] and Appendix A. Note that the processing specified in [RFC6130] and Appendix A. Note that the processing specified
in this document ensures that these constraints are satisfied. in this document ensures that these constraints are satisfied.
o Through accessing an outgoing message prior to it being o Through accessing an outgoing message prior to it being
transmitted over any OLSRv2 interface, and to add information to transmitted over any OLSRv2 interface and adding information to it
it as specified in [RFC5444]. This MAY include Message TLVs as specified in [RFC5444]. This MAY include Message TLVs and/or
and/or network addresses with associated Address Block TLVs. network addresses with associated Address Block TLVs. (Network
(Network addresses without new associated TLVs SHOULD NOT be added addresses without new associated TLVs SHOULD NOT be added to
to messages.) This may, for example, be to allow a security messages.) This may, for example, be to allow a security
protocol, as suggested in Section 23, to add a TLV containing a protocol, as suggested in Section 23, to add a TLV containing a
cryptographic signature to the message. cryptographic signature to the message.
o Through accessing an incoming message, and potentially discarding o Through accessing an incoming message and potentially discarding
it prior to processing by this protocol. This may, for example, it prior to processing by this protocol. This may, for example,
allow a security protocol, as suggested in Section 23, to perform allow a security protocol, as suggested in Section 23, to perform
verification of message signatures and prevent processing and/or verification of message signatures and prevent processing and/or
forwarding of unverifiable messages by this protocol. forwarding of unverifiable messages by this protocol.
o Through accessing an incoming message after it has been completely o Through accessing an incoming message after it has been completely
processed by this protocol. In particular, this may allow a processed by this protocol. In particular, this may allow a
protocol which has added information, by way of inclusion of protocol that has added information, by way of inclusion of
appropriate TLVs, or of network addresses associated with new appropriate TLVs or of network addresses associated with new TLVs,
TLVs, access to such information after appropriate updates have access to such information after appropriate updates have been
been recorded in the Information Bases in this protocol. recorded in the Information Bases in this protocol.
o Through requesting that a message be generated at a specific time. o Through requesting that a message be generated at a specific time.
In that case, message generation MUST still respect the In that case, message generation MUST still respect the
constraints in [RFC6130] and Section 5.4.3. constraints in [RFC6130] and Section 5.4.3.
23. Security Considerations 23. Security Considerations
As a proactive routing protocol, OLSRv2 is a potential target for As a proactive routing protocol, OLSRv2 is a potential target for
various attacks. This section presents the envisioned security various attacks. This section presents the envisioned security
architecture for OLSRv2, and gives guidelines on how to provide architecture for OLSRv2 and gives guidelines on how to provide
integrity, confidentiality, and integration into external routing integrity, confidentiality, and integration into external routing
domains. Separately specified mandatory security mechanisms are domains. Separately specified mandatory security mechanisms are
summarised, and some observations on key management are given. summarized, and some observations on key management are given.
23.1. Security Architecture 23.1. Security Architecture
OLSRv2 integrates into the architecture specified in Appendix A of OLSRv2 integrates into the architecture specified in Appendix A of
[RFC5444], in [RFC5498], and in Section 16 of [RFC6130], the latter [RFC5444], in [RFC5498], and in Section 16 of [RFC6130], the latter
by using and extending its messages and Information Bases. by using and extending its messages and Information Bases.
As part of this architecture, OLSRv2, and [RFC6130], recognize that As part of this architecture, OLSRv2 and NHDP [RFC6130] recognize
there may be external reasons for rejecting messages that would be that there may be external reasons for rejecting messages that would
considered "badly formed" or "insecure", e.g., if an Integrity Check be considered "badly formed" or "insecure", e.g., if an Integrity
Value (ICV) included in a message by an external mechanism cannot be Check Value (ICV) included in a message by an external mechanism
verified. This architecture allows options as to whether and how to cannot be verified. This architecture allows options as to whether
implement security features, reflecting the situation that MANET and how to implement security features, reflecting the situation that
routing protocol deployment domains have varying security MANET routing protocol deployment domains have varying security
requirements, ranging from "practically unbreakable" to "virtually requirements, ranging from "practically unbreakable" to "virtually
none". This approach allows MANET routing protocol specifications to none". This approach allows MANET routing protocol specifications to
remain generic, with extensions to them, and/or extensions to the remain generic, with extensions to them and/or extensions to the
multiplexing and demultiplexing process described in Appendix A of multiplexing and demultiplexing process described in Appendix A of
[RFC5444], providing security mechanisms appropriate to a given [RFC5444], providing security mechanisms appropriate to a given
deployment domain. deployment domain.
The following sections provide guidelines how to provide integrity, The following sections provide guidelines on how to provide
confidentiality, and integration with external routing domains in integrity, confidentiality, and integration with external routing
such extensions. domains in such extensions.
23.2. Integrity 23.2. Integrity
Each router injects topological information into the network by Each router injects topological information into the network by
transmitting HELLO messages and, for some routers, also TC messages. transmitting HELLO messages and, for some routers, also TC messages.
If some routers for some reason, malice or malfunction, inject If some routers for some reason (malice or malfunction) inject
invalid control traffic, network integrity may be compromised. invalid control traffic, network integrity may be compromised.
Therefore, message, or packet, authentication is strongly advised. Therefore, message, or packet, authentication is strongly advised.
Different such situations may occur, for example: Different such situations may occur, for example:
1. A router generates TC messages, advertising links to non-neighbor 1. A router generates TC messages, advertising links to non-neighbor
routers; routers;
2. A router generates TC messages, pretending to be another router; 2. A router generates TC messages, pretending to be another router;
skipping to change at page 84, line 42 skipping to change at page 85, line 39
4. A router generates HELLO messages, pretending to be another 4. A router generates HELLO messages, pretending to be another
router; router;
5. A router forwards altered control messages; 5. A router forwards altered control messages;
6. A router does not forward control messages; 6. A router does not forward control messages;
7. A router does not select multipoint relays correctly; 7. A router does not select multipoint relays correctly;
8. A router forwards broadcast control messages unaltered, but does 8. A router forwards broadcast control messages unaltered but does
not forward unicast data traffic; not forward unicast data traffic;
9. A router "replays" previously recorded control traffic from 9. A router "replays" previously recorded control traffic from
another router. another router.
Authentication of the originator router for control messages (for Authentication of the originator router for control messages (for
situations 2, 4 and 5), and of the individual links announced in the situations 2, 4, and 5) and of the individual links announced in the
control messages (for situations 1 and 3), may be used as a control messages (for situations 1 and 3) may be used as a
countermeasure. However to prevent routers from repeating old (and countermeasure. However, to prevent routers from repeating old (and
correctly authenticated) information (situation 9) additional correctly authenticated) information (situation 9), additional
information is required (e.g., a timestamp or sequence number), information is required (e.g., a timestamp or sequence number),
allowing a router to positively identify such replayed messages. allowing a router to positively identify such replayed messages.
In general, ICVs (e.g., digital signatures) and other required In general, ICVs (e.g., digital signatures) and other required
security information can be transmitted within the HELLO and TC security information can be transmitted within the HELLO and TC
messages, or within a packet header, using the TLV mechanism. Either messages or within a packet header using the TLV mechanism. Either
option permits different levels of protection to coexist in the same option permits different levels of protection to coexist in the same
network, if desired. network, if desired.
An important consideration is that all control messages (HELLO An important consideration is that all control messages (HELLO
messages and TC messages) are transmitted to all routers in the 1-hop messages and TC messages) are transmitted to all routers in the 1-hop
neighborhood and some control messages (TC messages) are flooded to neighborhood and some control messages (TC messages) are flooded to
all routers in the network. This is done in a packet that is all routers in the network. This is done in a packet that is
transmitted to all routers in the 1-hop neighborhood, the current set transmitted to all routers in the 1-hop neighborhood, the current set
of which may not be known. Thus, a control message, or packet, used of which may not be known. Thus, a control message or packet used by
by this protocol is always contained in a transmission destined for this protocol is always contained in a transmission destined for
multiple destinations, and it is important that the authentication multiple destinations, and it is important that the authentication
mechanism employed permits any receiving router to validate the mechanism employed permits any receiving router to validate the
authenticity of a message or packet. authenticity of a message or packet.
[RFC6622bis] specifies a common exchange format for cryptographic [RFC7182] specifies a common exchange format for cryptographic
information in the form of Packet TLVs, Message TLVs, and Address information in the form of Packet TLVs, Message TLVs, and Address
Block TLVs, as specified in [RFC5444]. These may be used (and Block TLVs, as specified in [RFC5444]. These may be used (and
shared) among MANET routing protocol security extensions. In shared) among MANET routing protocol security extensions. In
particular, [RFC6622bis] specifies the format of TLVs for containing particular, [RFC7182] specifies the format of TLVs for containing
Integrity Check Values (ICVs), i.e., signatures, for providing Integrity Check Values (ICVs), i.e., signatures, for providing
integrity, as well as TLVs for containing temporal information for integrity, as well as TLVs for containing temporal information for
preventing replay attacks. [RFC6622bis] specifies registries for preventing replay attacks. [RFC7182] specifies registries for using
using different ciphers and formats of temporal information. When different ciphers and formats of temporal information. When using
using ICV TLVs in an OLSRv2 deployment, failure to verify an ICV ICV TLVs in an OLSRv2 deployment, failure to verify an included ICV
included mandates to reject an incoming message or packet as mandates rejection of an incoming message or packet as "invalid",
"invalid", according to Section 12.1 of [RFC6130], and according to according to Section 12.1 of [RFC6130] and according to
Section 16.3.1 of this specification, when using the multiplexing and Section 16.3.1 of this specification when using the multiplexing and
demultiplexing process described in Appendix A of [RFC5444]. demultiplexing process described in Appendix A of [RFC5444].
[RFC6622bis] specifies how to insert IVCs into generated messages, [RFC7182] specifies how to insert ICVs into generated messages, how
how to verify incoming messages, and to reject "insecure" messages to verify incoming messages, and to reject "insecure" messages (i.e.,
(i.e., messages without an ICV or with an ICV that cannot be messages without an ICV or with an ICV that cannot be verified).
verified). Different MANET deployments may, as a result of the Different MANET deployments may, as a result of the purpose for which
purpose for which they are used and the possibility and nature of they are used and the possibility and nature of their configuration,
their configuration, require different ICV algorithms and timestamps, require different ICV algorithms and timestamps or multiple keys, and
or multiple keys, and thus a security extension may use any of the thus, a security extension may use any of the different options
different options provided in [RFC6622bis]. provided in [RFC7182].
23.3. Confidentiality 23.3. Confidentiality
OLSRv2 periodically MPR floods topological information to all routers OLSRv2 periodically MPR floods topological information to all routers
in the network. Hence, if used in an unprotected network, in in the network. Hence, if used in an unprotected network, in
particular an unprotected wireless network, the network topology is particular, an unprotected wireless network, the network topology is
revealed to anyone who successfully listens to the control messages. revealed to anyone who successfully listens to the control messages.
This information may serve an attacker to acquire details about the This information may serve an attacker to acquire details about the
topology, and therefore to initiate more effective attacks against topology and therefore to initiate more effective attacks against
routers in the routing domain e.g., by spoofing addresses of routers routers in the routing domain, e.g., by spoofing addresses of routers
in the network and attracting traffic for these addresses. Note that in the network and attracting traffic for these addresses. Note that
this is independent of the data traffic, and purely protects the this is independent of the data traffic and purely protects the
control traffic, i.e., information about the network topology. control traffic, i.e., information about the network topology.
In situations where the confidentiality of the network topology is of In situations where the confidentiality of the network topology is of
importance, regular cryptographic techniques, such as use of OLSRv2 importance, regular cryptographic techniques, such as use of OLSRv2
multicast control packets encrypted using IPsec (e.g., with a shared multicast control packets encrypted using IPsec (e.g., with a shared
secret key), can be applied to ensure that control traffic can be secret key), can be applied to ensure that control traffic can be
read and interpreted by only those authorized to do so. read and interpreted by only those authorized to do so.
Alternatively, a security extension may specify a mechanism to Alternatively, a security extension may specify a mechanism to
provide confidentiality for control messages and/or packets. provide confidentiality for control messages and/or packets.
However, unless the information about the network topology itself is However, unless the information about the network topology itself is
confidential, integrity of control messages (as specified in confidential, integrity of control messages (as specified in
Section 23.2) is sufficient to admit only trusted routers (i.e. Section 23.2) is sufficient to admit only trusted routers (i.e.,
routers with valid credentials) to the network. routers with valid credentials) to the network.
23.4. Interaction with External Routing Domains 23.4. Interaction with External Routing Domains
This protocol provides a basic mechanism for injecting external This protocol provides a basic mechanism for injecting external
routing information into this protocol's routing domain. Routing routing information into this protocol's routing domain. Routing
information can also be extracted from this protocol's Information information can also be extracted from this protocol's Information
Bases, in particular the Routing Set, and injected into an external Bases, in particular the Routing Set, and injected into an external
routing domain, if the routing protocol governing that routing domain routing domain, if the routing protocol governing that routing domain
permits this. permits this.
skipping to change at page 86, line 51 skipping to change at page 87, line 43
allow potentially insecure and untrustworthy information to be allow potentially insecure and untrustworthy information to be
injected from this routing domain to an external routing domain. injected from this routing domain to an external routing domain.
Care MUST also be taken to validate the correctness of information Care MUST also be taken to validate the correctness of information
prior to it being injected, so as to avoid polluting routing tables prior to it being injected, so as to avoid polluting routing tables
with invalid information. with invalid information.
A recommended way of extending connectivity from an external routing A recommended way of extending connectivity from an external routing
domain to this routing domain, which is routed using this protocol, domain to this routing domain, which is routed using this protocol,
is to assign an IP prefix (under the authority of the routers/ is to assign an IP prefix (under the authority of the routers/
gateways connecting this routing domain with the external routing gateways connecting this routing domain with the external routing
domain) exclusively to this routing domain, and to configure the domain) exclusively to this routing domain and to configure the
gateways to advertise routes for that IP prefix into the external gateways to advertise routes for that IP prefix into the external
routing domain. routing domain.
23.5. Mandatory Security Mechanisms 23.5. Mandatory Security Mechanisms
A conformant implementation of OLSRv2 MUST, at minimum, implement the A conformant implementation of OLSRv2 MUST, at minimum, implement the
security mechanisms specified in [OLSRv2-integrity], providing security mechanisms specified in [RFC7183], providing integrity and
integrity and replay protection of OLSRv2 control messages, including replay protection of OLSRv2 control messages, including of HELLO
of HELLO messages specified by [RFC6130] and used by OLSRv2, by messages specified by [RFC6130] and used by OLSRv2, by inclusion of a
inclusion of a timestamp TLV and an Integrity Check Value (ICV) TLV. timestamp TLV and an Integrity Check Value (ICV) TLV. This ICV TLV
This ICV TLV uses a SHA-256 based HMAC and one or more manually uses a SHA-256-based HMAC and one or more manually managed shared
managed shared secret keys. The timestamp TLV is based on POSIX secret keys. The timestamp TLV is based on Portable Operating System
time, assuming router time synchronization. Interface (POSIX) time, assuming router time synchronization.
The baseline use case, for which this security mechanism provides The baseline use case, for which this security mechanism provides
adequate integrity protection without rekeying, is for short-lived adequate integrity protection without rekeying, is for short-lived
(for example up to a couple of months) OLSRv2 deployments. (for example, up to a couple of months) OLSRv2 deployments.
Any deployment of OLSRv2 SHOULD use the security mechanism specified Any deployment of OLSRv2 SHOULD use the security mechanism specified
in [OLSRv2-integrity], but MAY use another mechanism if more in [RFC7183] but MAY use another mechanism if more appropriate in an
appropriate in an OLSRv2 deployment. For example, for longer-term OLSRv2 deployment. For example, for longer-term OLSRv2 deployments,
OLSRv2 deployments, alternative security mechanisms (e.g., re-keying) alternative security mechanisms (e.g., rekeying) SHOULD be
SHOULD be considered. considered.
23.6. Key Management 23.6. Key Management
This specification, including [OLSRv2-integrity], does not mandate This specification, as well as [RFC7183], does not mandate automated
automatic key management (AKM) as part of the security architecture key management (AKM) as part of the security architecture for OLSRv2.
for OLSRv2. While some use cases for OLSRv2 may require AKM, the While some use cases for OLSRv2 may require AKM, the baseline
baseline assumption is that many use cases do not, for the reasons assumption is that many use cases do not, for the reasons detailed
detailed below. below.
Bootstrapping a key is hard in a radio network, where it is - in Bootstrapping a key is hard in a radio network, where it is, in
general - not possible to determine from where a received signal was general, not possible to determine from where a received signal was
transmitted, or if two transmissions come from the same or from transmitted or if two transmissions come from the same or from
different sources. different sources.
A widespread use of radio networks, mobile phone networks, works The widespread use of radio networks and mobile phone networks works
under the assumptions that (i) secret information is embedded in under the assumptions that (i) secret information is embedded in
mobile phones at manufacture, and (ii) a centralized database of this mobile phones at manufacture, and (ii) a centralized database of this
is accessible during the network lifetime. is accessible during the network lifetime.
As a primary use case of a MANET is to provide connectivity without As a primary use case of a MANET is to provide connectivity without
centralized entities, and with minimal management, a solution such as centralized entities and with minimal management, a solution such as
described in the previous paragraph is not feasible. In many described in the previous paragraph is not feasible. In many
instances, a cryptographic authority may not be present in the MANET instances, a cryptographic authority may not be present in the MANET
at all, since such a cryptographic authority would be too vulnerable. at all, since such a cryptographic authority would be too vulnerable.
Due to the potentially dynamic topology of a MANET, a cryptographic Due to the potentially dynamic topology of a MANET, a cryptographic
authority may also become unreachable (to some or all of the MANET authority may also become unreachable (to some or all of the MANET
routers) without prior warning. routers) without prior warning.
[BCP107] provides guidelines for cryptographic key management. [BCP107] provides guidelines for cryptographic key management.
Specifically, Section 2.1 sets forth requirements for when AKM is Specifically, Section 2.1 sets forth requirements for when AKM is
required, and Section 2.2 sets forth conditions under which manual required, and Section 2.2 sets forth conditions under which manual
key management is acceptable. key management is acceptable.
Section 2.1 of [BCP107] stipulates that "Automated key management Section 2.1 of [BCP107] stipulates that "Automated key management
MUST be used if any of [a set of given] conditions hold". These MUST be used if any of [a set of given] conditions hold". These
conditions are listed below, for each of which arguments are provided conditions are listed below, and arguments for each are provided in
as to their applicability for the baseline use case of OLSRv2. regard to their applicability for the baseline use case of OLSRv2.
A party will have to manage n^2 static keys, where n may become o A party will have to manage n^2 static keys, where n may become
large. large.
The baseline use case of OLSRv2 uses only one or a small set of The baseline use case of OLSRv2 uses only one or a small set of
manually managed shared secrets in the whole MANET. manually managed shared secrets in the whole MANET.
Any stream cipher (such as RC4 [TK], AES-CTR [NIST], or AES-CCM o Any stream cipher (such as RC4 [RFC6229][RC4], AES-CTR
[WHF]) is used. [RFC3610][NIST-SP-800-38A], or AES-CCM [RFC3686][NIST-SP-800-38C])
is used.
A stream cipher is not envisioned for use to generate ICVs for A stream cipher is not envisioned for use to generate ICVs for
OLSRv2 control messages. OLSRv2 control messages.
An initialization vector (IV) might be reused, especially an implicit o An initialization vector (IV) might be reused, especially an
IV. Note that random or pseudo-random explicit IVs are not a problem implicit IV. Note that random or pseudo-random explicit IVs are
unless the probability of repetition is high. not a problem unless the probability of repetition is high.
An IV is not envisioned for use to generate ICVs for OLSRv2 An IV is not envisioned for use to generate ICVs for OLSRv2
control messages. control messages.
Large amounts of data might need to be encrypted in a short time, o Large amounts of data might need to be encrypted in a short time,
causing frequent change of the short-term session key. causing frequent change of the short-term session key.
Integrity Check Values (ICVs) are required only for OLSRv2 control Integrity Check Values (ICVs) are required only for OLSRv2 control
messages, which are low-volume messages. messages, which are low-volume messages.
Long-term session keys are used by more than two parties. Multicast o Long-term session keys are used by more than two parties.
is a necessary exception, but multicast key management standards are Multicast is a necessary exception, but multicast key management
emerging in order to avoid this in the future. Sharing long-term standards are emerging in order to avoid this in the future.
session keys should generally be discouraged. Sharing long-term session keys should generally be discouraged.
OLSRv2 control messages are all sent using link local multicast. OLSRv2 control messages are all sent using link-local multicast.
The likely operational environment is one where personnel (or device) o The likely operational environment is one where personnel (or
turnover is frequent, causing frequent change of the short-term device) turnover is frequent, causing frequent change of the
session key. short-term session key.
This is not an intended deployment of OLSRv2. For longer-term This is not an intended deployment of OLSRv2. For longer-term
OLSRv2 deployments, alternative security mechanisms (e.g., OLSRv2 deployments, alternative security mechanisms (e.g.,
including re-keying) SHOULD be considered. including rekeying) SHOULD be considered.
Section 2.2 of [BCP107] stipulates that "Manual key management may be Section 2.2 of [BCP107] stipulates that "Manual key management may be
a reasonable approach in any of [a given set of] situations". These a reasonable approach in any of [a given set of] situations". These
situation are listed below, for each of which arguments are provided situations are listed below, and arguments for each are provided in
as to their applicability for the baseline use case of OLSRv2. regard to their applicability for the baseline use case of OLSRv2.
The environment has very limited available bandwidth or very high o The environment has very limited available bandwidth or very high
round-trip times. Public key systems tend to require long messages round-trip times. Public key systems tend to require long
and lots of computation; symmetric key alternatives, such as messages and lots of computation; symmetric key alternatives, such
Kerberos, often require several round trips and interaction with as Kerberos, often require several round trips and interaction
third parties. with third parties.
As previously noted, there may not be the required infrastructure As previously noted, there may not be the required infrastructure
(cryptographic authority) present (or, if present, may not be (cryptographic authority) present (or, if present, may not be
reachable) in the MANET. Bandwidth in a MANET is commonly reachable) in the MANET. Bandwidth in a MANET is commonly
limited, both by being a radio environment, and by the need for limited, both by being a radio environment and by the need for any
any signaling to consume a minimal proportion thereof, and round signaling to consume a minimal proportion thereof, and round trip
trip times may also be significant. times may also be significant.
The information being protected has low value. o The information being protected has low value.
This depends on the OLSRv2 use case, but the information being This depends on the OLSRv2 use case, but the information being
protected is OLSRv2 control traffic, which is of at least moderate protected is OLSRv2 control traffic, which is of at least moderate
value, thus this case does not apply. value; thus, this case does not apply.
The total volume of traffic over the entire lifetime of the long-term o The total volume of traffic over the entire lifetime of the long-
session key will be very low. term session key will be very low.
Integrity Check Values (ICVs) are required only for OLSRv2 control Integrity Check Values (ICVs) are required only for OLSRv2 control
messages, which are low-volume messages. messages, which are low-volume messages.
The scale of each deployment is very limited o The scale of each deployment is very limited.
A typical use case for OLSRv2 may involve only tens of devices - A typical use case for OLSRv2 may involve only tens of devices --
with even the largest use cases for OLSRv2 being small by Internet with even the largest use cases for OLSRv2 being small by Internet
standards. standards.
24. IANA Considerations 24. IANA Considerations
This specification defines one Message Type, which must be allocated This specification defines one Message Type, which has been allocated
from the "Message Types" repository of [RFC5444], two Message TLV from the "Message Types" registry of [RFC5444], two Message TLV
Types, which must be allocated from the "Message TLV Types" Types, which have been allocated from the "Message TLV Types"
repository of [RFC5444], and four Address Block TLV Types, which must registry of [RFC5444], and four Address Block TLV Types, which have
be allocated from the "Address Block TLV Types" repository of been allocated from the "Address Block TLV Types" registry of
[RFC5444]. [RFC5444].
24.1. Expert Review: Evaluation Guidelines 24.1. Expert Review: Evaluation Guidelines
For the registries where an Expert Review is required, the designated For the registries where an Expert Review is required, the designated
expert SHOULD take the same general recommendations into expert SHOULD take the same general recommendations into
consideration as are specified by [RFC5444]. consideration as are specified by [RFC5444].
24.2. Message Types 24.2. Message Types
This specification defines one Message Type, to be allocated from the This specification defines one Message Type, allocated from the 0-223
0-223 range of the "Message Types" namespace defined in [RFC5444], as range of the "Message Types" namespace defined in [RFC5444], as
specified in Table 8. specified in Table 8.
+------+----------------------------------------------+ +------+----------------------------------------------+
| Type | Description | | Type | Description |
+------+----------------------------------------------+ +------+----------------------------------------------+
| TBD1 | TC : Topology Control (MANET-wide signaling) | | 1 | TC : Topology Control (MANET-wide signaling) |
+------+----------------------------------------------+ +------+----------------------------------------------+
Table 8: Message Type assignment Table 8: Message Type Assignment
24.3. Message-Type-Specific TLV Type Registries 24.3. Message-Type-Specific TLV Type Registries
IANA is requested to create a registry for Message-Type-specific IANA has created a registry for Message-Type-specific Message TLVs
Message TLVs for TC messages, in accordance with Section 6.2.1 of for TC messages, in accordance with Section 6.2.1 of [RFC5444] and
[RFC5444], and with initial assignments and allocation policies as with initial assignments and allocation policies as specified in
specified in Table 9. Table 9.
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| Type | Description | Allocation Policy | | Type | Description | Allocation Policy |
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review | | 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+ +---------+-------------+-------------------+
Table 9: TC Message-Type-specific Message TLV Types Table 9: TC Message-Type-Specific Message TLV Types
IANA is requested to create a registry for Message-Type-specific IANA has created a registry for Message-Type-specific Address Block
Address Block TLVs for TC messages, in accordance with Section 6.2.1 TLVs for TC messages, in accordance with Section 6.2.1 of [RFC5444]
of [RFC5444], and with initial assignments and allocation policies as and with initial assignments and allocation policies as specified in
specified in Table 10. Table 10.
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| Type | Description | Allocation Policy | | Type | Description | Allocation Policy |
+---------+-------------+-------------------+ +---------+-------------+-------------------+
| 128-223 | Unassigned | Expert Review | | 128-223 | Unassigned | Expert Review |
+---------+-------------+-------------------+ +---------+-------------+-------------------+
Table 10: TC Message-Type-specific Address Block TLV Types Table 10: TC Message-Type-Specific Address Block TLV Types
24.4. Message TLV Types 24.4. Message TLV Types
This specification defines two Message TLV Types, which must be This specification defines two Message TLV Types, which have been
allocated from the "Message TLV Types" namespace defined in allocated from the "Message TLV Types" namespace defined in
[RFC5444]. IANA is requested to make allocations in the 0-127 range [RFC5444]. IANA has made allocations in the 0-127 range for these
for these types. This will create two new Type Extension registries types. Two new Type Extension registries have been created with
with assignments as specified in Table 11 and Table 12. assignments as specified in Table 11 and Table 12. Specifications of
Specifications of these TLVs are in Section 13.3.1. Each of these these TLVs are in Section 13.3.1. Each of these TLVs MUST NOT be
TLVs MUST NOT be included more than once in a Message TLV Block. included more than once in a Message TLV Block.
+-------------+------+-----------+---------------------+------------+ +-------------+------+-----------+---------------------+------------+
| Name | Type | Type | Description | Allocation | | Name | Type | Type | Description | Allocation |
| | | Extension | | Policy | | | | Extension | | Policy |
+-------------+------+-----------+---------------------+------------+ +-------------+------+-----------+---------------------+------------+
| MPR_WILLING | TBD2 | 0 | Bits 0-3 specify | | | MPR_WILLING | 7 | 0 | Bits 0-3 specify | |
| | | | the originating | | | | | | the originating | |
| | | | router's | | | | | | router's | |
| | | | willingness to act | | | | | | willingness to act | |
| | | | as a flooding MPR; | | | | | | as a flooding MPR; | |
| | | | bits 4-7 specify | | | | | | bits 4-7 specify | |
| | | | the originating | | | | | | the originating | |
| | | | router's | | | | | | router's | |
| | | | willingness to act | | | | | | willingness to act | |
| | | | as a routing MPR. | | | | | | as a routing MPR. | |
| MPR_WILLING | TBD2 | 1-255 | Unassigned. | Expert | | MPR_WILLING | 7 | 1-255 | Unassigned. | Expert |
| | | | | Review | | | | | | Review |
+-------------+------+-----------+---------------------+------------+ +-------------+------+-----------+---------------------+------------+
Table 11: Message TLV Type assignment: MPR_WILLING Table 11: Message TLV Type Assignment: MPR_WILLING
+--------------+------+-----------+--------------------+------------+ +--------------+------+-----------+--------------------+------------+
| Name | Type | Type | Description | Allocation | | Name | Type | Type | Description | Allocation |
| | | Extension | | Policy | | | | Extension | | Policy |
+--------------+------+-----------+--------------------+------------+ +--------------+------+-----------+--------------------+------------+
| CONT_SEQ_NUM | TBD3 | 0 | COMPLETE: | | | CONT_SEQ_NUM | 8 | 0 | COMPLETE: | |
| | | | Specifies a | | | | | | Specifies a | |
| | | | content sequence | | | | | | content sequence | |
| | | | number for this | | | | | | number for this | |
| | | | complete message. | | | | | | complete message. | |
| CONT_SEQ_NUM | TBD3 | 1 | INCOMPLETE: | | | CONT_SEQ_NUM | 8 | 1 | INCOMPLETE: | |
| | | | Specifies a | | | | | | Specifies a | |
| | | | content sequence | | | | | | content sequence | |
| | | | number for this | | | | | | number for this | |
| | | | incomplete | | | | | | incomplete | |
| | | | message. | | | | | | message. | |
| CONT_SEQ_NUM | TBD3 | 2-255 | Unassigned. | Expert | | CONT_SEQ_NUM | 8 | 2-255 | Unassigned. | Expert |
| | | | | Review | | | | | | Review |
+--------------+------+-----------+--------------------+------------+ +--------------+------+-----------+--------------------+------------+
Table 12: Message TLV Type assignment: CONT_SEQ_NUM Table 12: Message TLV Type Assignment: CONT_SEQ_NUM
Type extensions indicated as Expert Review SHOULD be allocated as Type extensions indicated as Expert Review SHOULD be allocated as
described in [RFC5444], based on Expert Review as defined in described in [RFC5444], based on Expert Review as defined in
[RFC5226]. [RFC5226].
24.5. Address Block TLV Types 24.5. Address Block TLV Types
This specification defines four Address Block TLV Types, which must This specification defines four Address Block TLV Types, which have
be allocated from the "Address Block TLV Types" namespace defined in been allocated from the "Address Block TLV Types" namespace defined
[RFC5444]. IANA are requested to make allocations in the 8-127 range in [RFC5444]. IANA has made allocations in the 8-127 range for these
for these types. This will create four new Type Extension registries types. Four new Type Extension registries have been created with
with assignments as specified in Table 13, Table 14, Table 15 and assignments as specified in Tables 13, 14, 15, and 16.
Table 16. Specifications of these TLVs are in Section 13.3.2. Specifications of these TLVs are in Section 13.3.2.
+-------------+------+-----------+-------------------+--------------+ The registration procedure for the "LINK_METRIC Address Block TLV
| Name | Type | Type | Description | Allocation | Type Extensions" registry is Expert Review.
| | | Extension | | Policy |
+-------------+------+-----------+-------------------+--------------+ +-------------+------+-----------+----------------------------------+
| LINK_METRIC | TBD4 | 0 | Link metric | | | Name | Type | Type | Description |
| | | | meaning assigned | | | | | Extension | |
| | | | by administrative | | +-------------+------+-----------+----------------------------------+
| | | | action. | | | LINK_METRIC | 7 | 0 | Link metric meaning assigned by |
| LINK_METRIC | TBD4 | 1-223 | Unassigned. | Expert | | | | | administrative action. |
| | | | | Review | | LINK_METRIC | 7 | 1-223 | Unassigned. |
| LINK_METRIC | TBD4 | 224-255 | Unassigned. | Experimental | | LINK_METRIC | 7 | 224-255 | Reserved for Experimental Use |
| | | | | Use | +-------------+------+-----------+----------------------------------+
+-------------+------+-----------+-------------------+--------------+
Table 13: Address Block TLV Type assignment: LINK_METRIC Table 13: Address Block TLV Type Assignment: LINK_METRIC
All LINK_METRIC TLVs, whatever their type extension, MUST use their All LINK_METRIC TLVs, whatever their type extension, MUST use their
value field to encode the kind and value (in the interval value field to encode the kind and value (in the interval
MINIMUM_METRIC, to MAXIMUM_METRIC, inclusive) of a link metric as MINIMUM_METRIC to MAXIMUM_METRIC, inclusive) of a link metric as
specified in Section 6 and Section 13.3.2. An assignment of a specified in Sections 6 and 13.3.2. An assignment of a LINK_METRIC
LINK_METRIC TLV type extension MUST specify the physical meaning, and TLV type extension MUST specify the physical meaning of the link
mapping of that physical meaning to the representable values in the metric and the mapping of that physical meaning to the representable
indicated interval, of the link metric. values in the indicated interval.
+------+------+-----------+----------------------------+------------+ +------+------+-----------+----------------------------+------------+
| Name | Type | Type | Description | Allocation | | Name | Type | Type | Description | Allocation |
| | | Extension | | Policy | | | | Extension | | Policy |
+------+------+-----------+----------------------------+------------+ +------+------+-----------+----------------------------+------------+
| MPR | TBD5 | 0 | Specifies that a given | | | MPR | 8 | 0 | Specifies that a given | |
| | | | network address is of a | | | | | | network address is of a | |
| | | | router selected as a | | | | | | router selected as a | |
| | | | flooding MPR (FLOODING = | | | | | | flooding MPR (FLOODING = | |
| | | | 1), that a given network | | | | | | 1), that a given network | |
| | | | address is of a router | | | | | | address is of a router | |
| | | | selected as a routing MPR | | | | | | selected as a routing MPR | |
| | | | (ROUTING = 2), or both | | | | | | (ROUTING = 2), or both | |
| | | | (FLOOD_ROUTE = 3). | | | | | | (FLOOD_ROUTE = 3). | |
| MPR | TBD5 | 1-255 | Unassigned. | Expert | | MPR | 8 | 1-255 | Unassigned. | Expert |
| | | | | Review | | | | | | Review |
+------+------+-----------+----------------------------+------------+ +------+------+-----------+----------------------------+------------+
Table 14: Address Block TLV Type assignment: MPR Table 14: Address Block TLV Type Assignment: MPR
+---------------+------+-----------+-------------------+------------+ +---------------+------+-----------+-------------------+------------+
| Name | Type | Type | Description | Allocation | | Name | Type | Type | Description | Allocation |
| | | Extension | | Policy | | | | Extension | | Policy |
+---------------+------+-----------+-------------------+------------+ +---------------+------+-----------+-------------------+------------+
| NBR_ADDR_TYPE | TBD6 | 0 | Specifies that a | | | NBR_ADDR_TYPE | 9 | 0 | Specifies that a | |
| | | | given network | | | | | | given network | |
| | | | address is of a | | | | | | address is of a | |
| | | | neighbor reached | | | | | | neighbor reached | |
| | | | via the | | | | | | via the | |
| | | | originating | | | | | | originating | |
| | | | router, if it is | | | | | | router, if it is | |
| | | | an originator | | | | | | an originator | |
| | | | address | | | | | | address | |
| | | | (ORIGINATOR = 1), | | | | | | (ORIGINATOR = 1), | |
| | | | is a routable | | | | | | is a routable | |
| | | | address (ROUTABLE | | | | | | address (ROUTABLE | |
| | | | = 2), or if it is | | | | | | = 2), or if it is | |
| | | | both | | | | | | both | |
| | | | (ROUTABLE_ORIG = | | | | | | (ROUTABLE_ORIG = | |
| | | | 3). | | | | | | 3). | |
| NBR_ADDR_TYPE | TBD6 | 1-255 | Unassigned. | Expert | | NBR_ADDR_TYPE | 9 | 1-255 | Unassigned. | Expert |
| | | | | Review | | | | | | Review |
+---------------+------+-----------+-------------------+------------+ +---------------+------+-----------+-------------------+------------+
Table 15: Address Block TLV Type assignment: NBR_ADDR_TYPE Table 15: Address Block TLV Type Assignment: NBR_ADDR_TYPE
+---------+------+-----------+-------------------------+------------+ +---------+------+-----------+-------------------------+------------+
| Name | Type | Type | Description | Allocation | | Name | Type | Type | Description | Allocation |
| | | extension | | Policy | | | | extension | | Policy |
+---------+------+-----------+-------------------------+------------+ +---------+------+-----------+-------------------------+------------+
| GATEWAY | TBD7 | 0 | Specifies that a given | | | GATEWAY | 10 | 0 | Specifies that a given | |
| | | | network address is | | | | | | network address is | |
| | | | reached via a gateway | | | | | | reached via a gateway | |
| | | | on the originating | | | | | | on the originating | |
| | | | router, with value | | | | | | router, with value | |
| | | | equal to the number of | | | | | | equal to the number of | |
| | | | hops. | | | | | | hops. | |
| GATEWAY | TBD7 | 1-255 | | Expert | | GATEWAY | 10 | 1-255 | | Expert |
| | | | | Review | | | | | | Review |
+---------+------+-----------+-------------------------+------------+ +---------+------+-----------+-------------------------+------------+
Table 16: Address Block TLV Type assignment: GATEWAY Table 16: Address Block TLV Type Assignment: GATEWAY
Type extensions indicated as Expert Review SHOULD be allocated as Type extensions indicated as Expert Review SHOULD be allocated as
described in [RFC5444], based on Expert Review as defined in described in [RFC5444], based on Expert Review as defined in
[RFC5226]. [RFC5226].
24.6. NBR_ADDR_TYPE and MPR Values 24.6. NBR_ADDR_TYPE and MPR Values
Note: This section does not require any IANA action, as the required Note: This section does not require any IANA action, as the required
information is included in the descriptions of the MPR and information is included in the descriptions of the MPR and
NBR_ADDR_TYPE Address Block TLVs allocated in Section 24.5. This NBR_ADDR_TYPE Address Block TLVs allocated in Section 24.5. This
information is recorded here for clarity, and for use elsewhere in information is recorded here for clarity and for use elsewhere in
this specification. this specification.
The Values which the MPR Address Block TLV can use are the following: The Values that the MPR Address Block TLV can use are as follows:
o FLOODING := 1; o FLOODING := 1;
o ROUTING := 2; o ROUTING := 2;
o FLOOD_ROUTE := 3. o FLOOD_ROUTE := 3.
The Values which the NBR_ADDR_TYPE Address Block TLV can use are the The Values that the NBR_ADDR_TYPE Address Block TLV can use are
following: follows:
o ORIGINATOR := 1; o ORIGINATOR := 1;
o ROUTABLE := 2; o ROUTABLE := 2;
o ROUTABLE_ORIG := 3. o ROUTABLE_ORIG := 3.
25. Contributors 25. 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,
skipping to change at page 96, line 14 skipping to change at page 97, line 14
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, Toyota, Japan, <ryuji@sfc.wide.ad.jp> o Ryuji Wakikawa, Toyota, Japan, <ryuji@sfc.wide.ad.jp>
26. Acknowledgments 26. Acknowledgments
The authors would like to acknowledge the team behind OLSRv1, as The authors would like to acknowledge the team behind OLSRv1, as
listed in RFC3626, including Anis Laouiti (INT), Pascale Minet listed in RFC 3626, including Anis Laouiti (INT), Pascale Minet
(INRIA), Paul Muhlethaler (INRIA), Amir Qayyum (M.A. Jinnah (INRIA), Paul Muhlethaler (INRIA), Amir Qayyum (M.A. Jinnah
University), and Laurent Viennot (INRIA) for their contributions. University), and Laurent Viennot (INRIA) 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 (listed alphabetically): Khaldoun Al specification and its components (listed alphabetically): Khaldoun Al
Agha (LRI), Teco Boot (Infinity Networks), Ross Callon (Juniper), Agha (LRI), Teco Boot (Infinity Networks), Ross Callon (Juniper),
Song-Yean Cho (Samsung), Alan Cullen (BAE Systems), Louise Lamont Song-Yean Cho (Samsung), Alan Cullen (BAE Systems), Louise Lamont
(CRC), Li Li (CRC), Joseph Macker (NRL), Richard Ogier (SRI), Charles (CRC), Li Li (CRC), Joseph Macker (NRL), Richard Ogier (SRI), Charles
E. Perkins (Futurewei), Henning Rogge (Frauenhofer FKIE), and the E. Perkins (Futurewei), Henning Rogge (Frauenhofer FKIE), and the
entire IETF MANET Working Group. entire IETF MANET Working Group.
Finally, the authors would like to express their gratitude to the Finally, the authors would like to express their gratitude to the
Area Directors for providing valuable review comments during the IESG Area Directors for providing valuable review comments during the IESG
evaluation, in particular (listed alphabetically) Benoit Claise, evaluation, in particular (listed alphabetically) Benoit Claise,
Adrian Farrel, Stephen Farrell, Barry Leiba, Pete Resnick, and Martin Adrian Farrel, Stephen Farrell, Barry Leiba, Pete Resnick, and Martin
Stiemerling. Stiemerling.
27. References 27. References
27.1. Normative References 27.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Indicate Requirement Levels", RFC 2119, BCP 14, Requirement Levels", BCP 14, RFC 2119, March 1997.
March 1997.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
"Jitter Considerations in Mobile Ad Hoc Networks Considerations in Mobile Ad Hoc Networks (MANETs)", RFC
(MANETs)", RFC 5148, February 2008. 5148, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Writing an IANA Considerations Section in RFCs", IANA Considerations Section in RFCs", BCP 26, RFC 5226,
RFC 5226, BCP 26, May 2008. May 2008.
[RFC5444] Clausen, T., Dean, J., Dearlove, C., and C. [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
Adjih, "Generalized Mobile Ad Hoc Network (MANET) "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Packet/Message Format", RFC 5444, February 2009. Format", RFC 5444, February 2009.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi- [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
Value Time in Mobile Ad Hoc Networks (MANETs)", Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March
RFC 5497, March 2009. 2009.
[RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network
Network (MANET) Protocols", RFC 5498, March 2009. (MANET) Protocols", RFC 5498, March 2009.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Ad Hoc Network (MANET) Neighborhood Discovery Network (MANET) Neighborhood Discovery Protocol (NHDP)",
Protocol (NHDP)", RFC 6130, April 2011. RFC 6130, April 2011.
[RFC6622bis] Herberg, U., Clausen, T., and C. Dearlove, [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity
"Integrity Check Value and Timestamp TLV Check Value and Timestamp TLV Definitions for Mobile Ad
Definitions for Mobile Ad Hoc Networks (MANETs)", Hoc Networks (MANETs)", RFC 7182, April 2014.
work in progress draft-ietf-manet-rfc6622-bis-01,
March 2013.
[OLSRv2-integrity] Herberg, U., Dearlove, C., and T. Clausen, [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity
"Integrity Protection for Control Messages in Protection for the Neighborhood Discovery Protocol (NHDP)
NHDP and OLSRv2", work in and Optimized Link State Routing Protocol Version 2
progress draft-ietf-manet-nhdp-olsrv2-sec-01, (OLSRv2)", RFC 7183, April 2014.
March 2013.
27.2. Informative References 27.2. Informative References
[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc [BCP107] Bellovin, S. and R. Housley, "Guidelines for
Networking (MANET): Routing Protocol Performance Cryptographic Key Management", BCP 107, RFC 4107, June
Issues and Evaluation Considerations", RFC 2501, 2005.
January 1999.
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link [FSLS] Santivanez, C., Ramanathan, R., and I. Stavrakakis,
State Routing Protocol", RFC 3626, October 2003. "Making Link-State Routing Scale for Ad Hoc Networks",
MobiHoc '01, Proceedings of the 2nd ACM International
Symposium on Mobile Ad Hoc Networking & Computing, 2001.
[HIPERLAN] ETSI, "ETSI STC-RES10 Committee. Radio equipment [FSR] Pei, G., Gerla, M., and T. Chen, "Fisheye State Routing
and systems: HIPERLAN type 1, functional in Mobile Ad Hoc Networks", ICDCS Workshop on Wireless
specifications ETS 300-652", June 1996. Networks and Mobile Computing, 2000.
[HIPERLAN2] Jacquet, P., Minet, P., Muhlethaler, P., and N. [HIPERLAN] ETSI, "Radio Equipment and Systems (RES); HIgh
Rivierre, "Increasing reliability in cable free PErformance Radio Local Area Network (HIPERLAN) Type 1;
radio LANs: Low level forwarding in HIPERLAN.", Functional Specification", ETSI 300-652, June 1996.
1996.
[MPR] Qayyum, A., Viennot, L., and A. Laouiti, [HIPERLAN2] Jacquet, P., Minet, P., Muhlethaler, P., and N. Rivierre,
"Multipoint relaying: An efficient technique for "Increasing Reliability in Cable-Free Radio LANs: Low
flooding in mobile wireless networks.", 2001. Level Forwarding in HIPERLAN", Wireless Personal
Communications, Volume 4, Issue 1, 1997.
[FSR] Pei, G., Gerla, M., and T. Chen, "Fisheye state [MPR] Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint
routing in mobile ad hoc networks", 2000. relaying: An efficient technique for flooding in mobile
wireless Networks", INRIA, No. 3898, March 2000.
[FSLS] Santivanez, C., Ramanathan, R., and I. [McCabe] McCabe, A., Dearlove, C., Fredin, M., and L. Axelsson,
Stavrakakis, "Making link-state routing scale for "Scalability modelling of ad hoc routing protocols - a
ad hoc networks", 2000. comparison of OLSR and DSR", Scandinavian Wireless Adhoc
Networks '04, 2004.
[McCabe] McCabe, A., Dearlove, C., Fredin, M., and L. [NIST-SP-800-38A]
Axelsson, "Scalability Modelling of Ad Hoc National Institute of Standards and Technology,
Routing Protocols - A Comparison of OLSR and "Recommendation for Block Cipher Modes of Operation:
DSR", 2004. Methods and Techniques", Special Publication 800-38A,
December 2001.
[BCP107] Bellovin, S. and R. Housley, "Guidelines for [NIST-SP-800-38C]
Cryptographic Key Management", BCP 107, RFC 4107, National Institute of Standards and Technology,
June 2005. "Recommendation for Block Cipher Modes of Operation: The
CCM Mode for Authentication and Confidentiality", Special
Publication 800-38C, May 2004.
[RC4] Schneier, B., "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", Second Edition, John
Wiley and Sons, New York, 1996.
[RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, September 2003.
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol (OLSR)", RFC 3626, October 2003.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004.
[RFC6229] Strombergson, J. and S. Josefsson, "Test Vectors for the
Stream Cipher RC4", RFC 6229, May 2011.
Appendix A. Constraints Appendix A. Constraints
Updates to the Local Information Base, the Neighborhood Information Updates to the Local Information Base, the Neighborhood Information
Base or the Topology Information Base MUST ensure that all Base, or the Topology Information Base MUST ensure that all
constraints specified in this appendix are maintained, as well as constraints specified in this appendix are maintained, as well as
those specified in [RFC6130]. This is the case for the processing, those specified in [RFC6130]. This is the case for the processing,
specified in this document. Any protocol extension or outside specified in this document. Any protocol extension or outside
process, which updates the Neighborhood Information Base or the process, which updates the Neighborhood Information Base or the
Topology Information Base, MUST also ensure that these constraints Topology Information Base, MUST also ensure that these constraints
are maintained. are maintained.
In each Originator Tuple: In each Originator Tuple:
o O_orig_addr MUST NOT equal any other O_orig_addr. o O_orig_addr MUST NOT equal any other O_orig_addr.
skipping to change at page 98, line 43 skipping to change at page 100, line 30
o O_orig_addr MUST NOT equal this router's originator address. o O_orig_addr MUST NOT equal this router's originator address.
In each Local Attached Network Tuple: In eac