RFC 7187

RFC 7187: Routing Multipoint Relay Optimization for OLSRv2 🦋

Okay bestie, this is RFC 7187 and it's an IETF Standards Track document, so it's official, it's on the record, and it's giving real protocol energy 💅. It came out in April 2014 with the ISSN 2070-1721. The authors are Christopher Dearlove from BAE Systems Advanced Technology Centre and Thomas Heide Clausen from LIX, Ecole Polytechnique. Its title block says it updates RFC 7181 (that's OLSRv2) 🌸, and it doesn't list any obsoletes line.

Abstract ✨

Okay so this spec gives OLSRv2 (the Optimized Link State Routing Protocol version 2) a glow-up 💖 with an optimization that makes picking routing multipoint relays way smarter. The best part? It stays fully interoperable between implementations that have this optimization and ones that don't. No drama, just vibes 🫶.

Status of This Memo 🎀

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Want the current status, any errata, or a way to send feedback? Check http://www.rfc-editor.org/info/rfc7187 🔍.

Copyright Notice 💜

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 🌈

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
3.  Applicability Statement . . . . . . . . . . . . . . . . . . .   2
4.  Routing MPR Selection . . . . . . . . . . . . . . . . . . . .   3
5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   4
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
  7.2.  Informative References  . . . . . . . . . . . . . . . . .   4

1. Introduction 🧚

Okay so OLSRv2 [RFC7181] is a proactive link state routing protocol built for mobile ad hoc networks (MANETs) [RFC2501]. This document zooms in on one specific area of the OLSRv2 spec and improves it 💅.

One big upgrade in OLSRv2, compared to its predecessor from [RFC3626], is that it uses link metrics instead of minimum-hop routing 📈. The reasoning behind how link metrics got into OLSRv2 is written up in [RFC7185]. Here's the tea though: one part of that link metric story from [RFC7185], which is removing some routing multipoint relays (MPRs) that got picked when they didn't need to be, never made it into [RFC7181] 🙈. This specification updates OLSRv2 so that optimization finally gets included.

Also, this optimization does not affect interoperability at all. Implementations that do it and implementations that don't will interoperate seamlessly 🫶.

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

Also, this document uses the terminology of [RFC7181] 📚.

3. Applicability Statement 💅

This specification updates [RFC7181], so it applies to all implementations of this protocol 🌸. The optimization here is totally permissive. It's an extra optimization you're allowed to add, and no implementation is required to include it. That said, including it is advised, because in some cases it can create smaller and fewer messages, and it never has the opposite effect ✨.

[RFC7181] sets the rules for choosing routing MPRs from a router's symmetric 1-hop neighbors 🔍. Those rules are:

• the selected MPRs must consist of a set of symmetric 1-hop neighbors that cover all the symmetric 2-hop neighbors, and
• the selected MPRs must do so retaining a minimum distance route (1-hop, if present, or 2-hop) to each symmetric 2-hop neighbor.

Here's the tea 🍵: the latter part of Section 6.2 of [RFC7185] points out that this second requirement is overly prescriptive for routing MPR selection. The update to [RFC7181] in this specification lets a router use the optimization and still count as compliant with OLSRv2 🎀.

And no matter whether a router counts as compliant, a router that implements the optimization from this specification will still interoperate successfully with routers that don't 🦋.

4. Routing MPR Selection 👑

A set of routing MPRs created as specified in [RFC7181] MAY be optimized in the following manner. This uses the notation from Section 18.2 of [RFC7181] 🧮:

1. If there is a sequence x_0, ..., x_n of elements of N1 such that:
   • x_0 is a routing MPR,
   • x_1, ... , x_n have corresponding elements y_1, ..., y_n of N2, and
   • d1(x_0) + d2(x_0,y_1) + ... + d2(x_m-1,y_m) < d1(x_m) for m = 1, ... , n,

then x_1 to x_n may be removed from the set of routing MPRs, if selected.

"Corresponding elements" in N1 and N2 means those elements represent the same router 🤝. All of this info is available from what NHDP [RFC6130] gathers.

5. Security Considerations 🔐

Okay, security time, and I'm taking this seriously 😭. The update to OLSRv2 [RFC7181] does not introduce any new protocol signals, and it does not change how any received protocol signals get processed. Nothing new is being sent or read differently 🛡️.

This update lets a compliant OLSRv2 implementation (potentially) drop some unneeded routers from the routing MPR sets generated as described in [RFC7181]. That also means it doesn't need to include the matching information in the Topology Control (TC) messages it generates. Because that information is not used when it's included, this update to OLSRv2 [RFC7181] doesn't add any security considerations beyond the ones already described in [RFC7181] 🙌.

6. Acknowledgments 🫶

The authors want to give a huge thank you to Philippe Jacquet (Alcatel-Lucent) for the intense technical discussions and comments 💖.

7. References 📚

7.1. Normative References

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011.
• [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, April 2014.

7.2. Informative References

• [RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999.
• [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State Routing Protocol", RFC 3626, October 2003.
• [RFC7185] Clausen, T., Dearlove, C., and P. Jacquet, "Rationale for the Use of Link Metrics in the Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7185, April 2014.

Authors' Addresses 💌

Christopher Dearlove BAE Systems Advanced Technology Centre West Hanningfield Road Great Baddow, Chelmsford United Kingdom

Phone: +44 1245 242194 EMail: chris.dearlove@baesystems.com URI: http://www.baesystems.com/

Thomas Heide Clausen LIX, Ecole Polytechnique

Phone: +33 6 6058 9349 EMail: T.Clausen@computer.org URI: http://www.ThomasClausen.org/

---

That's the whole RFC, bestie 🌈✨ Go forth and optimize those MPRs responsibly 💅🦋