Definition of Managed Objects for the MANET
Optimized Link State Routing Protocol version 2LIX, 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/LIX, Ecole PolytechniquePalaiseau Cedex91128France+33 6 6058 9349T.Clausen@computer.orghttp://www.ThomasClausen.org/
Routing
Internet Engineering Task ForceNetwork ManagementManagement Information BaseMIBSMIv2RoutingMANETOptimized Link StateThis 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 and managing
aspects of the Optimized Link State Routing protocol version 2.
The Optimized Link State Routing MIB also reports
state information, performance metrics, and notifications. In addition
to configuration, this additional state and performance information is
useful to management stations troubleshooting Mobile Ad-Hoc Networks
routing 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 a process
implementing the Optimized Link State Routing Protocol version 2 (OLSRv2)
.
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 Optimized Link State Routing (OLSR) protocol version 2 (OLSRv2) is a table driven, proactive routing protocol, i.e. it exchanges topology information with other routers in the network regularly. OLSRv2 is an optimization of the classical link state routing protocol. Its key concept is that of MultiPoint Relays (MPRs). Each router selects a set of its neighbor routers (which "cover" all of its symmetrically connected 2-hop neighbor routers) as MPRs. MPRs are then used to achieve both flooding reduction and topology reduction.This MIB document provides management and control capabilities of an OLSRv2 instance, allowing to monitor the state and performance of an OLSRV2 router, as well as to change settings of the deployment.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 OLSRv2 routing process in the router.Performance Objects - automatically generated values which help
an administrator or automated tool to assess the performance of the
OLSRv2 routing process on the router and the overall packet forwarding
performance within the MANET routing domain.This section presents the structure of the Optimized Link State Routing version 2 Management Information Base (OLSRv2-MIB) module. The objects are arranged into the following groups:olsrMIBNotifications - defines the notifications associated with the
OLSRv2-MIB.olsrMIBObjects - defines the objects forming the basis for the OLSRv2-MIB. These objects are divided up by function into the following
groups:
Configuration Group - This group contains the OLSRv2 objects that
configure specific options that determine the overall operation of
the OLSRv2 routing process and the unicast packet forwarding performance.State Group - Contains information describing the current state
of the OLSRv2 routing process, in particular the Information Bases of OLSRv2.Performance Group - Contains objects which help to characterize
the performance of the OLSRv2 routing process, typically statistics
counters.olsrMIBConformance - defines minimal and full conformance of
implementations to this OLSRv2-MIB.The textual conventions used in the OLSRv2-MIB are as follows. The
RowStatus textual convention is imported from RFC 2579 . The OLSRv2 device is configured with a set of controls. The list of
configuration controls for the OLSRv2 device follows.Local History Times
O_HOLD_TIME - is used to define the time for which a recently used and replaced originator address is used to recognize the router's own messages.Message Intervals
TC_INTERVAL - is the maximum time between the transmission of two successive TC messages by this router.TC_MIN_INTERVAL - is the minimum interval between transmission of two successive TC messages by this router.Advertised Information Validity Times
T_HOLD_TIME - is used to define the minimum Value in the VALIDITY_TIME TLV included in all TC messages sent by this router.A_HOLD_TIME - is the period during which TC messages are sent after they no longer have any advertised information to report, but are sent in order to accelerate outdated information removal by other routers.Received Message Validity Times
RX_HOLD_TIME - is an interface parameter, and is the period after receipt of a message by the appropriate OLSRv2 interface of this router for which that information is recorded, in order that the message is recognized as having been previously received on this OLSRv2 interface.P_HOLD_TIME - is a router parameter, and is the period after receipt of a message which is processed by this router for which that information is recorded, in order that the message is not processed again if received again.F_HOLD_TIME - is a router parameter, and is the period after receipt of a message which is forwarded by this router for which that information is recorded, in order that the message is not forwarded again if received again.Jitter
TP_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] for periodically generated TC messages sent by this router.TT_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] for externally triggered TC messages sent by this router.F_MAXJITTER - represents the default value of MAXJITTER used in [RFC5148] for messages forwarded by this router.Hop Limit Parameter
TC_HOP_LIMIT - is the hop limit set in each TC message.Willingness
WILLINGNESS - represents the router's willingness to be an MPR, and hence its willingness to forward messages and be an intermediate router on routes.The State Subtree reports current state information.
In OLSRv2, the state is stored in Information Bases. These are separately discussed below.The Local Information Base (LIB), contains a router's local configuration, as defined by NHDP. It is extended in the OLSRv2 specification to also record an originator address and to include a router's:"Originator Set", which consists of Originator Tuples,
each of which contains addresses that were recently used as
this router's originator address."Local Attached Network Set", which consists of Local Attached Network Set Tuples, each of which contains addresses of networks to which this router can act as a gateway.The Interface Information Based (IIB),
recording information regarding
links on each MANET interface and symmetric 2-hop neighbors which
can be reached through such links. In addition to the uses in NHDP, information recorded in the Interface Information Bases is used for completing the Routing Set.
The IIB contains two tables:A "Link Set", which records links from other routers which are, or recently were, 1-hop neighbors. It consists of Link Tuples, each representing a single link.A "Two-Hop Set", which records network addresses of symmetric 2-hop neighbors, and the symmetric links to symmetric 1-hop neighbors through which these symmetric 2-hop neighbors can be reached. It consists of 2-Hop Tuples, each representing a single network address of a symmetric 2-hop neighbor, and a single MANET interface of a symmetric 1-hop neighborThe Neighbor Information Base (NIB),
records information regarding current
and recently lost 1-hop neighbors of this router.
The NIB contains two tables:The "Neighbor Set", which records all network addresses of each 1-hop neighbor. It consists of Neighbor Tuples, each representing a single 1-hop neighbor.The "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 address.The Topology Information Base (TIB),
records information used for the calculation
of the Routing Set.
The TIB contains five tables:The "Advertising Remote Router Set", which records information describing each remote router in the network that transmits TC messages, allowing outdated TC messages to be recognized and discarded. It consists of Advertising Remote Router Tuples.The "Router Topology Set", which records topology information about the links between routers in the MANET, allowing a "backbone" graph of all routers to be constructed using a minimum distance algorithm. It consists of Router Topology Tuples.The "Routable Address Topology Set", which records topology information about the routable addresses within the MANET, and via which routers they may be reached. It consists of Routable Address Topology Tuples.The "Attached Network Set", which records information about networks (which may be outside the MANET) attached to other routers and their routable addresses. It consists of Attached Network Tuples.The "Routing Set", which records the first hop along a selected path to each destination for which any such path is known. It consists of Routing Tuples.The Received Message Information Base (RMIB),
records information regarding messages, that have
been previously received, processed, or forwarded
by this router.
The RMIB contains three tables:The "Received Set", which records the signatures of messages which have been received over that OLSRv2 interface. Each consists of Received Tuples.The "Processed Set", which records signatures of messages which have been processed by the router. It consists of Processed Tuples.The "Forwarded Set", which records signatures of messages which have been forwarded by the router. It consists of Forwarded Tuples.The Performance Group reports values relevant to system performance.
This section lists objects for OLSRv2 performance monitoring,
some of which explicitly appear in the OLSRv2-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 in this group can be used to examine stability of the Routing Set, the selected MPRs, as well as message scheduling of this router.
The following objects return statistics to the frequency of Routing Set recalculations.
Number of Routing Set recalculations
This object counts each recalculation of the Routing Set.This is a Base Object.Object name: olsrv2RoutingSetRecalculationCountObject type: Counter32Acquire history of Routing Set recalculations
This object returns the history of the exact timestamps of each time the Routing Set has been recalculated.This is a Derived Object to be pulled from the REPORT-MIB. It is derived from the XXX Base Object.Object name: olsrv2RoutingSetRecalculationHistoryObject type: SEQUENCE OF TimeStampHistogram of the intervals between Routing Set recalculations
Returns the values that represent a histogram of intervals between Routing Set recalculations. This is a Derived Object to be pulled from the REPORT-MIB. It is derived from the XXX Base Object.Object name: olsrv2RoutingSetRecalculationHistogramObject type: SEQUENCE OF (TimeTicks, Unsigned32)Changes of the frequency of the Routing Set recalculations
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: olsrv2RoutingSetRecalculationFrequencyChangesObject type: SEQUENCE OF (TimeStamp, Float32)
The following objects return statistics to the frequency of recalculating the MPRs of this router.
Number of MPR recalculations
This object counts each recalculation of the MPRs of the router.This is a Base Object.Object name: olsrv2MPRSetRecalculationCountObject type: Counter32Acquire history of MPR recalculations
This object returns the history of the exact timestamps of each time the MPRs have been recalculated.This is a Derived Object to be pulled from the REPORT-MIB.
It is derived from the XXX Base Object.Object name: olsrv2MPRSetRecalculationHistoryObject type: SEQUENCE OF TimeStampHistogram of the intervals between MPR recalculations
Returns the values that represent a histogram of intervals between MPR recalculations. 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: olsrv2MPRSetRecalculationHistogramObject type: SEQUENCE OF (TimeTicks, Unsigned32)Changes of the frequency of MPR recalculations
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: olsrv2MPRSetRecalculationFrequencyChangesObject type: SEQUENCE OF (TimeStamp, Float32)
The following objects return some of the statistics related to TC messages:
Total number of sent TC messages on an interface
This is a Base Object.Object name: olsrv2IfTcMessageXmitsObject type: Counter32Total number of received TC messages on an interface
This is a Base Object.Object name: olsrv2IfTcMessageRecvdObject type: Counter32Total number of sent periodic TC messages on an interface
This is a Base Object.Object name: olsrv2IfTcMessagePeriodicXmitsObject type: Counter32Total number of sent triggered TC messages on an interface
This is a Base Object.Object name: olsrv2IfTcMessageTriggeredXmitsObject type: Counter32Total number of forwarded TC messages on an interface
This is a Base Object.Object name: olsrv2IfTcMessageForwardedXmitsObject type: Counter32Acquire history of TC message scheduling instance for the given time duration on an interface
This object returns the history of the exact timestamps of
each TC 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: olsrv2MessageSchedulingHistoryObject type: SEQUENCE OF (TimeStamp, olsrv2MessageType)Histogram of the intervals between TC messages on an interface
Returns the values (in a 2-dimensional array) that represent a histogram
of intervals between TC messages, separated by periodic and
triggered TC. The histogram displays the distribution of
intervals between two consecutive TC of the same type
(triggered or periodical) using a given bin size.
It includes all TC 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: olsrv2MessageSchedulingHistogramObject type: SEQUENCE OF (olsrv2MessageType, 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 TC 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: olsrv2MessageSchedulingFrequencyChangesObject type: SEQUENCE OF (olsrv2MessageType, TimeStamp, Float32)Average number of sent TC 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: olsrv2HelloSentPerSecondCountObject type: Float32Average number of received TC 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: olsrv2HelloReceivedPerSecondCountObject type: Float32Total accumulated size in octets of sent TC messages on an interface
This is a Base Object.Object name: olsrv2IfHelloMessageXmitAccumulatedSizeObject type: Counter32Total accumulated size in octets of received TC messages on an interface
This is a Base Object.Object name: olsrv2IfHelloMessageRecvdAccumulatedSizeObject type: Counter32Average size in octets of sent TC 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: olsrv2HelloSentPerSecondOctetsObject type: Float32Average size in octets of received TC 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: olsrv2HelloReceivedPerSecondOctetsObject type: Float32Total accumulated number of advertized MPR selectors in TC messages on an interface
This is a Base Object.Object name: olsrv2IfHelloMessageXmitAccumulatedSymmetricNeighborCountObject type: Counter32The Notifications Subtree contains the list of notifications
supported within the OLSRv2-MIB and their intended purpose or utility.
This group is currently empty.[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
OLSRv2-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 OLSRv2-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 place holders (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.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 Optimized Link State Routing Protocol version 2The MANET Report MIBIntroduction and Applicability Statements for Internet-Standard Management FrameworkThis section identifies the changes made during the development of this MIB.Here we list the changes made in developing draft-ietf-manet-olsrv2-mib-01.Added Performance Group objectsUpdated draft to adhere to the current version of the OLSRv2 draft.Cleaned up errors.Added U. Herberg as new author.Here we list the changes made in developing draft-ietf-manet-olsrv2-mib-00.Rev'd the draft as a new working group document.Ran 'smilint' against the module and cleaned up syntax errors and
other issues discovered by the checker.Here we list the changes made in developing draft-cole-manet-olsr-mib-01.Completely reworked the entire Configuration Objects group in order to
align with the newly developed NHDP-MIB draft.This section contains the set of open issues related to the
development and design of the OLSRv2-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.Look into possible redundancy between the TIB Routing Set
and the latest standard MIB forwarding table.Fill out the performance objects group.Complete notification group.Complete conformance group.Work on the relationship to other MIBs, IF-MIB, NHDP-MIB.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 with
their correct values.Run through the MIB checker.Complete the security analysis and section.Clean up all of the 'Note:' statements within the body of the MIB. Cleanup all the [TODOs] from the MIB template.