[ovs-discuss] [ovs-dev] Passive openflow proxy

[Xiao Liang]

Hi Ben and Bill,

Thanks for your reply.

Controller-to-switch messages can be handled by maintaining a cache of
outstanding xid mappings.
Controller state and async messages handling is a problem. I think the
proxy can maintain an internal state for each controller, remain
ROLE_EQUAL to switches, and SET_ASYNC to the OR-ed value of all
controllers.
I'm going to post a patch of prototype that handles
controller-to-switch messages.

Thanks,
Xiao

On Fri, Mar 9, 2018 at 3:38 AM, William Fisher
<william.w.fisher at gmail.com> wrote:
> Hi Xiao,
>
> You are proposing an OpenFlow proxy that passively accepts connections from
> OF switches, and feeds them upwards to multiple active/passive controller
> clients C1 and C2.  You want to use ovs-ofctl as one of these clients.
> ovs-ofctl would make an active connection to the proxy to get access to one
> of several existing OF control connections. Please let me know if my summary
> is incorrect.

Yes, that's correct.

>
> A couple of issues:
>
> 1. How does ovs-ofctl tell the proxy which datapath_id it is interested in?

The proxy can open a socket on behalf of each switch, identified by
switch connection endpoint or datapath_id.

> 2. xid's need to be virtualized.
>
> If client C1 issues a FLOW_STATS request with xid 1, the reply should go to
> C1 only.  This may require that the proxy re-maps xid's to a different
> number when sent to the real OF connection.
>
> 3. If a client issues a read-write OF command (e.g. SET_ASYNC), it is
> understood that this changes the datapath state for all clients.
>
> Are there any other issues or situations that such a tool would need to
> handle?
>
> Regards,
> -Bill
>
>
>
>
> On Thu, Mar 8, 2018 at 10:30 AM Ben Pfaff <blp at ovn.org> wrote:
>>
>> On Thu, Mar 08, 2018 at 07:51:23PM +0800, Xiao Liang wrote:
>> > In my experience, one thing I feel inconvenient is that some switches
>> > don't support controller-initiated connections. It would be helpful
>> > for testing and debugging if ovs-ofctl could be used.
>> > I'd propose an openflow proxy which is responsible for accepting and
>> > maintaining connections from switches, opening sockets for controllers
>> > to connect, and proxy messages between them. So that openflow tools
>> > like ovs-ofctl can operate on these switches.
>> > Another approach might be adding a "passive mode" to ovs-ofctl, which
>> > listens for connections, and opens an interactive shell to run
>> > commands.
>>
>> I guess that this is a problem with non-OVS switches?  OVS does support
>> controller-initiated connections.
>>

Yes, mainly for non-OVS switches.

>> The proxy that you describe is going to be difficult to write because to
>> be most useful it would have to multiplex multiple connections into a
>> single connection.  OpenFlow connections are not stateless, so it would
>> have to figure out how to effectively partition the desires of multiple
>> clients into a single session.  I haven't thought through all the
>> necessary logic, but it would not be trivial.
>>
>> I think that the ovs-ofctl passive mode that you describe is similar in
>> practice to writing a proxy: probably, it would internally start a proxy
>> and then allow the user to access it.  It might be easiest to actually
>> implement it as a mode for the proxy that starts a subshell.
>>
>> I think that this is a worthy project, for someone for whom support for
>> non-OVS switches is important, and I'd encourage a motivated developer
>> to work on it.
>> _______________________________________________
>> discuss mailing list
>> discuss at openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss