TCP-Splitter: A Reconfigurable Hardware Based TCP/IP Flow Monitor

Transcription

1 CP-Splitter: A Reconfigurable Hardware Based CP/IP Flow Monitor David V. Schuehler dvs1@arl.wustl.edu John W. Lockwood lockwood@arl.wustl.edu Applied Research Laboratory (ARL) Department of Computer Science and Engineering Washington University in Saint Louis Outline Motivation Hardware Platform Design Applications Results Questions 1

2 Problem Statement Develop a lightweight network monitoring component that operates at multi-gigabit/second line rates. Client Hardware IP frames Byte Stream CP Splitter IP frames IP Wrapper Why work with CP? Over 85% on Internet traffic is CP based Internet is growing CP is a proven reliable transport for data delivery Provide high speed active networks the ability work with CP flows 2

3 Why not use a software based monitor? Difficult to achieve desired performance Why not implement a full CP stack? Large memories required for reassembly Limited number of simultaneous connections Acts as a connection endpoint Not a lightweight solution Solution Develop CP flow monitor: CP-Splitter Leverage existing hardware infrastructure Expand upon Layered Protocol Wrappers research Client Application IP frames CP Splitter Byte Stream IP frames IP Wrapper AAL5 Frame Wrapper AM Cell Wrapper 3

4 HARDWARE PLAFORM Washington University Gigabit Switch 4

5 Module Oscillators Static Ram RAD (XCV1000E) NID (XCV600E) PROM DESIGN ô 5

6 Goals High Speed Design Small FPGA Footprint Simple Client Interface Support Large Number of Flows Utilize existing protocol wrapper framework Execute within environment, and systems like it Challenges Frames are dropped on the Internet Packets are reordering Flow state is needed for large number of flows Widescale deployment requires an efficient implementation Backbone networks must process data at multi-gigabit/second rates Hardware library should be small 6

7 Assumptions/Limitations hough traffic may take diverse paths through a network, all monitored traffic must flow through the node with CP-Splitter hrough flows are generally bidirectional, data is processed as a pair of unidirectional flows hough data may be sent out of order, data will be forced to be processed in-order CP-Splitter Client Application IP frames CP Splitter Byte Stream IP frames Inbound Outbound IP Wrapper AAL5 Frame Wrapper AM Cell Wrapper 7

8 CP Input Module Data Flow Flow Classifier Control FIFO Input Input State Machine Checksum Engine Output State Machine Output Frame FIFO Layout CPProc Client Application CPInput CPOutput Flow Classifier IP Input Checksum Engine Input State Machine Control FIFO Output State Machine Packet Routing IP Output Frame FIFO 8

9 Packet Routing Non-CP packets IP stack Invalid CP checksum Drop CP SYN packets IP stack (Seq # < Expected Seq #) IP stack (Seq # > Expected Seq #) Drop Else Client App AND IP stack Simple Client Interface 1 bit Clock 1 bit Reset 32 bit Data Word 2 bit Data Enable 3 bit Start/End of Data Signals 2 bit Valid Data Bytes N bit Flow Identifier 2 bit Start/End of Flow Signals 1 bit CA Client Application 9

10 APPLICAIONS Multi-Device Programmer Listens to CP/IP conversation Extracts programming information Sends programming information to device Simultaneously programs multiple devices Programmer Connection Endpoint CP/IP connection ô 10

11 Stacked programmer Line Card Client 50 Server RESULS 11

12 Synthesis Results for Xilinx XCV1000E-7 Space/LUs CPSplitter 617 (2%) Full Wrappers (Cell + Frame + IP + CP + Client) 4954 (20%) Register bits 503 (2%) 4933 (20%) Processing delay 7 clock cycles * clock cycles * * Plus length of packet in 32 bit words Sample Run Start of frame IP payload CP data enable End of frame Flow ID Byte count SRAM write 12

13 Conclusion Y CP-Splitter developed, simulated, and tested in reconfigurable hardware Y Monitors 256k CP/IP simultaneous flows in real-time Synthesizes at 101 MHz Processes data at 3.2 Gigabits/second Hardware design scalable to OC-192 and OC-768 Y Requires only limited resources: CP-Splitter uses 2% of Xilinx XCV1000E Complete IP stack uses 20% of XCV1000E Y Eliminates the need for large reassembly buffers Acknowledgments Harvey Ku Y Multi-Device Programmer Florian Braun and James Moscola Y IP Protocol Wrappers 13