diff options
Diffstat (limited to 'doc/rfc/rfc1398.txt')
| -rw-r--r-- | doc/rfc/rfc1398.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc1398.txt b/doc/rfc/rfc1398.txt new file mode 100644 index 0000000..5e38d97 --- /dev/null +++ b/doc/rfc/rfc1398.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group F. Kastenholz +Request for Comments: 1398 FTP Software, Inc. +Obsoletes: 1284 January 1993 + + + Definitions of Managed Objects for + the Ethernet-like Interface Types + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +Abstract + + 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 ethernet-like objects. + +Table of Contents + + 1. The Network Management Framework ...................... 1 + 2. Objects ............................................... 2 + 2.1 Format of Definitions ................................ 2 + 3. Overview .............................................. 3 + 4. Definitions ........................................... 4 + 4.1 The Ethernet-like Statistics Group ................... 4 + 4.2 The Ethernet-like Collision Statistics Group ......... 11 + 4.3 802.3 Tests .......................................... 12 + 4.4 802.3 Hardware Chipsets .............................. 14 + 5. Change Log ............................................ 14 + 6. Acknowledgements ...................................... 16 + 7. References ............................................ 16 + 8. Security Considerations ............................... 17 + 9. Author's Address ...................................... 17 + +1. The Network Management Framework + + The Internet-standard Network Management Framework consists of three + components. They are: + + STD 16/RFC 1155 [3] which defines the SMI, the mechanisms used for + describing and naming objects for the purpose of management. STD + 16/RFC 1212 [13] defines a more concise description mechanism, + which is wholly consistent with the SMI. + + + +Kastenholz [Page 1] + +RFC 1398 Ethernet-Like MIB January 1993 + + + RFC 1156 [4] which defines MIB-I, the core set of managed objects + for the Internet suite of protocols. STD 17/RFC 1213 [6] defines + MIB-II, an evolution of MIB-I based on implementation experience + and new operational requirements. + + STD 15/RFC 1157 [5] which defines the SNMP, the protocol used for + network access to managed objects. + + The Framework permits new objects to be defined for the purpose of + experimentation and evaluation. + +2. Objects + + 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) [7] + defined in the SMI. In particular, each object has a name, a syntax, + and an encoding. The name is an object identifier, an + administratively assigned name, which specifies an object type. 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 OBJECT + DESCRIPTOR, to also refer to the object type. + + The syntax of an object type defines the abstract data structure + corresponding to that object type. The ASN.1 language is used for + this purpose. However, the SMI [3] purposely restricts the ASN.1 + constructs which may be used. These restrictions are explicitly made + for simplicity. + + The encoding of an object type is simply how that object type is + represented using the object type's syntax. Implicitly tied to the + notion of an object type's syntax and encoding is how the object type + is represented when being transmitted on the network. + + The SMI specifies the use of the basic encoding rules of ASN.1 [8], + subject to the additional requirements imposed by the SNMP. + +2.1. Format of Definitions + + Section 4 contains contains the specification of all object types + contained in this MIB module. The object types are defined using the + conventions defined in the SMI, as amended by the extensions + specified in [13]. + + + + + + + +Kastenholz [Page 2] + +RFC 1398 Ethernet-Like MIB January 1993 + + +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 three values of the ifType object in the + Internet-standard MIB: + + ethernet-csmacd(6) + iso88023-csmacd(7) + starLan(11) + + For these interfaces, the value of the ifSpecific variable in the + MIB-II [6] has the OBJECT IDENTIFIER value: + + dot3 OBJECT IDENTIFER ::= { transmission 7 } + + The definitions presented here are based on the IEEE 802.3 Layer + Management Specification [9], as originally interpreted by Frank + Kastenholz of Interlan in [10]. 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 [9] are + represented by previously defined objects in the Internet- standard + MIB or in the Generic Interface Extensions MIB [11], 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. + + 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. + + + + + + + + + + + +Kastenholz [Page 3] + +RFC 1398 Ethernet-Like MIB January 1993 + + +4. Definitions + + RFC1398-MIB DEFINITIONS ::= BEGIN + + + IMPORTS + Counter, Gauge + FROM RFC1155-SMI + transmission + FROM RFC1213-MIB + OBJECT-TYPE + FROM RFC-1212; + + -- This MIB module uses the extended OBJECT-TYPE macro as + -- defined in RFC-1212. + + -- this is the MIB module for ethernet-like objects + + dot3 OBJECT IDENTIFIER ::= { transmission 7 } + + -- { dot3 1 } is obsolete and has been deleted. + +4.1. The Ethernet-like Statistics Group + + + -- the Ethernet-like Statistics group + + -- Implementation of this group is mandatory + + dot3StatsTable OBJECT-TYPE + SYNTAX SEQUENCE OF Dot3StatsEntry + ACCESS not-accessible + STATUS mandatory + DESCRIPTION + "Statistics for a collection of ethernet-like + interfaces attached to a particular system." + ::= { dot3 2 } + + + dot3StatsEntry OBJECT-TYPE + SYNTAX Dot3StatsEntry + ACCESS not-accessible + STATUS mandatory + DESCRIPTION + "Statistics for a particular interface to an + ethernet-like medium." + INDEX { dot3StatsIndex } + ::= { dot3StatsTable 1 } + + + +Kastenholz [Page 4] + +RFC 1398 Ethernet-Like MIB January 1993 + + + Dot3StatsEntry ::= SEQUENCE { + dot3StatsIndex + INTEGER, + dot3StatsAlignmentErrors + Counter, + dot3StatsFCSErrors + Counter, + dot3StatsSingleCollisionFrames + Counter, + dot3StatsMultipleCollisionFrames + Counter, + dot3StatsSQETestErrors + Counter, + dot3StatsDeferredTransmissions + Counter, + dot3StatsLateCollisions + Counter, + dot3StatsExcessiveCollisions + Counter, + dot3StatsInternalMacTransmitErrors + Counter, + dot3StatsCarrierSenseErrors + Counter, + dot3StatsFrameTooLongs + Counter, + dot3StatsInternalMacReceiveErrors + Counter + } + + dot3StatsIndex OBJECT-TYPE + SYNTAX INTEGER + ACCESS read-only + STATUS mandatory + DESCRIPTION + "An index value that uniquely identifies an + interface to an ethernet-like medium. The + interface identified by a particular value of + this index is the same interface as identified + by the same value of ifIndex." + ::= { dot3StatsEntry 1 } + + + dot3StatsAlignmentErrors OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "A count of frames received on a particular + + + +Kastenholz [Page 5] + +RFC 1398 Ethernet-Like MIB January 1993 + + + interface that are not an integral number of + octets in length and do not pass the FCS check. + + The count represented by an instance of this + object is incremented when the alignmentError + status is returned by the MAC service to the + LLC (or other MAC user). Received frames for + which multiple error conditions obtain are, + according to the conventions of IEEE 802.3 + Layer Management, counted exclusively according + to the error status presented to the LLC." + REFERENCE + "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 2 } + + + dot3StatsFCSErrors OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "A count of frames received on a particular + interface that are an integral number of octets + in length but do not pass the FCS check. + + The count represented by an instance of this + object is incremented when the frameCheckError + status is returned by the MAC service to the + LLC (or other MAC user). Received frames for + which multiple error conditions obtain are, + according to the conventions of IEEE 802.3 + Layer Management, counted exclusively according + to the error status presented to the LLC." + REFERENCE + "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 3 } + + + dot3StatsSingleCollisionFrames OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "A count of successfully transmitted frames on + a particular interface for which transmission + is inhibited by exactly one collision. + + A frame that is counted by an instance of this + + + +Kastenholz [Page 6] + +RFC 1398 Ethernet-Like MIB January 1993 + + + object is also counted by the corresponding + instance of either the ifOutUcastPkts or + ifOutNUcastPkts object and is not counted by + the corresponding instance of the + dot3StatsMultipleCollisionFrames object." + REFERENCE + "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 4 } + + + dot3StatsMultipleCollisionFrames OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "A count of successfully transmitted frames on + a particular interface for which transmission + is inhibited by more than one collision. + + A frame that is counted by an instance of this + object is also counted by the corresponding + instance of either the ifOutUcastPkts or + ifOutNUcastPkts object and is not counted by + the corresponding instance of the + dot3StatsSingleCollisionFrames object." + REFERENCE + "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 5 } + + + dot3StatsSQETestErrors OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "A count of times that the SQE TEST ERROR + message is generated by the PLS sublayer for a + particular interface. The SQE TEST ERROR + message is defined in section 7.2.2.2.4 of + ANSI/IEEE 802.3-1985 and its generation is + described in section 7.2.4.6 of the same + document." + REFERENCE + "ANSI/IEEE Std 802.3-1985 Carrier Sense + Multiple Access with Collision Detection Access + Method and Physical Layer Specifications" + ::= { dot3StatsEntry 6 } + + + + +Kastenholz [Page 7] + +RFC 1398 Ethernet-Like MIB January 1993 + + + dot3StatsDeferredTransmissions OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "A count of frames for which the first + transmission attempt on a particular interface + is delayed because the medium is busy. + + The count represented by an instance of this + object does not include frames involved in + collisions." + REFERENCE + "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 7 } + + + dot3StatsLateCollisions OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "The number of times that a collision is + detected on a particular interface later than + 512 bit-times into the transmission of a + packet. + + Five hundred and twelve bit-times corresponds + to 51.2 microseconds on a 10 Mbit/s system. A + (late) collision included in a count + represented by an instance of this object is + also considered as a (generic) collision for + purposes of other collision-related + statistics." + REFERENCE + "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 8 } + + + dot3StatsExcessiveCollisions OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "A count of frames for which transmission on a + particular interface fails due to excessive + collisions." + + + + +Kastenholz [Page 8] + +RFC 1398 Ethernet-Like MIB January 1993 + + + REFERENCE + "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 9 } + + + dot3StatsInternalMacTransmitErrors OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "A count of frames for which transmission on a + particular interface fails due to an internal + MAC sublayer transmit error. A frame is only + counted by an instance of this object if it is + not counted by the corresponding instance of + either the dot3StatsLateCollisions object, the + dot3StatsExcessiveCollisions object, or the + dot3StatsCarrierSenseErrors object. + + The precise meaning of the count represented by + an instance of this object is implementation- + specific. In particular, an instance of this + object may represent a count of transmission + errors on a particular interface that are not + otherwise counted." + REFERENCE + "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 10 } + + + dot3StatsCarrierSenseErrors OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "The number of times that the carrier sense + condition was lost or never asserted when + attempting to transmit a frame on a particular + interface. + + The count represented by an instance of this + object is incremented at most once per + transmission attempt, even if the carrier sense + condition fluctuates during a transmission + attempt." + REFERENCE + "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 11 } + + + +Kastenholz [Page 9] + +RFC 1398 Ethernet-Like MIB January 1993 + + + -- { dot3StatsEntry 12 } is not assigned + + dot3StatsFrameTooLongs OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "A count of frames received on a particular + interface that exceed the maximum permitted + frame size. + + The count represented by an instance of this + object is incremented when the frameTooLong + status is returned by the MAC service to the + LLC (or other MAC user). Received frames for + which multiple error conditions obtain are, + according to the conventions of IEEE 802.3 + Layer Management, counted exclusively according + to the error status presented to the LLC." + REFERENCE + "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 13 } + + + + -- { dot3StatsEntry 14 } is not assigned + + + -- { dot3StatsEntry 15 } is not assigned + + dot3StatsInternalMacReceiveErrors OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "A count of frames for which reception on a + particular interface fails due to an internal + MAC sublayer receive error. A frame is only + counted by an instance of this object if it is + not counted by the corresponding instance of + either the dot3StatsFrameTooLongs object, the + dot3StatsAlignmentErrors object, or the + dot3StatsFCSErrors object. + + The precise meaning of the count represented by + an instance of this object is implementation- + specific. In particular, an instance of this + object may represent a count of receive errors + + + +Kastenholz [Page 10] + +RFC 1398 Ethernet-Like MIB January 1993 + + + on a particular interface that are not + otherwise counted." + REFERENCE + "IEEE 802.3 Layer Management" + ::= { dot3StatsEntry 16 } + +4.2. The Ethernet-like Collision Statistics Group + + + -- the Ethernet-like Collision Statistics group + + -- Implementation of this group is optional; it is appropriate + -- for all systems which have the necessary metering + + dot3CollTable OBJECT-TYPE + SYNTAX SEQUENCE OF Dot3CollEntry + ACCESS not-accessible + STATUS mandatory + DESCRIPTION + "A collection of collision histograms for a + particular set of interfaces." + ::= { dot3 5 } + + + dot3CollEntry OBJECT-TYPE + SYNTAX Dot3CollEntry + ACCESS not-accessible + STATUS mandatory + DESCRIPTION + "A cell in the histogram of per-frame + collisions for a particular interface. An + instance of this object represents the + frequency of individual MAC frames for which + the transmission (successful or otherwise) on a + particular interface is accompanied by a + particular number of media collisions." + INDEX { dot3CollIndex, dot3CollCount } + ::= { dot3CollTable 1 } + + + + Dot3CollEntry ::= SEQUENCE { + dot3CollIndex + INTEGER, + dot3CollCount + INTEGER, + dot3CollFrequencies + Counter + + + +Kastenholz [Page 11] + +RFC 1398 Ethernet-Like MIB January 1993 + + + } + + + dot3CollIndex OBJECT-TYPE + SYNTAX INTEGER + ACCESS read-only + STATUS mandatory + DESCRIPTION + "The index value that uniquely identifies the + interface to which a particular collision + histogram cell pertains. The interface + identified by a particular value of this index + is the same interface as identified by the same + value of ifIndex." + ::= { dot3CollEntry 1 } + + + dot3CollCount OBJECT-TYPE + SYNTAX INTEGER (1..16) + ACCESS read-only + STATUS mandatory + DESCRIPTION + "The number of per-frame media collisions for + which a particular collision histogram cell + represents the frequency on a particular + interface." + ::= { dot3CollEntry 2 } + + + dot3CollFrequencies OBJECT-TYPE + SYNTAX Counter + ACCESS read-only + STATUS mandatory + DESCRIPTION + "A count of individual MAC frames for which the + transmission (successful or otherwise) on a + particular interface is accompanied by a + particular number of media collisions." + ::= { dot3CollEntry 3 } + + +4.3. 802.3 Tests + + + -- 802.3 Tests + + -- The ifExtnsTestTable defined in RFC 1229 provides a common + -- means for a manager to test any interface corresponding to + + + +Kastenholz [Page 12] + +RFC 1398 Ethernet-Like MIB January 1993 + + + -- a value of ifIndex. + + -- At this time, one well known test (testFullDuplexLoopBack) is + -- defined in RFC 1229. For ethernet-like interfaces, this test + -- configures the MAC chip and executes an internal loopback + -- test of memory and the MAC chip logic. This loopback test can + -- only be executed if the interface is offline. Once the test + -- has completed, the MAC chip should be reinitialized for network + -- operation, but it should remain offline. + + -- If an error occurs during a test, the object ifExtnsTestResult + -- (defined in RFC 1229) will be set to failed(7). The following + -- two OBJECT IDENTIFIERs may be used to provided more + -- information as values for the object ifExtnsTestCode in + -- RFC 1229: + + dot3Errors OBJECT IDENTIFIER ::= { dot3 7 } + + -- couldn't initialize MAC chip for test + dot3ErrorInitError OBJECT IDENTIFIER ::= { dot3Errors 1 } + + -- expected data not received (or not + -- received correctly) in loopback test + dot3ErrorLoopbackError OBJECT IDENTIFIER ::= { dot3Errors 2 } + + -- Tests + -- TDR Test + + -- Another test, specific to ethernet-like interfaces with the + -- exception of 10BaseT and 10BaseF, is Time-domain Reflectometry + (TDR). + -- The TDR value may be useful in determining the approximate + distance + -- to a cable fault. It is advisable to repeat this test to + check for + -- a consistent resulting TDR value, to verify that there is a + fault. + + dot3Tests OBJECT IDENTIFIER ::= { dot3 6 } + dot3TestTdr OBJECT IDENTIFIER ::= { dot3Tests 1 } + + -- A TDR test returns as its result the time interval, measured + -- in 10 MHz ticks or 100 nsec units, between the start of + -- TDR test transmission and the subsequent detection of a + -- collision or deassertion of carrier. On successful completion + -- of a TDR test, the appropriate instance of ifExtnsTestResult + -- contains the OBJECT IDENTIFIER of the MIB object which + -- contains the value of this time interval. + + + +Kastenholz [Page 13] + +RFC 1398 Ethernet-Like MIB January 1993 + + +4.4. 802.3 Hardware Chipsets + + + -- 802.3 Hardware Chipsets + + -- The object ifExtnsChipSet is provided in RFC 1229 to identify + -- the MAC hardware used to communcate on an interface. The + -- following hardware chipsets are provided for 802.3: + + dot3ChipSets OBJECT IDENTIFIER ::= { dot3 8 } + dot3ChipSetAMD OBJECT IDENTIFIER ::= { dot3ChipSets 1 } + dot3ChipSetAMD7990 OBJECT IDENTIFIER ::= { dot3ChipSetAMD 1 } + dot3ChipSetAMD79900 OBJECT IDENTIFIER ::= { dot3ChipSetAMD 2 } + + dot3ChipSetIntel OBJECT IDENTIFIER ::= { dot3ChipSets 2 } + dot3ChipSetIntel82586 OBJECT IDENTIFIER ::= { dot3ChipSetIntel 1 } + dot3ChipSetIntel82596 OBJECT IDENTIFIER ::= { dot3ChipSetIntel 2 } + dot3ChipSetSeeq OBJECT IDENTIFIER ::= { dot3ChipSets 3 } + dot3ChipSetSeeq8003 OBJECT IDENTIFIER ::= { dot3ChipSetSeeq 1 } + + dot3ChipSetNational OBJECT IDENTIFIER ::= { dot3ChipSets 4 } + dot3ChipSetNational8390 OBJECT IDENTIFIER ::= + { dot3ChipSetNational 1 } + dot3ChipSetNationalSonic OBJECT IDENTIFIER ::= + { dot3ChipSetNational 2 } + + dot3ChipSetFujitsu OBJECT IDENTIFIER ::= { dot3ChipSets 5 } + dot3ChipSetFujitsu86950 OBJECT IDENTIFIER ::= + { dot3ChipSetFujitsu 1 } + dot3ChipSetFujitsu86960 OBJECT IDENTIFIER ::= + { dot3ChipSetFujitsu 2 } + + -- For those chipsets not represented above, OBJECT IDENTIFIER + -- assignment is required in other documentation, e.g., assignment + -- within that part of the registration tree delegated to + -- individual enterprises (see RFC 1155). + + END + +5. Change Log + + (1) Replace old "Historical Perspective" boilerplate with the + new "The Network Management Framework" boilerplate. + + (2) Remove the "slime text". + + (3) Updated the reference to the Interface Extensions mib to + reflect its new RFC status. + + + +Kastenholz [Page 14] + +RFC 1398 Ethernet-Like MIB January 1993 + + + (4) Change the status of the memo section to hold the new + suggested text. + + (5) References in ASN.1 comments were changed from the [#] + form to name the actual document being referred to. These + references are now meaningful when the ASN.1 is read + outside of the RFC. + + (6) The IMPORTS section of the ASN.1 has been updated to + reflect that the OBJECT-TYPE macro is imported from RFC- + 1212. + + (7) The the Generic Ethernet-like group, containing + dot3Index, dot3InitializeMac, dot3MacSubLayerStatus, + dot3MulticastReceiveStatus, dot3TxEnabled, and + dot3TestTdrValue has been deprecated as a result of the + implementation experience presented at the San Diego IETF + meeting. + + (8) dot3StatsInRangeLengthErrors and + dot3StatsOutOfRangeLengthFields have been deprecated as a + result of the implementation experience presented at the + San Diego IETF meeting. + + (9) Update the acknowledgements section to reflect this + document's history, etc. + + (10) REFERENCE clauses have been added to all of the MIB + objects which are being retained. + + 12 August 1992 + + (1) Removed all deprecated objects. + + (2) Rephrased the description of the TDR test OID to reflect + the fact that dot3TestTdrValue is no more. + ifExtnsTestResult still points to the object containing + the result, the text simply does not refer to + dot3TestTdrValue. I could have deleted the Test, but the + OID should then remain reserved. I figured that it would + be just as easy to rephrase the definition of the test. + + 13 august 1992 + + (1) Add fuji. 86960 + + + + + + +Kastenholz [Page 15] + +RFC 1398 Ethernet-Like MIB January 1993 + + +6. Acknowledgements + + This document was produced by the Ethernet MIB Working Group. + + This document is based on the Proposed Standard Ethernet MIB, RFC + 1284 [14], of which John Cook of Chipcom was the editor. The + Ethernet MIB Working Group gathered implementation experience of the + variables specified in RFC 1284 and used that information to develop + this revised MIB. + + RFC 1284, in turn, is based on a document written by Frank Kastenholz + of Interlan entitled IEEE 802.3 Layer Management Draft M compatible + MIB for TCP/IP Networks [10]. This document has been modestly + reworked, initially by the SNMP Working Group, and then by the + Transmission Working Group, to reflect the current conventions for + defining objects for MIB interfaces. James Davin, of the MIT + Laboratory for Computer Science, and Keith McCloghrie of Hughes LAN + Systems, contributed to later drafts of this memo. Marshall Rose of + Performance Systems International, Inc. converted the document into + its current concise format. Anil Rijsinghani of DEC contributed text + that more adequately describes the TDR test. Thanks to Frank + Kastenholz of Interlan and Louis Steinberg of IBM for their + experimentation. + +7. References + + [1] Cerf, V., "IAB Recommendations for the Development of Internet + Network Management Standards", RFC 1052, NRI, April 1988. + + [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review + Group", RFC 1109, NRI, August 1989. + + [3] Rose M., and K. McCloghrie, "Structure and Identification of + Management Information for TCP/IP-based internets", STD 16, RFC + 1155, Performance Systems International, Hughes LAN Systems, May + 1990. + + [4] McCloghrie K., and M. Rose, "Management Information Base for + Network Management of TCP/IP-based internets", RFC 1156, Hughes + LAN Systems, Performance Systems International, May 1990. + + [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple + Network Management Protocol", STD 15, RFC 1157, SNMP Research, + Performance Systems International, Performance Systems + International, MIT Laboratory for Computer Science, May 1990. + + [6] Rose M., Editor, "Management Information Base for Network + Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, + + + +Kastenholz [Page 16] + +RFC 1398 Ethernet-Like MIB January 1993 + + + Performance Systems International, March 1991. + + [7] Information processing systems - Open Systems Interconnection - + Specification of Abstract Syntax Notation One (ASN.1), + International Organization for Standardization, International + Standard 8824, December 1987. + + [8] Information processing systems - Open Systems Interconnection - + Specification of Basic Encoding Rules for Abstract Notation One + (ASN.1), International Organization for Standardization, + International Standard 8825, December 1987. + + [9] IEEE, "IEEE 802.3 Layer Management", November 1988. + + [10] Kastenholz, F., "IEEE 802.3 Layer Management Draft compatible MIB + for TCP/IP Networks", electronic mail message to mib- + wg@nnsc.nsf.net, 9 June 1989. + + [11] McCloghrie, K., Editor, Extensions to the Generic-Interface MIB, + RFC 1229, Hughes LAN Systems, Inc., May 1991. + + [12] IEEE, "Carrier Sense Multiple Access with Collision Detection + (CSMA/CD) Access Method and Physical Layer Specifications", + ANSI/IEEE Std 802.3-1985. + + [13] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", + STD 16, RFC 1212, Performance Systems International, Hughes LAN + Systems, March 1991. + + [14] Cook, J., Editor, "Definitions of Managed Objects for Ethernet- + Like Interface Types", RFC 1284, Chipcom Corporation, December + 1991. + +8. Security Considerations + + Security issues are not discussed in this memo. + +9. Author's Address + + Frank Kastenholz + 2 High Street + North Andover, MA 01845-2620 + + Phone: (508) 685-4000 + EMail: kasten@ftp.com + + + + + + +Kastenholz [Page 17] +
\ No newline at end of file |