1 / 70

Innovation in Software-Based Routers for Networking Research

Explore the motivation and benefits of software data planes, active networking recap, Capsule concept, and OpenFlow for network innovation. Learn about the separation of control vs. data era, network management, traffic engineering, performance, security, and compliance in networking infrastructure.

ebowles
Download Presentation

Innovation in Software-Based Routers for Networking Research

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 15-744: Computer Networking L-7 Software Forwarding

  2. Software-Based Routers • Motivation • Enabling innovation in networking research • Software data planes • Readings: • OpenFlow: Enabling Innovation in Campus Networks • The Click Modular Router • Optional reading • RouteBricks: Exploiting Parallelism To Scale Software Routers

  3. Active Networking Recap • Network API exposes capabilities • Processing, queues, storage • Custom code/functions run on each packet • E.g., conventional IP is best effort, dst based • When could this be insufficient?

  4. Two models of active networks • “Capsule” • Packet carries code! • Programmable router • Operator installs modules on router • Pros/cons?

  5. Criticisms • Too far removed from conventional networks • Upgrade/deployability? • Capsule was considered insecure • No killer apps (continues to be problem) • Performance?

  6. Three logical stages (more hindsight) • Active networking era • Case for “programmable” network devices • “Separation” of control vs data era • Specifically about routing etc • OpenFlow/Network OS era

  7. Network Management Traffic Engineering Performance Security Compliance Resilience

  8. Problem: Toolbox is bad! Traffic Engineering Performance Security Compliance Resilience

  9. Why: Toolbox is implicit in routers! Traffic Engineering Performance Security Compliance Resilience Motivation: Management is complex, expensive, fragile Need: Direct control, expressive policy, network-wide views

  10. Solution • Separate out the “data” and the “control” • Open interface between control/data planes • Logically centralized views • Simplifies optimization/policy management • Network-wide visibility

  11. Today: OpenFlow Controller OpenFlow Config Config

  12. Next Lecture: ONIX Controller E.g., ONIX, NOX, … Config Config

  13. OpenFlow: Motivation • The Internet is a “success disaster” • Many successful applications • Critical for economy as a whole • Too huge a vested infrastructure • Vendors loathe to change anything • Fear in community: “ossification” • New ideas cannot get deployed

  14. Driving questions • Get our own operators comfortable with running network experiments • Isolate experimental traffic from production traffic • What is the functionality that enables innovation?

  15. Rejected alternatives • Get vendors to support • Use PC/Linux based network elements • Existing research prototypes for programmable elements

  16. Their Path • “Pragmatic compromise” • Sacrifice generality for: • Performance • Cost • Vendor “buy-in”

  17. Three Basic Features in OpenFlow Controller Secure Channel Open Protocol Config Config Flow Table

  18. FlowTable Actions • Forward on specific port/interface • Forward to controller (encapsulated) • Drop • Forward legacy • Future support: counters, modifiers

  19. What is nice • Fits well with the TCAM abstraction • Most vendors already have this • They can just expose this without exposing internals

  20. Example Apps • Ethane • Amy’s own OSPF • VLAN • VoIP for Mobile • Support for non-IP

  21. Driving questions: Did it achieve this? • Get operators comfortable with running experimental? • Isolate experimental traffic from production traffic? • What is the functionality that can enable innovation?

  22. Software-Based Routers • Enabling innovation in networking research • Software data planes • Readings: • OpenFlow: Enabling Innovation in Campus Networks • The Click Modular Router • Optional reading • RouteBricks: Exploiting Parallelism To Scale Software Routers

  23. Click overview • Modular architecture • Router = composition of modules • Router = data flow graph • An element is the basic unit of processing • Three key components of each element: • Ports • Configuration • Method interfaces

  24. Simple Tee Element

  25. Two types of “connections” • Push • Source element has finished processing • Sends it downstream • E.g., FromDevice • Pull • Destination is ready to process • Initiates packet transfer • E.g., ToDevice

  26. “Flow” of processing

  27. Click Config File

  28. Click Elements

  29. Other elements • Packet Classification • Scheduling • Queueing • Routing • What you write…

  30. Idea: Polling • Under heavy load, disable the network card’s interrupts • Use polling instead • Ask if there is more work once you’ve done the first batch • Click paper we read – does pure polling

  31. Takeaways • Click is a flexible modular router • Shows that s/w x86 can get pretty good performance • Extensible/modular • Widely used in academia/research • Play with it!

  32. Software-Based Routers • Enabling innovation in networking research • Software data planes • Readings: • OpenFlow: Enabling Innovation in Campus Networks • The Click Modular Router • Optional reading • RouteBricks: Exploiting Parallelism To Scale Software Routers

  33. Buildingrouters • Fast • Programmable • custom statistics • filtering • packet transformation • …

  34. Why programmable routers • New ISP services • intrusion detection, application acceleration • Simpler network monitoring • measure link latency, track down traffic • New protocols • IP traceback, Trajectory Sampling, … Enable flexible, extensible networks

  35. Today: fast or programmable • Fast “hardware” routers • throughput : Tbps • little programmability • Programmable “software” routers • processing by general-purpose CPUs • throughput < 10Gbps

  36. RouteBricks • A router out of off-the-shelf PCs • familiar programming environment • large-volume manufacturing • Can we build a Tbps router out of PCs?

  37. Router = • N: number of external router ports • R: external line rate R R packet processing + switching R R N R R R R

  38. A hardware router • Processing at rate ~R per linecard R R N linecards linecards

  39. A hardware router • Processing at rate ~R per linecard • Switching at rate N x R by switch fabric R R N switch fabric linecards linecards

  40. RouteBricks • Processing at rate ~R per server • Switching at rate ~R per server R R commodity interconnect N servers servers

  41. Outline • Interconnect • Server optimizations • Performance

  42. Requirements • Internal link rates < R • Per-server processing rate: c x R • Per-server fanout: constant R R commodity interconnect N

  43. A naive solution R R R N

  44. A naive solution • N external links of capacity R • N2 internal links of capacity R R R R N

  45. Valiant load balancing (VLB) R/N R R/N R N

  46. Valiant load balancing (VLB) • N external links of capacity R • N2 internal links of capacity R R/N R/N R R N 2R/N

  47. Valiant load balancing (VLB) • Per-server processing rate: 3R • W/ uniform traffic: 2R R/N R/N R R N

  48. Per-server fanout? R N

  49. Per-server fanout? • Increase server capacity R N

  50. Per-server fanout? • Increase server capacity R N

More Related