Definition of Managed Objects for the
Neighborhood Discovery ProtocolLIX, Ecole PolytechniquePalaiseau Cedex91128Franceulrich@herberg.namehttp://www.herberg.name/Johns Hopkins University11100 Johns Hopkins Road, Room 257LaurelMaryland21073USA+1 443 778 6951robert.cole@jhuapl.eduhttp://www.cs.jhu.edu/~rgcole/CenGen9250 Bendix Road NorthColumbiaMaryland560093USAian.chakeres@gmail.comhttp://www.ianchak.com/
MANET & Routing Area
Internet Engineering Task ForceNetwork ManagementManagement Information baseMIBSMIv2RoutingNeighbor DiscoveryMANETThis memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes objects for configuring aspects of the
Neighborhood Discovery Protocol (NHDP) process on a router.
The NHDP MIB also reports state information, performance information
and notifications. This additional
state and performance information is useful to management
stations troubleshooting neighbor discovery problems.This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes objects for configuring aspects of the
Neighborhood Discovery Protocol (NHDP)
process on a router. The NHDP MIB also reports state information, performance information and notifications. This additional state and performance information is useful to management stations troubleshooting neighbor discovery problems.For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 .Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of
Management Information (SMI). This memo specifies a MIB module that is
compliant to the SMIv2, which is described in STD 58, RFC 2578 , STD 58, RFC 2579 and STD 58, RFC 2580 .The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 .The NHDP protocol allows routers in a Mobile Ad-Hoc
Network (MANET) to discover and track one-hop and two-hop
neighbor sets. This information is useful for routers running
various routing and multicast flooding protocols developed
within the IETF MANET Working Group.The following definitions apply throughout this document:Configuration Objects - switches, tables, objects
which are initialized to default settings or set
through the management interface defined by this MIB.State Objects - automatically generated values which
define the current operating state of the NHDP
protocol process in the router.Performance Objects - automatically generated values
which help an administrator or automated tool to
assess the performance of the NHDP protocol process
on the router and the overall discovery performance
within the NHDP domain.This section presents the structure of the NHDP MIB module. The MIB is arranged into the following structure:nhdpNotifications - objects defining NHDP MIB notifications.nhdpObjects - defining objects within this MIB. The objects are arranged into the following groups:
Configuration Group - defining objects related to the configuration of the NHDP instance on the device.State Group - defining objects which reflect the current state of the NHDP instance running on the device.Performance Group - defining objects which are useful to a management station when characterizing the performance of the NHDP on the device and in the MANET.nhdpConformance - defining the minimal and maximal conformance
requirements for implementations of this MIB.This section is TBD.The device is configured with a set of controls. The list of configuration controls for the NHDP-MIB (found in ), are discussed in the following subsections.The Interface Parameters include:HELLO_INTERVAL - is the maximum time between the transmission of two successive HELLO messages on this MANET interface. If using periodic transmission of HELLO messages, these SHOULD be at a separation of HELLO_INTERVAL, possibly modified by jitter as specified in .HELLO_MIN_INTERVAL - is the minimum interval between transmission of two successive HELLO messages, on this MANET interface. (This minimum interval MAY be modified by jitter, as defined in .)REFRESH_INTERVAL - is the maximum interval between advertisements, in a HELLO message on this MANET interface, of each 1-hop neighbor network address and its status. In all intervals of length 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:HELLO_INTERVAL > 0HELLO_MIN_INTERVAL >= 0HELLO_INTERVAL >= HELLO_MIN_INTERVALREFRESH_INTERVAL >= HELLO_INTERVALIf an INTERVAL_TIME message TLV as defined in is included in a HELLO message, then HELLO_INTERVAL MUST be representable as described in .The following default values are recommended:HELLO_INTERVAL := 2 secondsHELLO_MIN_INTERVAL := HELLO_INTERVAL/4REFRESH_INTERVAL := HELLO_INTERVALParameters related to the Information Validity Times include:L_HOLD_TIME - is the period of advertisement, on this MANET interface, of former 1-hop neighbor network addresses as lost in HELLO messages, allowing recipients of these HELLO messages to accelerate removal of this information from their Link Sets. L_HOLD_TIME MAY be set to zero, if accelerated information removal is not required.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 then used by each router receiving such a HELLO message to indicate the validity of the information taken from that HELLO message and recorded in the receiving router's Information Bases.The following constraints apply to these interface parameters:L_HOLD_TIME >= 0H_HOLD_TIME >= REFRESH_INTERVALIf HELLO messages can be lost then both SHOULD be significantly
greater than REFRESH_INTERVAL.H_HOLD_TIME MUST be representable as described in .The following default values are recommended:H_HOLD_TIME := 3 x REFRESH_INTERVALL_HOLD_TIME := H_HOLD_TIMEParameters related to the Link Quality include:HYST_ACCEPT - is the link quality threshold at or above which a link becomes usable, if it was not already so.HYST_REJECT - is the link quality threshold below which a link becomes unusable, if it was not already so.INITIAL_QUALITY - is the initial quality of a newly identified link.INITIAL_PENDING - if true, then a newly identified link is considered pending, and is not usable until the link quality has reached or exceeded the HYST_ACCEPT threshold.The following constraints apply to these interface parameters:0 < = HYST_REJECT < = HYST_ACCEPT < = 10 < = INITIAL_QUALITY < = 1.If link quality is not updated, then INITIAL_QUALITY >=
HYST_ACCEPT.If INITIAL_QUALITY >= HYST_ACCEPT, then INITIAL_PENDING := false.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:INITIAL_PENDING := falseINITIAL_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:HYST_ACCEPT := 1HYST_REJECT := 0INITIAL_QUALITY := 1INITIAL_PENDING := falseIf jitter, as defined in , is used then these parameters are as follows:HP_MAXJITTER - represents the value of MAXJITTER used in for periodically generated HELLO messages on this MANET interface.HT_MAXJITTER - represents the value of MAXJITTER used in for externally triggered HELLO messages on this MANET interface.For constraints on these interface parameters see .The following default values are recommended:HP_MAXJITTER := HELLO_INTERVAL/4HT_MAXJITTER := HP_MAXJITTERC := 1/1024 secondThe following Router Parameters apply:N_HOLD_TIME - is used as the period during which former 1-hop neighbor network addresses are advertised as lost in HELLO messages, allowing recipients of these HELLO messages to accelerate removal of this information from their 2-Hop Sets. N_HOLD_TIME MAY be set to zero, if accelerated information is not required.I_HOLD_TIME - is the period for which a recently used local interface network address is recorded.The following constraints applies to these router parameters:N_HOLD_TIME >= 0I_HOLD_TIME >= 0The State Subtree reports current state information,
including neighbor tables.
These are separately discussed below.The Local Information Base (LIB), contains the network addresses of the interfaces (MANET and non-MANET) of this router. The contents of this Information Base are not changed by signaling. The LIB contains two tables:The "Local Interface Set", which records its local interfaces. It consists of Local Interface Tuples, one per interface. Note that the information from this set is contained in the nhdpInterfaceTable, which is defined by this MIB document. Therefore, the Local Interface Set is not defined as an object in this MIB.The "Removed Interface Address Set", which records network addresses which were recently used as local interface network addresses. If a router's interface network addresses are immutable then the Removed Interface Address Set is always empty and MAY be omitted. It consists of Removed Interface Address Tuples, one per network address.The Interface Information Based (IIB), recording information regarding links to this MANET interface and symmetric 2-hop neighbors which can be reached through such links. The IIB contains two tables:A "Link Set", which records information about current and recently lost links between this interface and MANET interfaces of 1-hop neighbors. The Link Set consists of Link Tuples, each of which contains information about a single link. Recently lost links are 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.A "Two-Hop Set", which records the existence of bidirectional links between symmetric 1-hop neighbors of this MANET interface and other routers (symmetric 2-hop neighbors). The 2-Hop Set consists of 2-Hop Tuples, each of which records an interface address of a symmetric 2-hop neighbor, and all interface addresses of the corresponding symmetric 1-hop neighbor. The 2-Hop Set is updated by the signaling of this protocol, but is not itself reported in that signaling.The Neighbor Information Base (NIB), records information regarding current and recently lost 1-hop neighbors of this router. The NIB contains two tables:A "Neighbor Set", which records all network addresses of each 1-hop neighbor. It consists of Neighbor Tuples, each representing a single 1-hop neighborA "Lost Neighbor Set", which records network addresses of routers which recently were symmetric 1-hop neighbors, but which are now advertised as lost. It consists of Lost Neighbor Tuples, each representing a single such network addressThe Performance Group reports values relevant to system performance.
This section lists objects for NHDP performance monitoring,
some of which explicitly appear in the NHDP-MIB and others which
are obtainable through a combination of base objects from this MIB and reports available through the REPORT-MIB.
Throughout this 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 are derived through a combination of the
base objects and capabilities afforded by the REPORT-MIB.The objects described in the following can be useful for determining
certain properties of the NHDP instance.
Notably unstable neighbors or 2-hop neighbors and frequent changes
of sets can have a negative influence on the performance of NHDP.
The following objects thus allow to acquire information related to
the stability and performance of NHDP:The following objects return some of the statistics related to HELLO messages:
Total number of sent HELLO messages on an interface
This is a Base Object.Object name: nhdpIfHelloMessageXmitsObject type: Counter32Total number of received HELLO messages on an interface
This is a Base Object.Object name: nhdpIfHelloMessageRecvdObject type: Counter32Total number of sent periodic HELLO messages on an interface
This is a Base Object.Object name: nhdpIfHelloMessagePeriodicXmitsObject type: Counter32Total number of sent triggered HELLO messages on an interface
This is a Base Object.Object name: nhdpIfHelloMessageTriggeredXmitsObject type: Counter32Acquire history of HELLO message scheduling instance for the given time duration on an interface
This object returns the history of the exact timestamps of
each HELLO message that has been sent as well as the type of the
message (triggered or periodical).
The list of events starts at the given point of time t0 and ends
at the given time t1.This is a Derived Object to be pulled from the REPORT-MIB.
It is derived from the XXX Base Object.Object name: nhdpMessageSchedulingHistoryObject type: SEQUENCE OF (TimeStamp, nhdpMessageType)Histogram of the intervals between HELLO messages on an interface
Returns the values (in a 2-dimensional array) that represent a histogram
of intervals between HELLO messages, separated by periodic and
triggered HELLOs. The histogram displays the distribution of
intervals between two consecutive HELLOs of the same type
(triggered or periodical) using a given bin size.
It includes all HELLOs that have been sent after the given
time t0 and before the given time t1.This is a Derived Object to be pulled from the REPORT-MIB.
It is derived from the XXX Base Object.Object name: nhdpMessageSchedulingHistogramObject type: SEQUENCE OF (nhdpMessageType, TimeTicks, Unsigned32)Changes of the frequency of the message scheduling on an interface
This object will divide the given time interval from t0 to t1 into a
given number of equal parts. It then creates a histogram for each
part and calculate the distances (using the Bhattacharyya distance) between
each two adjacent histograms in time. A higher value between two
histograms means more difference between the histograms.
For instance, that could happen if suddenly many triggered HELLO messages
are sent, whereas before there have been only very few such
triggered messages.This is a Derived Object to be pulled from the REPORT-MIB.
It is derived from the XXX Base Object.Object name: nhdpMessageSchedulingFrequencyChangesObject type: SEQUENCE OF (nhdpMessageType, TimeStamp, Float32)Average number of sent HELLO messages per second between
the 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: nhdpHelloSentPerSecondCountObject type: Float32Average number of received HELLO messages per second on an interface between the given time t0 and t1
This is a Derived Object to be pulled from the REPORT-MIB.
It is derived from the XXX Base Object.Object name: nhdpHelloReceivedPerSecondCountObject type: Float32Total accumulated size in octets of sent HELLO messages on an interface
This is a Base Object.Object name: nhdpIfHelloMessageXmitAccumulatedSizeObject type: Counter32Total accumulated size in octets of received HELLO messages on an interface
This is a Base Object.Object name: nhdpIfHelloMessageRecvdAccumulatedSizeObject type: Counter32Average size in octets of sent HELLO messages per second between the 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: nhdpHelloSentPerSecondOctetsObject type: Float32Average size in octets of received HELLO messages per second between the 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: nhdpHelloReceivedPerSecondOctetsObject type: Float32Total accumulated number of advertized symmetric neighbors in HELLOs on that interface
This is a Base Object.Object name: nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCountObject type: Counter32Total accumulated number of advertized heard neighbors in HELLOs on that interface
This is a Base Object.Object name: nhdpIfHelloMessageXmitAccumulatedHeardNeighborCountObject type: Counter32Total accumulated number of advertized lost neighbors in HELLOs on that interface
This is a Base Object.Object name: nhdpIfHelloMessageXmitAccumulatedLostNeighborCountObject type: Counter32Number of expected packets from a given neighbor based on the packet sequence number on an interface
This is a Base Object.Object name: nhdpDiscIfExpectedPacketsObject type: Counter32Success rate of received packets (number of received packets divided by
number of expected packets based on the packet sequence number)
This is a Derived Object to be pulled from the REPORT-MIB.
It is derived from the XXX Base Object.Object name: nhdpDiscIfRevdPacketsSuccessRateObject type: Float32The following objects inspect the frequency of all Neighbor Set changes:
Number of Neighbor Set changes
This object counts each Neighbor Set change. A change occurs whenever a new Neighbor Tuple has been added, a Neighbor Tuple has been removed or any entry of a Neighbor Tuple has been modified.This is a Base Object.Object name: nhdpNibNeighborSetChangesObject type: Counter32Acquire history of Neighbor Set changes
This object returns the history of the exact
timestamps of each time the Neighbor Set has been changed.This is a Derived Object to be pulled from the REPORT-MIB.
It is derived from the XXX Base Object.Object name: nhdpNeighborChangeHistoryObject type: SEQUENCE OF TimeStampHistogram of the intervals between Neighbor Set changes
Returns the values (in a 2-dimensional array)
that represent a histogram of intervals between
Neighbor Set changes.
This is a Derived Object to be pulled from the REPORT-MIB.
It is derived from the XXX Base Object.Object name: nhdpNeighborChangeHistogramObject type: SEQUENCE OF (TimeTicks, Unsigned32)Changes of the frequency of the Neighbor Set changes
This object will divide the given time interval
from t0 to t1 into a given number of equal parts.
It then creates a histogram for each part and calculate
the distances (using the Bhattacharyya distance) between
each two adjacent histograms in time.
A higher value between two histograms means more
difference between the histograms.This is a Derived Object to be pulled from the REPORT-MIB.
It is derived from the XXX Base Object.Object name: nhdpNeighborChangeFrequencyChangesObject type: SEQUENCE OF (TimeStamp, Float32)The next objects examine the uptime of a given neighbor:
Number of changes of a Neighbor Tuple
Returns the number of changes to the given Neighbor Tuple.This is a Base Object.Object name: nhdpDiscNeighborNibNeighborSetChangesObject type: Counter32Neighbor uptime
Returns the number of milliseconds since the Neighbor Tuple corresponding to the given neighbor exists.This is a Base Object.Object name: nhdpDiscNeighborNibNeighborSetUpTimeObject type: Unsigned32Acquire history of change of onlink status of a given neighbor
This object returns the history of the exact timestamps of
each time the neighbor becomes onlink or offlink.
A neighbor is said to become "onlink" if a new Neighbor Tuple
is created that corresponds to the given neighbor.
It becomes "offlink" if such a tuple has been deleted.This is a Derived Object to be pulled from the REPORT-MIB.
It is derived from the XXX Base Object.Object name: nhdpNeighborStatusHistoryObject type: SEQUENCE OF TimeStampHistogram of the intervals between a change of the onlink status of
a given neighbor
Returns the values that represent a histogram of intervals
between a change of the onlink status of a given neighbor.
The histogram includes all changes that have been made after
the given time t0 and before the given time t1.This is a Derived Object to be pulled from the REPORT-MIB.
It is derived from the XXX Base Object.Object name: nhdpNeighborStatusHistogramObject type: SEQUENCE OF (TimeTicks, Unsigned32)The following objects examine the stability of a neighbor.
A neighbor is said to be unstable if it "flaps" frequently between several links.
It is said to be stable if the set of Link Tuples that correspond to the given neighbor is stationary.
Count the changes of the interface over which a
given neighbor can be reached.
This object counts
each time the neighbor changes the interface over which it
is reachable.
That means that the corresponding Link Tuple of the given
link moves from the Link Set of one interface to another
interface.This is a Base Object.Object name: nhdpDiscNeighborNibNeighborSetReachableLinkChangesObject type: Counter32Acquire history of changes of the interface over which a given neighbor can be reached.
This object returns the history of the exact timestamps of
each time the neighbor changes the interface over which it
is reachable.
That means that the corresponding Link Tuple of the given
link moves from the Link Set of one interface to another
interface.This is a Derived Object to be pulled from the REPORT-MIB.
It is derived from the XXX Base Object.Object name: nhdpNeighborIfChangeHistoryObject type: SEQUENCE OF (TimeStamp)Histogram of the intervals between a change of the interface over
which a given neighbor is reachable
Returns the values that represent a histogram of intervals
between a change of the interface over which a given neighbor is
reachable after the given time t0 and before the given
time t1.This is a Derived Object to be pulled from the REPORT-MIB.
It is derived from the XXX Base Object.Object name: nhdpNeighborIfChangeHistogramObject type: SEQUENCE OF (
TimeTicks, Unsigned32))The following objects inspect the stability of a given 2-hop neighbor:
Count the changes of the N2_neighbor_iface_addr_list of
a given 2-hop neighbor
This object returns the count of the
times the 2-hop neighbor changes its N2_neighbor_iface_addr_list,
i.e. the neighbor over which it is reachable.This is a Base Object.Object name: nhdpIib2HopSetPerfChangesObject type: Counter32Acquire history of changes of the N2_neighbor_iface_addr_list of
a given 2-hop neighbor (Note: Not sure what the Base Object
is for this set and not clear how to capture in the REPORT-MIB.)
This object returns the history of the exact timestamps of
each time the 2-hop neighbor changes its N2_neighbor_iface_addr_list,
i.e. the neighbor over which it is reachable.This is a Derived Object to be pulled from the REPORT-MIB.
It is derived from the XXX Base Object.Object name: nhdpN2ReachabilityChangeHistoryObject type: SEQUENCE OF (TimeStamp)Histogram of the intervals between a change of a 2-hop
neighbor's N2_neighbor_iface_addr_list
Returns the values that represent a histogram of intervals
between a change of the 2-hop neighbor's N2_neighbor_iface_addr_list
after the given time t0 and before the given time t1.This is a Derived Object to be pulled from the REPORT-MIB.
It is derived from the XXX Base Object.Object name: nhdpN2ReachabilityChangeHistogramObject type: SEQUENCE OF (TimeTicks, Unsigned32)The next objects examine the uptime of a given 2-hop neighbor:
2-hop Neighbor uptime
Returns the number of milliseconds since the
2-Hop Tuple corresponding to the given 2-hop neighbor IP
address exists.This is a Base Object.Object name: nhdpIib2HopSetPerfUpTimeObject type: Unsigned32Acquire history of change of onlink status of a given 2-hop neighbor
This object returns the history of the exact timestamps of each
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 created that corresponds to the given 2-hop neighbor.
It becomes "offlink" if such a tuple has been deleted.This is a Derived Object to be pulled from the REPORT-MIB.
It is derived from the XXX Base Object.Object name: nhdpN2StatusHistoryObject type: SEQUENCE OF (TimeStamp)Histogram of the intervals between a change of the onlink status
of a given 2-hop neighbor
Returns the values that represent a histogram of intervals between
a change of the onlink status of a given 2-hop neighbor.
The histogram includes all changes that have been made after the
given time t0 and before the given time t1.This is a Derived Object to be pulled from the REPORT-MIB.
It is derived from the XXX Base Object.Object name: nhdpN2StatusHistogramObject type: SEQUENCE OF (TimeTicks, Unsigned32)If Link Quality is used, the following object provides information about the
link quality of a given link:
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 is derived from the XXX Base Object.Object name: nhdpLinkQualityHistoryObject type: SEQUENCE OF (nhdpNibNeighborSetRouterId, TimeStamp, Float32)The Notifications Subtree contains the list of notifications supported within the
NHDP MIB and their intended purpose or utility.
This group is currently empty, pending further discussion.[TODO]: The text of this section specifies the
relationship of the MIB modules contained in this document to
other standards, particularly to standards containing other MIB
modules. Definitions imported from other MIB modules and other MIB
modules that SHOULD be implemented in conjunction with the MIB
module contained within this document are identified in this section.The 'system' group in the SNMPv2-MIB
is defined as being mandatory for all systems, and the objects apply
to the entity as a whole. The 'system' group provides identification
of the management entity and certain other system-wide data. The
NHDP-MIB does not duplicate those objects.[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.[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 , SNMPv2-TC ,
SNMPv2-CONF , and IF-MIB [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
include the following boilerplate paragraph.There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such objects
may be considered sensitive or vulnerable in some network environments.
The support for SET operations in a non-secure environment without
proper protection can have a negative effect on network operations.
These are the tables and objects and their
sensitivity/vulnerability:[TODO] writable MIB objects that could be especially disruptive
if abused MUST be explicitly listed by name and the associated
security risks MUST be spelled out; RFC 2669 has a very good
example.[TODO] list the writable tables and objects and state why they
are sensitive.[TODO] else if there are no read-write objects in your MIB module,
use the following boilerplate paragraph.There are no management objects defined in this MIB module that have
a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB
module is implemented correctly, then there is no risk that an intruder
can alter or create any management objects of this MIB module via direct
SNMP SET operations.[TODO] if you have any sensitive readable objects, please include the
following boilerplate paragraph.Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. It is thus important to control
even GET and/or NOTIFY access to these objects and possibly to even
encrypt the values of these objects when sending them over the network
via SNMP. These are the tables and objects and their
sensitivity/vulnerability: [TODO] you must explicitly list by name any readable objects that
are sensitive or vulnerable and the associated security risks MUST
be spelled out (for instance, if they might reveal customer
information or violate personal privacy laws such as those of the
European Union if exposed to unauthorized parties)[TODO] list the tables and objects and state why they are
sensitive.[TODO] discuss what security the protocol used to carry the
information should have. The following three boilerplate paragraphs
should not be changed without very good reason. Changes will almost
certainly require justification during IESG review.SNMP versions prior to SNMPv3 did not include adequate security. 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 allowed to access
and GET/SET (read/change/create/delete) the objects in this MIB
module.It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see ,
section 8), including full support for the SNMPv3 cryptographic
mechanisms (for authentication and privacy).Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable
cryptographic security. It is then a customer/operator responsibility to
ensure that the SNMP entity giving access to an instance of this MIB
module is properly configured to give access to the objects only to
those principals (users) that have legitimate rights to indeed GET or
SET (change/create/delete) them.[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: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 MIB document uses the
template authored by D. Harrington which is
based on contributions from the MIB Doctors,
especially Juergen Schoenwaelder, Dave Perkins, C.M.Heard and Randy
Presuhn.[TODO]This acknowledgement can be removed from your MIB module
document.The Interfaces Group MIBManagement Information Base (MIB) for the Simple Network Management Protocol (SNMP)Key words for use in RFCs to Indicate Requirement LevelsHarvard UniversityStructure of Management Information Version 2 (SMIv2)Textual Conventions for SMIv2Cisco Systems, Inc.SNMPinfoTU BraunschweigConformance Statements for SMIv2Cisco Systems, Inc.SNMPinfoTU BraunschweigThe MANET Neighborhood Discovery Protocol (NHDP)The MANET Report MIBJitter Considerations in Mobile Ad Hoc Networks (MANETs)Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)Introduction and Applicability Statements for Internet-Standard Management FrameworkHere 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-01 draft to generate
the draft-ietf-manet-nhdp-mib-02 draft.Cleaned up several things (e.g. moved N_HOLD_TIME from interface parameter to router paramter)Updated to NHDP draft version 11We list here the changes made on the draft-ietf-manet-nhdp-mib-00 draft to generate
the draft-ietf-manet-nhdp-mib-01 draft.Made and extensive addition in the area of performance monitoring. Added text
in the front material, added a PerformanceGroup to the MIB and added the PerformanceGroup
to the Conformance Sections.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.Cleanup up numerous typos and add material to the Conformance section in order
to pass the MIB checker, i.e., smilint.We list here the changes made on the draft-cole-manet-nhdp-mib-00 draft to generate
the draft-cole-manet-nhdp-mib-01 draft.Defined the NeighborIfIndex and the NeighborRouterId textual conventions. These
identify a remote neighbor IfIndex and a remote neighbor router and are
used as indexes into NHDP state tables. These constructs were necessary in order
to associate address lists with specific remote interfaces as required by the
NHDP protocol specification.Developed the nhdpInterfaceTable as part of the configuration group.Developed the nhdpDiscIfSetTable as a means to associate address lists with
remotely discovered neighbor interfaces.Added tables defining the router's NHDP Local Information Base (LIB)
as specified in the NHPD protocol specification.Added tables defining the router's NHDP Interface information Base (IIB)
as specified in the NHPD protocol specification.Added tables defining the router's NHDP Neighbor Information Base (NIB)
as specified in the NHPD protocol specification.Aligned the NHDP-MIB and the OLSRv2-MIB configuration tables and indexing.This section contains the set of open issues related to the
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 the open issues have been resolved.How to handle dynamic parameters within NHDP? Should
we expose setting, min and max values?Need to address how to handle Link Quality settings and
parameters for a) optional operation and b) changing nature
of link quality.What notifications are of interest and utility?Identify all objects requiring non-volatile storage in their
DESCRIPTION clauses.Incorporate parameter relationship conditions into their
DESCRIPTION clauses.Also, specify specific SNMP response
to the snmp set request, i.e., 'generic error', 'bad value', etc.Fill in all of the DEFVAL within the configuration group objects.Run through the MIB checker.Clean up all of the 'Note:' statements within the body of the MIB. Work on the Security Section. This MIB does have
settable objects, but not sensitive objects (true?).Work on the relationship to other MIBs, IF-MIB, NHDP-MIB.Cleanup all the [TODOs] from the MIB template.