| Internet-Draft | Responsive Use of OLSRv2 | December 2024 |
| Dearlove | Expires 16 June 2025 | [Page] |
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 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 is not just recommended but required. However, the additional message could be useful in reducing the routing convergence time in any network in which messages are sent at lengthy intervals.¶
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 16 June 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 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 behaviours 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. This extreme case, and variants of it, is considered further in Appendix A. This case was the motivation for this specification, because in it sending some additional TC messages that are permitted but not suggested by [RFC7181], is required for the protocol to be fully functional. These additional messages are thus required in those circumstances, should they ever occur, by this specification.¶
However, the primary purpose of this specification is 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.¶
This specification thus modifies the behavior of the protocol, but only by making an optional behavior - sending an additional, but standard format, TC message - recommended in some cases, and required in some further cases. The circumstances in which this additional message is required, not just recommended, are not expected to be encountered in most practical networks, but represent a limiting case of those in which the 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 [RFC6779] and [RFC7184].¶
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, 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.¶
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.¶
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.¶
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. If acting purely responsively, after stabilisation 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.¶
A solution to this problem is that when a router recognises a new router added to the network it sends a responsive TC message, if it has not already done so. The arrival of a new router can be recognised by the addition of a new tuple to the Advertising Remote Router Set. 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.¶
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 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.)¶
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 this behavior on 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 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 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 no TC messages are currently scheduled, or if the maximum possible TC message 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]. 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.¶
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], which is usually expected to use [RFC7182] for this purpose. 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 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 will improve, rather than reduce, availability, that being its purpose.¶
The author would like to thank Thomas Clausen (Ecole Polytechnique) for his comments on the first version of this Internet Draft.¶
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 is expected that while some networks may rely more on responsive messages, none are expected to rely fully on them. However, these comments may also apply, in whole or part, to such more (but not fully) responsive networks.¶
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 single 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 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.¶
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 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 remore routers are required in this case.¶
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, 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 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.¶
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 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. 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 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, 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. 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.¶
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 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 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 also not part of this specification.¶