Definition of Managed Objects for the
Neighborhood Discovery ProtocolLIX, Ecole PolytechniquePalaiseau Cedex91128Franceulrich@herberg.namehttp://www.herberg.name/US Army CERDEC6010 Frankford Road, Bldg 6010Aberdeen Proving GroundMaryland21005USA+1 443 395 8744robert.g.cole@us.army.milhttp://www.cs.jhu.edu/~rgcole/CenGen9250 Bendix Road NorthColumbiaMaryland560093USAian.chakeres@gmail.comhttp://www.ianchak.com/
MANET & Routing Area
Internet Engineering Task ForceNetwork ManagementManagement Information baseMIBSMIv2RoutingNeighbor DiscoveryMANETThis memo 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 MIB defined in this memo, denoted NHDP-MIB,
also reports state, performance information and notifications.
This additional state and performance information is useful to
troubleshoot problems and performance issues during neighbor discovery.This memo 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
process on a router. The MIB defined in this memo, denoted NHDP-MIB,
also reports state, performance information and notifications.
This additional state and performance information is useful to troubleshoot
problems and performance issues during neighbor discovery.
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to
Section 7 of .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
,
and
.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 in a Mobile Ad Hoc Network (MANET) 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 pre-defined events on the managed router.Configuration Objects - switches, tables, objects which are initialized to default settings or set through the management interface defined by this MIB.State Objects - automatically generated values which define the current operating state of the NHDP protocol process in the router.Performance Objects - automatically generated values which help an administrator or automated tool to assess the performance of the NHDP protocol process on the router and the overall discovery performance within the MANET.This section presents the structure of the NHDP-MIB module.
The MIB is arranged into the following structure:nhdpNotifications - objects defining NHDP-MIB notifications.nhdpObjects - defining objects within this MIB.
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 which reflect the current
state of the NHDP instance running on the router.Performance Group - defining objects which 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.This section describes the use of notifications, and mechanisms to enhance the ability to manage NHDP networks.Notifications can be emitted by an NHDP router as a reaction to a specific event. This allows a network manager to efficiently determine the source of problems or significant changes of configuration or topology, instead of polling a possibly large number of NHDP 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. contains the notification definitions, which includes the variable lists. At least one IP address of the NHDP router that originates the notification is included in the variable list so that the network manager may determine the source of the notification.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 enabled on a router, at which time the symmetric neighbors and two-hop neighbors of the NHDP 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 certain time interval has elapsed, which is to be predefined by the network manager.The mechanism for throttling the notifications is the same as in (i.e. the amount of transmitted notifications per time is bounded).Appropriate values for the window time and upper bound are to be selected by the network manager and depend on the deployment of the MANET.Similar to the according mechanism in , only one notification is sent per event.The NHDP router is configured with a set of controls. The authoritative list of configuration controls within the NHDP-MIB 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 . The NHDP-MIB State Group tables were designed to contain the complete set of state information defined within the information bases specified in Section 6, Section 7 and Section 8 of .Two constructs, i.e., TEXTUAL CONVENTIONs, are defined to support
of the tables in the State Group.
The NHDP protocol 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 NHDP router) defined, unique identifiers
of virtual neighbors and neighbor interfaces.
Due to the nature of the
NHDP protocol, 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 in updating MIB tables using these
indexes as the local router learns more about its neighbors'
topology.
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.
This section lists objects for NHDP performance monitoring,
some of which are explicitly defined in the NHDP-MIB and others which
can be estimated through a combination of base objects from this MIB.
Throughout this section, those objects will be pointed out that are
intended as base objects which are explicitly defined within this MIB
and those objects which can be estimated.Unstable neighbors or 2-hop neighbors and frequent changes
of sets can have a negative influence on the performance of NHDP.
The following objects allow management applications to acquire
information related to the stability and performance of NHDP:The following objects return statistics related to HELLO messages:
Total number of sent HELLO messages on an interface
This is a Base Object.Object name: nhdpIfHelloMessageXmitsObject type: Counter32Total number of received HELLO messages on an interface
This is a Base Object.Object name: nhdpIfHelloMessageRecvdObject type: Counter32Total number of sent periodic HELLO messages on an interface
This is a Base Object.Object name: nhdpIfHelloMessagePeriodicXmitsObject type: Counter32Total number of sent triggered HELLO messages on an interface
This is a Base Object.Object name: nhdpIfHelloMessageTriggeredXmitsObject type: Counter32Acquire history of HELLO message scheduling instances for a given time duration on an interface
It is desirable to develop the history of the exact timestamps of each HELLO message that has been sent as well as the type of the message (triggered or periodical). The list of events starts at the given point of time t0 and ends at the given time t1.This is a Derived Object estimated from the NHDP-MIB.
It is derived from, e.g., the nhdpIfHelloMessagePeriodicXmits Base
Object from the NHDP-MIB.Histogram of the intervals between HELLO messages on an interface
It is desirable to track the values (in a 2-dimensional array) that represent a histogram of intervals between HELLO messages. The histogram would display the distribution of intervals between two consecutive HELLOs using a given bin size. It includes all HELLOs that have been sent after the given time t0 and before the given time t1.This is a Derived Object to be estimated from objects within the NHDP-MIB.
It can be estimated from, e.g., the nhdpIfHelloMessagePeriodicXmits
Base Object from the NHDP-MIB. The network management
application could convert this information into the desired histogram.Changes of the frequency of the message scheduling on an interface
This object will divide the given time interval from t0 to t1 into a given number of equal parts. It then creates a histogram for each part and calculates the distances (e.g. using the Bhattacharyya distance) between each two adjacent histograms in time. A higher value between two histograms means more difference between the histograms. For instance, this is representative of an event that suddenly sends many triggered HELLO messages, whereas before there have been only very few such triggered messages.This is a Derived Object estimated from objects within the NHDP-MIB,
as previously discussed,
albeit this is a bit more complex with respect to the management application.Average number of sent HELLO messages per second between
the given time t0 and t1 on an interface
This is a Derived Object estimated from, e.g., the nhdpIfHelloMessageXmits
Base Object.Average number of received HELLO messages per second
on an interface between the given time t0 and t1
This is a Derived Object estimated from the NHDP-MIB.
See the previous discussion.Total accumulated size in octets of sent HELLO messages on an interface
This is a Base Object.Object name: nhdpIfHelloMessageXmitAccumulatedSizeObject type: Counter64Total accumulated size in octets of received HELLO messages on an interface
This is a Base Object.Object name: nhdpIfHelloMessageRecvdAccumulatedSizeObject type: Counter64Average size in octets of sent HELLO messages
between the given time t0 and t1 on an interface
This is a Derived Object estimated from,
e.g., the nhdpIfHelloMessageRecvdAccumulatedSize
Base Object from this NHDP-MIB.Average size in octets of received HELLO messages
between the given time t0 and t1 on an interface
This is a Derived Object estimated from the NHDP-MIB.
See previous discussion.Total accumulated number of advertised symmetric neighbors in
HELLOs on that interface.
This is a Base Object.Object name: nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCountObject type: Counter32Total accumulated number of advertised heard neighbors in HELLOs on that interface
This is a Base Object.Object name: nhdpIfHelloMessageXmitAccumulatedHeardNeighborCountObject type: Counter32Total accumulated number of advertised lost neighbors in HELLOs on that interface
This is a Base Object.Object name: nhdpIfHelloMessageXmitAccumulatedLostNeighborCountObject type: Counter32Number of expected packets from a given neighbor based on the packet
sequence number on an interface
This is a Base Object.Object name: nhdpDiscIfExpectedPacketsObject type: Counter32Success rate of received packets (number of received packets divided by
number of expected packets based on the packet sequence number)
This is a Derived Object to be pulled from this NHDP-MIB.
It is derived from, e.g., the nhdpDiscIfRecvdPackets and
the nhdpDiscIfExpectedPackets Base Objects defined in this MIB.
This metric is then computed by the network management application.The following objects inspect the frequency of all Neighbor Set changes:
Number of Neighbor Set changes
This object counts each Neighbor Set change.
A change occurs whenever a new Neighbor Tuple has been added,
a Neighbor Tuple has been removed or any entry of a Neighbor Tuple
has been modified.This is a Base Object.Object name: nhdpNibNeighborSetChangesObject type: Counter32Acquire history of Neighbor Set changes
This object returns the history of the exact
timestamps of each time the Neighbor Set has been changed.This is a Derived Object estimated from the NHDP-MIB.
It is derived from the previously
discussed Base Object.Histogram of the intervals between Neighbor Set changes
Returns the values (in a 2-dimensional array)
that represent a histogram of intervals between
Neighbor Set changes.
This is a Derived Object estimated from
the previously discussed Base Object.Changes of the frequency of the Neighbor Set changes
This object will divide the given time interval
from t0 to t1 into a given number of equal parts.
It then creates a histogram for each part and calculates
the distances (e.g. using the Bhattacharyya distance) between
each two adjacent histograms in time.
A higher value between two histograms means more
difference between the histograms.This is a Derived Object estimated from the previously
discussed Base Object.The next objects examine the uptime of a given neighbor (as listed in the Neighbor Set):
Number of changes of a Neighbor Tuple
Returns the number of changes to the given Neighbor Tuple.This is a Base Object.Object name: nhdpDiscNeighborNibNeighborSetChangesObject type: Counter32Neighbor uptime
Returns the number of hundredths of a second since the Neighbor Tuple
corresponding to the given neighbor exists.This is a Base Object.Object name: nhdpDiscNeighborNibNeighborSetUpTimeObject type: TimeTicksAcquire history of change of the 'nbrup' status of a given neighbor
This object returns the history of the exact timestamps of
each time the neighbor (as listed in the Neighbor Set)
becomes 'nbrup' or 'nbrdown'.
A neighbor is said to become 'nbrup' if a new Neighbor Tuple
is created that corresponds to the given neighbor.
It becomes 'nbrdown' if such a Neighbor Tuple has been deleted.
The existence of a Lost Neighbor Tuple for that previous
neighbor does not mean that the neighbor is still 'nbrup'.This is a Derived Object estimated
from, e.g., the nhdpDiscNeighborNibNeighborSetChanges
Base Object defined in this MIB.Histogram of the intervals between a change of the 'nbrup' status of
a given neighbor
Returns the values that represent a histogram of intervals
between a change of the 'nbrup' status of a given neighbor.
The histogram includes all changes that have been made after
the given time t0 and before the given time t1.This is a Derived Object estimated
from, e.g. the nhdpDiscNeighborNibNeighborSetChanges
Base Object defined
in this MIB. This object sits in the
nhdpDiscNeighborSetPerfTable which is indexed by
the nhdpDiscRouterIndex.The following objects examine the stability of a neighbor.
A neighbor is said to be unstable if it 'flaps' frequently between several links.
It is said to be stable if the set of Link Tuples that
correspond to the given neighbor is stationary.
Count the changes of the interface(s) over which a
given neighbor (as listed in the Neighbor Set) can be reached
This object counts
each time the neighbor changes the interface(s) over which it
is reachable.
A change in the set of Link Tuples corresponding to the
appropriate Neighbor Tuple is registered,
i.e. a corresponding Link Tuple is added or removed from
the set of all corresponding Link Tuples.This is a Base Object.Object name: nhdpDiscNeighborNibNeighborSetReachableLinkChangesObject type: Counter32Acquire history of changes of the interface(s) over which a given neighbor can be reached
This object returns the history of the exact timestamps of
each time the neighbor changes the interface(s) over which it
is reachable.
That means that there is a change in the set of corresponding Link Tuples of for that Neighbor Tuple, i.e. a corresponding Link Tuple is added or removed from the set of all corresponding Link Tuples.This is a Derived Object estimated
from, e.g., the
nhdpDiscNeighborNibNeighborSetReachableLinkChanges
Base Object.Histogram of the intervals between a change of the interface(s) over
which a given neighbor is reachable
Returns the values that represent a histogram of intervals
between a change of the interface over which a given neighbor is
reachable after the given time t0 and before the given
time t1.This is a Derived Object estimated
from the previously discussed
Base Object, nhdpDiscNeighborNibNeighborSetChanges counter.The following objects inspect the stability of a given 2-hop neighbor:
Count the changes of the union of all N2_neighbor_iface_addr_list of
2-hop Tuples with an N2_2hop_addr equal to one of the given 2-hop neighbor's addresses
This object returns the count of the
times the 2-hop neighbor changes the neighbor(s) over which it is reachable.This is a Base Object.Object name: nhdpIib2HopSetPerfChangesObject type: Counter32Acquire history of changes of the N2_neighbor_iface_addr_list of
a given 2-hop neighbor
This object returns the history of the exact timestamps of
each time the 2-hop neighbor changes the neighbor(s) over which it is reachable.This is a Derived Object estimated
from the previously
discussed Base Object, nhdpIib2HopSetPerfChanges counter.Histogram of the intervals between a change of a 2-hop
neighbor's N2_neighbor_iface_addr_list
Returns the values that represent a histogram of intervals
between a change of the neighbor(s) over which
the 2-hop neighbor is reachable
after the given time t0 and before the given time t1.This is a Derived Object estimated
from the previously
discussed Base Object, nhdpIib2HopSetPerfChanges counter.The next objects examine the uptime of a given 2-hop neighbor:
2-hop Neighbor uptime
Returns the number of hundredths of a second since the
any 2-Hop Tuple with a N2_2hop_addr of the given 2-hop neighbor IP
address was registered.This is a Base Object.Object name: nhdpIib2HopSetPerfUpTimeObject type: TimeTicksAcquire history of change of 'nbrup' status of a given 2-hop neighbor
This object returns the history of the exact timestamps of each
time the 2-hop neighbor becomes 'nbrup' or 'nbrdown'.
A 2-hop neighbor becomes 'nbrup' when the first 2-hop
Tuple with N2_2hop_addr of the given 2-hop neighbor is created.
It becomes 'nbrdown' when the last 2-hop Tuple with N2_2hop_addr
of the given 2-hop neighbor has been deleted.This is a Derived Object estimated
from the previously
discussed Base Object, nhdpIib2HopSetPerfChanges counter.Histogram of the intervals between a change of the 'nbrup' status
of a given 2-hop neighbor
Returns the values that represent a histogram of intervals between
a change of the 'nbrup' status of a given 2-hop neighbor.
The histogram includes all changes that have been made after the
given time t0 and before the given time t1.This is a Derived Object estimated
from the previously discussed
Base Object, nhdpIib2HopSetPerfChanges counter.This section specifies the
relationship of the MIB modules contained in this document to
other standards, particularly to standards containing other MIB
modules. Definitions imported from other MIB modules and other 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 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 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, it may be desired to align the State Group tables of the NHDP-MIB and the routing protocol MIB. This is accomplished through the definition of two TEXTUAL-CONVENTIONS in the NHDP-MIB: the NeighborIfIndex and the NeighborRouterIndex. These object types are used to develop indexes into common NHDP-MIB and routing protocol State Group tables. These objects are locally significant but should be locally common to the NHDP-MIB and the routing protocol MIB implemented on a common networked router. This will allow for improved cross referencing of information across the two MIBs.The following NHDP-MIB module IMPORTS objects from
SNMPv2-SMI , SNMPv2-TC ,
SNMPv2-CONF , IF-MIB ,
INET-ADDRESS-MIB , and FLOAT-TC-MIB .This section contains the MIB module defined by the specification.This MIB defines objects for the configuration, monitoring and
notification of the Neighborhood Discovery Protocol .
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 can have a negative effect on network operations.
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 a wireless interface. If set at too high a rate,
this could represent a form of DOS attack by overloading interface
resources.nhdpHystAcceptQuality, nhdpHystRejectQuality, nhdpInitialQuality,
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 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 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 use 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-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, when implementing these capabilities,
the full use of SNMPv3 cryptographic mechanisms for authentication
and privacy is RECOMMENDED.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.It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see ,
section 8), including full support for the SNMPv3 cryptographic
mechanisms (for authentication and privacy).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.Editor's Note (to be removed prior to publication): the IANA is
requested to assign a value for "XXXX" under the 'mib-2' subtree and
to record the assignment in the SMI Numbers registry. When the
assignment has been made, the RFC Editor is asked to replace "XXXX"
(here and in the MIB module) with the assigned value and to remove this note.
Note well: prior to official assignment by the IANA, a draft document
MUST use placeholders (such as "XXXX" above) rather than actual
numbers. See RFC4181 Section 4.5 for an example of how this is done
in a draft MIB module.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.The authors wish to thank Thomas Clausen and Justin Dean for their detailed reviews and insightful comments to this document.Key words for use in RFCs to Indicate Requirement LevelsHarvard UniversityStructure of Management Information Version 2 (SMIv2)Textual Conventions for SMIv2Cisco Systems, Inc.SNMPinfoTU BraunschweigConformance Statements for SMIv2Cisco Systems, Inc.SNMPinfoTU BraunschweigThe Interfaces Group MIBManagement Information Base (MIB) for the Simple Network Management Protocol (SNMP)Textual Conventions for Internet Network AddressesMobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)Textual Conventions for the Representation of Floating-Point NumbersIntroduction and Applicability Statements for Internet-Standard Management FrameworkOSPF Version 2 Management Information BaseJitter Considerations in Mobile Ad Hoc Networks (MANETs)