The presentation discussed software-defined internet exchange points (SDXs) and the iSDX platform. SDXs can help solve internet routing problems by offering more flexible traffic control and innovative services compared to traditional Border Gateway Protocol (BGP)-based internet exchanges. The iSDX project developed an industrial-scale SDX that can support the data plane performance and scalability required for a major internet exchange through optimization techniques. It is deployed via an open source software stack and several organizations are working to adopt iSDX in public internet exchanges and enterprise networks.
6. 6
1. Work closely with network operators to build complete deployable solutions
2. Where possible, adopt (and get behind) existing open-source components.
3. Where necessary, create, adapt or commission missing components.
4. Organize and orchestrate as one large open-source effort
5. Tools and infrastructure to commission quickly, collaborate freely, with
minimum upfront cost and maximum speed to solution (tools, licenses,
support, etc.)
Principles
Standards-based, reference SDN distributions, easy to
deploy and operate on ONF member hardware
Vision of ONF Open Source SDN
8. Call to Action
• Bring your requirements,
use cases, sign-up for
trials
• Integrate your switching
hardware, controller or apps.
• http://opensourcesdn.org/
8
9. iSDX: An Industrial-Scale
Software-Defined IXP
Nick Feamster
Arpit Gupta
Princeton University
http://sdx.cs.princeton.edu
Robert MacDavid, Rüdiger Birkner,
Marco Canini, Jennifer Rexford, Laurent Vanbever
10. The Interdomain Ecosystem is Evolving ...
10
Flatter and densely interconnected Internet*
*Labovitz et al., Internet Inter-Domain Traffic, SIGCOMM 2010
11. …But BGP is Not
• Routing only on destination IP prefixes
(No customization of routes by application, sender)
• Can only influence immediate neighbors
(No ability to affect path selection remotely)
• Indirect control over data-plane forwarding (Indirect mechanisms to
influence path selection)
11
How to overcome BGP’s limitations?
12. SDN for Interdomain Routing
• Forwarding on multiple header fields
(not just destination IP prefixes)
• Ability to control entire networks with a single software
program (not just immediate neighbors)
• Direct control over data-plane forwarding (not
indirect control via control-plane arcana)
12
How to incrementally deploy SDN for
Interdomain Routing?
13. Deploy SDN at Internet Exchanges
• Leverage: SDN deployment even at single IXP can yield benefits
for tens to hundreds of ISPs
• Innovation hotbed: Incentives to innovate as IXPs on front line of
peering disputes
• Growing in numbers: ~100 new IXPs established in past three
years*
13
*https://prefix.pch.net/applications/ixpdir/summary/growth/
14. “SDX: A Software-Defined Exchange Point”
(SIGCOMM 2014)
Arpit Gupta, Nick Feamster, Laurent Vanbever, Muhammad Shahbaz, Sean
Donovan, Brandon Schlinker, Scott Shenker, Russ Clark, Ethan Katz-Bassett
14
“An Industrial-scale Software Defined Internet
Exchange Point” (NSDI 2016)
Arpit Gupta, Robert MacDavid, Rudiger Birkner, Marco Canini, Nick
Feamster, Jennifer Rexford, Laurent Vanbever
http://sdx.cs.princeton.edu
15. Internet Exchange Points (IXPs)
AS A Router
AS C Router
AS B Router
BGP Session
Switching Fabric
IXP
Route Server
15
16. Software Defined IXPs (SDXs)
AS A Router
AS C Router
AS B Router
BGP Session
SDN Switch
SDX Controller
SDX
16
17. SDX Opens Up New Possibilities
• More flexible business relationships
Make peering decisions based on time of day, volume of traffic & nature of
application
• More direct & flexible traffic control
Define fine-grained traffic engineering policies
• Better security
– Prefer “more secure” routes
– Automatically blackhole attack traffic
17
18. SDX Enables Innovations at IXPs
• Dropping of attack traffic
– Blocking unwanted traffic in middle of Internet
• Inbound traffic engineering
– Divide traffic by sender or application
• Application-specific peering
– Video traffic via Comcast, non-video via ATT
• Server load balancing
– Select data centers to handle request
• Redirection through middleboxes
– E.g., transcoding, caching, monitoring, etc.
18
19. SDX Enables Innovations at IXPs
• Dropping of attack traffic
– Blocking unwanted traffic in middle of Internet
• Inbound traffic engineering
– Divide traffic by sender or application
• Application-specific peering
– Video traffic via Comcast, non-video via ATT
• Server load balancing
– Select data centers to handle request
• Redirection through middleboxes
– E.g., transcoding, caching, monitoring, etc.
19
20. Use Case: Prevent DDoS Attacks
20
AS 2
AS 1
AS 3
SDX 1 SDX 2
Attacker
Victim
AS1 can remotely block attack
traffic at SDX(es)
21. SDX-based DDoS protection vs.
Traditional Defenses/Blackholing
• Remote influence
Physical connectivity to SDX not required
• More specific
Drop rules based on multiple header fields, source address,
destination address, port number …
• Coordinated
Drop rules can be coordinated across multiple IXPs
21
22. SDX Enables Innovations at IXPs
• Dropping of attack traffic
– Blocking unwanted traffic in middle of Internet
• Inbound traffic engineering
– Divide traffic by sender or application
• Application-specific peering
– Video traffic via Comcast, non-video via ATT
• Server load balancing
– Select data centers to handle request
• Redirection through middleboxes
– E.g., transcoding, caching, monitoring, etc.
22
23. Use Case: Inbound TE
23
AS A
Router
AS C Routers
AS B Router
SDX Controller
SDX
C1 C2
10.0.0.0/8
24. Use Case: Inbound TE
24
AS A Router
AS C Routers
AS B Router
C1 C2
Incoming Data
10.0.0.0/8
Incoming Traffic Out
Port
Using BGP Using SDX
dstport = 80 C1
25. 25
Incoming Traffic Out Port Using BGP Using SDX
dstport = 80 C1 ? match(dstport =80) fwd(C1)
AS A Router
AS C Routers
AS B Router
C1 C2
Incoming Data
10.0.0.0/8
Enables fine-grained traffic engineering policies
Use Case: Inbound TE
26. Data Plane Scalability Challenges
26
Devices Operations
Data Plane Performance
State
(# entries)
Update Rate
(flow-mods/s)
Match-Action on Multiple Headers 100K 2,500
27. Data Plane Scalability Challenges
27
Devices Operations
Data Plane Performance
State
(# entries)
Update Rate
(flow-mods/s)
Match-Action on Multiple Headers 100K 2,500
Matches on IP Prefixes only ~1M N/A
Problem: Optimize the usage of
available devices
28. We Can Do This at Industry-Scale!
28
100 200 300 400 500
Participants
103
104
105
106
107
108
109
ForwardingTableEntries
Unoptimized
MDS SDX-Central
iSDX
Optimal
BGP routes and updates for large
EU IXP in a commodity hardware switch
29. Ongoing Deployment Efforts
• Public Internet Exchange Points:
– Large IXPs in Europe, Endeavour Project
– Smaller IXPs in Pakistan, ISOC
• Enterprise Networks:
– Inter-agency exchange point
• Wide Area Networks :
– CloudRouter, IIX 29
30. Conclusion
• SDN-based exchange (SDX) is promising for
fixing Internet routing
• Solved various challenges in building a real
deployable SDX
• Many open research problems, both for building
and using SDX 30
31. You Can Run iSDX Today!
Running code
• Vagrant & Docker based setup
• Instructions to run with HW switches
• Github Repo: https://github.com/sdn-ixp/iSDX
31
http://sdx.cs.princeton.edu
But, before we talk about software defined IXPs, let’s briefly talk about traditional IXPs. At any IXP, participants connect their border router to the IXP’s switching fabrics to exchange traffic. They establish BGP session with route server to exchange routes with each other.
With respect to this traditional model of IXPs, what we proposed few years back was to replace the traditional L2 switching fabric with an SDN switch and route server with SDX controller. This SDX controller now subsumes the behavior of route server, that is it not only receives BGP update messages from the IXP participants, but it also receives SDN policies from them, combines these policies together and pushes them down to the data plane.
There are bunch of other applications that are also possible with SDX and you find more details about them in the paper.
Now let’s consider another scenario where AS C’s policy is to receive HTTP traffic on C2.
Now let’s consider another scenario where AS C’s policy is to receive HTTP traffic on C2.
Now such a fine grained policy is not possible with BGP
So SDX enables more direct & fine grained traffic control which is not possible in current networks.
There are bunch of other applications that are also possible with SDX and you find more details about them in the paper.
Even though SDN switches can support flexible match-action operations, they have limited data plane state and can only support about 2500 flow-mods/second.
Making SDN policies congruent with BGP requires both large forwarding tables and support for very high data plane update rate.
To address the scalability problem we can leverage participants’ border routers at the IXP. Though these routers have a larger TCAM space which we can leverage but they can only support limited operations in the data plane. The problem of scaling SDX boils down to a classic problem, where we need to optimize the usage of multiple components with disparate capabilities and limitations to scale the performance of the system.