Hi Thomas,
On 10/06/14 01:41, Thomas Graf wrote:
On 10/02/14 at 03:45pm, Franck Baudin wrote:
Good idea! This should be enough for, to reuse Justin's denomination, a
"limited L7 matching": protocols like DNS, Skype or BitTorrent cannot be
recognized with regex only.
How to you foresee the OF matcher definition? Would you go for a "regexp"
syntax, or a generic denomination permitting the usage of different
L7-classifier, for instance:
in_port=5,regex="GET "
versus something like "engine-name:engine-match"
in_port=5,l7=textsearch:"GET "
In the second way, several L7-classifier could be used (in addition or in
replacement), without any OF matcher modification, as l7=XXX match or
doesn't match. The expressiveness/richness of XXX is L7-classifier
dependent. And depending of the traffic, one L7-classifier could be a better
fit like another one, for instance an L7-classifier dedicated to protocols
over HTTP. Also, several L7-classifier could be used at the same time.
I would definitely prefer specifying the search algo with the pattern
as many uses will not require an expensive state machine search but
can use optimized text search algorithms. That said, this needs a lot
more discussion as this is a serious expansion of the scope of a flow
key.
One non intrusive way to extend the flow key is to run the regex before
the key lookup, and to extend the flow key with the result and not the
regex itself. For instance, the regex result is a 32 bits, encoding the
list of the matching regex.
It's like loading the skb->mark (already part of the flow key) with a
value reflecting the matching result. This is very simple from an
implementation perspective at the flow table level.
Best Regards,
Franck
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
