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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
