rfc2020.txt

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

Network Working Group                                           J. Flick
Request for Comments: 2020                               Hewlett Packard
Category: Standards Track                                   October 1996


       Definitions of Managed Objects for IEEE 802.12 Interfaces

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.

Table of Contents

 1.  Introduction ...............................................    1
 2.  Object Definitions .........................................    2
 3.  Overview ...................................................    2
 3.1.  MAC Addresses ............................................    3
 3.2.  Relation to RFC 1213 .....................................    3
 3.3.  Relation to RFC 1573 .....................................    3
 3.3.1.  Layering Model .........................................    4
 3.3.2.  Virtual Circuits .......................................    4
 3.3.3.  ifTestTable ............................................    4
 3.3.4.  ifRcvAddressTable ......................................    4
 3.3.5.  ifPhysAddress ..........................................    4
 3.3.6.  Specific Interface MIB Objects .........................    5
 3.4.  Relation to RFC 1643, RFC 1650, and RFC 1748 .............    8
 3.5.  Relation to RFC 1749 .....................................    8
 3.6.  Master Mode Operation ....................................    9
 3.7.  Normal and High Priority Counters ........................    9
 3.8.  IEEE 802.12 Training Frames ..............................   10
 3.9.  Mapping of IEEE 802.12 Managed Objects ...................   12
 4.  Definitions ................................................   14
 5.  Acknowledgements ...........................................   30
 6.  References .................................................   30
 7.  Security Considerations ....................................   31
 8.  Author's Address ...........................................   31

1.  Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in TCP/IP-based internets.
   In particular, it defines objects for managing network interfaces
   based on IEEE 802.12.




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


2.  Object Definitions

   Management information is viewed as a collection of managed objects,
   residing in a virtual information store, termed the Management
   Information Base (MIB).  Collections of related objects are defined
   in MIB modules.  MIB modules are written using a subset of Abstract
   Syntax Notation One (ASN.1) [1] termed the Structure of Management
   Information (SMI) [2].  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 refer to the
   object type.

3.  Overview

   Instances of these object types represent attributes of an interface
   to an IEEE 802.12 communications medium.  At present, IEEE 802.12
   media are identified by one value of the ifType object in the
   Internet-standard MIB:

      ieee80212(55)

   For this interface, the value of the ifSpecific variable in the MIB-
   II [5] has the OBJECT IDENTIFIER value:

      dot12MIB    OBJECT IDENTIFIER ::= { transmission 45 }

   The values for the ifType object are defined by the IANAifType
   textual convention.  The Internet Assigned Numbers Authority (IANA)
   is responsible for the assignment of all Internet numbers, including
   new ifType values.  Therefore, IANA is responsible for maintaining
   the definition of this textual convention.  The current definition of
   the IANAifType textual convention is available from IANA's World Wide
   Web server at:

         http://www.iana.org/iana/

   The definitions presented here are based on the IEEE Standard
   802.12-1995, [6] Clause 13 "Layer management functions and services",
   and Annex C "GDMO Specifications for Demand Priority Managed
   Objects".  Implementors of these MIB objects should note that the
   IEEE document explicitly describes (in the form of Pascal pseudocode)
   when, where, and how various MAC attributes are measured.  The IEEE
   document also describes the effects of MAC actions that may be
   invoked by manipulating instances of the MIB objects defined here.





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


   To the extent that some of the attributes defined in [6] are
   represented by previously defined objects in the Internet-standard
   MIB [5] or in the Evolution of the Interfaces Group of MIB-II [7],
   such attributes are not redundantly represented by objects defined in
   this memo.  Among the attributes represented by objects defined in
   other memos are the number of octets transmitted or received on a
   particular interface, the MAC address of an interface, and multicast
   information associated with an interface.

3.1.  MAC Addresses

   All representations of MAC addresses in this MIB module, and in other
   related MIB modules (like RFC 1573), are in "canonical" order defined
   by 802.1a, i.e., as if it were transmitted least significant bit
   first.  This is true even if the interface is operating in token ring
   framing mode, which requires MAC addresses to be transmitted most
   significant bit first.

3.2.  Relation to RFC 1213

   This section applies only when this MIB is used in conjunction with
   the "old" (i.e., pre-RFC 1573) interface group.

   The relationship between an IEEE 802.12 interface and an interface in
   the context of the Internet-standard MIB is one-to-one.  As such, the
   value of an ifIndex object instance can be directly used to identify
   corresponding instances of the objects defined herein.

3.3.  Relation to RFC 1573

   RFC 1573, the Interface MIB Evolution, requires that any MIB which is
   an adjunct of the Interface MIB, clarify specific areas within the
   Interface MIB.  These areas are intentionally left vague in RFC 1573
   to avoid over constraining the MIB, thereby precluding management of
   certain media-types.

   An agent which implements this MIB module must support the
   ifGeneralGroup, ifStackGroup, ifHCPacketGroup, and ifRcvAddressGroup
   of RFC 1573.

   Section 3.3 of RFC 1573 enumerates several areas which a media-
   specific MIB must clarify.  In addition, there are some objects in
   RFC 1573 for which additional clarification of how to apply them to
   an IEEE 802.12 interface would be helpful.  Each of these areas is
   addressed in a following subsection.  The implementor is referred to
   RFC 1573 in order to understand the general intent of these areas.





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


3.3.1.  Layering Model

   For the typical usage of this MIB module, there will be no sub-layers
   "above" or "below" the 802.12 Interface.  However, this MIB module
   does not preclude such layering.

3.3.2.  Virtual Circuits

   This medium does not support virtual circuits and this area is not
   applicable to this MIB.

3.3.3.  ifTestTable

   This MIB does not define any tests for media instrumented by this
   MIB.  Implementation of the ifTestTable is not required.  An
   implementation may optionally implement the ifTestTable to execute
   vendor specific tests.

3.3.4.  ifRcvAddressTable

   This table contains all IEEE addresses, unicast, multicast, and
   broadcast, for which this interface will receive packets and forward
   them up to a higher layer entity for consumption.  In addition, when
   the interface is using 802.5 framing mode, the ifRcvAddressTable will
   contain the functional address mask.

   In the event that the interface is part of a MAC bridge, this table
   does not include unicast addresses which are accepted for possible
   forwarding out some other port.  This table is explicitly not
   intended to provide a bridge address filtering mechanism.

3.3.5.  ifPhysAddress

   This object contains the IEEE 802.12 address which is placed in the
   source-address field of any frames that originate at this interface.
   Usually this will be kept in ROM on the interface hardware.  Some
   systems may set this address via software.

   In a system where there are several such addresses the designer has a
   tougher choice.  The address chosen should be the one most likely to
   be of use to network management (e.g.  the address placed in ARP
   responses for systems which are primarily IP systems).

   If the designer truly can not choose, use of the factory-provided ROM
   address is suggested.

   If the address can not be determined, an octet string of zero length
   should be returned.



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


   The address is stored in binary in this object.  The address is
   stored in "canonical" bit order, that is, the Group Bit is positioned
   as the low-order bit of the first octet.  Thus, the first byte of a
   multicast address would have the bit 0x01 set.  This is true even
   when the interface is using token ring framing mode, which transmits
   addresses high-order bit first.

3.3.6.  Specific Interface MIB Objects

   The following table provides specific implementation guidelines for
   the interface group objects in the conformance groups listed above.

     Object                 Use for an 802.12 Interface

     ifIndex                Each 802.12 interface is represented by an
                            ifEntry.  Interface tables in this MIB
                            module are indexed by ifIndex.

     ifDescr                Refer to [7].

     ifType                 The IANA reserved value for 802.12 - 55.

     ifMtu                  The value of ifMtu on an 802.12 interface
                            will depend on the type of framing that is
                            in use on that interface.  Changing the
                            dot12DesiredFramingType may have the effect
                            of changing ifMtu after the next time that
                            the interface trains.  When
                            dot12CurrentFramingType is equal to
                            frameType88023, ifMtu will be equal to
                            1500.  When dot12CurrentFramingType is
                            equal to frameType88025, ifMtu will be
                            4464.

     ifSpeed                The speed of the interface in bits per
                            second.  For current 802.12
                            implementations, this will be equal to
                            100,000,000 (100 million).

     ifPhysAddress          See Section 3.3.5.











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


     ifAdminStatus          Write access is not required.  Support for
                            'testing' is not required.  Setting this
                            object to 'up' will cause dot12Commands to
                            be set to 'open'.  Setting this object to
                            'down' will cause dot12Commands to be set
                            to 'close'.  Setting dot12Commands to
                            'open' will set this object to 'up'.
                            Setting dot12Commands to 'close' will set
                            this object to 'down'.  Setting
                            dot12Commands to 'reset' will have no
                            effect on this object.

     ifOperStatus           When dot12Status is equal to 'opened', this
                            object will be equal to 'up'.  When
                            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.