idnits 2.17.00 (12 Aug 2021) /tmp/idnits63798/draft-clausen-manet-olsrv2-management-snapshot-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 11, 2014) is 3021 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-manet-olsrv2 has been published as RFC 7181 == Outdated reference: draft-ietf-manet-olsrv2-mib has been published as RFC 7184 == Outdated reference: draft-ietf-manet-nhdp-olsrv2-sec has been published as RFC 7183 == Outdated reference: draft-ietf-manet-rfc6622-bis has been published as RFC 7182 -- Obsolete informational reference (is this intentional?): RFC 6779 (Obsoleted by RFC 7939) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 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: August 15, 2014 Fujitsu Laboratories of America 6 February 11, 2014 8 Snapshot of OLSRv2-Routed MANET Management 9 draft-clausen-manet-olsrv2-management-snapshot-01 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 routing protocol OLSRv2 and its constituent protocol 17 NHDP. Apart from pre-deployment management for setting up IP 18 addresses and security related credentials, OLSRv2 only needs routers 19 to agree one single parameter (called "C"). Other parameters for 20 tweaking network performance may be determined during operation of 21 the network, and need not be the same in all routers. This, using 22 MIB modules and related management protocols such as SNMP (or 23 possibly other, less "chatty", protocols). In addition, for 24 debugging purposes, monitoring data and performance related counters 25 can be sent to the Network Management Station (NMS) via standardized 26 management protocols. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 15, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Statement of Purpose . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Pre-Deployment Management . . . . . . . . . . . . . . . . . . 3 66 3.1. Lower Layer Alignment . . . . . . . . . . . . . . . . . . 4 67 3.2. Interface Addresses . . . . . . . . . . . . . . . . . . . 4 68 3.3. Security Material . . . . . . . . . . . . . . . . . . . . 5 69 3.4. The Value of C . . . . . . . . . . . . . . . . . . . . . . 5 70 4. How do we Manage MANETs? . . . . . . . . . . . . . . . . . . . 5 71 4.1. Internal Management . . . . . . . . . . . . . . . . . . . 6 72 4.2. External Management . . . . . . . . . . . . . . . . . . . 6 73 5. What and Why do we Manage and Monitor? . . . . . . . . . . . . 7 74 6. This Document does not Constrain how to Manage and Monitor 75 MANETs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 77 8. Informative References . . . . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 The MANET routing protocol OLSRv2 [OLSRv2], as well as its 83 constituent parts NHDP [RFC6130], [RFC5497], [RFC5148], [RFC5444], 84 [RFC6622bis], [OLSRv2-integrity], is designed to autonomously 85 maintain routes across a dynamic network topology. OLSRv2 is 86 designed so as to minimize operator intervention throughout the 87 duration of a network deployment, and to allow for heterogeneous 88 configuration of routers within the same network deployment: most 89 configuration values are either of local significance only (e.g., 90 message jitter parameters) or, when they are not, are carried in 91 control signals exchanged between routers (e.g., information validity 92 time). 94 All the same, a small set of configuration options must be 95 established in each router prior to deployment, with some requiring 96 agreement among all the routers within the same deployment. 97 Furthermore, throughout the duration of a network deployment, 98 external management and monitoring of a network may be desirable, 99 e.g., for performance optimization or debugging purposes. 101 1.1. Statement of Purpose 103 Deployments of OLSRv2 are diverse, and may include community 104 networks, constrained environments, tactical networks, etc. Each 105 such environment may present distinctly different requirements as to 106 management and monitoring. 108 This document does therefore explicitly not pretend to provide an 109 exhaustive description of how all OLSRv2 network deployments should 110 be managed and monitored - and does, specifically, not prescribe any 111 management model. 113 What this document does, however, is to present how some OLSRv2 114 network deployments are managed and monitored, using well-established 115 management patterns and well-known protocols. 117 2. Terminology 119 This document uses terminology from [OLSRv2], [RFC6130], and 120 [RFC5497]. 122 3. Pre-Deployment Management 124 Prior to operation of an OLSRv2 network, or more precisely, prior to 125 proper operation of OLSRv2 and its constituent parts, certain 126 parameters need to be configured on each router. The following 127 sections describe the required pre-deployment management. 129 3.1. Lower Layer Alignment 131 Interoperability between routers requires alignment of lower protocol 132 layers below OLSRv2. In particular, all routers in the same MANET 133 topology must be pre-configured to use the same IP address family 134 (IPv4 or IPv6). In a single OLSRv2 topology, it is not possible to 135 mix IPv4 and IPv6 addresses, notably because [RFC5444] messages can 136 contain either IPv4 *or* IPv6 addresses, but not both at the same 137 time. It is, however, possible to run two instances of OLSRv2, one 138 instance for IPv4 and another one for IPv6, within the same network. 140 In addition to the IP address family, other lower layer parameters 141 may also need to be aligned, e.g., radio channel selections. A 142 single OLSRv2 topology may, of course, span different link layers (or 143 the same link layer with different configuration settings such as 144 cryptographic keys) when routers in the topology have OLSRv2 145 interfaces towards these different link layers. 147 3.2. Interface Addresses 149 According to [RFC6130], and as used by [OLSRv2], each interface of a 150 router must be configured with at least one IP address. [RFC6130] 151 provides guidance as to the characteristics of such IP addresses, 152 including the (limited) conditions under which an IP address may be 153 configured on multiple interfaces. 155 While automatic configuration of IP addresses on router interfaces is 156 not excluded, currently no address autoconfiguration protocols have 157 been standardized (in the IETF) to accomplish this. As a 158 consequence, static configuration, or proprietary (as in: non- 159 standardized) protocols ensure this. 161 Note that this required pre-deployment of interface addresses does 162 not include "external" IP addresses, i.e., IP addresses that are 163 configured on local non-MANET interfaces or IP addresses from remote 164 destinations reachable through this router (i.e., addresses for which 165 this router serves as gateway). These can be added or removed 166 dynamically during runtime of OLSRv2. Such local non-MANET interface 167 addresses are managed by way of the Local Interface Set (as defined 168 in [RFC6130]) and remote addresses by way of the Attached Network Set 169 (as defined in [OLSRv2]). 171 3.3. Security Material 173 Security material (keys, algorithms, etc.) must be available for 174 generating Integrity Check Values (ICVs) for outgoing control 175 messages, and to allow validating ICVs in incoming control messages 176 [RFC6622bis] [OLSRv2-integrity]. 178 The appropriate way of making such security material available is 179 dependent on the deployment type. For example, community networks 180 (such as "Funkfeuer", http://funkfeuer.at), do currently not use any 181 security at all. Other deployment types may use a simple manual 182 shared key distribution mechanism, or may use a proprietary key 183 distribution protocol. Tactical networks have much more stringent 184 requirements for distributing key material, e.g., using manual 185 distribution of the keys on encrypted USB keys, and with defensive 186 mechanisms (up to and including mechanisms involving depleted 187 uranium) if the keys are compromised. 189 In general, Automatic Key Management (AKM) as well as static/manual 190 or other out-of-band mechanisms, can be viable options for 191 distributing keys. Currently, no standardized AKM mechanism for 192 MANETs exist. If the IETF standardizes such mechanisms in the 193 future, for deployment types where such is appropriate, these can be 194 used for distributing keys. Until such time, manual key distribution 195 as well as proprietary mechanisms, prevail. 197 The important point to make here, however, is that by whichever 198 method (automatic/manual, dynamic/static, ... ) a key and other 199 security material is made available, the security mechanisms of 200 OLSRv2, as defined by [OLSRv2-integrity], will be able to properly 201 use it for generating and validating ICVs. 203 3.4. The Value of C 205 The only pre-deployment configuration parameter that directly impacts 206 protocol operation is the value of C. This value is used by each 207 router for calculating the representation of interval and validity 208 time, as included in control messages. All routers in a deployment 209 must agree on the value of C, as described in [RFC5497]. 211 4. How do we Manage MANETs? 213 A deployed OLSRv2 network is, as previously discussed, operating 214 autonomously, but occasionally with internal or external management 215 operations being desirable, described in the following two sections. 217 4.1. Internal Management 219 Internal management describes a local process running on an router 220 that automatically (i.e., without external messaging or human 221 interaction) modifies the configuration of OLSRv2 based on different 222 environmental factors. For example, the HELLO interval may be 223 updated according to the rate of topology changes measured (or, 224 inferred: after all, the 'M' in MANET is for "Mobility") locally: if 225 the rate is high, then a more frequent HELLO update assures that 226 routes are more accurate. At a lower rate of topology changes, 227 network capacity and energy capacity of the router may be conserved 228 by increasing the HELLO interval. 230 Depending on the use case, many different automatic configuration 231 agents can be envisioned. As parameters in NHDP and OLSRv2 are 232 either only used locally or, in the case of HELLO_INTERVAL and 233 REFRESH_INTERVAL, are selected locally and then included in the 234 messages exchanged between adjacent routers in their HELLO messages, 235 none of these automatic local configuration methods needs necessarily 236 to be standardized: different routers doing different things will 237 interoperate. 239 4.2. External Management 241 For the deployments described by this document (but see Section 6), 242 external management operations are undertaken by a central Network 243 Management Station (NMS). 245 The MIB modules developed for OLSRv2 [OLSRv2-MIB] and for its 246 constituent protocol NHDP [RFC6779] are verbose, in as much as that 247 they expose for interrogation the complete protocol and router state, 248 as well as enable setting all parameters (timer intervals, time-outs, 249 jitter values etc.). They do explicitly not enable setting the value 250 of C (as that is required to be constant and uniform across the 251 network, see Section 3.4), nor distributing security material (see 252 Section 3.3). 254 In some deployments, the NMS communicates with individual routers by 255 way of SNMP - and, more commonly, by way of "proprietary" simpler, 256 less verbose and (often) less secure protocols, and over UDP. Note 257 that this does not constitute a recommendation, but rather an 258 observation that (apparently) SNMP has found less application in 259 MANETs. 261 The predecessor of OLSRv2, OLSR [RFC3626] did not have an associated 262 MIB module. Many deployments of OLSR did not support network 263 management operations per se (i.e., configuration-on-launch was the 264 way in which routers in these deployments were managed). Those 265 implementations and deployments of OLSR that did support network 266 management operations used a similar architecture to the one 267 described in this document, but with "proprietary" protocols and APIs 268 for parameters and router states, "proprietary" data-models, etc. It 269 can be speculated that the "proprietary" protocols used for 270 communication between the NMS and the MIB modules on each router also 271 for OLSRv2, in part, exist as inherited from the protocols used for 272 OLSR. 274 Finally, it is uncommon to see an NMS permanently active in a 275 deployed OLSRv2 network; rather, on an "ad hoc" basis an NMS is 276 introduced into the network, parameters configured or state 277 interrogated, following which the NMS disappears. 279 5. What and Why do we Manage and Monitor? 281 As indicated earlier, OLSRv2 and its constituent protocol NHDP, are 282 reasonably robust with respect to parameter values: a deployment can 283 operate with different parameters used in different routers in the 284 same network. That being said, adapting these parameters according 285 to circumstances is (often) desired. For example, in a stable 286 network (such as a wired network), TC messages may be sent 287 infrequently and with long validity times, whereas in a highly 288 dynamic network (such as in a vehicular network) TC messages may need 289 to be sent more frequently and HELLO messages for discovering the 290 local topology (almost) continuously. In a similar vein, the message 291 emission intervals and the information validity times should also be 292 commensurate with the available network capacity: millisecond 293 intervals between TC messages, for example, will consume all 294 available network capacity whereas hourly intervals will be 295 inappropriate even for a static and stable, wired, network (by way of 296 simply new routers arriving in the network, which will not "learn" 297 the network topology before undue long delays). 299 This adaptation may happen autonomously by a central NMS monitoring 300 and adopting the parameters globally, autonomously by an NMS in each 301 router, monitoring its local topology (and its stability) and 302 adapting parameters locally, or by manual operator intervention. 304 Given the dynamic and evolutive topology of OLSRv2 networks, a highly 305 desirable property of an NMS is the ability to display and offer 306 visibility of the current network status - for example, to display a 307 graphical map of which routers are currently part of the network. As 308 a proactive protocol, OLSRv2 maintains, in each router, a topology 309 map including all destinations and a subset of the links present in 310 the network (particularly true in a very dense network). A typical 311 feature of an NMS is to inquire as to the topology map of a single 312 router. A slightly less typical feature is to inquire all (or, at 313 least, many) routers in a network, with the purpose of presenting a 314 complete topology map. 316 In addition to actively monitoring an OLSRv2 network, erroneous or 317 unusual conditions on an router can be flagged to management, e.g., 318 detection of an unusually high number of 1-hop or 2-hop neighborhood 319 changes in a short amount of time, indicating potential problems in 320 that area of the network. [RFC6779] and [OLSRv2-MIB] facilitate 321 proactively sending "notifications" (also known as traps) from the 322 router towards an NMS. The MIB modules defined in [RFC6779] and 323 [OLSRv2-MIB] allow for defining both the threshold and the time 324 window of how many times this erroneous condition may occur in the 325 time window before the notification is sent to the NMS. Once the NMS 326 receives a notification, a network operator may investigate if there 327 is a problem that needs to be resolved, e.g., by changing parameters 328 via the above-described external management. 330 6. This Document does not Constrain how to Manage and Monitor MANETs 332 As explained in Section 1, this document describes how, what and why 333 some (typical) OLSRv2 networks are managed and monitored as of early 334 2014. As such, the document is reflexive, not prescriptive: it does 335 not stipulate requirements for how to manage OLSRv2 networks, nor 336 does it claim to be a complete list of all management patterns or 337 protocols. Other ways of managing an OLSRv2 network are very well 338 imaginable - now, or in future deployments of OLSRv2. 340 As an example of such a "future management scenario", rather than 341 managing and monitoring routers from a central NMS, a distributed, 342 autonomous management system between multiple routers can be 343 envisioned. In particular, monitoring data that is used to debug 344 network problems and to tweak inefficiencies could be distributed 345 amongst a group of routers in the same network. This would both 346 address problems of single point of failure when using only a single 347 NMS, as well provide additional information about groups of multiple 348 routers, rather than a single router. An example use for such a 349 distributed information flow would be to identify areas of a network 350 wherein, e.g., due to different router densities, message sending 351 interval parameters could be exchanged and optimal values negotiated 352 between routers, so as to obtain locally optimized performance. 354 While such a management model is highly interesting, it is also at 355 present entirely fictional - at least outside the realm of research. 356 It is included to, both, indicate directions being explored (but not 357 exploited), and to insist that the intent of this document is not to 358 prescribe how MANETs are to be managed, in the presence or in the 359 future, but to describe the (known) state of how MANETs are managed, 360 presently. 362 7. Acknowledgments 364 The authors would like to gratefully acknowledge the following people 365 for intense technical discussions, early reviews, and comments on the 366 documents: Alan Cullen (BAE Systems), Christopher Dearlove (BAE 367 Systems), and Adrian Farrel (Juniper). 369 8. Informative References 371 [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 372 "The Optimized Link State Routing Protocol version 2", 373 draft-ietf-manet-olsrv2-19 (work in progress), March 2013. 375 [OLSRv2-MIB] 376 Herberg, U., Cole, R., and T. Clausen, "Definition of 377 Managed Objects for the Optimized Link State Routing 378 Protocol version 2", work in 379 progress draft-ietf-manet-olsrv2-mib-12, June 2013. 381 [OLSRv2-integrity] 382 Herberg, U., Dearlove, C., and T. Clausen, "Integrity 383 Protection for Control Messages in NHDP and OLSRv2", work 384 in progress draft-ietf-manet-nhdp-olsrv2-sec-05, 385 September 2013. 387 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 388 Routing Protocol", RFC 3626, October 2003. 390 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 391 Considerations in Mobile Ad Hoc Networks (MANETs)", 392 RFC 5148, February 2008. 394 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 395 "Generalized MANET Packet/Message Format", RFC 5444, 396 February 2009. 398 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 399 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 400 March 2009. 402 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 403 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 404 RFC 6130, April 2011. 406 [RFC6622bis] 407 Herberg, U., Clausen, T., and C. Dearlove, "Integrity 408 Check Value and Timestamp TLV Definitions for Mobile Ad 409 Hoc Networks (MANETs)", work in 410 progress draft-ietf-manet-rfc6622-bis-06, November 2013. 412 [RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of 413 Managed Objects for the Neighborhood Discovery Protocol", 414 RFC 6779, May 2012. 416 Authors' Addresses 418 Thomas Clausen 419 LIX, Ecole Polytechnique 420 91128 Palaiseau Cedex, 421 France 423 Phone: +33-6-6058-9349 424 Email: T.Clausen@computer.org 425 URI: http://www.thomasclausen.org 427 Ulrich Herberg 428 Fujitsu Laboratories of America 429 1240 E Arques Ave 430 Sunnyvale CA 94086, 431 US 433 Phone: 434 Email: ulrich@herberg.name 435 URI: http://www.herberg.name