<pre>Network Working Group                                        N. Brownlee
Request for Comments: 2722                    The University of Auckland
Obsoletes: <a href="./rfc2063">2063</a>                                                 C. Mills
Category: Informational                            GTE Laboratories, Inc
                                                                 G. Ruth
                                                     GTE Internetworking
                                                            October 1999


                 <span class="h1">Traffic Flow Measurement: Architecture</span>

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   This document provides a general framework for describing network
   traffic flows, presents an architecture for traffic flow measurement
   and reporting, discusses how this relates to an overall network
   traffic flow architecture and indicates how it can be used within the
   Internet.

Table of Contents

   1  Statement of Purpose and Scope                                   3
      <a href="#section-1.1">1.1</a>  Introduction . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-3">3</a>

   2  Traffic Flow Measurement Architecture                            5
      <a href="#section-2.1">2.1</a>  Meters and Traffic Flows . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
      <a href="#section-2.2">2.2</a>  Interaction Between METER and METER READER . . . . . . . .  <a href="#page-7">7</a>
      <a href="#section-2.3">2.3</a>  Interaction Between MANAGER and METER  . . . . . . . . . .  <a href="#page-7">7</a>
      <a href="#section-2.4">2.4</a>  Interaction Between MANAGER and METER READER . . . . . . .  <a href="#page-8">8</a>
      <a href="#section-2.5">2.5</a>  Multiple METERs or METER READERs . . . . . . . . . . . . .  <a href="#page-9">9</a>
      <a href="#section-2.6">2.6</a>  Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . <a href="#page-10">10</a>
      <a href="#section-2.7">2.7</a>  METER READERs and APPLICATIONs . . . . . . . . . . . . . . <a href="#page-10">10</a>

   3  Traffic Flows and Reporting Granularity                         10
      <a href="#section-3.1">3.1</a>  Flows and their Attributes . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
      <a href="#section-3.2">3.2</a>  Granularity of Flow Measurements . . . . . . . . . . . . . <a href="#page-13">13</a>
      3.3  Rolling Counters, Timestamps, Report-in-One-Bucket-Only  . 15




<span class="grey">Brownlee, et al.             Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   4  Meters                                                          17
      <a href="#section-4.1">4.1</a>  Meter Structure  . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
      <a href="#section-4.2">4.2</a>  Flow Table . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
      <a href="#section-4.3">4.3</a>  Packet Handling, Packet Matching . . . . . . . . . . . . . <a href="#page-20">20</a>
      <a href="#section-4.4">4.4</a>  Rules and Rule Sets  . . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
      <a href="#section-4.5">4.5</a>  Maintaining the Flow Table . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
      <a href="#section-4.6">4.6</a>  Handling Increasing Traffic Levels . . . . . . . . . . . . <a href="#page-29">29</a>

   5  Meter Readers                                                   30
      <a href="#section-5.1">5.1</a>  Identifying Flows in Flow Records  . . . . . . . . . . . . <a href="#page-30">30</a>
      <a href="#section-5.2">5.2</a>  Usage Records, Flow Data Files . . . . . . . . . . . . . . <a href="#page-30">30</a>
      <a href="#section-5.3">5.3</a>  Meter to Meter Reader:  Usage Record Transmission  . . . . <a href="#page-31">31</a>

   6  Managers                                                        32
      <a href="#section-6.1">6.1</a>  Between Manager and Meter:  Control Functions  . . . . . . <a href="#page-32">32</a>
      <a href="#section-6.2">6.2</a>  Between Manager and Meter Reader:  Control Functions . . . <a href="#page-33">33</a>
      <a href="#section-6.3">6.3</a>  Exception Conditions . . . . . . . . . . . . . . . . . . . <a href="#page-35">35</a>
      <a href="#section-6.4">6.4</a>  Standard Rule Sets . . . . . . . . . . . . . . . . . . . . <a href="#page-36">36</a>

   7  Security Considerations                                         36
      <a href="#section-7.1">7.1</a>  Threat Analysis  . . . . . . . . . . . . . . . . . . . . . <a href="#page-36">36</a>
      <a href="#section-7.2">7.2</a>  Countermeasures  . . . . . . . . . . . . . . . . . . . . . <a href="#page-37">37</a>

   8  IANA Considerations                                             39
      <a href="#section-8.1">8.1</a>  PME Opcodes  . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-39">39</a>
      <a href="#section-8.2">8.2</a>  RTFM Attributes  . . . . . . . . . . . . . . . . . . . . . <a href="#page-39">39</a>

   9  APPENDICES                                                      41
      <a href="#appendix-A">Appendix A</a>: Network Characterisation  . . . . . . . . . . . . . <a href="#page-41">41</a>
      <a href="#appendix-B">Appendix B</a>: Recommended Traffic Flow Measurement Capabilities . 42
      <a href="#appendix-C">Appendix C</a>: List of Defined Flow Attributes . . . . . . . . . . <a href="#page-43">43</a>
      <a href="#appendix-D">Appendix D</a>: List of Meter Control Variables . . . . . . . . . . <a href="#page-44">44</a>
      <a href="#appendix-E">Appendix E</a>: Changes Introduced Since <a href="./rfc2063">RFC 2063</a> . . . . . . . . . <a href="#page-45">45</a>

   <a href="#section-10">10</a> Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-45">45</a>
   <a href="#section-11">11</a> References  . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-46">46</a>
   <a href="#section-12">12</a> Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . <a href="#page-47">47</a>
   <a href="#section-13">13</a> Full Copyright Statement  . . . . . . . . . . . . . . . . . . . <a href="#page-48">48</a>













<span class="grey">Brownlee, et al.             Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>  Statement of Purpose and Scope</span>

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>  Introduction</span>

   This document describes an architecture for traffic flow measurement
   and reporting for data networks which has the following
   characteristics:

     - The traffic flow model can be consistently applied to any
       protocol, using address attributes in any combination at the
       'adjacent' (see below), network and transport layers of the
       networking stack.

     - Traffic flow attributes are defined in such a way that they are
       valid for multiple networking protocol stacks, and that traffic
       flow measurement implementations are useful in multi-protocol
       environments.

     - Users may specify their traffic flow measurement requirements by
       writing 'rule sets', allowing them to collect the flow data they
       need while ignoring other traffic.

     - The data reduction effort to produce requested traffic flow
       information is placed as near as possible to the network
       measurement point.  This minimises the volume of data to be
       obtained (and transmitted across the network for storage), and
       reduces the amount of processing required in traffic flow
       analysis applications.

   'Adjacent' (as used above) is a layer-neutral term for the next layer
   down in a particular instantiation of protocol layering. Although
   'adjacent' will usually imply the link layer (MAC addresses), it does
   not implicitly advocate or dismiss any particular form of tunnelling
   or layering.

   The architecture specifies common metrics for measuring traffic
   flows.  By using the same metrics, traffic flow data can be exchanged
   and compared across multiple platforms.  Such data is useful for:

     - Understanding the behaviour of existing networks,

     - Planning for network development and expansion,

     - Quantification of network performance,

     - Verifying the quality of network service, and

     - Attribution of network usage to users.



<span class="grey">Brownlee, et al.             Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   The traffic flow measurement architecture is deliberately structured
   using address attributes which are defined in a consistent way at the
   Adjacent, Network and Transport layers of the networking stack,
   allowing specific implementations of the architecture to be used
   effectively in multi-protocol environments.  Within this document the
   term 'usage data' is used as a generic term for the data obtained
   using the traffic flow measurement architecture.

   In principle one might define address attributes for higher layers,
   but it would be very difficult to do this in a general way.  However,
   if an RTFM traffic meter were implemented within an application
   server (where it had direct access to application-specific usage
   information), it would be possible to use the rest of the RTFM
   architecture to collect application-specific information.  Use of the
   same model for both network- and application-level measurement in
   this way could simplify the development of generic analysis
   applications which process and/or correlate both traffic and usage
   information.  Experimental work in this area is described in the RTFM
   'New Attributes' document [<a href="#ref-RTFM-NEW" title="&quot;RTFM: New Attributes for Traffic Flow Measurment&quot;">RTFM-NEW</a>].

   This document is not a protocol specification.  It specifies and
   structures the information that a traffic flow measurement system
   needs to collect, describes requirements that such a system must
   meet, and outlines tradeoffs which may be made by an implementor.

   For performance reasons, it may be desirable to use traffic
   information gathered through traffic flow measurement in lieu of
   network statistics obtained in other ways.  Although the
   quantification of network performance is not the primary purpose of
   this architecture, the measured traffic flow data may be used as an
   indication of network performance.

   A cost recovery structure decides "who pays for what." The major
   issue here is how to construct a tariff (who gets billed, how much,
   for which things, based on what information, etc).  Tariff issues
   include fairness, predictability (how well can subscribers forecast
   their network charges), practicality (of gathering the data and
   administering the tariff), incentives (e.g. encouraging off-peak
   use), and cost recovery goals (100% recovery, subsidisation, profit
   making).  Issues such as these are not covered here.

   Background information explaining why this approach was selected is
   provided by the 'Internet Accounting Background' RFC [<a href="#ref-ACT-BKG" title="&quot;Internet Accounting Background&quot;">ACT-BKG</a>].








<span class="grey">Brownlee, et al.             Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>  Traffic Flow Measurement Architecture</span>

   A traffic flow measurement system is used by Network Operations
   personnel to aid in managing and developing a network.  It provides a
   tool for measuring and understanding the network's traffic flows.
   This information is useful for many purposes, as mentioned in <a href="#section-1">section</a>
   <a href="#section-1">1</a> (above).

   The following sections outline a model for traffic flow measurement,
   which draws from working drafts of the OSI accounting model [OSI-
   ACT].

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>  Meters and Traffic Flows</span>

   At the heart of the traffic measurement model are network entities
   called traffic METERS.  Meters observe packets as they pass by a
   single point on their way through the network and classify them into
   certain groups.  For each such group a meter will accumulate certain
   attributes, for example the numbers of packets and bytes observed for
   the group.  These METERED TRAFFIC GROUPS may correspond to a user, a
   host system, a network, a group of networks, a particular transport
   address (e.g. an IP port number), any combination of the above, etc,
   depending on the meter's configuration.

   We assume that routers or traffic monitors throughout a network are
   instrumented with meters to measure traffic.  Issues surrounding the
   choice of meter placement are discussed in the 'Internet Accounting
   Background' RFC [<a href="#ref-ACT-BKG" title="&quot;Internet Accounting Background&quot;">ACT-BKG</a>]. An important aspect of meters is that they
   provide a way of succinctly aggregating traffic information.

   For the purpose of traffic flow measurement we define the concept of
   a TRAFFIC FLOW, which is like an artificial logical equivalent to a
   call or connection.  A flow is a portion of traffic, delimited by a
   start and stop time, that belongs to one of the metered traffic
   groups mentioned above.  Attribute values (source/destination
   addresses, packet counts, byte counts, etc.)  associated with a flow
   are aggregate quantities reflecting events which take place in the
   DURATION between the start and stop times.  The start time of a flow
   is fixed for a given flow; the stop time may increase with the age of
   the flow.

   For connectionless network protocols such as IP there is by
   definition no way to tell whether a packet with a particular
   source/destination combination is part of a stream of packets or not
   - each packet is completely independent.  A traffic meter has, as
   part of its configuration, a set of 'rules' which specify the flows
   of interest, in terms of the values of their attributes.  It derives
   attribute values from each observed packet, and uses these to decide



<span class="grey">Brownlee, et al.             Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   which flow they belong to.  Classifying packets into 'flows' in this
   way provides an economical and practical way to measure network
   traffic and subdivide it into well-defined groups.

   Usage information which is not derivable from traffic flows may also
   be of interest.  For example, an application may wish to record
   accesses to various different information resources or a host may
   wish to record the username (subscriber id) for a particular network
   session.  Provision is made in the traffic flow architecture to do
   this.  In the future the measurement model may be extended to gather
   such information from applications and hosts so as to provide values
   for higher-layer flow attributes.

   As well as FLOWS and METERS, the traffic flow measurement model
   includes MANAGERS, METER READERS and ANALYSIS APPLICATIONS, which are
   explained in following sections.  The relationships between them are
   shown by the diagram below.  Numbers on the diagram refer to sections
   in this document.

                      MANAGER
                     /       \
                2.3 /         \ 2.4
                   /           \
                  /             \                      ANALYSIS
              METER  &lt;-----&gt;  METER READER  &lt;-----&gt;   APPLICATION
                       2.2                    2.7


     - MANAGER: A traffic measurement manager is an application which
       configures 'meter' entities and controls 'meter reader' entities.
       It sends configuration commands to the meters, and supervises the
       proper operation of each meter and meter reader.  It may well be
       convenient to combine the functions of meter reader and manager
       within a single network entity.

     - METER: Meters are placed at measurement points determined by
       Network Operations personnel.  Each meter selectively records
       network activity as directed by its configuration settings.  It
       can also aggregate, transform and further process the recorded
       activity before the data is stored.  The processed and stored
       results are called the 'usage data'.

     - METER READER: A meter reader transports usage data from meters so
       that it is available to analysis applications.







<span class="grey">Brownlee, et al.             Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


     - ANALYSIS APPLICATION: An analysis application processes the
       usage data so as to provide information and reports which are
       useful for network engineering and management purposes.  Examples
       include:

         - TRAFFIC FLOW MATRICES, showing the total flow rates for many
           of the possible paths within an internet.

         - FLOW RATE FREQUENCY DISTRIBUTIONS, summarizing flow rates
           over a period of time.

         - USAGE DATA showing the total traffic volumes sent and
           received by particular hosts.

   The operation of the traffic measurement system as a whole is best
   understood by considering the interactions between its components.
   These are described in the following sections.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>  Interaction Between METER and METER READER</span>

   The information which travels along this path is the usage data
   itself.  A meter holds usage data in an array of flow data records
   known as the FLOW TABLE.  A meter reader may collect the data in any
   suitable manner.  For example it might upload a copy of the whole
   flow table using a file transfer protocol, or read the records in the
   current flow set one at a time using a suitable data transfer
   protocol.  Note that the meter reader need not read complete flow
   data records, a subset of their attribute values may well be
   sufficient.

   A meter reader may collect usage data from one or more meters.  Data
   may be collected from the meters at any time.  There is no
   requirement for collections to be synchronized in any way.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>  Interaction Between MANAGER and METER</span>

   A manager is responsible for configuring and controlling one or more
   meters.  Each meter's configuration includes information such as:

     - Flow specifications, e.g. which traffic flows are to be measured,
       how they are to be aggregated, and any data the meter is required
       to compute for each flow being measured.

     - Meter control parameters, e.g. the 'inactivity' time for flows
       (if no packets belonging to a flow are seen for this time the
       flow is considered to have ended, i.e. to have become idle).





<span class="grey">Brownlee, et al.             Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


     - Sampling behaviour.  Normally every packet will be observed.  It
       may sometimes be necessary to use sampling techniques so as to
       observe only some of the packets (see following note).

   A note about sampling: Current experience with the measurement
   architecture shows that a carefully-designed and implemented meter
   compresses the data sufficiently well that in normal LANs and WANs of
   today sampling is seldom, if ever, needed.  For this reason sampling
   algorithms are not prescribed by the architecture.  If sampling is
   needed, e.g. for metering a very-high-speed network with fine-grained
   flows, the sampling technique should be carefully chosen so as not to
   bias the results.  For a good introduction to this topic see the IPPM
   Working Group's RFC "Framework for IP Performance Metrics" [IPPM-
   FRM].

   A meter may run several rule sets concurrently on behalf of one or
   more managers, and any manager may download a set of flow
   specifications (i.e. a 'rule set') to a meter.  Control parameters
   which apply to an individual rule set should be set by the manager
   after it downloads that rule set.

   One manager should be designated as the 'master' for a meter.
   Parameters such as sampling behaviour, which affect the overall
   operation of the meter, should only be set by the master manager.

<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>  Interaction Between MANAGER and METER READER</span>

   A manager is responsible for configuring and controlling one or more
   meter readers.  A meter reader may only be controlled by a single
   manager.  A meter reader needs to know at least the following for
   every meter it is collecting usage data from:

     - The meter's unique identity, i.e. its network name or address.

     - How often usage data is to be collected from the meter.

     - Which flow records are to be collected (e.g. all flows, flows for
       a particular rule set, flows which have been active since a given
       time, etc.).

     - Which attribute values are to be collected for the required flow
       records (e.g. all attributes, or a small subset of them)

   Since redundant reporting may be used in order to increase the
   reliability of usage data, exchanges among multiple entities must be
   considered as well.  These are discussed below.





<span class="grey">Brownlee, et al.             Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>  Multiple METERs or METER READERs</span>

                    -- METER READER A --
                   /         |          \
                  /          |           \
          =====METER 1     METER 2=====METER 3    METER 4=====
                              \          |           /
                               \         |          /
                                -- METER READER B --

   Several uniquely identified meters may report to one or more meter
   readers.  The diagram above gives an example of how multiple meters
   and meter readers could be used.

   In the diagram above meter 1 is read by meter reader A, and meter 4
   is read by meter reader B. Meters 1 and 4 have no redundancy; if
   either meter fails, usage data for their network segments will be
   lost.

   Meters 2 and 3, however, measure traffic on the same network segment.
   One of them may fail leaving the other collecting the segment's usage
   data.  Meters 2 and 3 are read by meter reader A and by meter reader
   B.  If one meter reader fails, the other will continue collecting
   usage data from both meters.

   The architecture does not require multiple meter readers to be
   synchronized.  In the situation above meter readers A and B could
   both collect usage data at the same intervals, but not necesarily at
   the same times.  Note that because collections are asynchronous it is
   unlikely that usage records from two different meter readers will
   agree exactly.

   If identical usage records were required from a single meter, a
   manager could achieve this using two identical copies of a ruleset in
   that meter.  Let's call them RS1 and RS2, and assume that RS1 is
   running.  When a collection is to be made the manager switches the
   meter from RS1 to RS2, and directs the meter reader(s) to read flow
   data for RS1 from the meter.  For the next collection the manager
   switches back to RS1, and so on.  Note, however, that it is not
   possible to get identical usage records from more than one meter,
   since there is no way for a manager to switch rulesets in more than
   one meter at the same time.

   If there is only one meter reader and it fails, the meters continue
   to run.  When the meter reader is restarted it can collect all of the
   accumulated flow data.  Should this happen, time resolution will be
   lost (because of the missed collections) but overall traffic flow
   information will not.  The only exception to this would occur if the



<span class="grey">Brownlee, et al.             Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   traffic volume was sufficient to 'roll over' counters for some flows
   during the failure; this is addressed in the section on 'Rolling
   Counters'.

<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>  Interaction Between MANAGERs (MANAGER - MANAGER)</span>

   Synchronization between multiple management systems is the province
   of network management protocols.  This traffic flow measurement
   architecture specifies only the network management controls necessary
   to perform the traffic flow measurement function and does not address
   the more global issues of simultaneous or interleaved (possibly
   conflicting) commands from multiple network management stations or
   the process of transferring control from one network management
   station to another.

<span class="h3"><a class="selflink" id="section-2.7" href="#section-2.7">2.7</a>  METER READERs and APPLICATIONs</span>

   Once a collection of usage data has been assembled by a meter reader
   it can be processed by an analysis application.  Details of analysis
   applications - such as the reports they produce and the data they
   require - are outside the scope of this architecture.

   It should be noted, however, that analysis applications will often
   require considerable amounts of input data.  An important part of
   running a traffic flow measurement system is the storage and regular
   reduction of flow data so as to produce daily, weekly or monthly
   summary files for further analysis.  Again, details of such data
   handling are outside the scope of this architecture.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>  Traffic Flows and Reporting Granularity</span>

   A flow was defined in <a href="#section-2.1">section 2.1</a> above in abstract terms as follows:

       "A TRAFFIC FLOW is an artifical logical equivalent to a call or
       connection, belonging to a (user-specieied) METERED TRAFFIC
       GROUP."

   In practical terms, a flow is a stream of packets observed by the
   meter as they pass across a network between two end points (or from a
   single end point), which have been summarized by a traffic meter for
   analysis purposes.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>  Flows and their Attributes</span>

   Every traffic meter maintains a table of 'flow records' for flows
   seen by the meter.  A flow record holds the values of the ATTRIBUTES
   of interest for its flow.  These attributes might include:




<span class="grey">Brownlee, et al.             Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


     - ADDRESSES for the flow's source and destination.  These comprise
       the protocol type, the source and destination addresses at
       various network layers (extracted from the packet header), and
       the number of the interface on which the packet was observed.

     - First and last TIMES when packets were seen for this flow, i.e.
       the 'creation' and 'last activity' times for the flow.

     - COUNTS for 'forward' (source to destination) and 'backward'
       (destination to source) components (e.g. packets and bytes) of
       the flow's traffic.  The specifying of 'source' and 'destination'
       for flows is discussed in the section on packet matching below.

     - OTHER attributes, e.g. the index of the flow's record in the flow
       table and the rule set number for the rules which the meter was
       running while the flow was observed.  The values of these
       attributes provide a way of distinguishing flows observed by a
       meter at different times.

   The attributes listed in this document (Appendix C) provide a basic
   (i.e. useful minimum) set; IANA considerations for allocating new
   attributes are set out in <a href="#section-8">section 8</a> below.

   A flow's METERED TRAFFIC GROUP is specified by the values of its
   ADDRESS attributes.  For example, if a flow's address attributes were
   specified as "source address = IP address 10.1.0.1, destination
   address = IP address 26.1.0.1" then only IP packets from 10.1.0.1 to
   26.1.0.1 and back would be counted in that flow.  If a flow's address
   attributes specified only that "source address = IP address
   10.1.0.1," then all IP packets from and to 10.1.0.1 would be counted
   in that flow.

   The addresses specifying a flow's address attributes may include one
   or more of the following types:

     - The INTERFACE NUMBER for the flow, i.e. the interface on which
       the meter measured the traffic.  Together with a unique address
       for the meter this uniquely identifies a particular physical-
       level port.

     - The ADJACENT ADDRESS, i.e. the address in the the next layer down
       from the peer address in a particular instantiation of protocol
       layering.  Although 'adjacent' will usually imply the link layer,
       it does not implicitly advocate or dismiss any particular form of
       tunnelling or layering.






<span class="grey">Brownlee, et al.             Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


       For example, if flow measurement is being performed using IP as
       the network layer on an Ethernet LAN [<a href="#ref-802-3" title="2nd edition">802-3</a>], an adjacent address
       will normally be a six-octet Media Access Control (MAC) address.
       For a host connected to the same LAN segment as the meter the
       adjacent address will be the MAC address of that host.  For hosts
       on other LAN segments it will be the MAC address of the adjacent
       (upstream or downstream) router carrying the traffic flow.

     - The PEER ADDRESS, which identifies the source or destination of
       the packet for the network layer (n) at which traffic measurement
       is being performed.  The form of a peer address will depend on
       the network-layer protocol in use, and the measurement network
       layer (n).

     - The TRANSPORT ADDRESS, which identifies the source or destination
       port for the packet, i.e. its (n+1) layer address.  For example,
       if flow measurement is being performed at the IP layer a
       transport address is a two-octet UDP or TCP port number.

   The four definitions above specify addresses for each of the four
   lowest layers of the OSI reference model, i.e. Physical layer, Link
   layer, Network layer and Transport layer.  A FLOW RECORD stores both
   the VALUE for each of its addresses (as described above) and a MASK
   specifying which bits of the address value are being used and which
   are ignored.  Note that if address bits are being ignored the meter
   will set them to zero, however their actual values are undefined.

   One of the key features of the traffic measurement architecture is
   that attributes have essentially the same meaning for different
   protocols, so that analysis applications can use the same reporting
   formats for all protocols.  This is straightforward for peer
   addresses; although the form of addresses differs for the various
   protocols, the meaning of a 'peer address' remains the same.  It
   becomes harder to maintain this correspondence at higher layers - for
   example, at the Network layer IP, Novell IPX and AppleTalk all use
   port numbers as a 'transport address', but CLNP and DECnet have no
   notion of ports.

   Reporting by adjacent intermediate sources and destinations or simply
   by meter interface (most useful when the meter is embedded in a
   router) supports hierarchical Internet reporting schemes as described
   in the 'Internet Accounting Background' RFC [<a href="#ref-ACT-BKG" title="&quot;Internet Accounting Background&quot;">ACT-BKG</a>]. That is, it
   allows backbone and regional networks to measure usage to just the
   next lower level of granularity (i.e. to the regional and
   stub/enterprise levels, respectively), with the final breakdown
   according to end user (e.g. to source IP address) performed by the
   stub/enterprise networks.




<span class="grey">Brownlee, et al.             Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   In cases where network addresses are dynamically allocated (e.g.
   dial-in subscribers), further subscriber identification will be
   necessary if flows are to ascribed to individual users.  Provision is
   made to further specify the metered traffic group through the use of
   an optional SUBSCRIBER ID as part of the flow id.  A subscriber ID
   may be associated with a particular flow either through the current
   rule set or by unspecified means within a meter.  At this time a
   subscriber ID is an arbitrary text string; later versions of the
   architecture may specify details of its contents.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>  Granularity of Flow Measurements</span>

   GRANULARITY is the 'control knob' by which an application and/or the
   meter can trade off the overhead associated with performing usage
   reporting against its level of detail.  A coarser granularity means a
   greater level of aggregation; finer granularity means a greater level
   of detail.  Thus, the number of flows measured (and stored) at a
   meter can be regulated by changing the granularity of their
   attributes.  Flows are like an adjustable pipe - many fine-
   granularity streams can carry the data with each stream measured
   individually, or data can be bundled in one coarse-granularity pipe.
   Time granularity may be controlled by varying the reporting interval,
   i.e. the time between meter readings.

   Flow granularity is controlled by adjusting the level of detail for
   the following:

     - The metered traffic group (address attributes, discussed above).

     - The categorisation of packets (other attributes, discussed
       below).

     - The lifetime/duration of flows (the reporting interval needs to
       be short enough to measure them with sufficient precision).

   The set of rules controlling the determination of each packet's
   metered traffic group is known as the meter's CURRENT RULE SET.  As
   will be shown, the meter's current rule set forms an integral part of
   the reported information, i.e. the recorded usage information cannot
   be properly interpreted without a definition of the rules used to
   collect that information.

   Settings for these granularity factors may vary from meter to meter.
   They are determined by the meter's current rule set, so they will
   change if network Operations personnel reconfigure the meter to use a
   new rule set.  It is expected that the collection rules will change
   rather infrequently; nonetheless, the rule set in effect at any time




<span class="grey">Brownlee, et al.             Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   must be identifiable via a RULE SET NUMBER. Granularity of metered
   traffic groups is further specified by additional ATTRIBUTES. These
   attributes include:

     - Attributes which record information derived from other attribute
       values.  Six of these are defined (SourceClass, DestClass,
       FlowClass, SourceKind, DestKind, FlowKind), and their meaning is
       determined by the meter's rule set.  For example, one could have
       a subroutine in the rule set which determined whether a source or
       destination peer address was a member of an arbitrary list of
       networks, and set SourceClass/DestClass to one if the source/dest
       peer address was in the list or to zero otherwise.

     - Administratively specified attributes such as Quality of Service
       and Priority, etc.  These are not defined at this time.

   Settings for these granularity factors may vary from meter to meter.
   They are determined by the meter's current rule set, so they will
   change if Network Operations personnel reconfigure the meter to use a
   new rule set.

   A rule set can aggregate groups of addresses in two ways.  The
   simplest is to use a mask in a single rule to test for an address
   within a masked group.  The other way is to use a sequence of rules
   to test for an arbitrary group of (masked) address values, then use a
   PushRuleTo rule to set a derived attribute (e.g. FlowKind) to
   indicate the flow's group.

   The LIFETIME of a flow is the time interval which began when the
   meter observed the first packet belonging to the flow and ended when
   it saw the last packet.  Flow lifetimes are very variable, but many -
   if not most - are rather short.  A meter cannot measure lifetimes
   directly; instead a meter reader collects usage data for flows which
   have been active since the last collection, and an analysis
   application may compare the data from each collection so as to
   determine when each flow actually stopped.

   The meter does, however, need to reclaim memory (i.e. records in the
   flow table) being held by idle flows.  The meter configuration
   includes a variable called InactivityTimeout, which specifies the
   minimum time a meter must wait before recovering the flow's record.
   In addition, before recovering a flow record the meter should be sure
   that the flow's data has been collected by all meter readers which
   registered to collect it.  These two wait conditions are desired
   goals for the meter; they are not difficult to achieve in normal
   usage, however the meter cannot guarantee to fulfil them absolutely.





<span class="grey">Brownlee, et al.             Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   These 'lifetime' issues are considered further in the section on
   meter readers (below).  A complete list of the attributes currently
   defined is given in <a href="#appendix-C">Appendix C</a> later in this document.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>  Rolling Counters, Timestamps, Report-in-One-Bucket-Only</span>

   Once a usage record is sent, the decision needs to be made whether to
   clear any existing flow records or to maintain them and add to their
   counts when recording subsequent traffic on the same flow.  The
   second method, called rolling counters, is recommended and has
   several advantages.  Its primary advantage is that it provides
   greater reliability - the system can now often survive the loss of
   some usage records, such as might occur if a meter reader failed and
   later restarted.  The next usage record will very often contain yet
   another reading of many of the same flow buckets which were in the
   lost usage record.  The 'continuity' of data provided by rolling
   counters can also supply information used for "sanity" checks on the
   data itself, to guard against errors in calculations.

   The use of rolling counters does introduce a new problem: how to
   distinguish a follow-on flow record from a new flow record.  Consider
   the following example.

                         CONTINUING FLOW        OLD FLOW, then NEW FLOW

                         start time = 1            start time = 1
   Usage record N:       flow count = 2000      flow count = 2000 (done)

                         start time = 1            start time = 5
   Usage record N+1:     flow count = 3000      new flow count = 1000

   Total count:                 3000                    3000

   In the continuing flow case, the same flow was reported when its
   count was 2000, and again at 3000: the total count to date is 3000.
   In the OLD/NEW case, the old flow had a count of 2000.  Its record
   was then stopped (perhaps because of temporary idleness), but then
   more traffic with the same characteristics arrived so a new flow
   record was started and it quickly reached a count of 1000.  The total
   flow count from both the old and new records is 3000.

   The flow START TIMESTAMP attribute is sufficient to resolve this. In
   the example above, the CONTINUING FLOW flow record in the second
   usage record has an old FLOW START timestamp, while the NEW FLOW
   contains a recent FLOW START timestamp.  A flow which has sporadic
   bursts of activity interspersed with long periods of inactivity will
   produce a sequence of flow activity records, each with the same set
   of address attributes, but with increasing FLOW START times.



<span class="grey">Brownlee, et al.             Informational                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   Each packet is counted in at most one flow for each running ruleset,
   so as to avoid multiple counting of a single packet.  The record of a
   single flow is informally called a "bucket."  If multiple, sometimes
   overlapping, records of usage information are required (aggregate,
   individual, etc), the network manager should collect the counts in
   sufficiently detailed granularity so that aggregate and combination
   counts can be reconstructed in post-processing of the raw usage data.
   Alternatively, multiple rulesets could be used to collect data at
   different granularities.

   For example, consider a meter from which it is required to record
   both 'total packets coming in interface #1' and 'total packets
   arriving from any interface sourced by IP address = a.b.c.d', using a
   single rule set.  Although a bucket can be declared for each case, it
   is not clear how to handle a packet which satisfies both criteria.
   It must only be counted once.  By default it will be counted in the
   first bucket for which it qualifies, and not in the other bucket.
   Further, it is not possible to reconstruct this information by post-
   processing.  The solution in this case is to define not two, but
   THREE buckets, each one collecting a unique combination of the two
   criteria:

           Bucket 1:  Packets which came in interface 1,
                      AND were sourced by IP address a.b.c.d

           Bucket 2:  Packets which came in interface 1,
                      AND were NOT sourced by IP address a.b.c.d

           Bucket 3:  Packets which did NOT come in interface 1,
                      AND were sourced by IP address a.b.c.d

          (Bucket 4:  Packets which did NOT come in interface 1,
                      AND were NOT sourced by IP address a.b.c.d)

   The desired information can now be reconstructed by post-processing.
   "Total packets coming in interface 1" can be found by adding buckets
   1 &amp; 2, and "Total packets sourced by IP address a.b.c.d" can be found
   by adding buckets 1 &amp; 3.  Note that in this case bucket 4 is not
   explicitly required since its information is not of interest, but it
   is supplied here in parentheses for completeness.

   Alternatively, the above could be achieved by running two rule sets
   (A and B), as follows:

           Bucket 1:  Packets which came in interface 1;
                      counted by rule set A.





<span class="grey">Brownlee, et al.             Informational                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


           Bucket 2:  Packets which were sourced by IP address a.b.c.d;
                      counted by rule set B.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>  Meters</span>

   A traffic flow meter is a device for collecting data about traffic
   flows at a given point within a network; we will call this the
   METERING POINT.  The header of every packet passing the network
   metering point is offered to the traffic meter program.

   A meter could be implemented in various ways, including:

     - A dedicated small host, connected to a broadcast LAN (so that it
       can see all packets as they pass by) and running a traffic meter
       program.  The metering point is the LAN segment to which the
       meter is attached.

     - A multiprocessing system with one or more network interfaces,
       with drivers enabling a traffic meter program to see packets.  In
       this case the system provides multiple metering points - traffic
       flows on any subset of its network interfaces can be measured.

     - A packet-forwarding device such as a router or switch.  This is
       similar to (b) except that every received packet should also be
       forwarded, usually on a different interface.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>  Meter Structure</span>

   An outline of the meter's structure is given in the following
   diagram:

   Briefly, the meter works as follows:

     - Incoming packet headers arrive at the top left of the diagram and
       are passed to the PACKET PROCESSOR.

     - The packet processor passes them to the Packet Matching Engine
       (PME) where they are classified.

     - The PME is a Virtual Machine running a pattern matching program
       contained in the CURRENT RULE SET.  It is invoked by the Packet
       Processor, executes the rules in the current rule set as
       described in <a href="#section-4.3">section 4.3</a> below, and returns instructions on what
       to do with the packet.

     - Some packets are classified as 'to be ignored'.  They are
       discarded by the Packet Processor.




<span class="grey">Brownlee, et al.             Informational                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


     - Other packets are matched by the PME, which returns a FLOW KEY
       describing the flow to which the packet belongs.

     - The flow key is used to locate the flow's entry in the FLOW
       TABLE; a new entry is created when a flow is first seen.  The
       entry's data fields (e.g. packet and byte counters) are updated.

     - A meter reader may collect data from the flow table at any time.
       It may use the 'collect' index to locate the flows to be
       collected within the flow table.


                   packet                     +------------------+
                   header                     | Current Rule Set |
                     |                        +--------+---------+
                     |                                 |
                     |                                 |
             +-------*--------+    'match key'  +------*-------+
             |    Packet      |----------------&gt;|    Packet    |
             |   Processor    |                 |   Matching   |
             |                |&lt;----------------|    Engine    |
             +--+----------+--+  'flow key'     +--------------+
                |          |
                |          |
         Ignore *          | Count (via 'flow key')
                           |
                        +--*--------------+
                        | 'Search' index  |
                        +--------+--------+
                                 |
                        +--------*--------+
                        |                 |
                        |   Flow Table    |
                        |                 |
                        +--------+--------+
                                 |
                        +--------*--------+
                        | 'Collect' index |
                        +--------+--------+
                                 |
                                 *
                            Meter Reader

   The discussion above assumes that a meter will only be running a
   single rule set.  A meter may, however, run several rule sets
   concurrently.  To do this the meter maintains a table of current
   rulesets.  The packet processor matches each packet against every




<span class="grey">Brownlee, et al.             Informational                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   current ruleset, producing a single flow table containing flows from
   all the rule sets.  One way to implement this is to use the Rule Set
   Number attribute in each flow as part of the flow key.

   A packet may only be counted once in a rule set (as explained in
   <a href="#section-3.3">section 3.3</a> above), but it may be counted in any of the current
   rulesets.  The overall effect of doing this is somewhat similar to
   running several independent meters, one for each rule set.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>  Flow Table</span>

   Every traffic meter maintains 'flow table', i.e. a table of TRAFFIC
   FLOW RECORDS for flows seen by the meter.  Details of how the flow
   table is maintained are given in <a href="#section-4.5">section 4.5</a> below.  A flow record
   contains attribute values for its flow, including:

     - Addresses for the flow's source and destination.  These include
       addresses and masks for various network layers (extracted from
       the packet header), and the identity of the interface on which
       the packet was observed.

     - First and last times when packets were seen for this flow.

     - Counts for 'forward' (source to destination) and 'backward'
       (destination to source) components of the flow's traffic.

     - Other attributes, e.g. state of the flow record (discussed
       below).

   The state of a flow record may be:

     - INACTIVE: The flow record is not being used by the meter.

     - CURRENT: The record is in use and describes a flow which belongs
       to the 'current flow set', i.e. the set of flows recently seen by
       the meter.

     - IDLE: The record is in use and the flow which it describes is
       part of the current flow set.  In addition, no packets belonging
       to this flow have been seen for a period specified by the meter's
       InactivityTime variable.










<span class="grey">Brownlee, et al.             Informational                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>  Packet Handling, Packet Matching</span>

   Each packet header received by the traffic meter program is processed
   as follows:

     - Extract attribute values from the packet header and use them to
       create a MATCH KEY for the packet.

     - Match the packet's key against the current rule set, as explained
       in detail below.

   The rule set specifies whether the packet is to be counted or
   ignored.  If it is to be counted the matching process produces a FLOW
   KEY for the flow to which the packet belongs.  This flow key is used
   to find the flow's record in the flow table; if a record does not yet
   exist for this flow, a new flow record may be created.  The data for
   the matching flow record can then be updated.

   For example, the rule set could specify that packets to or from any
   host in IP network 130.216 are to be counted.  It could also specify
   that flow records are to be created for every pair of 24-bit (Class
   C) subnets within network 130.216.

   Each packet's match key is passed to the meter's PATTERN MATCHING
   ENGINE (PME) for matching.  The PME is a Virtual Machine which uses a
   set of instructions called RULES, i.e. a RULE SET is a program for
   the PME. A packet's match key contains source (S) and destination (D)
   interface identities, address values and masks.

   If measured flows were unidirectional, i.e. only counted packets
   travelling in one direction, the matching process would be simple.
   The PME would be called once to match the packet.  Any flow key
   produced by a successful match would be used to find the flow's
   record in the flow table, and that flow's counters would be updated.

   Flows are, however, bidirectional, reflecting the forward and reverse
   packets of a protocol interchange or 'session'.  Maintaining two sets
   of counters in the meter's flow record makes the resulting flow data
   much simpler to handle, since analysis programs do not have to gather
   together the 'forward' and 'reverse' components of sessions.
   Implementing bi-directional flows is, of course, more difficult for
   the meter, since it must decide whether a packet is a 'forward'
   packet or a 'reverse' one.  To make this decision the meter will
   often need to invoke the PME twice, once for each possible packet
   direction.






<span class="grey">Brownlee, et al.             Informational                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   The diagram below describes the algorithm used by the traffic meter
   to process each packet.  Flow through the diagram is from left to
   right and top to bottom, i.e. from the top left corner to the bottom
   right corner.  S indicates the flow's source address (i.e. its set of
   source address attribute values) from the packet header, and D
   indicates its destination address.

   There are several cases to consider.  These are:

     - The packet is recognised as one which is TO BE IGNORED.

     - The packet would MATCH IN EITHER DIRECTION.  One situation in
       which this could happen would be a rule set which matches flows
       within network X (Source = X, Dest = X) but specifies that flows
       are to be created for each subnet within network X, say subnets y
       and z.  If, for example a packet is seen for y-&gt;z, the meter must
       check that flow z-&gt;y is not already current before creating y-&gt;z.

     - The packet MATCHES IN ONE DIRECTION ONLY.  If its flow is already
       current, its forward or reverse counters are incremented.
       Otherwise it is added to the flow table and then counted.

                   Ignore
   --- match(S-&gt;D) -------------------------------------------------+
        | Suc   | NoMatch                                           |
        |       |          Ignore                                   |
        |      match(D-&gt;S) -----------------------------------------+
        |       | Suc   | NoMatch                                   |
        |       |       |                                           |
        |       |       +-------------------------------------------+
        |       |                                                   |
        |       |             Suc                                   |
        |      current(D-&gt;S) ---------- count(D-&gt;S,r) --------------+
        |       | Fail                                              |
        |       |                                                   |
        |      create(D-&gt;S) ----------- count(D-&gt;S,r) --------------+
        |                                                           |
        |             Suc                                           |
       current(S-&gt;D) ------------------ count(S-&gt;D,f) --------------+
        | Fail                                                      |
        |             Suc                                           |
       current(D-&gt;S) ------------------ count(D-&gt;S,r) --------------+
        | Fail                                                      |
        |                                                           |
       create(S-&gt;D) ------------------- count(S-&gt;D,f) --------------+
                                                                    |
                                                                    *




<span class="grey">Brownlee, et al.             Informational                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   The algorithm uses four functions, as follows:

   match(A-&gt;B) implements the PME.  It uses the meter's current rule set
      to match the attribute values in the packet's match key.  A-&gt;B
      means that the assumed source address is A and destination address
      B, i.e. that the packet was travelling from A to B.  match()
      returns one of three results:

   'Ignore' means that the packet was matched but this flow is not to be
           counted.

   'NoMatch' means that the packet did not match.  It might, however
           match with its direction reversed, i.e. from B to A.

   'Suc' means that the packet did match, i.e. it belongs to a flow
           which is to be counted.

   current(A-&gt;B) succeeds if the flow A-to-B is current - i.e. has a
      record in the flow table whose state is Current - and fails
      otherwise.

   create(A-&gt;B) adds the flow A-to-B to the flow table, setting the
      value for attributes - such as addresses - which remain constant,
      and zeroing the flow's counters.

   count(A-&gt;B,f) increments the 'forward' counters for flow A-to-B.
   count(A-&gt;B,r) increments the 'reverse' counters for flow A-to-B.
      'Forward' here means the counters for packets travelling from A to
      B.  Note that count(A-&gt;B,f) is identical to count(B-&gt;A,r).

   When writing rule sets one must remember that the meter will normally
   try to match each packet in the reverse direction if the forward
   match does not succeed.  It is particularly important that the rule
   set does not contain inconsistencies which will upset this process.

   Consider, for example, a rule set which counts packets from source
   network A to destination network B, but which ignores packets from
   source network B.  This is an obvious example of an inconsistent rule
   set, since packets from network B should be counted as reverse
   packets for the A-to-B flow.

   This problem could be avoided by devising a language for specifying
   rule files and writing a compiler for it, thus making it much easier
   to produce correct rule sets.  An example of such a language is
   described in the 'SRL' document [<a href="#ref-RTFM-SRL" title="&quot;SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups&quot;">RTFM-SRL</a>]. Another approach would be
   to write a 'rule set consistency checker' program, which could detect
   problems in hand-written rule sets.




<span class="grey">Brownlee, et al.             Informational                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   Normally, the best way to avoid these problems is to write rule sets
   which only classify flows in the forward direction, and rely on the
   meter to handle reverse-travelling packets.

   Occasionally there can be situations when a rule set needs to know
   the direction in which a packet is being matched.  Consider, for
   example, a rule set which wants to save some attribute values (source
   and destination addresses perhaps) for any 'unusual' packets.  The
   rule set will contain a sequence of tests for all the 'usual' source
   addresses, follwed by a rule which will execute a 'NoMatch' action.
   If the match fails in the S-&gt;D direction, the NoMatch action will
   cause it to be retried.  If it fails in the D-&gt;S direction, the
   packet can be counted as an 'unusual' packet.

   To count such an 'unusual' packet we need to know the matching
   direction: the MatchingStoD attribute provides this.  To use it, one
   follows the source address tests with a rule which tests whether the
   matching direction is S-&gt;D (MatchingStoD value is 1).  If so, a
   'NoMatch' action is executed.  Otherwise, the packet has failed to
   match in both directions; we can save whatever attribute values are
   of interest and count the 'unusual' packet.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>  Rules and Rule Sets</span>

   A rule set is an array of rules.  Rule sets are held within a meter
   as entries in an array of rule sets.

   Rule set 1 (the first entry in the rule set table) is built-in to the
   meter and cannot be changed.  It is run when the meter is started up,
   and provides a very coarse reporting granularity; it is mainly useful
   for verifying that the meter is running, before a 'useful' rule set
   is downloaded to it.

   A meter also maintains an array of 'tasks', which specify what rule
   sets the meter is running.  Each task has a 'current' rule set (the
   one which it normally uses), and a 'standby' rule set (which will be
   used when the overall traffic level is unusually high).  If a task is
   instructed to use rule set 0, it will cease measuring; all packets
   will be ignored until another (non-zero) rule set is made current.

   Each rule in a rule set is an instruction for the Packet Matching
   Engine, i.e. it is an instruction for a Virtual Machine.  PME
   instructions have five component fields, forming two logical groups
   as follows:

      +-------- test ---------+    +---- action -----+
      attribute &amp; mask = value:    opcode,  parameter;




<span class="grey">Brownlee, et al.             Informational                     [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   The test group allows PME to test the value of an attribute.  This is
   done by ANDing the attribute value with the mask and comparing the
   result with the value field.  Note that there is no explicit
   provision to test a range, although this can be done where the range
   can be covered by a mask, e.g. attribute value less than 2048.

   The PME maintains a Boolean indicator called the 'test indicator',
   which determines whether or not a rule's test is performed.  The test
   indicator is initially set (true).

   The action group specifies what action may be performed when the rule
   is executed.  Opcodes contain two flags: 'goto' and 'test', as
   detailed in the table below.  Execution begins with rule 1, the first
   in the rule set.  It proceeds as follows:

      If the test indicator is true:
         Perform the test, i.e. AND the attribute value with the
            mask and compare it with the value.
         If these are equal the test has succeeded; perform the
            rule's action (below).
         If the test fails execute the next rule in the rule set.
         If there are no more rules in the rule set, return from the
            match() function indicating NoMatch.

      If the test indicator is false, or the test (above) succeeded:
         Set the test indicator to this opcode's test flag value.
         Determine the next rule to execute.
            If the opcode has its goto flag set, its parameter value
               specifies the number of the next rule.
            Opcodes which don't have their goto flags set either
               determine the next rule in special ways (Return),
               or they terminate execution (Ignore, NoMatch, Count,
               CountPkt).
         Perform the action.

   The PME maintains two 'history' data structures.  The first, the
   'return' stack, simply records the index (i.e. 1-origin rule number)
   of each Gosub rule as it is executed; Return rules pop their Gosub
   rule index.  Note that when the Ignore, NoMatch, Count and CountPkt
   actions are performed, PME execution is terminated regardless of
   whether the PME is executing a subroutine ('return' stack is non-
   empty) or not.

   The second data structure, the 'pattern' queue, is used to save
   information for later use in building a flow key.  A flow key is
   built by zeroing all its attribute values, then copying attribute
   number, mask and value information from the pattern queue in the
   order it was enqueued.



<span class="grey">Brownlee, et al.             Informational                     [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   An attribute number identifies the attribute actually used in a test.
   It will usually be the rule's attribute field, unless the attribute
   is a 'meter variable'.  Details of meter variables are given after
   the table of opcode actions below.

   The opcodes are:

            opcode         goto    test

         1  Ignore           0       -
         2  NoMatch          0       -
         3  Count            0       -
         4  CountPkt         0       -
         5  Return           0       0
         6  Gosub            1       1
         7  GosubAct         1       0
         8  Assign           1       1
         9  AssignAct        1       0
        10  Goto             1       1
        11  GotoAct          1       0
        12  PushRuleTo       1       1
        13  PushRuleToAct    1       0
        14  PushPktTo        1       1
        15  PushPktToAct     1       0
        16  PopTo            1       1
        17  PopToAct         1       0

   The actions they perform are:

   Ignore:         Stop matching, return from the match() function
                   indicating that the packet is to be ignored.

   NoMatch:        Stop matching, return from the match() function
                   indicating failure.

   Count:          Stop matching.  Save this rule's attribute number,
                   mask and value in the PME's pattern queue, then
                   construct a flow key for the flow to which this
                   packet belongs.  Return from the match() function
                   indicating success.  The meter will use the flow
                   key to search for the flow record for this
                   packet's flow.

   CountPkt:       As for Count, except that the masked value from
                   the packet header (as it would have been used in
                   the rule's test) is saved in the PME's pattern
                   queue instead of the rule's value.




<span class="grey">Brownlee, et al.             Informational                     [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   Gosub:          Call a rule-matching subroutine.  Push the current
                   rule number on the PME's return stack, set the
                   test indicator then goto the specified rule.

   GosubAct:       Same as Gosub, except that the test indicator is
                   cleared before going to the specified rule.

   Return:         Return from a rule-matching subroutine.  Pop the
                   number of the calling gosub rule from the PME's
                   'return' stack and add this rule's parameter value
                   to it to determine the 'target' rule.  Clear the
                   test indicator then goto the target rule.

                   A subroutine call appears in a rule set as a Gosub
                   rule followed by a small group of following rules.
                   Since a Return action clears the test flag, the
                   action of one of these 'following' rules will be
                   executed; this allows the subroutine to return a
                   result (in addition to any information it may save
                   in the PME's pattern queue).

   Assign:         Set the attribute specified in this rule to the
                   parameter value specified for this rule.  Set the
                   test indicator then goto the specified rule.

   AssignAct:      Same as Assign, except that the test indicator
                   is cleared before going to the specified rule.

   Goto:           Set the test indicator then goto the
                   specified rule.

   GotoAct:        Clear the test indicator then goto the specified
                   rule.

   PushRuleTo:     Save this rule's attribute number, mask and value
                   in the PME's pattern queue. Set the test
                   indicator then goto the specified rule.

   PushRuleToAct:  Same as PushRuleTo, except that the test indicator
                   is cleared before going to the specified rule.

                   PushRuleTo actions may be used to save the value
                   and mask used in a test, or (if the test is not
                   performed) to save an arbitrary value and mask.







<span class="grey">Brownlee, et al.             Informational                     [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   PushPktTo:      Save this rule's attribute number, mask, and the
                   masked value from the packet header (as it would
                   have been used in the rule's test), in the PME's
                   pattern queue.  Set the test indicator then goto
                   the specified rule.

   PushPktToAct:   Same as PushPktTo, except that the test indicator
                   is cleared before going to the specified rule.

                   PushPktTo actions may be used to save a value from
                   the packet header using a specified mask.  The
                   simplest way to program this is to use a zero value
                   for the PushPktTo rule's value field, and to
                   GoToAct to the PushPktTo rule (so that it's test is
                   not executed).

   PopTo:          Delete the most recent item from the pattern
                   queue, so as to remove the information saved by
                   an earlier 'push' action.  Set the test indicator
                   then goto the specified rule.

   PopToAct:       Same as PopTo, except that the test indicator
                   is cleared before going to the specified rule.

   As well as the attributes applying directly to packets (such as
   SourcePeerAddress, DestTransAddress, etc.)  the PME implements
   several further attribtes.  These are:

      Null:           Tests performed on the Null attribute always
                      succeed.

      MatchingStoD:   Indicates whether the PME is matching the packet
                      with its addresses in 'wire order' or with its
                      addresses reversed.  MatchingStoD's value is 1 if
                      the addresses are in wire order (StoD), and zero
                      otherwise.

      v1 .. v5:       v1, v2, v3, v4 and v5 are 'meter variables'.  They
                      provide a way to pass parameters into rule-
                      matching subroutines.  Each may hold the number of
                      a normal attribute; its value is set by an Assign
                      action.  When a meter variable appears as the
                      attribute of a rule, its value specifies the
                      actual attribute to be tested. For example, if v1
                      had been assigned SourcePeerAddress as its value,
                      a rule with v1 as its attribute would actually
                      test SourcePeerAddress.




<span class="grey">Brownlee, et al.             Informational                     [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


      SourceClass, DestClass, FlowClass,
      SourceKind, DestKind, FlowKind:
                      These six attributes may be set by executing
                      PushRuleTo actions.  They allow the PME to save
                      (in flow records) information which has been built
                      up during matching.  Their values may be tested in
                      rules; this allows one to set them early in a rule
                      set, and test them later.

   The opcodes detailed above (with their above 'goto' and 'test'
   values) form a minimum set, but one which has proved very effective
   in current meter implementations.  From time to time it may be useful
   to add further opcodes; IANA considerations for allocating these are
   set out in <a href="#section-8">section 8</a> below.

<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>  Maintaining the Flow Table</span>

   The flow table may be thought of as a 1-origin array of flow records.
   (A particular implementation may, of course, use whatever data
   structure is most suitable).  When the meter starts up there are no
   known flows; all the flow records are in the 'inactive' state.

   Each time a packet is matched for a flow which is not in a current
   flow set a flow record is created for it; the state of such a record
   is
   'current'.  When selecting a record for the new flow the meter
   searches the flow table for an 'inactive' record.  If no inactive
   records are available it will search for an 'idle' one instead.  Note
   that there is no particular significance in the ordering of records
   within the flow table.

   A meter's memory management routines should aim to minimise the time
   spent finding flow records for new flows, so as to minimise the setup
   overhead associated with each new flow.

   Flow data may be collected by a 'meter reader' at any time.  There is
   no requirement for collections to be synchronized.  The reader may
   collect the data in any suitable manner, for example it could upload
   a copy of the whole flow table using a file transfer protocol, or it
   could read the records in the current flow set row by row using a
   suitable data transfer protocol.

   The meter keeps information about collections, in particular it
   maintains ReaderLastTime variables which remember the time the last
   collection was made by each reader.  A second variable,
   InactivityTime, specifies the minimum time the meter will wait before
   considering that a flow is idle.




<span class="grey">Brownlee, et al.             Informational                     [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   The meter must recover records used for idle flows, if only to
   prevent it running out of flow records.  Recovered flow records are
   returned to the 'inactive' state.  A variety of recovery strategies
   are possible, including the following:

   One possible recovery strategy is to recover idle flow records as
   soon as possible after their data has been collected by all readers
   which have registered to do so.  To implement this the meter could
   run a background process which scans the flow table looking for '
   current' flows whose 'last packet' time is earlier than the meter's
   LastCollectTime.

   Another recovery strategy is to leave idle flows alone as long as
   possible, which would be acceptable if one was only interested in
   measuring total traffic volumes.  It could be implemented by having
   the meter search for collected idle flows only when it ran low on '
   inactive' flow records.

   One further factor a meter should consider before recovering a flow
   is the number of meter readers which have collected the flow's data.
   If there are multiple meter readers operating, each reader should
   collect a flow's data before its memory is recovered.

   Of course a meter reader may fail, so the meter cannot wait forever
   for it.  Instead the meter must keep a table of active meter readers,
   with a timeout specified for each.  If a meter reader fails to
   collect flow data within its timeout interval, the meter should
   delete that reader from the meter's active meter reader table.

<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>  Handling Increasing Traffic Levels</span>

   Under normal conditions the meter reader specifies which set of usage
   records it wants to collect, and the meter provides them.  If,
   however, memory usage rises above the high-water mark the meter
   should switch to a STANDBY RULE SET so as to decrease the rate at
   which new flows are created.

   When the manager, usually as part of a regular poll, becomes aware
   that the meter is using its standby rule set, it could decrease the
   interval between collections.  This would shorten the time that flows
   sit in memory waiting to be collected, allowing the meter to free
   flow memory faster.

   The meter could also increase its efforts to recover flow memory so
   as to reduce the number of idle flows in memory.  When the situation
   returns to normal, the manager may request the meter to switch back
   to its normal rule set.




<span class="grey">Brownlee, et al.             Informational                     [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>  Meter Readers</span>

   Usage data is accumulated by a meter (e.g. in a router) as memory
   permits.  It is collected at regular reporting intervals by meter
   readers, as specified by a manager.  The collected data is recorded
   in stable storage as a FLOW DATA FILE, as a sequence of USAGE
   RECORDS.

   The following sections describe the contents of usage records and
   flow data files.  Note, however, that at this stage the details of
   such records and files is not specified in the architecture.
   Specifying a common format for them would be a worthwhile future
   development.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>  Identifying Flows in Flow Records</span>

   Once a packet has been classified and is ready to be counted, an
   appropriate flow data record must already exist in the flow table;
   otherwise one must be created.  The flow record has a flexible format
   where unnecessary identification attributes may be omitted.  The
   determination of which attributes of the flow record to use, and of
   what values to put in them, is specified by the current rule set.

   Note that the combination of start time, rule set number and flow
   subscript (row number in the flow table) provide a unique flow
   identifier, regardless of the values of its other attributes.

   The current rule set may specify additional information, e.g. a
   computed attribute value such as FlowKind, which is to be placed in
   the attribute section of the usage record.  That is, if a particular
   flow is matched by the rule set, then the corresponding flow record
   should be marked not only with the qualifying identification
   attributes, but also with the additional information.  Using this
   feature, several flows may each carry the same FlowKind value, so
   that the resulting usage records can be used in post-processing or
   between meter reader and meter as a criterion for collection.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>  Usage Records, Flow Data Files</span>

   The collected usage data will be stored in flow data files on the
   meter reader, one file for each meter.  As well as containing the
   measured usage data, flow data files must contain information
   uniquely identifiying the meter from which it was collected.








<span class="grey">Brownlee, et al.             Informational                     [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   A USAGE RECORD contains the descriptions of and values for one or
   more flows.  Quantities are counted in terms of number of packets and
   number of bytes per flow.  Other quantities, e.g. short-term flow
   rates, may be added later; work on such extensions is described in
   the RTFM 'New Attributes' document [<a href="#ref-RTFM-NEW" title="&quot;RTFM: New Attributes for Traffic Flow Measurment&quot;">RTFM-NEW</a>].

   Each usage record contains the metered traffic group identifier of
   the meter (a set of network addresses), a time stamp and a list of
   reported flows (FLOW DATA RECORDS). A meter reader will build up a
   file of usage records by regularly collecting flow data from a meter,
   using this data to build usage records and concatenating them to the
   tail of a file.  Such a file is called a FLOW DATA FILE.

   A usage record contains the following information in some form:

   +-------------------------------------------------------------------+
   |    RECORD IDENTIFIERS:                                            |
   |      Meter Id (&amp; digital signature if required)                   |
   |      Timestamp                                                    |
   |      Collection Rules ID                                          |
   +-------------------------------------------------------------------+
   |    FLOW IDENTIFIERS:            |    COUNTERS                     |
   |      Address List               |       Packet Count              |
   |      Subscriber ID (Optional)   |       Byte Count                |
   |      Attributes (Optional)      |    Flow Start/Stop Time         |
   +-------------------------------------------------------------------+

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>  Meter to Meter Reader:  </span>Usage Record Transmission

   The usage record contents are the raison d'etre of the system.  The
   accuracy, reliability, and security of transmission are the primary
   concerns of the meter/meter reader exchange.  Since errors may occur
   on networks, and Internet packets may be dropped, some mechanism for
   ensuring that the usage information is transmitted intact is needed.

   Flow data is moved from meter to meter reader via a series of
   protocol exchanges between them.  This may be carried out in various
   ways, moving individual attribute values, complete flows, or the
   entire flow table (i.e. all the active and idle flows).  One possible
   method of achieving this transfer is to use SNMP; the 'Traffic Flow
   Measurement:  Meter MIB' RFC [<a href="#ref-RTFM-MIB" title="&quot;Traffic Flow Measurement: Meter MIB&quot;">RTFM-MIB</a>] gives details.  Note that
   this is simply one example; the transfer of flow data from meter to
   meter reader is not specified in this document.

   The reliability of the data transfer method under light, normal, and
   extreme network loads should be understood before selecting among
   collection methods.




<span class="grey">Brownlee, et al.             Informational                     [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   In normal operation the meter will be running a rule file which
   provides the required degree of flow reporting granularity, and the
   meter reader(s) will collect the flow data often enough to allow the
   meter's garbage collection mechanism to maintain a stable level of
   memory usage.

   In the worst case traffic may increase to the point where the meter
   is in danger of running completely out of flow memory.  The meter
   implementor must decide how to handle this, for example by switching
   to a default (extremely coarse granularity) rule set, by sending a
   trap message to the manager, or by attempting to dump flow data to
   the meter reader.

   Users of the Traffic Flow Measurement system should analyse their
   requirements carefully and assess for themselves whether it is more
   important to attempt to collect flow data at normal granularity
   (increasing the collection frequency as needed to keep up with
   traffic volumes), or to accept flow data with a coarser granularity.
   Similarly, it may be acceptable to lose flow data for a short time in
   return for being sure that the meter keeps running properly, i.e. is
   not overwhelmed by rising traffic levels.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>   Managers</span>

   A manager configures meters and controls meter readers.  It does this
   via the interactions described below.

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>  Between Manager and Meter:  </span>Control Functions

     - DOWNLOAD RULE SET: A meter may hold an array of rule sets.  One
       of these, the 'default' rule set, is built in to the meter and
       cannot be changed; this is a diagnostic feature, ensuring that
       when a meter starts up it will be running a known ruleset.

       All other rule sets must be downloaded by the manager.  A manager
       may use any suitable protocol exchange to achieve this, for
       example an FTP file transfer or a series of SNMP SETs, one for
       each row of the rule set.

     - SPECIFY METER TASK: Once the rule sets have been downloaded, the
       manager must instruct the meter which rule sets will be the
       'current' and 'standby' ones for each task the meter is to
       perform.

     - SET HIGH WATER MARK: A percentage of the flow table capacity,
       used by the meter to determine when to switch to its standby rule
       set (so as to increase the granularity of the flows and conserve
       the meter's flow memory).  Once this has happened, the manager



<span class="grey">Brownlee, et al.             Informational                     [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


       may also change the polling frequency or the meter's control
       parameters (so as to increase the rate at which the meter can
       recover memory from idle flows).  The meter has a separate high
       water mark value for each task it is currently running.

       If the high traffic levels persist, the meter's normal rule set
       may have to be rewritten to permanently reduce the reporting
       granularity.

     - SET FLOW TERMINATION PARAMETERS: The meter should have the good
       sense in situations where lack of resources may cause data loss
       to purge flow records from its tables.  Such records may include:

        - Flows that have already been reported to all registered meter
          readers, and show no activity since the last report,
        - Oldest flows, or
        - Flows with the smallest number of observed packets.

     - SET INACTIVITY TIMEOUT: This is a time in seconds since the last
       packet was seen for a flow.  Flow records may be reclaimed if
       they have been idle for at least this amount of time, and have
       been collected in accordance with the current collection
       criteria.

   It might be useful if a manager could set the FLOW TERMINATION
   PARAMETERS to different values for different tasks.  Current meter
   implementations have only single ('whole meter') values for these
   parameters, and experience to date suggests that this provides an
   adequate degree of control for the tasks.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>  Between Manager and Meter Reader:  </span>Control Functions

   Because there are a number of parameters that must be set for traffic
   flow measurement to function properly, and viable settings may change
   as a result of network traffic characteristics, it is desirable to
   have dynamic network management as opposed to static meter
   configurations.  Many of these operations have to do with space
   tradeoffs - if memory at the meter is exhausted, either the
   collection interval must be decreased or a coarser granularity of
   aggregation must be used to reduce the number of active flows.

   Increasing the collection interval effectively stores data in the
   meter; usage data in transit is limited by the effective bandwidth of
   the virtual link between the meter and the meter reader, and since
   these limited network resources are usually also used to carry user
   data (the purpose of the network), the level of traffic flow
   measurement traffic should be kept to an affordable fraction of the
   bandwidth.  ("Affordable" is a policy decision made by the Network



<span class="grey">Brownlee, et al.             Informational                     [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   Operations personnel).  At any rate, it must be understood that the
   operations below do not represent the setting of independent
   variables; on the contrary, each of the values set has a direct and
   measurable effect on the behaviour of the other variables.

   Network management operations follow:

     - MANAGER and METER READER IDENTIFICATION: The manager should
       ensure that meters are read by the correct set of meter readers,
       and take steps to prevent unauthorised access to usage
       information.  The meter readers so identified should be prepared
       to poll if necessary and accept data from the appropriate meters.
       Alternate meter readers may be identified in case both the
       primary manager and the primary meter reader are unavailable.
       Similarly, alternate managers may be identified.

     - REPORTING INTERVAL CONTROL: The usual reporting interval should
       be selected to cope with normal traffic patterns.  However, it
       may be possible for a meter to exhaust its memory during traffic
       spikes even with a correctly set reporting interval.  Some
       mechanism should be available for the meter to tell the manager
       that it is in danger of exhausting its memory (by declaring a '
       high water' condition), and for the manager to arbitrate (by
       decreasing the polling interval, letting nature take its course,
       or by telling the meter to ask for help sooner next time).

     - GRANULARITY CONTROL: Granularity control is a catch-all for all
       the parameters that can be tuned and traded to optimise the
       system's ability to reliably measure and store information on all
       the traffic (or as close to all the traffic as an administration
       requires).  Granularity:

          - Controls the amount of address information identifying each
            flow, and
          - Determines the number of buckets into which user traffic
            will be lumped together.

       Since granularity is controlled by the meter's current rule set,
       the manager can only change it by requesting the meter to switch
       to a different rule set.  The new rule set could be downloaded
       when required, or it could have been downloaded as part of the
       meter's initial configuration.









<span class="grey">Brownlee, et al.             Informational                     [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


     - FLOW LIFETIME CONTROL: Flow termination parameters include
       timeout parameters for obsoleting inactive flows and removing
       them from tables, and maximum flow lifetimes.  This is
       intertwined with reporting interval and granularity, and must be
       set in accordance with the other parameters.

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>  Exception Conditions</span>

   Exception conditions must be handled, particularly occasions when the
   meter runs out of space for flow data.  Since - to prevent an active
   task from counting any packet twice - packets can only be counted in
   a single flow, discarding records will result in the loss of
   information.  The mechanisms to deal with this are as follows:

     - METER OUTAGES: In case of impending meter outages (controlled
       restarts, etc.) the meter could send a trap to the manager.  The
       manager could then request one or more meter readers to pick up
       the data from the meter.

       Following an uncontrolled meter outage such as a power failure,
       the meter could send a trap to the manager indicating that it has
       restarted.  The manager could then download the meter's correct
       rule set and advise the meter reader(s) that the meter is running
       again.  Alternatively, the meter reader may discover from its
       regular poll that a meter has failed and restarted.  It could
       then advise the manager of this, instead of relying on a trap
       from the meter.

     - METER READER OUTAGES: If the collection system is down or
       isolated, the meter should try to inform the manager of its
       failure to communicate with the collection system.  Usage data is
       maintained in the flows' rolling counters, and can be recovered
       when the meter reader is restarted.

     - MANAGER OUTAGES: If the manager fails for any reason, the meter
       should continue measuring and the meter reader(s) should keep
       gathering usage records.

     - BUFFER PROBLEMS: The network manager may realise that there is a
       'low memory' condition in the meter.  This can usually be
       attributed to the interaction between the following controls:

        - The reporting interval is too infrequent, or
        - The reporting granularity is too fine.







<span class="grey">Brownlee, et al.             Informational                     [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


       Either of these may be exacerbated by low throughput or bandwidth
       of circuits carrying the usage data.  The manager may change any
       of these parameters in response to the meter (or meter reader's)
       plea for help.

<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>  Standard Rule Sets</span>

   Although the rule table is a flexible tool, it can also become very
   complex.  It may be helpful to develop some rule sets for common
   applications:

     - PROTOCOL TYPE: The meter records packets by protocol type.  This
       will be the default rule table for Traffic Flow Meters.

     - ADJACENT SYSTEMS: The meter records packets by the MAC address of
       the Adjacent Systems (neighbouring originator or next-hop).
       (Variants on this table are "report source" or "report sink"
       only.)  This strategy might be used by a regional or backbone
       network which wants to know how much aggregate traffic flows to
       or from its subscriber networks.

     - END SYSTEMS: The meter records packets by the IP address pair
       contained in the packet.  (Variants on this table are "report
       source" or "report sink" only.)  This strategy might be used by
       an End System network to get detailed host traffic matrix usage
       data.

     - TRANSPORT TYPE: The meter records packets by transport address;
       for IP packets this provides usage information for the various IP
       services.

     - HYBRID SYSTEMS: Combinations of the above, e.g. for one interface
       report End Systems, for another interface report Adjacent
       Systems.  This strategy might be used by an enterprise network to
       learn detail about local usage and use an aggregate count for the
       shared regional network.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>  Security Considerations</span>

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>  Threat Analysis</span>

   A traffic flow measurement system may be subject to the following
       kinds of attacks:

     - ATTEMPTS TO DISABLE A TRAFFIC METER: An attacker may attempt to
       disrupt traffic measurement so as to prevent users being charged
       for network usage.  For example, a network probe sending packets




<span class="grey">Brownlee, et al.             Informational                     [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


       to a large number of destination and transport addresses could
       produce a sudden rise in the number of flows in a meter's flow
       table, thus forcing it to use its coarser standby rule set.

     - UNAUTHORIZED USE OF SYSTEM RESOURCES: An attacker may wish to
       gain advantage or cause mischief (e.g. denial of service) by
       subverting any of the system elements - meters, meter readers or
       managers.

     - UNAUTHORIZED DISCLOSURE OF DATA: Any data that is sensitive to
       disclosure can be read through active or passive attacks unless
       it is suitably protected.  Usage data may or may not be of this
       type.  Control messages, traps, etc. are not likely to be
       considered sensitive to disclosure.

     - UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA:
       Similarly, any data whose integrity is sensitive can be altered,
       replaced/injected or deleted through active or passive attacks
       unless it is suitably protected.  Attackers may modify message
       streams to falsify usage data or interfere with the proper
       operation of the traffic flow measurement system.  Therefore, all
       messages, both those containing usage data and those containing
       control data, should be considered vulnerable to such attacks.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>  Countermeasures</span>

   The following countermeasures are recommended to address the possible
   threats enumerated above:

     - ATTEMPTS TO DISABLE A TRAFFIC METER can't be completely
       countered.  In practice, flow data records from network security
       attacks have proved very useful in determining what happened.
       The most effective approach is first to configure the meter so
       that it has three or more times as much flow memory as it needs
       in normal operation, and second to collect the flow data fairly
       frequently so as to minimise the time needed to recover flow
       memory after such an attack.

     - UNAUTHORIZED USE OF SYSTEM RESOURCES is countered through the use
       of authentication and access control services.

     - UNAUTHORIZED DISCLOSURE OF DATA is countered through the use of a
       confidentiality (encryption) service.

     - UNAUTHORIZED ALTERATION, REPLACEMENT OR DESTRUCTION OF DATA is
       countered through the use of an integrity service.





<span class="grey">Brownlee, et al.             Informational                     [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   A Traffic Measurement system must address all of these concerns.
   Since a high degree of protection is required, the use of strong
   cryptographic methodologies is recommended.  The security
   requirements for communication between pairs of traffic measurmement
   system elements are summarized in the table below.  It is assumed
   that meters do not communicate with other meters, and that meter
   readers do not communicate directly with other meter readers (if
   synchronization is required, it is handled by the manager, see
   <a href="#section-2.5">Section 2.5</a>).  Each entry in the table indicates which kinds of
   security services are required.  Basically, the requirements are as
   follows:

           Security Service Requirements for RTFM elements

  +------------------------------------------------------------------+
  | from\to |    meter     | meter reader | application |  manager   |
  |---------+--------------+--------------+-------------+------------|
  | meter   |     N/A      |  authent     |     N/A     |  authent   |
  |         |              |  acc ctrl    |             |  acc ctrl  |
  |         |              |  integrity   |             |            |
  |         |              |  confid **   |             |            |
  |---------+--------------+--------------+-------------+------------|
  | meter   |   authent    |     N/A      |  authent    |  authent   |
  | reader  |   acc ctrl   |              |  acc ctrl   |  acc ctrl  |
  |         |              |              |  integrity  |            |
  |         |              |              |  confid **  |            |
  |---------+--------------+--------------+-------------+------------|
  | appl    |     N/A      |  authent     |             |            |
  |         |              |  acc ctrl    |     ##      |    ##      |
  |---------+--------------+--------------+-------------+------------|
  | manager |  authent     |  authent     |     ##      |  authent   |
  |         |  acc ctrl    |  acc ctrl    |             |  acc ctrl  |
  |         |  integrity   |  integrity   |             |  integrity |
  +------------------------------------------------------------------+

     N/A = Not Applicable    ** = optional    ## = outside RTFM scope

     - When any two elements intercommunicate they should mutually
       authenticate themselves to one another.  This is indicated by '
       authent' in the table.  Once authentication is complete, an
       element should check that the requested type of access is
       allowed; this is indicated on the table by 'acc ctrl'.

     - Whenever there is a transfer of information its integrity should
       be protected.






<span class="grey">Brownlee, et al.             Informational                     [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


     - Whenever there is a transfer of usage data it should be possible
       to ensure its confidentiality if it is deemed sensitive to
       disclosure.  This is indicated by 'confid' in the table.

   Security protocols are not specified in this document.  The system
   elements' management and collection protocols are responsible for
   providing sufficient data integrity, confidentiality, authentication
   and access control services.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>  IANA Considerations</span>

   The RTFM Architecture, as set out in this document, has two sets of
   assigned numbers.  Considerations for assigning them are discussed in
   this section, using the example policies as set out in the
   "Guidelines for IANA Considerations" document [<a href="#ref-IANA-RFC" title="">IANA-RFC</a>].

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>  PME Opcodes</span>

   The Pattern Matching Engine (PME) is a virtual machine, executing
   RTFM rules as its instructions.  The PME opcodes appear in the
   'action' field of an RTFM rule.  The current list of opcodes, and
   their values for the PME's 'goto' and 'test' flags, are set out in
   <a href="#section-4.4">section 4.4</a> above ("Rules and Rulesets).

   The PME opcodes are pivotal to the RTFM architecture, since they must
   be implemented in every RTFM meter.  Any new opcodes must therefore
   be allocated through an IETF Consensus action [<a href="#ref-IANA-RFC" title="">IANA-RFC</a>].

   Opcodes are simply non-negative integers, but new opcodes should be
   allocated sequentially so as to keep the total opcode range as small
   as possible.

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>  RTFM Attributes</span>

   Attribute numbers in the range of 0-511 are globally unique and are
   allocated according to an IETF Consensus action [<a href="#ref-IANA-RFC" title="">IANA-RFC</a>]. <a href="#appendix-C">Appendix</a>
   <a href="#appendix-C">C</a> of this document allocates a basic (i.e. useful minimum) set of
   attribtes; they are assigned numbers in the range 0 to 63.  The RTFM
   working group is working on an extended set of attributes, which will
   have numbers in the range 64 to 127.

   Vendor-specific attribute numbers are in the range 512-1023, and will
   be allocated using the First Come FIrst Served policy [<a href="#ref-IANA-RFC" title="">IANA-RFC</a>].
   Vendors requiring attribute numbers should submit a request to IANA
   giving the attribute names: IANA will allocate them the next
   available numbers.





<span class="grey">Brownlee, et al.             Informational                     [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   Attribute numbers 1024 and higher are Reserved for Private Use
   [<a href="#ref-IANA-RFC" title="">IANA-RFC</a>]. Implementors wishing to experiment with further new
   attributes should use attribute numbers in this range.

   Attribute numbers are simply non-negative integers.  When writing
   specifications for attributes, implementors must give sufficient
   detail for the new attributes to be easily added to the RTFM Meter
   MIB [<a href="#ref-RTFM-MIB" title="&quot;Traffic Flow Measurement: Meter MIB&quot;">RTFM-MIB</a>]. In particular, they must indicate whether the new
   attributes may be:

    - tested in an IF statement
    - saved by a SAVE statement or set by a STORE statement
    - read from an RTFM meter

   (IF, SAVE and STORE are statements in the SRL Ruleset Language
   [<a href="#ref-RTFM-SRL" title="&quot;SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups&quot;">RTFM-SRL</a>]).



































<span class="grey">Brownlee, et al.             Informational                     [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>  APPENDICES</span>

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>  <a href="#appendix-A">Appendix A</a>: Network Characterisation</span>

   Internet users have extraordinarily diverse requirements.  Networks
   differ in size, speed, throughput, and processing power, among other
   factors.  There is a range of traffic flow measurement capabilities
   and requirements.  For traffic flow measurement purposes, the
   Internet may be viewed as a continuum which changes in character as
   traffic passes through the following representative levels:

           International                    |
           Backbones/National        ---------------
                                    /               \
           Regional/MidLevel     ----------   ----------
                                /     \    \ /    /     \
           Stub/Enterprise     ---   ---   ---   ----   ----
                               |||   |||   |||   ||||   ||||
           End-Systems/Hosts   xxx   xxx   xxx   xxxx   xxxx

   Note that mesh architectures can also be built out of these
   components, and that these are merely descriptive terms.  The nature
   of a single network may encompass any or all of the descriptions
   below, although some networks can be clearly identified as a single
   type.

   BACKBONE networks are typically bulk carriers that connect other
   networks.  Individual hosts (with the exception of network management
   devices and backbone service hosts) typically are not directly
   connected to backbones.

   REGIONAL networks are closely related to backbones, and differ only
   in size, the number of networks connected via each port, and
   geographical coverage.  Regionals may have directly connected hosts,
   acting as hybrid backbone/stub networks.  A regional network is a
   SUBSCRIBER to the backbone.

   STUB/ENTERPRISE networks connect hosts and local area networks.
   STUB/ENTERPRISE networks are SUBSCRIBERS to regional and backbone
   networks.

   END SYSTEMS, colloquially HOSTS, are SUBSCRIBERS to any of the above
   networks.

   Providing a uniform identification of the SUBSCRIBER in finer
   granularity than that of end-system, (e.g. user/account), is beyond
   the scope of the current architecture, although an optional attribute
   in the traffic flow measurement record may carry system-specific



<span class="grey">Brownlee, et al.             Informational                     [Page 41]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   'user identification' labels so that meters can implement proprietary
   or non-standard schemes for the attribution of network traffic to
   responsible parties.

<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>  <a href="#appendix-B">Appendix B</a>: Recommended Traffic Flow Measurement Capabilities</span>

   Initial recommended traffic flow measurement conventions are outlined
   here according to the following Internet building blocks.  It is
   important to understand what complexity reporting introduces at each
   network level.  Whereas the hierarchy is described top-down in the
   previous section, reporting requirements are more easily addressed
   bottom-up.

            End-Systems
            Stub Networks
            Enterprise Networks
            Regional Networks
            Backbone Networks

   END-SYSTEMS are currently responsible for allocating network usage to
   end-users, if this capability is desired.  From the Internet Protocol
   perspective, end-systems are the finest granularity that can be
   identified without protocol modifications.  Even if a meter violated
   protocol boundaries and tracked higher-level protocols, not all
   packets could be correctly allocated by user, and the definition of
   user itself varies widely from operating system to operating system
   (e.g. how to trace network usage back to users from shared
   processes).

   STUB and ENTERPRISE networks will usually collect traffic data either
   by end-system network address or network address pair if detailed
   reporting is required in the local area network.  If no local
   reporting is required, they may record usage information in the exit
   router to track external traffic only.  (These are the only networks
   which routinely use attributes to perform reporting at granularities
   finer than end-system or intermediate-system network address.)

   REGIONAL networks are intermediate networks.  In some cases,
   subscribers will be enterprise networks, in which case the
   intermediate system network address is sufficient to identify the
   regional's immediate subscriber.  In other cases, individual hosts or
   a disjoint group of hosts may constitute a subscriber.  Then end-
   system network address pairs need to be tracked for those
   subscribers.  When the source may be an aggregate entity (such as a
   network, or adjacent router representing traffic from a world of
   hosts beyond) and the destination is a singular entity (or vice
   versa), the meter is said to be operating as a HYBRID system.




<span class="grey">Brownlee, et al.             Informational                     [Page 42]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-43" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


   At the regional level, if the overhead is tolerable it may be
   advantageous to report usage both by intermediate system network
   address (e.g. adjacent router address) and by end-system network
   address or end-system network address pair.

   BACKBONE networks are the highest level networks operating at higher
   link speeds and traffic levels.  The high volume of traffic will in
   most cases preclude detailed traffic flow measurement.  Backbone
   networks will usually account for traffic by adjacent routers'
   network addresses.

<span class="h3"><a class="selflink" id="section-9.3" href="#section-9.3">9.3</a>  <a href="#appendix-C">Appendix C</a>: List of Defined Flow Attributes</span>

   This Appendix provides a checklist of the attributes defined to date;
   others will be added later as the Traffic Measurement Architecture is
   further developed.

   Note that this table gives only a very brief summary.  The Meter MIB
   [<a href="#ref-RTFM-MIB" title="&quot;Traffic Flow Measurement: Meter MIB&quot;">RTFM-MIB</a>] provides the definitive specification of attributes and
   their allowed values.  The MIB variables which represent flow
   attributes have 'flowData' prepended to their names to indicate that
   they belong to the MIB's flowData table.

       0  Null

       4  SourceInterface        Integer     Source Address
       5  SourceAdjacentType     Integer
       6  SourceAdjacentAddress  String
       7  SourceAdjacentMask     String
       8  SourcePeerType         Integer
       9  SourcePeerAddress      String
      10  SourcePeerMask         String
      11  SourceTransType        Integer
      12  SourceTransAddress     String
      13  SourceTransMask        String

      14  DestInterface          Integer     Destination Address
      15  DestAdjacentType       Integer
      16  DestAdjacentAddress    String
      17  DestAdjacentMask       String
      18  DestPeerType           Integer
      19  DestPeerAddress        String
      20  DestPeerMask           String
      21  DestTransType          Integer
      22  DestTransAddress       String
      23  DestTransMask          String





<span class="grey">Brownlee, et al.             Informational                     [Page 43]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-44" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


      26  RuleSet                Integer     Meter attribute

      27  ToOctets               Integer     Source-to-Dest counters
      28  ToPDUs                 Integer
      29  FromOctets             Integer     Dest-to-Source counters
      30  FromPDUs               Integer
      31  FirstTime              Timestamp   Activity times
      32  LastActiveTime         Timestamp
      33  SourceSubscriberID     String      Session attributes
      34  DestSubscriberID       String
      35  SessionID              String

      36  SourceClass            Integer     'Computed' attributes
      37  DestClass              Integer
      38  FlowClass              Integer
      39  SourceKind             Integer
      40  DestKind               Integer
      41  FlowKind               Integer

      50  MatchingStoD           Integer     PME variable

      51  v1                     Integer     Meter Variables
      52  v2                     Integer
      53  v3                     Integer
      54  v4                     Integer
      55  v5                     Integer

      65
      ..  'Extended' attributes (to be defined by the RTFM working group)
     127

<span class="h3"><a class="selflink" id="section-9.4" href="#section-9.4">9.4</a>  <a href="#appendix-D">Appendix D</a>: List of Meter Control Variables</span>

      Meter variables:
         Flood Mark                    Percentage
         Inactivity Timeout (seconds)  Integer

      'per task' variables:
         Current Rule Set Number       Integer
         Standby Rule Set Number       Integer
         High Water Mark               Percentage

      'per reader' variables:
         Reader Last Time              Timestamp







<span class="grey">Brownlee, et al.             Informational                     [Page 44]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-45" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


<span class="h3"><a class="selflink" id="section-9.5" href="#section-9.5">9.5</a>  <a href="#appendix-E">Appendix E</a>: Changes Introduced Since <a href="./rfc2063">RFC 2063</a></span>

   The first version of the Traffic Flow Measurement Architecture was
   published as <a href="./rfc2063">RFC 2063</a> in January 1997.  The most significant changes
   made since then are summarised below.

     - A Traffic Meter can now run multiple rule sets concurrently.
       This makes a meter much more useful, and required only minimal
       changes to the architecture.

     - 'NoMatch' replaces 'Fail' as an action.  This name was agreed to
       at the Working Group 1996 meeting in Montreal; it better
       indicates that although a particular match has failed, it may be
       tried again with the packet's addresses reversed.

     - The 'MatchingStoD' attribute has been added.  This is a Packet
       Matching Engine (PME) attribute indicating that addresses are
       being matched in StoD (i.e. 'wire') order.  It can be used to
       perform different actions when the match is retried, thereby
       simplifying some kinds of rule sets.  It was discussed and agreed
       to at the San Jose meeting in 1996.

     - Computed attributes (Class and Kind) may now be tested within a
       rule set.  This lifts an unneccessary earlier restriction.

     - The list of attribute numbers has been extended to define ranges
       for 'basic' attributes (in this document) and 'extended'
       attributes (currently being developed by the RTFM Working Group).

     - The 'Security Considerations' section has been completely
       rewritten.  It provides an evaluation of traffic measurement
       security risks and their countermeasures.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>  Acknowledgments</span>

       An initial draft of this document was produced under the auspices
       of the IETF's Internet Accounting Working Group with assistance
       from SNMP, RMON and SAAG working groups.  Particular thanks are
       due to Stephen Stibler (IBM Research) for his patient and careful
       comments during the preparation of this memo.











<span class="grey">Brownlee, et al.             Informational                     [Page 45]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-46" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>  References</span>

   [<a id="ref-802-3">802-3</a>]    IEEE 802.3/ISO 8802-3 Information Processing Systems -
              Local Area Networks - Part 3: Carrier sense multiple
              access with collision detection (CSMA/CD) access method
              and physical layer specifications, 2nd edition, September
              21, 1990.

   [<a id="ref-ACT-BKG">ACT-BKG</a>]  Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting
              Background", <a href="./rfc1272">RFC 1272</a>, November 1991.

   [<a id="ref-IANA-RFC">IANA-RFC</a>] Alvestrand, H. and T. Narten, "Guidelines for Writing an
              IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc2434">RFC 2434</a>,
              October 1998.

   [<a id="ref-IPPM-FRM">IPPM-FRM</a>] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis,
              "Framework for IP Performance Metrics", <a href="./rfc2330">RFC 2330</a>, May
              1998.

   [<a id="ref-OSI-ACT">OSI-ACT</a>]  International Standards Organisation (ISO), "Management
              Framework", Part 4 of Information Processing Systems Open
              Systems Interconnection Basic Reference Model, ISO 7498-4,
              1994.

   [<a id="ref-RTFM-MIB">RTFM-MIB</a>] Brownlee, N., "Traffic Flow Measurement: Meter MIB", <a href="./rfc2720">RFC</a>
              <a href="./rfc2720">2720</a>, October 1999.

   [<a id="ref-RTFM-NEW">RTFM-NEW</a>] Handelman, S., Stibler, S., Brownlee, N. and G. Ruth,
              "RTFM: New Attributes for Traffic Flow Measurment", <a href="./rfc2724">RFC</a>
              <a href="./rfc2724">2724</a>, October 1999.

   [<a id="ref-RTFM-SRL">RTFM-SRL</a>] Brownlee, N., "SRL: A Language for Describing Traffic
              Flows and Specifying Actions for Flow Groups", <a href="./rfc2723">RFC 2723</a>,
              October 1999.

















<span class="grey">Brownlee, et al.             Informational                     [Page 46]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-47" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>  Authors' Addresses</span>

   Nevil Brownlee
   Information Technology Systems &amp; Services
   The University of Auckland
   Private Bag 92-019
   Auckland, New Zealand

   Phone: +64 9 373 7599 x8941
   EMail: n.brownlee@auckland.ac.nz


   Cyndi Mills
   GTE Laboratories, Inc
   40 Sylvan Rd.
   Waltham, MA 02451, U.S.A.

   Phone: +1 781 466 4278
   EMail: cmills@gte.com


   Greg Ruth
   GTE Internetworking
   3 Van de Graaff Drive
   P.O. Box 3073
   Burlington, MA 01803, U.S.A.

   Phone: +1 781 262 4831
   EMail: gruth@bbn.com






















<span class="grey">Brownlee, et al.             Informational                     [Page 47]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-48" ></span>
<span class="grey"><a href="./rfc2722">RFC 2722</a>         Traffic Flow Measurement: Architecture     October 1999</span>


<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>  Full Copyright Statement</span>

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Brownlee, et al.             Informational                     [Page 48]
</pre>