rfc2722.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,433 行 · 第 1/5 页
TXT
1,433 行
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.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?