Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3276

Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing

Pages: 66
Obsoleted by:  4319
Part 1 of 3 – Pages 1 to 14
None   None   Next

ToP   noToC   RFC3276 - Page 1
Network Working Group                                             B. Ray
Request for Comments: 3276                        PESA Switching Systems
Category: Standards Track                                        R. Abbi
                                                                 Alcatel
                                                                May 2002


 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation
         (HDSL2) and Single-Pair High-Speed Digital Subscriber
                           Line (SHDSL) Lines

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

Abstract

This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces.

Table of Contents

1. Introduction ............................................. 2 2. The SNMP Network Management Framework .................... 2 3. Introduction ............................................. 3 3.1 Relationship of the HDSL2/SHDSL Line MIB to other MIBs ... 3 3.2 IANA Considerations ...................................... 5 4. Conventions used in the MIB .............................. 5 4.1 Naming Conventions ....................................... 5 4.2 Textual Conventions ...................................... 6 4.3 Structure ................................................ 7 4.4 Counters, Interval Buckets and Thresholds ................ 10 4.5 Profiles ................................................. 11 4.6 Notifications ............................................ 12 5. Conformance and Compliance ............................... 14 6. Definitions .............................................. 14 7. Security Considerations .................................. 60
ToP   noToC   RFC3276 - Page 2
   8.   Acknowledgments .......................................... 62
   9.   References ............................................... 63
   10.  Intellectual Property Notice ............................. 65
   11.  Authors' Addresses ....................................... 65
   12.  Full Copyright Statement ................................. 66

1. Introduction

This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) [18] and Single- Pair High-Speed Digital Subscriber Line (SHDSL) interfaces [19].

2. The SNMP Management Framework

The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and is described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3], and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], RFC 2579 [6], and RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and is described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described is in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and is described in RFC 1906 [10], RFC 2572 [11], and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15].
ToP   noToC   RFC3276 - Page 3
   A more detailed introduction to the current SNMP Management Framework
   can be found in RFC 2570 [16].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2.  A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations.  The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (use of Counter64).  Some machine readable
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process.  However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB.

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

3. Introduction

This document describes an SNMP MIB for managing HDSL2/SHDSL Lines. These definitions are based upon the specifications for the HDSL2 and SHDSL Embedded Operations Channel (EOC) as defined in ANSI T1E1.4/2000-006 [18] and ITU G.991.2 [19]. The MIB is located in the MIB tree under MIB 2 transmission, as discussed in the MIB-2 Integration (RFC 1213 [20] and RFC 2863 [21]) section of this document.

3.1. Relationship of the HDSL2/SHDSL Line MIB to other MIBs

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

3.1.1 General IF-MIB Integration (RFC 2863)

The HDSL2/SHDSL Line MIB specifies the detailed attributes of a data interface. As such, it needs to integrate with RFC 2863 [21]. The IANA has assigned the following ifTypes to HDSL2 and SHDSL:
ToP   noToC   RFC3276 - Page 4
   IANAifType ::= TEXTUAL-CONVENTION
       ...
   SYNTAX INTEGER {
       ...
       hdsl2 (168), -- High Bit-Rate DSL, 2nd generation
       shdsl (169), -- Multirate HDSL2
       ...
       }

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

3.1.2 Usage of ifTable

The MIB branch identified by this ifType contains tables appropriate for this interface type. Most such 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 [21], and are not duplicated in the HDSL2/SHDSL Line MIB.
ToP   noToC   RFC3276 - Page 5
   ===================================================================
       ifIndex                  Interface index.

       ifDescr                  See interfaces MIB [21].

       ifType                   hdsl2(168) or shdsl(169).

       ifSpeed                  Set as appropriate.
                                (This is fixed at 1552000 for HDSL2
                                lines)

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

       ifAdminStatus            See interfaces MIB [21].

       ifOperStatus             See interfaces MIB [21].

       ifLastChange             See interfaces MIB [21].

       ifName                   See interfaces MIB [21].

       ifLinkUpDownTrapEnable   Default to enabled(1).

       ifHighSpeed              Set as appropriate.
                                (For HDSL2 lines, this is fixed at 2)

       ifConnectorPresent       Set as appropriate.

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

3.2 IANA Considerations

The HDSL2-SHDSL-LINE-MIB module requires the allocation of a single object identifier for its MODULE-IDENTITY. The IANA has allocated this object identifier in the transmission subtree (48), defined in the SNMPv2-SMI MIB module.

4. Conventions used in the MIB

4.1. Naming Conventions

A. xtuC refers to a central site terminal unit; H2TU-C for HDSL2, or STU-C for SHDSL. B. xtuR refers to a remote site terminal unit; H2TU-R for HDSL2, or STU-R for SHDSL. C. xtu refers to a terminal unit; either an xtuC or xtuR.
ToP   noToC   RFC3276 - Page 6
   D.  xru refer to a regenerator unit;
       H2RU for HDSL2, or SRU for SHDSL.
   E.  xU refers to any HDSL2/SHDSL unit; either an xtu or xru.
   F.  CRC is cyclic redundancy check [19].
   G.  ES means errored second [19].
   H.  LOSW means loss of sync word [19].
   I.  LOSWS means LOSW seconds [19].
   J.  SES means severely errored second [19].
   K.  SNR means signal-to-noise ratio [19].
   L.  UAS means unavailable second [19].

4.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 Hdsl2ShdslUnitId: Attributes with this syntax uniquely identify each unit in a HDSL2/SHDSL span. It mirrors the EOC addressing mechanism: xtuC(1) - CO terminal unit xtuR(2) - CPE terminal unit xru1(3) .. xru8(10) - regenerators, numbered from central office side o Hdsl2ShdslUnitSide: Attributes with this syntax reference the two sides of a unit: networkSide(1) - N in figure 2, below customerSide(2) - C in figure 2, below o Hdsl2ShdslWirePair: Attributes with this syntax reference the wire-pairs connecting the units: wirePair1(1) - First pair for HDSL2/SHDSL. wirePair2(2) - Optional second pair for SHDSL only. o Hdsl2ShdslTransmissionModeType: Attributes with this syntax specify the regional setting for a SHDSL line. Specified as a BITS construct, the two mode types are:
ToP   noToC   RFC3276 - Page 7
   region1   - ITU-T G.991.2 Annex A
   region2   - ITU-T G.991.2 Annex B

   o   Hdsl2ShdslPerfCurrDayCount:

   Attributes with this syntax define the behavior of the 1-day (24
   hour) gauges found in the MIB.

   o   Hdsl2Shdsl1DayIntervalCount:

   Attributes with this syntax define the behavior of the 1-day (24
   hour) interval counters found in the MIB.

   o   Hdsl2ShdslPerfTimeElapsed:

   Attributes with this syntax define the behavior of the elapsed time
   counters found in the MIB.

   o   Hdsl2ShdslPerfIntervalThreshold:

   Attributes with this syntax define the behavior of the alarm
   thresholds found in the MIB.

   o   Hdsl2ShdslClockReferenceType

   Attributes with this syntax define the clock references for the
   HDSL2/SHDSL span.

4.3. Structure

The MIB is structured into following MIB groups: o Span Configuration Group: This group supports MIB objects for configuring parameters for the HDSL2/SHDSL span. It contains the following table: - hdsl2ShdslSpanConfTable o Span Status Group: This group supports MIB objects for retrieving span status information. It contains the following table: - hdsl2ShdslSpanStatusTable
ToP   noToC   RFC3276 - Page 8
   o   Unit Inventory Group:

   This group supports MIB objects for retrieving unit inventory
   information about units in HDSL2/SHDSL lines via the EOC. It contains
   the following table:

      - hdsl2ShdslInventoryTable

   o   Segment Endpoint Configuration Group:

   This group supports MIB objects for configuring parameters for the
   HDSL2/SHDSL segment endpoints.  It contains the following table:

      - hdsl2ShdslEndpointConfTable

   o   Segment Endpoint Current Status/Performance Group:

   This group supports MIB objects that provide the current
   status/performance information relating to segment endpoints.  It
   contains the following table:

      - hdsl2ShdslEndpointCurrTable

   o   Segment Endpoint 15-Minute Interval Status/Performance Group:

   This group supports MIB objects that provide historic
   status/performance information relating to segment endpoints in 15-
   minute intervals.  It contains the following table:

      - hdsl2Shdsl15MinIntervalTable

   o   Segment Endpoint 1-Day Interval Status/Performance Group:

   This group supports MIB objects that provide historic
   status/performance information relating to segment endpoints in 1-day
   intervals.  It contains the following table:

      - hdsl2Shdsl1DayIntervalTable

   o   Maintenance Group:

   This group supports MIB objects for performing maintenance operations
   such as loopbacks for HDSL2/SHDSL lines.  It contains the following
   table(s):

      - hdsl2ShdslEndpointMaintTable
      - hdsl2ShdslUnitMaintTable
ToP   noToC   RFC3276 - Page 9
   o   Span Configuration Profile Group:

   This group supports MIB objects for defining configuration profiles
   for HDSL2/SHDSL Spans.  It contains the following table:

      - hdsl2ShdslSpanConfProfileTable

   o   Segment Endpoint Alarm Configuration Profile Group:

   This group supports MIB objects for defining alarm configuration
   profiles for HDSL2/SHDSL Segment Endpoints.  It contains the
   following table:

      - hdsl2ShdslEndpointAlarmConfProfileTable

   o   Notifications Group:

   This group defines the notifications supported for HDSL2/SHDSL lines:

      - hdsl2ShdslLoopAttenCrossing
      - hdsl2ShdslSNRMarginCrossing
      - hdsl2ShdslPerfESThresh
      - hdsl2ShdslPerfSESThresh
      - hdsl2ShdslPerfCRCanomaliesThresh
      - hdsl2ShdslPerfLOSWSThresh
      - hdsl2ShdslPerfUASThresh
      - hdsl2ShdslSpanInvalidNumRepeaters
      - hdsl2ShdslLoopbackFailure
      - hdsl2ShdslpowerBackoff
      - hdsl2ShdsldeviceFault
      - hdsl2ShdsldcContinuityFault
      - hdsl2ShdslconfigInitFailure
      - hdsl2ShdslprotocolInitFailure
      - hdsl2ShdslnoNeighborPresent
      - hdsl2ShdslLocalPowerLoss

4.3.1 Line Topology

An HDSL2/SHDSL Line consists of a minimum of two units - xtuC (the central termination unit) and an xtuR (the remote termination unit). The line may optionally support up to 8 repeater/regenerator units (xru) as shown in the figure below.
ToP   noToC   RFC3276 - Page 10
    <-- Network Side                            Customer Side -->

    |</////////////////// HDSL2/SHDSL Span ////////////////////>|

            <~~~>       <~~~> HDSL2/SHDSL Segments  <~~~>

    +-------+   +-------+   +-------+       +-------+   +-------+
    +       C=1=N       C=1=N       C=..1..=N       C=1=N       +
    | xtuC  |   |  xru1 |   |  xru2 |       |  xru8 |   |  xtuR |
    +       C=2=N       C=2=N       C=..2..=N       C=2=N       +
    +-------+   +-------+   +-------+       +-------+   +-------+

    Key:  <////> HDSL2/SHDSL Span
          <~~~~> HDSL2/SHDSL Segment
          =1=    HDSL2/SHDSL wire-pair-1
          =2=    SHDSL optional wire-pair-2 (Not applicable to HDSL2)
          C      Customer Side Segment Endpoint (modem)
          N      Network Side Segment Endpoint (modem)


          Figure 2: General topology for an HDSL2/SHDSL Line

4.4. Counters, Interval Buckets and Thresholds

For SNR Margin, Loop Attenuation, ES, SES, CRC anomalies, LOSW, 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. Unlike RFC 2493 [22] and RFC 2662 [23], there is no representation in the MIB for invalid buckets. In those cases where the data for an interval is suspect or known to be invalid, the agent MUST NOT report the interval. If the current 15-minute event bucket is determined to be invalid, notifications based upon the value of the event bucket MUST NOT be generated. Not reporting an interval will result in holes in the associated table. For example, the table, hdsl2Shdsl15MinIntervalTable, is indexed by { ifIndex, hdsl2ShdslInvIndex, hdsl2ShdslEndpointSide, hdsl2ShdslEndpointWirePair, hdsl2Shdsl15MinIntervalNumber}. If interval 12 is determined to be invalid but intervals 11 and 13 are valid, a Get Next operation on the indices .1.1.1.1.11 would return indices .1.1.1.1.13.
ToP   noToC   RFC3276 - Page 11
   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 an xU is reinitialized, only when the
   agent is reset or reinitialized (or under specific request outside
   the scope of this MIB).

4.5. Profiles

As a managed node can handle a large number of xUs, (e.g., hundreds or perhaps thousands of lines), provisioning every parameter on every xU 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: o Span Configuration Profiles - Span configuration profiles contain parameters for configuring HDSL2/SHDSL spans. They are defined in the hdsl2ShdslSpanConfProfileTable. Since span configuration parameters are only applicable for SHDSL, the support for span configuration profiles are optional for HDSL2 interfaces. Note that the configuration of the span dictates the behavior for each individual segment end point in the span. If a different configuration is provisioned for any given segment end point within the span, the new configuration for this segment end point will override the span configuration for this segment end point only. o Segment Endpoint Alarm Configuration Profiles - These profiles contain parameters for configuring alarm thresholds for HDSL2/SHDSL segment endpoints. These profiles are defined in the hdsl2ShdslEndpointAlarmConfProfileTable. The index value for this profile is a locally-unique administratively assigned name for the profile having the textual convention `SnmpAdminString' (RFC 2571 [1]). One or more lines may be configured to share parameters of a single profile (e.g., hdsl2ShdslEndpointAlarmConfProfile = `silver') by setting its hdsl2ShdslEndpointAlarmConfProfile objects to the value of this profile. If a change is made to the profile, all lines that
ToP   noToC   RFC3276 - Page 12
   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 whose name is `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 hdsl2ShdslEndpointAlarmConfProfile and
   hdsl2ShdslSpanConfProfile to `DEFVAL' where appropriate.  This
   default profile name, 'DEFVAL', is considered reserved in the context
   of profiles defined in this MIB.

   Profiles are created, assigned, and deleted dynamically using the
   profile name and profile row status in each of the four profile
   tables.

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

4.6. Notifications

The ability to generate the SNMP notifications coldStart/WarmStart (per [21]) which are per agent (e.g., per Digital Subscriber Line Access Multiplexer, or DSLAM, in such a device), and linkUp/linkDown (per [21]) which are per interface (i.e., HDSL2/SHDSL line) is required. A linkDown notification MAY be generated whenever any of ES, SES, CRC Anomaly, LOSW, or UAS event occurs. The corresponding linkUp notification MAY be sent when all link failure conditions are cleared. The notifications defined in this MIB are for initialization failure and for the threshold crossings associated with the following events: ES, SES, CRC Anomaly, LOSW, and UAS. Each threshold has its own enable/threshold value. When that value is 0, the notification is disabled. The hdsl2ShdslEndpointCurrStatus is a bitmask representing all outstanding error conditions associated with a particular Segment Endpoint. Note that since status of remote endpoints is obtained via the EOC, this information may be unavailable for units that are 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 this object are defined.
ToP   noToC   RFC3276 - Page 13
   Two alarm conditions, SNR Margin Alarm and Loop Attenuation Alarm,
   are organized in a manner slightly different from that implied in the
   EOC specifications.  In the MIB, these alarm conditions are tied to
   the two thresholds hdsl2ShdslEndpointThreshSNRMargin and
   hdsl2ShdslEndpointThreshLoopAttenuation found in the
   hdsl2ShdslEndpointAlarmConfProfileTable.  In the EOC, the alarm
   conditions associated with these thresholds are per-unit.  In the
   MIB, these alarm conditions are per-endpoint.  For terminal units,
   this has no impact.  For repeaters, this implies an implementation
   variance where the agent in the terminal unit is responsible for
   detecting a threshold crossing.  As the reporting of a repeater
   detected alarm condition to the polling terminal unit occurs in the
   same EOC message as the reporting of the current SNR Margin and Loop
   Attenuation values, it is anticipated that this will have very little
   impact on agent implementation.

   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 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 [21]).  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.

   A hdsl2ShdslSpanInvalidNumRepeaters notification may be generated
   following completion of the discovery phase if the number of
   repeaters discovered on the line differs from the number of repeaters
   specified in hdsl2ShdslSpanConfNumRepeaters.  For those conditions
   where the number of provisioned repeaters is greater than those
   encountered during span discovery, all table entries associated with
   the nonexistent repeaters are to be discarded.  For those conditions
   where the number of provisioned repeaters is less than those
   encountered during span discovery, additional table entries are to be
   created using the default span configuration profile.
ToP   noToC   RFC3276 - Page 14

5. Conformance and Compliance

For both HDSL2 and SHDSL lines, the following group(s) are mandatory: hdsl2ShdslSpanConfGroup hdsl2ShdslSpanStatusGroup hdsl2ShdslInventoryGroup hdsl2ShdslEndpointConfGroup hdsl2Shdsl15MinIntervalGroup hdsl2Shdsl1DayIntervalGroup hdsl2ShdslMaintenanceGroup hdsl2ShdslEndpointAlarmConfGroup hdsl2ShdslNotificationGroup For HDSL2 lines, the following group(s) are optional: hdsl2ShdslSpanConfProfileGroup hdsl2ShdslSpanShdslStatusGroup


(page 14 continued on part 2)

Next Section