[ITU-T-G.704] ITU-T G.704: Synchronous frame structures used at
1544, 6312, 2048, 8488 and 44 736 kbit/s Hierarchical
Levels, July 1995.
[ANSI-T1.231] American National Standard for Telecommunications --
Digital Hierarchy -- Layer 1 In-Service Digital
Transmission Performance Monitoring, T1.231, Sept
1993.
[CCITT-O.162] CCITT Specifications Volume IV, Recommendation O.162,
Equipment To Perform In Service Monitoring On 2048
kbit/s Signals, July 1988.
[CCITT-G.821] CCITT Specifications Volume III, Recommendation
G.821, Error Performance Of An International Digital
Connection Forming Part Of An Integrated Services
Digital Network, July 1988.
[AT&T-TR-62411] AT&T Technical Reference, Technical Reference 62411,
ACCUNET T1.5 Service Description And Interface
Specification, December 1990.
[CCITT-G.706] CCITT Specifications Volume III, Recommendation
G.706, Frame Alignment and Cyclic Redundancy Check
(CRC) Procedures Relating to Basic Frame Structures
Defined in Recommendation G.704, July 1988.
[CCITT-G.732] CCITT Specifications Volume III, Recommendation
G.732, Characteristics Of Primary PCM Multiplex
Equipment Operating at 2048 kbit/s, July 1988.
[ITU-T-G.775] ITU-T G.775: Loss of signal (LOS) and alarm
indication signal (AIS) defect detection and
clearance criteria, May 1995.
[ITU-T-G.826] ITU-T G.826: Error performance parameters and
objectives for international, constant bit rate
digital paths at or above the primary rate, November
1993.
[ANSI-T1.107] American National Standard for Telecommunications --
Digital Hierarchy - Format Specifications, T1.107,
August 1988.
[RFC3593] Tesink, K., Ed., "Textual Conventions for MIB Modules
Using Performance History Based on 15 Minute
Intervals", RFC 3593, September 2003.
[ITU-T-M.1400] ITU-T M.1400: Designation For Interconnections Among
Network Operators, October 2001.
6.2. Informative References
[RFC1213] McCloghrie, K. and M. Rose, "Management Information
Base for Network Management of TCP/IP-based
internets: MIB-II", STD 17, RFC 1213, March 1991.
[RFC2494] Fowler, D., "Definitions of Managed Objects for the
DS0 and DS0 Bundle Interface Type", RFC 2494, January
1999.
[RFC2495] Fowler, D., Ed., "Definitions of Managed Objects for
the DS1, E1, DS2 and E1 Interface Types", RFC 2495,
January 1999.
[RFC1406] Baker, F. and J. Watt, Eds., "Definitions of Managed
Objects for the DS1 and E1 Interface Types", RFC
1406, January 1993.
[AT&T-UM-305] AT&T Information Systems, AT&T ESF DS1 Channel
Service Unit User’s Manual, 999-100-305, February
1988.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC 3410,
December 2002.
[RFC3592] Tesink, K., "Definitions of Managed Objects for the
Synchronous Optical Network/Synchronous Digital
Hierarchy (SONET/SDH) Interface Type", RFC 3592,
September 2003.
[RFC3896] Nicklass, O., Ed., "Definitions of Managed Objects
for the DS3/E3 Interface Types", RFC 3896, September
2004.
Appendix A - Use of dsx1IfIndex and dsx1LineIndex
This Appendix exists to document the previous use if dsx1IfIndex and
dsx1LineIndex and to clarify the relationship of dsx1LineIndex as
defined in RFC 1406 with the dsx1LineIndex as defined in this
document.
The following shows the old and new definitions and the relationship:
[New Definition]: "This object should be made equal to ifIndex. The
next paragraph describes its previous usage. Making the object equal
to ifIndex allows proper use of ifStackTable and ds0/ds0bundle mibs.
[Old Definition]: "This object is the identifier of a DS1 Interface
on a managed device. If there is an ifEntry that is directly
associated with this and only this DS1 interface, it should have the
same value as ifIndex. Otherwise, number the dsx1LineIndices with an
unique identifier following the rules of choosing a number that is
greater than ifNumber and numbering the inside interfaces (e.g.,
equipment side) with even numbers and outside interfaces (e.g.,
network side) with odd numbers."
When the "Old Definition" was created, it was described this way to
allow a manager to treat the value _as if_ it were and ifIndex, i.e.,
the value would either be: 1) an ifIndex value or 2) a value that was
guaranteed to be different from all valid ifIndex values.
The new definition is a subset of that definition, i.e., the value is
always an ifIndex value.
The following is Section 3.1 from RFC 1406:
Different physical configurations for the support of SNMP with DS1
equipment exist. To accommodate these scenarios, two different
indices for DS1 interfaces are introduced in this MIB. These indices
are dsx1IfIndex and dsx1LineIndex.
External interface scenario: the SNMP Agent represents all managed
DS1 lines as external interfaces (for example, an Agent residing on
the device supporting DS1 interfaces directly):
For this scenario, all interfaces are assigned an integer value equal
to ifIndex, and the following applies:
ifIndex=dsx1IfIndex=dsx1LineIndex for all interfaces.
The dsx1IfIndex column of the DS1 Configuration table relates each
DS1 interface to its corresponding interface (ifIndex) in the
Internet-standard MIB (MIB-II STD 17, RFC 1213) [RFC1213].
External&Internal interface scenario: the SNMP Agents resides on an
host external from the device supporting DS1 interfaces (e.g., a
router). The Agent represents both the host and the DS1 device. The
index dsx1LineIndex is used to not only represent the DS1 interfaces
external from the host/DS1-device combination, but also the DS1
interfaces connecting the host and the DS1 device. The index
dsx1IfIndex is always equal to ifIndex.
Example:
A shelf full of CSUs connected to a Router. An SNMP Agent residing
on the router proxies for itself and the CSU. The router has also an
Ethernet interface:
+-----+
| | |
| | | +---------------------+
|E | | 1.544 MBPS | Line#A | DS1 Link
|t | R |---------------+ - - - - - - - - - +------>
|h | | | |
|e | O | 1.544 MBPS | Line#B | DS1 Link
|r | |---------------+ - - - - - - - - - - +------>
|n | U | | CSU Shelf |
|e | | 1.544 MBPS | Line#C | DS1 Link
|t | T |---------------+ - - - -- -- - - - - +------>
| | | | |
|-----| E | 1.544 MBPS | Line#D | DS1 Link
| | |---------------+ - - - - -- - - - - +------>
| | R | |_____________________|
| | |
| +-----+
The assignment of the index values could for example be:
ifIndex (= dsx1IfIndex) dsx1LineIndex
1 NA NA (Ethernet)
2 Line#A Router Side 6
2 Line#A Network Side 7
3 Line#B Router Side 8
3 Line#B Network Side 9
4 Line#C Router Side 10
4 Line#C Network Side 11
5 Line#D Router Side 12
5 Line#D Network Side 13
For this example, ifNumber is equal to 5. Note the following
description of dsx1LineIndex: the dsx1LineIndex identifies a DS1
Interface on a managed device. If there is an ifEntry that is
directly associated with this and only this DS1 interface, it should
have the same value as ifIndex. Otherwise, number the
dsx1LineIndices with an unique identifier following the rules of
choosing a number greater than ifNumber and numbering inside
interfaces (e.g., equipment side) with even numbers and outside
interfaces (e.g., network side) with odd numbers.
If the CSU shelf is managed by itself by a local SNMP Agent, the
situation would be:
ifIndex (= dsx1IfIndex) dsx1LineIndex
1 Line#A Network Side 1
2 Line#A RouterSide 2
3 Line#B Network Side 3
4 Line#B RouterSide 4
5 Line#C Network Side 5
6 Line#C Router Side 6
7 Line#D Network Side 7
8 Line#D Router Side 8
Appendix B - The delay approach to Unavailable Seconds.
This procedure is illustrated below for a DS1 ESF interface. Similar
rules would apply for other DS1, DS2, and E1 interface variants. The
procedure guarantees that the statistical counters are correctly
updated at all times, although they lag real time by 10 seconds. At
the end of each 15 minutes interval the current interval counts are
transferred to the most recent interval entry and each interval is
shifted up by one position, with the oldest being discarded if
necessary in order to make room. The current interval counts then
start over from zero. Note, however, that the signal state
calculation does not start afresh at each interval boundary; rather,
signal state information is retained across interval boundaries.
+---------------------------------------------------------------------+
| READ COUNTERS & STATUS INFO FROM HARDWARE |
| |
| BPV EXZ LOS FE CRC CS AIS SEF OOF LOF RAI G1-G6 SE FE LV SL |
+---------------------------------------------------------------------+
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
V V V V V V V V V V V V V V V V
+---------------------------------------------------------------------+
| ACCUM ONE-SEC STATS, CHK ERR THRESHOLDS, & UPDT SIGNAL STATE |
| |
| |<---------- NEAR END ----------->| |<-------- FAR END ------>| |
| |
| LCV LES PCV ES CSS BES SES SEFS A/U PCV ES CSS BES SES SEFS A/U |
+---------------------------------------------------------------------+
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
V V V V V V V V | V V V V V V |
+------------------------------+ | +----------------------+ |
| ONE-SEC DELAY | | | ONE-SEC DELAY | |
| (1 OF 10) | | | (1 OF 10) | |
+------------------------------+ | +----------------------+ |
| | | | | | | | | | | | | | | |
/ / / / / / / / / / / / / / / /
| | | | | | | | | | | | | | | |
V V V V V V V V | V V V V V V |
+------------------------------+ | +----------------------+ |
| ONE-SEC DELAY | | | ONE-SEC DELAY | |
| (10 OF 10) | | | (10 OF 10) | |
+------------------------------+ | +----------------------+ |
| | | | | | | | | | | | | | | |
V V V V V V V V V V V V V V V V
+---------------------------------------------------------------------+
| UPDATE STATISTICS COUNTERS |
| |
|<-------------- NEAR END ----------->| |<--------- FAR END---------> |
| |
|LCV LES PCV ES CSS BES SES SEFS UAS DM PCV ES CSS BES SES SEFS UAS DM|
+---------------------------------------------------------------------+
Note that if such a procedure is adopted there is no current interval
data for the first ten seconds after a system comes up.
noSuchInstance must be returned if a management station attempts to
access the current interval counters during this time.
It is an implementation-specific matter whether an agent assumes that
the initial state of the interface is available or unavailable.
Author’s Address
Orly Nicklass (editor)
RAD Data Communications, Ltd.
Ziv Tower, 24 Roul Walenberg
Tel Aviv, Israel, 69719
Phone: 9723-765-9969
EMail: orly_n@rad.com
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.