Definition of Managed Objects for the Mobile Ad Hoc
Network (MANET)
Simplified Multicast Framework Relay Set ProcessUS Army CERDEC6010 Frankford RoadAberdeen Proving GroundMaryland21005United States+1 443 395 8744robert.g.cole@us.army.milNaval Research LaboratoryWashingtonD.C.20375United Statesmacker@itd.nrl.navy.milNaval Research LaboratoryWashingtonD.C.20375United Statesadamson@itd.nrl.navy.mil
Routing
Internet Engineering Task ForceNetwork ManagementManagement Information BaseMIBSMIv2RoutingMANETMulticastThis 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
Simplified Multicast Forwarding (SMF) process for Mobile Ad Hoc
Networks (MANETs). The SMF-MIB module also reports
state information, performance information, and notifications. In addition
to configuration, the additional state and performance information is
useful to operators troubleshooting multicast forwarding
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 Simplified Multicast Forwarding (SMF)
for Mobile Ad Hoc Networks (MANETs).
SMF provides multicast Duplicate
Packet Detection (DPD) and supports algorithms for constructing an
estimate of a MANET Minimum Connected Dominating
Set (MCDS) for efficient multicast forwarding. The SMF-MIB module also reports
state information, performance information, and notifications. In addition
to configuration, this additional state and performance information is
useful to operators troubleshooting multicast forwarding
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", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
RFC 2119 .SMF provides methods for implementing
DPD-based multicast forwarding
with the optional use of CDS-based relay sets.
The CDS provides a complete connected coverage of the nodes comprising
the MANET. The MCDS is the smallest
set of MANET nodes (comprising a connected cluster) that cover all the
nodes in the cluster with their transmissions. As the density of the
MANET nodes increase, the fraction of nodes required in an MCDS
decreases. Using the MCDS as a multicast forwarding set then becomes an
efficient multicast mechanism for MANETs.Various algorithms for the construction of estimates of the MCDS
exist. The Simplified Multicast Framework
describes some of these. It further
defines various operational modes for a node that is participating in
the collective creation of the MCDS estimates. These modes depend upon
the set of related MANET routing and discovery protocols and mechanisms
in operation in the specific MANET node.A SMF router's MIB module contains SMF process configuration parameters
(e.g., specific CDS algorithm), state information (e.g., current
membership in the CDS), performance counters (e.g., packet counters),
and notifications.This section describes the management model for the SMF node
process.Figure 1 (reproduced from Figure 1 of
) shows the relationship between the SMF
Relay Set Selection Algorithm and the related algorithms, processes,
and protocols running in the MANET nodes. The Relay Set Selection
Algorithm (RSSA) can rely upon topology information acquired from the
MANET Neighborhood Discovery Protocol (NHDP), from the specific MANET
routing protocol running on the node, or from Layer 2 information
passed up to the higher layer protocol processes.The following definitions apply throughout this document: switches, tables, and objects that are
initialized to default settings or set through the management
interfaces such as defined by this MIB module.objects whose values affect
timing or attempt bounds on the SMF Relay Set (RS) process. automatically generated values that define the
current operating state of the SMF RS process in the router. automatically generated values that help
an administrator or automated tool to assess the performance of the
CDS multicast process on the router and the overall multicast
performance within the MANET routing domain.This section presents the structure of the SMF-MIB module. The
objects are arranged into the following groups:smfMIBNotifications - defines the notifications associated with the
SMF process.smfMIBObjects - defines the objects forming the basis for the
SMF-MIB module. These objects are divided up by function into the following
groups:
Capabilities Group - This group contains the SMF objects that
the device uses to advertise its local capabilities with respect
to, e.g., the supported RSSAs.Configuration Group - This group contains the SMF objects that
configure specific options that determine the overall operation of
the SMF process and the resulting multicast performance.State Group - Contains information describing the current state
of the SMF process such as the Neighbor Table.Performance Group - Contains objects that help to characterize
the performance of the SMF process, typically
counters for statistical computations.smfMIBConformance - defines two, i.e., minimal and full, conformance
implementations for the SMF-MIB module.The Textual Conventions defined within the SMF-MIB module:The SmfStatus is defined within the SMF-MIB module.
This contains the current operational status of the
SMF process on an interface.The Textual Conventions defined for the SMF-MIB module
and maintained by IANA
are:The IANAsmfOpModeIdTC represents an index that identifies
a specific SMF operational mode. This Textual Convention
is maintained by IANA in the IANA-SMF-MIB.The IANAsmfRssaIdTC represents an index that identifies, through
reference, a specific RSSA available for
operation on the device. This Textual Convention
is maintained by IANA also in the IANA-SMF-MIB.The SMF device supports a set of capabilities. The list of
capabilities that the device can advertise is as follows:Operational Mode - topology information from NHDP, CDS-aware
unicast routing, or Cross-layer from Layer 2.SMF RSSA - the specific RSSA operational on the device. Note that
configuration, state, and performance objects related to a specific
RSSA must be defined within a separate MIB module.The SMF device is configured with a set of controls.
Some of the prominent
configuration controls for the SMF device are:Operational Mode - determines from where topology information
is derived, e.g., NHDP, CDS-aware
unicast routing, or Cross-layer from Layer 2.SMF RSSA - the specific RSSA operational on the device.Duplicate Packet detection for IPv4 - Identification-based or
Hash-based DPD (I-DPD or H-DPD, respectively).Duplicate Packet detection for IPv6 - Identification-based or
Hash-based DPD.SMF Type Message TLV - if NHDP mode is selected, then the
SMF Type Message TLV MAY be included in the NHDP exchanges.SMF Address Block TLV - if NHDP mode is selected, then
the SMF Address Block TLV SHOULD be included in the NHDP exchanges.SMF Address Forwarding Table - a table identifying
configured multicast addresses to be forwarded by the SMF process.The State sub-tree reports current state information, for example,Node RSSA State - identifies whether the node is currently
in or out of the Relay Set.Neighbors Table - a table containing current one-hop neighbors and their
operational RSSA.The Performance sub-tree primarily reports counters that relate to
SMF RSSA performance. The SMF performance counters consist of per-node and per-interface objects:Total multicast packets received.Total multicast packets forwarded.Total duplicate multicast packets detected.Per interface statistics table with the following entries:
Multicast packets received.Multicast packets forwarded.Duplicate multicast packets detected.The Notifications sub-tree contains the list of notifications
supported within the SMF-MIB module and their intended purpose and utility.
The SMF-MIB module contains a number of tables that record
data related to:
configuration and operation of packet forwarding on the local router,configuration and operation of local MANET interfaces on the router, andconfiguration and operation of various RSSAs for
packet forwarding.The SMF-MIB module's tables are indexed via the following constructs:
smfCapabilitiesIndex - the index identifying the
combination of SMF mode and SMF RSSA available on this device.smfCfgAddrForwardingIndex - the index to configured multicast address
lists that are forwarded by the SMF process.smfCfgIfIndex - the IfIndex of the interface on the local router on which
SMF is configured.smfStateNeighborIpAddrType, smfStateNeighborIpAddr, and
smfStateNeighborPrefixLen - the interface index set of specific
one-hop neighbor nodes to this local router.These tables and their associated indexing are defined in the SMF-MIB module:
smfCapabilitiesTable - identifies the resident
set of (SMF Operational Modes, SMF RSSA algorithms)
available on this router.
This table has 'INDEX { smfCapabilitiesIndex }'.smfCfgAddrForwardingTable - contains information on
multicast addresses that are to be forwarded by the
SMF process on this device.
This table has 'INDEX { smfCfgAddrForwardingIndex }'.smfCfgInterfaceTable - describes the SMF interfaces on this
device that are participating in the SMF packet forwarding
process.
This table has 'INDEX { smfCfgIfIndex }'.smfStateNeighborTable - describes the current neighbor nodes,
their addresses and the SMF RSSA and the interface on which
they can be reached.
This table has 'INDEX { smfStateNeighborIpAddrType,
smfStateNeighborIpAddr, smfStateNeighborPrefixLen }'.smfPerfIpv4InterfacePerfTable - contains the IPv4-related SMF statistics
per each SMF interface on this device.
This table has 'INDEX { smfCfgIfIndex }'.smfPerfIpv6InterfacePerfTable - contains the IPv6-related SMF statistics
per each SMF interface on this device.
This table has 'INDEX { smfCfgIfIndex }'.The 'system' group in the SNMPv2-MIB module
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
SMF-MIB module does not duplicate those objects.It is an expectation that SMF devices will
implement the standard IP-MIB module .
Exactly how to integrate SMF packet handling and management
into the standard IP-MIB module management are part of the experiment.The SMF-MIB module counters within the smfPerformanceGroup count packets
handled by the system and interface local SMF process (as discussed
above). Not all IP (unicast and multicast) packets on a device interface
are handled by the SMF process. So the counters are tracking different
packet streams in the IP-MIB and SMF-MIB modules.The smfCfgAddrForwardingTable is essentially a filter table (if
populated) that identifies addresses/packets to be forwarded via the local SMF
flooding process. The IP Multicast MIB module in RFC 5132
manages objects related to standard IP multicast,
which could be running in parallel to SMF on the device.RFC 5132 manages traditional IP-based multicast (based upon multicast
routing mechanisms). The SMF-MIB module provides management for a MANET subnet-based
flooding mechanism which, may be used for multicast transport (through SMF
broadcast) depending upon the MANET dynamics and other factors regarding the MANET subnet.
Further, they may coexist in certain MANET deployments
using the smfCfgAddrForwardingTable to
hand certain IP multicast addresses to the SMF process and other IP
multicast packets to be forwarded by other multicast mechanisms that are IP route based.
SMF and the associated SMF-MIB module
are experimental and these are some of the experiments to be
had with SMF and the SMF-MIB module.The objects imported for use in the SMF-MIB module are as
follows. The MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Counter32, Integer32, TimeTicks and experimental macros are
imported from RFC 2578 . The TEXTUAL-CONVENTION, RowStatus,
and TruthValue macros are imported from RFC 2579
. The MODULE-COMPLIANCE, OBJECT-GROUP, and NOTIFICATION-GROUP macros are imported from RFC 2580 . The
InterfaceIndexOrZero and ifName textual conventions are imported from RFC 2863
. The SnmpAdminString textual convention is imported from
RFC 3411 . The InetAddress, InetAddressType, and
InetAddressPrefixLength textual conventions are imported from RFC
4001 .In a sense, the SMF-MIB module is a general front-end to a set of yet-to-be
developed RSSA-specific MIB modules. These RSSA-specific MIB modules will define the objects
for the configuration, state, performance and notification
required for the operation of these specific RSSAs. The SMF-MIB module Capabilities
Group allows the remote management station the ability to query the
router to discover the set of supported RSSAs.This section contains the IANA-SMF-MIB module.
This MIB module defines two
Textual Conventions for which IANA SHOULD
maintain and keep synchronized with the registry
identified below within the
IANAsmfOpModeIdTC and the
IANAsmfRssaIdTC TEXTUAL-CONVENTIONs.
The IANAsmfOpModeIdTC defines an index
that identifies through reference to a
specific SMF operations mode. The index is an integer valued
named-number enumeration consisting of an integer and label.
IANA is to create and maintain this Textual Convention.
Future assignments are made to anyone on a first come,
first served basis.
There is no substantive review of the request, other than to
ensure that it is well-formed and does not duplicate an
existing assignment. However, requests must include a
minimal amount of clerical information, such as a point of
contact (including an email address) and a brief description
of the method being identified as a new SMF operations mode.
The IANAsmfRssaIdTC defines an index
that identifies through reference to a
specific Reduced Set Selection Algorithm (RSSA).
The index is an integer valued
named-number enumeration consisting of an integer and label.
IANA is to create and maintain this Textual Convention.
Future assignments to the
IANAsmfRssaIdTC for the index range 5-127
require an RFC publication
(either as an IETF submission or as
an Independent submission ).
The category of RFC MUST be Standards Track.
The specific RSSAs MUST be
documented in sufficient detail so that interoperability
between independent implementations is possible.
Future assignments to the
IANAsmfRssaIdTC for the index range 128-239
are private or local use only, with the type and
purpose defined by the local site. No attempt is made to
prevent multiple sites from using the same value in
different (and incompatible) ways. There is no need for
IANA to review such assignments (since IANA will not record
these), and assignments are not generally useful for broad
interoperability. It is the responsibility of the sites
making use of the Private Use range to ensure that no
conflicts occur (within the intended scope of use).
Future assignments to the
IANAsmfRssaIdTC for the index range 240-255
are to facilitate experimentation.
These require an RFC publication
(either as an IETF submission or as
an Independent submission ).
The category of RFC MUST be Experimental.
The RSSA algorithms MUST be
documented in sufficient detail so that interoperability
between independent implementations is possible.
This MIB module references , ,
, and .
This section discusses security implications of the choices made in this
SMF-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 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:'smfCfgAdminStatus' - this writable configuration object controls the
operational status of the SMF process. If this setting is configured
inconsistently across the MANET multicast domain, then delivery of
multicast data may be inconsistent across the domain; some nodes may
not receive multicast data intended for them.'smfCfgRouterIDAddrType' and 'smfCfgRouterID' - these writable
configuration objects define the
ID of the SMF process. These objects should be configured
with a routable address defined on the local SMF device.
The smfCfgRouterID is a logical identification
that MUST be configured as unique across interoperating
SMF neighborhoods, and it is RECOMMENDED to be
chosen as the numerically largest address
contained in a node's 'Neighbor Address List'
as defined in NHDP. A smfCfgRouterID MUST be
unique within the scope of the operating
MANET network regardless of the method used
for selecting it. If these objects are misconfigured
or configured inconsistently across the MANET, then the
ability of various RSSAs, e.g., eCDS, may be
compromised. This would potentially result in some
routers within the MANET not receiving multicast packets
destine to them. Hence, intentionally misconfiguring these
objects could pose a form of Denial-of-Service (DoS) attack
against the MANET.'smfCfgOpMode' - this writable configuration object defines the
operational mode of the SMF process. The operational mode
defines how the SMF process receives its data to form
its local estimate of the CDS. It is recommended that the value for this
object be set consistently across the MANET to ensure proper operation
of the multicast packet forwarding. If the value for this object is set
inconsistently across the MANET, the result may be that multicast packet
delivery will be compromised within the MANET.
Hence, intentionally misconfiguring this object could pose a form
DoS attack against the MANET.'smfCfgRssa' - this writable configuration object sets the specific
RSSA for the SMF process. If this
object is set inconsistently across the MANET domain, multicast
delivery of data will likely fail.
Hence, intentionally misconfiguring this object could pose a form
DoS attack against the MANET.'smfCfgRssaMember' - this writable configuration object sets the 'interest'
of the local SMF node in participating in the CDS. Setting this
object to 'never(3)' on a highly connected device could lead
to frequent island formation. Setting this object to 'always(2)'
could support data ex-filtration from the MANET domain.'smfCfgIpv4Dpd' - this writable configuration object sets the duplicate
packet detection method, i.e., H-DPD or I-DPD, for forwarding of
IPv4 multicast packets. Forwarders may operate with mixed H-DPD and
I-DPD modes as long as they consistently perform the appropriate DPD
routines outlined in . However, it is
RECOMMENDED that a deployment be configured with a common mode
for operational consistency.'smfCfgIpv6Dpd' - this writable configuration object sets the duplicate
packet detection method for the forwarding of IPv6 multicast packets.
Since IPv6 SMF does specify an option header, the
interoperability constraints are not as loose as in the IPv4 version, and
forwarders SHOULD NOT operate with mixed H-DPD and I-DPD modes.
Hence, the value for this object SHOULD be consistently set within the
forwarders comprising the MANET, else inconsistent forwarding
may result unnecessary multicast packet dropping.'smfCfgMaxPktLifetime' - this writable configuration object sets the
estimate of the network packet traversal time. If set too small,
this could lead to poor multicast data delivery ratios throughout
the MANET domain. This could serve as a form of DoS attack if
this object value is set too small.'smfCfgDpdEntryMaxLifetime' - this writable configuration object sets the
maximum lifetime (in seconds) for the cached DPD records
for the combined IPv4 and IPv6 methods. If the memory
is running low prior to the MaxLifetime being exceeded, the
local SMF devices should purge the oldest records first. If this object
value is set too small, then the effectiveness of the SMF DPD
algorithms may become greatly diminished causing a higher than
necessary packet load on the MANET.'smfCfgNhdpRssaMesgTLVIncluded' - this writable configuration object
indicates whether or not the associated NHDP messages include
the RSSA Message TLV. It is highly RECOMMENDED that
this object be set to 'true(1)' when the SMF operation mode is
set to independent as this information will inform the
local forwarder of the RSSA implemented in neighboring
forwarders and is used to ensure consistent forwarding across the MANET.
While it is possible that SMF neighbors MAY be configured differently
with respect to the RSSA and still operate cooperatively,
but these cases will vary dependent upon the algorithm types designated
and this situation SHOULD be avoided.'smfCfgNhdpRssaAddrBlockTLVIncluded' - this writable configuration object
indicates whether or not the associated NHDP messages include
the RSSA Address Block TLV.
The smfNhdpRssaAddrBlockTLVIncluded is optional
in all cases as it depends on the existence of
an address block that may not be present.
If this SMF device is configured with NHDP,
then this object should be set to 'true(1)' as
this TLV enables CDS relay algorithm operation
and configuration to be shared among 2-hop
neighborhoods.
Some relay algorithms require 2-hop neighbor
configuration in order to correctly select
relay sets.'smfCfgAddrForwardingTable' - the writable configuration objects
in this table indicate which multicast IP addresses are to be
forwarded by this SMF node. Misconfiguration of rows within
this table can limit the ability of this SMF device to
properly forward multicast data.'smfCfgInterfaceTable' - the writable configuration objects
in this table indicate which SMF node interfaces are
participating in the SMF packet forwarding process.
Misconfiguration of rows within
this table can limit the ability of this SMF device to
properly forward multicast data.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:
'smfNodeRsStatusIncluded' - this readable state object
indicates whether or not this SMF node is part of the CDS.
Being part of the CDS makes this node a distinguished device.
It could be exploited for data ex-filtration, or DoS
attacks.'smfStateNeighborTable' - the readable state objects
in this table indicate current neighbor nodes to
this SMF node. Exposing this information to an attacker
could allow the attacker easier access to the larger
MANET domain.The remainder of the objects in the SMF-MIB module are performance counter objects.
While these give an indication of the activity of the SMF process on this node,
it is not expected that exposing these values poses a security risk
to the MANET network.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.Implementations SHOULD provide the security features described by the
SNMPv3 framework (see ), and implementations claiming compliance
to the SNMPv3 standard MUST include full support for authentication and
privacy via the User-based Security Model (USM) with the AES
cipher algorithm . Implementations MAY also provide support for
the Transport Security Model (TSM) in combination with a secure
transport such as SSH or TLS/DTLS .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.This document describes objects for configuring parameters of the
Simplified Multicast Forwarding
process on a Mobile Ad Hoc Network (MANET) router.
This MIB module, denoted SMF-MIB,
also reports state and performance information and notifications.
This section provides some examples of how this MIB module can be used in
MANET network deployments.
A fuller discussion of MANET network management use cases and
challenges is out of scope for this document.
SMF is designed to allow MANET routers to forward IPv4 and IPv6 packets over
the MANET and cover the MANET nodes through the automatic discovery
of efficient estimates of the Minimum Connected Dominating Set (MCDS)
of nodes within the MANET.
The MCDS is estimated using the Relay Set Selection Algorithms (RSSAs)
discussed within this document.
In the following, three scenarios are listed where this MIB module is useful:
For a Parking Lot Initial Configuration Situation - it is common for
the vehicles comprising the
MANET being forward deployed at a remote location,
e.g., the site of a natural disaster,
to be off-loaded in a parking lot where an initial configuration
of the networking devices is performed.
The configuration is loaded into the
devices from a fixed-location Network Operations Center (NOC)
at the parking lot, and the vehicles are stationary at the parking lot
while the configuration changes are made.
Standards-based methods for configuration management from the co-located NOC
are necessary for this deployment option.
The set of interesting configuration objects for the SMF process are
listed within this MIB module.
For Mobile vehicles with Low Bandwidth Satellite Link to a Fixed NOC - Here
the vehicles carrying the MANET routers carry multiple wireless interfaces,
one of which is a relatively low-bandwidth on-the-move satellite connection
that interconnects a fix NOC to the nodes of the MANET.
Standards-based methods for monitoring and fault management from the fixed NOC
are necessary for this deployment option. For Fixed NOC and Mobile Local Manager in Larger Vehicles - for larger
vehicles, a hierarchical network management arrangement is useful.
Centralized network management is performed from a fixed NOC
while local management is performed locally from within the vehicles.
Standards-based
methods for configuration, monitoring, and fault management
are necessary for this deployment option. Here we provide an example of the simplest of configurations to establish an operational
multicast forwarding capability in a MANET.
This discussion only identifies the configuration necessary through the SMF-MIB
module and assumes that other configuration has occurred.
Assume that the MANET is to support only IPv4 addressing and that the MANET
nodes are to be configured in the context of the Parking Lot Initialization
case above.
Then, the SMF-MIB module defines ten configuration OIDs and two
configuration tables, i.e., the smfCfgAddrForwardingTable and the
smfCfgInterfaceTable.
Of the ten OIDs defined, all but one, i.e., the smfCfgRouterID, have
DEFVAL clauses that allow for a functional configuration of the SMF
process within the MANET.
The smfCfgRouterIDType defaults to 'ipv4' so the smfCfgRouterID can
be set as, e.g., (assuming the use of the Net-SNMP toolkit),:snmpset [options] <smfCfgRouterID_OID>.0 a 192.0.2.100 If the smfCfgAddrForwardingTable is left empty, then the SMF local
forwarder will forward all multicast addresses.
So this table does not require configuration if you want to have the MANET
forward all multicast addresses.All that remains is to configure at least one row in the
smfCfgInterfaceTable.
Assume that the node has a wireless interface with an <ifName>='wlan0'
and an <ifIndex>='1'.
All of the objects in the rows of the smfCfgInterfaceTable
have a DEFVAL clause; hence, only the RowStatus object needs to be set.
So the SMF process will be activated on the 'wlan0' interface by
the following network manager snmpset command:snmpset [options] <smfCfgIfRowStatus>.1 i active(1)At this point, the configured forwarder will begin a Classical Flooding
algorithm to forward all multicast addresses IPv4 packets it receives.To provide a more efficient multicast forwarding within the MANET, the
network manager could walk the smfCapabilitiesTable to identify other
SMF Operational Modes, for example:snmpwalk [options] <smfCapabilitiesTable>SMF-MIB::smfCapabilitiesIndex.1 = INTEGER: 1SMF-MIB::smfCapabilitiesIndex.2 = INTEGER: 2SMF-MIB::smfCapabilitiesOpModeID.1 = INTEGER: cfOnly(1)SMF-MIB::smfCapabilitiesOpModeiD.2 = INTEGER: independent(2)SMF-MIB::smfCapabilitiesRssaID.1 = INTEGER: cF(1)SMF-MIB::smfCapabilitiesRssaID.2 = INTEGER: eCDS(3)In this example, the forwarding device also supports the Essential
Connected Dominating Set (eCDS) RSSA with the forwarder in
the 'independent(2)' operational mode. If the network manager were to
then issue an snmpset, for example:snmpset [options] <smfCfgOperationalMode>.0 i 2then the local forwarder would switch its forwarding behavior from
Classical Flooding to the more efficient eCDS flooding.This document defines two MIB modules:SMF-MIB is defined in and is an experimental MIB module.IANA-SMF-MIB is defined in and is an IANA MIB
module that IANA maintains.Thus, IANA has completed three actions:IANA has allocated an OBJECT IDENTIFIER value and
recorded it in the SMI Numbers registry in the subregistry called
"SMI Experimental Codes" under the experimental branch
(1.3.6.1.3).IANA has allocated an OBJECT IDENTIFIER value and
recorded it in the SMI Numbers registry in the subregistry called
"SMI Network Management MGMT Codes Internet-standard MIB" under
the mib-2 branch (1.3.6.1.2.1).IANA maintains a MIB module called ianaSmfMIB
and has populated it with the initial MIB module defined in
of this document by creating a new entry in the registry "IANA
Maintained MIBs" called "IANA-SMF-MIB".User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)This document describes the User-based Security Model (USM) for Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a Management Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model. This document obsoletes RFC 2574. [STANDARDS-TRACK]The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security ModelThis document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [STANDARDS-TRACK]Transport Security Model for the Simple Network Management Protocol (SNMP)This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP).</t><t> This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. [STANDARDS-TRACK]Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol.</t><t> This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. [STANDARDS-TRACK]Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of an SNMP Transport Subsystem to make this protection possible in an interoperable way.</t><t> This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.</t><t> This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]The Interfaces Group MIBThis memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the 'interfaces' group. [STANDARDS-TRACK]Introduction and Applicability Statements for Internet-Standard Management FrameworkThe purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2). The architecture is designed to be modular to allow the evolution of the Framework over time. The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570. This memo provides information for the Internet community.An Architecture for Describing Simple Network Management Protocol (SNMP) Management FrameworksThis document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571. [STANDARDS-TRACK]Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)This document defines managed objects which describe the behavior of a Simple Network Management Protocol (SNMP) entity. This document obsoletes RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). [STANDARDS-TRACK]Textual Conventions for Internet Network AddressesThis MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
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.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
Structure of Management Information Version 2 (SMIv2)Cisco Systems, Inc.170 West Tasman DriveSan JoseCA95134-1706US+1 408 526 5260kzm@cisco.comSNMPinfo3763 Benton StreetSanta ClaraCA95051US+1 408 221 8702dperkins@snmpinfo.comTU BraunschweigBueltenweg 74/7538106 BraunschweigDE+49 531 3913283schoenw@ibr.cs.tu-bs.deTextual Conventions for SMIv2Cisco Systems, Inc.170 West Tasman DriveSan JoseCA95134-1706US+1 408 526 5260kzm@cisco.comSNMPinfo3763 Benton StreetSanta ClaraCA95051US+1 408 221 8702dperkins@snmpinfo.comTU BraunschweigBueltenweg 74/7538106 BraunschweigDE+49 531 3913283schoenw@ibr.cs.tu-bs.deConformance Statements for SMIv2Cisco Systems, Inc.170 West Tasman DriveSan JoseCA95134-1706US+1 408 526 5260kzm@cisco.comSNMPinfo3763 Benton StreetSanta ClaraCA95051US+1 408 221 8702dperkins@snmpinfo.comTU BraunschweigBueltenweg 74/75Braunschweig38106DE+49 531 3913283schoenw@ibr.cs.tu-bs.deOptimized Link State Routing Protocol (OLSR)This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs). MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context.IESG Procedures for Handling of Independent and IRTF Stream SubmissionsThis document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams.</t><t> This document updates procedures described in RFC 2026 and RFC 3710. This memo documents an Internet Best Current Practice.Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) FloodingThis document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. This memo defines an Experimental Protocol for the Internet community.Simplified Multicast ForwardingThis document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use. It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade-off. It defines techniques for multicast duplicate packet detection (DPD), to be applied in the forwarding process, for both IPv4 and IPv6 protocol use. This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to Classic Flooding. Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols or interaction with other multicast protocols, as well as multiple deployment approaches are also described. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices. Basic issues relating to the operation of multicast MANET border routers are discussed, but ongoing work remains in this area and is beyond the scope of this document. This document defines an Experimental Protocol for the Internet community.The Optimized Link State Routing Protocol Version 2This specification describes version 2 of the Optimized Link State Routing Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs).Management Information Base for the Internet Protocol (IP)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 managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465, and 2466. [STANDARDS-TRACK]IP Multicast MIBThis 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 used for managing multicast function, independent of the specific multicast protocol(s) in use. This document obsoletes RFC 2932. [STANDARDS-TRACK]The authors would like to acknowledge the valuable comments from Sean Harnedy
in the early phases of the development of this MIB module.
The authors would like to thank Adrian Farrel, Dan Romascanu, Juergen
Shoenwaelder, Stephen Hanna, and Brian Haberman for their careful
review of this document and their insightful comments. We also
wish to thank the entire MANET WG for many reviews of this document.
Further, the authors would like to thank James Nguyen for his careful review
and comments on this MIB module and his work on the definitions of
the follow-on MIB modules to configure specific RSSAs
related to SMF. Further, the authors would like to acknowledge the
work of James Nguyen, Brian Little, Ryan Morgan, and Justin Dean on
their software development of the SMF-MIB.This MIB document uses the template authored by D. Harrington that
is based on contributions from the MIB Doctors, especially Juergen
Schoenwaelder, Dave Perkins, C.M. Heard, and Randy Presuhn.