idnits 2.17.1 draft-clausen-manet-olsrv2-mgmt-snapshot-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 14, 2018) is 2293 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6779 (Obsoleted by RFC 7939) -- Duplicate reference: RFC7187, mentioned in 'RFC7188', was also mentioned in 'RFC7187'. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Clausen 3 Internet-Draft LIX, Ecole Polytechnique 4 Intended status: Informational U. Herberg 5 Expires: July 18, 2018 Fujitsu Laboratories of America 6 January 14, 2018 8 Snapshot of OLSRv2-Routed MANET Management 9 draft-clausen-manet-olsrv2-mgmt-snapshot-00 11 Abstract 13 This document describes how Mobile Ad Hoc Networks (MANETs) are 14 typically managed, in terms of pre-deployment management, as well as 15 rationale and means of monitoring and management of MANET routers 16 running the Optimized Link State Routing protocol version 2 (OLSRv2) 17 and its constituent MANET Neighborhood Discovery Protocol (NHDP). 18 Apart from pre-deployment management for setting up IP addresses and 19 security related credentials, OLSRv2 only needs routers to agree one 20 single configuration parameter (called "C"). Other parameters for 21 tweaking network performance may be determined during operation of 22 the network, and need not be the same in all routers. This, using 23 MIB modules and related management protocols such as SNMP (or 24 possibly other, less "chatty", protocols). In addition, for 25 debugging purposes, monitoring data and performance related counters, 26 as well as notifications ("traps") can be sent to the Network 27 Management System (NMS) via standardized management protocols. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on July 18, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Statement of Purpose . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Pre-Deployment Management . . . . . . . . . . . . . . . . . . 4 67 3.1. Lower Layer Alignment . . . . . . . . . . . . . . . . . . 4 68 3.2. Interface Addresses . . . . . . . . . . . . . . . . . . . 4 69 3.3. Security Material . . . . . . . . . . . . . . . . . . . . 5 70 3.4. The Value of C . . . . . . . . . . . . . . . . . . . . . . 5 71 4. How do we Manage OLSRv2-based MANETs? . . . . . . . . . . . . 6 72 4.1. Internal Management . . . . . . . . . . . . . . . . . . . 6 73 4.2. External Management . . . . . . . . . . . . . . . . . . . 6 74 5. What and Why do we Manage and Monitor? . . . . . . . . . . . . 7 75 6. Typical Communication Patterns . . . . . . . . . . . . . . . . 9 76 7. This Document does not Constrain how to Manage and Monitor 77 MANETs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 81 11. Informative References . . . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 The MANET routing protocol OLSRv2 [RFC7181], as well as its 87 constituent parts NHDP [RFC6130], [RFC5497], [RFC5148], [RFC5444], 88 [RFC7182], [RFC7183], [RFC7187], [RFC7188] is designed to 89 autonomously maintain routes across a dynamic network topology. 90 OLSRv2 is designed so as to minimize operator intervention throughout 91 the duration of a network deployment, and to allow for heterogeneous 92 configuration of routers within the same network deployment: most 93 configuration values are either of local significance only (e.g., 94 message jitter parameters) or, when they are not, are carried in 95 control signals exchanged between routers (e.g., information validity 96 time). 98 All the same, a small set of configuration options must be 99 established in each router prior to deployment, with some requiring 100 agreement among all the routers within the same deployment. 101 Furthermore, throughout the duration of a network deployment, 102 external management and monitoring of a network may be desirable, 103 e.g., for performance optimization or debugging purposes. 105 1.1. Statement of Purpose 107 Deployments of OLSRv2 are diverse, and may include community 108 networks, constrained environments, tactical networks, etc. Each 109 such environment may present distinctly different requirements as to 110 management and monitoring. 112 This document does therefore explicitly not pretend to provide an 113 exhaustive description of how all OLSRv2 network deployments should 114 be managed and monitored - and does, specifically, not prescribe any 115 management model. This document also does not address management of 116 MANETs using any routing protocols, other than OLSRv2. 118 What this document does, however, is to present how typical OLSRv2 119 network deployments are managed and monitored, using well-established 120 management patterns and well-known protocols. In particular, this 121 document addresses several of the consideration from [RFC5706], in 122 particular Section 3 ("Management Considerations - How Will the 123 Protocol Be Managed?"). 125 2. Terminology 127 This document uses terminology from [RFC7181], [RFC6130], and 128 [RFC5497]. 130 3. Pre-Deployment Management 132 Prior to operation of an OLSRv2 network, or more precisely, prior to 133 proper operation of OLSRv2 and its constituent parts, certain 134 parameters need to be configured on each router. The following 135 sections describe the required pre-deployment management. 137 3.1. Lower Layer Alignment 139 Interoperability between routers requires alignment of lower protocol 140 layers below OLSRv2. In particular, all routers in the same MANET 141 topology must be pre-configured to use the same IP address family 142 (IPv4 or IPv6). In a single OLSRv2 topology, it is not possible to 143 mix IPv4 and IPv6 addresses, notably because [RFC5444] messages can 144 contain either IPv4 *or* IPv6 addresses, but not both at the same 145 time. It is, however, possible to run two instances of OLSRv2, one 146 instance for IPv4 and another one for IPv6, within the same network. 148 In addition to the IP address family, other lower layer parameters 149 may also need to be aligned, e.g., MAC as well as radio channel 150 selections. A single OLSRv2 topology may, of course, span different 151 link layers (or the same link layer with different configuration 152 settings such as cryptographic keys) when routers in the topology 153 have OLSRv2 interfaces towards these different link layers. 155 3.2. Interface Addresses 157 According to [RFC6130], and as used by [RFC7181], each interface of a 158 router must be configured with at least one IP address. [RFC6130] 159 provides guidance as to the characteristics of such IP addresses, 160 including the (limited) conditions under which a single IP address 161 may be configured on multiple interfaces. 163 While automatic configuration of IP addresses on router interfaces is 164 not excluded, currently no address autoconfiguration protocols have 165 been standardized (in the IETF) to accomplish this. As a 166 consequence, static configuration, or proprietary (as in: non- 167 standardized) protocols ensure this. 169 Note that [RFC6130] and [RFC7181] permit to dynamically add or remove 170 IP addresses as part of normal network operation. This applies for 171 local MANET interfaces, as well as for local non-MANET interfaces or 172 IP addresses from remote destinations reachable through this router 173 (i.e., addresses for which this router serves as gateway). Interface 174 addresses are managed by way of the Local Interface Set (as defined 175 in [RFC6130]) and remote addresses by way of the Attached Network Set 176 (as defined in [RFC7181]). 178 3.3. Security Material 180 Security material (keys, algorithms, etc.) must be available for 181 generating Integrity Check Values (ICVs) for outgoing control 182 messages, and to allow validating ICVs in incoming control messages 183 [RFC7182] [RFC7183]. 185 The appropriate way of making such security material available is 186 dependent on the deployment type. For example, community networks 187 (such as "Funkfeuer", http://funkfeuer.at), do currently not use any 188 security at all. Other deployment types may use a simple manual 189 shared key distribution mechanism, or may use a proprietary key 190 distribution protocol. Tactical networks have much more stringent 191 requirements for distributing key material, e.g., using manual 192 distribution of the keys on encrypted USB flash drives, and with 193 defensive mechanisms (up to and including mechanisms involving 194 depleted uranium) if the keys are compromised. 196 In general, Automatic Key Management (AKM) as well as static/manual 197 or other out-of-band mechanisms, can be viable options for 198 distributing keys. Currently, no standardized AKM mechanism for 199 MANETs exist. If the IETF standardizes such mechanisms in the 200 future, for deployment types where such is appropriate, these can be 201 used for distributing keys (with the obvious chicken-and-egg problem 202 of using the routing fabric that is being constructed to distribute 203 the keys to establish that fabric). Until such an AKM mechanism is 204 standardized, manual key distribution as well as proprietary 205 mechanisms prevail. 207 The important point to make here, however, is that by whichever 208 method (automatic/manual, dynamic/static, ... ) a key and other 209 security material is made available, the security mechanisms of 210 OLSRv2, as defined by [RFC7183], will be able to properly use it for 211 generating and validating ICVs. 213 3.4. The Value of C 215 The only pre-deployment configuration parameter that directly impacts 216 protocol operation is the value of C. This value is used by each 217 router for calculating the representation of interval and validity 218 time, as included in control messages. All routers in a deployment 219 must agree on the value of C, as described in [RFC5497]. Note that 220 since all MANET routers inside a MANET must agree to the same value 221 of C before deployment, C is denoted "constant" in [RFC5497] rather 222 than "parameter" as in this document. From a management perspective, 223 C can be considered as configuration parameter prior to operation of 224 the routing protocol. 226 4. How do we Manage OLSRv2-based MANETs? 228 A deployed OLSRv2 network is, as previously discussed, operating 229 autonomously, but occasionally with internal or external management 230 operations being desirable, described in the following two sections. 232 4.1. Internal Management 234 Internal management describes a local process running on a router 235 that automatically (i.e., without external messaging or human 236 interaction) modifies the configuration of OLSRv2 based on different 237 environmental factors. In particular, message intervals can be 238 updated dynamically and without external management interaction, 239 e.g., the HELLO interval may be updated according to the rate of 240 topology changes measured (or, inferred: after all, the 'M' in MANET 241 is for "Mobility") locally: if the rate is high, then a more frequent 242 HELLO update assures that routes are more accurate. At a lower rate 243 of topology changes, network capacity and energy capacity of the 244 router may be conserved by increasing the HELLO interval. In 245 addition to message intervals, minimum intervals can have a 246 significant impact on the operation of OLSRv2, and therefore need to 247 be adjusted with care. If, for instance, the minimum interval 248 between two successive HELLO messages (HELLO_MIN_INTERVAL) is set too 249 low, many messages may be sent within a short timeframe, potentially 250 leading to frame collisions or exhaustion of the available bandwidth. 252 Depending on the use case, many different automatic configuration 253 agents can be envisioned. As parameters in NHDP and OLSRv2 are 254 either only used locally or, in the case of HELLO_INTERVAL and 255 REFRESH_INTERVAL, are selected locally and then included in the 256 messages exchanged between adjacent routers in their HELLO messages, 257 none of these automatic local configuration methods need necessarily 258 to be standardized: different routers doing different things will 259 interoperate. 261 4.2. External Management 263 For the deployments described by this document (but, see Section 7), 264 external management operations are undertaken by a central Network 265 Management Station (NMS). 267 The MIB modules developed for OLSRv2 [RFC7184] and for its 268 constituent protocol NHDP [RFC6779] are verbose, in as much as that 269 they expose for interrogation the complete protocol and router state, 270 as well as enable setting all parameters (timer intervals, time-outs, 271 jitter values etc.). They do explicitly not enable setting the value 272 of C (as that is required to be constant and uniform across the 273 network, see Section 3.4), nor distributing security material (see 274 Section 3.3). 276 In some deployments, the NMS communicates with individual routers by 277 way of SNMP - and, more commonly, by way of "proprietary" simpler, 278 less verbose and (often) less secure protocols, and over UDP. Note 279 that this does not constitute a recommendation, but rather an 280 observation that (apparently) SNMP has found less application in 281 MANETs. The "Writable MIB Module IESG Statement" 282 (http://www.ietf.org/iesg/statement/writable-mib-module.html) 283 recommends to use MIB modules for read-only operations only, and to 284 use YANG/NETCONF for read-write operations instead. While 285 publication of the MIB modules developed for OLSRv2 and NHDP predates 286 this statement, it may be possible to translate read-only objects 287 from the MIB modules into YANG modules using [RFC6643]. A complete 288 YANG model representing similar objects as in the MIB modules could, 289 of course, be developed. 291 The predecessor of OLSRv2, OLSR [RFC3626] did not have any associated 292 MIB module. Many deployments of OLSR did not support network 293 management operations per se (i.e., configuration-on-launch was the 294 way in which routers in these deployments were managed). Those 295 implementations and deployments of OLSR that did support network 296 management operations used a similar architecture to the one 297 described in this document, but with "proprietary" protocols and APIs 298 for parameters and router states, "proprietary" data-models, etc. It 299 can be speculated that the "proprietary" protocols used for 300 communication between the NMS and the MIB modules on each router also 301 for OLSRv2, in part, exist as inherited from the protocols used for 302 OLSR. Aligned with the recommendations from [RFC5706], management of 303 OLSRv2 (in the form of the MIB modules for OLSRv2 and NHDP) has been 304 developed alongside the standardization process of OLSRv2, rather 305 than as an afterthought. 307 Finally, it is uncommon to see an NMS permanently active in a 308 deployed OLSRv2 network; rather, on an "ad hoc" basis an NMS is 309 introduced into the network, parameters configured or state 310 interrogated, following which the NMS disappears. Part of the 311 rationale for this is that in a MANET, network connectivity from 312 every MANET router to an NMS cannot be guaranteed at all times due to 313 the dynamicity of the network topology. 315 5. What and Why do we Manage and Monitor? 317 As indicated earlier, OLSRv2 and its constituent protocol NHDP, are 318 reasonably robust with respect to parameter values: a deployment can 319 operate with different parameters used in different routers in the 320 same network. That being said, adapting these parameters according 321 to circumstances is (often) desired. For example, in a stable 322 network (such as a wired network), TC messages may be sent 323 infrequently and with long validity times, whereas in a highly 324 dynamic network (such as in a vehicular network) TC messages may need 325 to be sent more frequently and HELLO messages for discovering the 326 local topology (almost) continuously. Note that for highly dynamic 327 topologies, an alternative to sending control messages very 328 frequently is to use long message intervals in combination with all 329 of the permitted responsive mechanisms (e.g., to send an externally 330 triggered HELLO when the local topology of a router changes) and with 331 low minimum intervals. In this case, it is possible though that one 332 control message may get lost, and then OLSRv2 needs to react in order 333 to avoid a long convergence time. (One possibility is to reduce 334 HELLO_INTERVAL to minimum for a few HELLO messages, then restore it). 336 In a similar vein, the message emission intervals and the information 337 validity times should also be commensurate with the available network 338 capacity: millisecond intervals between TC messages, for example, 339 will consume all available network capacity whereas hourly intervals 340 will be inappropriate even for a static and stable, wired, network 341 (by way of simply new routers arriving in the network, which will not 342 "learn" the network topology before undue long delays). 344 These adaptations may be imparted (i) autonomously by a central NMS 345 monitoring and adopting the parameters globally, (ii) autonomously by 346 an NMS in each router monitoring its local topology (and its 347 stability) and adapting parameters locally, or (iii) by manual 348 operator intervention. 350 Given the dynamic and evolutive topology of OLSRv2 networks, a highly 351 desirable property of an NMS is the ability to display and offer 352 visibility of the current network status - for example, to display a 353 graphical map of which routers are currently part of the network. As 354 a proactive protocol, OLSRv2 maintains, in each router, a topology 355 map including all destinations and a subset of the links present in 356 the network (particularly true in a very dense network). A typical 357 feature of an NMS is to inquire as to the topology map of a single 358 router. A less typical feature is to inquire all (or, at least, 359 many) routers in a network, with the purpose of presenting a complete 360 topology map. 362 In addition to actively monitoring an OLSRv2 network, erroneous or 363 unusual conditions on a router can be flagged, e.g., detection of an 364 unusually high number of 1-hop or 2-hop neighborhood changes in a 365 short amount of time, indicating potential problems in that area of 366 the network. [RFC6779] and [RFC7184] facilitate proactively sending 367 "notifications" (also known as traps) from the router towards an NMS. 368 The MIB modules defined in [RFC6779] and [RFC7184] allow for defining 369 both the threshold and the time window of how many times this 370 erroneous condition may occur in the time window before the 371 notification is sent to the NMS. Once the NMS receives a 372 notification, a network operator may investigate if there is a 373 problem that needs to be resolved, e.g., by changing parameters via 374 the above-described external management. 376 6. Typical Communication Patterns 378 This section describes typical (management) communications patterns 379 in an operating (post-startup) network. One of the key 380 characteristics of OLSRv2 is that is enables an efficient flooding 381 mechanism (denoted "MPR Flooding"). For some management scenarios, 382 this facilitates better performance by (scope-limited) flooding 383 management requests to MANET routers, rather than sending multiple 384 consecutive unicast messages. While the MIB modules developed for 385 OLSRv2 and NHDP do not support such broadcast operation (due to the 386 nature of SNMP), some of the proprietary management tools mentioned 387 in Section 4 take advantage of this for increased performance. 389 The below list of such communication patterns is not claimed to be 390 exhaustive, and depending on the deployment, different patterns may 391 be used. However, these patterns have been observed in many 392 deployments of OLSRv2 and its constituent parts, as well as of its 393 predecessor OLSR. 395 a) Inquire the state (complete topology graph, link states, and local 396 links - even those not part of topology graph) of a router. An 397 NMS would typically initiate that request. OLSRv2 contains a 398 number of "Information Bases"; basically, tables with rows 399 representing information about local interfaces, other routers in 400 the MANET or the topology of the MANET as perceived by the MANET 401 router. These tables are also reflected as objects in the MIB 402 modules and can be inquired via, e.g., GETBULK for getting 403 multiple rows in a single request. Depending on the number of 404 MANET routers in the network and on the density of the MANET, 405 these "Information Bases" of a router describing one-hop and two- 406 hop routers, as well as routers farther away in the network, can 407 contain a substantial amount of information. Therefore, an NMS 408 inquiring for a complete copy of them them will return multiple KB 409 or more of data. Given the dynamic topology and often bandwidth- 410 constrained wireless links between MANET routers, this is not a 411 very commonly observed operation. Moreover, this would typically 412 only be required in debugging situations, as during regular 413 operations, OLSRv2 updates the state automatically and reacts to 414 changes (e.g., by triggering control message generation). This 415 type of operation can benefit from the optimized flooding 416 mechanism, by requesting the state from multiple routers in a 417 region of the MANET in a single request. 419 b) Inquire the history/statistics of a router. This request, 420 initiated by an NMS, is typically a small inquiry, such as "how 421 many local link changes have occured within the past n minutes/ 422 seconds/hours". This may be a rare occurence, or it may be occur 423 several times per minute and per router, at least for some time: 424 for example, an NMS may attempt to, e.g., "tune" message intervals 425 and timers, by sending this request to a group of topologically 426 close routers - and do so until the NMS decides that the topology 427 has stabilized. Again, this feature of requesting performance 428 related information is supported by the MIB modules for OLSRv2 and 429 NHDP. While SNMP does not support sending the inquiry via 430 optimized flooding, proprietary protocols take advantage of the 431 optimized flooding mechanism, to reduce the number of unicast 432 requests. 434 c) Change the configuration of a router. Other than in the above 435 case in b) (tuning), this really happens only when somehow a 436 router gets a new uplink to an external network, and either a new 437 gateway is added into the network, and/or a new prefix needs to be 438 distributed to the routers. The MIB modules for OLSRv2 and NHDP 439 allow to set all configuration parameters of each router. 440 Optimized flooding may significantly reduce the amount of unicast 441 requests, but are not supported by SNMP. 443 d) Visualizing the network as a router sees it. As in a MANET, 444 routers may move and link quality may vary due to link layer 445 characteristics, the network topology may change frequently. In a 446 naive way, this would essentially be the NMS setting up a 447 connection to the router in question, and getting a copy of all 448 routing protocol control messages to construct its own topology 449 graph as would have done that router. Typically, it consists of 450 the router sending a notification to the NMS when a topological 451 change happens, i.e., when either of its information bases change. 452 Even better, it consists of these notifications being "filtered" 453 to only send for those changes that actually impact the usable 454 topology. The latter case is supported by the MIB modules for 455 OLSRv2 and NHDP in the form of notifications (also called "traps") 456 that are send from the MANET router to the NMS. While these 457 notifications alone do not allow the NMS to visualize the 458 topology, they may suffice to inform the NMS of an unusual change 459 of the topology, and the NMS may inquire the current topology via 460 the process described in a). 462 e) Rekeying There is currently no (standardized) mechanism for 463 automated key management. One of the reasons for this may be that 464 it is difficult to come up with a single such that will satisfy 465 the requirements for all the different deployments. However in 466 MANET deploymentsm rekeying is something that can be observed, 467 e.g., as part of the parameter configuration. The particularity 468 of this is, that it often is a "broadcast configuration operation" 469 where new key material is supposed to be sent to everybody, and 470 not just a single router, e.g., leveraging the optimized flooding 471 mechanism of OLSRv2. 473 7. This Document does not Constrain how to Manage and Monitor MANETs 475 As explained in Section 1, this document describes how, what, and 476 why, some (typical) OLSRv2 networks are managed and monitored as of 477 2018. As such, the document is reflective, not prescriptive: it does 478 not stipulate requirements for how to manage OLSRv2 networks, nor 479 does it claim to be a complete list of all management patterns or 480 protocols. Other ways of managing an OLSRv2 network are very well 481 imaginable - now, or in future deployments of OLSRv2. 483 As an example of such a "future management scenario", rather than 484 managing and monitoring routers from a central NMS, a distributed, 485 autonomous management system between multiple routers can be 486 envisioned. In particular, monitoring data that is used to debug 487 network problems and to tweak inefficiencies could be distributed 488 amongst a group of routers in the same network. This would both 489 address problems of single point of failure when using only a single 490 NMS, as well provide additional information about groups of multiple 491 routers, rather than a single router. An example use for such a 492 distributed information flow would be to identify areas of a network 493 wherein, e.g., due to different router densities, message sending 494 interval parameters could be exchanged and optimal values negotiated 495 between routers, so as to obtain locally optimized performance. 497 While such a management model is highly interesting, it is also at 498 present entirely fictional - at least outside the realm of research. 499 It is included to, both, indicate directions being explored (but not 500 exploited), and to insist that the intent of this document is not to 501 prescribe how MANETs are to be managed, in the presence or in the 502 future, but to describe the (known) state of how MANETs are managed, 503 presently. 505 8. IANA Considerations 507 This document has no actions for IANA. 509 [This section may be removed by the RFC Editor.] 511 9. Security Considerations 513 This document does not specify a protocol, nor does it provide 514 recommendations for how to manage an OLSRv2 deployment - rather, it 515 reflects how some known deployments of OLSRv2 (and its predecessor, 516 OLSR) have been known to be managed. 518 With that being said, managing an OLSRv2 network requires the ability 519 to inspect and affect the internal state of the routers therein, by 520 way of mechanisms other than the protocol signals specified for 521 OLSRv2 [RFC7181] and NHDP [RFC6130]. 523 When affecting the state of the OLSRv2 routing process, a management 524 process can be considered as an "outside process" to OLSRv2 and is 525 then expected to respect (at least) the constraints given in Section 526 5.5, Section 5.6, and in Appendix A of [RFC7181], as well as in 527 Section 5.5 and in Appendix B of [RFC6130]. The example from 528 Section 4.1 of setting excessively short message intervals, leading 529 to channel capacity exhaustion and frame collisions, demonstrates 530 that such an outside process can harm network stability considerably 531 when not carefully protected against unauthorized or unintended 532 usage. 534 For both inspecting and affecting the state of an OLSRv2 routing 535 process by way of a management interface, great care is necessary to 536 avoid divulging information that should not be exposed, and in 537 opening additional vulnerabilities by way of the management 538 interface. In part, to be able to benefit from securing existing 539 management interfaces, protocols, and implementations, migration to a 540 standardized management framework is desired, and was one of the 541 motivators for standardizing MIB modules for OLSRv2 and NHDP in the 542 first place. 544 10. Acknowledgments 546 The authors would like to gratefully acknowledge the following people 547 for intense technical discussions, early reviews, and comments on the 548 documents: Alan Cullen (BAE Systems), Christopher Dearlove (BAE 549 Systems), Adrian Farrel (Juniper), David Harrington (Comcast), and 550 Jurgen Schoenwaelder (Jacobs University). 552 11. Informative References 554 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 555 Routing Protocol", RFC 3626, October 2003. 557 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 558 Considerations in Mobile Ad Hoc Networks (MANETs)", 559 RFC 5148, February 2008. 561 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 562 "Generalized MANET Packet/Message Format", RFC 5444, 563 February 2009. 565 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 566 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 567 March 2009. 569 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 570 Management of New Protocols and Protocol Extensions", 571 RFC 5706, November 2009. 573 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 574 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 575 RFC 6130, April 2011. 577 [RFC6643] Schoenwaelder, J., "Translation of Structure of Management 578 Information Version 2 (SMIv2) MIB Modules to YANG 579 Modules", RFC 6643, July 2012. 581 [RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of 582 Managed Objects for the Neighborhood Discovery Protocol", 583 RFC 6779, May 2012. 585 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 586 "The Optimized Link State Routing Protocol Version 2", 587 RFC 7181, April 2014. 589 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 590 Check Value and Timestamp TLV Definitions for Mobile Ad 591 Hoc Networks (MANETs)", RFC 7182, April 2014. 593 [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity 594 Protection for the Neighborhood Discovery Protocol (NHDP) 595 and Optimized Link State Routing Protocol Version 2 596 (OLSRv2)", RFC 7183, April 2014. 598 [RFC7184] Herberg, U., Cole, R., and T. Clausen, "Definition of 599 Managed Objects for the Optimized Link State Routing 600 Protocol Version 2", RFC 7184, April 2014. 602 [RFC7187] Dearlove, C. and T. Clausen, "Routing Multipoint Relay 603 Optimization for the Optimized Link State Routing Protocol 604 Version 2 (OLSRv2)", RFC 7187, April 2014. 606 [RFC7188] Dearlove, C. and T. Clausen, "Optimized Link State Routing 607 Protocol Version 2 (OLSRv2) and MANET Neighborhood 608 Discovery Protocol (NHDP) Extension TLVs", RFC 7187, 609 April 2014. 611 Authors' Addresses 613 Thomas Clausen 614 LIX, Ecole Polytechnique 615 91128 Palaiseau Cedex, 616 France 618 Phone: +33-6-6058-9349 619 Email: T.Clausen@computer.org 620 URI: http://www.thomasclausen.org 622 Ulrich Herberg 623 Fujitsu Laboratories of America 624 1240 E Arques Ave 625 Sunnyvale CA 94086, 626 US 628 Phone: 629 Email: ulrich@herberg.name 630 URI: http://www.herberg.name