Network Working Group J. Renwick Internet-Draft NetStar, Inc. September 1995 Definitions of Managed Objects for the HIPPI Interface Type draft-renwick-hippimib-01.txt Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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 learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 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 objects for managing HIPPI objects. These objects are intended to be used in conjunction with the interface mib to fully monitor a HIPPI interface. This memo is a modification of an original document by Jeff Miller, Network Systems Corporation, December 18, 1992. J. Renwick Expires March 1996 [Page 1] Internet-Draft draft-renwick-hippimib-01.txt September 1995 TABLE OF CONTENTS 1 The Network Management Framework 2 2 Objects 2 2.1 Format of Definitions 3 3 Overview 3 3.1 Textual Conventions 3 4 Definitions 4 5 Glossary 13 6 Security Considerations 14 7 Acknowledgments 14 8 References 14 9 Author's Address 15 1 The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI. RFC 1156 which defines MIB-I, the core set of managed objects for the Internet suite of protocols. RFC 1213 defines MIB-II, an evolution of MIB-I based on implementation experience and new operational requirements. RFC 1157 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. 2 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) defined in the SMI[1]. 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 J. Renwick Expires March 1996 [Page 2] Internet-Draft draft-renwick-hippimib-01.txt September 1995 this purpose. However, the SMI [1] 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, subject to the additional requirements imposed by the SNMP. 2.1 Format of Definitions Section 6 contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in RFC 1212. 3 Overview HIPPI is a simplex connection, normally configured as a pair of HIPPI endpoints in order to provide a duplex connection. This document describes SNMP objects that can be used to manage HIPPI endpoints. These objects are used when the particular media being used to realize an interface is a HIPPI endpoint. At present, this applies to these values of the ifType variable in the Internet-standard MIB: hippi (47) The definitions contained herein are based on the HIPPI specifications in ANSI X3.183-1991 (HIPPI-PH) and ANSI X3.222-199x (HIPPI-SC) [4, 5]. 3.1 Textual Conventions There are two counters in the HIPPI MIB which if implemented with the current SNMP counter definition of 32 bits would wrap within as little as an 8 second time interval. In order to make these counters retain more useful information an attempt is made to define a counter capable of counting in excess of 2x10**18. This is accomplished by using two integers. One integer is defined as the "low" integer with a range of zero to 999,999,999. The second integer is defined as the "high" integer with a range of zero to 2147483647 (0x7FFFFFFF). When used as a counter, increment the "low" integer until it reaches 1,000,000,000 at which point increment the "high" counter and return the low counter to zero. Should the "high" integer ever reach 2147483647, it will return to J. Renwick Expires March 1996 [Page 3] Internet-Draft draft-renwick-hippimib-01.txt September 1995 zero on its next increment. The reason for using the "low" integer limit of 999,999,999 is for decoding and implementation purposes. The implication of using two integers is that it is impossible to read or set the counter as an autonomous operation. To reduce erroneous information it is suggested that reads and sets be performed as a series of operations either as a single message (preferred) or a series of messages. When setting the counter (mostly likely a reset to zero), first set the high integer, then the low integer, and finally the high integer once again. This type of operation could also be performed for reads so that by comparing the high integers it will be possible to determine if a wrap of the low integer occurred. 4 Definitions HIPPI-MIB DEFINITIONS ::= BEGIN IMPORTS experimental, Counter FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212; -- This MIB module uses the extended OBJECT-TYPE macro -- as defined in RFC 1212 [4]. -- HIPPI MIB module hippi OBJECT IDENTIFIER ::= { experimental 66 } hippiNumber OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "An integer value indicating the number of HippiEntry objects that are in the hippiTable." ::= { hippi 1 } hippiTable OBJECT-TYPE SYNTAX SEQUENCE OF HippiEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The HIPPI table of entries" ::= { hippi 2 } hippiEntry OBJECT-TYPE J. Renwick Expires March 1996 [Page 4] Internet-Draft draft-renwick-hippimib-01.txt September 1995 SYNTAX HippiEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in the HIPPI table" INDEX {hippiIndex } ::= { hippiTable 1 } HippiEntry ::= SEQUENCE { hippiIndex INTEGER, hippiDescr DisplayString, hippiWordSize INTEGER, hippiEndPointType INTEGER, hippiInWordCountHigh INTEGER, hippiInWordCountLow INTEGER, hippiOutWordCountHigh INTEGER, hippiOutWordCountLow INTEGER, hippiInPacketCount INTEGER, hippiOutPacketCount INTEGER, hippiInConnectCount INTEGER, hippiOutConnectCount INTEGER, hippiInRejectCount Counter, hippiOutRejectCount Counter, hippiInAbortCount Counter, hippiOutAbortCount Counter, hippiInParityErrors Counter, hippiInOverrunCount Counter, hippiConnectTimeout INTEGER, hippiOutputTimeout INTEGER, hippiInLastIField J. Renwick Expires March 1996 [Page 5] Internet-Draft draft-renwick-hippimib-01.txt September 1995 OCTET STRING, hippiOutLastIField OCTET STRING, hippiInConnectState INTEGER, hippiOutConnectState INTEGER, hippiInLastErrorType INTEGER, hippiOutLastErrorType INTEGER, hippiInLastErrorIField OCTET STRING, hippiOutLastErrorIField OCTET STRING, hippiInInterconnectStatus INTEGER, hippiOutInterconnectStatus INTEGER } hippiIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Unique sequential integer identifying the hippi media. This is the ifIndex value of the corresponding ifEntry." ::= { hippiEntry 1 } hippiDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual description of the HIPPI interface. This value should include the interface's vendor name, model designation and revision level. It is mandatory that this only contain printable ASCII characters." ::= { hippiEntry 2 } hippiWordSize OBJECT-TYPE SYNTAX INTEGER { single-wide(1), double-wide(2) } ACCESS read-only STATUS mandatory J. Renwick Expires March 1996 [Page 6] Internet-Draft draft-renwick-hippimib-01.txt September 1995 DESCRIPTION "This enumerated value indicates the size of the data bus associated with this particular hippi media. This defines whether the interface operates at 800 or 1600 Mbits/s." ::= { hippiEntry 3 } hippiEndPointType OBJECT-TYPE SYNTAX INTEGER { source(1), destination(2), duplex(3) } ACCESS read-only STATUS mandatory DESCRIPTION "This enumerated value indicates whether this side of the hippi simplex connection is operating as a source or a destination or both." ::= { hippiEntry 4 } hippiInWordCountHigh OBJECT-TYPE SYNTAX INTEGER (0..'7FFFFFFF'h) ACCESS read-only STATUS mandatory DESCRIPTION "The input word counter represents the number of words received through the media. The counter is cleared at power up or reset. This is the portion of the count above 999,999,999." ::= { hippiEntry 5 } hippiInWordCountLow OBJECT-TYPE SYNTAX INTEGER (0..999999999) ACCESS read-only STATUS mandatory DESCRIPTION "The input word counter represents the number of words received through the media. The counter is cleared at power up or reset. This is the portion of the count below 1,000,000,000." ::= { hippiEntry 6 } hippiOutWordCountHigh OBJECT-TYPE SYNTAX INTEGER (0..'7FFFFFFF'h) ACCESS read-only STATUS mandatory DESCRIPTION "The output word counter represents the number of words sent through the media. The counter is cleared at power up or reset. This is the portion of the count above 999,999,999." ::= { hippiEntry 7 } J. Renwick Expires March 1996 [Page 7] Internet-Draft draft-renwick-hippimib-01.txt September 1995 hippiOutWordCountLow OBJECT-TYPE SYNTAX INTEGER (0..999999999) ACCESS read-only STATUS mandatory DESCRIPTION "The output word counter represents the number of words sent through the media. The counter is cleared at power up or reset. This is the portion of the count below 1,000,000,000." ::= { hippiEntry 8 } hippiInPacketCount OBJECT-TYPE SYNTAX INTEGER (0..999999999) ACCESS read-only STATUS mandatory DESCRIPTION "The input packet count represents the number of packets received on the media. The counter is cleared at power up or reset." ::= { hippiEntry 9 } hippiOutPacketCount OBJECT-TYPE SYNTAX INTEGER (0..999999999) ACCESS read-only STATUS mandatory DESCRIPTION "The output packet count represents the number of packets sent on the media." ::= { hippiEntry 10 } hippiInConnectCount OBJECT-TYPE SYNTAX INTEGER (0..999999999) ACCESS read-only STATUS mandatory DESCRIPTION "The input connect count represents the number of connections accepted by the destination. The counter is cleared at power up or reset." ::= { hippiEntry 11 } hippiOutConnectCount OBJECT-TYPE SYNTAX INTEGER (0..999999999) ACCESS read-only STATUS mandatory DESCRIPTION "The output connect count represents the number of connections established by the source. The counter is cleared at power up or reset." ::= { hippiEntry 12 } hippiInRejectCount OBJECT-TYPE J. Renwick Expires March 1996 [Page 8] Internet-Draft draft-renwick-hippimib-01.txt September 1995 SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "Total number of times that the input port has rejected a connection attempt due to I-Field parity errors, busy ports, or invalid source addresses since power up or reset. This object is only meaningful when the hippiEndPointType indicates this interface has a destination end point." ::= { hippiEntry 13 } hippiOutRejectCount OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "This counter represents the number of times that the source's connection request was rejected by a destination since power up or reset." ::= { hippiEntry 14 } hippiInAbortCount OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "This counter represents the number of completed connections that were aborted by a destination end point since power up or reset." ::= { hippiEntry 15 } hippiOutAbortCount OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "This counter represents the number of connections that were terminated prematurely by the source end point since power up or reset." ::= { hippiEntry 16 } hippiInParityErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "This counter represents the number of input parity errors that have occurred on the media since power up or reset. This object only has meaning when the hippiEndPointType indicates the interface contains a destination end point." J. Renwick Expires March 1996 [Page 9] Internet-Draft draft-renwick-hippimib-01.txt September 1995 ::= { hippiEntry 17 } hippiInOverrunCount OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "This counter represents the number of input data overrun errors that have occurred on the media since power up or reset. This object only has meaning when the hippiEndPointType indicates this media is a destination end point." ::= { hippiEntry 18 } hippiConnectTimeout OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The length of time, in milliseconds, that the Source will allow the REQUEST signal to remain asserted before CONNECT is received. At the end of this time, the Source aborts the request. A value of zero indicates that the timeout is unknown. A value of 2,147,483,647 (7fffffff hex) indicates that the timeout is infinite." ::= { hippiEntry 19 } hippiOutputTimeout OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The length of time, in milliseconds, that the Source will wait for READY when its READY counter is zero and it has data to send. At the end of this time, the Source aborts the request. A value of zero indicates that the timeout is unknown. A value of 2,147,483,647 (7fffffff hex) indicates that the timeout is infinite." ::= { hippiEntry 20 } hippiInLastIField OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4) ) ACCESS read-only STATUS mandatory DESCRIPTION "This data type specifies the last HIPPI I-Field value received by the destination." ::= { hippiEntry 21 } J. Renwick Expires March 1996 [Page 10] Internet-Draft draft-renwick-hippimib-01.txt September 1995 hippiOutLastIField OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4) ) ACCESS read-only STATUS mandatory DESCRIPTION "This data type specifies the last HIPPI I-Field value sent by the source." ::= { hippiEntry 22 } hippiInConnectState OBJECT-TYPE SYNTAX INTEGER { disconnected(1), requesting(2), connected(3) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the current connection state of the destination." ::= { hippiEntry 23 } hippiOutConnectState OBJECT-TYPE SYNTAX INTEGER { disconnected(1), requesting(2), connected(3) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates the current connection state of the source." ::= { hippiEntry 24 } hippiInLastErrorType OBJECT-TYPE SYNTAX INTEGER { reject(1), busy(2), parity-error(4), invalid-address(5), overrun(6), sequence-error(7), downline-disconnect(8) } ACCESS read-only STATUS mandatory DESCRIPTION "Contains the type identifier of the last error that was encountered by the destination. The type identifier and the hippiInLastErrorIField values are intended to be used together to aid in determining line connection problems." J. Renwick Expires March 1996 [Page 11] Internet-Draft draft-renwick-hippimib-01.txt September 1995 ::= { hippiEntry 25 } hippiOutLastErrorType OBJECT-TYPE SYNTAX INTEGER { reject(1), busy(2), timeout(3), sequence-error(7), downline-disconnect(8) } ACCESS read-only STATUS mandatory DESCRIPTION "Contains the type identifier of the last error that was encountered by the source. The type identifier and the hippiOutLastErrorIField values are intended to be used together to aid in determining line connection problems." ::= { hippiEntry 26 } hippiInLastErrorIField OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4) ) ACCESS read-only STATUS mandatory DESCRIPTION "This data type specifies the HIPPI I-Field address that was associated with the last error seen by the destination. The hippiInLastErrorType along with this I-Field information is intended to help in determining connection problems." ::= { hippiEntry 27 } hippiOutLastErrorIField OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4) ) ACCESS read-only STATUS mandatory DESCRIPTION "This data type specifies the HIPPI I-Field address that was associated with the last error seen by the source. The hippiOutLastErrorType along with this I-Field information is intended to help in determining connection problems." ::= { hippiEntry 28 } hippiInInterconnectStatus OBJECT-TYPE SYNTAX INTEGER (0..'F'h) ACCESS read-only STATUS mandatory DESCRIPTION "Status of the Interconnect signals at the destination. As defined in HIPPI-PH, HIPPI connections have interconnect signals that are carried to allow endpoints to determine power on and enable. These signals are also useful in determining J. Renwick Expires March 1996 [Page 12] Internet-Draft draft-renwick-hippimib-01.txt September 1995 that cables are established correctly. There are two (2) signals for all connections that are referred to as INTERCONNECT-A. These signals are used to identify a source to destination as well as a destination to source connection. In addition, 64 bit wide connections (1600 MB) have two (2) additional signals that are referred to as INTERCONNECT-B. These are exactly the same as the INTERCONNECT-A signals but are carried on the second set of cables that make up the 64 bit connection. These signals are encoded into the lowest order four (4) bits of the hippiInterconnectStatus object as follows: 0 0 0 1 INTERCONNECT-A Source to Destination (1) 0 0 1 0 INTERCONNECT-A Destination to Source (2) 0 1 0 0 INTERCONNECT-B Source to Destination (4) 1 0 0 0 INTERCONNECT-B Destination to Source (8)" ::= { hippiEntry 29 } hippiOutInterconnectStatus OBJECT-TYPE SYNTAX INTEGER (0..'F'h) ACCESS read-only STATUS mandatory DESCRIPTION "Status of the Interconnect signals at the source. As defined in HIPPI-PH, HIPPI connections have interconnect signals that are carried to allow endpoints to determine power on and enable. These signals are also useful in determining that cables are established correctly. There are two (2) signals for all connections that are referred to as INTERCONNECT-A. These signals are used to identify a source to destination as well as a destination to source connection. In addition, 64 bit wide connections (1600 MB) have two (2) additional signals that are referred to as INTERCONNECT-B. These are exactly the same as the INTERCONNECT-A signals but are carried on the second set of cables that make up the 64 bit connection. These signals are encoded into the lowest order four (4) bits of the hippiInterconnectStatus object as follows: 0 0 0 1 INTERCONNECT-A Source to Destination (1) 0 0 1 0 INTERCONNECT-A Destination to Source (2) 0 1 0 0 INTERCONNECT-B Source to Destination (4) 1 0 0 0 INTERCONNECT-B Destination to Source (8)" ::= { hippiEntry 30 } END 5 Glossary There are a number of terms used in this document that are specific to discussions regarding HIPPI. For convenience, this glossary contains definitions from the HIPPI-PH [5] and HIPPI-SC J. Renwick Expires March 1996 [Page 13] Internet-Draft draft-renwick-hippimib-01.txt September 1995 [6] for those terms. burst. A group of 1 to 256 words. Bursts that contain less the 256 words are called short bursts. Short bursts in a packet indicate either the first or last burst of the packet. connection. Condition of the HIPPI-PH when data transfers from a Source end-point to a Destination end-point are possible. destination. The equipment at the end of the interface that receives the data. end-point. The equipment at either end of the fabric for a particular connection. I-Field. A 32-bit information field sent as part of the sequence of operations establishing a connection from a Source to a Destination. logical address. An address stored in an I-Field that uniquely identifies a Destination end-point or set of end-points. packet. A data set, as defined by HIPPI-PH, sent from Source to Destination. A packet is composed of one or more bursts. source. The equipment at the end of the interface that transmits the data. source address. An address stored in an I-field that uniquely identifies a Source end-point or set of end-points. 6 Security Considerations Security issues are not discussed in this memo. 7 Acknowledgments The following people provided additional comments and suggestions: Bob Kowalski (bjk@network.com), Jim Hughes (hughes@network.com), Philip Cameron (pcameron@tiac.net). 8 References [1] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [2] McCloghrie K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1213, J. Renwick Expires March 1996 [Page 14] Internet-Draft draft-renwick-hippimib-01.txt September 1995 Performance Systems International, March 1991. [3] Rose, M., Editor, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991. [4] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [5] ANSI X3.183-1991, High Performance Parallel Interface, Mechanical, Electrical, and Signalling Protocol Specification (HIPPI-PH). [6] ANSI X3.222-1993, High Performance Parallel Interface - Physical Switch Control (HIPPI-SC). [7] Renwick, J., and Nicholson, A., "IP and ARP on HIPPI", RFC 1374, Cray Research, Inc., October 1992. 9 Author's Address John Renwick NetStar, Inc. 10250 Valley View Road Minneapolis, MN 55344 Phone: (612) 996-6847 EMail: jkr@netstar.com Mail list: hippi-ext@think.com J. Renwick Expires March 1996 [Page 15]