RFC 4706
Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2)
Pages: 167
Proposed Standard
Proposed Standard
Part 1 of 7 – Pages 1 to 25
Network Working Group M. Morgenstern Request for Comments: 4706 M. Dodge Category: Standards Track ECI Telecom Ltd. S. Baillie U. Bonollo NEC Australia November 2006 Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006).Abstract
This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the "Asymmetric Digital Subscriber Line" family of interface types: ADSL, ADSL2, ADSL2+, and their variants.
Table of Contents
1. The Internet-Standard Management Framework ......................3 2. Overview ........................................................3 2.1. Relationship to Other MIBs .................................4 2.1.1. General IF-MIB Integration (RFC 2863) ...............4 2.1.2. Usage of ifTable ....................................5 2.2. IANA Considerations ........................................6 2.3. Conventions Used in the MIB Module .........................6 2.3.1. Naming Conventions ..................................6 2.3.2. Textual Conventions .................................7 2.4. Structure .................................................12 2.5. Persistence ...............................................15 2.6. Line Topology .............................................17 2.7. Counters, Interval Buckets, and Thresholds ................18 2.7.1. Counters Managed ...................................18 2.7.2. Minimum Number of Buckets ..........................19 2.7.3. Interval Buckets Initialization ....................19 2.7.4. Interval Buckets Validity ..........................19 2.8. Profiles ..................................................20 2.8.1. Configuration Profiles and Templates ...............21 2.8.2. Alarm Configuration Profiles and Templates .........22 2.8.3. Managing Profiles and Templates ....................22 2.8.4. Managing Multiple Bearer Channels ..................23 2.9. Notifications .............................................24 3. Definitions ....................................................25 4. Implementation Analysis .......................................155 5. Security Considerations .......................................155 6. Acknowledgements ..............................................163 7. References ....................................................163 7.1. Normative References .....................................163 7.2. Informative References ...................................165
1. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].2. Overview
This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community for the purpose of managing ADSL, ADSL2, and ADSL2+ lines. The MIB module described in RFC 2662 [RFC2662] describes objects used for managing Asymmetric Bit-Rate DSL (ADSL) interfaces per [T1E1.413], [G.992.1], and [G.992.2]. These object descriptions are based upon the specifications for the ADSL Embedded Operations Channel (EOC) as defined in American National Standards Institute (ANSI) T1E1.413/1995 [T1E1.413] and International Telecommunication Union (ITU-T) G.992.1 [G.992.1] and G.992.2 [G.992.2]. This document does not obsolete RFC 2662 [RFC2662], but rather provides a more comprehensive management model that includes the ADSL2 and ADSL2+ technologies per G.992.3, G.992.4, and G.992.5 ([G.992.3], [G.992.4], and [G.992.5] respectively). In addition, objects have been added to improve the management of ADSL, ADSL2, and ADSL2+ lines. Additionally, the management framework for New Generation ADSL lines specified [TR-90] by the Digital Subscriber Line Forum (DSLF) has been taken into consideration. That framework is based on ITU-T G.997.1 standard [G.997.1] as well as on two amendments: ([G.997.1am1] and [G.997.1am2]). This document refers to all three documents as G.997.1. That is, a MIB attribute whose REFERENCE section provides a paragraph number in ITU-T G.997.1 is actually originated from either G.997.1 [G.997.1] or one of its amendment documents.
Note that the revised ITU-T G.997.1 standard also refers to the next generation of VDSL technology, known as VDSL2, as per ITU-T G.993.2 [G.993.2]. However, managing VDSL2 lines is currently beyond the scope of this document. The MIB module is located in the MIB tree under MIB 2 transmission, as discussed in the IANA Considerations section of this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].2.1. Relationship to Other MIBs
This section outlines the relationship of this MIB module with other MIB modules described in RFCs. Specifically, IF-MIB as presented in RFC 2863 [RFC2863] is discussed.2.1.1. General IF-MIB Integration (RFC 2863)
The ADSL2 Line MIB specifies the detailed attributes of a data interface. As such, it needs to integrate with RFC 2863 [RFC2863]. The IANA has assigned the following ifTypes, which may be applicable for ADSL lines: IANAifType ::= TEXTUAL-CONVENTION ... SYNTAX INTEGER { ... channel(70), -- Channel adsl(94), -- Asymmetric Digital Subscriber Loop ... interleave(124), -- Interleaved Channel fast(125), -- Fast Channel ... adsl2plus(238), -- Asymmetric Digital Subscriber Loop Version 2, Version 2 Plus, and all variants ... } ADSL lines that are identified with ifType=adsl(94) MUST be managed with the MIB specified by RFC 2662. ADSL, ADSL2, and ADSL2+ lines identified with ifType=adsl2plus(238) MUST be managed with the MIB specified by this document.
In any case, the SNMP agent may use either ifType=interleave(124) or fast(125) for each channel, e.g., depending on whether or not it is capable of using an interleaver on that channel. It may use the ifType=channel(70) when all channels are capable of using an interleaver (e.g., for ADSL2 XTUs). Note that the ifFixedLengthGroup from RFC 2863 [RFC2863] MUST be supported and that the ifRcvAddressGroup does not apply to this MIB module.2.1.2. Usage of ifTable
The MIB branch identified by ifType contains tables appropriate for the interface types described above. Most such tables extend the ifEntry table and are indexed by ifIndex. For interfaces in systems implementing this MIB module, those table entries indexed by ifIndex MUST be persistent. The following attributes are part of the mandatory ifGeneralInformationGroup in the Interfaces MIB [RFC2863] and are not duplicated in the ADSL2 Line MIB. =================================================================== ifIndex Interface index. ifDescr See interfaces MIB. ifType adsl2plus(238) or channel(70) or interleave(124) or fast(125). ifSpeed Set as appropriate. ifPhysAddress This object MUST have an octet string with zero length. ifAdminStatus See interfaces MIB. ifOperStatus See interfaces MIB. ifLastChange See interfaces MIB. ifName See interfaces MIB. ifAlias See interfaces MIB.
ifLinkUpDownTrapEnable Default to enabled(1). ifHighSpeed Set as appropriate. ifConnectorPresent Set as appropriate. =================================================================== Figure 1: Use of ifTable Objects2.2. IANA Considerations
The IANA has allocated ifType=adsl2plus(238) for Asymmetric Digital Subscriber Loop Version 2. A separate ifType number was necessary to distinguish between ADSL lines that are managed with the RFC 2662 management model and ADSL/ADSL2 and ADSL2+ lines managed with the model defined in this document. Also, the IANA has assigned transmission number 238 to the ADSL2-LINE-MIB module. An assignment was in fact done when RFC 2662 was published, but as this MIB does not obsolete RFC 2662, it required a new assignment from IANA.2.3. Conventions Used in the MIB Module
2.3.1. Naming Conventions
ATU ADSL Transceiver Unit ATU-C ATU at the Central office end (i.e., network operator). ATU-R ATU at the Remote end (i.e., subscriber end of the loop). XTU A terminal unit; either an ATU-C or an ATU-R. CRC Cyclic Redundancy Check DELT Dual Ended Loop Test ES Errored Second FEC Forward Error Correction LOF Loss Of Frame LOS Loss Of Signal LOSS LOS Seconds SES Severely-Errored Second SNR Signal-to-Noise Ratio UAS Unavailable Seconds
2.3.2. Textual Conventions
The following textual conventions are defined to reflect the line topology in the MIB module (further discussed in the following section), the various transmission modes, power states, synchronization states, possible values for various configuration parameters, status parameters, and other parameter types. o Adsl2Unit: Attributes with this syntax uniquely identify each unit in the ADSL/ADSL2/ADSL2+ link. It mirrors the EOC addressing mechanism: atuc(1) - Central office ADSL transceiver unit (ATU-C). atur(2) - Remote ADSL transceiver unit (ATU-R). o Adsl2Direction: Attributes with this syntax uniquely identify a transmission direction in an ADSL/ADSL2/ADSL2+ link. Upstream direction is a transmission from the remote end (ATU-R) towards the central office end (ATU-C), while downstream direction is a transmission from the ATU-C towards the ATU-R. upstream(1) - Transmission from the ATU-R to the ATU-C. downstream(2) - Transmission from the ATU-C to the ATU-R. o Adsl2TransmissionModeType: Attributes with this syntax reference the list of possible transmission modes for ADSL/ADSL2 or ADSL2+. Specified as a BITS construct, there are currently a few dozen transmission modes in the list. o Adsl2RaMode: Attributes with this syntax reference if and how Rate-Adaptive synchronization is being used on the respective ADSL/ADSL2 or ADSL2+ link: manual(1) - No Rate-Adaptation. The initialization process attempts to synchronize to a specified rate. raInit(2) - Rate-Adaptation during initialization process only, which attempts to synchronize to a rate between minimum and maximum specified values.
dynamicRa(3) - Dynamic Rate-Adaptation during initialization
process as well as during SHOWTIME.
o Adsl2InitResult:
Attributes with this syntax reference the recent result of a full
initialization attempt:
noFail(0) - Successful initialization.
configError(1) - Configuration failure.
configNotFeasible(2) - Configuration details not supported.
commFail(3) - Communication failure.
noPeerAtu(4) - Peer ADSL Transceiver Unit (ATU) not
detected.
otherCause(5) - Other initialization failure reason.
o Adsl2OperationModes:
Attributes with this syntax uniquely identify an ADSL mode, which
is a category associated with each transmission mode defined for
the ADSL/ADSL2 or ADSL2+ link. Part of the line configuration
profile depends on the ADSL Mode:
Specified as an enumeration construct, there are currently a few
dozen transmission modes in the list.
o Adsl2PowerMngState:
Attributes with this syntax uniquely identify each power
management state defined for the ADSL/ADSL2 or ADSL2+ link:
l0(1) - L0 - Full power management state.
l1(2) - L1 - Low power management state (for G.992.2).
l2(3) - L2 - Low power management state (for G.992.3,
G.992.4, and G.992.5).
l3(4) - L3 - Idle power management state.
o Adsl2ConfPmsForce:
Attributes with this syntax are configuration parameters that
reference the desired power management state for the ADSL/ADSL2 or
ADSL2+ link:
l3toL0(0) - Perform a transition from L3 to L0 (Full
power management state).
l0toL2(2) - Perform a transition from L0 to L2 (Low
power management state).
l0orL2toL3(3) - Perform a transition into L3 (Idle power
management state).
o Adsl2LConfProfPmMode:
Attributes with this syntax are configuration parameters that
reference the power modes/states into which the ATU-C or ATU-R may
autonomously transit.
This is a BITS structure that allows control of the following
transit options:
allowTransitionsToIdle(0) - XTU may autonomously transit
to idle (L3) state.
allowTransitionsToLowPower(1) - XTU may autonomously transit
to low-power (L2) state.
o Adsl2LineLdsf:
Attributes with this syntax are configuration parameters that
control the Loop Diagnostic mode for the ADSL/ADSL2 or ADSL2+
link:
inhibit(0) - Inhibit Loop Diagnostic mode.
force(1) - Force/Initiate Loop Diagnostic mode.
o Adsl2LdsfResult:
Attributes with this syntax are status parameters that report the
result of the recent Loop Diagnostic mode issued for the
ADSL/ADSL2 or ADSL2+ link:
none(1) - The default value, in case loop diagnostics
mode forced (LDSF) was never requested for
the associated line.
success(2) - The recent command completed
successfully.
inProgress(3) - The Loop Diagnostics process is in
progress.
unsupported(4) - The NE or the line card doesn't support
LDSF.
cannotRun(5) - The NE cannot initiate the command, due
to a nonspecific reason.
aborted(6) - The Loop Diagnostics process aborted.
failed(7) - The Loop Diagnostics process failed.
illegalMode(8) - The NE cannot initiate the command, due
to the specific mode of the relevant
line.
adminUp(9) - The NE cannot initiate the command because
the relevant line is administratively 'Up'.
tableFull(10) - The NE cannot initiate the command, due
to reaching the maximum number of rows
in the results table.
noResources(11) - The NE cannot initiate the command, due
to lack of internal memory resources.
o Adsl2SymbolProtection:
Attributes with this syntax are configuration parameters that
reference the minimum-length impulse noise protection (INP) in
terms of number of symbols:
noProtection(1) - INP not required.
halfSymbol(2) - INP length = 1/2 symbol.
singleSymbol(3) - INP length = 1 symbol.
twoSymbols(4) - INP length = 2 symbols.
threeSymbols(5) - INP length = 3 symbols.
fourSymbols(6) - INP length = 4 symbols.
fiveSymbols(7) - INP length = 5 symbols.
sixSymbols(8) - INP length = 6 symbols.
sevenSymbols(9) - INP length = 7 symbols.
eightSymbols(10) - INP length = 8 symbols.
nineSymbols(11) - INP length = 9 symbols.
tenSymbols(12) - INP length = 10 symbols.
elevenSymbols(13) - INP length = 11 symbols.
twelveSymbols(14) - INP length = 12 symbols.
thirteeSymbols(15) - INP length = 13 symbols.
fourteenSymbols(16) - INP length = 14 symbols.
fifteenSymbols(17) - INP length = 15 symbols.
sixteenSymbols(18) - INP length = 16 symbols.
o Adsl2MaxBer:
Attributes with this syntax are configuration parameters that
reference the maximum Bit Error Rate (BER):
eminus3(1) - Maximum BER=E^-3.
eminus5(2) - Maximum BER=E^-5.
eminus7(3) - Maximum BER=E^-7.
o Adsl2ScMaskDs:
Attributes with this syntax are configuration parameters that
reference the downstream sub-carrier mask. It is a bitmap of up
to 512 bits.
o Adsl2ScMaskUs:
Attributes with this syntax are configuration parameters that
reference the upstream sub-carrier mask. It is a bitmap of up to
64 bits.
o Adsl2RfiDs:
Attributes with this syntax are configuration parameters that
reference the downstream notch filters. It is a bitmap of up to
512 bits.
o Adsl2PsdMaskDs:
Attributes with this syntax are configuration parameters that
reference the downstream power spectrum density (PSD) mask. It is
a structure of up to 32 breakpoints, where each breakpoint
occupies 3 octets.
o Adsl2PsdMaskUs:
Attributes with this syntax are configuration parameters that
reference the upstream power spectrum density (PSD) mask. It is a
structure of up to 4 breakpoints, where each breakpoint occupies 3
octets.
o Adsl2Tssi:
Attributes with this syntax are status parameters that reference
the transmit spectrum shaping (TSSi). It is a structure of up to
32 breakpoints, where each breakpoint occupies 3 octets.
o Adsl2LastTransmittedState:
Attributes with this syntax reference the list of initialization
states for ADSL/ADSL2 or ADSL2+ modems. The list of states for CO
side modems (ATU-Cs) is different from the list of states for the
remote side modems (ATU-Rs).
Specified as an enumeration type, there are currently a few dozen
states in the list per each unit side (i.e., ATU-C or ATU-R).
o Adsl2LineStatus:
Attributes with this syntax are status parameters that reflect the
failure status for a given endpoint of ADSL/ADSL2 or ADSL2+ link.
This is a BITS structure that can report the following failures:
noDefect(0) - This bit position positively reports that
no defect or failure exists.
lossOfFrame(1) - Loss of frame synchronization.
lossOfSignal(2) - Loss of signal.
lossOfPower(3) - Loss of power. Usually this failure may
be reported for ATU-Rs only.
initFailure(4) - Recent initialization process failed.
Never active on ATU-R.
o Adsl2ChAtmStatus:
Attributes with this syntax are status parameters that reflect the
failure status for Transmission Convergence (TC) layer of a given
ATM interface (data path over an ADSL/ADSL2 or ADSL2+ link).
This is a BITS structure that can report the following failures:
noDefect(0) - This bit position positively reports
that no defect or failure exists.
noCellDelineation(1) - The link was successfully
initialized but cell delineation
was never acquired on the
associated ATM data path.
lossOfCellDelineation(2) - Loss of cell delineation on the
associated ATM data path.
o Adsl2ChPtmStatus:
Attributes with this syntax are status parameters that reflect the
failure status for a given PTM interface (packet data path over an
ADSL/ADSL2 or ADSL2+ link).
This is a BITS structure that can report the following failures:
noDefect(0) - This bit position positively reports that no
defect or failure exists.
outOfSync(1) - Out of synchronization.
2.4. Structure
The MIB module is structured into following MIB groups:
o Line Configuration, Maintenance, and Status Group:
This group supports MIB objects for configuring parameters for the
ADSL/ADSL2 or ADSL2+ line and retrieving line status information.
It also supports MIB objects for configuring a requested power
state or initiating a Dual Ended Loop Test (DELT) process in the
ADSL/ADSL2 or ADSL2+ line. It contains the following table:
- adsl2LineTable
o Channel Status Group:
This group supports MIB objects for retrieving channel layer
status information. It contains the following table:
- adsl2ChannelStatusTable
o Subcarrier Status Group:
This group supports MIB objects for retrieving the sub-carrier
layer status information, mostly collected by a Dual Ended Loop
Test (DELT) process. It contains the following table:
- adsl2SCStatusTable
o Unit Inventory Group:
This group supports MIB objects for retrieving Unit inventory
information about units in ADSL/ADSL2 or ADSL2+ lines via the EOC.
It contains the following table:
- adsl2LineInventoryTable
o Current Performance Group:
This group supports MIB objects that provide the current
performance information relating to ADSL/ADSL2 and ADSL2+ line,
units and channels level. It contains the following tables:
- adsl2PMLineCurrTable
- adsl2PMLineCurrInitTable
- adsl2PMChCurrTable
o 15-Minute Interval Performance Group:
This group supports MIB objects that provide historic performance
information relating to ADSL/ADSL2 and ADSL2+ line, units and
channels level in 15-minute intervals. It contains the following
tables:
- adsl2PMLineHist15MinTable
- adsl2PMLineInitHist15MinTable
- adsl2PMChHist15MinTable
o 1-Day Interval Performance Group:
This group supports MIB objects that provide historic performance
information relating to ADSL/ADSL2 and ADSL2+ line, units and
channels level in 1-day intervals. It contains the following
tables:
- adsl2PMLineHist1DayTable
- adsl2PMLineInitHist1DayTable
- adsl2PMChHist1DTable
o Configuration Template and Profile Group:
This group supports MIB objects for defining configuration
profiles for ADSL/ADSL2 and ADSL2+ lines and channels, as well as
configuration templates. Each configuration template is comprised
of one line configuration profile and one or more channel
configuration profiles. This group contains the following tables:
- adsl2LineConfTemplateTable
- adsl2LineConfProfTable
- adsl2LineConfProfModeSpecTable
- adsl2ChConfProfileTable
o Alarm Configuration Template and Profile Group:
This group supports MIB objects for defining alarm profiles for
ADSL/ADSL2 and ADSL2+ lines and channels, as well as alarm
templates. Each alarm template is comprised of one line alarm
profile and one or more channel alarm profiles. This group
contains the following tables:
- adsl2LineAlarmConfTemplateTable
- adsl2LineAlarmConfProfileTable
- adsl2ChAlarmConfProfileTable
o Notifications Group:
This group defines the notifications supported for ADSL/ADSL2 and
ADSL2+ lines:
- adsl2LinePerfFECSThreshAtuc
- adsl2LinePerfFECSThreshAtur
- adsl2LinePerfESThreshAtuc
- adsl2LinePerfESThreshAtur
- adsl2LinePerfSESThreshAtuc
- adsl2LinePerfSESThreshAtur
- adsl2LinePerfLOSSThreshAtuc
- adsl2LinePerfLOSSThreshAtur
- adsl2LinePerfUASThreshAtuc
- adsl2LinePerfUASThreshAtur
- adsl2LinePerfCodingViolationsThreshAtuc
- adsl2LinePerfCodingViolationsThreshAtur
- adsl2LinePerfCorrectedThreshAtuc
- adsl2LinePerfCorrectedThreshAtur
- adsl2LinePerfFailedFullInitThresh
- adsl2LinePerfFailedShortInitThresh
- adsl2LineStatusChangeAtuc
- adsl2LineStatusChangeAtur
2.5. Persistence
All read-create objects and most read-write objects defined in this
MIB module SHOULD be stored persistently. Following is an exhaustive
list of these persistent objects:
adsl2LineCnfgTemplate
adsl2LineAlarmCnfgTemplate
adsl2LineCmndConfPmsf
adsl2LineCmndConfLdsf
adsl2LineCmndAutomodeColdStart
adsl2LConfTempTemplateName
adsl2LConfTempLineProfile
adsl2LConfTempChan1ConfProfile
adsl2LConfTempChan1RaRatioDs
adsl2LConfTempChan1RaRatioUs
adsl2LConfTempChan2ConfProfile
adsl2LConfTempChan2RaRatioDs
adsl2LConfTempChan2RaRatioUs
adsl2LConfTempChan3ConfProfile
adsl2LConfTempChan3RaRatioDs
adsl2LConfTempChan3RaRatioUs
adsl2LConfTempChan4ConfProfile
adsl2LConfTempChan4RaRatioDs
adsl2LConfTempChan4RaRatioUs
adsl2LConfTempRowStatus
adsl2LConfProfProfileName
adsl2LConfProfScMaskDs
adsl2LConfProfScMaskUs
adsl2LConfProfRfiBandsDs
adsl2LConfProfRaModeDs
adsl2LConfProfRaModeUs
adsl2LConfProfRaUsNrmDs
adsl2LConfProfRaUsNrmUs
adsl2LConfProfRaUsTimeDs
adsl2LConfProfRaUsTimeUs
adsl2LConfProfRaDsNrmsDs
adsl2LConfProfRaDsNrmsUs
adsl2LConfProfRaDsTimeDs
adsl2LConfProfRaDsTimeUs
adsl2LConfProfTargetSnrmDs
adsl2LConfProfTargetSnrmUs
adsl2LConfProfMaxSnrmDs
adsl2LConfProfMaxSnrmUs
adsl2LConfProfMinSnrmDs
adsl2LConfProfMinSnrmUs
adsl2LConfProfMsgMinUs
adsl2LConfProfMsgMinDs
adsl2LConfProfAtuTransSysEna
adsl2LConfProfPmMode
adsl2LConfProfL0Time
adsl2LConfProfL2Time
adsl2LConfProfL2Atpr
adsl2LConfProfL2Atprt
adsl2LConfProfRowStatus
adsl2LConfProfAdslMode
adsl2LConfProfMaxNomPsdDs
adsl2LConfProfMaxNomPsdUs
adsl2LConfProfMaxNomAtpDs
adsl2LConfProfMaxNomAtpUs
adsl2LConfProfMaxAggRxPwrUs
adsl2LConfProfPsdMaskDs
adsl2LConfProfPsdMaskUs
adsl2LConfProfPsdMaskSelectUs
adsl2LConfProfModeSpecRowStatus
adsl2ChConfProfProfileName
adsl2ChConfProfMinDataRateDs
adsl2ChConfProfMinDataRateUs
adsl2ChConfProfMinResDataRateDs
adsl2ChConfProfMinResDataRateUs
adsl2ChConfProfMaxDataRateDs
adsl2ChConfProfMaxDataRateUs
adsl2ChConfProfMinDataRateLowPwrDs
adsl2ChConfProfMaxDelayDs
adsl2ChConfProfMaxDelayUs
adsl2ChConfProfMinProtectionDs
adsl2ChConfProfMinProtectionUs
adsl2ChConfProfMaxBerDs
adsl2ChConfProfMaxBerUs
adsl2ChConfProfUsDataRateDs
adsl2ChConfProfDsDataRateDs
adsl2ChConfProfUsDataRateUs
adsl2ChConfProfDsDataRateUs
adsl2ChConfProfImaEnabled
adsl2ChConfProfRowStatus
adsl2LAlarmConfTempTemplateName
adsl2LAlarmConfTempLineProfile
adsl2LAlarmConfTempChan1ConfProfile
adsl2LAlarmConfTempChan2ConfProfile
adsl2LAlarmConfTempChan3ConfProfile
adsl2LAlarmConfTempChan4ConfProfile
adsl2LAlarmConfTempRowStatus
adsl2LineAlarmConfProfileName
adsl2LineAlarmConfProfileAtucThresh15MinFecs
adsl2LineAlarmConfProfileAtucThresh15MinEs
adsl2LineAlarmConfProfileAtucThresh15MinSes
adsl2LineAlarmConfProfileAtucThresh15MinLoss
adsl2LineAlarmConfProfileAtucThresh15MinUas
adsl2LineAlarmConfProfileAturThresh15MinFecs
adsl2LineAlarmConfProfileAturThresh15MinEs
adsl2LineAlarmConfProfileAturThresh15MinSes
adsl2LineAlarmConfProfileAturThresh15MinLoss
adsl2LineAlarmConfProfileAturThresh15MinUas
adsl2LineAlarmConfProfileThresh15MinFailedFullInt
adsl2LineAlarmConfProfileThresh15MinFailedShrtInt
adsl2LineAlarmConfProfileRowStatus
adsl2ChAlarmConfProfileName
adsl2ChAlarmConfProfileAtucThresh15MinCodingViolations
adsl2ChAlarmConfProfileAtucThresh15MinCorrected
adsl2ChAlarmConfProfileAturThresh15MinCodingViolations
adsl2ChAlarmConfProfileAturThresh15MinCorrected
adsl2ChAlarmConfProfileRowStatus
Note also that the interface indices in this MIB are maintained
persistently. View-based Access Control Model (VACM) data relating
to these SHOULD be stored persistently as well [RFC3410].
2.6. Line Topology
An ADSL/ADSL2 and ADSL2+ Line consists of two units: ATU-C (the
central office termination unit) and ATU-R (the remote termination
unit). There are up to 4 channels, each carrying an independent
information flow, as shown in the figure below.
<-- Network Side Customer Side --> |<//////////////// ADSL/ADSL2/ADSL2+ Span /////////////////>| +-------+ +-------+ + |<---------------------1------------------->| + + |<---------------------2------------------->| + | ATU-C <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| ATU-R | + |<---------------------3------------------->| + + |<---------------------4------------------->| + +-------+ +-------+ Key: <////> ADSL/ADSL2/ADSL2+ Span <~~~~> ADSL/ADSL2/ADSL2+ twisted-pair -1- Channel #1 carried over the line -2- Optional channel #2 carried over the line -3- Optional channel #3 carried over the line -4- Optional channel #4 carried over the line Figure 2: General topology for an ADSL/ADSL2/ADSL2+ Line2.7. Counters, Interval Buckets, and Thresholds
2.7.1. Counters Managed
There are various types of counters specified in this MIB. Each counter refers either to the whole ADSL/ADSL2/ADSL2+ line, to one of the XTU entities, or to one of the bearer channels. o On the whole line level For full initializations, failed full initializations, short initializations, and failed short initializations, there are event counters, current 15-minute and 0 to 96 15-minute history bucket(s) of "interval-counters", as well as current and 0 to 30 previous 1-day interval-counter(s). Each current 15-minute "failed" event bucket has an associated threshold notification. o On the XTU level For the LOS Seconds, ES, SES, FEC seconds, and UAS, there are event counters, current 15-minute and 0 to 96 15-minute history bucket(s) of "interval-counters", as well as current and 0 to 30 previous 1-day interval-counter(s). Each current 15-minute event bucket has an associated threshold notification.
o On the bearer channel level For the coding violations (CRC anomalies) and corrected blocks (i.e., FEC events), there are event counters, current 15-minute and 0 to 96 15-minute history bucket(s) of "interval-counters", as well as current and 0 to 30 previous 1-day interval-counter(s). Each current 15-minute event bucket has an associated threshold notification.2.7.2. Minimum Number of Buckets
Although it is possible to support up to 96 15-minute history buckets of "interval-counters", systems implementing this MIB module SHOULD practically support at least 16 buckets, as specified in ITU-T G.997.1, paragraph 7.2.7.2. Similarly, it is possible to support up to 30 previous 1-day "interval-counters", but systems implementing this MIB module SHOULD support at least 1 previous-day bucket.2.7.3. Interval Buckets Initialization
There is no requirement for an agent to ensure a fixed relationship between the start of a 15-minute interval and any wall clock; however, some implementations may align the 15-minute intervals with quarter hours. Likewise, an implementation may choose to align one day intervals with the start of a day. Counters are not reset when an XTU is reinitialized, only when the agent is reset or reinitialized (or under specific request outside the scope of this MIB module).2.7.4. Interval Buckets Validity
As in RFC 3593 [RFC3593] and RFC 2662 [RFC2662], in case the data for an interval is suspect or known to be invalid, the agent MUST report the interval as invalid. If the current 15-minute event bucket is determined to be invalid, the element management system SHOULD ignore its content, and the agent MUST NOT generate notifications based upon the value of the event bucket. A valid 15-minute event bucket SHOULD usually count the events for exactly 15 minutes. Similarly, a valid 1-day event bucket SHOULD usually count the events for exactly 24 hours. However, the following scenarios are exceptional:
1) For implementations that align the 15-minute intervals with
quarter hours, and the 1-day intervals with start of a day, the
management system may still start the PM process not aligned with
the wall clock. Such a management system may wish to retrieve
even partial information for the first event buckets, rather than
declaring them all as invalid.
2) For an event bucket that suffered relatively short outages, the
management system may wish to retrieve the available PM outcomes,
rather than declare the whole event bucket as invalid. This is
more important for 1-day event buckets.
3) An event bucket may be shorter or longer than the formal duration
if a clock adjustment was performed during the interval.
This MIB allows supporting the exceptional scenarios described above
by reporting the actual Monitoring Time of a monitoring interval.
This parameter is relevant only for Valid intervals, but is useful
for these exceptional scenarios:
a) The management system MAY still declare a partial PM interval as
Valid and report the actual number of seconds the interval lasted.
b) If the interval was shortened or extended due to clock
corrections, the management system SHOULD report the actual number
of seconds the interval lasted, besides reporting that the
interval is Valid.
2.8. Profiles
As a managed node can handle a large number of XTUs, (e.g., hundreds
or perhaps thousands of lines), provisioning every parameter on every
XTU may become burdensome. Moreover, most lines are provisioned
identically with the same set of parameters. To simplify the
provisioning process, this MIB module makes use of profiles and
templates.
A configuration profile is a set of parameters that can be shared by
multiple entities. There are configuration profiles to address the
line-level provisioning, and another type of profile that addresses
the channel-level provisioning parameters.
A configuration template is actually a profile-of-profiles. That is,
a template is comprised of one line configuration profile and one or
more channel configuration profiles. A template provides the
complete configuration of a line. The same configuration can be
shared by multiple lines.
Similarly to the configuration profiles and templates, this MIB module makes use of templates and profiles for specifying the alarm thresholds associated with performance parameters. This allows provisioning multiple lines with the same criteria for generating threshold crossing notifications. The following paragraphs describe templates and profiles used in this MIB module2.8.1. Configuration Profiles and Templates
o Line Configuration Profiles - Line configuration profiles contain parameters for configuring the low layer of ADSL/ADSL2 and ADSL2+ lines. They are defined in the adsl2LineConfProfTable. The line configuration includes issues such as the specific ADSL/ADSL2 or ADSL2+ modes to enable on the respective line, power spectrum parameters, rate adaptation criteria, and SNR margin- related parameters. A subset of the line configuration parameters depends upon the specific ADSL Mode allowed (i.e., Does the profile allow ADSL, ADSL2, and/or ADSL2+) as well as what annex/annexes of the standard are allowed. This is the reason a line profile MUST include one or more mode-specific extensions. o Channel Configuration Profiles - Channel configuration profiles contain parameters for configuring bearer channels over the ADSL/ADSL2 and ADSL2+ lines. They are sometimes considered the service layer configuration of the ADSL/ADSL2 and ADSL2+ lines. They are defined in the adsl2ChConfProfTable. The channel configuration includes issues such as the desired minimum and maximum rate on each traffic flow direction and impulse noise protection parameters. o Line Configuration Templates - Line configuration templates allow combining line configuration profiles and channel configuration profiles to a comprehensive configuration of the ADSL/ADSL2 and ADSL2+ line. They are defined in the adsl2LineConfTemplateTable. The line configuration template includes one index (OID) of a line configuration profile and one to four indexes of channel configuration profiles. The template also addresses the issue of distributing the excess available data rate on each traffic flow direction (i.e., the data rate left after each channel is allocated a data rate to satisfy its minimum requested data rate) among the various channels.
2.8.2. Alarm Configuration Profiles and Templates
o Line Alarm Configuration Profiles - Line-level Alarm configuration profiles contain the threshold values for Performance Monitoring (PM) parameters, counted either on the whole line level or on an XTU level. Thresholds are required only for failures and anomalies, e.g., there are thresholds for failed initializations and LOS seconds, but not for the aggregate number of full initializations. These profiles are defined in the adsl2LineAlarmConfProfileTable. o Channel Alarm Configuration Profiles - Channel-level Alarm configuration profiles contain the threshold values for PM parameters counted on a bearer channel level. Thresholds are defined for two types of anomalies: corrected blocks and coding violations. These profiles are defined in the adsl2ChAlarmConfProfileTable. o Line Alarm Configuration Templates - Line Alarm configuration templates allow combining line-level alarm configuration profiles and channel-level alarm configuration profiles to a comprehensive configuration of the PM thresholds for ADSL/ADSL2 and ADSL2+ line. They are defined in the adsl2LineAlarmConfTemplateTable. The line alarm configuration template includes one index (OID) of a line-level alarm configuration profile and one to four indexes of channel-level alarm configuration profiles.2.8.3. Managing Profiles and Templates
The index value for each profile and template is a locally-unique, administratively assigned name having the textual convention 'SnmpAdminString' (RFC 3411 [RFC3411]). One or more lines may be configured to share parameters of a single configuration template (e.g., adsl2LConfTempTemplateName = 'silver') by setting its adsl2LineCnfgTemplate objects to the value of this template. One or more lines may be configured to share parameters of a single Alarm configuration template (e.g., adsl2LAlarmConfTempTemplateName = 'silver') by setting its adsl2LineAlarmCnfgTemplate objects to the value of this template. Before a template can be deleted or taken out of service, it MUST first be unreferenced from all associated lines. Implementations MAY also reject template modification while it is associated with any line.
Before a profile can be deleted or taken out of service, it MUST first be unreferenced from all associated templates. Implementations MAY also reject profile modification while it is referenced by any template. Implementations MUST provide a default profile whose name is 'DEFVAL' for each profile and template type. The values of the associated parameters will be vendor-specific unless otherwise indicated in this document. Before a line's templates have been set, these templates will be automatically used by setting adsl2LineCnfgTemplate and adsl2LineAlarmCnfgTemplate to 'DEFVAL' where appropriate. This default profile name, 'DEFVAL', is considered reserved in the context of profiles and templates defined in this MIB module. Profiles and templates are created, assigned, and deleted dynamically using the profile name and profile row status in each of the profile tables. If the implementation allows modifying a profile or template while it is associated with a line, then such changes MUST take effect immediately. These changes MAY result in a restart (hard reset or soft restart) of the units on the line.2.8.4. Managing Multiple Bearer Channels
The number of bearer channels is configured by setting the template attributes adsl2LConfTempChan1ConfProfile, adsl2LConfTempChan2ConfProfile, adsl2LConfTempChan3ConfProfile, and adsl2LConfTempChan4ConfProfile and then assigning that template to a DSL line using the adsl2LineCnfgTemplate attribute. When the number of bearer channels for a DSL line changes, the SNMP agent will automatically create or destroy rows in channel-related tables associated with that line. For example, when a DSL line is operating with one bearer channel, there will be zero rows in channel-related tables for channels two, three, and four. The SNMP agent MUST create and destroy channel-related rows as follows: o When the number of bearer channels for a DSL line changes to a higher number, the SNMP agent will automatically create rows in the adsl2ChannelStatusTable, and adsl2PMChCurrTable tables for that line. o When the number of bearer channels for a DSL line changes to a lower number, the SNMP agent will automatically destroy rows in the adsl2ChannelStatusTable, adsl2PMChCurrTable, adsl2PMChHist15MinTable, and adsl2PMChHist1DTable tables for that line.
2.9. Notifications
The ability to generate the SNMP notifications coldStart/warmStart (per [RFC3418]), which are per agent (e.g., per Digital Subscriber Line Access Multiplexer, or DSLAM, in such a device), and linkUp/linkDown (per [RFC2863]), which are per interface (i.e., ADSL/ADSL2 or ADSL2+ line), is REQUIRED. A linkDown notification MAY be generated whenever any of ES, SES, CRC Anomaly, LOS, LOF, or UAS event occurs. The corresponding linkUp notification MAY be sent when all link failure conditions are cleared. The notifications defined in this MIB module are for status change (e.g., initialization failure) and for the threshold crossings associated with the following events: full initialization failures, short initialization failures, ES, SES, FEC Seconds, LOS Seconds, UAS, FEC Seconds, FEC events, and CRC anomalies. Each threshold has its own enable/threshold value. When that value is 0, the notification is disabled. The adsl2LineStatusAtur and adsl2LineStatusAtuc are bitmasks representing all outstanding error conditions associated with the ATU-R and ATU-C (respectively). Note that since the ATU-R status is obtained via the EOC, this information may be unavailable in case the ATU-R is unreachable via EOC during a line error condition. Therefore, not all conditions may always be included in its current status. Notifications corresponding to the bit fields in those two status objects are defined. Note that there are other status parameters that refer to the ATU-R (e.g., downstream line attenuation). Those parameters also depend on the availability of EOC between the ATU-C and the ATU-R. A threshold notification occurs whenever the corresponding current 15-minute interval error counter becomes equal to or exceeds the threshold value. Only one notification SHOULD be sent per interval per interface. Since the current 15-minute counter is reset to 0 every 15 minutes, if the condition persists, the notification may recur as often as every 15 minutes. For example, to get a notification whenever a "loss of" event occurs (but at most once every 15 minutes), set the corresponding threshold to 1. The agent will generate a notification when the event originally occurs. Notifications, other than the threshold notifications listed above, SHOULD be rate-limited (throttled) such that there is an implementation-specific gap between the generation of consecutive notifications of the same event. When notifications are rate-
limited, they are dropped and not queued for sending at a future time. This is intended to be a general rate-limiting statement for notifications that otherwise have no explicit rate-limiting assertions in this document. Note that the Network Management System, or NMS, may receive a linkDown notification, as well, if enabled (via ifLinkUpDownTrapEnable [RFC2863]). At the beginning of the next 15 minute interval, the counter is reset. When the first second goes by and the event occurs, the current interval bucket will be 1, which equals the threshold, and the notification will be sent again.
(page 25 continued on part 2)