RFC 5449

OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks

📅 published February 2009, from ietf

RFC 5449: OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks 🦋

Okay bestie, RFC 5449 is an Experimental doc (📄 not a standard!) about tweaking OSPFv3 so it works on mobile ad hoc networks (MANETs). It was written in February 2009 by E. Baccelli, P. Jacquet, T. Clausen, and D. Nguyen. Baccelli and Jacquet are at INRIA, Nguyen is at CRC, and Clausen is at LIX, Ecole Polytechnique. Its title block doesn't list any RFC that it obsoletes or updates, so it's standing on its own. 💅

Status of This Memo ✨

This memo defines an Experimental Protocol for the Internet community. 🧪 It does not specify an Internet standard of any kind, and the authors are asking for discussion and suggestions for improvement. Distribution of this memo is unlimited. 🌈

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 📜

Abstract 🌸

This doc specifies an OSPFv3 interface type made for mobile ad hoc networks. It's derived from the broadcast interface type, and it's called the "OSPFv3 MANET interface type". 🦋

Table of Contents 📚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  5
  3.1.  MANET Characteristics  . . . . . . . . . . . . . . . . . .  5
  3.2.  OSPFv3 MANET Interface Characteristics . . . . . . . . . .  5
4.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  6
  4.1.  Efficient Flooding Using MPRs  . . . . . . . . . . . . . .  6
  4.2.  MPR Topology-Reduction . . . . . . . . . . . . . . . . . .  6
  4.3.  Multicast Transmissions of Protocol Packets  . . . . . . .  7
  4.4.  MPR Adjacency-Reduction  . . . . . . . . . . . . . . . . .  7
5.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . .  7
  5.1.  Data Structures  . . . . . . . . . . . . . . . . . . . . .  7
    5.1.1.  N(i): Symmetric 1-Hop Neighbor Set . . . . . . . . . .  7
    5.1.2.  N2(i): Symmetric Strict 2-Hop Neighbor Set . . . . . .  8
    5.1.3.  Flooding-MPR Set . . . . . . . . . . . . . . . . . . .  8
    5.1.4.  Flooding-MPR-Selector Set  . . . . . . . . . . . . . .  9
    5.1.5.  Path-MPR Set . . . . . . . . . . . . . . . . . . . . .  9
    5.1.6.  Path-MPR-Selector Set  . . . . . . . . . . . . . . . . 10
    5.1.7.  MPR Set  . . . . . . . . . . . . . . . . . . . . . . . 10
    5.1.8.  MPR-Selector Set . . . . . . . . . . . . . . . . . . . 10
  5.2.  Hello Protocol . . . . . . . . . . . . . . . . . . . . . . 10
    5.2.1.  Flooding-MPR Selection . . . . . . . . . . . . . . . . 11
    5.2.2.  Flooding-MPR Selection Signaling - FMPR TLV  . . . . . 11
    5.2.3.  Neighbor Ordering  . . . . . . . . . . . . . . . . . . 12
    5.2.4.  Metric Signaling - METRIC-MPR TLV and PMPR TLV . . . . 12
    5.2.5.  Path-MPR Selection . . . . . . . . . . . . . . . . . . 12
    5.2.6.  Path-MPR Selection Signaling - PMPR TLV  . . . . . . . 12
    5.2.7.  Hello Packet Processing  . . . . . . . . . . . . . . . 13
  5.3.  Adjacencies  . . . . . . . . . . . . . . . . . . . . . . . 13
    5.3.1.  Packets over 2-Way Links . . . . . . . . . . . . . . . 14
    5.3.2.  Adjacency Conservation . . . . . . . . . . . . . . . . 14
  5.4.  Link State Advertisements  . . . . . . . . . . . . . . . . 14
    5.4.1.  LSA Flooding . . . . . . . . . . . . . . . . . . . . . 15
    5.4.2.  Link State Acknowledgments . . . . . . . . . . . . . . 17
  5.5.  Hybrid Routers . . . . . . . . . . . . . . . . . . . . . . 18
  5.6.  Synch Routers  . . . . . . . . . . . . . . . . . . . . . . 18
  5.7.  Routing Table Computation  . . . . . . . . . . . . . . . . 18
6.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 19
  6.1.  Flooding-MPR  TLV  . . . . . . . . . . . . . . . . . . . . 19
  6.2.  Metric-MPR TLV . . . . . . . . . . . . . . . . . . . . . . 19
  6.3.  Path-MPR TLV . . . . . . . . . . . . . . . . . . . . . . . 22
7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
  9.1.  Normative References . . . . . . . . . . . . . . . . . . . 26
  9.2.  Informative References . . . . . . . . . . . . . . . . . . 26

Appendix A.  Flooding-MPR Selection Heuristic  . . . . . . . . . . 28
Appendix B.  Path-MPR Selection Heuristic  . . . . . . . . . . . . 29
Appendix C.  Contributors  . . . . . . . . . . . . . . . . . . . . 30
Appendix D.  Acknowledgments . . . . . . . . . . . . . . . . . . . 30

1. Introduction 💖

This document extends OSPFv3 [RFC5340] so it fits mobile ad hoc networks (MANETs) [RFC2501]. The extension uses three mechanisms:

  • Flooding-reduction: only a subset of all routers takes part in (re)transmissions during a flooding operation. 🌊
  • Topology-reduction: only a subset of links gets advertised, so both the number and the size of Link State Advertisements (LSAs) go down. ✂️
  • Adjacency-reduction: adjacencies only come up with a subset of neighbors, which means less database synchronization overhead. 🧠

These mechanisms are based on multipoint relays (MPR), a technique first developed in the Optimized Link State Routing Protocol (OLSR) [RFC3626]. 🪄

The extension in this document plugs into the OSPF framework by defining the OSPFv3 MANET interface type. ✨ OSPFv3 gets to run efficiently on mobile ad hoc networks, but operation on other interface or network types, or in areas without OSPFv3 MANET interfaces, stays exactly the same. 🫶

2. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🙈

This document uses OSPF terminology from [RFC2328] and [RFC5340], and Link-Local Signaling (LLS) terminology from [RFC4813]. It also adds the following term to the OSPF nomenclature:

  • OSPFv3 MANET interface - the OSPFv3 interface type for MANETs, as specified in this document. 🦋

These extra terms are used too:

  • MANET router - a router that has only OSPFv3 MANET interfaces. 📡
  • Wired router - a router that has only OSPFv3 interfaces of types other than OSPFv3 MANET interfaces. 🔌
  • Hybrid router - a router that has OSPFv3 interfaces of several types, including at least one OSPFv3 MANET interface type. 🧩
  • Neighbor - a router, reachable through an OSPFv3 interface (of any type). 👋
  • MANET neighbor - a neighbor, reachable through an OSPFv3 MANET interface. 📶
  • Symmetric 1-hop neighbor - a neighbor in a state greater than or equal to 2-Way (through an interface of any type). 🤝
  • Symmetric strict 2-hop neighbor - a symmetric 1-hop neighbor of a symmetric 1-hop neighbor, which is not itself a symmetric 1-hop neighbor of the considered router. 👀
  • Symmetric strict 2-hop neighborhood - the set formed by all the symmetric strict 2-hop neighbors of the considered router. 🗺️
  • Synch router - a router that brings up adjacencies with all of its MANET neighbors. 🔗
  • Flooding-MPR - a router that is selected by its symmetric 1-hop neighbor, router X, to retransmit all broadcast protocol packets it receives from router X, as long as the broadcast protocol packet is not a duplicate and the Hop Limit field of the protocol packet is greater than one. 📣
  • Path-MPR - a router that is selected by a symmetric 1-hop neighbor, X, as being on the shortest path from a router in the symmetric strict 2-hop neighborhood of router X to router X. 🛣️
  • Multipoint relay (MPR) - a router that is selected by its symmetric 1-hop neighbor as either a Flooding-MPR, a Path-MPR, or both. 🎯
  • Flooding-MPR-selector - a router that has selected its symmetric 1-hop neighbor, router X, as one of its Flooding-MPRs, is a Flooding-MPR-selector of router X. 💌
  • Path-MPR-selector - a router that has selected its symmetric 1-hop neighbor, router X, as one of its Path-MPRs, is a Path-MPR selector of router X. 💌
  • MPR-selector - a router that has selected its symmetric 1-hop neighbor, router X, as either one of its Flooding-MPRs, one of its Path-MPRs, or both, is an MPR-selector of router X. 💅

3. Applicability Statement 🌷

The OSPFv3 MANET interface type defined in this spec lets OSPFv3 be deployed within an area where parts of that area are a mobile ad hoc network (MANET) with moderate mobility properties. 🚀

3.1. MANET Characteristics 🌪️

MANETs [RFC2501] are networks where a dynamic topology is a frequently expected condition. This often comes from router mobility and/or from wireless links with changing quality. The second one also usually brings bandwidth scarcity and interference between neighbors, so it's a lot. 😭

MANETs also often show "semi-broadcast" behavior. In other words, when a router R makes a transmission inside a MANET, it can only assume that the transmission gets received by a subset of the total routers in that MANET. And if two routers, R1 and R2, each make a transmission, neither one is guaranteed to be received by the same subset of routers, even if R1 and R2 can hear each other just fine. 🙃

These characteristics clash with several OSPFv3 mechanisms. That includes existing control-traffic reduction mechanisms like flooding-reduction, topology-reduction, and adjacency-reduction (for example, Designated Router). 🚫

3.2. OSPFv3 MANET Interface Characteristics ✨

okay so an interface of the OSPFv3 MANET interface type is basically the spot where an OSPFv3 router plugs into a network that might have MANET characteristics 🌸 and it's built to handle those characteristics from Section 3.1. bestie, this type is NOT demanding that the network behave a certain way 💅 it's describing the rough conditions that protocols on that link have to survive and still work correctly, even when faced with the Section 3.1 stuff. it's giving umbrella energy 🦋 because the OSPFv3 MANET interface type is a generalization of the other OSPFv3 interface types. a protocol that runs correctly over an OSPFv3 MANET interface would also run correctly over an OSPFv3 broadcast interface, but the reverse isn't necessarily true, so don't assume it 🙈

ngl efficient OSPFv3 over MANETs is all about cutting down on control traffic and using stuff that actually fits semi-broadcast links 🔥 so this type brings MANET-friendly tricks into the OSPFv3 framework by mixing in flooding-reduction, topology-reduction, and adjacency-reduction. those tricks were pulled from solutions that the MANET working group standardized. iconic teamwork 👑

4. Protocol Overview and Functioning ✨

okay bestie, this spec uses flooding-reduction, topology-reduction, and adjacency-reduction, and all three are built on MPR 🦋 which is a technique derived from [RFC3626] and standardized in the MANET working group. also, multicast transmissions of protocol packets get used whenever that's possible 🫶

4.1. Efficient Flooding Using MPRs

okay so OSPFv3 MANET interfaces use a flooding-reduction mechanism called MPR flooding [MPR] 💖 only a subset of MANET neighbors takes part in a flood, specifically the ones picked as Flooding-MPR. this cuts down how many (re)transmissions a flood needs [MPR-analysis], and it still stays resilient to transmission errors (which are totally a thing on wireless links) and to obsolete two-hop neighbor info, like when routers keep moving around [MPR-robustness]. main character resilience 😭✨

4.2. MPR Topology-Reduction

okay so OSPFv3 MANET interfaces also have a topology-reduction mechanism, called MPR topology-reduction 🌈 routers only put the necessary links to MANET neighbors into LSAs, meaning the ones identified by Path-MPR selection as being on shortest paths. routers in a MANET periodically generate and flood Router-LSAs that describe which links they picked to their Path-MPRs 🧚 those links get reported as point-to-point links. this shrinks the LSAs that routers on a MANET originate [MPR-topology], and it keeps the classic OSPF vibes: optimal paths using synchronized adjacencies (if synchronized paths are preferred over non-synchronized paths of equal cost). slay 💅

4.3. Multicast Transmissions of Protocol Packets

okay so OSPFv3 MANET interfaces use multicast whenever it makes sense 🍓 that way they take advantage of the medium's inherent broadcast capabilities, if the medium has them. with wireless interfaces that's often the case [RFC2501]. LSA acknowledgments are sent via multicast over these interfaces, and retransmissions over the same interfaces count as implicit acknowledgments, which is so clever 🧠 jitter management, like delaying packet (re)transmission, can be used so that several packets get bundled into one transmission. that might help avoid pointless retransmissions caused by packet collisions [RFC5148] 🌸

4.4. MPR Adjacency-Reduction

lowkey the big idea here: adjacencies over OSPFv3 MANET interfaces are only formed with a subset of the interface's neighbors 💜 no Designated Router or Backup Designated Router gets elected on an OSPFv3 MANET interface, so it's giving no DR drama 🙅‍♀️ instead, adjacencies only come up with MPRs and MPR selectors. only a small subset of routers in the MANET, called Synch routers, has to bring up adjacencies with all of its MANET neighbors ✨ this cuts the control traffic needed for database synchronization, and LSAs still only describe synchronized adjacencies. genius, honestly 🫶

5. Protocol Details

okay bestie, this section adds to [RFC5340] and spells out the info that routers running one or more OSPFv3 MANET interfaces must keep track of, process, and send 🎀

5.1. Data Structures

so in addition to the values from [RFC5340], the Type field in the interface data structure can take a brand new value, "MANET" 🦋 routers running one or more MANET interfaces also use the data structures below, on top of the protocol structures from [RFC5340] 💖

5.1.1. N(i): Symmetric 1-Hop Neighbor Set

the Symmetric 1-hop Neighbor set N(i) records router IDs of the symmetric 1-hop neighbors of the router on interface i 🌸 more precisely, it records tuples shaped like this:

(1_HOP_SYM_id, 1_HOP_SYM_time)

where:

  • 1_HOP_SYM_id: is the router ID of the symmetric 1-hop neighbor of this router over interface i.
  • 1_HOP_SYM_time: specifies the time at which the tuple expires, and it MUST be removed from the set ⏰

for convenience throughout this document, N is the union of all N(i) sets for all MANET interfaces on the router 💅

5.1.2. N2(i): Symmetric Strict 2-Hop Neighbor Set

the Symmetric strict 2-hop Neighbor set N2(i) records links between routers in N(i) and their symmetric 1-hop neighbors, but it EXCLUDES a couple of things 🙈 specifically:

  • (i) the router performing the computation, and
  • (ii) all routers in N(i).

more precisely, it records tuples shaped like this:

(2_HOP_SYM_id, 1_HOP_SYM_id, 2_HOP_SYM_time)

where:

  • 2_HOP_SYM_id: is the router ID of a symmetric strict 2-hop neighbor.
  • 1_HOP_SYM_id: is the router ID of the symmetric 1-hop neighbor of this router through which the symmetric strict 2-hop neighbor can be reached.
  • 2_HOP_SYM_time: specifies the time at which the tuple expires, and it MUST be removed from the set ⏳

for convenience throughout this document, N2 is the union of all N2(i) sets for all MANET interfaces on the router 🧚

5.1.3. Flooding-MPR Set

the Flooding-MPR set on interface i records router IDs of a subset of the routers listed in N(i), picked so that, through this subset, every router listed in N2(i) is reachable in 2 hops by this router 🌈 there's one Flooding-MPR set per MANET interface. more precisely, it records tuples shaped like this:

(Flooding_MPR_id, Flooding_MPR_time)

where:

  • Flooding_MPR_id: is the router ID of the symmetric 1-hop neighbor of this router that gets selected as a Flooding-MPR.
  • Flooding_MPR_time: specifies the time at which the tuple expires, and it MUST be removed from the set.

Flooding-MPR selection is detailed in Section 5.2.1 💖

5.1.4. Flooding-MPR-Selector Set

the Flooding-MPR-selector set on interface i records router IDs of the symmetric 1-hop neighbors of this router on interface i that picked this router as their Flooding-MPR 🫶 there's one Flooding-MPR-selector set per MANET interface. more precisely, it records tuples shaped like this:

(Flooding_MPR_SELECTOR_id, Flooding_MPR_SELECTOR_time)

where:

  • Flooding_MPR_SELECTOR_id: is the router ID of the symmetric 1-hop neighbor of this router that has selected this router as its Flooding-MPR.
  • Flooding_MPR_SELECTOR_time: specifies the time at which the tuple expires, and it MUST be removed from the set.

Flooding-MPR selection is detailed in Section 5.2.1 🦋

5.1.5. Path-MPR Set

the Path-MPR set records router IDs of routers in N that provide shortest paths from routers in N2 to this router 🌸 there's one Path-MPR set per router. more precisely, it records tuples shaped like this:

(Path_MPR_id, Path_MPR_time)

where:

  • Path_MPR_id: is the router ID of the symmetric 1-hop neighbor of this router, selected as Path-MPR.
  • Path_MPR_time: specifies the time at which the tuple expires, and it MUST be removed from the set.

Path-MPR selection is detailed in Section 5.2.5 ✨

5.1.6. Path-MPR-Selector Set

the Path-MPR-selector set records router IDs of the symmetric 1-hop neighbors over any MANET interface that picked this router as their Path-MPR 🧚 there's one Path-MPR-selector set per router. more precisely, it records tuples shaped like this:

(Path_MPR_SELECTOR_id, Path_MPR_SELECTOR_time)

where:

  • Path_MPR_SELECTOR_id: is the router ID of the symmetric 1-hop neighbor of this router that has selected this router as its Path-MPR.
  • Path_MPR_SELECTOR_time: specifies the time at which the tuple expires, and it MUST be removed from the set.

Path-MPR selection is detailed in Section 5.2.5 💜

5.1.7. MPR Set

the MPR set is the union of the Flooding-MPR set(s) and the Path-MPR set 🎀 there's one MPR set per router.

5.1.8. MPR-Selector Set

the MPR-selector set is the union of the Flooding-MPR-selector set(s) and the Path-MPR-selector set 🌈 there's one MPR-selector set per router.

5.2. Hello Protocol

okay so on OSPFv3 MANET interfaces, packets are sent, received, and processed as defined in [RFC5340] and [RFC2328], just augmented for MPR selection the way this section describes 💅

all the extra signaling for OSPFv3 MANET interfaces happens by putting TLVs inside an LLS block [RFC4813], which gets appended to Hello packets ✨ if there isn't already an LLS block, an LLS block MUST be created and appended to the Hello packets 🫶

Hello packets sent over an OSPFv3 MANET interface MUST have the L bit of the OSPF Options field set, as per [RFC4813], which indicates that an LLS block is present 🦋

this document defines and uses the following TLVs in Hello packets sent over OSPFv3 MANET interfaces 🍓

  • FMPR - signaling Flooding-MPR selection;
  • PMPR - signaling Path-MPR selection;
  • METRIC-MPR - signaling metrics.

the layout and internal structure of these TLVs is detailed in Section 6 🧚

5.2.1. Flooding-MPR Selection

okay bestie, the whole point of Flooding-MPR selection is for a router to pick a subset of its neighbors so that a packet retransmitted by those picked neighbors gets received by every router 2 hops away 💖 this is called the Flooding-MPR "coverage criterion" 🔥 the Flooding-MPR set of a router is computed so that, for each OSPFv3 MANET interface, it satisfies this criterion. the info needed for that calculation (link sensing and neighborhood info) comes from periodic exchange of OSPFv3 Hello packets 🌸

every router running at least one OSPFv3 MANET interface computes its Flooding-MPRs 🌈 the smaller the Flooding-MPR set is, the lower the overhead will be 🙈 but it's not essential for the set to be minimal. the "coverage criterion" MUST be satisfied by the selected Flooding-MPR set, though 💅

a neighbor router's willingness to act as a Flooding-MPR MAY be taken into consideration by a heuristic for Flooding-MPR selection 🧚 there's an example heuristic that takes willingness into account in Appendix A ✨

5.2.2. Flooding-MPR Selection Signaling - FMPR TLV 🎀

okay so a router MUST tell its neighbors who its Flooding-MPRs are by putting an FMPR TLV in every Hello packet it generates 💌 That TLV does two jobs. It lists the symmetric 1-hop neighbors this router picked as Flooding-MPRs, and it shows how willing the router is to get picked as a Flooding-MPR by everyone else 🫶 The FMPR TLV structure is detailed in Section 6.1 ✨

5.2.3. Neighbor Ordering 🦋

neighbors listed in Hello packets sent over OSPFv3 MANET interfaces MUST be included in the order given below 📋

  1. symmetric 1-hop neighbors that are selected as Flooding-MPRs;
  2. other symmetric 1-hop neighbors;
  3. other 1-hop neighbors.

this ordering is what lets the receiver correctly interpret an included FMPR TLV 🧚

5.2.4. Metric Signaling - METRIC-MPR TLV and PMPR TLV 💜

Hello packets sent over OSPFv3 MANET interfaces MUST advertise the costs of links towards ALL the symmetric MANET neighbors of the sending router. If the sending router has more than one OSPFv3 MANET interface, links to ALL the symmetric MANET neighbors over ALL the OSPFv3 MANET interfaces of that router MUST have their costs advertised. bestie, that's a lot of links 😭

the costs of the links between the router and each of its MANET neighbors on the OSPFv3 MANET interface over which the Hello packet is sent MUST be signaled by including METRIC-MPR TLVs. The METRIC-MPR TLV structure is detailed in Section 6.2.

moreover, the lowest cost from each MANET neighbor towards the router (regardless of over which interface) MUST be specified in the included PMPR TLV. Note that the lowest cost can be over an interface that is not an OSPFv3 MANET interface 👀

5.2.5. Path-MPR Selection 🌸

a router that has one or more OSPFv3 MANET interfaces MUST select a Path-MPR set from among routers in N. Routers in the Path-MPR set of a router are the ones that take part in the shortest (with respect to the metrics used) path from routers in N2 to this router. A heuristic for Path-MPR selection is given in Appendix B 🧠

5.2.6. Path-MPR Selection Signaling - PMPR TLV 🍓

a router MUST signal its Path-MPR set to its neighbors by including a PMPR TLV in generated Hello packets.

a PMPR TLV MUST contain a list of IDs of all symmetric 1-hop neighbors of all OSPFv3 MANET interfaces of the router. These IDs MUST be included in the PMPR TLV in the order given below:

  1. Neighbors that are both adjacent AND selected as Path-MPR for any OSPFv3 MANET interface of the router generating the Hello packet.
  2. Neighbors that are adjacent over any OSPFv3 MANET interface of the router generating the Hello packet.
  3. Symmetric 1-hop neighbors on any OSPFv3 MANET interface of the router generating the Hello packet that have not been previously included in this PMPR TLV.

the list of neighbor IDs is followed by a list of costs for the links from these neighbors to the router generating the Hello packet containing this PMPR TLV, as detailed in Section 5.2.4. The PMPR TLV structure is detailed in Section 6.3 💅

5.2.7. Hello Packet Processing 🔥

in addition to the processing specified in [RFC5340], N and N2 MUST be updated when received Hello packets indicate changes to the neighborhood of an OSPFv3 MANET interface i. In particular, if a received Hello packet signals that a tuple in N (or N2) is to be deleted, the deletion is done immediately, without waiting for the tuple to expire. Note that N2 records not only 2-hop neighbors listed in received Hellos but also 2-hop neighbors listed in the appended PMPR TLVs.

the Flooding-MPR set MUST be recomputed when either of N(i) or N2(i) has changed. The Path-MPR set MUST be recomputed when either of N or N2 has changed. Moreover, the Path-MPR set MUST be recomputed if appended LLS information signals change with respect to one or more link costs.

the Flooding-MPR-selector set and the Path-MPR-selector set MUST be updated upon receipt of a Hello packet containing LLS information indicating changes in the list of neighbors that has selected the router as MPR 🌈

if a Hello with the S bit set is received on an OSPFv3 MANET interface of a router, from a non-adjacent neighbor, the router MUST transition this neighbor's state to ExStart. 🚨

5.3. Adjacencies 🦋

adjacencies are brought up between OSPFv3 MANET interfaces as described in [RFC5340] and [RFC2328]. However, in order to reduce the control-traffic overhead over the OSPFv3 MANET interfaces, a router that has one or more such OSPFv3 MANET interfaces MAY bring up adjacencies with only a subset of its MANET neighbors.

over an OSPFv3 MANET interface, a router MUST bring up adjacencies with all MANET neighbors that are included in its MPR set and its MPR-selector set. This ensures that, beyond the first hop, routes use synchronized links (if synchronized paths are preferred over non-synchronized paths of equal cost). A router MAY bring up adjacencies with other MANET neighbors, at the expense of additional synchronization overhead 💜

when a router does not form a full adjacency with a MANET neighbor, the state of that neighbor does not progress beyond 2-Way (as defined in [RFC2328]). A router can send protocol packets, such as LSAs, to a MANET neighbor in 2-Way state. Therefore, any packet received from a symmetric MANET neighbor MUST be processed.

as with the OSPF broadcast interface [RFC2328], the next hop in the forwarding table MAY be a neighbor that is not adjacent. However, when a data packet has travelled beyond its first hop, the MPR-selection process guarantees that subsequent hops in the shortest path tree (SPT) will be over adjacencies (if synchronized paths are preferred over non-synchronized paths of equal cost) ✨

5.3.2. Adjacency Conservation 🌈

adjacencies are torn down according to [RFC2328]. When the MPR set or MPR-selector set is updated (due to changes in the neighborhood), and when a neighbor was formerly, but is no longer, in the MPR set or the MPR-selector set, then the adjacency with that neighbor is kept unless the change causes the neighbor to cease being a symmetric 1-hop neighbor.

when a router receives Hello packets from a symmetric 1-hop neighbor that ceases to list this router as being adjacent (see Section 5.2.6), the state of that neighbor MUST be changed to:

  1. 2-Way if the neighbor is not in the MPR set or MPR-selector set, or
  2. ExStart if either the neighbor is in the MPR set or MPR-selector set, or the neighbor or the router itself is a Synch router.

routers generate Router-LSAs periodically, using the format specified in [RFC5340] and [RFC2328] ⏰

routers that have one or more OSPFv3 MANET interfaces MUST include the following links in the Router-LSAs that they generate:

  • links to all neighbors that are in the Path-MPR set, AND
  • links to all neighbors that are in the Path-MPR-selector set.

routers that have one or more OSPFv3 MANET interfaces MAY list other links they have through those OSPFv3 MANET interfaces, at the expense of larger LSAs.

in addition, routers that have one or more OSPFv3 MANET interfaces MUST generate updated Router-LSAs when either of the following occurs:

  • a new adjacency has been brought up, reflecting a change in the Path-MPR set;
  • a new adjacency has been brought up, reflecting a change in the Path-MPR-selector set;
  • a formerly adjacent and advertised neighbor ceases to be adjacent;
  • the cost of a link to (or from) an advertised neighbor has changed.

5.4.1. LSA Flooding ✨

an originated LSA is flooded, according to [RFC5340], out all interfaces concerned by the scope of this LSA.

Link State Updates received on an interface of a type other than OSPFv3 MANET interface are processed and flooded according to [RFC2328] and [RFC5340], over every interface. If a Link State Update was received on an OSPFv3 MANET interface, it is processed as follows:

  1. Consistency checks are performed on the received packet according to [RFC2328] and [RFC5340], and the Link State Update packet is thus associated with a particular neighbor and a particular area.
  2. If the Link State Update was received from a router other than a symmetric 1-hop neighbor, the Link State Update MUST be discarded without further processing. 🙅‍♀️
  3. Otherwise, for each LSA contained in Link State Updates received over an OSPFv3 MANET interface, the following steps replace steps 1 to 5 of Section 13.3 of [RFC2328].
    • (1) If an LSA exists in the Link State Database, with the same Link State ID, LS Type, and Advertising Router values as the received LSA, and if the received LSA is not newer (see Section 13.1 of [RFC2328]), then the received LSA MUST NOT be processed, except for acknowledgment as described in Section 5.4.2.
    • (2) Otherwise, the LSA MUST be attributed a scope according to its type, as specified in Section 3.5 of [RFC5340].
    • (3) If the scope of the LSA is link local or reserved, the LSA MUST NOT be flooded on any interface.
    • (4) Otherwise:
      • If the scope of the LSA is the area, the LSA MUST be flooded on all the OSPFv3 interfaces of the router in that area, according to the default flooding algorithm described in Section 5.4.1.1.
      • Otherwise, the LSA MUST be flooded on all the OSPFv3 interfaces of the router according to the default flooding algorithm described in Section 5.4.1.1.

5.4.1.1. Default LSA Flooding Algorithm 🎀

the default LSA flooding algorithm is as follows:

  1. The LSA MUST be installed in the Link State Database.
  2. The Age of the LSA MUST be increased by InfTransDelay.
  3. The LSA MUST be retransmitted over all OSPFv3 interfaces of types other than OSPFv3 MANET interface.
  4. If the sending OSPFv3 interface is a Flooding-MPR-selector of this router, then the LSA MUST also be retransmitted over all OSPFv3 MANET interfaces concerned by the scope, with the multicast address all_SPF_Routers.

note that MinLSArrival SHOULD be set to a value that is appropriate to dynamic topologies: LSA updating may need to be more frequent in MANET parts of an OSPF network than in other parts of an OSPF network. this one matters a lot for MANETs, so keep it in mind 🦋

bestie, when a router receives an LSA over an OSPFv3 MANET interface, it MUST acknowledge it. How it does that depends on where the LSA came from and whether it's already in the Link State Database 🦋

  1. Not from an adjacent neighbor? Then the router MUST NOT acknowledge it. 🙅‍♀️
  2. Otherwise, if the LSA came from an adjacent neighbor and it's already in the Link State Database (aka it's already been received and processed), the router MUST send an acknowledgment for this LSA on all OSPFv3 MANET interfaces to the multicast address all_SPF_Routers. 💖
  3. Otherwise, if the LSA is not already in the Link State Database:
    1. If the router decides to retransmit the LSA (as part of the flooding procedure), the router MUST NOT acknowledge it, because that retransmission counts as an implicit acknowledgment. 🔁
    2. Otherwise, if the router decides not to retransmit the LSA (as part of the flooding procedure), the router MUST send an explicit acknowledgment for this LSA on all OSPFv3 MANET interfaces to the multicast address all_SPF_Routers. 🎀

okay so if a router sends an LSA on an OSPFv3 MANET interface, it expects acknowledgments (explicit or implicit) from all adjacent neighbors. But if the router didn't make the LSA and is only relaying it, then it MUST expect acknowledgments (explicit or implicit) only from adjacent neighbors that haven't acknowledged this LSA before. If a router notices that some adjacent neighbor still hasn't acknowledged the LSA, then that router MUST retransmit the LSA. no notes, no drama 💅

and even if the router decides not to relay an LSA because of the MPR flooding-reduction mechanism from Section 5.4.1, it MUST still expect acknowledgments of this LSA (explicit or implicit) from adjacent neighbors that haven't acknowledged it before. If a router notices that some adjacent neighbor hasn't acknowledged the LSA, then the router MUST retransmit the LSA. 😭

Note that it may be beneficial to bundle several acknowledgments into the same transmission, taking advantage of native multicasting (if it's available). A timer wait MAY thus be used before any acknowledgment transmission. ⏲️

Additionally, jitter [RFC5148] on packet (re)transmission MAY be used to increase the chances of bundling several packets together in each transmission. that's a whole vibe 🌈

5.5. Hybrid Routers ⭐

On top of the operations described in Section 5.2, Section 5.3 and Section 5.4, Hybrid routers MUST:

  • select ALL their MANET neighbors as Path-MPRs.
  • list adjacencies over OSPFv3 interfaces of types other than OSPFv3 MANET interface, as specified in [RFC5340] and [RFC2328], in generated Router-LSAs.

5.6. Synch Routers 👑

In a network with no Hybrid routers, at least one Synch router MUST be selected. A Synch router MUST:

  • set the S bit in the PMPR TLV appended to the Hello packets it generates, AND
  • become adjacent with ALL MANET neighbors.

A proposed heuristic for selection of Sync routers goes like this:

  • A router that has a MANET interface and an ID that is higher than the ID of all of its current neighbors, and whose ID is higher than any other ID present in Router-LSAs currently in its Link State Database, selects itself as Synch router.

Other heuristics are possible. However, any heuristic for selecting Synch routers MUST ensure the presence of at least one Synch or Hybrid router in the network. 🧚

5.7. Routing Table Computation 🦋

When routing table (re)computation happens, routers that have one or more MANET interfaces MUST take into account links between themselves and MANET neighbors that are in state 2-Way or higher, on top of the processing of the Link State Database defined in [RFC5340] and [RFC2328]. Data and protocol packets may be sent, received, and processed over these links too, so they matter! Thus, the connectivity matrix used to compute routes MUST reflect links between the root and all its neighbors in state 2-Way and higher, as well as links described in the Link State Database. 💜

6. Packet Formats 🌸

OSPFv3 packets are as defined by [RFC5340] and [RFC2328]. Additional LLS signaling [RFC4813] is used in Hello packets sent over OSPFv3 MANET interfaces, as detailed in this section.

This specification uses network byte order (most significant octet first) for all fields.

6.1. Flooding-MPR TLV 🍓

A TLV of Type FMPR is defined for signaling Flooding-MPR selection, shown in Figure 1.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Type=FMPR          |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Willingness  | # Sym. Neigh. |  # Flood MPR  |    Reserved   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Flooding-MPR TLV (FMPR)

where:

Willingness is an 8-bit unsigned integer field that specifies how willing the router is to flood link-state information on behalf of other routers. It can be set to any integer value from 1 to 6. By default, a router SHOULD advertise a willingness of WILL_DEFAULT = 3. 🌟

# Sym. Neigh. is an 8-bit unsigned integer field that specifies the number of symmetric 1-hop neighbors. These symmetric 1-hop neighbors are listed first among the neighbors in a Hello packet. 🦋

# Flood MPR is an 8-bit unsigned integer field that specifies the number of neighbors selected as Flooding-MPR. These Flooding-MPRs are listed first among the symmetric 1-hop neighbors. ✨

Reserved is an 8-bit field that SHOULD be cleared (('0')) on transmission and SHOULD be ignored on reception. 🙈

6.2. Metric-MPR TLV 💅

A TLV of Type METRIC-MPR is defined for signaling costs of links to neighbors, shown in Figure 2.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Type=METRIC-MPR        |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Reserved          |U|R|           Cost 0              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Cost 1              |           Cost 2              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                                                               :
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Cost n              |            Padding            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Metric TLV (METRIC-MPR)

where:

Reserved is a 14-bit field that SHOULD be cleared (('0')) on transmission and SHOULD be ignored on reception. 🫶

R is a binary flag. It's cleared (('0')) if the costs advertised in the TLV are direct (i.e., the costs of the links from the router to the neighbors), or set (('1')) if the costs advertised are reverse (i.e., the costs of the links from the neighbors to the router). By default, R is cleared (('0')). 🔥

U is a binary flag. It's cleared (('0')) if the cost for each link from the sending router and to each advertised neighbor is explicitly included (shown in Figure 3), or set (('1')) if a single metric value is included that applies to all links (shown in Figure 4). 🌈

Cost n is an 8-bit unsigned integer field that specifies the cost of the link, in the direction specified by the R flag, between this router and the neighbor listed at the n-th position in the Hello packet. Counting starts from the beginning of the Hello packet, and the first neighbor is at position 0. 🍓

Padding is a 16-bit field that SHOULD be cleared (('0')) on transmission and SHOULD be ignored on reception. Padding is included so that the TLV is 32-bit aligned. Padding MUST be included when the TLV contains an even number of Cost fields, and MUST NOT be included otherwise. ✨

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Type=METRIC-MPR        |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Reserved          |0|R|           Cost 0              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |           Cost 1              |           Cost 2              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Metric Advertisement TLV (METRIC-MPR) example with explicit individual link costs (U=0) and an odd number of Costs (and, hence, no padding).

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Type=METRIC-MPR        |           Length              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Reserved          |1|R|           Cost                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Metric Advertisement TLV (METRIC-MPR) example with a single and uniform link cost (U=1) (and, hence, no padding).

6.3. Path-MPR TLV 🦋

okay so the Path-MPR TLV is the one with type PMPR, and it's how a router signals which neighbors it picked as Path-MPRs 💅 It also carries the link cost for each of those links. Figure 1 has the layout, and the figure below it is labeled Figure 5 🎀

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Type=PMPR          |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  # Sym Neigh  |  # Adj. Neigh |   # Path-MPR  | Reserved  |U|S|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Neighbor ID                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Neighbor ID                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Cost 0            |            Cost 1             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Cost n            |            Padding            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: Path-MPR TLV (PMPR)

Here's what each field means ✨

  • # Sym Neigh is an 8-bit unsigned integer 🌸 It counts the symmetric 1-hop MANET neighbors across all of the router's OSPFv3 MANET interfaces, and those neighbors are listed in the PMPR TLV.
  • # Adj. Neigh is also an 8-bit unsigned integer, and it counts the adjacent neighbors 🦋 These adjacent neighbors come first in the list of symmetric 1-hop MANET neighbors (again, across all of the router's OSPFv3 MANET interfaces) inside the PMPR TLV.
  • # Path-MPR is an 8-bit unsigned integer that counts the MANET neighbors picked as Path-MPR 👑 The Path-MPRs are listed first among the adjacent MANET neighbors in the PMPR TLV.
  • Reserved is a 6-bit field. It SHOULD be cleared ('0') on transmission and SHOULD be ignored on reception 🫶
  • U is a binary flag 🔥 It's cleared ('0') if the cost for each link, from each advertised neighbor in the PMPR TLV and to the sending router, is explicitly included (as in Figure 6). It's set ('1') if one single metric value is included that applies to all links (as in Figure 7).
  • S is also a binary flag 🌈 It's cleared ('0') if the router brings up adjacencies only with neighbors in its MPR set and MPR-selector set, as per Section 5.3. It's set ('1') if the router brings up adjacencies with all MANET neighbors as a Synch router, as per Section 5.6.
  • Neighbor ID is a 32-bit field 💜 It holds the router ID of a symmetric 1-hop neighbor of one of the router's OSPFv3 MANET interfaces.
  • Cost n is a 16-bit unsigned integer ⭐ It gives the cost of the link going from the n-th listed advertised neighbor in the PMPR TLV towards this router. The default value is 0xFFFF (i.e., infinity), and it MUST be advertised unless information received via Hello packets from the neighbor says otherwise, in which case the received information MUST be advertised. If a neighbor can be reached through more than one interface, the cost advertised MUST be the minimum of the costs by which that neighbor can be reached 🧚
  • Padding is a 16-bit field 🍓 It SHOULD be cleared ('0') on transmission and SHOULD be ignored on reception. It's there so the PMPR TLV ends up 32-bit aligned. Padding MUST be included when the TLV contains an odd number of Cost fields, and MUST NOT be included otherwise 🙈

Figures 6 and 7 show the two ways the Cost fields can look 🌸 Figure 6 is the explicit version, with a separate cost for each link (U=0) and an even number of Cost fields, so no padding is needed:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Type=PMPR          |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  # Sym Neigh  |  # Adj. Neigh |   # Path-MPR  | Reserved  |0|S|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Neighbor ID                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Neighbor ID                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Cost 1            |            Cost 2             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                            .......                            :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Cost n-1           |            Cost n             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: Path-MPR TLV (PMPR) with explicit individual link costs (U=0) and an even number of Cost fields (hence, no padding).

Figure 7 is the lazy-but-efficient version 💅 It uses a single, uniform link cost (U=1), and that means padding is included:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Type=PMPR             |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  # Sym Neigh  |  # Adj. Neigh |   # Path-MPR  | Reserved  |1|S|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Neighbor ID                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Neighbor ID                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Cost              |            Padding            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: Path-MPR TLV (PMPR) with a single and uniform link cost (U=1) (hence, padding included).

7. Security Considerations 🔐

okay bestie, this one is serious, so read it properly 🥹 [RFC4593] covers the generic threats to routing protocols. Its applicability to OSPFv3 [RFC5340] doesn't change just because you're using OSPFv3 MANET interfaces. So the OSPFv3 MANET interface type does not introduce new security threats to [RFC5340] ✨

BUT 😭 using a wireless medium and having no infrastructure (which is what the OSPFv3 MANET interface type makes possible) may make some of the attacks described in [RFC4593] easier to pull off. Sniffing and analyzing control traffic is simpler over wireless than over wires, because you only have to be somewhere within radio range to "listen" to the wireless traffic. You don't need to sneakily wiretap the right cable(s) at all 💀

Physical signal interference is also easier over wireless than over wires 🌩️ You only have to transmit from somewhere within radio range to disrupt the communication medium, and no complex wire connection is needed.

Other types of interference (including not forwarding packets), spoofing, and different kinds of falsification or overloading (as described in [RFC4593]) are threats too, for routers using OSPFv3 MANET interfaces. Without predetermined infrastructure or authority (which the OSPFv3 MANET interface type enables), these attacks can be easier, because it's simpler to forge legitimacy 🙈

The consequence zone of a threat, and its consequence period (as defined in [RFC4593]), can also shift a little over the wireless medium compared to the same threat on wired networks 🦋 Mobility, and the fact that radio range reaches "further" than a cable, can expand the consequence zone in some cases. Meanwhile, the more dynamic nature of MANET topologies may shorten the consequence period, because harmful information (or a lack of information) gets replaced more quickly by legitimate information 🌈

8. IANA Considerations 🧚

This document defines three LLS TLVs, and type values for them have been allocated from the LLS TLV type registry defined in [RFC4813] 🌸

                +------------+------------+--------------+
                |  Mnemonic  | Type Value | Name         |
                +------------+------------+--------------+
                |    FMPR    |      3     | Flooding-MPR |
                | METRIC-MPR |      4     | Metric-MPR   |
                |    PMPR    |      5     | Path-MPR     |
                +------------+------------+--------------+

Table 1: LLS TLV Type Assignments

9. References 📚

9.1. Normative References 💖

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
  • [RFC4813] Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A. Zinin, "OSPF Link-Local Signaling", RFC 4813, March 2007.
  • [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.

9.2. Informative References 🫶

  • [MPR] Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint Relaying for Flooding Broadcast Messages in Mobile Wireless Networks", Proceedings of HICSS , 2002.
  • [MPR-analysis] Ngyuen, D. and P. Minet, "Analysis of MPR Selection in the OLSR Protocol", 2nd Int. Workshop on Performance Analysis and Enhancement of Wireless Networks, 2007.
  • [MPR-robustness] Adjih, C., Baccelli, E., Clausen, T., and P. Jacquet, "On the Robustness and Stability of Connected Dominated Sets", INRIA Research Report RR-5609, 2005.
  • [MPR-topology] Baccelli, E., Clausen, T., and P. Jacquet, "Partial Topology in an MPR-based Solution for Wireless OSPF on Mobile Ad Hoc Networks", INRIA Research Report RR-5619, 2005.
  • [RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, February 1999.
  • [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
  • [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
  • [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter Considerations in Mobile Ad Hoc Networks (MANETs)", RFC 5148, February 2008.

Appendix A. Flooding-MPR Selection Heuristic 🌸

okay so this is a proposed heuristic (basically a suggested recipe, not a mandate 💅) for picking Flooding-MPRs on interface i. The goal is that a router can reach every router in its 2-hop neighborhood by relaying through one Flooding-MPR router. main character energy fr 🦋

Here's the terminology. D(Y) is the degree of a 1-hop neighbor, router Y (where Y is a member of N(i)). That's the number of neighbors of router Y, EXCLUDING all the members of N(i) and EXCLUDING the router doing the computation. Then the heuristic goes like this. You start with an empty Flooding-MPR set, and then:

  1. Calculate D(Y), where Y is a member of N(i), for all routers in N(i).
  2. Add to the Flooding-MPR set those routers in N(i) that are the only routers to provide reachability to a router in N2(i). For example, if router B in N2(i) can be reached only through a router A in N(i), then add router A to the Flooding-MPR set. Remove the routers from N2(i) that are now covered by a router in the Flooding-MPR set.
  3. While there exist routers in N2(i) that are not covered by at least one router in the Flooding-MPR set:
    1. For each router in N(i), calculate the reachability, i.e., the number of routers in N2(i) that are not yet covered by at least one router in the Flooding-MPR set, and that are reachable through this 1-hop neighbor;
    2. Select as a Flooding-MPR the neighbor with the highest willingness among the routers in N(i) with non-zero reachability. In case of a tie among routers with the same willingness, select the router that provides reachability to the maximum number of routers in N2(i). In case of another tie between routers also providing the same amount of reachability, select as Flooding-MPR the router whose D(Y) is greater. Remove the routers from N2(i) that are now covered by a router in the Flooding-MPR set.
  4. As an optimization, consider in increasing order of willingness each router Y in the Flooding-MPR set: if all routers in N2(i) are still covered by at least one router in the Flooding-MPR set when excluding router Y, then router Y MAY be removed from the Flooding-MPR set.

Other algorithms, plus improvements on this one, are totally possible ✨. Different routers can even use different algorithms independently. Just know the algorithm used MUST provide the router with a Flooding-MPR set that fulfills the flooding coverage criterion. In other words, it MUST select a Flooding-MPR set so that any 2-hop neighbor is covered by at least one Flooding-MPR router 🫶.

Appendix B. Path-MPR Selection Heuristic 💜

this one is a proposed heuristic for calculating a Path-MPR set, so a router can reach routers in its 2-hop neighborhood through shortest paths via routers in its Path-MPR set. Here's the vocab you need:

  • A - The router performing the Path-MPR set calculation.
  • B, C, D, .... - Other routers in the network.
  • cost(A,B) - The cost of the path through the direct link, from A to B.
  • dist(C,A) - The cost of the shortest path from C to A.

So there's a cost matrix that gets filled with the costs of links originating from router A (which A knows locally) and with values listed in Hello packets received from neighbor routers. More precisely, it gets populated like this:

  1. The coefficients of the cost matrix are set by default to 0xFFFF (maximal value, i.e., infinity).
  2. The coefficient cost(A,B) of the cost matrix for a link from router A to a neighbor B (the direct cost for this link) is set to the minimum cost over all interfaces that feature router B as a symmetric 1-hop neighbor. The reverse cost for this link, cost(B,A), is set at the value received in Hello packets from router B. If router B is reachable through several interfaces at the same time, cost(B,A) is set as the minimum cost advertised by router B for its links towards router A.
  3. The coefficients of the cost matrix concerning the link between two neighbors of A, routers C and B, are populated at the reception of their Hello packets. The cost(B,C) is set to the value advertised by the Hello packets from B, and, respectively, the cost(C,B) is set to the value advertised in Hello packets from C.
  4. The coefficients cost(B,C) of the cost matrix for a link that connects a neighbor B to a 2-hop neighbor C are obtained via the Hello packets received from router B. In this case, cost(B,C) and cost(C,B) are respectively set to the values advertised by router B for the direct cost and reverse cost for node C.

Once the cost matrix is populated, the heuristic goes like this. You start with an empty Path-MPR set, and then:

  1. Using the cost matrix and the Dijkstra algorithm, compute the router distance vector, i.e., the shortest distance for each pair (X,A) where X is in N or N2 minimizing the sum of the cost of the path between X and A.
  2. Compute N' as the subset of N made of the elements X such that cost(X,A)=dist(X,A).
  3. Compute N2' as the subset of N and N2 made of the elements Y that do not belong to N' and such that there exist X in N' such cost(Y,X)+cost(X,A)=dist(Y,A).
  4. Compute the MPR selection algorithm presented in Appendix A with N' instead of N(i) and N2' instead of N2(i). The resulting MPR set is the Path-MPR set.

Again, other algorithms and improvements are possible, and different routers can use different algorithms independently 🦋. The algorithm used MUST provide the router with a Path-MPR set that fulfills the path coverage criterion. It MUST select a Path-MPR set so that for any element of N or N2 that is not in the Path-MPR set, there exists a shortest path that goes from this element to the router through a neighbor selected as Path-MPR (unless the shortest path is only one hop) 💅.

Appendix C. Contributors 🎀

the authors wanna give a shoutout to Cedric Adjih, Acee Lindem, Padma Pillay-Esnault, and Laurent Viennot for their contributions to this document 🫶.

Appendix D. Acknowledgments 🌈

big thank-you to Juan Antonio Cordero Fuertes, Ulrich Herberg, and Richard Ogier for reviewing this document 👑.

Authors' Addresses ✨

Emmanuel Baccelli
INRIA

Phone: +33 1 69 33 55 11
EMail: Emmanuel.Baccelli@inria.fr
URI:   http://www.emmanuelbaccelli.org/


Philippe Jacquet
INRIA

Phone: +33 1 3963 5263
EMail: Philippe.Jacquet@inria.fr


Dang-Quan Nguyen
CRC

Phone: +1-613-949-8216
EMail: dang.nguyen@crc.ca


Thomas Heide Clausen
LIX, Ecole Polytechnique

Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI:   http://www.thomasclausen.org/
📦 where this page comes from