📄 rfc1513.txt
字号:
Network Working Group S. WaldbusserRequest for Comments: 1513 Carnegie Mellon UniversityUpdates: 1271 September 1993 Token Ring Extensions to the Remote Network Monitoring MIBStatus of this Memo This RFC specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.Abstract This memo defines extensions to the Remote Network Monitoring MIB for managing 802.5 Token Ring networks. The Remote Network Monitoring MIB, RFC 1271, defines a framework for remote monitoring functions implemented on a network probe. That MIB defines objects broken down into nine functional groups. Some of those functional groups, the statistics and the history groups, have a view of the data-link layer that is specific to the media type and require specific objects to be defined for each media type. RFC 1271 defined those specific objects necessary for Ethernet. This companion memo defines those specific objects necessary for Token Ring LANs. In addition, this memo defines some additional monitoring functions specifically for Token Ring. These are defined in the Ring Station Group, the Ring Station Order Group, the Ring Station Configuration Group, and the Source Routing Statistics Group.Table of Contents 1. The Network Management Framework ...................... 2 2. Guidelines for implementing RFC1271 objects on a Token Ring network .................................... 3 2.1 Host Group ........................................... 3 2.2 Matrix Group ......................................... 3 2.3 Filter Group ......................................... 3 2.4 Other comments ....................................... 4 3. Overview of the RMON Token Ring Extensions MIB ........ 4 3.1 The Token Ring Statistics Groups ..................... 4 3.2 The Token Ring History Groups ........................ 5 3.3 The Token Ring Ring Station Group .................... 5Waldbusser [Page 1]RFC 1513 Token Ring Extensions to RMON MIB September 1993 3.4 The Token Ring Ring Station Order Group .............. 5 3.5 The Token Ring Ring Station Config Group ............. 5 3.6 The Token Ring Source Routing Group .................. 5 4. Terminology ........................................... 5 5. Definitions ........................................... 6 5.1 The Token Ring Mac-Layer Statistics Group ............ 6 5.2 The Token Ring Promiscuous Statistics Group .......... 14 5.3 The Token Ring Mac-Layer History Group ............... 19 5.4 The Token Ring Promiscuous History Group ............. 27 5.5 The Token Ring Ring Station Group .................... 32 5.6 The Token Ring Ring Station Order Group .............. 41 5.7 The Token Ring Ring Station Config Group ............. 43 5.8 The Token Ring Source Routing Group .................. 47 6. References ............................................ 54 7. Acknowledgments ....................................... 55 8. Security Considerations ............................... 55 9. Author's Address ...................................... 551. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: STD 16, RFC 1155 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. STD 16, RFC 1212 [2] defines a more concise description mechanism, which is wholly consistent with the SMI. STD 17, RFC 1213 [3] which defines MIB-II, the core set of managed objects for the Internet suite of protocols. STD 15, RFC 1157 [4] which defines the SNMP, the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Within a given MIB module, objects are defined using STD 16, RFC 1212's OBJECT-TYPE macro. At a minimum, each object has a name, a syntax, an access-level, and an implementation-status. 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.Waldbusser [Page 2]RFC 1513 Token Ring Extensions to RMON MIB September 1993 The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1[5] language is used for this purpose. However, STD 16, RFC 1155 purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The access-level of an object type defines whether it makes "protocol sense" to read and/or write the value of an instance of the object type. (This access-level is independent of any administrative authorization policy.) The implementation-status of an object type indicates whether the object is mandatory, optional, obsolete, or deprecated.2. Guidelines for implementing RFC1271 objects on a Token Ring network Wherever a MacAddress is to be used in this MIB the source routing bit is stripped off. The resulting address will be consistently valid for all packets sent by a particular node.2.1. Host Group Only Token Ring isolating errors will increment the error counter for a particular hostEntry. The isolating errors are: LineErrors, BurstErrors, ACErrors, InternalErrors, and AbortErrors. ACErrors will increment the error counter only for the nearest upstream neighbor of the station reporting the error. LineErrors and BurstErrors will increment the error counters for the station reporting the error and its neighbor upstream neighbor. InternalErrors and AbortErrors will increment the error counter for the station reporting the error only. In addition, congestionErrors will also be counted for each hostEntry. These errors will be incremented in the host entry of the station that reports the errors in an error report frame. The hostOutPkts and hostOutOctets counters shall not be incremented for packets with errors.2.2. Matrix Group Error counters are never incremented.2.3. Filter Group The following conditions make up the status bitmask for token ring networks:Waldbusser [Page 3]RFC 1513 Token Ring Extensions to RMON MIB September 1993 bit # Error 3 First packet after some packets were dropped 4 Packet with the Frame Copied Bit set 5 Packet with the Address Recognized Bit set For the purpose of the packet match algorithm, the filters assume a 32 byte RIF field. Thus, when matching, the filter is compared to the packet starting at the AC byte of the packet, until the end of the RIF field; then the unused RIF bytes in the filter are skipped and matching proceeds from that point. Any filter "care" bits in the RIF that don't correspond to bytes in the input packet will cause the filter to fail.2.4. Other comments Because soft error report packets may be sent with assured delivery, some errors may be accidently reported twice on devices that perform the RMON function promiscuously.3. Overview of the RMON Token Ring Extensions MIB The Remote Network Monitoring MIB, RFC 1271, defines a framework for remote monitoring functions implemented on a network probe. That MIB defines objects broken down into nine functional groups. Some of those functional groups, the statistics and the history groups, have a view of the data-link layer that is specific to the media type and require specific objects to be defined for each media type. RFC 1271 defined those specific objects necessary for Ethernet. This MIB defines contains four groups that define those specific objects necessary for Token Ring LANs. In addition, this memo defines some additional monitoring functions specifically for Token Ring. These are defined in the Ring Station Group, the Ring Station Order Group, the Ring Station Configuration Group, and the Source Routing Statistics Group.3.1. The Token Ring Statistics Groups The Token Ring statistics groups contain current utilization and error statistics. The statistics are broken down into two groups, the Token Ring Mac-Layer Statistics Group and the Token Ring Promiscuous Statistics Group. The Token Ring Mac-Layer Statistics Group collects information from Mac Layer, including error reports for the ring and ring utilization of the Mac Layer. The Token Ring Promiscuous Statistics Group collects utilization statistics from data packets collected promiscuously.Waldbusser [Page 4]RFC 1513 Token Ring Extensions to RMON MIB September 19933.2. The Token Ring History Groups The Token Ring History Groups contain historical utilization and error statistics. The statistics are broken down into two groups, the Token Ring Mac-Layer History Group and the Token Ring Promiscuous History Group. The Token Ring Mac-Layer History Group collects information from Mac Layer, including error reports for the ring and ring utilization of the Mac Layer. The Token Ring Promiscuous History Group collects utilization statistics from data packets collected promiscuously.3.3. The Token Ring Ring Station Group The Token Ring Ring Station Group contains statistics and status information associated with each Token Ring station on the local ring. In addition, this group provides status information for each ring being monitored.3.4. The Token Ring Ring Station Order Group The Token Ring Ring Station Order Group provides the order of the stations on monitored rings.3.5. The Token Ring Ring Station Config Group The Token Ring Ring Station Config Group manages token ring stations through active means. Any station on a monitored ring may be removed or have configuration information downloaded from it.3.6. The Token Ring Source Routing Group The Token Ring Source Routing Group contains utilization statistics derived from source routing information optionally present in token ring packets.4. Terminology The 802.5 specification [7] defines the term "good frame" as a frame that is bounded by a valid SD and ED, is an integral number of octets in length, is composed of only 0 and 1 bits between the SD and the ED, has the FF bits of the GC field equal to 00 or 01, has a valid FCS, and has a minimum of 18 octets between the SD and the ED. This document will use the term "good frame" in the same manner.Waldbusser [Page 5]RFC 1513 Token Ring Extensions to RMON MIB September 19935. Definitions TOKEN-RING-RMON-MIB DEFINITIONS ::= BEGIN IMPORTS Counter, TimeTicks FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212 OwnerString, EntryStatus, -- Textual Conventions rmon, statistics, history FROM RFC1271-MIB; -- All representations of MAC addresses in this MIB -- Module use, as a textual convention (i.e. this -- convention does not affect their encoding), the -- data type: MacAddress ::= OCTET STRING (SIZE (6)) -- a 6 octet -- address in -- the "canonical" -- order -- defined by IEEE 802.1a, i.e., as if it were -- transmitted least significant bit first, even though -- 802.5 (in contrast to other 802.x protocols) requires -- MAC addresses to be transmitted most significant bit -- first. TimeInterval ::= INTEGER -- A period of time, measured in units of 0.01 seconds. -- This MIB module uses the extended OBJECT-TYPE macro as -- defined in [2]. -- Token Ring Remote Network Monitoring MIB tokenRing OBJECT IDENTIFIER ::= { rmon 10 }
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -