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