rfc2496.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

2.2.2.  Usage of Channelization for DS3, DS1, DS0

   An example is given here to explain the channelization objects in the
   DS3, DS1, and DS0 MIBs to help the implementor use the objects
   correctly. Treatment of E3 and E1 would be similar, with the number
   of DS0s being different depending on the framing of the E1.

   Assume that a DS3 (with ifIndex 1) is Channelized into DS1s (without
   DS2s).  The object dsx3Channelization is set to enabledDs1.  When
   this object is set to enabledDS1, 28 ifEntries of type DS1 will be
   created by the agent. If dsx3Channelization is set to disabled, then
   the DS1s are destroyed.

   Assume the entries in the ifTable for the DS1s are created in channel
   order and the ifIndex values are 2 through 29. In the DS1 MIB, there
   will be an entry in the dsx1ChanMappingTable for each ds1.  The
   entries will be as follows:

        dsx1ChanMappingTable Entries

        ifIndex  dsx1Ds1ChannelNumber   dsx1ChanMappedIfIndex

        1        1                      2
        1        2                      3
        ......
        1        28                     29

   In addition, the DS1s are channelized into DS0s.  The object
   dsx1Channelization is set to enabledDS0 for each DS1.  There will be
   24 DS0s in the ifTable for each DS1.  Assume the entries in the
   ifTable are created in channel order and the ifIndex values for the
   DS0s in the first DS1 are 30 through 53.  In the DS0 MIB, there will
   be an entry in the dsx0ChanMappingTable for each DS0.  The entries
   will be as follows:

        dsx0ChanMappingTable Entries

        ifIndex   dsx0Ds0ChannelNumber  dsx0ChanMappedIfIndex
        2         1                     30
        2         2                     31
        ......
        2         24                    53

2.2.3.  Usage of Channelization for DS3, DS2, DS1

   An example is given here to explain the channelization objects in the
   DS3 and DS1 MIBs to help the implementor use the objects correctly.




Fowler, Ed.                 Standards Track                     [Page 7]

RFC 2496                      DS3/E3 MIB                    January 1999


   Assume that a DS3 (with ifIndex 1) is Channelized into DS2s.  The
   object dsx3Channelization is set to enabledDs2.  There will be 7 DS2s
   (ifType of DS1) in the ifTable.  Assume the entries in the ifTable
   for the DS2s are created in channel order and the ifIndex values are
   2 through 8. In the DS1 MIB, there will be an entry in the
   dsx1ChanMappingTable for each DS2.  The entries will be as follows:

        dsx1ChanMappingTable Entries

        ifIndex  dsx1Ds1ChannelNumber   dsx1ChanMappedIfIndex
        1        1                      2
        1        2                      3
        ......
        1        7                      8

   In addition, the DS2s are channelized into DS1s.  The object
   dsx1Channelization is set to enabledDS1 for each DS2.  There will be
   4 DS1s in the ifTable for each DS2.  Assume the entries in the
   ifTable are created in channel order and the ifIndex values for the
   DS1s in the first DS2 are 9 through 12, then 13 through 16 for the
   second DS2, and so on.  In the DS1 MIB, there will be an entry in the
   dsx1ChanMappingTable for each DS1.  The entries will be as follows:

        dsx1ChanMappingTable Entries

        ifIndex   dsx1Ds1ChannelNumber  dsx1ChanMappedIfIndex
        2         1                     9
        2         2                     10
        2         3                     11
        2         4                     12
        3         1                     13
        3         2                     14
        ...
        8         4                     36

2.2.4.  Usage of Loopbacks

   This section discusses the behaviour of objects related to loopbacks.

   The object dsx3LoopbackConfig represents the desired state of
   loopbacks on this interface.  Using this object a Manager can
   request:
       LineLoopback
       PayloadLoopback (if ESF framing)
       InwardLoopback
       DualLoopback (Line + Inward)
       NoLoopback




Fowler, Ed.                 Standards Track                     [Page 8]

RFC 2496                      DS3/E3 MIB                    January 1999


   The remote end can also request lookbacks either through the FDL
   channel if ESF or inband if D4.  The loopbacks that can be request
   this way are:
   LineLoopback
   PayloadLoopback (if ESF framing)
   NoLoopback

   To model the current state of loopbacks on a DS3 interface, the
   object dsx3LoopbackStatus defines which loopback is currently applies
   to an interface.  This objects, which is a bitmap, will have bits
   turned on which reflect the currently active loopbacks on the
   interface as well as the source of those loopbacks.

   The following restrictions/rules apply to loopbacks:

   The far end cannot undo loopbacks set by a manager.

   A manager can undo loopbacks set by the far end.

   Both a line loopback and an inward loopback can be set at the same
   time.  Only these two loopbacks can co-exist and either one may be
   set by the manager or the far end.  A LineLoopback request from the
   far end is incremental to an existing Inward loopback established by
   a manager.  When a NoLoopback is received from the far end in this
   case, the InwardLoopback remains in place.

2.3.  Objectives of this MIB Module

   There are numerous things that could be included in a MIB for DS3/E3
   signals:  the management of multiplexors, CSUs, DSUs, and the like.
   The intent of this document is to facilitate the common management of
   all devices with DS3/E3 interfaces.  As such, a design decision was
   made up front to very closely align the MIB with the set of objects
   that can generally be read from DS3/E3 devices that are currently
   deployed.

2.4.  DS3/E3 Terminology

   The terminology used in this document to describe error conditions on
   a DS3 interface as monitored by a DS3 device are based on the late
   but not final draft of what became the ANSI T1.231 standard [11].  If
   the definition in this document does not match the definition in the
   ANSI T1.231 document, the implementer should follow the definition
   described in this document.







Fowler, Ed.                 Standards Track                     [Page 9]

RFC 2496                      DS3/E3 MIB                    January 1999


2.4.1.  Error Events

     Bipolar Violation (BPV) Error Event
          A bipolar violation error event, for B3ZS(HDB3)-coded signals,
          is the occurrence of a pulse of the same polarity as the
          previous pulse without being part of the zero substitution
          code, B3ZS(HDB3).  For B3ZS(HDB3)-coded signals, a bipolar
          violation error event may also include other error patterns
          such as:  three(four) or more consecutive zeros and incorrect
          polarity. (See T1.231 section 7.1.1.1.1)

     Excessive Zeros (EXZ) Error Event
          An EXZ is the occurrence of any zero string length equal to or
          greater than 3 for B3ZS, or greater than 4 for HDB3.  (See
          T1.231 section 7.1.1.1.2)

     Line Coding Violation (LCV) Error Event
          This parameter is a count of both BPVs and EXZs occurring over
          the accumulation period.  An EXZ increments the LCV by one
          regardless of the length of the zero string. (Also known as
          CV-L.  See T1.231 section 7.4.1.1)

     P-bit Coding Violation (PCV) Error Event
          For all DS3 applications, a coding violation error event is a
          P-bit Parity Error event.  A P-bit Parity Error event is the
          occurrence of a received P-bit code on the DS3 M-frame that is
          not identical to the corresponding locally- calculated code.
          (See T1.231 section 7.1.1.2.1)

     C-bit Coding Violation (CCV) Error Event
          For C-bit Parity and SYNTRAN DS3 applications, this is the
          count of coding violations reported via the C-bits.  For C-bit
          Parity, it is a count of CP-bit parity errors occurring in the
          accumulation interval.  For SYNTRAN, it is a count of CRC-9
          errors occurring in the accumulation interval. (See T1.231
          section 7.1.1.2.2)

2.4.2.  Performance Parameters

   All performance parameters are accumulated in fifteen minute
   intervals and up to 96 intervals (24 hours worth) are kept by an
   agent.  Fewer than 96 intervals of data will be available if the
   agent has been restarted within the last 24 hours.  In addition,
   there is a rolling 24-hour total of each performance parameter.







Fowler, Ed.                 Standards Track                    [Page 10]

RFC 2496                      DS3/E3 MIB                    January 1999


   There is no requirement for an agent to ensure fixed relationship
   between the start of a fifteen minute interval and any wall clock;
   however some agents may align the fifteen minute intervals with
   quarter hours.

   Performance parameters are of types PerfCurrentCount,
   PerfIntervalCount and PerfTotalCount.  These textual conventions are
   all Gauge32, and they are used because it is possible for these
   objects to decrease.  Objects may decrease when Unavailable Seconds
   occurs across a fifteen minutes interval boundary. See Unavailable
   Seconds discussion later in this section.

     Line Errored Seconds (LES)
          A Line Errored Second is a second in which one or more CV
          occurred OR one or more LOS defects.  (Also known as ES-L. See
          T1.231 section 7.4.1.2)

     P-bit Errored Seconds (PES)
          An PES is a second with one or more PCVs OR one or more Out of
          Frame defects OR a detected incoming AIS. This gauge is not
          incremented when UASs are counted.  (Also known as ESP-P. See
          T1.231 section 7.4.2.2)

     P-bit Severely Errored Seconds (PSES)
          A PSES is a second with 44 or more PCVs OR one or more Out of
          Frame defects OR a detected incoming AIS. This gauge is not
          incremented when UASs are counted.  (Also known as SESP-P. See
          T1.231 section 7.4.2.5)

     C-bit Errored Seconds (CES)
          An CES is a second with one or more CCVs OR one or more Out of
          Frame defects OR a detected incoming AIS.  This count is only
          for the SYNTRAN and C-bit Parity DS3 applications. This gauge
          is not incremented when UASs are counted. (Also known as
          ESCP-P. See T1.231 section 7.4.2.2)

     C-bit Severely Errored Seconds (CSES)
          A CSES is a second with 44 or more CCVs OR one or more Out of
          Frame defects OR a detected incoming AIS.  This count is only
          for the SYNTRAN and C-bit Parity DS3 applications.  This gauge
          is not incremented when UASs are counted. (Also known as
          SESCP-P. See T1.231 section 7.4.2.5)

     Severely Errored Framing Seconds (SEFS)
          A SEFS is a second with one or more Out of Frame defects OR a
          detected incoming AIS. This item is not incremented during
          unavailable seconds.  (Also known as SAS-P. See T1.231 section
          7.4.2.6)



Fowler, Ed.                 Standards Track                    [Page 11]

RFC 2496                      DS3/E3 MIB                    January 1999


     Unavailable Seconds (UAS)
          UAS are calculated by counting the number of seconds that the
          interface is unavailable.  The DS3 interface is said to be
          unavailable from the onset of 10 contiguous PSESs, or the
          onset of the condition leading to a failure (see Failure
          States).  If the condition leading to the failure was
          immediately preceded by one or more contiguous PSESs, then the
          DS3 interface unavailability starts from the onset of these
          PSESs.  Once unavailable, and if no failure is present, the
          DS3 interface becomes available at the onset of 10 contiguous
          seconds with no PSESs.  Once unavailable, and if a failure is
          present, the DS3 interface becomes available at the onset of
          10 contiguous seconds with no PSESs, if the failure clearing
          time is less than or equal to 10 seconds.  If the failure
          clearing time is more than 10 seconds, the DS3 interface
          becomes available at the onset of 10 contiguous seconds with
          no PSESs, or the onset period leading to the successful
          clearing condition, whichever occurs later. With respect to
          the DS3 error counts, all counters are incremented while the
          DS3 interface is deemed available.  While the interface is
          deemed unavailable, the only count that is incremented is
          UASs.

          Note that this definition implies that the agent cannot
          determine until after a ten second interval has passed whether
          a given one-second interval belongs to available or
          unavailable time.  If the agent chooses to update the various
          performance statistics in real time then it must be prepared
          to retroactively reduce the PES, PSES, CES, and CSES counts by
          10 and increase the UAS count by 10 when it determines that
          available time has been entered.  It must also be prepared to
          adjust the PCV, CCV, and SEFS count as necessary since these
          parameters are not accumulated during unavailable time.  It
          must be similarly prepared to retroactively decrease the UAS
          count by 10 and increase the PES, CES, PCV, and CCV counts as
          necessary upon entering available time.  A special case exists
          when the 10 second period leading to available or unavailable
          time crosses a 900 second statistics window boundary, as the
          foregoing description implies that the PCV, CCV, PES, CES,
          PSES, CSEC, SEFS, and UAS counts for the PREVIOUS interval
          must be adjusted.  In this case successive GETs of the
          affected dsx3IntervalPSESs and dsx3IntervalUASs objects will
          return differing values if the first GET occurs during the
          first few seconds of the window.







Fowler, Ed.                 Standards Track                    [Page 12]

RFC 2496                      DS3/E3 MIB                    January 1999


          The agent may instead choose to delay updates to the various
          statistics by 10 seconds in order to avoid retroactive