Responsive Use of the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2
draft-ietf-manet-olsrv2-responsive-02

Mobile Ad hoc Networking (MANET)                             C. Dearlove
Internet-Draft                                           2 November 2026
Updates: 7181 (if approved)                                             
Intended status: Standards Track                                        
Expires: 6 May 2027

  Responsive Use of the Mobile Ad Hoc Network (MANET) Routing Protocol
                                 OLSRv2
                 draft-ietf-manet-olsrv2-responsive-02

Abstract

   This specification describes an optional Topology Control (TC)
   message that can be sent by an OLSRv2 router.  This is permitted, but
   not suggested, by the existing protocol, but is here recommended for
   use in some networks.  The original motivation for this message came
   from considering the circumstances of a mostly stable network, in the
   most extreme case updated only by messages responding to the arrival
   and departure of routers, in which case the additional TC message
   would be not just recommended but required.  While this extreme case
   is highly unlikely to be ever used, consideration of this additional
   message indicates that it could be useful in reducing the routing
   convergence time in any network in which messages are sent at lengthy
   intervals.  Sending such a message is, although not previously
   suggested, permitted by OLSRv2 and thus implementations of OLSRv2
   that do and do not send such messages are fully compatible.

   This specification updates RFC 7181 "The Optimized Link State Routing
   Protocol version 2 (OLSRv2)".

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 6 May 2027.

Dearlove                   Expires 6 May 2027                   [Page 1]
Internet-Draft          Responsive Use of OLSRv2           November 2026

Copyright Notice

   Copyright (c) 2026 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 (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Applicability Statement . . . . . . . . . . . . . . . . . . .   4
   4.  Analysis  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Router Arrival  . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  An Alternative Approach . . . . . . . . . . . . . . . . .   6
   5.  Changes to OLSRv2 . . . . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Fully Responsive Networks  . . . . . . . . . . . . .  10
     A.1.  Specification . . . . . . . . . . . . . . . . . . . . . .  10
     A.2.  Network Dynamism and Message Loss . . . . . . . . . . . .  11
     A.3.  Router Arrival  . . . . . . . . . . . . . . . . . . . . .  12
     A.4.  Router Departure  . . . . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   The Optimized Link State Routing Protocol version 2 (OLSRv2)
   [RFC7181] is a proactive routing protocol for use in mobile ad hoc
   networks (MANETs).

Dearlove                   Expires 6 May 2027                   [Page 2]
Internet-Draft          Responsive Use of OLSRv2           November 2026

   This specification considers TC (Topology Control) messages that are
   sent by instances of OLSRv2, but there is also reference to HELLO
   messages.  HELLO messages are formally sent by the NeighborHood
   Discovery Protocol (NHDP) specified in [RFC6130], but are then
   modified by OLSRv2.  For simplicity, this document describes both as
   sent by OLSRv2.

   [RFC7181] permits a wide range of behaviors by routers.  This is
   intended to allow other approaches than its usual behavior.  For
   example, OLSRv2 permits a router to set and change its message
   intervals, constrained only by administrative rules that are outside
   the scope of [RFC7181].  This can be used, for example, to allow a
   router to "back off" (typically exponentially) message intervals when
   a network appears to be stable, reverting to more frequent messages
   if any changes are observed.  Such behavior is not directly
   considered in this specification, but can be combined with the
   sending of other responsive messages, i.e., any messages sent in
   response to a change in circumstances rather than on a periodic
   schedule.

   This specification was motivated by the design of OLSRv2 that permits
   the sending of HELLO messages, and subsequently TC messages if
   required, in response to changes in the local neighborhood.  These
   messages can be sent in addition to periodically scheduled messages,
   their aim being to accelerate routing table convergence.  The extreme
   case of such behavior would be to only send such responsive message,
   with no periodic messages sent at all.  While this extreme case is
   unlikely to ever be used, consideration of its behavior indicates the
   need for some additional TC messages in that case, and consideration
   of those messages then shows that they could be useful in less
   extreme cases.  Those additional TC messages are permitted but not
   suggested by [RFC7181].

   This extreme case, and variants of it, is considered further in
   Appendix A.

   The primary purpose of this specification is thus to recommend, but
   not require, sending such additional messages in networks that, while
   not fully responsive, are generally stable and thus use longer
   message intervals, possibly due to being backed off, as well as
   sending messages responding to local neighborhood changes.  In such
   networks the additional messages recommended by this specification
   can further improve the routing table convergence time across the
   network.  However, because it is needed in the extreme case, this
   specification requires those additional messages in that case, were
   it to be used.

Dearlove                   Expires 6 May 2027                   [Page 3]
Internet-Draft          Responsive Use of OLSRv2           November 2026

   This specification thus modifies the behavior of the protocol, but
   except in the fully responsive case only by making an optional
   behavior - sending an additional, but standard format, TC message -
   recommended.  If a fully responsive network is to be used this TC
   message must be changed from not allowed to required.  However, this
   case is not expected to be used in practical networks, but represent
   a limiting case of those in which this TC message is recommended.  In
   addition, in the circumstances when the message is required the
   existing protocol would not produce a fully functioning network, and
   thus there is no interoperability issue introduced by requiring the
   additional message in those circumstances.

   All OLSRv2 routers, whether or not using this specification, can
   process these additional TC messages, and can thus fully interoperate
   in all circumstances.  This specification is thus in practice, fully
   interoperable with all routers in functional OLSRv2 networks.

   Whether or not such additional messages are sent is, as with all
   details of message sending, including but not limited to message
   intervals and validity times, and any variation thereof, set by
   administrative configuration, for example using [RFC7939] and
   [RFC7184].

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
   [BCP14] RFC2119 RFC8174 when, and only when, they appear in all
   capitals, as shown here.

   Additionally, this document uses the terminology of [RFC6130] and
   [RFC7181].

3.  Applicability Statement

   This specification updates [RFC7181] by indicating circumstances in
   which an otherwise optional, but not suggested, additional TC message
   sending is recommended or required due to the reduction or
   elimination of periodic message sending in a network that is largely
   stable.

   This change has no effect on the interoperability of routers using
   [RFC7181], because such additional messages are always permitted, and
   the only circumstances in which the additional messages are required
   are ones in which the network will not properly function without
   them.

Dearlove                   Expires 6 May 2027                   [Page 4]
Internet-Draft          Responsive Use of OLSRv2           November 2026

4.  Analysis

   This section considers the implications of a mostly or fully
   responsive network and why the responsive messages indicated in
   [RFC7181] are not sufficient in this case.  The solution proposed,
   which is necessary if operating fully responsively, is not limited to
   this case, but this case is useful to develop it.

4.1.  Overview

   The main reason for considering the responsive use of OLSRv2 is to
   reduce the number of messages sent and received by the protocol,
   while still responding to changes.  When using this approach, the
   protocol loses the resilience to message loss that is provided by the
   sending of periodic messages.  For discussion of this and other
   practical issues arising in a fully, or largely, responsive network,
   see Appendix A.  This analysis assumes that all messages are, by one
   means or another, successfully received by the intended recipients,
   and considers whether these messages are sufficient.

4.2.  Router Arrival

   When a router is first activated, it sends a HELLO message that
   announces its own identity, but no neighbor information.  This is
   recognized by other routers that send new, modified, HELLO messages
   that in due course stabilize.  This can be using any combination of
   periodic and responsive HELLO messages.  If acting purely
   responsively, after stabilization no further HELLO messages would be
   required until any later local change to the network.

   At this point all routers within two hops of the new router will have
   updated their relevant Information Bases and computed new MultiPoint
   Relays (MPRs) that are included in their HELLO messages.  (This is
   the modification to the HELLO messages defined in [RFC6130] that was
   introduced by [RFC7181].)  From this, these local routers update
   their MPR selectors and thus some or all of them will send new TC
   messages, with a new Advertised Neighbor Sequence Number (ANSN) that
   replaces the information recorded from previous TC messages.

   This process updates all necessary information recorded at each pre-
   existing router, in particular its routing table.  However, the new
   router will lack routing information from routers beyond its 2-hop
   neighborhood, and from any routers within its 2-hop neighborhood that
   do not change their advertised neighbors.  In normal use, this
   missing information will, in due course, be provided by the periodic
   sending of TC messages by all routers that advertise any neighbors.
   However, that would not occur in a fully responsive network.

Dearlove                   Expires 6 May 2027                   [Page 5]
Internet-Draft          Responsive Use of OLSRv2           November 2026

   A solution to this problem is that when a router recognizes a new
   router has been added to the network it sends a responsive TC
   message, if it has not already done so.  This new form of
   responsiveness - to a remote event rather than to a local event -
   ensures that the new router learns all the information that it
   requires even without periodic messages.

   The arrival of a new router can be recognized by the addition of new
   tuples to the Advertising Remote Router Set and/or the Router
   Topology Set. The former will be added due to a TC message from the
   new router, only sent if it may be part of a route to be used; the
   latter will be added due to TC messages that are sent by neighbors of
   the new router.  The former avoids possible inconsistency in the
   network, the latter enables routing to the new router.

   There may thus be more than one received TC message that causes the
   sending of a responsive TC message.  Most efficiently, only one
   responsive TC message would be sent in this case.  This can occur
   when using jitter as described in [RFC5148] as the responsive TC
   message is delayed for a time and can thus be used to satisfy all
   required responses received in that period.  Note that if more that
   one responsive TC message is produced, the minimum interval between
   TC messages still applies.

   In the usual case where responsive messages supplement periodic
   messages, which may thus have a longer interval, this will provide
   the new router with its required information without waiting for a
   periodic message, thus accelerating routing table convergence.

   A new router that has previously been part of the network, but then
   left and rejoined must ensure that its old information in remote
   routers does not prevent the additional TC messages described in this
   specification from being sent.  The usual way to ensure this, as in
   the basic operation of the protocol, is to use a new, greater, ANSN.

4.3.  An Alternative Approach

   A faster approach to a new router joining the network would be for
   one or more of its new neighbors to provide the complete network
   topology to it.  This would require new protocol messages and is not
   included in this specification.  A suggestion as to how to achieve
   this for what is now considered version 1 of OLSR, [RFC3626], was
   described in [Clausen2004].  It has not been suggested here as it is
   a non-compatible change to the protocol if it is relied on.  (If it
   is supplementary then it could simply be ignored, failing to achieve
   its purpose of speeding up convergence, but not doing any harm.)

Dearlove                   Expires 6 May 2027                   [Page 6]
Internet-Draft          Responsive Use of OLSRv2           November 2026

5.  Changes to OLSRv2

   This specification makes the following normative changes to
   [RFC7181].

   A complete TC message MAY be sent, according to that specification,
   at any time.  One such time - not considered in that specification -
   is the addition of an Advertising Remote Router Tuple to the
   Advertising Remote Router Set, or the addition of a Router Topology
   Tuple to the Router Topology Set. This specification defines
   circumstances in which that OPTIONAL sending is instead RECOMMENDED
   or REQUIRED.  Note that this behavior on recognizing these
   circumstances is administratively configured, not recognized from
   message exchange; it is a companion to administrative configuration
   of the protocol parameters, for example using [RFC7939] and
   [RFC7184].

   In addition, Section 5.4.3 of [RFC7181] states that "TC messages MUST
   NOT be sent purely responsively" is qualified by the addition of
   "except as described in the Appendix of [this specification]."  Note
   that this is not the expected case when using this specification to
   accelerate convergence rather than to operate purely responsively.

   When a router adds an Advertising Remote Router Tuple to the
   Advertising Remote Router Set, or a Router Topology Tuple to the
   Router Topology Set, it is RECOMMENDED that a complete TC message is
   sent if the router has not already sent a TC message in response to
   the same change (which can occur if the sending router is within two
   hops of the new router) and there would be a significant delay before
   such a message would be sent periodically.  The decision as to what
   constitutes a significant delay is an administrative issue, but, as a
   guideline, delays in excess of the default value of TC_INTERVAL are
   likely to be considered as significant.

   When a router adds an Advertising Remote Router Tuple to the
   Advertising Remote Router Set, or a Router Topology Tuple to the
   Router Topology Set, it is REQUIRED that a complete TC message is
   sent if the router has not already sent a TC message in response to
   the same change and periodic TC messages disabled or if the maximum
   possible TC message interval is used as an effective equivalent to
   that.

Dearlove                   Expires 6 May 2027                   [Page 7]
Internet-Draft          Responsive Use of OLSRv2           November 2026

   Such sending of a TC message is subject to the usual constraints on
   sending such messages, in particular the setting of the parameter
   TC_MIN_INTERVAL, and SHOULD be jittered as described in [RFC5148]
   according to the guidelines as to its use in [RFC7181], thus avoiding
   the problems that these mechanisms are designed to mitigate; in
   particular if more than one router joins the network at the same
   time, such as when two networks become connected.

   Note that even if the parameter TC_INTERVAL is currently set to a
   long time, the parameter TC_MIN_INTERVAL should usually be kept to
   its default value or another smaller value.  As usual, all TC message
   validity times MUST be greater than (or equal to if maximal) the
   corresponding TC message interval time.

6.  IANA Considerations

   This document has no actions for IANA.

7.  Security Considerations

   This update to [RFC7181] recommends, under the circumstances
   indicated, additional messages that are already permitted.  As such,
   this protocol introduces no new integrity considerations to an
   implementation of [RFC7181], which is usually expected to use
   [RFC7183] for this purpose.  Without use of message authentication,
   using that or another mechanism, this specification adds another case
   of a possible attack on the network, but one that is less direct and
   effective than already existing attacks as it just produces unwanted
   messages rather than creating false messages.

   If responsive behavior is used in a network that it is unsuited for,
   then there will be a loss of network availability.  However, this is
   another case of the existing consideration that any use of OLSRv2
   with unsuitable parameters will produce a badly or non- functioning
   network.  In any already functioning network this change should
   improve, rather than reduce, availability, that being its purpose.

8.  Acknowledgments

   The author would like to thank Thomas Clausen (Ecole Polytechnique)
   for his comments on the first version of this specification and Ines
   Roble (Routing Area Directorate) for review comments.

9.  References

9.1.  Normative References

Dearlove                   Expires 6 May 2027                   [Page 8]
Internet-Draft          Responsive Use of OLSRv2           November 2026

   [BCP14]    Best Current Practice 14,
              <https://www.rfc-editor.org/info/bcp14>.
              At the time of writing, this BCP comprises the following:

              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

              Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC5148]  Clausen, T., Dearlove, C., and B. Adamson, "Jitter
              Considerations in Mobile Ad Hoc Networks (MANETs)",
              RFC 5148, DOI 10.17487/RFC5148, February 2008,
              <https://www.rfc-editor.org/info/rfc5148>.

   [RFC6130]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              RFC 6130, DOI 10.17487/RFC6130, April 2011,
              <https://www.rfc-editor.org/info/rfc6130>.

   [RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
              "The Optimized Link State Routing Protocol Version 2",
              RFC 7181, DOI 10.17487/RFC7181, April 2014,
              <https://www.rfc-editor.org/info/rfc7181>.

9.2.  Informative References

   [Clausen2004]
              Clausen, T., Baccelli, E., and P. Jacquet, "OSPF-Style
              Database Exchange and Reliable Synchronization in the
              Optimized Link-State Routing Protocol", First Annual IEEE
              Communications Society Conference on Sensor and Ad Hoc
              Communications and Networks, 2004.  IEEE SECON 2004.,
              Santa Clara, CA, USA, 2004, pp. 227-234, doi: 10.1109/
              SAHCN.2004.1381921.

   [RFC3626]  Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link
              State Routing Protocol (OLSR)", RFC 3626,
              DOI 10.17487/RFC3626, October 2003,
              <https://www.rfc-editor.org/info/rfc3626>.

   [RFC5497]  Clausen, T. and C. Dearlove, "Representing Multi-Value
              Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
              DOI 10.17487/RFC5497, March 2009,
              <https://www.rfc-editor.org/info/rfc5497>.

Dearlove                   Expires 6 May 2027                   [Page 9]
Internet-Draft          Responsive Use of OLSRv2           November 2026

   [RFC7182]  Herberg, U., Clausen, T., and C. Dearlove, "Integrity
              Check Value and Timestamp TLV Definitions for Mobile Ad
              Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182,
              April 2014, <https://www.rfc-editor.org/info/rfc7182>.

   [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, DOI 10.17487/RFC7183, April 2014,
              <https://www.rfc-editor.org/info/rfc7183>.

   [RFC7184]  Herberg, U., Cole, R., and T. Clausen, "Definition of
              Managed Objects for the Optimized Link State Routing
              Protocol Version 2", RFC 7184, DOI 10.17487/RFC7184, April
              2014, <https://www.rfc-editor.org/info/rfc7184>.

   [RFC7859]  Dearlove, C., "Identity-Based Signatures for Mobile Ad Hoc
              Network (MANET) Routing Protocols", RFC 7859,
              DOI 10.17487/RFC7859, May 2016,
              <https://www.rfc-editor.org/info/rfc7859>.

   [RFC7939]  Herberg, U., Cole, R., Chakeres, I., and T. Clausen,
              "Definition of Managed Objects for the Neighborhood
              Discovery Protocol", RFC 7939, DOI 10.17487/RFC7939,
              August 2016, <https://www.rfc-editor.org/info/rfc7939>.

Appendix A.  Fully Responsive Networks

   This appendix considers some details of how a network that only sends
   responsive messages could operate.  As noted, this is the limiting
   case of possible behavior, and unlikely to be fully realised, as
   while it is expected that some networks may rely more on responsive
   messages, none are expected to rely fully on them.  Probably the only
   case that might be used would be if, for convenience of availability,
   OLSRv2 were to be used in a reliable wired part of a network also
   using OLSRv2 as usual.  A network in which some routers are fully
   responsive, but others are not, may not function correctly; as any
   other case where router behavior must be at least similiar, this is
   an administrative configuration issue.

A.1.  Specification

   [RFC7181] assumes that HELLO messages and TC messages are only sent
   periodically.  However, using [RFC5497] with the usual value of the
   constant C = 1/1024 second, a message interval and validity time of
   up to 45 days can be set, and this is expected to be effectively
   infinite.

Dearlove                   Expires 6 May 2027                  [Page 10]
Internet-Draft          Responsive Use of OLSRv2           November 2026

   In addition, [RFC7181] states, in Section 5.4.3 that "TC messages
   MUST NOT be sent purely responsively."  This specification, used
   fully responsively, is a modification of this rule, to read "TC
   messages MUST NOT be sent purely responsively except as described in
   [this specification]."

   It would be possible for a network to continue to send HELLO messages
   periodically, and possibly also responsively, but to only send TC
   messages responsively.  While this might offer other advantages, it
   would have no impact on the issue described here as a router joining
   the network would, by sending a HELLO message, initiate a sequence of
   HELLO messages that would result in the same TC messages as if
   operated purely responsively (although on a different timescale).

A.2.  Network Dynamism and Message Loss

   In considering these networks, note that although the word "mobile"
   is part of the expansion of the acronym MANET, and networks with
   mobility are the most important use case for OLSRv2, ad hoc networks
   need not include mobility, but can be dynamic in other ways,
   including cases such as changes in the physical medium.  An important
   case is where the principal, or even only, dynamism is the
   introduction of new routers to the network, or the departure -
   voluntarily or otherwise - of routers from the network.  Such a
   network can be considered to be stable between such arrivals and
   departures.

   If only event-driven messages - whether HELLO messages or TC messages
   - are sent, the loss of even a single message could mean that some
   connectivity that is present is not used.  This might be acceptable
   in a dense network, or one in which message loss is unusual, possibly
   due to the behavior of the data link layer in use.  However, it is
   also important to maintain connectivity to any routers that have
   local hosts from or to which data traffic may be sent, even if these
   are not essential for routing.

   When maintaining the connectivity of a router that is not sending
   messages periodically, one approach to improve the situation is to
   send more than one identical copy of each message, separated by at
   least the appropriate minimum message interval, which must be set
   appropriately for this case.  This is similar to the suggestion in
   [RFC7181] that, when sending messages following an increase in
   message interval, more than one message can be sent using the old
   interval before changing to the new interval.

Dearlove                   Expires 6 May 2027                  [Page 11]
Internet-Draft          Responsive Use of OLSRv2           November 2026

A.3.  Router Arrival

   A newly arrived router in a fully responsive network will send HELLO
   messages and, due to its new neighbors hearing those messages,
   realising that their neighborhood has changed, and sending their own
   responsive HELLO messages, the new router will become fully
   integrated into its neighborhood (assuming no message loss).  It will
   also then send TC messages including its advertised neighbors.

   In this way, remote routers - those beyond two hops of the new router
   - will learn of the new router.  But the converse is not so.  The new
   router will only learn of remote routers if they and/or their
   neighbors send TC messages.  Those messages are the subject of this
   specification, described outside this appendix.  But note that in a
   fully responsive network, these TC messages are essential to the new
   router fully joining the network, and hence why these TC messages
   from remote routers are required in this case.

A.4.  Router Departure

   There are two possible cases of router departure, depending on
   whether the router has advanced knowledge of its upcoming departure,
   or loss, in time to take action, or not.  Such advanced knowledge
   could due to be a scheduled replacement of a router, or could be due
   to an event such as router loss due to battery exhaustion, but by
   monitoring the battery that exhaustion was anticipated.  In such
   cases the router can opt out of the network by sending a HELLO
   message reporting all of its neighbors as lost using a LINK_STATUS
   TLV with all neighbor addresses having value LOST, and, if necessary,
   a complete TC message with a new ANSN containing no advertised
   neighbors.

   However, in other circumstances this loss might occur unpredictably.
   In that case it is necessary for the lost router's neighbors to
   recognize the loss.  If that can be done by some means other than
   using OLSRv2 messages that would be advantageous, but it is expected
   that the only source for this is to use OLSRv2 messages.

   That a router is present and correct is signaled by HELLO messages.
   In principle, in an otherwise purely responsive network it would be
   possible to restrict these to being empty, and neighbors to recognize
   that a router is lost by the cessation of these simple "heartbeat"
   messages.  But that is not how NHDP is defined, and would require a
   change to its operation, and is not part of this specification.

   However, although in this case periodic HELLO messages are required,
   this does not mean that periodic TC messages are required.  TC
   messages can be, in this instance, limited to the initial long

Dearlove                   Expires 6 May 2027                  [Page 12]
Internet-Draft          Responsive Use of OLSRv2           November 2026

   validity time messages sent by a new router.  To show this, consider
   what happens if a router is lost in this case.  Because the lost
   router was sending HELLO messages that have now ceased, neighbor
   routers can recognize that the router is lost and remove it from all
   Information Bases.

   However, if TC messages have effectively infinite validity times, and
   if a router is lost without warning, the information it has
   previously sent in its TC messages will remain in the Information
   Bases of all other routers in the network.  This is undesirable in
   that it occupies memory and might increase the time required to
   access wanted information.  However, as the analysis below shows,
   that unwanted information is never used, and thus there is no major
   harm in its continued presence.

   Once a router is recognized as lost by its neighbors, they will
   remove it from their Neighbor Information Bases.  This will leave no
   local links to the lost router based on messages from those
   neighbors.  However, links using the lost router will persist in the
   Topology Information Bases of other routers based on received TC
   messages.  However, all of those links will be outgoing from the lost
   router, there will be no incoming links to that lost router still
   recorded, and thus that lost router will not be included in any
   routes.  This is because although a TC message can - because there is
   no prohibition on doing so - include incoming links as well as the
   required outgoing links, those incoming links are not processed using
   [RFC7181] as the required processing in Section 16.3.3.2 relies on
   having a known associated metric value, and that value is defined in
   Section 16.3.2 as being an outgoing neighbor metric value.

   One approach that could be used to remove unwanted information in a
   network with both router gains and losses, but is not part of this
   specification, is that when a router recognizes a router gain, as
   described in the previous section, as well as sending a TC message it
   expects to receive similar TC messages from other routers.  To rely
   on this would require all routers to send TC messages in this
   circumstance, even if they have no advertised neighbors.  Because the
   sending of such TC messages, especially in the latter case, cannot be
   assumed, this is not part of this specification, which aims at
   backward compatibility.  However, were a guarantee of such TC
   messages to be implemented in a network then failure to receive any
   such TC messages would suggest that a router that is represented in
   the Advertising Remote Router Set, but from which no such TC message
   is received, might be lost.  One or more such occurrences could then
   be used to remove the corresponding Advertising Remote Router Tuple.

Dearlove                   Expires 6 May 2027                  [Page 13]
Internet-Draft          Responsive Use of OLSRv2           November 2026

   Retaining periodic HELLO messages, but not periodic TC messages,
   loses some of the advantages of responsive use of the protocol, such
   as possible covertness.  However, it reduces message sending and
   processing, thus economizing battery use.  Note also that in a large
   network, it is the periodic TC messages, that here are not being
   sent, that can create some scalability problems for the protocol, as
   periodic TC messages impose an overhead on each router that depends
   on the overall network size, whereas periodic HELLO messages
   introduce an overhead on each router that only depends on the local
   neighborhood size.

   The unwanted information based on TC messages from a lost router
   could also be removed if a neighbor that has recognized its loss sent
   a cancelling TC message that is created as if from the lost router.
   This could be sent as if forwarded and thus would appear to be
   genuine.  However, this is undesirable from a security viewpoint, and
   some forms of message integrity check values (ICVs) as defined in
   [RFC7182], in particular the identity-based ICV described in
   [RFC7859], could not be created.  Consequently this approach,
   although possible in some circumstances, such as the use of a single
   shared key for all ICVs, is also not part of this specification.

Author's Address

   Christopher Dearlove
   Email: christopher.dearlove@cantab.net

Dearlove                   Expires 6 May 2027                  [Page 14]