INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 Managed Objects for Managing the Collection and Storage of ATM Accounting Information draft-ietf-atommib-acct-02.txt April 12, 1996 Wedge Greene (editor) MCI Telecommunications Corporation wedgeg@mcimail.com Juha Heinanen Telecom Finland Inc. jh@lohi.dat.tele.fi Keith McCloghrie Cisco Systems, Inc. kzm@cisco.com Michael Maston (editor) StrataCom, Inc. mmaston@strata.com Anil Prasad (editor) StrataCom, Inc. aprasad@strata.com James Watt Newbridge Networks james@newbridge.com 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract This document states requirements for ATM accounting management, and proposes MIB objects to manage the collection and storage of accounting information by ATM network elements. Draft Expires August 23, 1996 [page 1] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 Table of Contents 1.0 Introduction.....................................................3 2.0 Requirements for ATM Accounting Management.......................4 3.0 The SNMP Network Management Framework............................5 4.0 Operational Model................................................5 5.0 Object Definitions...............................................6 5.1 Selection of Accounting Data and File Storage....................6 5.2 Format of Accounting File........................................8 5.3 ASN.1 Definitions................................................10 6.0 Acknowledgments..................................................29 7.0 References.......................................................29 8.0 Security Considerations..........................................30 9.0 Authors' Contact Information.....................................30 Draft Expires August 23, 1996 [page 2] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 1.0 Introduction This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to support ATM accounting management. These managed objects relate to managing the collection and storage of ATM accounting information into data files for later retrieval via a file transfer protocol. In some ATM network environments, there is a need for the network administrator to be able to collect accounting data on the usage of ATM bandwidth/resources by connections within the ATM network. Data collection should be available for switched virtual connections (SVCs and SVPs), and permanent virtual connections (PVCs and PVPs), including soft-permanent virtual connections (SPVCCs and SPVPCs). The potential quantity of such accounting information is such that it is not, in general, feasible to retrieve the information via SNMP. A better method is to store the collected accounting information in a file which can be subsequently retrieved via a file transfer protocol. It is, however, appropriate to provide management control of the collection of such accounting data via SNMP. This document describes a MIB module which provides such control. The intent is to support basic accounting requirements listed in section 2.0, and to define information items and control MIB objects for file logging; additional functionality may be defined in enterprise-specific vendor MIB modules. Accounting management is a key consideration for service providers, who have voiced the need for ATM PVC and SVC accounting information support in the AToM MIB for several reasons, including the following: 1. Without a common specification of the accounting data items and log file structure, accounting management would have to be handled in a vendor-dependent manner, and service providers would have to develop customized software for each switch vendor to integrate the switches into the service provider's accounting management system. Specifying the data items and log structure in the MIB would foster data consistency across switch vendors and greatly facilitate integration of different vendor devices into accounting management systems of service providers. 2. This would facilitate usage based accounting, which would force users to use sensible connection parameter values when they are negotiating connection setup. Draft Expires August 23, 1996 [page 3] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 Key reasons for supporting log files for accounting management include the following: 1. Log files satisfy stringent accounting and billing requirements that most service providers have regarding non-volatile storage of accounting information, amount of storage, loss of information, frequency of polling, etc. A file transfer protocol would be more robust and efficient than SNMP for accounting data retrieval. 2. Log files may be easier for switch vendors to implement. 2.0 Requirements for ATM Accounting Management Key requirements for ATM accounting management include the following: 1. ATM PVC and SVC accounting management data items must be supported. 2. Logging PVC and SVC accounting management information may be optionally supported. However, if accounting management logging is supported, the vendor must conform to the MIB specification in this document. Vendors may support additional objects in enterprise-specific MIBs to extend the base functionality provided by this document. 3. Logging of PVC and SVC information in separate log files, but with similar control mechanisms and associated MIB control objects. 4. Optional support for turning logging on and off per interface (with optional trap notification of change of logging state) via the MIB. 5. Support for inspecting the structure and accounting information item types in the log files, via the MIB, and optionally being able to configure (via Set requests) logging of these accounting management information items. 6. Optional support for checkpoint (data dump) time control features; capability to "dump to file after connection release", or "dump to file every x seconds from now". 7. Flexibility in defining information items for PVC and SVC accounting logging, to support future enhancements. Note: The log files could be transferred to the service provider via FTP or TFTP on demand, at regular time intervals, or when the maximum log size was exceeded; this is implementation dependent, and specification of the mechanism of data transfer is left to the vendor. 8. The accounting records are collected to a log file that has a maximum defined size. 9. A trap can be generated if a high water mark is exceeded in the above log file. Draft Expires August 23, 1996 [page 4] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 10. A MIB control object is required to specify the low level encoding of the accounting data items when stored in the log file. This encoding may be: - BER encoded type/length/value tuples - Other (unspecified, possibly vendor-specific) binary encoding formats. 11. A single operation by the manager should save data to persistent non-volatile storage, a data "file". When the log file is saved, the current row contents of the accounting control table corresponding to the logged data is saved; this information can be later used to interpret the contents of the saved data. 3.0 The SNMP Network Management Framework The SNMP Network Management Framework presently consists of three major components. They are: The SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. The MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols. The protocol, RFC 1157 [3] and/or RFC 1905 [4] - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 4.0 Operational Model The requirement is for ATM switches to collect data concerning the connections which are routed across some subset of their UNI and/or NNI interfaces. The collected data is stored in persistent non-volatile data storage, i.e. into a "file". In order to retrieve the data the administrator or service provider instructs the ATM switch to terminate the collection of data into the current file, and start collecting data into a new file. After this operation, the data in the old file is to available for retrieval via file transfer. A collection file is defined to have a maximum size. When the size of the file currently being collected exceeds a threshold percentage of that maximum size, an SNMP notification (e.g., a trap) can be optionally generated. An SNMP notification can also be optionally generated if the file reaches its maximum size prior to collection being swapped to a new file. Draft Expires August 23, 1996 [page 5] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 Several events may cause the currently active accounting file to be closed and a new file to be created for subsequent logging operations. For example, if a data storage transaction would cause the current file size to exceed the maximum file size, the network element may start accounting data storage operations to a new file; the new file would have an incremented integer-based file extension or suffix. Also, network elements may have time-based file switchover schemes implemented, where accounting data is stored in files that have their suffixes or extensions dependent on the logging time interval. This enables service providers to retrieve accounting data files categorized by time intervals during which the logging took place. The accounting data collected for each connection consists of a set of objects and their values. The set of objects and their values are collected on (either or both of) two occasions: on the release (termination) of an SVC or PVC connection, and/or for every connection on a periodic basis. While collecting data to be stored in one file, the same set of objects are collected for each connection on each occasion. Storing the same set of objects on each occasion requires only the values of those objects to be stored in the file. This results in a significantly smaller file size, since it allows the names of the objects to be stored once and only once in the file, rather than having to store every value as a (name, value) pair. 5.0 Object Definitions 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. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. 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 descriptor, to refer to the object type. 5.1 Selection of Accounting Data and File Storage The items of accounting data to be collected are specified as a set of objects. Which objects are contained in such a set is selectable by an administrator through the specification of N (subtree, list) tuples, where the set of objects to be collected is the union of the subsets specified by each tuple: - 'subtree' specifies a OBJECT IDENTIFIER value such that every object in the subset is named by the subtree's value appended with a single additional sub-identifier. Draft Expires August 23, 1996 [page 6] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 - 'list' specifies an OCTET STRING value, such that if the N-th bit of the string's value is set then the subset contains the object named by appending N as a single additional sub- identifier to the subtree. The rationale for defining each subset as a (subtree,list) tuple is that one and only one OBJECT IDENTIFIER and one OCTET STRING is needed to define the subset of objects. This greatly simplifies the MIB mechanisms needed for selection: an NM application needs only to modify a few scalar variables. An accounting control table (atmAcctngControlTable) is defined to enable the accounting data subsets to be defined in a flexible manner. Each row of the table corresponds to an accounting data set; each row has a (subtree, list) tuple that specifies a subtree and the objects below that subtree that will be logged to a specified file. Enterprise or vendor-specific objects could be logged by adding one or more rows in the table corresponding to those objects to be logged. This scheme greatly facilitates fine-tuning or customization of logging functions for accounting management. For example, three rows could be added to the control table to support logging of data sets corresponding to SVCs, PVCs and vendor-specific accounting MIB objects. Each row of the atmAcctngControlTable table may, but it not required to, specify a different file for storage of the data set for that row; this would enable, for example, PVC and SVC data to be stored in two separate files (if so desired by a service provider). The following file storage paradigms are supported by the defined MIB objects. Both these paradigms are optional; for systems that do not support them, the values of atmAcctngCheckpointTimeInterval and/or atmAcctngFileChangeTimeInterval are set to -1. A. Checkpointing (saving newly collected or measured data) to the file at periodic intervals; the atmAcctngCheckpointTimeInterval object specifies this interval in seconds. B. File Change at periodic intervals. Data may be stored in the current file for a specific period of time (atmAcctngFileChangeTimeInterval), after which the file is closed, and new data is stored in a different file, which has the same filename, but an incremented integral suffix (e.g. 'PVCData.2'). The filename is indicated by the atmAcctngFilename object, and the current suffix is indicated by the atmAcctngFilenameCurrentSuffix object. The following example is provided to illustrate the above concepts. Assuming the relevant MIB objects have the following example values: atmAcctngFilename: PVCData atmAcctngFilenameCurrentSuffix: 1 atmAcctngCurrentSubtree, atmAcctngCurrentList: set to PVC-related object identifiers to be logged atmAcctngDescription: 'PVC Data Set for XYZ switch in Alaska' Draft Expires August 23, 1996 [page 7] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 atmAcctngCheckpointTimeInterval: 900 (seconds) atmAcctngFileChangeTimeInterval: 86400 (seconds; i.e., 24 hours) atmAcctngFileChangeSizeThreshold: 1000000 (bytes), the sequence of events is as follows: i. Logging of PVC data begins to a file named 'PVCData.1' ii. The accounting data is checkpointed every 60 seconds; i.e. data for each PVC is written to the file PVCData.1 every 60 seconds. iii. Every 86400 seconds (24 hours), the current file is closed and a new file is created for logging operations. So for this example, the PVCData.1 file would be closed in 86400 seconds, and the logging operations would commence on file PVCData.2. The service provider may thus extract data selectively from the network element, based on time. iv. In the event that the size of the file PVCData.2 exceeded the atmAcctngFileChangeSizeThreshold value (1000000 bytes for this example), the current file would be closed and a new data file would be created for logging operations. Logging would then commence on file PVCData.3. 5.2 Format of Accounting File The accounting file generated by this process contains the values of MIB objects defined using the SNMPv2 SMI. The standard way to encode the values of SNMP MIB objects in a device-independent manner is through the use of ASN.1's Basic Encoding Rules (BER) [9]. Thus, the format of the accounting file is defined here using ASN.1 [8]. If the equipment vendor chooses to support an alternative binary encoding format, the atmAcctngFileEncoding value is set to other (2) rather than ber(1). The file consists of a sequence of records; each record consists of the following parts: (A). This part specifies: i. The control table index. ii. The (subtree, list) tuple that specifies the objects that follow in subsequent records. iii. A textual description (e.g. "PVC data set") of the objects that follow in subsequent records. (B). Part (A) is followed by a sequence of zero or more connection records, where each connection record contains an ordered set of values. The values occur in ascending order of the sub-identifier which identifies them within the subtree. Draft Expires August 23, 1996 [page 8] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 Formally, an accounting file is an ASN.1 value with the following syntax: File ::= SEQUENCE OF { -- sequence of structured records follow SEQUENCE { atmAcctngControlIndex INTEGER, atmAcctngCurrentSubtree OBJECT IDENTIFIER, atmAcctngCurrentlist OCTET STRING, atmAcctngDescription DisplayString, SEQUENCE OF { -- sequence of connection records -- each record containing an ordered SEQUENCE OF { -- sequence of object values value ObjectSyntax } } } } where: (1) atmAcctngControlIndex specifies the index value of the row of the atmAcctngControlTable containing the format of the objects being logged in this record sequence. (2) (atmAcctngCurrentSubtree, atmAcctngCurrentlist) specifies the set of objects contained in each and every record in the immediately following sequence of connection records. (3) atmAcctngDescription specifies the textual description of the set of objects in the immediately following sequence of connection records. (4) The object values within each connection record occur in the same order as they are represented by the bits in the corresponding list value. (5) ObjectSyntax is defined by the SNMPv2 SMI [1]. The encoding of the above syntax using the Basic Encoding Rules is the same as defined by the SNMPv2 [5], with the following exception: - when encoding the length field for a structured type, i.e., a SEQUENCE or SEQUENCE OF, the indefinite form encoding is permitted. Draft Expires August 23, 1996 [page 9] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 5.3 ASN.1 Definitions ATM-ACCOUNTING-CONTROL-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, NOTIFICATION-TYPE, experimental, Integer32, Counter64 FROM SNMPv2-SMI TEXTUAL-CONVENTION, DateAndTime, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ifIndex FROM IF-MIB AtmAddr FROM ATMTC-MIB; atmAccountingControlMIB MODULE-IDENTITY LAST-UPDATED "9604110000Z" ORGANIZATION " IETF AToM MIB Working Group" CONTACT-INFO " Wedge Greene MCI Telecommunications Corporation 901 International Parkway Richardson, Texas 75081 Phone: 214-498-1232 Fax: 214-498-1300 E-mail: 5540088@mcimail.com Juha Heinanen Telecom Finland Inc. PO Box 228 SF-33101 Tampere Finland Phone: +358 49 500 958 EMail: jh@lohi.dat.tele.fi Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706 Phone: +1 408 526 5260 Email: kzm@cisco.com Michael Maston StrataCom, Inc. 1400 Parkmoor Avenue San Jose, CA 95126 Phone: 408-882-2734 Fax: 408-999-0115 E-mail: mmaston@strata.com Anil Prasad StrataCom, Inc. 1400 Parkmoor Avenue San Jose, CA 95126 Phone: 408-882-7209 Fax: 408-999-0115 E-mail: aprasad@strata.com James Watt Newbridge Networks 600 March Road Kanata ON Canada K2K 2E6 Phone: +1 613 591-3600 Fax: +1 613 591-3680 E-mail: james@newbridge.com" DESCRIPTION "The MIB module for managing the collection and storage of accounting information for connections in an ATM network." ::= { experimental xx } Draft Expires August 23, 1996 [page 10] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 atmAcctngMIBObjects OBJECT IDENTIFIER ::= { atmAccountingControlMIB 1 } atmAcctngControl OBJECT IDENTIFIER ::= { atmAcctngMIBObjects 1 } DataCollectionSubtree ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The subtree component of a (subtree, list) tuple. Such a (subtree, list) tuple defines a set of objects and their values collected as accounting data for an ATM connection. The subtree specifies a single OBJECT IDENTIFIER value such that each object in the set is named by the subtree value appended with a single additional sub-identifier." SYNTAX OBJECT IDENTIFIER DataCollectionList ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The list component of a (subtree, list) tuple. Such a (subtree, list) tuple defines a set of objects and their values collected as accounting data for an ATM connection. The subtree specifies a single OBJECT IDENTIFIER value such that each object in the set is named by the subtree value appended with a single additional sub-identifier. The list specifies a set of data items, where presence of an item in the list indicates that the item is (to be) present in the data collected for an ATM connection; the absence of an item from the list indicates that the item is not (to be) present in the data collected for an ATM connection. Each data item is represented by an integer which when appended (as as additional sub-identifier) to the OBJECT IDENTIFER value of the subtree identified by the tuple, is the name of an object defining that data item (its description and its syntax). The list is specified as an OCTET STRING in which each data item is represented by a single bit, where data items 1 through 8 are represented by the bits in the first octet, data items 9 through 16 by the bits in the second octet, etc. In each octet, the lowest numbered data item is represented by the most significant bit, and the highest numbered data item by the least significant bit. A data item is present in the list when its bit is set, and absent when its bit is reset. If the length of an OCTET STRING value is too short to represent one or more data items defined in a subtree, then those data items are absent from the set identified by the tuple of that subtree and that OCTET STRING value." SYNTAX OCTET STRING (SIZE(0..8)) Draft Expires August 23, 1996 [page 11] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 -- ATM Accounting Control Objects atmAcctngControlTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmAcctngControlEntry ACCESS not-accessible STATUS current DESCRIPTION "This table specifies the accounting information items that will be logged, for all interfaces for which accounting logging is enabled. The read-write capabilities for this table enable a management system to customize data logging to fit the service provider's accounting system. Each row of the table corresponds to an accounting data set; each row has a (subtree, list) tuple that specifies a subtree and the objects below that subtree that will be logged to the specified file. Enterprise or vendor-specific objects could be logged by adding one or more rows in the table corresponding to those objects to be logged. For example, three rows could be added to the control table to support data sets corresponding to SVCs, PVCs and vendor-specific accounting MIB objects. Each row may, but is not required to, specify a different file for storage of the data set for that row; this would enable, for example, PVC and SVC data to be stored in two separate files (if so desired by a service provider)." ::= { atmAcctngControl 1 } atmAcctngControlEntry OBJECT-TYPE SYNTAX AtmAcctngControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry of atmAcctngControlTable that specifies a data set to be logged. For example, this may be a PVC or SVC accounting data set." INDEX { atmAcctngControlIndex } ::= { atmAcctngControlTable 1 } Draft Expires August 23, 1996 [page 12] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 AtmAcctngControlEntry ::= SEQUENCE { atmAcctngControlIndex INTEGER, atmAcctngCurrentSubtree DataCollectionSubtree, atmAcctngCurrentList DataCollectionList, atmAcctngFilename DisplayString, atmAcctngFilenameCurrentSuffix INTEGER, atmAcctngForceCheckpoint TruthValue, atmAcctngNextSubtree DataCollectionSubtree, atmAcctngNextList DataCollectionList, atmAcctngDescription DisplayString, atmAcctngMaxFileSize INTEGER, atmAcctngFileEncoding INTEGER, atmAcctngCheckpointTimeInterval INTEGER, atmAcctngFileChangeTimeInterval INTEGER, atmAcctngTrapThreshold INTEGER, atmAcctngTrapEnable TruthValue, atmAcctngRowStatus RowStatus } atmAcctngControlIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index uniquely identifying the row, and thereby the accounting object data set to be logged." ::= { atmAcctngControlEntry 1} Draft Expires August 23, 1996 [page 13] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 atmAcctngCurrentSubtree OBJECT-TYPE SYNTAX DataCollectionSubtree ACCESS read-write STATUS current DESCRIPTION "The combination of atmAcctngCurrentSubtree and atmAcctngCurrentList specify a (subtree, list) tuple for this row. This tuple defines a set of objects which are currently being collected as the accounting data for each ATM connection for the interfaces on which logging is enabled." ::= { atmAcctngControlEntry 2 } atmAcctngCurrentList OBJECT-TYPE SYNTAX DataCollectionList MAX-ACCESS read-write STATUS current DESCRIPTION "The combination of atmAcctngCurrentSubtree and atmAcctngCurrentList specify one (subtree, list) tuple for this row. This tuple defines a set of objects which are currently being collected as the accounting data for each ATM connection for the interfaces on which logging is enabled." ::= { atmAcctngControlEntry 3 } atmAcctngFilename OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The name of the file (persistent non-volatile data storage) to which the accounting object data set specified by this row is being logged. Note that the file is uniquely identified by a combination of the filename and the filename suffix. For example, PVC data may be stored in the files PVCData.1, PVCData.2, PVCData.3 ... with the passage of time (see atmAcctngFileNameCurrentSuffix). Each row may, but is not required to, specify a different file for storage of the data set for that row; this would enable, for example, PVC and SVC data to be stored in two separate files." ::= { atmAcctngControlEntry 4 } Draft Expires August 23, 1996 [page 14] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 atmAcctngFilenameCurrentSuffix OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-write STATUS current DESCRIPTION "Note that the file is uniquely identified by a combination of the filename (see atmAcctngFileName) and the filename suffix. The suffix is an integer-based string that is incremented sequentially when the maximum file size is exceeded for the current file, or when it is time to change files (for devices that periodically change data storage files with the passage of time). The atmAcctngFilenameCurrentSuffix provides the integer value of the current file suffix. For example, this will have value 40 if the current file is PVCData.40. This value may be initialized by the management system on row creation." ::= { atmAcctngControlEntry 5 } atmAcctngForceCheckpoint OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION " A control object for the collection of ATM accounting data which forces a checkpoint to be invoked." ::= { atmAcctngControlEntry 6 } atmAcctngNextSubtree OBJECT-TYPE SYNTAX DataCollectionSubtree MAX-ACCESS read-only STATUS current Draft Expires August 23, 1996 [page 15] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 DESCRIPTION "The (atmAcctngNextSubtree, atmAcctngNextList) tuple defines a set of objects which are to be collected as the accounting data for each ATM connection. The values of these objects at the time when the file is swapped (either by setting the atmAcctngControlCommand object to 'swapToNewFile', or via an automatic swapover due to the file size being exceeded or due to passage of time) determine the set of objects collected into the new file which begins at that time." ::= { atmAcctngControlEntry 7 } atmAcctngNextList OBJECT-TYPE SYNTAX DataCollectionList MAX-ACCESS read-write STATUS current DESCRIPTION "The (atmAcctngNextSubtree, atmAcctngNextList) tuple defines a set of objects which are to be collected as the accounting data for each ATM connection. The values of these objects at the time when the file is swapped (either by setting the atmAcctngForceCheckpoint object, or via an automatic swapover due to the file size being exceeded or due to passage of time) determine the set of objects collected into the new file which begins at that time." ::= { atmAcctngControlEntry 8 } atmAcctngDescription OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "A textual description of the object data set defined by this row for logging. e.g. ATM PVC data for Alaska switch." ::= { atmAcctngControlEntry 9 } atmAcctngMaxFileSize OBJECT-TYPE SYNTAX INTEGER (100..2147483647) UNITS "bytes" MAX-ACCESS read-write STATUS current Draft Expires August 23, 1996 [page 16] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 DESCRIPTION "The maximum size of the accounting data to be collected into the current file for the data set defined by this row. When the file of collected data reaches this size, new records are discarded. Optionally, the new data may be stored in a new file having the same filename but an incremented filename suffix. The max file size value may be modified at any time, but the new value must be greater the current size of the file into which data is currently being collected." ::= { atmAcctngControlEntry 10 } atmAcctngFileEncoding OBJECT-TYPE SYNTAX INTEGER { ber(1), other (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The encoding format for the accounting data file. The default is BER (the Basic Encoding Rules format). If another (possibly vendor-specific) binary format is chosen, the value is set to other (2)." DEFVAL { 1 } ::= { atmAcctngControlEntry 11 } atmAcctngCheckpointTimeInterval OBJECT-TYPE SYNTAX INTEGER (-1..2147483647) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The time interval between checkpoints at which the collected accounting data is saved to the log file. A value of -1 indicates checkpoints are never performed or not supported." DEFVAL { -1 } ::= { atmAcctngControlEntry 12 } atmAcctngFileChangeTimeInterval OBJECT-TYPE SYNTAX INTEGER (-1..2147483647) UNITS "seconds" MAX-ACCESS read-write STATUS current Draft Expires August 23, 1996 [page 17] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 DESCRIPTION "This object is set to the time interval in seconds (since data storage operations began on the current file) that the file should be closed and data storage be initiated on a new file. For example, if this value is set to 86400 (i.e., 24 hours), the current data file is closed every 24 hours and a new file is created for logging, having an incremented integral filename suffix (e.g., PVCData.101, if the current file was PVCData.100). If this periodic file changeover feature is not supported or enabled on this device, the value is set to -1." DEFVAL { -1 } ::= { atmAcctngControlEntry 13 } atmAcctngTrapThreshold OBJECT-TYPE SYNTAX INTEGER (0..99) MAX-ACCESS read-write STATUS current DESCRIPTION "A percentage of the maximum file size at which a 'nearly- full' trap is generated. The value of 0 indicates that no 'nearly-full' trap is to be generated." ::= { atmAcctngControlEntry 14 } atmAcctngTrapEnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "An indication of whether the atmAcctngFileNearlyFull and atmAcctngFileFull traps are enabled." ::= { atmAcctngControlEntry 15 } atmAcctngRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create a new row or modify or delete an existing row in this table." DEFVAL { active } ::= { atmAcctngControlEntry 16 } Draft Expires August 23, 1996 [page 18] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 -- Per-interface control table atmAcctngControlIfTable OBJECT-TYPE SYNTAX SEQUENCE OF AtmAcctngControlIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table controlling whether ATM accounting data is to be collected for the switch's UNI/NNI interfaces, i.e., each interface for which each the corresponding ifType has a value of atm(37) or atmLogicial(80)." ::= { atmAcctngControl 2 } atmAcctngControlIfEntry OBJECT-TYPE SYNTAX AtmAcctngControlIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry which controls whether ATM accounting data is to be collected for an ATM-layer interface." INDEX { atmAcctngIfIndex } ::= { atmAcctngControlIfTable 1 } AtmAcctngControlIfEntry ::= SEQUENCE { atmAcctngControlIfEnable INTEGER, atmAcctngControlIfCollectMode INTEGER } atmAcctngControlIfEnable OBJECT-TYPE SYNTAX INTEGER { permanent(1), switched(2), all(3), interfaceDataOnly(4) none(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the types of connections, if any, for which ATM accounting data is to be collected on this interface. - 'permanent' indicates for permanent (PVC and PVP) connections, - 'switched' indicates for switched (SVC and SVP) connections - 'all' indicates for all connections - 'interfaceDataOnly' indicates for interface (port-level) statistics only. - 'none' indicates that collection is disabled on this interface." ::= { atmAcctngControlIfEntry 1 } Draft Expires August 23, 1996 [page 19] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 atmAcctngControlIfCollectMode OBJECT-TYPE SYNTAX INTEGER { onRelease(1), periodically(2), onReleaseAndPeriodically(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "An indication of when accounting data for this interface is to be written into the current file: - 'onRelease' - whenever a connection on this interface is terminated, either through a Release message or through management removal, information on that connection is written. - 'periodically' - information on all connections on this interface is written on the expiry of a periodic timer, - 'onReleaseAndPeriodically' when a connection is terminated, and on the expiry of a periodic timer." ::= { atmAcctngControlIfEntry 2 } -- definitions of objects for use in specifying the accounting -- data to be collected atmAcctngDataObjects OBJECT-IDENTITY STATUS current DESCRIPTION "This identifier defines a subtree within which various objects are defined such that a set of objects to be collected as accounting data can be specified as a (subtree, list) tuple using this identifier as the subtree." ::= { atmAccountingControlMIB 2 } -- With the definitions below, and a (subtree, list) tuple for -- which subtree has the value atmAcctngDataObjects, -- the list has an effective syntax of: -- -- SYNTAX BITS { -- sysName(1), -- currentTimeStamp(2), -- ifIndex(3), -- connectionType(4), -- castType(5), -- ifName(6), -- vpi(7), -- vci(8), -- callingParty(9), -- calledParty(10), -- callReference(11), -- startTime(12), -- collectionTime(13), -- collectMode(14), -- releaseCause(15), -- serviceCategory(16), Draft Expires August 23, 1996 [page 20] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 -- transmittedCells(17), -- transmittedClp0Cells(18), -- receivedCells(19), -- receivedClp0Cells(20), -- transmitTrafficDescriptorType(21), -- transmitTrafficDescriptorParam1(22), -- transmitTrafficDescriptorParam2(23), -- transmitTrafficDescriptorParam3(24), -- transmitTrafficDescriptorParam4(25), -- transmitTrafficDescriptorParam5(26), -- receiveTrafficDescriptorType(27), -- receiveTrafficDescriptorParam1(28), -- receiveTrafficDescriptorParam2(29), -- receiveTrafficDescriptorParam3(30), -- receiveTrafficDescriptorParam4(31), -- receiveTrafficDescriptorParam5(32) } atmAcctngIfIndex OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The interface index in the ifTable for this interface." ::= { atmAcctngDataObjects 1 } atmAcctngCurrentTimeStamp OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS not-accessible STATUS current DESCRIPTION "The timestamp indicating the data collection time." ::= { atmAcctngDataObjects 2 } atmAcctngSysName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An administratively-assigned name for this managed node. By convention, this is the node's fully-qualified domain name. From MIB-II's system group." ::= { atmAcctngDataObjects 3 } atmAcctngConnectionType OBJECT-TYPE SYNTAX INTEGER { pvc(1), pvp(2), svc(3), svp(4) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of connection." ::= { atmAcctngDataObjects 4 } Draft Expires August 23, 1996 [page 21] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 atmAcctngCastType OBJECT-TYPE SYNTAX INTEGER { p2p(1), p2mp(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "An indication of whether the connection is point-to-point or point-to-multipoint." ::= { atmAcctngDataObjects 5 } atmAcctngIfName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS not-accessible STATUS current DESCRIPTION "A textual name for the interface on which the data for the connection was collected. If the local SNMP agent supports the object ifName, the value of this object must be identical that of ifName in the conceptual row of the ifTable for this interface, i.e., the row corresponding to this interface for which ifType has a value of atm(37) or atmLogicial(80)." ::= { atmAcctngDataObjects 6 } atmAcctngVpi OBJECT-TYPE SYNTAX INTEGER (0..4095) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VPI used for the connection." ::= { atmAcctngDataObjects 7 } atmAcctngVci OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The VCI used for the connection." ::= { atmAcctngDataObjects 8 } atmAcctngCallingParty OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible STATUS current DESCRIPTION "The connection's calling party. If unknown (e.g., for a PVC), then the value of this object is the zero-length string." ::= { atmAcctngDataObjects 9 } atmAcctngCalledParty OBJECT-TYPE SYNTAX AtmAddr MAX-ACCESS not-accessible STATUS current Draft Expires August 23, 1996 [page 22] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 DESCRIPTION "The connection's called party. If unknown (e.g., for a PVC), then the value of this object is the zero-length string." ::= { atmAcctngDataObjects 10 } atmAcctngCallReference OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The connection's call reference value. If unknown (e.g., for a PVC), then the value of this object is zero." ::= { atmAcctngDataObjects 11 } atmAcctngStartTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS not-accessible STATUS current DESCRIPTION "The time when the connection was established." ::= { atmAcctngDataObjects 12 } atmAcctngCollectionTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS not-accessible STATUS current DESCRIPTION "The time at which the connection data was collected." ::= { atmAcctngDataObjects 13 } atmAcctngCollectMode OBJECT-TYPE SYNTAX INTEGER { onRelease(1), periodically(2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The reason why this connection data was collected." ::= { atmAcctngDataObjects 14 } atmAcctngReleaseCause OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "If the connection data was collected because of the release of an SVC, then this is the cause code in the Release message for the connection; otherwise, this object has the value zero." ::= { atmAcctngDataObjects 15 } Draft Expires August 23, 1996 [page 23] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 atmAcctngServiceCategory OBJECT-TYPE SYNTAX INTEGER { cbr(1), vbrRt(2), vbrNrt(3), abr(4), ubr(5), undefined(6) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The connection's service category." ::= { atmAcctngDataObjects 16 } atmAcctngTransmittedCells OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The number of cells transmitted by this switch on this connection." ::= { atmAcctngDataObjects 17 } atmAcctngTransmittedClp0Cells OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The number of cells with CLP=0 transmitted by this switch on this connection." ::= { atmAcctngDataObjects 18 } atmAcctngReceivedCells OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The number of cells received by this switch on this connection." ::= { atmAcctngDataObjects 19 } atmAcctngReceivedClp0Cells OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The number of cells with CLP=0 received by this switch on this connection." ::= { atmAcctngDataObjects 20 } atmAcctngTransmitTrafficDescriptorType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The traffic descriptor type in the direction in which the switch transmits cells on the connection." ::= { atmAcctngDataObjects 21 } Draft Expires August 23, 1996 [page 24] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 atmAcctngTransmitTrafficDescriptorParam1 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The first traffic descriptor parameter in the direction in which this switch transmits cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngTransmitTrafficDescriptorType." ::= { atmAcctngDataObjects 22 } atmAcctngTransmitTrafficDescriptorParam2 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The second traffic descriptor parameter in the direction in which this switch transmits cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngTransmitTrafficDescriptorType." ::= { atmAcctngDataObjects 23 } atmAcctngTransmitTrafficDescriptorParam3 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The third traffic descriptor parameter in the direction in which this switch transmits cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngTransmitTrafficDescriptorType." ::= { atmAcctngDataObjects 24 } atmAcctngTransmitTrafficDescriptorParam4 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The fourth traffic descriptor parameter in the direction in which this switch transmits cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngTransmitTrafficDescriptorType." ::= { atmAcctngDataObjects 25 } atmAcctngTransmitTrafficDescriptorParam5 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The fifth traffic descriptor parameter in the direction in which this switch transmits cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngTransmitTrafficDescriptorType." ::= { atmAcctngDataObjects 26 } Draft Expires August 23, 1996 [page 25] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 atmAcctngReceiveTrafficDescriptorType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The traffic descriptor type in the direction in which this switch receives cells on this connection." ::= { atmAcctngDataObjects 27 } atmAcctngReceiveTrafficDescriptorParam1 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The first traffic descriptor parameter in the direction in which this switch receives cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngReceiveTrafficDescriptorType." ::= { atmAcctngDataObjects 28 } atmAcctngReceiveTrafficDescriptorParam2 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The second traffic descriptor parameter in the direction in which this switch receives cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngReceiveTrafficDescriptorType." ::= { atmAcctngDataObjects 29 } atmAcctngReceiveTrafficDescriptorParam3 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The third traffic descriptor parameter in the direction in which this switch receives cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngReceiveTrafficDescriptorType." ::= { atmAcctngDataObjects 30 } atmAcctngReceiveTrafficDescriptorParam4 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The fourth traffic descriptor parameter in the direction in which this switch receives cells on this connection. Interpretation of this parameter is dependent on the value Draft Expires August 23, 1996 [page 26] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 of atmAcctngReceiveTrafficDescriptorType." ::= { atmAcctngDataObjects 31 } atmAcctngReceiveTrafficDescriptorParam5 OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The fifth traffic descriptor parameter in the direction in which this switch receives cells on this connection. Interpretation of this parameter is dependent on the value of atmAcctngReceiveTrafficDescriptorType." ::= { atmAcctngDataObjects 32 } -- notifications atmAcctngNotifications OBJECT IDENTIFIER ::= { atmAccountingControlMIB 3 } atmAcctngNotifyPrefix OBJECT IDENTIFIER ::= { atmAcctngNotifications 0 } atmAcctngFileNearlyFull NOTIFICATION-TYPE OBJECTS { atmAcctngControlIndex, atmAcctngControlMaximumFileSize, atmAcctngControlTrapThreshold } STATUS current DESCRIPTION "An indication that the size of the file into which ATM accounting information is currently being collected has exceeded the threshold percentage of its maximum file size." ::= { atmAcctngNotifyPrefix 1 } atmAcctngFileFull NOTIFICATION-TYPE OBJECTS { atmAcctngControlIndex, atmAcctngControlMaximumFileSize } STATUS current DESCRIPTION "An indication that the size of the file into which ATM accounting information is currently being collected has reached its maximum file size, and that new accounting data is now being discarded or being stored in a new file. This could be used as an indication to upload the file to the service provider's accounting management system." ::= { atmAcctngNotifyPrefix 2 } Draft Expires August 23, 1996 [page 27] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 -- conformance information atmAcctngConformance OBJECT IDENTIFIER ::= { atmAccountingControlMIB 4 } atmAcctngGroups OBJECT IDENTIFIER ::= { atmAcctngConformance 1 } atmAcctngCompliances OBJECT IDENTIFIER ::= { atmAcctngConformance 2 } -- compliance statements atmAcctngCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for ATM switches which implement the ATM Accounting Control MIB." MODULE -- this module MANDATORY-GROUPS { atmAcctngBasicGroup } ::= { atmAcctngCompliances 1 } -- units of conformance atmAcctngBasicGroup OBJECT-GROUP OBJECTS { atmAcctngControlIndex, atmAcctngCurrentSubtree, atmAcctngCurrentList, atmAcctngFilename, atmAcctngFilenameCurrentSuffix, atmAcctngControlCommand, atmAcctngNextSubtree, atmAcctngNextList, atmAcctngDescription, atmAcctngMaxFileSize, atmAcctngFileEncoding, atmAcctngCheckpointTimeInterval, atmAcctngFileChangeTimeInterval, atmAcctngTrapThreshold, atmAcctngTrapEnable, atmAcctngRowStatus, atmAcctngControlIfEnable, atmAcctngControlIfCollectMode } STATUS current DESCRIPTION "A collection of objects providing control of the basic collection of ATM accounting data." ::= { atmAcctngGroups 1 } END Draft Expires August 23, 1996 [page 28] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 6. Acknowledgements The following people contributed to this document through discussion and active participation on the AToM MIB e-mail discussion list: Chris Atkins, Erik Fretheim, Perttula Mika, Mike Noto, Kaj Tesink, James Watt. 7. References [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [3] Case, J., Fedor, M., Schoffstall, M., J. Davin, "Simple Network Management Protocol", RFC 1157, May 1990. [4] SNMPv2 Working Group, 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. [5] SNMPv2 Working Group, 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. [6] Ahmed, M., and K. Tesink, "Definitions of Managed Objects for ATM Management using SMIv2", RFC 1695, August 1994. [7] Noto, M., and K. Tesink, "Definitions of Textual Conventions and OBJECT-IDENTITY Objects for ATM Management", Internet Draft, February 1996. [8] Information processing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, Internation Standard 8824, December 1987. [9] Information processing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, Internation Standard 8825, December 1987. [10]. Prasad, A., and Sehgal, A., "Proposed enhancements to the M4 interface requirements", ATM Forum 95-1632, December 1995. [11]. RFC 1695, ATM Management Objects, August 1994. Draft Expires August 23, 1996 [page 29] INTERNET-DRAFT Managed Objects...ATM Accounting Information April 1996 8. Security Considerations Security issues are not discussed in this memo. 9. Authors' Contact Information Wedge Greene MCI Telecommunications Corporation 901 International Parkway Richardson, Texas 75081 Phone: 214-498-1232 Fax: 214-498-1300 E-mail: wedgeg@mcimail.com Juha Heinanen Telecom Finland Inc. PO Box 228 SF-33101 Tampere Finland Phone: +358 49 500 958 EMail: jh@lohi.dat.tele.fi Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706 Phone: +1 408 526 5260 Email: kzm@cisco.com Anil Prasad MCI Telecommunications Corporation 901 International Parkway Richardson, Texas 75081 Phone: 214-498-1325 Fax: 214-498-1300 E-mail: 7502332@mcimail.com Draft Expires August 23, 1996 [page 30]