draft-ietf-hubmib-etherif-mib-07.txt   rfc2358.txt 
Hub MIB Working Group J. Flick Network Working Group J. Flick
INTERNET DRAFT Hewlett-Packard Company Request for Comments: 2358 Hewlett-Packard Company
J. Johnson Obsoletes: 1650 J. Johnson
RedBack Networks Category: Standards Track RedBack Networks
June 1998 June 1998
Definitions of Managed Objects for Definitions of Managed Objects for
the Ethernet-like Interface Types the Ethernet-like Interface Types
<draft-ietf-hubmib-etherif-mib-07.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document specifies an Internet standards track protocol for the
documents of the Internet Engineering Task Force (IETF), its areas, Internet community, and requests discussion and suggestions for
and its working groups. Note that other groups may also distribute improvements. Please refer to the current edition of the "Internet
working documents as Internet-Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract Abstract
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community. for use with network management protocols in the Internet community.
This memo obsoletes RFC 1650 ''Definitions of Managed Objects for the This memo obsoletes RFC 1650 "Definitions of Managed Objects for the
Ethernet-like Interface Types using SMIv2.'' This memo extends that Ethernet-like Interface Types using SMIv2". This memo extends that
specification by including management information useful for the specification by including management information useful for the
management of 100 Mb/s Ethernet interfaces. management of 100 Mb/s Ethernet interfaces.
Ethernet technology, as defined by the 802.3 Working Group of the Ethernet technology, as defined by the 802.3 Working Group of the
IEEE, continues to evolve, with scalable increases in speed, new IEEE, continues to evolve, with scalable increases in speed, new
types of cabling and interfaces, and new features. This evolution types of cabling and interfaces, and new features. This evolution
may require changes in the managed objects in order to reflect this may require changes in the managed objects in order to reflect this
new functionality. This document, as with other documents issued by new functionality. This document, as with other documents issued by
this working group, reflect a certain stage in the evolution of this working group, reflect a certain stage in the evolution of
Ethernet technology. In the future, this document might be revised, Ethernet technology. In the future, this document might be revised,
or new documents might be issued by the Ethernet Interfaces and Hub or new documents might be issued by the Ethernet Interfaces and Hub
MIB Working Group, in order to reflect the evolution of Ethernet MIB Working Group, in order to reflect the evolution of Ethernet
technology. technology.
Distribution of this memo is unlimited. Please forward comments to
hubmib@hprnd.rose.hp.com.
Table of Contents Table of Contents
1. Introduction ................................................ 2 1. Introduction ................................................ 2
2. The SNMP Network Management Framework ...................... 3 2. The SNMP Network Management Framework ...................... 2
2.1. Object Definitions ....................................... 3 2.1. Object Definitions ....................................... 3
3. Overview ................................................... 3 3. Overview ................................................... 3
3.1. Relation to MIB-2 ........................................ 4 3.1. Relation to MIB-2 ........................................ 4
3.2. Relation to the Interfaces MIB ........................... 4 3.2. Relation to the Interfaces MIB ........................... 4
3.2.1. Layering Model ......................................... 4 3.2.1. Layering Model ......................................... 4
3.2.2. Virtual Circuits ....................................... 5 3.2.2. Virtual Circuits ....................................... 4
3.2.3. ifTestTable ............................................ 5 3.2.3. ifTestTable ............................................ 5
3.2.4. ifRcvAddressTable ...................................... 5 3.2.4. ifRcvAddressTable ...................................... 5
3.2.5. ifPhysAddress .......................................... 5 3.2.5. ifPhysAddress .......................................... 5
3.2.6. ifType ................................................. 6 3.2.6. ifType ................................................. 6
3.2.7. Specific Interface MIB Objects ......................... 7 3.2.7. Specific Interface MIB Objects ......................... 7
3.3. Relation to the 802.3 MAU MIB ............................ 10 3.3. Relation to the 802.3 MAU MIB ............................ 10
3.4. Mapping of IEEE 802.3 Managed Objects .................... 10 3.4. Mapping of IEEE 802.3 Managed Objects .................... 10
4. Definitions ................................................ 12 4. Definitions ................................................ 11
5. Intellectual Property ...................................... 34 5. Intellectual Property ...................................... 34
6. Acknowledgements ........................................... 35 6. Acknowledgements ........................................... 34
7. References ................................................. 35 7. References ................................................. 35
8. Security Considerations .................................... 37 8. Security Considerations .................................... 36
9. Author's Addresses ......................................... 38 9. Authors' Addresses ......................................... 37
A. Change Log ................................................. 38 A. Change Log ................................................. 38
B. Full Copyright Statement ................................... 39 B. Full Copyright Statement ................................... 39
1. Introduction 1. Introduction
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community. for use with network management protocols in the Internet community.
In particular, it defines objects for managing ethernet-like In particular, it defines objects for managing ethernet-like
interfaces. interfaces.
skipping to change at page 3, line 30 skipping to change at page 3, line 20
Managed objects are accessed via a virtual information store, termed Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1) [1] defined using the subset of Abstract Syntax Notation One (ASN.1) [1]
defined in the SMI [2]. In particular, each object object type is defined in the SMI [2]. In particular, each object object type is
named by an OBJECT IDENTIFIER, an administratively assigned name. named by an OBJECT IDENTIFIER, an administratively assigned name.
The object type together with an object instance serves to uniquely The object type together with an object instance serves to uniquely
identify a specific instantiation of the object. For human identify a specific instantiation of the object. For human
convenience, we often use a textual string, termed the descriptor, to convenience, we often use a textual string, termed the descriptor, to
refer to the object type. refer to the object type.
3. Overview 3. Overview
Instances of these object types represent attributes of an interface Instances of these object types represent attributes of an interface
to an ethernet-like communications medium. At present, ethernet-like to an ethernet-like communications medium. At present, ethernet-like
media are identified by the following values of the ifType object in media are identified by the following values of the ifType object in
the Interfaces MIB [12]: the Interfaces MIB [12]:
ethernetCsmacd(6) ethernetCsmacd(6)
iso88023Csmacd(7) iso88023Csmacd(7)
starLan(11) starLan(11)
The definitions presented here are based on the IEEE 802.3 Layer The definitions presented here are based on the IEEE 802.3 Layer
Management Specification [5], as originally interpreted by Frank Management Specification [5], as originally interpreted by Frank
Kastenholz then of Interlan in [7]. Implementors of these MIB Kastenholz then of Interlan in [7]. Implementors of these MIB
objects should note that the IEEE document explicitly describes (in objects should note that the IEEE document explicitly describes (in
the form of Pascal pseudocode) when, where, and how various MAC the form of Pascal pseudocode) when, where, and how various MAC
attributes are measured. The IEEE document also describes the attributes are measured. The IEEE document also describes the
effects of MAC actions that may be invoked by manipulating instances effects of MAC actions that may be invoked by manipulating instances
of the MIB objects defined here. of the MIB objects defined here.
skipping to change at page 4, line 29 skipping to change at page 4, line 19
The relationship between an ethernet-like interface and 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, 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 the value of an ifIndex object instance can be directly used to
identify corresponding instances of the objects defined herein. identify corresponding instances of the objects defined herein.
For agents which implement the (now deprecated) ifSpecific object, an For agents which implement the (now deprecated) ifSpecific object, an
instance of that object that is associated with an ethernet-like instance of that object that is associated with an ethernet-like
interface has the OBJECT IDENTIFIER value: interface has the OBJECT IDENTIFIER value:
dot3 OBJECT IDENTIFER ::= { transmission 7 } dot3 OBJECT IDENTIFER ::= { transmission 7 }
3.2. Relation to the Interfaces MIB 3.2. Relation to the Interfaces MIB
The Interface MIB [12] requires that any MIB which is an adjunct of The Interface MIB [12] requires that any MIB which is an adjunct of
the Interface MIB clarify specific areas within the Interface MIB. the Interface MIB clarify specific areas within the Interface MIB.
These areas were intentionally left vague in the Interface MIB to These areas were intentionally left vague in the Interface MIB to
avoid over constraining the MIB, thereby precluding management of avoid over constraining the MIB, thereby precluding management of
certain media-types. certain media-types.
Section 3.3 of [12] enumerates several areas which a media-specific Section 3.3 of [12] enumerates several areas which a media-specific
skipping to change at page 6, line 31 skipping to change at page 6, line 18
The address is stored in binary in this object. The address is The address is stored in binary in this object. The address is
stored in "canonical" bit order, that is, the Group Bit is positioned stored in "canonical" bit order, that is, the Group Bit is positioned
as the low-order bit of the first octet. Thus, the first byte of a as the low-order bit of the first octet. Thus, the first byte of a
multicast address would have the bit 0x01 set. multicast address would have the bit 0x01 set.
3.2.6. ifType 3.2.6. ifType
This MIB applies to interfaces which have any of the following ifType This MIB applies to interfaces which have any of the following ifType
values: values:
ethernetCsmacd(6) ethernetCsmacd(6)
iso88023Csmacd(7) iso88023Csmacd(7)
starLan(11) starLan(11)
It is RECOMMENDED that all Ethernet-like interfaces use an ifType of It is RECOMMENDED that all Ethernet-like interfaces use an ifType of
ethernetCsmacd(6) regardless of the speed that the interface is ethernetCsmacd(6) regardless of the speed that the interface is
running or the link-layer encapsulation in use. iso88023Csmacd(7) running or the link-layer encapsulation in use. iso88023Csmacd(7)
and starLan(11) are supported for backwards compatability. and starLan(11) are supported for backwards compatability.
There are two other interface types defined in the IANAifType-MIB for There are two other interface types defined in the IANAifType-MIB for
100 Mbit Ethernet. They are fastEther(62), and fastEtherFX(69). 100 Mbit Ethernet. They are fastEther(62), and fastEtherFX(69).
This document takes the position that an Ethernet is an Ethernet, and This document takes the position that an Ethernet is an Ethernet, and
Ethernet interfaces SHOULD always have the same value of ifType. Ethernet interfaces SHOULD always have the same value of ifType.
skipping to change at page 36, line 5 skipping to change at page 35, line 27
Laboratory for Computer Science, and Keith McCloghrie of Hughes LAN Laboratory for Computer Science, and Keith McCloghrie of Hughes LAN
Systems, contributed to later drafts of this memo. Marshall Rose of Systems, contributed to later drafts of this memo. Marshall Rose of
Performance Systems International, Inc. converted the document into Performance Systems International, Inc. converted the document into
its current concise format. Anil Rijsinghani of DEC contributed text its current concise format. Anil Rijsinghani of DEC contributed text
that more adequately describes the TDR test. Thanks to Frank that more adequately describes the TDR test. Thanks to Frank
Kastenholz of Interlan and Louis Steinberg of IBM for their Kastenholz of Interlan and Louis Steinberg of IBM for their
experimentation. experimentation.
7. References 7. References
[1] Information processing systems - Open Systems Interconnection - [1] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1), Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization, International International Organization for Standardization, International
Standard 8824, December 1987. Standard 8824, December 1987.
[2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
S. Waldbusser, "Structure of Management Information for Version Waldbusser, "Structure of Management Information for Version 2 of
2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996. January 1996.
[3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
S. Waldbusser, "Textual Conventions for Version 2 of the Simple Waldbusser, "Textual Conventions for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1903, January 1996. Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
S. Waldbusser, "Conformance Statements for Version 2 of the Waldbusser, "Conformance Statements for Version 2 of the Simple
Simple Network Management Protocol (SNMPv2)", RFC 1904, Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
January 1996.
[5] IEEE, IEEE 802.3 Layer Management, November 1988. [5] IEEE, IEEE 802.3 Layer Management, November 1988.
[6] IEEE, IEEE 802.3u-1995, "10 & 100 Mb/s Management," Section 30, [6] IEEE, IEEE 802.3u-1995, "10 & 100 Mb/s Management," Section 30,
Supplement to IEEE Std 802.3, October 26, 1995. Supplement to IEEE Std 802.3, October 26, 1995.
[7] Kastenholz, F., "IEEE 802.3 Layer Management Draft compatible [7] Kastenholz, F., "IEEE 802.3 Layer Management Draft compatible MIB
MIB for TCP/IP Networks", electronic mail message to mib- for TCP/IP Networks", electronic mail message to mib-
wg@nnsc.nsf.net, 9 June 1989. wg@nnsc.nsf.net, 9 June 1989.
[8] Cook, J., "Definitions of Managed Objects for Ethernet-Like [8] Cook, J., "Definitions of Managed Objects for Ethernet-Like
Interface Types", RFC 1284, Chipcom Corporation, December 1991. Interface Types", RFC 1284, December 1991.
[9] Kastenholz, F., "Definitions of Managed Objects for the [9] Kastenholz, F., "Definitions of Managed Objects for the
Ethernet-like Interface Types", RFC 1398, FTP Software, Inc., Ethernet-like Interface Types", RFC 1398, January 1993.
January 1993.
[10] Kastenholz, F., "Definitions of Managed Objects for the [10] Kastenholz, F., "Definitions of Managed Objects for the
Ethernet-like Interface Types", RFC 1643, FTP Software, Inc., Ethernet-like Interface Types", RFC 1643, July 1994.
July 1994.
[11] Kastenholz, F., "Definitions of Managed Objects for the [11] Kastenholz, F., "Definitions of Managed Objects for the
Ethernet-like Interface Types using SMIv2", RFC 1650, Ethernet-like Interface Types using SMIv2", RFC 1650, August
FTP Software, Inc., August 1994. 1994.
[12] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB [12] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB
using SMIv2", RFC 2233, Cisco Systems, FTP Software, using SMIv2", RFC 2233, Cisco Systems, November 1997.
November 1997.
[13] Bradner, S., "Key words for use in RFCs to Indicate [13] Bradner, S., "Key words for use in RFCs to Indicate Requirements
Requirements Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[14] deGraaf, K., Romascanu, D., McMaster, D., McCloghrie, K., and [14] deGraaf, K., Romascanu, D., McMaster, D., McCloghrie, K., and S.
S. Roberts, "Definitions of Managed Objects for IEEE 802.3 Roberts, "Definitions of Managed Objects for IEEE 802.3 Medium
Medium Attachment Units (MAUs) using SMIv2", RFC 2239, Attachment Units (MAUs) using SMIv2", RFC 2239, November 1997.
3Com Corporation, Madge Networks (Israel) Ltd., Cisco Systems
Inc., Cisco Systems Inc., Farallon Computing Inc., November
1997.
[15] Kastenholz, F., "Implementation Notes and Experience for The [15] Kastenholz, F., "Implementation Notes and Experience for The
Internet Ethernet MIB", RFC 1369, FTP Software, October 1992. Internet Ethernet MIB", RFC 1369, October 1992.
[16] McCloghrie, K., and M. Rose, Editors, "Management Information [16] McCloghrie, K., and M. Rose, Editors, "Management Information
Base for Network Management of TCP/IP-based internets: MIB-II", Base for Network Management of TCP/IP-based internets: MIB-II",
STD 17, RFC 1213, Hughes LAN Systems, Performance Systems STD 17, RFC 1213, March 1991.
International, March 1991.
[17] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) [17] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol for version 3 of the Simple Network Management Protocol
(SNMPv3)", RFC 2274, January 1998. (SNMPv3)", RFC 2274, January 1998.
[18] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access [18] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
Control Model for the Simple Network Management Protocol Control Model for the Simple Network Management Protocol (SNMP)",
(SNMP)", RFC 2275, January 1998. RFC 2275, January 1998.
8. Security Considerations 8. Security Considerations
There are no management objects defined in this MIB that have a MAX- There are no management objects defined in this MIB that have a MAX-
ACCESS clause of read-write and/or read-create. So, if this MIB is ACCESS clause of read-write and/or read-create. So, if this MIB is
implemented correctly, then there is no risk that an intruder can implemented correctly, then there is no risk that an intruder can
alter or create any management objects of this MIB via direct SNMP alter or create any management objects of this MIB via direct SNMP
SET operations. SET operations.
There are a number of managed objects in this MIB that may be There are a number of managed objects in this MIB that may be
skipping to change at page 38, line 16 skipping to change at page 37, line 31
It is recommended that the implementors consider the security It is recommended that the implementors consider the security
features as provided by the SNMPv3 framework. Specifically, the use features as provided by the SNMPv3 framework. Specifically, the use
of the User-based Security Model RFC 2274 [17] and the View-based of the User-based Security Model RFC 2274 [17] and the View-based
Access Control Model RFC 2275 [18] is recommended. Access Control Model RFC 2275 [18] is recommended.
It is then a customer/user responsibility to ensure that the SNMP It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, is properly entity giving access to an instance of this MIB, is properly
configured to give access to those objects only to those principals configured to give access to those objects only to those principals
(users) that have legitimate rights to access them. (users) that have legitimate rights to access them.
9. Author's Addresses 9. Authors' Addresses
John Flick John Flick
Hewlett-Packard Company Hewlett-Packard Company
8000 Foothills Blvd. M/S 5556 8000 Foothills Blvd. M/S 5556
Roseville, CA 95747-5556 Roseville, CA 95747-5556
Phone: +1 916 785 4018 Phone: +1 916 785 4018
Email: johnf@hprnd.rose.hp.com EMail: johnf@hprnd.rose.hp.com
Jeffrey Johnson Jeffrey Johnson
RedBack Networks RedBack Networks
2570 North First Street, Suite 410 2570 North First Street, Suite 410
San Jose, CA, 95131, USA San Jose, CA, 95131, USA
Phone: +1 408 571 2699 Phone: +1 408 571 2699
EMail: jeff@redbacknetworks.com EMail: jeff@redbacknetworks.com
A. Change Log A. Change Log
 End of changes. 34 change blocks. 
97 lines changed or deleted 74 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/