rfc2020.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,498 行 · 第 1/5 页

                            dot12Status is equal to 'closed', 'opening',
                            'openFailure' or 'linkFailure', this object
                            will be equal to 'down'.  Support for
                            'testing' is not required, but may be used
                            to indicate that a vendor specific test is
                            in progress.  The value 'dormant' has no
                            meaning for an IEEE 802.12 interface.

     ifLastChange           Refer to [7].

     ifInOctets             The number of octets in valid MAC frames
                            received on this interface, including the
                            MAC header and FCS.

     ifInUcastPkts          Refer to [7].

     ifInDiscards           Refer to [7].

     ifInErrors             The sum for this interface of
                            dot12InIPMErrors,
                            dot12InOversizeFrameErrors,
                            dot12InDataErrors, and any additional
                            internal errors that may occur in an
                            implementation.

     ifInUnknownProtos      Refer to [7].

     ifOutOctets            The number of octets transmitted in MAC
                            frames on this interface, including the MAC
                            header and FCS.

     ifOutUcastPkts         Refer to [7].

     ifOutDiscards          Refer to [7].



Flick                       Standards Track                     [Page 6]

RFC 2020               IEEE 802.12 Interface MIB            October 1996


     ifOutErrors            The number of implementation-specific
                            internal transmit errors on this interface.

     ifName                 Locally-significant textual name for the
                            interface (e.g. vg0).

     ifInMulticastPkts      Refer to [7].  When dot12CurrentFramingType
                            is frameType88025, this count includes
                            packets addressed to functional addresses.

     ifInBroadcastPkts      Refer to [7].

     ifOutMulticastPkts     Refer to [7].  When dot12CurrentFramingType
                            is frameType88025, this count includes
                            packets addressed to functional addresses.

     ifOutBroadcastPkts     Refer to [7].

     ifHCInOctets           64-bit version of ifInOctets.

     ifHCOutOctets          64-bit version of ifOutOctets

     ifHC*Pkts              Not required for 100 MBit interfaces.
                            Future IEEE 802.12 interfaces which operate
                            at higher speeds may require implementation
                            of these counters, but such interfaces are
                            beyond the scope of this memo.

     ifLinkUpDownTrapEnable Refer to [7].  Default is 'enabled'.

     ifHighSpeed            The speed of the interface in millions of
                            bits per second.  For current 802.12
                            implementations, this will be equal to 100.

     ifPromiscuousMode      Reflects whether the interface has
                            successfully trained and is currently
                            operating in promiscuous mode.
                            dot12DesiredPromiscStatus is used to select
                            the promiscuous mode to be requested in the
                            next training attempt.  Setting
                            ifPromiscuousMode will update
                            dot12DesiredPromiscStatus and cause the
                            interface to attempt to retrain using the
                            new promiscuous mode.  After the interface
                            has retrained, ifPromiscuousMode will
                            reflect the mode that is in use, not the
                            mode that was requested.




Flick                       Standards Track                     [Page 7]

RFC 2020               IEEE 802.12 Interface MIB            October 1996


     ifConnectorPresent     This will normally be 'true'.

     ifStackHigherLayer     Refer to section 3.3.1
     ifStackLowerLayer
     ifStackStatus

     ifRcvAddressAddress    Refer to section 3.3.4.
     ifRcvAddressStatus
     ifRcvAddressType

3.4.  Relation to RFC 1643, RFC 1650, and RFC 1748

   An IEEE 802.12 interface can be configured to operate in either
   ethernet or token ring framing mode.  An IEEE 802.12 interface uses
   the frame format for the configured framing mode, but does not use
   the media access protocol for ethernet or token ring.  Instead, IEEE
   802.12 defines its own media access protocol, the Demand Priority
   Access Method (DPAM).

   There are existing standards-track MIB modules for instrumenting
   ethernet-like interfaces and token ring interfaces.  At the time of
   this writing, they are: STD 50, RFC 1643, "Definitions of Managed
   Objects for Ethernet-like Interface Types" [8]; RFC 1650,
   "Definitions of Managed Objects for Ethernet-like Interface Types
   using SMIv2" [9]; and RFC 1748, "IEEE 802.5 MIB using SMIv2" [10].
   These MIB modules are designed to instrument the media access
   protocol for these respective technologies.  Since IEEE 802.12
   interfaces do not implement either of these media access protocols,
   an agent should not implement RFC 1643, RFC 1650, or RFC 1748 for
   IEEE 802.12 interfaces.

3.5.  Relation to RFC 1749

   When an IEEE 802.12 interface is operating in token ring framing
   mode, and the end node supports token ring source routing, the agent
   should implement RFC 1749, the IEEE 802.5 Station Source Routing MIB
   [11] for those interfaces.














Flick                       Standards Track                     [Page 8]

RFC 2020               IEEE 802.12 Interface MIB            October 1996


3.6.  Master Mode Operation

   In an IEEE 802.12 network, "master" devices act as network
   controllers to decide when to grant requesting end-nodes permission
   to transmit.  These master devices may be repeaters, or other active
   controller devices such as switches.

   Devices which do not act as network controllers, such as end-nodes or
   passive switches, are considered to be operating in "slave" mode.

   The dot12ControlMode object indicates if the interface is operating
   in master mode or slave mode.

3.7.  Normal and High Priority Counters

   The IEEE 802.12 interface MIB does not provide normal priority
   transmit counters.  Standardization of normal priority transmit
   counters could not be justified -- ifOutUcastPkts,
   ifOutMulticastPkts, ifOutBroadcastPkts, ifOutOctets,
   dot12OutHighPriorityFrames, and dot12OutHighPriorityOctets should
   suffice.  More precisely, the number of normal priority frames
   transmitted can be calculated as:

       outNormPriorityFrames = ifOutUcastPkts             +
                               ifOutMulticastPkts         +
                               ifOutBroadcastPkts         -
                               dot12OutHighPriorityFrames

   The number of normal priority octets transmitted can be calculated
   as:

       outNormPriorityOctets = ifOutOctets                -
                               dot12OutHighPriorityOctets

   On the other hand, normal priority receive counters are provided.
   The main reason for this is that the normal priority and high
   priority counters include errored frames, whereas the ifIn*Pkts and
   ifInOctets do not include errored frames.  dot12InNormPriorityFrames
   could be calculated, but the calculation is tedious:

       inNormPriorityFrames = ifInUcastPkts              +
                              ifInMulticastPkts          +
                              ifInBroadcastPkts          +
                              dot12InNullAddressedFrames +
                              ifInErrors                 +
                              ifInDiscards               +
                              ifInUnknownProtos          -
                              dot12InHighPriorityFrames



Flick                       Standards Track                     [Page 9]

RFC 2020               IEEE 802.12 Interface MIB            October 1996


   dot12InNormPriorityOctets includes octets in unreadable frames, which
   is not available elsewhere.  The number of octets in unreadable
   frames can be calculated as:

       octetsInUnreadableFrames = dot12InNormPriorityOctets +
                                  dot12InHighPriorityOctets -
                                  ifInOctets

   Also, the total traffic at this interface can be calculated as:

       traffic = dot12InNormPriorityOctets +
                 dot12InHighPriorityOctets +
                 ifOutOctets

   In other words, the normal priority receive counters were deemed
   useful, whereas the normal priority transmit counters can be easily
   calculated from other available counters.

3.8.  IEEE 802.12 Training Frames

   Training frames are special MAC frames that are used only during link
   initialization.  Training frames are initially constructed by the
   device at the lower end of a link, which is the slave mode device for
   the link.  The training frame format is as follows:

       +----+----+------------+--------------+----------+-----+
       | DA | SA | Req Config | Allow Config |   Data   | FCS |
       +----+----+------------+--------------+----------+-----+

               DA = destination address (six octets)
               SA = source address (six octets)
               Req Config = requested configuration (2 octets)
               Allow Config = allowed configuration (2 octets)
               Data = data (594 to 675 octets)
               FCS = frame check sequence (4 octets)

   Training frames are always sent with a null destination address.  To
   pass training, an end node must use its source address in the source
   address field of the training frame.  A repeater may use a non-null
   source address if it has one, or it may use a null source address.











Flick                       Standards Track                    [Page 10]

RFC 2020               IEEE 802.12 Interface MIB            October 1996


   The requested configuration field allows the slave mode device to
   inform the master mode device about itself and to request
   configuration options.  The training response frame from the master
   mode device contains the slave mode device's requested configuration
   from the training request frame.  The currently defined format of the
   requested configuration field as defined in the IEEE Standard
   802.12-1995 standard is shown below.  Please refer to the most
   current version of the IEEE document for a more up to date
   description of this field.  In particular, the reserved bits may be
   used in later versions of the standard.

       First Octet:       Second Octet:

        7 6 5 4 3 2 1 0    7 6 5 4 3 2 1 0
       +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+
       |v|v|v|r|r|r|r|r|  |r|r|r|F|F|P|P|R|
       +-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+

       vvv: The version of the 802.12 training protocol with which
            the training initiator is compliant.  The current version
            is 100.
       r:   Reserved bits (set to zero)
       FF:  00 = frameType88023
            01 = frameType88025
            10 = reserved
            11 = frameTypeEither
       PP:  00 = singleAddressMode
            01 = promiscuousMode
            10 = reserved
            11 = reserved
       R:   0  = the training initiator is an end node
            1  = the training initiator is a repeater

   The allowed configuration field allows the master mode device to