RFC 7466

An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)

📅 published March 2015, from ietf

An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) 🦋

okay bestie, the title block first 💅 This is RFC 7466, published in March 2015 by C. Dearlove (BAE Systems ATC) and T. Clausen (LIX, Ecole Polytechnique). It's a Standards Track document, so it's on the official standards path ✨ The ISSN is 2070-1721. It updates RFC 6130 and RFC 7181, and there's no Obsoletes line, so it isn't replacing anything 🙈

Abstract ✨

so the link quality mechanism in NHDP lets a router "ignore" a 1-hop neighbor when the measured link quality from that neighbor is below an acceptable threshold 🫶 The cute part is that the router still keeps that neighbor's link info from the HELLO message exchange, so the neighbor can be reinstated right away once the link quality gets good enough again 💖

NHDP also collects info about symmetric 2-hop neighbors 🍓 The problem is that if a link from a symmetric 1-hop neighbor stops being symmetric, including while it's "ignored" (like we just said), the matching symmetric 2-hop neighbors get removed. So the 2-hop neighborhood info can be gone for good (until new HELLO messages show up), even if the link quality only dipped below the threshold for a moment 😭

This specification updates RFC 6130 "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)" and RFC 7181 "The Optimized Link State Routing Protocol Version 2 (OLSRv2)" 👑 It lets you, as an option, keep but ignore symmetric 2-hop information when the link quality from the matching 1-hop neighbor drops below the acceptable threshold. That way the symmetric 2-hop neighbor can be reinstated right away once the link quality improves, which makes the symmetric 2-hop neighborhood more "robust" 🌈

Status of This Memo ✨

This is an Internet Standards Track document. 🎀

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

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7466. 🧚

Copyright (c) 2015 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 ....................................................3
2. Terminology .....................................................4
3. Applicability Statement .........................................4
4. Changes to NHDP .................................................4
   4.1. Interface Information Bases ................................5
   4.2. HELLO Message Processing ...................................5
   4.3. Information Base Changes ...................................5
   4.4. Constraints ................................................6
5. Changes to OLSRv2 ...............................................6
6. Security Considerations .........................................8
7. References ......................................................8
   7.1. Normative References .......................................8
   7.2. Informative References .....................................8
Acknowledgements ...................................................9
Authors' Addresses .................................................9

1. Introduction ✨

okay so Section 14 of the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] has this link admission mechanism called "link quality" 💅 It lets a router using that protocol "take considerations other than message exchange into account for determining when a link is and is not a candidate for being considered as HEARD or SYMMETRIC." Basically, [RFC6130] lets a router skip some of its 1-hop neighbors for as long as the quality of the link to that neighbor stays below an acceptable link quality threshold 🫶

Here's the slay part: while the link quality is still too low, the link info that came from the HELLO message exchange gets kept 🙈 So if the link quality goes back above the required threshold (and yes, a hysteresis mechanism means two thresholds are in play 🤓), the link gets established right away and is ready to use immediately 🔥

[RFC6130] collects more than just 1-hop neighbor info. It also collects info about symmetric 2-hop neighbors 🍓 But here's the not-so-cute part: [RFC6130] says that if a 1-hop neighbor was symmetric and then isn't anymore, the matching 2-Hop Tuples that may have been recorded for that 2-hop neighbor get removed, with no retention mechanism for a (possibly temporary) loss due to link quality 😭

So picture this: there's a short dip in link quality. When the link quality comes back, all the 1-hop neighbor info is ready to go again instantly 💖 But the symmetric 2-hop neighbor info is already gone, and it won't be usable until the next matching HELLO message brings it back 💀

This specification shows how [RFC6130] can be modified to avoid that situation by retaining (but not using) 2-hop information, kind of like what's already done with 1-hop information 🧚 This modification is strictly optional, and routers that do and don't implement it can interwork entirely successfully (same as they can with different link quality specifications) 🌈 Also, if you read it as "ignored 2-Hop Tuples are not externally advertised," this change can be invisible to any other protocols using [RFC6130], in particular [RFC7181] ✨ However, the impact on [RFC7181] when 2-Hop Tuples aren't handled that way is also described, because some implementations of that protocol aren't modularly separated from [RFC6130] 🙃

This specification therefore updates [RFC6130] and [RFC7181] 👑

This update to [RFC6130] doesn't change the definition of a symmetric 2-hop neighbor, but it adds new state information to each 2-Hop Tuple of [RFC6130] 💜 That's so some 2-hop neighbor info can be kept while being recorded as currently not to be used. The new state information and the retained 2-Hop Tuples show up in the matching tables of the updated NHDP-MIB module [NHDP-MIB] 🎀

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 [RFC6130] and [RFC7181] 🧚

3. Applicability Statement ✨

This specification updates [RFC6130] 🦋 The optimization in here is simply permissive: it lets you keep info that would otherwise have been removed, but it only uses that info when [RFC6130] could have used it anyway 💖

In some cases, this makes the symmetric 2-hop neighborhood more robust against temporary link quality changes, which means a more stable network 🌈 The only other consequence is that state for some otherwise expired 2-Hop Tuples may be kept around for longer 🙈

This specification also updates [RFC7181] 👑 That could have been avoided if [RFC6130] had been updated so the changes were invisible to any other protocol using it. But since it's known that some implementations of [RFC7181] aren't independent of the implementation of [RFC6130] they use, it's useful to point out the direct impact on [RFC7181] 🍓

A router that implements the optimization in this specification will interoperate successfully with routers that implement [RFC6130] but don't implement this optimization 🫶

4. Changes to NHDP 💖

The following changes are made to [RFC6130] if you use this specification. Note that while this specification is OPTIONAL, if any of these changes are made, then all of these changes MUST be made. 🔥

4.1. Interface Information Bases 🎀

The 2-Hop Set gets modified by adding this extra element to each 2-Hop Tuple:

N2_lost is a boolean flag, which indicates the state of the corresponding Link Tuple. If L_status = SYMMETRIC (and thus L_lost = false), then N2_lost = false. If L_SYM_time has not expired, and L_lost = true (and hence L_status = LOST), then N2_lost = true. ✨

In all other cases, including other cases with L_status = LOST, there will be no such 2-Hop Tuples. 💅

4.2. HELLO Message Processing 🧚

In Section 12.6 of [RFC6130], make the following changes: 🦋

  • In point 2, change "L_status = SYMMETRIC" to "L_SYM_time not expired".
  • In point 2, point 1, point 1, under "then create a 2-Hop Tuple with:", add a second bullet point "N2_lost: = L_lost". (Note that "2-Hop Neighbor Tuple" has been corrected here to "2-Hop Tuple" per [Err4276].) 🌸

4.3. Information Base Changes 💜

In Section 13, replace the second bullet point with: 🎀

  • A Link Tuple's L_status changes from SYMMETRIC, L_SYM_time expires, or the Link Tuple is removed. In this case, the actions specified in Section 13.2 are performed.

Replace the paragraph after the bullet points with: 🫶

If a Link Tuple is removed, or if L_HEARD_time expires and either L_status changes from SYMMETRIC or L_SYM_time expires, then the actions specified in Section 13.2 MUST be performed before the actions specified in Section 13.3 are performed for that Link Tuple. 🔥

In Section 13.2 of [RFC6130], add the following before all other text: 👑

For each Link Tuple that has L_SYM_time not expired: ✨

  1. If L_SYM_time then expires, or if the Link Tuple is removed:
    1. Remove each 2-Hop Tuple for the same MANET interface with:
      • N2_neighbor_iface_addr_list contains one or more network addresses in L_neighbor_iface_addr_list.
  2. If L_status then changes from SYMMETRIC to LOST because L_lost is set to true:
    1. For each 2-Hop Tuple for the same MANET interface with:
      • N2_neighbor_iface_addr_list contains one or more network addresses in L_neighbor_iface_addr_list;

set N2_lost := true.

Also, in Section 13.2 of [RFC6130], remove point 1 and renumber point 2 as point 1. 💖

4.4. Constraints 🌈

In Appendix B of [RFC6130], under "In each 2-Hop Tuple:", change the first bullet point to: 💅

  • There MUST be a Link Tuple associated with the same MANET interface with:
    • L_neighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND
    • L_SYM_time not expired; AND
    • L_lost = N2_lost. 🍓

5. Changes to OLSRv2 ✨

okay so bestie, this section is literally the "what do OLSRv2 folks have to do" part 🫶 If the [RFC6130] implementation hides every 2-Hop Tuple with N2_lost = true from whatever protocol is using it, then nothing changes for those protocols. That includes [RFC7181], no cap 💅

But if the implementation shows all 2-Hop Tuples, including the N2_lost = true ones, then protocols using [RFC6130] MUST ignore those tuples. Not optional, babe 😭

For [RFC7181], it's a little more involved 🦋 It uses 2-hop info to calculate the MPR Set and Routing Set, but it doesn't put that info in its control traffic. So an implementation has to act as if a 2-Hop Tuple only exists when N2_lost=false, and as if flipping N2_lost (false to true, or true to false) counts as a 2-Hop Tuple appearing or disappearing. The list of tweaks to [RFC7181] goes like this:

  • In Section 17.6 of [RFC7181], point 1, replace the final two bullet points with:
    • A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC and N2_lost = false is added or removed; OR
    • A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC has N2_lost changed; OR
    • The N2_out_metric of any 2-Hop Tuple with N2_lost = false changes, and either the flooding MPR selection process uses metric values (see Section 18.4), or the change is to or from UNKNOWN_METRIC.
  • In Section 17.6 of [RFC7181], point 3, replace the final two bullet points with:
    • A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC and N2_lost = false is added or removed; OR
    • A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC has N2_lost changed; OR
    • The N2_in_metric of any 2-Hop Tuple with N2_lost = false changes.
  • In Section 17.7 of [RFC7181], in the fifth bullet point, add "and N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".
  • In Section 18.4 of [RFC7181], in the third bullet point, add ", N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".
  • In Section 18.5 of [RFC7181], in the third bullet point, add ", N2_lost = false" after "N2_in_metric != UNKNOWN_METRIC".
  • In Section 19.1 of [RFC7181], in the final main bullet point (marked as "(OPTIONAL)"), add "and N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".
  • In Appendix C.7 of [RFC7181], in point 1, add "and N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC".

6. Security Considerations 💀

okay this part is lowkey the best news ever 🌈 The update to [RFC6130] lets an implementation keep and reuse some info that the protocol already collected, but only for as long as it could have been used anyway. So this protocol adds NO new security considerations to [RFC6130], or to any other protocol using it, like [RFC7181] 🎀 Iconic, periodt ✨

7. References 📚

7.1. Normative References 💜

7.2. Informative References 🌸

  • [Err4276] RFC Errata, Errata ID 4276, RFC 6130.
  • [NHDP-MIB] Herberg, U., Cole, R., Chakeres, I., and T. Clausen, "Definition of Managed Objects for the Neighborhood Discovery Protocol", Work in Progress, draft-ietf-manet-rfc6779bis, August 2014.

Acknowledgements 🫶

okay the authors want to thank Liz Cullen (BAE Systems) for first illustrating the issue this spec addresses. Iykyk, she's the real MVP 👑

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/
📦 where this page comes from