diff options
Diffstat (limited to 'doc/rfc/rfc6779.txt')
| -rw-r--r-- | doc/rfc/rfc6779.txt | 3755 |
1 files changed, 3755 insertions, 0 deletions
diff --git a/doc/rfc/rfc6779.txt b/doc/rfc/rfc6779.txt new file mode 100644 index 0000000..520f8ab --- /dev/null +++ b/doc/rfc/rfc6779.txt @@ -0,0 +1,3755 @@ + + + + + + +Internet Engineering Task Force (IETF) U. Herberg +Request for Comments: 6779 LIX, Ecole Polytechnique +Category: Standards Track R. Cole +ISSN: 2070-1721 US Army CERDEC + I. Chakeres + DRS CenGen + October 2012 + + + Definition of Managed Objects for the Neighborhood Discovery Protocol + +Abstract + + 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 Neighborhood Discovery Protocol (NHDP) process on a + router. The MIB module defined in this document, denoted NHDP-MIB, + also reports state, performance information, and notifications about + NHDP. This additional state and performance information is useful to + troubleshoot problems and performance issues during neighbor + discovery. + +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 5741. + + 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/rfc6779. + + + + + + + + + + + + + + + +Herberg, et al. Standards Track [Page 1] + +RFC 6779 The NHDP-MIB October 2012 + + +Copyright Notice + + Copyright (c) 2012 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 + 2. The Internet-Standard Management Framework . . . . . . . . . . 3 + 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 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 . . . . . . . . . . . . . . . . . 6 + 5.3. The State Group . . . . . . . . . . . . . . . . . . . . . 7 + 5.4. The Performance Group . . . . . . . . . . . . . . . . . . 7 + 5.5. Tables and Indexing . . . . . . . . . . . . . . . . . . . 7 + 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 9 + 6.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . . . 9 + 6.2. Relationship to Routing Protocol MIB Modules Relying + on the NHDP-MIB Module . . . . . . . . . . . . . . . . . . 10 + 6.3. MIB Modules Required for IMPORTS . . . . . . . . . . . . . 10 + 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 62 + 9. Applicability Statement . . . . . . . . . . . . . . . . . . . 64 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 65 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 66 + + + + + + +Herberg, et al. Standards Track [Page 2] + +RFC 6779 The NHDP-MIB October 2012 + + +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 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. + +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]. + +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. + + + + + + + + + + +Herberg, et al. Standards Track [Page 3] + +RFC 6779 The NHDP-MIB October 2012 + + +4.1. Terms + + The following definitions apply throughout this document: + + o Notification Objects - triggers and associated notification + messages allowing for asynchronous tracking of pre-defined 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 an + administrator or automated tool to assess the performance of the + NHDP instance on the router and the overall discovery performance + within the Mobile Ad Hoc Network (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. + + 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. + + + + +Herberg, et al. Standards Track [Page 4] + +RFC 6779 The NHDP-MIB October 2012 + + +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 a + network manager to efficiently determine the source of problems or + significant changes of configuration or topology, instead of polling + a possibly large number of 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 network manager may + determine the source of the notification. + +5.1.3. Limiting Frequency of Notifications + + To limit the frequency of notifications, the following additional + mechanisms are suggested, similar to those in [RFC4750]. + +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 two-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 certain time interval has + elapsed, which is to be predefined by the network manager. It is + RECOMMENDED that this time interval is at least 3 x + 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). + + + +Herberg, et al. Standards Track [Page 5] + +RFC 6779 The NHDP-MIB October 2012 + + + Appropriate values for the window time and upper bound are to be + selected by the network manager and depend on the deployment of the + MANET. 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. It is RECOMMENDED that if the number + of occurrences exceeds the change threshold within the previous + change window, then the notification is to 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. + +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. + + + + + + + + + +Herberg, et al. Standards Track [Page 6] + +RFC 6779 The NHDP-MIB October 2012 + + +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. + +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 + the network administrator to determine unusual topology changes or + other changes that affect stability and reliability of the MANET. + One such framework is specified in [REPORT-MIB]. + +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, + + + +Herberg, et al. Standards Track [Page 7] + +RFC 6779 The NHDP-MIB October 2012 + + + o other routers that are 1 hop removed from the local router, + + o interfaces on other routers that are 1 hop removed from the local + router, and + + o other routers that are 2 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 }. + + 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 }. + + + + + +Herberg, et al. Standards Track [Page 8] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 }. + + 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. + + + +Herberg, et al. Standards Track [Page 9] + +RFC 6779 The NHDP-MIB October 2012 + + +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. 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], 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) - The Neighborhood Discovery Protocol, +-- 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 + + + + +Herberg, et al. Standards Track [Page 10] + +RFC 6779 The NHDP-MIB October 2012 + + + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB -- RFC 3411 + + 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 "201210221000Z" -- 22 October 2012 + ORGANIZATION "IETF MANET Working Group" + CONTACT-INFO + "WG E-Mail: manet@ietf.org + + WG Chairs: sratliff@cisco.com + jmacker@nrl.navy.mil + + + Editors: Ulrich Herberg + LIX, Ecole Polytechnique + 91128 Palaiseau Cedex + France + + ulrich@herberg.name + http://www.herberg.name/ + + + Robert G. Cole + US Army CERDEC + Space and Terrestrial Communications + 6010 Frankford Street + Bldg 6010, Room 453H + Aberdeen Proving Ground, Maryland 21005 + USA + +1 443 395-8744 + + robert.g.cole@us.army.mil + http://www.cs.jhu.edu/~rgcole/ + + + + + + + + +Herberg, et al. Standards Track [Page 11] + +RFC 6779 The NHDP-MIB October 2012 + + + Ian D Chakeres + DRS CenGen + 9250 Bendix Road North + Columbia, Maryland 21045 + USA + + ian.chakeres@gmail.com + http://www.ianchak.com/" + + DESCRIPTION + "This NHDP-MIB module is applicable to routers + implementing the Neighborhood Discovery Protocol + defined in RFC 6130. + + Copyright (c) 2012 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). + + This version of this MIB module is part of RFC 6779; see + the RFC itself for full legal notices." + + -- revision + 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 + + + +Herberg, et al. Standards Track [Page 12] + +RFC 6779 The NHDP-MIB October 2012 + + + -- 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 + -- 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 IpAddrs 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. + + + + + +Herberg, et al. Standards Track [Page 13] + +RFC 6779 The NHDP-MIB October 2012 + + + 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, + 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 + + + +Herberg, et al. Standards Track [Page 14] + +RFC 6779 The NHDP-MIB October 2012 + + + until the next agent restart." + SYNTAX Unsigned32 (1..2147483647) + +-- +-- 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 either a manager has explicitly created the row + or there is an interface on the managed device + that supports and runs NHDP. + + The manager can create a row by setting + rowStatus to 'createAndGo' or 'createAndWait'. + Row objects having associated DEFVAL clauses are + automatically defined by the agent with these + values during row creation, unless the manager + explicitly defines these object values during the + row creation. + + + + +Herberg, et al. Standards Track [Page 15] + +RFC 6779 The NHDP-MIB October 2012 + + + If the corresponding entry with ifIndex value + is deleted from the Interface Table, then the entry + in this table 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." + 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 + non-volatile 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 + + + +Herberg, et al. Standards Track [Page 16] + +RFC 6779 The NHDP-MIB October 2012 + + + Unsigned32, + nhdpHystAcceptQuality + Float32TC, + 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 17] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 + DESCRIPTION + "nhdpHelloMinInterval corresponds to + HELLO_MIN_INTERVAL of NHDP and represents + + + +Herberg, et al. Standards Track [Page 18] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 + -- + + nhdpLHoldTime OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + + + +Herberg, et al. Standards Track [Page 19] + +RFC 6779 The NHDP-MIB October 2012 + + + 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." + REFERENCE + "Section 5 on Protocol Parameters and + Constraints of RFC 6130 - Mobile Ad Hoc Network + + + +Herberg, et al. Standards Track [Page 20] + +RFC 6779 The NHDP-MIB October 2012 + + + (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 + ::= { nhdpInterfaceEntry 9 } + + nhdpHystRejectQuality OBJECT-TYPE + SYNTAX Float32TC + MAX-ACCESS read-create + STATUS current + DESCRIPTION + + + +Herberg, et al. Standards Track [Page 21] + +RFC 6779 The NHDP-MIB October 2012 + + + "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), + 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 + + + +Herberg, et al. Standards Track [Page 22] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 } + + -- + -- Interface Parameters - Jitter + -- + nhdpHpMaxJitter OBJECT-TYPE + SYNTAX Unsigned32 + UNITS "milliseconds" + MAX-ACCESS read-create + + + +Herberg, et al. Standards Track [Page 23] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 + 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), + + + +Herberg, et al. Standards Track [Page 24] + +RFC 6779 The NHDP-MIB October 2012 + + + 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, then the network manager MUST + specify the value of this object 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 non-volatile (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 non-volatile + 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." + 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 + -- + + + +Herberg, et al. Standards Track [Page 25] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 + non-volatile 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. + + This object is persistent, and when written, + the entity SHOULD save the change to + non-volatile 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 } + + + + +Herberg, et al. Standards Track [Page 26] + +RFC 6779 The NHDP-MIB October 2012 + + + -- 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 a manager has explicitly created the row. The + manager can create a row 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 } + + nhdpLibLocalIfSetEntry OBJECT-TYPE + SYNTAX NhdpLibLocalIfSetEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A router's Local Interface Set consists + of Configured Interface Address Tuples for each network + interface. + + + + +Herberg, et al. Standards Track [Page 27] + +RFC 6779 The NHDP-MIB October 2012 + + + The objects in this table are persistent, and when + written, the device SHOULD save the change to + non-volatile 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." + 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 + + + +Herberg, et al. Standards Track [Page 28] + +RFC 6779 The NHDP-MIB October 2012 + + + "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." + 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 + + + +Herberg, et al. Standards Track [Page 29] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 non-volatile (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 non-volatile + 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 + -- + + + + +Herberg, et al. Standards Track [Page 30] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 the Standard MIB II's + IP address table (RFC 1213)." + REFERENCE + "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 + + + +Herberg, et al. Standards Track [Page 31] + +RFC 6779 The NHDP-MIB October 2012 + + + 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). + + 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, + + + +Herberg, et al. Standards Track [Page 32] + +RFC 6779 The NHDP-MIB October 2012 + + + 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." + 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 } + + + + +Herberg, et al. Standards Track [Page 33] + +RFC 6779 The NHDP-MIB October 2012 + + +-- +-- 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. + + The objects in this table are persistent, and when + written, the entity SHOULD save the change to + non-volatile 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 } + + + + +Herberg, et al. Standards Track [Page 34] + +RFC 6779 The NHDP-MIB October 2012 + + + 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." + 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 + + + +Herberg, et al. Standards Track [Page 35] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 + 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 + + + +Herberg, et al. Standards Track [Page 36] + +RFC 6779 The NHDP-MIB October 2012 + + + "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). + + 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" + + + +Herberg, et al. Standards Track [Page 37] + +RFC 6779 The NHDP-MIB October 2012 + + + ::= { 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 + -- + + 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: + + + +Herberg, et al. Standards Track [Page 38] + +RFC 6779 The NHDP-MIB October 2012 + + + (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 } + + 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 + + + +Herberg, et al. Standards Track [Page 39] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 } + + 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, + + + +Herberg, et al. Standards Track [Page 40] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 } + + -- + -- 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_time). + + + +Herberg, et al. Standards Track [Page 41] + +RFC 6779 The NHDP-MIB October 2012 + + + The entries include the 2-hop neighbor addresses, + which act as the table index, and associated + 1-hop symmetric link address set, designated + through nhdpDiscIfIndex, and an expiration 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 represents the 1-hop neighbor interface + through which these 2-hop addresses are + reachable." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + INDEX { nhdpIfIndex, + nhdpDiscIfIndex, + nhdpIib2HopSetIpAddressType, + nhdpIib2HopSetIpAddress + } + ::= { nhdpIib2HopSetTable 1 } + + NhdpIib2HopSetEntry ::= + SEQUENCE { + nhdpIib2HopSetIpAddressType + InetAddressType, + nhdpIib2HopSetIpAddress + InetAddress, + nhdpIib2HopSetIpAddrPrefixLen + InetAddressPrefixLength, + nhdpIib2HopSet1HopIfIndex + NeighborIfIndex, + nhdpIib2HopSetN2Time + TimeStamp + } + + 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." + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + + + +Herberg, et al. Standards Track [Page 42] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 + neighbor that communicated the ipAddress + of the 2-hop neighbor in this row entry." + + + +Herberg, et al. Standards Track [Page 43] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 } + + -- + -- Neighbor Information Base (NIB) + -- + -- Each router maintains a Neighbor Information Base + -- that records information about addresses of + -- current and recently symmetric 1-hop neighbors. + + -- + -- 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 } + + + +Herberg, et al. Standards Track [Page 44] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 + 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 + + + +Herberg, et al. Standards Track [Page 45] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 } + + 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 +-- + + + +Herberg, et al. Standards Track [Page 46] + +RFC 6779 The NHDP-MIB October 2012 + + +-- 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." + 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 + + + +Herberg, et al. Standards Track [Page 47] + +RFC 6779 The NHDP-MIB October 2012 + + + Counter32, + nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount + Counter32, + nhdpIfHelloMessageXmitAccumulatedLostNeighborCount + Counter32 + } + + 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." + ::= { 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 } + + + +Herberg, et al. Standards Track [Page 48] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 + "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 + + + +Herberg, et al. Standards Track [Page 49] + +RFC 6779 The NHDP-MIB October 2012 + + + "A counter is incremented by the number of advertised + lost neighbors in a HELLO each time a HELLO + message has been sent." + ::= { nhdpInterfacePerfEntry 9 } + + -- + -- 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 + + + +Herberg, et al. Standards Track [Page 50] + +RFC 6779 The NHDP-MIB October 2012 + + + DESCRIPTION + "This counter increments 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 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 + + + +Herberg, et al. Standards Track [Page 51] + +RFC 6779 The NHDP-MIB October 2012 + + + MAX-ACCESS not-accessible + STATUS current + 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, + + + +Herberg, et al. Standards Track [Page 52] + +RFC 6779 The NHDP-MIB October 2012 + + + C., and J. Dean, April 2011" + ::= { nhdpDiscNeighborSetPerfEntry 1 } + + nhdpDiscNeighborNibNeighborSetUpTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "This object returns the sysUpTime when + the neighbor becomes 'nbrup'. A neighbor is + said to become 'nbrup' if a new nhdpNibNeighborSetEntry + is created for a particular nhdpNibNeighborSetRouterIndex. + It becomes 'nbrdown' if the entry for that neighbor + has been deleted." + 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." + + + +Herberg, et al. Standards Track [Page 53] + +RFC 6779 The NHDP-MIB October 2012 + + + REFERENCE + "RFC 6130 - Mobile Ad Hoc Network (MANET) Neighborhood + Discovery Protocol (NHDP), Clausen, T., Dearlove, + C., and J. Dean, April 2011" + ::= { nhdpPerformanceObjGrp 5 } + + 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 + + + +Herberg, et al. Standards Track [Page 54] + +RFC 6779 The NHDP-MIB October 2012 + + + 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." + 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 status (i.e., 'down(0)' or + 'up(1)') within a time window of + nhdp2HopNbrStateChangeWindow." + ::= { nhdpNotificationsObjects 2 } + + + +Herberg, et al. Standards Track [Page 55] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 56] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 } + + -- nhdpNotificationStates + + + + +Herberg, et al. Standards Track [Page 57] + +RFC 6779 The NHDP-MIB October 2012 + + + 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) + } + 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 'up(1)'." + ::= { nhdpNotificationsStates 2 } + +-- +-- nhdpConformance information +-- + +nhdpCompliances OBJECT IDENTIFIER ::= { nhdpConformance 1 } +nhdpMIBGroups OBJECT IDENTIFIER ::= { nhdpConformance 2 } + + -- Compliance Statements + nhdpBasicCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The basic implementation requirements for + managed network entities that implement + NHDP." + + + +Herberg, et al. Standards Track [Page 58] + +RFC 6779 The NHDP-MIB October 2012 + + + MODULE -- this module + MANDATORY-GROUPS { nhdpConfigurationGroup } + ::= { nhdpCompliances 1 } + + nhdpFullCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The full implementation requirements for + managed network entities that implement + NHDP." + MODULE -- this module + MANDATORY-GROUPS { nhdpConfigurationGroup, + nhdpStateGroup, + nhdpNotificationObjectGroup, + nhdpNotificationGroup, + nhdpPerformanceGroup + } + ::= { nhdpCompliances 2 } + +-- +-- Units of Conformance +-- + + nhdpConfigurationGroup OBJECT-GROUP + OBJECTS { + nhdpIfName, + nhdpIfStatus, + nhdpHelloInterval, + nhdpHelloMinInterval, + nhdpRefreshInterval, + nhdpLHoldTime, + nhdpHHoldTime, + nhdpHystAcceptQuality, + nhdpHystRejectQuality, + nhdpInitialQuality, + nhdpInitialPending, + nhdpHpMaxJitter, + nhdpHtMaxJitter, + nhdpNHoldTime, + nhdpIHoldTime, + nhdpIfRowStatus, + nhdpLibLocalIfSetIfIndex, + nhdpLibLocalIfSetIpAddrType, + nhdpLibLocalIfSetIpAddr, + nhdpLibLocalIfSetIpAddrPrefixLen, + nhdpLibLocalIfSetRowStatus, + nhdpLibRemovedIfAddrSetIpAddrType, + nhdpLibRemovedIfAddrSetIpAddr, + + + +Herberg, et al. Standards Track [Page 59] + +RFC 6779 The NHDP-MIB October 2012 + + + nhdpLibRemovedIfAddrSetIpAddrPrefixLen, + nhdpLibRemovedIfAddrSetIfIndex, + nhdpLibRemovedIfAddrSetIRTime + } + STATUS current + DESCRIPTION + "Set of NHDP configuration objects implemented + in this module." + ::= { nhdpMIBGroups 2 } + + nhdpStateGroup OBJECT-GROUP + OBJECTS { + nhdpUpTime, + nhdpIfStateUpTime, + nhdpDiscRouterIndex, + nhdpDiscIfIndex, + nhdpDiscIfSetIpAddrType, + nhdpDiscIfSetIpAddr, + nhdpDiscIfSetIpAddrPrefixLen, + nhdpIibLinkSetLHeardTime, + nhdpIibLinkSetLSymTime, + nhdpIibLinkSetLPending, + nhdpIibLinkSetLLost, + nhdpIibLinkSetLTime, + nhdpIib2HopSetIpAddrPrefixLen, + nhdpIib2HopSet1HopIfIndex, + nhdpIib2HopSetN2Time, + nhdpNibNeighborSetNSymmetric, + nhdpNibLostNeighborSetNLTime + } + STATUS current + DESCRIPTION + "Set of NHDP state objects implemented + in this module." + ::= { nhdpMIBGroups 3 } + + nhdpPerformanceGroup OBJECT-GROUP + OBJECTS { + nhdpIfHelloMessageXmits, + nhdpIfHelloMessageRecvd, + nhdpIfHelloMessageXmitAccumulatedSize, + nhdpIfHelloMessageRecvdAccumulatedSize, + nhdpIfHelloMessageTriggeredXmits, + nhdpIfHelloMessagePeriodicXmits, + nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount, + nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount, + nhdpIfHelloMessageXmitAccumulatedLostNeighborCount, + nhdpDiscIfRecvdPackets, + + + +Herberg, et al. Standards Track [Page 60] + +RFC 6779 The NHDP-MIB October 2012 + + + nhdpDiscIfExpectedPackets, + nhdpNibNeighborSetChanges, + nhdpDiscNeighborNibNeighborSetChanges, + nhdpDiscNeighborNibNeighborSetUpTime, + nhdpDiscNeighborNibNeighborSetReachableLinkChanges, + nhdpIib2HopSetPerfChanges, + nhdpIib2HopSetPerfUpTime + } + STATUS current + DESCRIPTION + "Set of NHDP performance objects implemented + in this module." + ::= { nhdpMIBGroups 4 } + + 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 } + + +END + + + + + + + + +Herberg, et al. Standards Track [Page 61] + +RFC 6779 The NHDP-MIB October 2012 + + +8. Security Considerations + + This MIB module defines objects for the configuration, monitoring, + and notification of the Neighborhood Discovery Protocol [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 can have a negative effect on + network operations. 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. + + 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 + + + +Herberg, et al. Standards Track [Page 62] + +RFC 6779 The NHDP-MIB October 2012 + + + 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 MUST provide the security features described by the + SNMPv3 framework (see [RFC3410]), including 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]. + + 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. + + + + + + + +Herberg, et al. Standards Track [Page 63] + +RFC 6779 The NHDP-MIB October 2012 + + +9. Applicability Statement + + This document describes objects for configuring parameters of the + Neighborhood Discovery Protocol [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. A + fuller discussion of MANET network management use cases and + challenges will be provided elsewhere. + + NHDP is designed to allow routers to automatically discover and track + routers one hop remote (denoted "neighbors") and routers two hops + remote (denoted "two-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 Operation 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 + vehicles. Standards-based methods for configuration, monitoring, + and fault management are necessary for this deployment option. + + + + + + + + +Herberg, et al. Standards Track [Page 64] + +RFC 6779 The NHDP-MIB October 2012 + + +10. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER value recorded in the SMI Numbers registry: + + Descriptor OBJECT IDENTIFIER value + ---------- ----------------------- + NHDP-MIB { mib-2 213 } + +11. Acknowledgements + + The authors wish to thank Benoit Claise, Thomas Clausen, Justin Dean, + Adrian Farrel, Joel Halpern, Al Morton, and Thomas Nadeau for their + detailed reviews and insightful comments regarding 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. + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management + Information Version 2 (SMIv2)", STD 58, RFC 2578, + April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, June 2000. + + [RFC3418] Presuhn, R., "Management Information Base (MIB) for the + Simple Network Management Protocol (SNMP)", STD 62, + RFC 3418, December 2002. + + + + + + +Herberg, et al. Standards Track [Page 65] + +RFC 6779 The NHDP-MIB October 2012 + + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet + Network Addresses", RFC 4001, February 2005. + + [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc + Network (MANET) Neighborhood Discovery Protocol + (NHDP)", RFC 6130, April 2011. + + [RFC6340] Presuhn, R., "Textual Conventions for the + Representation of Floating-Point Numbers", RFC 6340, + August 2011. + +12.2. Informative References + + [REPORT-MIB] Cole, R., Macker, J., and A. Bierman, "Definition of + Managed Objects for Performance Reporting", Work + in Progress, January 2012. + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for + Internet-Standard Management Framework", RFC 3410, + December 2002. + + [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, + December 2002. + + [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The + Advanced Encryption Standard (AES) Cipher Algorithm in + the SNMP User-based Security Model", RFC 3826, + June 2004. + + [RFC4750] Joyal, D., Galecki, P., Giacalone, S., Coltun, R., and + F. Baker, "OSPF Version 2 Management Information Base", + RFC 4750, December 2006. + + [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter + Considerations in Mobile Ad Hoc Networks (MANETs)", + RFC 5148, February 2008. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security + Model for the Simple Network Management Protocol + (SNMP)", RFC 5591, June 2009. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 5592, June 2009. + + + +Herberg, et al. Standards Track [Page 66] + +RFC 6779 The NHDP-MIB October 2012 + + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport + Model for the Simple Network Management Protocol + (SNMP)", RFC 6353, July 2011. + +Authors' Addresses + + Ulrich Herberg + LIX, Ecole Polytechnique + 91128 Palaiseau Cedex + France + + EMail: ulrich@herberg.name + URI: http://www.herberg.name/ + + + Robert G. Cole + US Army CERDEC + Space and Terrestrial Communications + 6010 Frankford Road, Bldg 6010, Room 453H + Aberdeen Proving Ground, Maryland 21005 + United States + + Phone: +1 443 395-8744 + EMail: robert.g.cole@us.army.mil + URI: http://www.cs.jhu.edu/~rgcole/ + + + Ian D Chakeres + DRS CenGen + 9250 Bendix Road North + Columbia, Maryland 21045 + United States + + EMail: ian.chakeres@gmail.com + URI: http://www.ianchak.com/ + + + + + + + + + + + + + + + + +Herberg, et al. Standards Track [Page 67] + |