SDX Project Updates GEC 20

Transcription

1 SDX Project Updates GEC 20 Georgia Tech Team: Russ Clark, Nick Feamster, Arpit Gupta Ron Hutchins, Cas D Angelo, Siva Jayaraman! June 23, 2014!

2 Project Goals Enable and support SDX research in the GENI community! Create a reference architecture Provide sample implementations Demonstrate and document use in GENI First as a repeatable demonstration experiment Then as a core GENI service 2

3 SoX

4 What is SDX to us? Leverage SDN as a tool to overcome the limitations of traditional peering limitations closely linked to limitations of BGP lack of expressiveness in traffic policy can t replace BGP all at once Focus on the IXP (> 300 Internet Exchange Points) Incrementally deployed as a complementary technology Joint research work with L. Vanbever, M. Shahbaz, S. Donovan, B. Schlinker, N. Feamster, J. Rexford, S. Shenker, R. Clark, E. Katz-Bassett 4

5 SDX is a platform that enables multiple stakeholders to define policies/apps over a shared infrastructure Content providers Transit providers Eyeballs providers SDX 5

6 SDX enables a wide range of novel applications security Prevent/block policy violation Prevent participants communication Upstream blocking of DoS attacks forwarding optimization Middlebox traffic steering Traffic offloading Inbound Traffic Engineering Fast convergence peering Application-specific peering remote-control Influence BGP path selection Wide-area load balancing 6

7 What is an IXP? An IXP is a large L2 domain where participant routers exchange routes using BGP ebgp sessions Edge router IXP Switching Fabric ebgp route 7

8 What is an IXP? To alleviate the need of establishing ebgp sessions, IXP often provides a Route Server (route multiplexer) / /8 Router Server /8 8

9 What is an IXP? IP traffic is exchanged directly between participants, i.e. the IXP is forwarding transparent IP traffic Router Server 9

10 What is an SDX? With respect to a traditional IXP, SDN-enabled IXP (SDX) control-plane relies on a SDN controller SDN SDN controller also a Route Server 10

11 Programming Abstractions Abstractions are the key! Multiple participants share the control plane.! Need right abstractions for:! Flexibility! Isolation SDX policies interact with legacy protocols eg. BGP. Need right abstractions to ensure compatibility and correctness 11

12 Virtual SDX Switch Abstraction Be your own boss! policy: application-specific peering match(dstport=80) >> fwd(b)) + match(dstport=443) >> fwd(c)) AS B policy: inbound traffic engineering (match(srcip={0/1}) >> fwd(b1)) + (match(srcip={128/1}) >> BGP fwd(b2)) routes for RS SDX-enabled Route Server (RS) A1 virtual switch AS A C B A virtual switch AS C B A virtual switch AS B C B1 B2 prefix p1 p2 p3 p4 virtual port p5 received C, B C, B B, C C A AS A router SDX Fabric BGP session AS B router SDX Fabric elected routes physical port C1 AS C router Illusion of its own virtual SDX switch for each participant Balances desire for flexibility with necessary isolation 12

13 Virtual SDX Switch Abstraction How do participants write policy? Pyretic Pattern eth_type vlan_id Actions match ( srcmac dstmac protocol dstip, &&, ), then ( drop forward rewrite ) tos srcip srcport dstport 13

14 Virtual SDX Switch Abstraction AS A policy: application-specific peering (match(dstport=80) >> fwd(b)) + (match(dstport=443) >> fwd(c)) AS B policy: inbound traffic engineering (match(srcip={0/1}) >> fwd(b1)) + (match(srcip={128/1}) >> fwd(b2)) A1 virtual switch AS A C B virtual switch A virtual switch AS B C B1 B2 A AS C B virtual port SDX Fabric physical port C1 14

15 Integration with Inter-domain Routing Forwarding policies apply only for prefixes announced by neighbor BGP routes for RS SDX-enabled Route Server (RS) prefix p1 p2 p3 received C, B C, B B, C BGP session p4 C SDX Fabric p5 A AS A router AS B router elected routes AS C router match(dstport=80) >> fwd(b) match(dstport=443) >> fwd(c) Applied only for prefixes Applied only for prefixes p1, p2, p3 p1, p2, p3, p4 15

16 Integration with Inter-domain Routing Non-matching traffic follows default BGP forwarding. BGP routes for RS SDX-enabled Route Server (RS) prefix p1 p2 p3 received C, B C, B B, C BGP session p4 C SDX Fabric p5 A AS A router AS B router elected routes AS C router What happens with traffic for dstip=p2 dstport=22? match(dstport=80) >> fwd(b) match(dstport=443) >> fwd(c) Applied only for prefixes Applied only for prefixes p1, p2, p3 p1, p2, p3, p4 16

17 Controller Design What does the SDX controller look like? Policies Participants BGP Updates Policy Handler ExaBGP Isolation Input RIBs Policy Compiler Incorporating BGP Default Forwarding Optimization (i.e., compute VNH) BGP decision process Local RIBs Route Server Composition BGP Announcements Pyretic ARP OpenFlow Rules Access RiBs or ARP table Trigger compilation 17

18 How do I use it? Deploy a controller host operates the SDX controller software and route server Create your network topology Point your switches at the controller Define policy rules using policy language See example on GitHub 18

19 Application Specific Peering /16 AS C policy* announcements default AS A SDX Fabric :80 AS B tunnels Wisconsin TP Clemson TP /16 AWS Instance *policy = match(dstport=80) >> fwd(b) 19

20 Going Forward Deploy current SDX controller as a GENI demonstration project Get people using it! Iterate, refine, improve. Work to deploy as a core service with peering arrangements build on GEC 19 demo R&E and commercial 20

21 Contact Info 21