rfc2665.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,489 行 · 第 1/5 页

Network Working Group                                           J. Flick
Request for Comments: 2665                       Hewlett-Packard Company
Obsoletes: 2358                                               J. Johnson
Category: Standards Track                               RedBack Networks
                                                             August 1999


                   Definitions of Managed Objects for
                   the Ethernet-like Interface Types

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.

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   This memo obsoletes RFC 2358, "Definitions of Managed Objects for the
   Ethernet-like Interface Types".  This memo extends that specification
   by including management information useful for the management of 1000
   Mb/s and full-duplex Ethernet interfaces.

   Ethernet technology, as defined by the 802.3 Working Group of the
   IEEE, continues to evolve, with scalable increases in speed, new
   types of cabling and interfaces, and new features.  This evolution
   may require changes in the managed objects in order to reflect this
   new functionality.  This document, as with other documents issued by
   this working group, reflects a certain stage in the evolution of
   Ethernet technology.  In the future, this document might be revised,
   or new documents might be issued by the Ethernet Interfaces and Hub
   MIB Working Group, in order to reflect the evolution of Ethernet
   technology.










Flick & Johnson             Standards Track                     [Page 1]

RFC 2665                   Ethernet-Like MIB                 August 1999


Table of Contents

   1. Introduction ................................................    2
   2.  The SNMP Management Framework ..............................    3
   3.  Overview ...................................................    4
   3.1.  Relation to MIB-2 ........................................    4
   3.2.  Relation to the Interfaces MIB ...........................    5
   3.2.1.  Layering Model .........................................    5
   3.2.2.  Virtual Circuits .......................................    5
   3.2.3.  ifTestTable ............................................    5
   3.2.4.  ifRcvAddressTable ......................................    6
   3.2.5.  ifPhysAddress ..........................................    6
   3.2.6.  ifType .................................................    6
   3.2.7.  Specific Interface MIB Objects .........................    7
   3.3.  Relation to the 802.3 MAU MIB ............................   11
   3.4.  dot3StatsEtherChipSet ....................................   11
   3.5.  Mapping of IEEE 802.3 Managed Objects ....................   12
   4.  Definitions ................................................   16
   5.  Intellectual Property ......................................   39
   6.  Acknowledgements ...........................................   40
   7.  References .................................................   41
   8.  Security Considerations ....................................   43
   9.  Authors' Addresses .........................................   44
   A.  Change Log .................................................   45
   A.1.  Changes since RFC 2358 ...................................   45
   A.2.  Changes between RFC 1650 and RFC 2358 ....................   46
   B.  Full Copyright Statement ...................................   47

1. Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines objects for managing Ethernet-like
   interfaces.

   This memo also includes a MIB module.  This MIB module extends the
   list of managed objects specified in the earlier version of this MIB:
   RFC 2358 [23].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [26].









Flick & Johnson             Standards Track                     [Page 2]

RFC 2665                   Ethernet-Like MIB                 August 1999


2.  The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

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

   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 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The
       second version, called SMIv2, is described in STD 58, RFC 2578
       [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7].

   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 [8]. A second version of the SNMP
       message protocol, which is not an Internet standards track
       protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC
       1906 [10].  The third version of the message protocol is called
       SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574
       [12].

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

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

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo 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 (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.





Flick & Johnson             Standards Track                     [Page 3]

RFC 2665                   Ethernet-Like MIB                 August 1999


3.  Overview

   Instances of these object types represent attributes of an interface
   to an ethernet-like communications medium.  At present, ethernet-like
   media are identified by the following values of the ifType object in
   the Interfaces MIB [25]:

            ethernetCsmacd(6)
            iso88023Csmacd(7)
            starLan(11)

   The definitions presented here are based on Section 30, "10 Mb/s, 100
   Mb/s and 1000 Mb/s Management", and Annex 30A, "GDMO Specification
   for 802.3 managed object classes" of IEEE Std. 802.3, 1998 Edition
   [16], as originally interpreted by Frank Kastenholz then of Interlan
   in [17].  Implementors of these MIB objects should note that IEEE
   Std. 802.3 [16] 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.

   To the extent that some of the attributes defined in [16] are
   represented by previously defined objects in MIB-2 [24] or in the
   Interfaces MIB [25], 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 number of frames
   transmitted or received on a particular interface, the promiscuous
   status of an interface, the MAC address of an interface, and
   multicast information associated with an interface.

3.1.  Relation to MIB-2

   This section applies only when this MIB is used in conjunction with
   the "old" (RFC 1213) [24] interface group.

   The relationship between an ethernet-like interface and an interface
   in the context of MIB-2 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.

   For agents which implement the (now deprecated) ifSpecific object, an
   instance of that object that is associated with an ethernet-like
   interface has the OBJECT IDENTIFIER value:

         dot3    OBJECT IDENTIFER ::= { transmission 7 }





Flick & Johnson             Standards Track                     [Page 4]

RFC 2665                   Ethernet-Like MIB                 August 1999


3.2.  Relation to the Interfaces MIB

   The Interface MIB [25] requires that any MIB which is an adjunct of
   the Interface MIB clarify specific areas within the Interface MIB.
   These areas were intentionally left vague in the Interface MIB to
   avoid over constraining the MIB, thereby precluding management of
   certain media-types.

   Section 3.3 of [25] enumerates several areas which a media-specific
   MIB must clarify.  Each of these areas is addressed in a following
   subsection.  The implementor is referred to [25] in order to
   understand the general intent of these areas.

3.2.1.  Layering Model

   This MIB does not provide for layering.  There are no sublayers.

   EDITOR'S NOTE:

   One could foresee the development of an 802.2 and enet-transceiver
   MIB.  They could be higher and lower sublayers, respectively.  All
   that THIS document should do is allude to the possibilities and urge
   the implementor to be aware of the possibility and that they may have
   requirements which supersede the requirements in this document.

3.2.2.  Virtual Circuits

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

3.2.3.  ifTestTable

   This MIB defines two tests for media which are instrumented with this
   MIB; TDR and Loopback.  Implementation of these tests is not
   required.  Many common interface chips do not support one or both of
   these tests.

   These two tests are provided as a convenience, allowing a common
   method to invoke the test.

   Standard MIBs do not include objects in which to return the results
   of the TDR test.  Any needed objects MUST be provided in the vendor
   specific MIB.

   Note that the ifTestTable is now deprecated.  Work is underway to
   define a replacement MIB for system and interface testing.  It is
   expected that the tests defined in this document will be usable in
   this replacement MIB.



Flick & Johnson             Standards Track                     [Page 5]

RFC 2665                   Ethernet-Like MIB                 August 1999


3.2.4.  ifRcvAddressTable

   This table contains all IEEE 802.3 addresses, unicast, multicast, and
   broadcast, for which this interface will receive packets and forward
   them up to a higher layer entity for local consumption.  The format
   of the address, contained in ifRcvAddressAddress, is the same as for
   ifPhysAddress.

   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.