Internet draft Interface MIB Extensions September 1990
Extensions to the Generic-Interface MIB
11 September 1990
Keith McCloghrie
Hughes LAN Systems, Inc.
kzm@hls.com
1. Status of this Memo
This draft document will be submitted to the RFC editor as an
experimental extension to the SNMP MIB. Distribution of this
memo is unlimited. Please send comments to the author.
2. Abstract
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management
protocols in TCP/IP-based internets. In particular, it defines
managed object types as experimental extensions to the generic
interfaces structure of MIB-II.
This memo does not specify a standard for the Internet
community. However, after experimentation, if sufficient
consensus is reached in the Internet community, then a
subsequent revision of this document may be incorporated into
the Internet-standard MIB.
McCloghrie [Page 1]
Internet draft Interface MIB Extensions September 1990
3. Historical Perspective
As reported in RFC 1052, IAB Recommendations for the
Development of Internet Network Management Standards [1], a
two-prong strategy for network management of TCP/IP-based
internets was undertaken. In the short-term, the Simple
Network Management Protocol (SNMP), defined in RFC 1067, was
to be used to manage nodes in the Internet community. In the
long-term, the use of the OSI network management framework was
to be examined. Two documents were produced to define the
management information: RFC 1065, which defined the Structure
of Management Information (SMI), and RFC 1066, which defined
the Management Information Base (MIB). Both of these
documents were designed so as to be compatible with both the
SNMP and the OSI network management framework.
This strategy was quite successful in the short-term:
Internet-based network management technology was fielded, by
both the research and commercial communities, within a few
months. As a result of this, portions of the Internet
community became network manageable in a timely fashion.
As reported in RFC 1109, Report of the Second Ad Hoc Network
Management Review Group [2], the requirements of the SNMP and
the OSI network management frameworks were more different than
anticipated. As such, the requirement for compatibility
between the SMI/MIB and both frameworks was suspended. This
action permitted the operational network management framework,
based on the SNMP, to respond to new operational needs in the
Internet community by producing MIB-II [6].
In May of 1990, the core documents were elevated to Standard
Protocols with Recommended status. As such, the Internet-
standard network management framework consists of: Structure
and Identification of Management Information for TCP/IP-based
internets, RFC 1155 [3], which describes how managed objects
contained in the MIB are defined; Management Information Base
for Network Management of TCP/IP-based internets, which
describes the managed objects contained in the MIB, RFC 1156
[4]; and, the Simple Network Management Protocol, RFC 1157
[5], which defines the protocol used to manage these objects.
Consistent with the IAB directive to produce simple, workable
systems in the short-term, the list of managed objects defined
in the Internet-standard MIB was derived by taking only those
McCloghrie [Page 2]
Internet draft Interface MIB Extensions September 1990
elements which are considered essential. However, the SMI
defined three extensibility mechanisms: one, the addition of
new standard objects through the definitions of new versions
of the MIB; two, the addition of widely-available but non-
standard objects through the experimental subtree; and three,
the addition of private objects through the enterprises
subtree. Such additional objects can not only be used for
vendor-specific elements, but also for experimentation as
required to further the knowledge of which other objects are
essential.
This memo defines extensions to the MIB using the second
method. It contains definitions of managed objects used as
experimental extensions to the generic interfaces structure of
MIB-II. After experimentation, if sufficient consensus is
reached in the Internet community, then a subsequent revision
of this memo may be placed in the Internet-standard MIB.
McCloghrie [Page 3]
Internet draft Interface MIB Extensions September 1990
4. 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.
4.1. Format of Definitions
The next section contains the specification of all object
types specified in this section of the MIB. The object types
are defined using the conventions specified in the SMI, as
amended by the extensions specified in [10].
McCloghrie [Page 4]
Internet draft Interface MIB Extensions September 1990
5. Overview
The Internet Standard MIB [4,6] contains a group of management
objects pertaining to a network device's generic network
interface(s). These objects are generic in the sense that
they apply to all network interfaces, irrespective of the type
of communication media and protocols used on such interfaces.
This has proved to be necessary but not sufficient; there are
efforts underway to define additional MIB objects which are
specific to particular media and lower-level (subnetwork-layer
and below) protocol stacks.
However, some of these efforts have identified objects which
are required (or at least useful), but are not specific to the
interface-type on which the effort is focusing. In order to
avoid redundancy, it is better that such objects be defined as
extensions to the generic interface group, rather than defined
in multiple specific-interface-type MIBs.
This memo defines the resultant extensions to the generic
interface group. These extensions are spread over three
tables: the generic Interface Extension table, the generic
Interface Test table, and the generic Receive Address table.
5.1. Generic Interface Extension Table
This table consists of new objects applicable to all types of
subnetwork interface.
5.2. Generic Interface Test Table
This section defines objects which allow a network manager to
instruct an agent to test an interface for various faults. A
few common types of tests are defined in this document but
most will be defined elsewhere dependent on the particular
type of interface. After invoking a test, the object
ifExtnsTestResult can be read to determine the outcome. If an
agent can not perform the test, ifExtnsTestResult is set to so
indicate. The object ifExtnsTestCode can be used to provide
further test-specific or interface-specific (or even
enterprise-specific) information concerning the outcome of the
test. Only one test can be in progress on each interface at
any one time. If one test is in progress when another test is
McCloghrie [Page 5]
Internet draft Interface MIB Extensions September 1990
invoked, the second test is rejected. Some agents may reject
a test when a prior test is active on another interface.
When a test is invoked, the authentication service user
identity (as defined in [9]) originating the request is saved
by the agent, in the objects ifExtnsTestUser and
ifExtnsTestCommunity. These values remain set until the next
test is invoked. In the (rare) event that the invocation of
tests by two network managers were to overlap, then there is a
possibility that the first test's results might be overwritten
by the second test's results prior to the first results being
read. This unlikely circumstance can be detected by a network
manager retrieving the test-invoking authentication service
user identity at the same time as the test results are
retrieved, and ensuring that the results are for the desired
user identity.
In general, a Management station must not retransmit a request
to invoke a test for which it does not receive a response;
instead, it properly inspects an agent's MIB to determine if
the invocation was successful. Only if the invocation was
unsuccessful, is the invocation request retransmitted.
Some tests may require the interface to be taken off-line in
order to execute them, or may even require the agent to reboot
after completion of the test. In these circumstances,
communication with the management station invoking the test
may be lost until after completion of the test. The agent
should make every effort to transmit a response to the request
which invoked the test prior to losing communication. When
the agent is restored to normal service, the results of the
test are properly made available in the appropriate objects.
An agent which cannot, perhaps due to resource constraints,
retain even the minimum amount of information in these
situations, must reject any test which can cause one of these
situations to occur.
5.3. Generic Receive Address Table
This table of objects contains objects relating to an
interface's support for receiving packets/frames at more than
one address on the same interface.
McCloghrie [Page 6]
Internet draft Interface MIB Extensions September 1990
6. Definitions
RFCxxxx-MIB DEFINITIONS ::= BEGIN
IMPORTS
experimental, Counter FROM RFC1155-SMI
OBJECT-TYPE FROM RFCxxxx;
-- This MIB Module uses the extended OBJECT-TYPE macro as
-- defined in [10]
ifExtensions OBJECT IDENTIFIER ::= { experimental 6 }
-- Generic Interface Extension Table
--
-- This group of objects is mandatory for all types of
-- subnetwork interface.
ifExtnsTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfExtnsEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of interfaces extension entries.
The number of entries is given by the value
of ifNumber, defined in [4,6]."
::= { ifExtensions 1 }
ifExtnsEntry OBJECT-TYPE
SYNTAX IfExtnsEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An extension to the interfaces entry,
defined in [4,6], containing additional
objects at the subnetwork layer and below
for a particular interface."
INDEX { ifExtnsIfIndex }
::= { ifExtnsTable 1 }
IfExtnsEntry ::= SEQUENCE {
ifExtnsIfIndex
McCloghrie [Page 7]
Internet draft Interface MIB Extensions September 1990
INTEGER,
ifExtnsChipSet
OBJECT IDENTIFIER,
ifExtnsRevWare
DisplayString,
ifExtnsMulticastsTransmittedOks
Counter,
ifExtnsBroadcastsTransmittedOks
Counter,
ifExtnsMulticastsReceivedOks
Counter,
ifExtnsBroadcastsReceivedOks
Counter,
ifExtnsPromiscuous
INTEGER
}
ifExtnsIfIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the
interface for which this entry contains
extended management information. The value
of this object for a particular interface
has the same value as the ifIndex object,
defined in [4,6], for the same interface."
::= { ifExtnsEntry 1 }
ifExtnsChipSet OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object identifies the hardware chip
set being used in the interface. The
assignment of OBJECT IDENTIFIERs to various
types of hardware chip sets is defined
elsewhere. This document assigns only the
value: unknownChipSet for use if the chip
set in use is unknown.
Note that unknownChipSet is a
syntactically valid object identifier, and
any conformant implementation of ASN.1 and
McCloghrie [Page 8]
Internet draft Interface MIB Extensions September 1990
the BER must be able to generate and
recognize this value."
::= { ifExtnsEntry 2 }
-- for unknown hardware chip set
unknownChipSet OBJECT IDENTIFIER ::= { 0 0 }
ifExtnsRevWare OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An arbitrary octet string that describes
the firmware version of this interface.
It is intended that this should be human
readable. It must only contain ASCII
printable characters. Typically this
will be the firmware version of the main
interface software."
::= { ifExtnsEntry 3 }
ifExtnsMulticastsTransmittedOks OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The count of frames successfully
transmitted to a subnetwork or link-layer
multicast destination address other than a
broadcast address. For a MAC layer protocol,
this includes both Group and Functional
addresses."
::= { ifExtnsEntry 4 }
ifExtnsBroadcastsTransmittedOks OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The count of frames successfully
transmitted to a subnetwork or link-layer
broadcast addresses. It does not include
frames sent to a multicast address."
::= { ifExtnsEntry 5 }
McCloghrie [Page 9]
Internet draft Interface MIB Extensions September 1990
ifExtnsMulticastsReceivedOks OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The count of frames successfully received
that are directed to an active subnetwork
or link-layer multicast address (for a MAC
layer protocol, this includes both Group and
Functional addresses). This does not include
frames directed to a broadcast address, nor
frames received with errors."
::= { ifExtnsEntry 6 }
ifExtnsBroadcastsReceivedOks OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The count of frames successfully received
that are directed to a subnetwork or
link-layer broadcast address."
::= { ifExtnsEntry 7 }
ifExtnsPromiscuous OBJECT-TYPE
SYNTAX INTEGER {
true(1),
false(2)
}
ACCESS read-only -- Note: agent implementors are
-- encouraged to extend this
-- access to read-write if that
-- makes sense in their agent.
STATUS mandatory
DESCRIPTION
"This object has a value of false(2) if
this interface only accepts packets/frames
that are addressed to this station. This
object has a value of true(1) when the
station accepts all packets/frames
transmitted on the media. The value
true(1) is only legal on certain types of
media. If legal, setting this object to a
value of true(1) may require the interface
to be reset before becoming effective."
McCloghrie [Page 10]
Internet draft Interface MIB Extensions September 1990
::= { ifExtnsEntry 8 }
--
-- Generic Interface Test Table
--
-- This group of objects is optional, but if the table is
-- implemented, all objects in the table must be implemented.
ifExtnsTestTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfExtnsTestEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This table contains one entry per
interface."
::= { ifExtensions 2 }
ifExtnsTestEntry OBJECT-TYPE
SYNTAX IfExtnsTestEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry containing objects for
invoking tests on an interface."
INDEX { ifExtnsTestIfIndex }
::= { ifExtnsTestTable 1 }
IfExtnsTestEntry ::= SEQUENCE {
ifExtnsTestIfIndex
INTEGER,
ifExtnsTestUser
OCTET STRING,
ifExtnsTestCommunity
OCTET STRING,
ifExtnsTestType
OBJECT IDENTIFIER,
ifExtnsTestResult
INTEGER,
ifExtnsTestCode
OBJECT IDENTIFIER
}
ifExtnsTestUser OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-only
McCloghrie [Page 11]
Internet draft Interface MIB Extensions September 1990
STATUS mandatory
DESCRIPTION
"This object contains the name of the
authentication service user [9] who
originated the SNMP Message which invoked
the current or most recent test on this
interface. If the authentication service
user is unknown or undefined, this value
contains the zero-length string."
::= { ifExtnsTestEntry 1 }
ifExtnsTestCommunity OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object contains the name of the
SNMP authentication community [9] which
was used to authenticate the SNMP Message
which invoked the current or most recent
test on this interface. If the
authentication community is unknown or
undefined, this value contains the
zero-length string."
::= { ifExtnsTestEntry 2 }
ifExtnsTestIfIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the
interface for which this entry contains
information on interface tests. The value
of this object for a particular interface
has the same value as the ifIndex object,
defined in [4,6], for the same interface."
::= { ifExtnsTestEntry 3 }
ifExtnsTestType OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A control variable used to start and stop
McCloghrie [Page 12]
Internet draft Interface MIB Extensions September 1990
operator-initiated interface tests. If
the value noTest is written, then this
aborts any test in progress, or if no test
is in progress, acts as a no-operation.
If any other value is used, writing to
this object is only valid when no test is
currently in progress, in which case the
indicated test is initiated.
Most OBJECT IDENTIFIER values assigned
to tests are defined elsewhere, in associ-
ation with specific types of interface.
However, this document does assign a value
for a full-duplex loopback test. Also,
the subject identifier, noTest, is defined
here.
Note that noTest is a syntactically
valid object identifier, and any conformant
implementation of ASN.1 and BER must be able
to generate and recognize this value.
When read, this object always returns
the most recent value that ifExtnsTestType
was set to. If it has not been set since
the last initialization of the network
management subsystem on the node, it returns
a value of noTest."
::= { ifExtnsTestEntry 4 }
-- abort Test in progress/ no Test in progress
noTest OBJECT IDENTIFIER ::= { 0 0 }
wellKnownTests OBJECT IDENTIFIER ::= { ifExtensions 4 }
-- full-duplex loopback test
testFullDuplexLoopBack OBJECT IDENTIFIER ::= { wellKnownTests 1 }
ifExtnsTestResult OBJECT-TYPE
SYNTAX INTEGER {
none(1), -- no test yet requested
success(2),
inProgress(3),
notSupported(4),
unAbleToRun(5), -- due to state of system
aborted(6),
failed(7)
}
McCloghrie [Page 13]
Internet draft Interface MIB Extensions September 1990
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object contains the result of the most
recently requested test, or the value
none(1) if no tests have been requested since
the last reset. Note that this facility
provides no provision for saving the results
of one test when starting another, as could
be required if used by multiple managers
concurrently."
::= { ifExtnsTestEntry 5 }
ifExtnsTestCode OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This object contains a code which contains
more specific information on the test result,
for example an error-code after a failed
test. Error codes and other values this
object may take are specific to the type of
interface and/or test. However, one subject
identifier, testCodeUnknown, is defined here
for use if no additional result code is
available.
Note that testCodeUnknown is a
syntactically valid object identifier, and
any conformant implementation of ASN.1 and
the BER must be able to generate and
recognize this value."
::= { ifExtnsTestEntry 6 }
-- no additional result code available
testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 }
McCloghrie [Page 14]
Internet draft Interface MIB Extensions September 1990
-- Generic Receive Address Table
--
-- This group of objects is mandatory for all types of
-- interfaces which can receive packets/frames addressed to
-- more than one address.
ifExtnsRcvAddrTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfExtnsRcvAddrEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This table contains an entry for each
address (broadcast, multicast, or uni-cast)
for which the system will receive packets/
frames on a particular interface. When an
interface is operating in promiscuous mode,
entries are only required for those
addresses for which the system would receive
frames were it not operating in promiscuous
mode."
::= { ifExtensions 3 }
ifExtnsRcvAddrEntry OBJECT-TYPE
SYNTAX IfExtnsRcvAddrEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of objects identifying an address
for which the system will accept packets/
frames on a particular interface."
INDEX { ifExtnsRcvAddrIfIndex, ifExtnsRcvAddress }
::= { ifExtnsRcvAddrTable 1 }
IfExtnsRcvAddrEntry ::= SEQUENCE {
ifExtnsRcvAddrIfIndex
INTEGER,
ifExtnsRcvAddress
OCTET STRING,
ifExtnsRcvAddrStatus
INTEGER
}
ifExtnsRcvAddrIfIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
McCloghrie [Page 15]
Internet draft Interface MIB Extensions September 1990
STATUS mandatory
DESCRIPTION
"The value of ifIndex, defined in [4,6],
of an interface which recognizes this
entry's address."
::= { ifExtnsRcvAddrEntry 1 }
ifExtnsRcvAddress OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An address for which the system will
accept packets/frames on this entry's
interface."
::= { ifExtnsRcvAddrEntry 2 }
ifExtnsRcvAddrStatus OBJECT-TYPE
SYNTAX INTEGER {
other(1),
invalid(2),
volatile(3),
nonVolatile(4)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This object has the value nonVolatile(4)
for those entries in the table which are
valid and will not be deleted by the next
restart of the managed system. Entries
having the value volatile(3) are valid
and exist, but have not been saved, so
that will not exist after the next
restart of the managed system. Entries
having the value other(1) are valid and
exist but are not classified as to whether
they will continue to exist after the next
restart. Entries having the value invalid(2)
are invalid and do not represent an address
for which an interface accepts frames.
Setting an object instance to one of
the values other(1), volatile(3), or
nonVolatile(4) causes the corresponding
entry to exist or continue to exist, and
McCloghrie [Page 16]
Internet draft Interface MIB Extensions September 1990
to take on the respective status as regards
the next restart of the managed system.
Setting an object instance to the value
invalid(2) causes the corresponding entry
to become invalid or cease to exist.
It is an implementation-specific matter
as to whether the agent removes an
invalidated entry from the table.
Accordingly, management stations must be
prepared to receive tabular information
from agents that corresponds to entries not
currently in use. Proper interpretation of
such entries requires examination of the
relevant ifExtnsRcvAddrStatus object
instance."
DEFVAL volatile(3)
::= { ifExtnsRcvAddrEntry 3 }
END
McCloghrie [Page 17]
Internet draft Interface MIB Extensions September 1990
7. Acknowledgements
Most of the MIB objects defined in this document were
originally proposed as a part of the IEEE 802.5 MIB, as
prepared by:
Eric B. Decker, cisco Systems, Inc., and
Richard Fox, Synoptics Inc.
In addition, the comments of the following individuals are
acknowledged:
James R. Davin, MIT-LCS,
Stan Froyd, ACC,
Frank Kastenholz, Racal Interlan
Marshall T. Rose, PSI,
Bob Stewart, Xyplex,
David Waitzman, BBN,
Wengyik Yeong, PSI,
McCloghrie [Page 18]
Internet draft Interface MIB Extensions September 1990
8. References
[1] V. Cerf, IAB Recommendations for the Development of
Internet Network Management Standards. Internet Working
Group Request for Comments 1052. Network Information
Center, SRI International, Menlo Park, California,
(April, 1988).
[2] V. Cerf, Report of the Second Ad Hoc Network Management
Review Group, Internet Working Group Request for Comments
1109. Network Information Center, SRI International,
Menlo Park, California, (August, 1989).
[3] M.T. Rose and K. McCloghrie, Structure and Identification
of Management Information for TCP/IP-based internets,
Internet Working Group Request for Comments 1155.
Network Information Center, SRI International, Menlo
Park, California, (May, 1990).
[4] K. McCloghrie and M.T. Rose, Management Information Base
for Network Management of TCP/IP-based internets,
Internet Working Group Request for Comments 1156.
Network Information Center, SRI International, Menlo
Park, California, (May, 1990).
[5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
Simple Network Management Protocol, Internet Working
Group Request for Comments 1157. Network Information
Center, SRI International, Menlo Park, California, (May,
1990).
[6] M.T. Rose (editor), Management Information Base for
Network Management of TCP/IP-based internets, Internet
Working Group Request for Comments 1158. Network
Information Center, SRI International, Menlo Park,
California, (May, 1990).
[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
McCloghrie [Page 19]
Internet draft Interface MIB Extensions September 1990
Abstract Notation One (ASN.1), International Organization
for Standardization. International Standard 8825,
(December, 1987).
[9] J.M. Galvin, K. McCloghrie, J.R. Davin, Authentication
and Privacy in the SNMP, Internet Working Group, Request
for Comments (in preparation), Network Information
Center, SRI International, Menlo Park, California,
(September, 1990).
[10] M.T. Rose, K. McCloghrie (editors), Towards Concise MIB
Definitions, Internet Draft, Internet Engineering Task
Force, (September, 1990).
McCloghrie [Page 20]
Internet draft Interface MIB Extensions September 1990
Table of Contents
1 Status of this Memo ................................... 1
2 Abstract .............................................. 1
3 Historical Perspective ................................ 2
4 Objects ............................................... 4
4.1 Format of Definitions ............................... 4
5 Overview .............................................. 5
5.1 Generic Interface Extension Table ................... 5
5.2 Generic Interface Test Table ........................ 5
5.3 Generic Receive Address Table ....................... 6
6 Definitions ........................................... 7
7 Acknowledgements ...................................... 18
8 References ............................................ 19
McCloghrie [Page 21]
