Network Working Group                                         T. Clausen
Internet-Draft                                  LIX, Ecole Polytechnique
Intended status: Informational                                U. Herberg
Expires: January 5, 2015                 Fujitsu Laboratories of America
                                                            July 4, 2014

               Snapshot of OLSRv2-Routed MANET Management


   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 Optimized Link State Routing protocol version 2 (OLSRv2)
   and its constituent MANET NehgiborHood Discovery 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 possibly other, less
   "chatty", protocols).  In addition, for debugging purposes,
   monitoring data and performance related counters, as well as
   notifications ("traps") can be sent to the Network Management System
   (NMS) via standardized management protocols.  This document

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

   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 January 5, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the

Clausen & Herberg        Expires January 5, 2015                [Page 1]

Internet-Draft       OLSRv2-Routed MANET Management            July 2014

   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( 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  . . . . . . . . . . . . . . . . . .  4
     3.1.  Lower Layer Alignment  . . . . . . . . . . . . . . . . . .  4
     3.2.  Interface Addresses  . . . . . . . . . . . . . . . . . . .  4
     3.3.  Security Material  . . . . . . . . . . . . . . . . . . . .  5
     3.4.  The Value of C . . . . . . . . . . . . . . . . . . . . . .  5
   4.  How do we Manage OLSRv2-based MANETs?  . . . . . . . . . . . .  5
     4.1.  Internal Management  . . . . . . . . . . . . . . . . . . .  6
     4.2.  External Management  . . . . . . . . . . . . . . . . . . .  6
   5.  What and Why do we Manage and Monitor? . . . . . . . . . . . .  7
   6.  Typical Communication Patterns . . . . . . . . . . . . . . . .  8
   7.  This Document does not Constrain how to Manage and Monitor
       MANETs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

Clausen & Herberg        Expires January 5, 2015                [Page 2]

Internet-Draft       OLSRv2-Routed MANET Management            July 2014

1.  Introduction

   The MANET routing protocol OLSRv2 [RFC7181], as well as its
   constituent parts NHDP [RFC6130], [RFC5497], [RFC5148], [RFC5444],
   [RFC7182], [RFC7183], 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 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 routers (e.g., information validity time).

   All the same, a small set of configuration options must be
   established in each router prior to deployment, with some requiring
   agreement among all the 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.  This document also does not address management of
   MANET routing protocols, other than OLSRv2 (and its constituent

   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.  In particular, this
   document addresses several of the consideration from [RFC5706], in
   particular Section 3 ("Management Considerations - How Will the
   Protocol Be Managed?").

2.  Terminology

   This document uses terminology from [RFC7181], [RFC6130], and

Clausen & Herberg        Expires January 5, 2015                [Page 3]

Internet-Draft       OLSRv2-Routed MANET Management            July 2014

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
   parameters need to be configured on each router.  The following
   sections describe the required pre-deployment management.

3.1.  Lower Layer Alignment

   Interoperability between routers requires alignment of lower protocol
   layers below OLSRv2.  In particular, all routers in the same MANET
   topology must be pre-configured to use the same IP address family
   (IPv4 or IPv6).  In a single OLSRv2 topology, it is not possible to
   mix IPv4 and IPv6 addresses, notably because [RFC5444] messages can
   contain either IPv4 *or* IPv6 addresses, but not both at the same
   time.  It is, however, possible to run two instances of OLSRv2, one
   instance for IPv4 and another one for IPv6, within the same network.

   In addition to the IP address family, other lower layer parameters
   may also need to be aligned, e.g., radio channel selections.  A
   single OLSRv2 topology may, of course, span different link layers (or
   the same link layer with different configuration settings such as
   cryptographic keys) when routers in the topology have OLSRv2
   interfaces towards these different link layers.

3.2.  Interface Addresses

   According to [RFC6130], and as used by [RFC7181], each interface of a
   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 router interfaces is
   not excluded, currently no address autoconfiguration protocols have
   been standardized (in the IETF) to accomplish this.  As a
   consequence, static configuration, or proprietary (as in: non-
   standardized) protocols ensure this.

   Note that this required pre-deployment of interface addresses does
   not include "external" IP addresses, i.e., IP addresses that are
   configured on local non-MANET interfaces or IP addresses from remote
   destinations reachable through this router (i.e., addresses for which
   this router serves as gateway).  These can be added or removed
   dynamically during runtime of OLSRv2.  Such local non-MANET interface
   addresses are managed by way of the Local Interface Set (as defined
   in [RFC6130]) and remote addresses by way of the Attached Network Set
   (as defined in [RFC7181]).

Clausen & Herberg        Expires January 5, 2015                [Page 4]

Internet-Draft       OLSRv2-Routed MANET Management            July 2014

3.3.  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
   [RFC7182] [RFC7183].

   The appropriate way of making such security material available is
   dependent on the deployment type.  For example, community networks
   (such as "Funkfeuer",, 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 (automatic/manual, dynamic/static, ... ) a key and other
   security material is made available, the security mechanisms of
   OLSRv2, as defined by [RFC7183], will be able to properly use it for
   generating and validating ICVs.

3.4.  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].

4.  How do we Manage OLSRv2-based MANETs?

   A deployed OLSRv2 network is, as previously discussed, operating
   autonomously, but occasionally with internal or external management
   operations being desirable, described in the following two sections.

Clausen & Herberg        Expires January 5, 2015                [Page 5]

Internet-Draft       OLSRv2-Routed MANET Management            July 2014

4.1.  Internal Management

   Internal management describes a local process running on a router
   that automatically (i.e., without external messaging or human
   interaction) modifies the configuration of OLSRv2 based on different
   environmental factors.  For example, the HELLO interval may be
   updated according to the rate of topology changes measured (or,
   inferred: after all, the 'M' in MANET is for "Mobility") locally: if
   the rate is high, then a more frequent HELLO update assures that
   routes are more accurate.  At a lower rate of topology changes,
   network capacity and energy capacity of the router may be conserved
   by increasing the HELLO interval.

   Depending on the use case, many different automatic configuration
   agents can be envisioned.  As parameters in NHDP and OLSRv2 are
   either only used locally or, in the case of HELLO_INTERVAL and
   REFRESH_INTERVAL, are selected locally and then included in the
   messages exchanged between adjacent routers in their HELLO messages,
   none of these automatic local configuration methods needs necessarily
   to be standardized: different routers doing different things will

4.2.  External Management

   For the deployments described by this document (but see Section 7),
   external management operations are undertaken by a central Network
   Management Station (NMS).

   The MIB modules developed for OLSRv2 [RFC7184] 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 all 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.4), nor distributing security material (see
   Section 3.3).

   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 "Writable MIB Module IESG Statement"
   recommends to use MIB modules for read-only operations only, and to
   use YANG/NETCONF for read-write operations instead.  While
   publication of the MIB modules developed for OLSRv2 and NHDP predates
   this statement, it may be possible to translate read-only objects

Clausen & Herberg        Expires January 5, 2015                [Page 6]

Internet-Draft       OLSRv2-Routed MANET Management            July 2014

   from the MIB modules into YANG modules using [RFC6643].  A complete
   YANG model representing similar objects as in the MIB modules could
   be future work.

   The predecessor of OLSRv2, OLSR [RFC3626] did not have an associated
   MIB module.  Many deployments of OLSR did not support network
   management operations per se (i.e., configuration-on-launch was the
   way in which routers in these deployments were managed).  Those
   implementations and deployments of OLSR that did support network
   management operations used a similar architecture to the one
   described in this document, but with "proprietary" protocols and APIs
   for parameters and router states, "proprietary" data-models, etc.  It
   can be speculated that the "proprietary" protocols used for
   communication between the NMS and the MIB modules on each router also
   for OLSRv2, in part, exist as inherited from the protocols used for
   OLSR.  Aligned with the recommendations from [RFC5706], management of
   OLSRv2 (in the form of the MIB modules for OLSRv2 and NHDP) has been
   developed alongside the standardization process of OLSRv2, rather
   than as an afterthought.

   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, following which the NMS disappears.  Part of the
   rationale for this is that in a MANET, network connectivity from
   every MANET router to an NMS cannot be guaranteed at all times due to
   the dynamicity of the network topology.

5.  What and Why do we Manage and Monitor?

   As indicated earlier, OLSRv2 and its constituent protocol NHDP, are
   reasonably robust with respect to parameter values: a deployment can
   operate with different parameters used in different 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
   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 routers arriving in the network, which will not "learn"
   the network topology before undue long delays).

Clausen & Herberg        Expires January 5, 2015                [Page 7]

Internet-Draft       OLSRv2-Routed MANET Management            July 2014

   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 routers are currently part of the network.  As
   a proactive protocol, OLSRv2 maintains, in each 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
   router.  A slightly less typical feature is to inquire all (or, at
   least, many) routers in a network, with the purpose of presenting a
   complete topology map.

   In addition to actively monitoring an OLSRv2 network, erroneous or
   unusual conditions on a router can be flagged to management, e.g.,
   detection of an unusually high number of 1-hop or 2-hop neighborhood
   changes in a short amount of time, indicating potential problems in
   that area of the network.  [RFC6779] and [RFC7184] facilitate
   proactively sending "notifications" (also known as traps) from the
   router towards an NMS.  The MIB modules defined in [RFC6779] and
   [RFC7184] allow for defining both the threshold and the time window
   of how many times this erroneous condition may occur in the time
   window before the notification is sent to the NMS.  Once the NMS
   receives a notification, a network operator may investigate if there
   is a problem that needs to be resolved, e.g., by changing parameters
   via the above-described external management.

6.  Typical Communication Patterns

   This section describes typical (management) communications patterns
   in an operating (post-startup) network.  One of the key
   characteristics of OLSRv2 is that is enables an efficient flooding
   mechanism (denoted "MPR Flooding").  For some management scenarios,
   this facilitates better performance by (scope-limited) flooding
   management requests to MANET routers, rather than sending multiple
   consecutive unicast messages.  While the MIB modules developed for
   OLSRv2 and NHDP do not support such broadcast operation (due to the
   nature of SNMP), some of the proprietary management tools mentioned
   in Section 4 take advantage of this for increased performance.

   The below list of such communication patterns is not claimed to be
   exhaustive, and depending on the deployment, different patterns may
   be used.  However, these patterns have been observed in many

Clausen & Herberg        Expires January 5, 2015                [Page 8]

Internet-Draft       OLSRv2-Routed MANET Management            July 2014

   deployments of OLSRv2 and its constituent parts, as well as of its
   predecessor OLSR.

   a) Inquire the state (complete topology graph, link states, and local
      links - even those not part of topology graph) of a router.  An
      NMS would typically initiate that request.  OLSRv2 contains a
      number of "Information Bases"; basically, tables with rows
      representing information about local interfaces, other routers in
      the MANET or the topology of the MANET as perceived by the MANET
      router.  These tables are also reflected as objects in the MIB
      modules and can be inquired via, e.g., GETBULK for getting
      multiple rows in a single request.  Depending on the number of
      MANET routers in the network as well as the density of the MANET,
      tables for one-hop and two-hop routers, as well as routers in
      further distance, these tables can contain a substantial amount of
      information, and so inquiring them will return multiple KB or more
      of data back to the NMS.  Given the dynamic topology and often
      bandwidth-constrained wireless links between MANET routers, this
      is not a very common operation in many deployments.  Moreover,
      this would typically only be required in debugging situations, as
      during regular operations, OLSRv2 updates the state automatically
      and reacts to changes (e.g., by triggering control message
      generation).  This type of operation can benefit from the
      optimized flooding mechanism, by requesting the state from
      multiple routers in a region of the MANET in a single request.

   b) Inquire the history/statistics of a router.  This request,
      initiated by an NMS, is typically a small inquiry, such as "how
      many local link changes have you seen within the past n minutes/
      seconds/hours".  This may be very rare, or it may be several times
      per minute per router for a while: if the NMS is trying to, e.g.,
      "tune" message intervals and timers, by sending this request to a
      group of topologically close routers - until, that is, the NMS
      decides that the topology has stabilized and will ease up.  Again,
      this feature of requesting performance related information is
      supported by the MIB modules for OLSRv2 and NHDP.  While SNMP does
      not support sending the inquiry via optimized flooding,
      proprietary protocols take advantage of the optimized flooding
      mechanism, to reduce the number of unicast requests.

   c) Change the configuration of a router.  Other than in the above
      case in b) (tuning), this really happens only when somehow a
      router gets a new uplink to an external network, and either a new
      gateway is added into the network, and/or a new prefix needs to be
      distributed to the routers.  The MIB modules for OLSRv2 and NHDP
      allow to set all configuration parameters of each router.
      Optimized flooding may significantly reduce the amount of unicast
      requests, but are not supported by SNMP.

Clausen & Herberg        Expires January 5, 2015                [Page 9]

Internet-Draft       OLSRv2-Routed MANET Management            July 2014

   d) Visualizing the network as a router sees it.  As in a MANET,
      routers may move and link quality may vary due to link layer
      characteristics, the network topology may change frequently.  In a
      naive way, this would essentially be the NMS setting up a
      connection to the router in question, and getting a copy of all
      routing protocol control messages to construct its own topology
      graph as would have done that router.  Typically, it consists of
      the router sending a notification to the NMS when a topological
      change happens, i.e., when either of its information bases change.
      Even better, it consists of these notifications being "filtered"
      to only send for those changes that actually impact the usable
      topology.  The latter case is supported by the MIB modules for
      OLSRv2 and NHDP in the form of notifications (also called "traps")
      that are send from the MANET router to the NMS.  While these
      notifications alone do not allow the NMS to visualize the
      topology, they may suffice to inform the NMS of an unusual change
      of the topology, and the NMS may inquire the current topology via
      the process described in a).

   e) Rekeying  There is currently no (standard) mechanism for automated
      key management.  One of the reasons for this may be that it is
      difficult to come up with a single such that will satisfy the
      requirements for all the different deployments.  However, in MANET
      deployments rekeying is something that can be observed, e.g., as
      part of the parameter configuration.  The particularity of this
      is, that it often is a "broadcast configuration operation" where
      new key material is supposed to be sent to everybody, and not just
      a single router, e.g., leveraging the optimized flooding mechanism
      of OLSRv2.

7.  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 2014.
   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 of such a "future management scenario", rather than
   managing and monitoring routers from a central NMS, a distributed,
   autonomous management system between multiple routers can be
   envisioned.  In particular, monitoring data that is used to debug
   network problems and to tweak inefficiencies could be distributed
   amongst a group of routers in the same network.  This would both
   address problems of single point of failure when using only a single

Clausen & Herberg        Expires January 5, 2015               [Page 10]

Internet-Draft       OLSRv2-Routed MANET Management            July 2014

   NMS, as well provide additional information about groups of multiple
   routers, rather than a single router.  An example use for such a
   distributed information flow would be to identify areas of a network
   wherein, e.g., due to different router densities, message sending
   interval parameters could be exchanged and optimal values negotiated
   between routers, so as to obtain locally optimized performance.

   While such a management model is highly interesting, it is also at
   present entirely fictional - at least outside the realm of research.
   It is included to, both, indicate directions being explored (but not
   exploited), and to insist that the intent of this document is not to
   prescribe how MANETs are to be managed, in the presence or in the
   future, but to describe the (known) state of how MANETs are managed,

8.  Acknowledgments

   The authors would like to gratefully acknowledge the following people
   for intense technical discussions, early reviews, and comments on the
   documents: Alan Cullen (BAE Systems), Christopher Dearlove (BAE
   Systems), Adrian Farrel (Juniper), David Harrington (Comcast), and
   Jurgen Schoenwalder (Jacobs University).

9.  Informative References

   [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
              Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
              March 2009.

   [RFC5706]  Harrington, D., "Guidelines for Considering Operations and
              Management of New Protocols and Protocol Extensions",
              RFC 5706, November 2009.

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

Clausen & Herberg        Expires January 5, 2015               [Page 11]

Internet-Draft       OLSRv2-Routed MANET Management            July 2014

              RFC 6130, April 2011.

   [RFC6643]  Schoenwaelder, J., "Translation of Structure of Management
              Information Version 2 (SMIv2) MIB Modules to YANG
              Modules", RFC 6643, July 2012.

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

   [RFC7181]  Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
              "The Optimized Link State Routing Protocol Version 2",
              RFC 7181, April 2014.

   [RFC7182]  Herberg, U., Clausen, T., and C. Dearlove, "Integrity
              Check Value and Timestamp TLV Definitions for Mobile Ad
              Hoc Networks (MANETs)", RFC 7182, April 2014.

   [RFC7183]  Herberg, U., Dearlove, C., and T. Clausen, "Integrity
              Protection for the Neighborhood Discovery Protocol (NHDP)
              and Optimized Link State Routing Protocol Version 2
              (OLSRv2)", RFC 7183, April 2014.

   [RFC7184]  Herberg, U., Cole, R., and T. Clausen, "Definition of
              Managed Objects for the Optimized Link State Routing
              Protocol Version 2", RFC 7184, April 2014.

Authors' Addresses

   Thomas Clausen
   LIX, Ecole Polytechnique
   91128 Palaiseau Cedex,

   Phone: +33-6-6058-9349

Clausen & Herberg        Expires January 5, 2015               [Page 12]

Internet-Draft       OLSRv2-Routed MANET Management            July 2014

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


Clausen & Herberg        Expires January 5, 2015               [Page 13]