1 / 36

Hardware-Accelerated Signaling

Hardware-Accelerated Signaling. ―Design, implementation. and Implications. Haobo Wang November 15, 2004. Outline. Background and problem statement OCSP: a performance-oriented signaling protocol and its hardware implementation

avalon
Download Presentation

Hardware-Accelerated Signaling

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. Hardware-Accelerated Signaling ―Design, implementation and Implications Haobo Wang November 15, 2004

  2. Outline • Background and problem statement • OCSP: a performance-oriented signaling protocol and its hardware implementation • A subset of RSVP-TE signaling protocol and its hardware implementation • Comparison of signaling transport options • Implications of hardware-accelerated signaling • Conclusions and future work

  3. Outline • Background and problem statement • OCSP: a performance-oriented signaling protocol and its hardware implementation • A subset of RSVP-TE signaling protocol and its hardware implementation • Comparison of signaling transport options • Implications of hardware-accelerated signaling • Conclusions and future work

  4. Background • Signaling protocol • Set up and tear down connections in connection-oriented networks • Control-plane protocol • Signaling protocols are primarily implemented in software • Two reasons: complexity and the requirement for flexibility • Price paid: poor performance • RSVP-TE for GMPLS • Support a wide range of connection-oriented networks • Being implemented by switch vendors

  5. Network and node views

  6. Two questions • Question 1: why connection-oriented (CO)? • Inherent support for QoS • Can connectionless networks provide QoS? Yes, but • Over-provisioning -> low utilization • Question 2: What the drawbacks of CO? • Call setup overhead – signaling message propagation delay, processing delays, and transmission delays • Call handling capacities of today’s switches are limited

  7. Problem statement • How to overcome the drawbacks of CO ― Hardware-accelerated signaling? • Determine whether signaling protocols can be implemented in hardware and demonstrate it with an actual implementation • Study how to reduce signaling message trans-mission delays • Explore the impact of hardware-accelerated signaling protocol implementations

  8. Related work • How to achieve fast signaling? • New, simplified signaling protocols: YESSIR, PCC • Hardware implementation: FRP (ASIC, not flexible) • A simplified version of RSVP-TE intended for hardware implementation • “Keep It Simple” Signaling – still on the blueprint • Other comparable protocols implemented in hardware • TOE: TCP/IP Offload Engine • TCP switching

  9. Outline • Background and problem statement • OCSP: a performance-oriented signaling protocol and its hardware implementation • A subset of RSVP-TE signaling protocol and its hardware implementation • Comparison of signaling transport options • Implications of hardware-accelerated signaling • Conclusions and future work

  10. Optical Circuit-switching signaling Protocol - OCSP • Performance-oriented, optimized for hardware implementation • Specifically designed for SONET switches • Implemented on WILDFORCE FPGA board

  11. Hardware platform of the implementation

  12. Assuming a 25 MHz clock Total setup and teardown time: 5.9 to 6.8 us Call handling capacity of 150,000 calls/sec Simulation and implementation results for OCSP

  13. Outline • Background and problem statement • OCSP: a performance-oriented signaling protocol and its hardware implementation • A subset of RSVP-TE signaling protocol and its hardware implementation • Comparison of signaling transport options • Implications of hardware-accelerated signaling • Conclusions and future work

  14. Length Type Value Challenges for hardware implementation of RSVP-TE • A large number of messages, objects • Maintaining state information • Many data tables • Support for timers • Global connection reference • Flexible TLV style object…… Can be overcome by defining a sub- set of RSVP-TE

  15. Processing of Path message Incoming Connectivity table Outgoing Connectivity table IP 7.4.1.4 IP 5.7.1.1 IP 5.7.1.3 IP 4.8.1.1 IP 7.4.1.2 Int.#3 Int.#5 Int.#10 Int.#1 Routing table Outgoing CAC table State table User/Control Mapping table

  16. Message processing Message parsing Message assembling Architecture of the hardware signaling accelerator (FPGA)

  17. Functional modules of the hardware signaling accelerator • Incoming message buffer • Two-level message buffering and FIFO interface • Object dispatcher • Two-level dispatching and distributed decoding – TLV challenge • Data table management • Table access arbiter and TCAM/SRAM interfaces • Resource management • Hierarchical resource allocator and CAC table • Retransmission management • Retransmission buffers, timers, exponential back-off

  18. Message Buffer SRAM Architecture of the prototype board

  19. Main on-board modules • Hardware signaling accelerator: FPGA • 957-pin BGA, 6 separate clock signals, 3 I/O levels • High-speed (100MHz) • 1Gbps signaling channel: GbE MAC+SerDes+ optical transceiver • Demonstrate 250,000 calls/sec call handling rate • High-speed interface: 125MHz • Incoming message buffer: FIFO • Hardware/software interface • Data tables: TCAM and SRAM • User plane device: switch fabric • High-speed LVDS signals

  20. CAC table Routing table Incoming Conn tbl Outgoing Conn tbl State table Organization of the data tables User/Ctrl Mapping tbl

  21. Clock and power distribution schemes • Clock distribution scheme • Power distribution scheme • Two extra power supplies

  22. Processing of signaling message — simulation results

  23. Implementation and simulation results • Implementation results • Simulation results (@50MHz)

  24. Outline • Background and problem statement • OCSP: a performance-oriented signaling protocol and its hardware implementation • A subset of RSVP-TE signaling protocol and its hardware implementation • Comparison of signaling transport options • Implications of hardware-accelerated signaling • Conclusions and future work

  25. In-band signaling and out-of-band signaling

  26. Models for in-band signaling and out-of-band signaling

  27. Set-up delay analysis • Total delay = processing delay + network delay + transmission delay (retransmissions) • Assuming T0 = 3Tn, M/D/1 queue for E[Ttx], we have

  28. In-band/out-of-band signaling with software signaling, metro area • In-band/out-of-band signaling with hardware signaling, metro area, μtx=μproc • In-band/out-of-band signaling with hardware signaling, wide area, μtx=μproc • In-band/out-of-band signaling with hardware signaling, metro area, μtx<<μproc • In-band/out-of-band signaling with hardware signaling, wide area, μtx<<μproc • In-band/out-of-band signaling with software signaling, wide area Numerical results

  29. A sum-up of the comparison • With hardware signaling accelerators • In-band signaling is the way to go • Network delays dominate the total delay • With software signaling processors • In wide area –> in-band signaling • In metro area –> out-of-band signaling is a good choice

  30. Outline • Background and problem statement • OCSP: a performance-oriented signaling protocol and its hardware implementation • A subset of RSVP-TE signaling protocol and its hardware implementation • Comparison of signaling transport options • Implications of hardware-accelerated signaling • Conclusions and future work

  31. End-to-end circuits for large file transfers • End-to-end circuits only justifiable for large files • Define a crossover file size , per-circuit utilization is given by • Assuming 10Mbps signaling link, 100Mbps data link, 20 switches, in order to achieve 90% per-circuit utilization

  32. Fractional offered load • Assuming file size follows pareto distribution • Define fractional offered load • With hardware-accelerated signaling • In metro area, 81% of the offered load can be transferred through end-to-end circuits • In wide area, 71% of the offered load can be transferred through end-to-end circuits • With software signaling, this number is 51%

  33. Hardware-accelerated signaling and network survivability • Two approaches for network survivability • Protection requires pre-allocated resources and reacts to failure rapidly • SONET APS requires 100% resource redundancy (1+1) and can recover in 50ms • Restoration dynamically sets up a secondary path after a failure - less resource redundancy but longer recovery delay • Hardware-accelerated signaling • Less resource redundancy and acceptable recovery delay (<200ms) • A sample network with 13 nodes and 22 links • Recover from one link failure in 200ms with 9% extra resources

  34. Outline • Background and problem statement • OCSP: a performance-oriented signaling protocol and its hardware implementation • A subset of RSVP-TE signaling protocol and its hardware implementation • Comparison of signaling transport options • Implications of hardware-accelerated signaling • Conclusions and future work

  35. Conclusions and future work • Hardware-accelerated signaling is feasible and our implementation demonstrates a 100x-1000x speedup vis-à-vis software implementations • Applications like large file transfer and network restoration can benefit from hardware signaling and a well-devised signaling transport scheme • Future work • Finish the design and testing of the prototype board • New architectures and applications that can fully utilize the benefit of hardware-accelerated signaling

  36. Thank you!

More Related