draft-ietf-manet-nhdp-mib-02.txt   draft-ietf-manet-nhdp-mib-03.txt 
Internet Engineering Task Force U. Herberg Internet Engineering Task Force U. Herberg
Internet-Draft LIX, Ecole Polytechnique Internet-Draft LIX, Ecole Polytechnique
Intended status: Standards Track R. Cole Intended status: Standards Track R. Cole
Expires: May 13, 2010 Johns Hopkins University Expires: September 9, 2010 Johns Hopkins University
I. Chakeres I. Chakeres
CenGen CenGen
November 9, 2009 March 8, 2010
Definition of Managed Objects for the Neighborhood Discovery Protocol Definition of Managed Objects for the Neighborhood Discovery Protocol
draft-ietf-manet-nhdp-mib-02 draft-ietf-manet-nhdp-mib-03
Abstract Abstract
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community. for use with network management protocols in the Internet community.
In particular, it describes objects for configuring aspects of the In particular, it describes objects for configuring aspects of the
Neighborhood Discovery Protocol (NHDP) process on a router. The NHDP Neighborhood Discovery Protocol (NHDP) process on a router. The NHDP
MIB also reports state information, performance information and MIB also reports state information, performance information and
notifications. This additional state and performance information is notifications. This additional state and performance information is
useful to management stations troubleshooting neighbor discovery useful to management stations troubleshooting neighbor discovery
skipping to change at page 1, line 46 skipping to change at page 1, line 46
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 13, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Internet-Standard Management Framework . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 3
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 4 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 4
5.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 4 5.1. The Configuration Group . . . . . . . . . . . . . . . . . 4
5.2. The Configuration Group . . . . . . . . . . . . . . . . . 4 5.1.1. Interface Parameters . . . . . . . . . . . . . . . . . 4
5.2.1. Interface Parameters . . . . . . . . . . . . . . . . . 4 5.1.2. Router Parameters . . . . . . . . . . . . . . . . . . 6
5.2.2. Router Parameters . . . . . . . . . . . . . . . . . . 8 5.2. The State Group . . . . . . . . . . . . . . . . . . . . . 6
5.3. The State Group . . . . . . . . . . . . . . . . . . . . . 8 5.3. The Performance Group . . . . . . . . . . . . . . . . . . 7
5.4. The Performance Group . . . . . . . . . . . . . . . . . . 10 5.4. Notifications . . . . . . . . . . . . . . . . . . . . . . 17
6. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 18
7. Relationship to Other MIB Modules . . . . . . . . . . . . . . 20 6.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . . . 18
7.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . . . 20 6.2. MIB modules required for IMPORTS . . . . . . . . . . . . . 18
7.2. Relationship to the IF-MIB . . . . . . . . . . . . . . . . 20 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3. MIB modules required for IMPORTS . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 61
8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
9. Security Considerations . . . . . . . . . . . . . . . . . . . 61 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 63
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 64 11.1. Normative References . . . . . . . . . . . . . . . . . . . 64
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64 11.2. Informative References . . . . . . . . . . . . . . . . . . 64
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
13.1. Normative References . . . . . . . . . . . . . . . . . . . 64
13.2. Informative References . . . . . . . . . . . . . . . . . . 65
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 65 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 65
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 66 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 66
Appendix C. . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Appendix C. . . . . . . . . . . . . . . . . . . . . . . . . . . 67
1. Introduction 1. Introduction
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community. for use with network management protocols in the Internet community.
In particular, it describes objects for configuring aspects of the In particular, it describes objects for configuring aspects of the
Neighborhood Discovery Protocol (NHDP) [NHDP] process on a router. Neighborhood Discovery Protocol (NHDP) [NHDP] process on a router.
The NHDP MIB also reports state information, performance information The NHDP MIB also reports state information, performance information
and notifications. This additional state and performance information and notifications. This additional state and performance information
is useful to management stations troubleshooting neighbor discovery is useful to management stations troubleshooting neighbor discovery
skipping to change at page 3, line 39 skipping to change at page 3, line 39
[RFC2580]. [RFC2580].
3. Conventions 3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
4. Overview 4. Overview
The NHDP protocol allows routers in a Mobile Ad-Hoc Network (MANET) The NHDP protocol allows a router in a Mobile Ad-Hoc Network (MANET)
to discover and track one-hop and two-hop neighbor sets. This to discover and track topological information of routers up to two
information is useful for routers running various routing and hops away by virtue of exchanging HELLO messages. This information
multicast flooding protocols developed within the IETF MANET Working is useful for routers running various routing and multicast flooding
Group. protocols developed within the IETF MANET Working Group.
4.1. Terms 4.1. Terms
The following definitions apply throughout this document: The following definitions apply throughout this document:
o Configuration Objects - switches, tables, objects which are o Configuration Objects - switches, tables, objects which are
initialized to default settings or set through the management initialized to default settings or set through the management
interface defined by this MIB. interface defined by this MIB.
o State Objects - automatically generated values which define the o State Objects - automatically generated values which define the
current operating state of the NHDP protocol process in the current operating state of the NHDP protocol process in the
router. router.
o Performance Objects - automatically generated values which help an o Performance Objects - automatically generated values which help an
administrator or automated tool to assess the performance of the administrator or automated tool to assess the performance of the
NHDP protocol process on the router and the overall discovery NHDP protocol process on the router and the overall discovery
performance within the NHDP domain. performance within the NHDP domain.
o Notification Objects - define triggers and associated notification
messages allowing for asynchronous tracking of pre-defined events
on the managed device.
5. Structure of the MIB Module 5. Structure of the MIB Module
This section presents the structure of the NHDP MIB module. The MIB This section presents the structure of the NHDP MIB module. The MIB
is arranged into the following structure: is arranged into the following structure:
o nhdpNotifications - objects defining NHDP MIB notifications.
o nhdpObjects - defining objects within this MIB. The objects are o nhdpObjects - defining objects within this MIB. The objects are
arranged into the following groups: arranged into the following groups:
* Configuration Group - defining objects related to the * Configuration Group - defining objects related to the
configuration of the NHDP instance on the device. configuration of the NHDP instance on the device.
* State Group - defining objects which reflect the current state * State Group - defining objects which reflect the current state
of the NHDP instance running on the device. of the NHDP instance running on the device.
* Performance Group - defining objects which are useful to a * Performance Group - defining objects which are useful to a
management station when characterizing the performance of the management station when characterizing the performance of NHDP
NHDP on the device and in the MANET. on the device and in the MANET.
o nhdpNotifications - objects defining NHDP MIB notifications.
o nhdpConformance - defining the minimal and maximal conformance o nhdpConformance - defining the minimal and maximal conformance
requirements for implementations of this MIB. requirements for implementations of this MIB.
5.1. Textual Conventions 5.1. The Configuration Group
This section is TBD.
5.2. The Configuration Group
The device is configured with a set of controls. The list of The device is configured with a set of controls. The list of
configuration controls for the NHDP-MIB (found in [NHDP]), are configuration controls for the NHDP-MIB (found in [NHDP]), are
discussed in the following subsections. discussed in the following subsections. For all of the configuration
parameters, the same constraints apply as specified in [NHDP]. The
default values of these parameters are defined in [NHDP]
5.2.1. Interface Parameters 5.1.1. Interface Parameters
The Interface Parameters include: The Interface Parameters include:
5.2.1.1. Message Intervals 5.1.1.1. Message Intervals
o HELLO_INTERVAL - is the maximum time between the transmission of o HELLO_INTERVAL - is the maximum time between the transmission of
two successive HELLO messages on this MANET interface. If using two successive HELLO messages on this MANET interface.
periodic transmission of HELLO messages, these SHOULD be at a
separation of HELLO_INTERVAL, possibly modified by jitter as
specified in [RFC5148].
o HELLO_MIN_INTERVAL - is the minimum interval between transmission o HELLO_MIN_INTERVAL - is the minimum interval between transmission
of two successive HELLO messages, on this MANET interface. (This of two successive HELLO messages, on this MANET interface.
minimum interval MAY be modified by jitter, as defined in
[RFC5148].)
o REFRESH_INTERVAL - is the maximum interval between advertisements, o REFRESH_INTERVAL - is the maximum interval between advertisements,
in a HELLO message on this MANET interface, of each 1-hop neighbor in a HELLO message on this MANET interface, of each 1-hop
network address and its status. In all intervals of length neighbor.
REFRESH_INTERVAL, a router MUST include each 1-hop neighbor
network address and its status in at least one HELLO message on
this MANET interface. (This may be in the same or in different
HELLO messages.)
The following constraints apply to these interface parameters:
o HELLO_INTERVAL > 0
o HELLO_MIN_INTERVAL >= 0
o HELLO_INTERVAL >= HELLO_MIN_INTERVAL
o REFRESH_INTERVAL >= HELLO_INTERVAL
o If an INTERVAL_TIME message TLV as defined in [RFC5497] is
included in a HELLO message, then HELLO_INTERVAL MUST be
representable as described in [RFC5497].
The following default values are recommended:
o HELLO_INTERVAL := 2 seconds
o HELLO_MIN_INTERVAL := HELLO_INTERVAL/4
o REFRESH_INTERVAL := HELLO_INTERVAL
5.2.1.2. Information Validity Times 5.1.1.2. Information Validity Times
Parameters related to the Information Validity Times include: Parameters related to the Information Validity Times include:
o L_HOLD_TIME - is the period of advertisement, on this MANET o L_HOLD_TIME - is the period of advertisement, on this MANET
interface, of former 1-hop neighbor network addresses as lost in interface, of former 1-hop neighbor network addresses as lost in
HELLO messages, allowing recipients of these HELLO messages to HELLO messages, allowing recipients of these HELLO messages to
accelerate removal of this information from their Link Sets. accelerate removal of this information from their Link Sets.
L_HOLD_TIME MAY be set to zero, if accelerated information removal
is not required.
o H_HOLD_TIME - is used as the Value in the VALIDITY_TIME Message o H_HOLD_TIME - is used as the Value in the VALIDITY_TIME Message
TLV included in all HELLO messages on this MANET interface. It is TLV included in all HELLO messages on this MANET interface. It is
then used by each router receiving such a HELLO message to then used by each router receiving such a HELLO message to
indicate the validity of the information taken from that HELLO indicate the validity of the information taken from that HELLO
message and recorded in the receiving router's Information Bases. message and recorded in the receiving router's Information Bases.
The following constraints apply to these interface parameters: 5.1.1.3. Link Quality
o L_HOLD_TIME >= 0
o H_HOLD_TIME >= REFRESH_INTERVAL
o If HELLO messages can be lost then both SHOULD be significantly
greater than REFRESH_INTERVAL.
o H_HOLD_TIME MUST be representable as described in [RFC5497].
The following default values are recommended:
o H_HOLD_TIME := 3 x REFRESH_INTERVAL
o L_HOLD_TIME := H_HOLD_TIME
5.2.1.3. Link Quality
Parameters related to the Link Quality include: Parameters related to the Link Quality include:
o HYST_ACCEPT - is the link quality threshold at or above which a o HYST_ACCEPT - is the link quality threshold at or above which a
link becomes usable, if it was not already so. link becomes usable, if it was not already so.
o HYST_REJECT - is the link quality threshold below which a link o HYST_REJECT - is the link quality threshold below which a link
becomes unusable, if it was not already so. becomes unusable, if it was not already so.
o INITIAL_QUALITY - is the initial quality of a newly identified o INITIAL_QUALITY - is the initial quality of a newly identified
link. link.
o INITIAL_PENDING - if true, then a newly identified link is o INITIAL_PENDING - if true, then a newly identified link is
considered pending, and is not usable until the link quality has considered pending, and is not usable until the link quality has
reached or exceeded the HYST_ACCEPT threshold. reached or exceeded the HYST_ACCEPT threshold.
The following constraints apply to these interface parameters: 5.1.1.4. Jitter
o 0 < = HYST_REJECT < = HYST_ACCEPT < = 1
o 0 < = INITIAL_QUALITY < = 1.
o If link quality is not updated, then INITIAL_QUALITY >=
HYST_ACCEPT.
o If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING := false.
o If INITIAL_QUALITY < HYST_REJECT, then INITIAL_PENDING := true.
Link quality is a mechanism whereby a router MAY take considerations
other than message exchange into account for determining when a link
is and is not a candidate for being considered as HEARD or SYMMETRIC.
As such, it is a "link admission" mechanism.
Link quality information for a link is generated (e.g., through
access to signal to noise ratio, packet loss rate, or other
information from the link layer) and used only locally, i.e. is not
included in signaling, and routers may interoperate whether they
areusing the same, different, or no, link quality information.
In order for a router to not employ link quality, the router MUST
define:
o INITIAL_PENDING := false
o INITIAL_QUALITY >= HYST_REJECT (there is no reason not to define
INITIAL_QUALITY := 1).
If link quality is changed, then parameter values will depend on the
link quality process. If link quality is not changed, then:
o HYST_ACCEPT := 1
o HYST_REJECT := 0
o INITIAL_QUALITY := 1
o INITIAL_PENDING := false
5.2.1.4. Jitter
If jitter, as defined in [RFC5148], is used then these parameters are If jitter, as defined in [RFC5148], is used then these parameters are
as follows: as follows:
o HP_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] o HP_MAXJITTER - represents the value of MAXJITTER used in [RFC5148]
for periodically generated HELLO messages on this MANET interface. for periodically generated HELLO messages on this MANET interface.
o HT_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] o HT_MAXJITTER - represents the value of MAXJITTER used in [RFC5148]
for externally triggered HELLO messages on this MANET interface. for externally triggered HELLO messages on this MANET interface.
For constraints on these interface parameters see [RFC5148]. 5.1.2. Router Parameters
The following default values are recommended:
o HP_MAXJITTER := HELLO_INTERVAL/4
o HT_MAXJITTER := HP_MAXJITTER
o C := 1/1024 second
5.2.2. Router Parameters
The following Router Parameters apply: The following Router Parameters apply:
5.2.2.1. Information Validity Time 5.1.2.1. Information Validity Time
o N_HOLD_TIME - is used as the period during which former 1-hop o N_HOLD_TIME - is used as the period during which former 1-hop
neighbor network addresses are advertised as lost in HELLO neighbor network addresses are advertised as lost in HELLO
messages, allowing recipients of these HELLO messages to messages, allowing recipients of these HELLO messages to
accelerate removal of this information from their 2-Hop Sets. accelerate removal of this information from their 2-Hop Sets.
N_HOLD_TIME MAY be set to zero, if accelerated information is not
required.
o I_HOLD_TIME - is the period for which a recently used local o I_HOLD_TIME - is the period for which a recently used local
interface network address is recorded. interface network address is recorded.
The following constraints applies to these router parameters: 5.2. The State Group
o N_HOLD_TIME >= 0
o I_HOLD_TIME >= 0
5.3. The State Group
The State Subtree reports current state information, including The State Subtree reports current state information, including
neighbor tables. These are separately discussed below. neighbor tables. These are separately discussed below.
The Local Information Base (LIB), contains the network addresses of The Local Information Base (LIB), contains the network addresses of
the interfaces (MANET and non-MANET) of this router. The contents of the interfaces (MANET and non-MANET) of this router. The contents of
this Information Base are not changed by signaling. The LIB contains this Information Base are not changed by signaling. The LIB contains
two tables: two tables:
o The "Local Interface Set", which records its local interfaces. It o The "Local Interface Set", which records its local interfaces. It
consists of Local Interface Tuples, one per interface. Note that consists of Local Interface Tuples, one per interface. Note that
the information from this set is contained in the the information from this set is contained in the
nhdpInterfaceTable, which is defined by this MIB document. nhdpInterfaceTable, which is defined by this MIB document.
Therefore, the Local Interface Set is not defined as an object in Therefore, the Local Interface Set is not defined as an object in
this MIB. this MIB.
o The "Removed Interface Address Set", which records network o The "Removed Interface Address Set", which records network
addresses which were recently used as local interface network addresses which were recently used as local interface network
addresses. If a router's interface network addresses are addresses. It consists of Removed Interface Address Tuples, one
immutable then the Removed Interface Address Set is always empty per network address.
and MAY be omitted. It consists of Removed Interface Address
Tuples, one per network address.
The Interface Information Based (IIB), recording information The Interface Information Based (IIB), recording information
regarding links to this MANET interface and symmetric 2-hop neighbors regarding links to this MANET interface and symmetric 2-hop neighbors
which can be reached through such links. The IIB contains two which can be reached through such links. The IIB contains two
tables: tables:
o A "Link Set", which records information about current and recently o A "Link Set", which records information about current and recently
lost links between this interface and MANET interfaces of 1-hop lost links between this interface and MANET interfaces of 1-hop
neighbors. The Link Set consists of Link Tuples, each of which neighbors. The Link Set consists of Link Tuples, each of which
contains information about a single link. Recently lost links are contains information about a single link.
recorded so that they can be advertised in HELLO messages,
accelerating their removal from relevant 1-hop neighbors' Link
Sets. Link quality information, if used and available, is
recorded in Link Tuples and may indicate that links are treated as
lost.
o A "Two-Hop Set", which records the existence of bidirectional o A "Two-Hop Set", which records the existence of bidirectional
links between symmetric 1-hop neighbors of this MANET interface links between symmetric 1-hop neighbors of this MANET interface
and other routers (symmetric 2-hop neighbors). The 2-Hop Set and other routers (symmetric 2-hop neighbors). The 2-Hop Set
consists of 2-Hop Tuples, each of which records an interface consists of 2-Hop Tuples, each of which records an interface
address of a symmetric 2-hop neighbor, and all interface addresses address of a symmetric 2-hop neighbor, and all interface addresses
of the corresponding symmetric 1-hop neighbor. The 2-Hop Set is of the corresponding symmetric 1-hop neighbor.
updated by the signaling of this protocol, but is not itself
reported in that signaling.
The Neighbor Information Base (NIB), records information regarding The Neighbor Information Base (NIB), records information regarding
current and recently lost 1-hop neighbors of this router. The NIB current and recently lost 1-hop neighbors of this router. The NIB
contains two tables: contains two tables:
o A "Neighbor Set", which records all network addresses of each o A "Neighbor Set", which records all network addresses of each
1-hop neighbor. It consists of Neighbor Tuples, each representing 1-hop neighbor. It consists of Neighbor Tuples, each representing
a single 1-hop neighbor a single 1-hop neighbor
o A "Lost Neighbor Set", which records network addresses of routers o A "Lost Neighbor Set", which records network addresses of routers
which recently were symmetric 1-hop neighbors, but which are now which recently were symmetric 1-hop neighbors, but which are now
advertised as lost. It consists of Lost Neighbor Tuples, each advertised as lost. It consists of Lost Neighbor Tuples, each
representing a single such network address representing a single such network address
5.4. The Performance Group 5.3. The Performance Group
The Performance Group reports values relevant to system performance. The Performance Group reports values relevant to system performance.
This section lists objects for NHDP performance monitoring, some of This section lists objects for NHDP performance monitoring, some of
which explicitly appear in the NHDP-MIB and others which are which explicitly appear in the NHDP-MIB and others which are
obtainable through a combination of base objects from this MIB and obtainable through a combination of base objects from this MIB and
reports available through the REPORT-MIB [REPORT]. Throughout this reports available through the REPORT-MIB [REPORT]. Throughout this
section those objects will be pointed out that are intended as base section those objects will be pointed out that are intended as base
objects which will be explicitly defined within this MIB and those objects which will be explicitly defined within this MIB and those
objects which are derived through a combination of the base objects objects which are derived through a combination of the base objects
and capabilities afforded by the REPORT-MIB. and capabilities afforded by the REPORT-MIB.
The objects described in the following can be useful for determining The objects described in the following can be useful for determining
certain properties of the NHDP instance. Notably unstable neighbors certain properties of the NHDP instance. Notably unstable neighbors
or 2-hop neighbors and frequent changes of sets can have a negative or 2-hop neighbors and frequent changes of sets can have a negative
influence on the performance of NHDP. The following objects thus influence on the performance of NHDP. The following objects allow
allow to acquire information related to the stability and performance management applications to acquire information related to the
of NHDP: stability and performance of NHDP:
The following objects return some of the statistics related to HELLO The following objects return some of the statistics related to HELLO
messages: messages:
o Total number of sent HELLO messages on an interface o Total number of sent HELLO messages on an interface
This is a Base Object. This is a Base Object.
Object name: nhdpIfHelloMessageXmits Object name: nhdpIfHelloMessageXmits
skipping to change at page 11, line 20 skipping to change at page 8, line 43
This is a Base Object. This is a Base Object.
Object name: nhdpIfHelloMessageTriggeredXmits Object name: nhdpIfHelloMessageTriggeredXmits
Object type: Counter32 Object type: Counter32
o Acquire history of HELLO message scheduling instance for the given o Acquire history of HELLO message scheduling instance for the given
time duration on an interface time duration on an interface
This object returns the history of the exact timestamps of each It is desirable to develop the history of the exact timestamps
HELLO message that has been sent as well as the type of the of each HELLO message that has been sent as well as the type of
message (triggered or periodical). The list of events starts the message (triggered or periodical). The list of events
at the given point of time t0 and ends at the given time t1. starts at the given point of time t0 and ends at the given time
t1.
This is a Derived Object to be pulled from the REPORT-MIB. It This is a Derived Object to be pulled from the REPORT-MIB. It
is derived from the XXX Base Object. is derived from, e.g., the nhdpIfHelloMessagePeriodicXmits Base
Object from the NHDP-MIB along with the capabilities derived
Object name: nhdpMessageSchedulingHistory from the reportHistoryGroup from the REPORT-MIB.
Object type: SEQUENCE OF (TimeStamp, nhdpMessageType) Object type: SEQUENCE OF (TimeStamp, nhdpMessageType)
o Histogram of the intervals between HELLO messages on an interface o Histogram of the intervals between HELLO messages on an interface
Returns the values (in a 2-dimensional array) that represent a It is desirable to track the values (in a 2-dimensional array)
histogram of intervals between HELLO messages, separated by that represent a histogram of intervals between HELLO messages,
periodic and triggered HELLOs. The histogram displays the separated by periodic and triggered HELLOs. The histogram
distribution of intervals between two consecutive HELLOs of the would display the distribution of intervals between two
same type (triggered or periodical) using a given bin size. It consecutive HELLOs of the same type (triggered or periodical)
includes all HELLOs that have been sent after the given time t0 using a given bin size. It includes all HELLOs that have been
and before the given time t1. sent after the given time t0 and before the given time t1.
This is a Derived Object to be pulled from the REPORT-MIB. It This is a Derived Object to be pulled from the REPORT-MIB. It
is derived from the XXX Base Object. can be derived from, e.g., the nhdpIfHelloMessagePeriodicXmits
Base Object from the NHDP-MIB along with the capabilities
Object name: nhdpMessageSchedulingHistogram derived from the reportHistoryGroup from the REPORT-MIB. The
network management application could convert this information
into the desired histogram.
Object type: SEQUENCE OF (nhdpMessageType, TimeTicks, Object type: SEQUENCE OF (nhdpMessageType, TimeTicks,
Unsigned32) Unsigned32)
o Changes of the frequency of the message scheduling on an interface o Changes of the frequency of the message scheduling on an interface
This object will divide the given time interval from t0 to t1 This object will divide the given time interval from t0 to t1
into a given number of equal parts. It then creates a into a given number of equal parts. It then creates a
histogram for each part and calculate the distances (using the histogram for each part and calculate the distances (using the
Bhattacharyya distance) between each two adjacent histograms in Bhattacharyya distance) between each two adjacent histograms in
time. A higher value between two histograms means more time. A higher value between two histograms means more
difference between the histograms. For instance, that could difference between the histograms. For instance, that could
happen if suddenly many triggered HELLO messages are sent, happen if suddenly many triggered HELLO messages are sent,
whereas before there have been only very few such triggered whereas before there have been only very few such triggered
messages. messages.
skipping to change at page 12, line 14 skipping to change at page 9, line 39
This object will divide the given time interval from t0 to t1 This object will divide the given time interval from t0 to t1
into a given number of equal parts. It then creates a into a given number of equal parts. It then creates a
histogram for each part and calculate the distances (using the histogram for each part and calculate the distances (using the
Bhattacharyya distance) between each two adjacent histograms in Bhattacharyya distance) between each two adjacent histograms in
time. A higher value between two histograms means more time. A higher value between two histograms means more
difference between the histograms. For instance, that could difference between the histograms. For instance, that could
happen if suddenly many triggered HELLO messages are sent, happen if suddenly many triggered HELLO messages are sent,
whereas before there have been only very few such triggered whereas before there have been only very few such triggered
messages. messages.
This is a Derived Object to be pulled from the REPORT-MIB. It This is a Derived Object to be pulled from the REPORT-MIB, as
is derived from the XXX Base Object. previously discussed, albeit this is a bit more complex with
respect to the management application.
Object name: nhdpMessageSchedulingFrequencyChanges
Object type: SEQUENCE OF (nhdpMessageType, TimeStamp, Float32) Object type: SEQUENCE OF (nhdpMessageType, TimeStamp, Float32)
o Average number of sent HELLO messages per second between the given o Average number of sent HELLO messages per second between the given
time t0 and t1 on an interface time t0 and t1 on an interface
This is a Derived Object to be pulled from the REPORT-MIB. It This is a Derived Object to be pulled from the
is derived from the XXX Base Object. reportSampledGroup from the REPORT-MIB. It is derived from,
e.g., the nhdpIfHelloMessageXmits Base Object.
Object name: nhdpHelloSentPerSecondCount
Object type: Float32 Object type: Float32
o Average number of received HELLO messages per second on an o Average number of received HELLO messages per second on an
interface between the given time t0 and t1 interface between the given time t0 and t1
This is a Derived Object to be pulled from the REPORT-MIB. It This is a Derived Object to be pulled from the REPORT-MIB. See
is derived from the XXX Base Object. the previous discussion.
Object name: nhdpHelloReceivedPerSecondCount
Object type: Float32 Object type: Float32
o Total accumulated size in octets of sent HELLO messages on an o Total accumulated size in octets of sent HELLO messages on an
interface interface
This is a Base Object. This is a Base Object.
Object name: nhdpIfHelloMessageXmitAccumulatedSize Object name: nhdpIfHelloMessageXmitAccumulatedSize
skipping to change at page 13, line 14 skipping to change at page 10, line 33
o Total accumulated size in octets of received HELLO messages on an o Total accumulated size in octets of received HELLO messages on an
interface interface
This is a Base Object. This is a Base Object.
Object name: nhdpIfHelloMessageRecvdAccumulatedSize Object name: nhdpIfHelloMessageRecvdAccumulatedSize
Object type: Counter32 Object type: Counter32
o Average size in octets of sent HELLO messages per second between o Average size in octets of sent HELLO messages between the given
the given time t0 and t1 on an interface time t0 and t1 on an interface.
This is a Derived Object to be pulled from the REPORT-MIB. It
is derived from the XXX Base Object.
Object name: nhdpHelloSentPerSecondOctets This is a Derived Object to be pulled from the
reportSampledGroup from the REPORT-MIB. It is derived from,
e.g., the nhdpIfHelloMessageRecvdAccumulatedSize Base Object
from this NHDP-MIB.
Object type: Float32 Object type: Float32
o Average size in octets of received HELLO messages per second o Average size in octets of received HELLO messages between the
between the given time t0 and t1 on an interface given time t0 and t1 on an interface
This is a Derived Object to be pulled from the REPORT-MIB. It
is derived from the XXX Base Object.
Object name: nhdpHelloReceivedPerSecondOctets This is a Derived Object to be pulled from the REPORT-MIB. See
previous discussion.
Object type: Float32 Object type: Float32
o Total accumulated number of advertized symmetric neighbors in o Total accumulated number of advertized symmetric neighbors in
HELLOs on that interface HELLOs on that interface.
This is a Base Object. This is a Base Object.
Object name: Object name:
nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
Object type: Counter32 Object type: Counter32
o Total accumulated number of advertized heard neighbors in HELLOs o Total accumulated number of advertized heard neighbors in HELLOs
on that interface on that interface
skipping to change at page 14, line 26 skipping to change at page 11, line 45
packet sequence number on an interface packet sequence number on an interface
This is a Base Object. This is a Base Object.
Object name: nhdpDiscIfExpectedPackets Object name: nhdpDiscIfExpectedPackets
Object type: Counter32 Object type: Counter32
o Success rate of received packets (number of received packets o Success rate of received packets (number of received packets
divided by number of expected packets based on the packet sequence divided by number of expected packets based on the packet sequence
number) number).
This is a Derived Object to be pulled from the REPORT-MIB. It
is derived from the XXX Base Object.
Object name: nhdpDiscIfRevdPacketsSuccessRate This is a Derived Object to be pulled from this NHDP-MIB. It
is derived from, e.g., the nhdpDiscIfRecvdPackets and the
nhdpDiscIfExpectedPackets Base Objects defined in this MIB.
This metric is then computed by the network management
application.
Object type: Float32 Object type: Float32
The following objects inspect the frequency of all Neighbor Set The following objects inspect the frequency of all Neighbor Set
changes: changes:
o Number of Neighbor Set changes o Number of Neighbor Set changes
This object counts each Neighbor Set change. A change occurs This object counts each Neighbor Set change. A change occurs
whenever a new Neighbor Tuple has been added, a Neighbor Tuple whenever a new Neighbor Tuple has been added, a Neighbor Tuple
skipping to change at page 15, line 4 skipping to change at page 12, line 20
o Number of Neighbor Set changes o Number of Neighbor Set changes
This object counts each Neighbor Set change. A change occurs This object counts each Neighbor Set change. A change occurs
whenever a new Neighbor Tuple has been added, a Neighbor Tuple whenever a new Neighbor Tuple has been added, a Neighbor Tuple
has been removed or any entry of a Neighbor Tuple has been has been removed or any entry of a Neighbor Tuple has been
modified. modified.
This is a Base Object. This is a Base Object.
Object name: nhdpNibNeighborSetChanges Object name: nhdpNibNeighborSetChanges
Object type: Counter32 Object type: Counter32
o Acquire history of Neighbor Set changes o Acquire history of Neighbor Set changes
This object returns the history of the exact timestamps of each This object returns the history of the exact timestamps of each
time the Neighbor Set has been changed. time the Neighbor Set has been changed.
This is a Derived Object to be pulled from the REPORT-MIB. It This is a Derived Object to be pulled from the
is derived from the XXX Base Object. reportHistoryGroup of the REPORT-MIB. It is derived from the
previously discussed Base Object.
Object name: nhdpNeighborChangeHistory
Object type: SEQUENCE OF TimeStamp Object type: SEQUENCE OF TimeStamp
o Histogram of the intervals between Neighbor Set changes o Histogram of the intervals between Neighbor Set changes
Returns the values (in a 2-dimensional array) that represent a Returns the values (in a 2-dimensional array) that represent a
histogram of intervals between Neighbor Set changes. histogram of intervals between Neighbor Set changes.
This is a Derived Object to be pulled from the REPORT-MIB. It This is a Derived Object to be pulled from the
is derived from the XXX Base Object. reportHistoryGroup from the REPORT-MIB. It is derived from the
previously discussed Base Object. The network management
Object name: nhdpNeighborChangeHistogram application would develop the histograms based upon lists
obtained from the REPORT-MIB.
Object type: SEQUENCE OF (TimeTicks, Unsigned32) Object type: SEQUENCE OF (TimeTicks, Unsigned32)
o Changes of the frequency of the Neighbor Set changes o Changes of the frequency of the Neighbor Set changes
This object will divide the given time interval from t0 to t1 This object will divide the given time interval from t0 to t1
into a given number of equal parts. It then creates a into a given number of equal parts. It then creates a
histogram for each part and calculate the distances (using the histogram for each part and calculate the distances (using the
Bhattacharyya distance) between each two adjacent histograms in Bhattacharyya distance) between each two adjacent histograms in
time. A higher value between two histograms means more time. A higher value between two histograms means more
difference between the histograms. difference between the histograms.
This is a Derived Object to be pulled from the REPORT-MIB. It This is a Derived Object to be pulled from the
is derived from the XXX Base Object. reportHistoryGroup from the REPORT-MIB. It is derived from the
previously discussed Base Object. The network management
Object name: nhdpNeighborChangeFrequencyChanges application could then compute the desired metrics.
Object type: SEQUENCE OF (TimeStamp, Float32) Object type: SEQUENCE OF (TimeStamp, Float32)
The next objects examine the uptime of a given neighbor: The next objects examine the uptime of a given neighbor:
o Number of changes of a Neighbor Tuple o Number of changes of a Neighbor Tuple
Returns the number of changes to the given Neighbor Tuple. Returns the number of changes to the given Neighbor Tuple.
This is a Base Object. This is a Base Object.
Object name: nhdpDiscNeighborNibNeighborSetChanges Object name: nhdpDiscNeighborNibNeighborSetChanges
Object type: Counter32 Object type: Counter32
o Neighbor uptime o Neighbor uptime
skipping to change at page 16, line 31 skipping to change at page 13, line 45
Object type: Unsigned32 Object type: Unsigned32
o Acquire history of change of onlink status of a given neighbor o Acquire history of change of onlink status of a given neighbor
This object returns the history of the exact timestamps of each This object returns the history of the exact timestamps of each
time the neighbor becomes onlink or offlink. A neighbor is time the neighbor becomes onlink or offlink. A neighbor is
said to become "onlink" if a new Neighbor Tuple is created that said to become "onlink" if a new Neighbor Tuple is created that
corresponds to the given neighbor. It becomes "offlink" if corresponds to the given neighbor. It becomes "offlink" if
such a tuple has been deleted. such a tuple has been deleted.
This is a Derived Object to be pulled from the REPORT-MIB. It This is a Derived Object to be pulled from the
is derived from the XXX Base Object. reportHistoryGroup of the REPORT-MIB. It is derived from,
e.g., the nhdpDiscNeighborNibNeighborSetChanges Base Object
Object name: nhdpNeighborStatusHistory defined in this MIB.
Object type: SEQUENCE OF TimeStamp Object type: SEQUENCE OF TimeStamp
o Histogram of the intervals between a change of the onlink status o Histogram of the intervals between a change of the onlink status
of a given neighbor of a given neighbor
Returns the values that represent a histogram of intervals Returns the values that represent a histogram of intervals
between a change of the onlink status of a given neighbor. The between a change of the onlink status of a given neighbor. The
histogram includes all changes that have been made after the histogram includes all changes that have been made after the
given time t0 and before the given time t1. given time t0 and before the given time t1.
This is a Derived Object to be pulled from the REPORT-MIB. It This is a Derived Object to be pulled from the
is derived from the XXX Base Object. reportHistoryGroup of the REPORT-MIB. It is derived from, e.g.
the nhdpDiscNeighborNibNeighborSetChanges Base Object defined
in this MIB. This object sits in the
nhdpDiscNeighborSetPerfTable which is indexed by the
nhdpDiscNeighborSetRouterId.
Object name: nhdpNeighborStatusHistogram Object name: nhdpNeighborStatusHistogram
Object type: SEQUENCE OF (TimeTicks, Unsigned32) Object type: SEQUENCE OF (TimeTicks, Unsigned32)
The following objects examine the stability of a neighbor. A The following objects examine the stability of a neighbor. A
neighbor is said to be unstable if it "flaps" frequently between neighbor is said to be unstable if it "flaps" frequently between
several links. It is said to be stable if the set of Link Tuples several links. It is said to be stable if the set of Link Tuples
that correspond to the given neighbor is stationary. that correspond to the given neighbor is stationary.
skipping to change at page 17, line 37 skipping to change at page 15, line 5
o Acquire history of changes of the interface over which a given o Acquire history of changes of the interface over which a given
neighbor can be reached. neighbor can be reached.
This object returns the history of the exact timestamps of each This object returns the history of the exact timestamps of each
time the neighbor changes the interface over which it is time the neighbor changes the interface over which it is
reachable. That means that the corresponding Link Tuple of the reachable. That means that the corresponding Link Tuple of the
given link moves from the Link Set of one interface to another given link moves from the Link Set of one interface to another
interface. interface.
This is a Derived Object to be pulled from the REPORT-MIB. It This is a Derived Object to be pulled from the
is derived from the XXX Base Object. reportHistoryGroup of the REPORT-MIB. It is derived from,
e.g., the nhdpDiscNeighborNibNeighborSetReachableLinkChanges
Base Object. The network management could develop the desired
histogram based upon the information retrieved from the REPORT-
MIB.
Object name: nhdpNeighborIfChangeHistory Object name: nhdpNeighborIfChangeHistory
Object type: SEQUENCE OF (TimeStamp) Object type: SEQUENCE OF (TimeStamp)
o Histogram of the intervals between a change of the interface over o Histogram of the intervals between a change of the interface over
which a given neighbor is reachable which a given neighbor is reachable
Returns the values that represent a histogram of intervals Returns the values that represent a histogram of intervals
between a change of the interface over which a given neighbor between a change of the interface over which a given neighbor
is reachable after the given time t0 and before the given time is reachable after the given time t0 and before the given time
t1. t1.
This is a Derived Object to be pulled from the REPORT-MIB. It This is a Derived Object to be pulled from the
is derived from the XXX Base Object. reportHistoryGroup from the REPORT-MIB. It is derived from the
previously discussed Base Object. The network management
application would develop the histograms based upon lists
obtained from the REPORT-MIB.
Object name: nhdpNeighborIfChangeHistogram Object name: nhdpNeighborIfChangeHistogram
Object type: SEQUENCE OF ( TimeTicks, Unsigned32)) Object type: SEQUENCE OF ( TimeTicks, Unsigned32))
The following objects inspect the stability of a given 2-hop The following objects inspect the stability of a given 2-hop
neighbor: neighbor:
o Count the changes of the N2_neighbor_iface_addr_list of a given o Count the changes of the N2_neighbor_iface_addr_list of a given
2-hop neighbor 2-hop neighbor
skipping to change at page 18, line 31 skipping to change at page 16, line 4
This is a Base Object. This is a Base Object.
Object name: nhdpIib2HopSetPerfChanges Object name: nhdpIib2HopSetPerfChanges
Object type: Counter32 Object type: Counter32
o Acquire history of changes of the N2_neighbor_iface_addr_list of a o Acquire history of changes of the N2_neighbor_iface_addr_list of a
given 2-hop neighbor (Note: Not sure what the Base Object is for given 2-hop neighbor (Note: Not sure what the Base Object is for
this set and not clear how to capture in the REPORT-MIB.) this set and not clear how to capture in the REPORT-MIB.)
This object returns the history of the exact timestamps of each This object returns the history of the exact timestamps of each
time the 2-hop neighbor changes its time the 2-hop neighbor changes its
N2_neighbor_iface_addr_list, i.e. the neighbor over which it is N2_neighbor_iface_addr_list, i.e. the neighbor over which it is
reachable. reachable.
This is a Derived Object to be pulled from the REPORT-MIB. It This is a Derived Object to be pulled from the
is derived from the XXX Base Object. reportHistoryGroup of the REPORT-MIB. It is derived from the
previously discussed Base Object.
Object name: nhdpN2ReachabilityChangeHistory Object name: nhdpN2ReachabilityChangeHistory
Object type: SEQUENCE OF (TimeStamp) Object type: SEQUENCE OF (TimeStamp)
o Histogram of the intervals between a change of a 2-hop neighbor's o Histogram of the intervals between a change of a 2-hop neighbor's
N2_neighbor_iface_addr_list N2_neighbor_iface_addr_list
Returns the values that represent a histogram of intervals Returns the values that represent a histogram of intervals
between a change of the 2-hop neighbor's between a change of the 2-hop neighbor's
N2_neighbor_iface_addr_list after the given time t0 and before N2_neighbor_iface_addr_list after the given time t0 and before
the given time t1. the given time t1.
This is a Derived Object to be pulled from the REPORT-MIB. It This is a Derived Object to be pulled from the
is derived from the XXX Base Object. reportHistoryGroup from the REPORT-MIB. It is derived from the
previously discussed Base Object. The network management
application would develop the histograms based upon lists
obtained from the REPORT-MIB.
Object name: nhdpN2ReachabilityChangeHistogram Object name: nhdpN2ReachabilityChangeHistogram
Object type: SEQUENCE OF (TimeTicks, Unsigned32) Object type: SEQUENCE OF (TimeTicks, Unsigned32)
The next objects examine the uptime of a given 2-hop neighbor: The next objects examine the uptime of a given 2-hop neighbor:
o 2-hop Neighbor uptime o 2-hop Neighbor uptime
Returns the number of milliseconds since the 2-Hop Tuple Returns the number of milliseconds since the 2-Hop Tuple
skipping to change at page 19, line 27 skipping to change at page 17, line 4
corresponding to the given 2-hop neighbor IP address exists. corresponding to the given 2-hop neighbor IP address exists.
This is a Base Object. This is a Base Object.
Object name: nhdpIib2HopSetPerfUpTime Object name: nhdpIib2HopSetPerfUpTime
Object type: Unsigned32 Object type: Unsigned32
o Acquire history of change of onlink status of a given 2-hop o Acquire history of change of onlink status of a given 2-hop
neighbor neighbor
This object returns the history of the exact timestamps of each This object returns the history of the exact timestamps of each
time the 2-hop neighbor becomes onlink or offlink. A 2-hop time the 2-hop neighbor becomes onlink or offlink. A 2-hop
neighbor is said to become "onlink" if a new 2-hop Tuple is neighbor is said to become "onlink" if a new 2-hop Tuple is
created that corresponds to the given 2-hop neighbor. It created that corresponds to the given 2-hop neighbor. It
becomes "offlink" if such a tuple has been deleted. becomes "offlink" if such a tuple has been deleted.
This is a Derived Object to be pulled from the REPORT-MIB. It This is a Derived Object to be pulled from the
is derived from the XXX Base Object. reportHistoryGroup of the REPORT-MIB. It is derived from the
previously discussed Base Object.
Object name: nhdpN2StatusHistory Object name: nhdpN2StatusHistory
Object type: SEQUENCE OF (TimeStamp) Object type: SEQUENCE OF (TimeStamp)
o Histogram of the intervals between a change of the onlink status o Histogram of the intervals between a change of the onlink status
of a given 2-hop neighbor of a given 2-hop neighbor
Returns the values that represent a histogram of intervals Returns the values that represent a histogram of intervals
between a change of the onlink status of a given 2-hop between a change of the onlink status of a given 2-hop
neighbor. The histogram includes all changes that have been neighbor. The histogram includes all changes that have been
made after the given time t0 and before the given time t1. made after the given time t0 and before the given time t1.
This is a Derived Object to be pulled from the REPORT-MIB. It This is a Derived Object to be pulled from the
is derived from the XXX Base Object. reportHistoryGroup from the REPORT-MIB. It is derived from the
previously discussed Base Object. The network management
application would develop the histograms based upon lists
obtained from the REPORT-MIB.
Object name: nhdpN2StatusHistogram Object name: nhdpN2StatusHistogram
Object type: SEQUENCE OF (TimeTicks, Unsigned32) Object type: SEQUENCE OF (TimeTicks, Unsigned32)
If Link Quality is used, the following object provides information 5.4. Notifications
about the link quality of a given link:
o Acquire history of the values of the link quality of a given link
between a given time t0 and t1.
This is a Derived Object to be pulled from the REPORT-MIB. It The Notifications subtree contains the list of notifications
is derived from the XXX Base Object. supported within the NHDP MIB and their intended purpose or utility.
The following notifications are specified:
Object name: nhdpLinkQualityHistory o nhdpNbrStateChange is a notification sent each time the status of
a neighbor has changed. Possible status values are down,
asymmetric, and symmetric.
Object type: SEQUENCE OF (nhdpNibNeighborSetRouterId, o nhdp2hopNbrStateChange is a notification sent each time the status
TimeStamp, Float32) of a neighbor has changed. Possible status values are down and
up.
6. Notifications o nhdpIfRxBadMessage is a notification sent each time an incoming
HELLO message has not been succesfully parsed on an interface.
The Notifications Subtree contains the list of notifications o nhdpIfStateChange is a notification sent each time the status of
supported within the NHDP MIB and their intended purpose or utility. an interface of the designated router has changed (i.e. an IP
This group is currently empty, pending further discussion. address has been added or removed to the interface, or the
interface has changed its status from up to down or vice versa).
7. Relationship to Other MIB Modules 6. Relationship to Other MIB Modules
[TODO]: The text of this section specifies the relationship of the This section specifies the relationship of the MIB modules contained
MIB modules contained in this document to other standards, in this document to other standards, particularly to standards
particularly to standards containing other MIB modules. Definitions containing other MIB modules. Definitions imported from other MIB
imported from other MIB modules and other MIB modules that SHOULD be modules and other MIB modules that SHOULD be implemented in
implemented in conjunction with the MIB module contained within this conjunction with the MIB module contained within this document are
document are identified in this section. identified in this section.
7.1. Relationship to the SNMPv2-MIB 6.1. Relationship to the SNMPv2-MIB
The 'system' group in the SNMPv2-MIB [RFC3418] is defined as being The 'system' group in the SNMPv2-MIB [RFC3418] is defined as being
mandatory for all systems, and the objects apply to the entity as a mandatory for all systems, and the objects apply to the entity as a
whole. The 'system' group provides identification of the management whole. The 'system' group provides identification of the management
entity and certain other system-wide data. The NHDP-MIB does not entity and certain other system-wide data. The NHDP-MIB does not
duplicate those objects. duplicate those objects.
7.2. Relationship to the IF-MIB 6.2. MIB modules required for IMPORTS
[TODO] This section is included as an example; If the MIB module is
not an adjunct of the Interface MIB, then this section should be
removed.
7.3. MIB modules required for IMPORTS
[TODO]: Citations are not permitted within a MIB module, but any
module mentioned in an IMPORTS clause or document mentioned in a
REFERENCE clause is a Normative reference, and must be cited
someplace within the narrative sections. If there are imported items
in the MIB module, such as Textual Conventions, that are not already
cited, they can be cited in text here. Since relationships to other
MIB modules should be described in the narrative text, this section
is typically used to cite modules from which Textual Conventions are
imported.
The following NHDP MIB module IMPORTS objects from SNMPv2-SMI The following NHDP MIB module IMPORTS objects from SNMPv2-SMI
[RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], and IF-MIB [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB
[RFC2863] [RFC2863], INET-ADDRESS-MIB [RFC4001], and SMIng [RFC3781].
8. Definitions 7. Definitions
NHDP-MIB DEFINITIONS ::= BEGIN NHDP-MIB DEFINITIONS ::= BEGIN
-- This MIB is currently in an initial stage. -- This MIB is currently in an initial stage.
-- Not all proposed objects have been identified yet -- Not all proposed objects have been identified yet
-- in the current draft. -- in the current draft.
IMPORTS IMPORTS
Float32 Float32
FROM SMIng --[RFC3781] FROM SMIng --[RFC3781]
MODULE-IDENTITY, OBJECT-TYPE, Counter32, MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32,
Integer32, Unsigned32, mib-2 Integer32, Unsigned32, mib-2
FROM SNMPv2-SMI --[RFC2578] FROM SNMPv2-SMI --[RFC2578]
TEXTUAL-CONVENTION, StorageType, TimeStamp, TEXTUAL-CONVENTION, StorageType, TimeStamp,
TruthValue, RowStatus TruthValue, RowStatus
FROM SNMPv2-TC --[RFC2579] FROM SNMPv2-TC --[RFC2579]
MODULE-COMPLIANCE, OBJECT-GROUP MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF --[STD58] FROM SNMPv2-CONF --[STD58]
InetAddressType, InetAddress, InetAddressType, InetAddress,
InetAddressPrefixLength InetAddressPrefixLength
FROM INET-ADDRESS-MIB --[RFC3291] FROM INET-ADDRESS-MIB --[RFC4001]
InterfaceIndexOrZero InterfaceIndexOrZero
FROM IF-MIB --[RFC2863] FROM IF-MIB --[RFC2863]
; ;
nhdpMIB MODULE-IDENTITY nhdpMIB MODULE-IDENTITY
LAST-UPDATED "200911091000Z" -- November 09,2009 LAST-UPDATED "201003081000Z" -- March 08,2010
ORGANIZATION "IETF MANET working group" ORGANIZATION "IETF MANET working group"
CONTACT-INFO CONTACT-INFO
"WG E-Mail: manet@ietf.org "WG E-Mail: manet@ietf.org
WG Chairs: ian.chakeres@gmail.com WG Chairs: ian.chakeres@gmail.com
jmacker@nrl.navy.mil jmacker@nrl.navy.mil
Editors: Ulrich Herberg Editors: Ulrich Herberg
Ecole Polytechnique Ecole Polytechnique
LIX LIX
91128 Palaiseau Cedex 91128 Palaiseau Cedex
France France
ulrich@herberg.name ulrich@herberg.name
http://www.herberg.name/ http://www.herberg.name/
Robert G. Cole Robert G. Cole
Johns Hopkins University Johns Hopkins University
Applied Physics Lab and
Department of Computer Science Department of Computer Science
11000 Johns Hopkins Road 3400 North Charles Street
Room 02-257 NEB Room 213
Laurel, MD 22014 Baltimore, MD 21218
USA USA
+1 443 778-6951 +1 443 910-4420
robert.cole@jhuapl.edu rgcole01@comcast.net
http://www.cs.jhu.edu/~rgcole/ http://www.cs.jhu.edu/~rgcole/
Ian D Chakeres Ian D Chakeres
CenGen CenGen
9250 Bendix Road North 9250 Bendix Road North
Columbia, Maryland 21045 Columbia, Maryland 21045
USA USA
ian.chakeres@gmail.com ian.chakeres@gmail.com
http://www.ianchak.com/" http://www.ianchak.com/"
DESCRIPTION DESCRIPTION
"This NHDP MIB module is applicable to devices "This NHDP MIB module is applicable to devices
implementing the Neighborhood Discovery Protocol implementing the Neighborhood Discovery Protocol
defined in [XXX]. defined in [XXX].
Copyright (C) The IETF Trust (2009). This version Copyright (C) The IETF Trust (2009). This version
of this MIB module is part of RFC xxxx; see the RFC of this MIB module is part of RFC xxxx; see the RFC
itself for full legal notices." itself for full legal notices."
-- revision -- revision
REVISION "201003081000Z" -- March 08, 2010
DESCRIPTION
"The sixth version of this MIB module,
published as draft-ietf-manet-nhdp-mib-03.txt.
Added the local nhdpIfIndex to the
nhdpIibLinkSetTable."
REVISION "200911091000Z" -- November 09, 2009 REVISION "200911091000Z" -- November 09, 2009
DESCRIPTION DESCRIPTION
"The fifth version of this MIB module, "The fifth version of this MIB module,
published as draft-ietf-manet-nhdp-mib-02.txt. published as draft-ietf-manet-nhdp-mib-02.txt.
Cleaned up a few things and updated to newest Cleaned up a few things and updated to newest
revision of NHDP draft." revision of NHDP draft."
REVISION "200910211000Z" -- October 21, 2009 REVISION "200910211000Z" -- October 21, 2009
DESCRIPTION DESCRIPTION
"The fourth version of this MIB module, "The fourth version of this MIB module,
published as draft-ietf-manet-nhdp-mib-01.txt. published as draft-ietf-manet-nhdp-mib-01.txt.
skipping to change at page 26, line 47 skipping to change at page 24, line 17
nhdpHpMaxJitter nhdpHpMaxJitter
Unsigned32, Unsigned32,
nhdpHtMaxJitter nhdpHtMaxJitter
Unsigned32, Unsigned32,
nhdpIfRowStatus nhdpIfRowStatus
RowStatus RowStatus
} }
nhdpIfIndex OBJECT-TYPE nhdpIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The ifIndex for this interface." "The ifIndex for this interface."
::= { nhdpInterfaceEntry 1 } ::= { nhdpInterfaceEntry 1 }
nhdpIfStatus OBJECT-TYPE nhdpIfStatus OBJECT-TYPE
SYNTAX TruthValue SYNTAX TruthValue
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
skipping to change at page 37, line 4 skipping to change at page 34, line 18
mask to be logical-ANDed with the destination address mask to be logical-ANDed with the destination address
before being compared to the value in the before being compared to the value in the
nhdpDiscIfSetAddr field. If the resulting nhdpDiscIfSetAddr field. If the resulting
address block is contained in a block in this address block is contained in a block in this
table, then a match should be returned." table, then a match should be returned."
REFERENCE REFERENCE
"The NHDP draft." "The NHDP draft."
::= { nhdpDiscIfSetEntry 5 } ::= { nhdpDiscIfSetEntry 5 }
-- An NHDP router's Local Information Base (LIB) -- An NHDP router's Local Information Base (LIB)
-- Local IF Set Table -- Local IF Set Table
-- Entry (foreach IF): (IfAddrList, -- Entry (foreach IF): (IfAddrList,
-- PrefixMask, -- PrefixMask,
-- Manet_indication) -- Manet_indication)
-- --
-- Note: This table is redundant with information in -- Note: This table is redundant with information in
-- the nhdpIfTable above. Hence it is not present here. -- the nhdpInterfaceTable above. Hence it is not present here.
-- Removed Interface Addr Set Table -- Removed Interface Addr Set Table
-- Entry (foreach Addr): (IfAddrRemoved, -- Entry (foreach Addr): (IfAddrRemoved,
-- ExpirationTime) -- ExpirationTime)
nhdpLibRemovedIfAddrSetTable OBJECT-TYPE nhdpLibRemovedIfAddrSetTable OBJECT-TYPE
SYNTAX SEQUENCE OF NhdpLibRemovedIfAddrSetEntry SYNTAX SEQUENCE OF NhdpLibRemovedIfAddrSetEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
skipping to change at page 40, line 24 skipping to change at page 37, line 38
REFERENCE REFERENCE
"The NHDP draft." "The NHDP draft."
::= { nhdpStateObjGrp 3 } ::= { nhdpStateObjGrp 3 }
nhdpIibLinkSetEntry OBJECT-TYPE nhdpIibLinkSetEntry OBJECT-TYPE
SYNTAX NhdpIibLinkSetEntry SYNTAX NhdpIibLinkSetEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A Link Set consists of Link Tuples, each "A Link Set consists of Link Tuples, each
representing a single link: representing a single link indexed by the
local and remote interface pair:
(L_neighbor_iface_addr_list, L_HEARD_time, (L_neighbor_iface_addr_list, L_HEARD_time,
L_SYM_time, L_quality, L_pending, L_SYM_time, L_quality, L_pending,
L_lost, L_time)." L_lost, L_time)."
REFERENCE REFERENCE
"This NHDP-MIB draft." "This NHDP-MIB draft."
INDEX { nhdpIibLinkSet1HopIfIndex } INDEX { nhdpIfIndex,
nhdpIibLinkSet1HopIfIndex }
::= { nhdpIibLinkSetTable 1 } ::= { nhdpIibLinkSetTable 1 }
NhdpIibLinkSetEntry ::= NhdpIibLinkSetEntry ::=
SEQUENCE { SEQUENCE {
nhdpIibLinkSet1HopIfIndex nhdpIibLinkSet1HopIfIndex
NeighborIfIndex, NeighborIfIndex,
nhdpIibLinkSetIfIndex nhdpIibLinkSetIfIndex
InterfaceIndexOrZero, InterfaceIndexOrZero,
nhdpIibLinkSetLHeardTime nhdpIibLinkSetLHeardTime
Unsigned32, Unsigned32,
skipping to change at page 41, line 4 skipping to change at page 38, line 19
nhdpIibLinkSetLSymTime nhdpIibLinkSetLSymTime
Unsigned32, Unsigned32,
nhdpIibLinkSetLQuality nhdpIibLinkSetLQuality
Unsigned32, Unsigned32,
nhdpIibLinkSetLPending nhdpIibLinkSetLPending
TruthValue, TruthValue,
nhdpIibLinkSetLLost nhdpIibLinkSetLLost
TruthValue, TruthValue,
nhdpIibLinkSetLTime nhdpIibLinkSetLTime
Unsigned32 Unsigned32
} }
nhdpIibLinkSet1HopIfIndex OBJECT-TYPE nhdpIibLinkSet1HopIfIndex OBJECT-TYPE
SYNTAX NeighborIfIndex SYNTAX NeighborIfIndex
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The nhdpIibLinkSet1HopIfIndex is "The nhdpIibLinkSet1HopIfIndex is
the value of the NeighborIfIndex (from the value of the NeighborIfIndex (from
table 'xxx' above). This object table nhdpDiscIfSetTable above). This
is repeated here to support table object is repeated here to support
walks to view the set of neighbors table walks to view the set of neighbors
of this router." of this router."
REFERENCE REFERENCE
"The NHDP draft." "The NHDP draft."
::= { nhdpIibLinkSetEntry 1 } ::= { nhdpIibLinkSetEntry 1 }
nhdpIibLinkSetIfIndex OBJECT-TYPE nhdpIibLinkSetIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
skipping to change at page 45, line 4 skipping to change at page 42, line 20
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The type of the nhdpIib2HopSetIpAddress "The type of the nhdpIib2HopSetIpAddress
in the InetAddress MIB [RFC 4001]." in the InetAddress MIB [RFC 4001]."
REFERENCE REFERENCE
"The NHDP draft." "The NHDP draft."
::= { nhdpIib2HopSetEntry 1 } ::= { nhdpIib2HopSetEntry 1 }
nhdpIib2HopSetIpAddress OBJECT-TYPE nhdpIib2HopSetIpAddress OBJECT-TYPE
SYNTAX InetAddress SYNTAX InetAddress
MAX-ACCESS not-accessible MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The nhdpIib2HopSetIpAddr is an "The nhdpIib2HopSetIpAddr is an
address of an interface of a symmetric address of an interface of a symmetric
2-hop neighbor which has a symmetric 2-hop neighbor which has a symmetric
link (using any MANET interface) to link (using any MANET interface) to
the indicated symmetric 1-hop neighbor." the indicated symmetric 1-hop neighbor."
REFERENCE REFERENCE
"The NHDP draft." "The NHDP draft."
::= { nhdpIib2HopSetEntry 2 } ::= { nhdpIib2HopSetEntry 2 }
skipping to change at page 47, line 17 skipping to change at page 44, line 33
} }
nhdpNibNeighborSetRouterId OBJECT-TYPE nhdpNibNeighborSetRouterId OBJECT-TYPE
SYNTAX NeighborRouterId SYNTAX NeighborRouterId
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The nhdpNibNeighborSetRouterId is "The nhdpNibNeighborSetRouterId is
the NeighborRouterId of a one hop the NeighborRouterId of a one hop
neighbor to this router. It must also neighbor to this router. It must also
exist in the 'nhdpDiscSetTable' exist in the 'nhdpDiscIfSetTable'
allowing the manager to determine allowing the manager to determine
the set of Ip addr's associated the set of Ip addr's associated
with the NeighborRouterId in this row." with the NeighborRouterId in this row."
REFERENCE REFERENCE
"The NHDP draft." "The NHDP draft."
::= { nhdpNibNeighborSetEntry 1 } ::= { nhdpNibNeighborSetEntry 1 }
nhdpNibNeighborSetNSymmetric OBJECT-TYPE nhdpNibNeighborSetNSymmetric OBJECT-TYPE
SYNTAX TruthValue SYNTAX TruthValue
MAX-ACCESS read-only MAX-ACCESS read-only
skipping to change at page 48, line 41 skipping to change at page 46, line 5
nhdpNibLostNeighborSetRouterId OBJECT-TYPE nhdpNibLostNeighborSetRouterId OBJECT-TYPE
SYNTAX NeighborRouterId SYNTAX NeighborRouterId
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The nhdpNibLostNeighborSetRouterId is "The nhdpNibLostNeighborSetRouterId is
the NeighborRouterId of a one hop the NeighborRouterId of a one hop
neighbor to this router which was neighbor to this router which was
recently lost. It must also recently lost. It must also
exist in the 'nhdpDiscSetTable' exist in the 'nhdpDiscIfSetTable'
allowing the manager to determine allowing the manager to determine
the set of Ip addr's associated the set of Ip addr's associated
with the NeighborRouterId in this row." with the NeighborRouterId in this row."
REFERENCE REFERENCE
"The NHDP draft." "The NHDP draft."
::= { nhdpNibLostNeighborSetEntry 1 } ::= { nhdpNibLostNeighborSetEntry 1 }
-- Note: need to fime time type for this object -- Note: need to fime time type for this object
nhdpNibLostNeighborSetNLTime OBJECT-TYPE nhdpNibLostNeighborSetNLTime OBJECT-TYPE
SYNTAX Unsigned32 SYNTAX Unsigned32
skipping to change at page 58, line 26 skipping to change at page 55, line 37
corresponding to the given 2-hop neighbor IP address exists corresponding to the given 2-hop neighbor IP address exists
in the nhdpIib2HopSetTable." in the nhdpIib2HopSetTable."
REFERENCE REFERENCE
"This NHDP-MIB draft." "This NHDP-MIB draft."
::= { nhdpIib2HopSetPerfEntry 3 } ::= { nhdpIib2HopSetPerfEntry 3 }
-- --
-- nhdpNotifications -- nhdpNotifications
-- --
-- Note: What are the valuable notification information for the nhdpNotificationsGrp OBJECT IDENTIFIER ::= { nhdpObjects 4 }
-- NHDP-MIB? nhdpNotificationsControl OBJECT IDENTIFIER ::= { nhdpObjects 5 }
nhdpNotificationsStates OBJECT IDENTIFIER ::= { nhdpObjects 6 }
nhdpSetNotification OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(4))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"A 4-octet string serving as a bit map for
the notification events defined by the NHDP
notifications. This NHDP notifications where
a 1 in the bit field represents enabled. The
right-most bit (leastsignificant) represents
notification 0.
This object is persistent and when written
the entity SHOULD save the change to
non-volatile storage."
::= { nhdpNotificationsControl 1 }
nhdpMessageSrc OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP address of an inbound message that
cannot be identified by a neighbor instance. When
the last value of a notification using this object is
needed, but no notifications of that type have been sent,
this value pertaining to this object should
be returned as 0.0.0.0 or :: respectively."
::= { nhdpNotificationsControl 2 }
-- Notifications
-- Note: does this work when the neighbor goes down?
-- (there is no nhdpNibNeighborSetRouterId any more...)
nhdpNbrStateChange NOTIFICATION-TYPE
OBJECTS { nhdpDiscIfSetRouterId, -- The originator
-- of the notification
nhdpNbrState -- The new state
}
STATUS current
DESCRIPTION
"An nhdpNbrStateChange notification signifies that
there has been a change in the state of a
NHDP neighbor."
::= { nhdpNotificationsGrp 1 }
nhdpNbrState OBJECT-TYPE
SYNTAX INTEGER {
down (0),
asymmetric (1),
symmetric(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"NHDP neighbor states."
DEFVAL { down }
::= { nhdpNotificationsStates 1 }
nhdp2hopNbrStateChange NOTIFICATION-TYPE
OBJECTS { nhdpIib2HopSetIpAddress, -- The originator
-- of the notification
nhdp2hopNbrState -- The new state
}
STATUS current
DESCRIPTION
"An nhdp2hopNbrStateChange notification signifies that
there has been a change in the state of a 2-hop
neighbor. This notification should be
generated when the 2-hop neighbor state goes
down or up."
::= { nhdpNotificationsGrp 2 }
nhdp2hopNbrState OBJECT-TYPE
SYNTAX INTEGER {
down (0),
up (1)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"NHDP 2hop neighbor states."
DEFVAL { down }
::= { nhdpNotificationsStates 2 }
nhdpIfRxBadMessage NOTIFICATION-TYPE
OBJECTS { nhdpDiscIfSetRouterId, -- The originator of
-- the notification
nhdpDiscIfSetIndex, -- The interface on which the
-- message has been received
nhdpMessageSrc -- The source IP address
}
STATUS current
DESCRIPTION
"An nhdpIfRxBadMessage notification signifies that a
HELLO message has been received on an
interface that cannot be parsed."
::= { nhdpNotificationsGrp 3 }
nhdpIfStateChange NOTIFICATION-TYPE
OBJECTS { nhdpIfIndex, -- The local interface
nhdpIfState -- The new state
}
STATUS current
DESCRIPTION
"An nhdpIfStateChange notification signifies that there
has been a change in the state of an NHDP
interface. This notification should be generated
when the interface goes up or down, or when
the list of addresses of that interface
changes."
::= { nhdpNotificationsGrp 4 }
nhdpIfState OBJECT-TYPE
SYNTAX INTEGER {
down (0),
up (1),
addresschange(2) -- If a new address has been
-- added or an address has
-- been removed
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"NHDP interface states."
DEFVAL { down }
::= { nhdpNotificationsStates 3 }
-- --
-- nhdpConformance information -- nhdpConformance information
-- --
-- Note: To be determined. -- Note: To be determined.
nhdpCompliances OBJECT IDENTIFIER ::= { nhdpConformance 1 } nhdpCompliances OBJECT IDENTIFIER ::= { nhdpConformance 1 }
nhdpMIBGroups OBJECT IDENTIFIER ::= { nhdpConformance 2 } nhdpMIBGroups OBJECT IDENTIFIER ::= { nhdpConformance 2 }
-- Compliance Statements -- Compliance Statements
nhdpBasicCompliance MODULE-COMPLIANCE nhdpBasicCompliance MODULE-COMPLIANCE
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The basic implementation requirements for "The basic implementation requirements for
managed network entities that implement managed network entities that implement
NHDP." NHDP."
MODULE -- this module MODULE -- this module
MANDATORY-GROUPS { nhdpConfigurationGroup } MANDATORY-GROUPS { nhdpConfigurationGroup }
::= { nhdpCompliances 1 } ::= { nhdpCompliances 1 }
nhdpFullCompliance MODULE-COMPLIANCE nhdpFullCompliance MODULE-COMPLIANCE
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The full implementation requirements for "The full implementation requirements for
managed network entities that implement managed network entities that implement
NHDP." NHDP."
MODULE -- this module MODULE -- this module
MANDATORY-GROUPS { nhdpConfigurationGroup, MANDATORY-GROUPS { nhdpConfigurationGroup,
nhdpStateGroup, nhdpStateGroup,
nhdpNotificationGroup,
nhdpPerformanceGroup } nhdpPerformanceGroup }
::= { nhdpCompliances 2 } ::= { nhdpCompliances 2 }
-- --
-- Units of Conformance -- Units of Conformance
-- --
nhdpConfigurationGroup OBJECT-GROUP nhdpConfigurationGroup OBJECT-GROUP
OBJECTS { OBJECTS {
nhdpIfStatus, nhdpIfStatus,
nhdpHelloInterval, nhdpHelloInterval,
nhdpHelloMinInterval, nhdpHelloMinInterval,
nhdpRefreshInterval, nhdpRefreshInterval,
nhdpLHoldTime, nhdpLHoldTime,
nhdpHHoldTime, nhdpHHoldTime,
nhdpHystAcceptQuality, nhdpHystAcceptQuality,
nhdpHystRejectQuality, nhdpHystRejectQuality,
skipping to change at page 61, line 31 skipping to change at page 61, line 21
nhdpDiscNeighborNibNeighborSetReachableLinkChanges, nhdpDiscNeighborNibNeighborSetReachableLinkChanges,
nhdpIib2HopSetPerfChanges, nhdpIib2HopSetPerfChanges,
nhdpIib2HopSetPerfUpTime nhdpIib2HopSetPerfUpTime
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Set of NHDP performance objects implemented "Set of NHDP performance objects implemented
in this module." in this module."
::= { nhdpMIBGroups 4 } ::= { nhdpMIBGroups 4 }
nhdpNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
nhdpNbrStateChange,
nhdp2hopNbrStateChange,
nhdpIfRxBadMessage,
nhdpIfStateChange
}
STATUS current
DESCRIPTION
"Set of NHDP notification objects implemented
in this module."
::= { nhdpMIBGroups 5 }
END END
9. Security Considerations 8. Security Considerations
[TODO] Each specification that defines one or more MIB modules MUST
contain a section that discusses security considerations relevant to
those modules. This section MUST be patterned after the latest
approved template (available at
http://www.ops.ietf.org/mib-security.html). Remember that the
objective is not to blindly copy text from the template, but rather
to think and evaluate the risks/vulnerabilities and then state/
document the result of this evaluation.
[TODO] if you have any read-write and/or read-create objects, please This MIB defines objects for the configuration, monitoring and
include the following boilerplate paragraph. notification of the Neighborhood Discovery Protocol (NHDP) [NHDP].
NHDP allows routers to acquire topological information up to two hops
away by virtue of exchanging HELLO messages. The information
acquired by NHDP is used by other protocols, such as OLSRv2 [OLSRv2]
and SMF [SMF], and possibly other 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 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 with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on environment without proper protection can have a negative effect on
network operations. These are the tables and objects and their network operations. These are the tables and objects and their
sensitivity/vulnerability: sensitivity/vulnerability:
o [TODO] writable MIB objects that could be especially disruptive if o Specifically sensitive objects -
abused MUST be explicitly listed by name and the associated
security risks MUST be spelled out; RFC 2669 has a very good
example.
o [TODO] list the writable tables and objects and state why they are o nhdpIfStatus - this writable object turns on or off the NHDP
sensitive. process for the specified interface. If disabled, higher level
protocol functions, e.g., routing, would fail causing network-wide
disruptions.
[TODO] else if there are no read-write objects in your MIB module, o nhdpHelloInterval, nhdpHelloMinInterval, and nhdpRefreshInterval -
use the following boilerplate paragraph. these writable objects control the rate at which HELLO messages
are sent on a wireless interface. If set at too high a rate, this
could represent a form of DOS attack by overloading interface
resources.
There are no management objects defined in this MIB module that have o nhdpHystAcceptQuality, nhdpHystRejectQuality, nhdpInitialQuality,
a MAX-ACCESS clause of read-write and/or read-create. So, if this nhdpInitialPending - these writable objects affect the perceived
MIB module is implemented correctly, then there is no risk that an quality of the HNDP links and hence the overall stability of the
intruder can alter or create any management objects of this MIB network. If improperly set, these settings could result in
module via direct SNMP SET operations. network-wide disruptions.
[TODO] if you have any sensitive readable objects, please include the o The writable tables -
following boilerplate paragraph.
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
with writable objects.
Some of the readable objects in this MIB module (i.e., objects with a 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 MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. It is thus important to vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability: sensitivity/vulnerability:
o [TODO] you must explicitly list by name any readable objects that o nhdpDiscIfSetTable - The contains information on discovered
are sensitive or vulnerable and the associated security risks MUST neighbors, specifically their IP address in the
be spelled out (for instance, if they might reveal customer nhdpDiscIfSetIpAddr object. This information provides an
information or violate personal privacy laws such as those of the adversary broad information on the members of the MANET, located
European Union if exposed to unauthorized parties) within this single table. This information can be use to expedite
attacks on the other members of the MANET without having to go
o [TODO] list the tables and objects and state why they are through a laborious discovery process on their own. This object
sensitive. is the index into the table, and has a MAX-ACCESS of 'not-
accessible'. However this information can be exposed using SNMP
operations.
[TODO] discuss what security the protocol used to carry the MANET technology is often deployed to support communications of
information should have. The following three boilerplate paragraphs emergency services or military tactical applications. In these
should not be changed without very good reason. Changes will almost applications, it is imperative to maintain the proper operation of
certainly require justification during IESG review. the communications network and to protect sensitive information
related to its operation. Therefore, when implementing these
capabilities, the full use of SNMPv3 cryptographic machanisms for
authentication and privacy is RECOMMENDED.
SNMP versions prior to SNMPv3 did not include adequate security. SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec), Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is there is no control as to who on the secure network is allowed to
allowed to access and GET/SET (read/change/create/delete) the objects access and GET/SET (read/change/create/delete) the objects in this
in this MIB module. MIB module.
It is RECOMMENDED that implementers consider the security features as It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8), provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy). authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them. rights to indeed GET or SET (change/create/delete) them.
10. IANA Considerations 9. IANA Considerations
[TODO] In order to comply with IESG policy as set forth in
http://www.ietf.org/ID-Checklist.html, every Internet-Draft that is
submitted to the IESG for publication MUST contain an IANA
Considerations section. The requirements for this section vary
depending what actions are required of the IANA. see RFC4181 section
3.5 for more information on writing an IANA clause for a MIB module
document.
[TODO] select an option and provide the necessary details.
Option #1:
The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
sampleMIB { mib-2 XXX }
Option #2:
Editor's Note (to be removed prior to publication): the IANA is
requested to assign a value for "XXX" under the 'mib-2' subtree and
to record the assignment in the SMI Numbers registry. When the
assignment has been made, the RFC Editor is asked to replace "XXX"
(here and in the MIB module) with the assigned value and to remove
this note.
Note well: prior to official assignment by the IANA, a draft document
MUST use placeholders (such as "XXX" above) rather than actual
numbers. See RFC4181 Section 4.5 for an example of how this is done
in a draft MIB module.
Option #3:
This memo includes no request to IANA. This memo includes no request to IANA.
11. Contributors 10. Contributors
This MIB document uses the template authored by D. Harrington which This MIB document uses the template authored by D. Harrington which
is based on contributions from the MIB Doctors, especially Juergen is based on contributions from the MIB Doctors, especially Juergen
Schoenwaelder, Dave Perkins, C.M.Heard and Randy Presuhn. Schoenwaelder, Dave Perkins, C.M.Heard and Randy Presuhn.
12. Acknowledgements 11. References
11.1. Normative References
[TODO]This acknowledgement can be removed from your MIB module
document.
13. References
13.1. Normative References
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000. MIB", RFC 2863, June 2000.
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the [RFC3418] Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62, Simple Network Management Protocol (SNMP)", STD 62,
RFC 3418, December 2002. RFC 3418, December 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 65, line 24 skipping to change at page 64, line 32
STD 58, RFC 2579, April 1999. STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580, "Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999. April 1999.
[NHDP] Clausen, T., Dearlove, C., and J. Dean, "The MANET [NHDP] Clausen, T., Dearlove, C., and J. Dean, "The MANET
Neighborhood Discovery Protocol (NHDP)", Neighborhood Discovery Protocol (NHDP)",
draft-ietf-manet-nhdp-11 (work in progress), October 2009. draft-ietf-manet-nhdp-11 (work in progress), October 2009.
[REPORT] Cole, R., Macker, J., and A. Morton, "The MANET Report [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
MIB", June 2009. Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
11.2. Informative References
[REPORT] Cole, R., Macker, J., and A. Morton, "Definition of
Managed Objects for Performance Reporting",
draft-cole-manet-report-mib-02 (work in progress),
March 2010.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
Considerations in Mobile Ad Hoc Networks (MANETs)", Considerations in Mobile Ad Hoc Networks (MANETs)",
RFC 5148, February 2008. RFC 5148, February 2008.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value [OLSRv2] Clausen, T., Dearlove, C., and P. Philippe, "The Optimized
Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, Link State Routing Protocol version 2", work in
March 2009. progress draft-ietf-manet-olsrv2-10.txt, September 2009.
13.2. Informative References [SMF] Macker, J., "Simplified Multicast Forwarding", work in
progress draft-ietf-manet-smf-09.txt, July 2009.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet- "Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002. Standard Management Framework", RFC 3410, December 2002.
[RFC3781] Strauss, F. and J. Schoenwaelder, "Next Generation
Structure of Management Information (SMIng) Mappings to
the Simple Network Management Protocol (SNMP)", RFC 3781,
May 2004.
Appendix A. Change Log Appendix A. Change Log
Here we list the changes made to the various drafts of this MIB. Here we list the changes made to the various drafts of this MIB.
We list here the changes made on the draft-ietf-manet-nhdp-mib-02
draft to generate the draft-ietf-manet-nhdp-mib-03 draft.
1. Cleaned up text in the Performance Group section defining the
base versus the derived (from the REPORT-MIB) objects.
2. Added the local nhdpIfIndex to the nhdpIibLinkSetTable. A duplex
of interface indecies is required to define a wireless link.
3. Added text to the Security Considerations section.
4. Added notifications.
We list here the changes made on the draft-ietf-manet-nhdp-mib-01 We list here the changes made on the draft-ietf-manet-nhdp-mib-01
draft to generate the draft-ietf-manet-nhdp-mib-02 draft. draft to generate the draft-ietf-manet-nhdp-mib-02 draft.
1. Cleaned up several things (e.g. moved N_HOLD_TIME from interface 1. Cleaned up several things (e.g. moved N_HOLD_TIME from interface
parameter to router paramter) parameter to router paramter)
2. Updated to NHDP draft version 11 2. Updated to NHDP draft version 11
We list here the changes made on the draft-ietf-manet-nhdp-mib-00 We list here the changes made on the draft-ietf-manet-nhdp-mib-00
draft to generate the draft-ietf-manet-nhdp-mib-01 draft. draft to generate the draft-ietf-manet-nhdp-mib-01 draft.
1. Made and extensive addition in the area of performance 1. Made and extensive addition in the area of performance
monitoring. Added text in the front material, added a monitoring. Added text in the front material, added a
PerformanceGroup to the MIB and added the PerformanceGroup to the PerformanceGroup to the MIB and added the PerformanceGroup to the
Conformance Sections. Conformance Sections.
We list here the changes made on the draft-cole-manet-nhdp-mib-01 We list here the changes made on the draft-cole-manet-nhdp-mib-01
draft to generate the draft-ietf-manet-nhdp-mib-00 draft. draft to generate the draft-ietf-manet-nhdp-mib-00 draft.
skipping to change at page 67, line 5 skipping to change at page 66, line 43
7. Aligned the NHDP-MIB and the OLSRv2-MIB configuration tables and 7. Aligned the NHDP-MIB and the OLSRv2-MIB configuration tables and
indexing. indexing.
Appendix B. Open Issues Appendix B. Open Issues
This section contains the set of open issues related to the This section contains the set of open issues related to the
development and design of the NHDP-MIB. This section will not be development and design of the NHDP-MIB. This section will not be
present in the final version of the MIB and will be removed once all present in the final version of the MIB and will be removed once all
the open issues have been resolved. the open issues have been resolved.
1. How to handle dynamic parameters within NHDP? Should we expose 1. How to handle dynamic parameters within NHDP? Should we expose
setting, min and max values? setting, min and max values?
2. Need to address how to handle Link Quality settings and
parameters for a) optional operation and b) changing nature of
link quality.
3. What notifications are of interest and utility?
4. Identify all objects requiring non-volatile storage in their
DESCRIPTION clauses.
5. Incorporate parameter relationship conditions into their
DESCRIPTION clauses.
6. Also, specify specific SNMP response to the snmp set request,
i.e., 'generic error', 'bad value', etc.
7. Fill in all of the DEFVAL within the configuration group 2. Identify all objects requiring non-volatile storage in their
objects. DESCRIPTION clauses.
8. Run through the MIB checker. 3. Incorporate parameter relationship conditions into their
DESCRIPTION clauses.
9. Clean up all of the 'Note:' statements within the body of the 4. Also, specify specific SNMP response to the snmp set request,
MIB. i.e., 'generic error', 'bad value', etc.
10. Work on the Security Section. This MIB does have settable 5. Clean up all of the 'Note:' statements within the body of the
objects, but not sensitive objects (true?). MIB.
11. Work on the relationship to other MIBs, IF-MIB, NHDP-MIB. 6. Work on the relationship to other MIBs, IF-MIB, REPORT-MIB,
OLSRv2-MIB.
12. Cleanup all the [TODOs] from the MIB template. 7. Cleanup all the [TODOs] from the MIB template.
Appendix C. Appendix C.
*************************************************************** ***************************************************************
* Note to the RFC Editor (to be removed prior to publication) * * Note to the RFC Editor (to be removed prior to publication) *
* * * *
* 1) The reference to RFCXXXX within the DESCRIPTION clauses * * 1) The reference to RFCXXXX within the DESCRIPTION clauses *
* of the MIB module point to this draft and are to be * * of the MIB module point to this draft and are to be *
* assigned by the RFC Editor. * * assigned by the RFC Editor. *
* * * *
skipping to change at page 68, line 32 skipping to change at page 67, line 43
Ulrich Herberg Ulrich Herberg
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
Palaiseau Cedex, 91128 Palaiseau Cedex, 91128
France France
EMail: ulrich@herberg.name EMail: ulrich@herberg.name
URI: http://www.herberg.name/ URI: http://www.herberg.name/
Robert G. Cole Robert G. Cole
Johns Hopkins University Johns Hopkins University
11100 Johns Hopkins Road, Room 257 3400 North Charles Street, NEB Room 213
Laurel, Maryland 21073 Baltimore, Maryland 21218
USA USA
Phone: +1 443 778 6951 Phone: +1 443 910 4420
EMail: robert.cole@jhuapl.edu EMail: rgcole01@comcast.net
URI: http://www.cs.jhu.edu/~rgcole/ URI: http://www.cs.jhu.edu/~rgcole/
Ian D Chakeres Ian D Chakeres
CenGen CenGen
9250 Bendix Road North 9250 Bendix Road North
Columbia, Maryland 560093 Columbia, Maryland 560093
USA USA
EMail: ian.chakeres@gmail.com EMail: ian.chakeres@gmail.com
URI: http://www.ianchak.com/ URI: http://www.ianchak.com/
 End of changes. 127 change blocks. 
451 lines changed or deleted 470 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/