[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/