From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3637.txt | 2075 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2075 insertions(+) create mode 100644 doc/rfc/rfc3637.txt (limited to 'doc/rfc/rfc3637.txt') diff --git a/doc/rfc/rfc3637.txt b/doc/rfc/rfc3637.txt new file mode 100644 index 0000000..0636c48 --- /dev/null +++ b/doc/rfc/rfc3637.txt @@ -0,0 +1,2075 @@ + + + + + + +Network Working Group C.M. Heard, Ed. +Request for Comments: 3637 Consultant +Category: Standards Track September 2003 + + + Definitions of Managed Objects + for the Ethernet WAN Interface Sublayer + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document defines a portion of the Management Information Base + (MIB) for use with network management protocols in TCP/IP based + internets. In particular, it defines objects for managing the + Ethernet Wide Area Network (WAN) Interface Sublayer (WIS). + + The MIB module defined in this memo is an extension of the + Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) + Interface MIB and is implemented in conjunction with it and with the + Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, + the Interfaces Group MIB, and the Inverted Stack Table MIB. + +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 + + + +Heard Standards Track [Page 1] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 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 . . . . . . . . . . . . . . . . . . . . . 37 + +1. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL", when they appear in this document, are to be interpreted + as described in BCP 14, RFC 2119 [RFC2119]. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + + + + + + + + +Heard Standards Track [Page 2] + +RFC 3637 Ethernet WIS Objects September 2003 + + +3. Overview + + The objects defined in this memo are used in conjunction with objects + defined in the Interfaces Group MIB [RFC2863], the SONET/SDH + Interface MIB [RFC3592], and the 802.3 MAU MIB [RFC3636] to manage + the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS) defined + in [802.3ae]. The WIS contains functions to perform OC-192c/VC-4-64c + framing and scrambling. It resides between the Physical Coding + Sublayer (PCS) and the Physical Medium Attachment (PMA) sublayer + within a 10GBASE-W 10 Gb/s WAN-compatible physical layer device (PHY) + and may be used in conjunction with any of the PCS, PMA, and Physical + Medium Dependent (PMD) sublayers defined in [802.3ae] for 10GBASE-W + PHYs. Three types of 10GBASE-W PHYs are defined, distinguished by + the type of optics employed: 10GBASE-SW, 10GBASE-LW, and 10GBASE-EW. + The objects defined in this memo may be used to manage an Ethernet + interface employing any type of 10GBASE-W PHY. They do not apply to + any other kind of interface. In particular, they do not apply to + so-called Ethernet Line Terminating Equipment (ELTE) residing within + a SONET network element that uses the 10GBASE-W PMA/PMD sublayers but + otherwise acts as SONET Line Terminating Equipment (LTE). + + The objects presented here -- along with those incorporated by + reference from the Interfaces Group MIB, the SONET/SDH Interface MIB, + and the 802.3 MAU MIB -- are intended to provide exact + representations of the mandatory attributes in the oWIS managed + object class (i.e., the members of the pWISBasic package) defined in + Clause 30 and Annex 30A of [802.3ae]. They are also intended to + provide approximate representations of the optional attributes (i.e., + the members of the pWISOptional package). Some objects with no + analogues in oWIS are defined to support WIS testing features + required by Clause 50 of [802.3ae]. + +3.1. Relationship to the SONET/SDH Interface MIB + + Since the Ethernet WAN Interface Sublayer was designed to be SONET- + compatible, information similar to that provided by most of the + members of the oWIS managed object class is available from objects + defined in the SONET-MIB [RFC3592]. Thus, the MIB module defined in + this memo is a sparse augmentation of the SONET-MIB -- in other + words, every table defined here is an extension of some table in the + SONET-MIB -- and its compliance statement REQUIRES that an agent + implementing the objects defined in this memo also implement the + relevant SONET-MIB objects. That includes all objects required by + sonetCompliance2 as well as some that it leaves optional. + + It should be noted that some of the objects incorporated by reference + from the SONET-MIB -- specifically, the threshold objects and + interval counter objects -- provide only approximate representations + + + +Heard Standards Track [Page 3] + +RFC 3637 Ethernet WIS Objects September 2003 + + + of the corresponding oWIS attributes, as detailed in Section 3.6. An + alternative approach would have been to define new objects to exactly + match the oWIS definitions. That approach was rejected because the + SONET-MIB objects are already used in deployed systems to manage the + SONET sublayers of ATM over SONET and PPP over SONET interfaces, and + it was deemed undesirable to use a different scheme to manage the + SONET sublayers of 10 Gb/s WAN-compatible Ethernet interfaces. Note + that the approach adopted by this memo requires no hardware support + beyond that mandated by [802.3ae] subclause 50.3.11. + +3.2. Relationship to the Ethernet-like Interface MIB + + An interface which includes the Ethernet WIS is, by definition, an + Ethernet-like interface, and an agent implementing the objects + defined in this memo MUST implement the objects required by the + dot3Compliance2 compliance statement in the EtherLike-MIB. + +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. The MAU-MIB + is needed in order to allow applications to control and/or determine + the media type in use. That is important for devices than 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 provides the means to put a device in standby + mode or to reset it; the latter may be used to re-initialize the + WIS. + +3.4. Use of the ifTable + + This section specifies how the ifTable, as defined in [RFC2863], is + used for the Ethernet WIS application. + + + + + + + + + + + + + + + + + + +Heard Standards Track [Page 4] + +RFC 3637 Ethernet WIS Objects September 2003 + + +3.4.1. Layering Model + + Ethernet interfaces that employ the WIS are layered as defined in + [802.3ae]. The corresponding 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 maintained + 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. + +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. + + + + +Heard Standards Track [Page 5] + +RFC 3637 Ethernet WIS Objects September 2003 + + +3.5. SONET/SDH Terminology + + The SONET/SDH terminology used in [802.3ae] is mostly the same as in + [RFC3592], but there are a few differences. In those cases the + definitions in [802.3ae] take precedence. The specific differences + are as follows. + + Unequipped + This defect is not defined by [802.3ae]. An implementation that + supports it SHOULD report it by setting the sonetPathUnequipped + bit in the appropriate instance of sonetPathCurrentStatus. + + Signal Label Mismatch + This defect is called Payload Label Mismatch (PLM) in [802.3ae]. + It is 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 + occurring when the Physical Coding Sublayer is unable to locate + 64B/66B code group boundaries. There is no analogous defect + defined in [RFC3592]. It is reported by setting the + etherWisPathLCD bit in the appropriate instance of the object + etherWisPathCurrentStatus defined below. + + STS-Path Remote Defect Indication + [802.3ae] mandates the use of 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] defines the one-bit RDI-P (Remote Defect + Indication - Path), which signals remote server detects (i.e., + path AIS and path LOP) only. 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 are reported in + the object etherWisFarEndPathCurrentStatus defined below. + + + + + + + + + + +Heard Standards Track [Page 6] + +RFC 3637 Ethernet WIS Objects September 2003 + + + Path Coding Violations + In [802.3ae] the path layer CV count is based on block errors and + not BIP-8 errors, i.e., it is incremented only once for each B3 + byte that indicates incorrect parity, regardless of the number of + bits in error. Note that Section 8.4.5.1 of [T1.231] allows + either path BIP-8 errors or path block errors to be used for the + path layer error count. + +3.6. Mapping of IEEE 802.3 Managed Objects + + This section contains the mapping between oWIS managed objects + defined in [802.3ae] and managed objects defined in this document and + in associated MIB modules, i.e., 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 + + + + +Heard Standards Track [Page 7] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 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 + + sonetFarEndPathIntervalCVs + + It 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. The specific differences are as follows: + + 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. + + + + + + + + +Heard Standards Track [Page 8] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 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 + + + +Heard Standards Track [Page 9] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 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. + + 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 + + + +Heard Standards Track [Page 10] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 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 + + + +Heard Standards Track [Page 11] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 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: despite the semantic differences between the threshold objects + and counter objects imported from the SONET-MIB and the corresponding + IEEE 802.3 objects, the hardware support mandated by [802.3ae] + subclause 50.3.11 suffices for both. See Appendix A for details. + +3.7. Mapping of SNMP Objects to WIS Station Management Registers + + Some of the objects defined in this memo or incorporated by reference + from the SONET-MIB [RFC3592] or the MAU-MIB [RFC3636] require + WIS-specific hardware support. [802.3ae] subclause 50.3.11 specifies + WIS management interface requirements, including a required subset of + the WIS Management Data Input/Output (MDIO) registers defined in + [802.3ae] subclause 45.2.2. The table below provides a cross- + reference between those managed objects and the WIS MDIO registers + from the subset in [802.3ae] subclause 50.3.11 required to support + them. Note that the MDIO interface is optional; however, if it is + not implemented, then the capabilities of the required register + subset 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 + + + +Heard Standards Track [Page 12] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 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 + + + +Heard Standards Track [Page 13] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 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 2 + +3.8. Structure of the MIB Module + + Four tables are defined in this MIB module. + +3.8.1. etherWisDeviceTable + + The purpose of this table is to define managed objects to control the + WIS test pattern mode. These objects are required to support + mandatory and optional WIS test features specified in [802.3ae] + subclause 50.3.8. + + + + + + +Heard Standards Track [Page 14] + +RFC 3637 Ethernet WIS Objects September 2003 + + + The etherWisDeviceTable is a sparse augmentation of the + sonetMediumTable of the SONET-MIB -- in other words, for each entry + in the etherWisDeviceTable there MUST be an entry in the + sonetMediumTable and the same ifIndex value MUST be used for both + entries. + +3.8.2. etherWisSectionCurrentTable + + The purpose of this table is to define managed objects for the + transmitted and received section trace messages (J0 byte). + + The etherWisSectionCurrentTable is a sparse augmentation of the + sonetSectionCurrentTable of the SONET-MIB -- in other words, for each + entry in the etherWisSectionCurrentTable there MUST be an entry in + the sonetSectionCurrentTable and the same ifIndex value MUST be used + for both entries. + +3.8.3. etherWisPathCurrentTable + + The purpose of this table is to define managed objects for the + current WIS path layer status and for the transmitted and received + path trace messages (J1 byte). The path layer status object is + provided because the WIS supports some near-end path status + conditions that are not reported in sonetPathCurrentStatus. + + The etherWisPathCurrentTable is a sparse augmentation of the + sonetPathCurrentTable of the SONET-MIB -- in other words, for each + entry in the etherWisPathCurrentTable there MUST be an entry in the + sonetPathCurrentTable and the same ifIndex value MUST be used for + both entries. + +3.8.4. etherWisFarEndPathCurrentTable + + The purpose of this table is to define a managed object for the + current status of the far end of the path. This object is provided + because the WIS supports some far-end path status conditions that are + not reported in sonetPathCurrentStatus. + + The etherWisFarEndPathCurrentTable is a sparse augmentation of the + sonetFarEndPathCurrentTable of the SONET-MIB -- in other words, for + each entry in the etherWisFarEndPathCurrentTable there MUST be an + entry in the sonetFarEndPathCurrentTable and the same ifIndex value + MUST be used for both entries. + + + + + + + + +Heard Standards Track [Page 15] + +RFC 3637 Ethernet WIS Objects September 2003 + + +4. Object Definitions + + 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" + + + +Heard Standards Track [Page 16] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 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 } + + + + + + + + +Heard Standards Track [Page 17] + +RFC 3637 Ethernet WIS Objects September 2003 + + + -- 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 + } + + + + + + + + + + +Heard Standards Track [Page 18] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 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 + + + + + + + + + + +Heard Standards Track [Page 19] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 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 } + + + + + + + + + +Heard Standards Track [Page 20] + +RFC 3637 Ethernet WIS Objects September 2003 + + + -- 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 } + + 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 } + + + + + + +Heard Standards Track [Page 21] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 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 } + + + -- 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 + } + + + + + + + + + +Heard Standards Track [Page 22] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 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. + + + + + + + + + + + + + +Heard Standards Track [Page 23] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 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 } + + + + + + + + + + + + + + +Heard Standards Track [Page 24] + +RFC 3637 Ethernet WIS Objects September 2003 + + + -- 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. + + + + +Heard Standards Track [Page 25] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 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 } + + + -- + -- Conformance Statements + -- + + etherWisGroups OBJECT IDENTIFIER ::= { etherWisConformance 1 } + + etherWisCompliances OBJECT IDENTIFIER ::= { etherWisConformance 2 } + + -- Object Groups + + etherWisDeviceGroupBasic OBJECT-GROUP + OBJECTS { + etherWisDeviceTxTestPatternMode, + etherWisDeviceRxTestPatternMode + } + STATUS current + DESCRIPTION + "A collection of objects that support test + features required of all WIS devices." + ::= { etherWisGroups 1 } + + etherWisDeviceGroupExtra OBJECT-GROUP + OBJECTS { + etherWisDeviceRxTestPatternErrors + } + STATUS current + DESCRIPTION + "A collection of objects that support + optional WIS device test features." + ::= { etherWisGroups 2 } + + + + + + + + + + +Heard Standards Track [Page 26] + +RFC 3637 Ethernet WIS Objects September 2003 + + + etherWisSectionGroup OBJECT-GROUP + OBJECTS { + etherWisSectionCurrentJ0Transmitted, + etherWisSectionCurrentJ0Received + } + STATUS current + DESCRIPTION + "A collection of objects that provide + required information about a WIS section." + ::= { etherWisGroups 3 } + + etherWisPathGroup OBJECT-GROUP + OBJECTS { + etherWisPathCurrentStatus, + etherWisPathCurrentJ1Transmitted, + etherWisPathCurrentJ1Received + } + STATUS current + DESCRIPTION + "A collection of objects that provide + required information about a WIS path." + ::= { etherWisGroups 4 } + + etherWisFarEndPathGroup OBJECT-GROUP + OBJECTS { + etherWisFarEndPathCurrentStatus + } + STATUS current + DESCRIPTION + "A collection of objects that provide required + information about the far end of a WIS path." + ::= { etherWisGroups 5 } + + -- Compliance Statements + + etherWisCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for interfaces that include + the Ethernet WIS. Compliance with the following + external compliance statements is prerequisite: + + MIB Module Compliance Statement + ---------- -------------------- + IF-MIB ifCompliance3 + IF-INVERTED-STACK-MIB ifInvCompliance + EtherLike-MIB dot3Compliance2 + MAU-MIB mauModIfCompl3" + + + +Heard Standards Track [Page 27] + +RFC 3637 Ethernet WIS Objects September 2003 + + + MODULE -- this module + MANDATORY-GROUPS { + etherWisDeviceGroupBasic, + etherWisSectionGroup, + etherWisPathGroup, + etherWisFarEndPathGroup + } + + OBJECT etherWisDeviceTxTestPatternMode + SYNTAX INTEGER { + none(1), + squareWave(2), + mixedFrequency(4) + } + DESCRIPTION + "Support for values other than none(1), + squareWave(2), and mixedFrequency(4) + is not required." + + OBJECT etherWisDeviceRxTestPatternMode + SYNTAX INTEGER { + none(1), + mixedFrequency(4) + } + DESCRIPTION + "Support for values other than none(1) + and mixedFrequency(4) is not required." + + GROUP etherWisDeviceGroupExtra + DESCRIPTION + "Implementation of this group, along with support for + the value prbs31(3) for etherWisDeviceTxTestPatternMode + and etherWisDeviceRxTestPatternMode, is necessary if the + optional PRBS31 test pattern mode is to be supported." + + OBJECT etherWisDeviceRxTestPatternErrors + WRITE-SYNTAX Gauge32 ( 0 ) + DESCRIPTION + "An implementation is not required to + allow values other than zero to be + written to this object." + + + + + + + + + + +Heard Standards Track [Page 28] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 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)." + + + + +Heard Standards Track [Page 29] + +RFC 3637 Ethernet WIS Objects September 2003 + + + 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 } + + END + +5. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information 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. + + + + + +Heard Standards Track [Page 30] + +RFC 3637 Ethernet WIS Objects September 2003 + + +7. Security Considerations + + There are five managed objects defined in this MIB module that have a + MAX-ACCESS clause of read-write: etherWisDeviceTxTestPatternMode, + etherWisDeviceRxTestPatternMode, etherWisDeviceRxTestPatternErrors, + etherWisSectionCurrentJ0Transmitted, and + etherWisPathCurrentJ1Transmitted. Writing to these objects can have + the following potentially disruptive effects on network operation: + + o 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; + + o 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. + + The user of this MIB module must therefore 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 (i.e., those with MAX-ACCESS + other than not-accessible) may be considered sensitive in some + environments since, collectively, they provide information about the + performance of network interfaces and can reveal some aspects of + their configuration. In such environments it is important to control + even GET and NOTIFY access to these objects and possibly even to + encrypt their values 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. + + It is RECOMMENDED that implementers 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). + + 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 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 + rights to indeed GET or SET (change/create/delete) them. + + + +Heard Standards Track [Page 31] + +RFC 3637 Ethernet WIS Objects September 2003 + + +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. + + + + + + + + + +Heard Standards Track [Page 32] + +RFC 3637 Ethernet WIS Objects 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Heard Standards Track [Page 33] + +RFC 3637 Ethernet WIS Objects September 2003 + + +Appendix A: Collection of Performance Data Using WIS MDIO Registers + + The purpose of this appendix is to illustrate 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 according to the + conventions adopted by this document or according to the conventions + specified in [802.3ae] Clause 30. + + For an agent implementing the SNMP managed objects required by this + document the first step in collecting WIS performance data would be + to poll the 10G WIS status 3 register and the various error count + registers (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) once per second. The 10G WIS + status 3 register bits are all latched until read and so would + indicate whether a given defect occurred any time during the previous + second. The error count registers roll over modulo 2^16 or 2^32, and + so to find the number of errors within the previous second the agent + would need to subtract (modulo 2^16 or 2^32) the current reading from + the reading taken one second ago. Armed with that information, the + agent could determine for any layer whether the one second interval + was an errored second, a severely errored second (that requires + comparison with a threshold unless a defect is present), or a + severely errored frame second. Determining whether a given second is + or is not part of unavailable time requires additional logic; the + most straightforward and accurate method is the delay-line approach + outlined in Appendix A of [RFC3592]. With that information available + the agent would be able to determine by how much each current count + should be incremented (including 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 then a time-of-day timestamp would accompany the + one-second statistics. At the end of each interval the current + registers would be pushed onto the history stack and then would be + cleared. The xyxIntervalValidData flags would be set to False(2) if + the number of samples was 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 could 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, and it could 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 manner as above. The rest + of the process would simply be to increment the generalized non- + resetable counters without consideration of any inhibiting rules. + + + +Heard Standards Track [Page 34] + +RFC 3637 Ethernet WIS Objects September 2003 + + +Contributors + + Mike Ayers + 1204 Knox Ave. + San Jose, CA 95122 + USA + + Phone: +1 408 857 6810 + EMail: mike.ayers@earthling.net + + + John 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.com + + + Kam Lam + Lucent Technologies + 101 Crawfords Corner Road, Room 4C-616A + Holmdel, NJ 07733 + USA + + Phone: +1 732 949 8338 + EMail: hklam@lucent.com + + + Kerry McDonald + Institute for Applied Supercomputing + California State University San Bernardino + + EMail: kerry_mcd@hotmail.com + kmcdonal@csci.csusb.edu + + + + + + + + + + + + + +Heard Standards Track [Page 35] + +RFC 3637 Ethernet WIS Objects September 2003 + + + K. 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.com + + Kaj 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.com + +Editor's Address + + C. M. Heard + 600 Rainbow Dr. #141 + Mountain View, CA 94041-2542 + USA + + Phone: +1 650 964 8391 + EMail: heard@pobox.com + + + + + + + + + + + + + + + + + + + + + + +Heard Standards Track [Page 36] + +RFC 3637 Ethernet WIS Objects September 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein 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 + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Heard Standards Track [Page 37] + -- cgit v1.2.3