idnits 2.17.1 draft-ietf-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 (July 4, 2014) is 3582 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) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: January 5, 2015 Fujitsu Laboratories of America 6 July 4, 2014 8 Snapshot of OLSRv2-Routed MANET Management 9 draft-ietf-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 Optimized Link State Routing protocol version 2 (OLSRv2) 17 and its constituent MANET NehgiborHood 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 parameter (called "C"). Other parameters for tweaking network 21 performance may be determined during operation of the network, and 22 need not be the same in all routers. This, using MIB modules and 23 related management protocols such as SNMP (or possibly other, less 24 "chatty", protocols). In addition, for debugging purposes, 25 monitoring data and performance related counters, as well as 26 notifications ("traps") can be sent to the Network Management System 27 (NMS) via standardized management protocols. This document 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 January 5, 2015. 46 Copyright Notice 48 Copyright (c) 2014 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? . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . 8 76 7. This Document does not Constrain how to Manage and Monitor 77 MANETs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 79 9. Informative References . . . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 The MANET routing protocol OLSRv2 [RFC7181], as well as its 85 constituent parts NHDP [RFC6130], [RFC5497], [RFC5148], [RFC5444], 86 [RFC7182], [RFC7183], is designed to autonomously maintain routes 87 across a dynamic network topology. OLSRv2 is designed so as to 88 minimize operator intervention throughout the duration of a network 89 deployment, and to allow for heterogeneous configuration of routers 90 within the same network deployment: most configuration values are 91 either of local significance only (e.g., message jitter parameters) 92 or, when they are not, are carried in control signals exchanged 93 between routers (e.g., information validity time). 95 All the same, a small set of configuration options must be 96 established in each router prior to deployment, with some requiring 97 agreement among all the routers within the same deployment. 98 Furthermore, throughout the duration of a network deployment, 99 external management and monitoring of a network may be desirable, 100 e.g., for performance optimization or debugging purposes. 102 1.1. Statement of Purpose 104 Deployments of OLSRv2 are diverse, and may include community 105 networks, constrained environments, tactical networks, etc. Each 106 such environment may present distinctly different requirements as to 107 management and monitoring. 109 This document does therefore explicitly not pretend to provide an 110 exhaustive description of how all OLSRv2 network deployments should 111 be managed and monitored - and does, specifically, not prescribe any 112 management model. This document also does not address management of 113 MANET routing protocols, other than OLSRv2 (and its constituent 114 protocols). 116 What this document does, however, is to present how some OLSRv2 117 network deployments are managed and monitored, using well-established 118 management patterns and well-known protocols. In particular, this 119 document addresses several of the consideration from [RFC5706], in 120 particular Section 3 ("Management Considerations - How Will the 121 Protocol Be Managed?"). 123 2. Terminology 125 This document uses terminology from [RFC7181], [RFC6130], and 126 [RFC5497]. 128 3. Pre-Deployment Management 130 Prior to operation of an OLSRv2 network, or more precisely, prior to 131 proper operation of OLSRv2 and its constituent parts, certain 132 parameters need to be configured on each router. The following 133 sections describe the required pre-deployment management. 135 3.1. Lower Layer Alignment 137 Interoperability between routers requires alignment of lower protocol 138 layers below OLSRv2. In particular, all routers in the same MANET 139 topology must be pre-configured to use the same IP address family 140 (IPv4 or IPv6). In a single OLSRv2 topology, it is not possible to 141 mix IPv4 and IPv6 addresses, notably because [RFC5444] messages can 142 contain either IPv4 *or* IPv6 addresses, but not both at the same 143 time. It is, however, possible to run two instances of OLSRv2, one 144 instance for IPv4 and another one for IPv6, within the same network. 146 In addition to the IP address family, other lower layer parameters 147 may also need to be aligned, e.g., radio channel selections. A 148 single OLSRv2 topology may, of course, span different link layers (or 149 the same link layer with different configuration settings such as 150 cryptographic keys) when routers in the topology have OLSRv2 151 interfaces towards these different link layers. 153 3.2. Interface Addresses 155 According to [RFC6130], and as used by [RFC7181], each interface of a 156 router must be configured with at least one IP address. [RFC6130] 157 provides guidance as to the characteristics of such IP addresses, 158 including the (limited) conditions under which an IP address may be 159 configured on multiple interfaces. 161 While automatic configuration of IP addresses on router interfaces is 162 not excluded, currently no address autoconfiguration protocols have 163 been standardized (in the IETF) to accomplish this. As a 164 consequence, static configuration, or proprietary (as in: non- 165 standardized) protocols ensure this. 167 Note that this required pre-deployment of interface addresses does 168 not include "external" IP addresses, i.e., IP addresses that are 169 configured on local non-MANET interfaces or IP addresses from remote 170 destinations reachable through this router (i.e., addresses for which 171 this router serves as gateway). These can be added or removed 172 dynamically during runtime of OLSRv2. Such local non-MANET interface 173 addresses are managed by way of the Local Interface Set (as defined 174 in [RFC6130]) and remote addresses by way of the Attached Network Set 175 (as defined in [RFC7181]). 177 3.3. Security Material 179 Security material (keys, algorithms, etc.) must be available for 180 generating Integrity Check Values (ICVs) for outgoing control 181 messages, and to allow validating ICVs in incoming control messages 182 [RFC7182] [RFC7183]. 184 The appropriate way of making such security material available is 185 dependent on the deployment type. For example, community networks 186 (such as "Funkfeuer", http://funkfeuer.at), do currently not use any 187 security at all. Other deployment types may use a simple manual 188 shared key distribution mechanism, or may use a proprietary key 189 distribution protocol. Tactical networks have much more stringent 190 requirements for distributing key material, e.g., using manual 191 distribution of the keys on encrypted USB keys, and with defensive 192 mechanisms (up to and including mechanisms involving depleted 193 uranium) if the keys are compromised. 195 In general, Automatic Key Management (AKM) as well as static/manual 196 or other out-of-band mechanisms, can be viable options for 197 distributing keys. Currently, no standardized AKM mechanism for 198 MANETs exist. If the IETF standardizes such mechanisms in the 199 future, for deployment types where such is appropriate, these can be 200 used for distributing keys. Until such time, manual key distribution 201 as well as proprietary mechanisms, prevail. 203 The important point to make here, however, is that by whichever 204 method (automatic/manual, dynamic/static, ... ) a key and other 205 security material is made available, the security mechanisms of 206 OLSRv2, as defined by [RFC7183], will be able to properly use it for 207 generating and validating ICVs. 209 3.4. The Value of C 211 The only pre-deployment configuration parameter that directly impacts 212 protocol operation is the value of C. This value is used by each 213 router for calculating the representation of interval and validity 214 time, as included in control messages. All routers in a deployment 215 must agree on the value of C, as described in [RFC5497]. 217 4. How do we Manage OLSRv2-based MANETs? 219 A deployed OLSRv2 network is, as previously discussed, operating 220 autonomously, but occasionally with internal or external management 221 operations being desirable, described in the following two sections. 223 4.1. Internal Management 225 Internal management describes a local process running on a router 226 that automatically (i.e., without external messaging or human 227 interaction) modifies the configuration of OLSRv2 based on different 228 environmental factors. For example, the HELLO interval may be 229 updated according to the rate of topology changes measured (or, 230 inferred: after all, the 'M' in MANET is for "Mobility") locally: if 231 the rate is high, then a more frequent HELLO update assures that 232 routes are more accurate. At a lower rate of topology changes, 233 network capacity and energy capacity of the router may be conserved 234 by increasing the HELLO interval. 236 Depending on the use case, many different automatic configuration 237 agents can be envisioned. As parameters in NHDP and OLSRv2 are 238 either only used locally or, in the case of HELLO_INTERVAL and 239 REFRESH_INTERVAL, are selected locally and then included in the 240 messages exchanged between adjacent routers in their HELLO messages, 241 none of these automatic local configuration methods needs necessarily 242 to be standardized: different routers doing different things will 243 interoperate. 245 4.2. External Management 247 For the deployments described by this document (but see Section 7), 248 external management operations are undertaken by a central Network 249 Management Station (NMS). 251 The MIB modules developed for OLSRv2 [RFC7184] and for its 252 constituent protocol NHDP [RFC6779] are verbose, in as much as that 253 they expose for interrogation the complete protocol and router state, 254 as well as enable setting all parameters (timer intervals, time-outs, 255 jitter values etc.). They do explicitly not enable setting the value 256 of C (as that is required to be constant and uniform across the 257 network, see Section 3.4), nor distributing security material (see 258 Section 3.3). 260 In some deployments, the NMS communicates with individual routers by 261 way of SNMP - and, more commonly, by way of "proprietary" simpler, 262 less verbose and (often) less secure protocols, and over UDP. Note 263 that this does not constitute a recommendation, but rather an 264 observation that (apparently) SNMP has found less application in 265 MANETs. The "Writable MIB Module IESG Statement" 266 (http://www.ietf.org/iesg/statement/writable-mib-module.html) 267 recommends to use MIB modules for read-only operations only, and to 268 use YANG/NETCONF for read-write operations instead. While 269 publication of the MIB modules developed for OLSRv2 and NHDP predates 270 this statement, it may be possible to translate read-only objects 271 from the MIB modules into YANG modules using [RFC6643]. A complete 272 YANG model representing similar objects as in the MIB modules could 273 be future work. 275 The predecessor of OLSRv2, OLSR [RFC3626] did not have an associated 276 MIB module. Many deployments of OLSR did not support network 277 management operations per se (i.e., configuration-on-launch was the 278 way in which routers in these deployments were managed). Those 279 implementations and deployments of OLSR that did support network 280 management operations used a similar architecture to the one 281 described in this document, but with "proprietary" protocols and APIs 282 for parameters and router states, "proprietary" data-models, etc. It 283 can be speculated that the "proprietary" protocols used for 284 communication between the NMS and the MIB modules on each router also 285 for OLSRv2, in part, exist as inherited from the protocols used for 286 OLSR. Aligned with the recommendations from [RFC5706], management of 287 OLSRv2 (in the form of the MIB modules for OLSRv2 and NHDP) has been 288 developed alongside the standardization process of OLSRv2, rather 289 than as an afterthought. 291 Finally, it is uncommon to see an NMS permanently active in a 292 deployed OLSRv2 network; rather, on an "ad hoc" basis an NMS is 293 introduced into the network, parameters configured or state 294 interrogated, following which the NMS disappears. Part of the 295 rationale for this is that in a MANET, network connectivity from 296 every MANET router to an NMS cannot be guaranteed at all times due to 297 the dynamicity of the network topology. 299 5. What and Why do we Manage and Monitor? 301 As indicated earlier, OLSRv2 and its constituent protocol NHDP, are 302 reasonably robust with respect to parameter values: a deployment can 303 operate with different parameters used in different routers in the 304 same network. That being said, adapting these parameters according 305 to circumstances is (often) desired. For example, in a stable 306 network (such as a wired network), TC messages may be sent 307 infrequently and with long validity times, whereas in a highly 308 dynamic network (such as in a vehicular network) TC messages may need 309 to be sent more frequently and HELLO messages for discovering the 310 local topology (almost) continuously. In a similar vein, the message 311 emission intervals and the information validity times should also be 312 commensurate with the available network capacity: millisecond 313 intervals between TC messages, for example, will consume all 314 available network capacity whereas hourly intervals will be 315 inappropriate even for a static and stable, wired, network (by way of 316 simply new routers arriving in the network, which will not "learn" 317 the network topology before undue long delays). 319 This adaptation may happen autonomously by a central NMS monitoring 320 and adopting the parameters globally, autonomously by an NMS in each 321 router, monitoring its local topology (and its stability) and 322 adapting parameters locally, or by manual operator intervention. 324 Given the dynamic and evolutive topology of OLSRv2 networks, a highly 325 desirable property of an NMS is the ability to display and offer 326 visibility of the current network status - for example, to display a 327 graphical map of which routers are currently part of the network. As 328 a proactive protocol, OLSRv2 maintains, in each router, a topology 329 map including all destinations and a subset of the links present in 330 the network (particularly true in a very dense network). A typical 331 feature of an NMS is to inquire as to the topology map of a single 332 router. A slightly less typical feature is to inquire all (or, at 333 least, many) routers in a network, with the purpose of presenting a 334 complete topology map. 336 In addition to actively monitoring an OLSRv2 network, erroneous or 337 unusual conditions on a router can be flagged to management, e.g., 338 detection of an unusually high number of 1-hop or 2-hop neighborhood 339 changes in a short amount of time, indicating potential problems in 340 that area of the network. [RFC6779] and [RFC7184] facilitate 341 proactively sending "notifications" (also known as traps) from the 342 router towards an NMS. The MIB modules defined in [RFC6779] and 343 [RFC7184] allow for defining both the threshold and the time window 344 of how many times this erroneous condition may occur in the time 345 window before the notification is sent to the NMS. Once the NMS 346 receives a notification, a network operator may investigate if there 347 is a problem that needs to be resolved, e.g., by changing parameters 348 via the above-described external management. 350 6. Typical Communication Patterns 352 This section describes typical (management) communications patterns 353 in an operating (post-startup) network. One of the key 354 characteristics of OLSRv2 is that is enables an efficient flooding 355 mechanism (denoted "MPR Flooding"). For some management scenarios, 356 this facilitates better performance by (scope-limited) flooding 357 management requests to MANET routers, rather than sending multiple 358 consecutive unicast messages. While the MIB modules developed for 359 OLSRv2 and NHDP do not support such broadcast operation (due to the 360 nature of SNMP), some of the proprietary management tools mentioned 361 in Section 4 take advantage of this for increased performance. 363 The below list of such communication patterns is not claimed to be 364 exhaustive, and depending on the deployment, different patterns may 365 be used. However, these patterns have been observed in many 366 deployments of OLSRv2 and its constituent parts, as well as of its 367 predecessor OLSR. 369 a) Inquire the state (complete topology graph, link states, and local 370 links - even those not part of topology graph) of a router. An 371 NMS would typically initiate that request. OLSRv2 contains a 372 number of "Information Bases"; basically, tables with rows 373 representing information about local interfaces, other routers in 374 the MANET or the topology of the MANET as perceived by the MANET 375 router. These tables are also reflected as objects in the MIB 376 modules and can be inquired via, e.g., GETBULK for getting 377 multiple rows in a single request. Depending on the number of 378 MANET routers in the network as well as the density of the MANET, 379 tables for one-hop and two-hop routers, as well as routers in 380 further distance, these tables can contain a substantial amount of 381 information, and so inquiring them will return multiple KB or more 382 of data back to the NMS. Given the dynamic topology and often 383 bandwidth-constrained wireless links between MANET routers, this 384 is not a very common operation in many deployments. Moreover, 385 this would typically only be required in debugging situations, as 386 during regular operations, OLSRv2 updates the state automatically 387 and reacts to changes (e.g., by triggering control message 388 generation). This type of operation can benefit from the 389 optimized flooding mechanism, by requesting the state from 390 multiple routers in a region of the MANET in a single request. 392 b) Inquire the history/statistics of a router. This request, 393 initiated by an NMS, is typically a small inquiry, such as "how 394 many local link changes have you seen within the past n minutes/ 395 seconds/hours". This may be very rare, or it may be several times 396 per minute per router for a while: if the NMS is trying to, e.g., 397 "tune" message intervals and timers, by sending this request to a 398 group of topologically close routers - until, that is, the NMS 399 decides that the topology has stabilized and will ease up. Again, 400 this feature of requesting performance related information is 401 supported by the MIB modules for OLSRv2 and NHDP. While SNMP does 402 not support sending the inquiry via optimized flooding, 403 proprietary protocols take advantage of the optimized flooding 404 mechanism, to reduce the number of unicast requests. 406 c) Change the configuration of a router. Other than in the above 407 case in b) (tuning), this really happens only when somehow a 408 router gets a new uplink to an external network, and either a new 409 gateway is added into the network, and/or a new prefix needs to be 410 distributed to the routers. The MIB modules for OLSRv2 and NHDP 411 allow to set all configuration parameters of each router. 412 Optimized flooding may significantly reduce the amount of unicast 413 requests, but are not supported by SNMP. 415 d) Visualizing the network as a router sees it. As in a MANET, 416 routers may move and link quality may vary due to link layer 417 characteristics, the network topology may change frequently. In a 418 naive way, this would essentially be the NMS setting up a 419 connection to the router in question, and getting a copy of all 420 routing protocol control messages to construct its own topology 421 graph as would have done that router. Typically, it consists of 422 the router sending a notification to the NMS when a topological 423 change happens, i.e., when either of its information bases change. 424 Even better, it consists of these notifications being "filtered" 425 to only send for those changes that actually impact the usable 426 topology. The latter case is supported by the MIB modules for 427 OLSRv2 and NHDP in the form of notifications (also called "traps") 428 that are send from the MANET router to the NMS. While these 429 notifications alone do not allow the NMS to visualize the 430 topology, they may suffice to inform the NMS of an unusual change 431 of the topology, and the NMS may inquire the current topology via 432 the process described in a). 434 e) Rekeying There is currently no (standard) mechanism for automated 435 key management. One of the reasons for this may be that it is 436 difficult to come up with a single such that will satisfy the 437 requirements for all the different deployments. However, in MANET 438 deployments rekeying is something that can be observed, e.g., as 439 part of the parameter configuration. The particularity of this 440 is, that it often is a "broadcast configuration operation" where 441 new key material is supposed to be sent to everybody, and not just 442 a single router, e.g., leveraging the optimized flooding mechanism 443 of OLSRv2. 445 7. This Document does not Constrain how to Manage and Monitor MANETs 447 As explained in Section 1, this document describes how, what and why 448 some (typical) OLSRv2 networks are managed and monitored as of 2014. 449 As such, the document is reflexive, not prescriptive: it does not 450 stipulate requirements for how to manage OLSRv2 networks, nor does it 451 claim to be a complete list of all management patterns or protocols. 452 Other ways of managing an OLSRv2 network are very well imaginable - 453 now, or in future deployments of OLSRv2. 455 As an example of such a "future management scenario", rather than 456 managing and monitoring routers from a central NMS, a distributed, 457 autonomous management system between multiple routers can be 458 envisioned. In particular, monitoring data that is used to debug 459 network problems and to tweak inefficiencies could be distributed 460 amongst a group of routers in the same network. This would both 461 address problems of single point of failure when using only a single 462 NMS, as well provide additional information about groups of multiple 463 routers, rather than a single router. An example use for such a 464 distributed information flow would be to identify areas of a network 465 wherein, e.g., due to different router densities, message sending 466 interval parameters could be exchanged and optimal values negotiated 467 between routers, so as to obtain locally optimized performance. 469 While such a management model is highly interesting, it is also at 470 present entirely fictional - at least outside the realm of research. 471 It is included to, both, indicate directions being explored (but not 472 exploited), and to insist that the intent of this document is not to 473 prescribe how MANETs are to be managed, in the presence or in the 474 future, but to describe the (known) state of how MANETs are managed, 475 presently. 477 8. Acknowledgments 479 The authors would like to gratefully acknowledge the following people 480 for intense technical discussions, early reviews, and comments on the 481 documents: Alan Cullen (BAE Systems), Christopher Dearlove (BAE 482 Systems), Adrian Farrel (Juniper), David Harrington (Comcast), and 483 Jurgen Schoenwalder (Jacobs University). 485 9. Informative References 487 [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State 488 Routing Protocol", RFC 3626, October 2003. 490 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 491 Considerations in Mobile Ad Hoc Networks (MANETs)", 492 RFC 5148, February 2008. 494 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 495 "Generalized MANET Packet/Message Format", RFC 5444, 496 February 2009. 498 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 499 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 500 March 2009. 502 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 503 Management of New Protocols and Protocol Extensions", 504 RFC 5706, November 2009. 506 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 507 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 508 RFC 6130, April 2011. 510 [RFC6643] Schoenwaelder, J., "Translation of Structure of Management 511 Information Version 2 (SMIv2) MIB Modules to YANG 512 Modules", RFC 6643, July 2012. 514 [RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of 515 Managed Objects for the Neighborhood Discovery Protocol", 516 RFC 6779, May 2012. 518 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 519 "The Optimized Link State Routing Protocol Version 2", 520 RFC 7181, April 2014. 522 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 523 Check Value and Timestamp TLV Definitions for Mobile Ad 524 Hoc Networks (MANETs)", RFC 7182, April 2014. 526 [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity 527 Protection for the Neighborhood Discovery Protocol (NHDP) 528 and Optimized Link State Routing Protocol Version 2 529 (OLSRv2)", RFC 7183, April 2014. 531 [RFC7184] Herberg, U., Cole, R., and T. Clausen, "Definition of 532 Managed Objects for the Optimized Link State Routing 533 Protocol Version 2", RFC 7184, April 2014. 535 Authors' Addresses 537 Thomas Clausen 538 LIX, Ecole Polytechnique 539 91128 Palaiseau Cedex, 540 France 542 Phone: +33-6-6058-9349 543 Email: T.Clausen@computer.org 544 URI: http://www.thomasclausen.org 545 Ulrich Herberg 546 Fujitsu Laboratories of America 547 1240 E Arques Ave 548 Sunnyvale CA 94086, 549 US 551 Phone: 552 Email: ulrich@herberg.name 553 URI: http://www.herberg.name