From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2722.txt | 2691 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2691 insertions(+) create mode 100644 doc/rfc/rfc2722.txt (limited to 'doc/rfc/rfc2722.txt') 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] + -- cgit v1.2.3