A Hardware-Accelerated Implementation of the RSVP-TE Signaling Protocol Haobo Wang, Ramesh Karri Polytechnic University Malathi Veeraraghavan, Tao Li University of Virginia

Outline Background and problem statement A subset of RSVP-TE signaling protocol Hardware-accelerated implementation Conclusions and future work I repeat this outline for each section. Light blue shows the current section. 2019/1/16

Outline Background and problem statement A subset of RSVP-TE signaling protocol Hardware-accelerated implementation Conclusions and future work 2019/1/16

Background Signaling protocol RSVP-TE for GMPLS Control-plane protocol Set up and tear down connections in connection-oriented networks RSVP-TE for GMPLS Support a wide range of connection-oriented networks Being implemented by switch vendors Signaling protocols are primarily implemented in software Two reasons: complexity and flexibility Price paid: poor performance I’m wondering whether we should exchange item 2 and item 3. First we talk about general signaling protocol, followed by a specific signaling protocol, RSVP-TE. Then we explain why signaling protocols are primarily implemented in software. 2019/1/16

Problem statement Implement a subset of RSVP-TE signaling protocol in reconfigurable hardware Specifically tailored for SONET switches Achieve high call handling capacity and low delay Challenges RSVP RSVP-TE (MPLS)  RSVP-TE (GMPLS) A large number of messages, objects, parameters TLV (Type-Length-Value) style object processing Maintaining per connection state information Sophisticated data table manipulations Timers And more… Our work is to implement a subset of RSVP-TE signaling protocol in HW. Our target is SONET switch, we expect better performance. What are the difficulties? Here the challenges, and the innovative solutions on the next page, and implementation details on slides 15-19, are related. 2019/1/16

How to solve these challenges? Partition signaling functions Implement time-critical functions in hardware, and relegate non-time-critical functions to software Innovative hardware implementations Message/objects dispatchers Data table management Retransmission management and timers And more… 2019/1/16

Outline Background and problem statement A subset of RSVP-TE signaling protocol Hardware-accelerated implementation Conclusions and future work 2019/1/16

A subset of RSVP-TE — Messages Nine messages Path, Resv, PathTear, and ResvTear Set up and tear down connections Time-critical —> hardware All other messages Non-time-critical —> software Each message consists of a common header and a variable number of objects 2019/1/16

A subset of RSVP-TE — Objects Type-Length-Value (TLV) style object Flexible but a challenge for hardware implementation All mandatory objects and three optional objects are processed by hardware SUGGESTED_LABEL: forward label allocation MSG_ID, MSG_ID_ACK: reliable transmission 2019/1/16

A subset of RSVP-TE — Procedures (setup) Five steps at each switch Determine next-hop Reserve resources Allocate “labels” Program switch fabric Update state information Here we use setup procedure as an example. Releasing a connection follow the same end-to-end procedure. Pay attention that Path and Resv messages are together used for setting up a connection. PathTear, or ResvTear, either one can be used to tear down a connection. About these five steps. Our implementation realizes the first 3 steps in forward direction. However, allocating labels, according to RSVP specification, can be on the backward direction. In the paper, we justified our choice. Forward direction Backward direction 2019/1/16

Outline Background and problem statement A subset of RSVP-TE signaling protocol Hardware-accelerated implementation Conclusions and future work 2019/1/16

Network and node views 2019/1/16

Architecture of the prototype board FIFO: 64K by 36. A message is 125B or 32 32-bit words. Therefore can hold 2000 messages. TCAM: 64K by 72 entry device. 16 segments each of 4K. Each segment can be configured as a 4K by 72, 2K by 144, 1K by 288 or 512 by 576. SRAM: 128K by 36 FIFO holds messages to be passed to software. SRAM0: for data tables along with TCAM SRAM1: messages waiting for ACKs. What is a ternary CAM: Basically in a CAM we match the contents with a data value that we are looking up. But with Ip address some bits should not be matched if subnet mask indicates a 0. So it is 1, 0, x, and therefore we need a TCAM. It is realized with two 64K by 72 tables, one data and one for mask. 2019/1/16

Architecture of the hardware signaling accelerator (FPGA) 2019/1/16

TLV style object Processing SESSION Dispatcher RSVP_HOP Unknown obj. Processor Object Dispatchers Message Dispatcher There is some animations. First show the message dispatcher, then show multiple objects dispatchers. Then point out that the TLV processing consists of these two levels of dispatchers. The function of message dispatcher is to delimit objects. Object dispatchers work independently and in-parallel. Only the matched object dispatcher will be triggered. Two levels of Dispatchers 2019/1/16

Six data tables I use different color bubble to match the tables locations on the next slide. 2019/1/16

Organization of the data tables This figure is not clear. Please mention that these tables are located in three devices, TCAM, SRAM, and internal SRAM inside FPGA. Also show the audience that routing table (#1) locates in both TCAM and SRAM, Incoming Connectivity table and Outgoing Connectivity table locate in TCAM only (the return value from the TCAM (address) is what we need. Outgoing CAC table is located inside FPGA completely (two reasons, first, this table will be accessed several times in each message processing, we need to speed up the accessing; second, this table is small enough to fit into FPGA internal memory). State table is indexed by 128-bit global ID, and return 228-bit state information (it is expandable, we can maintain more state information). The outgoing and incoming conn. tables do need the SRAM because we need to extract 6 (if id) + 6 (phyid) + 12 (timeslots). Haobo took some impl. shortcut. 2019/1/16

Retransmission management (buffers and timers) It is a simplified version. RSVP-TE is built upon unreliable IP, RFC2901 proposed a exponential back-off retransmission algorithm, and introduced MESSAGE_ID, MESSAGE_ID_ACK objects. On the transmitting side, the unacknowledged messages are buffered. The buffer is organized as four segments, corresponding to initial transmission, first RE-transmission, and second retransmission (we try at most 3 times). Each buffered message also has an associated time tag. Messages are buffered in the FIFO (First In First Out), the head is always the oldest one, so we only need to compare the head message’s time tag with the timer. There are 3 separate FIFOs for initial transmission, 1st retransmission, and 2nd retransmission. Totally we have 3 timers on the transmitting side. On the receiving side. Each time a MESSAGE_ID is received, we do not send but the corresponding MESSAGE_ID_ACK object in a separate ACK message immediately. Instead, we save the corresponding MESSAGE_ID_ACK object into buffers. The buffers are organized according to the destination address (different neighbors). We have k (# of neighbors) timers. When timing out, we have no choice but to send out an ACK message and include all MSG_ID_ACKs. Or if we can, we piggyback the MSG_ID_ACKs in a ordinary signaling message. 2019/1/16

Processing of Path message Here is some animation. My idea is to show the complexity of message processing. Let’s use Path message as an example, it is three levels of processing. First we process the common header and find out it is a Path message. Next we processing the Path message and figure out that we need to process SESSION object. Then we process SESSION object. In next slide, I’ll show the simulation result of the Path message. 2019/1/16

Processing of Path message — timing simulation It is the timing simulation of the processing of Path message. I roughly marked main operations. 2019/1/16

Implementation and simulation results Implementation results Device PCI core Resource Eq.Gates Max freq. XC2V3000 w/o PCI 12% 360,000 90MHz w/ PCI 21% 630,000 50MHz Simulation results (@50MHz) About the implementation result, if including PCI core we got from Xilinx, the maximum frequency is around 50MHz (according to Xilinx report). It is 90MHz without PCI core. About the simulation results, the processing times for different messages are different. But in order to fully pipeline the processing of messages, idle cycles are inserted if necessary. The three stages: receiving, processing, transmitting. Path Resv PathTear/ResvTear Clock cycles 40 32 19 2019/1/16

Outline Background and problem statement A subset of RSVP-TE signaling protocol Hardware-accelerated implementation Conclusions and future work 2019/1/16

Conclusions and applications Feasibility Yes, hardware-accelerated implementation of RSVP-TE is possible Performance 400,000 calls/sec, 7.2 s (@50MHz) 100x-1000x speedup vis-à-vis software implementations CHEETAH: Circuit-switched High-Speed End-to-End Transport Architecture (Opticomm 2003) File transfer application Set up a high-speed circuit (GbE) end-to-end carried on SONET over the wide-area Transmit a single file (5MB file on a Gb/s circuit needs only 40ms) Release the circuit Intense sharing of circuits Hence the high call handling volume Need for very short call processing times consider metro settings with a low prop. delay primary component of call setup delay: call processing delay the smaller the call setup delays, the smaller the files that can be handled with circuits greater the load, better the utilization Call handling rate is 400,000 calls/sec, per switch delay (including message receiving, processing, and transmitting) is 7.2 ns. 400K is not the reciprocal of 7.2 ms, that is because three stages are fully pipelined, so that every 2.4 ns the hardware accelerator can accept a new message. 2019/1/16

Thank you!  Please visit our website for more information http://eeweb1.poly.edu/networks/html-files/index.htm 2019/1/16