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-01.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
Anil Prasad (editor)
MCI Telecommunications Corporation
7502332@mcimail.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 allows 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 two (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 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: 60 (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 file is checkpointed every 60 seconds; i.e. new PVC data 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
otherBinary(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
OCTET STRING,
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
Anil Prasad
MCI Telecommunications Corporation
901 International Parkway
Richardson, Texas 75081
Phone: 214-498-1325
Fax: 214-498-1300
E-mail: 7502332@mcimail.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.
This table permits the administrator or service
provider to query and inspect the data items that
will be logged.
The read-write capabilities for this table enable
a management system to customize data logging to fit
the service provider's accounting system. It permits
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 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. 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 data
sets corresponding to SVCs, PVCs and vendor-specific
accounting MIB objects.
Each row may 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
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
OCTET STRING,
atmAcctngFilenameCurrentSuffix
INTEGER,
atmAcctngControlCommand
INTEGER,
atmAcctngNextSubtree
DataCollectionSubtree,
atmAcctngNextList
DataCollectionList,
atmAcctngDescription
OCTET STRING,
atmAcctngMaxFileSize
INTEGER,
atmAcctngFileEncoding
INTEGER,
atmAcctngCheckpointTimeInterval
INTEGER,
atmAcctngFileChangeTimeInterval
INTEGER,
atmAcctngTrapThreshold
INTEGER,
atmAcctngTrapEnable
TruthValue,
atmAcctngRowStatus
RowStatus
}
atmAcctngControlIndex OBJECT-TYPE
SYNTAX INTEGER
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 OCTET STRING
MAX-ACCESS read-write
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. 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).
For example, PVC data may be stored in the
files PVCData.1, PVCData.2, PVCData.3 ... with the passage
of time.
Each row may 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).
This value may be initialized by the management system on
row creation."
::= { 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
"The atmAcctngFilename object specifies 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. The
suffix is specified by atmAcctngFilenameCurrentSuffix,
and 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 }
atmAcctngControlCommand OBJECT-TYPE
SYNTAX INTEGER { noop(1), swapToNewFile(2) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" A control object for the collection of ATM accounting
data.
When read the value is always 'noop'. Writing a value has
the following effect:
'noop' - no effect,
'swapToNewFile' - the collection of data into the
current file is terminated, and collection continues
into a new file. The new file has an incremented
integral suffix."
::= { 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
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 8 }
atmAcctngDescription OBJECT-TYPE
SYNTAX OCTET STRING
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), otherBinary(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 otherBinary(2)."
DEFVAL { 1 }
::= { atmAcctngControlEntry 11 }
atmAcctngCheckpointTimeInterval OBJECT-TYPE
SYNTAX INTEGER
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is applicable for systems that support
checkpointing (saving newly collected data to the logging
file) at periodic time intervals.
This object is set to the time interval in
seconds that the checkpointing is performed periodically.
If this periodic checkpointing feature is not supported or
enabled on this device, the value is set to -1."
DEFVAL { -1 }
::= { atmAcctngControlEntry 12 }
atmAcctngFileChangeTimeInterval OBJECT-TYPE
SYNTAX INTEGER
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 applicable for systems that support
changing over to new accounting data storage files at
periodic time intervals. 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 { ifIndex }
::= { 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) }
ifIndex OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The interface index in the ifTable for this interface."
::= { atmAcctngDataObjects 1 }
currentTimeStamp OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The timestamp indicating the data collection time."
::= { atmAcctngDataObjects 2 }
sysName 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 INTEGER { p2p(1), p2mp(2) }
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]
