Skip to content

Project Ideas

Jump to bottom Edit New page
Arpit Gupta edited this page Mar 11, 2015 · 2 revisions

#Project Ideas: Software Defined Internet Exchange Point

Mentors

Overview

We are developing the software platform for SDN-enabled IXPs (SDX), which enables more expressive policies than conventional hop-by-hop, destination-based forwarding. Deploying software defined networking (SDN) at Internet exchange points (IXPs) offers new hope for solving long standing problems in interdomain routing. SDN allows direct expression of more flexible policies, and IXPs are central rendezvous points that are in the midst of a rebirth, making them a natural place to start. At the SDX, the participants can apply many diverse actions on packets based on multiple header fields, and distant networks can exercise “remote control” over packet handling. This flexibility enables applications such as inbound traffic engineering, redirection of traffic to middleboxes, wide-area server load balancing, and blocking of unwanted traffic. Supporting these applications requires effective ways to combine the policies of multiple ISPs.

We have developed an SDX controller that provides each ISP the abstraction of its own virtual switch and sequentially composes the policies of different ISPs into a single set of rules in the physical switches. It comprises a set of participant applications running on a runtime system built on top of Pyretic, as shown in figure below. The SDX runtime abstracts the details of the IXP from the participant ASes, who write applications based on their own view of the logical topology. The SDX runtime also composes distinct AS policies using sequential (“>>”) and parallel (“+”) composition operators; it also ensures that participants’ policies do not interfere or conflict with one another. The SDX controller can incorporate auxiliary information such as resource public key infrastructure (RPKI) records, route server information, and so forth to enable routing decisions that are based on a richer set of information than today’s BGP-based routing.

More Background:

Project Ideas

SDX Codebase

Migration of SDX Controller code to Frenetic codebase:

Currently, the SDX controller implementation is based on Pyretic (a domain-specific language for writing SDN policies that is embedded in Python). We plan to migrate the SDX codebase to Frenetic, which has recently been upgraded to compile policies more efficiently than Pyretic. As part of GSOC, a student can chose to pursue this migration task. This code migration involves updating the policy expression and composition modules of the SDX codebase to use Frenetic.

  • Mentor: Arpit Gupta
  • Difficulty: medium/hard
  • Programming languages: Python
  • Recommended reading:
    1. Frenetic
    2. SDX Codebase

Scalable Route Server Software:

Currently the route server module for the SDX controller is based on exaBGP. The route server provides the SDX with information about the incoming route advertisements to the SDX controller and also assigns virtual next hops to outgoing BGP route advertisements (to neighboring networks). For production networks, the SDX controller will a require a route server that scales to hundreds of thousands of routes advertised at IXPs. Route servers based on BIRD scale well; various IXPs around the world use BIRD as their route server implementation. As part of GSOC, a student could integrate a BIRD-based route server implementation with the SDX controller.

  • Mentor: Laurent Vanbever
  • Difficulty: medium/hard
  • Programming languages: Python and C
  • Recommended reading:
    1. BIRD
    2. ExaBGP
    3. SDX Codebase

Multi-switch support:

Currently, the Pyretic-based SDX controller works for a single IXP switch; in practice, however, IXPs (especially the large ones) use multiple switches. The SDX should not only support multiple switches but also use multiple flow tables to minimize the total number of flow rules. As part of GSOC, a student could modify the SDX controller to work with multiple distributed switches at a single IXP and could also explore optimizing the number of flow rules in a distributed SDX by leveraging multiple switches at the IXPs..

  • Mentor: Laurent Vanbever & Arpit Gupta
  • Difficulty: medium
  • Programming languages: Python
  • Recommended reading:
    1. Frenetic
    2. SDX Codebase

SDX Applications

Congestion and Resource Management at SDX:

Certain access ISPs are currently interested in congestion management problems using SDX, such as how to make sure traffic from (say) Netflix is sufficiently isolated, performance-wise, so that it doesn’t clobber the other traffic on ports. One possible solution to this problem is to dedicate virtual ports for each participant at the IXP and apply traffic shaping on those ports. One challenge is to make sure that this virtual-port based solution scales in terms of number of flow rules and compilation time. As part of GSOC, a student could explore the congestion and resource management problem at the SDX and eventually implement the virtual-port based solution for it.

  • Mentor: Nick Feamster & Arpit Gupta
  • Difficulty: medium
  • Programming languages: Python
  • Recommended reading:
    1. SDX Codebase

DDoS attack mitigation at SDX:

DDoS attacks are prevalent in the Internet. When a service is under a DDoS attack, it is often debilitated. Such a practice risks unavailability, loss of revenue and reputation, and even legal claims for undelivered services. We need more proactive solutions to DDoS defense. The SDX can play an important role in blocking the attack traffic upstream before it enters the victim’s network. Such a solution requires (1) developing a traffic monitoring module which triggers identification of such attacks; (2) identifying the most specific attack traffic to ensure that we only block the attack traffic; (3) applying an authorization framework to commandeer the attack traffic on behalf of victim’s network, which might permit authorization to either drop or redirect to traffic scrubbers, the attack traffic destined to victim’s network. As part of GSOC, a student could explore the DDoS attack mitigation problem at SDX.

Wide-area server load balancing at SDX:

Content providers balance client requests across clusters of servers by manipulating the domain name system (DNS). Each service has a single domain name (e.g., http: //www.example.com/) that resolves to multiple IP addresses for different backend servers. When a client’s local DNS server issues a DNS request, the service’s authoritative DNS server returns an IP address that appropriately balances load. Unfortunately, using DNS for server selection has several limitations. Instead, a content provider could assign a single anycast IP address for a service and rewrite the destination addresses of client requests in the middle of the network (e.g., at exchange points). SDX controller could announce anycast prefixes and rewrite the destination IP address to match the chosen hosting location based on any fields in the packet header. As part of GSOC, a student could explore the problem of wide-area server load balancing with SDX and port Niagara load balancer to SDX.

SDX Deployments

SDX over different hardware switches:

We have been experimenting using SDX controller to control different hardware switches. We want to continue this exploration to (1) identify switches best suited to SDX’s requirements, (2) benchmark performance of various SDX applications over different hardware switches, and (3) create stress tests for various SDX applications over physical switches, in addition to existing software switches such as Open vSwitch.

  • Mentor: Russ Clark
  • Difficulty: medium
  • Programming languages: Python
  • Recommended reading:
    1. SDX Codebase
Add a custom footer
Add a custom sidebar
Clone this wiki locally