[ovs-discuss] Port range matching

Ben Pfaff blp at nicira.com
Fri Aug 5 16:15:46 UTC 2011


On Fri, Aug 05, 2011 at 01:31:08PM +0100, Mike Bursell wrote:
> Hi -
> 
> I'm investigating the possibility of adding port range matching to
> rules.  In other words, rather than just specifying a single tp_dst, you
> could add a range.  In other words:
> 
> tp_dst = 8080-8083
> would be equivalent to having four rules: with tp_dst 8080,8081,8082 &
> 8083. 
> 
> I'm not suggesting that we remove the existing support for a single
> port, of course.
> 
> I was wondering whether this has been discussed before?  It seems like a
> fairly obvious addition both to Open vSwitch and to OpenFlow.

It's been discussed (you will find a few relevant hits on Google for
"openflow port range matching") but to the best of my knowledge it has
never been developed into a proposal or implemented.

> Protocol changes would obviously be required.  We might, for example,
> adding the following fields to ofp_match:
> 
> uint16_t tp_src_end /* TCP/UDP/SCTP source port range end. */
> uint16_t tp_dst_end /* TCP/UDP/SCTP destination port range end. */

That only works if you are willing to break compatibility with
existing OpenFlow controllers and switches, because OpenFlow doesn't
provide a way to extend the ofp_match structure (it is fixed in
size).

In Open vSwitch, we have already defined protocol extensions that
allow for extending the match.  These extensions are, of course,
incompatible with switches and controllers that only speak OpenFlow
1.0, but they provide a framework that makes adding more types of
matching easier.  Port range matching could be easily added here.

Here is the description of the extensible match protocol:
	http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob;f=include/openflow/nicira-ext.h;h=5cf02e7c58a1b4fe6dac19b18c14104f503cbeee;hb=HEAD#l762

> Given these changes, my initial feeling is that it shouldn't be too
> difficult to add the matching to the vSwitch itself.  If the tp_*_end
> wasn't set, then we could safely ignore it matching time.

The biggest question in my mind is not how to formulate range matches
but how to efficiently integrate them into the classifier.  Do you
have thoughts on that?



More information about the discuss mailing list