tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 4836

 Errata 
Proposed STD
Pages: 67
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: HUBMIB

Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)

Part 1 of 3, p. 1 to 10
None       Next RFC Part

Obsoletes:    3636


Top       ToC       Page 1 
Network Working Group                                           E. Beili
Request for Comments: 4836                              Actelis Networks
Obsoletes: 3636                                               April 2007
Category: Standards Track


                   Definitions of Managed Objects for
               IEEE 802.3 Medium Attachment Units (MAUs)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document defines a portion of the Management Information Base
   (MIB) for use with network management protocols in the Internet
   community.  In particular, it defines objects for managing IEEE 802.3
   Medium Attachment Units (MAUs).  This document obsoletes RFC 3636.
   It amends that specification by moving MAU type OBJECT-IDENTITY
   definitions and relevant textual conventions into a separate Internet
   Assigned Number Authority (IANA) maintained MIB module.  In addition,
   management information is added to enable support for Ethernet in the
   First Mile (EFM) and 10GBASE-CX4 MAUs.

Top       Page 2 
Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The Internet-Standard Management Framework . . . . . . . . . .  3
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Relationship to RFC 3636 . . . . . . . . . . . . . . . . .  4
     3.2.  Relationship to Other MIBs . . . . . . . . . . . . . . . .  5
       3.2.1.  Relationship to the Interfaces MIB . . . . . . . . . .  5
       3.2.2.  Relationship to the 802.3 Repeater MIB Module  . . . .  6
     3.3.  Management of Internal MAUs  . . . . . . . . . . . . . . .  6
     3.4.  Mapping of IEEE 802.3 Managed Objects  . . . . . . . . . .  6
     3.5.  Addition of New MAU Types  . . . . . . . . . . . . . . . .  9
       3.5.1.  dot3MauType OBJECT-IDENTITIES  . . . . . . . . . . . .  9
       3.5.2.  IANAifMauTypeListBits TEXTUAL-CONVENTION . . . . . . .  9
       3.5.3.  IANAifMauMediaAvailable TEXTUAL-CONVENTION . . . . . .  9
       3.5.4.  IANAifMauAutoNegCapBits TEXTUAL-CONVENTION . . . . . . 10
       3.5.5.  JackType TEXTUAL-CONVENTION  . . . . . . . . . . . . . 10
   4.  MAU MIB Definitions  . . . . . . . . . . . . . . . . . . . . . 10
   5.  IANA-Maintained MAU TC Definitions . . . . . . . . . . . . . . 46
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 62
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 63
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 63
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 64
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 66

Top      ToC       Page 3 
1.  Introduction

   This document defines a portion of the Management Information Base
   (MIB) for use with network management protocols in the Internet
   community.  In particular, it defines objects for managing IEEE 802.3
   [IEEE802.3] Medium Attachment Units (MAUs).

   The previous version of this document, RFC 3636 [RFC3636], defined a
   single MIB module.  This document splits the original MIB module into
   two, putting frequently updated object identities and textual
   conventions into a separate, IANA-maintained MIB module, in order to
   decrease the need of updating the basic MAU MIB module.

   The first version of the IANA-maintained MIB module also extends the
   list of managed objects to support Ethernet in the First Mile (EFM)
   and 10GBASE-CX4 interfaces.

   Ethernet technology, as defined by the 802.3 Working Group of the
   IEEE, continues to evolve, with scalable increases in speed, new
   types of cabling and interfaces, and new features.  This evolution
   may require changes in the managed objects in order to reflect this
   new functionality.  This document, as with other documents issued by
   this working group, reflects a certain stage in the evolution of
   Ethernet technology.  In the future, this document might be revised,
   or new documents might be issued by the Ethernet Interfaces and Hub
   MIB Working Group, in order to reflect the evolution of Ethernet
   technology.

2.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [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,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Top      ToC       Page 4 
3.  Overview

   Instances of these object types represent attributes of an IEEE 802.3
   MAU.  Several types of MAUs are defined in the IEEE 802.3 CSMA/CD
   standard [IEEE802.3].  These MAUs may be connected to IEEE 802.3
   repeaters or to 802.3 (Ethernet-like) interfaces.  For convenience,
   this document refers to these devices as "repeater MAUs" and
   "interface MAUs."

   The definitions presented here are based on Section 30.5, "Layer
   Management for 10 Mb/s, 100 Mb/s, 1000 Mb/s, and 10 Gb/s Medium
   Attachment Units (MAUs)", Section 30.6, "Management for link Auto-
   Negotiation", and Annex 30A, "GDMO Specifications for 802.3 managed
   object classes" of IEEE Std. 802.3-2005 [IEEE802.3].  This
   specification is intended to provide for management of all types of
   Ethernet/802.3 MAUs.

3.1.  Relationship to RFC 3636

   The management definitions provided in this document are intended to
   be a superset of those defined by RFC 3636 [RFC3636].

   In order to decrease the need of updating the basic MAU MIB module
   due to the new MAU type, Media Available state, Auto Negotiation
   capability and/or Jack type introduction, all relevant object
   identities and textual conventions have been moved to a separate,
   IANA-maintained MIB module IANA-MAU-MIB, the first version of which
   is defined in this document.  Thus when a new MAU type, Media
   Available state, Auto Negotiation capability, and/or Jack type is
   defined by the IEEE 802.3 working group, only the IANA-maintained
   module needs to be revised, leaving the basic MAU-MIB module defined
   in this document unchanged.

   In addition, the new definitions are added to the IANA-maintained MIB
   module, to support Ethernet in the First Mile (EFM) and 10GBASE-CX4
   interfaces, defined in IEEE Std 802.3ah-2004 [IEEE802.3ah] and IEEE
   Std 802.3ak-2004 [IEEE802.3ak] respectively, now part of IEEE Std
   802.3-2005 [IEEE802.3].

   It should be noted that the changes made in this revision will not be
   entirely backward-compatible with MIB modules that currently import
   MAU type object identity descriptors from the MAU-MIB; such modules
   will need to be revised to import those DESCRIPTORS from the IANA-
   MAU-MIB.  Similarly, any management applications that process the
   object identity definitions (e.g., to present the DESCRIPTION text to
   a user) will need to get those definitions from the IANA-MAU-MIB
   instead of the MAU-MIB.  While it is true that changes that require
   such adjustments are not strictly compliant with the SMIv2 rules

Top      ToC       Page 5 
   governing MIB module revisions (see [RFC2578] Section 10), in this
   case continued high maintenance costs that would result from not
   making these changes make the deviation from the rules justified.  It
   should be noted that the working group was not able to find any
   examples of MIB modules or management applications that would
   actually be negatively affected by the changes.

3.2.  Relationship to Other MIBs

   It is assumed that an agent implementing MAU-MIB will also implement
   (at least) the 'system' group defined in the SNMPv2 MIB [RFC3418].
   The following sections identify other MIBs that such an agent should
   implement.

3.2.1.  Relationship to the Interfaces MIB

   The sections of this document that define interface MAU-related
   objects specify an extension to the Interfaces MIB [RFC2863].  An
   agent implementing these interface-MAU related objects MUST also
   implement the relevant groups of the ifCompliance3 MODULE-COMPLIANCE
   statement of the Interface MIB.  The value of the object ifMauIfIndex
   is the same as the value of 'ifIndex' used to instantiate the
   interface to which the given MAU is connected.

   It is REQUIRED that an agent implementing the interface-MAU related
   objects in the MAU-MIB will also fully comply with the
   dot3Compliance2 MODULE-COMPLIANCE statement of the Ethernet-like
   Interfaces MIB, [RFC3635].  Furthermore, when the interface-MAU
   related objects are used to manage a 10GBASE-W PHY -- i.e., when
   ifMauType is equal to dot3MauType10GigBaseW or any other 10GBASE-W
   variant -- then the agent MUST also support the Ethernet WAN
   Interface Sublayer (WIS) MIB [RFC3637] and must follow the interface
   layering model specified therein.  In that case the value of the
   object ifMauIfIndex is the same as the value of 'ifIndex' for the
   layer at the top of the stack, i.e., for the ifTable entry that has
   'ifType' equal to ethernetCsmacd(6).  If the interface-MAU related
   objects are used to manage a PHY that allows the MAU type to be
   changed dynamically, then the agent SHALL create ifTable,
   ifStackTable, and ifInvStackTable entries that pertain to the WIS
   when ifMauDefaultType is changed to a 10GBASEW variant (i.e., one of
   dot3MauType10GigBaseW, dot3MauType10GigBaseEW,
   dot3MauType10GigBaseLW, or dot3MauType10GigBaseSW) from any other
   type, and shall destroy the WIS-related entries when ifMauDefaultType
   is changed to a non- 10GBASE-W type.  The agent SHALL also change the
   values of 'ifConnectorPresent' and 'ifHighSpeed' in the ifTable entry
   indexed by ifMauIfIndex as specified in [RFC3635] and [RFC3637] when
   ifMauDefaultType is manipulated in this way, but SHALL NOT otherwise
   alter that entry.

Top      ToC       Page 6 
   (Note that repeater ports are not represented as interfaces in the
   Interface MIB.)

3.2.2.  Relationship to the 802.3 Repeater MIB Module

   The section of this document that defines repeater MAU-related
   objects specifies an extension to the 802.3 Repeater MIB defined in
   [RFC2108].  An agent implementing these repeater-MAU related objects
   MUST also comply with the snmpRptrModCompl compliance statement of
   the 802.3 Repeater MIB module.

   The values of 'rpMauGroupIndex' and 'rpMauPortIndex' used to
   instantiate a repeater MAU variable SHALL be the same as the values
   of 'rptrPortGroupIndex' and 'rptrPortIndex' used to instantiate the
   port that the given MAU is connected to.

3.3.  Management of Internal MAUs

   In some situations, a MAU can be "internal" -- i.e., its
   functionality is implemented entirely within a device.  For example,
   a managed repeater may contain an internal repeater-MAU and/or an
   internal interface-MAU through which management communications
   originating on one of the repeater's external ports pass, in order to
   reach the management agent associated with the repeater.  Such
   internal MAUs may or may not be managed.  If they are managed,
   objects describing their attributes should appear in the appropriate
   MIB subtree: dot3RpMauBasicGroup for internal repeater-MAUs and
   dot3IfMauBasicGroup for internal interface-MAUs.

3.4.  Mapping of IEEE 802.3 Managed Objects

   This section contains the mapping between relevant managed objects
   (attributes) defined in [IEEE802.3] Clause 30, and managed objects
   defined in this document.

Top      ToC       Page 7 
   +----------------------------------+--------------------------------+
   | IEEE 802.3 Managed Object        | Corresponding SNMP Object      |
   +----------------------------------+--------------------------------+
   | oMAU                             |                                |
   +----------------------------------+--------------------------------+
   | .aMAUID                          | rpMauIndex or ifMauIndex or    |
   |                                  | broadMauIndex                  |
   +----------------------------------+--------------------------------+
   | .aMAUType                        | rpMauType or ifMauType         |
   +----------------------------------+--------------------------------+
   | .aMAUTypeList                    | ifMauTypeListBits              |
   +----------------------------------+--------------------------------+
   | .aMediaAvailable                 | rpMauMediaAvailable or         |
   |                                  | ifMauMediaAvailable            |
   +----------------------------------+--------------------------------+
   | .aLoseMediaCounter               | rpMauMediaAvailableStateExits  |
   |                                  | or                             |
   |                                  | ifMauMediaAvailableStateExits  |
   +----------------------------------+--------------------------------+
   | .aJabber                         | rpMauJabberState and           |
   |                                  | rpMauJabberingStateEnters or   |
   |                                  | ifMauJabberState and           |
   |                                  | ifMauJabberingStateEnters      |
   +----------------------------------+--------------------------------+
   | .aMAUAdminState                  | rpMauStatus or ifMauStatus     |
   +----------------------------------+--------------------------------+
   | .aBbMAUXmitRcvSplitType          | broadMauXmtRcvSplitType        |
   +----------------------------------+--------------------------------+
   | .aBroadbandFrequencies           | broadMauXmtCarrierFreq and     |
   |                                  | broadMauTranslationFreq        |
   +----------------------------------+--------------------------------+
   | .aFalseCarriers                  | rpMauFalseCarriers or          |
   |                                  | ifMauFalseCarriers             |
   +----------------------------------+--------------------------------+
   | .acResetMAU                      | rpMauStatus or ifMauStatus     |
   +----------------------------------+--------------------------------+
   | .acMAUAdminControl               | rpMauStatus or ifMauStatus     |
   +----------------------------------+--------------------------------+
   | .nJabber                         | rpMauJabberTrap or             |
   |                                  | ifMauJabberTrap                |
   +----------------------------------+--------------------------------+
   | oAutoNegotiation                 |                                |
   +----------------------------------+--------------------------------+
   | .aAutoNegID                      | ifMauIndex                     |
   +----------------------------------+--------------------------------+
   | .aAutoNegAdminState              | ifMauAutoNegAdminStatus        |
   +----------------------------------+--------------------------------+
   | .aAutoNegRemoteSignalling        | ifMauAutoNegRemoteSignalling   |

Top      ToC       Page 8 
   | .aAutoNegAutoConfig              | ifMauAutoNegConfig             |
   +----------------------------------+--------------------------------+
   | .aAutoNegLocalTechnologyAbility  | ifMauAutoNegCapabilityBits     |
   +----------------------------------+--------------------------------+
   | .aAutoNegAdvertisedTechnologyAbi | ifMauAutoNegAdvertisedBits and |
   | lity                             | ifMauAutoNegRemoteFaultAdverti |
   |                                  | sed                            |
   +----------------------------------+--------------------------------+
   | .aAutoNegReceivedTechnologyAbili | ifMauAutoNegReceivedBits and   |
   | ty                               | ifMauAutoNegRemoteFaultReceive |
   |                                  | d                              |
   +----------------------------------+--------------------------------+
   | .acAutoNegRestartAutoConfig      | ifMauAutoNegRestart            |
   +----------------------------------+--------------------------------+
   | .acAutoNegAdminControl           | ifMauAutoNegAdminStatus        |
   +----------------------------------+--------------------------------+

              Table 1: Mapping of IEEE 802.3 Managed Objects

   The following IEEE 802.3 managed objects have not been included in
   the MAU-MIB for the following reasons.

   +------------------------------------+------------------------------+
   | IEEE 802.3 Managed Object          | Reason for exclusion         |
   +------------------------------------+------------------------------+
   | oMAU                               |                              |
   +------------------------------------+------------------------------+
   | .aIdleErrorCount                   | Only useful for 100BaseT2,   |
   |                                    | which is not widely          |
   |                                    | implemented.                 |
   +------------------------------------+------------------------------+
   | oAutoNegotiation                   |                              |
   +------------------------------------+------------------------------+
   | .aAutoNegLocalSelectorAbility      | Only needed for support of   |
   |                                    | isoethernet (802.9a), which  |
   |                                    | is not supported by MAU-MIB. |
   +------------------------------------+------------------------------+
   | .aAutoNegAdvertisedSelectorAbility |                              |
   +------------------------------------+------------------------------+
   | .aAutoNegReceivedSelectorAbility   |                              |
   +------------------------------------+------------------------------+

               Table 2: Unmapped IEEE 802.3 Managed Objects

Top      ToC       Page 9 
3.5.  Addition of New MAU Types

3.5.1.  dot3MauType OBJECT-IDENTITIES

   The dot3MauType OBJECT IDENTIFIER and its OBJECT-IDENTITY definitions
   has been moved from the MAU-MIB into the IANA-maintained IANA-MAU-
   MIB, the first version of which is defined in this document.

   When a new IEEE 802.3 MAU is defined, IANA can re-issue a version of
   IANA-MAU-MIB with the new dot3MauType OBJECT-IDENTITY and its
   matching IANAifMauTypeListBits textual convention value and,
   possibly, with new IANAifMauMediaAvailable, IANAifMauAutoNegCapBits,
   and/or IANAifJackType values.

   An Expert Review, as defined in RFC 2434 [RFC2434], is REQUIRED for
   the addition of the new MAU, Media Available states, Auto Negotiation
   capabilities, and/or Jack types.

   In some cases, new MAU types may require additional managed objects
   or may have side effects on the behavior of existing managed objects.
   In such cases a standards-track specification (which may be a new
   document or a revision of this document) is also REQUIRED.  Any such
   document is REQUIRED to note any special properties of the MAU types
   that it defines - for example, side effects on the ifStackTable as
   noted in this document for 10GBASE-W MAUs.

3.5.2.  IANAifMauTypeListBits TEXTUAL-CONVENTION

   The syntax of ifMauTypeListBits is changed to be a textual
   convention, such that the enumerated integer values are now defined
   in the textual convention IANAifMauTypeListBits, which can be re-
   specified (with additional values, when defined by IEEE 802.3) in the
   IANA-maintained MIB module without issuing a new version of this
   document.

3.5.3.  IANAifMauMediaAvailable TEXTUAL-CONVENTION

   The syntax of ifMauMediaAvailable and rpMauMediaAvailable is changed
   to be a textual convention, such that the enumerated integer values
   are now defined in the textual convention IANAifMauMediaAvailable,
   which can be re-specified (with additional values, when defined by
   IEEE 802.3) in the IANA-maintained MIB module without issuing a new
   version of this document.

Top      ToC       Page 10 
3.5.4.  IANAifMauAutoNegCapBits TEXTUAL-CONVENTION

   The syntax of ifMauAutoNegCapabilityBits,
   ifMauAutoNegCapAdvertisedBits, and ifMauAutoNegCapReceivedBits
   objects is changed to be a textual convention, such that the
   enumerated integer values are now defined in the textual convention
   IANAifMauAutoNegCapBits, which can be re-specified (with additional
   values, when defined by IEEE 802.3) in the IANA-maintained MIB module
   without issuing a new version of this document.

3.5.5.  JackType TEXTUAL-CONVENTION

   The JackType Textual Convention has been deprecated in favor of the
   IANAifJackType defined in the IANA-maintained MIB module, so the new
   Jack types can be added (when defined by IEEE 802.3) without issuing
   a new version of this document.



(page 10 continued on part 2)

Next RFC Part