As per Relevance of the word extension, we have this rfc below:
Network Working Group K. McCloghrie,
Request for Comments: 1229 Hughes LAN Systems, Inc
May 1991
Extensions to the Generic-Interface
Status of this
This RFC contains definitions of managed objects used as
extensions to the generic interfaces structure of MIB-II. This
is a product of the SNMP Working Group of the Internet
Task Force (IETF). This RFC specifies an IAB standards
protocol for the Internet community, and requests discussion
suggestions for improvements. Please refer to the current edition
the "IAB Official Protocol Standards" for the standardization
and status of this protocol. Distribution of this memo is unlimited
Table of
1. Abstract .............................................. 1
2. The Network Management Framework....................... 1
3. Objects ............................................... 2
4. Overview .............................................. 3
4.1 Generic Interface Extension Table .................... 3
4.2 Generic Interface Test Table ......................... 3
4.3 Generic Receive Address Table ........................ 4
5. Definitions ........................................... 5
6. Acknowledgements ...................................... 14
7. References ............................................ 15
8. Security Considerations................................ 15
9. Author's Address....................................... 16
1.
This memo defines an experimental portion of the
Information Base (MIB) for use with network management protocols
TCP/IP-based internets. In particular, it defines managed
types as experimental extensions to the generic interfaces
of MIB-II
2. The Network Management
The Internet-standard Network Management Framework consists of
components. They are
RFC 1155 which defines the SMI, the mechanisms used for
and naming objects for the purpose of management. RFC 1212
SNMP Working Group [Page 1]
RFC 1229 Interface MIB Extensions May 1991
defines a more concise description mechanism, which is
consistent with the SMI
RFC 1156 which defines MIB-I, the core set of managed objects
the Internet suite of protocols. RFC 1213, defines MIB-II,
evolution of MIB-I based on implementation experience and
operational requirements
RFC 1157 which defines the SNMP, the protocol used for
access to managed objects
The Framework permits new objects to be defined for the purpose
experimentation and evaluation
3.
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
Section 5 contains the specification of all object types in
section of the MIB. The object types are defined using
conventions specified in the SMI, as amended by the
specified in [9].
SNMP Working Group [Page 2]
RFC 1229 Interface MIB Extensions May 1991
4.
The Internet Standard MIB [4,6] contains a group of
objects pertaining to a network device's generic
interface(s). These objects are generic in the sense that they
to all network interfaces, irrespective of the type of
media and protocols used on such interfaces. This has proved to
necessary but not sufficient; there are efforts underway to
additional MIB objects which are specific to particular media
lower-level (subnetwork-layer and below) protocol stacks
However, some of these efforts have identified objects which
required (or at least useful), but are not specific to
interface-type on which the effort is focusing. In order to
redundancy, it is better that such objects be defined as
to the generic interface group, rather than defined in
specific-interface-type MIBs
This memo defines the resultant extensions to the generic
group. These extensions are spread over three tables: the
Interface Extension table, the generic Interface Test table, and
generic Receive Address table
4.1. Generic Interface Extension
This table consists of new objects applicable to all types
subnetwork interface
4.2. Generic Interface Test
This section defines objects which allow a network manager
instruct an agent to test an interface for various faults. A
common types of tests are defined in this document but most will
defined elsewhere, dependent on the particular type of interface
After testing, the object ifExtnsTestResult can be read to
the outcome. If an agent cannot perform the test,
is set to so indicate. The object ifExtnsTestCode can be used
provide further test-specific or interface-specific (or
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 invoked, the
test is rejected. Some agents may reject a test when a prior test
active on another interface
When a test is invoked, the identity of the originator of the
and the request-id are saved by the agent in the
ifExtnsTestRequestId and ifExtnsTestCommunity. These values
set until the next test is invoked. In the (rare) event that
SNMP Working Group [Page 3]
RFC 1229 Interface MIB Extensions May 1991
invocation of tests by two network managers were to overlap,
there would be a possibility that the first test's results might
overwritten by the second test's results prior to the first
being read. This unlikely circumstance can be detected by a
manager retrieving ifExtnsTestCommunity, and ifExtnsTestRequestId
the same time as the test results are retrieved, and ensuring
the results are for the desired request
In general, a Management station must not retransmit a request
invoke a test for which it does not receive a response; instead,
properly inspects an agent's MIB to determine if the invocation
successful. The invocation request is retransmitted only if
invocation was unsuccessful
Some tests may require the interface to be taken off-line or may
require the agent to be rebooted after completion of the test.
these circumstances, communication with the management
invoking the test may be lost until after completion of the test
The agent should make every effort to transmit a response to
request that invoked the test prior to losing communication.
the agent is restored to normal service, the results of the test
properly made available in the appropriate objects. Note that
requires that the ifIndex value assigned to an interface must
unchanged even if the test causes a reboot. An agent must reject
test for which it cannot, perhaps due to resource constraints,
available at least the minimum amount of information after that
completes
4.3. Generic Receive Address
This table contains objects relating to an interface's support
receiving packets/frames at more than one address on the
interface
SNMP Working Group [Page 4]
RFC 1229 Interface MIB Extensions May 1991
5.
RFC1229-MIB DEFINITIONS ::=
-- Extensions to MIB-II's Generic Interface
experimental, Counter FROM RFC1155-
DisplayString, PhysAddress FROM RFC1213-
OBJECT-TYPE FROM RFC-1212;
ifExtensions OBJECT IDENTIFIER ::= { experimental 6 }
-- Generic Interface Extension
--
-- This group of objects is mandatory for all types
-- subnetwork interface
ifExtnsTable OBJECT-
SYNTAX SEQUENCE OF
ACCESS not-
STATUS
"A list of interfaces extension entries
The number of entries is given by the
of ifNumber, defined in [4,6]."
::= { ifExtensions 1 }
ifExtnsEntry OBJECT-
SYNTAX
ACCESS not-
STATUS
"An extension to the interfaces entry
defined in [4,6], containing
objects at the subnetwork layer and
for a particular interface."
INDEX { ifExtnsIfIndex }
::= { ifExtnsTable 1 }
IfExtnsEntry ::=
SEQUENCE {
SNMP Working Group [Page 5]
RFC 1229 Interface MIB Extensions May 1991
INTEGER
OBJECT IDENTIFIER
DisplayString
Counter
Counter
Counter
Counter
}
ifExtnsIfIndex OBJECT-
SYNTAX
ACCESS read-
STATUS
"The value of this object identifies
interface for which this entry
extended management information. The
of this object for a particular
has the same value as the ifIndex object
defined in [4,6], for the same interface."
::= { ifExtnsEntry 1 }
ifExtnsChipSet OBJECT-
SYNTAX OBJECT
ACCESS read-
STATUS
"This object identifies the hardware
set being used in the interface.
assignment of OBJECT IDENTIFIERs to
types of hardware chip sets is
by the IANA. If the hardware chip set
unknown, the object
unknownChipSet OBJECT IDENTIFIER ::= { 0 0 }
is returned. Note that unknownChipSet is
syntactically valid object identifier,
any conformant implementation of ASN.1
the BER must be able to generate
SNMP Working Group [Page 6]
RFC 1229 Interface MIB Extensions May 1991
recognize this value."
::= { ifExtnsEntry 2 }
ifExtnsRevWare OBJECT-
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-
STATUS
"An arbitrary octet string that
the firmware version of this interface
It is intended that this should be
readable. It must only contain
printable characters. Typically
will be the firmware version of the
interface software."
::= { ifExtnsEntry 3 }
ifExtnsMulticastsTransmittedOks OBJECT-
SYNTAX
ACCESS read-
STATUS
"The count of frames
transmitted to a subnetwork or link-
multicast destination address other than
broadcast address. For a MAC layer protocol
this includes both Group and
addresses."
::= { ifExtnsEntry 4 }
ifExtnsBroadcastsTransmittedOks OBJECT-
SYNTAX
ACCESS read-
STATUS
"The count of frames
transmitted to a subnetwork or link-
broadcast addresses. It does not
frames sent to a multicast address."
::= { ifExtnsEntry 5 }
ifExtnsMulticastsReceivedOks OBJECT-
SYNTAX
ACCESS read-
STATUS
"The count of frames successfully
that are directed to an active
SNMP Working Group [Page 7]
RFC 1229 Interface MIB Extensions May 1991
or link-layer multicast address (for a
layer protocol, this includes both Group
Functional addresses). This does not
frames directed to a broadcast address,
frames received with errors."
::= { ifExtnsEntry 6 }
ifExtnsBroadcastsReceivedOks OBJECT-
SYNTAX
ACCESS read-
STATUS
"The count of frames successfully
that are directed to a subnetwork
link-layer broadcast address. This does
include frames received with errors."
::= { ifExtnsEntry 7 }
ifExtnsPromiscuous OBJECT-
SYNTAX INTEGER {
true(1),
false(2)
}
ACCESS read-only -- Note: agent implementors
-- encouraged to extend
-- access to read-write if
-- makes sense in their agent
STATUS
"This object has a value of false(2)
this interface only accepts packets/
that are addressed to this station.
object has a value of true(1) when
station accepts all packets/
transmitted on the media. The
true(1) is only legal on certain types
media. If legal, setting this object to
value of true(1) may require the
to be reset before becoming effective."
::= { ifExtnsEntry 8 }
--
-- Generic Interface Test
--
-- This group of objects is optional, but if the table
-- implemented, all objects in the table must be implemented
SNMP Working Group [Page 8]
RFC 1229 Interface MIB Extensions May 1991
ifExtnsTestTable OBJECT-
SYNTAX SEQUENCE OF
ACCESS not-
STATUS
"This table contains one entry per interface."
::= { ifExtensions 2 }
ifExtnsTestEntry OBJECT-
SYNTAX
ACCESS not-
STATUS
"An entry containing objects for
tests on an interface."
INDEX { ifExtnsTestIfIndex }
::= { ifExtnsTestTable 1 }
IfExtnsTestEntry ::=
SEQUENCE {
INTEGER
OCTET STRING
INTEGER
OBJECT IDENTIFIER
INTEGER
OBJECT
}
ifExtnsTestIfIndex OBJECT-
SYNTAX
ACCESS read-
STATUS
"The value of this object identifies
interface for which this entry
information on interface tests. The
of this object for a particular
has the same value as the ifIndex object
defined in [4,6], for the same interface."
::= { ifExtnsTestEntry 1 }
SNMP Working Group [Page 9]
RFC 1229 Interface MIB Extensions May 1991
ifExtnsTestCommunity OBJECT-
SYNTAX OCTET
ACCESS read-
STATUS
"This object contains the name of the
authentication community [5] which was
to authenticate the SNMP Message which
the current or most recent test on
interface. If the authentication
is unknown or undefined, this value
the zero-length string."
::= { ifExtnsTestEntry 2 }
ifExtnsTestRequestId OBJECT-
SYNTAX
ACCESS read-
STATUS
"This object contains the value of
request-id field in the SNMP PDU [5]
invoked the current or most recent test
this interface. If the request-id
unknown or undefined, this value
the value zero."
::= { ifExtnsTestEntry 3 }
ifExtnsTestType OBJECT-
SYNTAX OBJECT
ACCESS read-
STATUS
"A control variable used to start and
operator-initiated interface tests
Most OBJECT IDENTIFIER values
to tests are defined elsewhere, in associ
ation with specific types of interface
However, this document assigns a value
a full-duplex loopback test, and defines
special meanings of the subject identifier
noTest OBJECT IDENTIFIER ::= { 0 0 }
When the value noTest is written to
object, no action is taken unless a test
in progress, in which case the test
aborted. Writing any other value to
object is only valid when no test
SNMP Working Group [Page 10]
RFC 1229 Interface MIB Extensions May 1991
currently in progress, in which case
indicated test is initiated
Note that noTest is a syntactically
object identifier, and any
implementation of ASN.1 and BER must be
to generate and recognize this value
When read, this object always
the most recent value that
was set to. If it has not been set
the last initialization of the
management subsystem on the agent, a
of noTest is returned."
::= { ifExtnsTestEntry 4 }
wellKnownTests OBJECT IDENTIFIER ::= { ifExtensions 4 }
-- full-duplex loopback
testFullDuplexLoopBack OBJECT IDENTIFIER ::=
{ wellKnownTests 1 }
ifExtnsTestResult OBJECT-
SYNTAX INTEGER {
none(1), -- no test yet
success(2),
inProgress(3),
notSupported(4),
unAbleToRun(5), -- due to state of
aborted(6),
failed(7)
}
ACCESS read-
STATUS
"This object contains the result of the
recently requested test, or the
none(1) if no tests have been requested
the last reset. Note that this
provides no provision for saving the
of one test when starting another, as
be required if used by multiple
concurrently."
::= { ifExtnsTestEntry 5 }
ifExtnsTestCode OBJECT-
SYNTAX OBJECT
ACCESS read-
STATUS
SNMP Working Group [Page 11]
RFC 1229 Interface MIB Extensions May 1991
"This object contains a code which
more specific information on the test result
for example an error-code after a
test. Error codes and other values
object may take are specific to the type
interface and/or test. However, one
identifier
testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 }
for use if no additional result code
available
Note that testCodeUnknown is
syntactically valid object identifier,
any conformant implementation of ASN.1
the BER must be able to generate
recognize this value."
::= { ifExtnsTestEntry 6 }
-- Generic Receive Address
--
-- This group of objects is mandatory for all types
-- interfaces which can receive packets/frames addressed
-- more than one address
ifExtnsRcvAddrTable OBJECT-
SYNTAX SEQUENCE OF
ACCESS not-
STATUS
"This table contains an entry for
address (broadcast, multicast, or uni-cast
for which the system will receive packets
frames on a particular interface. When
interface is operating in promiscuous mode
entries are only required for those
for which the system would receive
were it not operating in promiscuous mode."
::= { ifExtensions 3 }
ifExtnsRcvAddrEntry OBJECT-
SYNTAX
ACCESS not-
STATUS
"A list of objects identifying an
for which the system will accept packets
SNMP Working Group [Page 12]
RFC 1229 Interface MIB Extensions May 1991
frames on a particular interface."
INDEX { ifExtnsRcvAddrIfIndex, ifExtnsRcvAddress }
::= { ifExtnsRcvAddrTable 1 }
IfExtnsRcvAddrEntry ::=
SEQUENCE {
INTEGER
PhysAddress
}
ifExtnsRcvAddrIfIndex OBJECT-
SYNTAX
ACCESS read-
STATUS
"The value of ifIndex, defined in [4,6], of
interface which recognizes this entry'
address."
::= { ifExtnsRcvAddrEntry 1 }
ifExtnsRcvAddress OBJECT-
SYNTAX
ACCESS read-
STATUS
"An address for which the system will
packets/frames on this entry's interface."
::= { ifExtnsRcvAddrEntry 2 }
ifExtnsRcvAddrStatus OBJECT-
SYNTAX INTEGER {
other(1),
invalid(2),
volatile(3),
nonVolatile(4)
}
ACCESS read-
STATUS
"This object has the value nonVolatile(4)
for those entries in the table which
valid and will not be deleted by the
restart of the managed system.
having the value volatile(3) are
SNMP Working Group [Page 13]
RFC 1229 Interface MIB Extensions May 1991
and exist, but have not been saved,
that will not exist after the
restart of the managed system.
having the value other(1) are valid
exist but are not classified as to
they will continue to exist after the
restart. Entries having the value invalid(2)
are invalid and do not represent an
for which an interface accepts frames
Setting an object instance to one
the values other(1), volatile(3),
nonVolatile(4) causes the
entry to exist or continue to exist,
to take on the respective status as
the next restart of the managed system
Setting an object instance to the
invalid(2) causes the corresponding
to become invalid or cease to exist
It is an implementation-specific
as to whether the agent removes
invalidated entry from the table
Accordingly, management stations must
prepared to receive tabular
from agents that corresponds to entries
currently in use. Proper interpretation
such entries requires examination of
relevant ifExtnsRcvAddrStatus
instance."
DEFVAL { volatile }
::= { ifExtnsRcvAddrEntry 3 }
6.
Most of the MIB objects defined in this document were
proposed as a part of a MIB for management of IEEE 802.5 Token
networks, as prepared by
Eric B. Decker, cisco Systems, Inc.,
Richard Fox, Synoptics Inc
In addition, the comments of the following individuals
acknowledged
James R. Davin, MIT-
Stan Froyd,
Frank Kastenholz, Racal
SNMP Working Group [Page 14]
RFC 1229 Interface MIB Extensions May 1991
Dave Perkins, 3
Marshall T. Rose,
Bob Stewart,
David Waitzman,
Wengyik Yeong,
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", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 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", 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", RFC 1213,
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] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
RFC 1212, Performance Systems International, Hughes LAN Systems
March 1991.
8. Security
Security issues are not discussed in this memo
SNMP Working Group [Page 15]
RFC 1229 Interface MIB Extensions May 1991
9. Author's
Keith
Hughes LAN Systems, Inc
1225 Charleston
Mountain View, CA 94043
Phone: (415) 966-7934
EMail: kzm@hls.
SNMP Working Group [Page 16]
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
