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. Morgenstern, et al. Standards Track [Page 1] RFC 4706 ADSL2-LINE MIB November 2006 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 Morgenstern, et al. Standards Track [Page 2] RFC 4706 ADSL2-LINE MIB November 2006 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. Morgenstern, et al. Standards Track [Page 3] RFC 4706 ADSL2-LINE MIB November 2006 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. Morgenstern, et al. Standards Track [Page 4] RFC 4706 ADSL2-LINE MIB November 2006 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. Morgenstern, et al. Standards Track [Page 5] RFC 4706 ADSL2-LINE MIB November 2006 ifLinkUpDownTrapEnable Default to enabled(1). ifHighSpeed Set as appropriate. ifConnectorPresent Set as appropriate. =================================================================== Figure 1: Use of ifTable Objects 2.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 Morgenstern, et al. Standards Track [Page 6] RFC 4706 ADSL2-LINE MIB November 2006 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. Morgenstern, et al. Standards Track [Page 7] RFC 4706 ADSL2-LINE MIB November 2006 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). Morgenstern, et al. Standards Track [Page 8] RFC 4706 ADSL2-LINE MIB November 2006 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. Morgenstern, et al. Standards Track [Page 9] RFC 4706 ADSL2-LINE MIB November 2006 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. Morgenstern, et al. Standards Track [Page 10] RFC 4706 ADSL2-LINE MIB November 2006 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. Morgenstern, et al. Standards Track [Page 11] RFC 4706 ADSL2-LINE MIB November 2006 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. Morgenstern, et al. Standards Track [Page 12] RFC 4706 ADSL2-LINE MIB November 2006 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: Morgenstern, et al. Standards Track [Page 13] RFC 4706 ADSL2-LINE MIB November 2006 - 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 Morgenstern, et al. Standards Track [Page 14] RFC 4706 ADSL2-LINE MIB November 2006 - 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 Morgenstern, et al. Standards Track [Page 15] RFC 4706 ADSL2-LINE MIB November 2006 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 Morgenstern, et al. Standards Track [Page 16] RFC 4706 ADSL2-LINE MIB November 2006 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. Morgenstern, et al. Standards Track [Page 17] RFC 4706 ADSL2-LINE MIB November 2006 <-- Network Side Customer Side --> || +-------+ +-------+ + |<---------------------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+ Line 2.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. Morgenstern, et al. Standards Track [Page 18] RFC 4706 ADSL2-LINE MIB November 2006 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: Morgenstern, et al. Standards Track [Page 19] RFC 4706 ADSL2-LINE MIB November 2006 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. Morgenstern, et al. Standards Track [Page 20] RFC 4706 ADSL2-LINE MIB November 2006 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 module 2.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. Morgenstern, et al. Standards Track [Page 21] RFC 4706 ADSL2-LINE MIB November 2006 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. Morgenstern, et al. Standards Track [Page 22] RFC 4706 ADSL2-LINE MIB November 2006 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. Morgenstern, et al. Standards Track [Page 23] RFC 4706 ADSL2-LINE MIB November 2006 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- Morgenstern, et al. Standards Track [Page 24] RFC 4706 ADSL2-LINE MIB November 2006 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. 3. Definitions ADSL2-LINE-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, transmission FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; adsl2TCMIB MODULE-IDENTITY LAST-UPDATED "200610040000Z" -- October 4th, 2006 ORGANIZATION "ADSLMIB Working Group" CONTACT-INFO "WG-email: adslmib@ietf.org Info: https://www1.ietf.org/mailman/listinfo/adslmib Chair: Mike Sneed Sand Channel Systems Postal: P.O. Box 37324 Raleigh NC 27627-732 Email: sneedmike@hotmail.com Phone: +1 206 600 7022 Co-Chair & Co-editor: Menachem Dodge ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel. Email: mbdodge@ieee.org Phone: +972 3 926 8421 Morgenstern, et al. Standards Track [Page 25] RFC 4706 ADSL2-LINE MIB November 2006 Co-editor: Moti Morgenstern ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel. Email: moti.morgenstern@ecitele.com Phone: +972 3 926 6258 Co-editor: Scott Baillie NEC Australia Postal: 649-655 Springvale Road, Mulgrave, Victoria 3170, Australia. Email: scott.baillie@nec.com.au Phone: +61 3 9264 3986 Co-editor: Umberto Bonollo NEC Australia Postal: 649-655 Springvale Road, Mulgrave, Victoria 3170, Australia. Email: umberto.bonollo@nec.com.au Phone: +61 3 9264 3385 " DESCRIPTION "This MIB Module provides Textual Conventions to be used by the ADSL2-LINE-MIB module for the purpose of managing ADSL, ADSL2, and ADSL2+ lines. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4706: see the RFC itself for full legal notices." REVISION "200610040000Z" -- October 4th, 2006 DESCRIPTION "Initial version, published as RFC 4706." ::= { transmission 238 2 } -- adsl2MIB 2 ------------------------------------------------ -- Textual Conventions -- ------------------------------------------------ Adsl2Unit ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies a transceiver as being either an ATU-C or an ATU-R. An ADSL line consists of two transceivers, an ATU-C and an ATU-R. Attributes with this syntax reference the two sides of a line. Specified as an INTEGER, the two values Morgenstern, et al. Standards Track [Page 26] RFC 4706 ADSL2-LINE MIB November 2006 are: atuc(1) -- Central office ADSL terminal unit (ATU-C). atur(2) -- Remote ADSL terminal unit (ATU-R)." SYNTAX INTEGER { atuc(1), atur(2) } Adsl2Direction ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies the direction of a band as being either upstream or downstream. Specified as an INTEGER, the two values are: upstream(1), and downstream(2)." SYNTAX INTEGER { upstream(1), downstream(2) } Adsl2TransmissionModeType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "A set of ADSL2 line transmission modes, with one bit per mode. The notes (F) and (L) denote Full-Rate and Lite/splitterless, respectively: Bit 00 : Regional Std. (ANSI T1.413) (F) Bit 01 : Regional Std. (ETSI DTS/TM06006) (F) Bit 02 : G.992.1 POTS non-overlapped (F) Bit 03 : G.992.1 POTS overlapped (F) Bit 04 : G.992.1 ISDN non-overlapped (F) Bit 05 : G.992.1 ISDN overlapped (F) Bit 06 : G.992.1 TCM-ISDN non-overlapped (F) Bit 07 : G.992.1 TCM-ISDN overlapped (F) Bit 08 : G.992.2 POTS non-overlapped (L) Bit 09 : G.992.2 POTS overlapped (L) Bit 10 : G.992.2 with TCM-ISDN non-overlapped (L) Bit 11 : G.992.2 with TCM-ISDN overlapped (L) Bit 12 : G.992.1 TCM-ISDN symmetric (F) -- not in G.997.1 Bit 13-17: Reserved Bit 18 : G.992.3 POTS non-overlapped (F) Bit 19 : G.992.3 POTS overlapped (F) Bit 20 : G.992.3 ISDN non-overlapped (F) Bit 21 : G.992.3 ISDN overlapped (F) Morgenstern, et al. Standards Track [Page 27] RFC 4706 ADSL2-LINE MIB November 2006 Bit 22-23: Reserved Bit 24 : G.992.4 POTS non-overlapped (L) Bit 25 : G.992.4 POTS overlapped (L) Bit 26-27: Reserved Bit 28 : G.992.3 Annex I All-Digital non-overlapped (F) Bit 29 : G.992.3 Annex I All-Digital overlapped (F) Bit 30 : G.992.3 Annex J All-Digital non-overlapped (F) Bit 31 : G.992.3 Annex J All-Digital overlapped (F) Bit 32 : G.992.4 Annex I All-Digital non-overlapped (L) Bit 33 : G.992.4 Annex I All-Digital overlapped (L) Bit 34 : G.992.3 Annex L POTS non-overlapped, mode 1, wide U/S (F) Bit 35 : G.992.3 Annex L POTS non-overlapped, mode 2, narrow U/S(F) Bit 36 : G.992.3 Annex L POTS overlapped, mode 3, wide U/S (F) Bit 37 : G.992.3 Annex L POTS overlapped, mode 4, narrow U/S (F) Bit 38 : G.992.3 Annex M POTS non-overlapped (F) Bit 39 : G.992.3 Annex M POTS overlapped (F) Bit 40 : G.992.5 POTS non-overlapped (F) Bit 41 : G.992.5 POTS overlapped (F) Bit 42 : G.992.5 ISDN non-overlapped (F) Bit 43 : G.992.5 ISDN overlapped (F) Bit 44-45: Reserved Bit 46 : G.992.5 Annex I All-Digital non-overlapped (F) Bit 47 : G.992.5 Annex I All-Digital overlapped (F) Bit 48 : G.992.5 Annex J All-Digital non-overlapped (F) Bit 49 : G.992.5 Annex J All-Digital overlapped (F) Bit 50 : G.992.5 Annex M POTS non-overlapped (F) Bit 51 : G.992.5 Annex M POTS overlapped (F) Bit 52-55: Reserved" SYNTAX BITS { ansit1413(0), etsi(1), g9921PotsNonOverlapped(2), g9921PotsOverlapped(3), g9921IsdnNonOverlapped(4), g9921isdnOverlapped(5), g9921tcmIsdnNonOverlapped(6), g9921tcmIsdnOverlapped(7), g9922potsNonOverlapped(8), g9922potsOverlapped(9), g9922tcmIsdnNonOverlapped(10), g9922tcmIsdnOverlapped(11), g9921tcmIsdnSymmetric(12), reserved1(13), reserved2(14), Morgenstern, et al. Standards Track [Page 28] RFC 4706 ADSL2-LINE MIB November 2006 reserved3(15), reserved4(16), reserved5(17), g9923PotsNonOverlapped(18), g9923PotsOverlapped(19), g9923IsdnNonOverlapped(20), g9923isdnOverlapped(21), reserved6(22), reserved7(23), g9924potsNonOverlapped(24), g9924potsOverlapped(25), reserved8(26), reserved9(27), g9923AnnexIAllDigNonOverlapped(28), g9923AnnexIAllDigOverlapped(29), g9923AnnexJAllDigNonOverlapped(30), g9923AnnexJAllDigOverlapped(31), g9924AnnexIAllDigNonOverlapped(32), g9924AnnexIAllDigOverlapped(33), g9923AnnexLMode1NonOverlapped(34), g9923AnnexLMode2NonOverlapped(35), g9923AnnexLMode3Overlapped(36), g9923AnnexLMode4Overlapped(37), g9923AnnexMPotsNonOverlapped(38), g9923AnnexMPotsOverlapped(39), g9925PotsNonOverlapped(40), g9925PotsOverlapped(41), g9925IsdnNonOverlapped(42), g9925isdnOverlapped(43), reserved10(44), reserved11(45), g9925AnnexIAllDigNonOverlapped(46), g9925AnnexIAllDigOverlapped(47), g9925AnnexJAllDigNonOverlapped(48), g9925AnnexJAllDigOverlapped(49), g9925AnnexMPotsNonOverlapped(50), g9925AnnexMPotsOverlapped(51), reserved12(52), reserved13(53), reserved14(54), reserved15(55) } Adsl2RaMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the rate adaptation behavior for the line. The three possible behaviors are: Morgenstern, et al. Standards Track [Page 29] RFC 4706 ADSL2-LINE MIB November 2006 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." SYNTAX INTEGER { manual(1), raInit(2), dynamicRa(3) } Adsl2InitResult ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Specifies the result of a full initialization attempt; the six possible result values are: noFail(0) - Successful initialization. configError(1) - Configuration failure. configNotFeasible(2) - Configuration details not supported. commFail(3) - Communication failure. noPeerAtu(4) - Peer ATU not detected. otherCause(5) - Other initialization failure reason. The values used are as defined in ITU-T G.997.1, paragraph 7.5.1.3" SYNTAX INTEGER { noFail(0), configError(1), configNotFeasible(2), commFail(3), noPeerAtu(4), otherCause(5) } Adsl2OperationModes ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The ADSL2 management model specified includes an ADSL Mode attribute that identifies an instance of ADSL Mode-Specific PSD Configuration object in the ADSL Line Profile. The following classes of ADSL operating mode are defined. The notes (F) and (L) denote Full-Rate and Lite/splitterless respectively: Morgenstern, et al. Standards Track [Page 30] RFC 4706 ADSL2-LINE MIB November 2006 +-------+--------------------------------------------------+ | Value | ADSL operation mode description | +-------+--------------------------------------------------+ 1 - The default/generic PSD configuration. Default configuration will be used when no other matching mode-specific configuration can be found. 2 - ADSL family. The attributes included in the Mode- Specific PSD Configuration are irrelevant for ITU-T G.992.1 and G.992.2 ADSL modes. Hence, it is possible to map those modes to this generic class. 3-7 - Unused. Reserved for future ITU-T specification. 8 - G.992.3 POTS non-overlapped (F) 9 - G.992.3 POTS overlapped (F) 10 - G.992.3 ISDN non-overlapped (F) 11 - G.992.3 ISDN overlapped (F) 12-13 - Unused. Reserved for future ITU-T specification. 14 - G.992.4 POTS non-overlapped (L) 15 - G.992.4 POTS overlapped (L) 16-17 - Unused. Reserved for future ITU-T specification. 18 - G.992.3 Annex I All-Digital non-overlapped (F) 19 - G.992.3 Annex I All-Digital overlapped (F) 20 - G.992.3 Annex J All-Digital non-overlapped (F) 21 - G.992.3 Annex J All-Digital overlapped (F) 22 - G.992.4 Annex I All-Digital non-overlapped (L) 23 - G.992.4 Annex I All-Digital overlapped (L) 24 - G.992.3 Annex L POTS non-overlapped, mode 1, wide U/S (F) 25 - G.992.3 Annex L POTS non-overlapped, mode 2, narrow U/S(F) 26 - G.992.3 Annex L POTS overlapped, mode 3, wide U/S (F) 27 - G.992.3 Annex L POTS overlapped, mode 4, narrow U/S (F) 28 - G.992.3 Annex M POTS non-overlapped (F) 29 - G.992.3 Annex M POTS overlapped (F) 30 - G.992.5 POTS non-overlapped (F) 31 - G.992.5 POTS overlapped (F) 32 - G.992.5 ISDN non-overlapped (F) 33 - G.992.5 ISDN overlapped (F) 34-35 - Unused. Reserved for future ITU-T specification. 36 - G.992.5 Annex I All-Digital non-overlapped (F) 37 - G.992.5 Annex I All-Digital overlapped (F) 38 - G.992.5 Annex J All-Digital non-overlapped (F) 39 - G.992.5 Annex J All-Digital overlapped (F) 40 - G.992.5 Annex M POTS non-overlapped (F) 41 - G.992.5 Annex M POTS overlapped (F) Morgenstern, et al. Standards Track [Page 31] RFC 4706 ADSL2-LINE MIB November 2006 " SYNTAX INTEGER { defMode (1), adsl(2), g9923PotsNonOverlapped(8), g9923PotsOverlapped(9), g9923IsdnNonOverlapped(10), g9923isdnOverlapped(11), g9924potsNonOverlapped(14), g9924potsOverlapped(15), g9923AnnexIAllDigNonOverlapped(18), g9923AnnexIAllDigOverlapped(19), g9923AnnexJAllDigNonOverlapped(20), g9923AnnexJAllDigOverlapped(21), g9924AnnexIAllDigNonOverlapped(22), g9924AnnexIAllDigOverlapped(23), g9923AnnexLMode1NonOverlapped(24), g9923AnnexLMode2NonOverlapped(25), g9923AnnexLMode3Overlapped(26), g9923AnnexLMode4Overlapped(27), g9923AnnexMPotsNonOverlapped(28), g9923AnnexMPotsOverlapped(29), g9925PotsNonOverlapped(30), g9925PotsOverlapped(31), g9925IsdnNonOverlapped(32), g9925isdnOverlapped(33), g9925AnnexIAllDigNonOverlapped(36), g9925AnnexIAllDigOverlapped(37), g9925AnnexJAllDigNonOverlapped(38), g9925AnnexJAllDigOverlapped(39), g9925AnnexMPotsNonOverlapped(40), g9925AnnexMPotsOverlapped(41) } Adsl2PowerMngState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax uniquely identify each power management state defined for the ADSL/ADSL2 or ADSL2+ link. The possible values are: 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." SYNTAX INTEGER { Morgenstern, et al. Standards Track [Page 32] RFC 4706 ADSL2-LINE MIB November 2006 l0(1), l1(2), l2(3), l3(4) } Adsl2ConfPmsForce ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "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). The values used are as defined in ITU-T G.997.1, paragraph 7.3.1.1.3" SYNTAX INTEGER { l3toL0(0), l0toL2(2), l0orL2toL3(3) } Adsl2LConfProfPmMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are configuration parameters that reference the power modes/states into which the ATU-C or ATU-R may autonomously transit. It 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." SYNTAX BITS { allowTransitionsToIdle(0), allowTransitionsToLowPower(1) } Adsl2LineLdsf ::= TEXTUAL-CONVENTION Morgenstern, et al. Standards Track [Page 33] RFC 4706 ADSL2-LINE MIB November 2006 STATUS current DESCRIPTION "Attributes with this syntax are configuration parameters that control the Loop Diagnostic mode for the ADSL/ADSL2 or ADSL2+ link. The possible values are: inhibit(0) - Inhibit Loop Diagnostic mode. force(1) - Force/Initiate Loop Diagnostic mode. The values used are as defined in ITU-T G.997.1, paragraph 7.3.1.1.8" SYNTAX INTEGER { inhibit(0), force(1) } Adsl2LdsfResult ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Possible failure reasons associated with performing a Dual Ended Loop Test (DELT) on a DSL line. Possible values are: none(1) - The default value in case 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, as 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." SYNTAX INTEGER { none(1), success(2), Morgenstern, et al. Standards Track [Page 34] RFC 4706 ADSL2-LINE MIB November 2006 inProgress(3), unsupported(4), cannotRun(5), aborted(6), failed(7), illegalMode(8), adminUp(9), tableFull(10), noResources(11) } Adsl2SymbolProtection ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are configuration parameters that reference the minimum-length impulse noise protection (INP) in terms of number of symbols. The possible values are: noProtection (i.e., INP not required), halfSymbol (i.e., INP length is 1/2 symbol), and 1-16 symbols in steps of 1 symbol." SYNTAX INTEGER { noProtection(1), halfSymbol(2), singleSymbol(3), twoSymbols(4), threeSymbols(5), fourSymbols(6), fiveSymbols(7), sixSymbols(8), sevenSymbols(9), eightSymbols(10), nineSymbols(11), tenSymbols(12), elevenSymbols(13), twelveSymbols(14), thirteeSymbols(15), fourteenSymbols(16), fifteenSymbols(17), sixteenSymbols(18) } Adsl2MaxBer ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are configuration parameters that reference the maximum Bit Error Rate (BER). The possible values are: eminus3(1) - Maximum BER=E^-3 Morgenstern, et al. Standards Track [Page 35] RFC 4706 ADSL2-LINE MIB November 2006 eminus5(2) - Maximum BER=E^-5 eminus7(3) - Maximum BER=E^-7" SYNTAX INTEGER { eminus3(1), eminus5(2), eminus7(3) } Adsl2ScMaskDs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Each one of the 512 bits in this OCTET STRING array represents the corresponding bin in the downstream direction. A value of one indicates that the bin is not in use." SYNTAX OCTET STRING (SIZE(0..64)) Adsl2ScMaskUs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Each one of the 64 bits in this OCTET STRING array represents the corresponding bin in the upstream direction. A value of one indicates that the bin is not in use." SYNTAX OCTET STRING (SIZE(0..8)) Adsl2RfiDs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Each one of the 512 bits in this OCTET STRING array represents the corresponding bin in the downstream direction. A value of one indicates that the bin is part of a notch filter." SYNTAX OCTET STRING (SIZE(0..64)) Adsl2PsdMaskDs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is a structure that represents up to 32 PSD Mask breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the sub-carrier associated with the breakpoint. The third octet holds the PSD reduction at the breakpoint from 0 (0 dBm/Hz) to 255 (-127.5 dBm/Hz) using units of 0.5 dBm/Hz." SYNTAX OCTET STRING (SIZE(0..96)) Morgenstern, et al. Standards Track [Page 36] RFC 4706 ADSL2-LINE MIB November 2006 Adsl2PsdMaskUs ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is a structure that represents up to 4 PSD Mask breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the sub-carrier associated with the breakpoint. The third octet holds the PSD reduction at the breakpoint from 0 (0 dBm/Hz) to 255 (-127.5 dBm/Hz) using units of 0.5 dBm/Hz." SYNTAX OCTET STRING (SIZE(0..12)) Adsl2Tssi ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is a structure that represents up to 32 transmit spectrum shaping (TSSi) breakpoints. Each breakpoint occupies 3 octets: The first two octets hold the index of the sub-carrier associated with the breakpoint. The third octet holds the shaping parameter at the breakpoint. It is a value from 0 to 127 (units of -0.5 dB). The special value 127 indicates that the sub-carrier is not transmitted." SYNTAX OCTET STRING (SIZE(0..96)) Adsl2LastTransmittedState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This parameter represents the last successfully transmitted initialization state in the last full initialization performed on the line. States are per the specific xDSL technology and are numbered from 0 (if G.994.1 is used) or 1 (if G.994.1 is not used) up to Showtime." SYNTAX INTEGER { atucG9941(0), atucQuiet1(1), atucComb1(2), atucQuiet2(3), atucComb2(4), atucIcomb1(5), atucLineprob(6), atucQuiet3(7), atucComb3(8), atucIComb2(9), atucMsgfmt(10), Morgenstern, et al. Standards Track [Page 37] RFC 4706 ADSL2-LINE MIB November 2006 atucMsgpcb(11), atucQuiet4(12), atucReverb1(13), atucTref1(14), atucReverb2(15), atucEct(16), atucReverb3(17), atucTref2(18), atucReverb4(19), atucSegue1(20), atucMsg1(21), atucReverb5(22), atucSegue2(23), atucMedley(24), atucExchmarker(25), atucMsg2(26), atucReverb6(27), atucSegue3(28), atucParams(29), atucReverb7(30), atucSegue4(31), atucShowtime(32), -- aturG9941(100), aturQuiet1(101), aturComb1(102), aturQuiet2(103), aturComb2(104), aturIcomb1(105), aturLineprob(106), aturQuiet3(107), aturComb3(108), aturIcomb2(109), aturMsgfmt(110), aturMsgpcb(111), aturReverb1(112), aturQuiet4(113), aturReverb2(114), aturQuiet5(115), aturReverb3(116), aturEct(117), aturReverb4(118), aturSegue1(119), aturReverb5(120), aturSegue2(121), aturMsg1(122), aturMedley(123), aturExchmarker(124), Morgenstern, et al. Standards Track [Page 38] RFC 4706 ADSL2-LINE MIB November 2006 aturMsg2(125), aturReverb6(126), aturSegue3(127), aturParams(128), aturReverb7(129), aturSegue4(130), aturShowtime(131) } Adsl2LineStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Attributes with this syntax are status parameters that reflect the failure status for a given endpoint of ADSL/ADSL2 or ADSL2+ link. This BITS structure 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." SYNTAX BITS { noDefect(0), lossOfFrame(1), lossOfSignal(2), lossOfPower(3), initFailure(4) } Adsl2ChAtmStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "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 BITS structure can report the following failures: noDefect(0) - This bit position positively reports that no defect or failure exists. noCellDelineation(1) - The link was successfully Morgenstern, et al. Standards Track [Page 39] RFC 4706 ADSL2-LINE MIB November 2006 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." SYNTAX BITS { noDefect(0), noCellDelineation(1), lossOfCellDelineation(2) } Adsl2ChPtmStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "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 BITS structure can report the following failures: noDefect(0) - This bit position positively reports that no defect or failure exists. outOfSync(1) - Out of synchronization." SYNTAX BITS { noDefect(0), outOfSync(1) } END Morgenstern, et al. Standards Track [Page 40] RFC 4706 ADSL2-LINE MIB November 2006 ADSL2-LINE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, transmission, Unsigned32, NOTIFICATION-TYPE, Integer32, Counter32 FROM SNMPv2-SMI ifIndex FROM IF-MIB TruthValue, RowStatus FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB HCPerfIntervalThreshold, HCPerfTimeElapsed FROM HC-PerfHist-TC-MIB -- [RFC3705] Adsl2Unit, Adsl2Direction, Adsl2TransmissionModeType, Adsl2RaMode, Adsl2InitResult, Adsl2OperationModes, Adsl2PowerMngState, Adsl2ConfPmsForce, Adsl2LConfProfPmMode, Adsl2LineLdsf, Adsl2LdsfResult, Adsl2SymbolProtection, Adsl2MaxBer, Adsl2ScMaskDs, Adsl2ScMaskUs, Adsl2RfiDs, Adsl2PsdMaskDs, Adsl2PsdMaskUs, Adsl2Tssi, Adsl2LastTransmittedState, Adsl2LineStatus, Adsl2ChAtmStatus, Morgenstern, et al. Standards Track [Page 41] RFC 4706 ADSL2-LINE MIB November 2006 Adsl2ChPtmStatus FROM ADSL2-LINE-TC-MIB -- [This document] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; adsl2MIB MODULE-IDENTITY LAST-UPDATED "200610040000Z" -- October 4th, 2006 ORGANIZATION "ADSLMIB Working Group" CONTACT-INFO "WG-email: adslmib@ietf.org Info: https://www1.ietf.org/mailman/listinfo/adslmib Chair: Mike Sneed Sand Channel Systems Postal: P.O. Box 37324 Raleigh NC 27627-732 Email: sneedmike@hotmail.com Phone: +1 206 600 7022 Co-Chair & Co-editor: Menachem Dodge ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel. Email: mbdodge@ieee.org Phone: +972 3 926 8421 Co-editor: Moti Morgenstern ECI Telecom Ltd. Postal: 30 Hasivim St. Petach Tikva 49517, Israel. Email: moti.morgenstern@ecitele.com Phone: +972 3 926 6258 Co-editor: Scott Baillie NEC Australia Postal: 649-655 Springvale Road, Mulgrave, Victoria 3170, Australia. Email: scott.baillie@nec.com.au Phone: +61 3 9264 3986 Co-editor: Umberto Bonollo Morgenstern, et al. Standards Track [Page 42] RFC 4706 ADSL2-LINE MIB November 2006 NEC Australia Postal: 649-655 Springvale Road, Mulgrave, Victoria 3170, Australia. Email: umberto.bonollo@nec.com.au Phone: +61 3 9264 3385 " DESCRIPTION " 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 by the Digital Subscriber Line Forum (DSLF) has been taken into consideration [TR-90]. That framework is based on ITU-T G.997.1 standard [G.997.1] as well as two amendments: [G.997.1am1] and [G.997.1am2]. Note that the revised ITU-T G.997.1 standard also refers to the next generation of VDSL technology, known as VDSL2, 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. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4706: see the RFC itself for full legal notices." Morgenstern, et al. Standards Track [Page 43] RFC 4706 ADSL2-LINE MIB November 2006 REVISION "200610040000Z" -- October 4th, 2006 DESCRIPTION "Initial version, published as RFC 4706." ::= { transmission 238 } adsl2 OBJECT IDENTIFIER ::= { adsl2MIB 1 } ------------------------------------------------ adsl2Line OBJECT IDENTIFIER ::= { adsl2 1 } adsl2Status OBJECT IDENTIFIER ::= { adsl2 2 } adsl2Inventory OBJECT IDENTIFIER ::= { adsl2 3 } adsl2PM OBJECT IDENTIFIER ::= { adsl2 4 } adsl2Profile OBJECT IDENTIFIER ::= { adsl2 5 } adsl2Scalar OBJECT IDENTIFIER ::= { adsl2 6 } adsl2Notifications OBJECT IDENTIFIER ::= { adsl2 0 } adsl2Conformance OBJECT IDENTIFIER ::= { adsl2 7 } ------------------------------------------------ adsl2PMLine OBJECT IDENTIFIER ::= { adsl2PM 1 } adsl2PMChannel OBJECT IDENTIFIER ::= { adsl2PM 2 } ------------------------------------------------ adsl2ProfileLine OBJECT IDENTIFIER ::= { adsl2Profile 1 } adsl2ProfileChannel OBJECT IDENTIFIER ::= { adsl2Profile 2 } adsl2ProfileAlarmConf OBJECT IDENTIFIER ::= { adsl2Profile 3 } ------------------------------------------------ adsl2ScalarSC OBJECT IDENTIFIER ::= { adsl2Scalar 1 } ------------------------------------------------ ------------------------------------------------ -- adsl2LineTable -- ------------------------------------------------ adsl2LineTable OBJECT-TYPE SYNTAX SEQUENCE OF Adsl2LineEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2LineTable contains configuration, command, and status parameters of the ADSL2 line. The index of this table is an interface index where the interface has an ifType of adsl2plus(238). Several objects in this table MUST be maintained in a persistent manner." ::= { adsl2Line 1 } adsl2LineEntry OBJECT-TYPE SYNTAX Adsl2LineEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 44] RFC 4706 ADSL2-LINE MIB November 2006 "The table adsl2LineTable contains configuration, commands, and status parameters of the ADSL2 line" INDEX { ifIndex } ::= { adsl2LineTable 1 } Adsl2LineEntry ::= SEQUENCE { adsl2LineCnfgTemplate SnmpAdminString, adsl2LineAlarmCnfgTemplate SnmpAdminString, adsl2LineCmndConfPmsf Adsl2ConfPmsForce, adsl2LineCmndConfLdsf Adsl2LineLdsf, adsl2LineCmndConfLdsfFailReason Adsl2LdsfResult, adsl2LineCmndAutomodeColdStart TruthValue, adsl2LineStatusAtuTransSys Adsl2TransmissionModeType, adsl2LineStatusPwrMngState Adsl2PowerMngState, adsl2LineStatusInitResult Adsl2InitResult, adsl2LineStatusLastStateDs Adsl2LastTransmittedState, adsl2LineStatusLastStateUs Adsl2LastTransmittedState, adsl2LineStatusAtur Adsl2LineStatus, adsl2LineStatusAtuc Adsl2LineStatus, adsl2LineStatusLnAttenDs Unsigned32, adsl2LineStatusLnAttenUs Unsigned32, adsl2LineStatusSigAttenDs Unsigned32, adsl2LineStatusSigAttenUs Unsigned32, adsl2LineStatusSnrMarginDs Integer32, adsl2LineStatusSnrMarginUs Integer32, adsl2LineStatusAttainableRateDs Unsigned32, adsl2LineStatusAttainableRateUs Unsigned32, adsl2LineStatusActPsdDs Integer32, adsl2LineStatusActPsdUs Integer32, adsl2LineStatusActAtpDs Integer32, adsl2LineStatusActAtpUs Integer32 } adsl2LineCnfgTemplate OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the row in the ADSL2 Line Configuration Templates Table, (adsl2LineConfTemplateTable), which applies for this ADSL2 line. This object MUST be maintained in a persistent manner." REFERENCE "DSL Forum TR-90, paragraph 5.1.1" DEFVAL { "DEFVAL" } ::= { adsl2LineEntry 1 } Morgenstern, et al. Standards Track [Page 45] RFC 4706 ADSL2-LINE MIB November 2006 adsl2LineAlarmCnfgTemplate OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object identifies the row in the ADSL2 Line Alarm Configuration Template Table, (adsl2LineAlarmConfTemplateTable), which applies to this ADSL2 line. This object MUST be maintained in a persistent manner." REFERENCE "DSL Forum TR-90, paragraph 5.1.1" DEFVAL { "DEFVAL" } ::= { adsl2LineEntry 2 } adsl2LineCmndConfPmsf OBJECT-TYPE SYNTAX Adsl2ConfPmsForce MAX-ACCESS read-write STATUS current DESCRIPTION "Power management state forced. Defines the line states to be forced by the near-end ATU on this line. The various possible values are: l3toL0(0), l0toL2(2), or l0orL2toL3(3). This object MUST be maintained in a persistent manner." REFERENCE "ITU-T G.997.1, paragraph 7.3.1.1.3" DEFVAL { l3toL0 } ::= { adsl2LineEntry 3 } adsl2LineCmndConfLdsf OBJECT-TYPE SYNTAX Adsl2LineLdsf MAX-ACCESS read-write STATUS current DESCRIPTION "Loop diagnostics mode forced (LDSF). Defines whether the line should be forced into the loop diagnostics mode by the near-end ATU on this line or only be responsive to loop diagnostics initiated by the far-end ATU. This object MUST be maintained in a persistent manner. However, in case the operator forces loop diagnostics mode then the access node should reset the object (inhibit) when loop diagnostics mode procedures are completed." REFERENCE "ITU-T G.997.1, paragraph 7.3.1.1.8" DEFVAL { inhibit } Morgenstern, et al. Standards Track [Page 46] RFC 4706 ADSL2-LINE MIB November 2006 ::= { adsl2LineEntry 4 } adsl2LineCmndConfLdsfFailReason OBJECT-TYPE SYNTAX Adsl2LdsfResult MAX-ACCESS read-only STATUS current DESCRIPTION "The status of the recent occasion the Loop diagnostics mode forced (LDSF) was issued for the associated line. Possible values are: none(1) - The default value in case 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, as 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." DEFVAL { none } ::= { adsl2LineEntry 5 } adsl2LineCmndAutomodeColdStart OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Automode cold start forced. This parameter is defined in order to improve testing of the performance of ATUs supporting automode when it is enabled in the MIB. Change the value of this parameter to 'true' indicates a change in loop conditions applied to the devices under test. The ATUs shall reset any historical information used for automode and for shortening G.994.1 handshake Morgenstern, et al. Standards Track [Page 47] RFC 4706 ADSL2-LINE MIB November 2006 and initialization. Automode is the case where multiple operation-modes are enabled through the adsl2LConfProfAtuTransSysEna object in the line configuration profile being used for the ADSL line, and where the selection of the actual operation-mode depends not only on the common capabilities of both ATUs (as exchanged in G.994.1), but also on achievable data rates under given loop conditions. This object MUST be maintained in a persistent manner." REFERENCE "ITU-T G.997.1 (amendment 1), 7.3.1.1.10" DEFVAL { false } ::= { adsl2LineEntry 6 } adsl2LineStatusAtuTransSys OBJECT-TYPE SYNTAX Adsl2TransmissionModeType MAX-ACCESS read-only STATUS current DESCRIPTION "The ATU Transmission System (ATS) in use. It is coded in a bit-map representation with only a single bit set to '1' (the selected coding for the ADSL line). This parameter may be derived from the handshaking procedures defined in Recommendation G.994.1. A set of ADSL2 line transmission modes, with one bit per mode." REFERENCE "ITU-T G.997.1, paragraph 7.3.1.1.1" ::= { adsl2LineEntry 7 } adsl2LineStatusPwrMngState OBJECT-TYPE SYNTAX Adsl2PowerMngState MAX-ACCESS read-only STATUS current DESCRIPTION "The current power management state. One of four possible power management states: L0 - Synchronized and full transmission (i.e., Showtime). L1 - Low Power with reduced net data rate (G.992.2 only). L2 - Low Power with reduced net data rate (G.992.3 and G.992.4 only). L3 - No power. The various possible values are: l0(1), l1(2), l2(3), or l3(4)." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.2" ::= { adsl2LineEntry 8 } Morgenstern, et al. Standards Track [Page 48] RFC 4706 ADSL2-LINE MIB November 2006 adsl2LineStatusInitResult OBJECT-TYPE SYNTAX Adsl2InitResult MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the result of the last full initialization performed on the line. It is an enumeration type with the following values: noFail(0), configError(1), configNotFeasible(2), commFail(3), noPeerAtu(4), or otherCause(5)." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.3" ::= { adsl2LineEntry 9 } adsl2LineStatusLastStateDs OBJECT-TYPE SYNTAX Adsl2LastTransmittedState MAX-ACCESS read-only STATUS current DESCRIPTION "The last successful transmitted initialization state in the downstream direction in the last full initialization performed on the line." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.4" ::= { adsl2LineEntry 10 } adsl2LineStatusLastStateUs OBJECT-TYPE SYNTAX Adsl2LastTransmittedState MAX-ACCESS read-only STATUS current DESCRIPTION "The last successful transmitted initialization state in the upstream direction in the last full initialization performed on the line." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.5" ::= { adsl2LineEntry 11 } adsl2LineStatusAtur OBJECT-TYPE SYNTAX Adsl2LineStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates current state (existing failures) of the ATU-R. This is a bit-map of possible conditions." REFERENCE "ITU-T G.997.1, paragraph 7.1.1.2" ::= { adsl2LineEntry 12 } adsl2LineStatusAtuc OBJECT-TYPE SYNTAX Adsl2LineStatus MAX-ACCESS read-only STATUS current Morgenstern, et al. Standards Track [Page 49] RFC 4706 ADSL2-LINE MIB November 2006 DESCRIPTION "Indicates current state (existing failures) of the ATU-C. This is a bit-map of possible conditions." REFERENCE "ITU-T G.997.1, paragraph 7.1.1.1" ::= { adsl2LineEntry 13 } adsl2LineStatusLnAttenDs OBJECT-TYPE SYNTAX Unsigned32 (0..1270 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "The measured difference in the total power transmitted by the ATU-C and the total power received by the ATU-R over all sub- carriers during diagnostics mode and initialization. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the line attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the line attenuation measurement is currently unavailable." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.6" ::= { adsl2LineEntry 14 } adsl2LineStatusLnAttenUs OBJECT-TYPE SYNTAX Unsigned32 (0..1270 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "The measured difference in the total power transmitted by the ATU-R and the total power received by the ATU-C over all sub- carriers during diagnostics mode and initialization. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the line attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the line attenuation measurement is currently unavailable." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.7" ::= { adsl2LineEntry 15 } adsl2LineStatusSigAttenDs OBJECT-TYPE SYNTAX Unsigned32 (0..1270 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 50] RFC 4706 ADSL2-LINE MIB November 2006 "The measured difference in the total power transmitted by the ATU-C and the total power received by the ATU-R over all sub- carriers during Showtime. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the signal attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the signal attenuation measurement is currently unavailable." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.8" ::= { adsl2LineEntry 16 } adsl2LineStatusSigAttenUs OBJECT-TYPE SYNTAX Unsigned32 (0..1270 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "The measured difference in the total power transmitted by the ATU-R and the total power received by the ATU-C over all sub- carriers during Showtime. It ranges from 0 to 1270 units of 0.1 dB (physical values are 0 to 127 dB). A special value of 0x7FFFFFFF (2147483647) indicates the signal attenuation is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the signal attenuation measurement is currently unavailable." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.9" ::= { adsl2LineEntry 17 } adsl2LineStatusSnrMarginDs OBJECT-TYPE SYNTAX Integer32 (-640..630 | 2147483646 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Downstream SNR Margin is the maximum increase in dB of the noise power received at the ATU-R, such that the BER requirements are met for all downstream bearer channels. It ranges from -640 to 630 units of 0.1 dB (physical values are -64 to 63 dB). A special value of 0x7FFFFFFF (2147483647) indicates the SNR Margin is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the SNR Margin measurement is currently unavailable." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.10" ::= { adsl2LineEntry 18 } adsl2LineStatusSnrMarginUs OBJECT-TYPE SYNTAX Integer32 (-640..630 | 2147483646 | 2147483647) Morgenstern, et al. Standards Track [Page 51] RFC 4706 ADSL2-LINE MIB November 2006 UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Upstream SNR Margin is the maximum increase in dB of the noise power received at the ATU-C, such that the BER requirements are met for all downstream bearer channels. It ranges from -640 to 630 units of 0.1 dB (physical values are -64 to 63 dB). A special value of 0x7FFFFFFF (2147483647) indicates the SNR Margin is out of range to be represented. A special value of 0x7FFFFFFE (2147483646) indicates the SNR Margin measurement is currently unavailable." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.11" ::= { adsl2LineEntry 19 } adsl2LineStatusAttainableRateDs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum Attainable Data Rate Downstream. The maximum downstream net data rate currently attainable by the ATU-C transmitter and the ATU-R receiver, coded in bits/second." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.12" ::= { adsl2LineEntry 20 } adsl2LineStatusAttainableRateUs OBJECT-TYPE SYNTAX Unsigned32 UNITS "bits/second" MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum Attainable Data Rate Upstream. The maximum upstream net data rate currently attainable by the ATU-R transmitter and the ATU-C receiver, coded in bits/second." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.13" ::= { adsl2LineEntry 21 } adsl2LineStatusActPsdDs OBJECT-TYPE SYNTAX Integer32 (-900..0 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION Morgenstern, et al. Standards Track [Page 52] RFC 4706 ADSL2-LINE MIB November 2006 "Actual Power Spectrum Density (PSD) Downstream. The average downstream transmit PSD over the sub-carriers used for downstream. It ranges from -900 to 0 units of 0.1 dB (physical values are -90 to 0 dBm/Hz). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.14" ::= { adsl2LineEntry 22 } adsl2LineStatusActPsdUs OBJECT-TYPE SYNTAX Integer32 (-900..0 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Power Spectrum Density (PSD) Upstream. The average upstream transmit PSD over the sub-carriers used for upstream. It ranges from -900 to 0 units of 0.1 dB (physical values are -90 to 0 dBm/Hz). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.15" ::= { adsl2LineEntry 23 } adsl2LineStatusActAtpDs OBJECT-TYPE SYNTAX Integer32 (-310..310 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Aggregate Transmit Power Downstream. The total amount of transmit power delivered by the ATU-C at the U-C reference point, at the instant of measurement. It ranges from -310 to 310 units of 0.1 dB (physical values are -31 to 31 dBm). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.16" ::= { adsl2LineEntry 24 } adsl2LineStatusActAtpUs OBJECT-TYPE SYNTAX Integer32 (-310..310 | 2147483647) UNITS "0.1 dB" MAX-ACCESS read-only STATUS current DESCRIPTION "Actual Aggregate Transmit Power Upstream. The total amount of transmit power delivered by the ATU-R at the U-R reference point, at the instant of measurement. It ranges Morgenstern, et al. Standards Track [Page 53] RFC 4706 ADSL2-LINE MIB November 2006 from -310 to 310 units of 0.1 dB (physical values are -31 to 31 dBm). A value of 0x7FFFFFFF (2147483647) indicates the measurement is out of range to be represented." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.17" ::= { adsl2LineEntry 25 } ------------------------------------------------ -- adsl2ChannelStatusTable -- ------------------------------------------------ adsl2ChannelStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF Adsl2ChannelStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2ChannelStatusTable contains status parameters of the ADSL2 channel. This table contains live data from equipment." ::= { adsl2Status 1 } adsl2ChannelStatusEntry OBJECT-TYPE SYNTAX Adsl2ChannelStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2ChannelStatusTable contains status parameters of the ADSL2 channel. The index of this table consists of an interface index, where the interface has an ifType value that is applicable for a DSL channel, along with a termination unit." INDEX { ifIndex, adsl2ChStatusUnit } ::= { adsl2ChannelStatusTable 1 } Adsl2ChannelStatusEntry ::= SEQUENCE { adsl2ChStatusUnit Adsl2Unit, adsl2ChStatusChannelNum Unsigned32, adsl2ChStatusActDataRate Unsigned32, adsl2ChStatusPrevDataRate Unsigned32, adsl2ChStatusActDelay Unsigned32, adsl2ChStatusAtmStatus Adsl2ChAtmStatus, adsl2ChStatusPtmStatus Adsl2ChPtmStatus } adsl2ChStatusUnit OBJECT-TYPE SYNTAX Adsl2Unit MAX-ACCESS not-accessible Morgenstern, et al. Standards Track [Page 54] RFC 4706 ADSL2-LINE MIB November 2006 STATUS current DESCRIPTION "The termination unit atuc(1) or atur(2)." ::= { adsl2ChannelStatusEntry 1 } adsl2ChStatusChannelNum OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Provides the bearer channel number associated with this row (i.e., the channel ifIndex). This enables determining the channel configuration profile and the channel thresholds profile applicable for this bearer channel." ::= { adsl2ChannelStatusEntry 2 } adsl2ChStatusActDataRate OBJECT-TYPE SYNTAX Unsigned32(0..200000000) UNITS "bits/second" MAX-ACCESS read-only STATUS current DESCRIPTION "The actual net data rate that the bearer channel is operating at, if in L0 power management state. In L1 or L2 states, it relates to the previous L0 state. The data rate is coded in bits/second." REFERENCE "ITU-T G.997.1, paragraph 7.5.2.1" ::= { adsl2ChannelStatusEntry 3 } adsl2ChStatusPrevDataRate OBJECT-TYPE SYNTAX Unsigned32(0..200000000) UNITS "bits/second" MAX-ACCESS read-only STATUS current DESCRIPTION "The previous net data rate that the bearer channel was operating at just before the latest rate change event. This could be a full or short initialization, fast retrain, DRA or power management transitions, excluding transitions between L0 state and L1 or L2 states. The data rate is coded in bits/second." REFERENCE "ITU-T G.997.1, paragraph 7.5.2.2" ::= { adsl2ChannelStatusEntry 4 } adsl2ChStatusActDelay OBJECT-TYPE SYNTAX Unsigned32(0..8176) UNITS "milliseconds" Morgenstern, et al. Standards Track [Page 55] RFC 4706 ADSL2-LINE MIB November 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The actual one-way interleaving delay introduced by the PMS-TC in the direction of the bearer channel, if in L0 power management state. In L1 or L2 states, it relates to the previous L0 state. It is coded in ms (rounded to the nearest ms)." REFERENCE "ITU-T G.997.1, paragraph 7.5.2.3" ::= { adsl2ChannelStatusEntry 5 } adsl2ChStatusAtmStatus OBJECT-TYPE SYNTAX Adsl2ChAtmStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the current state (existing failures) of the ADSL channel in case its Data Path is ATM. This is a bit-map of possible conditions. The various bit positions are: noDefect(0), noCellDelineation(1), or lossOfCellDelineation(2). In the case where the channel is not an ATM Data Path, the object is set to '0'." REFERENCE "ITU-T G.997.1, paragraph 7.1.4" ::= { adsl2ChannelStatusEntry 6 } adsl2ChStatusPtmStatus OBJECT-TYPE SYNTAX Adsl2ChPtmStatus MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the current state (existing failures) of the ADSL channel in case its Data Path is PTM. This is a bit-map of possible conditions. The various bit positions are: noDefect(0), or outOfSync(1). In the case where the channel is not a PTM Data Path, the object is set to '0'." REFERENCE "ITU-T G.997.1, paragraph 7.1.5" ::= { adsl2ChannelStatusEntry 7 } ------------------------------------------------ -- Scalars that relate to the adsl2SCStatusTable. ------------------------------------------------ adsl2ScalarSCMaxInterfaces OBJECT-TYPE Morgenstern, et al. Standards Track [Page 56] RFC 4706 ADSL2-LINE MIB November 2006 SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value determines the upper size of adsl2SCStatusTable. The maximum number of entries in adsl2SCStatusTable is equal to two times the value of this attribute." ::= { adsl2ScalarSC 1 } adsl2ScalarSCAvailInterfaces OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value determines the amount of space that is currently available in adsl2SCStatusTable. The number of entries available in adsl2SCStatusTable is equal to two times the value of this attribute." ::= { adsl2ScalarSC 2 } ------------------------------------------------ -- adsl2SCStatusTable -- ------------------------------------------------ adsl2SCStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF Adsl2SCStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table adsl2SCStatusTable contains status parameters of the ADSL2 sub-carriers. The following points apply to this table: 1. The main purpose of this table is to hold the results of a DELT. 2. This table also holds parameters obtained at line initialization time. 3. The rows in this table are volatile; that is, they are lost if the SNMP agent is rebooted. 4. Due to the large OCTET STRING attributes in this table, the worst case memory requirements for this table are very high. The manager may use the row status attribute of this table to delete rows in order to reclaim memory. 5. The manager may create rows in this table. The SNMP agent may create rows in this table. Only the manager may delete rows in this table. 6. The maximum number of rows allowable in this table is indicated by the scalar attribute adsl2ScalarSCMaxInterfaces. Morgenstern, et al. Standards Track [Page 57] RFC 4706 ADSL2-LINE MIB November 2006 The number of rows available in this table is indicated by the scalar attribute adsl2ScalarSCAvailInterfaces. 7. The SNMP agent is permitted to create rows in this table when a DELT completes successfully or when line initialization occurs. It is not mandatory for the SNMP agent to create rows in this table; hence, it may be necessary for the manager to create rows in this table before any results can be stored. 8. If the manager attempts to create a row in this table and there are no more rows available, the creation attempt will fail, and the response to the SNMP SET PDU will contain the error noCreation(11). 9. If the SNMP agent attempts to create a row in this table and there are no more rows available, the creation attempt will fail, and the attribute adsl2LineCmndConfLdsfFailReason will indicate the reason for the failure. The failure reason will be either tableFull(10) or noResources(11). 10. An example of use of this table is as follows: Step 1. : The DELT is started by setting the : adsl2LineCmndConfLdsf from inhibit to force. Step 2. : The DELT completes, and valid data is : available. Step 3. : The row in the adsl2SCStatusTable where the : results will be stored does not yet exist so : the SNMP agent attempts to create the row. Step 4. : Due to a low memory condition, a row in the : adsl2SCStatusTable table cannot be created at : this time. Step 5. : The reason for the failure, tableFull(10), is : indicated in the adsl2LineCmndConfLdsfFailReason : attribute. 11. Another example of use of this table is as follows : Step 1. : The DELT is started by setting the : adsl2LineCmndConfLdsf from inhibit to force. Step 2. : The DELT completes and valid data is : available. Step 3. : The row in the adsl2SCStatusTable where the : results will be stored does not yet exist so : the SNMP agent attempts to create the row. Step 4. : The row creation is successful. Step 5. : The value of the attribute : adsl2LineCmndConfLdsfFailReasonreason is set : to success(2). 12. Another example of use of this table is as follows: Step 1. : The manager creates a row in adsl2SCStatusTable : for a particular ADSL2 line. Step 2. : The DELT is started on the above-mentioned Morgenstern, et al. Standards Track [Page 58] RFC 4706 ADSL2-LINE MIB November 2006 : line by setting the adsl2LineCmndConfLdsf from : inhibit to force. Step 3. : The DELT completes, and valid data is : available. Step 4. : The value of the attribute : adsl2LineCmndConfLdsfFailReasonreason is set : to success(2)." ::= { adsl2Status 2 } adsl2SCStatusEntry OBJECT-TYPE SYNTAX Adsl2SCStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table Adsl2SCStatusEntry contains status parameters of the ADSL2 sub-carriers. The index of this table is an interface index where the interface has an ifType of adsl2plus(238)." INDEX { ifIndex, adsl2SCStatusDirection } ::= { adsl2SCStatusTable 1 } Adsl2SCStatusEntry ::= SEQUENCE { adsl2SCStatusDirection Adsl2Direction, adsl2SCStatusMtime Unsigned32, adsl2SCStatusSnr OCTET STRING, adsl2SCStatusBitsAlloc OCTET STRING, adsl2SCStatusGainAlloc OCTET STRING, adsl2SCStatusTssi Adsl2Tssi, adsl2SCStatusLinScale Unsigned32, adsl2SCStatusLinReal OCTET STRING, adsl2SCStatusLinImg OCTET STRING, adsl2SCStatusLogMt Unsigned32, adsl2SCStatusLog OCTET STRING, adsl2SCStatusQlnMt Unsigned32, adsl2SCStatusQln OCTET STRING, adsl2SCStatusLnAtten Unsigned32, adsl2SCStatusSigAtten Unsigned32, adsl2SCStatusSnrMargin Integer32, adsl2SCStatusAttainableRate Unsigned32, adsl2SCStatusActAtp Integer32, adsl2SCStatusRowStatus RowStatus } adsl2SCStatusDirection OBJECT-TYPE SYNTAX Adsl2Direction MAX-ACCESS not-accessible STATUS current Morgenstern, et al. Standards Track [Page 59] RFC 4706 ADSL2-LINE MIB November 2006 DESCRIPTION "The direction of the sub-carrier is either upstream or downstream." ::= { adsl2SCStatusEntry 1 } adsl2SCStatusMtime OBJECT-TYPE SYNTAX Unsigned32 UNITS "symbols" MAX-ACCESS read-only STATUS current DESCRIPTION "SNR Measurement Time. The number of symbols used to measure the SNR values on the respective transmission direction. It should correspond to the value specified in the recommendation (e.g., the number of symbols in 1 second time interval for G.992.3). This parameter corresponds to 1 second in loop diagnostic procedure and should be updated otherwise." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.20.1 (SNRMTds) and paragraph 7.5.1.20.3 (SNRMTus)" ::= { adsl2SCStatusEntry 2 } adsl2SCStatusSnr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..512)) MAX-ACCESS read-only STATUS current DESCRIPTION "The SNR Margin per sub-carrier, expressing the ratio between the received signal power and received noise power per subscriber. It is an array of 512 octets, designed for supporting up to 512 (downstream) sub-carriers. The number of utilized octets on downstream direction depends on NSCds, and on upstream direction it depends on NSCus. This value is referred to here as NSC. Octet i (0 <= i < NSC) is set to a value in the range 0 to 254 to indicate that the respective downstream or upstream sub- carrier i has SNR of: (-32 + Adsl2SubcarrierSnr(i)/2) in dB (i.e., -32 to 95dB). The special value 255 means that no measurement could be done for the subcarrier because it is out of the PSD mask passband or that the noise PSD is out of range to be represented. Each value in this array is 8 bits wide." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.20.2 (SNRpsds) and paragraph 7.5.1.20.4 (SNRpsus)" ::= { adsl2SCStatusEntry 3 } adsl2SCStatusBitsAlloc OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..256)) Morgenstern, et al. Standards Track [Page 60] RFC 4706 ADSL2-LINE MIB November 2006 UNITS "bits" MAX-ACCESS read-only STATUS current DESCRIPTION "The bits allocation per sub-carrier. An array of 256 octets (512 nibbles), designed for supporting up to 512 (downstream) sub-carriers. The number of utilized nibbles on downstream direction depends on NSCds, and on upstream direction it depends on NSCus. This value is referred to here as NSC. Nibble i (0 <= i < NSC) is set to a value in the range 0 to 15 to indicate that the respective downstream or upstream sub-carrier i has the same amount of bits allocation." REFERENCE "ITU-T G.997.1, paragraph 7.5.1.21.1 (BITSpsds) and paragraph 7.5.1.21.2 (BITSpsus)" ::= { adsl2SCStatusEntry 4 } adsl2SCStatusGainAlloc OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..1024)) MAX-ACCESS read-only STATUS current DESCRIPTION "The gain allocation per sub-carrier. An array of 512 16-bits values, designed for supporting up to 512 (downstream) sub- carriers. The number of utilized octets on downstream direction depends on NSCds, and on upstream direction it depends on NSCus. This value is referred to here as NSC. Value i (0 <= i < NSC) is in the range 0 to 4093 to indicate that the respective downstream or upstream sub-carrier i has the same amount of gain value.