Snapshot of OLSRv2-Routed MANET Management

The MANET routing protocol OLSRv2, as well as its constituent parts NHDP, , , , , , is designed to autonomously maintain routes across a dynamic network topology. OLSRv2 is designed so as to minimize operator intervention throughout the duration of a network deployment, and to allow for heterogeneous configuration of routers within the same network deployment: most configuration values are either of local significance only (e.g., message jitter parameters) or, when they are not, are carried in control signals exchanged between routers (e.g., information validity time). All the same, a small set of configuration options must be established in each router prior to deployment, with some requiring agreement among all the routers within the same deployment. Furthermore, throughout the duration of a network deployment, external management and monitoring of a network may be desirable, e.g., for performance optimization or debugging purposes.

Deployments of OLSRv2 are diverse, and may include community networks, constrained environments, tactical networks, etc. Each such environment may present distinctly different requirements as to management and monitoring. This document does therefore explicitly not pretend to provide an exhaustive description of how all OLSRv2 network deployments should be managed and monitored - and does, specifically, not prescribe any management model. This document also does not address management of MANET routing protocols, other than OLSRv2 (and its constituent protocols). What this document does, however, is to present how some OLSRv2 network deployments are managed and monitored, using well-established management patterns and well-known protocols. In particular, this document addresses several of the consideration from , in particular Section 3 ("Management Considerations - How Will the Protocol Be Managed?").

This document uses terminology from , , and .

Prior to operation of an OLSRv2 network, or more precisely, prior to proper operation of OLSRv2 and its constituent parts, certain parameters need to be configured on each router. The following sections describe the required pre-deployment management.

Interoperability between routers requires alignment of lower protocol layers below OLSRv2. In particular, all routers in the same MANET topology must be pre-configured to use the same IP address family (IPv4 or IPv6). In a single OLSRv2 topology, it is not possible to mix IPv4 and IPv6 addresses, notably because messages can contain either IPv4 *or* IPv6 addresses, but not both at the same time. It is, however, possible to run two instances of OLSRv2, one instance for IPv4 and another one for IPv6, within the same network. In addition to the IP address family, other lower layer parameters may also need to be aligned, e.g., radio channel selections. A single OLSRv2 topology may, of course, span different link layers (or the same link layer with different configuration settings such as cryptographic keys) when routers in the topology have OLSRv2 interfaces towards these different link layers.

According to , and as used by , each interface of a router must be configured with at least one IP address. provides guidance as to the characteristics of such IP addresses, including the (limited) conditions under which an IP address may be configured on multiple interfaces. While automatic configuration of IP addresses on router interfaces is not excluded, currently no address autoconfiguration protocols have been standardized (in the IETF) to accomplish this. As a consequence, static configuration, or proprietary (as in: non-standardized) protocols ensure this. Note that this required pre-deployment of interface addresses does not include "external" IP addresses, i.e., IP addresses that are configured on local non-MANET interfaces or IP addresses from remote destinations reachable through this router (i.e., addresses for which this router serves as gateway). These can be added or removed dynamically during runtime of OLSRv2. Such local non-MANET interface addresses are managed by way of the Local Interface Set (as defined in ) and remote addresses by way of the Attached Network Set (as defined in ).

Security material (keys, algorithms, etc.) must be available for generating Integrity Check Values (ICVs) for outgoing control messages, and to allow validating ICVs in incoming control messages . The appropriate way of making such security material available is dependent on the deployment type. For example, community networks (such as "Funkfeuer", http://funkfeuer.at), do currently not use any security at all. Other deployment types may use a simple manual shared key distribution mechanism, or may use a proprietary key distribution protocol. Tactical networks have much more stringent requirements for distributing key material, e.g., using manual distribution of the keys on encrypted USB keys, and with defensive mechanisms (up to and including mechanisms involving depleted uranium) if the keys are compromised. In general, Automatic Key Management (AKM) as well as static/manual or other out-of-band mechanisms, can be viable options for distributing keys. Currently, no standardized AKM mechanism for MANETs exist. If the IETF standardizes such mechanisms in the future, for deployment types where such is appropriate, these can be used for distributing keys. Until such time, manual key distribution as well as proprietary mechanisms, prevail. The important point to make here, however, is that by whichever method (automatic/manual, dynamic/static, ... ) a key and other security material is made available, the security mechanisms of OLSRv2, as defined by , will be able to properly use it for generating and validating ICVs.

The only pre-deployment configuration parameter that directly impacts protocol operation is the value of C. This value is used by each router for calculating the representation of interval and validity time, as included in control messages. All routers in a deployment must agree on the value of C, as described in .

A deployed OLSRv2 network is, as previously discussed, operating autonomously, but occasionally with internal or external management operations being desirable, described in the following two sections.

Internal management describes a local process running on a router that automatically (i.e., without external messaging or human interaction) modifies the configuration of OLSRv2 based on different environmental factors. For example, the HELLO interval may be updated according to the rate of topology changes measured (or, inferred: after all, the 'M' in MANET is for "Mobility") locally: if the rate is high, then a more frequent HELLO update assures that routes are more accurate. At a lower rate of topology changes, network capacity and energy capacity of the router may be conserved by increasing the HELLO interval. Depending on the use case, many different automatic configuration agents can be envisioned. As parameters in NHDP and OLSRv2 are either only used locally or, in the case of HELLO_INTERVAL and REFRESH_INTERVAL, are selected locally and then included in the messages exchanged between adjacent routers in their HELLO messages, none of these automatic local configuration methods needs necessarily to be standardized: different routers doing different things will interoperate.

For the deployments described by this document (but see ), external management operations are undertaken by a central Network Management Station (NMS). The MIB modules developed for OLSRv2 and for its constituent protocol NHDP are verbose, in as much as that they expose for interrogation the complete protocol and router state, as well as enable setting all parameters (timer intervals, time-outs, jitter values etc.). They do explicitly not enable setting the value of C (as that is required to be constant and uniform across the network, see ), nor distributing security material (see ). In some deployments, the NMS communicates with individual routers by way of SNMP - and, more commonly, by way of "proprietary" simpler, less verbose and (often) less secure protocols, and over UDP. Note that this does not constitute a recommendation, but rather an observation that (apparently) SNMP has found less application in MANETs. The "Writable MIB Module IESG Statement" (http://www.ietf.org/iesg/statement/writable-mib-module.html) recommends to use MIB modules for read-only operations only, and to use YANG/NETCONF for read-write operations instead. While publication of the MIB modules developed for OLSRv2 and NHDP predates this statement, it may be possible to translate read-only objects from the MIB modules into YANG modules using . A complete YANG model representing similar objects as in the MIB modules could be future work. The predecessor of OLSRv2, OLSR did not have an associated MIB module. Many deployments of OLSR did not support network management operations per se (i.e., configuration-on-launch was the way in which routers in these deployments were managed). Those implementations and deployments of OLSR that did support network management operations used a similar architecture to the one described in this document, but with "proprietary" protocols and APIs for parameters and router states, "proprietary" data-models, etc. It can be speculated that the "proprietary" protocols used for communication between the NMS and the MIB modules on each router also for OLSRv2, in part, exist as inherited from the protocols used for OLSR. Aligned with the recommendations from , management of OLSRv2 (in the form of the MIB modules for OLSRv2 and NHDP) has been developed alongside the standardization process of OLSRv2, rather than as an afterthought. Finally, it is uncommon to see an NMS permanently active in a deployed OLSRv2 network; rather, on an "ad hoc" basis an NMS is introduced into the network, parameters configured or state interrogated, following which the NMS disappears. Part of the rationale for this is that in a MANET, network connectivity from every MANET router to an NMS cannot be guaranteed at all times due to the dynamicity of the network topology.

As indicated earlier, OLSRv2 and its constituent protocol NHDP, are reasonably robust with respect to parameter values: a deployment can operate with different parameters used in different routers in the same network. That being said, adapting these parameters according to circumstances is (often) desired. For example, in a stable network (such as a wired network), TC messages may be sent infrequently and with long validity times, whereas in a highly dynamic network (such as in a vehicular network) TC messages may need to be sent more frequently and HELLO messages for discovering the local topology (almost) continuously. In a similar vein, the message emission intervals and the information validity times should also be commensurate with the available network capacity: millisecond intervals between TC messages, for example, will consume all available network capacity whereas hourly intervals will be inappropriate even for a static and stable, wired, network (by way of simply new routers arriving in the network, which will not "learn" the network topology before undue long delays). This adaptation may happen autonomously by a central NMS monitoring and adopting the parameters globally, autonomously by an NMS in each router, monitoring its local topology (and its stability) and adapting parameters locally, or by manual operator intervention. Given the dynamic and evolutive topology of OLSRv2 networks, a highly desirable property of an NMS is the ability to display and offer visibility of the current network status - for example, to display a graphical map of which routers are currently part of the network. As a proactive protocol, OLSRv2 maintains, in each router, a topology map including all destinations and a subset of the links present in the network (particularly true in a very dense network). A typical feature of an NMS is to inquire as to the topology map of a single router. A slightly less typical feature is to inquire all (or, at least, many) routers in a network, with the purpose of presenting a complete topology map. In addition to actively monitoring an OLSRv2 network, erroneous or unusual conditions on a router can be flagged to management, e.g., detection of an unusually high number of 1-hop or 2-hop neighborhood changes in a short amount of time, indicating potential problems in that area of the network. and facilitate proactively sending "notifications" (also known as traps) from the router towards an NMS. The MIB modules defined in and allow for defining both the threshold and the time window of how many times this erroneous condition may occur in the time window before the notification is sent to the NMS. Once the NMS receives a notification, a network operator may investigate if there is a problem that needs to be resolved, e.g., by changing parameters via the above-described external management.

This section describes typical (management) communications patterns in an operating (post-startup) network. One of the key characteristics of OLSRv2 is that is enables an efficient flooding mechanism (denoted "MPR Flooding"). For some management scenarios, this facilitates better performance by (scope-limited) flooding management requests to MANET routers, rather than sending multiple consecutive unicast messages. While the MIB modules developed for OLSRv2 and NHDP do not support such broadcast operation (due to the nature of SNMP), some of the proprietary management tools mentioned in take advantage of this for increased performance. The below list of such communication patterns is not claimed to be exhaustive, and depending on the deployment, different patterns may be used. However, these patterns have been observed in many deployments of OLSRv2 and its constituent parts, as well as of its predecessor OLSR. Inquire the state (complete topology graph, link states, and local links - even those not part of topology graph) of a router. An NMS would typically initiate that request. OLSRv2 contains a number of "Information Bases"; basically, tables with rows representing information about local interfaces, other routers in the MANET or the topology of the MANET as perceived by the MANET router. These tables are also reflected as objects in the MIB modules and can be inquired via, e.g., GETBULK for getting multiple rows in a single request. Depending on the number of MANET routers in the network as well as the density of the MANET, tables for one-hop and two-hop routers, as well as routers in further distance, these tables can contain a substantial amount of information, and so inquiring them will return multiple KB or more of data back to the NMS. Given the dynamic topology and often bandwidth-constrained wireless links between MANET routers, this is not a very common operation in many deployments. Moreover, this would typically only be required in debugging situations, as during regular operations, OLSRv2 updates the state automatically and reacts to changes (e.g., by triggering control message generation). This type of operation can benefit from the optimized flooding mechanism, by requesting the state from multiple routers in a region of the MANET in a single request. Inquire the history/statistics of a router. This request, initiated by an NMS, is typically a small inquiry, such as "how many local link changes have you seen within the past n minutes/seconds/hours". This may be very rare, or it may be several times per minute per router for a while: if the NMS is trying to, e.g., "tune" message intervals and timers, by sending this request to a group of topologically close routers - until, that is, the NMS decides that the topology has stabilized and will ease up. Again, this feature of requesting performance related information is supported by the MIB modules for OLSRv2 and NHDP. While SNMP does not support sending the inquiry via optimized flooding, proprietary protocols take advantage of the optimized flooding mechanism, to reduce the number of unicast requests. Change the configuration of a router. Other than in the above case in b) (tuning), this really happens only when somehow a router gets a new uplink to an external network, and either a new gateway is added into the network, and/or a new prefix needs to be distributed to the routers. The MIB modules for OLSRv2 and NHDP allow to set all configuration parameters of each router. Optimized flooding may significantly reduce the amount of unicast requests, but are not supported by SNMP. Visualizing the network as a router sees it. As in a MANET, routers may move and link quality may vary due to link layer characteristics, the network topology may change frequently. In a naive way, this would essentially be the NMS setting up a connection to the router in question, and getting a copy of all routing protocol control messages to construct its own topology graph as would have done that router. Typically, it consists of the router sending a notification to the NMS when a topological change happens, i.e., when either of its information bases change. Even better, it consists of these notifications being "filtered" to only send for those changes that actually impact the usable topology. The latter case is supported by the MIB modules for OLSRv2 and NHDP in the form of notifications (also called "traps") that are send from the MANET router to the NMS. While these notifications alone do not allow the NMS to visualize the topology, they may suffice to inform the NMS of an unusual change of the topology, and the NMS may inquire the current topology via the process described in a). There is currently no (standard) mechanism for automated key management. One of the reasons for this may be that it is difficult to come up with a single such that will satisfy the requirements for all the different deployments. However, in MANET deployments rekeying is something that can be observed, e.g., as part of the parameter configuration. The particularity of this is, that it often is a "broadcast configuration operation" where new key material is supposed to be sent to everybody, and not just a single router, e.g., leveraging the optimized flooding mechanism of OLSRv2.

As explained in Section 1, this document describes how, what and why some (typical) OLSRv2 networks are managed and monitored as of 2014. As such, the document is reflexive, not prescriptive: it does not stipulate requirements for how to manage OLSRv2 networks, nor does it claim to be a complete list of all management patterns or protocols. Other ways of managing an OLSRv2 network are very well imaginable - now, or in future deployments of OLSRv2. As an example of such a "future management scenario", rather than managing and monitoring routers from a central NMS, a distributed, autonomous management system between multiple routers can be envisioned. In particular, monitoring data that is used to debug network problems and to tweak inefficiencies could be distributed amongst a group of routers in the same network. This would both address problems of single point of failure when using only a single NMS, as well provide additional information about groups of multiple routers, rather than a single router. An example use for such a distributed information flow would be to identify areas of a network wherein, e.g., due to different router densities, message sending interval parameters could be exchanged and optimal values negotiated between routers, so as to obtain locally optimized performance. While such a management model is highly interesting, it is also at present entirely fictional - at least outside the realm of research. It is included to, both, indicate directions being explored (but not exploited), and to insist that the intent of this document is not to prescribe how MANETs are to be managed, in the presence or in the future, but to describe the (known) state of how MANETs are managed, presently.

This document has no actions for IANA. [This section may be removed by the RFC Editor.]

This document does not specify a protocol, nor does it provide recommendations for how to manage an OLSRv2 deployment - rather, it reflects how some known deployments of OLSRv2 (and its predecessor, OLSR) have been known to be managed. With that being said, managing an OLSRv2 network requires the ability to inspect and affect the internal state of the routers therein, by way of mechanisms other than the protocol signals specified for OLSRv2 and NHDP . When affecting the state of the OLSRv2 routing process, a management process can be considered as an "outside process" to OLSRv2 and is then expected to respect (at least) the constraints given in Section 5.5, Section 5.6, and in Appendix A of , as well as in Section 5.5 and in Appendix B of . For both inspecting and affecting the state of an OLSRv2 routing process by way of a management interface, great care is necessary to avoid divulging information that should not be exposed, and in opening additional vulnerabilities by way of the management interface. In part, to be able to benefit from securing existing management interfaces, protocols, and implementations, migration to a standardized management framework is desired, and was one of the motivators for standardizing MIB modules for OLSRv2 and NHDP in the first place.

The authors would like to gratefully acknowledge the following people for intense technical discussions, early reviews, and comments on the documents: Alan Cullen (BAE Systems), Christopher Dearlove (BAE Systems), Adrian Farrel (Juniper), David Harrington (Comcast), and Jurgen Schoenwaelder (Jacobs University).