summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2722.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2722.txt')
-rw-r--r--doc/rfc/rfc2722.txt2691
1 files changed, 2691 insertions, 0 deletions
diff --git a/doc/rfc/rfc2722.txt b/doc/rfc/rfc2722.txt
new file mode 100644
index 0000000..2a76fa5
--- /dev/null
+++ b/doc/rfc/rfc2722.txt
@@ -0,0 +1,2691 @@
+
+
+
+
+
+
+Network Working Group N. Brownlee
+Request for Comments: 2722 The University of Auckland
+Obsoletes: 2063 C. Mills
+Category: Informational GTE Laboratories, Inc
+ G. Ruth
+ GTE Internetworking
+ October 1999
+
+
+ Traffic Flow Measurement: Architecture
+
+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
+ 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
+
+ 2 Traffic Flow Measurement Architecture 5
+ 2.1 Meters and Traffic Flows . . . . . . . . . . . . . . . . . 5
+ 2.2 Interaction Between METER and METER READER . . . . . . . . 7
+ 2.3 Interaction Between MANAGER and METER . . . . . . . . . . 7
+ 2.4 Interaction Between MANAGER and METER READER . . . . . . . 8
+ 2.5 Multiple METERs or METER READERs . . . . . . . . . . . . . 9
+ 2.6 Interaction Between MANAGERs (MANAGER - MANAGER) . . . . . 10
+ 2.7 METER READERs and APPLICATIONs . . . . . . . . . . . . . . 10
+
+ 3 Traffic Flows and Reporting Granularity 10
+ 3.1 Flows and their Attributes . . . . . . . . . . . . . . . . 10
+ 3.2 Granularity of Flow Measurements . . . . . . . . . . . . . 13
+ 3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only . 15
+
+
+
+
+Brownlee, et al. Informational [Page 1]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 4 Meters 17
+ 4.1 Meter Structure . . . . . . . . . . . . . . . . . . . . . 17
+ 4.2 Flow Table . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 4.3 Packet Handling, Packet Matching . . . . . . . . . . . . . 20
+ 4.4 Rules and Rule Sets . . . . . . . . . . . . . . . . . . . 23
+ 4.5 Maintaining the Flow Table . . . . . . . . . . . . . . . . 28
+ 4.6 Handling Increasing Traffic Levels . . . . . . . . . . . . 29
+
+ 5 Meter Readers 30
+ 5.1 Identifying Flows in Flow Records . . . . . . . . . . . . 30
+ 5.2 Usage Records, Flow Data Files . . . . . . . . . . . . . . 30
+ 5.3 Meter to Meter Reader: Usage Record Transmission . . . . 31
+
+ 6 Managers 32
+ 6.1 Between Manager and Meter: Control Functions . . . . . . 32
+ 6.2 Between Manager and Meter Reader: Control Functions . . . 33
+ 6.3 Exception Conditions . . . . . . . . . . . . . . . . . . . 35
+ 6.4 Standard Rule Sets . . . . . . . . . . . . . . . . . . . . 36
+
+ 7 Security Considerations 36
+ 7.1 Threat Analysis . . . . . . . . . . . . . . . . . . . . . 36
+ 7.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . 37
+
+ 8 IANA Considerations 39
+ 8.1 PME Opcodes . . . . . . . . . . . . . . . . . . . . . . . 39
+ 8.2 RTFM Attributes . . . . . . . . . . . . . . . . . . . . . 39
+
+ 9 APPENDICES 41
+ Appendix A: Network Characterisation . . . . . . . . . . . . . 41
+ Appendix B: Recommended Traffic Flow Measurement Capabilities . 42
+ Appendix C: List of Defined Flow Attributes . . . . . . . . . . 43
+ Appendix D: List of Meter Control Variables . . . . . . . . . . 44
+ Appendix E: Changes Introduced Since RFC 2063 . . . . . . . . . 45
+
+ 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 45
+ 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
+ 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 47
+ 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 48
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brownlee, et al. Informational [Page 2]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+1 Statement of Purpose and Scope
+
+1.1 Introduction
+
+ 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.
+
+
+
+Brownlee, et al. Informational [Page 3]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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 [RTFM-NEW].
+
+ 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 [ACT-BKG].
+
+
+
+
+
+
+
+
+Brownlee, et al. Informational [Page 4]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+2 Traffic Flow Measurement Architecture
+
+ 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 section
+ 1 (above).
+
+ The following sections outline a model for traffic flow measurement,
+ which draws from working drafts of the OSI accounting model [OSI-
+ ACT].
+
+2.1 Meters and Traffic Flows
+
+ 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 [ACT-BKG]. 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
+
+
+
+Brownlee, et al. Informational [Page 5]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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 <-----> METER READER <-----> 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.
+
+
+
+
+
+
+
+Brownlee, et al. Informational [Page 6]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ - 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.
+
+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. 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).
+
+
+
+
+
+Brownlee, et al. Informational [Page 7]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ - 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.
+
+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 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.
+
+
+
+
+
+Brownlee, et al. Informational [Page 8]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+2.5 Multiple METERs or METER READERs
+
+ -- 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
+
+
+
+Brownlee, et al. Informational [Page 9]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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.
+
+ 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 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.
+
+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:
+
+
+
+
+Brownlee, et al. Informational [Page 10]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ - 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 section 8 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.
+
+
+
+
+
+
+Brownlee, et al. Informational [Page 11]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ For example, if flow measurement is being performed using IP as
+ the network layer on an Ethernet LAN [802-3], 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 [ACT-BKG]. 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.
+
+
+
+
+Brownlee, et al. Informational [Page 12]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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.
+
+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 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
+
+
+
+
+Brownlee, et al. Informational [Page 13]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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.
+
+
+
+
+
+Brownlee, et al. Informational [Page 14]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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 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.
+
+
+
+Brownlee, et al. Informational [Page 15]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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 & 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.
+
+ 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.
+
+
+
+
+
+Brownlee, et al. Informational [Page 16]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ Bucket 2: Packets which were sourced by IP address a.b.c.d;
+ counted by rule set B.
+
+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:
+
+ - 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.
+
+4.1 Meter Structure
+
+ 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 section 4.3 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.
+
+
+
+
+Brownlee, et al. Informational [Page 17]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ - 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 |---------------->| Packet |
+ | Processor | | Matching |
+ | |<----------------| 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
+
+
+
+
+Brownlee, et al. Informational [Page 18]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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
+ section 3.3 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.
+
+4.2 Flow Table
+
+ 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 section 4.5 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.
+
+
+
+
+
+
+
+
+
+
+Brownlee, et al. Informational [Page 19]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+4.3 Packet Handling, Packet Matching
+
+ 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.
+
+
+
+
+
+
+Brownlee, et al. Informational [Page 20]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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->z, the meter must
+ check that flow z->y is not already current before creating y->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->D) -------------------------------------------------+
+ | Suc | NoMatch |
+ | | Ignore |
+ | match(D->S) -----------------------------------------+
+ | | Suc | NoMatch |
+ | | | |
+ | | +-------------------------------------------+
+ | | |
+ | | 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) --------------+
+ |
+ *
+
+
+
+
+Brownlee, et al. Informational [Page 21]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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.
+
+ '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->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).
+
+ 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 [RTFM-SRL]. Another approach would be
+ to write a 'rule set consistency checker' program, which could detect
+ problems in hand-written rule sets.
+
+
+
+
+Brownlee, et al. Informational [Page 22]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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->D direction, the NoMatch action will
+ cause it to be retried. If it fails in the D->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->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.
+
+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.
+
+ 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 & mask = value: opcode, parameter;
+
+
+
+
+Brownlee, et al. Informational [Page 23]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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.
+
+
+
+Brownlee, et al. Informational [Page 24]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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.
+
+
+
+
+Brownlee, et al. Informational [Page 25]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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.
+
+
+
+
+
+
+
+Brownlee, et al. Informational [Page 26]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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.
+
+
+
+
+Brownlee, et al. Informational [Page 27]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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 section 8 below.
+
+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 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.
+
+
+
+
+Brownlee, et al. Informational [Page 28]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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.
+
+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,
+ 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.
+
+
+
+
+Brownlee, et al. Informational [Page 29]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+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 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.
+
+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 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.
+
+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.
+
+
+
+
+
+
+
+
+Brownlee, et al. Informational [Page 30]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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 [RTFM-NEW].
+
+ 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 (& 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 and idle flows). One possible
+ method of achieving this transfer is to use SNMP; the 'Traffic Flow
+ Measurement: Meter MIB' RFC [RTFM-MIB] 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.
+
+
+
+
+Brownlee, et al. Informational [Page 31]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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.
+
+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
+
+ - 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
+
+
+
+Brownlee, et al. Informational [Page 32]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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.
+
+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
+ 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
+
+
+
+Brownlee, et al. Informational [Page 33]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+Brownlee, et al. Informational [Page 34]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ - 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.
+
+6.3 Exception Conditions
+
+ 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.
+
+
+
+
+
+
+
+Brownlee, et al. Informational [Page 35]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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.
+
+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:
+
+ - 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.
+
+7 Security Considerations
+
+7.1 Threat Analysis
+
+ 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
+
+
+
+
+Brownlee, et al. Informational [Page 36]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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.
+
+7.2 Countermeasures
+
+ 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.
+
+
+
+
+
+Brownlee, et al. Informational [Page 37]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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
+ Section 2.5). 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.
+
+
+
+
+
+
+Brownlee, et al. Informational [Page 38]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ - 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.
+
+8 IANA Considerations
+
+ 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 [IANA-RFC].
+
+8.1 PME Opcodes
+
+ 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
+ section 4.4 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 [IANA-RFC].
+
+ 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.
+
+8.2 RTFM Attributes
+
+ Attribute numbers in the range of 0-511 are globally unique and are
+ allocated according to an IETF Consensus action [IANA-RFC]. Appendix
+ C 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 [IANA-RFC].
+ Vendors requiring attribute numbers should submit a request to IANA
+ giving the attribute names: IANA will allocate them the next
+ available numbers.
+
+
+
+
+
+Brownlee, et al. Informational [Page 39]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ Attribute numbers 1024 and higher are Reserved for Private Use
+ [IANA-RFC]. 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 [RTFM-MIB]. 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
+ [RTFM-SRL]).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brownlee, et al. Informational [Page 40]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+9 APPENDICES
+
+9.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
+ in the traffic flow measurement record may carry system-specific
+
+
+
+Brownlee, et al. Informational [Page 41]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 'user identification' labels so that meters can implement proprietary
+ or non-standard schemes for the attribution of network traffic to
+ responsible parties.
+
+9.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 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. Informational [Page 42]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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.
+
+9.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.
+
+ Note that this table gives only a very brief summary. The Meter MIB
+ [RTFM-MIB] 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
+
+
+
+
+
+Brownlee, et al. Informational [Page 43]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+ 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
+
+9.4 Appendix D: List of Meter Control Variables
+
+ 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
+
+
+
+
+
+
+
+Brownlee, et al. Informational [Page 44]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+9.5 Appendix E: Changes Introduced Since RFC 2063
+
+ The first version of the Traffic Flow Measurement Architecture was
+ published as RFC 2063 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.
+
+10 Acknowledgments
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+Brownlee, et al. Informational [Page 45]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+11 References
+
+ [802-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.
+
+ [ACT-BKG] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting
+ Background", RFC 1272, November 1991.
+
+ [IANA-RFC] Alvestrand, H. and T. Narten, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [IPPM-FRM] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis,
+ "Framework for IP Performance Metrics", RFC 2330, May
+ 1998.
+
+ [OSI-ACT] International Standards Organisation (ISO), "Management
+ Framework", Part 4 of Information Processing Systems Open
+ Systems Interconnection Basic Reference Model, ISO 7498-4,
+ 1994.
+
+ [RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC
+ 2720, October 1999.
+
+ [RTFM-NEW] Handelman, S., Stibler, S., Brownlee, N. and G. Ruth,
+ "RTFM: New Attributes for Traffic Flow Measurment", RFC
+ 2724, October 1999.
+
+ [RTFM-SRL] Brownlee, N., "SRL: A Language for Describing Traffic
+ Flows and Specifying Actions for Flow Groups", RFC 2723,
+ October 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brownlee, et al. Informational [Page 46]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+12 Authors' Addresses
+
+ Nevil Brownlee
+ Information Technology Systems & 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brownlee, et al. Informational [Page 47]
+
+RFC 2722 Traffic Flow Measurement: Architecture October 1999
+
+
+13 Full Copyright Statement
+
+ 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]
+