rfc2662.txt

RFC 的详细文档！

   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
   simultaneously:

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

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

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













Bathrick & Ly               Standards Track                    [Page 13]

RFC 2662                     ADSL Line MIB                   August 1999


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

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







Bathrick & Ly               Standards Track                    [Page 14]

RFC 2662                     ADSL Line MIB                   August 1999


   In this mode, profiles are created, assigned, and deleted dynamically
   using these four objects: adslLineConfProfile,
   adslLineConfProfileRowStatus, adslLineAlarmConfProfile,  and
   adslLineAlarmConfProfileRowStatus.

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.





Bathrick & Ly               Standards Track                    [Page 15]

RFC 2662                     ADSL Line MIB                   August 1999


   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

                                    or

               CurrTxRate <= PrevTxRate minus ThreshRateDown



Bathrick & Ly               Standards Track                    [Page 16]

RFC 2662                     ADSL Line MIB                   August 1999


   No trap is sent on initialization.

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

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

7.  Definitions

   ADSL-TC-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       transmission,
       MODULE-IDENTITY, Gauge32            FROM SNMPv2-SMI
       TEXTUAL-CONVENTION                  FROM SNMPv2-TC;

   adsltcmib MODULE-IDENTITY

   LAST-UPDATED "9908190000Z"

   ORGANIZATION "IETF ADSL MIB Working Group"

   CONTACT-INFO
       "
       Gregory Bathrick
       AG Communication Systems
       A Subsidiary of Lucent Technologies
       2500 W Utopia Rd.
       Phoenix, AZ 85027 USA
       Tel: [phone]
       Fax: [phone]
       E-mail: [e-mail]

       Faye Ly
       Copper Mountain Networks
       Norcal Office
       2470 Embarcadero Way
       Palo Alto, CA 94303
       Tel: [phone]
       Fax: [phone]
       E-Mail: [e-mail]



Bathrick & Ly               Standards Track                    [Page 17]

RFC 2662                     ADSL Line MIB                   August 1999


       IETF ADSL MIB Working Group ([e-mail])
       "
       DESCRIPTION
           "The MIB module which provides a ADSL
           Line Coding Textual Convention to be used
           by ADSL Lines."

       --  Revision history
       REVISION     "9908190000Z"  -- 19 August 1999, midnight
       DESCRIPTION  "Initial Version, published as RFC 2662"

       ::= { transmission 94 2 } -- adslMIB 2

       AdslLineCodingType ::= TEXTUAL-CONVENTION
           STATUS       current
           DESCRIPTION
               "This data type is used as the syntax for the ADSL
               Line Code."
           SYNTAX  INTEGER {
               other(1),-- none of the following
               dmt (2), -- Discrete MultiTone
               cap (3), -- Carrierless Amplitude & Phase modulation
               qam (4)  -- Quadrature Amplitude Modulation
           }

       AdslPerfCurrDayCount ::= TEXTUAL-CONVENTION
           STATUS  current
           DESCRIPTION
               "A counter associated with interface performance
               measurements in a current 1-day (24 hour) measurement
               interval.

               The value of this counter starts at zero at the
               beginning of an interval and is increased when
               associated events occur, until the end of the
               1-day interval.  At that time the value of the
               counter is stored in the previous 1-day history
               interval, if available, and the current interval
               counter is restarted at zero.

               In the case where the agent has no valid data available
               for this interval the corresponding object
               instance is not available and upon a retrieval
               request a corresponding error message shall be
               returned to indicate that this instance does
               not exist (for example, a noSuchName error for
               SNMPv1 and a noSuchInstance for SNMPv2 GET
               operation)."



Bathrick & Ly               Standards Track                    [Page 18]

RFC 2662                     ADSL Line MIB                   August 1999


            SYNTAX  Gauge32

       AdslPerfPrevDayCount ::= TEXTUAL-CONVENTION
           STATUS  current
           DESCRIPTION
               "A counter associated with interface performance