--- 1/draft-ietf-hubmib-rfc3636bis-03.txt 2006-06-28 22:12:35.000000000 +0200 +++ 2/draft-ietf-hubmib-rfc3636bis-04.txt 2006-06-28 22:12:35.000000000 +0200 @@ -1,18 +1,20 @@ Network Working Group E. Beili Internet-Draft Actelis Networks -Expires: December 9, 2006 June 07, 2006 +Obsoletes: 3636, 2668, 1515 (if June 25, 2006 +approved) +Expires: December 27, 2006 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) - draft-ietf-hubmib-rfc3636bis-03.txt + draft-ietf-hubmib-rfc3636bis-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -23,21 +25,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on December 9, 2006. + This Internet-Draft will expire on December 27, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo 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 @@ -47,57 +49,54 @@ 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. 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 RFC 2668 . . . . . . . . . . . . . . . . . 5 - 3.3. Relationship to RFC 2239 . . . . . . . . . . . . . . . . . 5 - 3.4. Relationship to RFC 1515 . . . . . . . . . . . . . . . . . 5 - 3.5. Relationship to other MIBs . . . . . . . . . . . . . . . . 5 - 3.5.1. Relationship to the Interfaces MIB . . . . . . . . . . 6 - 3.5.2. Relationship to the 802.3 Repeater MIB module . . . . 6 - 3.6. Management of Internal MAUs . . . . . . . . . . . . . . . 7 - 3.7. Management of IEEE 802.3 Managed Objects . . . . . . . . . 7 - 3.8. Addition of new MAU Types . . . . . . . . . . . . . . . . 8 - 3.8.1. dot3MauType OBJECT-IDENTITIES . . . . . . . . . . . . 8 - 3.8.2. IANAifMauTypeListBits Textual Convention . . . . . . . 9 - 3.8.3. IANAifMauMediaAvailable Textual Convention . . . . . . 9 - 3.8.4. IANAifMauAutoNegCapBits Textual Convention . . . . . . 9 - 3.8.5. JackType Textual Convention . . . . . . . . . . . . . 9 - 4. MAU MIB Definitions . . . . . . . . . . . . . . . . . . . . . 10 + 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. Management of IEEE 802.3 Managed Objects . . . . . . . . . 7 + 3.5. Addition of new MAU Types . . . . . . . . . . . . . . . . 8 + 3.5.1. dot3MauType OBJECT-IDENTITIES . . . . . . . . . . . . 8 + 3.5.2. IANAifMauTypeListBits Textual Convention . . . . . . . 8 + 3.5.3. IANAifMauMediaAvailable Textual Convention . . . . . . 9 + 3.5.4. IANAifMauAutoNegCapBits Textual Convention . . . . . . 9 + 3.5.5. JackType Textual Convention . . . . . . . . . . . . . 9 + 4. MAU MIB Definitions . . . . . . . . . . . . . . . . . . . . . 9 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 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 67 Intellectual Property and Copyright Statements . . . . . . . . . . 68 1. Introduction This memo 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). The previous version of this memo, RFC 3636 [RFC3636], defined a single MIB module. This memo 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 re-issues of the basic MIB module. + 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 @@ -132,168 +131,134 @@ 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, 2002 edition [IEEE802.3], as - amended by IEEE Std. 802.3ae-2002 [IEEE802.3ae], IEEE Std. 802.3ah- - 2004 [IEEE802.3ah] and IEEE Std. 802.3ak-2004 [IEEE802.3ak]. This + 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 memo are intended to be a superset of those defined by RFC 3636 [RFC3636]. - In order to decrease re-issues of this document 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 memo. - 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 memo unchanged. + 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 memo. 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 memo + 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. + 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 be 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 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 RFC 2668 - - RFC 3636 was a replacement for RFC 2668 [RFC2668]. RFC 3636 included - all of the objects contained in RFC 2668, plus new and updated - definitions to provide management support for 10 Gb/s devices. - -3.3. Relationship to RFC 2239 - - RFC 2668 was a replacement for RFC 2239 [RFC2239]. RFC 2668 defined - a superset of that defined by RFC 2239, which contained all of the - objects defined in RFC 2239, plus several new ones which provide - additional capabilities. The new objects provided management support - for: - - o management of 1000 Mb/s devices - - o management of PAUSE negotiation - - o management of remote fault status - -3.4. Relationship to RFC 1515 - - RFC 2239 was a replacement for RFC 1515 [RFC1515]. RFC 2239 defined - a superset of RFC 1515 which contained all of the objects defined in - RFC 1515, plus several new ones which provided additional - capabilities. The new objects in RFC 2239 provided management - support for: - - o management of 100 Mb/s devices - - o auto-negotiation on interface MAUs - - o jack management - -3.5. Relationship to other MIBs +3.2. Relationship to other MIBs - It is assumed that an agent implementing this MIB will also implement + 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.5.1. Relationship to the Interfaces MIB +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 this 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 + 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. (Note that repeater ports are not represented as interfaces in the Interface MIB.) -3.5.2. Relationship to the 802.3 Repeater MIB module +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 to which the given MAU is connected. -3.6. Management of Internal MAUs +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.7. Management of IEEE 802.3 Managed Objects +3.4. Management of IEEE 802.3 Managed Objects +----------------------------------+--------------------------------+ | IEEE 802.3 Managed Object | Corresponding SNMP Object | +----------------------------------+--------------------------------+ | oMAU | | | .aMAUID | rpMauIndex or ifMauIndex or | | | broadMauIndex | | .aMAUType | rpMauType or ifMauType | | .aMAUTypeList | ifMauTypeListBits | | .aMediaAvailable | rpMauMediaAvailable or | @@ -327,43 +292,42 @@ | .aAutoNegReceivedTechnologyAbili | ifMauAutoNegReceivedBits and | | ty | ifMauAutoNegRemoteFaultReceive | | | d | | .acAutoNegRestartAutoConfig | ifMauAutoNegRestart | | .acAutoNegAdminControl | ifMauAutoNegAdminStatus | +----------------------------------+--------------------------------+ Table 1 The following IEEE 802.3 managed objects have not been included in - this MIB for the following reasons. + the MAU-MIB for the following reasons. +------------------------------------+------------------------------+ | IEEE 802.3 Managed Object | Corresponding SNMP Object | +------------------------------------+------------------------------+ | 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 this | - | | MIB. | + | | is not supported by MAU-MIB. | | .aAutoNegAdvertisedSelectorAbility | | | .aAutoNegReceivedSelectorAbility | | +------------------------------------+------------------------------+ Table 2 -3.8. Addition of new MAU Types +3.5. Addition of new MAU Types -3.8.1. dot3MauType OBJECT-IDENTITIES +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, first version of which is defined in this memo. 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. @@ -373,49 +337,49 @@ 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.8.2. IANAifMauTypeListBits Textual Convention +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.8.3. IANAifMauMediaAvailable Textual Convention +3.5.3. IANAifMauMediaAvailable Textual Convention The syntax of ifMauMediaAvailable and rpMauMediaAvailable is changed 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. -3.8.4. IANAifMauAutoNegCapBits Textual Convention +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.8.5. JackType Textual Convention +3.5.5. JackType Textual Convention The JackType Textual Convention has been deprecated in favor of 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. 4. MAU MIB Definitions MAU-MIB DEFINITIONS ::= BEGIN @@ -430,21 +394,21 @@ InterfaceIndex FROM IF-MIB -- RFC 2863 IANAifMauTypeListBits, IANAifMauMediaAvailable, IANAifMauAutoNegCapBits, IANAifJackType FROM IANA-MAU-MIB -- RFC 3636bis -- EdNote: Replace RFC 3636bis above with the URL of the -- actual IANA-maintained module & remove this note. ; mauMod MODULE-IDENTITY - LAST-UPDATED "200606070000Z" -- June 07, 2006 + LAST-UPDATED "200606250000Z" -- June 25, 2006 ORGANIZATION "IETF Ethernet Interfaces and Hub MIB Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/hubmib-charter.html Mailing Lists: General Discussion: hubmib@ietf.org To Subscribe: hubmib-request@ietf.org In Body: subscribe your_email_address @@ -463,44 +427,37 @@ Israel Tel: +972-3-924-3491 E-mail: edward.beili@actelis.com" DESCRIPTION "Management information for 802.3 MAUs. The following reference is used throughout this MIB module: [IEEE 802.3 Std] refers to: - IEEE Std 802.3, 2002 Edition: 'IEEE Standard - for Information technology - - Telecommunications and information exchange - between systems - Local and metropolitan - area networks - Specific requirements - - Part 3: Carrier sense multiple access with - collision detection (CSMA/CD) access method - and physical layer specifications', as - amended by IEEE Std 802.3ae-2002: - 'Amendment: Media Access Control (MAC) - Parameters, Physical Layer, and Management - Parameters for 10 Gb/s Operation', August, - 2002. + IEEE Std 802.3, 2005 Edition: 'IEEE Standard for Information + technology - Telecommunications and information exchange + between systems - Local and metropolitan area networks - + Specific requirements - Part 3: Carrier sense multiple + access with collision detection (CSMA/CD) access method and + physical layer specifications'. - Of particular interest is Clause 30, '10Mb/s, - 100Mb/s, 1000Mb/s and 10 Gb/s Management'. + Of particular interest is Clause 30, 'Management'. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." - REVISION "200606070000Z" -- June 07, 2006 + REVISION "200606250000Z" -- June 25, 2006 DESCRIPTION "Updated to reference IANA maintaned textual - conventions for MAU types and jack types, + conventions for MAU types, Media Availability state, + Auto Negotiation capabilities and jack types, instead of using internally defined values. This version is published as RFC XXXX." -- EdNote: Replace XXXX with the actual RFC number -- & remove this note. REVISION "200309190000Z" -- September 19, 2003 DESCRIPTION "Updated to include support for 10 Gb/s MAUs. This resulted in the following revisions: - Added OBJECT-IDENTITY definitions for @@ -633,33 +589,34 @@ Note: In practice, a group will generally be a field-replaceable unit (i.e., module, card, or board) that can fit in the physical system enclosure, and the group number will correspond to a number marked on the physical enclosure. The group denoted by a particular value of this object is the same as the group denoted by the same value of rptrGroupIndex." - REFERENCE "Reference RFC 2108, rptrGroupIndex." + REFERENCE "RFC 2108, rptrGroupIndex." ::= { rpMauEntry 1 } rpMauPortIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "This variable uniquely identifies the repeater port within group rpMauGroupIndex to which the MAU described by this entry is connected." - REFERENCE "Reference RFC 2108, rptrPortIndex." + REFERENCE "RFC 2108, rptrPortIndex." ::= { rpMauEntry 2 } + rpMauIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS current DESCRIPTION "This variable uniquely identifies the MAU described by this entry from among other MAUs connected to the same port (rpMauPortIndex)." REFERENCE "[IEEE 802.3 Std], 30.5.1.1.1, aMAUID." @@ -1697,21 +1654,21 @@ broadMauIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** This variable uniquely identifies the interface to which the MAU described by this entry is connected." - REFERENCE "Reference RFC 2863, ifIndex." + REFERENCE "RFC 2863, ifIndex." ::= { broadMauBasicEntry 1 } broadMauIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only -- read-only since originally an -- SMIv1 index STATUS deprecated DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** This variable uniquely identifies the MAU @@ -1776,35 +1734,35 @@ rpMauJabberTrap NOTIFICATION-TYPE OBJECTS { rpMauJabberState } STATUS current DESCRIPTION "This trap is sent whenever a managed repeater MAU enters the jabber state. The agent MUST throttle the generation of consecutive rpMauJabberTraps so that there is at least a five-second gap between them." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.3.1, nJabber + REFERENCE "[IEEE 802.3 Std], 30.5.1.3.1, nJabber notification." ::= { snmpDot3MauTraps 1 } ifMauJabberTrap NOTIFICATION-TYPE OBJECTS { ifMauJabberState } STATUS current DESCRIPTION "This trap is sent whenever a managed interface MAU enters the jabber state. The agent MUST throttle the generation of consecutive ifMauJabberTraps so that there is at least a five-second gap between them." - REFERENCE "[IEEE 802.3 Mgt], 30.5.1.3.1, nJabber + REFERENCE "[IEEE 802.3 Std], 30.5.1.3.1, nJabber notification." ::= { snmpDot3MauTraps 2 } -- Conformance information mauModConf OBJECT IDENTIFIER ::= { mauMod 1 } mauModCompls OBJECT IDENTIFIER ::= { mauModConf 1 } mauModObjGrps @@ -2176,22 +2132,23 @@ 5. IANA-maintained MAU TC Definitions IANA-MAU-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC ; + ianaMauMIB MODULE-IDENTITY - LAST-UPDATED "200606070000Z" -- Jun 07, 2006 + LAST-UPDATED "200606250000Z" -- Jun 25, 2006 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" @@ -2209,50 +2166,39 @@ state, Auto Negotiation capability and/or Jack type defined by the IEEE 802.3 working group and approved for publication in a revision of IEEE Std 802.3 will be added to this MIB module, provided that it is suitable for being managed by the base objects in the MAU-MIB. An Expert Review, as defined in RFC 2434 [RFC2434], is REQUIRED for such additions. The following reference is used throughout this MIB module: [IEEE 802.3 Std] refers to: - IEEE Std 802.3, 2002 Edition: 'IEEE Standard for + IEEE Std 802.3, 2005 Edition: 'IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer - specifications', as amended by the following specifications: - IEEE Std 802.3ae-2002: - 'Amendment: Media Access Control (MAC) Parameters, - Physical Layer, and Management Parameters for 10 Gb/s - Operation', August 2002; - IEEE Std 802.3ak-2004: - 'Amendment: Media Access Control (MAC) Parameters, - Physical Layer, and Management Parameters for 10 Gb/s - Operation, Type 10GBASE-CX4', March 2004; - IEEE Std 802.3ah-2004: - 'Amendment: Media Access Control Parameters, Physical - Layers and Management Parameters for Subscriber Access - Networks', September 2004;. + specifications'. This reference should be updated as appropriate when new - MAU types and/or Jack types are added to this MIB module. + MAU types, Media Availability states, Auto Negotiation + capabilities and/or Jack types are added to this MIB module. Copyright (C) The Internet Society (2006). The initial version of this MIB module was published in RFC XXXX; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html" - REVISION "200606070000Z" -- Jun 07, 2006 + REVISION "200606250000Z" -- Jun 25, 2006 DESCRIPTION "Initial version of this MIB as published in RFC XXX." -- EdNote: Replace XXXX with the actual RFC number & remove this note ::= { mib-2 snmpDot3MauMgt(26) 7 } -- mauMod+1 -- Textual Conventions IANAifMauTypeListBits ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION @@ -2322,20 +2268,22 @@ b100BaseBX10U(45), -- 100BASE-BX10U b100BaseLX10(46), -- 100BASE-LX10 b1000BaseBX10D(47), -- 1000BASE-BX10D b1000BaseBX10U(48), -- 1000BASE-BX10U b1000BaseLX10(49), -- 1000BASE-LX10 b1000BasePX10D(50), -- 1000BASE-PX10D b1000BasePX10U(51), -- 1000BASE-PX10U b1000BasePX20D(52), -- 1000BASE-PX20D b1000BasePX20U(53) -- 1000BASE-PX20U } + REFERENCE + "[IEEE 802.3 Std], Section 30.5.1.1.2" IANAifMauMediaAvailable ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax of the ifMauMediaAvailable and rpMauMediaAvailable objects in the (updated) definition of MAU-MIB's ifMauTable and rpMauTable respectively. Possible values are: @@ -2354,33 +2302,36 @@ the other end of the link, 10BASE-FB only remoteJabber(7) - remote fault, due to jabber remoteLinkLoss(8) - remote fault, due to link loss remoteTest(9) - remote fault, due to test offline(10) - offline, Clause 37 Auto-Negotiation only autoNegError(11) - Auto-Negotiation Error, Clause 37 Auto-Negotiation only pmdLinkFault(12) - PMA/PMD receive link fault. In case of - PAF, all PMA/PMDs in the aggregation - group have detected a link fault + PAF (2BASE-TL / 10PASS-TS PHYs), all + PMEs in the aggregation group have + detected a link fault wisFrameLoss(13) - WIS loss of frame, 10GBASE-W only wisSignalLoss(14) - WIS loss of signal, 10GBASE-W only pcsLinkFault(15) - PCS receive link fault excessiveBER(16) - PCS Bit Error Ratio monitor reporting excessive error ratio dxsLinkFault(17) - DTE XGXS receive link fault, XAUI only pxsLinkFault(18) - PHY XGXS receive link fault, XAUI only availableReduced(19) - link normal, reduced bandwidth, 2BASE-TL / 10PASS-TS only - ready(20) - at least one PME available, + ready(20) - at least one PME in the aggregation + group is detecting handshake tones, 2BASE-TL / 10PASS-TS only + If the MAU is a 10M b/s link or fiber type (FOIRL, 10BASE-T, 10BASE-F), then this is equivalent to the link test fail state/low light function. For an AUI, 10BASE2, 10BASE5, or 10BROAD36 MAU, this indicates whether or not loopback is detected on the DI circuit. The value of this attribute persists between packets for MAU types AUI, 10BASE5, 10BASE2, 10BROAD36, and 10BASEFP. At power-up or following a reset, the Media Available state will be unknown(2) for AUI, 10BASE5, 10BASE2, 10BROAD36, and 10BASE-FP MAUs. For these MAUs loopback will be tested on each @@ -2386,52 +2337,56 @@ 10BASE-FP MAUs. For these MAUs loopback will be tested on each transmission during which no collision is detected. If DI is receiving input when DO returns to IDL after a transmission and there has been no collision during the transmission, then loopback will be detected. The Media Available state will only change during noncollided transmissions for AUI, 10BASE2, 10BASE5, 10BROAD36, and 10BASE-FP MAUs. For 100BASE-T2, 100BASE-T4, 100BASE-TX, 100BASE-FX, 100BASE-LX10 and 100BASE-BX10 PHYs the enumerations match the - states within the link integrity state diagram. Any MAU that - implements management of Clause 28 Auto-Negotiation will map - remote fault indication to remoteFault(5). + states within the link integrity state diagram. + Any MAU that implements management of [IEEE 802.3 Std] Clause + 28 Auto-Negotiation, will map remote fault indication to + remoteFault(5). Any MAU that implements management of Clause 37 - Auto-Negotiation will map the received RF1 and RF2 bits as + Auto-Negotiation, will map the received RF1 and RF2 bits as follows: Offline maps to offline(10), Link_Failure maps to remoteFault(5) and Auto-Negotiation Error maps to autoNegError(11). The value remoteFault(5) applies to 10BASE-FB remote fault indication, the 100BASE-X far-end fault indication and nonspecified remote faults from a system running Clause 28 Auto-Negotiation. The value remoteJabber(7), remoteLink loss(8), or remoteTest(9) SHOULD be used instead of remoteFault() where the reason for remote fault is identified in the remote signaling protocol. Where a Clause 22 MII or Clause 35 GMII is present, a logic one in the remote fault bit maps to the value remoteFault(5), a logic zero in the link status bit maps to the enumeration notAvailable(4). The value notAvailable(4) takes precedence over remoteFault(5). For 2BASE-TL and 10PASS-TS PHYs, the value unknown(2) maps to - the condition where the PHY is initializing, the value - ready(20) maps to the condition where at least one PME is - available and is ready for handshake, the value available(3) - maps to the condition where, at the PCS, at least one PME is - operationally linked, the value notAvailable(4) maps to the - condition where the PCS is not operationally linked, the value - availableReduced(19) maps to the condition where a link fault - is detected at the receive direction by one or more PMEs in the - aggregation group and the enumeration pmdLinkFault(12) maps to - the condition where a link fault is detected at the receive - direction by all of the PMA/PMDs in the aggregation group. + the condition where the PHY (PCS with connected PMEs) is + initializing, the value ready(20) maps to the condition where + the interface is down and at least one PME in the aggregation + group is ready for handshake, the value available(3) maps to + the condition where all the PMEs in the aggregation group are + up, the value notAvailable(4) maps to the condition where all + the PMEs in the aggregation group are down and no handshake + tones are detected, the value availableReduced(19) maps to the + condition where the interface is up, a link fault is detected + at the receive direction by one or more PMEs in the + aggregation group, but at least one PME is up and the + enumeration pmdLinkFault(12) maps to the condition where a link + fault is detected at the receive direction by all of the PMEs + in the aggregation group. For 10 Gb/s the enumerations map to value of the link_fault variable within the Link Fault Signaling state diagram as follows: the value OK maps to the value available(3), the value Local Fault maps to the value notAvailable(4) and the value Remote Fault maps to the value remoteFault(). The value pmdLinkFault(12), wisFrameLoss(13), wisSignalLoss(14), pcsLinkFault(15), excessiveBER(16) or dxsLinkFault(17) SHOULD be used instead of the value notAvailable(4) where the reason for the Local Fault state can be identified through the use of the Clause 45 MDIO Interface. @@ -2439,21 +2394,21 @@ identified only the highest precedence error SHOULD be reported. This precedence in descending order is as follows: pxsLinkFault pmdLinkFault wisFrameLoss wisSignalLoss pcsLinkFault excessiveBER dxsLinkFault. Where a Clause 45 MDIO interface is present a logic zero in - the PMA/PMD Receive link status bit ([IEEE Std 802.3ah-2004] + the PMA/PMD Receive link status bit ([IEEE 802.3 Std] Section 45.2.1.2.2) maps to the value pmdLinkFault(12), a logic one in the LOF status bit (Section 45.2.2.10.4) maps to the value wisFrameLoss(13), a logic one in the LOS status bit (Section 45.2.2.10.5) maps to the value wisSignalLoss, a logic zero in the PCS Receive link status bit (Section 45.2.3.2.2) maps to the value pcsLinkFault(15), a logic one in the 10GBASE-R PCS Latched high BER status bit (Section 45.2.3.12.2) maps to the value excessiveBER, a logic zero in the DTE XS receive link status bit (Section 45.2.5.2.2) maps to the value dxsLinkFault(17) @@ -2481,20 +2436,22 @@ pmdLinkFault(12), wisFrameLoss(13), wisSignalLoss(14), pcsLinkFault(15), excessiveBER(16), dxsLinkFault(17), pxsLinkFault(18), availableReduced(19), ready(20) } + REFERENCE + "[IEEE 802.3 Std], Section 30.5.1.1.4" IANAifMauAutoNegCapBits ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax of the ifMauAutoNegCapabilityBits, ifMauAutoNegCapAdvertisedBits and ifMauAutoNegCapReceivedBits objects in the (updated) definition of MAU-MIB's ifMauAutoNegTable. The most recent version of this textual convention is @@ -2519,20 +2476,22 @@ -- links bFdxBPause(11), -- Asymmetric and Symmetric PAUSE for -- full-duplex links b1000baseX(12), -- 1000BASE-X, -LX, -SX, -CX half -- duplex mode b1000baseXFD(13), -- 1000BASE-X, -LX, -SX, -CX full -- duplex mode b1000baseT(14), -- 1000BASE-T half duplex mode b1000baseTFD(15) -- 1000BASE-T full duplex mode } + REFERENCE + "[IEEE 802.3 Std], Section 30.6.1.1.5" IANAifJackType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Common enumeration values for repeater and interface MAU jack types. This data type is used as the syntax of the ifJackType and rpJackType objects in the (updated) definition of MAU-MIB's ifJackTable and rpJackTable respectively. Possible values are: @@ -2580,423 +2539,438 @@ -- OBJECT IDENTITIES for MAU types -- (see rpMauType and ifMauType of MAU-MIB for usage) -- The following definitions has been moved from RFC 3636 and -- no longer appear in its revision. dot3MauType OBJECT IDENTIFIER ::= { mib-2 snmpDot3MauMgt(26) 4 } dot3MauTypeAUI OBJECT-IDENTITY STATUS current DESCRIPTION "no internal MAU, view from AUI" - REFERENCE "[IEEE 802.3 Std.], Section 7" + REFERENCE "[IEEE 802.3 Std], Section 7" ::= { dot3MauType 1 } dot3MauType10Base5 OBJECT-IDENTITY STATUS current DESCRIPTION "thick coax MAU" - REFERENCE "[IEEE 802.3 Std.], Section 7" + REFERENCE "[IEEE 802.3 Std], Section 7" ::= { dot3MauType 2 } dot3MauTypeFoirl OBJECT-IDENTITY STATUS current DESCRIPTION "FOIRL MAU" - REFERENCE "[IEEE 802.3 Std.], Section 9.9" + REFERENCE "[IEEE 802.3 Std], Section 9.9" ::= { dot3MauType 3 } dot3MauType10Base2 OBJECT-IDENTITY STATUS current DESCRIPTION "thin coax MAU" - REFERENCE "[IEEE 802.3 Std.], Section 10" + REFERENCE "[IEEE 802.3 Std], Section 10" ::= { dot3MauType 4 } dot3MauType10BaseT OBJECT-IDENTITY STATUS current DESCRIPTION "UTP MAU. Note that it is strongly recommended that agents return either dot3MauType10BaseTHD or dot3MauType10BaseTFD if the duplex mode is known. However, management applications should be prepared to receive this MAU type value from older agent implementations." - REFERENCE "[IEEE 802.3 Std.], Section 14" + REFERENCE "[IEEE 802.3 Std], Section 14" ::= { dot3MauType 5 } dot3MauType10BaseFP OBJECT-IDENTITY STATUS current DESCRIPTION "passive fiber MAU" - REFERENCE "[IEEE 802.3 Std.], Section 16" + REFERENCE "[IEEE 802.3 Std], Section 16" ::= { dot3MauType 6 } dot3MauType10BaseFB OBJECT-IDENTITY STATUS current DESCRIPTION "sync fiber MAU" - REFERENCE "[IEEE 802.3 Std.], Section 17" + REFERENCE "[IEEE 802.3 Std], Section 17" ::= { dot3MauType 7 } dot3MauType10BaseFL OBJECT-IDENTITY STATUS current DESCRIPTION "async fiber MAU. Note that it is strongly recommended that agents return either dot3MauType10BaseFLHD or dot3MauType10BaseFLFD if the duplex mode is known. However, management applications should be prepared to receive this MAU type value from older agent implementations." - REFERENCE "[IEEE 802.3 Std.], Section 18" + REFERENCE "[IEEE 802.3 Std], Section 18" ::= { dot3MauType 8 } dot3MauType10Broad36 OBJECT-IDENTITY STATUS current DESCRIPTION "broadband DTE MAU. Note that 10BROAD36 MAUs can be attached to interfaces but not to repeaters." - REFERENCE "[IEEE 802.3 Std.], Section 11" + REFERENCE "[IEEE 802.3 Std], Section 11" ::= { dot3MauType 9 } ------ new since RFC 1515: dot3MauType10BaseTHD OBJECT-IDENTITY STATUS current DESCRIPTION "UTP MAU, half duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 14" + REFERENCE "[IEEE 802.3 Std], Section 14" ::= { dot3MauType 10 } dot3MauType10BaseTFD OBJECT-IDENTITY STATUS current DESCRIPTION "UTP MAU, full duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 14" + REFERENCE "[IEEE 802.3 Std], Section 14" ::= { dot3MauType 11 } dot3MauType10BaseFLHD OBJECT-IDENTITY STATUS current DESCRIPTION "async fiber MAU, half duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 18" + REFERENCE "[IEEE 802.3 Std], Section 18" ::= { dot3MauType 12 } dot3MauType10BaseFLFD OBJECT-IDENTITY STATUS current DESCRIPTION "async fiber MAU, full duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 18" + REFERENCE "[IEEE 802.3 Std], Section 18" ::= { dot3MauType 13 } dot3MauType100BaseT4 OBJECT-IDENTITY STATUS current DESCRIPTION "4 pair category 3 UTP" - REFERENCE "[IEEE 802.3 Std.], Section 23" + REFERENCE "[IEEE 802.3 Std], Section 23" ::= { dot3MauType 14 } dot3MauType100BaseTXHD OBJECT-IDENTITY STATUS current DESCRIPTION "2 pair category 5 UTP, half duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 25" + REFERENCE "[IEEE 802.3 Std], Section 25" ::= { dot3MauType 15 } dot3MauType100BaseTXFD OBJECT-IDENTITY STATUS current DESCRIPTION "2 pair category 5 UTP, full duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 25" + REFERENCE "[IEEE 802.3 Std], Section 25" ::= { dot3MauType 16 } dot3MauType100BaseFXHD OBJECT-IDENTITY STATUS current DESCRIPTION "X fiber over PMT, half duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 26" + REFERENCE "[IEEE 802.3 Std], Section 26" ::= { dot3MauType 17 } dot3MauType100BaseFXFD OBJECT-IDENTITY STATUS current DESCRIPTION "X fiber over PMT, full duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 26" + REFERENCE "[IEEE 802.3 Std], Section 26" ::= { dot3MauType 18 } dot3MauType100BaseT2HD OBJECT-IDENTITY STATUS current DESCRIPTION "2 pair category 3 UTP, half duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 32" + REFERENCE "[IEEE 802.3 Std], Section 32" ::= { dot3MauType 19 } dot3MauType100BaseT2FD OBJECT-IDENTITY STATUS current DESCRIPTION "2 pair category 3 UTP, full duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 32" + REFERENCE "[IEEE 802.3 Std], Section 32" ::= { dot3MauType 20 } ------ new since RFC 2239: dot3MauType1000BaseXHD OBJECT-IDENTITY STATUS current DESCRIPTION "PCS/PMA, unknown PMD, half duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 36" + REFERENCE "[IEEE 802.3 Std], Section 36" ::= { dot3MauType 21 } dot3MauType1000BaseXFD OBJECT-IDENTITY STATUS current DESCRIPTION "PCS/PMA, unknown PMD, full duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 36" + REFERENCE "[IEEE 802.3 Std], Section 36" ::= { dot3MauType 22 } dot3MauType1000BaseLXHD OBJECT-IDENTITY STATUS current DESCRIPTION "Fiber over long-wavelength laser, half duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 38" + REFERENCE "[IEEE 802.3 Std], Section 38" ::= { dot3MauType 23 } dot3MauType1000BaseLXFD OBJECT-IDENTITY STATUS current DESCRIPTION "Fiber over long-wavelength laser, full duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 38" + REFERENCE "[IEEE 802.3 Std], Section 38" ::= { dot3MauType 24 } dot3MauType1000BaseSXHD OBJECT-IDENTITY STATUS current DESCRIPTION "Fiber over short-wavelength laser, half duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 38" + REFERENCE "[IEEE 802.3 Std], Section 38" ::= { dot3MauType 25 } dot3MauType1000BaseSXFD OBJECT-IDENTITY STATUS current DESCRIPTION "Fiber over short-wavelength laser, full duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 38" + REFERENCE "[IEEE 802.3 Std], Section 38" ::= { dot3MauType 26 } dot3MauType1000BaseCXHD OBJECT-IDENTITY STATUS current DESCRIPTION "Copper over 150-Ohm balanced cable, half duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 39" + REFERENCE "[IEEE 802.3 Std], Section 39" ::= { dot3MauType 27 } dot3MauType1000BaseCXFD OBJECT-IDENTITY STATUS current DESCRIPTION "Copper over 150-Ohm balanced cable, full duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 39" + REFERENCE "[IEEE 802.3 Std], Section 39" ::= { dot3MauType 28 } dot3MauType1000BaseTHD OBJECT-IDENTITY STATUS current DESCRIPTION "Four-pair Category 5 UTP, half duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 40" + REFERENCE "[IEEE 802.3 Std], Section 40" ::= { dot3MauType 29 } dot3MauType1000BaseTFD OBJECT-IDENTITY STATUS current DESCRIPTION "Four-pair Category 5 UTP, full duplex mode" - REFERENCE "[IEEE 802.3 Std.], Section 40" + REFERENCE "[IEEE 802.3 Std], Section 40" ::= { dot3MauType 30 } ------ new since RFC 2668: dot3MauType10GigBaseX OBJECT-IDENTITY STATUS current DESCRIPTION "X PCS/PMA, unknown PMD." - REFERENCE "[IEEE 802.3 Std.], Section 48" + REFERENCE "[IEEE 802.3 Std], Section 48" ::= { dot3MauType 31 } dot3MauType10GigBaseLX4 OBJECT-IDENTITY STATUS current DESCRIPTION "X fiber over WWDM optics" - REFERENCE "[IEEE 802.3 Std.], Section 53" + REFERENCE "[IEEE 802.3 Std], Section 53" ::= { dot3MauType 32 } dot3MauType10GigBaseR OBJECT-IDENTITY STATUS current DESCRIPTION "R PCS/PMA, unknown PMD." - REFERENCE "[IEEE 802.3 Std.], Section 49" + REFERENCE "[IEEE 802.3 Std], Section 49" ::= { dot3MauType 33 } dot3MauType10GigBaseER OBJECT-IDENTITY STATUS current DESCRIPTION "R fiber over 1550 nm optics" - REFERENCE "[IEEE 802.3 Std.], Section 52" + REFERENCE "[IEEE 802.3 Std], Section 52" ::= { dot3MauType 34 } dot3MauType10GigBaseLR OBJECT-IDENTITY STATUS current DESCRIPTION "R fiber over 1310 nm optics" - REFERENCE "[IEEE 802.3 Std.], Section 52" + REFERENCE "[IEEE 802.3 Std], Section 52" ::= { dot3MauType 35 } dot3MauType10GigBaseSR OBJECT-IDENTITY STATUS current DESCRIPTION "R fiber over 850 nm optics" - REFERENCE "[IEEE 802.3 Std.], Section 52" + REFERENCE "[IEEE 802.3 Std], Section 52" ::= { dot3MauType 36 } dot3MauType10GigBaseW OBJECT-IDENTITY STATUS current DESCRIPTION "W PCS/PMA, unknown PMD." - REFERENCE "[IEEE 802.3 Std.], Section 49 and 50" + REFERENCE "[IEEE 802.3 Std], Section 49 and 50" ::= { dot3MauType 37 } dot3MauType10GigBaseEW OBJECT-IDENTITY STATUS current DESCRIPTION "W fiber over 1550 nm optics" - REFERENCE "[IEEE 802.3 Std.], Section 52" + REFERENCE "[IEEE 802.3 Std], Section 52" ::= { dot3MauType 38 } dot3MauType10GigBaseLW OBJECT-IDENTITY STATUS current DESCRIPTION "W fiber over 1310 nm optics" - REFERENCE "[IEEE 802.3 Std.], Section 52" + REFERENCE "[IEEE 802.3 Std], Section 52" ::= { dot3MauType 39 } dot3MauType10GigBaseSW OBJECT-IDENTITY STATUS current DESCRIPTION "W fiber over 850 nm optics" - REFERENCE "[IEEE 802.3 Std.], Section 52" + REFERENCE "[IEEE 802.3 Std], Section 52" ::= { dot3MauType 40 } ------ new since RFC 3636: dot3MauType10GigBaseCX4 OBJECT-IDENTITY STATUS current DESCRIPTION "X copper over 8 pair 100-Ohm balanced cable" - REFERENCE "[IEEE 802.3 Std.], Section 54" + REFERENCE "[IEEE 802.3 Std], Section 54" ::= { dot3MauType 41 } + dot3MauType2BaseTL OBJECT-IDENTITY STATUS current - DESCRIPTION "Voice grade UTP copper, up to 2700m " - REFERENCE "[IEEE 802.3 Std.], Sections 61 and 63" + DESCRIPTION "Voice grade UTP copper, up to 2700m, optional PAF" + REFERENCE "[IEEE 802.3 Std], Sections 61 and 63" ::= { dot3MauType 42 } dot3MauType10PassTS OBJECT-IDENTITY STATUS current - DESCRIPTION "Voice grade UTP copper, up to 750m" - REFERENCE "[IEEE 802.3 Std.], Sections 61 and 62" + DESCRIPTION "Voice grade UTP copper, up to 750m, optional PAF" + REFERENCE "[IEEE 802.3 Std], Sections 61 and 62" ::= { dot3MauType 43 } dot3MauType100BaseBX10D OBJECT-IDENTITY STATUS current - DESCRIPTION "One single-mode fiber OLT" - REFERENCE "[IEEE 802.3 Std.], Section 58" + DESCRIPTION "One single-mode fiber OLT, long wavelength, 10km" + REFERENCE "[IEEE 802.3 Std], Section 58" ::= { dot3MauType 44 } dot3MauType100BaseBX10U OBJECT-IDENTITY STATUS current - DESCRIPTION "One single-mode fiber ONU" - REFERENCE "[IEEE 802.3 Std.], Section 58" + DESCRIPTION "One single-mode fiber ONU, long wavelength, 10km" + REFERENCE "[IEEE 802.3 Std], Section 58" ::= { dot3MauType 45 } dot3MauType100BaseLX10 OBJECT-IDENTITY STATUS current - DESCRIPTION "Two fiber" - REFERENCE "[IEEE 802.3 Std.], Section 58" + DESCRIPTION "Two single-mode fibers, long wavelength, 10km" + REFERENCE "[IEEE 802.3 Std], Section 58" ::= { dot3MauType 46 } dot3MauType1000BaseBX10D OBJECT-IDENTITY STATUS current - DESCRIPTION "One single-mode fiber OLT" - REFERENCE "[IEEE 802.3 Std.], Section 59" + DESCRIPTION "One single-mode fiber OLT, long wavelength, 10km" + REFERENCE "[IEEE 802.3 Std], Section 59" ::= { dot3MauType 47 } dot3MauType1000BaseBX10U OBJECT-IDENTITY STATUS current - DESCRIPTION "One single-mode fiber ONU" - REFERENCE "[IEEE 802.3 Std.], Section 59" + DESCRIPTION "One single-mode fiber ONU, long wavelength, 10km" + REFERENCE "[IEEE 802.3 Std], Section 59" ::= { dot3MauType 48 } dot3MauType1000BaseLX10 OBJECT-IDENTITY STATUS current - DESCRIPTION "Two fiber 10km" - REFERENCE "[IEEE 802.3 Std.], Section 59" + DESCRIPTION "Two sigle-mode fiber, long wavelength, 10km" + REFERENCE "[IEEE 802.3 Std], Section 59" ::= { dot3MauType 49 } + dot3MauType1000BasePX10D OBJECT-IDENTITY STATUS current - DESCRIPTION "One single-mode fiber OMP OLT 10km" - REFERENCE "[IEEE 802.3 Std.], Section 60" + DESCRIPTION "One single-mode fiber EPON OLT, 10km" + REFERENCE "[IEEE 802.3 Std], Section 60" ::= { dot3MauType 50 } dot3MauType1000BasePX10U OBJECT-IDENTITY STATUS current - DESCRIPTION "One single-mode fiber OMP ONU 10km" - REFERENCE "[IEEE 802.3 Std.], Section 60" + DESCRIPTION "One single-mode fiber EPON ONU, 10km" + REFERENCE "[IEEE 802.3 Std], Section 60" ::= { dot3MauType 51 } dot3MauType1000BasePX20D OBJECT-IDENTITY STATUS current - DESCRIPTION "One single-mode fiber OMP OLT 20km" - REFERENCE "[IEEE 802.3 Std.], Section 60" + DESCRIPTION "One single-mode fiber EPON OLT, 20km" + REFERENCE "[IEEE 802.3 Std], Section 60" ::= { dot3MauType 52 } dot3MauType1000BasePX20U OBJECT-IDENTITY STATUS current - DESCRIPTION "One single-mode fiber OMP ONU 20km" - REFERENCE "[IEEE 802.3 Std.], Section 60" + DESCRIPTION "One single-mode fiber EPON ONU, 20km" + REFERENCE "[IEEE 802.3 Std], Section 60" ::= { dot3MauType 53 } END 6. Security Considerations - There are a number of management objects defined in this MIB that + The IANA-MAU-MIB does not define any management objects. Instead, it + defines a set of textual conventions which are used by the MAU-MIB + and may be used by other MIB modules to define management objects. + Meaningful security considerations can only be written for MIB + modules that define management objects. + + There is a number of management objects defined in the MAU-MIB that have a MAX-ACCESS clause of read-write. Setting these objects can have a serious effect on the operation of the network, including: o enabling or disabling a MAU o changing a MAU's default type o enabling, disabling or restarting autonegotiation o modifying the capabilities that a MAU advertizes during autonegotiation. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. - Some of the readable objects in this MIB module (i.e., objects with a - MAX-ACCESS other than not-accessible) may be considered sensitive or - vulnerable in some network environments. In some environments it may - be undesirable to allow unauthorized parties to access statistics or - status information about individual links in a network. It is thus - important to control even GET and/or NOTIFY access to these objects - and possibly to even encrypt the values of these objects when sending - them over the network via SNMP. + Some of the readable objects in the MAU-MIB module (i.e., objects + with a MAX-ACCESS other than not-accessible) may be considered + sensitive or vulnerable in some network environments. In some + environments it may be undesirable to allow unauthorized parties to + access statistics or status information about individual links in a + network. It is thus important to control even GET and/or NOTIFY + access to these objects and possibly to even encrypt the values of + these objects when sending them over the network via SNMP. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects - in this MIB module. + in the MAU-MIB module. It is recommended that the implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Furthermore, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an - instance of this MIB module is properly configured to give access to - the objects only to those principals (users) that have legitimate + instance of the MAU-MIB module is properly configured to give access + to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. IANA Considerations - This document defines first version of the IANA-maintained MIB - module. It is intended that each new MAU type, Media Available + This document defines first version of the IANA-maintained IANA-MAU- + MIB module. It is intended that each new MAU type, Media Available state, Auto Negotiation capability and/or Jack type defined by the IEEE 802.3 working group and approved for publication in a revision - of IEEE Std 802.3 will be added to the IANA-maintaned module. An - Expert Review, as defined in RFC 2434 [RFC2434], is REQUIRED. + of IEEE Std 802.3 will be added to the IANA-maintaned MIB module, + provided that it is suitable for being managed by the base objects in + the MAU-MIB module. + + For each new MAU type added, a short description of the MAU + technology and, wherever possible, a reference to a publicly + available specification SHOULD be specified. An Expert Review, as + defined in RFC 2434 [RFC2434], is REQUIRED, for each modification. 8. Acknowledgments This document was produced by the IETF Ethernet Interfaces and Hub MIB Working Group, whose efforts were greatly advanced by the contributions of the following people: Mike Heard + John Flick Dan Romascanu This document is based on the Proposed Standard MAU MIB, RFC 3636 [RFC3636], edited by John Flick of Hewlett-Packard, and produced by the Ethernet Interfaces and Hub MIB Working Group. It extends that document by moving the object identities and textual conventions for MAU types into a IANA-maintained MIB module. In addition, support is provided for the EFM and 10GBASE-CX4 MAUs as defined in [IEEE802.3ah] @@ -3005,41 +2979,42 @@ RFC 3636, in turn, was based on the Proposed Standard MAU MIB, RFC 2668 [RFC2668], edited by John Flick of Hewlett-Packard and Andrew Smith, then of Extreme Networks, and produced by the Ethernet Interfaces and Hub MIB Working Group. It extends that document by providing support for 10 Gb/s MAUs as defined in [IEEE802.3ae]. RFC 2668, in turn, was based on the Proposed Standard MAU MIB, RFC 2239 [RFC2239], edited by Kathryn de Graaf, then of 3Com, and Dan Romascanu, then of Madge Networks, and produced by the Ethernet Interfaces and Hub MIB Working Group. It extended that document by - providing support for 1000 Mb/sec MAUs as defined in [IEEE802.3]. + providing support for 1000 Mb/sec MAUs, PAUSE negotiation and remote + fault status as defined in [IEEE802.3]. RFC 2239, in turn, was based on the Proposed Standard MAU MIB, RFC 1515 [RFC1515], edited by Donna McMaster, then of SynOptics Communications, Keith McCloghrie, then of Hughes LAN Systems, and Sam Roberts, then of Farallon Computing, and produced by the Hub MIB Working Group. It extends that document by providing support for 100 - Mb/sec MAUs, full duplex MAUs, and auto-negotiation, as defined in - [IEEE802.3]. + Mb/sec MAUs, full duplex MAUs, auto-negotiation, and jack management + as defined in [IEEE802.3]. 9. References 9.1. Normative References [IEEE802.3] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical - layer specifications", IEEE Std 802.3-2002, March 2002. + layer specifications", IEEE Std 802.3-2005, December 2005. [IEEE802.3ae] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - Media Access Control (MAC) Parameters, Physical Layer and Management Parameters for 10 Gb/s Operation", IEEE Std 802.3ae-2002, August 2002.