-
Notifications
You must be signed in to change notification settings - Fork 51
GSoC 2015 Project Ideas
Common background readings:
- Software-Defined Networking: The New Norm for Networks.
- Languages for software-defined networks. IEEE Communications Magazine, 51(2):128-134, 2013
The current Frenetic implementation has support for OpenFlow 1.0, 1.3 and 1.4. As part of the GSoC, a student could consider implementing an abstraction layer that allows a controller to make use of different versions of the OpenFlow protocols.
Ultimately this project boils down to designing and implementing an abstraction layer that hides the differences between different versions of OpenFlow and exposes a uniform low-level API to be used by the controller run-time, allowing switches speaking different versions to interoperate in the same network.
Another approach could be to adopt an existing C or C++ library that supports multiple versions of OpenFlow and Still, if an external library is adopted, it should be exported to OCaml by designing an API that is convenient to work with (read, similar to the existing OpenFlow 1.0 design).
Moreover, to simplify the interface upstream, one might consider designing an abstraction layer that hides the differences between different versions of OpenFlow and allows switches speaking different versions to interoperate in the same network.
- Mentor: Marco Canini or Arjun Guha
- Difficulty: medium
- Programming languages: OCaml
- Recommended reading:
- OpenFlow specs
- For inspiration, OpenFlow abstraction layers in other languages include libfluid and flowgrammable's OpenFlow library.
To write network programs for Frenetic, developers must currently use either the custom syntax exposed by the Frenetic binary, or an OCaml API. As part of the GSoC, a student could consider implementing new language bindings to integrate the power of Frenetic to other languages. A special type of "language bindings" proposal could also look into integrating Frenetic as the backend for a BGP implementation (e.g., bird).
Ultimately this project boils down to designing and implementing a wrapper of the Frenetic application API that exposes this API in another programming language. There are many possible ways to export the Frenetic API. One approach might be to expose the Frenetic API as a RESTful interface by an embedded HTTP server. Another approach might be to embed a language interpreter (e.g., Python or Ruby) into Frenetic itself. Another approach might be to use an RPC library such as Apache Thrift.
This project requires two main components to be developed, one in OCaml and one in the programming language for the bindings:
On the Frenetic side:
- Wrap the Frenetic API in component that can expose this API to an external language. Exposing the API can be done via one of several possible mechanisms as described above.
On the other language side:
- Determine a representation of the NetKAT abstract syntax tree that programmers can use to construct policies (as an example, consider how Pyretic embeds into Python a set of types that are closely related to the NetKAT types).
- Develop the component that interfaces with the Frenetic API
- Mentor: Arjun Guha or Marco Canini
- Difficulty: easy
- Programming languages: OCaml and another language for the bindings (e.g., Python, Ruby, etc.)
- Recommended reading:
- NetKAT: Semantic Foundations for Networks. In Symposium on Principles of Programming Languages (POPL), 2014