Lines Matching full:flow
5 flow-level packet processing on selected network devices. It can be
7 VLAN processing, network access control, flow-based network control,
12 within a bridge). Each datapath also has associated with it a "flow
19 extracting its flow key and looking it up in the flow table. If there
20 is a matching flow, it executes the associated actions. If there is
22 its processing, userspace will likely set up a flow to handle further
26 Flow key compatibility
32 versions to parse additional protocols as part of the flow key. It
36 applications to work with any version of the flow key, past or future.
40 flow key that it parsed from the packet. Userspace then extracts its
41 own notion of a flow key from the packet and compares it against the
44 - If userspace's notion of the flow key for the packet matches the
47 - If the kernel's flow key includes more fields than the userspace
48 version of the flow key, for example if the kernel decoded IPv6
51 necessary. Userspace can still set up a flow in the usual way,
52 as long as it uses the kernel-provided flow key to do it.
54 - If the userspace flow key includes more fields than the
57 forward the packet manually, without setting up a flow in the
59 that the kernel considers part of the flow must go to userspace,
62 forwarding behavior, then it could set up a flow anyway.)
64 How flow keys evolve over time is important to making this work, so
68 Flow key format
71 A flow key is passed over a Netlink socket as a sequence of Netlink
80 flow key attributes. For informal explanatory purposes here, we write
82 and nesting. For example, the following could represent a flow key
94 Wildcarded flow key format
97 A wildcarded flow is described with two sequences of Netlink attributes
98 passed over the Netlink socket. A flow key, exactly as described above, and an
99 optional corresponding flow mask.
101 A wildcarded flow can represent a group of exact match flows. Each '1' bit
102 in the mask specifies a exact match with the corresponding bit in the flow key.
104 of a incoming packet. Using wildcarded flow can improve the flow set up rate
109 match flow, or reduce the number of don't care bits in the kernel to less than
111 that the kernel does not implement will simply result in additional flow setups.
113 nor supply flow mask attributes.
118 flow table (and therefore not attempt to determine wildcard changes at all)
123 identify the flow for all future operations. However, when reporting the
124 mask of an installed flow, the mask should include any restrictions imposed
129 can match at most one flow, wildcarded or not. The current implementation
134 Unique flow identifiers
138 flow identification is a unique flow identifier, or "UFID". UFIDs are optional
141 User space programs that support UFID are expected to provide it during flow
142 setup in addition to the flow, then refer to the flow using the UFID for all
144 flow key if a UFID is specified.
147 Basic rule for evolving flow keys
152 "Flow key compatibility" above.
157 New network protocol support must only supplement existing flow
159 flow key attributes.
166 packet. The flow key for any packet with an 802.1Q header would look
171 Naively, to add VLAN support, it makes sense to add a new "vlan" flow
175 flow key much like this:
180 has not been updated to understand the new "vlan" flow key attribute.
181 The application could, following the flow compatibility rules above,
183 assume that the flow contained IP packets. This is a bad assumption
184 (the flow only contains IP packets if one parses and skips over the
195 Notice how the "eth_type", "ip", and "tcp" flow key attributes are
216 header, so that the TCP header is missing. The flow key for this
224 after the Ethernet type. The flow key for this packet would include
233 Thus, the flow key in this second example unambiguously indicates a
239 The other rules for flow keys are much less subtle:
245 - When the kernel sends a given flow key to userspace, it always
247 compare entire flow keys that it may not be able to fully