draft-ietf-manet-smf-mib-09.txt   draft-ietf-manet-smf-mib-10.txt 
Internet Engineering Task Force R. Cole Internet Engineering Task Force R. Cole
Internet-Draft US Army CERDEC Internet-Draft US Army CERDEC
Intended status: Experimental J. Macker Intended status: Experimental J. Macker
Expires: July 24, 2014 B. Adamson Expires: September 9, 2014 B. Adamson
Naval Research Laboratory Naval Research Laboratory
January 20, 2014 March 8, 2014
Definition of Managed Objects for the Manet Simplified Multicast Definition of Managed Objects for the Manet Simplified Multicast
Framework Relay Set Process Framework Relay Set Process
draft-ietf-manet-smf-mib-09 draft-ietf-manet-smf-mib-10
Abstract Abstract
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community. for use with network management protocols in the Internet community.
In particular, it describes objects for configuring aspects of the In particular, it describes objects for configuring aspects of the
Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc
Networks (MANETs). The SMF-MIB module also reports state Networks (MANETs). The SMF-MIB module also reports state
information, performance information, and notifications. In addition information, performance information, and notifications. In addition
to configuration, the additional state and performance information is to configuration, the additional state and performance information is
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 24, 2014. This Internet-Draft will expire on September 9, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
5.2. The Capabilities Group . . . . . . . . . . . . . . . . . . 6 5.2. The Capabilities Group . . . . . . . . . . . . . . . . . . 6
5.3. The Configuration Group . . . . . . . . . . . . . . . . . 7 5.3. The Configuration Group . . . . . . . . . . . . . . . . . 7
5.4. The State Group . . . . . . . . . . . . . . . . . . . . . 7 5.4. The State Group . . . . . . . . . . . . . . . . . . . . . 7
5.5. The Performance Group . . . . . . . . . . . . . . . . . . 7 5.5. The Performance Group . . . . . . . . . . . . . . . . . . 7
5.6. The Notifications Group . . . . . . . . . . . . . . . . . 8 5.6. The Notifications Group . . . . . . . . . . . . . . . . . 8
5.7. Tables and Indexing . . . . . . . . . . . . . . . . . . . 8 5.7. Tables and Indexing . . . . . . . . . . . . . . . . . . . 8
6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 9 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 9
6.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . . . 9 6.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . . . 9
6.2. MIB modules required for IMPORTS . . . . . . . . . . . . . 9 6.2. MIB modules required for IMPORTS . . . . . . . . . . . . . 9
6.3. Relationship to the Future RSSA-MIB Moduless . . . . . . . 10 6.3. Relationship to the Future RSSA-MIB Moduless . . . . . . . 10
7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. SMF-MIB Definitions . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 50 8. IANAsmfOpModeID-MIB Definitions . . . . . . . . . . . . . . . 50
9. Applicability Statement . . . . . . . . . . . . . . . . . . . 54 9. IANAsmfRssaID-MIB Definitions . . . . . . . . . . . . . . . . 52
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 10. Security Considerations . . . . . . . . . . . . . . . . . . . 55
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 56 11. Applicability Statement . . . . . . . . . . . . . . . . . . . 58
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 61
13.1. Normative References . . . . . . . . . . . . . . . . . . . 56 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61
13.2. Informative References . . . . . . . . . . . . . . . . . . 57 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Appendix A. Appendix A: . . . . . . . . . . . . . . . . . . . . . 58 15.1. Normative References . . . . . . . . . . . . . . . . . . . 61
Appendix B. Appendix B: . . . . . . . . . . . . . . . . . . . . . 60 15.2. Informative References . . . . . . . . . . . . . . . . . . 62
Appendix C. . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . 63
1. Introduction 1. Introduction
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community. for use with network management protocols in the Internet community.
In particular, it describes objects for configuring aspects of a In particular, it describes objects for configuring aspects of a
process implementing Simplified Multicast Forwarding (SMF) [RFC6621] process implementing Simplified Multicast Forwarding (SMF) [RFC6621]
for Mobile Ad-Hoc Networks (MANETs). SMF provides multicast for Mobile Ad-Hoc Networks (MANETs). SMF provides multicast
Duplicate Packet Detection (DPD) and supports algorithms for Duplicate Packet Detection (DPD) and supports algorithms for
constructing an estimate of a MANET Minimum Connected Dominating Set constructing an estimate of a MANET Minimum Connected Dominating Set
skipping to change at page 7, line 35 skipping to change at page 7, line 35
o Duplicate Packet detection for IPv6 - Identification-based or o Duplicate Packet detection for IPv6 - Identification-based or
Hash-based DPD. Hash-based DPD.
o SMF Type Message TLV - if NHDP mode is selected, then the SMF Type o SMF Type Message TLV - if NHDP mode is selected, then the SMF Type
Message TLV MAY be included in the NHDP exchanges. Message TLV MAY be included in the NHDP exchanges.
o SMF Address Block TLV - if NHDP mode is selected, then the SMF o SMF Address Block TLV - if NHDP mode is selected, then the SMF
Address Block TLV SHOULD be included in the NHDP exchanges. Address Block TLV SHOULD be included in the NHDP exchanges.
o SMF Address Forwarding Table - a table identifying configured
multicast addresses to be forwarded by the SMF process.
5.4. The State Group 5.4. The State Group
The State sub-tree reports current state information, e.g., The State sub-tree reports current state information, e.g.,
o Node RSSA State - identifies whether the node is currently in or o Node RSSA State - identifies whether the node is currently in or
out of the Relay Set. out of the Relay Set.
o Neighbors Table - a table containing current one-hop neighbors and o Neighbors Table - a table containing current one-hop neighbors and
their operational RSSA. their operational RSSA.
skipping to change at page 8, line 44 skipping to change at page 8, line 44
router, and router, and
o configuration and operation of various RSSA algorithms for packet o configuration and operation of various RSSA algorithms for packet
forwarding. forwarding.
The SMF-MIB module's tables are indexed via the following constructs: The SMF-MIB module's tables are indexed via the following constructs:
o smfCapabilitiesIndex - the index identifying the combination of o smfCapabilitiesIndex - the index identifying the combination of
SMF mode and SMF RSSA available on this device. SMF mode and SMF RSSA available on this device.
o smfCfgAddrForwardingAddrType, smfCfgAddrForwardingAddress and o smfCfgAddrForwardingIndex - the index to configured multicast
smfCfgAddrForwardingAddrPreficLength - indexes to configured addresses lists which are forwarded by the SMF process.
multicast addresses which are forwarded by the SMF process.
o smfCfgIfIndex - the IfIndex of the interface on the local router o smfCfgIfIndex - the IfIndex of the interface on the local router
on which SMF is configured. on which SMF is configured.
o smfStateNeighborIpAddrType, smfStateNeighborIpAddr, and o smfStateNeighborIpAddrType, smfStateNeighborIpAddr, and
smfStateNeighborPrefixLen - the interface index set of specific smfStateNeighborPrefixLen - the interface index set of specific
one-hop neighbor nodes to this local router. one-hop neighbor nodes to this local router.
These tables and their associated indexing are: These tables and their associated indexing are:
o smfCapabilitiesTable - identifies the resident set of (SMF o smfCapabilitiesTable - identifies the resident set of (SMF
Operational Modes, SMF RSSA algorithms) available on this router. Operational Modes, SMF RSSA algorithms) available on this router.
This table has 'INDEX { smfCapabilitiesIndex }. This table has 'INDEX { smfCapabilitiesIndex }.
o smfCfgAddrForwardingTable - contains information on multicast o smfCfgAddrForwardingTable - contains information on multicast
addresses which are to be forwarded by the SMF process on this addresses which are to be forwarded by the SMF process on this
device. This table has 'INDEX { smfCfgAddrForwardingAddrType, device. This table has 'INDEX { smfCfgAddrForwardingIndex }'.
smfCfgAddrForwardingAddress, smfCfgAddrForwardingAddrPrefixLength
}'.
o smfCfgInterfaceTable - describes the SMF interfaces on this device o smfCfgInterfaceTable - describes the SMF interfaces on this device
that are participating in the SMF packet forwarding process. This that are participating in the SMF packet forwarding process. This
table has 'INDEX { smfCfgIfIndex }'. table has 'INDEX { smfCfgIfIndex }'.
o smfStateNeighborTable - describes the current neighbor nodes, o smfStateNeighborTable - describes the current neighbor nodes,
their addresses and the SMF RSSA and the interface on which they their addresses and the SMF RSSA and the interface on which they
can be reached. This table has 'INDEX { can be reached. This table has 'INDEX {
smfStateNeighborIpAddrType, smfStateNeighborIpAddr, smfStateNeighborIpAddrType, smfStateNeighborIpAddr,
smfStateNeighborPrefixLen }'. smfStateNeighborPrefixLen }'.
skipping to change at page 10, line 23 skipping to change at page 10, line 20
6.3. Relationship to the Future RSSA-MIB Moduless 6.3. Relationship to the Future RSSA-MIB Moduless
In a sense, the SMF-MIB module is a general front-end to a set of, 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 yet to be developed, RSSA-specific MIB modules. These RSSA-specific
MIB modules will define the objects for the configuration, state, MIB modules will define the objects for the configuration, state,
performance and notification required for the operation of these performance and notification required for the operation of these
specific RSSAs. The SMF-MIB module Capabilities Group allows the specific RSSAs. The SMF-MIB module Capabilities Group allows the
remote management station the ability to query the router to discover remote management station the ability to query the router to discover
the set of supported RSSAs. the set of supported RSSAs.
7. Definitions 7. SMF-MIB Definitions
SMF-MIB DEFINITIONS ::= BEGIN SMF-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Counter32, Integer32, TimeTicks, experimental Counter32, Integer32, TimeTicks, experimental
FROM SNMPv2-SMI -- [RFC2578] FROM SNMPv2-SMI -- [RFC2578]
TEXTUAL-CONVENTION, RowStatus, TruthValue TEXTUAL-CONVENTION, RowStatus, TruthValue
skipping to change at page 11, line 13 skipping to change at page 11, line 8
FROM INET-ADDRESS-MIB -- [RFC4001] FROM INET-ADDRESS-MIB -- [RFC4001]
IANAsmfOpModeIdTC IANAsmfOpModeIdTC
FROM IANAsmfOpModeID-MIB FROM IANAsmfOpModeID-MIB
IANAsmfRssaIdTC IANAsmfRssaIdTC
FROM IANAsmfRssaID-MIB FROM IANAsmfRssaID-MIB
; ;
smfMIB MODULE-IDENTITY smfMIB MODULE-IDENTITY
LAST-UPDATED "201309011300Z" -- September 01, 2013 LAST-UPDATED "201403081300Z" -- March 8, 2014
ORGANIZATION "IETF MANET Working Group" ORGANIZATION "IETF MANET Working Group"
CONTACT-INFO CONTACT-INFO
"WG E-Mail: manet@ietf.org "WG E-Mail: manet@ietf.org
WG Chairs: sratliff@cisco.com WG Chairs: sratliff@cisco.com
jmacker@nrl.navy.mil jmacker@nrl.navy.mil
Editors: Robert G. Cole Editors: Robert G. Cole
US Army CERDEC US Army CERDEC
Space and Terrestrial Communications Space and Terrestrial Communications
skipping to change at page 12, line 7 skipping to change at page 11, line 50
[SMF] Macker, J.(ed.), [SMF] Macker, J.(ed.),
Simplified Multicast Forwarding, RFC 6621, Simplified Multicast Forwarding, RFC 6621,
May 2012. May 2012.
Copyright (C) The IETF Trust (2012). This version Copyright (C) The IETF Trust (2012). This version
of this MIB module is part of RFC xxxx; see the RFC of this MIB module is part of RFC xxxx; see the RFC
itself for full legal notices." itself for full legal notices."
-- Revision History -- Revision History
REVISION "201309011300Z" -- September 01, 2013 REVISION "201403081300Z" -- March 8, 2014
DESCRIPTION DESCRIPTION
"The first version of this MIB module, "The first version of this MIB module,
published as RFC xxxx. published as RFC xxxx.
" "
-- RFC-Editor assigns xxxx -- RFC-Editor assigns xxxx
::= { experimental xxxx } -- to be assigned by IANA ::= { experimental xxxx } -- to be assigned by IANA
-- --
-- TEXTUAL CONVENTIONs -- TEXTUAL CONVENTIONs
-- --
skipping to change at page 20, line 51 skipping to change at page 20, line 46
smfCfgDpdEntryMaxLifetime OBJECT-TYPE smfCfgDpdEntryMaxLifetime OBJECT-TYPE
SYNTAX Integer32 (0..65525) SYNTAX Integer32 (0..65525)
UNITS "Seconds" UNITS "Seconds"
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The maximum lifetime of a cached DPD "The maximum lifetime of a cached DPD
record in the local device storage. record in the local device storage.
If the memory is running low prior to the If the memory is running low prior to the
MaxLifetimes being exceeded, the local SMF MaxLifetime being exceeded, the local SMF
devices should purge the oldest records first. devices should purge the oldest records first.
This object is persistent and when written This object is persistent and when written
the entity SHOULD save the change to the entity SHOULD save the change to
non-volatile storage." non-volatile storage."
REFERENCE REFERENCE
"See Section 6. 'SMF Duplicate Packet "See Section 6. 'SMF Duplicate Packet
Detection' in RFC 6621 - Simplified Detection' in RFC 6621 - Simplified
Multicast Forwarding (SMF), Macker, J., Multicast Forwarding (SMF), Macker, J.,
May 2012." May 2012."
skipping to change at page 50, line 18 skipping to change at page 50, line 18
smfNotifDpdMemoryOverflowEvent smfNotifDpdMemoryOverflowEvent
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Set of SMF notifications implemented "Set of SMF notifications implemented
in this module." in this module."
::= { smfMIBGroups 6 } ::= { smfMIBGroups 6 }
END END
8. Security Considerations 8. IANAsmfOpModeID-MIB Definitions
This section contains the IANAsmfOpModeID-MIB module. This MIB
module defines the single textual convention for which IANA SHOULD
maintain and keep synchronized with the registry identified below
within the IANAsmfOpModeIdTC TEXTUAL-CONVENTION.
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.
IANAsmfOpModeID-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
ianasmfOpModeID MODULE-IDENTITY
LAST-UPDATED "201403081300Z" -- March 8, 2014
ORGANIZATION "IANA"
CONTACT-INFO "Internet Assigned Numbers Authority
Postal: ICANN
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
Tel: +1 310 823 9358
E-Mail: iana@iana.org"
DESCRIPTION "This MIB module defines the
IANAsmfOpModeIdTC Textual
Convention, and thus the enumerated values of
the smfCapabilitiesOpModeID object defined in
the SMF-MIB."
REVISION "201403081300Z" -- March 8, 2014
DESCRIPTION "Initial version of this MIB as published in
RFC KKKK."
::= { mib-2 kkkk }
IANAsmfOpModeIdTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An index that identifies through reference to a specific
SMF operations mode. There are basically three styles
of SMF operation with reduced relay sets currently
identified:
Independent operation 'independent(1)' -
SMF performs its own relay
set selection using information from an associated
MANET NHDP process.
CDS-aware unicast routing operation 'routing(2)'-
a coexistent unicast routing
protocol provides dynamic relay
set state based upon its own control plane
CDS or neighborhood discovery information.
Cross-layer operation 'crossLayer(3)' -
SMF operates using neighborhood
status and triggers from a
cross-layer information base for dynamic relay
set selection and maintenance.
IANA MUST update this textual convention accordingly.
The definition of this textual convention with the
addition of newly assigned values is published
periodically by the IANA, in either the Assigned
Numbers RFC, or some derivative of it specific to
Internet Network Management number assignments. (The
latest arrangements can be obtained by contacting the
IANA.)
Requests for new values SHOULD be made to IANA via
email (iana@iana.org)."
REFERENCE
"See Section 7.2. 'Reduced Relay Set Forwarding',
and the Appendices A, B and C in
RFC 6621 - Simplified Multicast Forwarding
(SMF), Macker, J., May 2012."
SYNTAX INTEGER {
independent (1),
routing (2),
crossLayer (3)
-- future (4-255)
}
END
9. IANAsmfRssaID-MIB Definitions
This section contains the IANAsmfRssaID-MIB module. This MIB module
defines the single textual convention for which IANA SHOULD maintain
and keep synchronized with the registry identified below within the
IANAsmfRssadTC TEXTUAL-CONVENTION.
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 for the index range 5-127 require an RFC
publication (either as an IETF submission or as an RFC Editor
Independent submission [RFC3932]). The type of RFC MUST be Standards
Track. The specific RSSA algorithms MUST be documented in sufficient
detail so that interoperability between independent implementations
is possible.
Future assignments 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 for the index range 240-255 are to facilitate
experimentation. These require an RFC publication (either as an IETF
submission or as an RFC Editor Independent submission [RFC3932]).
The type of RFC MUST be Experimental. The RSSA algorithms MUST be
documented in sufficient detail so that interoperability between
independent implementations is possible.
IANAsmfRssaID-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
ianasmfRssaID MODULE-IDENTITY
LAST-UPDATED "201403081300Z" -- March 8, 2014
ORGANIZATION "IANA"
CONTACT-INFO "Internet Assigned Numbers Authority
Postal: ICANN
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
Tel: +1 310 823 9358
E-Mail: iana@iana.org"
DESCRIPTION "This MIB module defines the
IANAsmfRssaIdTC Textual
Convention, and thus the enumerated values of
the smfCapabilitiesRssaID object defined in
the SMF-MIB."
REVISION "201403081300Z" -- March 8, 2014
DESCRIPTION "Initial version of this MIB as published in
RFC LLLL."
::= { mib-2 llll }
IANAsmfRssaIdTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An index that identifies through reference to a specific
RSSA algorithms. Several are currently defined
in the Appendix A, B and C of RFC 6621.
Examples of RSSA algorithms already identified within
this TC are:
Classical Flooding (cF(1)) - is the standard
flooding algorithm where each node in the next
retransmits the information on each of its interfaces.
Source-Based Multipint Relay (sMPR(2)) -
this algorithm is used by Optimized Link State Routing
(OLSR) and OLSR version 2 (OLSRv2) protocols for the
relay of link state updates and other control
information [RFC3626]. Since each router picks
its neighboring relays independently, sMPR
forwarders depend upon previous hop information
(e.g., source MAC address) to operate correctly.
Extended Connected Dominating Set (eCDS(3)) -
defined in [RFC5614] this algorithm forms a single
CDS mesh for the SMF operating region. Its
packet-forwarding rules are not dependent upon
previous hop knowledge in contrast to sMPR.
Multipoint Relay Connected Dominating Set (mprCDS(4)) -
This algorithm is an extension to the basic sMPR
election algorithm that results in a shared
(non-source-specific) SMF CDS. Thus, its forwarding
rules are not dependent upon previous hop information,
similar to eCDS.
IANA MUST update this textual convention accordingly.
The definition of this textual convention with the
addition of newly assigned values is published
periodically by the IANA, in either the Assigned
Numbers RFC, or some derivative of it specific to
Internet Network Management number assignments. (The
latest arrangements can be obtained by contacting the
IANA.)
Requests for new values SHOULD be made to IANA via
email (iana@iana.org)."
REFERENCE
"See, e.g.,
Section 8.1.1. 'SMF Message TLV Type',
Appendix A. 'Essential Connecting Dominating Set (E-CDS)
Algorithm',
Appendix B. 'Source-Based Multipoint Relay (S-MPR)
Algorithm', and
Appendix C. 'Multipoint Relay Connected Dominating Set
(MPR-CDS) Algorithm'
in RFC 6621 - Simplified Multicast Forwarding
(SMF), Macker, J., May 2012."
SYNTAX INTEGER {
cF(1),
sMPR(2),
eCDS(3),
mprCDS(4)
-- future(5-127)
-- noStdAction(128-239)
-- experimental(240-255)
}
END
10. Security Considerations
This section discusses security implications of the choices made in This section discusses security implications of the choices made in
this SMF-MIB module. this SMF-MIB module.
There are a number of management objects defined in this MIB module There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on environment without proper protection can have a negative effect on
network operations. These are the tables and objects and their network operations. These are the tables and objects and their
skipping to change at page 52, line 14 skipping to change at page 57, line 10
o 'smfCfgMaxPktLifetime' - this writable configuration object sets o 'smfCfgMaxPktLifetime' - this writable configuration object sets
the estimate of the network packet traversal time. If set too the estimate of the network packet traversal time. If set too
small, this could lead to poor multicast data delivery ratios small, this could lead to poor multicast data delivery ratios
throughout the MANET domain. This could serve as a form of DOS throughout the MANET domain. This could serve as a form of DOS
attack if this object value is set too small. attack if this object value is set too small.
o 'smfCfgDpdEntryMaxLifetime' - this writable configuration object o 'smfCfgDpdEntryMaxLifetime' - this writable configuration object
sets the maximum lifetime (in seconds) for the cached DPD records sets the maximum lifetime (in seconds) for the cached DPD records
for the combined IPv4 and IPv6 methods. If the memory is running for the combined IPv4 and IPv6 methods. If the memory is running
low prior to the MaxLifetimes being exceeded, the local SMF low prior to the MaxLifetime being exceeded, the local SMF devices
devices should purge the oldest records first. If this object should purge the oldest records first. If this object value is
value is set too small, then the effectiveness of the SMF DPD set too small, then the effectiveness of the SMF DPD algorithms
algorithms may become greatly diminished causing a higher than may become greatly diminished causing a higher than necessary
necessary packet load on the MANET. packet load on the MANET.
o 'smfCfgNhdpRssaMesgTLVIncluded' - this writable configuration o 'smfCfgNhdpRssaMesgTLVIncluded' - this writable configuration
object indicates whether the associated NHDP messages include the object indicates whether the associated NHDP messages include the
the RSSA Message TLV, or not. It is highly RECOMMENDED that this the RSSA Message TLV, or not. It is highly RECOMMENDED that this
object be set to 'true(1)' when the SMF operation mode is set to object be set to 'true(1)' when the SMF operation mode is set to
independent as this information will inform the local forwarder of independent as this information will inform the local forwarder of
the RSSA algorithm implemented in neighboring forwarders and is the RSSA algorithm implemented in neighboring forwarders and is
used to ensure consistent forwarding across the MANET. While it used to ensure consistent forwarding across the MANET. While it
is possible that SMF neighbors MAY be configured differently with is possible that SMF neighbors MAY be configured differently with
respect to the RSSA algorithm and still operate cooperatively, but respect to the RSSA algorithm and still operate cooperatively, but
skipping to change at page 54, line 5 skipping to change at page 58, line 48
[RFC5592] or TLS/DTLS [RFC6353]. [RFC5592] or TLS/DTLS [RFC6353].
Further, deployment of SNMP versions prior to SNMPv3 is NOT Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them. rights to indeed GET or SET (change/create/delete) them.
9. Applicability Statement 11. Applicability Statement
This document describes objects for configuring parameters of the This document describes objects for configuring parameters of the
Simplified Multicast Forwarding [RFC6621] process on a Mobile Ad-Hoc Simplified Multicast Forwarding [RFC6621] process on a Mobile Ad-Hoc
Network (MANET) router. This MIB module, denoted SMF-MIB, also Network (MANET) router. This MIB module, denoted SMF-MIB, also
reports state and performance information and notifications. This reports state and performance information and notifications. This
section provides some examples of how this MIB module can be used in section provides some examples of how this MIB module can be used in
MANET network deployments. A fuller discussion of MANET network MANET network deployments. A fuller discussion of MANET network
management use cases and challenges will be provided elsewhere. management use cases and challenges will be provided elsewhere.
SMF is designed to allow MANET routers to forward IPv4 and IPv6 SMF is designed to allow MANET routers to forward IPv4 and IPv6
skipping to change at page 56, line 16 skipping to change at page 61, line 13
In this example, the forwarding device also supports the Extended In this example, the forwarding device also supports the Extended
Connected Dominating Set (eCDS) RSSA with the forwarder in the Connected Dominating Set (eCDS) RSSA with the forwarder in the
'independent(2)' operational mode. If the network manager were to 'independent(2)' operational mode. If the network manager were to
then issue an snmpset, e.g.,: then issue an snmpset, e.g.,:
snmpset [options] <smfCfgOperationalMode>.0 i 2 snmpset [options] <smfCfgOperationalMode>.0 i 2
then the local forwarder would switch if forwarding behavior from then the local forwarder would switch if forwarding behavior from
Classical Flooding to the more efficient eCDS flooding. Classical Flooding to the more efficient eCDS flooding.
10. IANA Considerations 12. IANA Considerations
The MIB module in this document uses the following IANA-assigned The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER value recorded in the SMI Numbers registry: OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value Descriptor OBJECT IDENTIFIER value
---------- ----------------------- ---------- -----------------------
SMF-MIB { experimental XXXX } SMF-MIB { experimental XXXX }
IANA EDITOR NOTE: please assign XXXX, and remove this note. IANAsmfOpModeID-MIB { experimental KKKK }
IANAsmfRssaID-MIB { experimental LLLL }
11. Contributors IANA EDITOR NOTE: please assign XXXX, KKKK and LLLL and
remove this note.
13. Contributors
This MIB document uses the template authored by D. Harrington which This MIB document uses the template authored by D. Harrington which
is based on contributions from the MIB Doctors, especially Juergen is based on contributions from the MIB Doctors, especially Juergen
Schoenwaelder, Dave Perkins, C.M.Heard and Randy Presuhn. Schoenwaelder, Dave Perkins, C.M.Heard and Randy Presuhn.
12. Acknowledgements 14. Acknowledgements
The authors would like to acknowledge the valuable comments from Sean The authors would like to acknowledge the valuable comments from Sean
Harnedy in the early phases of the development of this MIB module. Harnedy in the early phases of the development of this MIB module and
The authors would like to thank James Nguyen for his careful review from Dan Romascanu in the final reviews of this MIB module. The
and comments on this MIB module and his work on the definitions of authors would like to thank James Nguyen for his careful review and
the follow on MIB modules to configure specific RSSA algorithms comments on this MIB module and his work on the definitions of the
related to SMF. Further, the authors would like to acknowledge to follow-on MIB modules to configure specific RSSA algorithms related
work of James Nguyen, Brian Little, Ryan Morgan and Justin Dean on to SMF. Further, the authors would like to acknowledge to work of
their software development of the SMF-MIB. James Nguyen, Brian Little, Ryan Morgan and Justin Dean on their
software development of the SMF-MIB.
13. References 15. References
13.1. Normative References 15.1. Normative References
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000. MIB", RFC 2863, June 2000.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002. December 2002.
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the [RFC3418] Presuhn, R., "Management Information Base (MIB) for the
skipping to change at page 57, line 33 skipping to change at page 62, line 36
Schoenwaelder, Ed., "Textual Conventions for SMIv2", Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999. STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580, "Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999. April 1999.
[RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621,
May 2012. May 2012.
13.2. Informative References 15.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet- "Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002. Standard Management Framework", RFC 3410, December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management (USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
skipping to change at page 58, line 11 skipping to change at page 63, line 13
RFC 5591, June 2009. RFC 5591, June 2009.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for the Simple Network Management Shell Transport Model for the Simple Network Management
Protocol (SNMP)", RFC 5592, June 2009. Protocol (SNMP)", RFC 5592, June 2009.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)", Model for the Simple Network Management Protocol (SNMP)",
RFC 6353, July 2011. RFC 6353, July 2011.
Appendix A. Appendix A: Appendix A.
This appendix contains the IANAsmfOpModeID-MIB module defined by this
specification below. The RFC editor should remove this specification
of the IANAsmfOpModeID-MIB upon publication of the SMF-MIB. Further,
IANA should take over the IANAsmfOpModeID-MIB and to keep it
synchronized with the registry identified below within the
IANAsmfOpModeIdTC TEXTUAL-CONVENTION.
IANAsmfOpModeID-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
ianasmfOpModeID MODULE-IDENTITY
LAST-UPDATED "201401190000Z" -- January 19, 2014
ORGANIZATION "IANA"
CONTACT-INFO "Internet Assigned Numbers Authority
Postal: ICANN
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
Tel: +1 310 823 9358
E-Mail: iana@iana.org"
DESCRIPTION "This MIB module defines the
IANAsmfOpModeIdTC Textual
Convention, and thus the enumerated values of
the smfCapabilitiesOpModeID object defined in
the SMF-MIB."
REVISION "201401190000Z" -- January 19, 2014
DESCRIPTION "Initial version of this MIB as published in
RFC KKKK."
::= { mib-2 kkkk }
IANAsmfOpModeIdTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An index that identifies through reference to a specific
SMF operations mode. There are basically three styles
of SMF operation with reduced relay sets:
Independent operation 'independent(1)' -
SMF performs its own relay
set selection using information from an associated
MANET NHDP process.
CDS-aware unicast routing operation 'routing(2)'-
a coexistent unicast routing
protocol provides dynamic relay
set state based upon its own control plane
CDS or neighborhood discovery information.
Cross-layer operation 'crossLayer(3)' -
SMF operates using neighborhood
status and triggers from a
cross-layer information base for dynamic relay
set selection and maintenance.
IANA MUST update this textual convention accordingly.
The definition of this textual convention with the
addition of newly assigned values is published
periodically by the IANA, in either the Assigned
Numbers RFC, or some derivative of it specific to
Internet Network Management number assignments. (The
latest arrangements can be obtained by contacting the
IANA.)
Requests for new values should be made to IANA via
email (iana@iana.org)."
REFERENCE
"See Section 7.2. 'Reduced Relay Set Forwarding',
and the Appendices A, B and C in
RFC 6621 - Simplified Multicast Forwarding
(SMF), Macker, J., May 2012."
SYNTAX INTEGER {
independent (1),
routing (2),
crossLayer (3)
-- future (4-255)
}
END
Appendix B. Appendix B:
This appendix contains the IANAsmfRssaID-MIB module defined by this
specification below. The RFC editor should remove this specification
of the IANAsmfRssaID-MIB upon publication of the SMF-MIB. Further,
IANA should take over the IANAsmfRssaID-MIB and to keep it
synchronized with the registry identified below within the
IANAsmfRssaIdTC TEXTUAL-CONVENTION.
IANAsmfRssaID-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
ianasmfRssaID MODULE-IDENTITY
LAST-UPDATED "201401190000Z" -- January 19, 2014
ORGANIZATION "IANA"
CONTACT-INFO "Internet Assigned Numbers Authority
Postal: ICANN
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
Tel: +1 310 823 9358
E-Mail: iana@iana.org"
DESCRIPTION "This MIB module defines the
IANAsmfRssaIdTC Textual
Convention, and thus the enumerated values of
the smfCapabilitiesRssaID object defined in
the SMF-MIB."
REVISION "201401190000Z" -- January 19, 2014
DESCRIPTION "Initial version of this MIB as published in
RFC LLLL."
::= { mib-2 llll }
IANAsmfRssaIdTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An index that identifies through reference to a specific
RSSA algorithms. Several are currently defined
in the Appendix A, B and C of RFC 6621.
Examples of RSSA algorithms already identified within
this TC are:
Classical Flooding (cF(1)) - is the standard
flooding algorithm where each node in the next
retransmits the information on each of its interfaces.
Source-Based Multipint Relay (sMPR(2)) -
this algorithm is used by Optimized Link State Routing
(OLSR) and OLSR version 2 (OLSRv2) protocols for the
relay of link state updates and other control
information [RFC3626]. Since each router picks
its neighboring relays independently, sMPR
forwarders depend upon previous hop information
(e.g., source MAC address) to operate correctly.
Extended Connected Dominating Set (eCDS(3)) -
defined in [RFC5614] this algorithm forms a single
CDS mesh for the SMF operating region. Its
packet-forwarding rules are not dependent upon
previous hop knowledge in contrast to sMPR.
Multipoint Relay Connected Dominating Set (mprCDS(4)) -
This algorithm is an extension to the basic sMPR
election algorithm that results in a shared
(non-source-specific) SMF CDS. Thus, its forwarding
rules are not dependent upon previous hop information,
similar to eCDS.
IANA MUST update this textual convention accordingly.
The definition of this textual convention with the
addition of newly assigned values is published
periodically by the IANA, in either the Assigned
Numbers RFC, or some derivative of it specific to
Internet Network Management number assignments. (The
latest arrangements can be obtained by contacting the
IANA.)
Requests for new values should be made to IANA via
email (iana@iana.org)."
REFERENCE
"See, e.g.,
Section 8.1.1. 'SMF Message TLV Type',
Appendix A. 'Essential Connecting Dominating Set (E-CDS)
Algorithm',
Appendix B. 'Source-Based Multipoint Relay (S-MPR)
Algorithm', and
Appendix C. 'Multipoint Relay Connected Dominating Set
(MPR-CDS) Algorithm'
in RFC 6621 - Simplified Multicast Forwarding
(SMF), Macker, J., May 2012."
SYNTAX INTEGER {
cF(1),
sMPR(2),
eCDS(3),
mprCDS(4)
-- future(5-127)
-- noStdAction(128-239)
-- experimental(240-255)
}
END
Appendix C.
*************************************************************** ***************************************************************
* Note to the RFC Editor (to be removed prior to publication) * * Note to the RFC Editor (to be removed prior to publication) *
* * * *
* * * *
* 1) The reference to RFCXXXX throughout this document point * * 1) The reference to RFCXXXX throughout this document point *
* to the current draft-ietf-manet-smf-xx.txt. This needs * * to the current draft-ietf-manet-smf-xx.txt. This needs *
* to be replaced with the XXXX RFC number for the SMF * * to be replaced with the XXXX RFC number for the SMF *
* publication. * * publication. *
* * * *
* 2) Appendix A contains the IANAsmfOpModeID-MIB * * 2) This document also contains the IANAsmfOpModeID-MIB *
* module which is defined by this specification in the * * module which is defined by this specification above. *
* appendix. The RFC editor should remove this specification * * IANA should take over the IANAsmfOpModeID-MIB and keep it *
* of the IANAsmfOpModeID-MIB upon publication of * * synchronized with the registry identified within the *
* the SMF-MIB. Further, IANA should take over the * * contained IANAsmfOpModeIdTC TEXTUAL-CONVENTION. *
* IANAsmfOpModeID-MIB and keep it synchronized *
* with the registry identified within the contained *
* IANAsmfOpModeIdTC TEXTUAL-CONVENTION. *
* * * *
* 3) Appendix B contains the IANAsmfRssaID-MIB * * 3) This document contains the IANAsmfRssaID-MIB *
* module which is defined by this specification in the * * module which is defined by this specification above. *
* appendix. The RFC editor should remove this specification * * IANA should take over the IANAsmfRssaID-MIB and keep it *
* of the IANAsmfRssaID-MIB upon publication of * * synchronized with the registry identified within the *
* the SMF-MIB. Further, IANA should take over the * * contained IANAsmfRssaID TEXTUAL-CONVENTION. *
* IANAsmfRssaID-MIB and keep it synchronized *
* with the registry identified within the contained *
* IANAsmfRssaID TEXTUAL-CONVENTION. *
* * * *
*************************************************************** ***************************************************************
Authors' Addresses Authors' Addresses
Robert G. Cole Robert G. Cole
US Army CERDEC US Army CERDEC
6010 Frankford Road 6010 Frankford Road
Aberdeen Proving Ground, Maryland 21005 Aberdeen Proving Ground, Maryland 21005
USA USA
 End of changes. 27 change blocks. 
269 lines changed or deleted 305 lines changed or added

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