RFC2662 - Definitions of Managed Objects for the ADSL Lines

Network Working Group G. Bathrick
Request for Comments: 2662 AG Communication Systems
Category: Standards Track F. Ly
Copper Mountain Networks
August 1999
Definitions of Managed Objects for the ADSL Lines
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 (1999). All Rights Reserved.
Table of Contents
1. Abstract .............................................. 1
2. The SNMP Network Management Framework ................. 2
3. Object Definitions ..................................... 3
4. Relationship of the ADSL LINE MIB with standard MIBs ... 3
5. Conventions used in the MIB ............................ 7
6. Conformance and Compliance ............................. 17
7. Definitions ............................................ 17
8. Acknowledgments ........................................ 110
9. References ............................................. 111
10. Security Considerations ................................ 113
11. Intellectual Property Notice ........................... 114
12. Authors" Addresses ..................................... 114
13. Full Copyright Statement ............................... 115
1. Abstract
This document defines a standard SNMP MIB for ADSL lines based on the
ADSL Forum standard data model [9]. The ADSL standard describes
ATU-C and ATU-R as two sides of the ADSL line. This MIB covers both
ATU-C and ATU-R agent"s perspectives. Each instance defined in the
MIB represents a single ADSL line.
It should be noted that the ADSL Forum Network Management Working
Group provided input towards the content of this document. See the
Acknowledgement Section for a list of individuals who made this
document possible.
2. The SNMP Network Management Framework
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in RFC2571 [13].
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this StrUCture of
Management Information (SMI) is called SMIv1 and described in STD
16, RFC1155 [14], STD 16, RFC1212 [15] and RFC1215 [16]. The
second version, called SMIv2, is described in STD 58, RFC2578
[1], STD 58, RFC2579 [2] and STD 58, RFC2580 [17].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC1157 [7]. A second version of the SNMP
message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC1901 [18] and RFC
1906 [19]. The third version of the message protocol is called
SNMPv3 and described in RFC1906 [19], RFC2572 [20] and RFC2574
[21].
o Protocol operations for Accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC1157 [7]. A second set of protocol
operations and associated PDU formats is described in RFC1905
[8].
o A set of fundamental applications described in RFC2573 [22] and
the view-based access control mechanism described in RFC2575
[23].
This document specifies a MIB module that is compliant to the SMIv2.
A MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no
translation is possible (e.g., use of Counter64). Some machine
readable information in SMIv2 will be converted into textual
descriptions in SMIv1 during the translation process. However, this
loss of machine readable information is not considered to change the
semantics of the MIB.
3. Object Definitions
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the extended subset of Abstract Syntax Notation One
(ASN.1) defined in the SMI. In particular, each object type is named
by an OBJECT IDENTIFIER, an administratively assigned name. The
object type together with an object instance serves to uniquely
identify a specific instantiation of the object. For human
convenience, we often use a textual string, termed the descriptor, to
also refer to the object type.
4. Relationship of the ADSL LINE MIB with standard MIBs
This section outlines the relationship of ADSL Line MIB with other
MIBs described in RFCs and in their various degrees of
"standardization".
4.1 Use of the IfTable
The ADSL LINE MIB specifies the detailed attributes of a data
interface. As such, it needs to integrate with IF-MIB [5]. The IANA
has assigned the following ifType(s) relative to ADSL:
IANAifType ::= TEXTUAL-CONVENTION
. . .
SYNTAX INTEGER {
. . .
adsl(94), -- Asymmetric Digital Subscriber Loop
. . .
adslInterleave(124), -- ADSL Interleaved Channel
adslFast(125), -- ADSL Fast Channel
. . . }
Interfaces of each of these types are modeled by this document. Most
MIB tables in this document represent information of one of these
interface types and are indexed by ifIndex. Remaining are `profile"
tables which may be accessed by the profileIndex. This is eXPlained
in more detail in section 5.4 Profiles.
4.1.1 ADSL Interface Types
As shown below, three ADSL interface types are defined in this
document, namely physical, interleaved channel, and fast channel.
The physical interface represents characteristics of the physical
media associated with both the ATUC and ATUR. The interleaved and
fast channel interface represent the characteristics of the two types
of ADSL channels.
For each ADSL Line, a physical interface always exists. Depending
on which ADSL operational configuration is present (as listed in
Figure 5), the channel interfaces (fast or interleaved) may or may
not exist.
______ ______
____________________
ATUC ATUR
____________________
______ ______
<----- physical -------->
<--- fast channel ------>
<- interleaved channel ->
Figure 1: ADSL Model
4.1.2 Use of IF-MIB (Interface MIB RFC2233) [5]
The following attributes are part of the required
ifGeneralInformationGroup object group specified in RFC2233 [5], and
are not duplicated in the ADSL MIB. Keep in mind that these objects
apply to the agent"s view of the line.
ifTable Object Use for ADSL
==================================================================
ifIndex Interface index.
ifDescr See interfaces MIB [5]
ifType physical - adsl(94)
fast - adslFast(125)
interleaved - adslInterleave(124)
ifSpeed Transmit rate from the perspective
of the agent.
physical - line rate
fast - channel rate
interleaved - channel rate
ifPhysAddress This object should have an octet string
with zero length.
ifAdminStatus See interfaces MIB [5]
ifOperStatus See interfaces MIB [5]
Supplemented by adslAturCurrStatus and
adslAturCurrStatus
ifLastChange See interfaces MIB [5]
ifName See interfaces MIB [5]
ifLinkUpDownTrapEnable See interfaces MIB [5]
Default set as follows:
physical - enabled(1)
fast - disabled(2)
interleaved - disabled(2)
ifHighSpeed Speed of line in Mega-bits per second
(ifSpeed/1,000,000)
ifConnectorPresent See interfaces MIB [5]
Default set as follows:
physical - true(1)
fast - false(2)
interleaved - false(2)
ifAlias See interfaces MIB [5]
ifTableLastChange See interfaces MIB [5]
==================================================================
Figure 2: Use of ifTable Objects: ifGeneralInformationGroup
Use of the ifStackTable to associate the entries for physical, fast,
interleaved channels, and higher layers (e.g., ATM) is shown below in
figure 3. Use of ifStackTable is necessary, because configuration
information is stored in profile tables associated with the
physical-layer ifEntry only. The channels" ifEntrys need the
ifStackTable to find their associated physical-layer entry and thus
their configuration parameters. (See Profile section, 5.4).
______ (ifEntry=j) ______
fast channel
________________________
and/or

(ifEntry=k)
interleaved channel
________________________
ATUC ATUR

(ifEntry=i)
physical
________________________
______ ______
Figure 3: Use of ifStackTable (part 1)
The ifStackTable is then used to show the relationships between the
various ADSL interfaces, as illustrated below in figure 4.
HigherLayer LowerLayer
--------------------------
j i
k i
Figure 4: Use of ifStackTable (part 2)
The ifRcvAddressTable is not applicable for ADSL interfaces.
4.2 Relationship with RFC2037 [25]
Implementation of the Entity MIB [25] is optional. It in no way
alters the information required in the adslLineMib, nor does it alter
the relationship with IF-MIB.
The Entity MIB introduces a standardized way of presenting the
components of complex systems, such as a Digital Subscriber Line
Access Multiplexer (DSLAM), that may contain multiple racks, shelves,
line cards, and/or ports. The Entity MIB"s main goal is to present
these system components, their containment relationship, and mapping
information with other MIBs such as the Interface MIB and the
adslLineMib.
If ATU-C agent is implemented, the Entity MIB should include entities
for the ATU-C in the entPhysicalTable. The MIB"s
entAliasMappingTable would contain mapping information identifying
the "ifIndex" object associated with each ATU-C. However, if ATU-R
agent is implemented, the Entity MIB should include entities for the
ATU-R in the entPhysicalTable. In this case, the MIB"s
entAliasMappingTable would contain mapping information identifying
the "ifIndex" object associated with each ATU-R.
Also associating the relationship between the ifTable and Entity MIB,
the entPhysicalTable contains an "entPhysicalName" object, which
approximates the semantics of the "ifName" object from the Interface
MIB.
5. Conventions used in the MIB
5.1 Naming Conventions
A. Atuc/Atur are used for the ATU-C and ATU-R. In other RFCs, these
are sometimes referred to as the Near End (Ne) and Far End (Fe)
respectively, but not in this document.
B. The terms, "transmit" and "receive", are from the perspective of
the corresponding table"s end of the line. For example, in the
case of Fast channels, adslAtucChanConfFastMaxTxRate defines the
"downstream" rate, while adslAturChanConfFastMaxTxRate defines the
"upstream" rate for a particular channel.
C. There are two possible channels: fast, and interleaved. None, one
or both may be implemented on a particular ADSL Line. Figure 5
illustrates all possible operational configurations.
D. Lof, Lol, Los, Lpr mean Loss of Framing, Link, Signal, and Power,
respectively. Lpr is used by T1E1, so it is used for consistency
(rather than Lop).
A Loss of Link condition is declared at the ATU-C if a Loss of
Signal is not preceded by a `dying-gASP" message from the ATU-R.
Note that Loss of Link is only supported by the ATU-C.
E. ES means errored second. An Errored Second is any second
containing one or more CRC anomaly, or one or more Los(s) or
Severely Errored Frame (Sef) defect(s).
F. A "block" is a physical-layer `data buffer" over which CRCs are
calculated. For example, in DMT, the block is defined as the ADSL
superframe. The block duration is 250 micro-seconds so the block
length in bytes, as defined in adslAtu*ChanCrcBlockLength, varies
with data rate. See Line Code Specific MIBs [11] [12] for more
line code specific information.
G. Atn means Attenuation, Psd is Power Spectral Density and Snr is
Signal to Noise Ratio.
H. LCS means line code specific, e.g.,
o DMT = Discrete MultiTone
o CAP = Carrierless Amplitude and Phase modulation and
o QAM = Quadrature Amplitude Modulation
I. Vendor (in the Inventory objects) refers to the manufacturer of
the ATU-C or ATU-R assembly, not the modem chip vendor. When in
douBT, use the manufacturer of the smallest field replaceable unit
(e.g., stand-alone modem box, plug-in board).
J. RADSL - Rate Adaptive Asymmetric Digital Subscriber Loop
5.2 Structure
The MIB has multiple parallel tables. There are tables for:
o line - common attributes
o atuc and atur status
o atuc and atur performance
- Current and up to 96 buckets of 15 min performance history
- Current and Previous 1-day bucket performance history
o profiles - configuration parameters and alarm parameters
There are separate tables for Physical and Channel layers. Since
their attributes are similar, only one set of "channel" tables are
defined to be used for both fast and interleaved channels. The
corresponding ifType gives the proper interpretation for that
ifEntry.
It is intented that Line Code Specific MIBs be located under
adslLCSMib. These MIBs will be defined in separate modules.
There could have been fewer tables by combining the ATU-C and ATU-R
information into shared tables. However, the tables are more easily
read when there are two identical sets of data.
The figure below lists the five possible ADSL operational
configurations. (indicated by the value of the adslLineType). In all
configurations, the physical line interface entry will exist.
However, the existence of the ADSL channel varies in each case, as
shown below.
Table Phys Fast Interleaved
___________________________________________________________
No Channels (1) Y
Fast Only (2) Y Y
Interleaved Only (3) Y Y
Fast or Interleaved (4) Y Y Y
Fast and Interleaved (5) Y Y Y
Figure 5: ADSL Operational configurations
NOTE: In (4), channel exists of either Fast or Interleaved type, but
not both. The Manager may select the type of channel to be used.
Depending on which operation configuration exists, some or all ADSL
MIB tables could be supported, as shown in below. See Conformance
Statements for more information on which objects are mandatory.
Table Phys Fast Interleaved
___________________________________________________________
adslLineTable Y
adslAtucPhysTable Y
adslAturPhysTable Y
adslAtucChanTable Y Y
adslAturChanTable Y Y
adslAtucPerfDataTable Y
adslAturPerfDataTable Y
adslAtucIntervalTable Y
adslAturIntervalTable Y
adslAtucChanPerfDataTable Y Y
adslAturChanPerfDataTable Y Y
adslAtucChanIntervalTable Y Y
adslAturChanIntervalTable Y Y
Figure 6: Use of ADSL MIB Tables with various ifIndex values
NOTE: The adslLineConfProfileTable and adslLineAlarmConfProfileTable
will be present for all scenarios. See Profile Section of this
document for implementation details such as profile creation,
assignment, and indexing.
5.2.1 Structure of Conformance Groups
The MIB is organized to cover both ends of the ADSL line, ATU-C and
ATU-R. Objects defined can be categorized into two groups: the
ATU-C group which provides objects that are supported by ATU-C agents
and the ATU-R group which provides objects that are supported by
ATU-R agents. These two groups are defined by the conformance
section of the MIB. All objects defined in the MIB module are
supported by the ATU-C agent and only portions of the objects are
supported by the ATU-R agent. Figure 7 lists all tables/objects that
are supported by the ATU-R agent.
Table Objects
_______________________________________________________
adslLineTable adslLineCoding
adslAtucPhysTable adslAtucInvVendorID
adslAtucInvVersionNumber
adslAtucCurrStatus (Partial)
adslAtucCurrOutputPwr
adslAtucCurrAttainableRate
adslAturPhysTable all are supported
adslAtucChanTable all except
adslAtucChanCrcBlockLength
are supported
adslAtucPerfDataTable all except
adslAtucPerfLols,
adslAtucPerfLprs
adslAtucPerfCurr15MinLols,
adslAtucPerfCurr15MinLprs,
adslAtucPerfCurr1DayLols,
adslAtucPerfCurr1DayLprs,
adslAtucPerfPrev1DayLols and
adslAtucPerfPrev1DayLprs
are supported
adslAturPerfDataTable all are supported
adslAtucIntervalTable adslAtucIntervalLofs
adslAtucIntervalLoss
adslAtucIntervalESs
adslAtucIntervalInits
adslAtucIntervalValidData
adslAturIntervalTable all are supported
adslAtucChanPerfDataTable all are supported
adslAturChanPerfDataTable all are supported
adslAtucChanIntervalTable all are supported
adslAturChanIntervalTable all are supported
adslLineConfProfileTable not supported
adslLineAlarmConfProfileTable all are supported except
adslAtucThresh15MinLols
and adslAtucThresh15MinLprs
--------------------------------------------------------------------
Figure 7: MIB Tables and Objects Supported by the ATU-R Agent
All traps supported by the ATU-R agent are also listed:
adslAtucPerfLofsThreshTrap
adslAtucPerfLossThreshTrap
adslAtucPerfESsThreshTrap
adslAtucRateChangeTrap
adslAturPerfLofsThreshTrap
adslAturPerfLossThreshTrap
adslAturPerfLprsThreshTrap
adslAturPerfESsThreshTrap
adslAturRateChangeTrap
5.3 Counters, Interval Buckets and Thresholds
For physical-level ES, Los, Lof, Lol, Lpr and line initialization
attempts, there are event counters, current 15-minute and one (up to
96) 15-minute history bucket(s) of "interval-counters", as well as
current and previous 1-day interval-counters. Each physical-layer
current 15-minute event bucket has threshold trap.
At the channel level, there are counters for total received blocks,
received-and-corrected blocks, received-but-uncorrectable blocks, and
transmitted blocks. There are the same set of 15-minute and 1-day
buckets as at the physical-layer.
There is no requirement for an agent to ensure fixed relationship
between the start of a fifteen minute and any wall clock; however
some implementations may align the fifteen minute intervals with
quarter hours. Likewise, an implementation may choose to align one
day intervals with start of a day.
Separate tables are provided for the 96 interval-counters. They are
indexed by {ifIndex, AdslAtu*IntervalNumber}.
Counters are not reset when an ATU-C or ATU-R is reinitialized, only
when the agent is reset or reinitialized (or under specific request
outside the scope of this MIB).
The 15-minute event counters are of type PerfCurrentCount and
PerfIntervalCount. The 1-day event counters are of type
AdslPerfCurrDayCount and AdslPerfPrevDayCount. Both 15-minute and 1-
day time elapsed counters are of type AdslPerfTimeElapsed.
5.4 Profiles
As a managed node can handle a large number of ATU-Cs (e.g., hundreds
or perhaps thousands of ADSL lines), provisioning every parameter on
every ATU-C may become burdensome. In response, two MIB tables have
been created to define ADSL equipment configuration data profiles, as
well as a mechanism to associate the equipment to these profiles.
Profile tables may be implemented in one of two ways, but not
simultaneously:
o MODE-I: Dynamic Profiles - one profile shared by one or
multiple ADSL lines.
o MODE-II: Static Profiles - one profile per ADSL physical line
always.
5.4.1 MODE-I : Dynamic Profiles
Implementations using this mode will enable the manager to
dynamically create and delete profiles as needed. The index of the
profile is an locally-unique administratively assigned name for the
profile having the textual convention `SnmpAdminString" (RFC2571
[13]).
One or more ADSL lines may be configured to share parameters of a
single profile (e.g., adslLineConfProfileName = `silver") by setting
its adslLineConfProfile objects to the index value of this profile.
If a change is made to the profile, all lines that refer to it will
be re-configured to the changed parameters. Before a profile can be
deleted or taken out of service it must be first unreferenced from
all associated lines.
This figure below shows an example of how this mode can be
implemented. In the example, ADSL lines `1" and `x" share the
configuration of the `silver" profile, while line `2" uses the
`platinum" profile. The `gold" profile has no lines associated with
it.
ADSL ifIndex ifTable Configuration Line
Profile Table
__________________________________________________________________
1 i1 ADSL Line -- ---> Platinum Profile
j1 Fast Chan
k1 Int Chan
^
v Gold Profile
2 i2 ADSL Line ------->----
j2 Fast Chan
k2 Int Chan



v
x ix ADSL Line ------>------> Silver Profile
jx Fast Chan --------------->
kx Int Chan
__________________________________________________________________
Figure 8: Use of Dynamic Profiles: MODE-I
In the figure above, note that three interface entries of an ADSL
line, physical, fast channel, and interleaved channel, are
represented by `i", `j", and `k". Only the physical-layer entry `i"
contains an adslLineTable entry, therefore only those entries contain
pointers to the adslLineConfProfileTable. The ifStackTable (see
rfc2233 [5]) can be used to link the channel entries to the
corresponding physical-layer entry to get the channel"s configuration
parameters. See figure 4 for use of the ifStackTable.
The same characteristics and mechanisms are present for the alarm
profile type. There is no requirement that its index be the same as
the configuration profile.
Implementations of this mode, must provide a default profile whose
name is `DEFVAL" for each profile type: Configuration and Alarm. The
values of the associated parameters will be vendor specific unless
otherwise indicated in this document. Before a line"s profiles have
been set, these profiles will be automatically used by setting
adslLineConfProfile and adslLineAlarmConfProfile to `DEFVAL".
In this mode, profiles are created, assigned, and deleted dynamically
using these four objects: adslLineConfProfile,
adslLineConfProfileRowStatus, adslLineAlarmConfProfile, and
adslLineAlarmConfProfileRowStatus.
5.4.2 MODE-II : Static Profiles
Implementations with this mode will automatically create a profile
one-for-one with each ADSL line physical entry. The name of this
profile is a system generated read-only object whose value is
equivalent to the index of the physical line. The Agent will not
allow a Manager to create/delete profiles in this mode. Therefore,
adslLineConfProfile, adslLineConfProfileRowStatus,
adslLineAlarmConfProfile, and adslLineAlarmConfProfileRowStatus
objects have minimal value in this mode and are read-only.
The figure below shows an example of this mode. In the example, ADSL
lines `1", `2", and `x" each have their own profiles.
ADSL ifIndex ifTable Configuration Line
Profile Table
__________________________________________________________________
1 i1 ADSL Line ------------> Profile
j1 Fast Chan
k1 Int Chan
2 i2 ADSL Line ------------> Profile
j2 Fast Chan
k2 Int Chan
x ix ADSL Line ------------> Profile
jx Fast Chan
kx Int Chan
__________________________________________________________________
Figure 9: Use of Static Profiles: MODE II
5.5 Traps
These SNMP traps are required: coldStart / warmStart (per [6]) --
which are per agent (e.g., per DSLAM in such a device), and linkUp /
linkDown (per [5]) -- which are per interface (i.e., ADSL line).
Note: RFC2233 [5] recommends that linkUp / linkDown only be used at
a physical-layer ifEntry, as discussed above.
A linkDown trap is generated whenever any of Lof, Los, Lol, Loss of
Signal Quality, or Lpr events occurs. At this operational point, a
manager can use adslAtu*CurrStatus for additional detailed
information. The corresponding linkUp trap is sent when all link
failure conditions are cleared.
The traps defined in this MIB are for initialization failure, rate
change, and for the threshold crossings associated with the following
events: Lofs, Lols, Loss, Lprs, and ESs. Each threshold has its own
enable/threshold value. When that value is 0, the trap is disabled.
The current status objects (adslAtu*CurrStatus) indicate, through a
bitmask, all outstanding error conditions or that the line is
operational. Note that each object claims to represent the status of
the modem at that end of the line. However, since the SNMP agent
likely co-resides with only one end of the line, the corresponding
far-end current status object may be incomplete. For example, when
there are errors on the line, the far-end ATU may not be able to
correctly report this condition. Therefore, not all conditions are
included in its current status.
A threshold trap occurs whenever the corresponding current 15-minute
interval error counter becomes equal and/or exceeds to the threshold
value. One trap will be sent per interval per interface. Since the
current 15-minute counter are reset to 0 every 15 minutes, if the
condition persists, the trap may recur as often as every 15 minutes.
For example, to get a trap whenever a "loss of" event occurs (but at
most once every 15 minutes), set the corresponding "Thresh15Min" to
1. The agent will generate a trap when the event originally occurs.
Note that the NMS will get a linkDown trap, as well, if enabled. At
the beginning of the next 15 minute interval, the counter is reset.
When the first second goes by and the event occurs, the current
interval bucket will be 1, which equals the threshold and the trap
will be sent again.
The rate change trap is invoked when the transmit rate on a channel
either increases by adsl(x)Thresh(y)RateUp or decreases by
adsl(x)Thresh(y)RateDown. The trap is per direction:(x) == Atuc or
Atur, and per channel: (y) == Fast or Interleave. In other Words, the
trap is sent whenever the rate changes in either direction on either
channel and:
CurrTxRate >= PrevTxRate plus ThreshRateUp
or
CurrTxRate <= PrevTxRate minus ThreshRateDown
No trap is sent on initialization.
It can be disabled by setting the Up (and/or) Down threshold rates to
0.
The PrevTxRate object is set to the current value at initialization
and when a trap is sent. Thus rate changes are cumulative until the
total change reaches the threshold.
6. Conformance and Compliance
See the conformance and compliance statements within the information
module.
7. Definitions
ADSL-TC-MIB DEFINITIONS ::= BEGIN
IMPORTS
transmission,
MODULE-IDENTITY, Gauge32 FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC;
adsltcmib MODULE-IDENTITY
LAST-UPDATED "9908190000Z"
ORGANIZATION "IETF ADSL MIB Working Group"
CONTACT-INFO
"
Gregory Bathrick
AG Communication Systems
A Subsidiary of Lucent Technologies
2500 W Utopia Rd.
Phoenix, AZ 85027 USA
Tel: +1 602-582-7679
Fax: +1 602-582-7697
E-mail: bathricg@agcs.com
Faye Ly
Copper Mountain Networks
Norcal Office
2470 Embarcadero Way
Palo Alto, CA 94303
Tel: +1 650-858-8500
Fax: +1 650-858-8085
E-Mail: faye@coppermountain.com
IETF ADSL MIB Working Group (adsl@xlist.agcs.com)
"
DESCRIPTION
"The MIB module which provides a ADSL
Line Coding Textual Convention to be used
by ADSL Lines."
-- Revision history
REVISION "9908190000Z" -- 19 August 1999, midnight
DESCRIPTION "Initial Version, published as RFC2662"
::= { transmission 94 2 } -- adslMIB 2
AdslLineCodingType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This data type is used as the syntax for the ADSL
Line Code."
SYNTAX INTEGER {
other(1),-- none of the following
dmt (2), -- Discrete MultiTone
cap (3), -- Carrierless Amplitude & Phase modulation
qam (4) -- Quadrature Amplitude Modulation
}
AdslPerfCurrDayCount ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A counter associated with interface performance
measurements in a current 1-day (24 hour) measurement
interval.
The value of this counter starts at zero at the
beginning of an interval and is increased when
associated events occur, until the end of the
1-day interval. At that time the value of the
counter is stored in the previous 1-day history
interval, if available, and the current interval
counter is restarted at zero.
In the case where the agent has no valid data available
for this interval the corresponding object
instance is not available and upon a retrieval
request a corresponding error message shall be
returned to indicate that this instance does
not exist (for example, a noSuchName error for
SNMPv1 and a noSuchInstance for SNMPv2 GET
operation)."
SYNTAX Gauge32
AdslPerfPrevDayCount ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A counter associated with interface performance
measurements during the most previous 1-day (24 hour)
measurement interval. The value of this counter is
equal to the value of the current day counter at
the end of its most recent interval.
In the case where the agent has no valid data available
for this interval the corresponding object
instance is not available and upon a retrieval
request a corresponding error message shall be
returned to indicate that this instance does
not exist (for example, a noSuchName error for
SNMPv1 and a noSuchInstance for SNMPv2 GET
operation)."
SYNTAX Gauge32
AdslPerfTimeElapsed ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The number of seconds that have elapsed since
the beginning of the current measurement period.
If, for some reason, such as an adjustment in the
system"s time-of-day clock, the current interval
exceeds the maximum value, the agent will return
the maximum value."
SYNTAX Gauge32
END
ADSL-LINE-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
Counter32, Gauge32,
NOTIFICATION-TYPE,
transmission, Unsigned32 FROM SNMPv2-SMI
RowStatus,
TruthValue, VariablePointer FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP FROM SNMPv2-CONF
ifIndex FROM IF-MIB
PerfCurrentCount,
PerfIntervalCount FROM PerfHist-TC-MIB
SnmpAdminString FROM SNMP-FRAMEWORK-MIB
AdslPerfCurrDayCount,
AdslPerfPrevDayCount,
AdslPerfTimeElapsed,
AdslLineCodingType FROM ADSL-TC-MIB
;
adslMIB MODULE-IDENTITY
LAST-UPDATED "9908190000Z"
ORGANIZATION "IETF ADSL MIB Working Group"
CONTACT-INFO
"
Gregory Bathrick
AG Communication Systems
A Subsidiary of Lucent Technologies
2500 W Utopia Rd.
Phoenix, AZ 85027 USA
Tel: +1 602-582-7679
Fax: +1 602-582-7697
E-mail: bathricg@agcs.com
Faye Ly
Copper Mountain Networks
Norcal Office
2470 Embarcadero Way
Palo Alto, CA 94303
Tel: +1 650-858-8500
Fax: +1 650-858-8085
E-Mail: faye@coppermountain.com
(ADSL Forum input only)
John Burgess
Predictive Systems, Inc.
25A Vreeland Rd.
Florham Park, NJ 07932 USA
Tel: +1 973-301-5610
Fax: +1 973-301-5699
E-mail: jtburgess@predictive.com
IETF ADSL MIB Working Group (adsl@xlist.agcs.com)
"
DESCRIPTION
"The MIB module defining objects for the management of a pair of
ADSL modems at each end of the ADSL line. Each such line has
an entry in an ifTable which may include multiple modem lines.
An agent may reside at either end of the ADSL line however the
MIB is designed to require no management communication between
them beyond that inherent in the low-level ADSL line protocol.
The agent may monitor and control this protocol for its needs.
ADSL lines may support optional Fast or Interleaved channels.
If these are supported, additional entries corresponding to the
supported channels must be created in the ifTable. Thus an ADSL
line that supports both channels will have three entries in the
ifTable, one for each physical, fast, and interleaved, whose
ifType values are equal to adsl(94), fast(125), and
interleaved(124), respectively. The ifStackTable is used to
represent the relationship between the entries.
Naming Conventions:
Atuc -- (ATUC) modem at near (Central) end of line
Atur -- (ATUR) modem at Remote end of line
Curr -- Current
Prev -- Previous
Atn -- Attenuation
ES -- Errored Second.
LCS -- Line Code Specific
Lof -- Loss of Frame
Lol -- Loss of Link
Los -- Loss of Signal
Lpr -- Loss of Power
xxxs-- interval of Seconds in which xxx occurs
(e.g., xxx=Lof, Los, Lpr)
Max -- Maximum
Mgn -- Margin
Min -- Minimum
Psd -- Power Spectral Density
Snr -- Signal to Noise Ratio
Tx -- Transmit
Blks-- Blocks, a data unit, see
adslAtuXChanCrcBlockLength
"
-- Revision history
REVISION "9908190000Z" -- 19 August 1999, midnight
DESCRIPTION "Initial Version, published as RFC2662"
::= { transmission 94 }
adslLineMib OBJECT IDENTIFIER ::= { adslMIB 1 }
adslMibObjects OBJECT IDENTIFIER ::= { adslLineMib 1 }
-- objects
adslLineTable OBJECT-TYPE
SYNTAX SEQUENCE OF AdslLineEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table includes common attributes describing
both ends of the line. It is required for all ADSL
physical interfaces. ADSL physical interfaces are
those ifEntries where ifType is equal to adsl(94)."
::= { adslMibObjects 1 }
adslLineEntry OBJECT-TYPE
SYNTAX AdslLineEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in adslLineTable."
INDEX { ifIndex }
::= { adslLineTable 1 }
AdslLineEntry ::=
SEQUENCE {
adslLineCoding AdslLineCodingType,
adslLineType INTEGER,
adslLineSpecific VariablePointer,
adslLineConfProfile SnmpAdminString,
adslLineAlarmConfProfile SnmpAdminString
}
adslLineCoding OBJECT-TYPE
SYNTAX AdslLineCodingType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Specifies the ADSL coding type used on this
line."
::= { adslLineEntry 1 }
adslLineType OBJECT-TYPE
SYNTAX INTEGER {
noChannel (1), -- no channels exist
fastOnly (2), -- fast channel exists only
interleavedOnly (3), -- interleaved channel exists
-- only
fastOrInterleaved (4),-- either fast or interleaved
-- channels can exist, but
-- only one at any time
fastAndInterleaved (5)-- both fast or interleaved
-- channels exist
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Defines the type of ADSL physical line
entity that exists, by defining whether and how
the line is channelized. If the line is channelized,
the value will be other than noChannel(1). This
object defines which channel type(s) are supported.
In the case that the line is channelized, the manager
can use the ifStackTable to determine the ifIndex for
the associated channel(s)."
::= { adslLineEntry 2 }
adslLineSpecific OBJECT-TYPE
SYNTAX VariablePointer
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"OID instance in vendor-specific MIB. The Instance may
be used to determine shelf/slot/port of the ATUC
interface in a DSLAM."
::= { adslLineEntry 3 }
adslLineConfProfile OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (1..32))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value of this object identifies the row
in the ADSL Line Configuration Profile Table,
(adslLineConfProfileTable), which applies for this
ADSL line, and channels if applicable.
For `dynamic" mode, in the case which the
configuration profile has not been set, the
value will be set to `DEFVAL".
If the implementator of this MIB has chosen not
to implement `dynamic assignment" of profiles, this
object"s MIN-ACCESS is read-only."
::= { adslLineEntry 4 }
adslLineAlarmConfProfile OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (1..32))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value of this object identifies the row
in the ADSL Line Alarm Configuration Profile Table,
(adslLineAlarmConfProfileTable), which applies to this
ADSL line, and channels if applicable.
For `dynamic" mode, in the case which the
alarm profile has not been set, the
value will be set to `DEFVAL".
If the implementator of this MIB has chosen not
to implement `dynamic assignment" of profiles, this
object"s MIN-ACCESS is read-only."
::= { adslLineEntry 5 }
adslAtucPhysTable OBJECT-TYPE
SYNTAX SEQUENCE OF AdslAtucPhysEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table provides one row for each ATUC.
Each row contains the Physical Layer Parameters
table for that ATUC. ADSL physical interfaces are
those ifEntries where ifType is equal to adsl(94)."
::= { adslMibObjects 2 }
adslAtucPhysEntry OBJECT-TYPE
SYNTAX AdslAtucPhysEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in the adslAtucPhysTable."
INDEX { ifIndex }
::= { adslAtucPhysTable 1 }
AdslAtucPhysEntry ::=
SEQUENCE {
adslAtucInvSerialNumber SnmpAdminString,
adslAtucInvVendorID SnmpAdminString,
adslAtucInvVersionNumber SnmpAdminString,
adslAtucCurrSnrMgn INTEGER,
adslAtucCurrAtn Gauge32,
adslAtucCurrStatus BITS,
adslAtucCurrOutputPwr INTEGER,
adslAtucCurrAttainableRate Gauge32
}
-- inventory group
--
-- These items should describe the lowest level identifiable
-- component, be it a stand-alone modem, a card in a rack,
-- a child-board, etc.
--
adslAtucInvSerialNumber OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The vendor specific string that identifies the
vendor equipment."
::= { adslAtucPhysEntry 1 }
adslAtucInvVendorID OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..16))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The vendor ID code is a copy of the binary
vendor identification field defined by the
PHY[10] and expressed as readable characters."
REFERENCE "ANSI T1.413[10]"
::= { adslAtucPhysEntry 2 }
adslAtucInvVersionNumber OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..16))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The vendor specific version number sent by this ATU
as part of the initialization messages. It is a copy
of the binary version number field defined by the
PHY[10] and expressed as readable characters."
REFERENCE "ANSI T1.413[10]"
::= { adslAtucPhysEntry 3 }
-- current status group
--
adslAtucCurrSnrMgn OBJECT-TYPE
SYNTAX INTEGER (-640..640)
UNITS "tenth dB"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Noise Margin as seen by this ATU with respect to its
received signal in tenth dB."
::= { adslAtucPhysEntry 4 }
adslAtucCurrAtn OBJECT-TYPE
SYNTAX Gauge32(0..630)
UNITS "tenth dB"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Measured difference in the total power transmitted by
the peer ATU and the total power received by this ATU."
::= { adslAtucPhysEntry 5 }
adslAtucCurrStatus OBJECT-TYPE
SYNTAX BITS {
noDefect(0),
lossOfFraming(1),
lossOfSignal(2),
lossOfPower(3),
lossOfSignalQuality(4),
lossOfLink(5),
dataInitFailure(6),
configInitFailure(7),
protocolInitFailure(8),
noPeerAtuPresent(9)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates current state of the ATUC line. This is a
bit-map of possible conditions. The various bit
positions are:
0 noDefect There no defects on the line
1 lossOfFraming ATUC failure due to not
receiving valid frame.
2 lossOfSignal ATUC failure due to not
receiving signal.
3 lossOfPower ATUC failure due to loss of
power.
Note: the Agent may still
function.
4 lossOfSignalQuality Loss of Signal Quality is
declared when the Noise Margin
falls below the Minimum Noise
Margin, or the bit-error-rate
exceeds 10^-7.
5 lossOfLink ATUC failure due to inability
to link with ATUR.
6 dataInitFailure ATUC failure during
initialization due to bit
errors corrupting startup
exchange data.
7 configInitFailure ATUC failure during
initialization due to peer
ATU not able to support
requested configuration
8 protocolInitFailure ATUC failure during
initialization due to
incompatible protocol used by
the peer ATU.
9 noPeerAtuPresent ATUC failure during
initialization due to no
activation sequence detected
from peer ATU.
This is intended to supplement ifOperStatus."
::= { adslAtucPhysEntry 6 }
adslAtucCurrOutputPwr OBJECT-TYPE
SYNTAX INTEGER (-310..310)
UNITS "tenth dBm"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Measured total output power transmitted by this ATU.
This is the measurement that was reported during
the last activation sequence."
::= { adslAtucPhysEntry 7 }
adslAtucCurrAttainableRate OBJECT-TYPE
SYNTAX Gauge32
UNITS "bps"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the maximum currently attainable data rate
by the ATU. This value will be equal or greater than
the current line rate."
::= { adslAtucPhysEntry 8 }
adslAturPhysTable OBJECT-TYPE
SYNTAX SEQUENCE OF AdslAturPhysEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table provides one row for each ATUR
Each row contains the Physical Layer Parameters
table for that ATUR. ADSL physical interfaces are
those ifEntries where ifType is equal to adsl(94)."
::= { adslMibObjects 3 }
adslAturPhysEntry OBJECT-TYPE
SYNTAX AdslAturPhysEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in the adslAturPhysTable."
INDEX { ifIndex }
::= { adslAturPhysTable 1 }
AdslAturPhysEntry ::=
SEQUENCE {
adslAturInvSerialNumber SnmpAdminString,
adslAturInvVendorID SnmpAdminString,
adslAturInvVersionNumber SnmpAdminString,
adslAturCurrSnrMgn INTEGER,
adslAturCurrAtn Gauge32,
adslAturCurrStatus BITS,
adslAturCurrOutputPwr INTEGER,
adslAturCurrAttainableRate Gauge32
}
-- inventory group
--
adslAturInvSerialNumber OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The vendor specific string that identifies the
vendor equipment."
::= { adslAturPhysEntry 1 }
adslAturInvVendorID OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..16))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The vendor ID code is a copy of the binary
vendor identification field defined by the
PHY[10] and expressed as readable characters."
REFERENCE "ANSI T1.413"
::= { adslAturPhysEntry 2 }
adslAturInvVersionNumber OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..16))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The vendor specific version number sent by this ATU
as part of the initialization messages. It is a copy
of the binary version number field defined by the
PHY[10] and expressed as readable characters."
REFERENCE "ANSI T1.413"
::= { adslAturPhysEntry 3 }
-- current status group
--
adslAturCurrSnrMgn OBJECT-TYPE
SYNTAX INTEGER (-640..640)
UNITS "tenth dB"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Noise Margin as seen by this ATU with respect to its
received signal in tenth dB."
::= { adslAturPhysEntry 4 }
adslAturCurrAtn OBJECT-TYPE
SYNTAX Gauge32(0..630)
UNITS "tenth dB"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Measured difference in the total power transmitted by
the peer ATU and the total power received by this ATU."
::= { adslAturPhysEntry 5 }
adslAturCurrStatus OBJECT-TYPE
SYNTAX BITS {
noDefect(0),
lossOfFraming(1),
lossOfSignal(2),
lossOfPower(3),
lossOfSignalQuality(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates current state of the ATUR line. This is a
bit-map of possible conditions. Due to the isolation
of the ATUR when line problems occur, many state
conditions like loss of power, loss of quality signal,
and initialization errors, can not be determined.
While trouble shooting ATUR, also use object,
adslAtucCurrStatus. The various bit positions are:
0 noDefect There no defects on the line
1 lossOfFraming ATUR failure due to not
receiving valid frame
2 lossOfSignal ATUR failure due to not
receiving signal
3 lossOfPower ATUR failure due to loss of
power
4 lossOfSignalQuality Loss of Signal Quality is
declared when the Noise Margin
falls below the Minimum Noise
Margin, or the
bit-error-rate exceeds 10^-7.
This is intended to supplement ifOperStatus."
::= { adslAturPhysEntry 6 }
adslAturCurrOutputPwr OBJECT-TYPE
SYNTAX INTEGER (-310..310)
UNITS "tenth dBm"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Measured total output power transmitted by this ATU.
This is the measurement that was reported during
the last activation sequence."
::= { adslAturPhysEntry 7 }
adslAturCurrAttainableRate OBJECT-TYPE
SYNTAX Gauge32
UNITS "bps"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the maximum currently attainable data rate
by the ATU. This value will be equal or greater than
the current line rate."
::= { adslAturPhysEntry 8 }
adslAtucChanTable OBJECT-TYPE
SYNTAX SEQUENCE OF AdslAtucChanEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table provides one row for each ATUC channel.
ADSL channel interfaces are those ifEntries
where ifType is equal to adslInterleave(124)
or adslFast(125)."
::= { adslMibObjects 4 }
adslAtucChanEntry OBJECT-TYPE
SYNTAX AdslAtucChanEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in the adslAtucChanTable."
INDEX { ifIndex }
::= { adslAtucChanTable 1 }
AdslAtucChanEntry ::=
SEQUENCE {
adslAtucChanInterleaveDelay Gauge32,
adslAtucChanCurrTxRate Gauge32,
adslAtucChanPrevTxRate Gauge32,
adslAtucChanCrcBlockLength Gauge32
}
-- current group
--
adslAtucChanInterleaveDelay OBJECT-TYPE
SYNTAX Gauge32
UNITS "milli-seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Interleave Delay for this channel.
Interleave delay applies only to the
interleave channel and defines the mapping
(relative spacing) between subsequent input
bytes at the interleaver input and their placement
in the bit stream at the interleaver output.
Larger numbers provide greater separation between
consecutive input bytes in the output bit stream
allowing for improved impulse noise immunity at
the expense of payload latency.
In the case where the ifType is Fast(125), use
noSuchObject."
::= { adslAtucChanEntry 1 }
adslAtucChanCurrTxRate OBJECT-TYPE
SYNTAX Gauge32
UNITS "bps"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Actual transmit rate on this channel."
::= { adslAtucChanEntry 2 }
adslAtucChanPrevTxRate OBJECT-TYPE
SYNTAX Gauge32
UNITS "bps"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The rate at the time of the last
adslAtucRateChangeTrap event. It is also set at
initialization to prevent a trap being sent.
Rate changes less than adslAtucThresh(*)RateDown
or less than adslAtucThresh(*)RateUp will not
cause a trap or cause this object to change.
(*) == Fast or Interleave.
See AdslLineAlarmConfProfileEntry."
::= { adslAtucChanEntry 3 }
adslAtucChanCrcBlockLength OBJECT-TYPE
SYNTAX Gauge32
UNITS "byte"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the length of the channel data-block
on which the CRC operates. Refer to Line Code
Specific MIBs, [11] and [12] for more
information."
::= { adslAtucChanEntry 4 }
adslAturChanTable OBJECT-TYPE
SYNTAX SEQUENCE OF AdslAturChanEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table provides one row for each ATUR channel.
ADSL channel interfaces are those ifEntries
where ifType is equal to adslInterleave(124)
or adslFast(125)."
::= { adslMibObjects 5 }
adslAturChanEntry OBJECT-TYPE
SYNTAX AdslAturChanEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in the adslAturChanTable."
INDEX { ifIndex }
::= { adslAturChanTable 1 }
AdslAturChanEntry ::=
SEQUENCE {
adslAturChanInterleaveDelay Gauge32,
adslAturChanCurrTxRate Gauge32,
adslAturChanPrevTxRate Gauge32,
adslAturChanCrcBlockLength Gauge32
}
-- current group
--
adslAturChanInterleaveDelay OBJECT-TYPE
SYNTAX Gauge32
UNITS "milli-seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Interleave Delay for this channel.
Interleave delay applies only to the
interleave channel and defines the mapping
(relative spacing) between subsequent input
bytes at the interleaver input and their placement
in the bit stream at the interleaver output.
Larger numbers provide greater separation between
consecutive input bytes in the output bit stream
allowing for improved impulse noise immunity at
the expense of payload latency.
In the case where the ifType is Fast(125), use
noSuchObject."
::= { adslAturChanEntry 1 }
adslAturChanCurrTxRate OBJECT-TYPE
SYNTAX Gauge32
UNITS "bps"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Actual transmit rate on this channel."
::= { adslAturChanEntry 2 }
adslAturChanPrevTxRate OBJECT-TYPE
SYNTAX Gauge32
UNITS "bps"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The rate at the time of the last
adslAturRateChangeTrap event. It is also set at
initialization to prevent a trap being sent.
Rate changes less than adslAturThresh(*)RateDown
or less than adslAturThresh(*)RateUp will not
cause a trap or cause this object to change.
(*) == Fast or Interleave.
See AdslLineAlarmConfProfileEntry."
::= { adslAturChanEntry 3 }
adslAturChanCrcBlockLength OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the length of the channel data-block
on which the CRC operates. Refer to Line Code
Specific MIBs, [11] and [12] for more
information."
::= { adslAturChanEntry 4 }
adslAtucPerfDataTable OBJECT-TYPE
SYNTAX SEQUENCE OF AdslAtucPerfDataEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table provides one row for each ATUC.
ADSL physical interfaces are
those ifEntries where ifType is equal to adsl(94)."
::= { adslMibObjects 6 }
adslAtucPerfDataEntry OBJECT-TYPE
SYNTAX AdslAtucPerfDataEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in adslAtucPerfDataTable."
INDEX { ifIndex }
::= { adslAtucPerfDataTable 1 }
AdslAtucPerfDataEntry ::=
SEQUENCE {
adslAtucPerfLofs Counter32,
adslAtucPerfLoss Counter32,
adslAtucPerfLols Counter32,
adslAtucPerfLprs Counter32,
adslAtucPerfESs Counter32,
adslAtucPerfInits Counter32,
adslAtucPerfValidIntervals INTEGER,
adslAtucPerfInvalidIntervals INTEGER,
adslAtucPerfCurr15MinTimeElapsed AdslPerfTimeElapsed,
adslAtucPerfCurr15MinLofs PerfCurrentCount,
adslAtucPerfCurr15MinLoss PerfCurrentCount,
adslAtucPerfCurr15MinLols PerfCurrentCount,
adslAtucPerfCurr15MinLprs PerfCurrentCount,
adslAtucPerfCurr15MinESs PerfCurrentCount,
adslAtucPerfCurr15MinInits PerfCurrentCount,
adslAtucPerfCurr1DayTimeElapsed AdslPerfTimeElapsed,
adslAtucPerfCurr1DayLofs AdslPerfCurrDayCount,
adslAtucPerfCurr1DayLoss AdslPerfCurrDayCount,
adslAtucPerfCurr1DayLols AdslPerfCurrDayCount,
adslAtucPerfCurr1DayLprs AdslPerfCurrDayCount,
adslAtucPerfCurr1DayESs AdslPerfCurrDayCount,
adslAtucPerfCurr1DayInits AdslPerfCurrDayCount,
adslAtucPerfPrev1DayMoniSecs INTEGER,
adslAtucPerfPrev1DayLofs AdslPerfPrevDayCount,
adslAtucPerfPrev1DayLoss AdslPerfPrevDayCount,
adslAtucPerfPrev1DayLols AdslPerfPrevDayCount,
adslAtucPerfPrev1DayLprs AdslPerfPrevDayCount,
adslAtucPerfPrev1DayESs AdslPerfPrevDayCount,
adslAtucPerfPrev1DayInits AdslPerfPrevDayCount
}
-- Event Counters
--
-- Also see adslAtucIntervalTable for 15 minute interval
-- elapsed counters.
--
adslAtucPerfLofs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of the number of Loss of Framing failures since
agent reset."
::= { adslAtucPerfDataEntry 1 }
adslAtucPerfLoss OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of the number of Loss of Signal failures since
agent reset."
::= { adslAtucPerfDataEntry 2 }
adslAtucPerfLols OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of the number of Loss of Link failures since
agent reset."
::= { adslAtucPerfDataEntry 3 }
adslAtucPerfLprs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of the number of Loss of Power failures since
agent reset."
::= { adslAtucPerfDataEntry 4 }
adslAtucPerfESs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of the number of Errored Seconds since agent
reset. The errored second parameter is a count of
one-second intervals containing one or more crc
anomalies, or one or more los or sef defects."
::= { adslAtucPerfDataEntry 5 }
adslAtucPerfInits OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of the line initialization attempts since
agent reset. Includes both successful and failed
attempts."
::= { adslAtucPerfDataEntry 6 }
-- general 15 min interval information
--
adslAtucPerfValidIntervals OBJECT-TYPE
SYNTAX INTEGER(0..96)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of previous 15-minute intervals in the
interval table for which data was collected. Given
that <n> is the maximum # of intervals supported.
The value will be <n> unless the measurement was
(re-)started within the last (<n>*15) minutes, in which
case the value will be the number of complete 15
minute intervals for which the agent has at least
some data. In certain cases (e.g., in the case
where the agent is a proxy) it is possible that some
intervals are unavailable. In this case, this
interval is the maximum interval number for
which data is available."
::= { adslAtucPerfDataEntry 7 }
adslAtucPerfInvalidIntervals OBJECT-TYPE
SYNTAX INTEGER(0..96)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of intervals in the range from
0 to the value of adslAtucPerfValidIntervals
for which no data is available. This object
will typically be zero except in cases where
the data for some intervals are not available
(e.g., in proxy situations)."
::= { adslAtucPerfDataEntry 8 }
-- 15 min current performance group
--
adslAtucPerfCurr15MinTimeElapsed OBJECT-TYPE
SYNTAX AdslPerfTimeElapsed(0..899)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total elapsed seconds in this interval."
::= { adslAtucPerfDataEntry 9 }
adslAtucPerfCurr15MinLofs OBJECT-TYPE
SYNTAX PerfCurrentCount
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of seconds in the current 15 minute interval
when there was Loss of Framing."
::= { adslAtucPerfDataEntry 10 }
adslAtucPerfCurr15MinLoss OBJECT-TYPE
SYNTAX PerfCurrentCount
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of seconds in the current 15 minute interval
when there was Loss of Signal."
::= { adslAtucPerfDataEntry 11 }
adslAtucPerfCurr15MinLols OBJECT-TYPE
SYNTAX PerfCurrentCount
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of seconds in the current 15 minute interval
when there was Loss of Link."
::= { adslAtucPerfDataEntry 12 }
adslAtucPerfCurr15MinLprs OBJECT-TYPE
SYNTAX PerfCurrentCount
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of seconds in the current 15 minute interval
when there was Loss of Power."
::= { adslAtucPerfDataEntry 13 }
adslAtucPerfCurr15MinESs OBJECT-TYPE
SYNTAX PerfCurrentCount
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of Errored Seconds in the current 15 minute
interval. The errored second parameter is a count of
one-second intervals containing one or more crc
anomalies, or one or more los or sef defects."
::= { adslAtucPerfDataEntry 14 }
adslAtucPerfCurr15MinInits OBJECT-TYPE
SYNTAX PerfCurrentCount
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of the line initialization attempts in the
current 15 minute interval. Includes both successful
and failed attempts."
::= { adslAtucPerfDataEntry 15 }
-- 1-day current and previous performance group
--
adslAtucPerfCurr1DayTimeElapsed OBJECT-TYPE
SYNTAX AdslPerfTimeElapsed(0..86399)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of seconds that have elapsed since the
beginning of the current 1-day interval."
::= { adslAtucPerfDataEntry 16 }
adslAtucPerfCurr1DayLofs OBJECT-TYPE
SYNTAX AdslPerfCurrDayCount
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of the number of seconds when there was Loss of
Framing during the current day as measured by
adslAtucPerfCurr1DayTimeElapsed."
::= { adslAtucPerfDataEntry 17 }
adslAtucPerfCurr1DayLoss OBJECT-TYPE
SYNTAX AdslPerfCurrDayCount
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of the number of seconds when there was Loss of
Signal during the current day as measured by
adslAtucPerfCurr1DayTimeElapsed."
::= { adslAtucPerfDataEntry 18 }
adslAtucPerfCurr1DayLols OBJECT-TYPE
SYNTAX AdslPerfCurrDayCount
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of the number of seconds when there was Loss of
Link during the current day as measured by
adslAtucPerfCurr1DayTimeElapsed."
::= { adslAtucPerfDataEntry 19 }
adslAtucPerfCurr1DayLprs OBJECT-TYPE
SYNTAX AdslPerfCurrDayCount
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of the number of seconds when there was Loss of
Power during the current day as measured by
adslAtucPerfCurr1DayTimeElapsed."
::= { adslAtucPerfDataEntry 20 }
adslAtucPerfCurr1DayESs OBJECT-TYPE
SYNTAX AdslPerfCurrDayCount
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of Errored Seconds during the current day as
measured by adslAtucPerfCurr1DayTimeElapsed.
The errored second parameter is a count of
one-second intervals containing one or more crc
anomalies, or one or more los or sef defects."
::= { adslAtucPerfDataEntry 21 }
adslAtucPerfCurr1DayInits OBJECT-TYPE
SYNTAX AdslPerfCurrDayCount
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of the line initialization attempts in the
day as measured by adslAtucPerfCurr1DayTimeElapsed.
Includes both successful and failed attempts."
::= { adslAtucPerfDataEntry 22 }
adslAtucPerfPrev1DayMoniSecs OBJECT-TYPE
SYNTAX INTEGER(0..86400)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The amount of time in the previous 1-day interval
over which the performance monitoring information