draft-ietf-adslmib-adsllinemib-05.txt   draft-ietf-adslmib-adsllinemib-06.txt 
INTERNET-DRAFT ADSL Line MIB Gregory Bathrick INTERNET-DRAFT ADSL Line MIB Gregory Bathrick
AG Communication Systems AG Communication Systems
Faye Ly Faye Ly
Copper Mountain Networks Copper Mountain Networks
Febuary 26, 1999 May 5, 1999
Definitions of Managed Objects Definitions of Managed Objects
for the ADSL Lines for the ADSL Lines
Febuary 26, 1999 May 5, 1999
draft-ietf-adslmib-adsllinemib-05.txt
draft-ietf-adslmib-adsllinemib-06.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
2. Abstract 2. Abstract
This document defines a standard SNMP MIB for ADSL lines based on the This document defines a standard SNMP MIB for ADSL lines based on the
ADSL Forum standard data model [9]. The ADSL standard describes 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 as two sides of the ADSL line. This MIB covers both
ATU-C and ATU-R agent's perspectives. Each instance defined in the ATU-C and ATU-R agent's perspectives. Each instance defined in the
MIB represents a single ADSL line. MIB represents a single ADSL line.
It should be noted that the ADSL Forum Network Management Working It should be noted that the ADSL Forum Network Management Working
Group had significant input towards the original version (v00) of Group provided input towards the content of this document. See the
this document. See `REVISION' clauses of this document for summary Acknowledgement Section for a list of individuals who made this
of changes made since that point. See Acknowledgement Section for a document possible.
list of individuals involved with both the IETF and ADSL Forum
efforts.
3. The SNMP Network Management Framework 3. The SNMP Network Management Framework
The SNMP Management Framework presently consists of five major The SNMP Management Framework presently consists of five major
components: components:
o An overall architecture, described in RFC 2271 [13]. o An overall architecture, described in RFC 2271 [13].
o Mechanisms for describing and naming objects and events for o Mechanisms for describing and naming objects and events for
the purpose of management. The first version of this the purpose of management. The first version of this
skipping to change at page 3, line 26 skipping to change at page 3, line 23
Managed objects are accessed via a virtual information store, termed Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are the Management Information Base or MIB. Objects in the MIB are
defined using the extended subset of Abstract Syntax Notation One defined using the extended subset of Abstract Syntax Notation One
(ASN.1) defined in the SMI. In particular, each object type is named (ASN.1) defined in the SMI. In particular, each object type is named
by an OBJECT IDENTIFIER, an administratively assigned name. The by an OBJECT IDENTIFIER, an administratively assigned name. The
object type together with an object instance serves to uniquely object type together with an object instance serves to uniquely
identify a specific instantiation of the object. For human identify a specific instantiation of the object. For human
convenience, we often use a textual string, termed the descriptor, to convenience, we often use a textual string, termed the descriptor, to
also refer to the object type. also refer to the object type.
5. Introduction 5. Relationship of the ADSL LINE MIB with standard MIBs
This document describes an ADSL Line MIB which is intended to work
within the SNMP Network Management Framework (section 3). All MIB
definitions are backward compatible for SNMPv1 implementation.
The MIB definitions are attached. The MIB will eventually be located
in the MIB tree under mib-2 transmission, further discussed in
section 6 of this document.
6. Relationship of the ADSL LINE MIB with standard MIBs
This section outlines the relationship of ADSL Line MIB with other This section outlines the relationship of ADSL Line MIB with other
MIBs described in RFCs and in their various degrees of MIBs described in RFCs and in their various degrees of
"standardization". "standardization".
6.1 Use of the IfTable 5.1 Use of the IfTable
The ADSL LINE MIB specifies the detailed attributes of a data The ADSL LINE MIB specifies the detailed attributes of a data
interface. As such, it needs to integrate with IF-MIB [5]. The IANA interface. As such, it needs to integrate with IF-MIB [5]. The IANA
has assigned the following ifType(s) relative to ADSL: has assigned the following ifType(s) relative to ADSL:
IANAifType ::= TEXTUAL-CONVENTION IANAifType ::= TEXTUAL-CONVENTION
. . . . . .
SYNTAX INTEGER { SYNTAX INTEGER {
. . . . . .
adsl(94), -- Asymmetric Digital Subscriber Loop adsl(94), -- Asymmetric Digital Subscriber Loop
. . . . . .
skipping to change at page 4, line 16 skipping to change at page 4, line 4
SYNTAX INTEGER { SYNTAX INTEGER {
. . . . . .
adsl(94), -- Asymmetric Digital Subscriber Loop adsl(94), -- Asymmetric Digital Subscriber Loop
. . . . . .
adslInterleave(124), -- ADSL Interleaved Channel adslInterleave(124), -- ADSL Interleaved Channel
adslFast(125), -- ADSL Fast Channel adslFast(125), -- ADSL Fast Channel
. . . } . . . }
Interfaces of each of these types are modeled by this document. Interfaces of each of these types are modeled by this document.
Pending approval of the IANA, under the advisement from IESG, adslMIB
will be used as the root of this MIB and will be assigned to the
value { transmission 94 }.
Most MIB tables in this document represent information of one of Most MIB tables in this document represent information of one of
these interface types and are indexed by ifIndex. Remaining are these interface types and are indexed by ifIndex. Remaining are
`profile' tables which may be accessed by the profileIndex. This is `profile' tables which may be accessed by the profileIndex. This is
explained in more detail in section 7.4 Profiles. explained in more detail in section 6.4 Profiles.
6.1.1 ADSL Interface Types 5.1.1 ADSL Interface Types
As shown below, three ADSL interface types are defined in this As shown below, three ADSL interface types are defined in this
document, namely physical, interleaved channel, and fast channel. document, namely physical, interleaved channel, and fast channel.
The physical interface represents characteristics of the physical The physical interface represents characteristics of the physical
media associated with both the ATUC and ATUR. The interleaved and media associated with both the ATUC and ATUR. The interleaved and
fast channel interface represent the characteristics of the two types fast channel interface represent the characteristics of the two types
of ADSL channels. of ADSL channels.
For each ADSL Line, a physical interface always exists. Depending For each ADSL Line, a physical interface always exists. Depending
on which ADSL operational configuration is present (as listed in on which ADSL operational configuration is present (as listed in
skipping to change at page 5, line 4 skipping to change at page 4, line 34
Figure 5), the channel interfaces (fast or interleaved) may or may Figure 5), the channel interfaces (fast or interleaved) may or may
not exist. not exist.
______ ______ ______ ______
| |____________________| | | |____________________| |
| ATUC | | ATUR | | ATUC | | ATUR |
| |____________________| | | |____________________| |
|______| |______| |______| |______|
| <----- physical --------> | | <----- physical --------> |
| <--- fast channel ------> | | <--- fast channel ------> |
| <- interleaved channel -> | | <- interleaved channel -> |
Figure 1: ADSL Model Figure 1: ADSL Model
6.1.2 Use of IF-MIB (Interface MIB RFC 2233) [5] 5.1.2 Use of IF-MIB (Interface MIB RFC 2233) [5]
The following attributes are part of the required The following attributes are part of the required
ifGeneralInformationGroup object group specified in RFC 2233 [5], and ifGeneralInformationGroup object group specified in RFC 2233 [5], and
are not duplicated in the ADSL MIB. Keep in mind that these objects are not duplicated in the ADSL MIB. Keep in mind that these objects
apply to the agent's view of the line. apply to the agent's view of the line.
ifTable Object Use for ADSL ifTable Object Use for ADSL
================================================================== ==================================================================
ifIndex Interface index. ifIndex Interface index.
skipping to change at page 6, line 37 skipping to change at page 6, line 20
================================================================== ==================================================================
Figure 2: Use of ifTable Objects: ifGeneralInformationGroup Figure 2: Use of ifTable Objects: ifGeneralInformationGroup
Use of the ifStackTable to associate the entries for physical, fast, Use of the ifStackTable to associate the entries for physical, fast,
interleaved channels, and higher layers (e.g., ATM) is shown below in interleaved channels, and higher layers (e.g., ATM) is shown below in
figure 3. Use of ifStackTable is necessary, because configuration figure 3. Use of ifStackTable is necessary, because configuration
information is stored in profile tables associated with the information is stored in profile tables associated with the
physical-layer ifEntry only. The channels' ifEntrys need the physical-layer ifEntry only. The channels' ifEntrys need the
ifStackTable to find their associated physical-layer entry and thus ifStackTable to find their associated physical-layer entry and thus
their configuration parameters. (See Profile section, 7.4). their configuration parameters. (See Profile section, 6.4).
______ (ifEntry=j) ______ ______ (ifEntry=j) ______
| | fast channel | | | | fast channel | |
| |________________________| | | |________________________| |
| | and/or | | | | and/or | |
| | | | | | | |
| | (ifEntry=k) | | | | (ifEntry=k) | |
| | interleaved channel | | | | interleaved channel | |
| |________________________| | | |________________________| |
| ATUC | | ATUR | | ATUC | | ATUR |
skipping to change at page 7, line 19 skipping to change at page 7, line 4
Figure 3: Use of ifStackTable (part 1) Figure 3: Use of ifStackTable (part 1)
The ifStackTable is then used to show the relationships between the The ifStackTable is then used to show the relationships between the
various ADSL interfaces, as illustrated below in figure 4. various ADSL interfaces, as illustrated below in figure 4.
HigherLayer LowerLayer HigherLayer LowerLayer
-------------------------- --------------------------
j i j i
k i k i
Figure 4: Use of ifStackTable (part 2) Figure 4: Use of ifStackTable (part 2)
The ifRcvAddressTable is not applicable for ADSL interfaces. The ifRcvAddressTable is not applicable for ADSL interfaces.
6.2 Relationship with RFC 2037 [25] 5.2 Relationship with RFC 2037 [25]
Implementation of the Entity MIB [25] is optional. It in no way Implementation of the Entity MIB [25] is optional. It in no way
alters the information required in the adslLineMib, nor does it alter alters the information required in the adslLineMib, nor does it alter
the relationship with IF-MIB. the relationship with IF-MIB.
The Entity MIB introduces a standardized way of presenting the The Entity MIB introduces a standardized way of presenting the
components of complex systems, such as a Digital Subscriber Line components of complex systems, such as a Digital Subscriber Line
Access Multiplexer (DSLAM), that may contain multiple racks, shelves, Access Multiplexer (DSLAM), that may contain multiple racks, shelves,
line cards, and/or ports. The Entity MIB's main goal is to present line cards, and/or ports. The Entity MIB's main goal is to present
these system components, their containment relationship, and mapping these system components, their containment relationship, and mapping
information with other MIBs such as the Interface MIB and the information with other MIBs such as the Interface MIB and the
adslLineMib. adslLineMib.
If implemented, the Entity MIB should include entities for the ATU-C If ATU-C agent is implemented, the Entity MIB should include entities
in the entPhysicalTable. The MIB's entAliasMappingTable would for the ATU-C in the entPhysicalTable. The MIB's
contain mapping information identifying the `ifIndex' object entAliasMappingTable would contain mapping information identifying
associated with each ATU-C. Also associating the relationship the 'ifIndex' object associated with each ATU-C. However, if ATU-R
between the ifTable and Entity MIB, the entPhysicalTable contains an agent is implemented, the Entity MIB should include entities for the
`entPhysicalName' object, which approximates the semantics of the ATU-R in the entPhysicalTable. In this case, the MIB's
`ifName' object from the Interface MIB. entAliasMappingTable would contain mapping information identifying
the 'ifIndex' object associated with each ATU-R.
7. Conventions used in the MIB 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.
7.1 Naming Conventions 6. Conventions used in the MIB
6.1 Naming Conventions
A. Atuc/Atur are used for the ATU-C and ATU-R. In other RFCs, these 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) are sometimes referred to as the Near End (Ne) and Far End (Fe)
respectively, but not in this document. respectively, but not in this document.
B. The terms, "transmit" and "receive", are from the perspective of B. The terms, "transmit" and "receive", are from the perspective of
the corresponding table's end of the line. For example, in the case the corresponding table's end of the line. For example, in the case
of Fast channels, adslAtucChanConfFastMaxTxRate defines the of Fast channels, adslAtucChanConfFastMaxTxRate defines the
"downstream" rate, while adslAturChanConfFastMaxTxRate defines the "downstream" rate, while adslAturChanConfFastMaxTxRate defines the
"upstream" rate for a particular channel. "upstream" rate for a particular channel.
skipping to change at page 9, line 4 skipping to change at page 8, line 39
G. Atn means Attenuation, Psd is Power Spectral Density and Snr is G. Atn means Attenuation, Psd is Power Spectral Density and Snr is
Signal to Noise Ratio. Signal to Noise Ratio.
H. LCS means line code specific, e.g., H. LCS means line code specific, e.g.,
o DMT = Discrete MultiTone o DMT = Discrete MultiTone
o CAP = Carrierless Amplitude and Phase modulation and o CAP = Carrierless Amplitude and Phase modulation and
o QAM = Quadrature Amplitude Modulation o QAM = Quadrature Amplitude Modulation
I. Vendor (in the Inventory objects) refers to the manufacturer of 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 the ATU-C or ATU-R assembly, not the modem chip vendor. When in
doubt, use the manufacturer of the smallest field replaceable unit doubt, use the manufacturer of the smallest field replaceable unit
(e.g., stand-alone modem box, plug-in board). (e.g., stand-alone modem box, plug-in board).
J. RADSL - Rate Adaptive Asymmetric Digital Subscriber Loop J. RADSL - Rate Adaptive Asymmetric Digital Subscriber Loop
7.2 Structure 6.2 Structure
The MIB has multiple parallel tables. There are tables for: The MIB has multiple parallel tables. There are tables for:
o line - common attributes o line - common attributes
o atuc and atur status o atuc and atur status
o atuc and atur performance o atuc and atur performance
- Current and up to 96 buckets of 15 min performance history - Current and up to 96 buckets of 15 min performance history
skipping to change at page 9, line 33 skipping to change at page 9, line 23
- Current and Previous 1-day bucket performance history - Current and Previous 1-day bucket performance history
o profiles - configuration parameters and alarm parameters o profiles - configuration parameters and alarm parameters
There are separate tables for Physical and Channel layers. Since There are separate tables for Physical and Channel layers. Since
their attributes are similar, only one set of "channel" tables are their attributes are similar, only one set of "channel" tables are
defined to be used for both fast and interleaved channels. The defined to be used for both fast and interleaved channels. The
corresponding ifType gives the proper interpretation for that corresponding ifType gives the proper interpretation for that
ifEntry. ifEntry.
The MIB definitions are attached. The MIB will eventually be located
in the MIB tree under mib-2 transmission, further discussed in
section 6 of this document.
It is intented that Line Code Specific MIBs be located under It is intented that Line Code Specific MIBs be located under
adslLCSMib. These MIBs will be defined in separate modules. adslLCSMib. These MIBs will be defined in separate modules.
There could have been fewer tables by combining the ATU-C and ATU-R There could have been fewer tables by combining the ATU-C and ATU-R
information into shared tables. However, the tables are more easily information into shared tables. However, the tables are more easily
read when there are two identical sets of data. read when there are two identical sets of data.
The figure below lists the five possible ADSL operational The figure below lists the five possible ADSL operational
configurations. (indicated by the value of the adslLineType). In all configurations. (indicated by the value of the adslLineType). In all
configurations, the physical line interface entry will exist. configurations, the physical line interface entry will exist.
skipping to change at page 10, line 45 skipping to change at page 10, line 30
adslAtucChanIntervalTable | | Y | Y | adslAtucChanIntervalTable | | Y | Y |
adslAturChanIntervalTable | | Y | Y | adslAturChanIntervalTable | | Y | Y |
Figure 6: Use of ADSL MIB Tables with various ifIndex values Figure 6: Use of ADSL MIB Tables with various ifIndex values
NOTE: The adslLineConfProfileTable and adslLineAlarmConfProfileTable NOTE: The adslLineConfProfileTable and adslLineAlarmConfProfileTable
will be present for all scenarios. See Profile Section of this will be present for all scenarios. See Profile Section of this
document for implementation details such as profile creation, document for implementation details such as profile creation,
assignment, and indexing. assignment, and indexing.
7.2.1 Structure of Conformance Groups 6.2.1 Structure of Conformance Groups
The MIB is organized to cover both ends of the ADSL line, ATU-C and 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-R. Objects defined can be categorized into two groups: the
ATU-C group which provides objects that are supported by ATU-C agents 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 and the ATU-R group which provides objects that are supported by
ATU-R agents. These two groups are defined by the conformance ATU-R agents. These two groups are defined by the conformance
section of the MIB. All objects defined in the MIB module are 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-C agent and only portions of the objects are
supported by the ATU-R agent. Figure 7 lists all tables/objects that supported by the ATU-R agent. Figure 7 lists all tables/objects that
are supported by the ATU-R agent. are supported by the ATU-R agent.
skipping to change at page 12, line 15 skipping to change at page 11, line 48
adslAtucPerfLofsThreshTrap adslAtucPerfLofsThreshTrap
adslAtucPerfLossThreshTrap adslAtucPerfLossThreshTrap
adslAtucPerfESsThreshTrap adslAtucPerfESsThreshTrap
adslAtucRateChangeTrap adslAtucRateChangeTrap
adslAturPerfLofsThreshTrap adslAturPerfLofsThreshTrap
adslAturPerfLossThreshTrap adslAturPerfLossThreshTrap
adslAturPerfLprsThreshTrap adslAturPerfLprsThreshTrap
adslAturPerfESsThreshTrap adslAturPerfESsThreshTrap
adslAturRateChangeTrap adslAturRateChangeTrap
7.3 Counters, Interval Buckets and Thresholds 6.3 Counters, Interval Buckets and Thresholds
For physical-level ES, Los, Lof, Lol, Lpr and line initialization For physical-level ES, Los, Lof, Lol, Lpr and line initialization
attempts, there are event counters, current 15-minute and one (up to attempts, there are event counters, current 15-minute and one (up to
96) 15-minute history bucket(s) of "interval-counters", as well as 96) 15-minute history bucket(s) of "interval-counters", as well as
current and previous 1-day interval-counters. Each physical-layer current and previous 1-day interval-counters. Each physical-layer
current 15-minute event bucket has threshold trap. current 15-minute event bucket has threshold trap.
At the channel level, there are counters for total received blocks, At the channel level, there are counters for total received blocks,
received-and-corrected blocks, received-but-uncorrectable blocks, and received-and-corrected blocks, received-but-uncorrectable blocks, and
transmitted blocks. There are the same set of 15-minute and 1-day transmitted blocks. There are the same set of 15-minute and 1-day
skipping to change at page 12, line 46 skipping to change at page 12, line 32
Counters are not reset when an ATU-C or ATU-R is reinitialized, only 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 when the agent is reset or reinitialized (or under specific request
outside the scope of this MIB). outside the scope of this MIB).
The 15-minute event counters are of type PerfCurrentCount and The 15-minute event counters are of type PerfCurrentCount and
PerfIntervalCount. The 1-day event counters are of type PerfIntervalCount. The 1-day event counters are of type
AdslPerfCurrDayCount and AdslPerfPrevDayCount. Both 15-minute and 1- AdslPerfCurrDayCount and AdslPerfPrevDayCount. Both 15-minute and 1-
day time elapsed counters are of type AdslPerfTimeElapsed. day time elapsed counters are of type AdslPerfTimeElapsed.
7.4 Profiles 6.4 Profiles
As a managed node can handle a large number of ATU-Cs (e.g., hundreds 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 or perhaps thousands of ADSL lines), provisioning every parameter on
every ATU-C may become burdensome. In response, two MIB tables have every ATU-C may become burdensome. In response, two MIB tables have
been created to define ADSL equipment configuration data profiles, as been created to define ADSL equipment configuration data profiles, as
well as a mechanism to associate the equipment to these profiles. well as a mechanism to associate the equipment to these profiles.
Profile tables may be implemented in one of two ways, but not Profile tables may be implemented in one of two ways, but not
simultaneously: simultaneously:
o MODE-I: Dynamic Profiles - one profile shared by one or multiple o MODE-I: Dynamic Profiles - one profile shared by one or multiple
ADSL lines. ADSL lines.
o MODE-II: Static Profiles - one profile per ADSL physical line o MODE-II: Static Profiles - one profile per ADSL physical line
always. always.
7.4.1 MODE-I : Dynamic Profiles 6.4.1 MODE-I : Dynamic Profiles
Implementations using this mode will enable the manager to Implementations using this mode will enable the manager to
dynamically create and delete profiles as needed. The index of the dynamically create and delete profiles as needed. The index of the
profile is an locally-unique administratively assigned name for the profile is an locally-unique administratively assigned name for the
profile having the textual convention `SnmpAdminString' profile having the textual convention `SnmpAdminString'
(RFC2271[13]). (RFC2271[13]).
One or more ADSL lines may be configured to share parameters of a One or more ADSL lines may be configured to share parameters of a
single profile (e.g., adslLineConfProfileName = `silver') by setting single profile (e.g., adslLineConfProfileName = `silver') by setting
its adslLineConfProfile objects to the index value of this profile. its adslLineConfProfile objects to the index value of this profile.
skipping to change at page 14, line 44 skipping to change at page 14, line 29
values of the associated parameters will be vendor specific unless values of the associated parameters will be vendor specific unless
otherwise indicated in this document. Before a line's profiles have otherwise indicated in this document. Before a line's profiles have
been set, these profiles will be automatically used by setting been set, these profiles will be automatically used by setting
adslLineConfProfile and adslLineAlarmConfProfile to `DEFVAL'. adslLineConfProfile and adslLineAlarmConfProfile to `DEFVAL'.
In this mode, profiles are created, assigned, and deleted dynamically In this mode, profiles are created, assigned, and deleted dynamically
using these four objects: adslLineConfProfile, using these four objects: adslLineConfProfile,
adslLineConfProfileRowStatus, adslLineAlarmConfProfile, and adslLineConfProfileRowStatus, adslLineAlarmConfProfile, and
adslLineAlarmConfProfileRowStatus. adslLineAlarmConfProfileRowStatus.
7.4.2 MODE-II : Static Profiles 6.4.2 MODE-II : Static Profiles
Implementations with this mode will automatically create a profile Implementations with this mode will automatically create a profile
one-for-one with each ADSL line physical entry. The name of this one-for-one with each ADSL line physical entry. The name of this
profile is a system generated read-only object whose value is profile is a system generated read-only object whose value is
equivalent to the index of the physical line. The Agent will not equivalent to the index of the physical line. The Agent will not
allow a Manager to create/delete profiles in this mode. Therefore, allow a Manager to create/delete profiles in this mode. Therefore,
adslLineConfProfile, adslLineConfProfileRowStatus, adslLineConfProfile, adslLineConfProfileRowStatus,
adslLineAlarmConfProfile, and adslLineAlarmConfProfileRowStatus adslLineAlarmConfProfile, and adslLineAlarmConfProfileRowStatus
objects have minimal value in this mode and are read-only. objects have minimal value in this mode and are read-only.
skipping to change at page 15, line 30 skipping to change at page 15, line 17
j2 Fast Chan j2 Fast Chan
k2 Int Chan k2 Int Chan
x ix ADSL Line ------------> Profile x ix ADSL Line ------------> Profile
jx Fast Chan jx Fast Chan
kx Int Chan kx Int Chan
__________________________________________________________________ __________________________________________________________________
Figure 9: Use of Static Profiles: MODE II Figure 9: Use of Static Profiles: MODE II
7.5 Traps 6.5 Traps
These SNMP traps are required: coldStart / warmStart (per [6]) -- These SNMP traps are required: coldStart / warmStart (per [6]) --
which are per agent (e.g., per DSLAM in such a device), and linkUp / 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). linkDown (per [5]) -- which are per interface (i.e., ADSL line).
Note: RFC 2233 [5] recommends that linkUp / linkDown only be used at Note: RFC 2233 [5] recommends that linkUp / linkDown only be used at
a physical-layer ifEntry, as discussed above. a physical-layer ifEntry, as discussed above.
A linkDown trap is generated whenever any of Lof, Los, Lol, or Lpr A linkDown trap is generated whenever any of Lof, Los, Lol, Loss of
occurs. At this operational point, a manager can use Signal Quality, or Lpr events occurs. At this operational point, a
adslAtu*CurrStatus for additional detailed information. The manager can use adslAtu*CurrStatus for additional detailed
corresponding linkUp trap is sent when all link failure conditions information. The corresponding linkUp trap is sent when all link
are cleared. failure conditions are cleared.
The traps defined in this MIB are for initialization failure, rate The traps defined in this MIB are for initialization failure, rate
change, and for the threshold crossings associated with the following change, and for the threshold crossings associated with the following
events: Lofs, Lols, Loss, Lprs, and ESs. Each threshold has its own events: Lofs, Lols, Loss, Lprs, and ESs. Each threshold has its own
enable/threshold value. When that value is 0, the trap is disabled. enable/threshold value. When that value is 0, the trap is disabled.
The current status objects (adslAtu*CurrStatus) indicate, through a The current status objects (adslAtu*CurrStatus) indicate, through a
bitmask, all outstanding error conditions or that the line is bitmask, all outstanding error conditions or that the line is
operational. Note that each object claims to represent the status of operational. Note that each object claims to represent the status of
the modem at that end of the line. However, since the SNMP agent the modem at that end of the line. However, since the SNMP agent
skipping to change at page 17, line 5 skipping to change at page 16, line 36
No trap is sent on initialization. No trap is sent on initialization.
It can be disabled by setting the Up (and/or) Down threshold rates to It can be disabled by setting the Up (and/or) Down threshold rates to
0. 0.
The PrevTxRate object is set to the current value at initialization The PrevTxRate object is set to the current value at initialization
and when a trap is sent. Thus rate changes are cumulative until the and when a trap is sent. Thus rate changes are cumulative until the
total change reaches the threshold. total change reaches the threshold.
8. Conformance and Compliance 7. Conformance and Compliance
See the conformance and compliance statements within the information See the conformance and compliance statements within the information
module. module.
9. Definitions 8. Definitions
ADSL-TC-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, Gauge32,
OBJECT-TYPE, mib-2 FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC;
adsltcmib MODULE-IDENTITY
LAST-UPDATED "9905052200Z"
ORGANIZATION "IETF ADSL MIB Working Group"
CONTACT-INFO
"
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
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
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."
::= { mib-2 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 ADSL-LINE-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, MODULE-IDENTITY, OBJECT-TYPE,
Counter32, Gauge32, Counter32, Gauge32,
NOTIFICATION-TYPE, experimental, NOTIFICATION-TYPE,
transmission, Unsigned32 FROM SNMPv2-SMI transmission, Unsigned32 FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus, RowStatus,
TruthValue, VariablePointer FROM SNMPv2-TC TruthValue, VariablePointer FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP FROM SNMPv2-CONF NOTIFICATION-GROUP FROM SNMPv2-CONF
ifIndex FROM IF-MIB ifIndex FROM IF-MIB
PerfCurrentCount, PerfCurrentCount,
PerfIntervalCount FROM PerfHist-TC-MIB PerfIntervalCount FROM PerfHist-TC-MIB
SnmpAdminString FROM SNMP-FRAMEWORK-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB
AdslPerfCurrDayCount,
AdslPerfPrevDayCount,
AdslPerfTimeElapsed,
AdslLineCodingType FROM ADSL-TC-MIB
; ;
adslMIB MODULE-IDENTITY adslMIB MODULE-IDENTITY
LAST-UPDATED "9902261200Z" LAST-UPDATED "9905052200Z"
ORGANIZATION "IETF ADSL MIB Working Group" ORGANIZATION "IETF ADSL MIB Working Group"
CONTACT-INFO CONTACT-INFO
" "
Gregory Bathrick Gregory Bathrick
AG Communication Systems AG Communication Systems
A Subsidiary of Lucent Technologies A Subsidiary of Lucent Technologies
2500 W Utopia Rd. 2500 W Utopia Rd.
Phoenix, AZ 85027 USA Phoenix, AZ 85027 USA
skipping to change at page 19, line 11 skipping to change at page 21, line 15
xxxs-- interval of Seconds in which xxx occurs xxxs-- interval of Seconds in which xxx occurs
(e.g., xxx=Lof, Los, Lpr) (e.g., xxx=Lof, Los, Lpr)
Max -- Maximum Max -- Maximum
Mgn -- Margin Mgn -- Margin
Min -- Minimum Min -- Minimum
Psd -- Power Spectral Density Psd -- Power Spectral Density
Snr -- Signal to Noise Ratio Snr -- Signal to Noise Ratio
Tx -- Transmit Tx -- Transmit
Blks-- Blocks, a data unit, see Blks-- Blocks, a data unit, see
adslAtuXChanCrcBlockLength adslAtuXChanCrcBlockLength
" " ::= { transmission 94 }
REVISION "9808071200Z" -- v00
DESCRIPTION
"Changes taken at the March 98 ADSL WG meeting:
- Added Conformance Statement
- SNMPv3 conformance
- RFC-2233 conformance
Comments from Technical Advisors, Wijnen and Tesink:
- DisplayString -> UTF-8 String
- minimized # of mandatory performance counts
- Corrected Syntax of current status objects.
- Corrected use of SNMP SMI.
Lessons learned through implementation of MIB (ADSLF TR006):
- clarified definition of channel block size, SNR
Interleave Delay, Attenuation, and Output power.
- corrected UNITS and SYNTAX of adsl rate objects,
Version#, VendorID.
- added missing line activation objects.
General editorial cleanup.
Added Security Statement (Dave Allan)
"
REVISION "9808071200Z" -- v01
DESCRIPTION
"General editorial cleanup.
"
REVISION "9810301200Z" -- v02
DESCRIPTION
"
Changes taken at the August 98 ADSL WG meeting:
- Used PerfCurrentCount and PerfIntervalCount
when appropriate.
- Updated Security Statement to conform with
current format.
- Changed SYNTAX of Serial #, Vendor ID, and
Version # to `OCTET STRING'.
Comments taken from Jeff Johnson and other WG
contributors:
- Removed references to MIB-2 and RFC-1213.
- Re-organized the `Use of IF-MIB' section for
clarification and conformance reasons.
- Changed definition of profile control objects:
For the static profiles, they are read-only.
Updated conformance statements in a likely
manner.
- Removed references to ifTestTypes. IF-MIB does
support at this time.
- Minor changes to entity mib section.
- Changed SYNTAX of SNR, Attenuation, Attainable rate,
and Output power to `Gauge32`.
- Changed SYNTAX of adslLineSpecific to VariablePointer.
- Swapped lossOfLink(4) and lossOfSignalQuality(5) of
Atuc Current Status to line up better with Atur
Current Status.
- Removed ifIndex from traps
- and many additional and useful editorial comments.
"
REVISION "9811161200Z" -- v03
DESCRIPTION
"
Changes:
- updated text and conformance statements to include
CPE equipment view.
- updated text and objects to change profile tables
index to SnmpAdminString.
- changed transmission xx to experimental 89.
- resolved conflicting statements on when traps occur.
- added Faye Ly as co-editor and Ted Soo-Hoo and
Umberto Bonollo as contributors.
"
REVISION "9812211200Z" -- v04
DESCRIPTION
"
Changes (as agreed to made at the Orlando meeting).
- editorial corrections related to past CPE view updates.
- technical clarifications related to the use of profiles.
"
REVISION "9902261200Z" -- v05
DESCRIPTION
"Group Last Call agreements:
- Added AdslPerfCurrDayCount TC for current 1 day event
counts which clarifies their meaning. Assigned all
current 1 day event counter objects to it.
- Added AdslPerfPrevDayCount TC for previous 1 day
event counts which clarifies their meaning. Assigned
all curr 1 day event counter objects to it.
- Clarified meaning of Valid Data Flag to maintain
usefulness when using when used with RFC-2493.
- Updated descriptions of xxxValidIntervals and
xxxxInvalidIntervals objects to conform with
latest definitions of RFC-2493.
- Added AdslPerfTimeElapsed TC for both 15 min and 1
day type elapsed time counters. Its definition was
dervived from RFC-2493. Assigned range of 15 minute
counters to be 0..899 and 1 day counters to
be 0..86399.
- Clarified definition of prev 1 day monitored second.
- Added associated count object to the var bin of
threshold traps. Clarified that only one trap will
be sent per interval per interface.
- Updated SYNTAX of all R/W rate objects to be
Unsigned32.
- Updated SYNTAX of Serial #, Vendor ID, and Version #
to be SnmpAdminString. Clarified description.
- Corrected Range of SNR margin objects to be -64
to +63.5 dB.
- Added text as directed by IETF editor, `This document
is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.'
- Conformed to new SMI RFC (draft-ops-smiv2-smi-00.txt)
- Editorial changes:
- Corrected resolution problems with
adslLineAlarmProfile, adslAturAturPhysicalGroup, and
adslAturLineProfileGroup
- Corrected problem with traps names.
"
::= { experimental 89 } -- to be assigned to `94' by IANA given IESG
-- approval.
adslLineMib OBJECT IDENTIFIER ::= { adslMIB 1 } adslLineMib OBJECT IDENTIFIER ::= { adslMIB 1 }
adslMibObjects OBJECT IDENTIFIER ::= { adslLineMib 1 } adslMibObjects OBJECT IDENTIFIER ::= { adslLineMib 1 }
-- textual conventions
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
-- objects -- objects
adslLineTable OBJECT-TYPE adslLineTable OBJECT-TYPE
SYNTAX SEQUENCE OF AdslLineEntry SYNTAX SEQUENCE OF AdslLineEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This table includes common attributes describing "This table includes common attributes describing
both ends of the line. It is required for all ADSL both ends of the line. It is required for all ADSL
physical interfaces. ADSL physical interfaces are physical interfaces. ADSL physical interfaces are
those ifEntries where ifType is equal to adsl(94)." those ifEntries where ifType is equal to adsl(94)."
skipping to change at page 23, line 26 skipping to change at page 21, line 43
adslLineEntry OBJECT-TYPE adslLineEntry OBJECT-TYPE
SYNTAX AdslLineEntry SYNTAX AdslLineEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION "An entry in adslLineTable." DESCRIPTION "An entry in adslLineTable."
INDEX { ifIndex } INDEX { ifIndex }
::= { adslLineTable 1 } ::= { adslLineTable 1 }
AdslLineEntry ::= AdslLineEntry ::=
SEQUENCE { SEQUENCE {
adslLineCoding INTEGER, adslLineCoding AdslLineCodingType,
adslLineType INTEGER, adslLineType INTEGER,
adslLineSpecific VariablePointer, adslLineSpecific VariablePointer,
adslLineConfProfile SnmpAdminString, adslLineConfProfile SnmpAdminString,
adslLineAlarmConfProfile SnmpAdminString adslLineAlarmConfProfile SnmpAdminString
} }
adslLineCoding OBJECT-TYPE adslLineCoding OBJECT-TYPE
SYNTAX INTEGER { SYNTAX AdslLineCodingType
other (1),
dmt (2), -- Discrete MultiTone
cap (3), -- Carrierless Amplitude & Phase modulation
qam (4) -- Quadrature Amplitude Modulation
}
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Specifies the ADSL coding type used on this line. "Specifies the ADSL coding type used on this
Other types may be added in the future." line."
::= { adslLineEntry 1 } ::= { adslLineEntry 1 }
adslLineType OBJECT-TYPE adslLineType OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
noChannel (1), -- no channels exist noChannel (1), -- no channels exist
fastOnly (2), -- fast channel exists only fastOnly (2), -- fast channel exists only
interleavedOnly (3), -- interleaved channel exists interleavedOnly (3), -- interleaved channel exists
-- only -- only
fastOrInterleaved (4),-- either fast or interleaved fastOrInterleaved (4),-- either fast or interleaved
-- channels can exist, but -- channels can exist, but
skipping to change at page 26, line 31 skipping to change at page 24, line 45
::= { adslAtucPhysEntry 1 } ::= { adslAtucPhysEntry 1 }
adslAtucInvVendorID OBJECT-TYPE adslAtucInvVendorID OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..16)) SYNTAX SnmpAdminString (SIZE (0..16))
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The vendor ID code is a copy of the binary "The vendor ID code is a copy of the binary
vendor identification field defined by the vendor identification field defined by the
PHY[10] and expressed as readable characters." PHY[10] and expressed as readable characters."
REFERENCE "ANSI T1.413[10]"
::= { adslAtucPhysEntry 2 } ::= { adslAtucPhysEntry 2 }
adslAtucInvVersionNumber OBJECT-TYPE adslAtucInvVersionNumber OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..16)) SYNTAX SnmpAdminString (SIZE (0..16))
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The vendor specific version number sent by this ATU "The vendor specific version number sent by this ATU
as part of the initialization messages. It is a copy as part of the initialization messages. It is a copy
of the binary version number field defined by the of the binary version number field defined by the
PHY[10] and expressed as readable characters." PHY[10] and expressed as readable characters."
REFERENCE "ANSI T1.413[10]"
::= { adslAtucPhysEntry 3 } ::= { adslAtucPhysEntry 3 }
-- current status group -- current status group
-- --
adslAtucCurrSnrMgn OBJECT-TYPE adslAtucCurrSnrMgn OBJECT-TYPE
SYNTAX INTEGER (-640..640) SYNTAX INTEGER (-640..640)
UNITS "tenth dB" UNITS "tenth dB"
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
skipping to change at page 30, line 11 skipping to change at page 28, line 27
::= { adslAturPhysEntry 1 } ::= { adslAturPhysEntry 1 }
adslAturInvVendorID OBJECT-TYPE adslAturInvVendorID OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..16)) SYNTAX SnmpAdminString (SIZE (0..16))
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The vendor ID code is a copy of the binary "The vendor ID code is a copy of the binary
vendor identification field defined by the vendor identification field defined by the
PHY[10] and expressed as readable characters." PHY[10] and expressed as readable characters."
REFERENCE "ANSI T1.413"
::= { adslAturPhysEntry 2 } ::= { adslAturPhysEntry 2 }
adslAturInvVersionNumber OBJECT-TYPE adslAturInvVersionNumber OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..16)) SYNTAX SnmpAdminString (SIZE (0..16))
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The vendor specific version number sent by this ATU "The vendor specific version number sent by this ATU
as part of the initialization messages. It is a copy as part of the initialization messages. It is a copy
of the binary version number field defined by the of the binary version number field defined by the
PHY[10] and expressed as readable characters." PHY[10] and expressed as readable characters."
REFERENCE "ANSI T1.413"
::= { adslAturPhysEntry 3 } ::= { adslAturPhysEntry 3 }
-- current status group -- current status group
-- --
adslAturCurrSnrMgn OBJECT-TYPE adslAturCurrSnrMgn OBJECT-TYPE
SYNTAX INTEGER (-640..640) SYNTAX INTEGER (-640..640)
UNITS "tenth dB" UNITS "tenth dB"
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
skipping to change at page 33, line 28 skipping to change at page 31, line 46
UNITS "bps" UNITS "bps"
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Actual transmit rate on this channel." "Actual transmit rate on this channel."
::= { adslAtucChanEntry 2 } ::= { adslAtucChanEntry 2 }
adslAtucChanPrevTxRate OBJECT-TYPE adslAtucChanPrevTxRate OBJECT-TYPE
SYNTAX Gauge32 SYNTAX Gauge32
UNITS "bps" UNITS "bps"
MAX-ACCESS accessible-for-notify MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The rate at the time of the last "The rate at the time of the last
adslAtucRateChangeTrap event. It is also set at adslAtucRateChangeTrap event. It is also set at
initialization to prevent a trap being sent. initialization to prevent a trap being sent.
Rate changes less than adslAtucThresh(*)RateDown Rate changes less than adslAtucThresh(*)RateDown
or less than adslAtucThresh(*)RateUp will not or less than adslAtucThresh(*)RateUp will not
cause a trap or cause this object to change. cause a trap or cause this object to change.
(*) == Fast or Interleave. (*) == Fast or Interleave.
skipping to change at page 35, line 21 skipping to change at page 33, line 38
UNITS "bps" UNITS "bps"
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Actual transmit rate on this channel." "Actual transmit rate on this channel."
::= { adslAturChanEntry 2 } ::= { adslAturChanEntry 2 }
adslAturChanPrevTxRate OBJECT-TYPE adslAturChanPrevTxRate OBJECT-TYPE
SYNTAX Gauge32 SYNTAX Gauge32
UNITS "bps" UNITS "bps"
MAX-ACCESS accessible-for-notify MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The rate at the time of the last "The rate at the time of the last
adslAturRateChangeTrap event. It is also set at adslAturRateChangeTrap event. It is also set at
initialization to prevent a trap being sent. initialization to prevent a trap being sent.
Rate changes less than adslAturThresh(*)RateDown Rate changes less than adslAturThresh(*)RateDown
or less than adslAturThresh(*)RateUp will not or less than adslAturThresh(*)RateUp will not
cause a trap or cause this object to change. cause a trap or cause this object to change.
(*) == Fast or Interleave. (*) == Fast or Interleave.
skipping to change at page 89, line 32 skipping to change at page 88, line 4
adslAturRateChangeTrap NOTIFICATION-TYPE adslAturRateChangeTrap NOTIFICATION-TYPE
OBJECTS { adslAturChanCurrTxRate, OBJECTS { adslAturChanCurrTxRate,
adslAturChanPrevTxRate } adslAturChanPrevTxRate }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The ATURs transmit rate has changed (RADSL mode only)" "The ATURs transmit rate has changed (RADSL mode only)"
::= { adslAturTraps 0 5 } ::= { adslAturTraps 0 5 }
-- no adslAturPerfLolsThreshTrap possible { 0 6 } -- no adslAturPerfLolsThreshTrap possible { 0 6 }
-- no adslAturInitFailureTrap possible { 0 7 } -- no adslAturInitFailureTrap possible { 0 7 }
-- conformance information -- conformance information
adslConformance OBJECT IDENTIFIER ::= { adslLineMib 3 } adslConformance OBJECT IDENTIFIER ::= { adslLineMib 3 }
adslGroups OBJECT IDENTIFIER ::= { adslConformance 1 } adslGroups OBJECT IDENTIFIER ::= { adslConformance 1 }
adslCompliances OBJECT IDENTIFIER ::= { adslConformance 2 } adslCompliances OBJECT IDENTIFIER ::= { adslConformance 2 }
-- compliance statements -- ATU-C agent compliance statements
adslLineMibCompliance MODULE-COMPLIANCE adslLineMibAtucCompliance MODULE-COMPLIANCE
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The compliance statement for SNMP entities "The compliance statement for SNMP entities
which have ADSL interfaces." which manage ADSL ATU-C interfaces."
MODULE -- this module MODULE -- this module
MANDATORY-GROUPS MANDATORY-GROUPS
{ {
adslLineGroup, adslPhysicalGroup, adslChannelGroup, adslLineGroup, adslPhysicalGroup, adslChannelGroup,
adslAtucPhysPerfIntervalGroup, adslAtucPhysPerfIntervalGroup,
adslAturPhysPerfIntervalGroup, adslLineConfProfileGroup, adslAturPhysPerfIntervalGroup, adslLineConfProfileGroup,
adslLineAlarmConfProfileGroup, adslLineAlarmConfProfileGroup,
adslLineConfProfileControlGroup adslLineConfProfileControlGroup
} }
GROUP adslAtucPhysPerfRawCounterGroup GROUP adslAtucPhysPerfRawCounterGroup
DESCRIPTION DESCRIPTION
"This group is optional." "This group is optional. Implementations which
require continuous ATU-C physical event counters
should implement this group."
GROUP adslAturPhysPerfRawCounterGroup GROUP adslAturPhysPerfRawCounterGroup
DESCRIPTION DESCRIPTION
"This group is optional." "This group is optional. Implementations which
require continuous ATU-R physical event counters
should implement this group."
GROUP adslAtucChanPerformanceGroup GROUP adslAtucChanPerformanceGroup
DESCRIPTION DESCRIPTION
"This group is optional." "This group is optional. Implementations which
require ATU-C channel block event counters should
implement this group."
GROUP adslAturChanPerformanceGroup GROUP adslAturChanPerformanceGroup
DESCRIPTION DESCRIPTION
"This group is optional." "This group is optional. Implementations which
require ATU-R channel block event counters should
implement this group."
OBJECT adslAtucIntervalNumber OBJECT adslAtucIntervalNumber
SYNTAX INTEGER (1..1) SYNTAX INTEGER (1..1)
DESCRIPTION DESCRIPTION
"It is allowable to implement only one ATU-C 15-minute "It is allowable to implement only one ATU-C 15-minute
performance interval." performance interval."
OBJECT adslAturIntervalNumber OBJECT adslAturIntervalNumber
SYNTAX INTEGER (1..1) SYNTAX INTEGER (1..1)
DESCRIPTION DESCRIPTION
skipping to change at page 91, line 32 skipping to change at page 90, line 10
profiles are implemented." profiles are implemented."
OBJECT adslLineAlarmConfProfileRowStatus OBJECT adslLineAlarmConfProfileRowStatus
MIN-ACCESS read-only MIN-ACCESS read-only
DESCRIPTION DESCRIPTION
"Read-only access is applicable only when static "Read-only access is applicable only when static
profiles are implemented." profiles are implemented."
::= { adslCompliances 1 } ::= { adslCompliances 1 }
-- Atur compliance statements -- ATU-R agent compliance statements
adslLineMibAturCompliance MODULE-COMPLIANCE adslLineMibAturCompliance MODULE-COMPLIANCE
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The compliance statement for SNMP entities "The compliance statement for SNMP entities
which manage ADSL ATU-R interfaces." which manage ADSL ATU-R interfaces."
MODULE -- this module MODULE -- this module
MANDATORY-GROUPS MANDATORY-GROUPS
{ {
adslAturLineGroup, adslAturPhysicalGroup, adslAturLineGroup, adslAturPhysicalGroup,
adslAturChannelGroup, adslAturChannelGroup,
adslAturAtucPhysPerfIntervalGroup, adslAturAtucPhysPerfIntervalGroup,
adslAturAturPhysPerfIntervalGroup, adslAturAturPhysPerfIntervalGroup,
adslAturLineAlarmConfProfileGroup, adslAturLineAlarmConfProfileGroup,
adslAturLineConfProfileControlGroup adslAturLineConfProfileControlGroup
} }
GROUP adslAturAtucPhysPerfRawCounterGroup GROUP adslAturAtucPhysPerfRawCounterGroup
DESCRIPTION DESCRIPTION
"This group is optional." "This group is optional. Implementations which
require continuous ATU-C physical event counters
should implement this group."
GROUP adslAturAturPhysPerfRawCounterGroup GROUP adslAturAturPhysPerfRawCounterGroup
DESCRIPTION DESCRIPTION
"This group is optional." "This group is optional. Implementations which
require continuous ATU-R physical event counters
should implement this group."
GROUP adslAturAtucChanPerformanceGroup GROUP adslAturAtucChanPerformanceGroup
DESCRIPTION DESCRIPTION
"This group is optional." "This group is optional. Implementations which
require ATU-C channel block event counters should
implement this group."
GROUP adslAturAturChanPerformanceGroup GROUP adslAturAturChanPerformanceGroup
DESCRIPTION DESCRIPTION
"This group is optional." "This group is optional. Implementations which
require ATU-R channel block event counters should
implement this group."
OBJECT adslAtucIntervalNumber OBJECT adslAtucIntervalNumber
SYNTAX INTEGER (1..1) SYNTAX INTEGER (1..1)
DESCRIPTION DESCRIPTION
"It is allowable to implement only one ATU-C 15-minute "It is allowable to implement only one ATU-C 15-minute
performance interval." performance interval."
OBJECT adslAturIntervalNumber OBJECT adslAturIntervalNumber
SYNTAX INTEGER (1..1) SYNTAX INTEGER (1..1)
DESCRIPTION DESCRIPTION
skipping to change at page 103, line 46 skipping to change at page 102, line 33
adslAturPerfLofsThreshTrap, adslAturPerfLofsThreshTrap,
adslAturPerfLossThreshTrap, adslAturPerfLossThreshTrap,
adslAturPerfLprsThreshTrap, adslAturPerfLprsThreshTrap,
adslAturPerfESsThreshTrap, adslAturPerfESsThreshTrap,
adslAturRateChangeTrap adslAturRateChangeTrap
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The collection of ADSL notifications implemented by "The collection of ADSL notifications implemented by
the ATU-R agent." the ATU-R agent."
::= { adslGroups 25 } ::= { adslGroups 25 } END
END 9. Acknowledgments
10. Acknowledgments The current authors/editors are:
The current editors are:
Gregory Bathrick (AG Communication Systems) Gregory Bathrick (AG Communication Systems)
Faye Ly (Copper Mountain Networks) Faye Ly (Copper Mountain Networks)
Input from the ADSL Forum was edited by: Input from the ADSL Forum was edited by:
Gregory Bathrick (AG Communication Systems) Gregory Bathrick (AG Communication Systems)
John Burgess (Predictive Systems) John Burgess (Predictive Systems)
Contributions have been received from, but not limited to the Contributions have been received from, but not limited to the
following. (in alphabetical order) following. (in alphabetical order)
David Allen (Nortel) David Allen (Nortel)
Rajesh Abbi (Alcatel) Rajesh Abbi (Alcatel)
Gregory Bathrick (AG Communication Systems) Gregory Bathrick (AG Communication Systems)
Umberto Bonollo (NEC) Umberto Bonollo (NEC)
John Burgess (Predictive Systems) John Burgess (Predictive Systems)
Gail Cone (Amati) Gail Cone (Amati)
Andrew Cheer (NEC) Andrew Cheers (NEC)
Peter Duffy (Atlantech) Peter Duffy (Atlantech)
Kevin Godfrey (Motorola) Kevin Godfrey (Motorola)
Bill Hong (Diamond Lane) Bill Hong (Diamond Lane)
Bob Jenness (Siemens) Bob Jenness (Siemens)
Lars Johansson (Ericsson) Lars Johansson (Ericsson)
Jeff Johnson (RedBack Network) Jeff Johnson (RedBack Network)
Tsu Kai Lu (DSC) Tsu Kai Lu (DSC)
Faye Ly (Copper Mountain Networks) Faye Ly (Copper Mountain Networks)
Gigi Karmous-Edwards (Pulsecom) Gigi Karmous-Edwards (Pulsecom)
Ron Knipper (Diamond Lane) Ron Knipper (Diamond Lane)
skipping to change at page 104, line 47 skipping to change at page 103, line 32
Donald Simon (Motorola) Donald Simon (Motorola)
Mike Sneed (Pulsecom) Mike Sneed (Pulsecom)
Ted Soo-Hoo (Pulsecom) Ted Soo-Hoo (Pulsecom)
John Stehman (Diamond Lane) John Stehman (Diamond Lane)
Chuck Storry (Newbridge) Chuck Storry (Newbridge)
Chi-Lin Tom (AFC) Chi-Lin Tom (AFC)
Frank Van der Putten (Alcatel) Frank Van der Putten (Alcatel)
Marc Van Vlimmeren (Alcatel) Marc Van Vlimmeren (Alcatel)
Bert Wijnen (IBM) Bert Wijnen (IBM)
11. References 10. References
[1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Structure of Management Information for Version S. Waldbusser, "Structure of Management Information for Version
2 of the Simple Network Management Protocol (SNMPv2)", 2 of the Simple Network Management Protocol (SNMPv2)",
RFC 1902, January 1996. RFC 1902, January 1996.
[2] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, [2] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Textual Conventions for SNMPv2", RFC 1903, SNMP Research, "Textual Conventions for SNMPv2", RFC 1903, SNMP Research,
Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996. International Network Services, January 1996.
skipping to change at page 105, line 29 skipping to change at page 104, line 14
[5] McCloghrie, K. and F. Kastenholz, "The Interfaces Group [5] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB using SMIv2", RFC 2233, Cisco Systems, FTP Software, MIB using SMIv2", RFC 2233, Cisco Systems, FTP Software,
November 1997. November 1997.
[6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
and S. Waldbusser, "Management Information Base for and S. Waldbusser, "Management Information Base for
version 2 of the Simple Network Management Protocol version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1907, January 1996. (SNMPv2)", RFC 1907, January 1996.
[6] RFC 1907, "Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2)", January 1996.
[7] Case, J., Fedor, M., Schoffstall, M., and J. Davin. " A Simple [7] Case, J., Fedor, M., Schoffstall, M., and J. Davin. " A Simple
Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP
Research, Performance Systems International, MIT Lab for Research, Performance Systems International, MIT Lab for
Computer Science, May 1990. Computer Science, May 1990.
[8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Protocol Operations for Version 2 of the Simple S. Waldbusser, "Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1905, January 1996. Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[9] ADSL Forum TR-006, "SNMP-based ADSL Line MIB", March 1998. [9] ADSL Forum TR-006, "SNMP-based ADSL Line MIB", March 1998.
skipping to change at page 107, line 17 skipping to change at page 105, line 46
[24] Ahmed, M., and K. Tesink, Editors, "Definitions of Managed [24] Ahmed, M., and K. Tesink, Editors, "Definitions of Managed
Objects for ATM Management Version 8.0 using SMIv2", RFC 1695, Objects for ATM Management Version 8.0 using SMIv2", RFC 1695,
Bell Communications Research, August 1994. Bell Communications Research, August 1994.
[25] McCloghrie, K. and A. Bierman, "Entity MIB", RFC 2037, October [25] McCloghrie, K. and A. Bierman, "Entity MIB", RFC 2037, October
1996. 1996.
[26] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO [26] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
10646", RFC 2044, October 1996. 10646", RFC 2044, October 1996.
12. Security Considerations 11. Security Considerations
1) Blocking unauthorized access to the ADSL MIB via the element 1) Blocking unauthorized access to the ADSL MIB via the element
management system is outside the scope of this document. It should be management system is outside the scope of this document. It should be
noted that access to the MIB permits the unauthorized entity to noted that access to the MIB permits the unauthorized entity to
modify the profiles (sect 7.4) such that both subscriber service and modify the profiles (sect 7.4) such that both subscriber service and
network operations can be interfered with. Subscriber service can be network operations can be interfered with. Subscriber service can be
altered by modifying any of a number of service characteristics such altered by modifying any of a number of service characteristics such
as rate partitioning and maximum transmission rates. Network as rate partitioning and maximum transmission rates. Network
operations can be impacted by modification of trap thresholds such as operations can be impacted by modification of trap thresholds such as
SNR margins. SNR margins.
skipping to change at page 108, line 14 skipping to change at page 106, line 43
(users) that have legitimate rights to access them. (users) that have legitimate rights to access them.
3) ADSL layer connectivity from the ATU-R will permit the subscriber 3) ADSL layer connectivity from the ATU-R will permit the subscriber
to manipulate both the ADSL link directly and the AOC/EOC channels to manipulate both the ADSL link directly and the AOC/EOC channels
for their own loop. For example, unchecked or unfiltered for their own loop. For example, unchecked or unfiltered
fluctuations initiated by the subscriber could generate sufficient fluctuations initiated by the subscriber could generate sufficient
traps to potentially overwhelm either the management interface to the traps to potentially overwhelm either the management interface to the
network or the element manager. Other attacks affecting the ATU-R network or the element manager. Other attacks affecting the ATU-R
portions of the MIB may also be possible. portions of the MIB may also be possible.
13. Authors' Addresses 12. Authors' Addresses
Gregory Bathrick Gregory Bathrick
AG Communication Systems AG Communication Systems
A Subsidiary of Lucent Technologies [A Subsidiary of Lucent Technologies]
2500 W Utopia Rd. 2500 W Utopia Rd.
Phoenix, AZ 85027 USA Phoenix, AZ 85027 USA
Tel: +1 602-582-7679 Tel: +1 602-582-7679
Fax: +1 602-582-7697 Fax: +1 602-582-7697
E-MAIL: bathricg@agcs.com E-MAIL: bathricg@agcs.com
Faye Ly Faye Ly
Copper Mountain Networks Copper Mountain Networks
Norcal Office Norcal Office
2470 Embarcadero Way 2470 Embarcadero Way
skipping to change at page 108, line 44 skipping to change at page 107, line 27
Table of Contents Table of Contents
1. Status of this Memo ................................... 1 1. Status of this Memo ................................... 1
2. Abstract .............................................. 1 2. Abstract .............................................. 1
3. The SNMP Network Management Framework ................. 2 3. The SNMP Network Management Framework ................. 2
4. Object Definitions ..................................... 3 4. Object Definitions ..................................... 3
5. Introduction ........................................... 3 5. Relationship of the ADSL LINE MIB with standard MIBs ... 3
6. Relationship of the ADSL LINE MIB with standard MIBs ... 3 6. Conventions used in the MIB ............................ 7
7. Conventions used in the MIB ............................ 8 7. Conformance and Compliance ............................. 16
8. Conformance and Compliance ............................. 17
9. Definitions ............................................ 17 8. Definitions ............................................ 16
10. Acknowledgments ........................................ 104 9. Acknowledgments ........................................ 102
11. References ............................................. 105 10. References ............................................. 103
12. Security Considerations ................................ 107 11. Security Considerations ................................ 105
13. Authors' Addresses ..................................... 108 12. Authors' Addresses ..................................... 106
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/