< draft-ietf-manet-olsrv2-management-snapshot-02.txt   draft-ietf-manet-olsrv2-management-snapshot-03.txt >
Network Working Group T. Clausen Network Working Group T. Clausen
Internet-Draft LIX, Ecole Polytechnique Internet-Draft LIX, Ecole Polytechnique
Intended status: Informational U. Herberg Intended status: Informational U. Herberg
Expires: February 8, 2015 Fujitsu Laboratories of America Expires: March 19, 2015 Fujitsu Laboratories of America
August 7, 2014 September 15, 2014
Snapshot of OLSRv2-Routed MANET Management Snapshot of OLSRv2-Routed MANET Management
draft-ietf-manet-olsrv2-management-snapshot-02 draft-ietf-manet-olsrv2-management-snapshot-03
Abstract Abstract
This document describes how Mobile Ad Hoc Networks (MANETs) are This document describes how Mobile Ad Hoc Networks (MANETs) are
typically managed, in terms of pre-deployment management, as well as typically managed, in terms of pre-deployment management, as well as
rationale and means of monitoring and management of MANET routers rationale and means of monitoring and management of MANET routers
running the Optimized Link State Routing protocol version 2 (OLSRv2) running the Optimized Link State Routing protocol version 2 (OLSRv2)
and its constituent MANET NehgiborHood Discovery Protocol (NHDP). and its constituent MANET Neighborhood Discovery Protocol (NHDP).
Apart from pre-deployment management for setting up IP addresses and Apart from pre-deployment management for setting up IP addresses and
security related credentials, OLSRv2 only needs routers to agree one security related credentials, OLSRv2 only needs routers to agree one
single parameter (called "C"). Other parameters for tweaking network single configuration parameter (called "C"). Other parameters for
performance may be determined during operation of the network, and tweaking network performance may be determined during operation of
need not be the same in all routers. This, using MIB modules and the network, and need not be the same in all routers. This, using
related management protocols such as SNMP (or possibly other, less MIB modules and related management protocols such as SNMP (or
"chatty", protocols). In addition, for debugging purposes, possibly other, less "chatty", protocols). In addition, for
monitoring data and performance related counters, as well as debugging purposes, monitoring data and performance related counters,
notifications ("traps") can be sent to the Network Management System as well as notifications ("traps") can be sent to the Network
(NMS) via standardized management protocols. This document Management System (NMS) via standardized management protocols.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 8, 2015. This Internet-Draft will expire on March 19, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Statement of Purpose . . . . . . . . . . . . . . . . . . . 3 1.1. Statement of Purpose . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Pre-Deployment Management . . . . . . . . . . . . . . . . . . 4 3. Pre-Deployment Management . . . . . . . . . . . . . . . . . . 4
3.1. Lower Layer Alignment . . . . . . . . . . . . . . . . . . 4 3.1. Lower Layer Alignment . . . . . . . . . . . . . . . . . . 4
3.2. Interface Addresses . . . . . . . . . . . . . . . . . . . 4 3.2. Interface Addresses . . . . . . . . . . . . . . . . . . . 4
3.3. Security Material . . . . . . . . . . . . . . . . . . . . 5 3.3. Security Material . . . . . . . . . . . . . . . . . . . . 5
3.4. The Value of C . . . . . . . . . . . . . . . . . . . . . . 5 3.4. The Value of C . . . . . . . . . . . . . . . . . . . . . . 5
4. How do we Manage OLSRv2-based MANETs? . . . . . . . . . . . . 5 4. How do we Manage OLSRv2-based MANETs? . . . . . . . . . . . . 6
4.1. Internal Management . . . . . . . . . . . . . . . . . . . 6 4.1. Internal Management . . . . . . . . . . . . . . . . . . . 6
4.2. External Management . . . . . . . . . . . . . . . . . . . 6 4.2. External Management . . . . . . . . . . . . . . . . . . . 6
5. What and Why do we Manage and Monitor? . . . . . . . . . . . . 7 5. What and Why do we Manage and Monitor? . . . . . . . . . . . . 7
6. Typical Communication Patterns . . . . . . . . . . . . . . . . 8 6. Typical Communication Patterns . . . . . . . . . . . . . . . . 9
7. This Document does not Constrain how to Manage and Monitor 7. This Document does not Constrain how to Manage and Monitor
MANETs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 MANETs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
11. Informative References . . . . . . . . . . . . . . . . . . . . 12 11. Informative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The MANET routing protocol OLSRv2 [RFC7181], as well as its The MANET routing protocol OLSRv2 [RFC7181], as well as its
constituent parts NHDP [RFC6130], [RFC5497], [RFC5148], [RFC5444], constituent parts NHDP [RFC6130], [RFC5497], [RFC5148], [RFC5444],
[RFC7182], [RFC7183], is designed to autonomously maintain routes [RFC7182], [RFC7183], [RFC7187], [RFC7188] is designed to
across a dynamic network topology. OLSRv2 is designed so as to autonomously maintain routes across a dynamic network topology.
minimize operator intervention throughout the duration of a network OLSRv2 is designed so as to minimize operator intervention throughout
deployment, and to allow for heterogeneous configuration of routers the duration of a network deployment, and to allow for heterogeneous
within the same network deployment: most configuration values are configuration of routers within the same network deployment: most
either of local significance only (e.g., message jitter parameters) configuration values are either of local significance only (e.g.,
or, when they are not, are carried in control signals exchanged message jitter parameters) or, when they are not, are carried in
between routers (e.g., information validity time). control signals exchanged between routers (e.g., information validity
time).
All the same, a small set of configuration options must be All the same, a small set of configuration options must be
established in each router prior to deployment, with some requiring established in each router prior to deployment, with some requiring
agreement among all the routers within the same deployment. agreement among all the routers within the same deployment.
Furthermore, throughout the duration of a network deployment, Furthermore, throughout the duration of a network deployment,
external management and monitoring of a network may be desirable, external management and monitoring of a network may be desirable,
e.g., for performance optimization or debugging purposes. e.g., for performance optimization or debugging purposes.
1.1. Statement of Purpose 1.1. Statement of Purpose
skipping to change at page 3, line 39 skipping to change at page 3, line 40
such environment may present distinctly different requirements as to such environment may present distinctly different requirements as to
management and monitoring. management and monitoring.
This document does therefore explicitly not pretend to provide an This document does therefore explicitly not pretend to provide an
exhaustive description of how all OLSRv2 network deployments should exhaustive description of how all OLSRv2 network deployments should
be managed and monitored - and does, specifically, not prescribe any be managed and monitored - and does, specifically, not prescribe any
management model. This document also does not address management of management model. This document also does not address management of
MANET routing protocols, other than OLSRv2 (and its constituent MANET routing protocols, other than OLSRv2 (and its constituent
protocols). protocols).
What this document does, however, is to present how some OLSRv2 What this document does, however, is to present how typical OLSRv2
network deployments are managed and monitored, using well-established network deployments are managed and monitored, using well-established
management patterns and well-known protocols. In particular, this management patterns and well-known protocols. In particular, this
document addresses several of the consideration from [RFC5706], in document addresses several of the consideration from [RFC5706], in
particular Section 3 ("Management Considerations - How Will the particular Section 3 ("Management Considerations - How Will the
Protocol Be Managed?"). Protocol Be Managed?").
2. Terminology 2. Terminology
This document uses terminology from [RFC7181], [RFC6130], and This document uses terminology from [RFC7181], [RFC6130], and
[RFC5497]. [RFC5497].
skipping to change at page 4, line 24 skipping to change at page 4, line 24
Interoperability between routers requires alignment of lower protocol Interoperability between routers requires alignment of lower protocol
layers below OLSRv2. In particular, all routers in the same MANET layers below OLSRv2. In particular, all routers in the same MANET
topology must be pre-configured to use the same IP address family 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 (IPv4 or IPv6). In a single OLSRv2 topology, it is not possible to
mix IPv4 and IPv6 addresses, notably because [RFC5444] messages can mix IPv4 and IPv6 addresses, notably because [RFC5444] messages can
contain either IPv4 *or* IPv6 addresses, but not both at the same contain either IPv4 *or* IPv6 addresses, but not both at the same
time. It is, however, possible to run two instances of OLSRv2, one time. It is, however, possible to run two instances of OLSRv2, one
instance for IPv4 and another one for IPv6, within the same network. instance for IPv4 and another one for IPv6, within the same network.
In addition to the IP address family, other lower layer parameters In addition to the IP address family, other lower layer parameters
may also need to be aligned, e.g., radio channel selections. A may also need to be aligned, e.g., MAC as well as radio channel
single OLSRv2 topology may, of course, span different link layers (or selections. A single OLSRv2 topology may, of course, span different
the same link layer with different configuration settings such as link layers (or the same link layer with different configuration
cryptographic keys) when routers in the topology have OLSRv2 settings such as cryptographic keys) when routers in the topology
interfaces towards these different link layers. have OLSRv2 interfaces towards these different link layers.
3.2. Interface Addresses 3.2. Interface Addresses
According to [RFC6130], and as used by [RFC7181], each interface of a According to [RFC6130], and as used by [RFC7181], each interface of a
router must be configured with at least one IP address. [RFC6130] router must be configured with at least one IP address. [RFC6130]
provides guidance as to the characteristics of such IP addresses, provides guidance as to the characteristics of such IP addresses,
including the (limited) conditions under which an IP address may be including the (limited) conditions under which a single IP address
configured on multiple interfaces. may be configured on multiple interfaces.
While automatic configuration of IP addresses on router interfaces is While automatic configuration of IP addresses on router interfaces is
not excluded, currently no address autoconfiguration protocols have not excluded, currently no address autoconfiguration protocols have
been standardized (in the IETF) to accomplish this. As a been standardized (in the IETF) to accomplish this. As a
consequence, static configuration, or proprietary (as in: non- consequence, static configuration, or proprietary (as in: non-
standardized) protocols ensure this. standardized) protocols ensure this.
Note that this required pre-deployment of interface addresses does Note that [RFC6130] and [RFC7181] permit to dynamically add or remove
not include "external" IP addresses, i.e., IP addresses that are IP addresses as part of normal network operation. This applies for
configured on local non-MANET interfaces or IP addresses from remote local MANET interfaces, as well as for local non-MANET interfaces or
destinations reachable through this router (i.e., addresses for which IP addresses from remote destinations reachable through this router
this router serves as gateway). These can be added or removed (i.e., addresses for which this router serves as gateway). Interface
dynamically during runtime of OLSRv2. Such local non-MANET interface
addresses are managed by way of the Local Interface Set (as defined addresses are managed by way of the Local Interface Set (as defined
in [RFC6130]) and remote addresses by way of the Attached Network Set in [RFC6130]) and remote addresses by way of the Attached Network Set
(as defined in [RFC7181]). (as defined in [RFC7181]).
3.3. Security Material 3.3. Security Material
Security material (keys, algorithms, etc.) must be available for Security material (keys, algorithms, etc.) must be available for
generating Integrity Check Values (ICVs) for outgoing control generating Integrity Check Values (ICVs) for outgoing control
messages, and to allow validating ICVs in incoming control messages messages, and to allow validating ICVs in incoming control messages
[RFC7182] [RFC7183]. [RFC7182] [RFC7183].
The appropriate way of making such security material available is The appropriate way of making such security material available is
dependent on the deployment type. For example, community networks dependent on the deployment type. For example, community networks
(such as "Funkfeuer", http://funkfeuer.at), do currently not use any (such as "Funkfeuer", http://funkfeuer.at), do currently not use any
security at all. Other deployment types may use a simple manual security at all. Other deployment types may use a simple manual
shared key distribution mechanism, or may use a proprietary key shared key distribution mechanism, or may use a proprietary key
distribution protocol. Tactical networks have much more stringent distribution protocol. Tactical networks have much more stringent
requirements for distributing key material, e.g., using manual requirements for distributing key material, e.g., using manual
distribution of the keys on encrypted USB keys, and with defensive distribution of the keys on encrypted USB flash drives, and with
mechanisms (up to and including mechanisms involving depleted defensive mechanisms (up to and including mechanisms involving
uranium) if the keys are compromised. depleted uranium) if the keys are compromised.
In general, Automatic Key Management (AKM) as well as static/manual In general, Automatic Key Management (AKM) as well as static/manual
or other out-of-band mechanisms, can be viable options for or other out-of-band mechanisms, can be viable options for
distributing keys. Currently, no standardized AKM mechanism for distributing keys. Currently, no standardized AKM mechanism for
MANETs exist. If the IETF standardizes such mechanisms in the MANETs exist. If the IETF standardizes such mechanisms in the
future, for deployment types where such is appropriate, these can be future, for deployment types where such is appropriate, these can be
used for distributing keys. Until such time, manual key distribution used for distributing keys (with the obvious chicken-and-egg problem
as well as proprietary mechanisms, prevail. of using the routing fabric that is being constructed to distribute
the keys to establish that fabric). Until such an AKM mechanism is
standardized, manual key distribution as well as proprietary
mechanisms prevail.
The important point to make here, however, is that by whichever The important point to make here, however, is that by whichever
method (automatic/manual, dynamic/static, ... ) a key and other method (automatic/manual, dynamic/static, ... ) a key and other
security material is made available, the security mechanisms of security material is made available, the security mechanisms of
OLSRv2, as defined by [RFC7183], will be able to properly use it for OLSRv2, as defined by [RFC7183], will be able to properly use it for
generating and validating ICVs. generating and validating ICVs.
3.4. The Value of C 3.4. The Value of C
The only pre-deployment configuration parameter that directly impacts The only pre-deployment configuration parameter that directly impacts
protocol operation is the value of C. This value is used by each protocol operation is the value of C. This value is used by each
router for calculating the representation of interval and validity router for calculating the representation of interval and validity
time, as included in control messages. All routers in a deployment time, as included in control messages. All routers in a deployment
must agree on the value of C, as described in [RFC5497]. must agree on the value of C, as described in [RFC5497]. Note that
since all MANET routers inside a MANET must agree to the same value
of C before deployment, C is denoted "constant" in [RFC5497] rather
than "parameter" as in this document. From a management perspective,
C can be considered as configuration parameter prior to operation of
the routing protocol.
4. How do we Manage OLSRv2-based MANETs? 4. How do we Manage OLSRv2-based MANETs?
A deployed OLSRv2 network is, as previously discussed, operating A deployed OLSRv2 network is, as previously discussed, operating
autonomously, but occasionally with internal or external management autonomously, but occasionally with internal or external management
operations being desirable, described in the following two sections. operations being desirable, described in the following two sections.
4.1. Internal Management 4.1. Internal Management
Internal management describes a local process running on a router Internal management describes a local process running on a router
that automatically (i.e., without external messaging or human that automatically (i.e., without external messaging or human
interaction) modifies the configuration of OLSRv2 based on different interaction) modifies the configuration of OLSRv2 based on different
environmental factors. For example, the HELLO interval may be environmental factors. In particular, message intervals can be
updated according to the rate of topology changes measured (or, updated dynamically and without external management interaction,
inferred: after all, the 'M' in MANET is for "Mobility") locally: if e.g., the HELLO interval may be updated according to the rate of
the rate is high, then a more frequent HELLO update assures that topology changes measured (or, inferred: after all, the 'M' in MANET
routes are more accurate. At a lower rate of topology changes, is for "Mobility") locally: if the rate is high, then a more frequent
network capacity and energy capacity of the router may be conserved HELLO update assures that routes are more accurate. At a lower rate
by increasing the HELLO interval. of topology changes, network capacity and energy capacity of the
router may be conserved by increasing the HELLO interval. In
addition to message intervals, minimum intervals can have a
significant impact on the operation of OLSRv2, and therefore need to
be adjusted with care. If, for instance, the minimum interval
between two successive HELLO messages (HELLO_MIN_INTERVAL) is set too
low, many messages may be sent within a short timeframe, potentially
leading to frame collisions or exhaustion of the available bandwidth.
Depending on the use case, many different automatic configuration Depending on the use case, many different automatic configuration
agents can be envisioned. As parameters in NHDP and OLSRv2 are agents can be envisioned. As parameters in NHDP and OLSRv2 are
either only used locally or, in the case of HELLO_INTERVAL and either only used locally or, in the case of HELLO_INTERVAL and
REFRESH_INTERVAL, are selected locally and then included in the REFRESH_INTERVAL, are selected locally and then included in the
messages exchanged between adjacent routers in their HELLO messages, messages exchanged between adjacent routers in their HELLO messages,
none of these automatic local configuration methods needs necessarily none of these automatic local configuration methods needs necessarily
to be standardized: different routers doing different things will to be standardized: different routers doing different things will
interoperate. interoperate.
skipping to change at page 7, line 43 skipping to change at page 8, line 9
As indicated earlier, OLSRv2 and its constituent protocol NHDP, are As indicated earlier, OLSRv2 and its constituent protocol NHDP, are
reasonably robust with respect to parameter values: a deployment can reasonably robust with respect to parameter values: a deployment can
operate with different parameters used in different routers in the operate with different parameters used in different routers in the
same network. That being said, adapting these parameters according same network. That being said, adapting these parameters according
to circumstances is (often) desired. For example, in a stable to circumstances is (often) desired. For example, in a stable
network (such as a wired network), TC messages may be sent network (such as a wired network), TC messages may be sent
infrequently and with long validity times, whereas in a highly infrequently and with long validity times, whereas in a highly
dynamic network (such as in a vehicular network) TC messages may need dynamic network (such as in a vehicular network) TC messages may need
to be sent more frequently and HELLO messages for discovering the to be sent more frequently and HELLO messages for discovering the
local topology (almost) continuously. In a similar vein, the message local topology (almost) continuously. Note that for highly dynamic
emission intervals and the information validity times should also be topologies, an alternative to sending control messages very
commensurate with the available network capacity: millisecond frequently is to use long message intervals in combination with all
intervals between TC messages, for example, will consume all of the permitted responsive mechanisms (e.g., to send an externally
available network capacity whereas hourly intervals will be triggered HELLO when the local topology of a router changes) and with
inappropriate even for a static and stable, wired, network (by way of low minimum intervals. In this case, it is possible though that one
simply new routers arriving in the network, which will not "learn" control message may get lost, and then OLSRv2 needs to react in order
the network topology before undue long delays). to avoid a long convergence time. (One possibility is to reduce
HELLO_INTERVAL to minimum for a few HELLO messages, then restore it).
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 This adaptation may happen autonomously by a central NMS monitoring
and adopting the parameters globally, autonomously by an NMS in each and adopting the parameters globally, autonomously by an NMS in each
router, monitoring its local topology (and its stability) and router, monitoring its local topology (and its stability) and
adapting parameters locally, or by manual operator intervention. adapting parameters locally, or by manual operator intervention.
Given the dynamic and evolutive topology of OLSRv2 networks, a highly Given the dynamic and evolutive topology of OLSRv2 networks, a highly
desirable property of an NMS is the ability to display and offer desirable property of an NMS is the ability to display and offer
visibility of the current network status - for example, to display a visibility of the current network status - for example, to display a
graphical map of which routers are currently part of the network. As graphical map of which routers are currently part of the network. As
skipping to change at page 10, line 39 skipping to change at page 11, line 13
part of the parameter configuration. The particularity of this part of the parameter configuration. The particularity of this
is, that it often is a "broadcast configuration operation" where is, that it often is a "broadcast configuration operation" where
new key material is supposed to be sent to everybody, and not just new key material is supposed to be sent to everybody, and not just
a single router, e.g., leveraging the optimized flooding mechanism a single router, e.g., leveraging the optimized flooding mechanism
of OLSRv2. of OLSRv2.
7. This Document does not Constrain how to Manage and Monitor MANETs 7. This Document does not Constrain how to Manage and Monitor MANETs
As explained in Section 1, this document describes how, what and why As explained in Section 1, this document describes how, what and why
some (typical) OLSRv2 networks are managed and monitored as of 2014. some (typical) OLSRv2 networks are managed and monitored as of 2014.
As such, the document is reflexive, not prescriptive: it does not As such, the document is reflective, not prescriptive: it does not
stipulate requirements for how to manage OLSRv2 networks, nor does it stipulate requirements for how to manage OLSRv2 networks, nor does it
claim to be a complete list of all management patterns or protocols. claim to be a complete list of all management patterns or protocols.
Other ways of managing an OLSRv2 network are very well imaginable - Other ways of managing an OLSRv2 network are very well imaginable -
now, or in future deployments of OLSRv2. now, or in future deployments of OLSRv2.
As an example of such a "future management scenario", rather than As an example of such a "future management scenario", rather than
managing and monitoring routers from a central NMS, a distributed, managing and monitoring routers from a central NMS, a distributed,
autonomous management system between multiple routers can be autonomous management system between multiple routers can be
envisioned. In particular, monitoring data that is used to debug envisioned. In particular, monitoring data that is used to debug
network problems and to tweak inefficiencies could be distributed network problems and to tweak inefficiencies could be distributed
skipping to change at page 11, line 41 skipping to change at page 12, line 21
With that being said, managing an OLSRv2 network requires the ability With that being said, managing an OLSRv2 network requires the ability
to inspect and affect the internal state of the routers therein, by to inspect and affect the internal state of the routers therein, by
way of mechanisms other than the protocol signals specified for way of mechanisms other than the protocol signals specified for
OLSRv2 [RFC7181] and NHDP [RFC6130]. OLSRv2 [RFC7181] and NHDP [RFC6130].
When affecting the state of the OLSRv2 routing process, a management When affecting the state of the OLSRv2 routing process, a management
process can be considered as an "outside process" to OLSRv2 and is process can be considered as an "outside process" to OLSRv2 and is
then expected to respect (at least) the constraints given in Section then expected to respect (at least) the constraints given in Section
5.5, Section 5.6, and in Appendix A of [RFC7181], as well as in 5.5, Section 5.6, and in Appendix A of [RFC7181], as well as in
Section 5.5 and in Appendix B of [RFC6130]. Section 5.5 and in Appendix B of [RFC6130]. The example from
Section 4.1 of setting excessively short message intervals, leading
to channel capacity exhaustion and frame collisions, demonstrates
that such an outside process can harm network stability considerably
when not carefully protected against unauthorized or unintended
usage.
For both inspecting and affecting the state of an OLSRv2 routing For both inspecting and affecting the state of an OLSRv2 routing
process by way of a management interface, great care is necessary to process by way of a management interface, great care is necessary to
avoid divulging information that should not be exposed, and in avoid divulging information that should not be exposed, and in
opening additional vulnerabilities by way of the management opening additional vulnerabilities by way of the management
interface. In part, to be able to benefit from securing existing interface. In part, to be able to benefit from securing existing
management interfaces, protocols, and implementations, migration to a management interfaces, protocols, and implementations, migration to a
standardized management framework is desired, and was one of the standardized management framework is desired, and was one of the
motivators for standardizing MIB modules for OLSRv2 and NHDP in the motivators for standardizing MIB modules for OLSRv2 and NHDP in the
first place. first place.
skipping to change at page 13, line 19 skipping to change at page 13, line 50
[RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity
Protection for the Neighborhood Discovery Protocol (NHDP) Protection for the Neighborhood Discovery Protocol (NHDP)
and Optimized Link State Routing Protocol Version 2 and Optimized Link State Routing Protocol Version 2
(OLSRv2)", RFC 7183, April 2014. (OLSRv2)", RFC 7183, April 2014.
[RFC7184] Herberg, U., Cole, R., and T. Clausen, "Definition of [RFC7184] Herberg, U., Cole, R., and T. Clausen, "Definition of
Managed Objects for the Optimized Link State Routing Managed Objects for the Optimized Link State Routing
Protocol Version 2", RFC 7184, April 2014. Protocol Version 2", RFC 7184, April 2014.
[RFC7187] Dearlove, C. and T. Clausen, "Routing Multipoint Relay
Optimization for the Optimized Link State Routing Protocol
Version 2 (OLSRv2)", RFC 7187, April 2014.
[RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing
Protocol Version 2 (OLSRv2) and MANET Neighborhood
Discovery Protocol (NHDP) Extension TLVs", RFC 7187,
April 2014.
Authors' Addresses Authors' Addresses
Thomas Clausen Thomas Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex,
France France
Phone: +33-6-6058-9349 Phone: +33-6-6058-9349
Email: T.Clausen@computer.org Email: T.Clausen@computer.org
URI: http://www.thomasclausen.org URI: http://www.thomasclausen.org
 End of changes. 23 change blocks. 
63 lines changed or deleted 100 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/