rfc2358.txt

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

Network Working Group                                           J. Flick
Request for Comments: 2358                       Hewlett-Packard Company
Obsoletes: 1650                                               J. Johnson
Category: Standards Track                               RedBack Networks
                                                               June 1998


                   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 (1998).  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 1650 "Definitions of Managed Objects for the
   Ethernet-like Interface Types using SMIv2".  This memo extends that
   specification by including management information useful for the
   management of 100 Mb/s 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, reflect 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 2358         MIB for Ethernet-like Interface Types         June 1998


Table of Contents

   1. Introduction ................................................    2
   2.  The SNMP Network Management Framework ......................    2
   2.1.  Object Definitions .......................................    3
   3.  Overview ...................................................    3
   3.1.  Relation to MIB-2 ........................................    4
   3.2.  Relation to the Interfaces MIB ...........................    4
   3.2.1.  Layering Model .........................................    4
   3.2.2.  Virtual Circuits .......................................    4
   3.2.3.  ifTestTable ............................................    5
   3.2.4.  ifRcvAddressTable ......................................    5
   3.2.5.  ifPhysAddress ..........................................    5
   3.2.6.  ifType .................................................    6
   3.2.7.  Specific Interface MIB Objects .........................    7
   3.3.  Relation to the 802.3 MAU MIB ............................   10
   3.4.  Mapping of IEEE 802.3 Managed Objects ....................   10
   4.  Definitions ................................................   11
   5.  Intellectual Property ......................................   34
   6.  Acknowledgements ...........................................   34
   7.  References .................................................   35
   8.  Security Considerations ....................................   36
   9.  Authors' Addresses .........................................   37
   A.  Change Log .................................................   38
   B.  Full Copyright Statement ...................................   39

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:
   RFC1650 [11].

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

2.  The SNMP Network Management Framework

   The SNMP Network Management Framework consists of several components.
   For the purpose of this specification, the applicable components of
   the Framework are the SMI and related documents [2, 3, 4], which
   define the mechanisms used for describing and naming objects for the
   purpose of management.



Flick & Johnson             Standards Track                     [Page 2]

RFC 2358         MIB for Ethernet-like Interface Types         June 1998


   The Framework permits new objects to be defined for the purpose of
   experimentation and evaluation.

2.1.  Object Definitions

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the subset of Abstract Syntax Notation One (ASN.1) [1]
   defined in the SMI [2].  In particular, each object 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 ethernet-like communications medium.  At present, ethernet-like
   media are identified by the following values of the ifType object in
   the Interfaces MIB [12]:

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

   The definitions presented here are based on the IEEE 802.3 Layer
   Management Specification [5], as originally interpreted by Frank
   Kastenholz then of Interlan in [7].  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.

   To the extent that some of the attributes defined in [5] are
   represented by previously defined objects in MIB-2 [16] or in the
   Interfaces MIB [12], 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.







Flick & Johnson             Standards Track                     [Page 3]

RFC 2358         MIB for Ethernet-like Interface Types         June 1998


3.1.  Relation to MIB-2

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

   The relationship between an ethernet-like 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.

   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 }

3.2.  Relation to the Interfaces MIB

   The Interface MIB [12] 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 [12] 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 [12] 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.






Flick & Johnson             Standards Track                     [Page 4]

RFC 2358         MIB for Ethernet-like Interface Types         June 1998


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.

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.

3.2.5.  ifPhysAddress

   This object contains the IEEE 802.3 address which is placed in the
   source-address field of any Ethernet, Starlan, or IEEE 802.3 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 chose, use of the factory- provided ROM
   address is suggested.




Flick & Johnson             Standards Track                     [Page 5]

RFC 2358         MIB for Ethernet-like Interface Types         June 1998


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

   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.

3.2.6.  ifType

   This MIB applies to interfaces which have any of the following ifType
   values:

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

   It is RECOMMENDED that all Ethernet-like interfaces use an ifType of
   ethernetCsmacd(6) regardless of the speed that the interface is
   running or the link-layer encapsulation in use.  iso88023Csmacd(7)
   and starLan(11) are supported for backwards compatability.

   There are two other interface types defined in the IANAifType-MIB for
   100 Mbit Ethernet.  They are fastEther(62), and fastEtherFX(69).
   This document takes the position that an Ethernet is an Ethernet, and
   Ethernet interfaces SHOULD always have the same value of ifType.
   Information on the particular flavor of Ethernet that an interface is
   running is available from ifSpeed in the Interfaces MIB, and
   ifMauType in the 802.3 MAU MIB.  An Ethernet-like interface SHOULD
   NOT use the fastEther(62) or fastEtherFX(69) ifTypes.

   Interfaces with any of the supported ifType values map to the
   EtherLike-MIB in the same manner.  Which compliance statement an