Network Working Group J. Nguyen Internet-Draft R. Cole Intended status: Informational U.S. Army CERDEC Expires: August 22, 2013 U. Herberg Fujitsu Laboratories of America J. Yi LIX, Ecole Polytechnique J. Dean Naval Research Laboratory February 18, 2013 Network Management of Mobile Ad hoc Networks (MANET): Architecture, Use Cases, and Applicability draft-nguyen-manet-management-00 Abstract This document aims at providing an extended architecture, use case and applicability statement for management of MANETs, as a guideline for how to manage MANETs. This document describes different management activities, such as network configuration, monitoring of state, monitoring of performance, fault management, and software upgrades. Different aspects of a MANET management architecture are illustrated (e.g., distributed vs. centralized management, flat vs. hierarchical management, management of an entire network vs. an individual router, etc.) and contrasted to the NMS architecture in the Internet. A desciption of typical MANET use cases relevant for management is followed by an overview of current standard management protocols that can be used in MANETs. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 22, 2013. Nguyen, et al. Expires August 22, 2013 [Page 1] Internet-Draft Network Management of MANETs February 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Objective of this Document . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Challenges and Problem Statement . . . . . . . . . . . . . . . 5 3.1. [CLG1] Distributed Ownership . . . . . . . . . . . . . . . 6 3.2. [CLG2] Ad Hoc Topology . . . . . . . . . . . . . . . . . . 6 3.3. [CLG3] Infrastructureless . . . . . . . . . . . . . . . . 6 3.4. [CLG4] Network Performance . . . . . . . . . . . . . . . . 6 3.5. [CLG5] Low Bandwidth / Lossy Channel . . . . . . . . . . . 7 4. Management Functions . . . . . . . . . . . . . . . . . . . . . 7 4.1. [ACT1] Network Configuration . . . . . . . . . . . . . . . 7 4.2. [ACT2] Monitoring of State . . . . . . . . . . . . . . . . 7 4.3. [ACT3] Monitoring of Performance . . . . . . . . . . . . . 8 4.4. [ACT4] Notifications and Fault Management . . . . . . . . 8 4.5. [ACT5] Software Upgrades (Out of Scope) . . . . . . . . . 8 4.6. [ACT6] Security Configuration (Out of Scope) . . . . . . . 8 5. MANET Management Scenarios . . . . . . . . . . . . . . . . . . 9 5.1. [SCE1] Pre-Deployment Configuration . . . . . . . . . . . 9 5.2. [SCE2] Out-of-Band Management . . . . . . . . . . . . . . 10 5.3. [SCE3] Management of Mobile Nodes of Networks . . . . . . 11 5.4. [SCE4] In-Band Network Management . . . . . . . . . . . . 12 6. Management Architecture . . . . . . . . . . . . . . . . . . . 13 6.1. Typical Network Management Architecture in the Internet . 13 6.2. Distributed Architecture [ARC1] vs Centralized Architecture [ARC2] . . . . . . . . . . . . . . . . . . . 13 6.3. Flat Architecture [ARC3] vs Hierarchical Architecture [ARC4] . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.4. Entire Network Management [ARC5] vs Individual Router Management [ARC6] . . . . . . . . . . . . . . . . . . . . 14 6.5. Connectivity Assumptions . . . . . . . . . . . . . . . . . 14 Nguyen, et al. Expires August 22, 2013 [Page 2] Internet-Draft Network Management of MANETs February 2013 6.6. Notification Destination (Fault Management) . . . . . . . 14 7. MANET Use Cases . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Military Networks . . . . . . . . . . . . . . . . . . . . 14 7.2. Emmergency or Disaster Situations . . . . . . . . . . . . 15 7.3. Community Networks . . . . . . . . . . . . . . . . . . . . 16 7.3.1. Public Interent access . . . . . . . . . . . . . . . . 17 7.3.2. Public Safety . . . . . . . . . . . . . . . . . . . . 17 7.3.3. Opportunistic networks for developing areas . . . . . 17 7.4. Wireless Sensor Networks . . . . . . . . . . . . . . . . . 18 7.4.1. Habitat and Environmental Monitoring . . . . . . . . . 18 7.4.2. Health monitoring . . . . . . . . . . . . . . . . . . 18 7.4.3. Tracking applications . . . . . . . . . . . . . . . . 18 7.4.4. Wildlife monitoring . . . . . . . . . . . . . . . . . 18 7.5. Vehicular Networks . . . . . . . . . . . . . . . . . . . . 18 7.5.1. Intelligent Transportation Systems . . . . . . . . . . 18 7.5.2. Vehicular to vehicular networks . . . . . . . . . . . 19 8. Standard Management Protocols Currently Used in MANETs . . . . 19 8.1. Managing with Simple Network Management Protocol (SNMP) . 19 8.1.1. Overview of the Protocol . . . . . . . . . . . . . . . 19 8.1.2. Applicability for MANETs . . . . . . . . . . . . . . . 19 8.2. Managing MANET with NETwork CONFiguration Protocol (NETCONF) . . . . . . . . . . . . . . . . . . . . . . . . 20 8.2.1. Overview of the Protocol . . . . . . . . . . . . . . . 20 8.2.2. Applicability for MANETs . . . . . . . . . . . . . . . 21 8.3. Managing MANET with DISMAN . . . . . . . . . . . . . . . . 21 8.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 21 8.3.2. Applicability for MANETs . . . . . . . . . . . . . . . 21 8.4. Managing MANET with CoAP . . . . . . . . . . . . . . . . . 21 8.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22 8.4.2. Applicability for MANETs . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Nguyen, et al. Expires August 22, 2013 [Page 3] Internet-Draft Network Management of MANETs February 2013 1. Introduction MANET routing protocols are commonly assumed to be entirely self- managing: routers, running such a protocol, perceive the topology of the MANET by means of control message exchange. Any change to the topology is reflected in the local routing tables of each router after a bounded convergence time, which allows forwarding of data traffic towards its intended destination. Usually, no human interaction is required, as all variable parameters required by the routing protocol are either negotiated in the control traffic exchange, or are only of local importance to each router (i.e. do not influence interoperability). However, external management and monitoring of a MANET routing protocol may be desirable to optimize parameters of the routing protocol. Such an optimization may lead to a more stable perceived topology and to a lower control traffic overhead, and therefore to a higher delivery success ratio of data packets, a lower end-to-end delay, and less unnecessary bandwidth and energy usage. Such optimizations facilitate to scale the network to a large number of routers. In the following, requirements for MANET management are illustrated using an example, the Optimized Link State Routing Protocol version 2 [I-D.OLSRv2]: Fundamentally, the only parameter upon which agreement is required between OLSRv2 routers is C - a constant, used to fix the scale and granularity of validity and interval time values, as included in protocol control messages. [RFC5497] proposes a value for this constant; the symbol C is chosen to indicate it to be a "constant of nature" inside an OLSRv2 network, to which all routers must adhere. As control messages carry validity time and interval time values, a recipient OLSRv2 router can behave appropriately, even if it uses vastly different values itself, as long as the recipient and sender use the same value for C. Link admittance, by way of the hysteresis values and link quality estimation, requires no agreement; these are used for an individual router to determine a suitable threshold for "considering that a link could be a candidate for being advertised as usable". Still, external monitoring and management may be desirable in an OLSRv2 network. A network may benefit from having its control message emission tuned according to the network dynamics: in a mostly static network, i.e. a network in which the topology remains stable over long durations, the control message emission frequency could be decreased in order to consume less bandwidth or less energy. Conversely, of course, in a highly dynamic network, the emission frequency could be increased from improved responsiveness. Concerning the hysteresis and link quality estimation, a management Nguyen, et al. Expires August 22, 2013 [Page 4] Internet-Draft Network Management of MANETs February 2013 application might detect a region of an OLSRv2 network with a high link density - but also a high degree of "flapping": links coming "up" (SYM) only to disappear as LOST shortly thereafter. Detecting such behavior, on a global level and for multiple routers in the same region, could enable appropriately "tuning" the thresholds towards more stable links and, thus, a more stable routing structure in the network. These are but two examples, and have as common that a more "global view" of the network, than that of a single OLSRv2 router, is required - i.e. entail that a Network Management System is able to inquire as to various performance values of the network, and to set various router parameters. 1.1. Objective of this Document As MANETs are a relatively new kind of network, experience with large-scale deployments, and in particular management of such deployments, is limited. This document aims at providing an extended architecture, use case and applicability statement for management of MANETs, as a guideline for how to manage MANETs. This document describes different management activities, such as network configuration, monitoring of state, monitoring of performance, fault management, and software upgrades. Different aspects of a MANET management architecture are illustrated (e.g., distributed vs. centralized management, flat vs. hierarchical management, management of an entire network vs. an individual router, etc.) and contrasted to the NMS architecture in the Internet. A desciption of typical MANET use cases relevant for management is followed by an overview of current standard management protocols that can be used in MANETs. A related document that discusses other use cases and requirements of constrained networks and constrained devices (not focused on MANETs) is currently being developed in [I-D.ersue-constrained-mgmt]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Challenges and Problem Statement Management of MANETs is more difficult than in the Internet, for multiple reasons. This section outlines these challenges for Nguyen, et al. Expires August 22, 2013 [Page 5] Internet-Draft Network Management of MANETs February 2013 management of MANETs. 3.1. [CLG1] Distributed Ownership Depending on the user case, there may not be a network administrator of the MANET, e.g., in the use case of Section 7.3, where each inhabitant owns its own router. This means that the router may be completely protected against external access, or at least only allows limited access to it. Moreover, there may be issues of privacy, but these are out of scope of this document. 3.2. [CLG2] Ad Hoc Topology As the topology of a MANET may frequently change over time, no a priori topology planning is possible for the network administrator. Therefore, new routers may join at any time, and other may leave. This leads to a change of topology as well as IP addresses, depending on the IP address allocation policy or mechanism. Depending on the routing protocol used in the MANET, it may not be known to a network management station which IP addresses are available in the network, e.g., when using a reactive protocol, which only discovers routes on demand. Moreover, because of changes of the topology, it is possible that there is no route between two MANET routers because they are in different connected components of the network graph representing the network topology. 3.3. [CLG3] Infrastructureless In some use cases of MANETs, such as descibed in Section 7.3, there may not be a "controller" or "server". Even if there is, connectivity may be interrupted because of the ad hoc topology, described above. This entails that a distributed management may be desired instead of a centralized one. Routers could, e.g., monitor their neighbors and report failures on behalf of them once they have connectivity to a logging station; or they keep that information locally until requested by a user remotely. A decentralized management may lead to an increased coordination complexity. For example, it needs to be defined to which NMS notifications are sent from routers. 3.4. [CLG4] Network Performance Whereas in classical network management of the Internet, administrators typically connect to a single router in order to configure parameters or to monitor its performance, MANETs may have performance problems because of a whole group of malconfigured routers. Also, the performance measures of a larger number of Nguyen, et al. Expires August 22, 2013 [Page 6] Internet-Draft Network Management of MANETs February 2013 routers may be more relevant than that of a single router. In order to do that, different protocols would need to be used to manage a region of a network (e.g., using multicast connections, collection trees etc.) Typically in wired networks, performance monitoring is accomplished through periodic polling for state and counter data, from which performance reports are generated. In MANETs, due to dynamics, individual routers may be disconnected from a management station handling the periodic polling for performance data. Hence, architectures need to be developed which allow for remote control of reporting functions, but local generation of performance reports to allow for continuous collection during periods of disconnection. 3.5. [CLG5] Low Bandwidth / Lossy Channel Due to the nature of wireless channels, bandwidths may be far lower than in the Internet, and packet loss rates orders of magnitude higher. In terms of management applications requiring delivery of large volumes of data, e.g., new configuration files or software upgrades, may not be viable if running over reliable transport protocols. Standard TCP implementations are known to have poor performance characteristics in lossy MANETs. 4. Management Functions This section describes several management activities that are relevant for management of networks in general (not only MANETs). 4.1. [ACT1] Network Configuration Section 1 gives an example for network configuration for OLSRv2. Most network protocols allow for setting parameters, e.g., message intervals, timeouts, metric types, security parameters etc. These parameters can affect interoperability of the protocols, as well as protocol performance and efficiency. Managing such parameters remotely allows quick updates of parameters remotely, e.g., as a reaction to a change in topology by changing message intervals as described in the example in Section 1. 4.2. [ACT2] Monitoring of State Many network protocols maintain state during operation. For example for routing protocols, the state consists of information about destinations in the network, neighbors of a router, local interfaces etc. Monitoring such information remotely by means of a management protocol can provide insight into the current operation of the Nguyen, et al. Expires August 22, 2013 [Page 7] Internet-Draft Network Management of MANETs February 2013 protocol (e.g., the network topology), help to discover problems, calculate statistics, etc. Monitoring may require continous feedback of the current state for analyzing long-term behavior of the protocol, as well as to observe frequencies of changes of the state. 4.3. [ACT3] Monitoring of Performance Monitoring of performance is related to Section 4.2. Network operators may not only be interest in changing coonfiguration of a protocol or observer the state, but investigate performance issues, such as slow convergence of a protocol or (unncesseary) large network bandwidth consumption. While this information may be directly accessible by observing the state of the router, management protocols may help to provide complete reports, statistics, counters etc. to the network operator. For example, RMON [RFC4502] allows for gathering statistics based on counters and generating reports that are sent back to the network operator. 4.4. [ACT4] Notifications and Fault Management In case of criticial malfunctions or warnings, notifications may be actively sent to a network operator (e.g., via email or using a network management protocol). The notification will typically include the reason for the notification, the source address, related information, the time of the incident etc., and is sent to a preconfigured server (e.g., a network management station). 4.5. [ACT5] Software Upgrades (Out of Scope) During deployment of a device, it may be necessary to upgrade the firmware of the device, e.g., in order to fix security holes. Management protocols may allow a remote upgrade of the software by monitoring new versions of the firmware, downloading the upgrade in case there is a new version and verifying integrity of the downlaoded file, backing up the existing firmware, installing the firmware, verifying correct installation and providing feedback about the successful installation. As firmware upgrades are very different in terms of requirements, use cases, and protocols, they are out of scope for this document. 4.6. [ACT6] Security Configuration (Out of Scope) IETF protocols are required to provide sufficient security protection against malicious attacks. Before secure communication between devices over an unsecured network is possible, parameters such as cryptographic keys, cipher algorithms, trusted authorities, revoked keys etc. must be exchanged betwen devices. Nguyen, et al. Expires August 22, 2013 [Page 8] Internet-Draft Network Management of MANETs February 2013 As security configuration is very different in terms of requirements, use cases, and protocols, it is out of scope for this document. 5. MANET Management Scenarios This section discusses several management scenarios for the various types of MANETs identified previously. Management Scenarios represent applications of the Management Activities to abstracted MANET Use Cases, which combined identify a set of current and desired management capabilities. The list is non-exhaustive. In the following, the term "node" is used for either a host or router. The term "unit" or "mobile unit" is a unit that may contain multiple routers, hosts, and/or other IP-based communication devices. 5.1. [SCE1] Pre-Deployment Configuration Configuration of MANET devices once they have been deployed can be a very tricky endeavor. Hence, one common approach is the pre- configuration the MANET nodes prior to their deployment, followed by monitoring of their state and performance once they are deployed. This is often performed in the 'Parking Lot Staging Area'. MANET nodes are shipped to a remote location, along with a fixed Network Operations Center (NOC), where they are all connected over traditional wired or wireless networks. The Fixed NOC then performs mass-configuration and evaluation of configuration processes similar to configuration of networked devices in Enterprise Networks. Once all units are successfully configured, they are ready to be deployed. Once deployed, monitoring of the state and performance of the nodes is attempted at the fixed NOC. +---------+ +--------+ | Fixed |<---+------->| unit_1 | | NOC | | +--------+ +---------+ | | +--------+ +------->| unit_2 | | +--------+ | . | . | . | +--------+ +------->| unit_N | +--------+ Nguyen, et al. Expires August 22, 2013 [Page 9] Internet-Draft Network Management of MANETs February 2013 Figure 1: Parking Lot Staging Area 5.2. [SCE2] Out-of-Band Management Configuration management is relatively straightforward in Enterprise Networks due to the possibility of Out-of-Band Management. Here, in the event of mis-configuration, the manager can access the mis- configured device(s) out-of-band and correct, or back out of, the incorrect configuration(s). In MANETs, the equivalent capability can be achieved, to a certain extent, when multiple radio, satellite, or other interfaces exist on the MANET devices. An example of this scenario is management with satellite reach-back. Here, a fixed NOC and the MANET are connected through an On-The-Move (OTM) satellite communications capability. Vehicles carrying MANET routers can support multiple types of wireless interfaces, including high capacity short range radio interfaces as well as low capacity OTM satellite interfaces. The radio interfaces are the preferred interfaces for carrying data traffic due to their relatively high capacity, but the range is limiting with respect to connectivity to a Fixed NOC. Hence, OTM satellite interfaces offer a more persistent but lower capacity reach-back capability. The existence of a more persistent satellite reach-back capability offers the NOC the ability to monitor and manage the MANET routers over the air. This affords the NOC the ability to perform state and performance monitoring and receive notifications, but also allows the NOC to perform some amount of configuration management safely while the MANET nodes are on the move. Nguyen, et al. Expires August 22, 2013 [Page 10] Internet-Draft Network Management of MANETs February 2013 --- +--+ --- / /---|SC|---/ / --- +--+ --- +---------+ | | Fixed |<--------------------------+ | NOC | +--------------| +---------+ | +-------------------+ | | | +--------+ | +--------+ | unit_1 | +---------+ | unit_N | +--------+ | | +--------+ * | | * * * +--------+ | * * *********| unit_2 |******|******* * +--------+ | * * | * * +--------+ * ********| unit_3 |***** +--------+ --- show SatCom links *** show Radio links Figure 2: Monitoring with one-hop SatCom Reachback network 5.3. [SCE3] Management of Mobile Nodes of Networks It is common to find mobile vehicles carrying a rather complex set of networking devices, including routers running MANET control protocols. In this scenario, the MANET mobile unit has a rather complex internal architecture where a local manager within the unit is responsible for local management. The local management includes management of the MANET router and control protocols, the firewall, servers, proxies, hosts and applications. Here, a standard Enterprise Management interface is applicable in this scenario. Moreover, in addition to being able to utilize a standard management interface into the components comprising the MANET nodal network, the local manager can be responsible for local monitoring and the generation of periodic reports back to the Fixed NOC. Nguyen, et al. Expires August 22, 2013 [Page 11] Internet-Draft Network Management of MANETs February 2013 Interface | V +---------+ +-------------------------+ | Fixed | Interface | +---+ +---+ | | NOC |<---+------->| | R |--+--| F | | +---------+ | | +---+ | +---+ | | | | | +---+ | | | +---+ | +--| P | | | | | M |--+ | +---+ | | | +---+ | | | | | +---+ | | | +--| D | | | | | +---+ | | | | | | | | +---+ | | | +--| H | | | | +---+ | | | unit_1 | | +-------------------------+ | | | +--------+ +------->| unit_2 | | +--------+ | . | . | . | +--------+ +------->| unit_N | +--------+ Key: R-Router F-Firewall P-PEP (Performance Enhancing Proxy) D-Servers, e.g., DNS H-hosts M-Local Manager Figure 3: Hierarchical Management Nodes 5.4. [SCE4] In-Band Network Management In future MANET operations, it would be useful to achieve full management of the MANET over In-Band access over potentially lossy, intermittent and large delay links. In this case, there are a number Nguyen, et al. Expires August 22, 2013 [Page 12] Internet-Draft Network Management of MANETs February 2013 of issues that would arise and need to be addressed, including: 1. Validating the network configuration (and local configuration) becomes a complex task, e.g., when to cut-over the network to the new configuration becomes an interesting question. 2. Bandwidth considerations may become important when attempting to push large configuration changes to a large number of MANET nodes over the wireless infrastructure. 3. Typically the state of the devices comprising the MANET would be in various states of operations, e.g., ON/OFF, etc., and synchronizing these nodes to the new network configuration would be problematic. 4. Pushing large data files, e.g., software upgrades, over a lossy network, would be problematic,e.g., the TCP over lossy links issue previously discussed. +---------+ +--------+ | Mobile |<----------->| unit_1 | | NOC |?--+ +--------+ +---------+ | ^ | +--------+ | +------->| unit_2 | | +--------+ | . | . | . | +--------+ +---------------->| unit_N | +--------+ In-Band Management over Lossy/intermittent Links 6. Management Architecture 6.1. Typical Network Management Architecture in the Internet 6.2. Distributed Architecture [ARC1] vs Centralized Architecture [ARC2] 6.3. Flat Architecture [ARC3] vs Hierarchical Architecture [ARC4] Nguyen, et al. Expires August 22, 2013 [Page 13] Internet-Draft Network Management of MANETs February 2013 6.4. Entire Network Management [ARC5] vs Individual Router Management [ARC6] 6.5. Connectivity Assumptions 6.6. Notification Destination (Fault Management) 7. MANET Use Cases This section lists several use cases of MANETs. Each case is introduced with a brief description of the application, role of MANET in such application, and maybe some example deployments in the real world. Required management activities, related challenges and management scenarios are illustrated with a reference to previous section. For example, [ACT3] stands for section 4.3 Monitoring of Performance. This list is non-exhaustive. 7.1. Military Networks Military tactical networks are characterized by their domain of operations. Networks are required to support a broad range of mobilities (e.g., ground, air and space vehicles), are required to support a broad range of sizes (e.g., from small squad level networks to divisional level deployments of tens of thousands of nodes), are required to operate in very hostile environments (e.g., all climates), in very critical situations (e.g., warfare), and do so under explicit attacks (e.g., kinetic and non-kinetic) by hostiles. Military tactical networks are primarily wireless and hence must operate with intermittent and lossy connectivity with little or no infrastructure. These networks are required to provide highly reliable and robust communications; it is not possible to simply provide monetary rebates to customers in the event of a failure-to- operate. Military networks must provide a robust Quality-of-Service in order to both support the presentation of a broad range of realtime and non-realtime applications and to support the triage of information in situations of network congestion. Current military MANETs range from upper echelon deployments such as the Warfighter Information Network-Tactical (WIN-T) [WIN-T]. WIN-T is a vehicular-based MANET, where vehicles of various sizes are supported depending upon the echelon level, e.g., high capacity trucks carrying multiple computers, routers, radio and satellite systems, high power generation systems, etc., versus small capacity Nguyen, et al. Expires August 22, 2013 [Page 14] Internet-Draft Network Management of MANETs February 2013 car-sized or unmanned ground and air vehicles with one or two computers and a single radio system with minimal power storage capabilities. Other military MANETs are comprised of networks of single radio systems such as the Joint Tactical Radio System (JTRS) [JTRS]. JTRS systems are typically carried as individual mobile radio nodes of various sizes and platforms. The JTRS Ground Mobile Radio (GMR) is a larger high power high bandwidth radio carried on vehicular systems. While the JTRS Handheld, Manpack and Small Form Fit (HMS) radio is a small hand held system. NOTE: the following is just an example to illustrate the refs! Derived challenges: [CLG2][CLG3][CLG5] Derived management activities: [ACT1][ACT2][ACT3][ACT4][ACT5] Derived management scenarios: [SCE1] Derived management architecture: [ARC1][ARC2][ARC4][ARC5] 7.2. Emmergency or Disaster Situations Establishing basic communication after an emergency such as a flood, earthquake or nuclear accident, is difficult when the communication infrastructure is damaged. Mobile phones require nearby infrastructure that provide connectivity, which may not work any more. Even if the infrastructure is still available, the increased use of mobile phones after an emergency can saturate the network. The cable telephone network may be malfunctioning when cables are broken, satellite phones are rarely available and expensive. In addition to voice communication, data collection on the emergency site is desirable. Information, such as temperature, humidity or radioactivity of the disaster area, can help understanding the degree of the disaster, and to coordinate help accordingly. One such deployment that establishes communication in emergency situations is the SKYMESH project of Niigata University [SKYMESH], which is aimed at establishing communication between several unmanned balloons in order to rapidly create communication networks for rescuers. A small computer, together with a GPS device and a camera, is attached to the balloon, which floats in a height of 50 to 100m over ground, allowing remote wide area monitoring of the disaster area, as well as establishing communication (voice or data) using the ad hoc network. Another deployment in emergency situations is to drop large numbers of sensors from an airplane. The sensors can then establish an ad hoc network, once they are on the ground, without the necessity for humans to enter the disaster site and to deploy the sensors manually. Nguyen, et al. Expires August 22, 2013 [Page 15] Internet-Draft Network Management of MANETs February 2013 7.3. Community Networks Community networks are comprised of constrained routers in a multi- hop mesh topology, communicating over a lossy, and often wireless channel. While the routers are mostly non-mobile, the topology may be very dynamic because of fluctuations in link quality of the (wireless) channel caused by, e.g., obstacles, or other nearby radio transmissions. Depending on the routers that are used in the community network, the resources of the routers (memory, CPU) may be more or less constrained - available resources may range from only a few kilobytes of RAM to several megabytes or more, and CPUs may be small and embedded, or more powerful general-purpose processors. Examples of such community networks are the FunkFeuer network (Vienna, Austria), FreiFunk (Berlin, Germany), Seattle Wireless (Seattle, USA), and AWMN (Athens, Greece). These community networks are public and non-regulated, allowing their users to connect to each other and - through an uplink to an ISP - to the Internet. No fee, other than the initial purchase of a wireless router, is charged for these services. Applications of these community networks can be diverse, e.g., location based services, free Internet access, file sharing between users, distributed chat services, social networking etc, video sharing etc. As an example of a community network, the FunkFeuer network comprises several hundred routers, many of which have several radio interfaces (with omnidirectional and some directed antennas). The routers of the network are small-sized wireless routers, such as the Linksys WRT54GL, available in 2011 for less than 50 Euros. These routers, with 16 MB of RAM and 264 MHz of CPU power, are mounted on the rooftops of the users. When new users want to connect to the network, they acquire a wireless router, install the appropriate firmware and routing protocol, and mount the router on the rooftop. IP addresses for the router are assigned manually from a list of addresses (because of the lack of autoconfiguration standards for mesh networks in the IETF). While the routers are non-mobile, fluctuations in link quality require an ad hoc routing protocol that allows for quick convergence to reflect the effective topology of the network (such as [RFC6130] and [I-D.OLSRv2]). Usually, no human interaction is required for these protocols, as all variable parameters required by the routing protocol are either negotiated in the control traffic exchange, or are only of local importance to each router (i.e. do not influence interoperability). However, external management and monitoring of an ad hoc routing protocol may be desirable to optimize parameters of the routing protocol. Such an optimization may lead to a more stable perceived topology and to a lower control traffic overhead, and therefore to a higher delivery success ratio of data packets, a lower Nguyen, et al. Expires August 22, 2013 [Page 16] Internet-Draft Network Management of MANETs February 2013 end-to-end delay, and less unnecessary bandwidth and energy usage. Different use cases for the management of community networks are possible: o One single Network Management Station (NMS), e.g. a border gateway providing connectivity to the Internet, requires managing or monitoring routers in the community network, in order to investigate problems (monitoring) or to improve performance by changing parameters (managing). As the topology of the network is dynamic, constant connectivity of each router towards the management station cannot be guaranteed. Current network management protocols, such as SNMP and NETCONF, may be used (e.g., using interfaces such as the NHDP-MIB [RFC6779]). However, when routers in the community network are constrained, existing protocols may require too many resources in terms of memory and CPU; and more importantly, the bandwidth requirements may exceed the available channel capacity in wireless mesh networks. Moreover, management and monitoring may be unfeasible if the connection between the NMS and the routers is frequently interrupted. o A distributed network monitoring, in which more than one management station monitors or manages other routers. Because connectivity to a server cannot be guaranteed at all times, a distributed approach may provide a higher reliability, at the cost of increased complexity. Within the IETF, several standard exists for distributed monitoring and management, including Remote Monitoring (RMON) and DIStributed MANagement (DISMAN). This will be discussed in the Management Architectures section below. o Monitoring and management of a whole network or a group of routers. Monitoring the performance of a community network may require more information than what can be acquired from a single router using a network management protocol. Statistics, such as topology changes over time, data throughput along certain routing paths, congestion etc., are of interest for a group of routers (or the routing domain) as a whole. As of 2012, no IETF standard allows for monitoring or managing whole networks, instead of single routers. 7.3.1. Public Interent access 7.3.2. Public Safety 7.3.3. Opportunistic networks for developing areas Nguyen, et al. Expires August 22, 2013 [Page 17] Internet-Draft Network Management of MANETs February 2013 7.4. Wireless Sensor Networks The general context for Wireless Sensor Networks (WSNs) is small, cheap devices whose primary function is data acquisition, with communications capabilities enabling them to send data to a controller, using a wireless multi-hop topology. As an example, a WSN deployed for environmental monitoring might contain a set of temperature sensors, sending "notifications" to a central controller when the temperature exceeds certain thresholds. Compared to a network of wired sensors, WSNs offer the advantage of enabling mobility to sensors, as well as reducing cost and space requirements for the installation of cables. The properties of WSNs are similar to the ad hoc network presented in section 1.3.1, with the following differences: (1) hardware resources (in terms of CPU and memory) of sensor routers are even more constrained than ad hoc routers in the FunkFeuer network, (2) unlike the routers in the FunkFeuer network, sensor routers may be battery driven, and (3) sensor network topologies are often optimized for particular traffic patterns. As for (1), a typical sensor router may be equipped with no more than 50 KByte of flash, 5 KByte of RAM, and a few Megahertz of CPU speed (e.g., the Scatterweb MSB430). Compared to the routers in the FunkFeuer network, these sensor routers have much more constrained resources, and thus require special care when designing protocols for these sensor routers, minimizing required memory space and CPU power. As for (2), sensor nodes are often battery-driven, constraining their life-time compared to routers with a permanent energy supply. This implies that protocols for such sensors should have the objective to maximize resource savings (e.g. by reducing the frequency of message transmissions). As for (3), a major use case for sensors is measuring a set of environmental data and sending it through the network to a central controller. This traffic flow assumption allows to construct specific, optimized network topologies which focus on connections from a sensor to the controller (versus sensor-to-sensor or controller-to-sensor). 7.4.1. Habitat and Environmental Monitoring 7.4.2. Health monitoring 7.4.3. Tracking applications 7.4.4. Wildlife monitoring 7.5. Vehicular Networks 7.5.1. Intelligent Transportation Systems Nguyen, et al. Expires August 22, 2013 [Page 18] Internet-Draft Network Management of MANETs February 2013 7.5.2. Vehicular to vehicular networks 8. Standard Management Protocols Currently Used in MANETs The IETF has already offered an array of solutions to manage IP networks. These range from the Simple Network Management Protocol (SNMP) [RFC1157] and related capabilities, to more recent management capabilities based upon the NETwork CONFiguration Protocol (NETCONF) [RFC6241] and associated capabilities and other tools, e.g., Constrained Application Protocol (CoAP) or DIStributed MANagement (DISMAN). 8.1. Managing with Simple Network Management Protocol (SNMP) 8.1.1. Overview of the Protocol SNMP was purposely designed at the application level to manage different devices built by different vendors. SNMP uses the concept of a manager and agents for managing devices using the TCP/IP protocol suite. It provides a set of network operations for configuring, monitoring, and managing networks. In SNMP frameworks, a manager station, which runs the SNMP client program, controls a set of agents. An agent residing on the device runs the SNMP server program. The management process is achieved either through a simple session- less User Datagram Protocol (UDP) or a session-oriented Transport Control Protocol (TCP), communication between a manager and an agent. SNMP uses two other protocols for handling management tasks: Structure of Management Information (SMI) as a language to describe management model and Management Information Bases (MIBs) as instances of management models. SMI defines general rules for naming the objects, defining object types, and showing how to encode objects and values. MIB modules model a collection of named objects and their relationship to each other. SNMP can provide capabilities of configuring the network devices and monitoring functionality by providing network states, performance data, and notifications through a set of packet types (GET, GET-NEXT, SET, GET-BULK, TRAP, INFORM, RESPONSE, and REPORT). 8.1.2. Applicability for MANETs SNMP is used on a broad range of networks, from a small number of network devices to networks with large numbers of network devices. SNMP has a minimal impact on the managed nodes, places minimal transport requirements, and continues working when most other network applications fail. These characteristics allow for SNMP applications Nguyen, et al. Expires August 22, 2013 [Page 19] Internet-Draft Network Management of MANETs February 2013 on MANET as well. Using SNMP, we can monitor network performance, track network usage, detect network faults, detect inappropriate access, and remotely configure MANET nodes. These network management activities help to optimize MANET network performance. In the following, scenarios are listed where SNMP can be useful in the management of MANETs: o Pre-deployment situation is the most common practice when all MANET routers are deployed at a fixed location for initial configuration. The configuration is conducted by a fixed management station. SNMP configuration methods are necessary to be performed for this situation. o Once MANET routers are deployed or being used in the field where low bandwidth is available, SNMP performance and state management, and fault management methods are necessary to be used for this situation. o MANET routers can be managed from a Centralized Network Management Station where is usually a fixed location. SNMP configuration, monitoring, and fault management methods are necessary to be applied here. o In some cases when a MANET router is required to be reset to its initial configuration, this is often accomplished by a local network management manager that resides within the MANET router. SNMP configuration, monitoring, and fault management methods are necessary to be applied here. 8.2. Managing MANET with NETwork CONFiguration Protocol (NETCONF) 8.2.1. Overview of the Protocol NETCONF is a promising technology emerging from the IETF as a potential method of standardizing network management that is directed to improve the configuration process for network based devices. The NETCONF protocol was designed as a means of addressing the drawbacks and limitations of SNMP as a mode of initializing, manipulating and deleting configuration data. It accomplishes this through a set of standard Remote Procedure Calls (RPCs) that interact with a NETCONF enabled device. Some of the features it boasts over SNMP are: o Separation of configuration and state data o Three distinct configuration sets for running, start-up and candidate (uncommitted scratch set) Nguyen, et al. Expires August 22, 2013 [Page 20] Internet-Draft Network Management of MANETs February 2013 o Ability to extend the functionality beyond the core RPCs It should be noted that NETCONF is not intended to be a complete replacement for SNMP. NETCONF is tailored specifically for its configuration functionality while SNMP would still be the dominate method of polling for performance and monitoring. The protocols are designed to work side by side to provide a complete network management solution. The current version of NETCONF can run over four secure transport protocols: Secure Shell (SSH) which is mandatory. The configuration data exchanged by NETCONF is modeled using YANG [RFC6022] and coded in modules. These modules can be broken down into sub modules to reduce complexity. Data is encoded using a set of pre-defined data types and stored in a tree/leaf structure. 8.2.2. Applicability for MANETs With the advantage of configuration and security over SNMP, NETCONF has recently been supported and utilized by network management community. SNMP configuration methods in the old days can now be replaced with NETCONF configuration methods. In the following, scenarios are listed where NETCONF managing methods are useful: Pre-deployment configuration - NETCONF can be best useful in this situation when stable and reliable connectivity exists. Configuration changes done by a Centralized Network Management Station - although NETCONF can certainly be useful here, but high latency can be a problem if there is high latency. Configuration changes done by Local Network Management Manager - NETCONF configuration methods are necessary to be deployed for this management framework. 8.3. Managing MANET with DISMAN 8.3.1. Overview TBD 8.3.2. Applicability for MANETs TBD 8.4. Managing MANET with CoAP Nguyen, et al. Expires August 22, 2013 [Page 21] Internet-Draft Network Management of MANETs February 2013 8.4.1. Overview TBD 8.4.2. Applicability for MANETs TBD 9. References [I-D.OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol version 2", draft-ietf-manet-olsr-17 (work in progress), October 2012. [I-D.ersue-constrained-mgmt] Ersue, M., Romascanu, R., and J. Schoenwaelder, "Management of Networks with Constrained Devices: Use Cases and Requirements", draft-ersue-constrained-mgmt-02 (work in progress), October 2012. [JTRS] "Wikipedia: Joint tactical Radio System", January 2013. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC4502] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2", RFC 4502, May 2006. [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March 2009. [RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF Monitoring", RFC 6022, October 2010. [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. Nguyen, et al. Expires August 22, 2013 [Page 22] Internet-Draft Network Management of MANETs February 2013 [RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of Managed Objects for the Neighborhood Discovery Protocol", RFC 6779, October 2012. [SKYMESH] Suzuki, H., Kaneko, Y., Mase, K., Yamazaki, S., and H. Makino, "An Ad Hoc Network in the Sky, SKYMESH, for Large- Scale Disaster Recovery", Proceedings of the 64th IEEE Vehicular Technology Conference, September 2006. [WIN-T] "Wikipedia: Warfighter Information Network - Tactical", January 2013. Authors' Addresses James Nguyen U.S. Army CERDEC 6010 Frankfort St Aberdeen Proving Ground, USA Phone: +1-443-395-5628 Email: james.h.nguyen4.civ@mail.mil URI: Robert G. Cole U.S. Army CERDEC 6010 Frankfort St Aberdeen Proving Ground, USA Phone: +1-443-395-8744 Email: robert.g.cole.civ@mail.mil URI: Ulrich Herberg Fujitsu Laboratories of America 1240 East Arques Avenue Sunnyvale, CA USA Phone: +1 408 530 4528 Email: ulrich@herberg.name URI: http://www.herberg.name Nguyen, et al. Expires August 22, 2013 [Page 23] Internet-Draft Network Management of MANETs February 2013 Jiazi Yi LIX, Ecole Polytechnique Route de Saclay Palaiseau, France Phone: Email: jiazi@jiaziyi.com URI: http://www.jiaziyi.com/ Justin Dean Naval Research Laboratory Phone: Email: jdean@itd.nrl.navy.mil URI: http://cs.itd.nrl.navy.mil/ Nguyen, et al. Expires August 22, 2013 [Page 24]