idnits 2.17.1 draft-nguyen-manet-management-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 : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 18, 2013) is 4083 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ARC1' is mentioned on line 633, but not defined == Missing Reference: 'ARC3' is mentioned on line 567, but not defined == Missing Reference: 'ARC5' is mentioned on line 633, but not defined == Missing Reference: 'CLG1' is mentioned on line 225, but not defined == Missing Reference: 'CLG2' is mentioned on line 627, but not defined == Missing Reference: 'CLG3' is mentioned on line 627, but not defined == Missing Reference: 'CLG4' is mentioned on line 264, but not defined == Missing Reference: 'CLG5' is mentioned on line 627, but not defined == Missing Reference: 'ACT1' is mentioned on line 629, but not defined == Missing Reference: 'ACT2' is mentioned on line 629, but not defined == Missing Reference: 'ACT3' is mentioned on line 629, but not defined == Missing Reference: 'ACT4' is mentioned on line 629, but not defined == Missing Reference: 'ACT5' is mentioned on line 629, but not defined == Missing Reference: 'ACT6' is mentioned on line 359, but not defined == Missing Reference: 'SCE1' is mentioned on line 631, but not defined == Missing Reference: 'SCE2' is mentioned on line 414, but not defined == Missing Reference: 'SCE3' is mentioned on line 465, but not defined == Missing Reference: 'SCE4' is mentioned on line 521, but not defined == Missing Reference: 'ARC2' is mentioned on line 633, but not defined == Missing Reference: 'ARC4' is mentioned on line 633, but not defined == Missing Reference: 'ARC6' is mentioned on line 569, but not defined -- Unexpected draft version: The latest known version of draft-ietf-manet-olsr is -11, but you're referring to -17. == Outdated reference: A later version (-03) exists of draft-ersue-constrained-mgmt-02 ** Obsolete normative reference: RFC 6779 (Obsoleted by RFC 7939) Summary: 4 errors (**), 0 flaws (~~), 24 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Nguyen 3 Internet-Draft R. Cole 4 Intended status: Informational U.S. Army CERDEC 5 Expires: August 22, 2013 U. Herberg 6 Fujitsu Laboratories of America 7 J. Yi 8 LIX, Ecole Polytechnique 9 J. Dean 10 Naval Research Laboratory 11 February 18, 2013 13 Network Management of Mobile Ad hoc Networks (MANET): Architecture, Use 14 Cases, and Applicability 15 draft-nguyen-manet-management-00 17 Abstract 19 This document aims at providing an extended architecture, use case 20 and applicability statement for management of MANETs, as a guideline 21 for how to manage MANETs. This document describes different 22 management activities, such as network configuration, monitoring of 23 state, monitoring of performance, fault management, and software 24 upgrades. Different aspects of a MANET management architecture are 25 illustrated (e.g., distributed vs. centralized management, flat vs. 26 hierarchical management, management of an entire network vs. an 27 individual router, etc.) and contrasted to the NMS architecture in 28 the Internet. A desciption of typical MANET use cases relevant for 29 management is followed by an overview of current standard management 30 protocols that can be used in MANETs. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 22, 2013. 49 Copyright Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Objective of this Document . . . . . . . . . . . . . . . . 5 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Challenges and Problem Statement . . . . . . . . . . . . . . . 5 70 3.1. [CLG1] Distributed Ownership . . . . . . . . . . . . . . . 6 71 3.2. [CLG2] Ad Hoc Topology . . . . . . . . . . . . . . . . . . 6 72 3.3. [CLG3] Infrastructureless . . . . . . . . . . . . . . . . 6 73 3.4. [CLG4] Network Performance . . . . . . . . . . . . . . . . 6 74 3.5. [CLG5] Low Bandwidth / Lossy Channel . . . . . . . . . . . 7 75 4. Management Functions . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. [ACT1] Network Configuration . . . . . . . . . . . . . . . 7 77 4.2. [ACT2] Monitoring of State . . . . . . . . . . . . . . . . 7 78 4.3. [ACT3] Monitoring of Performance . . . . . . . . . . . . . 8 79 4.4. [ACT4] Notifications and Fault Management . . . . . . . . 8 80 4.5. [ACT5] Software Upgrades (Out of Scope) . . . . . . . . . 8 81 4.6. [ACT6] Security Configuration (Out of Scope) . . . . . . . 8 82 5. MANET Management Scenarios . . . . . . . . . . . . . . . . . . 9 83 5.1. [SCE1] Pre-Deployment Configuration . . . . . . . . . . . 9 84 5.2. [SCE2] Out-of-Band Management . . . . . . . . . . . . . . 10 85 5.3. [SCE3] Management of Mobile Nodes of Networks . . . . . . 11 86 5.4. [SCE4] In-Band Network Management . . . . . . . . . . . . 12 87 6. Management Architecture . . . . . . . . . . . . . . . . . . . 13 88 6.1. Typical Network Management Architecture in the Internet . 13 89 6.2. Distributed Architecture [ARC1] vs Centralized 90 Architecture [ARC2] . . . . . . . . . . . . . . . . . . . 13 91 6.3. Flat Architecture [ARC3] vs Hierarchical Architecture 92 [ARC4] . . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 6.4. Entire Network Management [ARC5] vs Individual Router 94 Management [ARC6] . . . . . . . . . . . . . . . . . . . . 14 95 6.5. Connectivity Assumptions . . . . . . . . . . . . . . . . . 14 96 6.6. Notification Destination (Fault Management) . . . . . . . 14 97 7. MANET Use Cases . . . . . . . . . . . . . . . . . . . . . . . 14 98 7.1. Military Networks . . . . . . . . . . . . . . . . . . . . 14 99 7.2. Emmergency or Disaster Situations . . . . . . . . . . . . 15 100 7.3. Community Networks . . . . . . . . . . . . . . . . . . . . 16 101 7.3.1. Public Interent access . . . . . . . . . . . . . . . . 17 102 7.3.2. Public Safety . . . . . . . . . . . . . . . . . . . . 17 103 7.3.3. Opportunistic networks for developing areas . . . . . 17 104 7.4. Wireless Sensor Networks . . . . . . . . . . . . . . . . . 18 105 7.4.1. Habitat and Environmental Monitoring . . . . . . . . . 18 106 7.4.2. Health monitoring . . . . . . . . . . . . . . . . . . 18 107 7.4.3. Tracking applications . . . . . . . . . . . . . . . . 18 108 7.4.4. Wildlife monitoring . . . . . . . . . . . . . . . . . 18 109 7.5. Vehicular Networks . . . . . . . . . . . . . . . . . . . . 18 110 7.5.1. Intelligent Transportation Systems . . . . . . . . . . 18 111 7.5.2. Vehicular to vehicular networks . . . . . . . . . . . 19 112 8. Standard Management Protocols Currently Used in MANETs . . . . 19 113 8.1. Managing with Simple Network Management Protocol (SNMP) . 19 114 8.1.1. Overview of the Protocol . . . . . . . . . . . . . . . 19 115 8.1.2. Applicability for MANETs . . . . . . . . . . . . . . . 19 116 8.2. Managing MANET with NETwork CONFiguration Protocol 117 (NETCONF) . . . . . . . . . . . . . . . . . . . . . . . . 20 118 8.2.1. Overview of the Protocol . . . . . . . . . . . . . . . 20 119 8.2.2. Applicability for MANETs . . . . . . . . . . . . . . . 21 120 8.3. Managing MANET with DISMAN . . . . . . . . . . . . . . . . 21 121 8.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 21 122 8.3.2. Applicability for MANETs . . . . . . . . . . . . . . . 21 123 8.4. Managing MANET with CoAP . . . . . . . . . . . . . . . . . 21 124 8.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22 125 8.4.2. Applicability for MANETs . . . . . . . . . . . . . . . 22 126 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 129 1. Introduction 131 MANET routing protocols are commonly assumed to be entirely self- 132 managing: routers, running such a protocol, perceive the topology of 133 the MANET by means of control message exchange. Any change to the 134 topology is reflected in the local routing tables of each router 135 after a bounded convergence time, which allows forwarding of data 136 traffic towards its intended destination. Usually, no human 137 interaction is required, as all variable parameters required by the 138 routing protocol are either negotiated in the control traffic 139 exchange, or are only of local importance to each router (i.e. do not 140 influence interoperability). 142 However, external management and monitoring of a MANET routing 143 protocol may be desirable to optimize parameters of the routing 144 protocol. Such an optimization may lead to a more stable perceived 145 topology and to a lower control traffic overhead, and therefore to a 146 higher delivery success ratio of data packets, a lower end-to-end 147 delay, and less unnecessary bandwidth and energy usage. Such 148 optimizations facilitate to scale the network to a large number of 149 routers. 151 In the following, requirements for MANET management are illustrated 152 using an example, the Optimized Link State Routing Protocol version 2 153 [I-D.OLSRv2]: Fundamentally, the only parameter upon which agreement 154 is required between OLSRv2 routers is C - a constant, used to fix the 155 scale and granularity of validity and interval time values, as 156 included in protocol control messages. [RFC5497] proposes a value 157 for this constant; the symbol C is chosen to indicate it to be a 158 "constant of nature" inside an OLSRv2 network, to which all routers 159 must adhere. As control messages carry validity time and interval 160 time values, a recipient OLSRv2 router can behave appropriately, even 161 if it uses vastly different values itself, as long as the recipient 162 and sender use the same value for C. 164 Link admittance, by way of the hysteresis values and link quality 165 estimation, requires no agreement; these are used for an individual 166 router to determine a suitable threshold for "considering that a link 167 could be a candidate for being advertised as usable". Still, 168 external monitoring and management may be desirable in an OLSRv2 169 network. A network may benefit from having its control message 170 emission tuned according to the network dynamics: in a mostly static 171 network, i.e. a network in which the topology remains stable over 172 long durations, the control message emission frequency could be 173 decreased in order to consume less bandwidth or less energy. 174 Conversely, of course, in a highly dynamic network, the emission 175 frequency could be increased from improved responsiveness. 176 Concerning the hysteresis and link quality estimation, a management 177 application might detect a region of an OLSRv2 network with a high 178 link density - but also a high degree of "flapping": links coming 179 "up" (SYM) only to disappear as LOST shortly thereafter. Detecting 180 such behavior, on a global level and for multiple routers in the same 181 region, could enable appropriately "tuning" the thresholds towards 182 more stable links and, thus, a more stable routing structure in the 183 network. 185 These are but two examples, and have as common that a more "global 186 view" of the network, than that of a single OLSRv2 router, is 187 required - i.e. entail that a Network Management System is able to 188 inquire as to various performance values of the network, and to set 189 various router parameters. 191 1.1. Objective of this Document 193 As MANETs are a relatively new kind of network, experience with 194 large-scale deployments, and in particular management of such 195 deployments, is limited. This document aims at providing an extended 196 architecture, use case and applicability statement for management of 197 MANETs, as a guideline for how to manage MANETs. This document 198 describes different management activities, such as network 199 configuration, monitoring of state, monitoring of performance, fault 200 management, and software upgrades. Different aspects of a MANET 201 management architecture are illustrated (e.g., distributed vs. 202 centralized management, flat vs. hierarchical management, management 203 of an entire network vs. an individual router, etc.) and contrasted 204 to the NMS architecture in the Internet. A desciption of typical 205 MANET use cases relevant for management is followed by an overview of 206 current standard management protocols that can be used in MANETs. 208 A related document that discusses other use cases and requirements of 209 constrained networks and constrained devices (not focused on MANETs) 210 is currently being developed in [I-D.ersue-constrained-mgmt]. 212 2. Terminology 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 216 "OPTIONAL" in this document are to be interpreted as described in 217 [RFC2119]. 219 3. Challenges and Problem Statement 221 Management of MANETs is more difficult than in the Internet, for 222 multiple reasons. This section outlines these challenges for 223 management of MANETs. 225 3.1. [CLG1] Distributed Ownership 227 Depending on the user case, there may not be a network administrator 228 of the MANET, e.g., in the use case of Section 7.3, where each 229 inhabitant owns its own router. This means that the router may be 230 completely protected against external access, or at least only allows 231 limited access to it. Moreover, there may be issues of privacy, but 232 these are out of scope of this document. 234 3.2. [CLG2] Ad Hoc Topology 236 As the topology of a MANET may frequently change over time, no a 237 priori topology planning is possible for the network administrator. 238 Therefore, new routers may join at any time, and other may leave. 239 This leads to a change of topology as well as IP addresses, depending 240 on the IP address allocation policy or mechanism. 242 Depending on the routing protocol used in the MANET, it may not be 243 known to a network management station which IP addresses are 244 available in the network, e.g., when using a reactive protocol, which 245 only discovers routes on demand. Moreover, because of changes of the 246 topology, it is possible that there is no route between two MANET 247 routers because they are in different connected components of the 248 network graph representing the network topology. 250 3.3. [CLG3] Infrastructureless 252 In some use cases of MANETs, such as descibed in Section 7.3, there 253 may not be a "controller" or "server". Even if there is, 254 connectivity may be interrupted because of the ad hoc topology, 255 described above. This entails that a distributed management may be 256 desired instead of a centralized one. Routers could, e.g., monitor 257 their neighbors and report failures on behalf of them once they have 258 connectivity to a logging station; or they keep that information 259 locally until requested by a user remotely. A decentralized 260 management may lead to an increased coordination complexity. For 261 example, it needs to be defined to which NMS notifications are sent 262 from routers. 264 3.4. [CLG4] Network Performance 266 Whereas in classical network management of the Internet, 267 administrators typically connect to a single router in order to 268 configure parameters or to monitor its performance, MANETs may have 269 performance problems because of a whole group of malconfigured 270 routers. Also, the performance measures of a larger number of 271 routers may be more relevant than that of a single router. In order 272 to do that, different protocols would need to be used to manage a 273 region of a network (e.g., using multicast connections, collection 274 trees etc.) 276 Typically in wired networks, performance monitoring is accomplished 277 through periodic polling for state and counter data, from which 278 performance reports are generated. In MANETs, due to dynamics, 279 individual routers may be disconnected from a management station 280 handling the periodic polling for performance data. Hence, 281 architectures need to be developed which allow for remote control of 282 reporting functions, but local generation of performance reports to 283 allow for continuous collection during periods of disconnection. 285 3.5. [CLG5] Low Bandwidth / Lossy Channel 287 Due to the nature of wireless channels, bandwidths may be far lower 288 than in the Internet, and packet loss rates orders of magnitude 289 higher. In terms of management applications requiring delivery of 290 large volumes of data, e.g., new configuration files or software 291 upgrades, may not be viable if running over reliable transport 292 protocols. Standard TCP implementations are known to have poor 293 performance characteristics in lossy MANETs. 295 4. Management Functions 297 This section describes several management activities that are 298 relevant for management of networks in general (not only MANETs). 300 4.1. [ACT1] Network Configuration 302 Section 1 gives an example for network configuration for OLSRv2. 303 Most network protocols allow for setting parameters, e.g., message 304 intervals, timeouts, metric types, security parameters etc. These 305 parameters can affect interoperability of the protocols, as well as 306 protocol performance and efficiency. Managing such parameters 307 remotely allows quick updates of parameters remotely, e.g., as a 308 reaction to a change in topology by changing message intervals as 309 described in the example in Section 1. 311 4.2. [ACT2] Monitoring of State 313 Many network protocols maintain state during operation. For example 314 for routing protocols, the state consists of information about 315 destinations in the network, neighbors of a router, local interfaces 316 etc. Monitoring such information remotely by means of a management 317 protocol can provide insight into the current operation of the 318 protocol (e.g., the network topology), help to discover problems, 319 calculate statistics, etc. Monitoring may require continous feedback 320 of the current state for analyzing long-term behavior of the 321 protocol, as well as to observe frequencies of changes of the state. 323 4.3. [ACT3] Monitoring of Performance 325 Monitoring of performance is related to Section 4.2. Network 326 operators may not only be interest in changing coonfiguration of a 327 protocol or observer the state, but investigate performance issues, 328 such as slow convergence of a protocol or (unncesseary) large network 329 bandwidth consumption. While this information may be directly 330 accessible by observing the state of the router, management protocols 331 may help to provide complete reports, statistics, counters etc. to 332 the network operator. For example, RMON [RFC4502] allows for 333 gathering statistics based on counters and generating reports that 334 are sent back to the network operator. 336 4.4. [ACT4] Notifications and Fault Management 338 In case of criticial malfunctions or warnings, notifications may be 339 actively sent to a network operator (e.g., via email or using a 340 network management protocol). The notification will typically 341 include the reason for the notification, the source address, related 342 information, the time of the incident etc., and is sent to a 343 preconfigured server (e.g., a network management station). 345 4.5. [ACT5] Software Upgrades (Out of Scope) 347 During deployment of a device, it may be necessary to upgrade the 348 firmware of the device, e.g., in order to fix security holes. 349 Management protocols may allow a remote upgrade of the software by 350 monitoring new versions of the firmware, downloading the upgrade in 351 case there is a new version and verifying integrity of the downlaoded 352 file, backing up the existing firmware, installing the firmware, 353 verifying correct installation and providing feedback about the 354 successful installation. 356 As firmware upgrades are very different in terms of requirements, use 357 cases, and protocols, they are out of scope for this document. 359 4.6. [ACT6] Security Configuration (Out of Scope) 361 IETF protocols are required to provide sufficient security protection 362 against malicious attacks. Before secure communication between 363 devices over an unsecured network is possible, parameters such as 364 cryptographic keys, cipher algorithms, trusted authorities, revoked 365 keys etc. must be exchanged betwen devices. 367 As security configuration is very different in terms of requirements, 368 use cases, and protocols, it is out of scope for this document. 370 5. MANET Management Scenarios 372 This section discusses several management scenarios for the various 373 types of MANETs identified previously. Management Scenarios 374 represent applications of the Management Activities to abstracted 375 MANET Use Cases, which combined identify a set of current and desired 376 management capabilities. The list is non-exhaustive. 378 In the following, the term "node" is used for either a host or 379 router. The term "unit" or "mobile unit" is a unit that may contain 380 multiple routers, hosts, and/or other IP-based communication devices. 382 5.1. [SCE1] Pre-Deployment Configuration 384 Configuration of MANET devices once they have been deployed can be a 385 very tricky endeavor. Hence, one common approach is the pre- 386 configuration the MANET nodes prior to their deployment, followed by 387 monitoring of their state and performance once they are deployed. 388 This is often performed in the 'Parking Lot Staging Area'. MANET 389 nodes are shipped to a remote location, along with a fixed Network 390 Operations Center (NOC), where they are all connected over 391 traditional wired or wireless networks. The Fixed NOC then performs 392 mass-configuration and evaluation of configuration processes similar 393 to configuration of networked devices in Enterprise Networks. Once 394 all units are successfully configured, they are ready to be deployed. 395 Once deployed, monitoring of the state and performance of the nodes 396 is attempted at the fixed NOC. 398 +---------+ +--------+ 399 | Fixed |<---+------->| unit_1 | 400 | NOC | | +--------+ 401 +---------+ | 402 | +--------+ 403 +------->| unit_2 | 404 | +--------+ 405 | . 406 | . 407 | . 408 | +--------+ 409 +------->| unit_N | 410 +--------+ 412 Figure 1: Parking Lot Staging Area 414 5.2. [SCE2] Out-of-Band Management 416 Configuration management is relatively straightforward in Enterprise 417 Networks due to the possibility of Out-of-Band Management. Here, in 418 the event of mis-configuration, the manager can access the mis- 419 configured device(s) out-of-band and correct, or back out of, the 420 incorrect configuration(s). In MANETs, the equivalent capability can 421 be achieved, to a certain extent, when multiple radio, satellite, or 422 other interfaces exist on the MANET devices. An example of this 423 scenario is management with satellite reach-back. Here, a fixed NOC 424 and the MANET are connected through an On-The-Move (OTM) satellite 425 communications capability. Vehicles carrying MANET routers can 426 support multiple types of wireless interfaces, including high 427 capacity short range radio interfaces as well as low capacity OTM 428 satellite interfaces. The radio interfaces are the preferred 429 interfaces for carrying data traffic due to their relatively high 430 capacity, but the range is limiting with respect to connectivity to a 431 Fixed NOC. Hence, OTM satellite interfaces offer a more persistent 432 but lower capacity reach-back capability. The existence of a more 433 persistent satellite reach-back capability offers the NOC the ability 434 to monitor and manage the MANET routers over the air. This affords 435 the NOC the ability to perform state and performance monitoring and 436 receive notifications, but also allows the NOC to perform some amount 437 of configuration management safely while the MANET nodes are on the 438 move. 440 --- +--+ --- 441 / /---|SC|---/ / 442 --- +--+ --- 443 +---------+ | 444 | Fixed |<--------------------------+ 445 | NOC | +--------------| 446 +---------+ | +-------------------+ 447 | | | 448 +--------+ | +--------+ 449 | unit_1 | +---------+ | unit_N | 450 +--------+ | | +--------+ 451 * | | * * 452 * +--------+ | * * 453 *********| unit_2 |******|******* * 454 +--------+ | * 455 * | * 456 * +--------+ * 457 ********| unit_3 |***** 458 +--------+ 460 --- show SatCom links 461 *** show Radio links 463 Figure 2: Monitoring with one-hop SatCom Reachback network 465 5.3. [SCE3] Management of Mobile Nodes of Networks 467 It is common to find mobile vehicles carrying a rather complex set of 468 networking devices, including routers running MANET control 469 protocols. In this scenario, the MANET mobile unit has a rather 470 complex internal architecture where a local manager within the unit 471 is responsible for local management. The local management includes 472 management of the MANET router and control protocols, the firewall, 473 servers, proxies, hosts and applications. Here, a standard 474 Enterprise Management interface is applicable in this scenario. 475 Moreover, in addition to being able to utilize a standard management 476 interface into the components comprising the MANET nodal network, the 477 local manager can be responsible for local monitoring and the 478 generation of periodic reports back to the Fixed NOC. 480 Interface 481 | 482 V 483 +---------+ +-------------------------+ 484 | Fixed | Interface | +---+ +---+ | 485 | NOC |<---+------->| | R |--+--| F | | 486 +---------+ | | +---+ | +---+ | 487 | | | | +---+ | 488 | | +---+ | +--| P | | 489 | | | M |--+ | +---+ | 490 | | +---+ | | 491 | | | +---+ | 492 | | +--| D | | 493 | | | +---+ | 494 | | | | 495 | | | +---+ | 496 | | +--| H | | 497 | | +---+ | 498 | | unit_1 | 499 | +-------------------------+ 500 | 501 | 502 | +--------+ 503 +------->| unit_2 | 504 | +--------+ 505 | . 506 | . 507 | . 508 | +--------+ 509 +------->| unit_N | 510 +--------+ 512 Key: R-Router 513 F-Firewall 514 P-PEP (Performance Enhancing Proxy) 515 D-Servers, e.g., DNS 516 H-hosts 517 M-Local Manager 519 Figure 3: Hierarchical Management Nodes 521 5.4. [SCE4] In-Band Network Management 523 In future MANET operations, it would be useful to achieve full 524 management of the MANET over In-Band access over potentially lossy, 525 intermittent and large delay links. In this case, there are a number 526 of issues that would arise and need to be addressed, including: 528 1. Validating the network configuration (and local configuration) 529 becomes a complex task, e.g., when to cut-over the network to the 530 new configuration becomes an interesting question. 532 2. Bandwidth considerations may become important when attempting to 533 push large configuration changes to a large number of MANET nodes 534 over the wireless infrastructure. 536 3. Typically the state of the devices comprising the MANET would be 537 in various states of operations, e.g., ON/OFF, etc., and 538 synchronizing these nodes to the new network configuration would 539 be problematic. 541 4. Pushing large data files, e.g., software upgrades, over a lossy 542 network, would be problematic,e.g., the TCP over lossy links 543 issue previously discussed. 545 +---------+ +--------+ 546 | Mobile |<----------->| unit_1 | 547 | NOC |?--+ +--------+ 548 +---------+ | 549 ^ | +--------+ 550 | +------->| unit_2 | 551 | +--------+ 552 | . 553 | . 554 | . 555 | +--------+ 556 +---------------->| unit_N | 557 +--------+ 559 In-Band Management over Lossy/intermittent Links 561 6. Management Architecture 563 6.1. Typical Network Management Architecture in the Internet 565 6.2. Distributed Architecture [ARC1] vs Centralized Architecture [ARC2] 567 6.3. Flat Architecture [ARC3] vs Hierarchical Architecture [ARC4] 568 6.4. Entire Network Management [ARC5] vs Individual Router Management 569 [ARC6] 571 6.5. Connectivity Assumptions 573 6.6. Notification Destination (Fault Management) 575 7. MANET Use Cases 577 This section lists several use cases of MANETs. Each case is 578 introduced with a brief description of the application, role of MANET 579 in such application, and maybe some example deployments in the real 580 world. Required management activities, related challenges and 581 management scenarios are illustrated with a reference to previous 582 section. For example, [ACT3] stands for section 4.3 Monitoring of 583 Performance. 585 This list is non-exhaustive. 587 7.1. Military Networks 589 Military tactical networks are characterized by their domain of 590 operations. Networks are required to support a broad range of 591 mobilities (e.g., ground, air and space vehicles), are required to 592 support a broad range of sizes (e.g., from small squad level networks 593 to divisional level deployments of tens of thousands of nodes), are 594 required to operate in very hostile environments (e.g., all 595 climates), in very critical situations (e.g., warfare), and do so 596 under explicit attacks (e.g., kinetic and non-kinetic) by hostiles. 597 Military tactical networks are primarily wireless and hence must 598 operate with intermittent and lossy connectivity with little or no 599 infrastructure. These networks are required to provide highly 600 reliable and robust communications; it is not possible to simply 601 provide monetary rebates to customers in the event of a failure-to- 602 operate. 604 Military networks must provide a robust Quality-of-Service in order 605 to both support the presentation of a broad range of realtime and 606 non-realtime applications and to support the triage of information in 607 situations of network congestion. 609 Current military MANETs range from upper echelon deployments such as 610 the Warfighter Information Network-Tactical (WIN-T) [WIN-T]. WIN-T 611 is a vehicular-based MANET, where vehicles of various sizes are 612 supported depending upon the echelon level, e.g., high capacity 613 trucks carrying multiple computers, routers, radio and satellite 614 systems, high power generation systems, etc., versus small capacity 615 car-sized or unmanned ground and air vehicles with one or two 616 computers and a single radio system with minimal power storage 617 capabilities. Other military MANETs are comprised of networks of 618 single radio systems such as the Joint Tactical Radio System (JTRS) 619 [JTRS]. JTRS systems are typically carried as individual mobile 620 radio nodes of various sizes and platforms. The JTRS Ground Mobile 621 Radio (GMR) is a larger high power high bandwidth radio carried on 622 vehicular systems. While the JTRS Handheld, Manpack and Small Form 623 Fit (HMS) radio is a small hand held system. 625 NOTE: the following is just an example to illustrate the refs! 627 Derived challenges: [CLG2][CLG3][CLG5] 629 Derived management activities: [ACT1][ACT2][ACT3][ACT4][ACT5] 631 Derived management scenarios: [SCE1] 633 Derived management architecture: [ARC1][ARC2][ARC4][ARC5] 635 7.2. Emmergency or Disaster Situations 637 Establishing basic communication after an emergency such as a flood, 638 earthquake or nuclear accident, is difficult when the communication 639 infrastructure is damaged. Mobile phones require nearby 640 infrastructure that provide connectivity, which may not work any 641 more. Even if the infrastructure is still available, the increased 642 use of mobile phones after an emergency can saturate the network. 643 The cable telephone network may be malfunctioning when cables are 644 broken, satellite phones are rarely available and expensive. In 645 addition to voice communication, data collection on the emergency 646 site is desirable. Information, such as temperature, humidity or 647 radioactivity of the disaster area, can help understanding the degree 648 of the disaster, and to coordinate help accordingly. One such 649 deployment that establishes communication in emergency situations is 650 the SKYMESH project of Niigata University [SKYMESH], which is aimed 651 at establishing communication between several unmanned balloons in 652 order to rapidly create communication networks for rescuers. A small 653 computer, together with a GPS device and a camera, is attached to the 654 balloon, which floats in a height of 50 to 100m over ground, allowing 655 remote wide area monitoring of the disaster area, as well as 656 establishing communication (voice or data) using the ad hoc network. 657 Another deployment in emergency situations is to drop large numbers 658 of sensors from an airplane. The sensors can then establish an ad 659 hoc network, once they are on the ground, without the necessity for 660 humans to enter the disaster site and to deploy the sensors manually. 662 7.3. Community Networks 664 Community networks are comprised of constrained routers in a multi- 665 hop mesh topology, communicating over a lossy, and often wireless 666 channel. While the routers are mostly non-mobile, the topology may 667 be very dynamic because of fluctuations in link quality of the 668 (wireless) channel caused by, e.g., obstacles, or other nearby radio 669 transmissions. Depending on the routers that are used in the 670 community network, the resources of the routers (memory, CPU) may be 671 more or less constrained - available resources may range from only a 672 few kilobytes of RAM to several megabytes or more, and CPUs may be 673 small and embedded, or more powerful general-purpose processors. 674 Examples of such community networks are the FunkFeuer network 675 (Vienna, Austria), FreiFunk (Berlin, Germany), Seattle Wireless 676 (Seattle, USA), and AWMN (Athens, Greece). These community networks 677 are public and non-regulated, allowing their users to connect to each 678 other and - through an uplink to an ISP - to the Internet. No fee, 679 other than the initial purchase of a wireless router, is charged for 680 these services. Applications of these community networks can be 681 diverse, e.g., location based services, free Internet access, file 682 sharing between users, distributed chat services, social networking 683 etc, video sharing etc. 685 As an example of a community network, the FunkFeuer network comprises 686 several hundred routers, many of which have several radio interfaces 687 (with omnidirectional and some directed antennas). The routers of 688 the network are small-sized wireless routers, such as the Linksys 689 WRT54GL, available in 2011 for less than 50 Euros. These routers, 690 with 16 MB of RAM and 264 MHz of CPU power, are mounted on the 691 rooftops of the users. When new users want to connect to the 692 network, they acquire a wireless router, install the appropriate 693 firmware and routing protocol, and mount the router on the rooftop. 694 IP addresses for the router are assigned manually from a list of 695 addresses (because of the lack of autoconfiguration standards for 696 mesh networks in the IETF). 698 While the routers are non-mobile, fluctuations in link quality 699 require an ad hoc routing protocol that allows for quick convergence 700 to reflect the effective topology of the network (such as [RFC6130] 701 and [I-D.OLSRv2]). Usually, no human interaction is required for 702 these protocols, as all variable parameters required by the routing 703 protocol are either negotiated in the control traffic exchange, or 704 are only of local importance to each router (i.e. do not influence 705 interoperability). However, external management and monitoring of an 706 ad hoc routing protocol may be desirable to optimize parameters of 707 the routing protocol. Such an optimization may lead to a more stable 708 perceived topology and to a lower control traffic overhead, and 709 therefore to a higher delivery success ratio of data packets, a lower 710 end-to-end delay, and less unnecessary bandwidth and energy usage. 712 Different use cases for the management of community networks are 713 possible: 715 o One single Network Management Station (NMS), e.g. a border gateway 716 providing connectivity to the Internet, requires managing or 717 monitoring routers in the community network, in order to 718 investigate problems (monitoring) or to improve performance by 719 changing parameters (managing). As the topology of the network is 720 dynamic, constant connectivity of each router towards the 721 management station cannot be guaranteed. Current network 722 management protocols, such as SNMP and NETCONF, may be used (e.g., 723 using interfaces such as the NHDP-MIB [RFC6779]). However, when 724 routers in the community network are constrained, existing 725 protocols may require too many resources in terms of memory and 726 CPU; and more importantly, the bandwidth requirements may exceed 727 the available channel capacity in wireless mesh networks. 728 Moreover, management and monitoring may be unfeasible if the 729 connection between the NMS and the routers is frequently 730 interrupted. 732 o A distributed network monitoring, in which more than one 733 management station monitors or manages other routers. Because 734 connectivity to a server cannot be guaranteed at all times, a 735 distributed approach may provide a higher reliability, at the cost 736 of increased complexity. Within the IETF, several standard exists 737 for distributed monitoring and management, including Remote 738 Monitoring (RMON) and DIStributed MANagement (DISMAN). This will 739 be discussed in the Management Architectures section below. 741 o Monitoring and management of a whole network or a group of 742 routers. Monitoring the performance of a community network may 743 require more information than what can be acquired from a single 744 router using a network management protocol. Statistics, such as 745 topology changes over time, data throughput along certain routing 746 paths, congestion etc., are of interest for a group of routers (or 747 the routing domain) as a whole. As of 2012, no IETF standard 748 allows for monitoring or managing whole networks, instead of 749 single routers. 751 7.3.1. Public Interent access 753 7.3.2. Public Safety 755 7.3.3. Opportunistic networks for developing areas 756 7.4. Wireless Sensor Networks 758 The general context for Wireless Sensor Networks (WSNs) is small, 759 cheap devices whose primary function is data acquisition, with 760 communications capabilities enabling them to send data to a 761 controller, using a wireless multi-hop topology. As an example, a 762 WSN deployed for environmental monitoring might contain a set of 763 temperature sensors, sending "notifications" to a central controller 764 when the temperature exceeds certain thresholds. Compared to a 765 network of wired sensors, WSNs offer the advantage of enabling 766 mobility to sensors, as well as reducing cost and space requirements 767 for the installation of cables. The properties of WSNs are similar 768 to the ad hoc network presented in section 1.3.1, with the following 769 differences: (1) hardware resources (in terms of CPU and memory) of 770 sensor routers are even more constrained than ad hoc routers in the 771 FunkFeuer network, (2) unlike the routers in the FunkFeuer network, 772 sensor routers may be battery driven, and (3) sensor network 773 topologies are often optimized for particular traffic patterns. 775 As for (1), a typical sensor router may be equipped with no more than 776 50 KByte of flash, 5 KByte of RAM, and a few Megahertz of CPU speed 777 (e.g., the Scatterweb MSB430). Compared to the routers in the 778 FunkFeuer network, these sensor routers have much more constrained 779 resources, and thus require special care when designing protocols for 780 these sensor routers, minimizing required memory space and CPU power. 781 As for (2), sensor nodes are often battery-driven, constraining their 782 life-time compared to routers with a permanent energy supply. This 783 implies that protocols for such sensors should have the objective to 784 maximize resource savings (e.g. by reducing the frequency of message 785 transmissions). As for (3), a major use case for sensors is 786 measuring a set of environmental data and sending it through the 787 network to a central controller. This traffic flow assumption allows 788 to construct specific, optimized network topologies which focus on 789 connections from a sensor to the controller (versus sensor-to-sensor 790 or controller-to-sensor). 792 7.4.1. Habitat and Environmental Monitoring 794 7.4.2. Health monitoring 796 7.4.3. Tracking applications 798 7.4.4. Wildlife monitoring 800 7.5. Vehicular Networks 802 7.5.1. Intelligent Transportation Systems 803 7.5.2. Vehicular to vehicular networks 805 8. Standard Management Protocols Currently Used in MANETs 807 The IETF has already offered an array of solutions to manage IP 808 networks. These range from the Simple Network Management Protocol 809 (SNMP) [RFC1157] and related capabilities, to more recent management 810 capabilities based upon the NETwork CONFiguration Protocol (NETCONF) 811 [RFC6241] and associated capabilities and other tools, e.g., 812 Constrained Application Protocol (CoAP) or DIStributed MANagement 813 (DISMAN). 815 8.1. Managing with Simple Network Management Protocol (SNMP) 817 8.1.1. Overview of the Protocol 819 SNMP was purposely designed at the application level to manage 820 different devices built by different vendors. SNMP uses the concept 821 of a manager and agents for managing devices using the TCP/IP 822 protocol suite. It provides a set of network operations for 823 configuring, monitoring, and managing networks. In SNMP frameworks, 824 a manager station, which runs the SNMP client program, controls a set 825 of agents. An agent residing on the device runs the SNMP server 826 program. 828 The management process is achieved either through a simple session- 829 less User Datagram Protocol (UDP) or a session-oriented Transport 830 Control Protocol (TCP), communication between a manager and an agent. 831 SNMP uses two other protocols for handling management tasks: 832 Structure of Management Information (SMI) as a language to describe 833 management model and Management Information Bases (MIBs) as instances 834 of management models. SMI defines general rules for naming the 835 objects, defining object types, and showing how to encode objects and 836 values. MIB modules model a collection of named objects and their 837 relationship to each other. SNMP can provide capabilities of 838 configuring the network devices and monitoring functionality by 839 providing network states, performance data, and notifications through 840 a set of packet types (GET, GET-NEXT, SET, GET-BULK, TRAP, INFORM, 841 RESPONSE, and REPORT). 843 8.1.2. Applicability for MANETs 845 SNMP is used on a broad range of networks, from a small number of 846 network devices to networks with large numbers of network devices. 847 SNMP has a minimal impact on the managed nodes, places minimal 848 transport requirements, and continues working when most other network 849 applications fail. These characteristics allow for SNMP applications 850 on MANET as well. Using SNMP, we can monitor network performance, 851 track network usage, detect network faults, detect inappropriate 852 access, and remotely configure MANET nodes. These network management 853 activities help to optimize MANET network performance. In the 854 following, scenarios are listed where SNMP can be useful in the 855 management of MANETs: 857 o Pre-deployment situation is the most common practice when all 858 MANET routers are deployed at a fixed location for initial 859 configuration. The configuration is conducted by a fixed 860 management station. SNMP configuration methods are necessary to 861 be performed for this situation. 863 o Once MANET routers are deployed or being used in the field where 864 low bandwidth is available, SNMP performance and state management, 865 and fault management methods are necessary to be used for this 866 situation. 868 o MANET routers can be managed from a Centralized Network Management 869 Station where is usually a fixed location. SNMP configuration, 870 monitoring, and fault management methods are necessary to be 871 applied here. 873 o In some cases when a MANET router is required to be reset to its 874 initial configuration, this is often accomplished by a local 875 network management manager that resides within the MANET router. 876 SNMP configuration, monitoring, and fault management methods are 877 necessary to be applied here. 879 8.2. Managing MANET with NETwork CONFiguration Protocol (NETCONF) 881 8.2.1. Overview of the Protocol 883 NETCONF is a promising technology emerging from the IETF as a 884 potential method of standardizing network management that is directed 885 to improve the configuration process for network based devices. The 886 NETCONF protocol was designed as a means of addressing the drawbacks 887 and limitations of SNMP as a mode of initializing, manipulating and 888 deleting configuration data. It accomplishes this through a set of 889 standard Remote Procedure Calls (RPCs) that interact with a NETCONF 890 enabled device. Some of the features it boasts over SNMP are: 892 o Separation of configuration and state data 894 o Three distinct configuration sets for running, start-up and 895 candidate (uncommitted scratch set) 897 o Ability to extend the functionality beyond the core RPCs 899 It should be noted that NETCONF is not intended to be a complete 900 replacement for SNMP. NETCONF is tailored specifically for its 901 configuration functionality while SNMP would still be the dominate 902 method of polling for performance and monitoring. The protocols are 903 designed to work side by side to provide a complete network 904 management solution. The current version of NETCONF can run over 905 four secure transport protocols: Secure Shell (SSH) which is 906 mandatory. The configuration data exchanged by NETCONF is modeled 907 using YANG [RFC6022] and coded in modules. These modules can be 908 broken down into sub modules to reduce complexity. Data is encoded 909 using a set of pre-defined data types and stored in a tree/leaf 910 structure. 912 8.2.2. Applicability for MANETs 914 With the advantage of configuration and security over SNMP, NETCONF 915 has recently been supported and utilized by network management 916 community. SNMP configuration methods in the old days can now be 917 replaced with NETCONF configuration methods. In the following, 918 scenarios are listed where NETCONF managing methods are useful: 920 Pre-deployment configuration - NETCONF can be best useful in this 921 situation when stable and reliable connectivity exists. 923 Configuration changes done by a Centralized Network Management 924 Station - although NETCONF can certainly be useful here, but high 925 latency can be a problem if there is high latency. 927 Configuration changes done by Local Network Management Manager - 928 NETCONF configuration methods are necessary to be deployed for this 929 management framework. 931 8.3. Managing MANET with DISMAN 933 8.3.1. Overview 935 TBD 937 8.3.2. Applicability for MANETs 939 TBD 941 8.4. Managing MANET with CoAP 942 8.4.1. Overview 944 TBD 946 8.4.2. Applicability for MANETs 948 TBD 950 9. References 952 [I-D.OLSRv2] 953 Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 954 "The Optimized Link State Routing Protocol version 2", 955 draft-ietf-manet-olsr-17 (work in progress), October 2012. 957 [I-D.ersue-constrained-mgmt] 958 Ersue, M., Romascanu, R., and J. Schoenwaelder, 959 "Management of Networks with Constrained Devices: Use 960 Cases and Requirements", draft-ersue-constrained-mgmt-02 961 (work in progress), October 2012. 963 [JTRS] "Wikipedia: Joint tactical Radio System", January 2013. 965 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 966 "Simple Network Management Protocol (SNMP)", STD 15, 967 RFC 1157, May 1990. 969 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 970 Requirement Levels", RFC 2119, BCP 14, March 1997. 972 [RFC4502] Waldbusser, S., "Remote Network Monitoring Management 973 Information Base Version 2", RFC 4502, May 2006. 975 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 976 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 977 March 2009. 979 [RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF 980 Monitoring", RFC 6022, October 2010. 982 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 983 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 984 RFC 6130, April 2011. 986 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 987 Bierman, "Network Configuration Protocol (NETCONF)", 988 RFC 6241, June 2011. 990 [RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of 991 Managed Objects for the Neighborhood Discovery Protocol", 992 RFC 6779, October 2012. 994 [SKYMESH] Suzuki, H., Kaneko, Y., Mase, K., Yamazaki, S., and H. 995 Makino, "An Ad Hoc Network in the Sky, SKYMESH, for Large- 996 Scale Disaster Recovery", Proceedings of the 64th IEEE 997 Vehicular Technology Conference, September 2006. 999 [WIN-T] "Wikipedia: Warfighter Information Network - Tactical", 1000 January 2013. 1002 Authors' Addresses 1004 James Nguyen 1005 U.S. Army CERDEC 1006 6010 Frankfort St 1007 Aberdeen Proving Ground, 1008 USA 1010 Phone: +1-443-395-5628 1011 Email: james.h.nguyen4.civ@mail.mil 1012 URI: 1014 Robert G. Cole 1015 U.S. Army CERDEC 1016 6010 Frankfort St 1017 Aberdeen Proving Ground, 1018 USA 1020 Phone: +1-443-395-8744 1021 Email: robert.g.cole.civ@mail.mil 1022 URI: 1024 Ulrich Herberg 1025 Fujitsu Laboratories of America 1026 1240 East Arques Avenue 1027 Sunnyvale, CA 1028 USA 1030 Phone: +1 408 530 4528 1031 Email: ulrich@herberg.name 1032 URI: http://www.herberg.name 1033 Jiazi Yi 1034 LIX, Ecole Polytechnique 1035 Route de Saclay 1036 Palaiseau, 1037 France 1039 Phone: 1040 Email: jiazi@jiaziyi.com 1041 URI: http://www.jiaziyi.com/ 1043 Justin Dean 1044 Naval Research Laboratory 1046 Phone: 1047 Email: jdean@itd.nrl.navy.mil 1048 URI: http://cs.itd.nrl.navy.mil/