RFC 3637
Definitions of Managed Objects for the Ethernet WAN Interface Sublayer
RFC 3637: Definitions of Managed Objects for the Ethernet WAN Interface Sublayer 🎀
Okay bestie, let's get into this one 💅 RFC 3637 comes from the Network Working Group, and it's a Standards Track document, dated September 2003. It was written by C.M. Heard, Ed., who was a Consultant at the time. Heard is the editor, so the doc is their work to shape 🫶 This header doesn't list anything it obsoletes or updates.
It's all about MIB modules (the management info blueprints that network tools use to read and control gear) for the Ethernet WAN Interface Sublayer (WIS) 🌈
Status of This Memo ✨
This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💜
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. 🌸
Abstract
Okay so this doc defines a piece of the Management Information Base (MIB) for network management protocols in TCP/IP based internets. Specifically, it defines objects for managing the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS) 🦋
The MIB module here is an extension of the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface MIB, and it's implemented alongside that one. It also works with the Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, the Interfaces Group MIB, and the Inverted Stack Table MIB. It's a whole squad 👑
Table of Contents ✨
1. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Internet-Standard Management Framework . . . . . . . . . . 2
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Relationship to the SONET/SDH Interface MIB. . . . . . . 3
3.2. Relationship to the Ethernet-like Interface MIB. . . . . 4
3.3. Relationship to the 802.3 MAU MIB. . . . . . . . . . . . 4
3.4. Use of the ifTable . . . . . . . . . . . . . . . . . . . 4
3.4.1. Layering Model . . . . . . . . . . . . . . . . . 5
3.4.2. Use of ifTable for LLC Layer/MAC Layer
Reconciliation Sublayer/Physical Coding Sublayer 5
3.4.3. Use of ifTable for SONET/SDH Path Layer. . . . . 5
3.4.4. Use of ifTable for SONET/SDH Medium/Section/
Line Layer . . . . . . . . . . . . . . . . . . . 5
3.5. SONET/SDH Terminology. . . . . . . . . . . . . . . . . . 6
3.6. Mapping of IEEE 802.3 Managed Objects. . . . . . . . . . 7
3.7. Mapping of SNMP Objects to WIS Station Management
Registers. . . . . . . . . . . . . . . . . . . . . . . . 12
3.8. Structure of the MIB Module . . . . . . . . . . . . . . 14
3.8.1. etherWisDeviceTable. . . . . . . . . . . . . . . 14
3.8.2. etherWisSectionCurrentTable. . . . . . . . . . . 15
3.8.3. etherWisPathCurrentTable . . . . . . . . . . . . 15
3.8.4. etherWisFarEndPathCurrentTable . . . . . . . . . 15
4. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 16
5. Intellectual Property Statement. . . . . . . . . . . . . . . . 30
6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 30
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A: Collection of Performance Data Using WIS
MDIO Registers . . . . . . . . . . . . . . . . . . . . . . . . 34
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Editor's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 371. Conventions 💖
When you see "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", or "OPTIONAL" in this document, they get read the way BCP 14 and RFC 2119 [RFC2119] describe them. Those words are the key words, so they're the ones to pay attention to 👀
2. The Internet-Standard Management Framework 🧚
If you want the full overview of the documents behind the current Internet-Standard Management Framework, go to section 7 of RFC 3410 [RFC3410] 🌈
Managed objects get accessed through a virtual information store called the Management Information Base, or MIB. MIB objects are usually reached through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms 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]. It's giving organized 🍓
3. Overview 🦋
The objects in this memo get used alongside objects from the Interfaces Group MIB [RFC2863], the SONET/SDH Interface MIB [RFC3592], and the 802.3 MAU MIB [RFC3636]. Together they manage the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS) defined in [802.3ae] 💜
The WIS handles OC-192c/VC-4-64c framing and scrambling. It sits between the Physical Coding Sublayer (PCS) and the Physical Medium Attachment (PMA) sublayer, inside a 10GBASE-W 10 Gb/s WAN-compatible physical layer device (PHY). It can be used with any of the PCS, PMA, and Physical Medium Dependent (PMD) sublayers that [802.3ae] defines for 10GBASE-W PHYs ⭐
There are three types of 10GBASE-W PHYs, told apart by their optics: 10GBASE-SW, 10GBASE-LW, and 10GBASE-EW. The objects in this memo can manage an Ethernet interface using any of them. They don't apply to any other kind of interface. That includes so-called Ethernet Line Terminating Equipment (ELTE), which lives inside a SONET network element, uses the 10GBASE-W PMA/PMD sublayers, but otherwise acts as SONET Line Terminating Equipment (LTE) 🙈
The objects here, together with the ones pulled in from the Interfaces Group MIB, the SONET/SDH Interface MIB, and the 802.3 MAU MIB, are meant to give exact representations of the mandatory attributes of the oWIS managed object class (aka the members of the pWISBasic package). Those are defined in Clause 30 and Annex 30A of [802.3ae]. They also give approximate representations of the optional attributes, which are the members of the pWISOptional package. A few objects with no oWIS equivalent exist to support WIS testing features that Clause 50 of [802.3ae] requires 🧪
3.1. Relationship to the SONET/SDH Interface MIB 🌸
Since the Ethernet WAN Interface Sublayer was built to be SONET-compatible, you can get info similar to most members of the oWIS managed object class from objects in the SONET-MIB [RFC3592]. So this MIB module is a sparse augmentation of the SONET-MIB. Every table defined here extends some table in the SONET-MIB. Its compliance statement REQUIRES that an agent implementing the objects in this memo also implements the relevant SONET-MIB objects. That covers every object required by sonetCompliance2, plus some that sonetCompliance2 leaves optional 🫶
Some of the objects pulled in from the SONET-MIB, specifically the threshold objects and interval counter objects, only approximately represent the matching oWIS attributes. Section 3.6 has the details. An alternative would have been to define brand new objects that exactly match the oWIS definitions. That idea got rejected, because the SONET-MIB objects already run in deployed systems to manage the SONET sublayers of ATM over SONET and PPP over SONET interfaces. Using a different scheme for the SONET sublayers of 10 Gb/s WAN-compatible Ethernet interfaces was judged undesirable 🙅♀️ Also, the approach this memo takes needs no hardware support beyond what [802.3ae] subclause 50.3.11 mandates 💖
3.2. Relationship to the Ethernet-like Interface MIB ✨
An interface that includes the Ethernet WIS is, by definition, an Ethernet-like interface. So an agent implementing the objects in this memo MUST implement the objects required by the dot3Compliance2 compliance statement in the EtherLike-MIB. No skipping 💅
3.3. Relationship to the 802.3 MAU MIB 🎀
Support for the mauModIfCompl3 compliance statement of the MAU-MIB [RFC3636] is REQUIRED for all Ethernet-like interfaces. This is needed so applications can control and/or determine the media type in use. That's important for devices that can support both the 10GBASE-R 10 Gb/s LAN format (which does not include the WIS) and the 10GBASE-W 10 Gb/s WAN format (which does include the WIS). The MAU-MIB also lets you put a device into standby mode or reset it. A reset may be used to re-initialize the WIS 🔥
3.4. Use of the ifTable 🌈
This section specifies how the ifTable, as defined in [RFC2863], gets used for the Ethernet WIS application 🦋
3.4.1. Layering Model ✨
Ethernet interfaces that employ the WIS are layered as defined in [802.3ae]. The matching use of the ifTable [RFC2863] is shown in the figure below 🧚
_____________________________ _
| LLC Layer | |
+-----------------------------+ |
| MAC Layer | |
+-----------------------------+ > 1 ifEntry
| Reconciliation Sublayer | | ifType: ethernetCsmacd(6)
+-----------------------------+ |
| Physical Coding Sublayer | |
+-----------------------------+ +
| Path Layer | > 1 ifEntry
+-----------------------------+ + ifType: sonetPath(50)
| Line Layer | |
+-----------------------------+ |
| Section Layer | > 1 ifEntry
+-----------------------------+ | ifType: sonet(39)
| Physical Medium Layer | |
----------------------------- -Figure 1 - Use of ifTable for an Ethernet WIS port
The exact configuration and multiplexing of the layers is kept in the ifStackTable [RFC2863] and in the ifInvStackTable [RFC2864] 🎀
3.4.2. Use of ifTable for LLC Layer/MAC Layer/Reconciliation Sublayer/Physical Coding Sublayer 💜
The ifTable MUST be used as specified in [RFC3635] and [RFC3636] for the LLC Layer/MAC Layer/Reconciliation Sublayer/Physical Coding Sublayer. No wiggle room here, bestie 😭
3.4.3. Use of ifTable for SONET/SDH Path Layer 🌸
The ifTable MUST be used as specified in [RFC3592] for the SONET/SDH Path Layer. The value of ifHighSpeed is set to 9585. ifSpeed reports a value of 4294967295 🍓
3.4.4. Use of ifTable for SONET/SDH Medium/Section/Line Layer 🫶
The ifTable MUST be used as specified in [RFC3592] for the SONET/SDH Medium/Section/Line Layer. The value of ifHighSpeed is set to 9953. ifSpeed reports a value of 4294967295 💅✨
3.5. SONET/SDH Terminology 🌸
okay so the SONET/SDH terminology in [802.3ae] is mostly the same as in [RFC3592] 💅, but there are a few differences. When that happens, the definitions in [802.3ae] win, no debate. Here's the tea on each one:
Unequipped 🫶 This defect isn't defined by [802.3ae] 🙈. An implementation that does support it SHOULD report it by setting the sonetPathUnequipped bit in the appropriate instance of sonetPathCurrentStatus.
Signal Label Mismatch ✨ [802.3ae] calls this one Payload Label Mismatch (PLM) 🎀. It gets reported by setting both the sonetPathSignalLabelMismatch bit in the appropriate instance of sonetPathCurrentStatus (defined in [RFC3592]) and the etherWisPathPLM bit in the corresponding instance of etherWisPathCurrentStatus (defined below).
Loss of Codegroup Delineation 🦋 [802.3ae] defines Loss of Codegroup Delineation (LCD) as happening when the Physical Coding Sublayer can't find the 64B/66B code group boundaries 😭. There's no matching defect in [RFC3592], so it's a whole new vibe. It gets reported by setting the etherWisPathLCD bit in the appropriate instance of the object etherWisPathCurrentStatus, which is defined below.
STS-Path Remote Defect Indication 👑 Okay this one is a lot. [802.3ae] MUST use ERDI-P (Enhanced Remote Defect Indication - Path), defined in [T1.231], to signal remote server defects (triggered by path AIS or path LOP) and remote payload defects (triggered by Payload Label Mismatch or Loss of Codegroup Delineation) 🔥. [RFC3592] only has the one-bit RDI-P (Remote Defect Indication - Path), which signals remote server detects (i.e., path AIS and path LOP) and nothing else 💀. So an implementation of the MIB module defined in this memo MUST set the sonetPathSTSRDI bit in the appropriate instance of sonetPathCurrentStatus when it receives an ERDI-P server defect indication from the remote end ✨. Both ERDI-P payload defects and ERDI-P server defects get reported in the object etherWisFarEndPathCurrentStatus, which is also defined below 🧚.
Path Coding Violations 💜 In [802.3ae], the path layer CV count is based on block errors instead of BIP-8 errors 🌈. So it only goes up once for each B3 byte that shows incorrect parity, no matter how many bits are wrong 🍓. And just so you know, Section 8.4.5.1 of [T1.231] lets you use either path BIP-8 errors or path block errors for the path layer error count, so it's flexible 🦋.
3.6. Mapping of IEEE 802.3 Managed Objects 🧚
this section is the cheat sheet 📋 that maps the oWIS managed objects from [802.3ae] to the objects in this document and its associated MIB modules: the IF-MIB [RFC2863], the SONET-MIB [RFC3592], and the MAU-MIB [RFC3636] 💖.
IEEE 802.3 Managed Object Corresponding SNMP Object
oWIS - pWISBasic package
aWISID IF-MIB - ifIndex
aSectionStatus SONET-MIB - sonetSectionCurrentStatus
aLineStatus SONET-MIB - sonetLineCurrentStatus
aPathStatus etherWisPathCurrentStatus
aFarEndPathStatus etherWisFarEndPathCurrentStatus
oWIS - pWISOptional package
aSectionSESThreshold SONET-MIB - sonetSESthresholdSet
aSectionSESs SONET-MIB - sonetSectionCurrentSESs +
sonetSectionIntervalSESs
aSectionESs SONET-MIB - sonetSectionCurrentESs +
sonetSectionIntervalESs
aSectionSEFSs SONET-MIB - sonetSectionCurrentSEFSs +
sonetSectionIntervalSEFSs
aSectionCVs SONET-MIB - sonetSectionCurrentCVs +
sonetSectionIntervalCVs
aJ0ValueTX etherWisSectionCurrentJ0Transmitted
aJ0ValueRX etherWisSectionCurrentJ0Received
aLineSESThreshold SONET-MIB - sonetSESthresholdSet
aLineSESs SONET-MIB - sonetLineCurrentSESs +
sonetLineIntervalSESs
aLineESs SONET-MIB - sonetLineCurrentESs +
sonetLineIntervalESs
aLineCVs SONET-MIB - sonetLineCurrentCVs +
sonetLineIntervalCVs
aFarEndLineSESs SONET-MIB - sonetFarEndLineCurrentSESs +
sonetFarEndLineIntervalSESs
aFarEndLineESs SONET-MIB - sonetFarEndLineCurrentESs +
sonetFarEndLineIntervalESs
aFarEndLineCVs SONET-MIB - sonetFarEndLineCurrentCVs +
sonetFarEndLineIntervalCVs
aPathSESThreshold SONET-MIB - sonetSESthresholdSet
aPathSESs SONET-MIB - sonetPathCurrentSESs +
sonetPathIntervalSESs
aPathESs SONET-MIB - sonetPathCurrentESs +
sonetPathIntervalESs
aPathCVs SONET-MIB - sonetPathCurrentCVs +
sonetPathIntervalCVs
aJ1ValueTX etherWisPathCurrentJ1Transmitted
aJ1ValueRX etherWisPathCurrentJ1Received
aFarEndPathSESs SONET-MIB - sonetFarEndPathCurrentSESs +
sonetFarEndPathIntervalSESs
aFarEndPathESs SONET-MIB - sonetFarEndPathCurrentESs +
sonetFarEndPathIntervalESs
aFarEndPathCVs SONET-MIB - sonetFarEndPathCurrentCVs +
sonetFarEndPathIntervalCVsIt should be noted 📝 that the threshold and counter objects imported from the SONET-MIB are NOT completely equivalent to the corresponding IEEE 802.3 objects 🙈. Here are the differences, bestie:
IEEE 802.3 Managed Object How Corresponding SNMP Object Differs
aSectionSESThreshold This object is defined in [802.3ae] as an
integer with one instance per interface.
sonetSESthresholdSet is an enumerated value
that has one instance per network element;
it controls the thresholds for all layers
simultaneously and allows only certain
discrete values to be selected.
aSectionSESs This object is defined in [802.3ae] as a
generalized nonresetable counter. The
objects sonetSectionCurrentSESs and
sonetSectionIntervalSESs are 15-minute
interval counters.
aSectionESs This object is defined as a generalized
nonresetable counter in [802.3ae]. The
objects sonetSectionCurrentESs and
sonetSectionIntervalESs are 15-minute
interval counters.
aSectionSEFSs This object is defined as a generalized
nonresetable counter in [802.3ae]. The
objects sonetSectionCurrentSEFSs and
sonetSectionIntervalSEFSs are 15-minute
interval counters.
aSectionCVs This object is defined as a generalized
nonresetable counter in [802.3ae], and it
is not subject to inhibiting. The objects
sonetSectionCurrentCVs and
sonetSectionIntervalCVs are 15-minute
interval counters, and they are inhibited
(not incremented) during one-second
intervals that qualify as severely errored
seconds.
aLineSESThreshold This object is defined in [802.3ae] as an
integer with one instance per interface.
sonetSESthresholdSet is an enumerated value
that has one instance per network element;
it controls the thresholds for all layers
simultaneously and allows only certain
discrete values to be selected.
aLineSESs This object is defined as a generalized
nonresetable counter in [802.3ae], and it
is not subject to inhibiting. The objects
sonetLineCurrentSESs and
sonetLineIntervalSESs are 15-minute
interval counters, and they are inhibited
(not incremented) during one-second
intervals that qualify as unavailable
seconds.
aLineESs This object is defined as a generalized
nonresetable counter in [802.3ae], and it
is not subject to inhibiting. The objects
sonetLineCurrentESs and
sonetLineIntervalESs are 15-minute interval
counters, and they are inhibited (not
incremented) during one-second intervals
that qualify as unavailable seconds.
aLineCVs This object is defined as a generalized
nonresetable counter in [802.3ae], and it
is not subject to inhibiting. The objects
sonetLineCurrentCVs and
sonetLineIntervalCVs are 15-minute interval
counters, and they are inhibited (not
incremented) during one-second intervals
that qualify either as severely errored
seconds or as unavailable seconds.
aFarEndLineSESs This object is defined as a generalized
nonresetable counter in [802.3ae], and it
is not subject to inhibiting. The objects
sonetFarEndLineCurrentSESs and
sonetFarEndLineIntervalSESs are 15-minute
interval counters, and they are inhibited
(not incremented) during one-second
intervals that qualify as unavailable
seconds.
aFarEndLineESs This object is defined as a generalized
nonresetable counter in [802.3ae], and it
is not subject to inhibiting. The objects
sonetFarEndLineCurrentESs and
sonetFarEndLineIntervalESs are 15-minute
interval counters, and they are inhibited
(not incremented) during one-second
intervals that qualify as unavailable
seconds.Okay bestie, picking up right where we left off with the 3.6 mapping list. First up is the big rundown of the far-end and path-layer counters. Heads up: the object names and wording below are copied exactly, because the spec needs every detail.
aFarEndLineCVs This object is defined as a generalized
nonresetable counter in [802.3ae], and it
is not subject to inhibiting. The objects
sonetFarEndLineCurrentCVs and
sonetFarEndLineIntervalCVs are 15-minute
interval counters, and they are inhibited
(not incremented) during one-second
intervals that qualify either as severely
errored seconds or as unavailable seconds.
aPathSESThreshold This object is defined in [802.3ae] as an
integer with one instance per interface.
sonetSESthresholdSet is an enumerated value
that has one instance per network element;
it controls the thresholds for all layers
simultaneously and allows only certain
discrete values to be selected.
aPathSESs This object is defined as a generalized
nonresetable counter in [802.3ae], and it
is not subject to inhibiting. The objects
sonetPathCurrentSESs and
sonetPathIntervalSESs are 15-minute
interval counters, and they are inhibited
(not incremented) during one-second
intervals that qualify as unavailable
seconds. In addition, [802.3ae] includes
PLM-P and LCD-P defects in the criteria for
declaring path layer severely errored
seconds, while [RFC3592] does not.
aPathESs This object is defined as a generalized
nonresetable counter in [802.3ae], and it
is not subject to inhibiting. The objects
sonetPathCurrentESs and
sonetPathIntervalESs are 15-minute interval
counters, and they are inhibited (not
incremented) during one-second intervals
that qualify as unavailable seconds. In
addition, [802.3ae] includes PLM-P and
LCD-P defects in the criteria for declaring
path layer errored seconds, while [RFC3592]
does not.
aPathCVs This object is defined as a generalized
nonresetable counter in [802.3ae], and it
is not subject to inhibiting. The objects
sonetPathCurrentCVs and
sonetPathIntervalCVs are 15-minute interval
counters, and they are inhibited (not
incremented) during one-second intervals
that qualify either as severely errored
seconds or as unavailable seconds.
aFarEndPathSESs This object is defined as a generalized
nonresetable counter in [802.3ae], and it
is not subject to inhibiting. The objects
sonetFarEndPathCurrentSESs and
sonetFarEndPathIntervalSESs are 15-minute
interval counters, and they are inhibited
(not incremented) during one-second
intervals that qualify as unavailable
seconds. In addition, [802.3ae] includes
far-end PLM-P and LCD-P defects in the
criteria for declaring far-end path layer
severely errored seconds, while [RFC3592]
does not.
aFarEndPathESs This object is defined as a generalized
nonresetable counter in [802.3ae], and it
is not subject to inhibiting. The objects
sonetFarEndPathCurrentESs and
sonetFarEndPathIntervalESs are 15-minute
interval counters, and they are inhibited
(not incremented) during one-second
intervals that qualify as unavailable
seconds. In addition, [802.3ae] includes
far-end PLM-P and LCD-P defects in the
criteria for declaring far-end path layer
errored seconds, while [RFC3592] does not.
aFarEndPathCVs This object is defined as a generalized
nonresetable counter in [802.3ae], and it
is not subject to inhibiting. The objects
sonetFarEndPathCurrentCVs and
sonetFarEndPathIntervalCVs are 15-minute
interval counters, and they are inhibited
(not incremented) during one-second
intervals that qualify either as severely
errored seconds or as unavailable seconds.Note: even though the threshold and counter objects pulled in from the SONET-MIB are semantically different from the matching IEEE 802.3 objects 🤓, the hardware support that [802.3ae] subclause 50.3.11 asks for is enough to cover both. See Appendix A for details ✨.
3.7. Mapping of SNMP Objects to WIS Station Management Registers 🔌
Okay so some of the objects in this memo, plus the ones borrowed from the SONET-MIB [RFC3592] or the MAU-MIB [RFC3636], need WIS-specific hardware support 🛠️. [802.3ae] subclause 50.3.11 spells out the WIS management interface requirements, including a required subset of the WIS Management Data Input/Output (MDIO) registers from [802.3ae] subclause 45.2.2 💜. The table below is a cross-reference that maps each managed object to the WIS MDIO registers in that required subset that support it. Also, the MDIO interface is optional, but if it isn't implemented, then the required register subset's capabilities must be provided by other means 🫶.
SNMP Object WIS MDIO Register(s)
ETHER-WIS - etherWisDeviceTxTestPatternMode 10G WIS control 2
ETHER-WIS - etherWisDeviceRxTestPatternMode 10G WIS control 2
ETHER-WIS - etherWisDeviceRxTestPatternErrors 10G WIS test pattern
error counter
SONET-MIB - sonetMediumType none required
SONET-MIB - sonetMediumTimeElapsed none required
SONET-MIB - sonetMediumValidIntervals none required
SONET-MIB - sonetMediumLineCoding none required
SONET-MIB - sonetMediumLineType none required
SONET-MIB - sonetMediumCircuitIdentifier none required
SONET-MIB - sonetMediumInvalidIntervals none required
SONET-MIB - sonetMediumLoopbackConfig none required
SONET-MIB - sonetSESthresholdSet none required
ETHER-WIS - etherWisSectionCurrentJ0Transmitted 10G WIS J0 transmit
ETHER-WIS - etherWisSectionCurrentJ0Received 10G WIS J0 receive
SONET-MIB - sonetSectionCurrentStatus 10G WIS status 3
SONET-MIB - sonetSectionCurrentESs \
SONET-MIB - sonetSectionCurrentSESs \
SONET-MIB - sonetSectionCurrentSEFSs | 10G WIS status 3
SONET-MIB - sonetSectionCurrentCVs | +
SONET-MIB - sonetSectionIntervalESs | 10G WIS section
SONET-MIB - sonetSectionIntervalSESs | BIP error count
SONET-MIB - sonetSectionIntervalSEFSs /
SONET-MIB - sonetSectionIntervalCVs /
SONET-MIB - sonetSectionIntervalValidData none required
SONET-MIB - sonetLineCurrentStatus 10G WIS status 3
SONET-MIB - sonetLineCurrentESs \
SONET-MIB - sonetLineCurrentSESs \
SONET-MIB - sonetLineCurrentCVs | 10G WIS status 3
SONET-MIB - sonetLineCurrentUASs | +
SONET-MIB - sonetLineIntervalESs | 10G WIS line
SONET-MIB - sonetLineIntervalSESs | BIP errors
SONET-MIB - sonetLineIntervalCVs /
SONET-MIB - sonetLineIntervalUASs /
SONET-MIB - sonetLineIntervalValidData none required
SONET-MIB - sonetFarEndLineCurrentESs \
SONET-MIB - sonetFarEndLineCurrentSESs \
SONET-MIB - sonetFarEndLineCurrentCVs | 10G WIS status 3
SONET-MIB - sonetFarEndLineCurrentUASs | +
SONET-MIB - sonetFarEndLineIntervalESs | 10G WIS far end
SONET-MIB - sonetFarEndLineIntervalSESs | line BIP errors
SONET-MIB - sonetFarEndLineIntervalCVs /
SONET-MIB - sonetFarEndLineIntervalUASs /
SONET-MIB - sonetFarEndLineIntervalValidData 10G WIS status 3
ETHER-WIS - etherWisPathCurrentStatus 10G WIS status 3
ETHER-WIS - etherWisPathCurrentJ1Transmitted 10G WIS J1 transmit
ETHER-WIS - etherWisPathCurrentJ1Received 10G WIS J1 receive
SONET-MIB - sonetPathCurrentWidth none required
SONET-MIB - sonetPathCurrentStatus 10G WIS status 3
SONET-MIB - sonetPathCurrentESs \
SONET-MIB - sonetPathCurrentSESs \
SONET-MIB - sonetPathCurrentCVs | 10G WIS status 3
SONET-MIB - sonetPathCurrentUASs | +
SONET-MIB - sonetPathIntervalESs | 10G WIS
SONET-MIB - sonetPathIntervalSESs | path block
SONET-MIB - sonetPathIntervalCVs / error count
SONET-MIB - sonetPathIntervalUASs /
SONET-MIB - sonetPathIntervalValidData none required
ETHER-WIS - etherWisFarEndPathCurrentStatus 10G WIS status 3
SONET-MIB - sonetFarEndPathCurrentESs \
SONET-MIB - sonetFarEndPathCurrentSESs \
SONET-MIB - sonetFarEndPathCurrentCVs | 10G WIS status 3
SONET-MIB - sonetFarEndPathCurrentUASs | +
SONET-MIB - sonetFarEndPathIntervalESs | 10G WIS far end
SONET-MIB - sonetFarEndPathIntervalSESs | path block
SONET-MIB - sonetFarEndPathIntervalCVs / error count
SONET-MIB - sonetFarEndPathIntervalUASs /
SONET-MIB - sonetFarEndPathIntervalValidData 10G WIS status 3
MAU-MIB - ifMauIfIndex none required
MAU-MIB - ifMauIndex none required
MAU-MIB - ifMauType 10G WIS control 2
MAU-MIB - ifMauStatus WIS control 1
MAU-MIB - ifMauMediaAvailable \ WIS status 1 +
MAU-MIB - ifMauMediaAvailableStateExits / 10G WIS status 3
MAU-MIB - ifMauJabberState none required
MAU-MIB - ifMauJabberingStateEnters none required
MAU-MIB - ifMauFalseCarriers none required
MAU-MIB - ifMauDefaultType 10G WIS control 2
MAU-MIB - ifMauAutoNegSupported none required
MAU-MIB - ifMauTypeListBits 10G WIS status 23.8. Structure of the MIB Module ✨
okay so this MIB module has four tables total 🎀 let's go through them one by one bestie 💅
3.8.1. etherWisDeviceTable
this one is all about controlling the WIS test pattern mode 🧪 the objects in here are needed to back up the mandatory and optional WIS test features from [802.3ae] subclause 50.3.8 💖
the etherWisDeviceTable is a sparse augmentation of the sonetMediumTable from the SONET-MIB 🦋 so for every entry in etherWisDeviceTable there MUST be a matching entry in sonetMediumTable, and both entries MUST use the same ifIndex value 🫶
3.8.2. etherWisSectionCurrentTable
this table holds the managed objects for the transmitted and received section trace messages, aka the J0 byte 🌸
the etherWisSectionCurrentTable is a sparse augmentation of the sonetSectionCurrentTable from the SONET-MIB 💜 same deal as before: every entry here MUST have a partner in sonetSectionCurrentTable, and both MUST share the same ifIndex value ✨
3.8.3. etherWisPathCurrentTable
this one covers two things 👑 the current WIS path layer status, and the transmitted and received path trace messages (the J1 byte) 🍓 the path layer status object exists because the WIS supports some near-end path status conditions that sonetPathCurrentStatus doesn't report, so it's giving "we need our own" energy 💀
the etherWisPathCurrentTable is a sparse augmentation of the sonetPathCurrentTable from the SONET-MIB 🧚 every entry MUST have a matching entry in sonetPathCurrentTable, and the same ifIndex value MUST be used for both 💖
3.8.4. etherWisFarEndPathCurrentTable
this table is for the current status of the far end of the path 🌈 it's here because the WIS supports some far-end path status conditions that sonetPathCurrentStatus doesn't report either, so again, we make our own object 🙈
the etherWisFarEndPathCurrentTable is a sparse augmentation of the sonetFarEndPathCurrentTable from the SONET-MIB 🎀 each entry MUST have a counterpart in sonetFarEndPathCurrentTable, and both MUST use the same ifIndex value 🫶
4. Object Definitions ✨
Here's the actual MIB module, copied exactly as the spec has it 💅
ETHER-WIS DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
Gauge32, transmission
FROM SNMPv2-SMI
ifIndex
FROM IF-MIB
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
sonetMediumStuff2, sonetSectionStuff2,
sonetLineStuff2, sonetFarEndLineStuff2,
sonetPathStuff2, sonetFarEndPathStuff2,
sonetMediumType, sonetMediumLineCoding,
sonetMediumLineType, sonetMediumCircuitIdentifier,
sonetMediumLoopbackConfig, sonetSESthresholdSet,
sonetPathCurrentWidth
FROM SONET-MIB;
etherWisMIB MODULE-IDENTITY
LAST-UPDATED "200309190000Z" -- September 19, 2003
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
Chair: Dan Romascanu
Postal: Avaya Inc.
Atidim Technology Park, Bldg. 3
Tel Aviv 61131
Israel
Tel: +972 3 645 8414
E-mail: dromasca@avaya.com
Editor: C. M. Heard
Postal: 600 Rainbow Dr. #141
Mountain View, CA 94041-2542
USA
Tel: +1 650-964-8391
E-mail: heard@pobox.com"
DESCRIPTION
"The objects in this MIB module are used in conjunction
with objects in the SONET-MIB and the MAU-MIB to manage
the Ethernet WAN Interface Sublayer (WIS).
The following reference is used throughout this MIB module:
[IEEE 802.3 Std] refers to:
IEEE Std 802.3, 2000 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,
'IEEE Standard for 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', 30 August 2002.
Of particular interest are Clause 50, 'WAN Interface
Sublayer (WIS), type 10GBASE-W', Clause 30, '10Mb/s,
100Mb/s, 1000Mb/s, and 10Gb/s MAC Control, and Link
Aggregation Management', and Clause 45, 'Management
Data Input/Output (MDIO) Interface'.
Copyright (C) The Internet Society (2003). This version
of this MIB module is part of RFC 3637; see the RFC
itself for full legal notices."
REVISION "200309190000Z" -- September 19, 2003
DESCRIPTION "Initial version, published as RFC 3637."
::= { transmission 134 }
-- The main sections of the module
etherWisObjects OBJECT IDENTIFIER ::= { etherWisMIB 1 }
etherWisObjectsPath OBJECT IDENTIFIER ::= { etherWisMIB 2 }
etherWisConformance OBJECT IDENTIFIER ::= { etherWisMIB 3 }
-- groups in the Ethernet WIS MIB module
etherWisDevice OBJECT IDENTIFIER ::= { etherWisObjects 1 }
etherWisSection OBJECT IDENTIFIER ::= { etherWisObjects 2 }
etherWisPath OBJECT IDENTIFIER ::= { etherWisObjectsPath 1 }
etherWisFarEndPath OBJECT IDENTIFIER ::= { etherWisObjectsPath 2 }
-- The Device group
-- These objects provide WIS extensions to
-- the SONET-MIB Medium Group.
etherWisDeviceTable OBJECT-TYPE
SYNTAX SEQUENCE OF EtherWisDeviceEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table for Ethernet WIS devices"
::= { etherWisDevice 1 }
etherWisDeviceEntry OBJECT-TYPE
SYNTAX EtherWisDeviceEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the Ethernet WIS device table. For each
instance of this object there MUST be a corresponding
instance of sonetMediumEntry."
INDEX { ifIndex }
::= { etherWisDeviceTable 1 }
EtherWisDeviceEntry ::=
SEQUENCE {
etherWisDeviceTxTestPatternMode INTEGER,
etherWisDeviceRxTestPatternMode INTEGER,
etherWisDeviceRxTestPatternErrors Gauge32
}
etherWisDeviceTxTestPatternMode OBJECT-TYPE
SYNTAX INTEGER {
none(1),
squareWave(2),
prbs31(3),
mixedFrequency(4)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable controls the transmit test pattern mode.
The value none(1) puts the the WIS transmit path into
the normal operating mode. The value squareWave(2) puts
the WIS transmit path into the square wave test pattern
mode described in [IEEE 802.3 Std.] subclause 50.3.8.1.
The value prbs31(3) puts the WIS transmit path into the
PRBS31 test pattern mode described in [IEEE 802.3 Std.]
subclause 50.3.8.2. The value mixedFrequency(4) puts the
WIS transmit path into the mixed frequency test pattern
mode described in [IEEE 802.3 Std.] subclause 50.3.8.3.
Any attempt to set this object to a value other than
none(1) when the corresponding instance of ifAdminStatus
has the value up(1) MUST be rejected with the error
inconsistentValue, and any attempt to set the corresponding
instance of ifAdminStatus to the value up(1) when an
instance of this object has a value other than none(1)
MUST be rejected with the error inconsistentValue."
REFERENCE
"[IEEE 802.3 Std.], 50.3.8, WIS test pattern generator and
checker, 45.2.2.6, 10G WIS control 2 register (2.7), and
45.2.2.7.2, PRBS31 pattern testing ability (2.8.1)."
::= { etherWisDeviceEntry 1 }
etherWisDeviceRxTestPatternMode OBJECT-TYPE
SYNTAX INTEGER {
none(1),
prbs31(3),
mixedFrequency(4)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable controls the receive test pattern mode.
The value none(1) puts the the WIS receive path into the
normal operating mode. The value prbs31(3) puts the WIS
receive path into the PRBS31 test pattern mode described
in [IEEE 802.3 Std.] subclause 50.3.8.2. The value
mixedFrequency(4) puts the WIS receive path into the mixed
frequency test pattern mode described in [IEEE 802.3 Std.]
subclause 50.3.8.3. Any attempt to set this object to a
value other than none(1) when the corresponding instance
of ifAdminStatus has the value up(1) MUST be rejected with
the error inconsistentValue, and any attempt to set the
corresponding instance of ifAdminStatus to the value up(1)
when an instance of this object has a value other than
none(1) MUST be rejected with the error inconsistentValue."
REFERENCE
"[IEEE 802.3 Std.], 50.3.8, WIS test pattern generator and
checker, 45.2.2.6, 10G WIS control 2 register (2.7), and
45.2.2.7.2, PRBS31 pattern testing ability (2.8.1)."
::= { etherWisDeviceEntry 2 }
etherWisDeviceRxTestPatternErrors OBJECT-TYPE
SYNTAX Gauge32 ( 0..65535 )
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object counts the number of errors detected when the
WIS receive path is operating in the PRBS31 test pattern
mode. It is reset to zero when the WIS receive path
initially enters that mode, and it increments each time
the PRBS pattern checker detects an error as described in
[IEEE 802.3 Std.] subclause 50.3.8.2 unless its value is
65535, in which case it remains unchanged. This object is
writeable so that it may be reset upon explicit request
of a command generator application while the WIS receive
path continues to operate in PRBS31 test pattern mode."
REFERENCE
"[IEEE 802.3 Std.], 50.3.8, WIS test pattern generator and
checker, 45.2.2.7.2, PRBS31 pattern testing ability
(2.8.1), and 45.2.2.8, 10G WIS test pattern error counter
register (2.9)."
::= { etherWisDeviceEntry 3 }
-- The Section group
-- These objects provide WIS extensions to
-- the SONET-MIB Section Group.
etherWisSectionCurrentTable OBJECT-TYPE
SYNTAX SEQUENCE OF EtherWisSectionCurrentEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table for the current state of Ethernet WIS sections."
::= { etherWisSection 1 }Okay bestie, we're still in the MIB module, and this part is where the WIS section and path objects get their full definitions 🦋✨ The section trace bytes are first up, then the path group, then the far-end path group 💅
etherWisSectionCurrentEntry OBJECT-TYPE
SYNTAX EtherWisSectionCurrentEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the etherWisSectionCurrentTable. For each
instance of this object there MUST be a corresponding
instance of sonetSectionCurrentEntry."
INDEX { ifIndex }
::= { etherWisSectionCurrentTable 1 }
EtherWisSectionCurrentEntry ::=
SEQUENCE {
etherWisSectionCurrentJ0Transmitted OCTET STRING,
etherWisSectionCurrentJ0Received OCTET STRING
}
etherWisSectionCurrentJ0Transmitted OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (16))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is the 16-octet section trace message that
is transmitted in the J0 byte. The value SHOULD
be '89'h followed by fifteen octets of '00'h
(or some cyclic shift thereof) when the section
trace function is not used, and the implementation
SHOULD use that value (or a cyclic shift thereof)
as a default if no other value has been set."
REFERENCE
"[IEEE 802.3 Std.], 30.8.1.1.8, aJ0ValueTX."
::= { etherWisSectionCurrentEntry 1 }
etherWisSectionCurrentJ0Received OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (16))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is the 16-octet section trace message that
was most recently received in the J0 byte."
REFERENCE
"[IEEE 802.3 Std.], 30.8.1.1.9, aJ0ValueRX."
::= { etherWisSectionCurrentEntry 2 }So the section entry is a table row keyed by ifIndex, and each row MUST line up with a sonetSectionCurrentEntry 🎀 The two J0 objects are the 16-octet section trace strings, one for what we send and one for what we receive. The default for the transmit side is '89'h followed by fifteen '00'h octets (or a cyclic shift of that), and it's the value the implementation SHOULD fall back to when nobody has set anything else 🌸
-- The Path group
-- These objects provide WIS extensions to
-- the SONET-MIB Path Group.
etherWisPathCurrentTable OBJECT-TYPE
SYNTAX SEQUENCE OF EtherWisPathCurrentEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table for the current state of Ethernet WIS paths."
::= { etherWisPath 1 }
etherWisPathCurrentEntry OBJECT-TYPE
SYNTAX EtherWisPathCurrentEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the etherWisPathCurrentTable. For each
instance of this object there MUST be a corresponding
instance of sonetPathCurrentEntry."
INDEX { ifIndex }
::= { etherWisPathCurrentTable 1 }
EtherWisPathCurrentEntry ::=
SEQUENCE {
etherWisPathCurrentStatus BITS,
etherWisPathCurrentJ1Transmitted OCTET STRING,
etherWisPathCurrentJ1Received OCTET STRING
}
etherWisPathCurrentStatus OBJECT-TYPE
SYNTAX BITS {
etherWisPathLOP(0),
etherWisPathAIS(1),
etherWisPathPLM(2),
etherWisPathLCD(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This variable indicates the current status of the
path payload with a bit map that can indicate multiple
defects at once. The bit positions are assigned as
follows:
etherWisPathLOP(0)
This bit is set to indicate that an
LOP-P (Loss of Pointer - Path) defect
is being experienced. Note: when this
bit is set, sonetPathSTSLOP MUST be set
in the corresponding instance of
sonetPathCurrentStatus.
etherWisPathAIS(1)
This bit is set to indicate that an
AIS-P (Alarm Indication Signal - Path)
defect is being experienced. Note: when
this bit is set, sonetPathSTSAIS MUST be
set in the corresponding instance of
sonetPathCurrentStatus.
etherWisPathPLM(1)
This bit is set to indicate that a
PLM-P (Payload Label Mismatch - Path)
defect is being experienced. Note: when
this bit is set, sonetPathSignalLabelMismatch
MUST be set in the corresponding instance of
sonetPathCurrentStatus.
etherWisPathLCD(3)
This bit is set to indicate that an
LCD-P (Loss of Codegroup Delination - Path)
defect is being experienced. Since this
defect is detected by the PCS and not by
the path layer itself, there is no
corresponding bit in sonetPathCurrentStatus."
REFERENCE
"[IEEE 802.3 Std.], 30.8.1.1.18, aPathStatus."
::= { etherWisPathCurrentEntry 1 }
etherWisPathCurrentJ1Transmitted OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (16))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is the 16-octet path trace message that
is transmitted in the J1 byte. The value SHOULD
be '89'h followed by fifteen octets of '00'h
(or some cyclic shift thereof) when the path
trace function is not used, and the implementation
SHOULD use that value (or a cyclic shift thereof)
as a default if no other value has been set."
REFERENCE
"[IEEE 802.3 Std.], 30.8.1.1.23, aJ1ValueTX."
::= { etherWisPathCurrentEntry 2 }
etherWisPathCurrentJ1Received OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (16))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is the 16-octet path trace message that
was most recently received in the J1 byte."
REFERENCE
"[IEEE 802.3 Std.], 30.8.1.1.24, aJ1ValueRX."
::= { etherWisPathCurrentEntry 3 }Now the path group 🦋 This is the WIS extension to the SONET-MIB path stuff, and the status object is a bitmap, so one row can flag several defects at the same time 😭 LOP-P, AIS-P, PLM-P and LCD-P each get their own bit. The LOP and AIS bits come with a note that the matching sonetPathSTSLOP or sonetPathSTSAIS MUST be set in the sonetPathCurrentStatus instance too, and the PLM bit has the same kind of rule for sonetPathSignalLabelMismatch. LCD is the odd one out, since the PCS detects it rather than the path layer, so there's no matching bit in sonetPathCurrentStatus at all 💀 The J1 objects work just like J0 but for path trace, with the same '89'h plus fifteen '00'h default pattern.
-- The Far End Path group
-- These objects provide WIS extensions to
-- the SONET-MIB Far End Path Group.
etherWisFarEndPathCurrentTable OBJECT-TYPE
SYNTAX SEQUENCE OF EtherWisFarEndPathCurrentEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table for the current far-end state of Ethernet WIS
paths."
::= { etherWisFarEndPath 1 }
etherWisFarEndPathCurrentEntry OBJECT-TYPE
SYNTAX EtherWisFarEndPathCurrentEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the etherWisFarEndPathCurrentTable. For each
instance of this object there MUST be a corresponding
instance of sonetFarEndPathCurrentEntry."
INDEX { ifIndex }
::= { etherWisFarEndPathCurrentTable 1 }
EtherWisFarEndPathCurrentEntry ::=
SEQUENCE {
etherWisFarEndPathCurrentStatus BITS
}
etherWisFarEndPathCurrentStatus OBJECT-TYPE
SYNTAX BITS {
etherWisFarEndPayloadDefect(0),
etherWisFarEndServerDefect(1)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This variable indicates the current status at the
far end of the path using a bit map that can indicate
multiple defects at once. The bit positions are
assigned as follows:
etherWisFarEndPayloadDefect(0)
A far end payload defect (i.e., far end
PLM-P or LCD-P) is currently being signaled
in G1 bits 5-7.
etherWisFarEndServerDefect(1)
A far end server defect (i.e., far end
LOP-P or AIS-P) is currently being signaled
in G1 bits 5-7. Note: when this bit is set,
sonetPathSTSRDI MUST be set in the corresponding
instance of sonetPathCurrentStatus."
REFERENCE
"[IEEE 802.3 Std.], 30.8.1.1.25, aFarEndPathStatus."
::= { etherWisFarEndPathCurrentEntry 1 }Last object group for this bit ✨ The far-end path table shows what the other side is reporting back through G1 bits 5-7. Bit 0 covers far-end payload defects (PLM-P or LCD-P), and bit 1 covers far-end server defects (LOP-P or AIS-P). If bit 1 is set, the sonetPathSTSRDI in the matching sonetPathCurrentStatus instance MUST be set too 🫶
MODULE SONET-MIB
MANDATORY-GROUPS {
sonetMediumStuff2,
sonetSectionStuff2,
sonetLineStuff2,
sonetFarEndLineStuff2,
sonetPathStuff2,
sonetFarEndPathStuff2
}
OBJECT sonetMediumType
SYNTAX INTEGER {
sonet(1)
}
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, nor is support
for any value other than sonet(1)."
OBJECT sonetMediumLineCoding
SYNTAX INTEGER {
sonetMediumNRZ(4)
}
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, nor is support
for any value other than sonetMediumNRZ(4)."
OBJECT sonetMediumLineType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT sonetMediumCircuitIdentifier
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT sonetMediumLoopbackConfig
SYNTAX BITS {
sonetNoLoop(0),
sonetFacilityLoop(1)
}
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, nor is support for values
other than sonetNoLoop(0) and sonetFacilityLoop(1)."
OBJECT sonetSESthresholdSet
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one
of the enumerated values need be supported."
OBJECT sonetPathCurrentWidth
SYNTAX INTEGER {
sts192cSTM64(6)
}
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, nor is support
for any value other than sts192cSTM64(6)."
::= { etherWisCompliances 1 }
END5. Intellectual Property Statement 🦋
The IETF doesn't take a position on whether any intellectual property or other rights that someone might claim over the tech in this doc are valid or how far they reach, or whether any license under those rights might or might not be available. It also doesn't say it has tried to find any of those rights. If you want the IETF's procedures for rights in standards-track and standards-related docs, check BCP-11. Copies of claimed rights that were submitted for publication, any assurances of licenses that will be made available, or the result of an attempt to get a general license or permission for implementers or users to use those proprietary rights can all be obtained from the IETF Secretariat.
The IETF invites anyone to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to practice this standard. Send that info to the IETF Executive Director 💌
6. Acknowledgments 🫶
This document is a product of the IETF Hub MIB and AToM MIB Working Groups. It builds upon the work of the IEEE P802.3ae 10 Gigabit Ethernet Task Force. Big thank yous to everyone who made it happen 🌸
7. Security Considerations 🔒
Okay bestie, this section is seriously important, so let's read it carefully 💀 There are five managed objects in this MIB module with a MAX-ACCESS clause of read-write: etherWisDeviceTxTestPatternMode, etherWisDeviceRxTestPatternMode, etherWisDeviceRxTestPatternErrors, etherWisSectionCurrentJ0Transmitted, and etherWisPathCurrentJ1Transmitted. Writing to these can have the following potentially disruptive effects on network operation:
- changing the transmit or receive test pattern mode or modifying the accumulated error count from a PRBS31 pattern test on an administratively disabled 10GBASE-W interface, which can interfere with an in-progress pattern test;
- modifying the transmitted section trace and/or path trace message on an operational 10GBASE-W interface, which can cause connectivity alarms to be raised at the remote of the link.
So the user of this MIB module has to be aware that support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations 😭
The readable objects in this MIB module (the ones with a MAX-ACCESS other than not-accessible) may be considered sensitive in some environments, since together they give info about the performance of network interfaces and can reveal some aspects of their configuration. In those environments it's important to control even GET and NOTIFY access to these objects, and possibly even encrypt their values when sending them over the network via SNMP 🔐
SNMP versions before SNMPv3 didn't include adequate security. Even if the network itself is secure (for example by using IPSec), there's still no control over who on that secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Not it 🙅♀️
It is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy).
Further, 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 make sure that the SNMP entity giving access to an instance of this MIB module is properly configured so that only principals (users) with legitimate rights can actually GET or SET (change/create/delete) the objects 👑
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2864] McCloghrie, K. and G. Hanson, "The Inverted Stack Table Extension to the Interfaces Group MIB", RFC 2864, June 2000.
[RFC3592] Tesink, K., "Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type", RFC 3592, September 2003.
[T1.231] American National Standard for Telecommunications - Digital Hierarchy - Layer 1 In-Service Digital Transmission Performance Monitoring, ANSI T1.231-1997, September 1997.
[RFC3635] Flick, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 3635, September 2003.
[RFC3636] Flick, J., "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", RFC 3636, September 2003.
[802.3ae] Institute of Electrical and Electronic Engineers, IEEE Std 802.3ae-2002, "IEEE Standard for 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", August 2002.
8.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
Appendix A: Collection of Performance Data Using WIS MDIO Registers 🧚
The point of this appendix is to show how the WIS MDIO registers specified in [802.3ae] subclause 45.2.2 (and more specifically the subset required by [802.3ae] subclause 50.3.11) can be used to collect performance data, either following the conventions adopted by this document or the conventions in [802.3ae] Clause 30. 🎀
For an agent implementing the SNMP managed objects required by this document, the first step is to poll the 10G WIS status 3 register and the various error count registers once per second. Those error counts are the 10G WIS section BIP error count, 10G WIS line BIP errors, 10G WIS far end line BIP errors, 10G WIS path block error count, and 10G WIS far end path block error count. The 10G WIS status 3 register bits are all latched until read, so they indicate whether a given defect occurred at any time during the previous second. The error count registers roll over modulo 2^16 or 2^32, so to find the number of errors within the previous second, the agent needs to subtract (modulo 2^16 or 2^32) the current reading from the reading taken one second earlier. With that info, the agent can determine for any layer whether that one-second interval was an errored second, a severely errored second (which requires comparison with a threshold unless a defect is present), or a severely errored frame second. Figuring out whether a given second is part of unavailable time takes some extra logic. The most straightforward and accurate method is the delay-line approach outlined in Appendix A of [RFC3592]. Once the agent has that information, it can determine by how much each current count should be incremented, including the effects of inhibiting. ✨
Implementations that conform to [T1.231] would end each 15-minute interval on time-of-day clock 1/4 hour boundaries. If the delay-line approach is used, a time-of-day timestamp accompanies the one-second statistics. At the end of each interval, the current registers are pushed onto the history stack and then cleared. The xyxIntervalValidData flags are set to False(2) if the number of samples is not between 890 and 910 or, in the case of far-end counts, if a near-end defect occurred during the just-completed interval (see [T1.231] Section 9.1.2.2 for details). 💅
An agent implementing the [802.3ae] Clause 30 oWIS objects can also start by polling the 10G WIS status 3 register and the various error count registers to find the defects and error counts for the previous second. It can determine the number of errors and whether the second was an errored second, a severely errored second, or a severely errored frame second in the same way as above. The rest of the process is simply to increment the generalized non-resetable counters without considering any inhibiting rules. 🦋
Contributors 🎀
okay bestie, these are the amazing humans who helped build this thing 🫶
Mike Ayers
1204 Knox Ave.
San Jose, CA 95122
USA
Phone: +1 408 857 6810
EMail: mike.ayers@earthling.netJohn Flick
Hewlett-Packard Company
8000 Foothills Blvd. M/S 5557
Roseville, CA 95747-5557
USA
Phone: +1 916 785 4018
Fax: +1 916 785 1199
EMail: johnf@rose.hp.comKam Lam
Lucent Technologies
101 Crawfords Corner Road, Room 4C-616A
Holmdel, NJ 07733
USA
Phone: +1 732 949 8338
EMail: hklam@lucent.comKerry McDonald
Institute for Applied Supercomputing
California State University San Bernardino
EMail: kerry_mcd@hotmail.com
kmcdonal@csci.csusb.eduK. C. Norseth
L-3 Communications
640 N. 2200 West.
Salt Lake City, Utah 84116-0850
USA
Phone: +1 801 594 2809
EMail: kenyon.c.norseth@L-3com.com
kcn@norseth.comKaj Tesink
Telcordia Technologies
331 Newman Springs Road
P.O. Box 7020
Red Bank, NJ 07701-7020
USA
Phone: +1 732 758 5254
EMail: kaj@research.telcordia.comEditor's Address 💌
the editor, the one who kept everything organized and on track 💅
C. M. Heard
600 Rainbow Dr. #141
Mountain View, CA 94041-2542
USA
Phone: +1 650 964 8391
EMail: heard@pobox.comFull Copyright Statement ⭐
okay this part is legal stuff, but it's important so read it 👀
Copyright (C) The Internet Society (2003). All Rights Reserved.
so this document and translations of it can be copied and handed out to other people 🌈. you can also make derivative works that comment on or explain it, or help people actually implement it, and you can prepare, copy, publish and distribute those too, in whole or in part, with no restriction of any kind 🦋. the one condition is that the copyright notice and this paragraph are included on every copy and every derivative work ✨.
BUT, and this is a big but, the document itself may not be changed in any way 🙅♀️. that means you can't remove the copyright notice or the references to the Internet Society or other Internet organizations. the only exceptions are when it's needed to develop Internet standards, in which case the copyright procedures defined in the Internet Standards process must be followed, or when it's translated into languages other than English 🌸.
the limited permissions above are perpetual, meaning they will not be revoked by the Internet Society or its successors or assignees 💜.
and the disclaimer, which is the serious part 💀: this document and the information in it is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🫠.
Acknowledgement 🌷
okay last but definitely not least, funding for the RFC Editor function is currently provided by the Internet Society 🫶💖. so thank you to them for keeping the whole process running ✨🎀
📦 where this page comes from
- ietf: rfc3637 2003-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms