IANA-SMF-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, mib-2
              FROM SNMPv2-SMI
    TEXTUAL-CONVENTION
              FROM SNMPv2-TC;

ianaSmfMIB MODULE-IDENTITY
    LAST-UPDATED "201408140000Z"  -- August 14, 2014
    ORGANIZATION "IANA"
    CONTACT-INFO "Internet Assigned Numbers Authority

                  Postal: ICANN
                          12025 Waterfront Drive, Suite 300
                          Los Angeles, CA 90094-2536
                          United States

                  Tel:    +1 310 301 5800
                  E-Mail: iana&iana.org"
    DESCRIPTION  "This MIB module defines the
                  IANAsmfOpModeIdTC and IANAsmfRssaIdTC
                  Textual Conventions, and thus the
                  enumerated values of the
                  smfCapabilitiesOpModeID and
                  smfCapabilitiesRssaID objects defined
                  in the SMF-MIB."
    REVISION     "201408140000Z"  -- August 14, 2014
    DESCRIPTION  "Initial version of this MIB as published in
                  RFC7367."
    ::= { mib-2 225 }


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)
    }


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.

           Essential 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 - Macker, J., `Simplified Multicast
        Forwarding (SMF)', May 2012.

        RFC 3626 - Clausen, T., and P. Jacquet, `Optimized Link
        State Routing Protocol (OLSR)', October 2003.

        RFC 5614 - Ogier, R. and P. Spagnolo, `Mobile Ad Hoc
        Network (MANET) Extension of OSPF Using Connected
        Dominating Set (CDS) Flooding', August 2009.
        "
    SYNTAX      INTEGER {
                        cF(1),
                        sMPR(2),
                        eCDS(3),
                        mprCDS(4)
                        -- future(5-127)
                        -- noStdAction(128-239)
                        -- experimental(240-255)
                }

END                                    