RFC 7181

The Optimized Link State Routing Protocol Version 2

📅 published April 2014, from ietf

RFC 7181: The Optimized Link State Routing Protocol Version 2 ✨

okay bestie, let's start with the title block 🎀 This one's an IETF Standards Track doc (no cap, it's the real deal 👑), published in April 2014 as RFC 7181. It's giving ISSN 2070-1721 💅 and it doesn't list anything it obsoletes or updates, so it stands on its own 🦋

The authors are a squad of four: T. Clausen (LIX, Ecole Polytechnique), C. Dearlove (BAE Systems ATC), P. Jacquet (Alcatel-Lucent Bell Labs), and U. Herberg (Fujitsu Laboratories of America) 🌸 Iconic team, honestly 😭

Abstract

So here's the tea ☕ This spec describes version 2 of the Optimized Link State Routing Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs) 🧚 Basically it's the routing protocol for networks where devices are always wandering around and the links keep changing, so it has to figure out where things are going to go next. Main character energy 💜

Status of This Memo

Okay, the status bit is short and sweet 🍓 This is an Internet Standards Track document, which means the IETF community has agreed on it, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🔥

If you want more info on what "Internet Standards" even means, check out Section 2 of RFC 5741 📚 You can also see the current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc7181 🌈

Copyright Notice

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as they stood on the publication date ✨ Please actually read those, bestie, because they explain what you're allowed to do with it 🫶

Any Code Components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions 🎀 They come with no warranty, same as that license says 🌸

Some of the material here came from IETF Documents or IETF Contributions published before November 10, 2008 🦋 The people who hold the copyright on some of that older stuff might not have given the IETF Trust permission to let it be modified outside the IETF Standards Process 🙈 So unless you get a proper license from them, you can't modify this doc outside the IETF Standards Process, and you can't make derivative works outside it either 💅 The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍

Table of Contents ✨

okay bestie, this is the map of the whole spec 🗺️ every section and appendix is listed here, so you can see exactly where each part lives 💅

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
           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

   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
   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

ngl this is a LOT of sections 😭 but the numbering is the roadmap, so the names and numbers stay exactly as the spec has them 🫶

1. Introduction ✨

okay so OLSRv2 (Optimized Link State Routing Protocol version 2) is the successor to OLSR version 1, which is published in [RFC3626]. 💖 Compared to [RFC3626], OLSRv2 keeps the same basic mechanisms and algorithms, but it can use a link metric other than hop count when picking shortest routes. It also has a more flexible and efficient signaling framework and simplifies some of the messages being exchanged. 🎀

OLSRv2 is made for Mobile Ad Hoc Networks (MANETs) 🌸. It's a table-driven, proactive protocol, which just means it swaps topology info with the other routers in the network on a regular schedule. It's an optimization of the classic link state routing protocol, and its key concept is multipoint relays (MPRs) 👑. Each router picks two sets of MPRs. Each set is a group of its neighbor routers that "cover" all of its symmetrically connected 2-hop neighbor routers. These two sets are "flooding MPRs" and "routing MPRs", and they're used for flooding reduction and topology reduction, respectively. 🦋

Flooding reduction works by flooding control traffic through the network with hop-by-hop forwarding. The catch is that a router only needs to forward control traffic that it first received directly from one of the routers that selected it as a flooding MPR (its "flooding MPR selectors") 💅. This is called "MPR flooding", and it's an efficient way to spread information around the MANET because it cuts down on the number of transmissions required [MPR]. iconic, honestly. ✨

Topology reduction is achieved by giving a special job to routers that were selected as routing MPRs when they declare link state information. OLSRv2 is guaranteed to provide shortest routes to all destinations if routers declare link state information for their routing MPR selectors, if any. 🧚 Routers that aren't 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. 🌈

So MPRs cut down on the number and size of link state messages, and they also reduce how much link state information each router has to keep track of. 🫶 When it's possible (especially if you're using a hop count metric), the same routers can be picked as both flooding MPRs and routing MPRs. main character energy 👑

A router picks both routing and flooding MPRs from among its one-hop neighbors connected by "symmetric", i.e., bidirectional, links. That means selecting routes through routing MPRs avoids the problems that come with data packet transfer over unidirectional links 🙈. For example, you don't get link-layer acknowledgments at each hop, for link layers that use this technique. ngl that's a big deal. 💀

OLSRv2 uses and extends the MANET Neighborhood Discovery Protocol (NHDP) defined in [RFC6130]. It also uses the Generalized MANET Packet/Message Format [RFC5444], the TLVs specified in [RFC5497] and, optionally, message jitter as specified in [RFC5148]. 🍓 All four of these other protocols and specifications were originally created as part of OLSRv2, but they've been specified separately so more people can use them. ✨

OLSRv2 doesn't make any assumptions about the underlying link layer 🌸. Through its use of [RFC6130], OLSRv2 may use link-layer information and notifications when they're available and applicable. On top of that, OLSRv2 uses link metrics that may be derived from link layer information or any other information. OLSRv2 doesn't specify the physical meaning of link metrics, but it does specify a way that new types of link metrics can be defined in the future and then used by OLSRv2 without any modification. 🔥

Like OLSR [RFC3626], OLSRv2 inherits its concept of forwarding and relaying from the High Performance Radio Local Area Network (HIPERLAN), a MAC-layer protocol standardized by ETSI [HIPERLAN] [HIPERLAN2] 🧚. This document does not obsolete [RFC3626], which is left in place for further experimentation. 💜

2. Terminology

okay this section is the vocab list, so let's get the definitions straight 🎀. 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] are to be interpreted as described there. That includes "packet", "Packet Header", "message", "Message Header", "Message Body", "Message Type", "message sequence number", "hop limit", "hop count", "Address Block", "TLV Block", "TLV", "Message TLV", "Address Block TLV", "type" (of TLV), "type extension" (of TLV), "value" (of TLV), "address", "address prefix", and "address object". 🦋

All terms introduced in [RFC6130] are to be interpreted as described there too. That includes "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". 🌈

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 tell a routable address apart from a non-routable address by directly inspecting the network address. This is based on global-scope address allocations by IANA and/or administrative configuration, and it has to be consistent 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. For example, if the originator address is an IPv6 address, it MUST have either no prefix length or a prefix length of 128. 💀

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, there's an exceptional case, which doesn't add a <msg-orig-addr> element to a HELLO message. A router that only has a single address may use that case. 🧚

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's indicated to participate in the flooding process of messages received from router Y. Or it may be a routing MPR for Y if it's 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. 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]. 💜

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. This protocol: 🎀

Is designed to work in networks with a dynamic topology, and in networks where messages may be lost, such as due to collisions over wireless media. 💖
Supports routers that each have one or more participating OLSRv2 interfaces. These 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. 🌈
Enables hop-by-hop routing, i.e., each router can use its local information provided by this protocol to route packets. 🧚
Continuously maintains routes to all destinations in the network. Routes are instantly available, and data traffic is subject to no delays due to route discovery. Consequently, no data traffic buffering is required. ✨
Supports routers that have non-OLSRv2 interfaces, which may be local to a router or may serve as gateways towards other networks. 🫶
Enables the use of bidirectional additive link metrics to use shortest distance routes (i.e., routes with the smallest total of link metrics). Incoming link metric values are to be determined by a process outside this specification. 🍓
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]. 👑
Uses [RFC5444] as described in its "Intended Usage" appendix and by [RFC5498]. 💅
Allows "external" and "internal" extensibility (adding new Message Types and adding information to existing messages) as enabled by [RFC5444]. 🦋
Is designed to work in a completely distributed manner and does not depend on any central entity. 🌸

4. Protocol Overview and Functioning ✨

The objectives of this protocol are for each router to: 💖

Identify all destinations in the network. 🎀
Identify a sufficient subset of links in the network, in order that shortest routes can be calculated to all available destinations. 🦋
Provide a Routing Set containing these shortest routes from this router to all destinations (routable addresses and local links). 👑

4.1. Overview ✨

okay so here's how each router pulls this off, bestie 💅

Using NHDP [RFC6130] to find symmetric 1-hop neighbors and symmetric 2-hop neighbors. 👀
Telling everyone it's in OLSRv2 🎀 and how willing it is to be a flooding MPR and a routing MPR, by extending the HELLO messages from [RFC6130] with an MPR_WILLING Message TLV. The "flooding willingness" is how eager it is to join MPR flooding, and the "routing willingness" is how eager it is to be an intermediate router for routing. Even if a router is unwilling to do either, it can still be a routing source or destination. Main character energy 🦋
Extending HELLO messages from [RFC6130] so links to other OLSRv2 routers can carry directional link metrics, and so routers can say which link metric type they're using. Incoming and outgoing link metrics can both be reported, and the incoming one is decided by the advertising router. 🌸
Picking flooding MPRs and routing MPRs from its willing symmetric 1-hop neighbors. For each set of MPRs, every symmetric 2-hop neighbor has to be reachable, either directly or through at least one selected MPR, along a path with an appropriate minimum total metric for routing MPR selection (at least). MPR selection algorithms are analysed with examples in [MPR], and a suggested algorithm, adapted for each set of MPRs, lives in Appendix B of this spec. Routers don't need the same algorithm to interoperate in the same MANET, but every algorithm must have the properties in Section 18. 🧚
Signalling its flooding MPR and routing MPR selections by extending HELLO messages from [RFC6130], using MPR Address Block TLV(s) tied to the right network addresses. 📣
Pulling out its flooding MPR selectors and routing MPR selectors from received HELLO messages, using those MPR Address Block TLV(s). 🔍
Defining a TC (Topology Control) Message Type in the format from [RFC5444]. TC messages periodically announce links between routing MPR selectors and the router itself across the whole MANET, including suitable directional neighbor metrics (the best link metric in that direction between those routers). 💖
Letting TC messages and HELLO messages sit inside packets from [RFC5444], using the "manet" IP protocol or UDP port from [RFC5498]. 🫶
Spreading TC messages with a flooding reduction mechanism called "MPR flooding". Only a router's flooding MPRs retransmit messages received from (meaning originated by or last relayed by) that router. Less noise, more slay ✨

Heads up: the extensions to [RFC6130] are all in forms that spec already permits. 💅

This specification defines:

The requirement to use [RFC6130], along with its parameters, constants, HELLO messages, and Information Bases, each as extended here. 📚
Two new Information Bases: the Topology Information Base and the Received Message Information Base. 🎀
TC messages, used for MANET-wide signalling of selected topology (link state) information with MPR flooding. 🌈
A requirement that every router has an originator address that is included in, or can be deduced from, HELLO messages and TC messages. 🔑
New Message TLVs and Address Block TLVs used in HELLO messages and TC messages. They cover reporting neighbor status, MPR selection, external gateways, link metrics, willingness to be an MPR, and content sequence numbers. Heads up, though: generating incoming link metric values is handled by a process outside this spec. This spec only deals with distributing and using those metrics. 🍓
Generating TC messages from the right information in the Information Bases. 🧁
Updating the Topology Information Base based on received TC messages. 💜
The MPR flooding mechanism, including the message originator address and sequence number that manage duplicate messages, using information recorded in the Received Message Information Base. 🦋
How the protocol responds to other events, like information in the Information Bases expiring. ⭐

This protocol inherits the stability of a link state algorithm, and because it's proactive, routes are immediately available when needed. Iconic behaviour 👑

This protocol only interacts with IP through routing table management and by using the sending IP address of IP datagrams that carry messages used by this specification. 🌸

4.2. Routers and Interfaces ✨

Okay so for a router to join a MANET using this protocol, it must have at least one OLSRv2 interface, and it might have more. Each OLSRv2 interface:

Is a MANET interface, as described in [RFC6130]. Specifically, it must be configured with one or more network addresses. Those addresses must each be specific to this router, and they must include any address that will be used as the sending address of any IP packet sent on this OLSRv2 interface. 🎀
Has a set of interface parameters, added to the ones from [RFC6130]. 💅
Has an Interface Information Base, extending the one from [RFC6130]. 📚
Generates and processes HELLO messages according to [RFC6130], extended as Section 15 specifies. 🫶

On top of that set of OLSRv2 interfaces, each router:

May have one or more non-OLSRv2 interfaces (these can include MANET interfaces and/or non-MANET interfaces) and/or local attached networks where it can accept IP packets. Every routable address the router is supposed to accept IP packets for must be used as an interface network address (OLSRv2 or non-OLSRv2) or as an address of a local attached network of the router. 🧚
Has a set of router parameters, added to the ones from [RFC6130]. 🍓
Has a Local Information Base, extending the one from [RFC6130]. This covers choosing an originator address and recording any locally attached networks. 🔍
Has a Neighbor Information Base, extending the one from [RFC6130] to record MPR selection and advertisement information. 💖
Has a Topology Information Base, recording information received in TC messages. 🌈
Has a Received Message Information Base, recording information about received messages. This makes sure each TC message is only processed once, and forwarded at most once on each OLSRv2 interface, by a router. 🔑
Generates, receives, and processes TC messages. ⭐

4.3. Information Base Overview ✨

Each router keeps the Information Bases described in the next sections. They're used to describe the protocol in this specification. An implementation can store this information in the indicated form, or in any other organisation that gives access to it. Heads up: it isn't necessary to remove Tuples from Sets at the exact time indicated. It only has to behave as though the Tuples were removed at that time. 🦋

4.3.1. Local Information Base 🎀

The Local Information Base is specified in [RFC6130] and holds a router's local configuration. This spec extends it to also record an originator address, and to include a router's:

Originator Set, which holds addresses that were recently used as this router's originator address. Together with the router's current originator address, it lets a router recognise and discard control traffic that it originated itself. 🌸
Local Attached Network Set, which holds network addresses of networks this router can act as a gateway to. It advertises these in its TC messages. 🧁

4.3.2. Interface Information Base 💜

The Interface Information Base for each OLSRv2 interface is as specified in [RFC6130]. This spec extends it so each Link Set also records 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]. This spec extends it so each neighbor's Neighbor Tuple also records:

Its originator address. 🔑
Neighbor metric values. These are the minimum of the link metric values in the indicated direction across all symmetric 1-hop links with that neighbor. 🍓
Its willingness to be a flooding MPR and to be a routing MPR. 💖
Whether this router has selected it 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.) 🫶
Whether it is to be advertised in TC messages sent by this router. 🧚

4.3.4. Topology Information Base 🗺️

okay so the Topology Information Base is basically the router's tea board 🍵 and it holds:

An Advertising Remote Router Set, which records each remote router that has sent TC messages. This is how a router figures out if a TC message is fresh or outdated, and an outdated one gets ignored 💀
A Router Topology Set, which records links between routers in the MANET, as described by received TC messages 🔗
A Routable Address Topology Set, which records routable addresses in the MANET (the ones you can use as IP packet destinations) and which remote router each one can be directly reached through (that's a single IP hop from that router), as reported by received TC messages 📍
An Attached Network Set, which records networks that a remote router has advertised it may act as a gateway for. These networks might be one or more IP hops away from that router 🌐
A Routing Set, which records routes from this router to all available destinations. The IP routing table gets updated using this Routing Set ✨ (A router can choose to use any or all of the destination network addresses in the Routing Set to update the IP routing table. That selection is outside the scope of this specification, so it's up to the implementer 🫶)

The whole point of the Topology Information Base is to store the info that, together with the Local Information Base, the Interface Information Bases, and the Neighbor Information Base, gets used to build the Routing Set (which also lives in the Topology Information Base 💅).

This specification works out the Routing Set from a Topology Graph that gets built in two phases. First, there's a "backbone" graph that shows the routers in the MANET and how they're connected to each other. It's built from the Local Information Base, the Neighbor Information Base, and the Router Topology Set. Second, that graph gets "decorated" with extra destination network addresses, using the Local Information Base, the Routable Address Topology Set, and the Attached Network Set 🎀

The Topology Graph doesn't have to be stored in the Topology Information Base. You can either build it whenever the Routing Set needs to change, or skip building it explicitly altogether (there's an example of that in Appendix C 🧚). An implementation is still allowed to build and keep the Topology Graph if it prefers that, though 💖

4.3.5. Received Message Information Base 📬

okay the Received Message Information Base in each router holds:

A Received Set for each OLSRv2 interface, describing the TC messages this router received on that OLSRv2 interface
A Processed Set, describing the TC messages this router processed
A Forwarded Set, describing the TC messages this router forwarded

This is what keeps the MPR flooding mechanism on track 🦋 It makes sure received messages get forwarded at most once by a router, and that they get processed exactly once by a router. The Received Message Information Base can also record info about other Message Types that use the MPR flooding mechanism 🌸

4.4. Signaling Overview 📢

This protocol creates and processes HELLO messages according to [RFC6130]. HELLO messages sent on OLSRv2 interfaces get extended under Section 15 of this specification so they include an originator address, link metrics, and MPR selection information 💜

This specification defines just one Message Type, which is the TC message. TC messages get sent by their originating router proactively, at a regular interval, on all OLSRv2 interfaces ⏰ That interval can be fixed or dynamic. For example, it might get backed off because of congestion or network stability 😮‍💨 TC messages can also be sent in response to a change in the router itself, or in its advertised symmetric 1-hop neighborhood, like when it first gets selected as a routing MPR 🔥

Because TC messages are sent periodically, this protocol is tolerant of unreliable transmissions. Messages can get lost more often in wireless networks because of collisions or other transmission problems 📡 This protocol may use "jitter", which means randomized adjustments to message transmission times, to cut down on collisions, as specified in [RFC5148] 🎲

This protocol is also tolerant of out-of-sequence delivery of TC messages, which can happen when messages get reordered in transit 🔀 Each router keeps an Advertised Neighbor Sequence Number (ANSN) that gets incremented whenever its recorded neighbor information that goes into its TC messages changes. The ANSN is included in the router's TC messages. The recipient of a TC message can use that ANSN to figure out which information it has is the most recent, even if messages got reordered on the way. Only the most recent information is used, and older information that shows up later gets thrown out 🗑️

TC messages can be "complete" or "incomplete". A complete TC message advertises all of the originating router's routing MPR selectors, and it may also advertise other symmetric 1-hop neighbors 👑 Complete TC messages are generated periodically (and also, optionally, in response to changes in the symmetric 1-hop neighborhood). Incomplete TC messages can be used to report additions to the advertised info without repeating stuff that hasn't changed 🙈

TC messages, and HELLO messages as extended by this specification, define an originator address for the router that created the message. They do this either by including it or by deducing it when there's only a single address 🪪 A TC message reports both the originator addresses and the routable addresses of its advertised neighbors, and it tells the two apart with an Address Block TLV. (An address can be both routable and an originator address, btw 🫧) TC messages also report the originator's locally attached networks 🏠

TC messages get MPR flooded throughout the MANET. A router retransmits a TC message it received on an OLSRv2 interface if and only if all of these are true: the message didn't originate at this router, the router hasn't forwarded it before, this is the first time the message has been received on this OLSRv2 interface, and the message was received from (meaning it originated from or was last relayed by) one of this router's flooding MPR selectors 🚀

Some TC messages may only get MPR flooded over part of the network. That lets a router keep nearer routers more up to date than distant ones, which is what Fisheye State Routing [FSR] and Fuzzy Sighted Link State routing [FSLS] do. This is enabled using [RFC5497] 🐠

TC messages include outgoing neighbor metrics that get used when routes are selected 📊

4.5. Link Metrics 📏

OLSRv1 [RFC3626] created minimum hop routes to destinations. But in lots of situations (honestly, most of them 😤), you can make better routes, in terms of quality of service for end users, by using link metrics ✨

OLSRv2, the way this specification defines it, supports metric-based routing. That means each link can have a chosen metric 💅 Link metrics in OLSRv2 are additive, and the routes that get created are the ones with the minimum sum of link metrics along that route 🏆

Link metrics are directional, so the link metric from one router to another can be different from the one on the reverse link ↔️ The link metric gets assessed at the receiver, like on a (typically) wireless link, because the receiver is the one that knows the most about that link 🧠 OLSRv2 uses both incoming and outgoing link info, so you have to keep the distinctions in this specification crystal clear 💜

This specification also defines both incoming and outgoing neighbor metrics for each symmetric 1-hop neighbor. Each one is the minimum value of the link metrics in the same direction across all symmetric links with that neighbor. So every neighbor metric value is also a link metric value, and when you specify something like link metric value encoding, that encoding also covers neighbor metric values 🫶

This specification doesn't define what the link metric actually is. What it does allow is, through the type extension of a defined Address Block TLV, link metrics with specific meanings. Those can be allocated by IANA or used privately 🎀 Each HELLO or TC message that carries link (or neighbor) metrics says which link metric info it's carrying, so routers can tell if they can interoperate 🤝 If link metrics need extra signaling to get their values, whether in HELLO messages or somewhere else, that's allowed, but it's outside the scope of this specification 🙅‍♀️

Be careful about how you use link metrics. In particular, it's a good idea to not just default to using all links with equal metrics (aka hop count) for routing without thinking about whether that's actually appropriate 🤔

4.6. Flooding MPRs and Routing MPR 🌊

This specification uses two sets of MPRs: flooding MPRs and routing MPRs. They get selected separately, because:

Flooding MPRs may use metrics, but routing MPRs must use metrics 📏
When flooding MPRs use metrics, those are outgoing link metrics. Routing MPRs use incoming neighbor metrics 📥
Flooding MPRs must be selected per OLSRv2 interface, but routing MPRs don't need to be selected per OLSRv2 interface 🧩

4.7. Routing Set Use 🛣️

The Routing Set exists to determine and record routes (local interface network address and next-hop interface network address) to every possible routable address advertised by this protocol. It also covers all destinations that are local to the router, meaning within one hop, whether they use routable addresses or not 🏡 Only symmetric links get used in these routes 💖

The Routing Set is meant to be used for IP packet routing, by using its contents to update the IP routing table. That update, and whether any Routing Tuples are left out when the IP routing table gets updated, is outside the scope of this specification 🤷‍♀️

This signaling was designed so that a "backbone" Topology Graph of routers can be built. Each router is identified by its originator address, and there's at most one direct connection between any pair of routers. It's built from the Neighbor Set and the Router Topology Set using a suitable minimum path length algorithm 🧮 Other network addresses (routable ones or ones of symmetric 1-hop neighbors) can then be added to that graph, using the Interface Information Bases, the Routable Address Topology Set, and the Attached Network Set 🌈

5. Protocol Parameters and Constants ✨

The parameters and constants in this specification are the ones defined in [RFC6130], plus the ones in this section. The split in [RFC6130] into interface parameters, router parameters, and constants is also used here 🎀

Just like the parameters in [RFC6130], parameters defined in this specification MAY be changed dynamically by a router. They don't need to 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 🎀

okay so this protocol sends TC messages, and they get tucked inside packets the way [RFC5444] defines 💌 These packets MUST be sent using either the "manet" protocol number or the "manet" UDP well-known port number, as specified in [RFC5498].

TC messages and HELLO messages [RFC6130] MUST, in a given MANET, either both use IP or both use UDP. The reason is so that messages from both protocols can be combined into the same [RFC5444] packet for transmission 🧦✨

5.2. Multicast Address 🦋

TC messages get 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 🌸

only one extra interface parameter is specified, and it's only for OLSRv2 interfaces 🙈

5.3.1. Received Message Validity Time 💜

this parameter handles how long we keep track of messages we've already received 🕰️

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 constraints for this one are:

RX_HOLD_TIME > 0
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 👑

these are the router parameters, and they're specified for routers 💅

5.4.1. Local History Times ⏳

this router parameter controls how long local information sticks around 🧸

O_HOLD_TIME: The time for which a recently used and replaced originator address is used to recognize the router's own messages.

the constraint here is:

O_HOLD_TIME > 0

5.4.2. Link Metric Parameters 📏

all routes found using this spec use a single link metric type, which is set by the router parameter LINK_METRIC_TYPE. It can be any value from 0 to 255, both inclusive 🔢

5.4.3. Message Intervals ⏰

okay this one is so good 😭 These parameters control when a router sends TC messages. TC messages are usually sent periodically, but they 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, 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. BUT a router has no knowledge of, for example, routers remote to it (i.e., beyond two hops away) joining the network, so 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 constraints for these are:

TC_INTERVAL > 0
0 <= TC_MIN_INTERVAL <= TC_INTERVAL
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 📣

these parameters manage how long the info we advertise in TC messages stays valid 🗓️

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 constraints here are:

T_HOLD_TIME > 0
A_HOLD_TIME >= 0
T_HOLD_TIME >= TC_INTERVAL
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. 🙌
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 🔁

these parameters manage the validity time of recorded message info for processing and forwarding 🧠

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.

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 constraints are:

P_HOLD_TIME > 0
F_HOLD_TIME > 0
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 these are the governing jitter parameters:

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. but here's the catch 👀 each other router, at any hop count distance, MUST see a regular pattern of TC messages, so 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]. So the pattern of TC_HOP_LIMIT MUST be 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 constraints for this parameter:

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.
All values of TC_HOP_LIMIT >= 2.

5.4.8. Willingness 🙋‍♀️

each router has two willingness parameters: WILL_FLOODING and WILL_ROUTING, and each of them MUST be in the range WILL_NEVER to WILL_ALWAYS, inclusive 🌈

WILL_FLOODING is the router's willingness to be selected as a flooding MPR, and so to take part in MPR flooding, especially of TC messages.

WILL_ROUTING is the router's willingness to be selected as a routing MPR, and so to be an intermediate router on routes.

either way, the higher the value, the more willing the router is 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. Heads up ⚠️ a MANET using this protocol with too many routers having either WILL_FLOODING or WILL_ROUTING equal to WILL_NEVER will not function, so it MUST be ensured, by administrative or other means, that this does not happen.

Note that the proportion at which routers with a willingness value equal to WILL_NEVER count as "too many" depends on the network topology, which in a MANET may change dynamically 🔄 Willingness is meant to let certain routers (e.g., routers with generous resources, like a permanent power supply) take on more of the network operation, while others (e.g., routers with fewer resources, like battery-operated ones) can avoid such tasks 🔋 A general guideline: 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 where all routers have WILL_FLOODING = WILL_ALWAYS, flooding reduction will effectively be disabled, and flooding will perform as blind flooding 🌊

In a MANET where 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 constraints for these parameters:

WILL_NEVER <= WILL_FLOODING <= WILL_ALWAYS
WILL_NEVER <= WILL_ROUTING <= WILL_ALWAYS

5.5. Parameter Change Constraints

okay bestie, this is the part where we talk about what happens when you turn the knobs mid-run 🎛️✨ if protocol parameters get changed dynamically, these constraints kick in, so pay attention 💅

RX_HOLD_TIME

If RX_HOLD_TIME for an OLSRv2 interface changes, the expiry time for all Received Tuples for that OLSRv2 interface MAY be changed.

O_HOLD_TIME

If O_HOLD_TIME changes, the expiry time for all Originator Tuples MAY be changed.

TC_INTERVAL

If TC_INTERVAL increases, 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, 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, the expiry time for all Processed Tuples MAY be changed.

F_HOLD_TIME

If F_HOLD_TIME changes, the expiry time for all Forwarded Tuples MAY be changed.

TP_MAXJITTER

If TP_MAXJITTER changes, the periodic TC message schedule on this router MAY be changed immediately.

TT_MAXJITTER

If TT_MAXJITTER changes, externally triggered TC messages on this router MAY be rescheduled.

F_MAXJITTER

If F_MAXJITTER changes, 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.

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:

MINIMUM_METRIC := 1
MAXIMUM_METRIC := 16776960

The symbolic value UNKNOWN_METRIC is defined in Section 6.1.

5.6.2. Willingness Constants

The constant minimum, RECOMMENDED default, and maximum willingness values are defined by:

WILL_NEVER := 0
WILL_DEFAULT := 7
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:

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.)

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:

Find the smallest integer b such that v + 256 <= 2^(b + 9).
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:

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.
The addition of an Originator Set, defined in Section 7.1, and a Local Attached Network Set, defined in Section 7.2.

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.

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.

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:

L_in_metric := UNKNOWN_METRIC;
L_out_metric := UNKNOWN_METRIC;
L_mpr_selector := false.

8.2. 2-Hop Set 🦋

okay so the 2-Hop Set gets upgraded bestie 💅 every 2-Hop Tuple picks up two new fields:

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 that gets created (but not updated) by [RFC6130] MUST set these:

N2_in_metric := UNKNOWN_METRIC;
N2_out_metric := UNKNOWN_METRIC.

9. Neighbor Information Base 🎀

every router keeps a Neighbor Information Base, as defined in [RFC6130] 🧚 this protocol adds more stuff to each Neighbor Tuple in the Neighbor Set. sometimes it's easier to think of these Sets as also holding these extra bits for other MANET interfaces, which get the listed values when they're created and never get updated after that 🫶

N_orig_addr is the neighbor's originator address, which might be unknown. heads up that this originator address does not include a prefix length 🙈
N_in_metric is the neighbor metric of any link from this neighbor to an OLSRv2 interface of this router. that's the minimum of all the matching L_in_metric values where L_status = SYMMETRIC and L_in_metric != UNKNOWN_METRIC, and it's 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. same energy: the minimum of all the matching L_out_metric values where L_status = SYMMETRIC and L_out_metric != UNKNOWN_METRIC, and UNKNOWN_METRIC if there are no such Link Tuples 💀
N_will_flooding is the neighbor's willingness to be picked as a flooding MPR, anywhere from WILL_NEVER to WILL_ALWAYS (both included). it's WILL_NEVER if no OLSRv2-specific info has come in from this neighbor 🍓
N_will_routing is the neighbor's willingness to be picked as a routing MPR, anywhere from WILL_NEVER to WILL_ALWAYS (both included). also WILL_NEVER if no OLSRv2-specific info has come in from this neighbor 🌈
N_flooding_mpr is a boolean flag saying whether this router has picked this neighbor as a flooding MPR 👑
N_routing_mpr is a boolean flag saying whether this router has picked this neighbor as a routing MPR 💜
N_mpr_selector is a boolean flag saying whether this neighbor has picked this router as a routing MPR. in other words, it's a routing MPR selector of this router 🦋
N_advertised is a boolean flag saying whether this router has decided to advertise a link to this neighbor in its TC messages ⭐

a Neighbor Tuple that gets created (but not updated) by [RFC6130] MUST set:

N_orig_addr := unknown;
N_in_metric := UNKNOWN_METRIC;
N_out_metric := UNKNOWN_METRIC;
N_will_flooding := WILL_NEVER;
N_will_routing := WILL_NEVER;
N_routing_mpr := false;
N_flooding_mpr := false;
N_mpr_selector := false;
N_advertised := false.

the Neighbor Information Base also has a variable called the Advertised Neighbor Sequence Number (ANSN) ✨ its value goes into TC messages so everyone can tell how fresh the info is 🕰️ the ANSN goes up whenever the advertised info changes (that's the originator and routable addresses in Neighbor Tuples with N_advertised = true, plus the local attached networks recorded in the Local Attached Network Set in the Local Information Base). adding or removing any of that counts as a change too 🔥

10. Topology Information Base 🌸

the Topology Information Base is defined for each router by this spec, and it stores info received in TC messages in the Advertising Remote Router Set, the Router Topology Set, the Routable Address Topology Set, and the Attached Network Set 💖

there's also a Routing Set, which gets derived from the Local Information Base, the Interface Information Bases, the Neighbor Information Base, and the rest of the Topology Information Base. it's giving layers 🧁

10.1. Advertising Remote Router Set 💌

a router's Advertising Remote Router Set keeps track of every remote router in the network that sends TC messages. that way outdated TC messages can be spotted and tossed out 🗑️ it's made 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 doesn't include a prefix length 🫶
AR_seq_number is the greatest ANSN in any TC message received from the router with originator address AR_orig_addr (aka the ANSN that contributed to the info in this Tuple) 🧠
AR_time is the time this Tuple expires, and it MUST be removed at that point ⏰

10.2. Router Topology Set 🛰️

a router's Topology Set holds topology info about the links between routers in the MANET. it's made 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. (no prefix length here either 🙈)
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. (still no prefix length 💅)
TR_seq_number is the greatest ANSN in any TC message received from the router with originator address TR_from_orig_addr (the ANSN that helped build 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 says when this Tuple expires, and it MUST be removed then ⏳

10.3. Routable Address Topology Set 🗺️

a router's Routable Address Topology Set holds topology info about the routable addresses inside the MANET, including which routers you can reach them through 🧚 it's made 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 (no prefix length, babe 💖)
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 from the router with originator address TA_from_orig_addr (the one that contributed to 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 says when this Tuple expires, and it MUST be removed then 🥀

10.4. Attached Network Set 🏠

a router's Attached Network Set holds info about networks (which can be outside the MANET) attached to other routers, plus their routable addresses. it's made 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 a gateway to the network with network address AN_net_addr (no prefix length, as always 🙃)
AN_net_addr is the network address of an attached network that can be reached via the router with originator address AN_orig_addr 🌐
AN_seq_number is the greatest ANSN in any TC message received from the router with originator address AN_orig_addr (the one that contributed to 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 says when this Tuple expires, and it MUST be removed then 🫠

10.5. Routing Set 🛤️

a router's Routing Set records the first hop along a selected path to each destination that has any known path ✨ it's made 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. it's 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 that an IP packet MUST be sent over to reach the destination by the selected path. no skipping this one, it's a must 🚦
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 its other Protocol Sets (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). it gets updated (Routing Tuples added or removed, or the whole Routing Set recalculated) when routing paths are calculated, based on changes to those other Protocol Sets 🔄 and fun fact: Routing Tuples don't get timer-based expiration 🙌

11. Received Message Information Base 📬

the Received Message Information Base, defined by this spec, keeps info needed to make sure a message gets processed at most once, and forwarded at most once per OLSRv2 interface of a router, using MPR flooding 🔁 messages get recorded by their "signature", which is their type, originator address, and message sequence number 🪪

11.1. Received Set 📥

a router has a Received Set per OLSRv2 interface. each Received Set records the signatures of messages received over that OLSRv2 interface. each one is made 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 (no prefix length, obvi 🙄)
RX_seq_number is the message sequence number of the received message 🔢
RX_time says when this Tuple expires, and it MUST be removed then 🕳️

11.2. Processed Set ✅

a router has one single Processed Set that records signatures of messages the router has processed. it's made 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 (no prefix length, periodt 💅)
P_seq_number is the message sequence number of the processed message 🔖
P_time says when this Tuple expires, and it MUST be removed then 🌙

11.3. Forwarded Set 💌

Every router has a single Forwarded Set 🦋 It's basically a diary of the messages this router has already passed along, so it doesn't pass the same thing twice. Each entry is a Forwarded Tuple:

(F_type, F_orig_addr, F_seq_number, F_time)

Here's what each piece means:

F_type is the Message Type that got forwarded 📦
F_orig_addr is the originator address of the forwarded message (and yes, no prefix length here, so don't add one 🙅‍♀️)
F_seq_number is the message sequence number of that forwarded message
F_time says when the Tuple expires, and at that point it MUST be removed 🗑️ no exceptions, bestie

12. Information Base Properties ✨

Okay, this part is about some extra properties of the Information Bases and what's inside them 🧚

12.1. Corresponding Protocol Tuples 🎀

So a lot of the time, one Protocol Tuple in one Protocol Set has a natural partner, a single Protocol Tuple in another Protocol Set. That could be in the same Information Base or a different one 💕 The partner is called "corresponding" to the first one. It's like matching besties across the group chat 👯‍♀️

Here are the main matches:

There's a Local Interface Tuple for each Link Tuple, where the Link Tuple sits in the Link Set for a MANET interface, and the Local Interface Tuple represents that same MANET interface 🌸
There's a Neighbor Tuple for each Link Tuple whose L_HEARD_time is not EXPIRED, as long as N_neighbor_addr_list contains L_neighbor_iface_addr_list 💜
There's a Link Tuple (in the Link Set of the same Interface Information Base) for each 2-Hop Tuple where L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list ✨
There's a Neighbor Tuple for each 2-Hop Tuple, where N_neighbor_addr_list contains N2_neighbor_iface_addr_list. This is the Neighbor Tuple that corresponds to the Link Tuple that corresponds to the 2-Hop Tuple 🔗 (the matchmaking chain is real, iykyk 😭)
There's an Advertising Remote Router Tuple for each Router Topology Tuple where AR_orig_addr = TR_from_orig_addr 🦋
There's an Advertising Remote Router Tuple for each Routable Address Topology Tuple where AR_orig_addr = TA_from_orig_addr 🌈
There's an Advertising Remote Router Tuple for each Attached Network Tuple where AR_orig_addr = AN_orig_addr 🍓
There's a Neighbor Tuple for each Routing Tuple where N_neighbor_addr_list contains R_next_iface_addr 💅

12.2. Address Ownership 👑

This one is all about who "owns" an address when a router is processing a received message. Ownership comes in two flavors, and they're kinda layered 🧁

Addresses or network addresses count as "fully owned" by a router when processing a received message if they meet any of these:

They equal its originator address; OR
They equal the O_orig_addr in an Originator Tuple; OR
They equal or are a sub-range of the I_local_iface_addr_list in a Local Interface Tuple; OR
They equal or are a sub-range of the IR_local_iface_addr in a Removed Interface Address Tuple; OR
They equal an AL_net_addr in a Local Attached Network Tuple.

Addresses or network addresses count as "partially owned" (which can also include being fully owned) by a router when processing a received message if they meet any of these:

They overlap (equal or contain) its originator address; OR
They overlap (equal or contain) the O_orig_addr in an Originator Tuple; OR
They overlap the I_local_iface_addr_list in a Local Interface Tuple; OR
They overlap the IR_local_iface_addr in a Removed Interface Address Tuple; OR
They equal or have as a sub-range an AL_net_addr in a Local Attached Network Tuple.

13. Packets and Messages 📨

The packet and message format this protocol uses is defined in [RFC5444] 💌 Unless otherwise noted, options defined in [RFC5444] may be freely used, especially the alternative formats defined by packet, message, Address Block, and TLV flags 🌟

This section explains how this spec uses the packets and messages defined in [RFC5444], plus the TLVs that this spec defines and uses 🎀

13.1. Messages 💬

Routers using this protocol swap info through messages. The Message Types used here 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 that a router sends at the same time SHOULD be combined into a single packet 🧳 That's subject to any limits on maximum packet size (like the ones derived from the MTU over a local single hop) that MAY be imposed. These messages might have started at the sending router, or at another router and are just being forwarded by the sending router 🔁 Messages with different originating routers MAY be combined into the same packet. Messages from other protocols defined using [RFC5444], including but not limited to NHDP [RFC6130], MAY be combined into the same packet too 🧚 This specification does not define or use any contents of the Packet Header 🙈

Forwarded messages MAY be jittered as described in [RFC5148] 🎲 And the observation there is that the forwarding jitter of all messages received in a single packet SHOULD be the same. The value of MAXJITTER used when 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). Otherwise, it SHOULD be with a maximum delay of F_MAXJITTER 💖 A router MAY modify the jitter applied to a message so it can combine messages into packets more efficiently, as long as the maximum jitter isn't exceeded 🌸

13.3. TLVs 🏷️

This specification defines two Message TLVs and four Address Block TLVs ✨

Any reference in this specification to a TLV that doesn't indicate a type extension assumes Type Extension = 0. In processed messages, TLVs with a type extension that is neither zero (as assumed) nor a specifically indicated non-zero type extension are ignored 🙅‍♀️

Quick reminder: 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 💖

okay so the LINK_METRIC TLV shows up in HELLO messages and TC messages 🦋 It MAY use any type extension, but this spec only uses LINK_METRIC TLVs whose type extension equals LINK_METRIC_TYPE ✨ And an 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. no double dipping!! 🙅

+-------------+--------------+--------------------------------------+
|     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'), says the link metric is of that kind and direction. Any combination of these bits MAY be used, so mix and match 🌈

            +-----+-----------------+-----------+
            | 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 it tells you that an address it's attached to belongs to a symmetric 1-hop neighbor that got picked 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

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. two options, pick your fave 💅

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. the rules are strict, but the vibes are clean 🫶

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. it's the gatekeeper, bestie 🚪✨

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. so much efficiency, it's giving main character 💜

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. no sequence number, no entry!! 🙅

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:

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. talking to yourself is not it 🪞
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:

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. it's a soft pass, not a hard no 🌷
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. already seen it, already ate it 🍓

Otherwise:
1. Create a Processed Tuple in the Processed Set with:
  - P_type := the Message Type of the current message;
  - 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:

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. not from a friend? not getting forwarded 🙅
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. we already did this one, periodt 💅

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;
  - 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. forwarded already, don't be extra 🙈

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:

Okay bestie, first up: create a Forwarded Tuple in the Forwarded Set with:
- F_type := the Message Type of the current message 🎀
- F_orig_addr := originator address of the current message 💌
- F_seq_number := sequence number of the current message 🔢
- F_time := current time + F_HOLD_TIME ⏰
Then the Message Header of the current message gets modified by:
- Decrement <msg-hop-limit> in the Message Header by 1; AND
- If present, increment <msg-hop-count> in the Message Header by 1. ✨
The message gets transmitted over all OLSRv2 interfaces, as described in Section 13. 🚀
Otherwise, the current message MUST be silently discarded. 🙈

15. HELLO Messages 🦋

Okay so the HELLO Message Type is owned by NHDP [RFC6130], which means HELLO messages get generated, transmitted, received, and processed by NHDP. This protocol, as permitted by [RFC6130], also uses HELLO messages. It adds to HELLO message generation and does extra processing based on the HELLO messages it receives. Ngl, the division of labour is iconic. 💅 HELLO messages are not forwarded by NHDP [RFC6130] or by OLSRv2, so they stay put. 🫶

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. The main character is only the OLSRv2 interface, bestie. 👑

HELLO messages sent over OLSRv2 interfaces are extended by adding the following elements:

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. 🧚
A Message TLV with Type := MPR_WILLING MUST be included. 🍓
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 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]. Bestie, this part is giving rules, so read it twice. 🔁
- 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.
- 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). So it's a maybe, plus the usual NHDP limits, no cap. 🕰️

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]:

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. 🗑️
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:

Has more than one Message TLV with Type = MPR_WILLING.
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].)
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.
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.
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:

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;
  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.
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 📏✨

okay so for every address in a received HELLO message that has an associated Type = LINK_STATUS TLV with Value = HEARD or Value = SYMMETRIC, we get an incoming (to the message originator) link metric 💅. If the HELLO also has a Type = LINK_METRIC TLV with Type Extension = LINK_METRIC_TYPE that ties that address to a metric of the right kind (link) and direction (incoming), that value is the incoming link metric. If not, it's UNKNOWN_METRIC. no cap, it's that deep 🫶

same vibe for Value = SYMMETRIC, but this time we're looking at the outgoing (from the message originator) link metric. Same matching rule: find the link metric for that address with the right kind (link) and direction (outgoing), and if it's not there, it's UNKNOWN_METRIC 🦋

now neighbor metrics 🌸 For every address with an associated Type = LINK_STATUS or Type = OTHER_NEIGHB TLV whose Value = SYMMETRIC, we get an incoming (to the message originator) neighbor metric. Same matching idea, but this time it's the kind (neighbor) and direction (incoming). No match means UNKNOWN_METRIC.

and the last one is the same setup, just flipped: outgoing (from the message originator) neighbor metric, using the same Type = LINK_STATUS or Type = OTHER_NEIGHB with Value = SYMMETRIC condition, matched on kind (neighbor) and direction (outgoing). No match, UNKNOWN_METRIC 🍓

now the Link Tuple elements L_in_metric and L_out_metric get updated like this 💜

okay so L_in_metric MAY be set to any representable value by a process outside this specification, at any time 🧚 But it MUST be set whenever L_status becomes equal to HEARD or SYMMETRIC. If there's no other value available, the value MAXIMUM_METRIC MUST be used 🔥 Setting L_in_metric MAY use info based on receiving a packet with a HELLO message that creates or updates the Link Tuple.
when a Link Tuple gets updated (maybe right after it's created) because we got a HELLO message, as specified in [RFC6130], and L_status = SYMMETRIC, then L_out_metric is set equal to the incoming link metric for any included address of the interface the HELLO came in on. (psst, the rules for discarding HELLO messages in Section 15.3.1 make this value unambiguous 👑) If there's an address like that but no such link metric, then L_out_metric is set to UNKNOWN_METRIC.

the Neighbor Tuple elements N_in_metric and N_out_metric are updated according to Section 17.3 ✨

and for any 2-Hop Tuple updated as defined in [RFC6130], N2_in_metric and N2_out_metric get set equal to the incoming neighbor metric and the outgoing neighbor metric, respectively, that go with the matching N2_2hop_addr. If there aren't any such metrics, both get set to UNKNOWN_METRIC 💖

15.3.2.2. Updating Willingness 🎀

N_will_flooding and N_will_routing in the current Neighbor Tuple get updated using the Message TLV with Type = MPR_WILLING. (note that this must be present, bestie 🙈) It goes like this:

N_will_flooding := bits 0-3 of the value of that TLV; AND
N_will_routing := bits 4-7 of the value of that TLV.

(each one being in the range 0 to 15, aka WILL_NEVER up to WILL_ALWAYS 💅)

15.3.2.3. Updating MPR Selector Status 🦋

okay so L_mpr_selector gets updated like this:

if a router finds an address object for any of its relevant local interface network addresses (the ones in the I_local_iface_addr_list of an OLSRv2 interface) that has an associated Address Block TLV with Type = MPR and Value = FLOODING or Value = FLOOD_ROUTE in the HELLO message (which means the originating router picked the receiving router as a flooding MPR 💫), then, for the current Link Tuple:
- L_mpr_selector := true.
otherwise (i.e., if no such address object and Address Block TLV was found), if a router finds an address object for any of its relevant local interface network addresses (again, the ones 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.

and N_mpr_selector gets updated like this 🌈

if a router finds an address object for any of its relevant local interface network addresses (the ones 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 (meaning the originating router picked the receiving router as a routing MPR 🎉), then, for the current Neighbor Tuple:
- N_mpr_selector := true;
- N_advertised := true.
otherwise (i.e., if no such address object and Address Block TLV was found), if a router finds an address object for any of its relevant local interface network addresses (the ones 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 Neighbor Tuple:
- N_mpr_selector := false;
- the router MAY also set N_advertised := false. 🫠

16. TC Messages 📡✨

this protocol defines, and so owns, the TC Message Type (see Section 24) 👑 So, as specified in [RFC5444], this protocol generates and transmits all TC messages, receives all TC messages, and decides whether and how each TC message gets processed (updating the Topology Information Base) and/or forwarded, according to this specification. main character energy, no notes 💅

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]:

a message originator address that records this router's originator address. This MUST use a <msg-orig-addr> element. 💖
a <msg-seq-num> element containing the message sequence number. 🌸
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). 🦋
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 doesn't need to. 🍓
a single Message TLV with Type := CONT_SEQ_NUM and Value := ANSN from the Neighbor Information Base. If the TC message is complete, this Message TLV MUST have Type Extension := COMPLETE; otherwise, it MUST have Type Extension := INCOMPLETE. (Exception: a TC message MAY omit this Message TLV if the TC message doesn't include any address objects with an associated Address Block TLV with Type = NBR_ADDR_TYPE or Type = GATEWAY.) 🙈
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.

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 that match 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. ⏳

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, 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 going to be associated with Value = ROUTABLE. 🫶
if the TC message is complete, all routable addresses 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, 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 going 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 a value equal to the corresponding N_out_metric. ✨
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, 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:

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 MUST specify times that vary with the number of hops that match 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 🦋

okay so a router with one or more OLSRv2 interfaces, and with any Neighbor Tuples with N_advertised = true or a non-empty Local Attached Network Set, MUST generate TC messages 📡. If a router has nothing to advertise, it MUST also generate "empty" TC messages for a period of A_HOLD_TIME after it last generated a non-empty TC message. bestie, that's giving continuity ✨

Complete TC messages get generated and transmitted periodically on all OLSRv2 interfaces. The default interval between two consecutive TC message transmissions by the same router is TC_INTERVAL ⏰

TC messages MAY be generated in response to a change in the information they advertise, which shows up as a change in the ANSN in the Neighbor Information Base 💅 When that happens, a router MAY send a complete TC message and, if it does, MAY restart its TC message schedule. Or, alternatively, a router MAY send an incomplete TC message with at least the newly advertised network addresses in its Address Blocks, along with the associated Address Block TLV(s). By "newly advertised" I mean addresses that weren't advertised before but now are, so an N_orig_addr, something in an N_neighbor_addr_list in a Neighbor Tuple with N_advertised = true, or an AL_net_addr 🫶 Just a heads-up though: a router cannot report removal of advertised content using an incomplete TC message 💀

When a router sends a TC message because the advertised network addresses changed, it MUST respect a minimum interval of TC_MIN_INTERVAL between sending TC messages (complete or incomplete). It also MUST respect a maximum interval of TC_INTERVAL between sending complete TC messages. So, a router MUST NOT send an incomplete TC message if it's within TC_MIN_INTERVAL of the next scheduled time to send a complete TC message 🙈

The generation of TC messages, whether it's scheduled or triggered by a change of contents, MAY be jittered as described in [RFC5148] 🌈 The values of MAXJITTER used MUST be:

TP_MAXJITTER for periodic TC message generation;
TT_MAXJITTER for responsive TC message generation.

16.3. TC Message Processing 🧚

When a router receives a TC message on an OLSRv2 interface, it MUST then follow the processing and forwarding procedures defined in Section 14.

If the message is considered for processing (Section 14.2), a router MUST first check whether 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. When it does, 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 the TC Message Type, described in Section 16.3.2, MUST be applied. This updates its appropriate Interface Information Bases and its Router Information Base. After that, if there are any changes in these Information Bases, 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:

Has an address length specified in the Message Header that is not equal to the length of the addresses used by this router.
Does not include a message originator address and a message sequence number.
Does not include a hop count and contains a multi-value TLV with Type = VALIDITY_TIME or Type = INTERVAL_TIME, as defined in [RFC5497].
Does not have exactly one Message TLV with Type = VALIDITY_TIME.
Has more than one Message TLV with Type = INTERVAL_TIME.
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.
Has more than one Message TLV with Type = CONT_SEQ_NUM and Type Extension = COMPLETE or Type Extension = INCOMPLETE.
Has a message originator address that is partially owned by this router.
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.
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.
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.
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, and that is also associated with more than one outgoing neighbor metric using a TLV with Type = LINK_METRIC and Type Extension = LINK_METRIC_TYPE.
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.
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 by rejecting TC messages "at random", may cause parts of the network to be unable 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 🔐

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:

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.
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:

"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.
"received ANSN" is defined as being the value of a Message TLV with Type = CONT_SEQ_NUM.
"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.)
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:

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.
The Router Topology Set is updated according to Section 16.3.3.2.
The Routable Address Topology Set is updated according to Section 16.3.3.3.
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:

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.

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.

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:

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.
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.

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:

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,

then create a new Routable Address Topology Tuple with:

TA_from_orig_addr := message originator address;
TA_dest_addr := advertised address.

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 🌸

okay bestie, this is where the router updates its Attached Network Set, and it MUST do it in this exact order 💅

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.

This Attached Network Tuple (existing or new) is then modified as follows:
- AN_seq_number := received ANSN;
- 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 gets finished off in three steps, in this order 🎀

The Router Topology Set is updated according to Section 16.3.4.1.
The Routable Address Topology Set is updated according to Section 16.3.4.2.
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 like this:

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 like this:

Any Routable Address Topology Tuples with:
- TA_from_orig_addr = message originator address; AND
- TA_seq_number < received ANSN,

MUST be removed.

16.3.4.3. Purging the Attached Network Set 🧚

the Attached Network Set MUST be updated like this:

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 in the following sections MUST be carried out whenever an Information Base changes as indicated. no skipping, periodt 😭

17.1. Originator Address Changes 🌈

if the router changes its originator address, then:

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]:

If L_status = HEARD or L_status = SYMMETRIC, then L_in_metric MUST be set (by a process outside this specification).
If L_status != SYMMETRIC, then set L_mpr_selector := false.
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]:

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.
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.
If N_symmetric = false, then N_flooding_mpr, N_routing_mpr, N_mpr_selector, and N_advertised MUST all be equal to false.
If N_mpr_selector = true, then N_advertised MUST be equal to true.
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:

Any Neighbor Tuple changes its N_advertised value, or any Neighbor Tuple with N_advertised = true is removed.
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.
Any Neighbor Tuple with N_advertised = true has N_out_metric changed.
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:

All Router Topology Tuples with:
- TR_from_orig_addr = AR_orig_addr of the Advertising Remote Router Tuple

are removed.

All Routable Address Topology Tuples with:
- TA_from_orig_addr = AR_orig_addr of the Advertising Remote Router Tuple

are removed.

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 make sure this happens:

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
- 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.
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.
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
- 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.
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. that's the whole section, slay ✨

17.7. Routing Set Updates ✨

Okay bestie, the Routing Set MUST be updated, as described in Section 19, whenever the Local Information Base, the Neighborhood Information Base, or the Topology Information Base shows a change (including any change to potentially used outgoing neighbor metric values) in the known symmetric links and/or attached networks across the MANET 🌸. That changes the Topology Graph, so it's a whole big deal. You only need to care about changes that affect at least one of these:

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, with an alternative network address from the same I_local_iface_addr_list 🦋.
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 💅.
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) 🔥.
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 🫶.
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 🌈.
Router Topology Set of the router. ⭐
Routable Address Topology Set of the router. 🧚
Attached Network Set of the router. 👑

18. Selecting MPRs 🎀

Okay so each router MUST select, from among its willing symmetric 1-hop neighbors, two subsets of these routers: flooding MPRs and routing MPRs 😭. That selection gets 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 below, which may, but doesn't have to, use the organization of the data described. Routers can freely interoperate whether they use the same or different MPR selection algorithms, which is honestly so iconic 💜.

Only flooding MPRs forward control messages that get flooded through the MANET. That's the 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.) So while it isn't essential for these two sets to be minimal, keeping the numbers of MPRs small keeps the overhead of this protocol as low as possible 🍓.

18.1. Overview 🌸

MPRs get selected through the following steps, which are defined in the sections below:

A data structure known as a Neighbor Graph is defined.
The properties of an MPR Set derived from a Neighbor Graph are defined. Any algorithm that creates an MPR Set satisfying these properties is a valid MPR selection algorithm. An example algorithm that creates such an MPR Set is given in Appendix B 🦋.
How to create a Neighbor Graph for each interface, based on the corresponding Interface Information Base, is defined. It also explains how to combine the resulting MPR Sets to determine the router's flooding MPRs and record those in the router's Neighbor Set 💅.
How to create a single Neighbor Graph based on all Interface Information Bases and the Neighbor Information Base is defined. It also explains how to record the resulting MPR Set as the router's routing MPRs in the router's Neighbor Set 🔥.
A specification as to when MPRs MUST be calculated is given. Literally non-negotiable 🙈.

When a router selects its MPRs, it MAY consider any characteristics of its neighbors that it's 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 (whichever is 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 it MAY 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. Very strategic, very main character ⭐.

18.2. Neighbor Graph 💖

A Neighbor Graph is a structure defined here as consisting of sets N1 and N2, plus 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 🌸.

A Neighbor Graph has the following properties:

It contains two disjoint sets, N1 and N2.
For each element x in N1, there is an associated willingness value W(x) such that WILL_NEVER < W(x) <= WILL_ALWAYS 🦋.
For each element x in N1, there is an associated metric d1(x) > 0 💅.
For some elements y in N2, there is an associated metric d1(y) > 0. (Other elements y in N2 have undefined d1(y), which may be considered to be infinite 🔥.)
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 🫶.)
N2 is equal to the union of all the N2(x) for all x in N1. In other words, for each y in N2, there is at least one x in N1 such that y is in N2(x) 🌈.

It's convenient to also define:

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 👑.
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).) 🧚
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 (and may be considered 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 💜:

If x in N1 has W(x) = WILL_ALWAYS, then x is in M 🌸.
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 🦋.
For any y in N2, d(y,M) = d(y,N1) 💅.

These properties reflect that the MPR Set is a set of symmetric 1-hop neighbors that cover all the symmetric 2-hop neighbors, and that they do so while keeping 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, N1 is always an MPR Set 🌈. An MPR Set may be empty, but it cannot be empty if N2 contains any elements y that don't have a defined d1(y) ✨.

18.4. Flooding MPRs ✨

Okay so whenever flooding MPRs need to be calculated, an implementation MUST determine and record a set of flooding MPRs that is equivalent to one calculated the way this section describes 💅

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 🦋 But links with unknown metric (L_out_metric = UNKNOWN_METRIC) MUST NOT be used, even if link metrics are otherwise not used. Not even a little 💀

Routers MAY make individual decisions about whether to use link metrics for the calculation of flooding MPRs. A router MUST use the same approach to that choice for all links. So in the cases marked A or B, the same choice MUST be made in each case. Consistency is everything, periodt 🎀

For each OLSRv2 interface (the "current interface"), define a Neighbor Graph as defined in Section 18.2, following these rules:

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.
Define an allowed Link Tuple to be a reachable Link Tuple whose corresponding Neighbor Tuple has N_will_flooding > WILL_NEVER.
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.
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.
For each element x in N1, define W(x) := N_will_flooding of the corresponding Neighbor Tuple.
For each element x in N1, define d1(x) as either:
- A. L_out_metric of the corresponding Link Tuple; OR
- B. 1.
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.
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.

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. Pick whatever labelling vibes with your code 🌸

Using these Neighbor Graphs, flooding MPRs are selected and recorded by:

For each OLSRv2 interface, determine an MPR Set as specified in Section 18.3.
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 means the overall set of flooding MPRs is the union of the sets of flooding MPRs for all OLSRv2 interfaces. Main character energy 👑

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 coordinated approach is to process the OLSRv2 interfaces one at a time and, for each interface, start with flooding MPRs selected (and not removable) if the neighbor has already been 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 need 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. Same energy as before, bestie 🫶

Define a single Neighbor Graph as defined in Section 18.2, following these rules:

Define a reachable Neighbor Tuple to be a Neighbor Tuple with N_symmetric = true and N_in_metric != UNKNOWN_METRIC.
Define an allowed Neighbor Tuple to be a reachable Neighbor Tuple with N_will_routing > WILL_NEVER.
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.
Define an element of N1 for each allowed Neighbor Tuple. This then defines the corresponding Neighbor Tuple for each element of N1.
For each element x in N1, define W(x) := N_will_routing of the corresponding Neighbor Tuple.
For each element x in N1, define d1(x) := N_in_metric of the corresponding Neighbor Tuple.
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.
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.
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. Labels are yours to choose 🍓

Using these Neighbor Graphs, routing MPRs are selected and recorded according to the following:

Determine an MPR Set as specified in Section 18.3.
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 is still valid but could be more efficient. Sufficient conditions to recalculate a router's sets of MPRs are given in Section 17.6. Recalc when needed, not vibes-only 😭

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. Basically the whole network map, sorted out for you ✨

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. So not every tuple has to make it into the routing table, just the right ones 💅

19.1. Network Topology Graph ✨

okay so the Network Topology Graph gets built from the router's Local Interface Set, the Link Sets for OLSRv2 interfaces, the Neighbor Set, the Router Topology Set, the Routable Address Topology Set, and the Attached Network Set. it MAY also use info from the router's 2-Hop Sets for OLSRv2 interfaces 🧚 this graph is the router's whole view of the network as a directed graph, and every edge in it has a metric value 💅 the "backbone" is where the minimum total metric routes get constructed, and it's got these edges:

Edges X -> Y for all possible Y, with 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.

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 also gets extra "decorations" 🎀 with the edges below. quick warning, bestie: if a network address S, V, Z, or T equals a network address Y or W, then the edge ending at that address MUST NOT be used in any path. no exceptions 🙅‍♀️

If a network address S, V, Z, or T equals a network address Y or W, the edge terminating in that address MUST NOT be used in any path.

Edges X -> S for all possible S, with 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.

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.

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.

(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.

ok last bits, and these matter 🫶 any part of the Topology Graph that isn't connected to a local network address X just gets ignored 🙈 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. every edge has a hop count of 1, except the edges W -> T, which have a hop count of the matching AN_dist value 🍓

19.2. Populating the Routing Set

the Routing Set MUST contain the shortest paths for all destinations from all local OLSRv2 interfaces, calculated over the Network Topology Graph 👑 this calculation MAY use any algorithm, including any way of picking between paths with equal total metric. (quick aside: if two paths have equal total metric but different hop counts, the path with the lower hop count SHOULD be used ✨)

so the order goes like this: first you build the "backbone" paths using only X -> Y and W -> U edges, using a minimum distance algorithm. then you can add paths whose final edge is one of the other types. those extra paths MUST NOT replace backbone paths with the same destination, and paths ending in an edge Y -> Z SHOULD NOT replace paths with any other form of terminating edge 💖

every path turns into a Routing Tuple, and there are two types. the first type covers single edge paths, meaning X -> S or X -> Y, and it looks like this:

R_local_iface_addr := X;
R_next_iface_addr := R;
R_dest_addr := S or Y;
R_dist := 1;
R_metric := edge metric,

where R is defined in Section 19.1 for these edge types ✨

the second type covers multiple edge paths. these always start with an X -> Y edge, and they finish with an edge of type W -> U, W -> V, W -> T, or Y -> Z. the Routing Tuple is:

R_local_iface_addr := X;
R_next_iface_addr := Y;
R_dest_addr := U, V, T or Z;
R_dist := the total hop count of all edges in the path;
R_metric := the total metric of all edges in the path.

last one: Routing Tuples of the second type whose R_dest_addr is not routable MAY be discarded 🧹 and if you want an example algorithm for calculating a router's Routing Set, it's in Appendix C 🦋

20. Proposed Values for Parameters 💜

this protocol uses all the parameters defined in [RFC6130], plus extra ones defined in this specification 🌈 all of these extra parameters are router parameters as defined in [RFC6130] except one, RX_HOLD_TIME. the proposed values for the extra parameters in the following sections are the right ones for when every parameter (including the [RFC6130] ones) has a single value. proposed values for [RFC6130] parameters live in that spec, so go check there 📖

the following proposed values come from experience with [RFC3626] deployments (like the ones documented in [McCabe]) and they're considered typical 🫧 you can change them for different deployment needs. for example, a network with capacity-limited interfaces would be expected to use bigger message intervals, whereas a super mobile network would be expected to use smaller ones 🏃‍♀️ when you're picking these values, the constraints in Section 5 MUST be respected, no skipping 🔥

also, routers in a MANET don't all need the same parameters, and the ones marked as interface parameters don't need to match across all OLSRv2 interfaces on a single router 💅

20.1. Local History Time Parameters

O_HOLD_TIME := 30 seconds

20.2. Message Interval Parameters

TC_INTERVAL := 5 seconds
TC_MIN_INTERVAL := TC_INTERVAL/4

20.3. Advertised Information Validity Time Parameters

T_HOLD_TIME := 3 x TC_INTERVAL
A_HOLD_TIME := T_HOLD_TIME

20.4. Received Message Validity Time Parameters

RX_HOLD_TIME := 30 seconds
P_HOLD_TIME := 30 seconds
F_HOLD_TIME := 30 seconds

20.5. Jitter Time Parameters

TP_MAXJITTER := HP_MAXJITTER
TT_MAXJITTER := HT_MAXJITTER
F_MAXJITTER := TT_MAXJITTER

20.6. Hop Limit Parameter

TC_HOP_LIMIT := 255

20.7. Willingness Parameters

WILL_FLOODING := WILL_DEFAULT
WILL_ROUTING := WILL_DEFAULT

21. Sequence Numbers 🌸

sequence numbers are how this protocol tosses out "old" info, aka messages that show up out of order 📬 but there's a catch: with only a limited number of bits, wraparound happens, meaning the number goes from the max value back to zero 😭 so to stop that from messing things up, the following MUST be observed when working out the ordering of sequence numbers 🎀

the term MAXVALUE means one more than the largest possible value for a sequence number. for a 16-bit sequence number (like the ones defined in this spec), MAXVALUE is 65536 🧮

sequence number S1 is "greater than" sequence number S2 if:

S1 > S2 AND S1 - S2 < MAXVALUE/2, OR
S2 > S1 AND S2 - S1 > MAXVALUE/2

when S1 and S2 differ by MAXVALUE/2, their ordering can't be figured out. in that case (which shouldn't happen!) either ordering may be assumed 🙈

so even with wraparound, comparing two messages still tells you which one has the most recent info 💖

22. Extensions 🧚

an extension to this protocol will need to interact with this specification and maybe with [RFC6130] too 🦋 this protocol was designed to allow those interactions, specifically:

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.
Through accessing an outgoing message before it's 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 messages.) This might, for example, let a security protocol, as suggested in Section 23, add a TLV containing a cryptographic signature to the message 🔐
Through accessing an incoming message and potentially discarding it before this protocol processes it. This might, for example, let a security protocol, as suggested in Section 23, verify message signatures and stop unverifiable messages from being processed and/or forwarded by this protocol 🛡️
Through accessing an incoming message after this protocol has fully processed it. In particular, this may let a protocol that has added information (by including appropriate TLVs or network addresses associated with new TLVs) access that information after the updates have been recorded in the Information Bases in this protocol 👀
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 💀

okay bestie, this one's serious 😭 as a proactive routing protocol, OLSRv2 is a potential target for all kinds of attacks 🚨 this section lays out the envisioned security architecture for OLSRv2 and gives guidelines on how to get integrity, confidentiality, and integration into external routing domains 🔒 it also summarizes the separately specified mandatory security mechanisms and shares some observations on key management 🗝️ the security stuff is literally the main character here, so read it carefully 👑

23.1. Security Architecture 🏰

okay so OLSRv2 slots right into the architecture from Appendix A of [RFC5444], plus [RFC5498], plus Section 16 of [RFC6130], and that last one works by using and extending its messages and Information Bases 💅

NHDP [RFC6130] and OLSRv2 both know there can be outside reasons to reject messages that count as "badly formed" or "insecure" 🙈 like when an Integrity Check Value (ICV) that some external mechanism put in a message can't be verified. The architecture gives you options on whether and how to do security stuff, because MANET deployments have wildly different security needs, from "practically unbreakable" 🔐 all the way down to "virtually none" 💀 So the protocol specs stay generic, and you add extensions to them and/or to the multiplexing and demultiplexing process from Appendix A of [RFC5444] to get the security that fits your deployment domain ✨

The next sections give guidelines on how to provide integrity, confidentiality, and integration with external routing domains in those extensions 🦋

23.2. Integrity 🔐

Every router puts topology info into the network by sending HELLO messages and, for some routers, TC messages too 🌸 If some routers inject invalid control traffic, whether from malice or malfunction, the network's integrity can get wrecked 😭 So message, or packet, authentication is strongly advised 🫶

Here's what that could look like:

A router generates TC messages, advertising links to non-neighbor routers;
A router generates TC messages, pretending to be another router;
A router generates HELLO messages, advertising non-neighbor routers;
A router generates HELLO messages, pretending to be another router;
A router forwards altered control messages;
A router does not forward control messages;
A router does not select multipoint relays correctly;
A router forwards broadcast control messages unaltered but does not forward unicast data traffic;
A router "replays" previously recorded control traffic from another router.

Authenticating the originator router for control messages (for situations 2, 4, and 5) and the individual links announced in the control messages (for situations 1 and 3) can be used as a countermeasure 🛡️ BUT 🙃 stopping routers from repeating old, correctly authenticated info (situation 9) needs extra stuff, like a timestamp or sequence number, so a router can spot replayed messages positively 🧚

ICVs (e.g., digital signatures) and other required security info can ride inside the HELLO and TC messages, or in a packet header using the TLV mechanism 💖 Either way, different levels of protection can coexist in the same network if you want that 🌈

Here's the big thing 👀 All control messages (HELLO and TC) go to every router in the 1-hop neighborhood, and some (TC messages) get flooded to every router in the network. That happens in a packet sent to everyone in the 1-hop neighborhood, and the current set of those routers might not even be known 😵 So every control message or packet in this protocol is always inside a transmission aimed at multiple destinations, which means the authentication mechanism has to let any receiving router validate the authenticity of a message or packet 🎀

[RFC7182] defines a common exchange format for cryptographic info as Packet TLVs, Message TLVs, and Address Block TLVs, as specified in [RFC5444] 🧁 Everyone can use (and share) these among MANET routing protocol security extensions. Specifically, [RFC7182] gives the format of TLVs that hold Integrity Check Values (ICVs), i.e., signatures for integrity, plus TLVs with temporal info for preventing replay attacks ⏰ It also sets up registries for different ciphers and formats of temporal info 📚

When you use ICV TLVs in an OLSRv2 deployment, failing to verify an included ICV means the incoming message or packet gets rejected as "invalid" 🚫 That follows Section 12.1 of [RFC6130], and Section 16.3.1 of this specification when you're using the multiplexing and demultiplexing process from Appendix A of [RFC5444] 💅

[RFC7182] also covers how to insert ICVs into generated messages, how to verify incoming ones, and how to reject "insecure" messages, meaning ones with no ICV or an ICV that can't be verified 🙅‍♀️ Different MANET deployments might need different ICV algorithms and timestamps, or multiple keys, depending on what they're for and how they can be configured 🔑 So a security extension can use any of the options in [RFC7182] that it needs 🧚‍♀️

23.3. Confidentiality 🤫

OLSRv2 periodically MPR floods topological info to every router in the network 📡 So if you use it on an unprotected network (especially an unprotected wireless one), anyone who listens to the control messages can see the network topology 👀 That info can help an attacker learn the topology and then launch stronger attacks on routers in the routing domain, like spoofing router addresses to pull in traffic for them 😱 Also, this is separate from data traffic. It only protects the control traffic, i.e., the info about network topology 🦋

When the confidentiality of the topology really matters, regular crypto techniques can be applied 🔒 For example, OLSRv2 multicast control packets can be encrypted using IPsec (e.g., with a shared secret key), so only authorized readers can read and interpret the control traffic 💜 Or a security extension can specify its own mechanism for confidentiality of control messages and/or packets 🛠️

Unless the network topology info itself is confidential, integrity of control messages (as specified in Section 23.2) is enough to let in only trusted routers (i.e., routers with valid credentials) 🫶

23.4. Interaction with External Routing Domains 🌐

This protocol has a basic mechanism for injecting external routing info into its own routing domain 🚪 Routing info can also be pulled out of this protocol's Information Bases, especially the Routing Set, and injected into an external routing domain, as long as the protocol governing that external domain allows it ✨

When you run routers that connect a routing domain using this protocol to an external one, you MUST take care not to let potentially insecure and untrustworthy info get injected from this domain into the external one 🚨 You MUST also take care to validate the correctness of info before it's injected, so you don't pollute routing tables with invalid info 🙈

A recommended way to extend connectivity from an external routing domain into this one, which is routed using this protocol, is to assign an IP prefix exclusively to this domain 🎀 That prefix is assigned under the authority of the routers/gateways connecting the two domains, and those gateways are configured 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] 👑 That gives integrity and replay protection for OLSRv2 control messages, including the HELLO messages specified by [RFC6130] and used by OLSRv2, using 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 is short-lived OLSRv2 deployments (for example, up to a couple of months). For those, this security mechanism gives adequate integrity protection without rekeying 🦋

Any OLSRv2 deployment SHOULD use the security mechanism specified in [RFC7183] 💅 It MAY use another mechanism if that's more appropriate for the OLSRv2 deployment 🌈 For example, for longer-term OLSRv2 deployments, alternative security mechanisms (e.g., rekeying) SHOULD be considered 🧠

23.6. Key Management ✨

okay so this one's about key management, and the spec is like "we are NOT making automated key management (AKM) mandatory for OLSRv2 🙅‍♀️." that goes for this spec and [RFC7183] too. AKM might be needed for some OLSRv2 use cases, but the baseline assumption is that a lot of them don't need it, and here's why 💅

Bootstrapping a key is hard in a radio network 📡 Generally you can't tell where a received signal came from, or whether two transmissions are from the same source or different ones. It's giving chaos 😭

Radio networks and mobile phone networks already work because (i) secret info gets baked into phones at manufacture, and (ii) a centralized database of that info is reachable for the whole life of the network 🫶

BUT a primary use case of a MANET is connectivity without centralized entities and with minimal management 🦋 So a setup like the one in the paragraph above is just not feasible. A cryptographic authority might not even exist in the MANET, since it would be too vulnerable 💀 And because the topology of a MANET can change a lot, a cryptographic authority could become unreachable (for some or all of the MANET routers) with zero warning 😩

[BCP107] has guidelines for cryptographic key management ✨ Section 2.1 covers when AKM is required, and Section 2.2 covers when manual key management is acceptable.

Section 2.1 of [BCP107] says "Automated key management MUST be used if any of [a set of given] conditions hold". Here are those conditions, with how each one applies to the baseline OLSRv2 use case 👑

A party will have to manage n^2 static keys, where n may become large.

The baseline OLSRv2 use case only uses one shared secret, or a small set of manually managed ones, across the whole MANET. So not a problem 🌸

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 isn't planned for generating ICVs for OLSRv2 control messages 🙈

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 isn't planned for generating ICVs for OLSRv2 control messages either 🧚

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 only needed for OLSRv2 control messages, and those are low-volume messages 🍓

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.

All OLSRv2 control messages are sent using link-local multicast 📣

The likely operational environment is one where personnel (or device) turnover is frequent, causing frequent change of the short-term session key.

This isn't an intended deployment of OLSRv2. For longer-term OLSRv2 deployments, alternative security mechanisms (e.g., including rekeying) SHOULD be considered 🔥

Section 2.2 of [BCP107] says "Manual key management may be a reasonable approach in any of [a given set of] situations". Here are those situations and how they apply to the baseline OLSRv2 use case 💜

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.

Like we said before, there may not be the required infrastructure (a cryptographic authority) in the MANET, or if there is one, it might not be reachable 😭 Bandwidth in a MANET is usually limited, both because it's a radio environment and because any signaling has to eat up only a minimal proportion of it. Round trip times can also be significant ⏳

The information being protected has low value.

This depends on the OLSRv2 use case, but the info being protected is OLSRv2 control traffic, which has at least moderate value. So this case does not apply 🙅‍♀️

The total volume of traffic over the entire lifetime of the long-term session key will be very low.

ICVs are only needed for OLSRv2 control messages, which are low-volume messages 💅

The scale of each deployment is very limited.

A typical OLSRv2 use case might only involve tens of devices, and even the biggest ones are small by Internet standards 🎀

24. IANA Considerations ✨

This spec defines one Message Type, which was allocated from the "Message Types" registry of [RFC5444]. It also defines two Message TLV Types, allocated from the "Message TLV Types" registry of [RFC5444], and four Address Block TLV Types, allocated from the "Address Block TLV Types" registry of [RFC5444] 📋

24.1. Expert Review: Evaluation Guidelines

For the registries that need an Expert Review, the designated expert SHOULD take the same general recommendations into consideration as the ones specified by [RFC5444] 🧐

24.2. Message Types

This spec 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 made a registry for Message-Type-specific Message TLVs for TC messages, following Section 6.2.1 of [RFC5444], 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 also made a registry for Message-Type-specific Address Block TLVs for TC messages, following Section 6.2.1 of [RFC5444], 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

24.4. Message TLV Types

This spec defines two Message TLV Types, allocated from the "Message TLV Types" namespace defined in [RFC5444]. IANA made allocations in the 0-127 range for these types. Two new Type Extension registries were created, with assignments as specified in Table 11 and Table 12. The specs for 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

+--------------+------+-----------+--------------------+------------+
|     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 marked as Expert Review SHOULD be allocated as described in [RFC5444], based on Expert Review as defined in [RFC5226] 🎀

24.5. Address Block TLV Types 💅

Okay bestie, this part is all about the four Address Block TLV Types 🦋 They were grabbed from the "Address Block TLV Types" namespace that [RFC5444] set up, and IANA gave them numbers in the 8-127 range. There are also four new Type Extension registries, with the assignments in Tables 13, 14, 15, and 16. The full specs for these TLVs live 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

Okay so every LINK_METRIC TLV, no matter what its type extension is, MUST use its value field to encode the kind and value of a link metric 🔥 The value has to sit somewhere in the interval MINIMUM_METRIC to MAXIMUM_METRIC (inclusive), and Sections 6 and 13.3.2 explain how. Also, whoever assigns a LINK_METRIC TLV type extension MUST specify the physical meaning of that link metric, plus how that meaning maps onto the representable values in the interval. It's giving precision 🎀

+------+------+-----------+----------------------------+------------+
| 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

+---------------+------+-----------+-------------------+------------+
|      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

Any type extension marked Expert Review SHOULD be allocated the way [RFC5444] describes, based on Expert Review as defined in [RFC5226] 🫶

24.6. NBR_ADDR_TYPE and MPR Values 🍓

Note: This section does not require any IANA action, since the info it needs is already in the descriptions of the MPR and NBR_ADDR_TYPE Address Block TLVs allocated in Section 24.5. It's recorded here just for clarity and so it can be used elsewhere in this specification 🧚

The values the MPR Address Block TLV can use are:

FLOODING := 1;
ROUTING := 2;
FLOOD_ROUTE := 3.

The values the NBR_ADDR_TYPE Address Block TLV can use are:

ORIGINATOR := 1;
ROUTABLE := 2;
ROUTABLE_ORIG := 3.

25. Contributors 👯

This specification is the result of the joint efforts of the following contributors, listed alphabetically 🌈

Cedric Adjih, INRIA, France, <Cedric.Adjih@inria.fr>
Emmanuel Baccelli, INRIA , France, <Emmanuel.Baccelli@inria.fr>
Thomas Heide Clausen, LIX, France, <T.Clausen@computer.org>
Justin Dean, NRL, USA, <jdean@itd.nrl.navy.mil>
Christopher Dearlove, BAE Systems, UK, <chris.dearlove@baesystems.com>
Ulrich Herberg, Fujitsu Laboratories of America, USA, <ulrich@herberg.name>
Satoh Hiroki, Hitachi SDL, Japan, <hiroki.satoh.yj@hitachi.com>
Philippe Jacquet, Alcatel Lucent Bell Labs, France, <philippe.jacquet@alcatel-lucent.fr>
Monden Kazuya, Hitachi SDL, Japan, <kazuya.monden.vw@hitachi.com>
Kenichi Mase, Niigata University, Japan, <mase@ie.niigata-u.ac.jp>
Ryuji Wakikawa, Toyota, Japan, <ryuji@sfc.wide.ad.jp>

26. Acknowledgments 🌸

The authors want to shout out 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 also want to thank 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 are so grateful to the Area Directors for their 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.
[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

okay so bestie, this is the reading list for the stuff that's helpful but not required to implement OLSRv2 🎀 ✨

[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.

[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.

Appendix A. Constraints 💅

okay this is the rulebook for the data stores 🧚 the Local Information Base, the Neighborhood Information Base, and the Topology Information Base. ANY update to them MUST keep every constraint in here (plus the ones in [RFC6130]) happy. this is true for the processing in this document, and ANY protocol extension or outside process that touches the NIB or TIB MUST ALSO keep these constraints maintained. no exceptions, bestie 😭

In each Originator Tuple:

O_orig_addr MUST NOT equal any other O_orig_addr.
O_orig_addr MUST NOT equal this router's originator address.

In each Local Attached Network Tuple:

AL_net_addr MUST NOT equal any other AL_net_addr.
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.
AL_net_addr MUST NOT equal this router's originator address or equal the O_orig_addr in any Originator Tuple.
AL_dist MUST NOT be less than zero.

In each Link Tuple:

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.
If L_in_metric != UNKNOWN_METRIC, then L_in_metric MUST be representable in the defined compressed form.
If L_out_metric != UNKNOWN_METRIC, then L_out_metric MUST be representable in the defined compressed form.
If L_mpr_selector = true, then L_status = SYMMETRIC.

In each Neighbor Tuple:

N_orig_addr MUST NOT be changed to unknown.
N_orig_addr MUST NOT equal this router's originator address or equal O_orig_addr in any Originator Tuple.
N_orig_addr MUST NOT equal the AL_net_addr in any Local Attached Network Tuple.
If N_orig_addr != unknown, then N_orig_addr MUST NOT equal the N_orig_addr in any other Neighbor Tuple.
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.
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.
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.
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.
N_will_flooding and N_will_routing MUST be in the range from WILL_NEVER to WILL_ALWAYS, inclusive.
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.
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.
If N_symmetric = true and N_flooding_mpr = false, then N_will_flooding MUST NOT equal WILL_ALWAYS.
If N_symmetric = true and N_routing_mpr = false, then N_will_routing MUST NOT equal WILL_ALWAYS.
If N_mpr_selector = true, then N_advertised MUST be true.
If N_advertised = true, then N_symmetric MUST be true and N_out_metric MUST NOT equal UNKNOWN_METRIC.

In each Lost Neighbor Tuple:

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:

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.
If N2_in_metric != UNKNOWN_METRIC, then N2_in_metric MUST be representable in the defined compressed form.
If N2_out_metric != UNKNOWN_METRIC, then N2_out_metric MUST be representable in the defined compressed form.

In each Advertising Remote Router Tuple:

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.
AR_orig_addr MUST NOT equal this router's originator address or equal the O_orig_addr in any Originator Tuple.
AR_orig_addr MUST NOT be in the AL_net_addr in any Local Attached Network Tuple.
AR_orig_addr MUST NOT equal the AR_orig_addr in any other Advertising Remote Router Tuple.

In each Router Topology Tuple:

There MUST be an Advertising Remote Router Tuple with AR_orig_addr = TR_from_orig_addr.
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.
TR_to_orig_addr MUST NOT equal this router's originator address or equal the O_orig_addr in any Originator Tuple.
TR_to_orig_addr MUST NOT be in the AL_net_addr in any Local Attached Network Tuple.
The ordered pair (TR_from_orig_addr, TR_to_orig_addr) MUST NOT equal the corresponding pair for any other Router Topology Tuple.
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.
TR_metric MUST be representable in the defined compressed form.

In each Routable Address Topology Tuple:

There MUST be an Advertising Remote Router Tuple with AR_orig_addr = TA_from_orig_addr.
TA_dest_addr MUST be routable.
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.
TA_dest_addr MUST NOT include this router's originator address or include the O_orig_addr in any Originator Tuple.
TA_dest_addr MUST NOT equal or have as a sub-range the AL_net_addr in any Local Attached Network Tuple.
The ordered pair (TA_from_orig_addr, TA_dest_addr) MUST NOT equal the corresponding pair for any other Attached Network Tuple.
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.
TA_metric MUST be representable in the defined compressed form.

In each Attached Network Tuple:

There MUST be an Advertising Remote Router Tuple with AR_orig_addr = AN_orig_addr.
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.
AN_net_addr MUST NOT equal this router's originator address or equal the O_orig_addr in any Originator Tuple.
The ordered pair (AN_orig_addr, AN_net_addr) MUST NOT equal the corresponding pair for any other Attached Network Tuple.
AN_seq_number MUST NOT be greater than AR_seq_number in the Advertising Remote Router Tuple with AR_orig_addr = AN_orig_addr.
AN_dist MUST NOT be less than zero.
AN_metric MUST be representable in the defined compressed form.

Appendix B. Example Algorithm for Calculating MPRs 🍓

okay so this part is an example algorithm for picking the MPR Set from a Neighbor Graph (see Section 18.2 and Section 18.3). it's totally allowed to use it, it MAY be used, but it's just one option 💜

this algorithm picks an MPR Set M that's a subset of the set N1 in the Neighbor Graph. it assumes a subset I of N1 is already pre-selected as MPRs, so M will contain I 🦋

B.1. Additional Notation 🧮

Okay so, on top of the notation from Section 18.2, this algorithm brings in a few extra definitions 💅

N: a subset of N2, made of the elements y in N2 where 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).)

B.2. MPR Selection Algorithm 🌸

Here's how we build the MPR Set. We start with M := I and then work through these steps:

Add all elements x in N1 that have W(x) = WILL_ALWAYS to M.
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.
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 it 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.
OPTIONAL: consider each element x in M, but not in I, in turn. 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. 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. 💖

C.1. Local Interfaces and Neighbors 🎀

The following selections and definitions are made:

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.
For each Link Tuple, the selected address of its corresponding Local Interface Tuple is defined as the selected local address for this Link Tuple.
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.
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:

The selected local address is defined as the selected local address for the selected Link Tuple.
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.

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.

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. 🔥