Hardware-Accelerated Signaling

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!