Definition of Managed Objects for the
Neighborhood Discovery ProtocolUnited States of Americaulrich@herberg.namehttp://www.herberg.name/US Army CERDECSpace and Terrestrial Communications6010 Frankford RoadAberdeen Proving GroundMaryland21005United States of America+1 443 395-8744rgcole01@comcast.nethttp://www.cs.jhu.edu/~rgcole/DelvinEllicott CityMaryland21042United States of Americaian.chakeres@gmail.comhttp://www.ianchak.com/Ecole Polytechnique+33 6 6058 9349T.Clausen@computer.orghttp://www.ThomasClausen.org/
MANET & Routing Area
Network ManagementManagement Information baseMIBSMIv2RoutingNeighbor DiscoveryMANETThis document replaces RFC 6779; it contains revisions and
extensions to the original document. It defines a portion of
the Management Information Base (MIB) for use with network
management protocols in the Internet community. In particular,
it describes objects for configuring parameters of the
Neighborhood Discovery Protocol (NHDP) process on a router. The
extensions described in this document add objects and values to
support the NHDP optimization specified in RFC 7466. The MIB
module defined in this document, denoted NHDP-MIB, also reports
state, performance information, and notifications about
NHDP. This additional state and performance information is
useful to troubleshoot problems and performance issues during
neighbor discovery.
This document defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes objects for configuring parameters of the
Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
process on a router. The MIB module defined in this document, denoted NHDP-MIB,
also reports state, performance information, and notifications about NHDP.
This additional state and performance information is useful to troubleshoot
problems and performance issues during neighbor discovery.
This document obsoletes , replacing that document as the specification of the MIB module for . This revision to is necessitated by the update to specified in .
The MIB module for , specified in this document, captures the new information and states for each symmetric 2-hop neighbor, recorded in the Neighbor Information Base of a router and to be reflected in the appropriate tables, introduced by , specifically:
Addition of objects nhdpIib2HopSetN2Lost and nhdpIfPerfCounterDiscontinuityTime.Addition of extra value (notconsidered) to nhdp2HopNbrState.Revised full compliance state.
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to
section 7 of RFC 3410 .Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP). Objects
in the MIB are defined using the mechanisms defined in the Structure of
Management Information (SMI). This memo specifies a MIB module that is
compliant to the SMIv2, which is described in
STD 58, RFC 2578 ,
STD 58, RFC 2579 and
STD 58, RFC 2580 .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 . allows a router to discover and track topological information of routers up to two hops away by virtue of exchanging HELLO messages. This information is useful for routers running various routing and multicast flooding protocols developed within the IETF MANET Working Group.The following definitions apply throughout this document:Notification Objects - triggers and associated notification messages allowing for asynchronous tracking of predefined events on the managed router.Configuration Objects - switches, tables, and objects that are initialized to default settings or set through the management interface defined by this MIB module.State Objects - automatically generated values that define the current operating state of the NHDP instance in the router.Performance Objects - automatically generated values that help to assess the performance of the
NHDP instance on the router and the overall discovery performance
within the MANET.The same notations as defined in are used throughout this
document.This section presents the structure of the NHDP-MIB module.
The MIB module is arranged into the following structure:nhdpNotifications - objects defining NHDP-MIB notifications.nhdpObjects - defining objects within this MIB module.
The objects are arranged into the following groups:
Configuration Group - defining objects related to
the configuration of the NHDP instance on the router.State Group - defining objects that reflect the current
state of the NHDP instance running on the router.Performance Group - defining objects that are
useful to a management station when characterizing the
performance of NHDP on the router and in the MANET.nhdpConformance - defining the minimal and maximal conformance
requirements for implementations of this MIB module.This section describes the use of notifications and mechanisms to
enhance the ability to manage NHDP routing domains.Notifications can be emitted by a router running an instance of this
specification as a reaction to a specific event. This allows an
observer of these events to efficiently determine the source of problems or
significant changes of configuration or topology, instead of polling
a possibly large number of routers.
When an exception event occurs, the application notifies the local
agent, which sends a notification to the appropriate SNMP management
stations. The message includes the notification type and may include
a list of notification-specific variables. Section 7 contains the
notification definitions, which includes the variable lists. At
least one IP address of the router that originates the notification
is included in the variable list so that the source of the notification may be determined.To limit the frequency of notifications, the following additional mechanisms are suggested, similar to those in .The majority of critical events occur when NHDP is first enabled on a
router, at which time, the symmetric neighbors and 2-hop neighbors of
the router are discovered. During this initial period, a potential
flood of notifications is unnecessary since the events are expected.
To avoid unnecessary notifications, a router SHOULD NOT originate
expected notifications until a predefined and administratively configured time interval has elapsed. It is RECOMMENDED that this time interval be at least 3 times nhdpHelloInterval so that symmetric neighbors are discovered. The suppression window for notifications is started when the nhdpIfStatus
transitions from its default value of 'false(2)' to 'true(1)'.The mechanism for throttling the notifications is the same
as in (i.e., the number of transmitted notifications
per time is bounded).Appropriate values for the window time and upper bound are to be
administratively configured and depend on the deployment of the
MANET.
If NHDP is deployed on a lossy, wireless medium, sending too many
notifications in a short time interval may lead to collisions and dropped
packets. In particular, in dense deployments of routers running NHDP (i.e.,
where each router has many neighbors), a change of the local topology may
trigger many notifications at the same time.
recommends "7 traps with a window time of 10 seconds" as the upper
bound. As NHDP is expected to be deployed in more
lossy channels than OSPF, it is RECOMMENDED to choose a lower threshold for the
number of notifications per time than that. Specifically, it is RECOMMENDED that
the threshold value for the objects reflecting the change be set to a
value of '10' and the DEFAULT values for these objects within the
Notifications Group be set to this value. Further, a time window for the change
objects is defined within this MIB module. If the number
of occurrences exceeds the change threshold within the previous change window,
then it is RECOMMENDED that the notification be sent. Furthermore, it is RECOMMENDED that the
value for this window be set to at least 5 times the nhdpHelloInterval.The following objects are used to define the thresholds and time
windows for specific notifications defined in the NHDP-MIB module:
nhdpNbrStateChangeThreshold, nhdpNbrStateChangeWindow,
nhdp2HopNbrStateChangeThreshold, and nhdp2HopNbrStateChangeWindow.Similar to the mechanism in , only one notification is sent per event.The router running NHDP is configured with a set of controls. The
authoritative list of configuration controls within the NHDP-MIB module are
found within the MIB module itself. Generally, an attempt was made in
developing the NHDP-MIB module to support all configuration objects defined in
. For all of the configuration parameters, the same
constraints and default values of these parameters as defined in are followed. Refer to for
guidance on setting jitter-related parameters, e.g., nhdpMaxJitter.The State Group reports current state information of a router
running NHDP. The NHDP-MIB State Group tables were designed to contain the
complete set of state information defined within the information bases
specified in Sections 6, 7, and 8 of .Two constructs, i.e., TEXTUAL-CONVENTIONs, are defined to support
the tables in the State Group.
NHDP stores and indexes information through sets
of (dynamically defined) addresses, i.e., address sets.
Within SMIv2, it is not possible to
index tables with variably defined address sets. Hence, these TEXTUAL-CONVENTIONs are defined to provide a local mapping between
NHDP-managed address sets and SMIv2 table indexing.
These constructs are the NeighborIfIndex and NeighborRouterIndex.
These are locally (to the router) defined, unique identifiers
of virtual neighbors and neighbor interfaces.
Due to the nature of NHDP, the local router may have identified distinct address
sets but is not able to associate these as a single interface. Hence,
two or more NeighborIfIndexes pointing to multiple distinct address sets
may, in fact, be related to a common neighbor interface. This ambiguity
may also hold with respect to the assignment of the NeighborRouterIndex.
The local MIB agent is responsible for managing, aggregating, and
retiring the defined indexes and for updating MIB tables using these
indexes as the local router learns more about its neighbors'
topologies.
These constructs are used to define indexes to the appropriate State
Group tables and
to correlate table entries to address sets, virtual neighbor
interfaces, and
virtual neighbors
within the MANET.The Performance Group reports values relevant to system performance.
Unstable neighbors or 2-hop neighbors and frequent changes of sets
can have a negative influence on the performance of NHDP. This MIB
module defines several objects that can be polled in order to, e.g.,
calculate histories or monitor frequencies of changes. This may help
an observer determining unusual topology changes or
other changes that affect stability and reliability of the MANET.
The NHDP-MIB module contains a number of tables that record
data related to:
the local router,a local MANET interface on the router,other routers that are one hop removed from the local router,interfaces on other routers that are one hop removed from the
local router, andother routers that are two hops removed from the local router.The NHDP-MIB module's tables are indexed via the following constructs:
nhdpIfIndex - the IfIndex of the local router on which
NHDP is configured.nhdpDiscIfIndex - a locally managed index representing a known
interface on a neighboring router.nhdpDiscRouterIndex - a locally managed index representing an
ID of a known neighboring router.These tables and their indexing are:
nhdpInterfaceTable - describes the
configuration of the interfaces of this router.
This table has INDEX { nhdpIfIndex }.nhdpLibLocalIfSetTable - records all
network addresses that are defined as local
interface network addresses on this router.
This table has INDEX { nhdpLibLocalIfSetIndex }.nhdpLibRemovedIfAddrSetTable - records
network addresses that were recently used as local
interface network addresses on this router but
have been removed.
This table has INDEX { nhdpLibRemovedIfAddrSetIndex }.nhdpInterfaceStateTable - records state information
related to specific interfaces of this router.
This table has INDEX { nhdpIfIndex }.nhdpDiscIfSetTable - includes the nhdpDiscRouterIndex of
the discovered router, the nhdpDiscIfIndex
of the discovered interface, and the
current set of addresses associated
with this neighbor interface.
This table has INDEX { nhdpDiscIfSetIndex }.nhdpIibLinkSetTable - for each local interface,
records all links
belonging to other routers that are, or recently
were, 1-hop neighbors to this router.
This table has INDEX { nhdpIfIndex, nhdpDiscIfIndex }.nhdpIib2HopSetTable - for each local interface,
records network
addresses (one at a time)
of symmetric 2-hop neighbors and
the symmetric links to symmetric 1-hop neighbors
of this router
through which these symmetric 2-hop neighbors
can be reached.
This table has INDEX { nhdpIfIndex, nhdpDiscIfIndex,
nhdpIib2HopSetIpAddressType, nhdpIib2HopSetIpAddress }.nhdpNibNeighborSetTable - records all
network addresses of each 1-hop
neighbor to this router.
This table has INDEX { nhdpDiscRouterIndex }.nhdpNibLostNeighborSetTable - records network
addresses of other routers that were recently
symmetric 1-hop neighbors to this router
but are now advertised as lost.
This table has INDEX { nhdpDiscRouterIndex }.nhdpInterfacePerfTable - records performance objects that are
measured for each local NHDP interface on this
router.
This table has INDEX { nhdpIfIndex }.nhdpDiscIfSetPerfTable - records performance objects that are
measured for each discovered interface of a neighbor of this
router.
This table has INDEX { nhdpDiscIfIndex }.nhdpDiscNeighborSetPerfTable - records performance objects that are
measured for discovered neighbors of this router.
This table has INDEX { nhdpDiscRouterIndex }.nhdpIib2HopSetPerfTable - records performance objects that are
measured for discovered 2-hop neighbors of this router.
This table has INDEX { nhdpDiscRouterIndex }.This section specifies the relationship of the MIB module contained
in this document to other standards, particularly to standards containing other
MIB modules.
MIB modules and specific definitions imported from MIB modules
that SHOULD be implemented in conjunction with the MIB module
contained within this document are identified in this section.The System Group in the SNMPv2-MIB module is defined as being mandatory for all systems, and the objects apply to the entity as a whole. The System Group provides identification of the management entity and certain other system-wide data. The NHDP-MIB module does not duplicate those objects. allows routing protocols to rely on the neighborhood information that is discovered by means of HELLO message exchange. In order to allow for troubleshooting, fault isolation, and management of such routing protocols through a routing protocol MIB module, it may be desired to align the State Group tables of the NHDP-MIB module and the routing protocol MIB module. This is accomplished through the definition of two TEXTUAL-CONVENTIONs in the NHDP-MIB module: the NeighborIfIndex and the NeighborRouterIndex. These object types are used to develop indexes into common NHDP-MIB module and routing protocol State Group tables. These objects are locally significant but should be locally common to the NHDP-MIB module and the routing protocol MIB module implemented on a common networked router. This will allow for improved cross-referencing of information across the two MIB modules.The nhdpInterfaceTable in this MIB module describes the
configuration of the interfaces of this router
that are intended to use MANET control protocols.
As such, this table 'sparse augments' the ifTable
specifically when NHDP is to be configured to
operate over this interface. The interface is
identified by the ifIndex from the Interfaces
Group defined in the Interfaces Group MIB module .A conceptual row in the nhdpInterfaceTable exists if and only if
either the row has been administratively created or there is an
interface on the managed device that supports and runs NHDP. This
implies that for each entry in the nhdpInterfaceTable, there is a
corresponding entry in the Interface Table where nhdpIfIndex and
ifIndex are equal. If that corresponding entry in the Interface Table
is deleted, then the entry in nhdpInterfaceTable is automatically
deleted, NHDP is disabled on this interface, and all configuration and
state information related to this interface is to be removed from
memory.
The following NHDP-MIB module IMPORTS objects from
SNMPv2-SMI , SNMPv2-TC ,
SNMPv2-CONF , IF-MIB , SNMP-FRAMEWORK-MIB , INET-ADDRESS-MIB , and FLOAT-TC-MIB .This section contains the MIB module defined by the specification.This MIB module defines objects for the configuration, monitoring, and
notification of the Mobile Ad Hoc Network (MANET)
Neighborhood Discovery Protocol (NHDP).
NHDP allows routers to acquire topological information up to two hops away
by virtue of exchanging HELLO messages. The information acquired by NHDP
may be used by routing protocols. The neighborhood information, exchanged
between routers using NHDP, serves these routing protocols as a baseline
for calculating paths to all destinations in the MANET, relay set selection
for network-wide transmissions, etc.There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such objects
may be considered sensitive or vulnerable in some network environments.
The support for SET operations in a non-secure environment without
proper protection opens devices to attack.
These are the tables and objects and their sensitivity/vulnerability:nhdpIfStatus - This writable object turns on or off the NHDP
process for the specified interface. If disabled, higher-level
protocol functions, e.g., routing, would fail, causing
network-wide disruptions.nhdpHelloInterval, nhdpHelloMinInterval, and nhdpRefreshInterval
- These writable objects control the rate at which HELLO messages
are sent on an interface. If set at too high a rate,
this could represent a form of denial-of-service (DoS) attack by overloading interface
resources.nhdpHystAcceptQuality, nhdpHystRejectQuality, nhdpInitialQuality, and
nhdpInitialPending - These writable objects affect the perceived
quality of the NHDP links and hence the overall stability of the network.
If improperly set, these settings could result in network-wide disruptions.nhdpInterfaceTable - This table contains writable objects that affect
the overall performance and stability of the NHDP process.
Failure of the NHDP process would result in network-wide failure.
Particularly sensitive objects from this table are discussed
in the previous list items. This is the only table in the
NHDP-MIB module with writable objects.Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. It is thus important to control
even GET and/or NOTIFY access to these objects and possibly to even
encrypt the values of these objects when sending them over the network
via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
nhdpDiscIfSetTable - The object contains information on discovered neighbors,
specifically their IP address in the nhdpDiscIfSetIpAddr object.
This information provides an adversary broad information on the
members of the MANET, located within this single table.
This information can be used to expedite attacks on the other members
of the MANET without having to go through a laborious discovery
process on their own. This object is the index into the table
and has a MAX-ACCESS of 'not&nbhy;accessible'. However, this information
can be exposed using SNMP operations.MANET technology is often deployed to support communications of
emergency services or military tactical applications. In these
applications, it is imperative to maintain the proper operation of the
communications network and to protect sensitive information related
to its operation. Therefore, it is RECOMMENDED to provide support
for the Transport Security Model (TSM)
in combination with TLS/DTLS .SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPsec),
there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.Implementations SHOULD provide the security features described by the
SNMPv3 framework (see ), and implementations
claiming compliance to the SNMPv3 standard MUST include full support for
authentication and privacy via the User-based Security Model (USM)
with the AES cipher algorithm .
Implementations MAY also provide support for the Transport Security Model (TSM)
in combination with a secure transport such as
SSH or
TLS/DTLS .Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable
cryptographic security. It is then a customer/operator responsibility to
ensure that the SNMP entity giving access to an instance of this MIB
module is properly configured to give access to the objects only to
those principals (users) that have legitimate rights to indeed GET or
SET (change/create/delete) them.This document describes objects for configuring parameters of the
Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
process on a router.
This MIB module, denoted NHDP-MIB,
also reports state, performance information, and notifications.
This section provides some examples of how this MIB module can be used in
MANET network deployments.
NHDP is designed to allow routers to automatically discover and track
routers one hop remote (denoted "neighbors") and routers two hops remote
(denoted "2-hop neighbors"). This information is used by other MANET
protocols
in operation on the router to perform
routing, multicast forwarding, and other functions with ad hoc and
mobile networks.
In the following, three example scenarios are listed where this MIB module is
useful:
For a Parking Lot Initial Configuration Situation - It is common for
the vehicles comprising the
MANET being forward deployed at a remote location, e.g., the site of
a natural disaster, to be off-loaded in a parking lot where an initial configuration
of the networking devices is performed. The configuration is loaded into the
devices from a fixed location Network Operations Center (NOC) at the parking lot, and the
vehicles are stationary at the parking lot while the configuration changes are made.
Standards-based
methods for configuration management from the co-located NOC
are necessary for this deployment option.
For Mobile Vehicles with Low-Bandwidth Satellite Link to a Fixed
NOC - Here,
the vehicles carrying the MANET routers carry multiple wireless
interfaces, one of
which is a relatively low-bandwidth, on-the-move satellite
connection that interconnects
a fix NOC to the nodes of the MANET.
Standards-based
methods for monitoring and fault management from the fixed NOC
are necessary for this deployment option. For Fixed NOC and Mobile Local Manager in Larger Vehicles - for larger
vehicles, a hierarchical network management arrangement is useful. Centralized
network management is performed from a fixed NOC while local management is performed
locally from within the vehicles.
Standards-based
methods for configuration, monitoring, and fault management
are necessary for this deployment option. The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER value recorded in the SMI Numbers registry:The authors wish to thank Benoit Claise, Elwyn Davies, Justin Dean,
Adrian Farrel, Joel Halpern, Michael MacFaden, Al Morton, and Thomas Nadeau for their detailed
reviews and insightful comments regarding RFC 6779 and this document.This MIB document uses the
template authored by D. Harrington, which is
based on contributions from the MIB Doctors,
especially Juergen Schoenwaelder, Dave Perkins, C.M. Heard, and Randy
Presuhn.