<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc category="exp" docName="draft-nguyen-manet-ecds-mib-02" ipr="trust200902">
<front>
<title abbrev="ECDS-MIB">Definition of Managed Objects for the MANET Essential Connected Dominating Set (E-CDS) Process</title>

<author fullname="James H. Nguyen" initials="J.N." surname="Nguyen">
<organization>US Army CERDEC</organization>
<address>
<postal>
<street>6010 Frankford Road</street>
<city>Aberdeen Proving Ground</city>
<region>Maryland</region>
<code>21005</code>
<country>USA</country>
</postal>
<phone>+1 443 395 5628</phone>
<email>james.h.nguyen4.civ@mail.mil</email>
</address>
</author>

<author fullname="Robert G. Cole" initials="R.G." surname="Cole">
<organization>US Army CERDEC</organization>
<address>
<postal>
<street>6010 Frankford Road</street>
<city>Aberdeen Proving Ground</city>
<region>Maryland</region>
<code>21005</code>
<country>USA</country>
</postal>
<phone>+1 443 395 8744</phone>
<email>robert.g.cole@us.army.mil</email>
</address>
</author>

<date />

<area>Operations and Management</area>

<workgroup>Internet Engineering Task Force</workgroup>

<keyword>Network Management</keyword>
<keyword>Management Information Base</keyword>
<keyword>MIB</keyword>
<keyword>SMIv2</keyword>
<keyword>Reporting</keyword>
<keyword>MANET</keyword>

<abstract>
<t>
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects for configuring aspects of the Essential Connected Dominating Set (E-CDS) process for Mobile Ad-Hoc Networks (MANETs).  The ECDS-MIB also reports state information, performance metrics, and notifications.  In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems.
</t>
</abstract>
</front>

<middle>
<section title="Introduction">
<t>
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 Essential-Connected Dominating Set (E-CDS) <xref target="RFC5614"/> algorithm for Mobile Ad-Hoc Networks (MANETs).  The E-CDS process transforms a 2-hop neighborhood topology information set for routers to dynamically perform relay self-election to form a Connected Dominating Set (CDS).  The ECDS-MIB, an extension to the SMF-MIB <xref target="draft-ietf-manet-smf-mib-06"/>, reports state information, performance metrics, and notifications.  In addition to configuration, this additional state and performance information is useful to operators troubleshooting multicast forwarding problems.
</t>
</section>


<section title="The Internet-Standard Management Framework">
<t>For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of <xref target="RFC3410"/>.  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, <xref target="RFC2578"/>, STD 58, <xref target="RFC2579"/> and STD 58, <xref target="RFC2580"/>.</t>
</section>

<section title="Conventions">
<t>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 <xref target="RFC2119" />.
</t>
</section>

<section title="Overview">
<t>The E-CDS algorithm provides method for implementing selection of Multipoint Relay nodes that define an estimate of the Minimum Connected Dominating Set (MCDS) flooding.  The MCDS  provides an efficient and complete coverage of the nodes comprising the MANET.  The packet forwarding rules do not require knowledge of the previous hop.  Routers that run Simplified Multicast Forwarding (SMF) <xref target="RFC6621"/> and have E-CDS enabled can be mixed with routers that run SMF and Classic Flooding (CF) enabled without a problem, even when the CF nodes are not participating in the Neighborhood Discovery Protocol (NHDP) <xref target="RFC6130"/>.  Another benefit is that packets opportunistically received from non-symmetric neighbors may be forwarded without compromising flooding efficiency or correctness. Furthermore, multicast sources not participating in NHDP may freely inject their traffic and any neighboring E-CDS relays will properly forward the traffic.  The E-CDS based relay set selection algorithm is defined in <xref target="RFC5614"/>.</t>

<section title="ECDS-MIB Management Model">
<t>As mentioned in Overview Section, the ECDS-MIB is an extension to SMF-MIB.  The SMF-MIB defines the management interfaces into the SMF process.  The SMF process is a framework for efficient broadcast capabilities within a MANET.  As part of the management interfaces, the SMF-MIB contains configuration objects required for the common management of all CDS processes.  The SMF-MIB contains a capabilities table which lists the set of CDS algorithms supported by the specific router.  However, the SMF-MIB does not define objects for configuration which are specific to the particular
CDS process in question.  Hence, it is required that additional MIB modules be defined for each new CDS process implemented
on the router.  In this sense, these additional MIB-modules extend the SMF-MIB.</t>

<figure>
<preamble />
<artwork><![CDATA[
 ______________                _____________
|              |              |             |
| Neighborhood |              |  Relay Set  |
|  Discovery   |------------->|  Selection  |
|              |   neighbor   |  Algorithm  |
|______________|     info     |_____________|
	\                              /
         \                            /
  neighbor\                          /forwarding
    info*  \      ____________      /  status
            \    |            |    /
             `-->| Forwarding |<--'
                 |  Process   |
~~~~~~~~~~~~~~~~>|____________|~~~~~~~~~~~~~~~~~>
incoming packet,                 forwarded packets
interface id*, and
previous hop*

Figure 1: SMF router Architecture.

]]></artwork>
<postamble />
</figure>

<t>The various CDS algorithms are referred to as Relay Set Selection Algorithm (RSSA) within the SMF specification.  The RSSAs can rely upon topology information gotten from the MANET NHDP, from the specific MANET routing protocol running on the node, or from Layer 2 information passed up to the higher layer protocol processes.  In the ECDS process, nodes can select themselves as relays using a router identifier and a nodal metric known as "Router Priority" for all one-hop and two-hop neighbors.  Changing the Router Priority can result in different realizations of CDSs for a given network topology.</t>

</section>


<section title="Terms">
<t>The following definitions apply throughout this document:</t>
<t>
<list style="symbols">
<t>Control Objects - Objects which are initialized to default settings or set through the management interface defined by this MIB.</t>
<t>State Objects - objects are automatically generated values which define the current operating state of the E-CDS process in the router.</t>
<t>Performance Objects - objects are automatically generated values which help an administrator or automated tool to assess the performance of the CDS multicast process on the router and the overall multicasting performance within the MANET routing domain.</t>
</list>
</t>
</section>
</section>


<section title="Structure of the MIB Module">
<t>This section presents the structure of the ECDS-MIB module.  The objects are arranged into the following groups:</t>
<t>
<list style="symbols">
    <t>ecdsMIBNotifications - defines notifications that are associated with ECDS-MIB</t>
    <t>ecdsMIBObjects - defines objects as part of the structure of ECDS-MIB.  These objects are divided as follows:
    <list style="symbols">
        <t>Configuration Group - this group contains ECDS objects that configure specific options that determine the overall operation of ECDS process.</t>
        <t>State Group - this group contains ECDS objects that describe the state of the ECDS process.</t>
        <t>Performance Group - this groups contains ECDS objects that help operators to characterize the performance of the ECDS process as configured.</t>
    </list></t>
    <t>ecdsMIBConformance - defines minimal and full conformance of the implementations of this ECDS-MIB module.</t>
</list>
</t>
<section title="Textual Conventions">
<!--Generic and Common Textual Conventions can be found summarized at http://www.ops.ietf.org/mib-common-tcs.html-->

<t>The textual conventions defined within the ECDS-MIB are as follows:</t>
<t>
<list style="symbols">
    <t>EcdsStatus - is defined within the ECDS-MIB. This contains the current operational status of the E-CDS process on an interface.</t>
</list>
</t>
</section>


<section title="The Configuration Group">
<t>The E-CDS device is configured with a set of controls.   Some of the prominent configuration controls for the SMF E-CDS device follow:
</t>

<t>
<list style="symbols">
    <t>E-CDS Operational Mode (ecdsAdminStatus) - indicates that the router has E-CDS enabled.</t>
    <t>Router Identifier (ecdsRouterIDAddrType and ecdsRouterID) - indicates router's unique identifier in E-CDS neighborhood.</t>
    <t>Router Priority (ecdsConfiguredRouterPriority) - indicates nodal metric value for all one-hop and two-hop neighbors.</t>
    <t>Configuration method that computes Router Priority (ecdsConfiguredRtrPriMethod) - indicates what method the Router Priority is computed, i.e., dynamically configured, management configured, or other.</t>
</list>
</t>

</section>


<section title="The State Group">
<t>The state of an ECDS device can be retrieved from the following objects:</t>
<t>
<list style="symbols">
<t>E-CDS Configuration State (ecdsOperationStatus) - a state that indicates whether or not the ECDS process is enabled or disabled on the node.</t>
<t>E-CDS Operational State (ecdsCurrentInEcds) - a state that indicates whether or not the node currently in or out of the Relay Set</t>
<t>E-CDS Current Router Priority Value (ecdsCurrentRtRPriValue) - the Router Priority that is currently assigned to the device.</t>
</list>
</t>	
</section>

<section title="The Performance Group">
<t>The E-CDS performance counters consist of per node objects:</t>
<t>
<list style="symbols">
    <t>Counter of times the given node changed into or out of E-CDS (ecdsInEcdsChange).</t>
    <t>Counter of times the Router Priority has been changed (ecdsCurrentRtrPriValueChange).</t>
</list>
</t>	
</section>

<section title="The Notifications Group">
  <t>The Notifications Sub-tree contains the list of notifications supported within the ECDS-MIB and their intended purpose or utility.  These include:</t>
  <t> 
    <list style="symbols">
      <t>ecdsAdminStatusChange - this notification is sent when ecdsAdminStatus is changed.</t>
      <t>ecdsConfiguredMemberChange - this notification is sent when cdsConfiguredMember is changed.</t>
      <t>ecdsIfRtrPriChange - this notification is sent when ecdsIfRtrPri value is changed.</t>
      <t>ecdsRtrPriMethodChange - this notification is sent when ecdsConfiguredRtrPriMethod is changed.</t>
    </list>
  </t>
</section>      

</section>

<section title="Relationship to Other MIB Modules">

<section title="Relationship to the SNMPv2-MIB">
<t>The 'system' group in the SNMPv2-MIB <xref target="RFC3418"/> 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 ECDS-MIB does not duplicate those objects.</t>
</section>

<section title="Relationship to the SMF-MIB">
<t>This ECDS-MIB module is an extension of the SMF-MIB module in the sense previously discussed.  To manage SMF router with ECDS-enabled, both SMF-MIB and ECDS-MIB implementations are required.</t>
</section>

<section title="MIB modules required for IMPORTS">
  <t>The textual conventions imported for use in the SMF-MIB are as follows:</t>
  <t>
    <list style="symbols">
      <t>The MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Unsigned32, Integer32 and mib-2 textual conventions are imported from <xref target="RFC2578"/>.</t> 
      <t>The TEXTUAL-CONVENTION, RowStatus and TruthValue textual conventions are imported from <xref target="RFC2579"/>.</t>
      <t>The MODULE-COMPLIANCE, OBJECT-GROUP and NOTIFICATION-GROUP textual conventions are imported from <xref target="RFC2580"/>.</t>
      <t>The InetAddress, InetAddressType and InetAddressPrefixLength textual conventions are imported from <xref target="RFC4001"/>.</t>
    </list>
  </t>
</section>

</section>

<section title="Definitions">
<t></t>

<figure>
<artwork><![CDATA[

ECDS-MIB DEFINITIONS ::= BEGIN

IMPORTS

	MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
	Counter32, Integer32, experimental
		FROM SNMPv2-SMI 			   -- [RFC2578]

	TEXTUAL-CONVENTION, TruthValue
		FROM SNMPv2-TC 			           -- [RFC2579]

	MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 
		FROM SNMPv2-CONF 		           -- [RFC2580]

	InetAddress, InetAddressType
		FROM INET-ADDRESS-MIB 		           -- [RFC4001]
;

manetEcdsMIB MODULE-IDENTITY
LAST-UPDATED "201301021000Z" -- 2 January 2013
ORGANIZATION "IETF MANET Working Group"
CONTACT-INFO
"WG E-Mail:	manet@ietf.org

WG Chairs: 	jmacker@nrl.navy.mil
		sratliff@cisco.com 

Editors: 	James H. Nguyen
		US Army CERDEC
		Space and Terrestrial Communications
		6010 Frankford Road
		Aberdeen Proving Ground, MD 21005
		USA
		+1 443 395-5628

		Robert G. Cole
		US Army CERDEC
		Space and Terrestrial Communications
		Aberdeen Proving Ground, MD 21005
		USA
		+1 443 395-8744"

DESCRIPTION

	"This MIB module contains managed object definitions for the 
         Manet E-CDS process defined in: [RFC5614]

	 Copyright (C) The IETF Trust (2008). This version of this MIB 
	 module is part of RFC xxxx; see the RFC itself for full legal 
	 notices."

	-- revision
	REVISION "201301021000Z" -- 2 January 2013
	DESCRIPTION
		"Initial version of this MIB module,
	 	 published as draft-nguyen-maney-ecds-mib-02.txt."
	::= { experimental 9999 }  -- to be assigned by IANA



-- 
-- TEXTUAL Conventions
--

EcdsStatus ::= TEXTUAL-CONVENTION
	STATUS		current
	DESCRIPTION
		"An indication of the operability of a E-CDS function 
                 or feature or example, the status of an node: 
		
		 - 'enabled(1)' indicates that it is performing E-CDS 
                   functions
		 - 'disabled(2)' indicates that it is not."
	SYNTAX	INTEGER {
			enabled (1),
			disabled (2)
		}

--
-- Top-Level Object Identifier Assignments
--

ecdsMIBNotifications OBJECT IDENTIFIER 	::= { manetEcdsMIB 0 }
ecdsMIBObjects OBJECT IDENTIFIER 	::= { manetEcdsMIB 1 }
ecdsMIBConformance OBJECT IDENTIFIER 	::= { manetEcdsMIB 2 }

--
-- ecdsMIBObjects Assignments:
-- ecdsConfigurationGroup 	- 1
-- ecdsStateGroup 		- 2
-- ecdsPerformanceGroup 	- 3
--

--
-- ecdsConfigurationGroup
--
-- This group contains the E-CDS objects that configure specific 
-- options that determine the overall performance and operation
-- of the multicast forwarding process for the router device
--


ecdsConfigurationGroup OBJECT IDENTIFIER ::= { ecdsMIBObjects 1 }

ecdsAdminStatus	OBJECT-TYPE
	SYNTAX		EcdsStatus
	MAX-ACCESS	read-write
	STATUS 		current
	DESCRIPTION
		"The configured status of the E-CDS process on this 
                 device. 

		 - Enabled(1) means that E-CDS is configured to run on 
                   this device. 
		 - Disabled(2) mean that the E-CDS process is 
                   configured off. 

		 This object is persistent and when written the entity 
		 should save the change to non-volatile storage.
		
		 The default value of ecdsAdminStatus is disabled (2)."
	DEFVAL { disabled }
	::= { ecdsConfigurationGroup 1 }

ecdsRouterIDAddrType	OBJECT-TYPE
	SYNTAX		InetAddressType
	MAX-ACCESS	read-write
	STATUS		current
	DESCRIPTION
		"The address type of the address that is used for 
                 'ecdsRouterID' of this router as specified in the 
                 'ecdsRouterID' text.

		 Only ipv4(1) and ipv6(2) are supported. 

		 ecdsRouterIDAddrType can be set by the management 
                 station, the ecdsRouterID must be a routable address
                 assigned to this router.  If the management station 
                 does not assign this value then the router should 
                 choose the highest routable IP address assigned to 
                 this router. the default value of ecdsRouterAddrType
                 is ipv4.

		 This object is persistent and when written, the
                 entity should save the change to non-volatitle 
                 storage."
	DEFVAL { ipv4 }
::= { ecdsConfigurationGroup 2 }

ecdsRouterID 	OBJECT-TYPE
	SYNTAX		InetAddress (SIZE(4|16))
	MAX-ACCESS 	read-write
	STATUS 		current
	DESCRIPTION
		"The IP address used as the E-CDS router ID.  This can
                 be set by the management station.  If not explicitly
                 set, then the device should select a routable IP 
                 address assigned to this router for use as the 
                 'ecdsRouterID'.  The ecdsRouterID is a logical 
                 identification that must be consistent across 
                 interoperating E-CDS 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 ecdsRouterID must be unique 
                 within the scope of the operating MANET network 
                 regardless of the method used for selecting it.  

		 This object is persistent and when written the entity 
		 should save the change to non-volatile storage."
::= { ecdsConfigurationGroup 3 }

ecdsConfiguredRtrPriMethod OBJECT-TYPE
	SYNTAX 	INTEGER {
			dynamicallyConfigured (1),
			managementConfigured (2),
			other (3)
		}
	MAX-ACCESS 	read-write
	STATUS	 	current
	DESCRIPTION
		"This object indicates which method Router Priority 
                 value is computed."
::= { ecdsConfigurationGroup 4 }

ecdsConfiguredRouterPriority OBJECT-TYPE
	SYNTAX 		Integer32
	MAX-ACCESS 	read-write
	STATUS 		current
	DESCRIPTION
		"a nodal metric for all 1-hop and 2-hop neighbors. 
                 Relay routers use tuple of router identifier and 
                 router priority to compute self-election of MPR."
::= { ecdsConfigurationGroup 5 }

ecdsConfiguredMember OBJECT-TYPE
	SYNTAX 	INTEGER {
			potential(1),
			always(2),
			never(3)
		}
	MAX-ACCESS 	read-write
	STATUS 		current
	DESCRIPTION
		"The E-CDS downselects a set of forwarders for
                 multicast forwarding. Sometimes, it is useful to force
                 an agent to be included or excluded from the resulting 
                 CDS. This object is a switch to allow for this 
                 behavior.  

		 - The value potential(1) allows the selected E-CDS
		   to determine if this agent is included or 
		   excluded from the E-CDS. 

		 - The value always(1) forces the selected E-CDS 
                   process

		 - The value never(3) forces not to use E-CDS process

		 - The default setting for this object is 
                   'potential(1)'.  Other settings could pose 
                   operational risks under certain conditions.  

		 This object is persistent and when written the entity 
		 should save the change to non-volatile storage."
	DEFVAL { potential }
::= { ecdsConfigurationGroup 6 }

--
-- E-CDS State Group
--

ecdsStateGroup OBJECT IDENTIFIER ::= { ecdsMIBObjects 2 }

ecdsOperationStatus OBJECT-TYPE
	SYNTAX 		EcdsStatus
	MAX-ACCESS 	read-only
	STATUS 		current
	DESCRIPTION
		"The configured status of the E-CDS process on this 
		 device. 

		 - enabled(1) means that E-CDS is configured to run on
                   this device. 
		
		 - disabled(2) mean that the E-CDS process is 
                   configured off. 

		 This object is persistent and when written the entity 
		 should save the change to non-volatile storage.
		
		 The default value of ecdsOperationStatus is 
                 disabled (2)."
	DEFVAL { disabled }
::= { ecdsStateGroup 1 }


ecdsCurrentRtrPriValue OBJECT-TYPE
	SYNTAX 		Integer32 
	MAX-ACCESS 	read-only
	STATUS		current
	DESCRIPTION
		"current Router Priority value"
::= { ecdsStateGroup 2 }

ecdsCurrentInEcds OBJECT-TYPE
	SYNTAX 		TruthValue
	MAX-ACCESS	read-only
	STATUS 		current
	DESCRIPTION
		"This object indicates that the current node has E-CDS 
		 configured and in E-CDS. true(1) means the router has 
		 E-CDS configured or false(2) otherwise."
::= { ecdsStateGroup 3 }


--
-- E-CDS Performance Group
--

ecdsPerformanceGroup OBJECT IDENTIFIER ::= { ecdsMIBObjects 3 }

ecdsInEcdsChange OBJECT-TYPE
	SYNTAX		Counter32
	MAX-ACCESS	read-only
	STATUS		current
	DESCRIPTION
		"This object indicates how many times the current 
                 node is configured to be in E-CDS."
::= { ecdsPerformanceGroup 1 }


ecdsCurrentRtrPriValueChange OBJECT-TYPE
	SYNTAX		Counter32
	MAX-ACCESS	read-only
	STATUS		current
	DESCRIPTION
		"This object indicates how many times the Router 
                 Priority of the current node has been changed."
::= { ecdsPerformanceGroup 2 }

--
-- E-CDS Notification 
--

ecdsMIBNotifObjects OBJECT IDENTIFIER 	::= { ecdsMIBNotifications 0 }

--
-- E-CDS Notification Objects
--

ecdsAdminStatusChange NOTIFICATION-TYPE
	OBJECTS {
		ecdsRouterID,	      -- the originator of notification
		ecdsRouterIDAddrType, -- the originator of notification
		ecdsAdminStatus	      -- the new status of E-CDS 
                                      --     process
	}
	STATUS		current
	DESCRIPTION
		"ecdsAdminStatusChange notification is sent when 
		 ecdsAdminStatus is changed."
::= { ecdsMIBNotifObjects 1 }

ecdsConfiguredMemberChange NOTIFICATION-TYPE
	OBJECTS {
		ecdsRouterID,	      -- the originator of notification
		ecdsRouterIDAddrType, -- the originator of notification
		ecdsConfiguredMember  -- the indication of being 
                                      --    included from E-CDS process
	}
	STATUS 		current
	DESCRIPTION
		"ecdsConfiguredMemberChange notification is sent when 
		 ecdsConfiguredMember is changed."
::= { ecdsMIBNotifObjects 2 }

ecdsRtrPriChange NOTIFICATION-TYPE
	OBJECTS {
		ecdsRouterID,	             -- the originator of 
                                             --     notification
		ecdsRouterIDAddrType,        -- the originator of 
                                             --     notification
		ecdsConfiguredRouterPriority -- the priority value
	}
	STATUS 		current
	DESCRIPTION
		"ecdsIfRtrPriChange notification is sent when 
                 ecdsIfRtrPri value is changed."
::= { ecdsMIBNotifObjects 3 }

ecdsRtrPriMethodChange NOTIFICATION-TYPE
	OBJECTS {
		ecdsRouterID,	           -- the originator of 
                                           --     notification
		ecdsRouterIDAddrType,      -- the originator of 
                                           --     notification
		ecdsConfiguredRtrPriMethod -- the method is used to 
                                           --     calculate router 
                                           --     priority
	}
	STATUS		current
	DESCRIPTION
		"ecdsRtrPriMethodChange notification is sent when
		 ecdsConfiguredRtrPriMethod is changed."
::= { ecdsMIBNotifObjects 4 }

--
-- Compliance Statements
--

ecdsCompliances OBJECT IDENTIFIER  ::= { ecdsMIBConformance 1 }
ecdsMIBGroups 	OBJECT IDENTIFIER  ::= { ecdsMIBConformance 2 }

ecdsBasicCompliance MODULE-COMPLIANCE
	STATUS 		current
	DESCRIPTION 
		"The basic implementation requirements for managed 
		 network entities that implement the E-CDS process."
	MODULE -- this module
	MANDATORY-GROUPS { 
		ecdsConfigurationComplianceGroup 
	}
::= { ecdsCompliances 1 }

ecdsFullCompliance MODULE-COMPLIANCE
	STATUS 		current
	DESCRIPTION 
		"The full implementation requirements for managed  
		 network entities that implement the E-CDS process."
	MODULE -- this module
	MANDATORY-GROUPS { 
		ecdsConfigurationComplianceGroup,
		ecdsStateComplianceGroup,
		ecdsPerformanceComplianceGroup,
		ecdsNotificationsComplianceGroup
	}
::= { ecdsCompliances 2 }

ecdsConfigurationComplianceGroup OBJECT-GROUP
	OBJECTS {
		ecdsAdminStatus,
		ecdsRouterID,
                ecdsRouterIDAddrType,
                ecdsConfiguredRouterPriority,
		ecdsConfiguredMember,
		ecdsConfiguredRtrPriMethod
	}
	STATUS 		current
	DESCRIPTION
		"Set of configuration objects implemented in this 
                 module"
::= { ecdsMIBGroups 1 }

ecdsStateComplianceGroup OBJECT-GROUP
	OBJECTS {	
		ecdsOperationStatus,
		ecdsCurrentRtrPriValue,
		ecdsCurrentInEcds
	}
	STATUS 		current
	DESCRIPTION
		"set of state objects implemented in this module"
::= { ecdsMIBGroups 2 }

ecdsPerformanceComplianceGroup OBJECT-GROUP
	OBJECTS {
		ecdsInEcdsChange,
		ecdsCurrentRtrPriValueChange
	}
	STATUS 		current
	DESCRIPTION
		"set of performance objects implemented in this
                 module"
::= { ecdsMIBGroups 3 }

ecdsNotificationsComplianceGroup NOTIFICATION-GROUP
	NOTIFICATIONS {
		ecdsAdminStatusChange,
		ecdsConfiguredMemberChange,
		ecdsRtrPriChange,
		ecdsRtrPriMethodChange
	}
	STATUS 		current
	DESCRIPTION
		"set of notification objects implemented in this
                 module"
::= { ecdsMIBGroups 4 }

END

]]></artwork>
</figure>
</section>

<section title="Security Considerations">
<t>This section discusses security implications of the choices made in this ECDS-MIB module.</t>

<t>There are a number of management objects defined in this MIB module with MAX-ACCESS clause of read-write and/or read-create.  Such objects maybe considered sensitive or vulnerable in some network environments.  The support of SET operations in a non-secure environment without proper protection can have a negative effect on network operations.  These are objects and their sensitivity/vulnerability:
</t>
<t>
<list style="symbols">
    <t>ecdsAdminStatus - this writable configuration object controls the operational status of the SMF ECDS process.  If this setting is configured inconsistently across the MANET multicast domain, then the delivery of multicast data maybe also be inconsistent across the domain.</t>
    <t>ecdsRouterIDAddrType and ecdsRouterID - these writable configuration objects define the identifier (ID) of the SMF E-CDS process.  These objects should be configured with a routable address defined on the local SMF E-CDS device.  The ecdsRouterID is the logical identification that must be consistent across interoperating SMF E-CDS neighborhoods.  The ecdsRouterID is recommended to be chosen as the numerically largest address contained in a node's 'Neighbor Address List' as defined in NHDP <xref target="RFC6130" />.</t>
    <t>ecdsConfiguredRtrPriMethod - this writable configuration object indicates how the value of Router Priority is computed.</t>
    <t>ecdsConfiguredRouterPriority - this writable configuration object indicates a nodal metric for all 1-hop and 2-hop neighbors.  Relay routers use tuple of router identifier and router priority to compute self-election of MPR.</t>
    <t>ecdsConfiguredMember - this writable configuration object defines a set of forwarders for multicast forwarding.  Sometimes, it is useful to force an agent to be included or excluded from the resulting CDS.  This object is a switch to allow for this behavior.  Mis-configuration of the object may cause the MANET flooding to break due to logical splits in the topology.</t>
</list>
</t>
</section>

<section title="Applicability Statement">
<t>
This document describes objects for configuring Essential Connected Dominating Set (E-CDS) process parameters on a router.  This MIB module, denoted ECDS-MIB module, also reports state, performance information and notifications.  Since it is an extension of SMF-MIB module, the same applicability examples can be found in SMF-MIB draft.
</t>
</section>


<section title="IANA Considerations">
  <t>The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER value recorded in the SMI Numbers registry:</t>
  <figure>
  <artwork>
    <![CDATA[
        Descriptor        OBJECT IDENTIFIER value
        ----------        -----------------------
        ECDS-MIB          { experimental 9999 }
	IANA EDITOR NOTE: please assign 9999
    ]]>
  </artwork>
  </figure>
</section>

<section title="Contributors">
<t>
This MIB document uses templates authored by D. Harrington which is based on contributions from the MIB Doctors, especially Juergen Schoenwaelder, Dave Perkins, C.M. Heard, and Randy Presuhn.
</t>
</section>

<section title="Acknowledgements">
<t>
The authors would like to acknowledge the valuable comments from Ulrich Herberg in the early phases of the development of this MIB-module.  Further, the authors would like to acknowledge to work of Brian Little and Ryan Morgan on their software development of the ECDS-MIB.
</t>
</section>

<section title="Change Log">
  <t>This section tracks the revision history in the development of this ECDS-MIB.  It will be removed from the final version of this document.</t>
  <t>These changes were made from draft-nguyen-manet-ecds-mib-01 to draft-nguyen-manet-ecds-mib-02:</t>
  <t>
    <list style="numbers">
      <t>Added references, applicability statement, security considerations, IANA considerations, acknowledgment.</t>
      <t>Added ecdsRouterIDAddrType object to go along with ecdsRouterID</t>
    </list>
  </t>

  <t>These changes were made from draft-nguyen-manet-ecds-mib-00 to draft-nguyen-manet-ecds-mib-01:</t>
  <t>
    <list style="numbers">
      <t>Initial draft</t>
    </list>
  </t>
</section>

<section title="Open Issues">
<t>This section contains the set of open issues related to the development and design of the ECDS-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.</t>

<t>
<list style="numbers">
    <t> Does this MIB module need to include the MDR Level as a state object? </t>
    <t> Within the Security Section, we need to include a discussion of the problems caused by mis-configuring the ecdsRouterID, the ecdsConfigured RtrPriMethod, and the ecdsConfiguredRouterPriority objects. </t>
    <t> Once the SMF-MIB module is published, the references to the RFC must be updated.</t>
    <t>A careful review by the working group.</t>
</list>
</t>
</section>



<section title="Title">
<figure>
<preamble/>
<artwork>
***************************************************************
* Note to the RFC Editor (to be removed prior to publication) *
*                                                             *
* 1) The reference to RFCXXXX within the DESCRIPTION clauses  *
* of the MIB module point to this draft and are to be         *
* assigned by the RFC Editor.                                 *
*                                                             *
***************************************************************
</artwork>
<postamble/>
</figure>
</section>


</middle>
<back>
<references title="Normative References">

<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>

<reference anchor='RFC2578'>
<front>
<title abbrev='SMIv2'>Structure of Management Information Version 2 (SMIv2)</title>
<author initials='K.' surname='McCloghrie' fullname='Keith McCloghrie' role='editor'>
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country></postal>
<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email></address></author>
<author initials='D.' surname='Perkins' fullname='David Perkins' role='editor'>
<organization>SNMPinfo</organization>
<address>
<postal>
<street>3763 Benton Street</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>US</country></postal>
<phone>+1 408 221 8702</phone>
<email>dperkins@snmpinfo.com</email></address></author>
<author initials='J.' surname='Schoenwaelder' fullname='Juergen Schoenwaelder' role='editor'>
<organization>TU Braunschweig</organization>
<address>
<postal>
<street>Bueltenweg 74/75</street>
<street>38106 Braunschweig</street>
<country>DE</country></postal>
<phone>+49 531 3913283</phone>
<email>schoenw@ibr.cs.tu-bs.de</email></address></author>
<date year='1999' month='April' /></front>
<seriesInfo name='STD' value='58' />
<seriesInfo name='RFC' value='2578' />
<format type='TXT' octets='89712' target='http://www.rfc-editor.org/rfc/rfc2578.txt' />
</reference>

<reference anchor='RFC2579'>
<front>
<title>Textual Conventions for SMIv2</title>
<author initials='K.' surname='McCloghrie' fullname='Keith McCloghrie' role='editor'>
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country></postal>
<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email></address></author>
<author initials='D.' surname='Perkins' fullname='David Perkins' role='editor'>
<organization>SNMPinfo</organization>
<address>
<postal>
<street>3763 Benton Street</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>US</country></postal>
<phone>+1 408 221 8702</phone>
<email>dperkins@snmpinfo.com</email></address></author>
<author initials='J.' surname='Schoenwaelder' fullname='Juergen Schoenwaelder' role='editor'>
<organization>TU Braunschweig</organization>
<address>
<postal>
<street>Bueltenweg 74/75</street>
<street>38106 Braunschweig</street>
<country>DE</country></postal>
<phone>+49 531 3913283</phone>
<email>schoenw@ibr.cs.tu-bs.de</email></address></author>
<date year='1999' month='April' /></front>
<seriesInfo name='STD' value='58' />
<seriesInfo name='RFC' value='2579' />
<format type='TXT' octets='59039' target='http://www.rfc-editor.org/rfc/rfc2579.txt' />
</reference>

<reference anchor='RFC2580'>
<front>
<title>Conformance Statements for SMIv2</title>
<author initials='K.' surname='McCloghrie' fullname='Keith McCloghrie'>
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country></postal>
<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email></address></author>
<author initials='D.' surname='Perkins' fullname='David Perkins'>
<organization>SNMPinfo</organization>
<address>
<postal>
<street>3763 Benton Street</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>US</country></postal>
<phone>+1 408 221 8702</phone>
<email>dperkins@snmpinfo.com</email></address></author>
<author initials='J.' surname='Schoenwaelder' fullname='Juergen Schoenwaelder'>
<organization>TU Braunschweig</organization>
<address>
<postal>
<street>Bueltenweg 74/75</street>
<city>Braunschweig</city>
<code>38106</code>
<country>DE</country></postal>
<phone>+49 531 3913283</phone>
<email>schoenw@ibr.cs.tu-bs.de</email></address></author>
<date year='1999' month='April' /></front>
<seriesInfo name='STD' value='58' />
<seriesInfo name='RFC' value='2580' />
<format type='TXT' octets='54253' target='http://www.rfc-editor.org/rfc/rfc2580.txt' />
</reference>

<reference anchor='RFC3418'>
<front>
<title>Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)</title>
<author initials='R.' surname='Presuhn' fullname='R. Presuhn'>
<organization /></author>
<date year='2002' month='December' />
</front>
<seriesInfo name='STD' value='62' />
<seriesInfo name='RFC' value='3418' />
<format type='TXT' octets='49096' target='http://www.rfc-editor.org/rfc/rfc3418.txt' />
</reference>

<reference anchor='RFC4001'>
<front>
<title>Textual Conventions for Internet Network Addresses</title>
<author initials='M.' surname='Daniele' fullname='M. Daniele'>
<organization /></author>
<author initials='B.' surname='Haberman' fullname='B. Haberman'>
<organization /></author>
<author initials='S.' surname='Routhier' fullname='S. Routhier'>
<organization /></author>
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder'>
<organization /></author>
<date year='2005' month='February' />
</front>
<seriesInfo name='RFC' value='4001' />
<format type='TXT' octets='45836' target='http://www.rfc-editor.org/rfc/rfc4001.txt' />
</reference>

<reference anchor="RFC6130">
<front>
<title>Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)</title>
<author initials='T.' surname='Clausen' fullname='T. Clausen'>
<organization /></author>
<author initials='C.' surname='Dearlove' fullname='C. Dearlove'>
<organization /></author>
<author initials='J.' surname='Dean' fullname='J. Dean'>
<organization /></author>
<date year='2011' month='April' />
</front>
<seriesInfo name='RFC' value='6130' />
<format type='TXT' octets='190678' target='http://www.rfc-editor.org/rfc/rfc6130.txt' />
</reference>

<reference anchor="RFC6621">
<front>
<title>Simplified Multicast Forwarding</title>
<author initials="J." surname="Macker" fullname="J. Macker"><organization/></author>
<date year="2012" month="May"/>
<abstract>
<t>This 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.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6621"/>
<format type="TXT" octets="139674" target="http://www.rfc-editor.org/rfc/rfc6621.txt"/>
</reference>

<reference anchor="RFC5614">
<front>
<title>Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding</title>
<author initials="R." surname="Ogier" fullname="R. Ogier"><organization/></author>
<author initials="P." surname="Spagnolo" fullname="P. Spagnolo"><organization/></author>
<date year="2009" month="August"/>
<abstract>
<t>This 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 bi-connected 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.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5614"/>
<format type="TXT" octets="170106" target="http://www.rfc-editor.org/rfc/rfc5614.txt"/>
</reference>

<reference anchor="draft-ietf-manet-smf-mib-06">
<front>
<title>Definition of Managed Objects for the Manet Simplified Multicast Framework  Relay Set Process</title>
<author initials="R" surname="Cole" fullname="Robert Cole"><organization/></author>
<author initials="J" surname="Macker" fullname="Joseph Macker"><organization/></author
><author initials="B" surname="Adamson" fullname="Brian Adamson"><organization/></author>
<author initials="S" surname="Harnedy" fullname="Sean Harnedy"><organization/></author>
<date month="February" day="28" year="2009"/>
<abstract>
<t>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process.  The SMF 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 multicast forwarding problems.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-cole-manet-smf-mib-06"/><format type="TXT" target="http://www.ietf.org/internet-drafts/draft-cole-manet-smf-mib-06.txt"/>
</reference>



</references>

<references title="Informative References">

<reference anchor='RFC3410'>
<front>
<title>Introduction and Applicability Statements for Internet-Standard Management Framework</title>
<author initials='J.' surname='Case' fullname='J. Case'>
<organization /></author>
<author initials='R.' surname='Mundy' fullname='R. Mundy'>
<organization /></author>
<author initials='D.' surname='Partain' fullname='D. Partain'>
<organization /></author>
<author initials='B.' surname='Stewart' fullname='B. Stewart'>
<organization /></author>
<date year='2002' month='December' />
</front>
<seriesInfo name='RFC' value='3410' />
<format type='TXT' octets='61461' target='http://www.rfc-editor.org/rfc/rfc3410.txt' />
</reference>


</references>


</back>
</rfc>
