1 / 38

Silicon-based Programmable Routers: What have we learned?

Silicon-based Programmable Routers: What have we learned?. Tal Lavian - Nortel Networks Labs tlavian@nortelnetworks.com 408-495-3062. Franco Travostino, Phil Wang, Rob Duncan. More info: http://www.openetlab.org. Usual Disclaimer. We are part of research organization.

nuncio
Download Presentation

Silicon-based Programmable Routers: What have we learned?

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. Silicon-based Programmable Routers: What have we learned? Tal Lavian - Nortel Networks Labs tlavian@nortelnetworks.com 408-495-3062 Franco Travostino, Phil Wang, Rob Duncan More info: http://www.openetlab.org

  2. Usual Disclaimer We are part of research organization. This talk describes exploratory research. • Nortel makes no commitment to turn this technology into products. • Nortel makes no commitment to do anything with the ideas described in this talk.

  3. What have we learned? • We have implemented programmable (Java) Gigabit Routing Switch (backplane 256 Gbs) • Infinite Bandwidth , Wire speed routing & Streaming media, drive New Types of intelligence on programmable network device • Dynamic monitoring and modification of silicon knobs • The granularity is streams and not packets • Short time granularity (part of apps and not human intervention, keyboard, telnet, cli, snmp)

  4. Agenda • Programmability - market drivers • Infinite bandwidth drives the need for programmability • Architecture • Separation of Control and Data planes • Example - Dynamic Classification • Summary

  5. Industry Movement from Vertical toward HorizontalMarkets Applications OSs Peripherals Hardware Amdel IBM Digital CDC 2000s - Horizontal Industry 1980s - Vertical Industry

  6. Inflection Points Ahead of Us Incomplete transformation; the inflection point is quickly approaching … Network & Mgmt services Embedded OS System ASICs 3Com Cisco Juniper Nortel Horizontal Network Industry “00 Vertical Network Industry

  7. Infinite BandwidthWhy this change the playground? • Are we ready for streaming media on the net? • Peer to Peer – Napster, 6000 radio stations • Streaming video, multicast, Napster video is coming • Web traffic will be minor (streaming is constant) • 3-4 orders of magnitudes bandwidth growth in many dimensions • Access – Cable, DSL, 3G – (28kbs10mbs, 1.5mbs, 384kbs) • Core – Optical bandwidth - (155mbs  1Tbs) • LAN – (10mbps  10Gbps) • Silicon Wire-speed routing

  8. Bottlenecks in Programmable Routing • The streaming media demand & the infinite bandwidth will drive the need for programmability and dynamic services on the net • Need programmability to drive this booming demand. Software based routers can’t do it. • Unlike Linux routers and software based routers, we can’t add software to the data plane • Data plane : Wire speed silicon forwarding, multi Gigabit • Control plane : • Can’t see the data in wire speed. • Can dynamically modify the silicon knobs

  9. Programmable Services - Locations • Service-enablement will prove most effective where “impedance mismatches” occur in the network • Optical vs. Wireline (3-4 oom) • Wireline vs. wire-less (3-4 oom) • Secure vs. non-secure • Customer-premises vs. Content-provider-land (3-4 oom) • SLA (x) vs. SLA (y) • Resource-constrained vs. unwashed unlimited computing • A service-enabled box can wear multiple hat oom – Order of Magnitude

  10. Proprietary Apps Proprietary NOS ASICs/Processors Emancipation of a Router It all started from old-world, vertically-integrated code.

  11. N 1 Routing k N Protocol r o M 1 w e m O N a Management r F System Interface s e Agents C O Manager c 1 i v N r e S 1 N Routing m e Table t s Manager y S M C M Forwarding Engine Interface FC FM Routers Emancipation ISV’s Software Extroverted APIs extend a commodity Java runtime. JAPIs Extroverted APIs JVM APIs Introverted APIs Forwarding Engine ASICs/Processors

  12. Java-enabled Device Architecture Download Oplet Oplet Oplet Oplet Native APIs Oplet Runtime Env Routing Code JVM Operation System Hardware

  13. Example: Downloading Intelligence Monitor Intelligence Security Authentication Dynamic loading application React JVM OS HW Network Device

  14. Separation of Control and Forwarding Planes Centralized, CPU-based Router Forwarding-Processors Based Router Routing SW Control Plane CPU CPU Forwarding Processor Forwarding Processor Forwarding Processor Slow Wire Speed Control + Forwarding Functions combined Control separated from forwarding

  15. Forwarding Rules Forwarding Rules Forwarding Rules Forwarding Processor Statistics &Monitors Forwarding Processor Forwarding Processor Statistics &Monitors Statistics &Monitors Programmable Networking Network Services ORE JFWD Control Plane CPU System Filtered packets New rules Switching Fabric Forwarding Plane (Wire Speed Forwarding) . . . Traffic Packets

  16. But Java is Slooowwwww • Not appropriate in the fast-path data forwarding plane • forwarding is done by ASICs or NPUs • packet processing not affected • Java applications run on the CPU • Packets designated for Java application are pushed into the control plane

  17. Simple Example: Fine grain monitoring • Imagine a SNMP-based network with: • 100 nodes • each node with 100 ports • each port with 100 conditions • all being checked 100 times a second • That’s 10 billion SNMP variable accesses every second. • And that’s a significant load on the NMS and the network as a whole. It’s not going to work.

  18. Forwarding Rules Forwarding Rules Forwarding Rules Forwarding Processor Statistics &Monitors Forwarding Processor Forwarding Processor Statistics &Monitors Statistics &Monitors Silicon-based Forwarding Engines Control Plane CPU Switching Fabric Wire Speed Forwarding . . .

  19. Forwarding Rules Forwarding Rules Forwarding Rules Forwarding Processor Forwarding Processor Forwarding Processor Statistics &Monitors Statistics &Monitors Statistics &Monitors Real-time Forwarding Stats and Monitors Apps CPU SW HW

  20. Dynamic Classification Objectives • Implement flow performance enhancement mechanisms without introducing software into data forwarding path • Service defined packet processing in a silicon-based forwarding engine • Dynamic packet classifier

  21. Policy Filters Dynamic - On the Fly Configuration Dynamic Apps Filter Packet Packet Forwarding Processor Forwarding Processor Packet

  22. Source Address Source Port Destination Address Destination Port Protocol Copy the packet to the control plane Don't forward the packet Set TOS field Set VLAN priority Adjust priority queue 5-tuple Filtering List Dynamic Filtering JFWD 5-tuple Filtering Layer 4-7 in new hardware Utilize Network Processors capabilities

  23. Experimental Setup Acclear 1100B Routing Switch Source 1 tcp_send() 100 Mbps Destination 1. tcp_recv() 2. tcp_recv() 100 Mbps Source 2 tcp_send() 100 Mbps • Rob Jaeger, Jeff Hollingsworth, Bobby Bhattacharjee - University of Maryland

  24. Streams Programmability

  25. Dynamic Classification • Identify real-time flows (e.g. packet signature or flowId ) • Use CarbonCopy filters to deliver multimedia control protocols to control plane • e.g. SIP, H.323. RTCP • Determine dynamically assigned ports from control msgs • Use CarbonCopy filters to sample a number of packets from the physical port and identify RTP packets/signature • Set a packet processing filter for packet signature to: • adjust DS-byte OR • adjust priority queue

  26. Dynamic Classification • Without introducing software into data path we performed Dynamic Classification of flows in a Silicon-Based Gigabit Routing Switch • Introduced a new service to a Gigabit Routing Switch • Identified real-time flows • Performed policy-based flow behavior classification • Adjusted DS-byte value • Showed that flow performance can be improved • Let Open Programmability and Innovation to build end-to-end network solutions and services

  27. Nortel’s Openet.lab • It’s an incubator for service-enabled network nodes and sample services • It provides: • JVM-emancipated prototypes of Nortel routers • Java APIs to MIBs • Java APIs to Forwarding Planes, packet capturing • A runtime environment for downloaded code • Open Source at http://www.openetlab.org

  28. Closing remark Back then, thrust wasn’t a problem; control was. Likewise, network bandwidth isn’t the problem, control is. It demands our collective efforts Wright brothers 1904

  29. Q&A

  30. Appendix

  31. Multiple points of view • It is possible for node A to lose network “visibility” to node B, even though the NMS has visibility to both • The NMS is the traditional PoV for observing the network • Being able to move the management PoV out of the NMS and into the managed nodes would help A B NMS

  32. Mobile diagnostics • Similar to multiple points of view • Blocking DoS at ingress into the network is best • Inject mobile agent into the network at the node where the DoS is first detected • The agent moves from node to node towards the DoS traffic source • A bit like an immune system 

  33. Active Intrusion Detection • Intruder is identified by Intrusion Detection software • Intruder signature is identified • Mobile agent is dispatched in direction of intruder (based on physical port of entry) • Mobile agent “chases” and terminates intruder (shuts down link, reboot host, notify NMS)

  34. Diagnostic Mobile Agents • Automatic trace-route from edge router where problem exists • Each node reached generates a report to NMS • Trace-route code “moves” to next node in path • Mobile agents identify router health • Create logs for NMS

  35. App Server Download Monitor Complex Condition Exceeded Appropriate Application Download Apps - Routing Relationship Extensive access to internal resources • Download Oplet Service to the router. • Monitor router locally • Report “events” to App server • Allow Service to take action • Download application • Adjust parameters based on direction from app server router

  36. Collaboration with Applications • New paradigm of distributed applications • Network devices collaborating with applications • Application aware routing Apps Server Oplet Oplet Apps Apps RMI, XML, CORBA JVM JVM Routers Switches Servers

  37. Java-based Application Java-based Application Java-based Application Router Server Collaboration • Supports distributedcomputing applications in which network devices participate • router to router • server to router • Supports Intelligent Agents • Supports Mobile Agents

  38. Strong Security in the New Model • The new concept is secure to add 3rd party code to network devices • Digital Signature • Administrative “Certified Optlet” • No access out of the JVM space • No pointers that can do harm • Access only to the published API • Verifier - only correct code can be loaded • Class loader access list • JVM has run time bounds, type, and execution checking

More Related