summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2856.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2856.txt')
-rw-r--r--doc/rfc/rfc2856.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc2856.txt b/doc/rfc/rfc2856.txt
new file mode 100644
index 0000000..52f8a60
--- /dev/null
+++ b/doc/rfc/rfc2856.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group A. Bierman
+Request for Comments: 2856 K. McCloghrie
+Category: Standards Track Cisco Systems, Inc.
+ R. Presuhn
+ BMC Software, Inc.
+ June 2000
+
+
+ Textual Conventions for Additional High Capacity Data Types
+
+Status of this Memo
+
+ This document 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" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ This memo specifies new textual conventions for additional high
+ capacity data types, intended for SNMP implementations which already
+ support the Counter64 data type. The definitions contained in this
+ document represent a short term solution which may be deprecated in
+ the future.
+
+Table of Contents
+
+ 1 The SNMP Management Framework ................................. 2
+ 2 Overview ...................................................... 3
+ 2.1 Short Term and Long Term Objectives ......................... 3
+ 2.2 Limitations of the Textual Convention Approach .............. 3
+ 3 New Textual Conventions ....................................... 4
+ 3.1 CounterBasedGauge64 ......................................... 4
+ 3.2 ZeroBasedCounter64 .......................................... 4
+ 4 Definitions ................................................... 4
+ 5 Intellectual Property ......................................... 7
+ 6 References .................................................... 7
+ 7 Security Considerations ....................................... 9
+ 8 Authors' Addresses ............................................ 9
+ 9 Full Copyright Statement ...................................... 10
+
+
+
+
+
+
+Bierman, et al. Standards Track [Page 1]
+
+RFC 2856 High Capacity Data Types June 2000
+
+
+1. The SNMP Management Framework
+
+ The SNMP Management Framework presently consists of five major
+ components:
+
+ o An overall architecture, described in RFC 2571 [RFC2571].
+
+ o Mechanisms for describing and naming objects and events for the
+ purpose of management. The first version of this Structure of
+ Management Information (SMI) is called SMIv1 and described in STD
+ 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215
+ [RFC1215]. The second version, called SMIv2, is described in STD
+ 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,
+ RFC 2580 [RFC2580].
+
+ o Message protocols for transferring management information. The
+ first version of the SNMP message protocol is called SNMPv1 and
+ described in STD 15, RFC 1157 [RFC1157]. A second version of the
+ SNMP message protocol, which is not an Internet standards track
+ protocol, is called SNMPv2c and described in RFC 1901 [RFC1901]
+ and RFC 1906 [RFC1906]. The third version of the message
+ protocol is called SNMPv3 and described in RFC 1906 [RFC1906],
+ RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
+
+ o Protocol operations for accessing management information. The
+ first set of protocol operations and associated PDU formats is
+ described in STD 15, RFC 1157 [RFC1157]. A second set of
+ protocol operations and associated PDU formats is described in
+ RFC 1905 [RFC1905].
+
+ o A set of fundamental applications described in RFC 2573 [RFC2573]
+ and the view-based access control mechanism described in RFC 2575
+ [RFC2575].
+
+ A more detailed introduction to the current SNMP Management Framework
+ can be found in RFC 2570 [RFC2570].
+
+ Managed objects are accessed via a virtual information store, termed
+ the Management Information Base or MIB. Objects in the MIB are
+ defined using the mechanisms defined in the SMI.
+
+ This memo specifies a MIB module that is compliant to the SMIv2. The
+ textual conventions defined in this MIB module cannot be translated
+ to SMIv1 since the Counter64 type does not exist in SMIv1.
+
+
+
+
+
+
+
+Bierman, et al. Standards Track [Page 2]
+
+RFC 2856 High Capacity Data Types June 2000
+
+
+2. Overview
+
+ The Structure of Management Information [RFC2578] does not explicitly
+ address the question of how to represent integer objects other than
+ counters that would require up to 64 bits to provide the necessary
+ range and precision. There are MIBs in progress targeted for the
+ standards track, which need such data types. This memo specifies a
+ short term solution, using textual conventions, to meet these needs.
+
+2.1. Short Term and Long Term Objectives
+
+ There is an immediate need to provide a Gauge64 data type, similar in
+ semantics to the Gauge32 data type, in order to support common data
+ representations such as:
+
+ - a snapshot of a Counter64 at a given moment, e.g., history ring
+ buffer
+
+ - the difference between two Counter64 values
+
+ There is also an immediate need for a 64-bit zero-based counter type,
+ similar in semantics to the ZeroBasedCounter32 TC defined in the
+ RMON-2 MIB [RFC2021].
+
+ Both of these textual conventions should use a base type of Gauge64
+ or Unsigned64, but such a base type is not available. Until such a
+ base type is defined and deployed, these temporary textual
+ conventions (which use a base type of Counter64) will be used in MIBs
+ which require unsigned 64-bit data types.
+
+ In order to be backward compatible with existing implementations of
+ Counter64, the ASN.1 encoding of unsigned 64-bit data types must be
+ identical to the encoding of Counter64 objects, i.e., identified by
+ the [APPLICATION 6] ASN.1 tag.
+
+ Note that the textual conventions defined in this document represent
+ a limited and short-term solution to the problem. These textual
+ conventions may be deprecated as a long term solution is defined and
+ deployed to replace them. A MIB object which uses either of these
+ textual conventions may also eventually have to be deprecated.
+
+2.2. Limitations of the Textual Convention Approach
+
+ New unsigned data types with textual conventions based on the
+ Counter64 tag, instead of a new (or other existing) ASN.1 tag have
+ some limitations:
+
+
+
+
+
+Bierman, et al. Standards Track [Page 3]
+
+RFC 2856 High Capacity Data Types June 2000
+
+
+ - The MAX-ACCESS of the TC must be read-only, because the MAX-ACCESS
+ of the underlying Counter64 type is read-only.
+
+ - No sub-range can be specified on the TC-derived types, because
+ sub-ranges are not allowed on Counter64 objects.
+
+ - No DEFVAL clause can be specified for the TC-derived types,
+ because DEFVALs are not allowed on Counter64 objects.
+
+ - The TC-derived types cannot be used in an INDEX clause, because
+ there is no INDEX clause mapping defined for objects of type
+ Counter64.
+
+3. New Textual Conventions
+
+ The following textual conventions are defined to support unsigned
+ 64-bit data types.
+
+3.1. CounterBasedGauge64
+
+ This textual convention defines a 64-bit gauge, but defined with
+ Counter64 syntax, since no Gauge64 or Unsigned64 base type is
+ available in SMIv2.
+
+ This TC is used for storing the difference between two Counter64
+ values, or simply storing a snapshot of a Counter64 value at a given
+ moment in time.
+
+3.2. ZeroBasedCounter64
+
+ This textual convention defines a 64-bit counter with an initial
+ value of zero, instead of an arbitrary initial value.
+
+ This TC is used for counter objects in tables which are instantiated
+ by management application action.
+
+4. Definitions
+
+ HCNUM-TC DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ MODULE-IDENTITY, mib-2, Counter64
+ FROM SNMPv2-SMI
+ TEXTUAL-CONVENTION
+ FROM SNMPv2-TC;
+
+ hcnumTC MODULE-IDENTITY
+ LAST-UPDATED "200006080000Z"
+
+
+
+Bierman, et al. Standards Track [Page 4]
+
+RFC 2856 High Capacity Data Types June 2000
+
+
+ ORGANIZATION "IETF OPS Area"
+ CONTACT-INFO
+ " E-mail: mibs@ops.ietf.org
+ Subscribe: majordomo@psg.com
+ with msg body: subscribe mibs
+
+ Andy Bierman
+ Cisco Systems Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134 USA
+ +1 408-527-3711
+ abierman@cisco.com
+
+ Keith McCloghrie
+ Cisco Systems Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134 USA
+ +1 408-526-5260
+ kzm@cisco.com
+
+ Randy Presuhn
+ BMC Software, Inc.
+ Office 1-3141
+ 2141 North First Street
+ San Jose, California 95131 USA
+ +1 408 546-1006
+ rpresuhn@bmc.com"
+ DESCRIPTION
+ "A MIB module containing textual conventions
+ for high capacity data types. This module
+ addresses an immediate need for data types not directly
+ supported in the SMIv2. This short-term solution
+ is meant to be deprecated as a long-term solution
+ is deployed."
+ REVISION "200006080000Z"
+ DESCRIPTION
+ "Initial Version of the High Capacity Numbers
+ MIB module, published as RFC 2856."
+ ::= { mib-2 78 }
+
+ CounterBasedGauge64 ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "The CounterBasedGauge64 type represents a non-negative
+ integer, which may increase or decrease, but shall never
+ exceed a maximum value, nor fall below a minimum value. The
+ maximum value can not be greater than 2^64-1
+ (18446744073709551615 decimal), and the minimum value can
+
+
+
+Bierman, et al. Standards Track [Page 5]
+
+RFC 2856 High Capacity Data Types June 2000
+
+
+ not be smaller than 0. The value of a CounterBasedGauge64
+ has its maximum value whenever the information being modeled
+ is greater than or equal to its maximum value, and has its
+ minimum value whenever the information being modeled is
+ smaller than or equal to its minimum value. If the
+ information being modeled subsequently decreases below
+ (increases above) the maximum (minimum) value, the
+ CounterBasedGauge64 also decreases (increases).
+
+ Note that this TC is not strictly supported in SMIv2,
+ because the 'always increasing' and 'counter wrap' semantics
+ associated with the Counter64 base type are not preserved.
+ It is possible that management applications which rely
+ solely upon the (Counter64) ASN.1 tag to determine object
+ semantics will mistakenly operate upon objects of this type
+ as they would for Counter64 objects.
+
+ This textual convention represents a limited and short-term
+ solution, and may be deprecated as a long term solution is
+ defined and deployed to replace it."
+ SYNTAX Counter64
+
+
+ ZeroBasedCounter64 ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "This TC describes an object which counts events with the
+ following semantics: objects of this type will be set to
+ zero(0) on creation and will thereafter count appropriate
+ events, wrapping back to zero(0) when the value 2^64 is
+ reached.
+
+ Provided that an application discovers the new object within
+ the minimum time to wrap it can use the initial value as a
+ delta since it last polled the table of which this object is
+ part. It is important for a management station to be aware
+ of this minimum time and the actual time between polls, and
+ to discard data if the actual time is too long or there is
+ no defined minimum time.
+
+ Typically this TC is used in tables where the INDEX space is
+ constantly changing and/or the TimeFilter mechanism is in
+ use.
+
+ Note that this textual convention does not retain all the
+ semantics of the Counter64 base type. Specifically, a
+ Counter64 has an arbitrary initial value, but objects
+ defined with this TC are required to start at the value
+
+
+
+Bierman, et al. Standards Track [Page 6]
+
+RFC 2856 High Capacity Data Types June 2000
+
+
+ zero. This behavior is not likely to have any adverse
+ effects on management applications which are expecting
+ Counter64 semantics.
+
+ This textual convention represents a limited and short-term
+ solution, and may be deprecated as a long term solution is
+ defined and deployed to replace it."
+ SYNTAX Counter64
+
+ END
+
+5. Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards- related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+6. References
+
+ [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
+ of Management Information for TCP/IP-based Internets",
+ STD 16, RFC 1155, May 1990.
+
+ [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin,
+ "Simple Network Management Protocol", STD 15, RFC 1157,
+ May 1990.
+
+ [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions",
+ STD 16, RFC 1212, March 1991.
+
+ [RFC1215] Rose, M., "A Convention for Defining Traps for use with
+ the SNMP", RFC 1215, March 1991.
+
+
+
+Bierman, et al. Standards Track [Page 7]
+
+RFC 2856 High Capacity Data Types June 2000
+
+
+ [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+ "Introduction to Community-based SNMPv2", RFC 1901,
+ January 1996.
+
+ [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+ "Protocol Operations for Version 2 of the Simple Network
+ Management Protocol (SNMPv2)", RFC 1905, January 1996.
+
+ [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+ "Transport Mappings for Version 2 of the Simple Network
+ Management Protocol (SNMPv2)", RFC 1906, January 1996.
+
+ [RFC2021] Waldbusser, S., "Remote Network Monitoring MIB (RMON-2)",
+ RFC 2021, January 1997.
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart,
+ "Introduction to Version 3 of the Internet-standard
+ Network Management Framework", RFC 2570, April 1999.
+
+ [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An
+ Architecture for Describing SNMP Management Frameworks",
+ RFC 2571, April 1999.
+
+ [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen,
+ "Message Processing and Dispatching for the Simple
+ Network Management Protocol (SNMP)", RFC 2572, April
+ 1999.
+
+ [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3
+ Applications", RFC 2573, April 1999.
+
+ [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model
+ (USM) for version 3 of the Simple Network Management
+ Protocol (SNMPv3)", RFC 2574, April 1999.
+
+ [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
+ Access Control Model (VACM) for the Simple Network
+ Management Protocol (SNMP)", RFC 2575, April 1999.
+
+ [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+ Rose, M. and S. Waldbusser, "Structure of Management
+ Information Version 2 (SMIv2)", STD 58, RFC 2578, April
+ 1999.
+
+
+
+
+
+Bierman, et al. Standards Track [Page 8]
+
+RFC 2856 High Capacity Data Types June 2000
+
+
+ [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+ Rose, M. and S. Waldbusser, "Textual Conventions for
+ SMIv2", STD 58, RFC 2579, April 1999.
+
+ [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+ Rose, M. and S. Waldbusser, "Conformance Statements for
+ SMIv2", STD 58, RFC 2580, April 1999.
+
+7. Security Considerations
+
+ This module does not define any management objects. Instead, it
+ defines a set of textual conventions which may be used by other MIB
+ modules to define management objects.
+
+ Meaningful security considerations can only be written in the modules
+ that define management objects.
+
+8. Authors' Addresses
+
+ Andy Bierman
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134 USA
+
+ Phone: +1 408-527-3711
+ EMail: abierman@cisco.com
+
+
+ Keith McCloghrie
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134 USA
+
+ Phone: +1 408-526-5260
+ EMail: kzm@cisco.com
+
+
+ Randy Presuhn
+ BMC Software, Inc.
+ Office 1-3141
+ 2141 North First Street
+ San Jose, California 95131 USA
+
+ Phone: +1 408 546-1006
+ EMail: rpresuhn@bmc.com
+
+
+
+
+
+
+Bierman, et al. Standards Track [Page 9]
+
+RFC 2856 High Capacity Data Types June 2000
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bierman, et al. Standards Track [Page 10]
+