    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]