rfc2724.txt

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

Network Working Group                                       S. Handelman
Request for Comments: 2724                                    S. Stibler
Category: Experimental                                               IBM
                                                             N. Brownlee
                                              The University of Auckland
                                                                 G. Ruth
                                                     GTE Internetworking
                                                            October 1999


           RTFM: New Attributes for Traffic Flow Measurement

Status of this Memo

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

Copyright Notice

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

Abstract

   The RTFM Traffic Measurement Architecture provides a general
   framework for describing and measuring network traffic flows.  Flows
   are defined in terms of their Address Attribute values and measured
   by a 'Traffic Meter'.  This document discusses RTFM flows and the
   attributes which they can have, so as to provide a logical framework
   for extending the architecture by adding new attributes.

   Extensions described include Address Attributes such as DSCodePoint,
   SourceASN and DestASN, and Group Attributes such as short-term bit
   rates and turnaround times.  Quality of Service parameters for
   Integrated Services are also discussed.

Table of Contents

   1  Introduction .  . . . . . . . . . . . . . . . . . . . . . . . . 2
      1.1 RTFM's Definition of Flows  . . . . . . . . . . . . . . . . 3
      1.2 RTFM's Current Definition of Flows and their Attributes . . 3
      1.3 RTFM Flows, Integrated Services, IPPM and Research in Flows 4
   2  Flow Abstractions . . . . . . . . . . . . . . . . . . . . . . . 5
      2.1 Meter Readers and Meters  . . . . . . . . . . . . . . . . . 5
      2.2 Attribute Types . . . . . . . . . . . . . . . . . . . . . . 6
      2.3 Packet Traces . . . . . . . . . . . . . . . . . . . . . . . 7
      2.4 Aggregate Attributes  . . . . . . . . . . . . . . . . . . . 8



Handelman, et al.             Experimental                      [Page 1]

RFC 2724                  RTFM: New Attributes              October 1999


      2.5 Group Attributes  . . . . . . . . . . . . . . . . . . . . . 8
      2.6 Actions on Exceptions . . . . . . . . . . . . . . . . . . .10
   3  Extensions to the 'Basic' RTFM Meter  . . . . . . . . . . . . .10
      3.1 Flow table extensions . . . . . . . . . . . . . . . . . . .10
      3.2 Specifying Distributions in RuleSets  . . . . . . . . . . .11
      3.3 Reading Distributions . . . . . . . . . . . . . . . . . . .13
   4  Extensions to the Rules Table, Attribute Numbers  . . . . . . .13
   5  Security Considerations . . . . . . . . . . . . . . . . . . . .15
   6  References  . . . . . . . . . . . . . . . . . . . . . . . . . .16
   7  Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . .17
   8  Full Copyright Statement  . . . . . . . . . . . . . . . . . . .18

1  Introduction

   The Real-Time Flow Measurement (RTFM) Working Group (WG) has
   developed a system for measuring and reporting information about
   traffic flows in the Internet.  This document explores the definition
   of extensions to the flow measurements as currently defined in
   [RTFM-ARC]. The new attributes described in this document will be
   useful for monitoring network performance and will expand the scope
   of RTFM beyond simple measurement of traffic volumes.  A companion
   document to this memo will be written to define MIB structures for
   the new attributes.

   This memo was started in 1996 to advance the work of the RTFM group.
   The goal of this work is to produce a simple set of abstractions,
   which can be easily implemented and at the same time enhance the
   value of RTFM Meters.  This document also defines a method for
   organizing the flow abstractions to augment the existing RTFM flow
   table.

   Implementations of the RTFM Meter have been done by Nevil Brownlee in
   the University of Auckland, NZ, and Stephen Stibler and Sig Handelman
   at IBM in Hawthorne, NY, USA. The RTFM WG has also defined the role
   of the Meter Reader whose role is to retrieve flow data from the
   Meter.

   Note on flows and positioning of meters:

      A flow as it traverses the Internet may have some of its
      characteristics altered as it travels through Routers, Switches,
      and other network units.  It is important to note the spatial
      location of the Meter when referring to attributes of a flow.  An
      example, a server may send a sequence of packets with a definite
      order, and inter packet timing with a leaky bucket algorithm.  A
      meter reading downstream of the leaky bucket would record a set
      with minimal inter packet timing due to the leaky bucket.  At the
      client's location, the packets may arrive out of sequence, with



Handelman, et al.             Experimental                      [Page 2]

RFC 2724                  RTFM: New Attributes              October 1999


      the timings altered.  A meter at the client's location would
      record different attributes for the same flow.

1.1  RTFM's Definition of Flows

   The RTFM Meter architecture views a flow as a set of packets between
   two endpoints (as defined by their source and destination attribute
   values and start and end times), and as BI-DIRECTIONAL (i.e. the
   meter effectively monitors two sub-flows, one in each direction).

   Reasons why RTFM flows are bi-directional:

      -  The WG is interested in understanding the behavior of sessions
         between endpoints.

      -  The endpoint attribute values (the "Address" and "Type" ones)
         are the same for both directions; storing them in bi-
         directional flows reduces the meter's memory demands.

      -  'One-way' (uni-directional) flows are a degenerate case.
         Existing RTFM meters can handle this by using one of the
         computed attributes (e.g. FlowKind) to indicate direction.

1.2  RTFM's Current Definition of Flows and their Attributes

   Flows, as described in the "Architecture" document [RTFM-ARC] have
   the following properties:

   a. They occur between two endpoints, specified as sets of attribute
      values in the meter's current rule set.  A flow is completely
      identified by its set of endpoint attribute values.

   b. Each flow may also have values for "computed" attributes (Class
      and Kind).  These are directly derived from the endpoint attribute
      values.

   c. A new flow is created when a packet is to be counted that does not
      match the attributes of an existing flow. The meter records the
      time when this new flow is created.

   d. Attribute values in (a), (b) and (c) are set when the meter sees
      the first packet for the flow, and are never changed.

   e. Each flow has a "LastTime" attribute, which indicates the time the
      meter last saw a packet for the flow.






Handelman, et al.             Experimental                      [Page 3]

RFC 2724                  RTFM: New Attributes              October 1999


   f. Each flow has two packet and two byte counters, one for each flow
      direction (Forward and Backward).  These are updated as packets
      for the flow are observed by the meter.

   g. ALL the attributes have (more or less) the same meaning for a
      variety of protocols; IPX, AppleTalk, DECnet and CLNS as well as
      TCP/IP.

   Current flow attributes - as described above - fit very well into the
   SNMP data model.  They are either static, or are continuously updated
   counters.  They are NEVER reset.  In this document they will be
   referred to as "old-style" attributes.

   It is easy to add further "old-style" attributes, since they don't
   require any new features in the architecture.  For example:

      -  Count of the number of "lost" packets (determined by watching
         sequence number fields for packets in each direction; only
         available for protocols which have such sequence numbers).

      -  In the future, RTFM could coordinate directly with the Flow
         Label from the IPv6 header.

1.3  RTFM Flows, Integrated Services, IPPM and Research in Flows

   The concept of flows has been studied in various different contexts.
   For the purpose of extending RTFM, a starting point is the work of
   the Integrated Services WG. We will measure quantities that are often
   set by Integrated Services configuration programs.  We will look at
   the work of the Benchmarking/IP Performance Metrics Working Group,
   and also look at the work of Claffy, Braun and Polyzos [C-B-P]. We
   will demonstrate how RTFM can compute throughput, packet loss, and
   delays from flows.

   An example of the use of capacity and performance information is
   found in "The Use of RSVP with IETF Integrated Services" [IIS-RSVP].
   RSVP's use of Integrated Services revolves around Token Bucket Rate,
   Token Bucket Size, Peak Data Rate, Minimum Policed Unit, Maximum
   Packet Size, and the Slack term.  These are set by TSpec, ADspec and
   FLowspec (Integrated Services Keywords), and are used in
   configuration and operation of Integrated Services.  RTFM could
   monitor explicitly Peak Data Rate, Minimum Policed Unit, Maximum
   Packet Size, and the Slack term.  RTFM could infer details of the
   Token Bucket.  The WG will develop measures to work with these
   service metrics.  An initial implementation of IIS Monitoring has
   been developd at CEFRIEL in Italy [IIS-ACCT].





Handelman, et al.             Experimental                      [Page 4]

RFC 2724                  RTFM: New Attributes              October 1999


   RTFM will work with several traffic measurements identified by IPPM
   [IPPM-FRM]. There are three broad areas in which RTFM is useful for
   IPPM.

      -  An RTFM Meter could act as a passive device, gathering traffic
         and performance statistics at appropriate places in networks
         (server or client locations).

      -  RTFM could give detailed analyses of IPPM test flows that pass
         through the Network segment that RTFM is monitoring.

      -  RTFM could be used to identify the most-used paths in a network
         mesh, so that detailed IPPM work could be applied to these most
         used paths.

2  Flow Abstractions

   Performance attributes include throughput, packet loss, delays,
   jitter, and congestion measures.  RTFM will calculate these
   attributes in the form of extensions to the RTFM flow attributes
   according to three general classes:

      -  'Trace', attributes of individual packets in a flow or a
         segment of a flow (e.g. last packet size, last packet arrival
         time).

      -  'Aggregate', attributes derived from the flow taken as a whole
         (e.g. mean rate, max packet size, packet size distribution).

      -  'Group', attributes that depend on groups of packet values
         within the flow (e.g. inter-arrival times, short-term traffic
         rates).

   Note that attributes within each of these classes may have various
   types of values - numbers, distributions, time series, and so on.

2.1  Meter Readers and Meters

   A note on the relation between Meter Readers and Meters.

   Several of the measurements enumerated below can be implemented by a
   Meter Reader that is tied to a meter with very short response time
   and very high bandwidth.  If the Meter Reader and Meter can be
   arranged in such a way, RTFM could collect Packet Traces with time
   stamps and provide them directly to the Meter Reader for further
   processing.





Handelman, et al.             Experimental                      [Page 5]

RFC 2724                  RTFM: New Attributes              October 1999


   A more useful alternative is to have the Meter calculate some flow
   statistics locally.  This allows a looser coupling between the Meter
   and Meter Reader.  RTFM will monitor an 'extended attribute'
   depending upon settings in its Rule table.  RTFM will not create any
   "extended attribute" data without explicit instructions in the Rule
   table.

2.2  Attribute Types

   Section 2 described three different classes of attributes; this
   section considers the "data types" of these attributes.

   Packet Traces (as described below) are a special case in that they
   are tables with each row containing a sequence of values, each of
   varying type.  They are essentially 'compound objects' i.e. lists of
   attribute values for a string of packets.

   Aggregate attributes are like the 'old-style' attributes.  Their
   types are:

      -  Addresses, represented as byte strings (1 to 20 bytes long)

      -  Counters, represented as 64-bit unsigned integers

      -  Times, represented as 32-bit unsigned integers

   Addresses are saved when the first packet of a flow is observed.
   They do not change with time, and they are used as a key to find the
   flow's entry in the meter's flow table.

   Counters are incremented for each packet, and are never reset.  An
   analysis application can compute differences between readings of the
   counters, so as to determine rates for these attributes.  For
   example, if we read flow data at five-minute intervals, we can
   calculate five-minute packet and byte rates for the flow's two
   directions.

   Times are derived from the FirstTime for a flow, which is set when
   its first packet is observed.  LastTime is updated as each packet in
   the flow is observed.

   All the above types have the common feature that they are expressed
   as single values.  At least some of the new attributes will require
   multiple values.  If, for example, we are interested in inter-packet
   time intervals, we can compute an interval for every packet after the
   first.  If we are interested in packet sizes, a new value is obtained
   as each packet arrives.  When it comes to storing this data we have
   two options:



Handelman, et al.             Experimental                      [Page 6]