draft-ietf-adslmib-adsllinemib-08.txt   rfc2662.txt 
INTERNET-DRAFT ADSL Line MIB Gregory Bathrick
AG Communication Systems
Faye Ly
Copper Mountain Networks
May 14, 1999
Definitions of Managed Objects Network Working Group G. Bathrick
for the ADSL Lines Request for Comments: 2662 AG Communication Systems
Category: Standards Track F. Ly
May 14, 1999 Copper Mountain Networks
August 1999
draft-ietf-adslmib-adsllinemib-08.txt
1. Status of this Memo Definitions of Managed Objects for the ADSL Lines
This document is an Internet-Draft and is in full conformance with Status of this Memo
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering This document specifies an Internet standards track protocol for the
Task Force (IETF), its areas, and its working groups. Note that other Internet community, and requests discussion and suggestions for
groups may also distribute working documents as Internet-Drafts. 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.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at Copyright (C) The Internet Society (1999). All Rights Reserved.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Table of Contents
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check the 1. Abstract .............................................. 1
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 2. The SNMP Network Management Framework ................. 2
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 3. Object Definitions ..................................... 3
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 4. Relationship of the ADSL LINE MIB with standard MIBs ... 3
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 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
2. Abstract 1. 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 provided input towards the content of this document. See the Group provided input towards the content of this document. See the
Acknowledgement Section for a list of individuals who made this Acknowledgement Section for a list of individuals who made this
document possible. document possible.
3. The SNMP Network Management Framework 2. 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 2571 [13]. o An overall architecture, described in RFC 2571 [13].
o Mechanisms for describing and naming objects and events for o Mechanisms for describing and naming objects and events for the
the purpose of management. The first version of this purpose of management. The first version of this Structure of
Structure of Management Information (SMI) is called SMIv1 and Management Information (SMI) is called SMIv1 and described in STD
described in RFC 1155 [14], RFC 1212 [15] and RFC 1215 [16]. 16, RFC 1155 [14], STD 16, RFC 1212 [15] and RFC 1215 [16]. The
The second version, called SMIv2, is described in RFC 2578 second version, called SMIv2, is described in STD 58, RFC 2578
[1], RFC 2579 [2] and RFC 2580 [17]. [1], STD 58, RFC 2579 [2] and STD 58, RFC 2580 [17].
o Message protocols for transferring management information. o Message protocols for transferring management information. The
The first version of the SNMP message protocol is called first version of the SNMP message protocol is called SNMPv1 and
SNMPv1 and described in RFC 1157 [7]. A second version of described in STD 15, RFC 1157 [7]. A second version of the SNMP
the SNMP message protocol, which is not an Internet standards message protocol, which is not an Internet standards track
track protocol, is called SNMPv2c and described in RFC 1901 protocol, is called SNMPv2c and described in RFC 1901 [18] and RFC
[18] and RFC 1906 [19]. The third version of the message 1906 [19]. The third version of the message protocol is called
protocol is called SNMPv3 and described in RFC 1906 [19], RFC SNMPv3 and described in RFC 1906 [19], RFC 2572 [20] and RFC 2574
2572 [20] and RFC 2574 [21]. [21].
o Protocol operations for accessing management information. o Protocol operations for accessing management information. The
The first set of protocol operations and associated PDU first set of protocol operations and associated PDU formats is
formats is described in RFC 1157 [7]. A second set of described in STD 15, RFC 1157 [7]. A second set of protocol
protocol operations and associated PDU formats is described operations and associated PDU formats is described in RFC 1905
in RFC 1905 [8]. [8].
o A set of fundamental applications described in RFC 2573 [22] o A set of fundamental applications described in RFC 2573 [22] and
and the view-based access control mechanism described in RFC the view-based access control mechanism described in RFC 2575
2575 [23]. [23].
This document specifies a MIB module that is compliant to the SMIv2. This document specifies a MIB module that is compliant to the SMIv2.
A MIB conforming to the SMIv1 can be produced through the appropriate A MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no equivalent, except where objects or events are omitted because no
translation is possible (e.g., use of Counter64). Some machine translation is possible (e.g., use of Counter64). Some machine
readable information in SMIv2 will be converted into textual readable information in SMIv2 will be converted into textual
descriptions in SMIv1 during the translation process. However, this descriptions in SMIv1 during the translation process. However, this
loss of machine readable information is not considered to change the loss of machine readable information is not considered to change the
semantics of the MIB. semantics of the MIB.
4. Object Definitions 3. Object Definitions
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. Relationship of the ADSL LINE MIB with standard MIBs 4. 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".
5.1 Use of the IfTable 4.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 {
skipping to change at page 3, line 48 skipping to change at page 3, line 46
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. Most
MIB tables in this document represent information of one of these
Most MIB tables in this document represent information of one of interface types and are indexed by ifIndex. Remaining are `profile'
these interface types and are indexed by ifIndex. Remaining are tables which may be accessed by the profileIndex. This is explained
`profile' tables which may be accessed by the profileIndex. This is in more detail in section 5.4 Profiles.
explained in more detail in section 6.4 Profiles.
5.1.1 ADSL Interface Types 4.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 4, line 36 skipping to change at page 4, line 31
| ATUC | | ATUR | | ATUC | | ATUR |
| |____________________| | | |____________________| |
|______| |______| |______| |______|
| <----- physical --------> | | <----- physical --------> |
| <--- fast channel ------> | | <--- fast channel ------> |
| <- interleaved channel -> | | <- interleaved channel -> |
Figure 1: ADSL Model Figure 1: ADSL Model
5.1.2 Use of IF-MIB (Interface MIB RFC 2233) [5] 4.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 16 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, 6.4). their configuration parameters. (See Profile section, 5.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 |
| | | | | | | |
| | (ifEntry=i) | | | | (ifEntry=i) | |
| | physical | | | | physical | |
| |________________________| | | |________________________| |
|______| |______| |______| |______|
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.
5.2 Relationship with RFC 2037 [25] 4.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
skipping to change at page 7, line 35 skipping to change at page 7, line 33
agent is implemented, the Entity MIB should include entities for the agent is implemented, the Entity MIB should include entities for the
ATU-R in the entPhysicalTable. In this case, the MIB's ATU-R in the entPhysicalTable. In this case, the MIB's
entAliasMappingTable would contain mapping information identifying entAliasMappingTable would contain mapping information identifying
the 'ifIndex' object associated with each ATU-R. the 'ifIndex' object associated with each ATU-R.
Also associating the relationship between the ifTable and Entity MIB, Also associating the relationship between the ifTable and Entity MIB,
the entPhysicalTable contains an 'entPhysicalName' object, which the entPhysicalTable contains an 'entPhysicalName' object, which
approximates the semantics of the 'ifName' object from the Interface approximates the semantics of the 'ifName' object from the Interface
MIB. MIB.
6. Conventions used in the MIB 5. Conventions used in the MIB
6.1 Naming Conventions 5.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
of Fast channels, adslAtucChanConfFastMaxTxRate defines the case 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.
C. There are two possible channels: fast, and interleaved. None, one C. There are two possible channels: fast, and interleaved. None, one
or both may be implemented on a particular ADSL Line. Figure 5 or both may be implemented on a particular ADSL Line. Figure 5
illustrates all possible operational configurations. illustrates all possible operational configurations.
D. Lof, Lol, Los, Lpr mean Loss of Framing, Link, Signal, and Power, 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 respectively. Lpr is used by T1E1, so it is used for consistency
(rather than Lop). (rather than Lop).
A Loss of Link condition is declared at the ATU-C if a Loss of Signal A Loss of Link condition is declared at the ATU-C if a Loss of
is not preceded by a `dying-gasp' message from the ATU-R. Note that Signal is not preceded by a `dying-gasp' message from the ATU-R.
Loss of Link is only supported by the ATU-C. Note that Loss of Link is only supported by the ATU-C.
E. ES means errored second. An Errored Second is any second 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 containing one or more CRC anomaly, or one or more Los(s) or
Errored Frame (Sef) defect(s). Severely Errored Frame (Sef) defect(s).
F. A "block" is a physical-layer `data buffer' over which CRCs are 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 calculated. For example, in DMT, the block is defined as the ADSL
superframe. The block duration is 250 micro-seconds so the block superframe. The block duration is 250 micro-seconds so the block
length in bytes, as defined in adslAtu*ChanCrcBlockLength, varies length in bytes, as defined in adslAtu*ChanCrcBlockLength, varies
with data rate. See Line Code Specific MIBs [11] [12] for more line with data rate. See Line Code Specific MIBs [11] [12] for more
code specific information. line code specific information.
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
6.2 Structure 5.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
- 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.
It is intented that Line Code Specific MIBs be located under It is intented that Line Code Specific MIBs be located under
skipping to change at page 9, line 39 skipping to change at page 9, line 39
shown below. shown below.
Table Phys Fast Interleaved Table Phys Fast Interleaved
___________________________________________________________ ___________________________________________________________
No Channels (1) | Y | | | No Channels (1) | Y | | |
Fast Only (2) | Y | Y | | Fast Only (2) | Y | Y | |
Interleaved Only (3) | Y | | Y | Interleaved Only (3) | Y | | Y |
Fast or Interleaved (4) | Y | Y | Y | Fast or Interleaved (4) | Y | Y | Y |
Fast and Interleaved (5) | Y | Y | Y | Fast and Interleaved (5) | Y | Y | Y |
Figure 5: ADSL Operational configurations Figure 5: ADSL Operational configurations
NOTE: In (4), channel exists of either Fast or Interleaved type, but 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. not both. The Manager may select the type of channel to be used.
Depending on which operation configuration exists, some or all ADSL Depending on which operation configuration exists, some or all ADSL
MIB tables could be supported, as shown in below. See Conformance MIB tables could be supported, as shown in below. See Conformance
Statements for more information on which objects are mandatory. Statements for more information on which objects are mandatory.
Table Phys Fast Interleaved Table Phys Fast Interleaved
___________________________________________________________ ___________________________________________________________
adslLineTable | Y | | | adslLineTable | Y | | |
adslAtucPhysTable | Y | | | adslAtucPhysTable | Y | | |
adslAturPhysTable | Y | | | adslAturPhysTable | Y | | |
adslAtucChanTable | | Y | Y | adslAtucChanTable | | Y | Y |
adslAturChanTable | | Y | Y | adslAturChanTable | | Y | Y |
adslAtucPerfDataTable | Y | | | adslAtucPerfDataTable | Y | | |
adslAturPerfDataTable | Y | | | adslAturPerfDataTable | Y | | |
adslAtucIntervalTable | Y | | | adslAtucIntervalTable | Y | | |
adslAturIntervalTable | Y | | | adslAturIntervalTable | Y | | |
skipping to change at page 10, line 20 skipping to change at page 10, line 21
adslAturChanTable | | Y | Y | adslAturChanTable | | Y | Y |
adslAtucPerfDataTable | Y | | | adslAtucPerfDataTable | Y | | |
adslAturPerfDataTable | Y | | | adslAturPerfDataTable | Y | | |
adslAtucIntervalTable | Y | | | adslAtucIntervalTable | Y | | |
adslAturIntervalTable | Y | | | adslAturIntervalTable | Y | | |
adslAtucChanPerfDataTable | | Y | Y | adslAtucChanPerfDataTable | | Y | Y |
adslAturChanPerfDataTable | | Y | Y | adslAturChanPerfDataTable | | Y | Y |
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.
6.2.1 Structure of Conformance Groups 5.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 11, line 4 skipping to change at page 11, line 17
adslLineTable adslLineCoding adslLineTable adslLineCoding
adslAtucPhysTable adslAtucInvVendorID adslAtucPhysTable adslAtucInvVendorID
adslAtucInvVersionNumber adslAtucInvVersionNumber
adslAtucCurrStatus (Partial) adslAtucCurrStatus (Partial)
adslAtucCurrOutputPwr adslAtucCurrOutputPwr
adslAtucCurrAttainableRate adslAtucCurrAttainableRate
adslAturPhysTable all are supported adslAturPhysTable all are supported
adslAtucChanTable all except adslAtucChanTable all except
adslAtucChanCrcBlockLength adslAtucChanCrcBlockLength
are supported are supported
adslAtucPerfDataTable all except adslAtucPerfDataTable all except
adslAtucPerfLols, adslAtucPerfLprs adslAtucPerfLols,
adslAtucPerfLprs
adslAtucPerfCurr15MinLols, adslAtucPerfCurr15MinLols,
adslAtucPerfCurr15MinLprs, adslAtucPerfCurr15MinLprs,
adslAtucPerfCurr1DayLols, adslAtucPerfCurr1DayLols,
adslAtucPerfCurr1DayLprs, adslAtucPerfCurr1DayLprs,
adslAtucPerfPrev1DayLols and adslAtucPerfPrev1DayLols and
adslAtucPerfPrev1DayLprs adslAtucPerfPrev1DayLprs
are supported are supported
adslAturPerfDataTable all are supported adslAturPerfDataTable all are supported
adslAtucIntervalTable adslAtucIntervalLofs adslAtucIntervalTable adslAtucIntervalLofs
adslAtucIntervalLoss adslAtucIntervalLoss
skipping to change at page 11, line 31 skipping to change at page 11, line 44
adslAtucChanPerfDataTable all are supported adslAtucChanPerfDataTable all are supported
adslAturChanPerfDataTable all are supported adslAturChanPerfDataTable all are supported
adslAtucChanIntervalTable all are supported adslAtucChanIntervalTable all are supported
adslAturChanIntervalTable all are supported adslAturChanIntervalTable all are supported
adslLineConfProfileTable not supported adslLineConfProfileTable not supported
adslLineAlarmConfProfileTable all are supported except adslLineAlarmConfProfileTable all are supported except
adslAtucThresh15MinLols adslAtucThresh15MinLols
and adslAtucThresh15MinLprs and adslAtucThresh15MinLprs
-------------------------------------------------------------------- --------------------------------------------------------------------
Figure 7: MIB Tables and Objects Supported by the ATU-R Agent Figure 7: MIB Tables and Objects Supported by the ATU-R Agent
All traps supported by the ATU-R agent are also listed: All traps supported by the ATU-R agent are also listed:
adslAtucPerfLofsThreshTrap adslAtucPerfLofsThreshTrap
adslAtucPerfLossThreshTrap adslAtucPerfLossThreshTrap
adslAtucPerfESsThreshTrap adslAtucPerfESsThreshTrap
adslAtucRateChangeTrap adslAtucRateChangeTrap
adslAturPerfLofsThreshTrap adslAturPerfLofsThreshTrap
adslAturPerfLossThreshTrap adslAturPerfLossThreshTrap
adslAturPerfLprsThreshTrap adslAturPerfLprsThreshTrap
adslAturPerfESsThreshTrap adslAturPerfESsThreshTrap
adslAturRateChangeTrap adslAturRateChangeTrap
6.3 Counters, Interval Buckets and Thresholds 5.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 28 skipping to change at page 13, line 5
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.
6.4 Profiles 5.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
ADSL lines. multiple 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.
6.4.1 MODE-I : Dynamic Profiles 5.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' (RFC2571 profile having the textual convention `SnmpAdminString' (RFC2571
[13]). [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 13, line 44 skipping to change at page 14, line 28
| |
| |
| |
v v
x ix ADSL Line ------>------> Silver Profile x ix ADSL Line ------>------> Silver Profile
jx Fast Chan ---------------> jx Fast Chan --------------->
kx Int Chan kx Int Chan
__________________________________________________________________ __________________________________________________________________
Figure 8: Use of Dynamic Profiles: MODE-I Figure 8: Use of Dynamic Profiles: MODE-I
In the figure above, note that three interface entries of an ADSL In the figure above, note that three interface entries of an ADSL
line, physical, fast channel, and interleaved channel, are line, physical, fast channel, and interleaved channel, are
represented by `i', `j', and `k'. Only the physical-layer entry `i' represented by `i', `j', and `k'. Only the physical-layer entry `i'
contains an adslLineTable entry, therefore only those entries contain contains an adslLineTable entry, therefore only those entries contain
pointers to the adslLineConfProfileTable. The ifStackTable (see pointers to the adslLineConfProfileTable. The ifStackTable (see
rfc2233 [5]) can be used to link the channel entries to the rfc2233 [5]) can be used to link the channel entries to the
corresponding physical-layer entry to get the channel's configuration corresponding physical-layer entry to get the channel's configuration
parameters. See figure 4 for use of the ifStackTable. parameters. See figure 4 for use of the ifStackTable.
skipping to change at page 14, line 25 skipping to change at page 15, line 10
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.
6.4.2 MODE-II : Static Profiles 5.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 4 skipping to change at page 15, line 34
ADSL ifIndex ifTable Configuration Line ADSL ifIndex ifTable Configuration Line
Profile Table Profile Table
__________________________________________________________________ __________________________________________________________________
1 i1 ADSL Line ------------> Profile 1 i1 ADSL Line ------------> Profile
j1 Fast Chan j1 Fast Chan
k1 Int Chan k1 Int Chan
2 i2 ADSL Line ------------> Profile 2 i2 ADSL Line ------------> Profile
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
6.5 Traps 5.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, Loss of A linkDown trap is generated whenever any of Lof, Los, Lol, Loss of
Signal Quality, or Lpr events occurs. At this operational point, a Signal Quality, or Lpr events occurs. At this operational point, a
manager can use adslAtu*CurrStatus for additional detailed manager can use adslAtu*CurrStatus for additional detailed
skipping to change at page 16, line 33 skipping to change at page 17, line 14
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.
7. Conformance and Compliance 6. Conformance and Compliance
See the conformance and compliance statements within the information See the conformance and compliance statements within the information
module. module.
8. Definitions 7. Definitions
ADSL-TC-MIB DEFINITIONS ::= BEGIN ADSL-TC-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
transmission, transmission,
MODULE-IDENTITY, Gauge32 FROM SNMPv2-SMI MODULE-IDENTITY, Gauge32 FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC; TEXTUAL-CONVENTION FROM SNMPv2-TC;
adsltcmib MODULE-IDENTITY adsltcmib MODULE-IDENTITY
LAST-UPDATED "9905052200Z"
LAST-UPDATED "9908190000Z"
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 17, line 27 skipping to change at page 18, line 4
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
Palo Alto, CA 94303 Palo Alto, CA 94303
Tel: +1 650-858-8500 Tel: +1 650-858-8500
Fax: +1 650-858-8085 Fax: +1 650-858-8085
E-Mail: faye@coppermountain.com E-Mail: faye@coppermountain.com
IETF ADSL MIB Working Group (adsl@xlist.agcs.com) IETF ADSL MIB Working Group (adsl@xlist.agcs.com)
" "
DESCRIPTION DESCRIPTION
"The MIB module which provides a ADSL "The MIB module which provides a ADSL
Line Coding Textual Convention to be used Line Coding Textual Convention to be used
by ADSL Lines." by ADSL Lines."
-- Revision history
REVISION "9908190000Z" -- 19 August 1999, midnight
DESCRIPTION "Initial Version, published as RFC 2662"
::= { transmission 94 2 } -- adslMIB 2 ::= { transmission 94 2 } -- adslMIB 2
AdslLineCodingType ::= TEXTUAL-CONVENTION AdslLineCodingType ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This data type is used as the syntax for the ADSL "This data type is used as the syntax for the ADSL
Line Code." Line Code."
SYNTAX INTEGER { SYNTAX INTEGER {
other(1),-- none of the following other(1),-- none of the following
dmt (2), -- Discrete MultiTone dmt (2), -- Discrete MultiTone
skipping to change at page 19, line 32 skipping to change at page 20, line 13
PerfIntervalCount FROM PerfHist-TC-MIB PerfIntervalCount FROM PerfHist-TC-MIB
SnmpAdminString FROM SNMP-FRAMEWORK-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB
AdslPerfCurrDayCount, AdslPerfCurrDayCount,
AdslPerfPrevDayCount, AdslPerfPrevDayCount,
AdslPerfTimeElapsed, AdslPerfTimeElapsed,
AdslLineCodingType FROM ADSL-TC-MIB AdslLineCodingType FROM ADSL-TC-MIB
; ;
adslMIB MODULE-IDENTITY adslMIB MODULE-IDENTITY
LAST-UPDATED "9905052200Z" LAST-UPDATED "9908190000Z"
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 21, line 13 skipping to change at page 21, line 41
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 history
REVISION "9908190000Z" -- 19 August 1999, midnight
DESCRIPTION "Initial Version, published as RFC 2662"
::= { transmission 94 }
adslLineMib OBJECT IDENTIFIER ::= { adslMIB 1 } adslLineMib OBJECT IDENTIFIER ::= { adslMIB 1 }
adslMibObjects OBJECT IDENTIFIER ::= { adslLineMib 1 } adslMibObjects OBJECT IDENTIFIER ::= { adslLineMib 1 }
-- 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 70, line 15 skipping to change at page 70, line 42
Distribute bandwidth on each channel in excess of the Distribute bandwidth on each channel in excess of the
corresponding ChanConfMinTxRate so that: corresponding ChanConfMinTxRate so that:
adslAtucConfRateChanRatio = adslAtucConfRateChanRatio =
[Fast / (Fast + Interleaved)] * 100 [Fast / (Fast + Interleaved)] * 100
In other words this value is the fast channel In other words this value is the fast channel
percentage." percentage."
::= { adslLineConfProfileEntry 3 } ::= { adslLineConfProfileEntry 3 }
adslAtucConfTargetSnrMgn OBJECT-TYPE adslAtucConfTargetSnrMgn OBJECT-TYPE
SYNTAX INTEGER (-640..640) SYNTAX INTEGER (0..310)
UNITS "tenth dB" UNITS "tenth dB"
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Configured Target Signal/Noise Margin. "Configured Target Signal/Noise Margin.
This is the Noise Margin the modem must achieve This is the Noise Margin the modem must achieve
with a BER of 10-7 or better to successfully complete with a BER of 10-7 or better to successfully complete
initialization." initialization."
::= { adslLineConfProfileEntry 4 } ::= { adslLineConfProfileEntry 4 }
adslAtucConfMaxSnrMgn OBJECT-TYPE adslAtucConfMaxSnrMgn OBJECT-TYPE
SYNTAX INTEGER (-640..640) SYNTAX INTEGER (0..310)
UNITS "tenth dB" UNITS "tenth dB"
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Configured Maximum acceptable Signal/Noise Margin. "Configured Maximum acceptable Signal/Noise Margin.
If the Noise Margin is above this the modem should If the Noise Margin is above this the modem should
attempt to reduce its power output to optimize its attempt to reduce its power output to optimize its
operation." operation."
::= { adslLineConfProfileEntry 5 } ::= { adslLineConfProfileEntry 5 }
adslAtucConfMinSnrMgn OBJECT-TYPE adslAtucConfMinSnrMgn OBJECT-TYPE
SYNTAX INTEGER (-640..640) SYNTAX INTEGER (0..310)
UNITS "tenth dB" UNITS "tenth dB"
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Configured Minimum acceptable Signal/Noise Margin. "Configured Minimum acceptable Signal/Noise Margin.
If the noise margin falls below this level, the modem If the noise margin falls below this level, the modem
should attempt to increase its power output. If that should attempt to increase its power output. If that
is not possible the modem will attempt to is not possible the modem will attempt to
re-initialize or shut down." re-initialize or shut down."
::= { adslLineConfProfileEntry 6 } ::= { adslLineConfProfileEntry 6 }
skipping to change at page 71, line 4 skipping to change at page 71, line 29
UNITS "tenth dB" UNITS "tenth dB"
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Configured Minimum acceptable Signal/Noise Margin. "Configured Minimum acceptable Signal/Noise Margin.
If the noise margin falls below this level, the modem If the noise margin falls below this level, the modem
should attempt to increase its power output. If that should attempt to increase its power output. If that
is not possible the modem will attempt to is not possible the modem will attempt to
re-initialize or shut down." re-initialize or shut down."
::= { adslLineConfProfileEntry 6 } ::= { adslLineConfProfileEntry 6 }
adslAtucConfDownshiftSnrMgn OBJECT-TYPE adslAtucConfDownshiftSnrMgn OBJECT-TYPE
SYNTAX INTEGER (-640..640) SYNTAX INTEGER (0..310)
UNITS "tenth dB" UNITS "tenth dB"
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Configured Signal/Noise Margin for rate downshift. "Configured Signal/Noise Margin for rate downshift.
If the noise margin falls below this level, the modem If the noise margin falls below this level, the modem
should attempt to decrease its transmit rate. In should attempt to decrease its transmit rate. In
the case that RADSL mode is not present, the case that RADSL mode is not present,
the value will be `0'." the value will be `0'."
::= { adslLineConfProfileEntry 7 } ::= { adslLineConfProfileEntry 7 }
adslAtucConfUpshiftSnrMgn OBJECT-TYPE adslAtucConfUpshiftSnrMgn OBJECT-TYPE
SYNTAX INTEGER (-640..640) SYNTAX INTEGER (0..310)
UNITS "tenth dB" UNITS "tenth dB"
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Configured Signal/Noise Margin for rate upshift. "Configured Signal/Noise Margin for rate upshift.
If the noise margin rises above this level, the modem If the noise margin rises above this level, the modem
should attempt to increase its transmit rate. In should attempt to increase its transmit rate. In
the case that RADSL is not present, the value will the case that RADSL is not present, the value will
be `0'." be `0'."
::= { adslLineConfProfileEntry 8 } ::= { adslLineConfProfileEntry 8 }
skipping to change at page 74, line 11 skipping to change at page 74, line 35
Distribute bandwidth on each channel in excess of the Distribute bandwidth on each channel in excess of the
corresponding ChanConfMinTxRate so that: corresponding ChanConfMinTxRate so that:
adslAturConfRateChanRatio = adslAturConfRateChanRatio =
[Fast / (Fast + Interleaved)] * 100 [Fast / (Fast + Interleaved)] * 100
In other words this value is the fast channel In other words this value is the fast channel
percentage." percentage."
::= { adslLineConfProfileEntry 17 } ::= { adslLineConfProfileEntry 17 }
adslAturConfTargetSnrMgn OBJECT-TYPE adslAturConfTargetSnrMgn OBJECT-TYPE
SYNTAX INTEGER (-640..640) SYNTAX INTEGER (0..310)
UNITS "tenth dB" UNITS "tenth dB"
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Configured Target Signal/Noise Margin. "Configured Target Signal/Noise Margin.
This is the Noise Margin the modem must achieve This is the Noise Margin the modem must achieve
with a BER of 10-7 or better to successfully complete with a BER of 10-7 or better to successfully complete
initialization." initialization."
::= { adslLineConfProfileEntry 18 } ::= { adslLineConfProfileEntry 18 }
adslAturConfMaxSnrMgn OBJECT-TYPE adslAturConfMaxSnrMgn OBJECT-TYPE
SYNTAX INTEGER (-640..640) SYNTAX INTEGER (0..310)
UNITS "tenth dB" UNITS "tenth dB"
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Configured Maximum acceptable Signal/Noise Margin. "Configured Maximum acceptable Signal/Noise Margin.
If the Noise Margin is above this the modem should If the Noise Margin is above this the modem should
attempt to reduce its power output to optimize its attempt to reduce its power output to optimize its
operation." operation."
::= { adslLineConfProfileEntry 19 } ::= { adslLineConfProfileEntry 19 }
adslAturConfMinSnrMgn OBJECT-TYPE adslAturConfMinSnrMgn OBJECT-TYPE
SYNTAX INTEGER (-640..640) SYNTAX INTEGER (0..310)
UNITS "tenth dB" UNITS "tenth dB"
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Configured Minimum acceptable Signal/Noise Margin. "Configured Minimum acceptable Signal/Noise Margin.
If the noise margin falls below this level, the modem If the noise margin falls below this level, the modem
should attempt to increase its power output. If that should attempt to increase its power output. If that
is not possible the modem will attempt to is not possible the modem will attempt to
re-initialize or shut down." re-initialize or shut down."
::= { adslLineConfProfileEntry 20 } ::= { adslLineConfProfileEntry 20 }
adslAturConfDownshiftSnrMgn OBJECT-TYPE adslAturConfDownshiftSnrMgn OBJECT-TYPE
SYNTAX INTEGER (-640..640) SYNTAX INTEGER (0..310)
UNITS "tenth dB" UNITS "tenth dB"
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Configured Signal/Noise Margin for rate downshift. "Configured Signal/Noise Margin for rate downshift.
If the noise margin falls below this level, the modem If the noise margin falls below this level, the modem
should attempt to decrease its transmit rate. should attempt to decrease its transmit rate.
In the case that RADSL mode is not present, In the case that RADSL mode is not present,
the value will be `0'." the value will be `0'."
::= { adslLineConfProfileEntry 21 } ::= { adslLineConfProfileEntry 21 }
adslAturConfUpshiftSnrMgn OBJECT-TYPE adslAturConfUpshiftSnrMgn OBJECT-TYPE
SYNTAX INTEGER (-640..640) SYNTAX INTEGER (0..310)
UNITS "tenth dB" UNITS "tenth dB"
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Configured Signal/Noise Margin for rate upshift. "Configured Signal/Noise Margin for rate upshift.
If the noise margin rises above this level, the modem If the noise margin rises above this level, the modem
should attempt to increase its transmit rate. should attempt to increase its transmit rate.
In the case that RADSL is not present, In the case that RADSL is not present,
the value will be `0'." the value will be `0'."
::= { adslLineConfProfileEntry 22 } ::= { adslLineConfProfileEntry 22 }
skipping to change at page 89, line 20 skipping to change at page 89, line 42
"Read-write access is applicable when "Read-write access is applicable when
static profiles are implemented." static profiles are implemented."
OBJECT adslAtucConfMaxSnrMgn OBJECT adslAtucConfMaxSnrMgn
MIN-ACCESS read-write MIN-ACCESS read-write
DESCRIPTION DESCRIPTION
"Read-write access is applicable when "Read-write access is applicable when
static profiles are implemented." static profiles are implemented."
OBJECT adslAtucConfMinSnrMgn OBJECT adslAtucConfMinSnrMgn
MIN-ACCESS read-wr
MIN-ACCESS read-write MIN-ACCESS read-write
DESCRIPTION DESCRIPTION
"Read-write access is applicable when "Read-write access is applicable when
static profiles are implemented." static profiles are implemented."
OBJECT adslAtucConfDownshiftSnrMgn OBJECT adslAtucConfDownshiftSnrMgn
MIN-ACCESS read-write MIN-ACCESS read-write
DESCRIPTION DESCRIPTION
"Read-write access is applicable when "Read-write access is applicable when
static profiles are implemented." static profiles are implemented."
skipping to change at page 109, line 7 skipping to change at page 110, line 5
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 8. Acknowledgments
The current authors/editors are: The current authors/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 Cheers (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)
Adil Masood (AG Communication Systems) Adil Masood (AG Communication Systems)
Padmore Peterson (BT) Padmore Peterson (BT)
Anna Salguero (SBC) Anna Salguero (SBC)
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)
10. References 9. References
[1] B. Wijnen, D. Harrington, R. Presuhn, "Structure of [1] McCloghrie K., Perkins D. and J. Schoenwaelder, "Structure of
Management Information Version 2 (SMIv2)" RFC 2578, Management Information Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999. April 1999.
[2] K. McCloghrie, D. Perkins, J. Schoenwaelder, [2] McCloghrie K., Perkins D. and J. Schoenwaelder, "Textual
"Textual Conventions for SMIv2", RFC 2579, April 1999. Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[3] ADSL Forum TR-005, "Network Management Element Management", [3] ADSL Forum TR-005, "Network Management Element Management",
March 1998. March 1998.
[4] McCloghrie, K., and M. Rose, Editors, "Management [4] McCloghrie, K. and M. Rose, Editors, "Management Information
Information Base for Network Management of TCP/IP-based Base for Network Management of TCP/IP-based internets: MIB-II",
internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, STD 17, RFC 1213, March 1991.
Performance Systems International, March 1991.
[5] McCloghrie, K. and F. Kastenholz, "The Interfaces Group [5] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB
MIB using SMIv2", RFC 2233, Cisco Systems, FTP Software, using SMIv2", RFC 2233, November 1997.
November 1997.
[6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., [6] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
and S. Waldbusser, "Management Information Base for "Management Information Base for version 2 of the Simple
version 2 of the Simple Network Management Protocol Network Management Protocol (SNMPv2)", RFC 1907, January 1996.
(SNMPv2)", RFC 1907, 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, May
Research, Performance Systems International, MIT Lab for 1990.
Computer Science, May 1990.
[8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and [8] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol
S. Waldbusser, "Protocol Operations for Version 2 of the Simple Operations for Version 2 of the Simple Network Management
Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 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.
[10] American National Standards Institute, ANSI T1.413-1995, [10] American National Standards Institute, ANSI T1.413-1995, August
August 1995 1995.
[11] ADSL Forum WT-014, "DMT Line Code Specific MIB", February 1999 [11] ADSL Forum WT-014, "DMT Line Code Specific MIB", February 1999.
[12] ADSL Forum WT-015, "CAP Line Code Specific MIB", February 1999 [12] ADSL Forum WT-015, "CAP Line Code Specific MIB", February 1999.
[13] B. Wijnen, D. Harrington, R. Presuhn, "An Architecture for [13] Wijnen, B., Harrington, D. and R. Presuhn, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, April 1999 Describing SNMP Management Frameworks", RFC 2571, April 1999.
[14] Rose, M., and K. McCloghrie, "Structure and Identification of [14] Rose, M. and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", RFC 1155, Management Information for TCP/IP-based Internets", STD 16, RFC
Performance Systems International, Hughes LAN Systems, May 1990 1155, May 1990.
[15] Rose, M., and K. McCloghrie, "Concise MIB Definitions", [15] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, Performance Systems International, Hughes LAN Systems, RFC 1212, March 1991.
March 1991
[16] M. Rose, "A Convention for Defining Traps for use with the [16] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, Performance Systems International, March SNMP", RFC 1215, March 1991.
1991
[17] K. McCloghrie, D. Perkins, J. Schoenwaelder, "Conformance [17] McCloghrie K., Perkins D. and J. Schoenwaelder, "Conformance
Statements for SMIv2", RFC 2580, April 1999 Statements for SMIv2", RFC 2580, April 1999.
[18] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. [18] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, "Introduction to Community-based SNMPv2", RFC 1901, January
SNMP Research, Inc., Cisco Systems, Inc., Dover Beach 1996.
Consulting, Inc., International Network Services, January 1996.
[19] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. [19] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
Waldbusser, "Transport Mappings for Version 2 of the Simple "Transport Mappings for Version 2 of the Simple Network
Network Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Management Protocol (SNMPv2)", RFC 1906, January 1996.
Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[20] Case, J., Harrington D., R. Presuhn, B. Wijnen, "Message [20] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, April 1999. Protocol (SNMP)", RFC 2572, April 1999.
[21] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) [21] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol for version 3 of the Simple Network Management Protocol
(SNMPv3)", RFC 2574, Aprile 1999. (SNMPv3)", RFC 2574, April 1999.
[22] Levi, D., Meyer, P., and B. Stewart, "SNMP Applications", [22] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC
RFC 2573, April 1999. 2573, April 1999.
[23] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access [23] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2575, IBM T. J. Watson Research, BMC Software, (SNMP)", RFC 2575, April 1999.
Inc., Cisco Systems, Inc., April 1999.
[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. 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 ISO 10646", RFC
10646", RFC 2044, October 1996. 2279, January 1998.
11. Security Considerations 10. 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 6.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.
2) There are a number of managed objects in this MIB that may be 2) There are a number of managed objects in this MIB that may be
considered to contain sensitive information. In particular, the considered to contain sensitive information. In particular, the
certain objects may be considered sensitive in many environments, certain objects may be considered sensitive in many environments,
since it would allow an intruder to obtain information about which since it would allow an intruder to obtain information about which
skipping to change at page 112, line 49 skipping to change at page 114, line 5
(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.
12. Authors' Addresses 11. Intellectual Property Notice
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 The IETF takes no position regarding the validity or scope of any
Copper Mountain Networks intellectual property or other rights that might be claimed to
Norcal Office pertain to the implementation or use of the technology described in
2470 Embarcadero Way this document or the extent to which any license under such rights
Palo Alto, CA 94303 might or might not be available; neither does it represent that it
Tel: +1 650-858-8500 has made any effort to identify any such rights. Information on the
Fax: +1 650-858-8085 IETF's procedures with respect to rights in standards-track and
E-Mail: faye@coppermountain.com standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat."
Table of Contents The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
1. Status of this Memo ................................... 1 12. Authors' Addresses
2. Abstract .............................................. 1 Gregory Bathrick
AG Communication Systems
[A Subsidiary of Lucent Technologies]
2500 W Utopia Rd.
Phoenix, AZ 85027 USA
3. The SNMP Network Management Framework ................. 2 Phone: +1 602-582-7679
Fax: +1 602-582-7697
EMail: bathricg@agcs.com
4. Object Definitions ..................................... 3 Faye Ly
Copper Mountain Networks
Norcal Office
2470 Embarcadero Way
Palo Alto, CA 94303
5. Relationship of the ADSL LINE MIB with standard MIBs ... 3 Phone: +1 650-858-8500
Fax: +1 650-858-8085
EMail: faye@coppermountain.com
6. Conventions used in the MIB ............................ 7 13. Full Copyright Statement
7. Conformance and Compliance ............................. 16 Copyright (C) The Internet Society (1999). All Rights Reserved.
8. Definitions ............................................ 16 This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
9. Acknowledgments ........................................ 109 The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
10. References ............................................. 109 This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
11. Security Considerations ................................ 112 Acknowledgement
12. Authors' Addresses ..................................... 112 Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 128 change blocks. 
277 lines changed or deleted 307 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/