rfc2064.txt

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

Network Working Group                                        N. Brownlee
Request for Comments: 2064                    The University of Auckland
Category: Experimental                                      January 1997


                  Traffic Flow Measurement:  Meter MIB

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in TCP/IP-based internets.
   In particular, this memo defines managed objects used for obtaining
   traffic flow information from network traffic meters.

Table of Contents

   1 The Network Management Framework . . . . . . . . . . . . . . . .  1
   2 Objects  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
     2.1 Format of Definitions . . . . .  . . . . . . . . . . . . . .  3
   3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1 Scope of Definitions, Textual Conventions  . . . . . . . . .  3
     3.2 Usage of the MIB variables  . . . . . . .  . . . . . . . . .  4
   4 Definitions  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37
   6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
   7 Security Considerations  . . . . . . . . . . . . . . . . . . . . 38
   8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38

1 The Network Management Framework

   The Internet-standard Network Management Framework consists of three
   components.  They are:

      RFC 1155 defines the SMI, the mechanisms used for describing and
      naming objects for the purpose of management.  STD 16, RFC 1212
      defines a more concise description mechanism, which is wholly
      consistent with the SMI.







Brownlee                      Experimental                      [Page 1]

RFC 2064                       Meter MIB                    January 1997


      RFC 1156 defines MIB-I, the core set of managed objects for the
      Internet suite of protocols.  STD 17, RFC 1213 [1] defines MIB-II,
      an evolution of MIB-I based on implementation experience and new
      operational requirements.

      STD 15, RFC 1157 defines the SNMP, the protocol used for network
      access to managed objects.

      RFC 1442 [2] defines the SMI for version 2 of the Simple Network
      Management Protocol.

      RFCs 1443 and 1444 [3,4] define Textual Conventions and
      Conformance Statements for version 2 of the Simple Network
      Management Protocol.

      RFC 1452 [5] describes how versions 1 and 2 of the Simple Network
      Management Protocol should coexist.

   The Framework permits new objects to be defined for the purpose of
   experimentation and evaluation.

2 Objects

   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) [6]
   defined in the SMI. In particular, each object has a name, a syntax,
   and an encoding.  The name is an object identifier, an
   administratively assigned name, which specifies an object type.  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 OBJECT
   DESCRIPTOR, to also refer to the object type.

   The syntax of an object type defines the abstract data structure
   corresponding to that object type.  The ASN.1 language is used for
   this purpose.  However, the SMI [2] purposely restricts the ASN.1
   constructs which may be used.  These restrictions are explicitly made
   for simplicity.

   The encoding of an object type is simply how that object type is
   represented using the object type's syntax.  Implicitly tied to the
   notion of an object type's syntax and encoding is how the object type
   is represented when being transmitted on the network.

   The SMI specifies the use of the basic encoding rules of ASN.1 [7],
   subject to the additional requirements imposed by the SNMP.




Brownlee                      Experimental                      [Page 2]

RFC 2064                       Meter MIB                    January 1997


2.1 Format of Definitions

   Section 4 contains contains the specification of all object types
   contained in this MIB module.  These object types are defined using
   the conventions defined in [2] and [3].

3 Overview

   Traffic Flow Measurement seeks to provide a well-defined method for
   gathering traffic flow information from networks and internetworks.
   The background for this is given in "Traffic Flow Measurement:
   Background" [8].  The Realtime Traffic Flow Measurement (rtfm)
   Working Group has produced a measurement architecture to achieve it;
   this is documented in "Traffic Flow Measurement:  Architecture" [9].
   The architecture defines three entities:

     - METERS, which observe network traffic flows and build up a
       table of flow data records for them,

     - METER REAERS, which collect traffic flow data from meters, and

     - MANAGERS, which oversee the operation of meters and meter readers.

   This memo defines the SNMP management information for a Traffic Flow
   Meter (TFM). It documents the earlier work of the Internet Accounting
   Working Group, and is intended to provide a starting point for the
   Realtime Traffic Flow Measurement Working Group.

3.1 Scope of Definitions, Textual Conventions

   All objects defined in this memo are registered in a single subtree
   within the mib-2 namespace [1,2], and are for use in network devices
   which may perform a PDU forwarding or monitoring function.  For these
   devices, the value of the ifSpecific variable in the MIB-II [1] has
   the OBJECT IDENTIFIER value:

   flowMIB OBJECT IDENTIFIER ::=  mib-2 40

   as defined below.

   The RTFM Meter MIB was first produced and tested using SNMPv1.  It
   has been converted into SNMPv2 following the guidelines in RFC 1452
   [5].








Brownlee                      Experimental                      [Page 3]

RFC 2064                       Meter MIB                    January 1997


3.2 Usage of the MIB variables

   The MIB breaks into four parts - control, flows, rules and
   conformance statements.

   The rules implement the minumum set of packet-matching actions, as
   set out in the "Traffic Flow Measurment:  Architecture" document [9].
   In addition they provide for BASIC-style subroutines, allowing a
   network manager to dramatically reduce the number of rules required
   to monitor a big network.

   Traffic flows are identified by a set of attributes for each of its
   end-points.  Attributes include network addresses for each layer of
   the network protocol stack, and 'subscriber ids,' which may be used
   to identify an accountable entity for the flow.

   The conformance statements are set out as defined in [4].  They
   explain what must be implemented in a meter which claims to conform
   to this MIB.

   To retrieve flow data one could simply do a linear scan of the flow
   table.  This would certainly work, but would require a lot of
   protocol exchanges.  To reduce the overhead in retrieving flow data
   the flow table uses a TimeFilter variable, defined as a Textual
   Convention in the RMON2 MIB [10].  This, when used together with
   SNMPv2's GetBulk request, allows a meter reader to scan the flow
   table and upload a specified set of flow attributes for those rows
   which have changed since the last reading.

   As an alternative method of reading flow data, the MIB provides an
   index into the flow table called flowColumnActivityTable.  This is
   (logically) a three-dimensional array, subscripted by flow attribute,
   activity time and starting flow number.  This allows a meter reader
   to retrieve (in an opaque object) data for a column of the flow table
   with a minimum of SNMP overhead.  An attempt has been made to include
   a full ASN.1 definition of the flowColumnActivityData object.

   One aspect of data collection which needs emphasis is that all the
   MIB variables are set up to allow multiple independent colletors to
   work properly, i.e.  the flow table indexes are stateless.  An
   alternative approach would have been to 'snapshot' the flow table,
   which would mean that the meter readers would have to be
   synchronized.  The stateless approach does mean that two meter
   readers will never return exactly the same set of traffic counts, but
   over long periods (e.g.  15-minute collections over a day) the
   discrepancies are acceptable.  If one really needs a snapshot, this
   can be achieved by switching to an identical rule set with a
   different RuleSet number, hence asynchronous collections may be



Brownlee                      Experimental                      [Page 4]

RFC 2064                       Meter MIB                    January 1997


   regarded as a useful generalisation of synchronised ones.

   The control variables are the minimum set required for a meter
   reader.  Their number has been whittled down as experience has been
   gained with the MIB implementation.  A few of them are 'general,'
   i.e.  they control the overall behaviour of the meter.  These are set
   by a single 'master' manager, and no other manager should attempt to
   change their values.  The decision as to which manager is the
   'master' must be made by the network operations personnel
   responsible; this MIB does not attempt to provide any support for
   interaction between managers.

   There are three other groups of control groups, arranged into tables
   in the same way as in the RMON MIB [10].  They are used as follows:

     - RULE SET INFO: Before attempting to download a rule table a manager
       must create a row in the flowRuleSetInfo with flowRuleInfoStatus
       set to 'createAndWait.'  When the rule set is ready the manager
       must set RuleSetInfo to 'active,' indicating that the rule set is
       ready for use.

     - METER READER INFO: Any meter reader wishing to collect data
       reliably for all flows should first create a row in the
       flowReaderInfoTable with flowReaderStatus set to 'active.'  It
       should write that row's flowReaderLastTime object each time it
       starts a collection pass through the flow table.  The meter will
       not recover a flow's memory until every meter reader holding a row
       in this table has collected that flow's data.

     - MANAGER INFO: Any manager wishing to download rule sets to the
       meter must create a row in the flowManagerInfo table with
       flowManagerStatus set to 'active.'.  Once it has a table row, the
       manager may set the control variables in its row so as to cause the
       meter to run any valid rule set held by the meter.

















Brownlee                      Experimental                      [Page 5]

RFC 2064                       Meter MIB                    January 1997


4 Definitions

FLOW-METER-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, TimeTicks
        FROM SNMPv2-SMI
    TEXTUAL-CONVENTION, RowStatus, TimeStamp
        FROM SNMPv2-TC
    OBJECT-GROUP, MODULE-COMPLIANCE
        FROM SNMPv2-CONF
    mib-2, ifIndex
        FROM RFC1213-MIB
    OwnerString
        FROM RMON-MIB;

flowMIB MODULE-IDENTITY
    LAST-UPDATED "9603080208Z"
    ORGANIZATION "IETF Realtime Traffic Flow Measurement Working Group"
    CONTACT-INFO
        "Nevil Brownlee, The University of Auckland
        Email: [e-mail]"
    DESCRIPTION
                "MIB for the RTFM Traffic Flow Meter."
    ::= { mib-2 40 }


flowControl         OBJECT IDENTIFIER ::= { flowMIB 1 }

flowData            OBJECT IDENTIFIER ::= { flowMIB 2 }

flowRules           OBJECT IDENTIFIER ::= { flowMIB 3 }

flowMIBConformance  OBJECT IDENTIFIER ::= { flowMIB 4 }


-- Textual Conventions

TimeFilter ::= TEXTUAL-CONVENTION
    STATUS  current
    DESCRIPTION
        "Used as an index to a table.  A TimeFilter variable allows
        a GetNext or GetBulk request to find rows in a table for
        which the TimeFilter index variable is greater than or equal
        to a specified value.  For example, a meter reader could
        find all rows in the flow table which have been active at or
        since a specified time.




Brownlee                      Experimental                      [Page 6]

RFC 2064                       Meter MIB                    January 1997


        More details on TimeFilter variables, their implementation
        and use can be found in the RMON2 MIB [10]."
    SYNTAX  TimeTicks

AddressType ::= TEXTUAL-CONVENTION
    STATUS  current
    DESCRIPTION
        "Indicates the type of an adjacent address or peer address.
        The values used are from the 'Address Family Numbers' section
        of the Assigned Numbers RFC [11]."
    SYNTAX  INTEGER {
        ip(1),
        nsap(3),
        ieee802(6),
        ipx(11),
        appletalk(12),
        decnet(13) }

AdjacentAddress ::= TEXTUAL-CONVENTION
    STATUS  current
    DESCRIPTION
        "Specifies the value of an adjacent address for various
        media.  The values used for IEEE 802 media are from the
        'Network Management Parameters (ifType definitions)'
        section of the Assigned Numbers RFC [11].  Address format
        depends on the actual media, as follows:

        Ethernet:     ethernet(7)
            6-octet 802.3 MAC address in 'canonical' order

        FDDI:         fddi(15)
            FddiMACLongAddress, i.e. a 6-octet MAC address
            in 'canonical' order  (defined in the FDDI MIB [12])

        Token Ring:   tokenring(9)
            6-octet 802.5 MAC address in 'canonical' order

        PeerAddress:  other(1)
            If traffic is being metered inside a tunnel, its
            adjacent addresses will be the peer addresses of hosts
            at the ends of the tunnel
        "
    SYNTAX OCTET STRING (SIZE (6..20))

PeerAddress ::= TEXTUAL-CONVENTION
    STATUS  current
    DESCRIPTION
        "Specifies the value of a peer address for various network



Brownlee                      Experimental                      [Page 7]

RFC 2064                       Meter MIB                    January 1997


        protocols.  Address format depends on the actual protocol,
        as follows:

        IP:          ip(1)
            4-octet IpAddress  (defined in the SNMPv2 SMI [2])

        CLNS:        nsap(3)
            NsapAddress  (defined in the SNMPv2 SMI [2])

        Novell:      ipx(11)
            4-octet Network number,
            6-octet Host number (MAC address)