Fulvio Risso (fulvio.risso@polito.it)

1. Towards Effective Portability ofPacket Handling Applications Across HeterogeneousHardware Platforms Fulvio Risso (fulvio.risso@polito.it)

2. A typical packet-based application Generic output Packet-based application Higher-level processing logic Packet Filtering Classification Pattern Matching Connection tracking . . . Very common pieces of (simple) logic related to packet processing Network packets

3. The problem Application • Many different kinds of processing • may even require to be updated in real-time • Processing efficiency issues • we need to optimize these components and exploit some dedicated hardware components when available Count traffic (bytes) according to the “ip.source” field of each packet Application Capture UDP packets whose udp.sport == 53 Application Count traffic (bytes) belonging to the following protocols:IP, IPv6, TCP, UDP Application Extract the value of field tcp.seqnumber from TCP packets Network packets

4. The (proposed) solution • The solution • NetVM (Network Virtual Machine) • Packet handling programming • Architecture • Instruction set • Programming language NetVM : JavaVM = IXP2400 : Pentium

5. Implementing the NetVM ... Application Application Packet Processing Count traffic (bytes) according to the “ip.source” field of each packet Application Capture UDP packets whose udp.sport == 53 Application Count traffic (bytes) related to the following protocols: IP, IPv6, TCP, UDP Extract the value of field tcp.seqnumber from TCP packets User Level Hardware … in user (application) space Packets

6. Implementing the NetVM ... Application Application Count traffic (bytes) according to the “ip.source” field of each packet Capture UDP packets whose udp.sport == 53 Count traffic (bytes) related to the following protocols: IP, IPv6, TCP, UDP Application Application Extract the value of field tcp.seqnumber from TCP packets User Level Packet Processing Hardware … in kernel space Packets

7. Implementing the NetVM ... Application Count traffic (bytes) according to the “ip.source” field of each packet Application Capture UDP packets whose udp.sport == 53 Application Count traffic (bytes) related to the following protocols: IP, IPv6, TCP, UDP Application Extract the value of field tcp.seqnumber from TCP packets User Level Hardware (e.g. NIC) Packet Processing … in hardware Packets

8. Define the processing through a high-level language Compiler Create program in “intermediate” assembler (NetVM assembler) NetVM Create native program forthe target hardware platform JIT compiler Native code for general-purpose CPU (e.g. x86) Native code for network processor (e.g. IXP 2400) VHDL code for reprogrammable ASICs Packets The NetVM framework Higher-level code PacketProcessingLibrary (Hardware)

9. Another Hourglass Model Packet capture Traffic monitor NAT Firewall NIDS L4/7 switches Router access list New applications: - Content Delivery Networks - Active Networking High-level networking interface NetVM Low-level networking interface Generic Hardware(e.g., PC) Specialized network hardware (vendor X) Specialized network hardware (vendor Y)

10. Properties • Optimized to operate on network packets • Lightweight • Efficient execution on • Network processors • Systems with custom hardware • User programs can benefit from hw resources thanks to the JIT compilation

11. Benefits • Fast network program development • Application portability • Hardware implementation

12. NetVM Architecture NetIL Bytecode NetIL Bytecode Control Plane (API) Shared Memory NetVM Data Plane Exchange Buffer Pool PE1 (e.g. filtering) Local PU Local Memory PE2 (e.g. classification) Local PU Local Memory Packets/ Other Infos Network Packets Output Socket Input Socket Input Port Output Port Output Port Input Port TCP Reassembly coprocessor IP Reassembly coprocessor Connection Tracking coprocessor

13. Processing Element Architecture NetPE Local Processing Unit Read-Only Registers PCprogram counter Code Memory SP stack pointer Shared Memory Data Memory Config. Registers Current Exchange Buffer NetPE internal communication bus CML code memory length Evaluation Stack DMLdata memory length Local Variables Pool EBL exchange buffer length PTL port table length Port Table

14. Processing Element Interconnection Port1 Output1 NetPE1 (e.g. filtering) NetPE2 (e.g. classification) Output2 Port2 . . . . . . NetPE1 (e.g. IP stats) NetPE2 (e.g. TCP stats) Input Output NetPE3 (e.g. UDP stats)

15. Exchange Buffer NetPE1 (e.g. field extraction) NetPE2 (e.g. classification) Exchange Buffer Packet Buffer Packet Data IP.src: offset 26 IP.dst: offset 30 TCP.sport: offset 34 TCP.dport: offset 36

16. High Level Code • NetPFL (Network Packet Filtering Language) • Example: IPv4 filter eth.type == 0x800 ReturnPacket on port 1 • Potentially, a C compiler can be created for generating NetVM code

17. Corresponding NetVM Code ; Push Port Handler ; triggered when data is present on a push-input port segment .push .locals 5 .maxstacksize 10 pop ; pop the "calling" port ID push 12 ; push the location of the ethertype upload.16 ; load the ethertype field push 2048 ; push 0x800 (=IP) jcmp.eq send_pkt ; compare the 2 topmost values; jump if true ret ; otherwise do nothing and return send_pkt: pkt.send out1 ; send the packet to port out1 ret ; return ends

18. Numerical results • Filtering on “IP” packets • Interpreted code (no JIT) • PC Dual Xeon, 1GB RAM, 2GHz clock • Promising performances • Stack-based architecture (less efficient) • NetVM interpreter not really optimized • NetVM interpreter is not the “definitive” target platform 13 BPF instructions against 7 NetIL instructions

19. Distributed Packet Processing User application Ethernet phone Send an alarm when a SIP INVITE is received Get a summary of each TCP session Router Count IPv6 and IPv6- in-IPv4 packets Capture PPPOE packets Local workstation ADSL Modem Remote workstation Reassembly all TCP sessions on port 8888 and look for keyword “MP3” in there

20. Some new ideas for discussion • Is the NetVM suitable for implementing a complete packet-based application? • Is the NetVM suitable for hiding the complexity of network processors?

21. Can we create complete, portable applications using the NetVM? Developing a complete application NetVM goals: Other technologies already offer a solution to this problem (e.g. Java, CLR) Performance Portability What we need is something that allows very high performance on packet-processing code

22. Packet-based application Higher-level processing logic NetVM Packet Filtering Classification Pattern Matching Connection tracking . . . Developing a complete application Packet-based application General-purposeCPU Higher-level processing logic Packet Filtering Classification Pattern Matching Connection tracking . . . NetVM

23. A note about high performance • Is the NetVM suitable for hiding the complexity of network processors (or ASICs)? • Network Processors have different architectures for being able to squeeze the last bit of performance out of them • This is one of the reason a large number of companies are still developing ASICs • Are engineers fancy developing NetVM code? • You cannot avoid some performance penalty with NetVM

24. The NetVM target • Which is the most appropriate target for the NetVM? • Packet capture with some basic (and customizable) packet processing • Anything else? • What about “complex” applications (e.g. firewall)? • The current model cannot guarantee portability • Should we stay with a “simple” NetPE model, or a “service processor” model may be better? • Requires at least a C compiler • Currently implementing Snort in the NetVM

25. ? !