rfc3276.txt

RFC 的详细文档！

   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






Ray & Abbi                  Standards Track                     [Page 7]

RFC 3276                  HDSL2-SHDSL-LINE MIB                  May 2002


   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




Ray & Abbi                  Standards Track                     [Page 8]

RFC 3276                  HDSL2-SHDSL-LINE MIB                  May 2002


   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.









Ray & Abbi                  Standards Track                     [Page 9]

RFC 3276                  HDSL2-SHDSL-LINE MIB                  May 2002


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







Ray & Abbi                  Standards Track                    [Page 10]

RFC 3276                  HDSL2-SHDSL-LINE MIB                  May 2002


   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



Ray & Abbi                  Standards Track                    [Page 11]

RFC 3276                  HDSL2-SHDSL-LINE MIB                  May 2002


   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.



Ray & Abbi                  Standards Track                    [Page 12]

RFC 3276                  HDSL2-SHDSL-LINE MIB                  May 2002


   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.








Ray & Abbi                  Standards Track                    [Page 13]

RFC 3276                  HDSL2-SHDSL-LINE MIB                  May 2002


5.  Conformance and Compliance

   For both HDSL2 and SHDSL lines, the following group(s) are mandatory:

      hdsl2ShdslSpanConfGroup
      hdsl2ShdslSpanStatusGroup
      hdsl2ShdslInventoryGroup
      hdsl2ShdslEndpointConfGroup
      hdsl2Shdsl15MinIntervalGroup
      hdsl2Shdsl1DayIntervalGroup