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."
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 }
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.
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.
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 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.
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
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
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.