Snapshot of OLSRv2-Routed MANET Management
draft-clausen-manet-olsrv2-management-snapshot-00

Network Working Group                                         T. Clausen
Internet-Draft                                  LIX, Ecole Polytechnique
Intended status: Informational                                U. Herberg
Expires: May 10, 2014                    Fujitsu Laboratories of America
                                                        November 6, 2013

               Snapshot of OLSRv2-Routed MANET Management
           draft-clausen-manet-olsrv2-management-snapshot-00

Abstract

   This document describes how Mobile Ad Hoc Networks (MANETs) are
   typically managed, in terms of pre-deployment management, as well as
   rationale and means of monitoring and management of MANET routers
   running the routing protocol OLSRv2 and its constituent protocol
   NHDP.  Apart from pre-deployment management for setting up IP
   addresses and security related credentials, OLSRv2 only needs routers
   to agree one single parameter (called "C").  Other parameters for
   tweaking network performance may be determined during operation of
   the network, and need not be the same in all routers.  This, using
   MIB modules and related management protocols such as SNMP (or other,
   less "chatty" protocols).  In addition, for debugging purposes,
   monitoring data and performance related counters can be sent to the
   Network Management Station (NMS) via standardized management
   protocols.

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 May 10, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Clausen & Herberg         Expires May 10, 2014                  [Page 1]
Internet-Draft       OLSRv2-Routed MANET Management        November 2013

   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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Statement of Purpose  . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Pre-Deployment Management . . . . . . . . . . . . . . . . . . . 3
     3.1.  Interface Addresses . . . . . . . . . . . . . . . . . . . . 4
     3.2.  Security Material . . . . . . . . . . . . . . . . . . . . . 4
     3.3.  The Value of C  . . . . . . . . . . . . . . . . . . . . . . 4
   4.  How do we Manage MANETs?  . . . . . . . . . . . . . . . . . . . 5
   5.  What and Why do we Manage and Monitor?  . . . . . . . . . . . . 5
   6.  This Document does not Constrain how to Manage and Monitor
       MANETs  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Informative References  . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

Clausen & Herberg         Expires May 10, 2014                  [Page 2]
Internet-Draft       OLSRv2-Routed MANET Management        November 2013

1.  Introduction

   The MANET routing protocol OLSRv2 [OLSRv2], as well as its
   constituent parts NHDP [RFC6130], [RFC5497], [RFC5148], [RFC5444],
   [RFC6622bis], [OLSRv2-integrity], is designed to autonomously
   maintain routes across a dynamic network topology.  OLSRv2 is
   designed so as to minimize operator intervention throughout the
   duration of a network deployment, and to allow for heterogeneous
   configuration of OLSRv2 routers within the same network deployment:
   most configuration values are either of local significance only
   (e.g., message jitter parameters) or, when they are not, are carried
   in control signals exchanged between OLSRv2 routers (e.g.,
   information validity time).

   All the same, a small set of configuration options must be
   established in each OLSRv2 router prior to deployment, with some
   requiring agreement among all the OLSRv2 routers within the same
   deployment.  Furthermore, throughout the duration of a network
   deployment, external management and monitoring of a network may be
   desirable, e.g., for performance optimization or debugging purposes.

1.1.  Statement of Purpose

   Deployments of OLSRv2 are diverse, and may include community
   networks, constrained environments, tactical networks, etc. - each
   such environment may present distinctly different requirements as to
   management and monitoring.

   This document does therefore explicitly not pretend to provide an
   exhaustive description of how all OLSRv2 network deployments should
   be managed and monitored - and does, specifically, not prescribe any
   management model.

   What this document does, however, is to present how some OLSRv2
   network deployments are managed and monitored, using well-established
   management patterns and well-known protocols.

2.  Terminology

   This document uses terminology from [OLSRv2], [RFC6130], and
   [RFC5497].

3.  Pre-Deployment Management

   Prior to operation of an OLSRv2 network, or more precisely, prior to
   proper operation of OLSRv2 and its constituent parts, certain

Clausen & Herberg         Expires May 10, 2014                  [Page 3]
Internet-Draft       OLSRv2-Routed MANET Management        November 2013

   parameters need to be configured on each OLSRv2 router.

3.1.  Interface Addresses

   According to [RFC6130], and as used by [OLSRv2], each interface of an
   OLSRv2 router must be configured with at least one IP address.
   [RFC6130] provides guidance as to the characteristics of such IP
   addresses, including the (limited) conditions under which an IP
   address may be configured on multiple interfaces.  While automatic
   configuration of IP addresses on OLSRv2 router interfaces is not
   excluded, currently no address autoconfiguration protocols have been
   standardized accomplishing this.  As a consequence, static
   configuration, or proprietary (as in: non-standardized) protocols
   ensure this.

3.2.  Security Material

   Security material (keys, algorithms, etc.) must be available for
   generating Integrity Check Values (ICVs) for outgoing control
   messages, and to allow validating ICVs in incoming control messages.
   The appropriate way of making such security material available is
   dependent on the deployment type.  For example, community networks
   (such as "Funkfeuer", http://funkfeuer.at), do currently not use any
   security at all.  Other deployment types may use a simple manual
   shared key distribution mechanism, or may use a proprietary key
   distribution protocol.  Tactical networks have much more stringent
   requirements for distributing key material, e.g., using manual
   distribution of the keys on encrypted USB keys, and with defensive
   mechanisms (up to and including mechanisms involving depleted
   uranium) if the keys are compromised.  In general, Automatic Key
   Management (AKM) as well as static/manual or other out-of-band
   mechanisms, can be viable options for distributing keys.  Currently,
   no standardized AKM mechanism for MANETs exist.  If the IETF
   standardizes such mechanisms in the future, for deployment types
   where such is appropriate, these can be used for distributing keys.
   Until such time, manual key distribution as well as proprietary
   mechanisms, prevail.  The important point to make here, however, is
   that by whichever method a key and other security material is made
   available, OLSRv2 will be able to properly use it.

3.3.  The Value of C

   The only pre-deployment configuration parameter that directly impacts
   protocol operation is the value of C. This value is used by each
   router for calculating the representation of interval and validity
   time, as included in control messages.  All routers in a deployment
   must agree on the value of C, as described in [RFC5497].

Clausen & Herberg         Expires May 10, 2014                  [Page 4]
Internet-Draft       OLSRv2-Routed MANET Management        November 2013

4.  How do we Manage MANETs?

   A deployed OLSRv2 network is, as previously discussed, operating
   autonomously, but occasionally with external management operations
   being desirable.  For the deployments described by this document (but
   see Section 6), these management operations are undertaken by a
   central Network Management Station (NMS).

   The MIB modules developed for OLSRv2 [OLSRv2-MIB] and for its
   constituent protocol NHDP [RFC6779] are verbose, in as much as that
   they expose for interrogation the complete protocol and router state,
   as well as enable setting parameters (timer intervals, time-outs,
   jitter values etc.).  They do explicitly not enable setting the value
   of C (as that is required to be constant and uniform across the
   network, see Section 3.3), nor distributing security material (see
   Section 3.2).

   In some deployments, the NMS communicates with individual routers by
   way of SNMP - and, more commonly, by way of "proprietary" simpler,
   less verbose and (often) less secure protocols, and over UDP.  Note
   that this does not constitute a recommendation, but rather an
   observation that (apparently) SNMP has found less application in
   MANETs.

   The predecessor of OLSRv2, OLSR [RFC3626] did not have an associated
   MIB module.  Many deployments of OLSR did not support network
   management per se (i.e., configuration-on-launch was the way in which
   OLSR routers were managed), whereas those that did used a similar
   architecture to the one described in this document, and "proprietary"
   protocols, APIs for parameters and router states, data-models, etc.
   It can be speculated that the "proprietary" protocols used for
   communication between the NMS and the MIB modules on each OLSRv2
   router, in part, exist inherited from the protocols used for OLSR.

   Finally, it is uncommon to see an NMS permanently active in a
   deployed OLSRv2 network; rather, on an ad-hoc basis an NMS is
   introduced into the network, parameters configured or state
   interrogated.

5.  What and Why do we Manage and Monitor?

   As indicated earlier, OLSRv2 and its constituent protocol NHDP, are
   pretty robust with respect to parameter values: a deployment can
   operate with different parameters used in different OLSRv2 routers in
   the same network.  That being said, adapting these parameters
   according to circumstances is (often) desired.  For example, in a
   stable network (such as a wired network), TC messages may be sent

Clausen & Herberg         Expires May 10, 2014                  [Page 5]
Internet-Draft       OLSRv2-Routed MANET Management        November 2013

   infrequently and with long validity times, whereas in a highly
   dynamic network (such as in a vehicular network) TC messages may need
   to be sent more frequently and HELLO messages for discovering the
   local topology (almost) continuously.  In a similar vein, the message
   emission intervals and the information validity times should also be
   commensurate with the available network capacity: millisecond
   intervals between TC messages, for example, will consume all
   available network capacity whereas hourly intervals will be
   inappropriate even for a static and stable, wired, network (by way of
   simply new OLSRv2 routers arriving in the network, which will not
   "learn" the network topology before undue long delays).

   This adaptation may happen autonomously by a central NMS monitoring
   and adopting the parameters globally, autonomously by an NMS in each
   router, monitoring its local topology (and its stability) and
   adapting parameters locally, or by manual operator intervention.

   Given the dynamic and evolutive topology of OLSRv2 networks, a highly
   desirable property of an NMS is the ability to display and offer
   visibility of the current network status - for example, to display a
   graphical map of which OLSRv2 routers are currently part of the
   network.  As a proactive protocol, OLSRv2 maintains, in each OLSRv2
   router, a topology map including all destinations and a subset of the
   links present in the network (particularly true in a very dense
   network).  A typical feature of an NMS is to inquire as to the
   topology map of a single OLSRv2 router.  A slightly less typical
   feature is to inquire all (or, at least, many) OLSRv2 routers in a
   network, with the purpose of presenting a complete topology map.

6.  This Document does not Constrain how to Manage and Monitor MANETs

   As explained in Section 1, this document describes how, what and why
   some (typical) OLSRv2 networks are managed and monitored as of 2013.
   As such, the document is reflexive, not prescriptive: it does not
   stipulate requirements for how to manage OLSRv2 networks, nor does it
   claim to be a complete list of all management patterns or protocols.
   Other ways of managing an OLSRv2 network are very well imaginable,
   now or in future deployments of OLSRv2.

   As an example, rather than managing and monitoring OLSRv2 routers
   from a central NMS, a distributed management between multiple OLSRv2
   routers can be envisioned.  In particular, the monitoring data that
   is used to debug network problems and to tweak inefficiencies could
   be distributed amongst a group of OLSRv2 routers in the same network.
   This would both address problems of single point of failure when
   using only a single NMS, as well provide additional information about
   groups of multiples OLSRv2 routers rather than a single OLSRv2

Clausen & Herberg         Expires May 10, 2014                  [Page 6]
Internet-Draft       OLSRv2-Routed MANET Management        November 2013

   router.  An example for such a distributed information flow would be
   to identify certain areas of a network wherein, e.g., due to
   different density of OLSRv2 routers, message sending interval
   parameters could be exchanged between multiple OLSRv2 routers and
   optimal values negotiated between them.  This is just one example of
   many possible ways of how to manage and monitor a MANET, and it is
   not the intention of this document to prescribe how MANETs are
   managed in the presence or in the future.

7.  Acknowledgments

   The authors would like to gratefully acknowledge the following people
   for intense technical discussions, early reviews, and comments on the
   documents: Christopher Dearlove (BAE Systems), Adrian Farrel
   (Juniper).

8.  Informative References

   [OLSRv2]   Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
              "The Optimized Link State Routing Protocol version 2",
              draft-ietf-manet-olsrv2-19 (work in progress), March 2013.

   [OLSRv2-MIB]
              Herberg, U., Cole, R., and T. Clausen, "Definition of
              Managed Objects for the  Optimized Link State Routing
              Protocol version 2", work in
              progress draft-ietf-manet-olsrv2-mib-12, June 2013.

   [OLSRv2-integrity]
              Herberg, U., Dearlove, C., and T. Clausen, "Integrity
              Protection for Control Messages in NHDP and OLSRv2", work
              in progress draft-ietf-manet-nhdp-olsrv2-sec-01,
              March 2013.

   [RFC3626]  Clausen, T. and P. Jacquet, "The Optimized Link State
              Routing Protocol", RFC 3626, October 2003.

   [RFC5148]  Clausen, T., Dearlove, C., and B. Adamson, "Jitter
              Considerations in Mobile Ad Hoc Networks (MANETs)",
              RFC 5148, February 2008.

   [RFC5444]  Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
              "Generalized MANET Packet/Message Format", RFC 5444,
              February 2009.

   [RFC5497]  Clausen, T. and C. Dearlove, "Representing Multi-Value

Clausen & Herberg         Expires May 10, 2014                  [Page 7]
Internet-Draft       OLSRv2-Routed MANET Management        November 2013

              Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
              March 2009.

   [RFC6130]  Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              RFC 6130, April 2011.

   [RFC6622bis]
              Herberg, U., Clausen, T., and C. Dearlove, "Integrity
              Check Value and Timestamp TLV Definitions for Mobile Ad
              Hoc Networks (MANETs)", work in
              progress draft-ietf-manet-rfc6622-bis-05, September 2013.

   [RFC6779]  Herberg, U., Cole, R., and I. Chakeres, "Definition of
              Managed Objects for the Neighborhood Discovery Protocol",
              RFC 6779, May 2012.

Authors' Addresses

   Thomas Clausen
   LIX, Ecole Polytechnique
   91128 Palaiseau Cedex,
   France

   Phone: +33-6-6058-9349
   Email: T.Clausen@computer.org
   URI:   http://www.thomasclausen.org

   Ulrich Herberg
   Fujitsu Laboratories of America
   1240 E Arques Ave
   Sunnyvale CA 94086,
   US

   Phone:
   Email: ulrich@herberg.name
   URI:   http://www.herberg.name

Clausen & Herberg         Expires May 10, 2014                  [Page 8]