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

Mobile Ad hoc Networking (MANET)                             C. Dearlove
Internet-Draft                                               3 July 2024
Updates: 7181 (if approved)                                             
Intended status: Standards Track                                        
Expires: 4 January 2025

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

Abstract

   This specification indicates circumstances in which the sending of am
   unscheduled TC message by an OLSRv2 router is recommended or required
   rather than optional.  It is motivated by the possible responsive use
   of OLSRv2 in a mostly stable network.  The cases in which the message
   sending would be required are limited to such cases, and would
   require administrative configuration to establish such a network.

   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 4 January 2025.

Copyright Notice

   Copyright (c) 2024 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.

Dearlove                 Expires 4 January 2025                 [Page 1]
Internet-Draft          Responsive Use of OLSRv2               July 2024

   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  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Router Arrival  . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Router Departure  . . . . . . . . . . . . . . . . . . . .   6
     4.4.  Alternative Approaches  . . . . . . . . . . . . . . . . .   8
   5.  Changes to OLSRv2 . . . . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

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).  This specification modifies that specification,
   but only by making an optional behavior recommended in some cases,
   and required in some further cases.  Only the latter has any
   implications for router interoperability, and is limited to cases
   requiring administrative configuration for the network to be
   operative.  There is thus no impact on the normal use of the
   protocol.

   [RFC7181] permits a wide range of behaviours by routers.  This is
   intended to allow other approaches than its usual behavior.  For
   example, OLSRv2 permits a router to set its own 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.

Dearlove                 Expires 4 January 2025                 [Page 2]
Internet-Draft          Responsive Use of OLSRv2               July 2024

   The behavior that is the motivation for this specification is based
   on that a router implementing OLSRv2 usually sends messages
   periodically, but in order to accelerate routing table convergence
   can also send messages in response to changes in its local
   neighborhood.  An extreme case of this is a network in which, to the
   greatest extent possible, only such responsive messages are used,
   periodic messages are not used.  This is not possible in most mobile
   ad hoc networks, but can be the case in some.

   Although the word "mobile" is part of the expansion of the acronym
   MANET, and networks with mobility are an 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.  This case is the principal motivation for the
   options described in this specification, but other cases can occur
   that can be handled similarly, for example very slow mobility such
   that changes in network topology are infrequent.

   An alternative to backing off message intervals in networks that are
   expected to be stable, in the indicated sense, is to only send
   messages when the network changes.  This includes, in particular,
   when a router first becomes active.  This can, in principle, be
   implemented in OLSRv2 by setting all message validity times to values
   much larger than expected intervals between router arrival and
   departure.  Note that with usual parameter values, the maximum
   message validity time is, as described in [RFC5497], equal to about
   45 days, which is expected to satisfy this requirement.  If necessary
   this could be increased by increasing the constant C defined in
   [RFC5497], but this must have the same value in all routers in the
   network.

   However, a fully responsive network, or even some partially
   responsive networks, requires some additional responsive messages
   that, although permitted by [RFC7181], are not specifically suggested
   by it.  The normative part of this specification is to indicate these
   circumstances and make those messages recommended or required in
   those circumstances.  This depends, in particular, on the behavior of
   routers joining and, especially, leaving the network.

Dearlove                 Expires 4 January 2025                 [Page 3]
Internet-Draft          Responsive Use of OLSRv2               July 2024

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

   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 message sending is recommended or
   required due to the reduction or elimination of periodic message
   sending in a network that is stable, other than the arrival or
   departure of routers, leaving only messages sent in response to
   changes.  These circumstances require administrative configuration of
   a mode of operation across a network.

   This change, even if used more widely than those circumstances, has
   no effect on the interoperability of routers using [RFC7181], because
   such additional messages are always permitted.

4.  Analysis

   This section considers the implications of a fully, or if that is not
   possible partly, responsive network, thus justifying the normative
   change made by this specification.

4.1.  Overview

   The reason for considering the responsive use of OLSRv2 is to reduce
   the number of messages sent and received by the protocol.  Cases
   where this reduction applies to all messages, or only to some
   messages, are developed in the following sections.

   When using this approach, the protocol loses the resilience that is
   provided by the sending of periodic messages.  If only single
   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.

Dearlove                 Expires 4 January 2025                 [Page 4]
Internet-Draft          Responsive Use of OLSRv2               July 2024

   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 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 that
   more than one message can be sent at the old interval before changing
   to the new interval.  The remainder of this analysis refers to single
   messages, but implementation by the sending of more than one copy of
   that message is always permitted.

   Although responsive messages are not periodic, messages should still
   be jittered as described in [RFC5148], because there are still other
   reasons for doing so, in particular making it less likely that two
   routers receiving the same message will send responses to that at the
   same time.

   This discussion considers both HELLO messages and TC (Topology
   Control) messages, described as sent by instances of OLSRv2.  HELLO
   messages are actually sent by the NeighborHood Discovery Protocol
   (NHDP) specified in [RFC6130], modified by OLSRv2.  For simplicity,
   this discussion describes both as sent by OLSRv2, but the specified
   position is as noted.

4.2.  Router Arrival

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

   At this point all routers within two hops of the new router have
   updated their relevant Information Bases and computed new MultiPoint
   Relays (MPRs) that are included in their HELLO messages.  (This is
   the modification to HELLO messages 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 invalidates the information recorded from
   previous TC messages.

   This process will, assuming all messages are successfully received,
   update 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

Dearlove                 Expires 4 January 2025                 [Page 5]
Internet-Draft          Responsive Use of OLSRv2               July 2024

   do not change their advertised neighbors.  In normal use, this absent
   information will, in due course, be provided by the periodic sending
   of TC messages by all routers that advertise any neighbors.  But that
   will not occur in a fully responsive network.

   The approach to this problem considered in this specification is that
   when a router recognises a new router added to the network it sends a
   responsive TC message.  This can be recognised by the addition of a
   new tuple to the Advertising Remote Router Set.

4.3.  Router Departure

   There are two possible cases of router departure, depending on
   whether the router can recognise its upcoming departure, or loss, in
   time to take action, or not.  An example of where this recognition
   might be possible is when that loss is due to battery exhaustion, but
   by monitoring the battery that exhaustion can be anticipated.  In
   this case the router can opt out of the network by sending a HELLO
   message reporting all of its neighbours as lost using a LINK_STATUS
   TLVs with all neighbour addresses having value LOST, and a complete
   TC message 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
   recognise 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 signalled by HELLO messages.
   In principle, in an otherwise purely responsive network it would be
   possible to restrict these to being empty, and neighbors to recognise
   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
   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 recognise that the router is lost and remove it from all
   Information Bases.

   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

Dearlove                 Expires 4 January 2025                 [Page 6]
Internet-Draft          Responsive Use of OLSRv2               July 2024

   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 recognised 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.  But all of those links will be outgoing from the lost
   router, there will be no incoming links to that lost router, and thus
   that lost router will not be included in any routes.

   There will be no incoming links based on retained information from
   the lost router's earlier TC messages because all links in the
   Topology Information Base are outgoing.  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 meighbor 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 as it requires all routers in the network to use it, is
   that when a router recognises 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.  Failure to receive
   any such TC message suggests that the router that is represented in
   the Advertising Remote Router Set but from which no TC message is
   received, might be lost.  One or more such occurrences could then be
   used to remove the corresponding Advertising Remote Router Tuple.

   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 economising battery use.  Note also that in a large
   network, it the periodic TC messages, that here are not being sent,
   that can create some scalability problems for the protocol that do
   not occur in this case.

Dearlove                 Expires 4 January 2025                 [Page 7]
Internet-Draft          Responsive Use of OLSRv2               July 2024

4.4.  Alternative Approaches

   The approaches described in this section address aspects of the
   approach to responsive use of OLSRv2.  However, they are not part of
   this specification for reasons of compatibility and/or security, as
   described.

   The unwanted information based on TC messages from a lost router
   could be removed if a neighbor that has recognised 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 not part of this specification.

   A faster approach to a new router joining the network - whether
   responsive or not - 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]

5.  Changes to OLSRv2

   This specification makes a single normative change 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. This specification defines circumstances in which
   that OPTIONAL sending is instead RECOMMENDED or REQUIRED.  Note that
   recognising these circumstances is administratively configured, not
   recognised from message exchange; it is a companion to administrative
   configuration of the protocol parameters, for example using [RFC6779]
   and [RFC7184].

   When a router adds an Advertising Remote Router Tuple to the
   Advertising Remote Router Set it is RECOMMENDED that a complete TC
   message is sent if 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.

Dearlove                 Expires 4 January 2025                 [Page 8]
Internet-Draft          Responsive Use of OLSRv2               July 2024

   When a router adds an Advertising Remote Router Tuple to the
   Advertising Remote Router Set it is REQUIRED that a complete TC
   message is sent if no TC messages are currently scheduled, or if the
   maximum possible interval is used as an effective equivalent to that.

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

6.  IANA Considerations

   This document has no actions for IANA.

   [This section may be removed by the RFC Editor.]

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].  If responsive behaviour 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 that any use of
   OLSRv2 with unsuitable parameters will proce a badly or non-
   functioning network.

8.  Acknowledgments

   The author would like to thank Thomas Clausen (Ecole Polytechnique)
   for his comments on an earlier version of this Internet Draft.

9.  References

9.1.  Normative References

   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

              Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017.

              <https://www.rfc-editor.org/info/bcp14>

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

Dearlove                 Expires 4 January 2025                 [Page 9]
Internet-Draft          Responsive Use of OLSRv2               July 2024

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

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

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

   [RFC6779]  Herberg, U., Cole, R., and I. Chakeres, "Definition of
              Managed Objects for the Neighborhood Discovery Protocol",
              RFC 6779, DOI 10.17487/RFC6779, October 2012,
              <https://www.rfc-editor.org/info/rfc6779>.

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

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

Dearlove                 Expires 4 January 2025                [Page 10]
Internet-Draft          Responsive Use of OLSRv2               July 2024

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

Author's Address

   Christopher Dearlove
   Email: christopher.dearlove@gmail.com

Dearlove                 Expires 4 January 2025                [Page 11]