tech-invite   World Map     

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

RFC 3728

 Errata 
Proposed STD
Pages: 76
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 Lines (VDSL)

Part 1 of 4, p. 1 to 11
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                             B. Ray
Request for Comments: 3728                        PESA Switching Systems
Category: Standards Track                                        R. Abbi
                                                                 Alcatel
                                                           February 2004


              Definitions of Managed Objects for Very High
                 Speed Digital Subscriber Lines (VDSL)

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 (2004).  All Rights Reserved.

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 Very High Speed
   Digital Subscriber Line (VDSL) interfaces.

Table of Contents

   1.  The Internet-Standard Management Framework . . . . . . . . . .  2
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
       2.1.  Relationship of the VDSL Line MIB Module to other MIB
             Modules. . . . . . . . . . . . . . . . . . . . . . . . .  2
       2.2.  Conventions used in the MIB Module . . . . . . . . . . .  4
       2.3.  Structure. . . . . . . . . . . . . . . . . . . . . . . .  5
       2.4.  Counters, Interval Buckets and Thresholds. . . . . . . .  7
       2.5.  Profiles . . . . . . . . . . . . . . . . . . . . . . . .  8
       2.6.  Notifications. . . . . . . . . . . . . . . . . . . . . .  9
       2.7.  Persistence. . . . . . . . . . . . . . . . . . . . . . . 10
   3.  Conformance and Compliance . . . . . . . . . . . . . . . . . . 11
   4.  Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 71
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
       6.1.  Normative References . . . . . . . . . . . . . . . . . . 72
       6.2.  Informative References . . . . . . . . . . . . . . . . . 74
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 74

Top      ToC       Page 2 
   8.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 75
   9.  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 76

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

2.  Overview

   This document describes an SNMP MIB module for managing VDSL Lines.
   These definitions are based upon the specifications for VDSL as
   defined in T1E1, ETSI, and ITU documentation [T1E1311, T1E1011,
   T1E1013, ETSI2701, ETSI2702, ITU9931, ITU9971].

   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.

2.1.   Relationship of the VDSL Line MIB Module to other MIB Modules

   This section outlines the relationship of this MIB with other MIBs
   described in RFCs.  Specifically, IF-MIB as presented in RFC 2863
   [RFC2863] is discussed.

2.1.1.   General IF-MIB Integration (RFC 2863)

   The VDSL 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 ifType to VDSL:

Top      ToC       Page 3 
   IANAifType ::= TEXTUAL-CONVENTION
       ...

   SYNTAX INTEGER {
       ...
       vdsl(97), -- Very H-speed Digital Subscrib.  Loop
       ...
       }

   Additionally, a VDSL line may contain an optional fast channel and an
   optional interleaved channel which also integrate into RFC 2863
   [RFC2863].  The IANA has assigned the following ifTypes to these
   channels:

   IANAifType ::= TEXTUAL-CONVENTION
       ...
   SYNTAX INTEGER {
       ...
       interleave (124), -- Interleave channel
       fast (125),       -- Fast channel
       ...
       }

2.1.2.  Usage of ifTable

   The MIB branch identified by this ifType contains tables appropriate
   for this interface type.  Most tables extend the ifEntry table, and
   are indexed by ifIndex.  For interfaces in systems implementing this
   MIB, those table entries indexed by ifIndex MUST be persistent.

   The following attributes are part of the mandatory ifGeneral group in
   RFC 2863 [RFC2863], and are not duplicated in the VDSL Line MIB.

   ===================================================================
       ifIndex                  Interface index.

       ifDescr                  See interfaces MIB [RFC2863].

       ifType                   vdsl(97),
                                interleave(124), or
                                fast(125)

       ifSpeed                  Set as appropriate.

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

       ifAdminStatus            See interfaces MIB [RFC2863].

Top      ToC       Page 4 
       ifOperStatus             See interfaces MIB [RFC2863].

       ifLastChange             See interfaces MIB [RFC2863].

       ifName                   See interfaces MIB [RFC2863].

       ifHighSpeed              Set as appropriate.

       ifConnectorPresent       Set as appropriate.

       ifLinkUpDownTrapEnable   Default to enabled(1).

   ===================================================================
                   Figure 1: Use of ifTable Objects

   Section 2.3, below, describes the structure of this MIB in relation
   to ifEntry in greater detail.

2.2.  Conventions used in the MIB Module

2.2.1.  Naming Conventions

   A.  Vtuc -- (VTUC) transceiver at near (Central) end of line
   B.  Vtur -- (VTUR) transceiver at Remote end of line
   C.  Vtu  -- One of either Vtuc or Vtur
   D.  Curr -- Current
   E.  Prev -- Previous
   F.  Atn  -- Attenuation
   G.  ES   -- Errored Second
   H.  SES  -- Severely Errored Second
   I.  UAS  -- Unavailable Second
   J.  LCS  -- Line Code Specific
   K.  Lof  -- Loss of Frame
   L.  Lol  -- Loss of Link
   M.  Los  -- Loss of Signal
   N.  Lpr  -- Loss of Power
   O.  xxxs -- Sum of Seconds in which xxx has occured
               (e.g., xxx = Lof, Los, Lpr, Lol)
   P.  Max  -- Maximum
   Q.  Mgn  -- Margin
   R.  Min  -- Minimum
   S.  Psd  -- Power Spectral Density
   T.  Snr  -- Signal to Noise Ratio
   U.  Tx   -- Transmit
   V.  Blks -- Blocks

Top      ToC       Page 5 
2.2.2.  Textual Conventions

   The following textual conventions are defined to reflect the line
   topology in the MIB (further discussed in the following section) and
   to define the behavior of the statistics to be maintained by an
   agent.

   o    VdslLineCodingType :

   Attributes with this syntax identify the line coding used.  Specified
   as an INTEGER, the three values are:

   other(1)  -- none of the following
   mcm(2)    -- Multiple Carrier Modulation
   scm(3)    -- Single Carrier Modulation

   o    VdslLineEntity :

   Attributes with this syntax reference the two sides of a line.
   Specified as an INTEGER, the two values are:

   vtuc(1)  -- central site transceiver
   vtur(2)  -- remote site transceiver

2.3  Structure

   The MIB is structured into the following MIB groups:

   o   vdslGroup :

   This group supports all line code independent MIB objects found in
   this MIB.  The following tables contain objects permitted for ifType
   vdsl(97):

      - vdslLineTable
      - vdslPhysTable
      - vdslPerfDataTable
      - vdslPerfIntervalTable
      - vdslPerf1DayIntervalTable
      - vdslLineConfProfileTable
      - vdslLineAlarmConfProfileTable

Top      ToC       Page 6 
   The following tables contain objects permitted for ifTypes
   interleave(124) and (fast):

      - vdslChanTable
      - vdslChanPerfDataTable
      - vdslChanPerfIntervalTable
      - vdslChanPerf1DayIntervalTable

   Figure 2, below, displays the relationship of the tables in the
   vdslGroup to ifEntry (and each other):

     ifEntry(ifType=97)  ---> vdslLineTableEntry 1:(0 to 1)

     vdslLineTableEntry  ---> vdslPhysTableEntry 1:(0 to 2)
                         ---> vdslPerfDataEntry 1:(0 to 2)
                         ---> vdslLineConfProfileEntry 1:(0 to 1)
                         ---> vdslLineAlarmConfProfileEntry 1:(0 to 1)

     vdslPhysTableEntry  ---> vdslPerfIntervalEntry 1:(0 to 96)
                         ---> vdslPerf1DayIntervalEntry 1:(0 to 30)

     ifEntry(ifType=124) ---> vdslChanEntry 1:(0 to 2)
                         ---> vdslChanPerfDataEntry 1:(0 to 2)

     ifEntry(ifType=125) ---> vdslChanEntry 1:(0 to 2)
                         ---> vdslChanPerfDataEntry 1:(0 to 2)

     vdslChanEntry       ---> vdslchanPerfIntervalEntry 1:(0 to 96)
                         ---> vdslchan1DayPerfIntervalEntry 1:(0 to 30)

                   Figure 2: Table Relationships

   o   vdslNotificationGroup :

   This group contains definitions of VDSL line notifications.  Section
   2.6, below, presents greater detail on the notifications defined
   within the MIB module.

Top      ToC       Page 7 
2.3.1.  Line Topology

   A VDSL Line consists of two units - a Vtuc (the central transceiver
   unit) and a Vtur (the remote transceiver unit).

             <-- Network Side   Customer Side -->

             |<////////// VDSL Line ///////////>|

             +-------+                  +-------+
             |       |                  |       |
             | Vtuc  +------------------+  Vtur |
             |       |                  |       |
             +-------+                  +-------+

          Figure 3: General topology for a VDSL Line

2.4.  Counters, Interval Buckets and Thresholds

   For Loss of Frame (lof), Loss of Link (lol), Loss of Signal (los),
   and Loss of Power (lpr), Errored Seconds (ES), Severely Errored
   Seconds (SES), and Unavailable Seconds (UAS) there are event
   counters, current 15-minute, 0 to 96 15-minute history bucket(s), and
   0 to 30 1-day history bucket(s) of "interval-counters".  Each current
   15-minute event bucket has an associated threshold notification.

   Each of these counters uses the textual conventions defined in the
   HC-PerfHist-TC-MIB [RFC3705].  The HC-PerfHist-TC-MIB defines 64-bit
   versions of the textual conventions found in RFC 3593 [RFC3593].

   There is no requirement for an agent to ensure a fixed relationship
   between the start of a fifteen minute interval and any wall clock;
   however, some implementations may align the fifteen 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 a Vtu is reinitialized, only when the
   agent is reset or reinitialized (or under specific request outside
   the scope of this MIB module).

Top      ToC       Page 8 
2.5.  Profiles

   As a managed node can handle a large number of Vtus, (e.g., hundreds
   or perhaps thousands of lines), provisioning every parameter on every
   Vtu may become burdensome.  Moreover, most lines are provisioned
   identically with the same set of parameters.  To simplify the
   provisioning process, this MIB makes use of profiles.  A profile is a
   set of parameters that can be shared by multiple lines using the same
   configuration.

   The following profiles are used in this MIB module:

   o   Line Configuration Profiles - Line configuration profiles contain
       parameters for configuring VDSL lines.  They are defined in the
       vdslLineConfProfileTable.

   o   Alarm Configuration Profiles - These profiles contain parameters
       for configuring alarm thresholds for VDSL transceivers.  These
       profiles are defined in the vdslLineAlarmConfProfileTable.

   One or more lines may be configured to share parameters of a single
   profile by setting their vdslLineConfProfile objects to the value of
   this profile.  If a change is made to the profile, all lines that
   refer to it will be reconfigured to the changed parameters.  Before a
   profile can be deleted or taken out of service it must be first
   unreferenced from all associated lines.

   Implementations MUST provide a default profile with an index value of
   'DEFVAL' for each profile type.  The values of the associated
   parameters will be vendor specific unless otherwise indicated in this
   document.  Before a line's profiles have been set, these profiles
   will be automatically used by setting vdslLineConfProfile and
   vdslLineAlarmConfProfile to 'DEFVAL' where appropriate.  This default
   profile name, 'DEFVAL', is considered reserved in the context of
   profiles defined in this MIB module.

   Profiles are created, assigned, and deleted dynamically using the
   profile name and profile row status in each of the ten profile tables
   (nine line configuration tables and one alarm configuration table).

   Profile changes MUST take effect immediately.  These changes MAY
   result in a restart (hard reset or soft restart) of the units on the
   line.

Top      ToC       Page 9 
2.6.  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., VDSL
   line) is required.

   The notifications defined in this MIB are for initialization failure
   and for the threshold crossings associated with the following events:
   lof, lol, los, lpr, ES, SES, and UAS.  Each threshold has its own
   enable/threshold value.  When that value is 0, the notification is
   disabled.

   A linkDown notification MAY be generated whenever any of lof, lol,
   los, lpr, ES, SES, or UAS threshold crossing event (as defined in
   this MIB module) occurs.  The corresponding linkUp notification MAY
   be sent when all link failure conditions are cleared.

   The vdslPhysCurrStatus is a bitmask representing all outstanding
   error conditions associated with a particular VDSL transceiver.  Note
   that since status of remote transceivers is obtained via the EOC,
   this information may be unavailable for units that are unreachable
   via the 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 this object are
   defined.

   A threshold notification occurs whenever the corresponding current
   15-minute interval error counter becomes equal to, or exceeds the
   threshold value.  One notification may be sent per interval per
   interface.  Since the current 15-minute counters are 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.

   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.

Top      ToC       Page 10 
2.7.  Persistence

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

      - vdslLineConfProfile
      - vdslLineAlarmConfProfile
      - vdslLineConfProfileName
      - vdslLineConfDownRateMode
      - vdslLineConfUpRateMode
      - vdslLineConfDownMaxPwr
      - vdslLineConfUpMaxPwr
      - vdslLineConfDownMaxSnrMgn
      - vdslLineConfDownMinSnrMgn
      - vdslLineConfDownTargetSnrMgn
      - vdslLineConfUpMaxSnrMgn
      - vdslLineConfUpMinSnrMgn
      - vdslLineConfUpTargetSnrMgn
      - vdslLineConfDownFastMaxDataRate
      - vdslLineConfDownFastMinDataRate
      - vdslLineConfDownSlowMaxDataRate
      - vdslLineConfDownSlowMinDataRate
      - vdslLineConfUpFastMaxDataRate
      - vdslLineConfUpFastMinDataRate
      - vdslLineConfUpSlowMaxDataRate
      - vdslLineConfUpSlowMinDataRate
      - vdslLineConfDownRateRatio
      - vdslLineConfUpRateRatio
      - vdslLineConfDownMaxInterDelay
      - vdslLineConfUpMaxInterDelay
      - vdslLineConfDownPboControl
      - vdslLineConfUpPboControl
      - vdslLineConfDownPboLevel
      - vdslLineConfUpPboLevel
      - vdslLineConfDeploymentScenario
      - vdslLineConfAdslPresence
      - vdslLineConfApplicableStandard
      - vdslLineConfBandPlan
      - vdslLineConfBandPlanFx
      - vdslLineConfBandOptUsage
      - vdslLineConfUpPsdTemplate
      - vdslLineConfDownPsdTemplate
      - vdslLineConfHamBandMask
      - vdslLineConfCustomNotch1Start
      - vdslLineConfCustomNotch1Stop
      - vdslLineConfCustomNotch2Start
      - vdslLineConfCustomNotch2Stop

Top      ToC       Page 11 
      - vdslLineConfDownTargetSlowBurst
      - vdslLineConfUpTargetSlowBurst
      - vdslLineConfDownMaxFastFec
      - vdslLineConfUpMaxFastFec
      - vdslLineConfLineType
      - vdslLineConfProfRowStatus
      - vdslLineAlarmConfProfileName
      - vdslLineAlarmConfThresh15MinLofs
      - vdslLineAlarmConfThresh15MinLoss
      - vdslLineAlarmConfThresh15MinLprs
      - vdslLineAlarmConfThresh15MinLols
      - vdslLineAlarmConfThresh15MinESs
      - vdslLineAlarmConfThresh15MinSESs
      - vdslLineAlarmConfThresh15MinUASs
      - vdslLineAlarmConfInitFailure
      - vdslLineAlarmConfProfRowStatus

   It should also be noted that interface indices in this MIB are
   maintained persistently.  VACM data relating to these SHOULD be
   stored persistently as well [RFC3415].

3.  Conformance and Compliance

   For VDSL lines, the following groups are mandatory:

      -  vdslGroup
      -  vdslNotificationGroup



(page 11 continued on part 2)

Next RFC Part