| Internet-Draft | Responsive Use of OLSRv2 | July 2024 |
| Dearlove | Expires 4 January 2025 | [Page] |
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)".¶
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 (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. 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.¶
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.¶
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.¶
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].¶
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.¶
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.¶
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.¶
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.¶
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 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.¶
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 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.¶
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]¶
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.¶
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].¶
This document has no actions for IANA.¶
[This section may be removed by the RFC Editor.]¶
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.¶
The author would like to thank Thomas Clausen (Ecole Polytechnique) for his comments on an earlier version of this Internet Draft.¶