-
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
Using Frenetic requires writing code and getting exposed to low-level details. For certain tasks, it would be far more convenient to use a GUI that allows to carry out common operations such as defining the network access policy, or establishing the shortest path between 2 nodes.
This project consists of implementing a GUI for Frenetic. This should be implemented as a modern, reactive Web-based application. The GUI could implemented several possible features but at its basics it should provide (1) a view of the network map, (2) the ability to inspect the flowtable state, (3) a visualization of the policy, and (4) the ability to update the policy through the interface. The student could consider the ONOS Web interface for inspiration.
- Mentor: Nate Foster or Marco Canini
- Difficulty: easy
- Programming languages: OCaml and JavaScript for the interface
- Recommended reading:
- NetKAT: Semantic Foundations for Networks. In Symposium on Principles of Programming Languages (POPL), 2014
Frenetic is a very powerful framework for creating SDN controllers but there are only a few example applications that demonstrate the capabilities of the framework. The GSoC student could consider writing 2 or more example applications and integrate them within the Frenetic tutorial.
Example applications include:
- Load balancer
- Stateful firewall
- Compact routing
- ECMP
- Fault-tolerant forwarding
- Mentor: Nate Foster or Marco Canini
- Difficulty: medium
- Programming languages: OCaml
- Recommended reading:
- NetKAT: Semantic Foundations for Networks. In Symposium on Principles of Programming Languages (POPL), 2014
MacOS X doesn't have a viable OpenFlow implementation currently, but (as of 10.10 Yosemite) it does have the vmnet
user-level network bridging framework included as part of the base distribution. The goal of this project would be to port a minimal OpenFlow switch and controller such that it runs on MacOS X via a virtual vmnet
interface.
- There exist OCaml bindings to
vmnet
at https://github.com/mirage/ocaml-vmnet - An OpenFlow switch needs to be written that uses the
vmnet
layer to forward Ethernet frames. - The Frenetic controller is written in OCaml, which may need minor porting to OSX for configuration purposes.
- Mentor: Anil Madhavapeddy
- Difficulty: medium
- Programming languages: OCaml