A RECONFIGURABLE ARCHITECTURE FOR MULTI-GIGABIT SPEED CONTENT-BASED ROUTING. James Moscola, Young H. Cho, John W. Lockwood

A RECONFIGURABLE ARCHITECTURE FOR MULTI-GIGABIT SPEED CONTENT-BASED ROUTING James Moscola, Young H. Cho, John W. Lockwood Dept. of Computer Scence and Engneerng Washngton Unversty, St. Lous, MO {jmm5, young, lockwood}@arl.wustl.edu ABSTRACT Ths paper presents a reconfgurable archtecture for hghspeed content-based routng. Our archtecture goes beyond smple pattern matchng by mplementng a parsng engne that defnes the semantcs of patterns that are parsed wthn the stream. Defnng the semantcs of patterns allows for more accurate processng and routng of usng any felds that appear wthn the payload of the packet. The archtecture conssts of several components, ncludng a pattern matcher, a parsng structure, and a routng module. Both the pattern matcher and parsng structure are automatcally generated usng an applcaton-specfc compler that s descrbed n ths paper. The compler accepts a grammar specfcaton as nput and outputs a parser n VHDL. The routng module receves control sgnals from both the pattern matcher and the parsng structure that ad n the routng of. We llustrate how a content-based router can be mplemented wth our technque usng an XML parser as an example. The XML parser presented was desgned, mplemented, and tested n a Xlnx Vrtex XCV2000E FPGA on the FPX platform. It s capable of processng 32-bts of per clock cycle and runs at 00 MHz. Ths allows the system to process and route XML messages at 3.2 Gbps.. INTRODUCTION Typcal routers use layers through 4 to route network. On the Internet, IP addresses are commonly used to route. However, such routng schemes requre packet senders to obtan the destnaton address before sendng the. Such nteracton ntroduces overhead at the applcaton level and places constrants on the scalablty and dynamcs of the network. Ths research was sponsored by the Ar Force Research Laboratory, Ar Force Materel Command, USAF, under Contract number MDA972-03-9-000. The vews and conclusons contaned heren are those of the authors and should not be nterpreted as necessarly representng the offcal polces or endorsements, ether expressed or mpled, of AFRL or the U.S. Government. As the Internet contnues to expand, researchers are startng to look at content-based routng as a mechansm to mprove upon and/or add new servces for managng the dstrbuton of. Content-based routng mproves upon the exstng Internet model by gvng users the freedom to descrbe routng schemes n the applcaton layer of the network. Content-based routers then nspect and nterpret packet payloads and route accordng to the content of the packet. One example of ths type of nteracton can be seen n publsh/subscrbe networks [, 2]. Users can subscrbe to nformaton that s nterestng to them by sendng hgh level descrptons to routers usng the applcaton layer (layer 7) of the packet. Content-based routers then nterpret the subscrpton packet content and route all messages wth matchng contents to the subscrber. Some examples for publsh/subscrbe networks nclude the routng of stock quotes, dstrbuton of weather reports, and streamng vdeo broadcasts. Content-based routng can also be used for applcatons such as load balancng n web server clusters [3], or routng of onlne transactons to the approprate shppng warehouse. It s ths class of content-based routng applcatons that s the focus of ths paper. To route based on values that appear n the payload, effcent methods for packet payload processng are needed. Carzanga, Rutherford, and Wolf presented a software based routng algorthm n [4]. However, due to the processng power requred by deep content nspecton, software approaches are unlkely to mantan the throughput of mult-ggabt networks. Ths can potentally lmt the adopton of content-based networks. As such we propose a reconfgurable hardware archtecture capable of ntellgent content nspecton. In ths paper we descrbe the mplementaton of a contentbased routng archtecture that has been mplemented n reconfgurable hardware. Our system performs much more than smple pattern matchng the archtecture takes the next evolutonary step n message content processng by mplementng a complete parser. Gven a grammar specfcaton, our parser archtecture s capable of understandng the

semantcs of and routng any message format. Our archtecture has been fully mplemented on the Feld-Programmable Port Extender (FPX) platform whch allows for rapd deployment and testng n ggabt-rate networks. The remander of ths paper s dvded nto the followng sectons. Secton 2 gves a bref descrpton of the mplementaton platform and supportng work. Secton 3 descrbes our approach and archtecture for content-based routng. Performance and area numbers are presented n secton 4. Secton 5 presents concludng statements. Data Packets Content-Based Router IP Processor Frame Processor Cell Processor Fg.. Content-based router n protocol wrappers Data Packets 2. BACKGROUND The hardware platform and modules used to mplement parts of our content-based router have been descrbed n prevous papers. Ths secton ncludes a short descrpton of that work, ncludng the FPX platform and a set protocol wrappers. 2.. Feld-Programmable Port Extender The FPX s a general purpose, reprogrammable platform that performs processng n FPGA hardware [5, 6]. As pass through the devce, they can be processed n the hardware by user-defned, reprogrammable modules. Hardware-accelerated processng enables the FPX to process at mult-ggabt per second rates, even when performng deep processng of packet payloads. Verson 2 of the FPX contans two FPGAs. A Xlnx Vrtex XCV600E FPGA called the Network Interface Devce (NID) routes nto and out of the FPX. It also controls the routng of to and from the applcaton FPGA. The Reconfgurable Applcaton Devce (RAD) s another FPGA, whch s confgured over the network to perform the customzed processng functons. The RAD s mplemented wth a large Xlnx Vrtex XCV2000E. The FPX also contans two banks of 36-bt wde Zero-Bus-Turnaround Statc RAM (ZBT SRAM) and two banks of 64-bt PC-00 Synchronous Dynamc RAM (SDRAM) whch provded ample space for off-chp storage.. 2.2. Protocol Wrappers To provde a hgher level of abstracton for packet processng, a lbrary of layered protocol wrappers was mplemented for the FPX [7]. They use a layered desgn and consst of dfferent processng crcuts wthn each layer. At the lowest level, a cell processor processes raw cells between network nterfaces. At the hgher levels, a frame processor reassembles and processes varable length frames whle an IP processor processes IP. Fgure shows the confguraton of our content-based router n the protocol wrappers. 3. CONTENT-BASED ROUTER ARCHITECTURE Our archtecture for content-based routng can route wth many dfferent formats. Instead of routng based on strngs that appear wthn the packet, our archtecture acheves a hgher level of understandng of each packet by fully parsng the entre payload. Packet formats to be routed are specfed usng grammars. In ths paper we llustrate how our archtecture s confgured and used to route XML. Snce ts ntroducton, XML has become the format of choce for exchangng nformaton over networks. Addtonally, we choose XML because there are many grammars already avalable for XML messages n the form of document type defntons (DTD). <!ELEMENT card (routekey, name, ttle?, phone?)> <!ELEMENT routekey (#PCDATA)> <!ELEMENT name ((frst, last) (last, frst))> <!ELEMENT frst (#PCDATA)> <!ELEMENT last (#PCDATA)> <!ELEMENT ttle (#PCDATA)> <!ELEMENT phone (#PCDATA)> Fg. 2. DTD for example mplementaton STRING [a-za-z0-9-]+ %% card: "<card>" routekey name ttle phone "</card>" routekey: "<routekey>" route "</routekey>" route: routefrst routelast routefrst: "frst" routelast: "last" name: "" namen "" namen: namefl namelf namefl: frstfl lastfl namelf: lastlf frstlf frstfl: "<frst>" STRING "</frst>" lastfl: "<last>" STRING "</last>" lastlf: "<last>" STRING "</last>" frstlf: "<frst>" STRING "</frst>" ttle: "<ttle>" STRING "</ttle>" ε phone: "<phone>" STRING "</phone>" ε %% Fg. 3. Lex/Yacc style grammar for example mplementaton Fgure 2 shows an example DTD whch represents a smple busness card. It contans felds for a frst name, a last name, a ttle, and a phone number. Addtonally, the DTD

contans a routekey feld whch ndcates whch feld the router should use for routng. We wll use ths DTD throughout the remander of the paper to llustrate our content-based router archtecture. Pror to generatng the hardware to parse the DTD n fgure 2, we frst convert the DTD nto a Lex/Yacc style grammar. The Lex/Yacc style grammar s shown n fgure 3. Ths grammar s then passed nto a custom compler whch automatcally generates the VHDL requred for the dynamc components of the archtecture. The dynamc components nclude a pattern matcher and a parsng structure. These components have a statc nterface whch allows them to ntegrate easly wth the statc components of the archtecture. The layout of the man components of our archtecture, ncludng the pattern matcher, the parsng structure, and the routng module, s shown n fgure 4. The remander of ths secton wll descrbe each of these components n more detal. 32 Patterns Pattern Matcher Token FIFO Grammar Parsng Structure Routng Module Fg. 4. Content-based router archtecture 3.. Pattern Matcher Data enter our content-based router va the layered protocol wrappers. The frst stage n processng each packet for routng s pattern matchng. Our modular desgn, allows a varety of technques to be used for pattern matchng. For ths mplementaton, we use a modfed decoded character ppelne [8, 9] whch has been scaled to accept a four character wde (32-bt) nput. Scalng s acheved by replcatng the ppelne untl there s one ppelne for each character n the nput wdth. A detaled block dagram of the decoded character ppelne s shown n fgure 5. The scaled ppelne receves four characters (32-bts) per clock cycle from the layered protocol wrappers. Characters, 2, 3, and 4 are passed nto ppelne algnments 3, 2,, and 0 respectvely. Before enterng the ppelne regsters, characters are passed nto an 8-to-256-bt decoder. The 256-bt output represents a sngle bt lne for each of the 256 possble ASCII characters. Ths decreases the routng resource requred for strng detectors. The decoded character lnes 32 [32:24] [23:6] [5:8] [7:0] 8-bt to 256-bt decoder Pattern Matcher One copy for each algnment b c a m0 256-bt decoded regsters m m2 m3 m4 Algnment 3 Algnment 2 Algnment Algnment 0 Fg. 5. Detaled vew of the pattern matcher ppelne are passed nto the ppelne regsters as llustrated n fgure 5. The ppelne can detect patterns that are less than or equal to the length of the ppelne. Addtonally, the ppelne only needs to be as long as the longest pattern n the grammar The actual pattern matchng s executed by a seres of strng detectors. A strng detector s generated for each of the patterns n the nput grammar. For our example grammar n fgure 3 there are 7 unque patterns: <card>, </card>, <routekey>, </routkey>, frst, last,,, <frst>, </frst>, <last>, </last>, <ttle>, </ttle>, <phone>, </phone>, and STRING. Each of these patterns can be detected by ANDng together the approprate bts from the decoded character ppelne. Snce we are usng a scaled ppelne, we need to check for the presence of a pattern at each possble startng algnment. A pattern s detected f t s found at any one of the four possble startng algnments. Fgure 6 llustrates the logc requred to match the patten <card>. The notaton shown n fgure 6 s Regster[Algnment][Character]. For example, m[0][c] represents the c character bt of regster m n algnment 0. A sngle bt lne s output from the pattern matcher to the parser structure for each of the strng detectors. m[][<] m[0][c] m0[3][a] m0[2][r] m0[][d] m0[0][>] Strng Detectors m[2][<] m[][c] m[0][a] m0[3][r] m0[2][d] m0[][>] m[3][<] m[2][c] m[][a] m[0][r] m0[3][d] m0[2][>] m2[0][<] m[3][c] m[2][a] m[][r] m[0][d] m0[3][>] Fg. 6. Detaled vew of a strng detector pattern(0) "<card>" pattern() pattern(n)

3.2. Parsng Structure The parsng structure gves the content-based router a hgher level of understandng than just smple pattern matchng. It defnes the semantcs of patterns as they are detected by the pattern matcher. The hardware logc for the parsng structure s determned from the nput grammar (or grammars). The producton lst of a grammar defnes all of the possble transtons for a grammar. Whle processng, the parser mantans the state of the grammar allowng t to determne whch patterns can occur next. For each termnal symbol FIRST[ Z] { Z} repeat For each producton X Y Y f Y Y then nullable[ X ] true For each from to k, each j from + to k f Y Y then FIRST[ X ] FIRST[ X ] FIRST[ Y ] f Y then FOLLOW[ Y ] FOLLOW[ Y ] FOLLOW[ X ] f Y + + k are all nullable (or f k= 0) Y are all nullable (or f = ) Y are all nullable (or f =k) k j Z are all nullable (or f + =j) then FOLLOW[ Y ] FOLLOW[ Y ] FOLLOW[ Y ] untl FIRST, FOLLOW and nullable no longer change k j routed to the nput of other pattern regsters. Transtons are determned from the producton lst of the grammar usng the well known FIRST and FOLLOW set algorthms (fgure 7) [0]. The FIRST algorthm s used to determne the startng pont of the grammar. The FOLLOW set algorthm traverses through the producton lst to fnd sets of patterns that can follow any other patten n the grammar. The resultng sets are then used to map the output of pattern prmtves to the nput of each of the pattern prmtves lsted n ts FOLLOW set. When there s more than one connecton to the nput of a pattern prmtve, an OR gate s used to combne the sgnals nto a sngle bt nput. Fgure 8 shows the FOLLOW sets for each of the patterns n our example grammar n 3. The resultng parsng structure for our example mplementaton s llustrated n fgure 9. <card> <routekey> frst P2 start of packet last P0 P P3 <frst> STRING </frst> <last> P6 P7 P8 P9 <last> 2 STRING2 </last> 2 <frst> 2 P2 P3 P4 P5 <ttle> STRING </ttle> P8 P9 P20 P2 <phone> STRING </phone> P22 P23 P24 Fg. 7. FIRST and FOLLOW set algorthms </routekey> P4 STRING P0 STRING2 P6 Non-termnals <card> <routekey> frst, last </routekey> <frst>, <last>, <frst> 2, <last> 2, <ttle>, <phone> STIRNG FOLLOW Set <routekey> frst, last </routekey> <frst>, <last> STRING </frst>, </last>, </frst> 2, </last> 2, </ttle>, </phone> P5 Parsng Structure </last> P </frst> 2 P7 </card> XML vald Fg. 9. Detaled vew of the parsng structure P25 </frst> </last> 2 </last>, </frst> 2 </ttle> </phone> <last> <frst>2 <ttle>, <phone>, </card> <phone>, </card> </card> Fg. 8. FOLLOW sets for example mplementaton In our parsng structure, each pattern s represented usng a smple prmtve that conssts of a sngle regster and a sngle AND gate. The nputs to each of the AND gates are the outputs of the pattern matcher. The output of each AND gate represents a transton n the state of the grammar and s The generated parsng structure processes one pattern at a tme. At the start of a packet, the startng regster (regster P0 n fgure 9) s set. As are processed, the parsng structure receves a sgnal from the pattern matcher for each pattern that s found. These sgnals allow the parsng structure to traverse through the grammar and mantan the semantcs of the stream. Durng processng, all sgnals from the pattern matcher are sent downstream to the routng module accompaned by the state of the parsng structure. The state of the parsng structure ndcates where n the grammar each pattern s found. Knowng where n the grammar a pattern s found allows the routng module to make more ntellgent decsons.

3.2.. Valdatng XML Input To avod routng nvald or malformed XML messages, our content-based router valdates all XML messages pror to routng them. As shown n fgure 9, an XML vald sgnal s asserted when the parsng structure successfully traverses through the entre grammar. The XML vald sgnal s forwarded to the routng module. 3.3. Routng Module The routng module (fgure 0) s responsble for modfyng the IP header of each packet to route the packet to the approprate destnaton. As enter the content-based router they are buffered n the routng module untl the packet has been completely processed. Pror to routng any packet, the routng module verfes that the packet s the correct format. Most mportantly, ths entals valdatng the XML message. XML messages that do not strctly adhere to the grammar provded wll not be rerouted by the module. Optonally, the module can also check for specfc IP address and port ranges pror to routng. 32 Packet Buffer IP vald Port vald XML vald reroute packet output controller name n the XML message. These values stay enabled for the duraton of the packet. The frststring value s enabled by the parsng structure when ether regster P7 or regster P6 are set and a STRING pattern s detected by the pattern matcher. Smlarly, the laststring value s enabled when ether regster P0 or P3 are set and a STRING pattern s detected. The frststring and laststring values are only vald for a sngle clock cycle. Durng ths clock cycle, the frst character of the STRING pattern (the route character) s forwarded to the routng module and stored. Ths value s then used to address a routng table whch determnes the next destnaton of the packet beng processed. Once a packet has been fully processed, the output controller reads the packet from the packet buffer for output. If the packet contans a vald XML message (and optonally, IP address and port ranges), then the IP header s rewrtten wth the new destnaton address as t s output. 4. IMPLEMENTATION The content-based router descrbed n ths paper was fully mplemented and tested on the Xlnx Vrtex XCV2000E FPGA on the FPX platform. The FPX was ntegrated nto a Global Velocty GVS-000 chasss. A photograph of an FPX and the GVS-000 chasss s shown n fgure. routefrst frststring routelast laststring route character 8 D E Q route dest. IP Routng Module Route Table Fg. 0. Detaled vew of the routng module For our example mplementaton, we want to route based on the frst character of ether the frst name or the last name specfed n the XML message. The routekey value specfes whch name to use for routng. A seres of control sgnals receved from the pattern matcher and the parsng module allow the routng module to route accordngly. These control sgnals are descrbed below and can be seen n fgure 0. The value routefrst s enabled by the parsng structure when regster P2 s set and the pattern frst s detected by the pattern matcher. Ths value ndcates that the packet should be routed accordng to the frst name n the XML message. Smlarly, the value routelast s enabled when regster P3 s set and the pattern last s detected. It ndcates that the packet should be routed accordng to the last Fg.. FPX and GVS-000 chasss The GVS-000 has two bdrectonal ggabt nterfaces for passng traffc nto the FPX. To test our content-based router archtecture, each of the ggabt nterfaces on the GVS- 000 were connected to a dfferent host machnes. One machne was used to generate and send XML messages nto the content-based router. The second machne was used as a recever for routed messages. Snce only two machnes were used for our experments, we routed XML messages to dfferent ports on the recevng machne based on the message content. Both Ethereal and a small counter applcaton were used to verfy XML messages arrved at the correct destnaton port on the recevng machne. XML messages were generated on the sendng machne va the small test applcaton shown n fgure 2. The test applcaton creates XML messages usng the values specfed n the text felds and sends them as UDP nto

the content-based router. Addtonally, the test applcaton can randomly generate and send a specfed number of XML messages nto the content-based router. An example XML message s shown n fgure 3. Fg. 2. Test applcaton nterface routng archtecture means we can ft much larger and/or many more grammars on the FPGA. 5. CONCLUSION In ths paper we presented a content-based router applcaton that has been mplemented wth Feld Programmable Gate Arrays. The content-based router conssts of a pattern matcher, a parsng structure and a routng module. The pattern matcher and the parsng structure are automatcally generated by a custom compler that accepts grammars as nput. The routng module receves control sgnals from the pattern matcher and the parsng structure that ad n the routng of the packet. The router s wrapped n a set of layered protocol wrappers that handle all the requred protocol processng. The content-based router was mplemented and tested n the Xlnx Vrtex XCV2000E FPGA on the FPX platform. The archtecture was placed and routed at 00 MHz and can process XML messages at 3.2 Gbps. Wthout the layered protocol wrappers, the content-based router archtecture s capable of runnng at over 200 MHz and processng XML messages at over 6.4 Gbps. <card> <routekey>frst</routekey> <frst>john</frst> <last>doe</last> <ttle>ctzen</ttle> <phone>555-555-5555</phone> </card> Fg. 3. XML packet contents 4.. Area and Performance For ths applcaton our maxmum clock frequency s lmted to 00 MHz by the layered protocol wrappers. At ths speed our content-based router can acheve a maxmum throughput of 3.2 Gbps. Wthout the protocol wrappers, the core of the content-based router archtecture can acheve frequences over 200 MHz. At ths speed the content-based router can route XML messages at over 6.4 Gbps. The content-based router requres 375 slce flp flops, approxmately 9% of the avalable flp flop resources. The archtecture requres 3058 4-nput LUTs, approxmately 7% of the avalable LUT resources. The layered protocol wrappers alone requre 2623 flp flops and 296 4-nput LUTs. Ths s approxmately 6% and 5% of the avalable flp flop and LUT resources respectvely. The core of the content-based router (wthout the protocol wrappers) requres approxmately 28 slce flp flops and 862 4-nput LUTs. Ths s approxmately 2.9% and 2.2% of the avalable flp flop and LUT resources respectvely. Such a small space requrement for the core of the 6. REFERENCES [] A. Carzanga, D. S. Rosenblum, and A. L. Wolf, Desgn and evaluaton of a wde-area event notfcaton servce, ACM Transactons on Computer Systems, vol. 9, no. 3, pp. 332 383, Aug. 200. [2] D. S. Rosenblum and A. L. Wolf, A desgn framework for nternet-scale event observaton and notfcaton, n Proceedngs of the Sxth European Software Engneerng Conference (ESEC/FSE 97), M. Jazayer and H. Schauer, Eds. Sprnger Verlag, 997, pp. 344 360. [3] Chu-Sng Yang and Mon-Yen Luo, Effcent Support for Content- Based Routng n Web Server Clusters, n Proceedngs of USENIX Symposum on Internet Technologes & Systems (USITS), Boulder, CO, Oct. 999. [4] A. Carzanga, M. J. Rutherford, and A. L. Wolf, A routng scheme for content-based networkng, n Proceedngs of IEEE INFOCOM 2004, Hong Kong, Chna, Mar. 2004. [5] J. W. Lockwood, An open platform for development of network processng modules n reprogrammable hardware, n IEC Desgn- Con 0, Santa Clara, CA, Jan. 200, pp. WB 9. [6] Feld Programmable Port Extender Homepage, Onlne: http://www.arl.wustl.edu/projects/fpx- /reconfg.htm, Aug. 2000. [7] F. Braun, J. W. Lockwood, and M. Waldvogel, Layered Protocol Wrappers for Internet Packet Processng n Reconfgurable Hardware, IEEE Mcro, vol. Volume 22, no. Number 3, pp. 66 74, Feb. 2002. [8] Z. K. Baker and V. K. Prasanna, A Methodology for Synthess of Effcent Intruson Detecton Systems on FPGAs, n IEEE Symposum on Feld-Programmable Custom Computng Machnes. Napa Valley, CA: IEEE, Aprl 2004. [9] R. Sdhu and V. K. Prasanna, Fast Regular Expresson Matchng usng FPGAs, n IEEE Symposum on Feld-Programmable Custom Computng Machnes. Napa Valley, CA: IEEE, Apr. 200. [0] A. Aho, R. Seth, and J. Ullman, Complers: Prncples and Technques and Tools. Addson-Wesley, 986.