tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5650

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

Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)

Part 1 of 10, p. 1 to 24
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                     M. Morgenstern
Request for Comments: 5650                              ECI Telecom Ltd.
Category: Standards Track                                     S. Baillie
                                                              U. Bonollo
                                                           NEC Australia
                                                          September 2009


                   Definitions of Managed Objects for
           Very High Speed Digital Subscriber Line 2 (VDSL2)

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
   "Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type,
   which are also applicable for managing Asymmetric Digital Subscriber
   Line (ADSL), ADSL2, and ADSL2+ interfaces.

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 and License Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

Top       Page 2 
Table of Contents

   1. The Internet-Standard Management Framework ......................2
   2. Overview ........................................................2
      2.1. Relationship to Other MIBs .................................4
      2.2. IANA Considerations ........................................7
      2.3. Conventions Used in the MIB Module .........................7
      2.4. Structure .................................................11
      2.5. Persistence ...............................................13
      2.6. Line Topology .............................................16
      2.7. Counters, Interval Buckets, and Thresholds ................17
      2.8. Profiles ..................................................19
      2.9. Notifications .............................................23
   3. Definitions ....................................................24
   4. Implementation Analysis .......................................204
   5. Security Considerations .......................................204
   6. Acknowledgments ...............................................215
   7. References ....................................................216
      7.1. Normative References .....................................216
      7.2. Informative References ...................................217

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].

   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.  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 VDSL2, ADSL, ADSL2, and ADSL2+ lines.

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

   The MIB module described in RFC 4706 [RFC4706] is a wider management
   model that includes, in addition to ADSL technology, 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).

   This document does not obsolete RFC 2662 [RFC2662] or RFC 4706
   [RFC4706], but rather provides a more comprehensive management model
   that addresses the VDSL2 technology per G.993.2 ([G.993.2]) as well
   as ADSL, ADSL2, and ADSL2+ technologies.

   This document does not obsolete RFC 2662 [RFC2662] or RFC 4706
   [RFC4706].  RFC 2662 is relevant only for managing modems that do not
   support any DSL technology other than ADSL (e.g., G.992.1 [G.992.1]
   and G.992.2 [G.992.2]) especially if the modems were produced prior
   to approval of ITU-T G.997.1 standard revision 3 [G.997.1].  RFC 4706
   is more appropriate for managing modems that support ADSL2 technology
   variants (with or without being able to support the legacy ADSL).
   This document supports all ADSL, ADSL2, and VDSL2 standards, but it
   assumes a more sophisticated management model, which older modems
   (even ADSL2 ones) may not be able to support.  The selection of the
   appropriate MIB module for any DSL modem is based on the ifType value
   it reports, as explained in the next section.

   The management framework for VDSL2 lines [TR-129] specified by the
   Digital Subscriber Line Forum (DSLF) has been taken into
   consideration.  That framework is based on the ITU-T G.997.1 standard
   [G.997.1] and its amendment 1 [G.997.1-Am1].

   Note that the management model, according to this document, does not
   allow managing VDSL technology per G.993.1 [G.993.1].  VDSL lines
   MUST be managed by RFC 3728 [RFC3728].

   The MIB module is located in the MIB tree under MIB 2 transmission,
   as discussed in the MIB-2 Integration (RFC 2863 [RFC2863]) section of
   this document.

Top      ToC       Page 4 
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 defined in
   RFC 2863 [RFC2863] and ENTITY-MIB as defined in RFC 4133 [RFC4133]
   are discussed.

2.1.1.  Relationship with IF-MIB (RFC 2863)

2.1.1.1.  General IF-MIB Integration

   The VDSL2 Line MIB specifies the detailed objects 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 VDSL2 lines as well as for ADSL, ADSL2, and ADSL2+ 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
       vdsl2(251),      -- Very High Speed Digital Subscriber Loop 2
       ...
       }

   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 RFC 4706 [RFC4706].  VDSL2, ADSL, ADSL2, and ADSL2+
   lines identified with ifType=vdsl2(251) MUST be managed with the MIB
   specified by this document.

   In any case, the SNMP agent may use either ifType=interleave(124) or
   fast(125) for each channel, e.g., depending on whether or not it is
   capable of using an interleaver on that channel.  It may use the
   ifType=channel (70) when all channels are capable of using an
   interleaver (e.g., for ADSL2 xTUs).

   Note that the ifFixedLengthGroup from RFC 2863 [RFC2863] MUST be
   supported and that the ifRcvAddressGroup does not apply to this MIB
   module.

Top      ToC       Page 5 
2.1.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 objects are part of the mandatory
   ifGeneralInformationGroup in the Interfaces MIB [RFC2863], and are
   not duplicated in the VDSL2 Line MIB.

      ifIndex                  Interface index.

      ifDescr                  See interfaces MIB.

      ifType                   vdsl2(251), channel(70),
                               interleave(124), or fast(125)

      ifSpeed                  Set as appropriate.

      ifPhysAddress            This object MUST have an octet
                               string with zero length.

      ifAdminStatus            See interfaces MIB.

      ifOperStatus             See interfaces MIB.

      ifLastChange             See interfaces MIB.

      ifName                   See interfaces MIB.

      ifAlias                  See interfaces MIB.

      ifLinkUpDownTrapEnable   Default to enabled(1).

      ifHighSpeed              Set as appropriate.

      ifConnectorPresent       Set as appropriate.
   -------------------------------------------------------------------
                     Figure 1: Use of ifTable Objects

2.1.1.3.  Usage of ifStackTable

   Use of the ifStackTable to associate the entries for physical, fast,
   interleaved channels, and higher layers (e.g., ATM) is shown below.
   Use of the ifStackTable is necessary because configuration
   information is stored in profile tables associated with the physical-

Top      ToC       Page 6 
   layer ifEntry only.  The channels' ifEntrys need the ifStackTable to
   find their associated physical-layer entry and thus their
   configuration parameters.  The following example shows the
   ifStackTable entries for an xDSL line with a single channel that uses
   an ATM data path.

                       HigherLayer      LowerLayer
                       -----------------------------
                            0               ATM
                           ATM           XdslChannel
                        XdslChannel      XdslPhysical
                        XdslPhysical         0

   Figure 2: ifStackTable Entries for ATM Path over a Single xDSL
   Channel

2.1.2.  Relationship with the ENTITY-MIB (RFC 4133)

   Implementation of the Entity MIB [RFC4133] is optional.  It in no way
   alters the information required in the VDSL2 Line MIB, nor does it
   alter the relationship with IF-MIB.

   The Entity MIB introduces a standardized way of presenting the
   components of complex systems, such as a Digital Subscriber Line
   Access Multiplexer (DSLAM), that may contain multiple racks, shelves,
   line cards, and/or ports.  The Entity MIB's main goal is to present
   these system components, their containment relationship, and mapping
   information with other MIBs such as the Interface MIB and the VDSL2
   Line MIB.

   The Entity MIB is capable of supporting the local DSL termination
   unit.  Thus, assuming the SNMP agent is in the DSLAM, the Entity MIB
   should include entities for the xTU-C in the entPhysicalTable.  The
   MIB's entAliasMappingTable would contain mapping information
   identifying the 'ifIndex' object associated with each xTU-C.  In case
   the SNMP agent is actually in the Customer Premise Equipment (CPE),
   the Entity MIB should include entities for the xTU-R in the
   entPhysicalTable.  In this case, the MIB's entAliasMappingTable would
   contain mapping information identifying the 'ifIndex' object
   associated with each xTU-R.

   Also associating the relationship between the ifTable and Entity MIB,
   the entPhysicalTable contains an 'entPhysicalName' object, which
   approximates the semantics of the 'ifName' object from the Interface
   MIB.

Top      ToC       Page 7 
2.2.  IANA Considerations

   A new ifType value (251) for Very High Speed Digital Subscriber Loop
   Version 2 has been allocated for the VDSL2-LINE-MIB module, to
   distinguish between ADSL lines that are managed with the RFC 2662
   management model, ADSL/ADSL2 and ADSL2+ lines that are managed with
   the RFC 4706 [RFC4706] management model, and VDSL2/ADSL/ADSL2 and
   ADSL2+ lines that are managed with the model defined in this
   document.

   Also, the VDSL2-LINE-MIB module has been assigned a single object
   identifier (251) for its MODULE-IDENTITY.  The IANA has allocated
   this object identifier in the transmission subtree.

   As performed in the past for the ADSL2-LINE-MIB module, the IANA has
   ensured that the allocated ifType value is the same as the allocated
   branch number in the transmission subtree.

2.3.  Conventions Used in the MIB Module

2.3.1.  Naming Conventions

    ADSL   Asymmetric (bit rate) DSL
    ATM    Asynchronous Transfer Mode
    atuc   ADSL/ADSL2 or ADSL2+ line termination unit -
           central office
    atur   ADSL/ADSL2 or ADSL2+ line termination unit -
           Remote site
    BER    Bit Error Rate
    CO     Central Office
    CPE    Customer Premise Equipment
    CRC    Cyclic Redundancy Check
    DELT   Dual Ended Loop Test
    DMT    Discrete Multitone
    DPBO   Downstream PBO
    DRA    Dynamic Rate Adaptation
    DSL    Digital Subscriber Line/Loop
    DSLF   DSL Forum
    EOC    Embedded Operations Channel
    ES     Errored Second
    FE     Far-End (unit)
    FEBE   Far-End Block Error
    FEC    Forward Error Correction
    FFEC   Far-End FEC
    IMA    Inverse Multiplexing over ATM
    INP    Impulse Noise Protection
    ISDN   Integrated Services Digital Network
    LDSF   Loop Diagnostic State Forced

Top      ToC       Page 8 
    LOF    Loss Of Frame
    LOS    Loss Of Signal
    LOSS   LOS Seconds
    LPR    Loss of Power
    NE     Network Element or Near-End (unit)
    NSC    Highest transmittable subcarriers index
    NSCds  NSC for downstream transmission direction
    NSCus  NSC for upstream transmission direction
    OLR    Online Reconfiguration
    PBO    Power Backoff
    PM     Performance Monitoring
    PMS-TC Physical Media Specific-Transmission Convergence
    POTS   Plain Old Telephone Service
    PSD    Power Spectral Density
    PTM    Packet Transfer Mode
    QLN    Quiet Line
    RDI    Remote Defect Indication
    RFI    Radio Frequency Interference
    SEF    Severely Errored Frame
    SES    Severely Errored Second
    SNR    Signal-to-Noise Ratio
    TC     Transmission Convergence (e.g., ATM sub layer)
    TCM    (TCM-ISDN) Time Compression Multiplexed ISDN
    UAS    Unavailable Seconds
    U-C    Loop interface-central office end
    UPBO   Upstream PBO
    U-R    Loop interface-remote side (i.e., subscriber end of the loop)
    US0    Upstream band number 0
    VDSL   Very high speed DSL
    VTU-O  VDSL2 Transceiver Unit - central office or
           Network Element End
    VTU-R  VTU at the remote site (i.e., subscriber end of the loop)
    vtuc   VDSL2 line termination unit - central office
    vtur   VDSL2 line termination unit - Remote site
    xDSL   Either VDSL2, ADSL, ADSL2 or ADSL2+
    xTU-C  ADSL/ADSL2/ADSL2+ or VDSL2 line termination unit -
           central office
    xTU-R  ADSL/ADSL2/ADSL2+ or VDSL2 line termination unit -
           Remote site
    xTU    A line termination unit; either an xTU-C or xTU-R

Top      ToC       Page 9 
2.3.2.  Textual Conventions

   The following lists the textual conventions defined by VDSL2-LINE-TC-
   MIB in this document:

   o  Xdsl2Unit

   o  Xdsl2Direction

   o  Xdsl2Band

   o  Xdsl2TransmissionModeType

   o  Xdsl2RaMode

   o  Xdsl2InitResult

   o  Xdsl2OperationModes

   o  Xdsl2PowerMngState

   o  Xdsl2ConfPmsForce

   o  Xdsl2LinePmMode

   o  Xdsl2LineLdsf

   o  Xdsl2LdsfResult

   o  Xdsl2LineBpsc

   o  Xdsl2BpscResult

   o  Xdsl2LineReset

   o  Xdsl2LineProfiles

   o  Xdsl2LineClassMask

   o  Xdsl2LineLimitMask

   o  Xdsl2LineUs0Disable

   o  Xdsl2LineUs0Mask

   o  Xdsl2SymbolProtection

   o  Xdsl2SymbolProtection8

Top      ToC       Page 10 
   o  Xdsl2MaxBer

   o  Xdsl2ChInitPolicy

   o  Xdsl2ScMaskDs

   o  Xdsl2ScMaskUs

   o  Xdsl2CarMask

   o  Xdsl2RfiBands

   o  Xdsl2PsdMaskDs

   o  Xdsl2PsdMaskUs

   o  Xdsl2Tssi

   o  Xdsl2LastTransmittedState

   o  Xdsl2LineStatus

   o  Xdsl2ChInpReport

   o  Xdsl2ChAtmStatus

   o  Xdsl2ChPtmStatus

   o  Xdsl2UpboKLF

   o  Xdsl2BandUs

   o  Xdsl2LinePsdMaskSelectUs

   o  Xdsl2LineCeFlag

   o  Xdsl2LineSnrMode

   o  Xdsl2LineTxRefVnDs

   o  Xdsl2LineTxRefVnUs

   o  Xdsl2BitsAlloc

   o  Xdsl2MrefPsdDs

   o  Xdsl2MrefPsdUs

Top      ToC       Page 11 
2.4.  Structure

   The MIB module is structured into the following MIB groups:

   o  Line Configuration, Maintenance, and Status Group:

      This group supports MIB objects for configuring parameters for the
      VDSL2/ADSL/ADSL2 or ADSL2+ line and retrieving line status
      information.  It also supports MIB objects for configuring a
      requested power state or initiating a Dual Ended Loop Test (DELT)
      process in the VDSL2/ADSL/ADSL2 or ADSL2+ line.  It contains the
      following tables:

         - xdsl2LineTable
         - xdsl2LineSegmentTable
         - xdsl2LineBandTable

   o  Channel Status Group:

      This group supports MIB objects for retrieving channel layer
      status information.  It contains the following table:

         - xdsl2ChannelStatusTable

   o  Subcarrier Status Group:

      This group supports MIB objects for retrieving the subcarrier
      layer status information, mostly collected by a Dual Ended Loop
      Test (DELT) process.  It contains the following tables:

         - xdsl2SCStatusTable
         - xdsl2SCStatusBandTable
         - xdsl2SCStatusSegmentTable

   o  Unit Inventory Group:

      This group supports MIB objects for retrieving Unit inventory
      information about units in VDSL2/ADSL/ADSL2 or ADSL2+ lines via
      the EOC.  It contains the following table:

         - xdsl2LineInventoryTable

   o  Current Performance Group:

      This group supports MIB objects that provide the current
      performance information relating to VDSL2/ADSL/ADSL2 and ADSL2+
      line, unit, and channel levels.  It contains the following tables:

Top      ToC       Page 12 
         - xdsl2PMLineCurrTable
         - xdsl2PMLineInitCurrTable
         - xdsl2PMChCurrTable

   o  15-Minute Interval Performance Group:

      This group supports MIB objects that provide historic performance
      information relating to VDSL2/ADSL/ADSL2 and ADSL2+ line, unit,
      and channel levels in 15-minute intervals.  It contains the
      following tables:

         - xdsl2PMLineHist15MinTable
         - xdsl2PMLineInitHist15MinTable
         - xdsl2PMChHist15MinTable

   o  1-Day Interval Performance Group:

      This group supports MIB objects that provide historic performance
      information relating to VDSL2/ADSL/ADSL2 and ADSL2+ line, unit,
      and channel levels in 1-day intervals.  It contains the following
      tables:

         - xdsl2PMLineHist1DayTable
         - xdsl2PMLineInitHist1DayTable
         - xdsl2PMChHist1DTable

   o  Configuration Template and Profile Group:

      This group supports MIB objects for defining configuration
      profiles for VDSL2/ADSL/ADSL2 and ADSL2+ lines and channels, as
      well as configuration templates.  Each configuration template is
      comprised of a one-line configuration profile and one or more
      channel configuration profiles.  This group contains the following
      tables:

         - xdsl2LineConfTemplateTable
         - xdsl2LineConfProfTable
         - xdsl2LineConfProfModeSpecTable
         - xdsl2LineConfProfModeSpecBandUsTable
         - xdsl2ChConfProfileTable

   o  Alarm Configuration Template and Profile Group:

      This group supports MIB objects for defining alarm profiles for
      VDSL2/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:

Top      ToC       Page 13 
         - xdsl2LineAlarmConfTemplateTable
         - xdsl2LineAlarmConfProfileTable
         - xdsl2ChAlarmConfProfileTable

   o  Notifications Group:

      This group defines the notifications supported for VDSL2/ADSL/
      ADSL2 and ADSL2+ lines:

         - xdsl2LinePerfFECSThreshXtuc
         - xdsl2LinePerfFECSThreshXtur
         - xdsl2LinePerfESThreshXtuc
         - xdsl2LinePerfESThreshXtur
         - xdsl2LinePerfSESThreshXtuc
         - xdsl2LinePerfSESThreshXtur
         - xdsl2LinePerfLOSSThreshXtuc
         - xdsl2LinePerfLOSSThreshXtur
         - xdsl2LinePerfUASThreshXtuc
         - xdsl2LinePerfUASThreshXtur
         - xdsl2LinePerfCodingViolationsThreshXtuc
         - xdsl2LinePerfCodingViolationsThreshXtur
         - xdsl2LinePerfCorrectedThreshXtuc
         - xdsl2LinePerfCorrectedThreshXtur
         - xdsl2LinePerfFailedFullInitThresh
         - xdsl2LinePerfFailedShortInitThresh
         - xdsl2LineStatusChangeXtuc
         - xdsl2LineStatusChangeXtur

2.5.  Persistence

   All read-create objects and most read-write objects defined in this
   MIB module SHOULD be stored persistently.  The following is an
   exhaustive list of these persistent objects:

         xdsl2LineConfTemplate
         xdsl2LineAlarmConfTemplate
         xdsl2LineCmndConfPmsf
         xdsl2LConfTempTemplateName
         xdsl2LConfTempLineProfile
         xdsl2LConfTempChan1ConfProfile
         xdsl2LConfTempChan1RaRatioDs
         xdsl2LConfTempChan1RaRatioUs
         xdsl2LConfTempChan2ConfProfile
         xdsl2LConfTempChan2RaRatioDs
         xdsl2LConfTempChan2RaRatioUs
         xdsl2LConfTempChan3ConfProfile
         xdsl2LConfTempChan3RaRatioDs
         xdsl2LConfTempChan3RaRatioUs

Top      ToC       Page 14 
         xdsl2LConfTempChan4ConfProfile
         xdsl2LConfTempChan4RaRatioDs
         xdsl2LConfTempChan4RaRatioUs
         xdsl2LConfTempRowStatus
         xdsl2LConfProfProfileName
         xdsl2LConfProfScMaskDs
         xdsl2LConfProfScMaskUs
         xdsl2LConfProfVdsl2CarMask
         xdsl2LConfProfRfiBandsDs
         xdsl2LConfProfRaModeDs
         xdsl2LConfProfRaModeUs
         xdsl2LConfProfRaUsNrmDs
         xdsl2LConfProfRaUsNrmUs
         xdsl2LConfProfRaUsTimeDs
         xdsl2LConfProfRaUsTimeUs
         xdsl2LConfProfRaDsNrmDs
         xdsl2LConfProfRaDsNrmUs
         xdsl2LConfProfRaDsTimeDs
         xdsl2LConfProfRaDsTimeUs
         xdsl2LConfProfTargetSnrmDs
         xdsl2LConfProfTargetSnrmUs
         xdsl2LConfProfMaxSnrmDs
         xdsl2LConfProfMaxSnrmUs
         xdsl2LConfProfMinSnrmDs
         xdsl2LConfProfMinSnrmUs
         xdsl2LConfProfMsgMinUs
         xdsl2LConfProfMsgMinDs
         xdsl2LConfProfXtuTransSysEna
         xdsl2LConfProfPmMode
         xdsl2LConfProfL0Time
         xdsl2LConfProfL2Time
         xdsl2LConfProfL2Atpr
         xdsl2LConfProfL2Atprt
         xdsl2LConfProfProfiles
         xdsl2LConfProfDpboEPsd
         xdsl2LConfProfDpboEsEL
         xdsl2LConfProfDpboEsCableModelA
         xdsl2LConfProfDpboEsCableModelB
         xdsl2LConfProfDpboEsCableModelC
         xdsl2LConfProfDpboMus
         xdsl2LConfProfDpboFMin
         xdsl2LConfProfDpboFMax
         xdsl2LConfProfUpboKL
         xdsl2LConfProfUpboKLF
         xdsl2LConfProfUs0Mask
         xdsl2LConfProfRowStatus
         xdsl2LConfProfXdslMode
         xdsl2LConfProfMaxNomPsdDs

Top      ToC       Page 15 
         xdsl2LConfProfMaxNomPsdUs
         xdsl2LConfProfMaxNomAtpDs
         xdsl2LConfProfMaxNomAtpUs
         xdsl2LConfProfMaxAggRxPwrUs
         xdsl2LConfProfPsdMaskDs
         xdsl2LConfProfPsdMaskUs
         xdsl2LConfProfPsdMaskSelectUs
         xdsl2LConfProfClassMask
         xdsl2LConfProfLimitMask
         xdsl2LConfProfUs0Disabl
         xdsl2LConfProfModeSpecRowStatus
         xdsl2LConfProfXdslBandUs
         xdsl2LConfProfUpboPsdA
         xdsl2LConfProfUpboPsdB
         xdsl2LConfProfModeSpecBandUsRowStatus
         xdsl2ChConfProfProfileName
         xdsl2ChConfProfMinDataRateDs
         xdsl2ChConfProfMinDataRateUs
         xdsl2ChConfProfMinResDataRateDs
         xdsl2ChConfProfMinResDataRateUs
         xdsl2ChConfProfMaxDataRateDs
         xdsl2ChConfProfMaxDataRateUs
         xdsl2ChConfProfMinDataRateLowPwrDs
         xdsl2ChConfProfMaxDelayDs
         xdsl2ChConfProfMaxDelayUs
         xdsl2ChConfProfMinProtectionDs
         xdsl2ChConfProfMinProtectionUs
         xdsl2ChConfProfMaxBerDs
         xdsl2ChConfProfMaxBerUs
         xdsl2ChConfProfUsDataRateDs
         xdsl2ChConfProfDsDataRateDs
         xdsl2ChConfProfUsDataRateUs
         xdsl2ChConfProfDsDataRateUs
         xdsl2ChConfProfImaEnabled
         xdsl2ChConfProfMaxDelayVar
         xdsl2ChConfProfInitPolicy
         xdsl2ChConfProfRowStatus
         xdsl2LAlarmConfTempTemplateName
         xdsl2LAlarmConfTempLineProfile
         xdsl2LAlarmConfTempChan1ConfProfile
         xdsl2LAlarmConfTempChan2ConfProfile
         xdsl2LAlarmConfTempChan3ConfProfile
         xdsl2LAlarmConfTempChan4ConfProfile
         xdsl2LAlarmConfTempRowStatus
         xdsl2LineAlarmConfProfileName
         xdsl2LineAlarmConfProfileXtucThresh15MinFecs
         xdsl2LineAlarmConfProfileXtucThresh15MinEs
         xdsl2LineAlarmConfProfileXtucThresh15MinSes

Top      ToC       Page 16 
         xdsl2LineAlarmConfProfileXtucThresh15MinLoss
         xdsl2LineAlarmConfProfileXtucThresh15MinUas
         xdsl2LineAlarmConfProfileXturThresh15MinFecs
         xdsl2LineAlarmConfProfileXturThresh15MinEs
         xdsl2LineAlarmConfProfileXturThresh15MinSes
         xdsl2LineAlarmConfProfileXturThresh15MinLoss
         xdsl2LineAlarmConfProfileXturThresh15MinUas
         xdsl2LineAlarmConfProfileThresh15MinFailedFullInt
         xdsl2LineAlarmConfProfileThresh15MinFailedShrtInt
         xdsl2LineAlarmConfProfileRowStatus
         xdsl2ChAlarmConfProfileName
         xdsl2ChAlarmConfProfileXtucThresh15MinCodingViolations
         xdsl2ChAlarmConfProfileXtucThresh15MinCorrected
         xdsl2ChAlarmConfProfileXturThresh15MinCodingViolations
         xdsl2ChAlarmConfProfileXturThresh15MinCorrected
         xdsl2ChAlarmConfProfileRowStatus

   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

   A VDSL2/ADSL/ADSL2 and ADSL2+ line consists of two units: atuc or
   vtuc (a central office termination unit) and atur or vtur (a remote
   termination unit).  There are up to 4 channels (maximum number of
   channels depends on the specific DSL technology), each carrying an
   independent information flow, as shown in the figure below.

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

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

       +-------+                                           +-------+
       |       |<---------------------1------------------->|       |
       | atuc  |<---------------------2------------------->|  atur |
       |  or   |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|   or  |
       | vtuc  |<---------------------3------------------->|  vtuc |
       |       |<---------------------4------------------->|       |
       +-------+                                           +-------+

       Key:  <////> VDSL2/ADSL/ADSL2/ADSL2+ Span
             <~~~~> VDSL2/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 3: General Topology for a VDSL2/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 VDSL2/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 for 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 18 
   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.9.

   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 1-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 19 
   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 declaring 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 module 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, in addition to 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 is a configuration profile to address line-
   level provisioning and another type of profile that addresses
   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 20 
   In a similar manner 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
      line-level parameters for configuring VDSL2/ADSL/ADSL2 and ADSL2+
      lines.  They are defined in the xdsl2LineConfProfTable.

      The line configuration includes settings such as the specific
      VDSL2/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 xDSL Mode allowed (i.e., does
      the profile allow VDSL2, 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 VDSL2/
      ADSL/ADSL2 and ADSL2+ lines.  They are sometimes considered as the
      service layer configuration of the VDSL2/ADSL/ADSL2 and ADSL2+
      lines.  They are defined in the xdsl2ChConfProfTable.

      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 into a comprehensive configuration of the VDSL2/ADSL/
      ADSL2 and ADSL2+ line.  They are defined in the
      xdsl2LineConfTemplateTable.

      The line configuration template includes one index of a line
      configuration profile and one to four indices of channel
      configuration profiles.  The template also addresses the issue of
      distributing the excess available data rate on each traffic flow

Top      ToC       Page 21 
      direction (i.e., the data rate left after each channel is
      allocated a data rate to satisfy its minimum requested data rate)
      among the various channels.

2.8.2.  Alarm Configuration Profiles and Templates

   o  Line Alarm Configuration Profiles - Line-level Alarm configuration
      profiles contain the threshold values for Performance Monitoring
      (PM) parameters, counted either on the whole line level or on an
      xTU level.  Thresholds are required only for failures and
      anomalies.  For example, there are thresholds for failed
      initializations and LOS seconds, but not for the aggregate number
      of full initializations.  These profiles are defined in the
      xdsl2LineAlarmConfProfileTable.

   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
      xdsl2ChAlarmConfProfileTable.

   o  Line Alarm Configuration Templates - Line Alarm configuration
      templates allow combining line-level alarm configuration profiles
      and channel-level alarm configuration profiles into a
      comprehensive configuration of the PM thresholds for the VDSL2/
      ADSL/ADSL2 and ADSL2+ line.  They are defined in the
      xdsl2LineAlarmConfTemplateTable.

      The line alarm configuration template includes one index of a
      line-level alarm configuration profile and one to four indices 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., xdsl2LConfTempTemplateName = 'silver')
   by setting its xdsl2LineConfTemplate object to the value of this
   template.

   One or more lines may be configured to share parameters of a single
   Alarm configuration template (e.g., xdsl2LAlarmConfTempTemplateName =
   'silver') by setting its xdsl2LineAlarmConfTemplate object to the
   value of this template.

Top      ToC       Page 22 
   Before a template can be deleted or taken out of service, it MUST be
   first unreferenced from all associated lines.  Implementations MAY
   also reject template modification while it is associated with any
   line.

   Before a profile can be deleted or taken out of service, it MUST be
   first 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 xdsl2LineConfTemplate and
   xdsl2LineAlarmConfTemplate 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.

   Network Elements MAY optionally implement a fallback line
   configuration template (see xdsl2LineConfFallbackTemplate).  The
   fallback template will be tried if the xDSL2 line fails to operate
   using the primary template.  If the xDSL2 line fails to operate using
   the fallback template, then the primary template should be retried.
   The xTU-C SHOULD continue to alternate between the primary and
   fallback templates until one of them succeeds.

2.8.4.  Managing Multiple Bearer Channels

   The number of bearer channels is configured by setting the template
   objects xdsl2LConfTempChan1ConfProfile,
   xdsl2LConfTempChan2ConfProfile, xdsl2LConfTempChan3ConfProfile, and
   xdsl2LConfTempChan4ConfProfile and then assigning that template to a
   DSL line using the xdsl2LineConfTemplate object.  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

Top      ToC       Page 23 
   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 xdsl2ChannelStatusTable and xdsl2PMChCurrTable 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 xdsl2ChannelStatusTable,
      xdsl2PMChCurrTable,xdsl2PMChHist15MinTable, and
      xdsl2PMChHist1DTable tables for that line.

2.9.  Notifications

   The ability to generate the SNMP notifications coldStart/WarmStart
   (per [RFC3418]), which are per agent (e.g., per Digital Subscriber
   Line Access Multiplexer, or DSLAM, in such a device), and linkUp/
   linkDown (per [RFC2863]), which are per interface (i.e., VDSL2/ADSL/
   ADSL2 or ADSL2+ line) is required.

   A linkDown notification MAY be generated whenever any of ES, SES, CRC
   anomaly, LOS, LOF, or UAS events occur.  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, 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 xdsl2LineStatusXtur and xdsl2LineStatusXtuc are bitmasks
   representing all outstanding error conditions associated with the
   xTU-R and xTU-C (respectively).  Note that since the xTU-R status is
   obtained via the EOC, this information may be unavailable in case the
   xTU-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.

Top      ToC       Page 24 
   Note that there are other status parameters that refer to the xTU-R
   (e.g., downstream line attenuation).  Those parameters also depend on
   the availability of EOC between the central office xTU and the remote
   xTU.

   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, and 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.

   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 24 continued on part 2)

Next RFC Part