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