2016 Technology Exchange

close
Use Internet2 SiteID

Already have an Internet2 SiteID?
Sign in here.

Internet2 SiteID

Your organization not listed? Create a local account to use Internet2 services.

Create SiteID

Challenges When Designing a Distributed SDX

Time 09/28/16 09:00AM-09:50AM

Room Brickell

Session Abstract

A Software-Defined Internet Exchange Point (SDX) is a new technology that has many, often conflicting definitions. We hope to cement the definition to refer to two specific aspects: first, a SDN-based dataplane that connects various networks together, and second, participant networks are able to define forwarding policy within the exchange point by way of a configuration API. With such an API, participants can make forwarding decisions based on more information than simply destination IP address, as is the case with traditional Internet Exchange Points (IXPs). Further, a Distributed SDX is a new style of SDX, wherein participant networks can connect to the SDX at multiple locations, to multiple switches, potentially owned and operated by multiple organizations.

Having a distributed SDX leads to a number of challenges. Having centralized control of a dataplane in a datacenter is reasonable, while having centralized control across states, or even countries leads to challenges with control distribution, recovery, latency of control signal propagation, in-band vs. out-of-band control, etc. Having different organizations manage different sites can lead to other challenges, including handling heterogeneous switching hardware with different capabilities. Finally, with different hardware, different control protocols are possible.

To these ends, Georgia Tech and Florida International University are creating a distributed SDX, spanning Atlanta, Miami, and São Paulo as part of the AtlanticWave/SDX IRNC project. Beyond the challenges associated with a distributed SDX, we have found two particular challenges that drive our research agenda. First is a lack of available 100Gb OpenFlow-controllable hardware that supports all OpenFlow 1.3 functionality on any match-action table. This provides the opportunity to discover what alternative network designs in order to provide better functionality to participants. Second is defining an API for participants to use, determining how much abstraction is necessary to mask any heterogeneity of hardware resources, while providing a level of functionality that is not present in traditional IXPs.

Speakers

Speaker Sean Donovan Georgia Institute of Technology

Speaker Jeronimo Bezerra Florida International University

Speaker Russ Clark Georgia Institute of Technology

Presentation Media

Speaker Jeronimo Bezerra Florida International University

Speaker Russ Clark Georgia Institute of Technology

Speaker Sean Donovan Georgia Institute of Technology

Primary track Research

Secondary tracks Advanced Networking

platinum Sponsors

gold Sponsors

silver Sponsors

supporter Sponsors