As per Relevance of the word identifier, we have this rfc below:











Network Working Group F.
Request for Comments: 1398 FTP Software, Inc
Obsoletes: 1284 January 1993


Definitions of Managed Objects
the Ethernet-like Interface

Status of this

This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited



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

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

The Internet-standard Network Management Framework consists of
components. They are

STD 16/RFC 1155 [3] which defines the SMI, the mechanisms used
describing and naming objects for the purpose of management.
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
for the Internet suite of protocols. STD 17/RFC 1213 [6]
MIB-II, an evolution of MIB-I based on implementation
and new operational requirements

STD 15/RFC 1157 [5] which defines the SNMP, the protocol used
network access to managed objects

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

2.

Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
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,
administratively assigned name, which specifies an object type.
object type together with an object instance serves to
identify a specific instantiation of the object. For
convenience, we often use a textual string, termed the
DESCRIPTOR, to also refer to the object type

The syntax of an object type defines the abstract data
corresponding to that object type. The ASN.1 language is used
this purpose. However, the SMI [3] purposely restricts the ASN.1
constructs which may be used. These restrictions are explicitly
for simplicity

The encoding of an object type is simply how that object type
represented using the object type's syntax. Implicitly tied to
notion of an object type's syntax and encoding is how the object
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

Section 4 contains contains the specification of all object
contained in this MIB module. The object types are defined using
conventions defined in the SMI, as amended by the
specified in [13].







Kastenholz [Page 2]

RFC 1398 Ethernet-Like MIB January 1993


3.

Instances of these object types represent attributes of an
to an ethernet-like communications medium. At present, ethernet-
media are identified by three values of the ifType object in
Internet-standard MIB

ethernet-csmacd(6)
iso88023-csmacd(7)
starLan(11)

For these interfaces, the value of the ifSpecific variable in
MIB-II [6] has the OBJECT IDENTIFIER value

dot3 OBJECT IDENTIFER ::= { transmission 7 }

The definitions presented here are based on the IEEE 802.3
Management Specification [9], as originally interpreted by
Kastenholz of Interlan in [10]. Implementors of these MIB
should note that the IEEE document explicitly describes (in the
of Pascal pseudocode) when, where, and how various MAC attributes
measured. The IEEE document also describes the effects of
actions that may be invoked by manipulating instances of the
objects defined here

To the extent that some of the attributes defined in [9]
represented by previously defined objects in the Internet-
MIB or in the Generic Interface Extensions MIB [11], such
are not redundantly represented by objects defined in this memo
Among the attributes represented by objects defined in other
are the number of octets transmitted or received on a
interface, the number of frames transmitted or received on
particular interface, the promiscuous status of an interface, the
address of an interface, and multicast information associated with
interface

The relationship between an ethernet-like interface and an
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
identify corresponding instances of the objects defined herein











Kastenholz [Page 3]

RFC 1398 Ethernet-Like MIB January 1993


4.

RFC1398-MIB DEFINITIONS ::=



Counter,
FROM RFC1155-

FROM RFC1213-
OBJECT-
FROM RFC-1212;

-- This MIB module uses the extended OBJECT-TYPE macro
-- defined in RFC-1212.

-- this is the MIB module for ethernet-like

dot3 OBJECT IDENTIFIER ::= { transmission 7 }

-- { dot3 1 } is obsolete and has been deleted

4.1. The Ethernet-like Statistics


-- the Ethernet-like Statistics

-- Implementation of this group is

dot3StatsTable OBJECT-
SYNTAX SEQUENCE OF Dot3
ACCESS not-
STATUS

"Statistics for a collection of ethernet-
interfaces attached to a particular system."
::= { dot3 2 }


dot3StatsEntry OBJECT-
SYNTAX Dot3
ACCESS not-
STATUS

"Statistics for a particular interface to
ethernet-like medium."
INDEX { dot3StatsIndex }
::= { dot3StatsTable 1 }



Kastenholz [Page 4]

RFC 1398 Ethernet-Like MIB January 1993


Dot3StatsEntry ::= SEQUENCE {
dot3
INTEGER
dot3
Counter
dot3
Counter
dot3
Counter
dot3
Counter
dot3
Counter
dot3
Counter
dot3
Counter
dot3
Counter
dot3
Counter
dot3
Counter
dot3
Counter
dot3

}

dot3StatsIndex OBJECT-
SYNTAX
ACCESS read-
STATUS

"An index value that uniquely identifies
interface to an ethernet-like medium.
interface identified by a particular value
this index is the same interface as
by the same value of ifIndex."
::= { dot3StatsEntry 1 }


dot3StatsAlignmentErrors OBJECT-
SYNTAX
ACCESS read-
STATUS

"A count of frames received on a



Kastenholz [Page 5]

RFC 1398 Ethernet-Like MIB January 1993


interface that are not an integral number
octets in length and do not pass the FCS check

The count represented by an instance of
object is incremented when the
status is returned by the MAC service to
LLC (or other MAC user). Received frames
which multiple error conditions obtain are
according to the conventions of IEEE 802.3
Layer Management, counted exclusively
to the error status presented to the LLC."

"IEEE 802.3 Layer Management
::= { dot3StatsEntry 2 }


dot3StatsFCSErrors OBJECT-
SYNTAX
ACCESS read-
STATUS

"A count of frames received on a
interface that are an integral number of
in length but do not pass the FCS check

The count represented by an instance of
object is incremented when the
status is returned by the MAC service to
LLC (or other MAC user). Received frames
which multiple error conditions obtain are
according to the conventions of IEEE 802.3
Layer Management, counted exclusively
to the error status presented to the LLC."

"IEEE 802.3 Layer Management
::= { dot3StatsEntry 3 }


dot3StatsSingleCollisionFrames OBJECT-
SYNTAX
ACCESS read-
STATUS

"A count of successfully transmitted frames
a particular interface for which
is inhibited by exactly one collision

A frame that is counted by an instance of



Kastenholz [Page 6]

RFC 1398 Ethernet-Like MIB January 1993


object is also counted by the
instance of either the ifOutUcastPkts
ifOutNUcastPkts object and is not counted
the corresponding instance of
dot3StatsMultipleCollisionFrames object."

"IEEE 802.3 Layer Management
::= { dot3StatsEntry 4 }


dot3StatsMultipleCollisionFrames OBJECT-
SYNTAX
ACCESS read-
STATUS

"A count of successfully transmitted frames
a particular interface for which
is inhibited by more than one collision

A frame that is counted by an instance of
object is also counted by the
instance of either the ifOutUcastPkts
ifOutNUcastPkts object and is not counted
the corresponding instance of
dot3StatsSingleCollisionFrames object."

"IEEE 802.3 Layer Management
::= { dot3StatsEntry 5 }


dot3StatsSQETestErrors OBJECT-
SYNTAX
ACCESS read-
STATUS

"A count of times that the SQE TEST
message is generated by the PLS sublayer for
particular interface. The SQE TEST
message is defined in section 7.2.2.2.4
ANSI/IEEE 802.3-1985 and its generation
described in section 7.2.4.6 of the
document."

"ANSI/IEEE Std 802.3-1985 Carrier
Multiple Access with Collision Detection
Method and Physical Layer Specifications
::= { dot3StatsEntry 6 }




Kastenholz [Page 7]

RFC 1398 Ethernet-Like MIB January 1993


dot3StatsDeferredTransmissions OBJECT-
SYNTAX
ACCESS read-
STATUS

"A count of frames for which the
transmission attempt on a particular
is delayed because the medium is busy

The count represented by an instance of
object does not include frames involved
collisions."

"IEEE 802.3 Layer Management
::= { dot3StatsEntry 7 }


dot3StatsLateCollisions OBJECT-
SYNTAX
ACCESS read-
STATUS

"The number of times that a collision
detected on a particular interface later
512 bit-times into the transmission of
packet

Five hundred and twelve bit-times
to 51.2 microseconds on a 10 Mbit/s system.
(late) collision included in a
represented by an instance of this object
also considered as a (generic) collision
purposes of other collision-
statistics."

"IEEE 802.3 Layer Management
::= { dot3StatsEntry 8 }


dot3StatsExcessiveCollisions OBJECT-
SYNTAX
ACCESS read-
STATUS

"A count of frames for which transmission on
particular interface fails due to
collisions."




Kastenholz [Page 8]

RFC 1398 Ethernet-Like MIB January 1993



"IEEE 802.3 Layer Management
::= { dot3StatsEntry 9 }


dot3StatsInternalMacTransmitErrors OBJECT-
SYNTAX
ACCESS read-
STATUS

"A count of frames for which transmission on
particular interface fails due to an
MAC sublayer transmit error. A frame is
counted by an instance of this object if it
not counted by the corresponding instance
either the dot3StatsLateCollisions object,
dot3StatsExcessiveCollisions object, or
dot3StatsCarrierSenseErrors object

The precise meaning of the count represented
an instance of this object is implementation
specific. In particular, an instance of
object may represent a count of
errors on a particular interface that are
otherwise counted."

"IEEE 802.3 Layer Management
::= { dot3StatsEntry 10 }


dot3StatsCarrierSenseErrors OBJECT-
SYNTAX
ACCESS read-
STATUS

"The number of times that the carrier
condition was lost or never asserted
attempting to transmit a frame on a
interface

The count represented by an instance of
object is incremented at most once
transmission attempt, even if the carrier
condition fluctuates during a
attempt."

"IEEE 802.3 Layer Management
::= { dot3StatsEntry 11 }



Kastenholz [Page 9]

RFC 1398 Ethernet-Like MIB January 1993


-- { dot3StatsEntry 12 } is not

dot3StatsFrameTooLongs OBJECT-
SYNTAX
ACCESS read-
STATUS

"A count of frames received on a
interface that exceed the maximum
frame size

The count represented by an instance of
object is incremented when the
status is returned by the MAC service to
LLC (or other MAC user). Received frames
which multiple error conditions obtain are
according to the conventions of IEEE 802.3
Layer Management, counted exclusively
to the error status presented to the LLC."

"IEEE 802.3 Layer Management
::= { dot3StatsEntry 13 }



-- { dot3StatsEntry 14 } is not


-- { dot3StatsEntry 15 } is not

dot3StatsInternalMacReceiveErrors OBJECT-
SYNTAX
ACCESS read-
STATUS

"A count of frames for which reception on
particular interface fails due to an
MAC sublayer receive error. A frame is
counted by an instance of this object if it
not counted by the corresponding instance
either the dot3StatsFrameTooLongs object,
dot3StatsAlignmentErrors object, or
dot3StatsFCSErrors object

The precise meaning of the count represented
an instance of this object is implementation
specific. In particular, an instance of
object may represent a count of receive



Kastenholz [Page 10]

RFC 1398 Ethernet-Like MIB January 1993


on a particular interface that are
otherwise counted."

"IEEE 802.3 Layer Management
::= { dot3StatsEntry 16 }

4.2. The Ethernet-like Collision Statistics


-- the Ethernet-like Collision Statistics

-- Implementation of this group is optional; it is
-- for all systems which have the necessary

dot3CollTable OBJECT-
SYNTAX SEQUENCE OF Dot3
ACCESS not-
STATUS

"A collection of collision histograms for
particular set of interfaces."
::= { dot3 5 }


dot3CollEntry OBJECT-
SYNTAX Dot3
ACCESS not-
STATUS

"A cell in the histogram of per-
collisions for a particular interface.
instance of this object represents
frequency of individual MAC frames for
the transmission (successful or otherwise) on
particular interface is accompanied by
particular number of media collisions."
INDEX { dot3CollIndex, dot3CollCount }
::= { dot3CollTable 1 }



Dot3CollEntry ::= SEQUENCE {
dot3
INTEGER
dot3
INTEGER
dot3




Kastenholz [Page 11]

RFC 1398 Ethernet-Like MIB January 1993


}


dot3CollIndex OBJECT-
SYNTAX
ACCESS read-
STATUS

"The index value that uniquely identifies
interface to which a particular
histogram cell pertains. The
identified by a particular value of this
is the same interface as identified by the
value of ifIndex."
::= { dot3CollEntry 1 }


dot3CollCount OBJECT-
SYNTAX INTEGER (1..16)
ACCESS read-
STATUS

"The number of per-frame media collisions
which a particular collision histogram
represents the frequency on a
interface."
::= { dot3CollEntry 2 }


dot3CollFrequencies OBJECT-
SYNTAX
ACCESS read-
STATUS

"A count of individual MAC frames for which
transmission (successful or otherwise) on
particular interface is accompanied by
particular number of media collisions."
::= { dot3CollEntry 3 }


4.3. 802.3


-- 802.3

-- The ifExtnsTestTable defined in RFC 1229 provides a
-- means for a manager to test any interface corresponding



Kastenholz [Page 12]

RFC 1398 Ethernet-Like MIB January 1993


-- a value of ifIndex

-- At this time, one well known test (testFullDuplexLoopBack)
-- defined in RFC 1229. For ethernet-like interfaces, this
-- configures the MAC chip and executes an internal
-- test of memory and the MAC chip logic. This loopback test
-- only be executed if the interface is offline. Once the
-- has completed, the MAC chip should be reinitialized for
-- operation, but it should remain offline

-- If an error occurs during a test, the object
-- (defined in RFC 1229) will be set to failed(7). The
-- two OBJECT IDENTIFIERs may be used to provided
-- information as values for the object ifExtnsTestCode
-- RFC 1229:

dot3Errors OBJECT IDENTIFIER ::= { dot3 7 }

-- couldn't initialize MAC chip for
dot3ErrorInitError OBJECT IDENTIFIER ::= { dot3Errors 1 }

-- expected data not received (or
-- received correctly) in loopback
dot3ErrorLoopbackError OBJECT IDENTIFIER ::= { dot3Errors 2 }

--
-- TDR

-- Another test, specific to ethernet-like interfaces with
-- exception of 10BaseT and 10BaseF, is Time-domain
(TDR).
-- The TDR value may be useful in determining the

-- to a cable fault. It is advisable to repeat this test
check
-- a consistent resulting TDR value, to verify that there is
fault

dot3Tests OBJECT IDENTIFIER ::= { dot3 6 }
dot3TestTdr OBJECT IDENTIFIER ::= { dot3Tests 1 }

-- A TDR test returns as its result the time interval,
-- in 10 MHz ticks or 100 nsec units, between the start
-- TDR test transmission and the subsequent detection of
-- collision or deassertion of carrier. On successful
-- of a TDR test, the appropriate instance of
-- contains the OBJECT IDENTIFIER of the MIB object
-- contains the value of this time interval



Kastenholz [Page 13]

RFC 1398 Ethernet-Like MIB January 1993


4.4. 802.3 Hardware


-- 802.3 Hardware

-- The object ifExtnsChipSet is provided in RFC 1229 to
-- the MAC hardware used to communcate on an interface.
-- 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
-- assignment is required in other documentation, e.g.,
-- within that part of the registration tree delegated
-- individual enterprises (see RFC 1155).



5. Change

(1) Replace old "Historical Perspective" boilerplate with
new "The Network Management Framework" boilerplate

(2) Remove the "slime text".

(3) Updated the reference to the Interface Extensions mib
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
suggested text

(5) References in ASN.1 comments were changed from the [#]
form to name the actual document being referred to.
references are now meaningful when the ASN.1 is
outside of the RFC

(6) The IMPORTS section of the ASN.1 has been updated
reflect that the OBJECT-TYPE macro is imported from RFC
1212.

(7) The the Generic Ethernet-like group,
dot3Index, dot3InitializeMac, dot3MacSubLayerStatus
dot3MulticastReceiveStatus, dot3TxEnabled,
dot3TestTdrValue has been deprecated as a result of
implementation experience presented at the San Diego
meeting

(8) dot3StatsInRangeLengthErrors
dot3StatsOutOfRangeLengthFields have been deprecated as
result of the implementation experience presented at
San Diego IETF meeting

(9) Update the acknowledgements section to reflect
document's history, etc

(10) REFERENCE clauses have been added to all of the
objects which are being retained

12 August 1992

(1) Removed all deprecated objects

(2) Rephrased the description of the TDR test OID to
the fact that dot3TestTdrValue is no more
ifExtnsTestResult still points to the object
the result, the text simply does not refer
dot3TestTdrValue. I could have deleted the Test, but
OID should then remain reserved. I figured that it
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.

This document was produced by the Ethernet MIB Working Group

This document is based on the Proposed Standard Ethernet MIB,
1284 [14], of which John Cook of Chipcom was the editor.
Ethernet MIB Working Group gathered implementation experience of
variables specified in RFC 1284 and used that information to
this revised MIB

RFC 1284, in turn, is based on a document written by Frank
of Interlan entitled IEEE 802.3 Layer Management Draft M
MIB for TCP/IP Networks [10]. This document has been
reworked, initially by the SNMP Working Group, and then by
Transmission Working Group, to reflect the current conventions
defining objects for MIB interfaces. James Davin, of the
Laboratory for Computer Science, and Keith McCloghrie of Hughes
Systems, contributed to later drafts of this memo. Marshall Rose
Performance Systems International, Inc. converted the document
its current concise format. Anil Rijsinghani of DEC contributed
that more adequately describes the TDR test. Thanks to
Kastenholz of Interlan and Louis Steinberg of IBM for
experimentation

7.

[1] Cerf, V., "IAB Recommendations for the Development of
Network Management Standards", RFC 1052, NRI, April 1988.

[2] Cerf, V., "Report of the Second Ad Hoc Network Management
Group", RFC 1109, NRI, August 1989.

[3] Rose M., and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based internets", STD 16,
1155, Performance Systems International, Hughes LAN Systems,
1990.

[4] McCloghrie K., and M. Rose, "Management Information Base
Network Management of TCP/IP-based internets", RFC 1156,
LAN Systems, Performance Systems International, May 1990.

[5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "
Network Management Protocol", STD 15, RFC 1157, SNMP Research
Performance Systems International, Performance
International, MIT Laboratory for Computer Science, May 1990.

[6] Rose M., Editor, "Management Information Base for
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,
Standard 8824, December 1987.

[8] Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Notation
(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
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
(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
Systems, March 1991.

[14] Cook, J., Editor, "Definitions of Managed Objects for Ethernet
Like Interface Types", RFC 1284, Chipcom Corporation,
1991.

8. Security

Security issues are not discussed in this memo

9. Author's

Frank
2 High
North Andover, MA 01845-2620

Phone: (508) 685-4000
EMail: kasten@ftp.






Kastenholz [Page 17]







if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.




RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX







Spectrum