GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2063

Network Working Group N. Brownlee Request for Comments: 2063 The University of Auckland Category: Experimental C. Mills

                                          BBN Systems and Technologies
                                                               G. Ruth
                                                GTE Laboratories, Inc.
                                                          January 1997
              Traffic Flow Measurement:  Architecture

Status of this Memo

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

Abstract

 This document describes an architecture for the measurement and
 reporting of network traffic flows, discusses how this relates to an
 overall network traffic flow architecture, and describes how it can
 be used within the Internet.  It is intended to provide a starting
 point for the Realtime Traffic Flow Measurement Working Group.

Table of Contents

1 Statement of Purpose and Scope 2 2 Traffic Flow Measurement Architecture 4

 2.1 Meters and Traffic Flows . . . . . . . . . . . . . . . . . .   4
 2.2 Interaction Between METER and METER READER . . . . . . . . .   6
 2.3 Interaction Between MANAGER and METER  . . . . . . . . . . .   6
 2.4 Interaction Between MANAGER and METER READER . . . . . . . .   7
 2.5 Multiple METERs or METER READERs . . . . . . . . . . . . . .   7
 2.6 Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . .   8
 2.7 METER READERs and APPLICATIONs . . . . . . . . . . . . . . .   8

3 Traffic Flows and Reporting Granularity 9

 3.1 Flows and their Attributes . . . . . . . . . . . . . . . . .   9
 3.2 Granularity of Flow Measurements . . . . . . . . . . . . . .  11
 3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only  . .  13

4 Meters 15

 4.1 Meter Structure  . . . . . . . . . . . . . . . . . . . . . .  15
 4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . .  17
 4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . .  17
 4.4 Rules and Rule Sets  . . . . . . . . . . . . . . . . . . . .  21
 4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . .  24
 4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . .  25

Brownlee, et. al. Experimental [Page 1] RFC 2063 Traffic Flow Measurement: Architecture January 1997

5 Meter Readers 26

 5.1 Identifying Flows in Flow Records  . . . . . . . . . . . . .  26
 5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . .  27
 5.3 Meter to Meter Reader:  Usage Record Transmission. . . . . .  27

6 Managers 28

 6.1 Between Manager and Meter:  Control Functions  . . . . . . .  28
 6.2 Between Manager and Meter Reader:  Control Functions   . . .  29
 6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . .  31
 6.4 Standard Rule Sets   . . . . . . . . . . . . . . . . . . . .  32

7 APPENDICES 33

 7.1 Appendix A: Network Characterisation . . . . . . . . . . . .  33
 7.2 Appendix B: Recommended Traffic Flow Measurement Capabilities 34
 7.3 Appendix C: List of Defined Flow Attributes  . . . . . . . .  35
 7.4 Appendix D: List of Meter Control Variables  . . . . . . . .  36

8 Acknowledgments 36 9 References 37 10 Security Considerations 37 11 Authors' Addresses 37

1 Statement of Purpose and Scope

 This document describes an architecture for traffic flow measurement
 and reporting for data networks which has the following
 characteristics:
  1. The traffic flow model can be consistently applied to any

protocol/application at any network layer (e.g. network,

     transport, application layers).
  1. 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.
  1. Users may specify their traffic flow measurement requirements

in a simple manner, allowing them to collect the flow data they

     need while ignoring other traffic.
  1. The data reduction effort to produce requested traffic flow

information is placed as near as possible to the network

     measurement point.  This reduces the volume of data to be
     obtained (and transmitted across the network for storage),
     and minimises the amount of processing required in traffic
     flow analysis applications.

Brownlee, et. al. Experimental [Page 2] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 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:
  1. Understanding the behaviour of existing networks,
  1. Planning for network development and expansion,
  1. Quantification of network performance,
  1. Verifying the quality of network service, and
  1. Attribution of network usage to users.
 The traffic flow measurement architecture is deliberately structured
 so that specific protocol implementations may extend coverage to
 multi-protocol environments and to other protocol layers, such as
 usage measurement for application-level services.  Use of the same
 model for both network- and application-level measurement may
 simplify the development of generic analysis applications which
 process and/or correlate any or all levels of traffic and usage
 information.  Within this docuemt the term 'usage data' is used as a
 generic term for the data obtained using the traffic flow measurement
 architecture.
 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 'Traffic Flow Measurement:  Background' RFC [1].

Brownlee, et. al. Experimental [Page 3] RFC 2063 Traffic Flow Measurement: Architecture January 1997

2 Traffic Flow Measurement Architecture

 A traffic flow measurement system is used by network Operations
 personnel for 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 section 1
 (above).
 The following sections outline a model for traffic flow measurement,
 which draws from working drafts of the OSI accounting model [2].
 Future extensions are anticipated as the model is refined to address
 additional protocol layers.

2.1 Meters and Traffic Flows

 At the heart of the traffic measurement model are network entities
 called traffic METERS. Meters count certain attributes (such as
 numbers of packets and bytes) and classify them as belonging to
 ACCOUNTABLE ENTITIES using other attributes (such as source and
 destination addresses).  An accountable entity is someone who (or
 something which) is responsible for some activitiy on the network.
 It may be a user, a host system, a network, a group of networks, etc,
 depending on the granularity specified by 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 'Traffic Flow
 Measurement:  Background' RFC [1].  An important aspect of meters is
 that they provide a way of succinctly aggregating entity usage
 information.
 For the purpose of traffic flow measurement we define the concept of
 a TRAFFIC FLOW, which is an artificial logical equivalent to a call
 or connection.  A flow is a portion of traffic, delimited by a start
 and stop time, that was generated by a particular accountable entity.
 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 end 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

Brownlee, et. al. Experimental [Page 4] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 which flow they belong to.  Classifying packets into 'flows' in this
 way provides an economical and practical way to measure network
 traffic and ascribe it to accountable entities.
 Usage information which is not deriveable 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 will 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 APPLICAIONS, 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   <----->   METER READER  <----->   APPLICATION
                   2.2                     2.7
  1. MANAGER: A traffic measurement manager is an application which

configures 'meter' entities and controls 'meter reader' entities.

  It uses the data requirements of analysis applications to determine
  the appropriate configurations for each meter, and the proper
  operation of each meter reader.  It may well be convenient to
  combine the functions of meter reader and manager within a single
  network entity.
  1. 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.'
  1. METER READER: A meter reader reliably transports usage data from

meters so that it is available to analysis applications.

Brownlee, et. al. Experimental [Page 5] RFC 2063 Traffic Flow Measurement: Architecture January 1997

  1. 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:
  1. TRAFFIC FLOW MATRICES, showing the total flow rates for

many of the possible paths within an internet.

  1. FLOW RATE FREQUENCY DISTRIBUTIONS, indicating how flow

rates vary with time.

  1. 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.

2.2 Interaction Between METER and METER READER

 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.

2.3 Interaction Between MANAGER and METER

 A manager is responsible for configuring and controlling one or more
 meters.  At the time of writing a meter can only be controlled by a
 single manager; in the future this restriction may be relaxed.  Each
 meter's configuration includes information such as:
  1. 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.
  1. Meter control parameters, e.g. the maximum size of its flow table,

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).

Brownlee, et. al. Experimental [Page 6] RFC 2063 Traffic Flow Measurement: Architecture January 1997

  1. Sampling rate. Normally every packet will be observed. It may

sometimes be necessary to use sampling techniques to observe only

  some of the packets.  (Sampling algorithms are not prescribed by
  the architecture; it should be noted that before using sampling one
  should verify the statistical validity of the algorithm used).
  Current experience with the measurement architecture shows that a
  carefully-designed and implemented meter compresses the data such
  that in normal LANs and WANs of today sampling is really not
  needed.

2.4 Interaction Between MANAGER and METER READER

 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 is is collecting usage data from:
  1. The meter's unique identity, i.e. its network name or address.
  1. How often usage data is to be collected from the meter.
  1. Which flow records are to be collected (e.g. all active flows, the

whole flow table, flows seen since a given time, etc.).

  1. 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.

2.5 Multiple METERs or METER READERs

  1. - 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.

Brownlee, et. al. Experimental [Page 7] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 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 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.
 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 neccesarily 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 precisely synchronized collections are required this can be
 achieved by having one manager request each meter to begin collecting
 a new set of flows, then allowing all meter readers to collect the
 usage data from the old sets of flows.
 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
 traffic volume was sufficient to 'roll over' counters for some flows
 during the failure; this is addressed in the section on 'Rolling
 Counters.'

2.6 Interaction Between MANAGERs (MANAGER - MANAGER)

 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.

2.7 METER READERs and APPLICATIONs

 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.

Brownlee, et. al. Experimental [Page 8] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 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.

3 Traffic Flows and Reporting Granularity

 A flow was defined in section 2.1 above in abstract terms as follows:
  "A TRAFFIC FLOW is an artifical logical equivalent to a call or
  connection, belonging to an ACCOUNTABLE ENTITY."
 In practical terms, a flow is a stream of packets passing across a
 network between two end points (or being sent from a single end
 point), which have been summarized by a traffic meter for analysis
 purposes.

3.1 Flows and their Attributes

 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:
  1. 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), and the number of the
  interface on which the packet was observed.
  1. First and last TIMES when packets were seen for this flow, i.e.

the 'creation' and 'last activity' times for the flow.

  1. 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.
  1. OTHER attributes, e.g. information computed by the meter.
 A flow's ACCOUNTABLE ENTITY is specified by the values of its ADDRESS
 attributes.  For example, if a flow's address attributes specified
 only that "source address = IP address 10.1.0.1," then all IP packets
 from and to that address would be counted in that flow.  If a flow's
 address list were specified as "source address = IP address 10.1.0.1,
 destination address = IP address 26.1.0.1" then only IP packets
 between 10.1.0.1 and 26.1.0.1 would be counted in that flow.

Brownlee, et. al. Experimental [Page 9] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 The addresses specifying a flow's address attributes may include one
 or more of the following types:
  1. 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.
  1. The ADJACENT ADDRESS, i.e. the [n-1] layer address of the

immediate source or destination on the path of the packet. For

  example, if flow measurement is being performed at the IP layer on
  an Ethernet LAN [3], an adjacent address is 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.
  1. The PEER ADDRESS, which identifies the source or destination of the

PEER-LEVEL packet. The form of a peer address will depend on the

  network-layer protocol in use, and the network layer [n] at which
  traffic measurement is being performed.
  1. 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.  Further work is needed here, particularly in
 selecting attributes which will be suitable for the higher layers of
 the OSI reference model.

Brownlee, et. al. Experimental [Page 10] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 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 'Traffic Flow Measurement:  Background' RFC [1].  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.
 In cases where network addresses are dynamically allocated (e.g.
 mobile subscribers), further subscriber identification will be
 necessary if flows are to ascribed to individual users.  Provision is
 made to further specify the accountable entity 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 proprietary means within a meter, for example via protocol
 exchanges with one or more (multi-user) hosts.  At this time a
 subscriber ID is an arbitrary text string; later versions of the
 architecture may specify its contents on more detail.

3.2 Granularity of Flow Measurements

 GRANULARITY is the 'control knob' by which an application and/or the
 meter can trade off the overhead associated with performing usage
 reporting against the level of detail supplied.  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 the accountable entity, the attributes, or the time intervals.
 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.
 Flow granularity is controlled by adjusting the level of detail at
 which the following are reported:
  1. The accountable entity (address attributes, discussed above).
  1. The categorisation of packets (other attributes, discussed below).
  1. The lifetime/duration of flows (the reporting interval needs to be

short enough to measure them with sufficient precision).

Brownlee, et. al. Experimental [Page 11] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 The set of rules controlling the determination of each packet's
 accountable entity 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
 must be identifiable via a RULE SET ID. Granularity of accountable
 entities is further specified by additional ATTRIBUTES. These
 attributes include:
  1. Meter variables such as the index of the flow's record in the flow

table and the rule set id 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.
  1. 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.
  1. Administratively specified attributes such as Quality Of Service

and Priority, etc. These are not defined at this time.

  1. Higher-layer (especially application-level) attributes. 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.
 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

Brownlee, et. al. Experimental [Page 12] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 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 must be sure
 that the flow's data has been collected by at least one meter reader.
 These 'lifetime' issues are considered further in the section on
 meter readers (below).  A complete list of the attributes currently
 defined is given in Appendix C later in this document.

3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only

 Once an 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

Brownlee, et. al. Experimental [Page 13] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 was then stopped (perhaps because of temporary idleness, or MAX
 LIFETIME policy), 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.
 Each packet is counted in one and only one flow, 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.
 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.'
 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 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 & 2, and "Total packets sourced by IP address a.b.c.d" can be found
 by adding buckets 1 & 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.

Brownlee, et. al. Experimental [Page 14] RFC 2063 Traffic Flow Measurement: Architecture January 1997

4 Meters

 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:
  1. A dedicated small host, connected to a 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.
  1. 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.
  1. 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.
 The discussion in the following sections assumes that a meter may
 only run a single rule set.  It is, however, possible for a meter to
 run several rule sets concurrently, matching each packet against
 every active rule set and producing a single flow table with flows
 from all the active rule sets.  The overall effect of doing this
 would be similar to running several independent meters, one for each
 rule set.

4.1 Meter Structure

 An outline of the meter's structure is given in the following
 diagram.
 Briefly, the meter works as follows:
  1. Incoming packet headers arrive at the top left of the diagram and

are passed to the PACKET PROCESSOR.

  1. The packet processor passes them to the Packet Matching Engine

(PME) where they are classified.

  1. The PME is a Virtual Machine running a pattern matching program

contained in the CURRENT RULE SET. It is invoked by the Packet

  Processor, and returns instructions on what to do with the packet.

Brownlee, et. al. Experimental [Page 15] RFC 2063 Traffic Flow Measurement: Architecture January 1997

  1. Some packets are classified as 'to be ignored.' They are discarded

by the Packet Processor.

  1. Other packets are matched by the PME, which returns a FLOW KEY

describing the flow to which the packet belongs.

  1. 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

  packet and byte counters are updated.
  1. 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 |
                  |                   +--------+---------+
                  |                            |
         +--------*---------+       +----------*-------------+
         | Packet Processor |<----->| Packet Matching Engine |
         +--+------------+--+       +------------------------+
            |            |
     Ignore *            | Count via flow key
                         |
                      +--*--------------+
                      | 'Search' index  |
                      +--------+--------+
                               |
                      +--------*--------+
                      |                 |
                      |   Flow Table    |
                      |                 |
                      +--------+--------+
                               |
                      +--------*--------+
                      | 'Collect' index |
                      +--------+--------+
                               |
                               *
                          Meter Reader

Brownlee, et. al. Experimental [Page 16] RFC 2063 Traffic Flow Measurement: Architecture January 1997

4.2 Flow Table

 Every traffic meter maintains a table of TRAFFIC FLOW RECORDS for
 flows seen by the meter.  A flow record contains attribute values for
 its flow, including:
  1. Addresses for the flow's source and destination. These include

addresses and masks for various network layers (extracted from the

  packet), and the number of the interface on which the packet was
  observed.
  1. First and last times when packets were seen for this flow.
  1. Counts for 'forward' (source to destination) and 'backward'

(destination to source) components of the flow's traffic.

  1. Other attributes, e.g. state of the flow record (discussed below).
 The state of a flow record may be:
  1. INACTIVE: The flow record is not being used by the meter.
  1. 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.
  1. 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.

4.3 Packet Handling, Packet Matching

 Each packet header received by the traffic meter program is processed
 as follows:
  1. Extract attribute values from the packet header and use them to

create a MATCH KEY for the packet.

  1. 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 counts
 for the matching flow record can then be incremented.

Brownlee, et. al. Experimental [Page 17] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 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 an interface number, source
 address (S) and destination address (D) values.  It does not,
 however, contain any attribute masks for its attributes, only their
 values.
 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.
 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, and D indicates
 its destination address.
 There are several cases to consider.  These are:
  1. The packet is recognised as one which is TO BE IGNORED.
  1. The packet MATCHES IN BOTH DIRECTIONS. 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->z, the meter must check that flow
  z->y is not already current before creating y->z.

Brownlee, et. al. Experimental [Page 18] RFC 2063 Traffic Flow Measurement: Architecture January 1997

  1. 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.
 The algorithm uses four functions, as follows:

match(A→B) implements the PME. It uses the meter's current rule set

 to match the attribute values in the packet's match key.  A->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.
 'Fail' 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→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→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→B,f) increments the 'forward' counters for flow A-to-B. count(A→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->B,f) is identical to count(B->A,r).

Brownlee, et. al. Experimental [Page 19] RFC 2063 Traffic Flow Measurement: Architecture January 1997

                  Ignore
  --- match(S->D) -------------------------------------------------+
       | Suc   | Fail                                              |
       |       |          Ignore                                   |
       |      match(D->S) -----------------------------------------+
       |       | Suc   | Fail                                      |
       |       |       |                                           |
       |       |       +-------------------------------------------+
       |       |                                                   |
       |       |             Suc                                   |
       |      current(D->S) ---------- count(D->S,r) --------------+
       |       | Fail                                              |
       |       |                                                   |
       |      create(D->S) ----------- count(D->S,r) --------------+
       |                                                           |
       |             Suc                                           |
      current(S->D) ------------------ count(S->D,f) --------------+
       | Fail                                                      |
       |             Suc                                           |
      current(D->S) ------------------ count(D->S,r) --------------+
       | Fail                                                      |
       |                                                           |
      create(S->D) ------------------- count(S->D,f) --------------+
                                                                   |
                                                                   *
 When writing rule sets one must remember that the meter will normally
 try to match each packet in both directions.  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.  Another approach would be to write a
 'rule set consistency checker' program, which could detect problems
 in hand-written rule sets.
 In the short term the best way to avoid these problems is to write
 rule sets which only clasify flows in the forward direction, and rely
 on the meter to handle reverse-travelling packets.

Brownlee, et. al. Experimental [Page 20] RFC 2063 Traffic Flow Measurement: Architecture January 1997

4.4 Rules and Rule Sets

 A rule set is an array of rules.  Rule sets are held within a meter
 as entries in an array of rule sets.  One member of this array is the
 CURRENT RULE SET, in that it is the one which is currently being used
 by the meter to classify incoming packets.
 Rule set 1 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.
 If the meter 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 structured as follows:
 +-------- test ---------+    +---- action -----+
 attribute & mask = value:    opcode,  parameter;
 Opcodes contain two flags:  'goto' and 'test.'  The PME maintains a
 Boolean indicator called the 'test indicator,' which is initially set
 (on).  Execution begins with rule 1, the first in the rule set.  It
 proceeds as follows:
 If the test indicator is on:
    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 failure.
 If the test indicator is off, or the test (above) succeeded:
    Set the test indicator to this rule'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, Fail, Count,
          CountPkt).
    Perform the action.

Brownlee, et. al. Experimental [Page 21] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 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.  The second, 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 and
 mask information from the pattern stack in the order it was enqueued.
 The opcodes are:
       opcode         goto    test
    1  Ignore           0       -
    2  Fail             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
 The actions they perform are:
 Ignore:         Stop matching, return from the match() function
                 indicating that the packet is to be ignored.
 Fail:           Stop matching, return from the match() function
                 indicating failure.
 Count:          Stop matching.  Save this rule's attribute name,
                 mask and value in the PME's pattern queue, then
                 construct a flow key for the flow to which this
                 this packet belongs.  Return from the match()
                 function indicating success.  The meter will use
                 the flow key to locate the flow record for this
                 packet's flow.
 CountPkt:       As for Count, except that the masked value from
                 the packet is saved in the PME's pattern queue
                 instead of the rule's value.

Brownlee, et. al. Experimental [Page 22] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 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
                 value specified in 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 name, 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.

Brownlee, et. al. Experimental [Page 23] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 PushPktTo:      Save this rule's attribute name, mask, together
                 with the masked value from the packet, 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 using a specified mask.  The test in
                 PushPktTo rules will almost never be executed.
 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.
 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 name 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.
 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.
             Since their values are only defined when matching is
             complete (and the flow key is built) their values may
             not be tested in rules.

4.5 Maintaining the Flow Table

 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 seen for a flow which is not in the current
 flow set a flow record is set up 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 a 'inactive' record - there is no

Brownlee, et. al. Experimental [Page 24] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 particular significance in the ordering of records within the table.
 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 a LastCollectTime variable which remembers the time the
 last collection was made.  A second variable, InactivityTime,
 specifies the minimum time the meter will wait before considering
 that a flow is idle.
 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.  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.  This would be suitable for use
 when one was interested in measuring flow lifetimes.
 Another recovery strategy is to leave idle flows alone as long as
 possible, which would be suitable 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 out of
 '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, network Operations
 personnel should be able to specify the minimum number of meters - or
 perhaps a specific list of meters - which should collect a flow's
 data before its memory can be recovered.  This issue will be further
 developed in the future.

4.6 Handling Increasing Traffic Levels

 Under normal conditions the meter reader specifies which set of usage
 records it wants to collect, and the meter provides them.
 If memory usage rises above the high-water mark the meter should
 switch to a STANDBY RULE SET so as to increase the granularity of

Brownlee, et. al. Experimental [Page 25] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 flow collection and 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.  The meter should 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.

5 Meter Readers

 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 a disk file called 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.

5.1 Identifying Flows in Flow Records

 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 id and 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.

Brownlee, et. al. Experimental [Page 26] RFC 2063 Traffic Flow Measurement: Architecture January 1997

5.2 Usage Records, Flow Data Files

 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.
 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.  Each usage record contains the entity
 identifier of the meter (a network address), 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 (& 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         |
 +-------------------------------------------------------------------+

5.3 Meter to Meter Reader: 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 flows).  One possible method
 of achieving this transfer is to use SNMP; the 'Traffic Flow
 Measurement:  Meter MIB' document [4] 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.

Brownlee, et. al. Experimental [Page 27] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 The reliability of the data transfer method under light, normal, and
 extreme network loads should be understood before selecting among
 collection methods.
 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 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.

6 Managers

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

6.1 Between Manager and Meter: Control Functions

  1. 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; the others 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.
  1. SWITCH TO SPECIFIED RULE SET: Once the rule sets have been

downloaded, the manager must instruct the meter which rule set it

  is to actually run (i.e.  which is to be the current rule set), and
  which is to be the standby rule set.
  1. SET HIGH WATER MARK: A percentage value interpreted by the meter

which tells the meter when to switch to its standby rule set, so as

  to increase the granularity of the flows and conserve the meter's

Brownlee, et. al. Experimental [Page 28] RFC 2063 Traffic Flow Measurement: Architecture January 1997

  flow memory.  Once this has happened, the manager 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).
  If the high traffic levels persist, the meter's normal rule set may
  have to be rewritten to permanently reduce the reporting
  granularity.
  1. 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:
  1. Flows that have already been reported to at least one meter

reader, and show no activity since the last report,

  1. Oldest flows, or
  1. Flows with the smallest number of unreported packets.
  1. 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.

6.2 Between Manager and Meter Reader: 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 reporting
 interval must be decreased or a coarser granularity of aggregation
 must be used so that more data fits into less space.
 Increasing the reporting 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
 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.

Brownlee, et. al. Experimental [Page 29] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 Network management operations follow:
  1. MANAGER and METER READER IDENTIFICATION: The manager should ensure

that meters report to the correct set of collection stations, and

  take steps to prevent unauthorised access to usage information.
  The collection stations so identified should be prepared to poll if
  necessary and accept data from the appropriate meters.  Alternate
  collection stations may be identified in case both the primary
  manager and the primary collection station are unavailable.
  Similarly, alternate managers may be identified.
  1. 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 must
  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).
  1. 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
  1. Controls flow-id granularities for each interface, and
  1. 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.
  1. 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.

Brownlee, et. al. Experimental [Page 30] RFC 2063 Traffic Flow Measurement: Architecture January 1997

6.3 Exception Conditions

 Exception conditions must be handled, particularly occasions when the
 meter runs out of buffer space.  Since, to prevent counting any
 packet twice, packets can only be counted in a single flow at any
 given time, discarding records will result in the loss of
 information.  The mechanisms to deal with this are as follows:
  1. METER OUTAGES: In case of impending meter outages (controlled

crashes, etc.) the meter could send a trap to the manager. The

  manager could then request one or more meter readers to pick up the
  usage record 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.
  1. 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.
  1. MANAGER OUTAGES: If the manager fails for any reason, the meter

should continue measuring and the meter reader(s) should keep

  gathering usage records.
  1. 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:
  1. The reporting interval is too infrequent,
  1. The reporting granularity is too fine, or
  1. The throughput/bandwidth of circuits carrying the usage

data is too low.

  The manager may change any of these parameters in response to the
  meter (or meter reader's) plea for help.

Brownlee, et. al. Experimental [Page 31] RFC 2063 Traffic Flow Measurement: Architecture January 1997

6.4 Standard Rule Sets

 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:
  1. PROTOCOL TYPE: The meter records packets by protocol type. This

will be the default rule table for Traffic Flow Meters.

  1. 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.
  1. 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.
  1. TRANSPORT TYPE: The meter records packets by transport address; for

IP packets this provides usage information for the various IP

  services.
  1. 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.

Brownlee, et. al. Experimental [Page 32] RFC 2063 Traffic Flow Measurement: Architecture January 1997

7 APPENDICES

7.1 Appendix A: Network Characterisation

 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

Brownlee, et. al. Experimental [Page 33] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 in the traffic flow measurement record may carry system-specific
 "accountable (billable) party" labels so that meters can implement
 proprietary or non-standard schemes for the attribution of network
 traffic to responsible parties.

7.2 Appendix B: Recommended Traffic Flow Measurement Capabilities

 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 too 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.

Brownlee, et. al. Experimental [Page 34] RFC 2063 Traffic Flow Measurement: Architecture January 1997

 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.

7.3 Appendix C: List of Defined Flow Attributes

 This Appendix provides a checklist of the attributes defined to date;
 others will be added later as the Traffic Measurement Architecture is
 further developed.
 0  Null
 1  Flow Subscript                Integer    Flow table info
 2  Flow Status                   Integer
 4  Source Interface              Integer    Source Address
 5  Source Adjacent Type          Integer
 6  Source Adjacent Address       String
 7  Source Adjacent Mask          String
 8  Source Peer Type              Integer
 9  Source Peer Address           String
10  Source Peer Mask              String
11  Source Trans Type             Integer
12  Source Trans Address          String
13  Source Trans Mask             String
14  Destination Interface         Integer    Destination Address
15  Destination Adjacent Type     Integer
16  Destination Adjacent Address  String
17  Destination AdjacentMask      String
18  Destination PeerType          Integer
19  Destination PeerAddress       String
20  Destination PeerMask          String
21  Destination TransType         Integer
22  Destination TransAddress      String
23  Destination TransMask         String
24  Packet Scale Factor           Integer    'Other' attributes
25  Byte Scale Factor             Integer
26  Rule Set Number               Integer
27  Forward Bytes                 Counter    Source-to-Dest counters
28  Forward Packets               Counter

Brownlee, et. al. Experimental [Page 35] RFC 2063 Traffic Flow Measurement: Architecture January 1997

29  Reverse Bytes                 Counter    Dest-to-Source counters
30  Reverse Packets               Counter
31  First Time                    TimeTicks  Activity times
32  Last Active Time              TimeTicks
33  Source Subscriber ID          String     Session attributes
34  Destination Subscriber ID     String
35  Session ID                    String
36  Source Class                  Integer    'Computed' attributes
37  Destination Class             Integer
38  Flow Class                    Integer
39  Source Kind                   Integer
40  Destination Kind              Integer
41  Flow Kind                     Integer
51  V1                            Integer    Meter variables
52  V2                            Integer
53  V3                            Integer
54  V4                            Integer
55  V5                            Integer

7.4 Appendix D: List of Meter Control Variables

    Current Rule Set Number       Integer
    Standby Rule Set Number       Integer
    High Water Mark               Percentage
    Flood Mark                    Percentage
    Inactivity Timeout (seconds)  Integer
    Last Collect Time             TimeTicks

8 Acknowledgments

 This document was initially produced under the auspices of the IETF's
 Internet Accounting Working Group with assistance from SNMP, RMON and
 SAAG working groups.  This version documents the implementation work
 done by the Internet Accounting Working Group, and is intended to
 provide a starting point for the Realtime Traffic Flow Measurement
 Working Group.  Particular thanks are due to Stephen Stibler (IBM
 Research) for his patient and careful comments during the preparation
 of this memo.

Brownlee, et. al. Experimental [Page 36] RFC 2063 Traffic Flow Measurement: Architecture January 1997

9 References

 [1] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting
 Background", RFC 1272, Bolt Beranek and Newman Inc., Meridian
 Technology Corporation, November 1991.
 [2] International Standards Organisation (ISO), "Management
 Framework," Part 4 of Information Processing Systems Open
 Systems Interconnection Basic Reference Model, ISO 7498-4,
 1994.
 [3] 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.
 [4] Brownlee, N., "Traffic Flow Measurement:  Meter MIB",
 RFC 2064, The University of Auckland, January 1997.

10 Security Considerations

 Security issues are not discussed in detail in this document.  The
 meter's management and collection protocols are responsible for
 providing sufficient data integrity and confidentiality.

11 Authors' Addresses

 Nevil Brownlee
 Information Technology Systems & Services
 The University of Auckland
 Phone: +64 9 373 7599 x8941
 EMail: n.brownlee @auckland.ac.nz
 Cyndi Mills
 BBN Systems and Technologies
 Phone: +1 617 873 4143
 EMail: cmills@bbn.com
 Greg Ruth
 GTE Laboratories, Inc
 Phone: +1 617 466 2448
 EMail: gruth@gte.com

Brownlee, et. al. Experimental [Page 37]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2063.txt · Last modified: 1996/12/31 17:48 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki