Refactor Into Plugin Architecture

[craig-riecke]

In the current version of Frenetic, there's too much coupling between the internals and OpenFlow 1.0. Introduce a plugin module type into Frenetic_NetKAT_Controller, and make the Frenetic_OpenFlow0x01_Controller fit the new plugin architecture. This paves the way for an easier transition to OpenFlow 1.3, P4, etc. by making the main internals protocol-independent.

All of the code in the Frenetic Programmers Manual has been tested against the refactoring, and works as advertised.

The following are changes in behavior or functionality, which may or may not be solved in this release:

• There was a way for the HTTP controller to twiddle compiler settings like optimization and field order. This is defunct in the current release.
• Stat buckets (a/k/a queries) used to be carried over so aggregate stats used to be kept from the time the switch started. The current version only gets stats collected since the last time the flows were installed.
• In Ox, events (switch-to-controller messages) are only those that Frenetic itself passes on: PortUp, PortDown, etc. Events like Barrier Responses, Echo Replies, etc. are dropped. All OpenFlow 1.0 commands (controller-to-switch messages), on the other hand, can still be sent with full generality.
• Sending /query/name where name was not specified in the latest installed NetKAT policy used to generate an error. Now Frenetic simply sends back 0's.

[craig-riecke]

The failing checks are caused by a breaking change in OcamlGraph that was released 13 days ago on OPAM. I'm tempted to pin the version back because the breakage is in Frenetic_Network, which is not used by Frenetic proper.

[smolkaj]

@craig-riecke: See #513

[craig-riecke]

I would rather not wait for all the above questions to be answered before merging, since I'm going to be gone in 4 days and I don't want Issue #507 or Pull Request #517 to be held up.

I added Compiler Option setting to plugin signatures, since this is required for the Gates SDN app (http://github.com/coscin/gates) to work. The others are not critical, as far as I know.

[jnfoster]

Hi Craig, this seems cool, but it's not clear to me how to use this for multiple backends. The Frenetic_NetKAT_Controller.ml seems to have a lot of hardcoded references to OF10 and the Make module isn't a functor. Similarly, Frenetic_OpenFlow0x01_Controller.ml doesn't have any references to Frenetic_NetKAT_Controller.ml. I would have expected there to be a PLUGIN signature that specifies what a back-end needs to provide and a Controller.Make functor that produces a controller using that plugin.

Huh? This is the whole point. There are now no references to OpenFlow0x01 in Frenetic_NetKAT_Controller.

https://github.com/frenetic-lang/frenetic/blob/b480ade5cb8e57707a46c7aeddd9e8710289b464/async/Frenetic_NetKAT_Controller.ml

[basus]

I was looking at the master branch instead of the plugin branch.

On Wed, Jul 20, 2016 at 10:35 PM, Nate Foster [email protected]
wrote:

Hi Craig, this seems cool, but it's not clear to me how to use this for
multiple backends. The Frenetic_NetKAT_Controller.ml seems to have a lot of
hardcoded references to OF10 and the Make module isn't a functor.
Similarly, Frenetic_OpenFlow0x01_Controller.ml doesn't have any references
to Frenetic_NetKAT_Controller.ml. I would have expected there to be a
PLUGIN signature that specifies what a back-end needs to provide and a
Controller.Make functor that produces a controller using that plugin.

Huh? This is the whole point. There are now no references to
OpenFlow0x01 in Frenetic_NetKAT_Controller.

https://github.com/frenetic-lang/frenetic/blob/b480ade5cb8e57707a46c7aeddd9e8710289b464/async/Frenetic_NetKAT_Controller.ml

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#512 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFi-F2ijLlyCyctSIp00nB6d8jpUCbFks5qXtsJgaJpZM4JJjOH
.

Shrutarshi Basu
Basus.me
The ByteBaker http://bytebaker.com

[basus]

Is there a straightforward way to extend this upwards? For an interesting P4 backend you would want to have custom actions (eg., encapsulate, modify outer header, insert some custom header). One way to currently do this is sticking information into the string argument of a Pipe location, but that's deeply unsatisfying for obvious reasons.