rfc2513.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                      K. McCloghrie
Request for Comments: 2513                           Cisco Systems, Inc.
Category: Standards Track                                    J. Heinanen
                                                     Telia Finland, Inc.
                                                               W. Greene
                                            MCI Telecommunications Corp.
                                                               A. Prasad
                                                     Cisco Systems, Inc.
                                                           February 1999


             Managed Objects for Controlling the Collection
               and Storage of Accounting Information for
                      Connection-Oriented Networks

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Table of Contents

   1 Introduction .................................................... 2
   2 The SNMP Network Management Framework ........................... 2
   3 Overview ........................................................ 3
   3.1 Operational Model ............................................. 3
   3.2 Selection of Accounting Data .................................. 5
   3.3 Format of Collection File ..................................... 6
   4 Definitions ..................................................... 9
   5 Acknowledgements ................................................25
   6 References ......................................................25
   7 Security Considerations .........................................27
   8 IANA Considerations .............................................27
   9 Authors' Addresses ..............................................28
   10 Full Copyright Statement .......................................29









McCloghrie, et. al.         Standards Track                     [Page 1]

RFC 2513           Connection-Oriented Accounting MIB      February 1999


1.  Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects used for controlling the
   collection and storage of accounting information for connection-
   oriented networks such as ATM.  The accounting data is collected into
   files for later retrieval via a file transfer protocol.  For
   information on data which can be collected for ATM networks, see
   [19].

2.  The SNMP Network Management Framework

   The SNMP Management Framework presently consists of five major
   components:

   o    An overall architecture, described in RFC 2271 [1].

   o    Mechanisms for describing and naming objects and events for the
        purpose of management.  The first version of this Structure of
        Management Information (SMI) is called SMIv1 and described in
        STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4].
        The second version, called SMIv2, is described in RFC 1902 [5],
        RFC 1903 [6] and RFC 1904 [7].

   o    Message protocols for transferring management information.  The
        first version of the SNMP message protocol is called SNMPv1 and
        described in STD 15, RFC 1157 [8].  A second version of the SNMP
        message protocol, which is not an Internet standards track
        protocol, is called SNMPv2c and described in RFC 1901 [9] and
        RFC 1906 [10].  The third version of the message protocol is
        called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and
        RFC 2274 [12].

   o    Protocol operations for accessing management information.  The
        first set of protocol operations and associated PDU formats is
        described in STD 15, RFC 1157 [8].  A second set of protocol
        operations and associated PDU formats is described in RFC 1905
        [13].

   o    A set of fundamental applications described in RFC 2273 [14] and
        the view-based access control mechanism described in RFC 2275
        [15].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.




McCloghrie, et. al.         Standards Track                     [Page 2]

RFC 2513           Connection-Oriented Accounting MIB      February 1999


   This memo specifies a MIB module that is compliant to the SMIv2.  A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations.  The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (e.g., use of Counter64).  Some machine
   readable information in SMIv2 will be converted into textual
   descriptions in SMIv1 during the translation process.  However, this
   loss of machine readable information is not considered to change the
   semantics of the MIB.

3.  Overview

   In some connection-oriented network environments, there is a need for
   the network administrator to be able to collect accounting data on
   the usage of bandwidth/resources by connections (e.g., ATM
   connections) within the 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).  This need exists for ATM networks,
   and may well exist for other connection-oriented networks, such as
   Frame Relay.

   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
   selection and collection of such accounting data via SNMP.  This memo
   describes a MIB module which provides such control in a manner
   independent of the type of network.  One or more other documents
   provide definitions of particular items of accounting data which can
   be selected; for example, a particular set of data items which can be
   collected for ATM networks is specified in [19].

3.1.  Operational Model

   The requirement is for switches (e.g., ATM switches) to collect data
   concerning the connections which are routed across some subset of
   their interfaces (e.g., ATM UNI and/or NNI interfaces).  The
   collected data is stored into one or more "files".  The use of
   multiple files allows, for example, the data collected for PVCs to be
   different from that collected for SVCs.

   In order to retrieve the data currently being stored in a file, the
   administrator instructs the switch to terminate the collection of
   data into that file, and start collecting data into a new file.



McCloghrie, et. al.         Standards Track                     [Page 3]

RFC 2513           Connection-Oriented Accounting MIB      February 1999


   After this operation, the data in the old file is 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 might also be generated
   if the file reaches its maximum size.

   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 one or more of the following occasions:

   (1)  on the release (termination) of a connection optionally
        including failed connection attempts;

   (2)  for each active connection (having a particular minimum age) on
        a periodic basis;

   (3)  for each active connection (having a particular minimum age)
        when so commanded by a management application.

   While collecting data to be stored in a particular file, the same set
   of objects is collected for each connection on each occasion.  Having
   the same set of objects stored on each occasion allows the
   optimization of storing only the values of those objects.  This
   results in a significantly smaller file size, since it allows the
   names of the objects to be stored once and only once at the beginning
   of the file, rather than having to store every value as a (name,
   value) pair.

   Two modes of agent behaviour are allowed on the event of a file
   reaching its maximum size:

   (1)  management application in control:

        The agent does not automatically swap to a new file; rather, it
        discards newly collected data until the management application
        subsequently instructs it to swap to a new file.  Before
        swapping to a new file, the name of the file into which data is
        currently being collected is an implementation issue of no
        concern to an NM application; after swapping to a new file, the
        name of the file available for retrieval is as specified by the
        controlling MIB objects.  This behaviour allows the application
        to know exactly how many files need to be retrieved and their
        names without having to perform any type of file directory
        operation, but also results in the possibility that data will be
        discarded if the application does not instruct the agent to swap



McCloghrie, et. al.         Standards Track                     [Page 4]

RFC 2513           Connection-Oriented Accounting MIB      February 1999


        within the required time frame.

   (2)  agent automatically swaps to new file:

        The agent terminates collection into the current (full) file,
        and begins collecting data into a new version of the same base
        file name.  This behaviour aims to avoid loss of data by
        assuming that additional storage space is actually available to
        create a new version of the file.  To support this behaviour,
        files are named using suffixes, such that when the current
        version of the file becomes full, the agent begins collecting
        data into a file with the same base file-name but with an
        incremented (or otherwise modified) suffix.  This requires the
        application to perform file directory operations prior to
        retrieving completed files in order to know how many and which
        suffixes have been used.

   With either behaviour, any completed file must be an integral number
   of connection records (see below).  When a file reaches its maximum
   size, collection into that file is terminated either immediately
   before or immediately after storing the whole of the current
   connection record into the file.  The former causes the file to be
   just less than its maximum size, and the latter causes the file to be
   just greater than its maximum size.

3.2.  Selection of Accounting Data

   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 one or more
   (subtree, list) tuples, where the set of objects to be collected is
   the union of the subsets specified by each tuple:

       'subtree' specifies an OBJECT IDENTIFIER value such that every
           object in the subset is named by the subtree's value appended
           with a single additional sub-identifier.

       'list' specifies an OCTET STRING value, such that if the N-th bit
           of the string's value is set then the 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 simplifies the MIB
   mechanisms needed for selection: an NM application needs to create
   only one conceptual row in a MIB table for each subset (rather than
   needing to create a conceptual row in a table for each and every



McCloghrie, et. al.         Standards Track                     [Page 5]

RFC 2513           Connection-Oriented Accounting MIB      February 1999


   object in the set).

   The number of tuples supported by a particular switch is an
   implementation choice.  One possibility is to support two (subtree,
   list) tuples so that one such tuple can specify a standard 'subtree'
   (e.g., the atmAcctngDataObjects subtree defined in [19]), and the
   second tuple can specify an enterprise-specific 'subtree'; this would
   allow the selected set of objects to be the union of a set of
   standard objects and a set of enterprise-defined objects.

3.3.  Format of Collection File

   A collection file generated by this process contains the values of
   MIB objects defined using the SMIv2.  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) [18].  Thus, the
   standard format of an accounting file is defined here using the same
   adapted subset of ASN.1 [17] as the SMIv2.

   The file consists of a set of header information followed by a
   sequence of zero or more collection records.  The header information
   identifies (via sysName [16]) the switch which collected the data,
   the date and time at which the collection in to this file started,
   and the sequence of one or more (subtree, list) tuples identifying
   the objects whose values are contained in each connection record.
   The header information also includes a textual description of the
   data contained in the file.

   Each connection record contains a sequence of values for each
   identified tuple, in the same order as the tuples are identified in
   the header information.  For each tuple, the sequence of values are
   in ascending order of the sub-identifier which identifies them within
   the subtree.

   Formally, an accounting file is an ASN.1 value with the following
   syntax:

File ::=
   [1]
      IMPLICIT SEQUENCE {
                           -- header information
          sysName               -- name of the switch
              DisplayString,

          description           -- textual description of the collection
              DisplayString,

          startTime             -- start time of the collection



McCloghrie, et. al.         Standards Track                     [Page 6]

RFC 2513           Connection-Oriented Accounting MIB      February 1999


              DateAndTime,

          SEQUENCE OF {         -- sequence of (subtree, list) tuples
              SEQUENCE {
                  subtree
                      OBJECT IDENTIFIER,
                  list
                      OCTET STRING
              }
          }
                           -- sequence of connection records
          SEQUENCE OF {
                                -- each record containing a sequence
              SEQUENCE OF {     -- per identified tuple

                  SEQUENCE OF {     -- each per-tuple sequence containing
                      value         -- a sequence of object values
                          ObjectSyntax
                  }
              }
          }
      }

   where:

   (1)  the value of the sysName component is that of the sysName object
        in the System group [16].

   (2)  each (subtree, list) specifies the set of objects contained in
        that tuple's sequence within each and every connection record.

   (3)  the tuples' sequences within each connection record occur in the
        same order as the (subtree, list) tuples occur in the header
        information.

   (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 SMIv2 [5].

   (6)  One particular category of object values deserves special
        attention: an object defined to hold the checksum value of an
        accounting record (e.g., atmAcctngRecordCrc16, defined in [19]).
        An object in this category will generally have a SYNTAX of a
        fixed-length OCTET STRING, and have its value initialized to the
        string of all zeros when composing the accounting record
        containing it, with the location of these zeros being saved.



McCloghrie, et. al.         Standards Track                     [Page 7]

RFC 2513           Connection-Oriented Accounting MIB      February 1999


        Once the record is generated, the checksum is calculated over
        the whole connection record (including the starting SEQUENCE OF
        and the trailing end-of-contents octets, if used), and then the
        zeros are overwritten (at the saved location) by the calculated
        value of the checksum.

   The encoding of the above syntax using the Basic Encoding Rules is
   the same as defined by the SNMPv2 [10], with the following exception: