googlesoc2016 projects

Overview:

IPOP is an open-source user-centric software virtual network allowing end users to define and create their own virtual private networks (VPNs). IPOP virtual networks provide end-to-end IP tunneling over “TinCan” links setup and managed through a control API to create various software-defined VPN overlays. IPOP builds upon the Jingle WebRTC library to create such links, which are then use as a basis to create a P2P routing overlay for easy-to-deploy VPNs with P2P links.

The IPOP project had a very successful participation in GSoC 2015, and we are looking forward to working with bright, motivated students for another summer.

One of the key outcomes of the GSoC'15 was a complete overhaul of the IPOP ``controller'' framework, where the logic related to configuration, creation, management of P2P VPN links, overlay construction and routing, virtual network address assignment/mapping, among others, is implemented (in Python). This is now part of the release 16.01 of the IPOP codebase.

The GSoC'16 projects fall largely into the category of design of useful modules that can plug into this new framework. These modules have different levels of complexity/expected coding time, but it is expected that a GSoC student will be able to take on several modules. These include:

1) Overlay multicast and routing modules

Summary: IPOP virtual networks form overlays connecting nodes in a peer-to-peer fashion with libjingle-based tunnels. For scalability reasons, it is necessary to allow routing across multiple overlay ``hops'' - in particular, for multicast messages (e.g. the ARP protocol when IPOP is configured to run in Layer-2 mode). IPOP needs to be extended with modules to support multicasting - with possibly different multicasting approaches tailored to different overlay topologies

Requirements: The overlay multicast modules needs to implement the following primitives:

Core multicast module (CMM)

• The CMM is implemented as a module loaded to the IPOP controller framework
• The CMM takes as inputs a unique message ID, a payload, a list of neighbors to deliver to, and the name of a destination multicast module (DMM) to deliver to handle multicast messages
• The CMM sends messages to the CMM modules of immediate-neighbor IPOP nodes, using Inter-Controller Communication (ICC), where they are delivered to the DMM

Structured multicast module (SMM)

• SMM multicasts messages across a structured P2P overlay network (e.g. Chord topology)
• SMM is implemented as a module loaded to the IPOP controller framework
• The SMM module takes as inputs a unique message ID, a payload, and a range of UUIDs of nodes to deliver to
• The SMM module partitions the range of the UUIDs it receives across n' sub-ranges, one for each of its n' neighbors, and uses CMM to forward multicast messages to each neighbor with each appropriate sub-range

Token-limited flooding module (TLFM)

• TLFM multicasts messages across an arbitrary P2P overlay network (e.g. social network graph)
• TLFM is implemented as a module loaded to the IPOP controller framework
• The TLFM module takes as inputs a unique message ID, a payload, and a a number of tokens
• The TLFM module records processing of this message ID, selects k<=n' out of its n' neighbors, and uses CMM to forward multicast messages to each `k' neighbor

Source-routed path discovery module (SPDM)

• SPDM uses multicast messages to discover intermediary nodes in a path between a source and a destination
• SPDM is used as a basis for implemented source-based routing for unstructured overlays
• SPDM uses TMM to token-limited flood a message with the destination node's UUID

Mentor:
Saumitra Aditya

Skills needed:
Strong command over Python, basic understanding of computer networks and software design.

Deliverables:
Various IPOP controller modules, encompassing above listed requirements.