summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7939.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7939.txt')
-rw-r--r--doc/rfc/rfc7939.txt4035
1 files changed, 4035 insertions, 0 deletions
diff --git a/doc/rfc/rfc7939.txt b/doc/rfc/rfc7939.txt
new file mode 100644
index 0000000..6581344
--- /dev/null
+++ b/doc/rfc/rfc7939.txt
@@ -0,0 +1,4035 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) U. Herberg
+Request for Comments: 7939
+Obsoletes: 6779 R. Cole
+Category: Standards Track US Army CERDEC
+ISSN: 2070-1721 I. Chakeres
+ Delvin
+ T. Clausen
+ Ecole Polytechnique
+ August 2016
+
+
+ Definition of Managed Objects for the Neighborhood Discovery Protocol
+
+Abstract
+
+ This 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.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7939.
+
+
+
+
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 1]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+Copyright Notice
+
+ Copyright (c) 2016 IETF Trust and the persons identified as the
+ document authors. All rights reserved. This document is subject to
+ BCP 78 and the IETF Trust's Legal Provisions Relating to IETF
+ Documents (http://trustee.ietf.org/license-info) in effect on the
+ date of publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Differences from RFC 6779 . . . . . . . . . . . . . . . . 3
+ 2. The Internet-Standard Management Framework . . . . . . . . . 3
+ 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 4.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 4.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 4
+ 5.1. Notifications . . . . . . . . . . . . . . . . . . . . . . 5
+ 5.1.1. Introduction . . . . . . . . . . . . . . . . . . . . 5
+ 5.1.2. Notification Generation . . . . . . . . . . . . . . . 5
+ 5.1.3. Limiting Frequency of Notifications . . . . . . . . . 5
+ 5.2. The Configuration Group . . . . . . . . . . . . . . . . . 7
+ 5.3. The State Group . . . . . . . . . . . . . . . . . . . . . 7
+ 5.4. The Performance Group . . . . . . . . . . . . . . . . . . 8
+ 5.5. Tables and Indexing . . . . . . . . . . . . . . . . . . . 8
+ 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 10
+ 6.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . . 10
+ 6.2. Relationship to Routing Protocol MIB Modules Relying on
+ the NHDP-MIB Module . . . . . . . . . . . . . . . . . . . 10
+ 6.3. Relationship to the If-MIB . . . . . . . . . . . . . . . 10
+ 6.4. MIB Modules Required for IMPORTS . . . . . . . . . . . . 11
+ 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 66
+ 9. Applicability Statement . . . . . . . . . . . . . . . . . . . 68
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 69
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . 69
+ 11.2. Informative References . . . . . . . . . . . . . . . . . 71
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 72
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72
+
+
+
+
+
+Herberg, et al. Standards Track [Page 2]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+1. Introduction
+
+ 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) [RFC6130] 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.
+
+1.1. Differences from RFC 6779
+
+ This document obsoletes [RFC6779], replacing that document as the
+ specification of the MIB module for [RFC6130]. This revision to
+ [RFC6779] is necessitated by the update to [RFC6130] specified in
+ [RFC7466].
+
+ The MIB module for [RFC6130], 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 [RFC7466],
+ specifically:
+
+ o Addition of objects nhdpIib2HopSetN2Lost and
+ nhdpIfPerfCounterDiscontinuityTime.
+
+ o Addition of extra value (notconsidered) to nhdp2HopNbrState.
+
+ o Revised full compliance state.
+
+2. The Internet-Standard Management Framework
+
+ For a detailed overview of the documents that describe the current
+ Internet-Standard Management Framework, please refer to section 7 of
+ RFC 3410 [RFC3410].
+
+ 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 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
+ [RFC2580].
+
+
+
+
+Herberg, et al. Standards Track [Page 3]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+3. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+4. Overview
+
+ [RFC6130] 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.
+
+4.1. Terms
+
+ The following definitions apply throughout this document:
+
+ o Notification Objects - triggers and associated notification
+ messages allowing for asynchronous tracking of predefined events
+ on the managed router.
+
+ o Configuration Objects - switches, tables, and objects that are
+ initialized to default settings or set through the management
+ interface defined by this MIB module.
+
+ o State Objects - automatically generated values that define the
+ current operating state of the NHDP instance in the router.
+
+ o 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.
+
+4.2. Notation
+
+ The same notations as defined in [RFC6130] are used throughout this
+ document.
+
+5. Structure of the MIB Module
+
+ This section presents the structure of the NHDP-MIB module. The MIB
+ module is arranged into the following structure:
+
+ o nhdpNotifications - objects defining NHDP-MIB notifications.
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 4]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ o 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.
+
+ o nhdpConformance - defining the minimal and maximal conformance
+ requirements for implementations of this MIB module.
+
+5.1. Notifications
+
+ This section describes the use of notifications and mechanisms to
+ enhance the ability to manage NHDP routing domains.
+
+5.1.1. Introduction
+
+ 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.
+
+5.1.2. Notification Generation
+
+ 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.
+
+5.1.3. Limiting Frequency of Notifications
+
+ To limit the frequency of notifications, the following additional
+ mechanisms are suggested, similar to those in [RFC4750].
+
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 5]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+5.1.3.1. Ignoring Initial Activity
+
+ 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)'.
+
+5.1.3.2. Throttling Notifications
+
+ The mechanism for throttling the notifications is the same as in
+ [RFC4750] (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. [RFC4750] 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.
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 6]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+5.1.3.3. One Notification per Event
+
+ Similar to the mechanism in [RFC4750], only one notification is sent
+ per event.
+
+5.2. The Configuration Group
+
+ 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 [RFC6130]. For all of the
+ configuration parameters, the same constraints and default values of
+ these parameters as defined in [RFC6130] are followed. Refer to
+ [RFC5148] for guidance on setting jitter-related parameters, e.g.,
+ nhdpMaxJitter.
+
+5.3. The State Group
+
+ 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 [RFC6130].
+
+ 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.
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 7]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+5.4. The Performance Group
+
+ 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.
+
+5.5. Tables and Indexing
+
+ The NHDP-MIB module contains a number of tables that record data
+ related to:
+
+ o the local router,
+
+ o a local MANET interface on the router,
+
+ o other routers that are one hop removed from the local router,
+
+ o interfaces on other routers that are one hop removed from the
+ local router, and
+
+ o other routers that are two hops removed from the local router.
+
+ The NHDP-MIB module's tables are indexed via the following
+ constructs:
+
+ o nhdpIfIndex - the IfIndex of the local router on which NHDP is
+ configured.
+
+ o nhdpDiscIfIndex - a locally managed index representing a known
+ interface on a neighboring router.
+
+ o nhdpDiscRouterIndex - a locally managed index representing an ID
+ of a known neighboring router.
+
+ These tables and their indexing are:
+
+ o nhdpInterfaceTable - describes the configuration of the interfaces
+ of this router. This table has INDEX { nhdpIfIndex }.
+
+ o nhdpLibLocalIfSetTable - records all network addresses that are
+ defined as local interface network addresses on this router. This
+ table has INDEX { nhdpLibLocalIfSetIndex }.
+
+
+
+
+
+Herberg, et al. Standards Track [Page 8]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ o 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 }.
+
+ o nhdpInterfaceStateTable - records state information related to
+ specific interfaces of this router. This table has INDEX
+ { nhdpIfIndex }.
+
+ o 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 }.
+
+ o 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 }.
+
+ o 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 }.
+
+ o nhdpNibNeighborSetTable - records all network addresses of each
+ 1-hop neighbor to this router. This table has INDEX
+ { nhdpDiscRouterIndex }.
+
+ o 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 }.
+
+ o nhdpInterfacePerfTable - records performance objects that are
+ measured for each local NHDP interface on this router. This table
+ has INDEX { nhdpIfIndex }.
+
+ o nhdpDiscIfSetPerfTable - records performance objects that are
+ measured for each discovered interface of a neighbor of this
+ router. This table has INDEX { nhdpDiscIfIndex }.
+
+ o nhdpDiscNeighborSetPerfTable - records performance objects that
+ are measured for discovered neighbors of this router. This table
+ has INDEX { nhdpDiscRouterIndex }.
+
+
+
+
+
+Herberg, et al. Standards Track [Page 9]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ o nhdpIib2HopSetPerfTable - records performance objects that are
+ measured for discovered 2-hop neighbors of this router. This
+ table has INDEX { nhdpDiscRouterIndex }.
+
+6. Relationship to Other MIB Modules
+
+ 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.
+
+6.1. Relationship to the SNMPv2-MIB
+
+ The System Group in the SNMPv2-MIB module [RFC3418] 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.
+
+6.2. Relationship to Routing Protocol MIB Modules Relying on the NHDP-
+ MIB Module
+
+ [RFC6130] 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.
+
+6.3. Relationship to the If-MIB
+
+ 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 [RFC2863] 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 [RFC2863].
+
+
+
+Herberg, et al. Standards Track [Page 10]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ 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.
+
+6.4. MIB Modules Required for IMPORTS
+
+ The following NHDP-MIB module IMPORTS objects from SNMPv2-SMI
+ [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB
+ [RFC2863], SNMP-FRAMEWORK-MIB [RFC3411], INET-ADDRESS-MIB [RFC4001],
+ and FLOAT-TC-MIB [RFC6340].
+
+7. Definitions
+
+ This section contains the MIB module defined by the specification.
+
+NHDP-MIB DEFINITIONS ::= BEGIN
+
+-- This MIB module defines objects for the management of
+-- NHDP (RFC 6130) - Mobile Ad Hoc Network (MANET)
+-- Neighborhood Discovery Protocol (NHDP),
+-- Clausen, T., Dearlove, C., and J. Dean, January 2011.
+
+IMPORTS
+
+ MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
+ Counter32, Counter64, Integer32, Unsigned32, mib-2,
+ TimeTicks
+ FROM SNMPv2-SMI -- RFC 2578
+
+ TEXTUAL-CONVENTION, TruthValue, TimeStamp,
+ RowStatus
+ FROM SNMPv2-TC -- RFC 2579
+
+ MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
+ FROM SNMPv2-CONF -- STD 58
+
+ SnmpAdminString
+ FROM SNMP-FRAMEWORK-MIB -- RFC 3411
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 11]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ InetAddressType, InetAddress,
+ InetAddressPrefixLength
+ FROM INET-ADDRESS-MIB -- RFC 4001
+
+ InterfaceIndex
+ FROM IF-MIB -- RFC 2863
+
+ Float32TC
+ FROM FLOAT-TC-MIB -- RFC 6340
+ ;
+
+nhdpMIB MODULE-IDENTITY
+ LAST-UPDATED "201607120000Z" -- 12 July 2016
+ ORGANIZATION "IETF MANET Working Group"
+ CONTACT-INFO
+ "WG Email: manet@ietf.org
+ WG web page: https://datatracker.ietf.org/wg/manet
+
+ Editors: Ulrich Herberg
+ United States of America
+ ulrich@herberg.name
+ http://www.herberg.name/
+
+ Robert G. Cole
+ US Army CERDEC
+ Space and Terrestrial Communications
+ 6010 Frankford Street
+ Aberdeen Proving Ground, Maryland 21005
+ United States of America
+ +1 443 395-8744
+ robert.g.cole@us.army.mil
+ http://www.cs.jhu.edu/~rgcole/
+
+ Ian D Chakeres
+ Delvin
+ Ellicott City, Maryland 21042
+ United States of America
+ ian.chakeres@gmail.com
+ http://www.ianchak.com/
+
+ Thomas Heide Clausen
+ Ecole Polytechnique
+ LIX
+ 91128 Palaiseau Cedex
+ France
+ Email: T.Clausen@computer.org
+ URI: http://www.thomasclausen.org/"
+
+
+
+
+Herberg, et al. Standards Track [Page 12]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ DESCRIPTION
+ "This NHDP-MIB module is applicable to routers
+ implementing the Mobile Ad Hoc Network (MANET)
+ Neighborhood Discovery Protocol (NHDP)
+ defined in RFC 6130.
+
+ Copyright (c) 2016 IETF Trust and the persons identified
+ as authors of the code. All rights reserved.
+
+ Redistribution and use in source and binary forms, with
+ or without modification, is permitted pursuant to, and
+ subject to the license terms contained in, the Simplified
+ BSD License set forth in Section 4.c of the IETF Trust's
+ Legal Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info)."
+
+ -- revision
+ REVISION "201607120000Z" -- 12 July 2016
+ DESCRIPTION
+ "Updated version of this MIB module,
+ including updates made to NHDP by
+ RFC 7466, published as RFC 7939."
+ REVISION "201210221000Z" -- 22 October 2012
+ DESCRIPTION
+ "Initial version of this MIB module,
+ published as RFC 6779."
+ ::= { mib-2 213 }
+
+--
+-- Top-Level Components of this MIB Module
+--
+nhdpNotifications OBJECT IDENTIFIER ::= { nhdpMIB 0 }
+nhdpObjects OBJECT IDENTIFIER ::= { nhdpMIB 1 }
+nhdpConformance OBJECT IDENTIFIER ::= { nhdpMIB 2 }
+
+--
+-- TEXTUAL-CONVENTIONs
+--
+ -- Two new TEXTUAL-CONVENTIONs have been defined in
+ -- this MIB module for indexing into the following
+ -- tables and indexing into other tables in other MIB modules.
+ -- This was necessary because NHDP manages and
+ -- indexes based upon dynamic address tuples, i.e.,
+ -- address sets, while SMI requires statically
+ -- defined indexes for accessing its table rows.
+ -- The NeighborIfIndex defines a unique (to the local router)
+ -- index referencing a discovered virtual interface on another
+ -- neighbor within the MANET. The NeighborRouterIndex defines a
+
+
+
+Herberg, et al. Standards Track [Page 13]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ -- unique (to the local router) index referencing a discovered
+ -- virtual neighbor within the MANET.
+ --
+ -- Due to the nature of NHDP,
+ -- different indexes may be related to common neighbor
+ -- interfaces or common neighbor routers, but the information
+ -- obtained through NHDP has not allowed the local router
+ -- to relate these virtual objects (i.e., interfaces or routers)
+ -- at this point in time. As more topology information
+ -- is gathered by the local router, it may associate
+ -- virtual interfaces or routers and collapse these
+ -- indexes appropriately.
+
+ -- Multiple addresses can be associated with a
+ -- given NeighborIfIndex. Each NeighborIfIndex is
+ -- associated with a NeighborRouterIndex. Throughout
+ -- the nhdpStateObjGroup, the
+ -- NeighborIfIndex and the NeighborRouterIndex are used
+ -- to define the set of IP Addresses related to a virtual
+ -- neighbor interface or virtual neighbor under discussion.
+
+
+NeighborIfIndex ::= TEXTUAL-CONVENTION
+ DISPLAY-HINT "d"
+ STATUS current
+ DESCRIPTION
+ "An arbitrary, locally unique identifier associated with a
+ virtual interface of a discovered NHDP neighbor.
+ Due to the nature of NHDP, the local router
+ may not know if two distinct addresses belong to the
+ same interface of a neighbor or to two different
+ interfaces. As the local router gains more
+ knowledge of its neighbors, its local view may change, and
+ this table will be updated to reflect the local router's
+ current understanding, associating address sets to neighbor
+ interfaces. The local router identifies a virtual neighbor
+ interface through the receipt of address lists advertised
+ through an NHDP HELLO message.
+
+ All objects of type NeighborIfIndex are assigned by the agent
+ out of a common number space.
+
+ The value for each discovered virtual neighbor
+ interface may not remain constant from
+ one re-initialization of the entity's network management
+ agent to the next re-initialization. If the
+ local router gains information associating two virtual
+ interfaces on a neighbor as a common interface,
+
+
+
+Herberg, et al. Standards Track [Page 14]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ then the agent MUST aggregate the two address sets to
+ a single index chosen from the set of aggregated indexes,
+ and it MUST update all tables in this
+ MIB module that are indexed by indexes
+ of type NeighborIfIndex. It MAY then reuse freed
+ index values following the next agent restart.
+
+ The specific value is meaningful only within a given SNMP
+ entity."
+ SYNTAX Unsigned32 (1..2147483647)
+
+NeighborRouterIndex ::= TEXTUAL-CONVENTION
+ DISPLAY-HINT "d"
+ STATUS current
+ DESCRIPTION
+ "An arbitrary, locally unique identifier associated with a
+ virtual discovered neighbor (one or two hop). Due to the
+ nature of NHDP, the local router may identify
+ multiple virtual neighbors that, in fact, are one and
+ the same. Neighbors that are two hops away with more than
+ one advertised address will exhibit this behavior. As the
+ local router's knowledge of its neighbors' topology
+ increases, the local router will be able to associate
+ multiple virtual neighbor indexes into a single virtual
+ neighbor index chosen from the set of aggregated indexes;
+ it MUST update all tables in this MIB module indexed by these
+ indexes, and it MAY reuse the freed indexes following the
+ next agent re-initialization.
+
+ All objects of type NeighborRouterIndex are assigned by
+ the agent out of a common number space.
+
+ The NeighborRouterIndex defines a discovered NHDP peer
+ virtual neighbor of the local router.
+ The value for each discovered virtual neighbor index MUST
+ remain constant at least from one re-initialization of
+ the entity's network management agent to the next
+ re-initialization, except if an application is deleted
+ and re-created.
+
+ The specific value is meaningful only within a given SNMP
+ entity. A NeighborRouterIndex value MUST NOT be reused
+ until the next agent restart."
+ SYNTAX Unsigned32 (1..2147483647)
+
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 15]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+--
+-- nhdpObjects
+--
+
+-- 1) Configuration Objects Group
+-- 2) State Objects Group
+-- 3) Performance Objects Group
+--
+-- nhdpConfigurationObjGrp
+--
+
+-- Contains the NHDP objects that configure specific options
+-- that determine the overall performance and operation of
+-- NHDP.
+
+
+nhdpConfigurationObjGrp OBJECT IDENTIFIER ::= { nhdpObjects 1 }
+
+ nhdpInterfaceTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF NhdpInterfaceEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The nhdpInterfaceTable 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 this table exists if and only
+ if the row has been administratively created
+ or there is an interface on the managed device
+ that supports and runs NHDP.
+
+ A row can be administratively created by setting
+ rowStatus to 'createAndGo' or 'createAndWait'.
+ During the row creation, objects having associated
+ DEFVAL clauses are automatically defined by
+ the agent if not explicitly administratively defined.
+
+ 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
+ the nhdpInterfaceTable is automatically deleted,
+
+
+
+Herberg, et al. Standards Track [Page 16]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ NHDP is disabled on this interface, and all configuration
+ and state information related to this interface is to be
+ removed from memory."
+ REFERENCE
+ "RFC 2863 - The Interfaces Group MIB, McCloghrie,
+ K., and F. Kastenholtz, June 2000"
+ ::= { nhdpConfigurationObjGrp 1 }
+
+ nhdpInterfaceEntry OBJECT-TYPE
+ SYNTAX NhdpInterfaceEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The nhdpInterfaceEntry describes one NHDP
+ local interface configuration as indexed by
+ its ifIndex as defined in the Standard MIB II
+ Interface Table (RFC 2863).
+
+ The objects in this table are persistent, and when
+ written, the device SHOULD save the change to
+ nonvolatile storage. For further information
+ on the storage behavior for these objects, refer
+ to the description for the nhdpIfRowStatus
+ object."
+ INDEX { nhdpIfIndex }
+ ::= { nhdpInterfaceTable 1 }
+
+ NhdpInterfaceEntry ::=
+ SEQUENCE {
+ nhdpIfIndex
+ InterfaceIndex,
+ nhdpIfName
+ SnmpAdminString,
+ nhdpIfStatus
+ TruthValue,
+ nhdpHelloInterval
+ Unsigned32,
+ nhdpHelloMinInterval
+ Unsigned32,
+ nhdpRefreshInterval
+ Unsigned32,
+ nhdpLHoldTime
+ Unsigned32,
+ nhdpHHoldTime
+ Unsigned32,
+ nhdpHystAcceptQuality
+ Float32TC,
+
+
+
+
+Herberg, et al. Standards Track [Page 17]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ nhdpHystRejectQuality
+ Float32TC,
+ nhdpInitialQuality
+ Float32TC,
+ nhdpInitialPending
+ TruthValue,
+ nhdpHpMaxJitter
+ Unsigned32,
+ nhdpHtMaxJitter
+ Unsigned32,
+ nhdpIfRowStatus
+ RowStatus
+ }
+
+ nhdpIfIndex OBJECT-TYPE
+ SYNTAX InterfaceIndex
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This value MUST correspond to an ifIndex referring
+ to a valid entry in the Interfaces Table."
+ REFERENCE
+ "RFC 2863 - The Interfaces Group MIB, McCloghrie, K.,
+ and F. Kastenholtz, June 2000"
+ ::= { nhdpInterfaceEntry 1 }
+
+ nhdpIfName OBJECT-TYPE
+ SYNTAX SnmpAdminString
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The textual name of the interface. The value of this
+ object SHOULD be the name of the interface as assigned by
+ the local device. This can be a text-name, such as 'le0'
+ or a simple port number, such as '1',
+ depending on the interface-naming syntax of the device.
+
+ If there is no local name or this object is otherwise not
+ applicable, then this object contains a zero-length string."
+ ::= { nhdpInterfaceEntry 2 }
+
+ nhdpIfStatus OBJECT-TYPE
+ SYNTAX TruthValue
+ MAX-ACCESS read-create
+ STATUS current
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 18]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ DESCRIPTION
+ "nhdpIfStatus indicates whether this interface is
+ currently running NHDP. A value of 'true(1)' indicates
+ that NHDP is running on this interface.
+ A value of 'false(2)' indicates that NHDP is not
+ currently running on this interface. This corresponds
+ to the I_manet parameter in the Local Interface Set
+ of NHDP."
+ DEFVAL { false }
+ ::= { nhdpInterfaceEntry 3 }
+
+ --
+ -- Interface Parameters - Message Intervals
+ --
+
+
+ nhdpHelloInterval OBJECT-TYPE
+ SYNTAX Unsigned32
+ UNITS "milliseconds"
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "nhdpHelloInterval corresponds to
+ HELLO_INTERVAL of NHDP and represents the
+ maximum time between the transmission of two
+ successive HELLO messages on this MANET interface.
+
+ Guidance for setting this object may be found
+ in Section 5 of the NHDP specification (RFC 6130),
+ which indicates that:
+ o nhdpHelloInterval > 0
+ o nhdpHelloInterval >= nhdpHelloMinInterval"
+ REFERENCE
+ "Section 5 on Protocol Parameters and
+ Constraints of RFC 6130 - Mobile Ad Hoc
+ Network (MANET) Neighborhood Discovery
+ Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ DEFVAL { 2000 }
+ ::= { nhdpInterfaceEntry 4 }
+
+ nhdpHelloMinInterval OBJECT-TYPE
+ SYNTAX Unsigned32
+ UNITS "milliseconds"
+ MAX-ACCESS read-create
+ STATUS current
+
+
+
+
+
+Herberg, et al. Standards Track [Page 19]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ DESCRIPTION
+ "nhdpHelloMinInterval corresponds to
+ HELLO_MIN_INTERVAL of NHDP and represents
+ the minimum interval between transmission
+ of two successive HELLO messages on this
+ MANET interface.
+
+ Guidance for setting this object may be found
+ in Section 5 of the NHDP specification (RFC 6130),
+ which indicates that:
+ o nhdpHelloMinInterval <= nhdpHelloInterval"
+ REFERENCE
+ "Section 5 on Protocol Parameters and
+ Constraints of RFC 6130 - Mobile Ad Hoc Network
+ (MANET) Neighborhood Discovery Protocol (NHDP),
+ Clausen, T., Dearlove, C., and J. Dean, April 2011"
+ DEFVAL { 500 }
+ ::= { nhdpInterfaceEntry 5 }
+
+ nhdpRefreshInterval OBJECT-TYPE
+ SYNTAX Unsigned32
+ UNITS "milliseconds"
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "nhdpRefreshInterval corresponds to
+ REFRESH_INTERVAL of NHDP and represents the
+ maximum interval between advertisements of
+ each 1-hop neighbor network address and its
+ status. Each advertisement is in a HELLO
+ message on this MANET interface.
+
+ Guidance for setting this object may be found
+ in Section 5 of the NHDP specification (RFC 6130),
+ which indicates that:
+ o nhdpRefreshInterval >= nhdpHelloInterval"
+ REFERENCE
+ "Section 5 on Protocol Parameters and
+ Constraints of RFC 6130 - Mobile Ad Hoc Network
+ (MANET) Neighborhood Discovery Protocol (NHDP),
+ Clausen, T., Dearlove, C., and J. Dean, April 2011"
+ DEFVAL { 2000 }
+ ::= { nhdpInterfaceEntry 6 }
+
+ --
+ -- Interface Parameters - Information Validity times
+ --
+
+
+
+
+Herberg, et al. Standards Track [Page 20]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ nhdpLHoldTime OBJECT-TYPE
+ SYNTAX Unsigned32
+ UNITS "milliseconds"
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "nhdpLHoldTime corresponds to
+ L_HOLD_TIME of NHDP and represents the period
+ of advertisement, on this MANET interface, of
+ former 1-hop neighbor network addresses as lost
+ in HELLO messages, allowing recipients of these
+ HELLO messages to accelerate removal of this
+ information from their Link Sets.
+
+ Guidance for setting this object may be found
+ in Section 5 of the NHDP specification (RFC 6130),
+ which indicates that it should be assigned a
+ value significantly greater than the refresh
+ interval held by nhdpRefreshInterval."
+ REFERENCE
+ "Section 5 on Protocol Parameters and
+ Constraints of RFC 6130 - Mobile Ad Hoc Network
+ (MANET) Neighborhood Discovery Protocol (NHDP),
+ Clausen, T., Dearlove, C., and J. Dean, April 2011"
+ DEFVAL { 6000 }
+ ::= { nhdpInterfaceEntry 7 }
+
+ nhdpHHoldTime OBJECT-TYPE
+ SYNTAX Unsigned32
+ UNITS "milliseconds"
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "nhdpHHoldTime corresponds to
+ H_HOLD_TIME of NHDP and is used as the value
+ in the VALIDITY_TIME Message TLV included in all
+ HELLO messages on this MANET interface. It is then
+ used by each router receiving such a HELLO message
+ to indicate the validity of the information taken
+ from that HELLO message and recorded in the receiving
+ router's Information Bases.
+
+ Guidance for setting this object may be found
+ in Section 5 of the NHDP specification (RFC 6130),
+ which indicates that it should be assigned a
+ value significantly greater than the refresh interval
+ held by nhdpRefreshInterval and must be representable
+ as described in RFC 5497."
+
+
+
+Herberg, et al. Standards Track [Page 21]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ REFERENCE
+ "RFC 5497 - Representing Multi-Value Time in Mobile Ad
+ Hoc Networks (MANETs), Clausen, T., and C. Dearlove,
+ March 2009.
+
+ Section 5 on Protocol Parameters and
+ Constraints of RFC 6130 - Mobile Ad Hoc Network
+ (MANET) Neighborhood Discovery Protocol (NHDP),
+ Clausen, T., Dearlove, C., and J. Dean, April 2011"
+ DEFVAL { 6000 }
+ ::= { nhdpInterfaceEntry 8 }
+
+ --
+ -- Interface Parameters - Link Quality
+ --
+
+ nhdpHystAcceptQuality OBJECT-TYPE
+ SYNTAX Float32TC
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "nhdpHystAcceptQuality corresponds to
+ HYST_ACCEPT of NHDP and represents the link
+ quality threshold at or above which a link becomes
+ usable, if it was not already so.
+
+ Guidance for setting this object may be found
+ in Section 5 of the NHDP specification (RFC 6130),
+ which indicates that:
+ o 0 <= nhdpHystRejectQuality
+ <= nhdpHystAcceptQuality <= 1.0
+
+ The default value for this object is 1.0. According to
+ RFC 6340:
+ Since these textual conventions are defined in terms
+ of the OCTET STRING type, the SMI's mechanisms for
+ formally setting range constraints are not available.
+ MIB designers using these textual conventions will need
+ to use DESCRIPTION clauses to spell out any applicable
+ range constraints beyond those implied by the underlying
+ IEEE types.
+ Therefore, this object does not have a DEFVAL clause."
+ REFERENCE
+ "Section 5 on Protocol Parameters and
+ Constraints of RFC 6130 - Mobile Ad Hoc Network
+ (MANET) Neighborhood Discovery Protocol (NHDP),
+ Clausen, T., Dearlove, C., and J. Dean, April 2011"
+-- DEFVAL { 1.0 } see DESCRIPTION
+
+
+
+Herberg, et al. Standards Track [Page 22]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ ::= { nhdpInterfaceEntry 9 }
+
+ nhdpHystRejectQuality OBJECT-TYPE
+ SYNTAX Float32TC
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "nhdpHystRejectQuality corresponds to
+ HYST_REJECT of NHDP and represents the
+ link quality threshold below which a
+ link becomes unusable, if it was not
+ already so.
+
+ Guidance for setting this object may be found
+ in Section 5 of the NHDP specification (RFC 6130),
+ which indicates that:
+ o 0 <= nhdpHystRejectQuality
+ <= nhdpHystAcceptQuality <= 1.0
+
+ The default value for this object is 0.0. According to
+ RFC 6340:
+ Since these textual conventions are defined in terms
+ of the OCTET STRING type, the SMI's mechanisms for
+ formally setting range constraints are not available.
+ MIB designers using these textual conventions will need
+ to use DESCRIPTION clauses to spell out any applicable
+ range constraints beyond those implied by the underlying
+ IEEE types.
+ Therefore, this object does not have a DEFVAL clause."
+ REFERENCE
+ "Section 5 on Protocol Parameters and
+ Constraints of RFC 6130 - Mobile Ad Hoc Network
+ (MANET) Neighborhood Discovery Protocol (NHDP),
+ Clausen, T., Dearlove, C., and J. Dean, April 2011"
+-- DEFVAL { 0.0 } see DESCRIPTION
+ ::= { nhdpInterfaceEntry 10 }
+
+ nhdpInitialQuality OBJECT-TYPE
+ SYNTAX Float32TC
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "nhdpInitialQuality corresponds to
+ INITIAL_QUALITY of NHDP and represents the
+ initial quality of a newly identified link.
+
+ Guidance for setting this object may be found
+ in Section 5 of the NHDP specification (RFC 6130),
+
+
+
+Herberg, et al. Standards Track [Page 23]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ which indicates that:
+ o 0 <= nhdpInitialQuality <= 1.0
+
+ The default value for this object is 1.0. According to
+ RFC 6340:
+ Since these textual conventions are defined in terms
+ of the OCTET STRING type, the SMI's mechanisms for
+ formally setting range constraints are not available.
+ MIB designers using these textual conventions will need
+ to use DESCRIPTION clauses to spell out any applicable
+ range constraints beyond those implied by the underlying
+ IEEE types.
+ Therefore, this object does not have a DEFVAL clause."
+ REFERENCE
+ "Section 5 on Protocol Parameters and
+ Constraints of RFC 6130 - Mobile Ad Hoc Network
+ (MANET) Neighborhood Discovery Protocol (NHDP),
+ Clausen, T., Dearlove, C., and J. Dean, April 2011"
+-- DEFVAL { 1.0 } see DESCRIPTION
+ ::= { nhdpInterfaceEntry 11 }
+
+ nhdpInitialPending OBJECT-TYPE
+ SYNTAX TruthValue
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "nhdpInitialPending corresponds to
+ INITIAL_PENDING of NHDP. If the value of this object
+ is 'true(1)', then a newly identified link is considered
+ pending and is not usable until the link quality
+ has reached or exceeded the nhdpHystAcceptQuality
+ threshold.
+
+ Guidance for setting this object may be found
+ in Section 5 of the NHDP specification (RFC 6130),
+ which indicates that:
+ o If nhdpInitialQuality >= nhdpHystAcceptQuality,
+ then nhdpInitialPending := false(2).
+ o If nhdpInitialQuality < nhdpHystRejectQuality,
+ then nhdpInitialPending := true(1)."
+ REFERENCE
+ "Section 5 on Protocol Parameters and
+ Constraints of RFC 6130 - Mobile Ad Hoc Network
+ (MANET) Neighborhood Discovery Protocol (NHDP),
+ Clausen, T., Dearlove, C., and J. Dean, April 2011"
+ DEFVAL { false }
+ ::= { nhdpInterfaceEntry 12 }
+
+
+
+
+Herberg, et al. Standards Track [Page 24]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ --
+ -- Interface Parameters - Jitter
+ --
+ nhdpHpMaxJitter OBJECT-TYPE
+ SYNTAX Unsigned32
+ UNITS "milliseconds"
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "nhdpHpMaxJitter corresponds to
+ HP_MAXJITTER of NHDP and represents the
+ value of MAXJITTER used in RFC 5148 for
+ periodically generated HELLO messages on
+ this MANET interface.
+
+ Guidance for setting this object may be found
+ in Section 5 of RFC 5148, which indicates that:
+ o nhdpHpMaxJitter <= nhdpHelloInterval / 2
+ o nhdpHpMaxJitter should not be greater
+ than nhdpHelloInterval / 4
+ o If nhdpMinHelloInterval > 0, then
+ nhdpHpMaxJitter <= nhdpHelloMinInterval; and
+ nhdpHpMaxJitter should not be greater than
+ nhdpHelloMinInterval / 2"
+ REFERENCE
+ "Section 5 of RFC 5148 - Jitter Considerations in
+ Mobile Ad Hoc Networks (MANETs),
+ Clausen, T., Dearlove, C., and B. Adamson, February 2008"
+ DEFVAL { 500 }
+ ::= { nhdpInterfaceEntry 13 }
+
+
+ nhdpHtMaxJitter OBJECT-TYPE
+ SYNTAX Unsigned32
+ UNITS "milliseconds"
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "nhdpHtMaxJitter corresponds to
+ HT_MAXJITTER of NHDP and represents the
+ value of MAXJITTER used in RFC 5148 for
+ externally triggered HELLO messages on this
+ MANET interface.
+
+ Guidance for setting this object may be found
+ in Section 5 of RFC 5148, which indicates that:
+ o nhdpHtMaxJitter <= nhdpHelloInterval / 2
+
+
+
+
+Herberg, et al. Standards Track [Page 25]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ o nhdpHtMaxJitter should not be greater
+ than nhdpHelloInterval / 4
+ o If nhdpMinHelloInterval > 0, then
+ nhdpHtMaxJitter <= nhdpHelloMinInterval; and
+ nhdpHtMaxJitter should not be greater than
+ nhdpHelloMinInterval / 2"
+ REFERENCE
+ "Section 5 of RFC 5148 - Jitter Considerations in
+ Mobile Ad Hoc Networks (MANETs),
+ Clausen, T., Dearlove, C., and B. Adamson, February 2008"
+ DEFVAL { 500 }
+ ::= { nhdpInterfaceEntry 14 }
+
+ nhdpIfRowStatus OBJECT-TYPE
+ SYNTAX RowStatus
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This object permits management of the table
+ by facilitating actions such as row creation,
+ construction, and destruction. The value of
+ this object has no effect on whether other
+ objects in this conceptual row can be
+ modified.
+
+ An entry may not exist in the 'active(1)' state unless all
+ objects in the entry have a defined appropriate value. For
+ objects with DEFVAL clauses, the management station
+ does not need to specify the value of this object in order
+ for the row to transit to the 'active(1)' state; the default
+ value for this object is used. For objects that do not
+ have DEFVAL clauses, the value of this object prior
+ to this row transitioning to the 'active(1)' state MUST be
+ administratively specified.
+
+
+ When this object transitions to 'active(1)', all objects
+ in this row SHOULD be written to nonvolatile (stable)
+ storage. Read-create objects in this row MAY be modified.
+ When an object in a row with nhdpIfRowStatus of 'active(1)'
+ is changed, then the updated value MUST be reflected in NHDP,
+ and this new object value MUST be written to nonvolatile
+ storage.
+
+ If the value of this object is not equal to 'active(1)',
+ all associated entries in the nhdpLibLocalIfSetTable,
+ nhdpInterfaceStateTable, nhdpIibLinkSetTable, and
+ nhdpInterfacePerfTable MUST be deleted."
+
+
+
+Herberg, et al. Standards Track [Page 26]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ DEFVAL { active }
+ ::= { nhdpInterfaceEntry 15 }
+
+
+ --
+ -- Router Parameters - Information Validity Time
+ --
+ nhdpNHoldTime OBJECT-TYPE
+ SYNTAX Unsigned32
+ UNITS "milliseconds"
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "nhdpNHoldTime corresponds to
+ N_HOLD_TIME of NHDP and is used as the period
+ during which former 1-hop neighbor network
+ addresses are advertised as lost in HELLO
+ messages, allowing recipients of these HELLO
+ messages to accelerate removal of this information
+ from their 2-Hop Sets.
+
+ This object is persistent, and when written,
+ the entity SHOULD save the change to
+ nonvolatile storage."
+ REFERENCE
+ "Section 5 on Protocol Parameters and
+ Constraints of RFC 6130 - Mobile Ad Hoc Network
+ (MANET) Neighborhood Discovery Protocol (NHDP),
+ Clausen, T., Dearlove, C., and J. Dean, April 2011"
+ DEFVAL { 6000 }
+ ::= { nhdpConfigurationObjGrp 2 }
+
+ nhdpIHoldTime OBJECT-TYPE
+ SYNTAX Unsigned32
+ UNITS "milliseconds"
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "nhdpIHoldTime corresponds to
+ I_HOLD_TIME of NHDP and represents the period
+ for which a recently used local interface network
+ address is recorded.
+
+
+
+
+
+Herberg, et al. Standards Track [Page 27]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ This object is persistent, and when written,
+ the entity SHOULD save the change to
+ nonvolatile storage."
+ REFERENCE
+ "Section 5 on Protocol Parameters and
+ Constraints of RFC 6130 - Mobile Ad Hoc Network
+ (MANET) Neighborhood Discovery Protocol (NHDP),
+ Clausen, T., Dearlove, C., and J. Dean, April 2011"
+ DEFVAL { 6000 }
+ ::= { nhdpConfigurationObjGrp 3 }
+
+
+ -- A router's Local Information Base (LIB)
+ --
+ -- Local Interface Set Table
+ --
+
+ nhdpLibLocalIfSetTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF NhdpLibLocalIfSetEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A router's Local Interface Set records all
+ network addresses that are defined as local
+ MANET interface network addresses.
+ As such, this table 'sparse augments' the
+ nhdpInterfaceTable when network addresses are
+ being defined for the interfaces existing within
+ the nhdpInterfaceTable. The local interface
+ is defined by the nhdpIfIndex.
+
+ The Local Interface Set consists of Local Interface
+ Address Tuples per MANET interface and their prefix
+ lengths (in order to determine the network addresses
+ related to the interface).
+
+ A conceptual row in this table exists if and only
+ if one has been administratively created. This can be done
+ by setting rowStatus to 'createAndGo' or 'createAndWait'.
+
+ Further guidance on the addition or removal of
+ local addresses and network addresses is found
+ in Section 9 of RFC 6130."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpConfigurationObjGrp 4 }
+
+
+
+Herberg, et al. Standards Track [Page 28]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ nhdpLibLocalIfSetEntry OBJECT-TYPE
+ SYNTAX NhdpLibLocalIfSetEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A router's Local Interface Set consists
+ of Local Interface Tuples for each network
+ interface.
+
+ The objects in this table are persistent, and when
+ written, the device SHOULD save the change to
+ nonvolatile storage. For further information
+ on the storage behavior for these objects, refer
+ to the description for the nhdpLibLocalIfSetRowStatus
+ object."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ INDEX { nhdpLibLocalIfSetIndex }
+ ::= { nhdpLibLocalIfSetTable 1 }
+
+ NhdpLibLocalIfSetEntry ::=
+ SEQUENCE {
+ nhdpLibLocalIfSetIndex
+ Integer32,
+ nhdpLibLocalIfSetIfIndex
+ InterfaceIndex,
+ nhdpLibLocalIfSetIpAddrType
+ InetAddressType,
+ nhdpLibLocalIfSetIpAddr
+ InetAddress,
+ nhdpLibLocalIfSetIpAddrPrefixLen
+ InetAddressPrefixLength,
+ nhdpLibLocalIfSetRowStatus
+ RowStatus
+ }
+
+ nhdpLibLocalIfSetIndex OBJECT-TYPE
+ SYNTAX Integer32 (0..65535)
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The index for this table. Necessary
+ because multiple addresses may be associated
+ with a given nhdpIfIndex."
+
+
+
+
+
+Herberg, et al. Standards Track [Page 29]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpLibLocalIfSetEntry 1 }
+
+ nhdpLibLocalIfSetIfIndex OBJECT-TYPE
+ SYNTAX InterfaceIndex
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Specifies the local nhdpIfIndex for which this
+ IP address was added."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpLibLocalIfSetEntry 2 }
+
+ nhdpLibLocalIfSetIpAddrType OBJECT-TYPE
+ SYNTAX InetAddressType
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The type of the nhdpLibLocalIfSetIpAddr
+ in the InetAddress MIB (RFC 4001).
+
+ Only the values 'ipv4(1)' and
+ 'ipv6(2)' are supported."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpLibLocalIfSetEntry 3 }
+
+ nhdpLibLocalIfSetIpAddr OBJECT-TYPE
+ SYNTAX InetAddress (SIZE(4|16))
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "nhdpLibLocalIfSetIpAddr is an
+ address of an interface of
+ this router.
+
+ This object is interpreted according to
+ the setting of nhdpLibLocalIfSetIpAddrType."
+
+
+
+
+
+Herberg, et al. Standards Track [Page 30]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpLibLocalIfSetEntry 4 }
+
+ nhdpLibLocalIfSetIpAddrPrefixLen OBJECT-TYPE
+ SYNTAX InetAddressPrefixLength
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Indicates the number of leading one bits that
+ form the mask. The mask is logically ANDed
+ to the nhdpLibLocalIfSetIpAddr to determine
+ the address prefix. A row match is true
+ if the address used as an index falls within
+ the network address range defined by the
+ address prefix."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpLibLocalIfSetEntry 5 }
+
+ nhdpLibLocalIfSetRowStatus OBJECT-TYPE
+ SYNTAX RowStatus
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This object permits management of the table
+ by facilitating actions such as row creation,
+ construction, and destruction. The value of
+ this object has no effect on whether other
+ objects in this conceptual row can be
+ modified.
+
+ An entry may not exist in the 'active(1)' state unless all
+ read-create objects in the entry have a defined
+ appropriate value. As no objects in this table have
+ DEFVAL clauses, the management station MUST specify
+ the values of all read-create objects prior to this row
+ transitioning to the 'active(1)' state.
+
+ When this object transitions to 'active(1)', all objects
+ in this row SHOULD be written to nonvolatile (stable)
+ storage. Read-create objects in this row MAY be modified.
+ When an object in a row with nhdpIfRowStatus of 'active(1)'
+ is changed, then the updated value MUST be reflected in NHDP,
+
+
+
+Herberg, et al. Standards Track [Page 31]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ and this new object value MUST be written to nonvolatile
+ storage."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ DEFVAL { notReady }
+ ::= { nhdpLibLocalIfSetEntry 6 }
+
+
+
+ --
+ -- Removed Interface Addr Set Table
+ --
+
+ nhdpLibRemovedIfAddrSetTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF NhdpLibRemovedIfAddrSetEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A router's Removed Interface Address Set records
+ network addresses that were recently used as local
+ interface network addresses. If a router's interface
+ network addresses are immutable, then the Removed
+ Interface Address Set is always empty and may be omitted.
+ It consists of Removed Interface Address Tuples, one
+ per network address."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpConfigurationObjGrp 5 }
+
+ nhdpLibRemovedIfAddrSetEntry OBJECT-TYPE
+ SYNTAX NhdpLibRemovedIfAddrSetEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A router's Removed Interface Address Set consists
+ of Removed Interface Address Tuples, one per network
+ address:
+
+ (IR_local_iface_addr, IR_time)
+
+ The association between these addresses and the
+ router's Interface is found in RFC 4293 (ipAddressTable)"
+
+
+
+
+
+Herberg, et al. Standards Track [Page 32]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ REFERENCE
+ "RFC 4293 - Management Information Base for the Internet
+ Protocol (IP), S. Routhier, Ed., April 2006.
+
+ RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ INDEX { nhdpLibRemovedIfAddrSetIndex }
+ ::= { nhdpLibRemovedIfAddrSetTable 1 }
+
+ NhdpLibRemovedIfAddrSetEntry ::=
+ SEQUENCE {
+ nhdpLibRemovedIfAddrSetIndex
+ Integer32,
+ nhdpLibRemovedIfAddrSetIpAddrType
+ InetAddressType,
+ nhdpLibRemovedIfAddrSetIpAddr
+ InetAddress,
+ nhdpLibRemovedIfAddrSetIpAddrPrefixLen
+ InetAddressPrefixLength,
+ nhdpLibRemovedIfAddrSetIfIndex
+ InterfaceIndex,
+ nhdpLibRemovedIfAddrSetIRTime
+ TimeStamp
+ }
+
+ nhdpLibRemovedIfAddrSetIndex OBJECT-TYPE
+ SYNTAX Integer32 (0..65535)
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The index for this table. Necessary
+ because multiple addresses may be associated
+ with a given nhdpIfIndex."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpLibRemovedIfAddrSetEntry 1 }
+
+ nhdpLibRemovedIfAddrSetIpAddrType OBJECT-TYPE
+ SYNTAX InetAddressType
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The type of the nhdpLibRemovedIfAddrSetIpAddr
+ in the InetAddress MIB (RFC 4001).
+
+
+
+
+Herberg, et al. Standards Track [Page 33]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ Only the values 'ipv4(1)' and
+ 'ipv6(2)' are supported."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpLibRemovedIfAddrSetEntry 2 }
+
+ nhdpLibRemovedIfAddrSetIpAddr OBJECT-TYPE
+ SYNTAX InetAddress (SIZE(4|16))
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "nhdpLibRemovedIfAddrSetIpAddr is a
+ recently used address of an interface of
+ this router."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpLibRemovedIfAddrSetEntry 3 }
+
+ nhdpLibRemovedIfAddrSetIpAddrPrefixLen OBJECT-TYPE
+ SYNTAX InetAddressPrefixLength
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Indicates the number of leading one bits that
+ form the mask. The mask is logically ANDed
+ to the nhdpLibRemovedIfAddrSetIpAddr to determine
+ the address prefix. A row match is true
+ if the address used as an index falls within
+ the network address range defined by the
+ address prefix."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpLibRemovedIfAddrSetEntry 4 }
+
+ nhdpLibRemovedIfAddrSetIfIndex OBJECT-TYPE
+ SYNTAX InterfaceIndex
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Specifies the local IfIndex from which this
+ IP address was recently removed."
+
+
+
+
+Herberg, et al. Standards Track [Page 34]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpLibRemovedIfAddrSetEntry 5 }
+
+ nhdpLibRemovedIfAddrSetIRTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "nhdpLibRemovedIfAddrSetIRTime specifies the value
+ of sysUpTime when this entry should expire and be
+ removed from the nhdpLibRemovedIfAddrSetTable."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpLibRemovedIfAddrSetEntry 6 }
+
+--
+-- nhdpStateObjGrp
+--
+
+-- Contains information describing the current state of the NHDP
+-- process on this router.
+
+nhdpStateObjGrp OBJECT IDENTIFIER ::= { nhdpObjects 2 }
+
+ nhdpUpTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of sysUpTime at the time the current NHDP
+ process was initialized."
+ ::= { nhdpStateObjGrp 1 }
+
+ nhdpInterfaceStateTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF NhdpInterfaceStateEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "nhdpInterfaceStateTable lists state information
+ related to specific interfaces of this router.
+ The value of nhdpIfIndex is an ifIndex from the
+ Interfaces Group defined in the Interfaces Group
+ MIB.
+
+
+
+Herberg, et al. Standards Track [Page 35]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ The objects in this table are persistent, and when
+ written, the entity SHOULD save the change to
+ nonvolatile storage."
+ REFERENCE
+ "RFC 2863 - The Interfaces Group MIB, McCloghrie,
+ K., and F. Kastenholtz, June 2000"
+ ::= { nhdpStateObjGrp 2 }
+
+ nhdpInterfaceStateEntry OBJECT-TYPE
+ SYNTAX NhdpInterfaceStateEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "nhdpInterfaceStateEntry describes one NHDP
+ local interface state as indexed by
+ its nhdpIfIndex."
+ INDEX { nhdpIfIndex }
+ ::= { nhdpInterfaceStateTable 1 }
+
+ NhdpInterfaceStateEntry ::=
+ SEQUENCE {
+ nhdpIfStateUpTime
+ TimeStamp
+ }
+
+ nhdpIfStateUpTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of the sysUpTime when
+ NHDP was last initialized on this
+ MANET interface."
+ ::= { nhdpInterfaceStateEntry 1 }
+
+
+ --
+ -- This table allows for the mapping between discovered
+ -- remote interfaces and routers and their addresses.
+ --
+
+ nhdpDiscIfSetTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF NhdpDiscIfSetEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A router's set of discovered interfaces on
+ neighboring routers."
+
+
+
+Herberg, et al. Standards Track [Page 36]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpStateObjGrp 3 }
+
+ nhdpDiscIfSetEntry OBJECT-TYPE
+ SYNTAX NhdpDiscIfSetEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The entries include the nhdpDiscRouterIndex of
+ the discovered router, the nhdpDiscIfIndex
+ of the discovered interface, and the
+ current set of addresses associated
+ with this neighbor interface. The
+ nhdpDiscIfIndex uniquely identifies
+ the remote interface address sets
+ through this table. It does not need
+ to be unique across the MANET but MUST
+ be locally unique within this router."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ INDEX { nhdpDiscIfSetIndex }
+ ::= { nhdpDiscIfSetTable 1 }
+
+ NhdpDiscIfSetEntry ::=
+ SEQUENCE {
+ nhdpDiscIfSetIndex
+ Integer32,
+ nhdpDiscIfIndex
+ NeighborIfIndex,
+ nhdpDiscRouterIndex
+ NeighborRouterIndex,
+ nhdpDiscIfSetIpAddrType
+ InetAddressType,
+ nhdpDiscIfSetIpAddr
+ InetAddress,
+ nhdpDiscIfSetIpAddrPrefixLen
+ InetAddressPrefixLength
+ }
+
+ nhdpDiscIfSetIndex OBJECT-TYPE
+ SYNTAX Integer32 (0..65535)
+ MAX-ACCESS not-accessible
+ STATUS current
+
+
+
+Herberg, et al. Standards Track [Page 37]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ DESCRIPTION
+ "The index for this table. Necessary
+ because multiple addresses may be associated
+ with a given nhdpDiscIfIndex."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpDiscIfSetEntry 1 }
+
+ nhdpDiscIfIndex OBJECT-TYPE
+ SYNTAX NeighborIfIndex
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The NHDP interface index (locally created)
+ of a neighbor's interface. Used for cross-
+ indexing into other NHDP tables and other
+ MIB modules."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpDiscIfSetEntry 2 }
+
+ nhdpDiscRouterIndex OBJECT-TYPE
+ SYNTAX NeighborRouterIndex
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The NHDP neighbor index (locally created)
+ of a neighboring router. Used for cross-
+ indexing into other NHDP tables and other
+ MIB modules."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpDiscIfSetEntry 3 }
+
+ nhdpDiscIfSetIpAddrType OBJECT-TYPE
+ SYNTAX InetAddressType
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The type of the nhdpDiscIfSetIpAddr
+ in the InetAddress MIB (RFC 4001).
+
+
+
+
+Herberg, et al. Standards Track [Page 38]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ Only the values 'ipv4(1)' and
+ 'ipv6(2)' are supported."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpDiscIfSetEntry 4 }
+
+ nhdpDiscIfSetIpAddr OBJECT-TYPE
+ SYNTAX InetAddress (SIZE(4|16))
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The nhdpDiscIfSetIpAddr is a
+ recently used address of a neighbor
+ of this router."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpDiscIfSetEntry 5 }
+
+ nhdpDiscIfSetIpAddrPrefixLen OBJECT-TYPE
+ SYNTAX InetAddressPrefixLength
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Indicates the number of leading one bits that
+ form the mask. The mask is logically ANDed
+ to the nhdpDiscIfSetIpAddr to determine
+ the address prefix. A row match is true
+ if the address used as an index falls within
+ the network address range defined by the
+ address prefix."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpDiscIfSetEntry 6 }
+
+
+ -- Interface Information Base (IIB)
+
+ --
+ -- Link Set
+ --
+
+
+
+
+
+Herberg, et al. Standards Track [Page 39]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ nhdpIibLinkSetTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF NhdpIibLinkSetEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A Link Set of an interface records all links
+ from other routers that are, or recently
+ were, 1-hop neighbors."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpStateObjGrp 4 }
+
+ nhdpIibLinkSetEntry OBJECT-TYPE
+ SYNTAX NhdpIibLinkSetEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A Link Set consists of Link Tuples, each
+ representing a single link indexed by the
+ local and remote interface pair:
+
+ (L_neighbor_iface_addr_list, L_HEARD_time,
+ L_SYM_time, L_quality, L_pending,
+ L_lost, L_time).
+
+ The local interface is indexed via the
+ nhdpIfIndex. The 1-hop interface is
+ indexed via the nhdpDiscIfIndex. There
+ SHOULD be an entry in this table for each
+ local interface and associated 1-hop
+ neighbor reachable on this local interface.
+
+ Note that L_quality is not included in the
+ entries below, because updates may be
+ required too frequently."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ INDEX { nhdpIfIndex,
+ nhdpDiscIfIndex }
+ ::= { nhdpIibLinkSetTable 1 }
+
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 40]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ NhdpIibLinkSetEntry ::=
+ SEQUENCE {
+ nhdpIibLinkSetLHeardTime
+ TimeStamp,
+ nhdpIibLinkSetLSymTime
+ TimeStamp,
+ nhdpIibLinkSetLPending
+ TruthValue,
+ nhdpIibLinkSetLLost
+ TruthValue,
+ nhdpIibLinkSetLTime
+ TimeStamp
+ }
+
+ nhdpIibLinkSetLHeardTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "nhdpIibLinkSetLHeardTime corresponds
+ to L_HEARD_time of NHDP and represents the
+ time up to which the MANET interface of the
+ 1-hop neighbor would be considered heard if
+ not considering link quality."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpIibLinkSetEntry 1 }
+
+ nhdpIibLinkSetLSymTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "nhdpIibLinkSetLSymTime corresponds
+ to L_SYM_time of NHDP and represents the time
+ up to which the link to the 1-hop neighbor
+ would be considered symmetric if not considering
+ link quality."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpIibLinkSetEntry 2 }
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 41]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ nhdpIibLinkSetLPending OBJECT-TYPE
+ SYNTAX TruthValue
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "nhdpIibLinkSetLPending corresponds
+ to L_pending of NHDP and is a boolean flag,
+ describing if a link is considered pending
+ (i.e., a candidate, but not yet established,
+ link)."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpIibLinkSetEntry 3 }
+
+ nhdpIibLinkSetLLost OBJECT-TYPE
+ SYNTAX TruthValue
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "nhdpIibLinkSetLLost corresponds
+ to L_lost of NHDP and is a boolean flag,
+ describing if a link is considered lost due
+ to low link quality."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpIibLinkSetEntry 4 }
+
+ nhdpIibLinkSetLTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "nhdpIibLinkSetLTime specifies the value
+ of sysUpTime when this entry should expire and be
+ removed from the nhdpIibLinkSetTable."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpIibLinkSetEntry 5 }
+
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 42]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ --
+ -- 2-Hop Set
+ --
+ nhdpIib2HopSetTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF NhdpIib2HopSetEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A 2-Hop Set of an interface records network
+ addresses of symmetric 2-hop neighbors and
+ the symmetric links to symmetric 1-hop neighbors
+ through which these symmetric 2-hop neighbors
+ can be reached. It consists of 2-Hop Tuples."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpStateObjGrp 5 }
+
+ nhdpIib2HopSetEntry OBJECT-TYPE
+ SYNTAX NhdpIib2HopSetEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "nhdpIib2HopSetTable consists of 2-Hop Tuples, each
+ representing a single network address of a symmetric
+ 2-hop neighbor and a single MANET interface of a
+ symmetric 1-hop neighbor.
+
+ (N2_neighbor_iface_addr_list,
+ N2_2hop_addr, N2_lost, N2_time).
+
+ The entries include:
+ - the 2-hop neighbor addresses
+ ('N2_neighbor_iface_addr_list'), which
+ act as the table index,
+ - the associated symmetric 1-hop
+ neighbor address set ('N2_2hop_addr'), designated
+ through nhdpDiscIfIndex,
+ - a flag indicating if the 1-hop neighbor
+ through which this 2-hop neighbor is reachable
+ ('N2_lost') is considered lost due to link quality,
+ or not,
+ - and the expiration time ('N2_time').
+
+ The nhdpIfIndex in the INDEX is the interface index of
+ the local interface through which these 2-hop addresses
+ are accessible. The nhdpDiscIfIndex in the INDEX
+
+
+
+Herberg, et al. Standards Track [Page 43]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ represents the 1-hop neighbor interface through which
+ these 2-hop neighbor addresses are reachable."
+
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011
+ and
+ RFC 7466 - An Optimization for the Mobile Ad Hoc
+ Network (MANET) Neighborhood Discovery Protocol (NHDP),
+ Dearlove, C., and T. Clausen, March 2015"
+ INDEX { nhdpIfIndex,
+ nhdpDiscIfIndex,
+ nhdpIib2HopSetIpAddressType,
+ nhdpIib2HopSetIpAddress
+ }
+ ::= { nhdpIib2HopSetTable 1 }
+
+ NhdpIib2HopSetEntry ::=
+ SEQUENCE {
+ nhdpIib2HopSetIpAddressType
+ InetAddressType,
+ nhdpIib2HopSetIpAddress
+ InetAddress,
+ nhdpIib2HopSetIpAddrPrefixLen
+ InetAddressPrefixLength,
+ nhdpIib2HopSet1HopIfIndex
+ NeighborIfIndex,
+ nhdpIib2HopSetN2Time
+ TimeStamp,
+ nhdpIib2HopSetN2Lost
+ TruthValue
+ }
+
+ nhdpIib2HopSetIpAddressType OBJECT-TYPE
+ SYNTAX InetAddressType
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The type of the nhdpIib2HopSetIpAddress
+ in the InetAddress MIB module (RFC 4001).
+
+ Only the values 'ipv4(1)' and
+ 'ipv6(2)' are supported."
+
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 44]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpIib2HopSetEntry 1 }
+
+ nhdpIib2HopSetIpAddress OBJECT-TYPE
+ SYNTAX InetAddress (SIZE(4|16))
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "nhdpIib2HopSetIpAddr corresponds
+ to N2_2hop_addr of NHDP and is a network
+ address of a symmetric 2-hop neighbor that
+ has a symmetric link (using any MANET
+ interface) to the indicated symmetric
+ 1-hop neighbor."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpIib2HopSetEntry 2 }
+
+ nhdpIib2HopSetIpAddrPrefixLen OBJECT-TYPE
+ SYNTAX InetAddressPrefixLength
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Indicates the number of leading one bits that
+ form the mask. The mask is logically ANDed
+ to the nhdpIib2HopSetIpAddress to determine
+ the address prefix. A row match is true
+ if the address used as an index falls within
+ the network address range defined by the
+ address prefix."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpIib2HopSetEntry 3 }
+
+ nhdpIib2HopSet1HopIfIndex OBJECT-TYPE
+ SYNTAX NeighborIfIndex
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "nhdpIib2HopSet1HopIfIndex is
+ nhdpDiscIfIndex of the 1-hop
+
+
+
+Herberg, et al. Standards Track [Page 45]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ neighbor that communicated the ipAddress
+ of the 2-hop neighbor in this row entry."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpIib2HopSetEntry 4 }
+
+ nhdpIib2HopSetN2Time OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "nhdpIib2HopSetN2Time specifies the value
+ of sysUpTime when this entry should expire and be
+ removed from the nhdpIib2HopSetTable."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpIib2HopSetEntry 5 }
+
+
+ nhdpIib2HopSetN2Lost OBJECT-TYPE
+ SYNTAX TruthValue
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "nhdpIib2HopSetN2Lost corresponds to N2_lost of NHDP and
+ is a boolean flag, describing if for a 2-Hop Tuple, the
+ corresponding Link Tuple currently is considered lost
+ due to link quality."
+
+ REFERENCE
+ "RFC 7466 - An Optimization for the Mobile Ad Hoc
+ Network (MANET) Neighborhood Discovery Protocol (NHDP),
+ Dearlove, C., and T. Clausen, March 2015"
+ ::= {nhdpIib2HopSetEntry 6}
+
+
+ --
+ -- Neighbor Information Base (NIB)
+ --
+ -- Each router maintains a Neighbor Information Base
+ -- that records information about addresses of
+ -- current and recently symmetric 1-hop neighbors.
+
+
+
+
+
+Herberg, et al. Standards Track [Page 46]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ --
+ -- Neighbor Set
+ --
+ -- The Neighbor Set Table is small because
+ -- most of the corresponding information is found
+ -- in the nhdpDiscoveredIfTable above.
+ --
+
+ nhdpNibNeighborSetTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF NhdpNibNeighborSetEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A router's Neighbor Set records all
+ network addresses of each 1-hop
+ neighbor."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpStateObjGrp 6 }
+
+ nhdpNibNeighborSetEntry OBJECT-TYPE
+ SYNTAX NhdpNibNeighborSetEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A router's Neighbor Set consists
+ of Neighbor Tuples, each representing
+ a single 1-hop neighbor:
+
+ (N_neighbor_addr_list, N_symmetric)"
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ INDEX { nhdpDiscRouterIndex }
+ ::= { nhdpNibNeighborSetTable 1 }
+
+ NhdpNibNeighborSetEntry ::=
+ SEQUENCE {
+ nhdpNibNeighborSetNSymmetric
+ TruthValue
+ }
+
+ nhdpNibNeighborSetNSymmetric OBJECT-TYPE
+ SYNTAX TruthValue
+ MAX-ACCESS read-only
+
+
+
+Herberg, et al. Standards Track [Page 47]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ STATUS current
+ DESCRIPTION
+ "nhdpNibNeighborNSymmetric corresponds
+ to N_symmetric of NHDP and is a boolean flag,
+ describing if this is a symmetric 1-hop neighbor."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpNibNeighborSetEntry 1 }
+
+
+ --
+ -- Lost Neighbor Set
+ --
+ nhdpNibLostNeighborSetTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF NhdpNibLostNeighborSetEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A router's Lost Neighbor Set records network
+ addresses of routers that were recently
+ symmetric 1-hop neighbors but are now
+ advertised as lost."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpStateObjGrp 7 }
+
+ nhdpNibLostNeighborSetEntry OBJECT-TYPE
+ SYNTAX NhdpNibLostNeighborSetEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A router's Lost Neighbor Set consists of
+ Lost Neighbor Tuples, each representing a
+ single such network address:
+
+ (NL_neighbor_addr, NL_time)"
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ INDEX { nhdpDiscRouterIndex }
+ ::= { nhdpNibLostNeighborSetTable 1 }
+
+
+
+
+
+Herberg, et al. Standards Track [Page 48]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ NhdpNibLostNeighborSetEntry ::=
+ SEQUENCE {
+ nhdpNibLostNeighborSetNLTime
+ TimeStamp
+ }
+
+ nhdpNibLostNeighborSetNLTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "nhdpNibLostNeighborSetNLTime
+ specifies the value of sysUpTime when this entry
+ should expire and be removed from the
+ nhdpNibLostNeighborSetTable."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpNibLostNeighborSetEntry 1 }
+
+
+--
+-- nhdpPerformanceObjGrp
+--
+-- Contains objects that help to characterize the performance of
+-- the NHDP process, typically counters.
+--
+nhdpPerformanceObjGrp OBJECT IDENTIFIER ::= { nhdpObjects 3 }
+
+ --
+ -- Objects per local interface
+ --
+
+ nhdpInterfacePerfTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF NhdpInterfacePerfEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This table summarizes performance objects that are
+ measured per local NHDP interface.
+ nhdpIfPerfCounterDiscontinuityTime indicates
+ the most recent occasion at which any one or more
+ of this interface's counters listed in this table
+ suffered a discontinuity."
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 49]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpPerformanceObjGrp 1 }
+
+ nhdpInterfacePerfEntry OBJECT-TYPE
+ SYNTAX NhdpInterfacePerfEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A single entry contains performance counters for
+ a local NHDP interface."
+ INDEX { nhdpIfIndex }
+ ::= { nhdpInterfacePerfTable 1 }
+
+ NhdpInterfacePerfEntry ::=
+ SEQUENCE {
+ nhdpIfHelloMessageXmits
+ Counter32,
+ nhdpIfHelloMessageRecvd
+ Counter32,
+ nhdpIfHelloMessageXmitAccumulatedSize
+ Counter64,
+ nhdpIfHelloMessageRecvdAccumulatedSize
+ Counter64,
+ nhdpIfHelloMessageTriggeredXmits
+ Counter32,
+ nhdpIfHelloMessagePeriodicXmits
+ Counter32,
+ nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
+ Counter32,
+ nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
+ Counter32,
+ nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
+ Counter32,
+ nhdpIfPerfCounterDiscontinuityTime
+ TimeStamp
+ }
+
+ nhdpIfHelloMessageXmits OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "messages"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A counter is incremented each time a HELLO
+ message has been transmitted on that interface."
+
+
+
+Herberg, et al. Standards Track [Page 50]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ ::= { nhdpInterfacePerfEntry 1 }
+
+ nhdpIfHelloMessageRecvd OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "messages"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A counter is incremented each time a HELLO
+ message has been received on that interface."
+ ::= { nhdpInterfacePerfEntry 2 }
+
+ nhdpIfHelloMessageXmitAccumulatedSize OBJECT-TYPE
+ SYNTAX Counter64
+ UNITS "octets"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A counter is incremented by the number of octets in
+ a HELLO message each time a HELLO message has been sent."
+ ::= { nhdpInterfacePerfEntry 3 }
+
+ nhdpIfHelloMessageRecvdAccumulatedSize OBJECT-TYPE
+ SYNTAX Counter64
+ UNITS "octets"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A counter is incremented by the number of octets in
+ a HELLO message each time a HELLO message has been received."
+ ::= { nhdpInterfacePerfEntry 4 }
+
+ nhdpIfHelloMessageTriggeredXmits OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "messages"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A counter is incremented each time a triggered
+ HELLO message has been sent."
+ ::= { nhdpInterfacePerfEntry 5 }
+
+ nhdpIfHelloMessagePeriodicXmits OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "messages"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+
+
+
+Herberg, et al. Standards Track [Page 51]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ "A counter is incremented each time a periodic
+ HELLO message has been sent."
+ ::= { nhdpInterfacePerfEntry 6 }
+
+ nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "neighbors"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A counter is incremented by the number of advertised
+ symmetric neighbors in a HELLO each time a HELLO
+ message has been sent."
+ ::= { nhdpInterfacePerfEntry 7 }
+
+ nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "neighbors"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A counter is incremented by the number of advertised
+ heard neighbors in a HELLO each time a HELLO
+ message has been sent."
+ ::= { nhdpInterfacePerfEntry 8 }
+
+ nhdpIfHelloMessageXmitAccumulatedLostNeighborCount OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "neighbors"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A counter is incremented by the number of advertised
+ lost neighbors in a HELLO each time a HELLO
+ message has been sent."
+ ::= { nhdpInterfacePerfEntry 9 }
+
+ nhdpIfPerfCounterDiscontinuityTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of sysUpTime on the most recent occasion at which
+ any one or more of this interface's counters suffered a
+ discontinuity. If no such discontinuities have occurred
+ since the last reinitialization of the local management
+ subsystem, then this object contains a zero value."
+ ::= { nhdpInterfacePerfEntry 10 }
+
+
+
+Herberg, et al. Standards Track [Page 52]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ --
+ -- Objects per discovered neighbor interface
+ --
+ nhdpDiscIfSetPerfTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF NhdpDiscIfSetPerfEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A router's set of performance properties for
+ each discovered interface of a neighbor."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpPerformanceObjGrp 2 }
+
+ nhdpDiscIfSetPerfEntry OBJECT-TYPE
+ SYNTAX NhdpDiscIfSetPerfEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "There is an entry for each discovered
+ interface of a neighbor."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ INDEX { nhdpDiscIfIndex }
+ ::= { nhdpDiscIfSetPerfTable 1 }
+
+ NhdpDiscIfSetPerfEntry ::=
+ SEQUENCE {
+ nhdpDiscIfRecvdPackets
+ Counter32,
+ nhdpDiscIfExpectedPackets
+ Counter32
+ }
+
+ nhdpDiscIfRecvdPackets OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "packets"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This counter increments each
+ time this router receives a packet from that interface
+ of the neighbor."
+ REFERENCE
+
+
+
+Herberg, et al. Standards Track [Page 53]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpDiscIfSetPerfEntry 1 }
+
+ nhdpDiscIfExpectedPackets OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "packets"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This counter increments by the number
+ of missed packets from this neighbor based
+ on the packet sequence number each time this
+ router receives a packet from that interface
+ of the neighbor."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpDiscIfSetPerfEntry 2 }
+
+
+ --
+ -- Objects concerning the Neighbor Set
+ --
+ nhdpNibNeighborSetChanges OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "changes"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This counter increments each time the Neighbor Set changes.
+ 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."
+ ::= { nhdpPerformanceObjGrp 3 }
+
+
+ --
+ -- Objects per discovered neighbor
+ --
+ nhdpDiscNeighborSetPerfTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF NhdpDiscNeighborSetPerfEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+
+
+
+
+
+Herberg, et al. Standards Track [Page 54]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ DESCRIPTION
+ "A router's set of discovered neighbors and
+ their properties."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpPerformanceObjGrp 4 }
+
+ nhdpDiscNeighborSetPerfEntry OBJECT-TYPE
+ SYNTAX NhdpDiscNeighborSetPerfEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The entries include the nhdpDiscRouterIndex of
+ the discovered router as well as performance
+ objects related to changes of the Neighbor
+ Set."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ INDEX { nhdpDiscRouterIndex }
+ ::= { nhdpDiscNeighborSetPerfTable 1 }
+
+ NhdpDiscNeighborSetPerfEntry ::=
+ SEQUENCE {
+ nhdpDiscNeighborNibNeighborSetChanges
+ Counter32,
+ nhdpDiscNeighborNibNeighborSetUpTime
+ TimeStamp,
+ nhdpDiscNeighborNibNeighborSetReachableLinkChanges
+ Counter32
+ }
+
+ nhdpDiscNeighborNibNeighborSetChanges OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "changes"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object returns the number of changes
+ to the given Neighbor Tuple."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpDiscNeighborSetPerfEntry 1 }
+
+
+
+Herberg, et al. Standards Track [Page 55]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ nhdpDiscNeighborNibNeighborSetUpTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object returns the sysUpTime when a new
+ nhdpNibNeighborSetEntry has been created for a
+ particular nhdpNibNeighborSetRouterIndex."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpDiscNeighborSetPerfEntry 2 }
+
+ nhdpDiscNeighborNibNeighborSetReachableLinkChanges OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "changes"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "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."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpDiscNeighborSetPerfEntry 3 }
+
+
+ --
+ -- Objects per discovered 2-hop neighbor
+ --
+ nhdpIib2HopSetPerfTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF NhdpIib2HopSetPerfEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "This table contains performance objects per
+ discovered 2-hop neighbor."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpPerformanceObjGrp 5 }
+
+
+
+Herberg, et al. Standards Track [Page 56]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ nhdpIib2HopSetPerfEntry OBJECT-TYPE
+ SYNTAX NhdpIib2HopSetPerfEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The entries contain performance objects per
+ discovered 2-hop neighbor."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ INDEX { nhdpDiscRouterIndex }
+ ::= { nhdpIib2HopSetPerfTable 1 }
+
+ NhdpIib2HopSetPerfEntry ::=
+ SEQUENCE {
+ nhdpIib2HopSetPerfChanges
+ Counter32,
+ nhdpIib2HopSetPerfUpTime
+ TimeStamp
+ }
+
+ nhdpIib2HopSetPerfChanges OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "changes"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object counts 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."
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpIib2HopSetPerfEntry 1 }
+
+ nhdpIib2HopSetPerfUpTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This object returns the sysUpTime
+ when the 2-Hop Tuple
+ corresponding to the given 2-hop neighbor IP address
+ was registered in the nhdpIib2HopSetTable."
+
+
+
+
+Herberg, et al. Standards Track [Page 57]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ REFERENCE
+ "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP), Clausen, T., Dearlove,
+ C., and J. Dean, April 2011"
+ ::= { nhdpIib2HopSetPerfEntry 2 }
+
+
+--
+-- nhdpNotifications
+--
+
+nhdpNotificationsObjects OBJECT IDENTIFIER ::= { nhdpNotifications 0 }
+nhdpNotificationsControl OBJECT IDENTIFIER ::= { nhdpNotifications 1 }
+nhdpNotificationsStates OBJECT IDENTIFIER ::= { nhdpNotifications 2 }
+
+ -- nhdpNotificationsObjects
+
+ nhdpNbrStateChange NOTIFICATION-TYPE
+ OBJECTS { nhdpIfName, -- The originator of the notification.
+ nhdpNbrState -- The new state
+ }
+ STATUS current
+ DESCRIPTION
+ "nhdpNbrStateChange is a notification sent when
+ more than nhdpNbrStateChangeThreshold neighbors change
+ their status (i.e., 'down(0)', 'asymmetric(1)', or
+ 'symmetric(2)') within a time window of
+ nhdpNbrStateChangeWindow."
+ ::= { nhdpNotificationsObjects 1 }
+
+ nhdp2HopNbrStateChange NOTIFICATION-TYPE
+ OBJECTS { nhdpIfName, -- The originator
+ -- of the notification
+ nhdp2HopNbrState -- The new state
+ }
+ STATUS current
+ DESCRIPTION
+ "nhdp2HopNbrStateChange is a notification sent
+ when more than nhdp2HopNbrStateChangeThreshold 2-hop
+ neighbors change their nhdp2HopNbrState
+ within a time window of
+ nhdp2HopNbrStateChangeWindow."
+ ::= { nhdpNotificationsObjects 2 }
+
+
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 58]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ nhdpIfStateChange NOTIFICATION-TYPE
+ OBJECTS { nhdpIfName, -- The local interface
+ nhdpIfStatus -- The new status
+ }
+ STATUS current
+ DESCRIPTION
+ "nhdpIfStateChange is a notification sent when
+ nhdpIfStatus has changed on this interface."
+ ::= { nhdpNotificationsObjects 3 }
+
+ -- nhdpNotificationsControl
+
+ nhdpNbrStateChangeThreshold OBJECT-TYPE
+ SYNTAX Integer32 (0..255)
+ UNITS "changes"
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "A threshold value for the
+ nhdpNbrStateChange object. If the
+ number of occurrences exceeds this threshold
+ within the previous nhdpNbrStateChangeWindow,
+ then the nhdpNbrStateChange notification
+ is to be sent.
+
+ It is recommended that the value of this
+ threshold be set to at least 10 and higher
+ in dense topologies with frequent expected
+ topology changes."
+ DEFVAL { 10 }
+ ::= { nhdpNotificationsControl 1 }
+
+ nhdpNbrStateChangeWindow OBJECT-TYPE
+ SYNTAX TimeTicks
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "A time window for the
+ nhdpNbrStateChange object. If the
+ number of occurrences exceeds the
+ nhdpNbrStateChangeThreshold
+ within the previous nhdpNbrStateChangeWindow,
+ then the nhdpNbrStateChange notification
+ is to be sent.
+
+ It is recommended that the value for this
+ window be set to at least 5 times the
+ nhdpHelloInterval.
+
+
+
+Herberg, et al. Standards Track [Page 59]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ This object represents the time in hundredths
+ of a second."
+ DEFVAL { 1000 }
+ ::= { nhdpNotificationsControl 2 }
+
+ nhdp2HopNbrStateChangeThreshold OBJECT-TYPE
+ SYNTAX Integer32 (0..255)
+ UNITS "changes"
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "A threshold value for the
+ nhdp2HopNbrStateChange object. If the
+ number of occurrences exceeds this threshold
+ within the previous nhdp2HopNbrStateChangeWindow,
+ then the nhdp2HopNbrStateChange notification
+ is to be sent.
+
+ It is recommended that the value of this
+ threshold be set to at least 10 and higher
+ when topologies are expected to be highly dynamic."
+ DEFVAL { 10 }
+ ::= { nhdpNotificationsControl 3 }
+
+ nhdp2HopNbrStateChangeWindow OBJECT-TYPE
+ SYNTAX TimeTicks
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "A time window for the
+ nhdp2HopNbrStateChange object. If the
+ number of occurrences exceeds the
+ nhdp2HopNbrStateChangeThreshold
+ within the previous nhdp2HopNbrStateChangeWindow,
+ then the nhdp2HopNbrStateChange notification
+ is to be sent.
+
+ It is recommended that the value for this
+ window be set to at least 5 times
+ nhdpHelloInterval.
+
+ This object represents the time in hundredths
+ of a second."
+ DEFVAL { 1000 }
+ ::= { nhdpNotificationsControl 4 }
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 60]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ -- nhdpNotificationStates
+
+ nhdpNbrState OBJECT-TYPE
+ SYNTAX INTEGER {
+ down(0),
+ asymmetric(1),
+ symmetric(2)
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "NHDP neighbor states. In NHDP, it is not
+ necessary to remove Protocol Tuples from Protocol Sets
+ at the exact time indicated, only to behave as if the
+ Protocol Tuples were removed at that time. This case is
+ indicated here as 'down(0)', all other cases being
+ indicated as 'asymmetric(1)' or 'symmetric(2)'. If 'down(0)',
+ the direct neighbor is also added to the
+ nhdpNibLostNeighborSetTable."
+ ::= { nhdpNotificationsStates 1 }
+
+ nhdp2HopNbrState OBJECT-TYPE
+ SYNTAX INTEGER {
+ down(0),
+ up(1),
+ notconsidered(2)
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "NHDP 2-hop neighbor states. In NHDP, it is not necessary
+ to remove Protocol Tuples from Protocol Sets at the
+ exact time indicated, only to behave as if the Protocol
+ Tuples were removed at that time. This case is indicated
+ here as 'down(0)'; otherwise, it is either 'up(1)', if
+ N2_lost for the 2-Hop Tuple is equal to false, or
+ 'notconsidered(2)' otherwise."
+ ::= { nhdpNotificationsStates 2 }
+
+--
+-- nhdpConformance information
+--
+
+nhdpCompliances OBJECT IDENTIFIER ::= { nhdpConformance 1 }
+nhdpMIBGroups OBJECT IDENTIFIER ::= { nhdpConformance 2 }
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 61]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ -- Compliance Statements
+ nhdpBasicCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The basic implementation requirements for
+ managed network entities that implement
+ NHDP."
+ MODULE -- this module
+ MANDATORY-GROUPS { nhdpConfigurationGroup }
+ ::= { nhdpCompliances 1 }
+
+ nhdpFullCompliance2 MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The full implementation requirements for
+ managed network entities that implement
+ NHDP."
+ MODULE -- this module
+ MANDATORY-GROUPS { nhdpConfigurationGroup,
+ nhdpStateGroup2,
+ nhdpNotificationObjectGroup,
+ nhdpNotificationGroup,
+ nhdpPerformanceGroup
+ }
+ ::= { nhdpCompliances 3 }
+
+
+--
+-- Units of Conformance
+--
+
+ nhdpConfigurationGroup OBJECT-GROUP
+ OBJECTS {
+ nhdpIfName,
+ nhdpIfStatus,
+ nhdpHelloInterval,
+ nhdpHelloMinInterval,
+ nhdpRefreshInterval,
+ nhdpLHoldTime,
+ nhdpHHoldTime,
+ nhdpHystAcceptQuality,
+ nhdpHystRejectQuality,
+ nhdpInitialQuality,
+ nhdpInitialPending,
+ nhdpHpMaxJitter,
+ nhdpHtMaxJitter,
+ nhdpNHoldTime,
+ nhdpIHoldTime,
+
+
+
+Herberg, et al. Standards Track [Page 62]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ nhdpIfRowStatus,
+ nhdpLibLocalIfSetIfIndex,
+ nhdpLibLocalIfSetIpAddrType,
+ nhdpLibLocalIfSetIpAddr,
+ nhdpLibLocalIfSetIpAddrPrefixLen,
+ nhdpLibLocalIfSetRowStatus,
+ nhdpLibRemovedIfAddrSetIpAddrType,
+ nhdpLibRemovedIfAddrSetIpAddr,
+ nhdpLibRemovedIfAddrSetIpAddrPrefixLen,
+ nhdpLibRemovedIfAddrSetIfIndex,
+ nhdpLibRemovedIfAddrSetIRTime
+ }
+ STATUS current
+ DESCRIPTION
+ "Set of NHDP configuration objects implemented
+ in this module."
+ ::= { nhdpMIBGroups 2 }
+
+ nhdpPerformanceGroup OBJECT-GROUP
+ OBJECTS {
+ nhdpIfHelloMessageXmits,
+ nhdpIfHelloMessageRecvd,
+ nhdpIfHelloMessageXmitAccumulatedSize,
+ nhdpIfHelloMessageRecvdAccumulatedSize,
+ nhdpIfHelloMessageTriggeredXmits,
+ nhdpIfHelloMessagePeriodicXmits,
+ nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount,
+ nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount,
+ nhdpIfHelloMessageXmitAccumulatedLostNeighborCount,
+ nhdpIfPerfCounterDiscontinuityTime,
+ nhdpDiscIfRecvdPackets,
+ nhdpDiscIfExpectedPackets,
+ nhdpNibNeighborSetChanges,
+ nhdpDiscNeighborNibNeighborSetChanges,
+ nhdpDiscNeighborNibNeighborSetUpTime,
+ nhdpDiscNeighborNibNeighborSetReachableLinkChanges,
+ nhdpIib2HopSetPerfChanges,
+ nhdpIib2HopSetPerfUpTime
+ }
+ STATUS current
+ DESCRIPTION
+ "Set of NHDP performance objects implemented
+ in this module."
+ ::= { nhdpMIBGroups 4 }
+
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 63]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ nhdpNotificationObjectGroup OBJECT-GROUP
+ OBJECTS {
+ nhdpNbrStateChangeThreshold,
+ nhdpNbrStateChangeWindow,
+ nhdp2HopNbrStateChangeThreshold,
+ nhdp2HopNbrStateChangeWindow,
+ nhdpNbrState,
+ nhdp2HopNbrState
+ }
+ STATUS current
+ DESCRIPTION
+ "Set of NHDP notification objects implemented
+ in this module."
+ ::= { nhdpMIBGroups 5 }
+
+ nhdpNotificationGroup NOTIFICATION-GROUP
+ NOTIFICATIONS {
+ nhdpNbrStateChange,
+ nhdp2HopNbrStateChange,
+ nhdpIfStateChange
+ }
+ STATUS current
+ DESCRIPTION
+ "Set of NHDP notifications implemented
+ in this module."
+ ::= { nhdpMIBGroups 6 }
+
+ nhdpStateGroup2 OBJECT-GROUP
+ OBJECTS {
+ nhdpUpTime,
+ nhdpIfStateUpTime,
+ nhdpDiscRouterIndex,
+ nhdpDiscIfIndex,
+ nhdpDiscIfSetIpAddrType,
+ nhdpDiscIfSetIpAddr,
+ nhdpDiscIfSetIpAddrPrefixLen,
+ nhdpIibLinkSetLHeardTime,
+ nhdpIibLinkSetLSymTime,
+ nhdpIibLinkSetLPending,
+ nhdpIibLinkSetLLost,
+ nhdpIibLinkSetLTime,
+ nhdpIib2HopSetIpAddrPrefixLen,
+ nhdpIib2HopSet1HopIfIndex,
+ nhdpIib2HopSetN2Time,
+ nhdpIib2HopSetN2Lost,
+ nhdpNibNeighborSetNSymmetric,
+ nhdpNibLostNeighborSetNLTime
+ }
+
+
+
+Herberg, et al. Standards Track [Page 64]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ STATUS current
+ DESCRIPTION
+ "Set of NHDP state objects implemented
+ in this module."
+ ::= { nhdpMIBGroups 7 }
+
+
+--
+-- Deprecated compliance statements and groups
+--
+
+ nhdpFullCompliance MODULE-COMPLIANCE
+ STATUS deprecated
+ DESCRIPTION
+ "The full implementation requirements for
+ managed network entities that implement
+ NHDP.
+
+ For version-independence, this compliance statement
+ is deprecated in favor of nhdpFullCompliance2."
+ MODULE -- this module
+ MANDATORY-GROUPS { nhdpConfigurationGroup,
+ nhdpStateGroup,
+ nhdpNotificationObjectGroup,
+ nhdpNotificationGroup,
+ nhdpPerformanceGroup
+ }
+ ::= { nhdpCompliances 2 }
+
+ nhdpStateGroup OBJECT-GROUP
+ OBJECTS {
+ nhdpUpTime,
+ nhdpIfStateUpTime,
+ nhdpDiscRouterIndex,
+ nhdpDiscIfIndex,
+ nhdpDiscIfSetIpAddrType,
+ nhdpDiscIfSetIpAddr,
+ nhdpDiscIfSetIpAddrPrefixLen,
+ nhdpIibLinkSetLHeardTime,
+ nhdpIibLinkSetLSymTime,
+ nhdpIibLinkSetLPending,
+ nhdpIibLinkSetLLost,
+ nhdpIibLinkSetLTime,
+ nhdpIib2HopSetIpAddrPrefixLen,
+ nhdpIib2HopSet1HopIfIndex,
+ nhdpIib2HopSetN2Time,
+ nhdpNibNeighborSetNSymmetric,
+ nhdpNibLostNeighborSetNLTime
+
+
+
+Herberg, et al. Standards Track [Page 65]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ }
+ STATUS deprecated
+ DESCRIPTION
+ "Set of NHDP state objects implemented
+ in this module.
+
+ For version-independence, this compliance statement
+ is deprecated in favor of nhdpStateGroup2."
+ ::= { nhdpMIBGroups 3 }
+
+
+END
+
+8. Security Considerations
+
+ This MIB module defines objects for the configuration, monitoring,
+ and notification of the Mobile Ad Hoc Network (MANET) Neighborhood
+ Discovery Protocol (NHDP) [RFC6130]. 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:
+
+ o 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.
+
+ o 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.
+
+ o 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.
+
+
+
+Herberg, et al. Standards Track [Page 66]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ o 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:
+
+ o 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-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) [RFC5591] in
+ combination with TLS/DTLS [RFC6353].
+
+ 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 [RFC3410]), and implementations claiming
+ compliance to the SNMPv3 standard MUST include full support for
+ authentication and privacy via the User-based Security Model (USM)
+ [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations
+ MAY also provide support for the Transport Security Model (TSM)
+ [RFC5591] in combination with a secure transport such as SSH
+ [RFC5592] or TLS/DTLS [RFC6353].
+
+
+
+Herberg, et al. Standards Track [Page 67]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ 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.
+
+9. Applicability Statement
+
+ This document describes objects for configuring parameters of the
+ Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
+ [RFC6130] 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:
+
+ o 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.
+
+ o 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.
+
+ o 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
+
+
+
+Herberg, et al. Standards Track [Page 68]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ vehicles. Standards-based methods for configuration, monitoring,
+ and fault management are necessary for this deployment option.
+
+10. IANA Considerations
+
+ The MIB module in this document uses the following IANA-assigned
+ OBJECT IDENTIFIER value recorded in the SMI Numbers registry:
+
+ Description OBJECT IDENTIFIER value
+ ----------- -----------------------
+ NHDP-MIB { mib-2 213 }
+
+11. References
+
+11.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
+ Schoenwaelder, Ed., "Structure of Management Information
+ Version 2 (SMIv2)", STD 58, RFC 2578,
+ DOI 10.17487/RFC2578, April 1999,
+ <http://www.rfc-editor.org/info/rfc2578>.
+
+ [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
+ Schoenwaelder, Ed., "Textual Conventions for SMIv2",
+ STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999,
+ <http://www.rfc-editor.org/info/rfc2579>.
+
+ [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J.
+ Schoenwaelder, Ed., "Conformance Statements for SMIv2",
+ STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999,
+ <http://www.rfc-editor.org/info/rfc2580>.
+
+ [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
+ MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
+ <http://www.rfc-editor.org/info/rfc2863>.
+
+ [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
+ (USM) for version 3 of the Simple Network Management
+ Protocol (SNMPv3)", STD 62, RFC 3414,
+ DOI 10.17487/RFC3414, December 2002,
+ <http://www.rfc-editor.org/info/rfc3414>.
+
+
+
+
+
+Herberg, et al. Standards Track [Page 69]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+ [RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for
+ the Simple Network Management Protocol (SNMP)", STD 62,
+ RFC 3418, DOI 10.17487/RFC3418, December 2002,
+ <http://www.rfc-editor.org/info/rfc3418>.
+
+ [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
+ Advanced Encryption Standard (AES) Cipher Algorithm in the
+ SNMP User-based Security Model", RFC 3826,
+ DOI 10.17487/RFC3826, June 2004,
+ <http://www.rfc-editor.org/info/rfc3826>.
+
+ [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
+ Schoenwaelder, "Textual Conventions for Internet Network
+ Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005,
+ <http://www.rfc-editor.org/info/rfc4001>.
+
+ [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model
+ for the Simple Network Management Protocol (SNMP)",
+ STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009,
+ <http://www.rfc-editor.org/info/rfc5591>.
+
+ [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
+ Shell Transport Model for the Simple Network Management
+ Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June
+ 2009, <http://www.rfc-editor.org/info/rfc5592>.
+
+ [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
+ Network (MANET) Neighborhood Discovery Protocol (NHDP)",
+ RFC 6130, DOI 10.17487/RFC6130, April 2011,
+ <http://www.rfc-editor.org/info/rfc6130>.
+
+ [RFC6340] Presuhn, R., "Textual Conventions for the Representation
+ of Floating-Point Numbers", RFC 6340,
+ DOI 10.17487/RFC6340, August 2011,
+ <http://www.rfc-editor.org/info/rfc6340>.
+
+ [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
+ Model for the Simple Network Management Protocol (SNMP)",
+ STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011,
+ <http://www.rfc-editor.org/info/rfc6353>.
+
+ [RFC7466] Dearlove, C. and T. Clausen, "An Optimization for the
+ Mobile Ad Hoc Network (MANET) Neighborhood Discovery
+ Protocol (NHDP)", RFC 7466, DOI 10.17487/RFC7466, March
+ 2015, <http://www.rfc-editor.org/info/rfc7466>.
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 70]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+11.2. Informative References
+
+ [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
+ "Introduction and Applicability Statements for Internet-
+ Standard Management Framework", RFC 3410,
+ DOI 10.17487/RFC3410, December 2002,
+ <http://www.rfc-editor.org/info/rfc3410>.
+
+ [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
+ Architecture for Describing Simple Network Management
+ Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
+ DOI 10.17487/RFC3411, December 2002,
+ <http://www.rfc-editor.org/info/rfc3411>.
+
+ [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed.,
+ Coltun, R., and F. Baker, "OSPF Version 2 Management
+ Information Base", RFC 4750, DOI 10.17487/RFC4750,
+ December 2006, <http://www.rfc-editor.org/info/rfc4750>.
+
+ [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
+ Considerations in Mobile Ad Hoc Networks (MANETs)",
+ RFC 5148, DOI 10.17487/RFC5148, February 2008,
+ <http://www.rfc-editor.org/info/rfc5148>.
+
+ [RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of
+ Managed Objects for the Neighborhood Discovery Protocol",
+ RFC 6779, DOI 10.17487/RFC6779, October 2012,
+ <http://www.rfc-editor.org/info/rfc6779>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herberg, et al. Standards Track [Page 71]
+
+RFC 7939 The NHDP-MIB August 2016
+
+
+Acknowledgements
+
+ 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.
+
+Authors' Addresses
+
+ Ulrich Herberg
+ United States of America
+
+ Email: ulrich@herberg.name
+ URI: http://www.herberg.name/
+
+
+ Robert G. Cole
+ US Army CERDEC
+ Space and Terrestrial Communications
+ 6010 Frankford Road
+ Aberdeen Proving Ground, Maryland 21005
+ United States of America
+
+ Phone: +1 443 395-8744
+ Email: rgcole01@comcast.net
+ URI: http://www.cs.jhu.edu/~rgcole/
+
+
+ Ian D Chakeres
+ Delvin
+ Ellicott City, Maryland 21042
+ United States of America
+
+ Email: ian.chakeres@gmail.com
+ URI: http://www.ianchak.com/
+
+
+ Thomas Heide Clausen
+ Ecole Polytechnique
+
+ Phone: +33 6 6058 9349
+ Email: T.Clausen@computer.org
+ URI: http://www.ThomasClausen.org/
+
+
+
+
+Herberg, et al. Standards Track [Page 72]
+