tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4706

Proposed STD
Pages: 167
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ADSLMIB

Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2)

Part 1 of 7, p. 1 to 25
None       Next RFC Part

 


Top       ToC       Page 1 
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.

Top       Page 2 
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

Top      ToC       Page 3 
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.

Top      ToC       Page 4 
   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.

Top      ToC       Page 5 
   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.

Top      ToC       Page 6 
      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

Top      ToC       Page 7 
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.

Top      ToC       Page 8 
         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).

Top      ToC       Page 9 
         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.

Top      ToC       Page 10 
         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.

Top      ToC       Page 11 
   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.

Top      ToC       Page 12 
      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.

Top      ToC       Page 13 
      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:

Top      ToC       Page 14 
         - 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

Top      ToC       Page 15 
         - 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

Top      ToC       Page 16 
         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

Top      ToC       Page 17 
         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.

Top      ToC       Page 18 
       <-- Network Side                            Customer Side -->

       |<//////////////// ADSL/ADSL2/ADSL2+ Span /////////////////>|

       +-------+                                           +-------+
       +       |<---------------------1------------------->|       +
       +       |<---------------------2------------------->|       +
       | ATU-C <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| ATU-R |
       +       |<---------------------3------------------->|       +
       +       |<---------------------4------------------->|       +
       +-------+                                           +-------+

       Key:  <////> ADSL/ADSL2/ADSL2+ Span
             <~~~~> ADSL/ADSL2/ADSL2+ twisted-pair
             -1-    Channel #1 carried over the line
             -2-    Optional channel #2 carried over the line
             -3-    Optional channel #3 carried over the line
             -4-    Optional channel #4 carried over the line

   Figure 2: General topology for an ADSL/ADSL2/ADSL2+ 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.

Top      ToC       Page 19 
   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:

Top      ToC       Page 20 
   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.

Top      ToC       Page 21 
   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.

Top      ToC       Page 22 
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.

Top      ToC       Page 23 
   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.

Top      ToC       Page 24 
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-

Top      ToC       Page 25 
   limited, they are dropped and not queued for sending at a future
   time.  This is intended to be a general rate-limiting statement for
   notifications that otherwise have no explicit rate-limiting
   assertions in this document.

   Note that the Network Management System, or NMS, may receive a
   linkDown notification, as well, if enabled (via
   ifLinkUpDownTrapEnable [RFC2863]).  At the beginning of the next 15
   minute interval, the counter is reset.  When the first second goes by
   and the event occurs, the current interval bucket will be 1, which
   equals the threshold, and the notification will be sent again.



(page 25 continued on part 2)

Next RFC Part