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
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].
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
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.
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.
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.
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 +
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.
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