Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 2662

Proposed STD
Pages: 115
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: ADSLMIB

Definitions of Managed Objects for the ADSL Lines

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


Top       ToC       Page 1 
Network Working Group                                        G. Bathrick
Request for Comments: 2662                      AG Communication Systems
Category: Standards Track                                          F. Ly
                                                Copper Mountain Networks
                                                             August 1999

           Definitions of Managed Objects for the ADSL 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 (1999).  All Rights Reserved.

Table of Contents

    1.  Abstract  ..............................................   1
    2.  The SNMP Network Management Framework  .................   2
    3.  Object Definitions .....................................   3
    4.  Relationship of the ADSL LINE MIB with standard MIBs ...   3
    5.  Conventions used in the MIB ............................   7
    6.  Conformance and Compliance .............................  17
    7.  Definitions ............................................  17
    8.  Acknowledgments ........................................ 110
    9.  References ............................................. 111
   10.  Security Considerations ................................ 113
   11.  Intellectual Property Notice ........................... 114
   12.  Authors' Addresses ..................................... 114
   13.  Full Copyright Statement ............................... 115

1.  Abstract

   This document defines a standard SNMP MIB for ADSL lines based on the
   ADSL Forum standard data model [9].  The ADSL standard describes
   ATU-C and ATU-R as two sides of the ADSL line.  This MIB covers both
   ATU-C and ATU-R agent's perspectives.  Each instance defined in the

   MIB represents a single ADSL line.

Top      ToC       Page 2 
   It should be noted that the ADSL Forum Network Management Working
   Group provided input towards the content of this document.  See the
   Acknowledgement Section for a list of individuals who made this
   document possible.

2.  The SNMP Network Management Framework

   The SNMP Management Framework presently consists of five major

   o  An overall architecture, described in RFC 2571 [13].

   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 described in STD
      16, RFC 1155 [14], STD 16, RFC 1212 [15] and RFC 1215 [16].  The
      second version, called SMIv2, is described in STD 58, RFC 2578
      [1], STD 58, RFC 2579 [2] and STD 58, RFC 2580 [17].

   o  Message protocols for transferring management information.  The
      first version of the SNMP message protocol is called SNMPv1 and
      described in STD 15, RFC 1157 [7].  A second version of the SNMP
      message protocol, which is not an Internet standards track
      protocol, is called SNMPv2c and described in RFC 1901 [18] and RFC
      1906 [19].  The third version of the message protocol is called
      SNMPv3 and described in RFC 1906 [19], RFC 2572 [20] and RFC 2574

   o  Protocol operations for accessing management information.  The
      first set of protocol operations and associated PDU formats is
      described in STD 15, RFC 1157 [7].  A second set of protocol
      operations and associated PDU formats is described in RFC 1905

   o  A set of fundamental applications described in RFC 2573 [22] and
      the view-based access control mechanism described in RFC 2575

   This document 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 (e.g., 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.

Top      ToC       Page 3 
3.  Object Definitions

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the extended subset of Abstract Syntax Notation One
   (ASN.1) defined in the SMI.  In particular, each object type is named
   by an OBJECT IDENTIFIER, an administratively assigned name.  The
   object type together with an object instance serves to uniquely
   identify a specific instantiation of the object.  For human
   convenience, we often use a textual string, termed the descriptor, to
   also refer to the object type.

4.  Relationship of the ADSL LINE MIB with standard MIBs

   This section outlines the relationship of ADSL Line MIB with other
   MIBs described in RFCs and in their various degrees of

4.1  Use of the IfTable

   The ADSL LINE MIB specifies the detailed attributes of a data
   interface.  As such, it needs to integrate with IF-MIB [5].  The IANA
   has assigned the following ifType(s) relative to ADSL:


           . . .


                . . .

           adsl(94),    -- Asymmetric Digital Subscriber Loop

                . . .

           adslInterleave(124),    -- ADSL Interleaved Channel
           adslFast(125),          -- ADSL Fast Channel

                . . .          }

   Interfaces of each of these types are modeled by this document.  Most
   MIB tables in this document represent information of one of these
   interface types and are indexed by ifIndex.  Remaining are `profile'
   tables which may be accessed by the profileIndex.  This is explained
   in more detail in section 5.4 Profiles.

Top      ToC       Page 4 
4.1.1  ADSL Interface Types

   As shown below, three ADSL interface types are defined in this
   document, namely physical, interleaved channel, and fast channel.
   The physical interface represents characteristics of the physical
   media associated with both the ATUC and ATUR.  The interleaved and
   fast channel interface represent the characteristics of the two types
   of ADSL channels.

   For each ADSL Line, a physical interface always exists.   Depending
   on which ADSL operational configuration is present (as listed in
   Figure 5), the channel interfaces (fast or interleaved) may or may
   not exist.

               ______                      ______
              |      |____________________|      |
              | ATUC |                    | ATUR |
              |      |____________________|      |
              |______|                    |______|

                 | <----- physical --------> |

                 | <--- fast channel ------> |

                 | <- interleaved channel -> |

                      Figure 1: ADSL Model

4.1.2  Use of IF-MIB  (Interface MIB RFC 2233) [5]

   The following attributes are part of the required
   ifGeneralInformationGroup object group specified in RFC 2233 [5], and
   are not duplicated in the ADSL MIB.  Keep in mind that these objects
   apply to the agent's view of the line.

Top      ToC       Page 5 
              ifTable Object    Use for ADSL
              ifIndex           Interface index.

              ifDescr           See interfaces MIB [5]

              ifType            physical    - adsl(94)
                                fast        - adslFast(125)
                                interleaved - adslInterleave(124)

              ifSpeed           Transmit rate from the perspective
                                of the agent.

                                physical      - line rate
                                fast          - channel rate
                                interleaved   - channel rate

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

              ifAdminStatus     See interfaces MIB [5]

              ifOperStatus      See interfaces MIB [5]

                                Supplemented by adslAturCurrStatus and

              ifLastChange      See interfaces MIB [5]

              ifName            See interfaces MIB [5]

              ifLinkUpDownTrapEnable   See interfaces MIB [5]

                                Default set as follows:

                                physical      - enabled(1)
                                fast          - disabled(2)
                                interleaved   - disabled(2)

              ifHighSpeed       Speed of line in Mega-bits per second

              ifConnectorPresent See interfaces MIB [5]

                                Default set as follows:

                                physical      - true(1)
                                fast          - false(2)

Top      ToC       Page 6 
                                interleaved   - false(2)

              ifAlias           See interfaces MIB [5]

              ifTableLastChange See interfaces MIB [5]


        Figure 2: Use of ifTable Objects: ifGeneralInformationGroup

   Use of the ifStackTable to associate the entries for physical, fast,
   interleaved channels, and higher layers (e.g., ATM) is shown below in
   figure 3.  Use of ifStackTable is necessary, because configuration
   information is stored in profile tables associated with the
   physical-layer ifEntry only.  The channels' ifEntrys need the
   ifStackTable to find their associated physical-layer entry and thus
   their configuration parameters.  (See Profile section, 5.4).

               ______       (ifEntry=j)        ______
              |      |      fast channel      |      |
              |      |________________________|      |
              |      |        and/or          |      |
              |      |                        |      |
              |      |     (ifEntry=k)        |      |
              |      |   interleaved channel  |      |
              |      |________________________|      |
              | ATUC |                        | ATUR |
              |      |                        |      |
              |      |     (ifEntry=i)        |      |
              |      |      physical          |      |
              |      |________________________|      |
              |______|                        |______|

               Figure 3: Use of ifStackTable (part 1)

   The ifStackTable is then used to show the relationships between the
   various ADSL interfaces, as illustrated below in figure 4.

                     HigherLayer   LowerLayer
                         j             i
                         k             i

                  Figure 4: Use of ifStackTable (part 2)

   The ifRcvAddressTable is not applicable for ADSL interfaces.

Top      ToC       Page 7 
4.2  Relationship with RFC 2037 [25]

   Implementation of the Entity MIB [25] is optional.  It in no way
   alters the information required in the adslLineMib, 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

   If ATU-C agent is implemented, the Entity MIB should include entities
   for the ATU-C in the entPhysicalTable.  The MIB's
   entAliasMappingTable would contain mapping information identifying
   the 'ifIndex' object associated with each ATU-C.  However, if ATU-R
   agent is implemented, the Entity MIB should include entities for the
   ATU-R in the entPhysicalTable.  In this case, the MIB's
   entAliasMappingTable would  contain mapping information identifying
   the 'ifIndex' object associated with each ATU-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

5.  Conventions used in the MIB

5.1  Naming Conventions

   A. Atuc/Atur are used for the ATU-C and ATU-R.  In other RFCs, these
      are sometimes referred to as the Near End (Ne) and Far End (Fe)
      respectively, but not in this document.

   B. The terms, "transmit" and "receive", are from the perspective of
      the corresponding table's end of the line.  For example, in the
      case of Fast channels, adslAtucChanConfFastMaxTxRate defines the
      "downstream" rate, while adslAturChanConfFastMaxTxRate defines the
      "upstream" rate for a particular channel.

   C. There are two possible channels: fast, and interleaved.  None, one
      or both may be implemented on a particular ADSL Line.  Figure 5
      illustrates all possible operational configurations.

Top      ToC       Page 8 
   D. Lof, Lol, Los, Lpr mean Loss of Framing, Link, Signal, and Power,
      respectively.  Lpr is used by T1E1, so it is used for consistency
      (rather than Lop).

      A Loss of Link condition is declared at the ATU-C if a Loss of
      Signal is not preceded by a `dying-gasp' message from the ATU-R.
      Note that Loss of Link is only supported by the ATU-C.

   E. ES means errored second. An Errored Second is any second
      containing one or more CRC anomaly, or one or more Los(s) or
      Severely Errored Frame (Sef) defect(s).

   F. A "block" is a physical-layer `data buffer' over which CRCs are
      calculated.  For example, in DMT, the block is defined as the ADSL
      superframe.  The block duration is 250 micro-seconds so the block
      length in bytes, as defined in adslAtu*ChanCrcBlockLength, varies
      with data rate.  See Line Code Specific MIBs [11] [12] for more
      line code specific information.

   G. Atn means Attenuation, Psd is Power Spectral Density and Snr is
      Signal to Noise Ratio.

   H. LCS means line code specific, e.g.,

      o DMT = Discrete MultiTone

      o CAP = Carrierless Amplitude and Phase modulation and

      o QAM = Quadrature Amplitude Modulation

   I. Vendor (in the Inventory objects) refers to the manufacturer of
      the ATU-C or ATU-R assembly, not the modem chip vendor. When in
      doubt, use the manufacturer of the smallest field replaceable unit
      (e.g., stand-alone modem box, plug-in board).

   J. RADSL - Rate Adaptive Asymmetric Digital Subscriber Loop

5.2  Structure

   The MIB has multiple parallel tables.  There are tables for:

      o line -  common attributes

      o atuc and atur status

Top      ToC       Page 9 
      o atuc and atur performance

         - Current and up to 96 buckets of 15 min performance history

         - Current and Previous 1-day bucket performance history

      o profiles - configuration parameters and alarm parameters

   There are separate tables for Physical and Channel layers.  Since
   their attributes are similar, only one set of "channel" tables are
   defined to be used for both fast and interleaved channels. The
   corresponding ifType gives the proper interpretation for that

   It is intented that Line Code Specific MIBs be located under
   adslLCSMib.  These MIBs will be defined in separate modules.

   There could have been fewer tables by combining the ATU-C and ATU-R
   information into shared tables. However, the tables are more easily
   read when there are two identical sets of data.

   The figure below lists the five possible ADSL operational
   configurations. (indicated by the value of the adslLineType).  In all
   configurations, the physical line interface entry will exist.
   However, the existence of the ADSL channel varies in each case, as
   shown below.

       Table                         Phys     Fast  Interleaved
     No Channels (1)               |  Y    |        |        |
     Fast Only (2)                 |  Y    |   Y    |        |
     Interleaved Only (3)          |  Y    |        |   Y    |
     Fast or Interleaved (4)       |  Y    |   Y    |   Y    |
     Fast and Interleaved (5)      |  Y    |   Y    |   Y    |

              Figure 5: ADSL Operational configurations

   NOTE: In (4), channel exists of either Fast or Interleaved type, but
   not both.   The Manager may select the type of channel to be used.

   Depending on which operation configuration exists, some or all ADSL
   MIB tables could be supported, as shown in below.  See Conformance
   Statements for more information on which objects are mandatory.

Top      ToC       Page 10 
       Table                         Phys     Fast  Interleaved
     adslLineTable                  |  Y    |        |        |
     adslAtucPhysTable              |  Y    |        |        |
     adslAturPhysTable              |  Y    |        |        |
     adslAtucChanTable              |       |   Y    |   Y    |
     adslAturChanTable              |       |   Y    |   Y    |
     adslAtucPerfDataTable          |  Y    |        |        |
     adslAturPerfDataTable          |  Y    |        |        |
     adslAtucIntervalTable          |  Y    |        |        |
     adslAturIntervalTable          |  Y    |        |        |
     adslAtucChanPerfDataTable      |       |   Y    |   Y    |
     adslAturChanPerfDataTable      |       |   Y    |   Y    |
     adslAtucChanIntervalTable      |       |   Y    |   Y    |
     adslAturChanIntervalTable      |       |   Y    |   Y    |

   Figure 6: Use of ADSL MIB Tables with various ifIndex values

   NOTE: The adslLineConfProfileTable and adslLineAlarmConfProfileTable
   will be present for all scenarios.  See Profile Section of this
   document for implementation details such as profile creation,
   assignment, and indexing.

5.2.1 Structure of Conformance Groups

   The MIB is organized to cover both ends of the ADSL line, ATU-C and
   ATU-R.  Objects defined can be categorized into two groups:  the
   ATU-C group which provides objects that are supported by ATU-C agents
   and the ATU-R group which provides objects that are supported by
   ATU-R agents.  These two groups are defined by the conformance
   section of the MIB.  All objects defined in the MIB module are
   supported by the ATU-C agent and only portions of the objects are
   supported by the ATU-R agent.  Figure 7 lists all tables/objects that
   are supported by the ATU-R agent.

Top      ToC       Page 11 
              Table                         Objects
              adslLineTable                 adslLineCoding
              adslAtucPhysTable             adslAtucInvVendorID
                                            adslAtucCurrStatus (Partial)
              adslAturPhysTable             all are supported
              adslAtucChanTable             all except
                                            are supported
              adslAtucPerfDataTable         all except
                                            adslAtucPerfPrev1DayLols and
                                            are supported
              adslAturPerfDataTable         all are supported
              adslAtucIntervalTable         adslAtucIntervalLofs
              adslAturIntervalTable         all are supported
              adslAtucChanPerfDataTable     all are supported
              adslAturChanPerfDataTable     all are supported
              adslAtucChanIntervalTable     all are supported
              adslAturChanIntervalTable     all are supported
              adslLineConfProfileTable      not supported
              adslLineAlarmConfProfileTable all are supported except
                                            and adslAtucThresh15MinLprs

     Figure 7: MIB Tables and Objects Supported by the ATU-R Agent

Top      ToC       Page 12 
   All traps supported by the ATU-R agent are also listed:


5.3  Counters, Interval Buckets and Thresholds

   For physical-level ES, Los, Lof, Lol, Lpr and line initialization
   attempts, there are event counters, current 15-minute and one (up to
   96) 15-minute history bucket(s) of "interval-counters", as well as
   current and previous 1-day interval-counters.  Each physical-layer
   current 15-minute event bucket has threshold trap.

   At the channel level, there are counters for total received blocks,
   received-and-corrected blocks, received-but-uncorrectable blocks, and
   transmitted blocks. There are the same set of 15-minute and 1-day
   buckets as at the physical-layer.

   There is no requirement for an agent to ensure fixed relationship
   between the start of a fifteen minute 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 start of a day.

   Separate tables are provided for the 96 interval-counters. They are
   indexed by {ifIndex, AdslAtu*IntervalNumber}.

   Counters are not reset when an ATU-C or ATU-R is reinitialized, only
   when the agent is reset or reinitialized (or under specific request
   outside the scope of this MIB).

   The 15-minute event counters are of type PerfCurrentCount and
   PerfIntervalCount.  The 1-day event counters are of type
   AdslPerfCurrDayCount and AdslPerfPrevDayCount. Both 15-minute and 1-
   day time elapsed counters are of type AdslPerfTimeElapsed.

Top      ToC       Page 13 
5.4  Profiles

   As a managed node can handle a large number of ATU-Cs (e.g., hundreds
   or perhaps thousands of ADSL lines), provisioning every parameter on
   every ATU-C may become burdensome.  In response, two MIB tables have
   been created to define ADSL equipment configuration data profiles, as
   well as a mechanism to associate the equipment to these profiles.

   Profile tables may be implemented in one of two ways, but not

      o  MODE-I: Dynamic Profiles - one profile shared by one or
         multiple ADSL lines.

      o  MODE-II: Static Profiles - one profile per ADSL physical line

5.4.1  MODE-I : Dynamic Profiles

   Implementations using this mode will enable the manager to
   dynamically create and delete profiles as needed.  The index of the
   profile is an locally-unique administratively assigned name for the
   profile having the textual convention `SnmpAdminString' (RFC2571

   One or more ADSL lines may be configured to share parameters of a
   single profile (e.g., adslLineConfProfileName = `silver') by setting
   its adslLineConfProfile objects to the index value of this profile.
   If a change is made to the profile, all lines that refer to it will
   be re-configured to the changed parameters.  Before a profile can be
   deleted or taken out of service it must be first unreferenced from
   all associated lines.

   This figure below shows an example of how this mode can be
   implemented.  In the example, ADSL lines `1' and `x' share the
   configuration of the `silver' profile, while line `2' uses the
   `platinum' profile.  The `gold' profile has no lines associated with

Top      ToC       Page 14 
   ADSL    ifIndex      ifTable                       Configuration Line
   Profile Table

   1         i1         ADSL Line --           ---> Platinum Profile
             j1         Fast Chan    |        |
             k1         Int Chan     |        |
                                     |        ^
                                     v        |     Gold Profile

   2         i2         ADSL Line ------->----
             j2         Fast Chan    |
             k2         Int Chan     |

   x         ix         ADSL Line    ------>------> Silver Profile
             jx         Fast Chan  --------------->
             kx         Int Chan

               Figure 8: Use of Dynamic Profiles: MODE-I

   In the figure above, note that three interface entries of an ADSL
   line, physical, fast channel, and interleaved channel, are
   represented by `i', `j', and `k'.  Only the physical-layer entry `i'
   contains an adslLineTable entry, therefore only those entries contain
   pointers to the adslLineConfProfileTable.  The ifStackTable (see
   rfc2233 [5]) can be used to link the channel entries to the
   corresponding physical-layer entry to get the channel's configuration
   parameters.  See figure 4 for use of the ifStackTable.

   The same characteristics and mechanisms are present for the alarm
   profile type. There is no requirement that its index be the same as
   the configuration profile.

   Implementations of this mode, must provide a default profile whose
   name is `DEFVAL' for each profile type: Configuration and Alarm.  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
   adslLineConfProfile and adslLineAlarmConfProfile to `DEFVAL'.

Top      ToC       Page 15 
   In this mode, profiles are created, assigned, and deleted dynamically
   using these four objects: adslLineConfProfile,
   adslLineConfProfileRowStatus, adslLineAlarmConfProfile,  and

5.4.2  MODE-II : Static Profiles

   Implementations with this mode will automatically create a profile
   one-for-one with each ADSL line physical entry.  The name of this
   profile is a system generated read-only object whose value is
   equivalent to the index of the physical line.  The Agent will not
   allow a Manager to create/delete profiles in this mode.  Therefore,
   adslLineConfProfile, adslLineConfProfileRowStatus,
   adslLineAlarmConfProfile, and adslLineAlarmConfProfileRowStatus
   objects have minimal value in this mode and are read-only.

   The figure below shows an example of this mode. In the example, ADSL
   lines `1', `2', and `x' each have their own profiles.

   ADSL    ifIndex      ifTable                       Configuration Line
   Profile Table

   1         i1         ADSL Line      ------------>  Profile
             j1         Fast Chan
             k1         Int Chan

   2         i2         ADSL Line      ------------>  Profile
             j2         Fast Chan

             k2         Int Chan

   x         ix         ADSL Line      ------------>  Profile
             jx         Fast Chan
             kx         Int Chan

                Figure 9: Use of Static Profiles: MODE II

5.5  Traps

   These SNMP traps are required: coldStart / warmStart (per [6]) --
   which are per agent (e.g., per DSLAM in such a device), and linkUp /
   linkDown (per [5]) -- which are per interface (i.e., ADSL line).
   Note: RFC 2233 [5] recommends that linkUp / linkDown only be used at
   a physical-layer ifEntry, as discussed above.

Top      ToC       Page 16 
   A linkDown trap is generated whenever any of Lof, Los, Lol, Loss of
   Signal Quality, or Lpr events occurs.  At this operational point, a
   manager can use adslAtu*CurrStatus for additional detailed
   information. The corresponding linkUp trap is sent when all link
   failure conditions are cleared.

   The traps defined in this MIB are for initialization failure, rate
   change, and for the threshold crossings associated with the following
   events: Lofs, Lols, Loss, Lprs, and ESs.  Each threshold has its own
   enable/threshold value. When that value is 0, the trap is disabled.

   The current status objects (adslAtu*CurrStatus) indicate, through a
   bitmask, all outstanding error conditions or that the line is
   operational.  Note that each object claims to represent the status of
   the modem at that end of the line.  However, since the SNMP agent
   likely co-resides with only one end of the line, the corresponding
   far-end current status object may be incomplete. For example, when
   there are errors on the line, the far-end ATU may not be able to
   correctly report this condition. Therefore, not all conditions are
   included in its current status.

   A threshold trap occurs whenever the corresponding current 15-minute
   interval error counter becomes equal and/or exceeds to the threshold
   value.  One trap will be sent per interval per interface. Since the
   current 15-minute counter are reset to 0 every 15 minutes, if the
   condition persists, the trap may recur as often as every 15 minutes.
   For example, to get a trap whenever a "loss of" event occurs (but at
   most once every 15 minutes), set the corresponding "Thresh15Min" to
   1.  The agent will generate a trap when the event originally occurs.

   Note that the NMS will get a linkDown trap, as well, if enabled.  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 trap
   will be sent again.

   The rate change trap is invoked when the transmit rate on a channel
   either increases by adsl(x)Thresh(y)RateUp or decreases by
   adsl(x)Thresh(y)RateDown. The trap is per direction:(x) == Atuc or
   Atur, and per channel: (y) == Fast or Interleave. In other words, the
   trap is sent whenever the rate changes in either direction on either
   channel and:

                CurrTxRate >= PrevTxRate plus ThreshRateUp


               CurrTxRate <= PrevTxRate minus ThreshRateDown

Top      ToC       Page 17 
   No trap is sent on initialization.

   It can be disabled by setting the Up (and/or) Down threshold rates to

   The PrevTxRate object is set to the current value at initialization
   and when a trap is sent.  Thus rate changes are cumulative until the
   total change reaches the threshold.

6.  Conformance and Compliance

   See the conformance and compliance statements within the information

(page 17 continued on part 2)

Next RFC Part