The Architecture of a Gb/s
`Multimedia Protocol Adapter
`
`Erich Rutsche
`IBM Research Division,
`Zurich Research Laboratory
`Saumerstrasse 4, 8803 Rischlikon, Switzerland
`
`Abstract
`In this paper a new multiprocessor—based communication adapter is presented. The adapter architec-
`ture supports isochronous multimedia traffic and asynchronousdata traffic by handling them separate-
`ly. The adapterarchitecture andits components are explained andtheprotocolprocessing performance
`for TCPIIP andfor ST-IIis evaluated. The architecture supports the processing ofST-Hat the network
`speed of622 MbI/s. The calculated performancefor TCPHP is more than 30000 segments/sec. Thear-
`chitecture can be extended to protocol processing at one Gbis.
`
`Keywords: Multimedia Communication Subsystems, Network Protocols; Parallel Protocol
`Processing
`
`1. Introduction
`Asdata transmission speeds have increased dramatically in recent years,the processing of protocols has
`becomeoneof the major bottlenecks in data communications. Current experimental networks provide a
`bandwidth in the Gb/s range. New multimedia applications require that networks guarantee the quality
`of service of bulk data streams for video or HDTV. The protocol processing bottleneck has been over-
`come by dedicated communication subsystems which off—load protocol processing from the worksta-
`tion. Many of such communication subsystems proposedin the literature are multiprocessorarchitec-
`tures [Braun 92, Jain 90, Steenkiste 92, Wicki 90]. In this paper we present a new multiprocessor
`communication subsystem architecture, the Multimedia Protocol Adapter (MPA), which is based on
`the experience with the Parallel Protocol Engine (PPE) [Kaiserswerth 92] and is designed to connectto
`a 622 Mb/s ATM network. The MPAarchitecture exploits the inherent parallelism between the trans-
`mitter and receiver parts of a protocol and provides support for the handling of new multimedia proto-
`cols,
`The goal ofthis architecture is to speed up the handling of multiple protocol stacks and of multimedia
`protocols suchasthe Internet Stream Protocol (ST—//) [Topolcic 90]. Multimedia traffic often requires
`isochronous transmission in contrast to conventional asynchronous traffic for file transfer or for remote
`procedurecall. To guarantee the isochronous processing of multimedia data streams, the asynchronous
`and isochronoustraffic are handled separately. A Header Parser scans incoming packets, detects the
`headerfields and extracts the header information. This informationis used to separate isochronous and
`asynchronoustraffic andto split the header and the data portionsof a packet. Dedicated header and data
`memories are used to store the header and data portions of a packet. The separation of receiver, trans-
`mitter and the dedicated memories decreases memory contention.
`
`ACM SIGCOMM
`
`-59-
`
`Computer Communication Review
`
`DEFS-ALA0010789
`Alacritech, Ex. 2031 Page 1
`
`Alacritech, Ex. 2031 Page 1
`
`

`

`In Section 2 the concepts of the MPAarchitecture are presented. Section 3 explains protocol processing
`on the MPA.In Section 4 the performanceof the MPAis evaluated by adapting the measurementsof our
`TCP/IP implementation on the PPE to the MPA architecture. Thelast section gives the conclusions.
`
`2. Architecture
`
`The architecture of the MPA is based on our experiments with the PPE [Kaiserswerth 92],[Rtitsche 92].
`The PPEis a four—processor system based on the transputer T425 with a network interface running at
`120 Mb/s. On the separate transmit and receive side two processors, the host system and the network
`interface use a shared memory forstoring and processing protocol data. Transmit and receive side are
`only connected via serial transputer links.
`
`2.1 Concept
`Theprotocol processing requirements of multimedia protocols are very different from the requirements
`of traditional transport protocols. Isochronous multimedia traffic may require the processing of bulk
`data streamswith low delay and low jitter but may accept bit errors or packet loss. Asynchronoustraffic,
`such asfile transfer or remote procedure call, requires more moderate throughputbuttolerates noer-
`rors. Ina file transfer betweena file server and a client the throughputis limited by the I/O bus and the
`disk speed. Errors in the data are not acceptable, whereas a bit-error in uncompressed video is not vis-
`ible.
`
`To guarantee the requirements of multimedia connections the processing of multimedia data must be
`separated from the processing of asynchronous data. A Header Parser detects the connection to which
`an incoming packet belongs. Multimedia packets are then forwarded to dedicated multimedia devices
`while other packets go through normal protocol processing.
`
`Protocol processing mustbe done in software to handle a multitude of protocols. Only functionsthatare
`commontoall or mostof the protocols are implemented in hardware. The MAClayer for ATM andthe
`ATM Adaptation Layer (AAL) must be implemented in hardware or firmware to achieve the full net-
`work bandwidth of 622 Mb/s.
`
`Our measurements of TCP/IP on the PPE have shownthat the processors were not equally loaded be-
`causeof the different processing requirementsof the protocol layers and becauseof the very high costs
`of the memory operations [Riitsche 92]. The loose coupling via serial links between the receive and a
`transmit part had only minor impact on the performance. An optimal speedupof 1.7 was calculated for
`two processors. Therefore we chose a two-processor architecture for the MPA. One processor on the
`transmit side is connected via serial links to one processor on the receive side. The processors are sup-
`ported by an intelligent Direct Memory Access Unit and dedicated devices for header parsing and
`checksumming. The memoryofbothparts is split into a header memory and a data memory to lower
`memory contention. The two halves of the MPA are only connected by serial messagelinks.
`
`2.2 Main Building Blocks
`
`The MPAis split into two parts, a receiver and a transmitter, as shown in Figure 1. The various compo-
`nents and their function are presented in the following.
`
`ACM SIGCOMM
`
`-60-
`
`Computer Communication Review
`
`DEFS-ALA0010790
`Alacritech, Ex. 2031 Page 2
`
`Alacritech, Ex. 2031 Page 2
`
`

`

`
`
`
`
`Media Access Control Unit (MAC
`
`
`
`al ®
`
`Media Access Control Unit (MACU)
`
`
`
`aon ed ao. ee ——
`;
`=
`i
`
`
`
`c
`=
`3
`q
`
`
`
`
`
`
`
`
`Checksum
`Generator (CG)
`
`
`
`
`
`
`ys
`
`
`
`
`>
`Protocol
`Protocol
`[*"
`
`|
`;
`Processor
`Processor
`d
`
`
`
`
`Direct
`"Serial |Links L_ SS
`
`
`
`Device|Sole F— [aus] Bevie
`
`Attachement a
`Controller Jattachement
`Workstation Bus
`
`Header are HP)
`
`_
`
`a
`
`|
`l a
`a | =
`}2
`D
`
`|
`
`o
`
`«a@- Data
`
`&
`
`-
`
`ns.
`Te
`$F
`O85
`3
`°
`
`
`
`a
`
`Checksum
`_Generator (CG)
`
`—— |
`
`
`
`
`
`|
`Figure 1. MPA Architecture
`Media Access Control Unit (MACU): The MPAis designed to be connected to any high-speed net-
`work. The design of the MACis beyond thescope of this paper. [Traw 91] for example describes an
`interface to the Aurora ATM network.
`HeaderParser (HP): The HPis similar to the ProtoParser! [Chin 92]. The HP detects on the fly the
`protocol type of an incoming packet and extracts the relevant header information. This information is
`forwarded to the DMA Unit and the Checksum Generator.
`
`Workstation Bus
`
`ChecksumGenerator (CG): The CG istriggered by the HP to calculate the appropriate checksum or
`Cyclic Redundancy Check (CRC)for the packet onthe fly. The algorithms are implemented in hard-
`ware and selected by decoding the HP signal]. On the sender side the CGis triggered by the DMA unit.
`[Birch 92], for example, describes a programmable CRC generator whichis capable of processing 800
`Mb/s.
`The Protocol Processor T9000: The selection of the inmos? T9000 [inmos 91] is based on our good
`experience with the transputer family of processors in the PPE. The mostsignificant improvements of
`the T9000 over the T425 for protocol processing are faster programmable link interfaces, a faster
`memory interface, and a cache. The serial message passing link provides a transmission speed of 100
`1.
`ProtoParser is a trademark of Protocol Engines, Inc.
`2.
`inmos is a trademark of INMOS Limited.
`
`ACM SIGCOMM
`
`Computer Communication Review
`
`DEFS-ALA0010791
`Alacritech, Ex. 2031 Page 3
`
`Alacritech, Ex. 2031 Page 3
`
`

`

`Mb/splusa setof instructions to use the links for control purposes. The peek and pokeinstructionsissue
`read and write operations in the address space of the second transputer connected to the other end of the
`link. These commands allow distributed ’shared memory’ between transputers. Two transputers may
`allocate a block of memoryat identical physical addressesin their local memory. Whenever a value is
`written into the local copy of the data structure, the address of the variable and its value are also sent via a
`control link to the second transputer.
`
`The Memories: The memory is split into dedicated parts for each flow of data through the MPA to
`lower memory contention and to provide high bandwidth to those componentsthat access the memory
`most. The following memory split is used:
`
`Header memory: stores the protocol headers. Fast static memory operating at cache speed is used to
`avoid wait cycles.
`
`Data memory: stores the data part of the packets. Inexpensive video memory (VRAM)is used. Theseri-
`al port of the VRAM provides guaranteed access via the DMA Unit to the network. The parallel
`port of the VRAMis used in normal processing by the Bus Controller only, The processor can
`accesses the parallel port, e.g. for exception handling.
`
`Local memory: stores the program code of the processor and the control information of the connections.
`
`Multimedia FIFO: stores multimedia data and is the interface to a multimedia device. It can be con-
`trolled by the processorfor synchronization with asynchronousdata streams. Multiple multime-
`dia FIFOs can be arranged in parallel.
`
`The design does not employ physically shared memory between the transmitter and the receiver, be-
`cause the implementation costs are too high compared to a software implementation using transputer
`links.
`
`Memory Access; Processor to
`
`__| Memory Type
`
`
`
`Average Access Time
`
`
`
`
`
`
`
`
`
`
`
`Table 1. Memory Access Time
`
`Direct Memory Access Unit (DMAU): The DMAUdirects the in— and outgoing data streamsto the
`correct destination. The DMAUsplits an incoming packet into its header and data part and movesthe
`parts to the respective memories. A pointer to the header structure is written to the receive queue. To
`send a packet the DMAU gathers the data from the data memory and the header from the header
`memory. For multimedia traffic the data are gathered from the multimedia FIFO. The memory buffers
`are handled in a linked list format. The DMAUhandlesthis linked list in hardware and thereby off-
`loads part of the memory managementfrom the protocol processor.
`
`Bus Controller (BC): The BC is a programmable busmaster DMAcontroller. It provides a small FIFO
`anda table for DMA requests. The FIFO containsa pointerto the linked list of source data and a connec-
`tion identifier. The BC determinesthe destination memory address through the connectionidentifier in
`the table. Thelist format is the same for the BC and the DMAU. In the transmit BC the host writesto the
`
`ACM SIGCOMM
`
`-62~-
`
`Computer Communication Review
`
`DEFS-ALA0010792
`Alacritech, Ex. 2031 Page 4
`
`Alacritech, Ex. 2031 Page 4
`
`

`

`FIFO andtheprotocol processorto thetable. In the receive BC the protocol processorwrites to the FIFO
`and the host to the table.
`
`2.3 Packet Processing
`
`Packets are processed in a hardware pipeline which runs at network speed. The pipelined packetproces-
`sing is shown in Figure 2.
`
`Receiver
`The MACUreceivescells from the ATM network,processes the AAL,andtriggers the receivepipeline
`to start. The receive pipeline is run by the DMAU. The HP and the CG processthe data as they are co-
`pied from the MACUto thedestination address in the memories or to the multimedia FIFO, The HP
`extracts the relevant header information from the packet and forwards the information to the DMAU
`and the CG. The CG usesthis information to detect which checksum or CRCit must calculate. The CG
`calculates the checksum onthefly as the packet is copied by the DMAUand forwardsthe result to the
`DMAU. The DMAUusesthe information generated by the HP to determine the format and the connec-
`tion of the packet. For a multimedia connection the DMAU removesthe header from the packet and
`writes the data part to the Multimedia FIFO.
`
`Transmit Pipeline
`
`
`
`Multimedia
`Header
`Data
`
`HP
`CG
`DMAU
`
`parse header
`w..22..2.24-44244 eee). 2. we kk ee le
`ad Aare
`Neck
`sui
`
`header
`write data
`
`
`Receive Pipeline Header
`
`Data
`
`Multimedia
`
`e
`write data
`header
`write
`
`DMAU.....2L... Pe
`
`calculate , write checksum
`...2e eee eee ee”SS)
`
`CG
`
`Figure 2. Pipelined Packet Processing
`
`For asynchronoustraffic the DMAU writes a structure to the header memory which holds the header,
`the header information extracted by the HP, the checksum calculated by the CG, and the pointer to the
`data in data memory. The data part of the packet is written to the data memory. The DMAU writes a
`pointerto the headerstructure to the receive queue. The protocol processor is then responsible for pro-
`cessing of the headerstructure. The addressesof free buffers in header and data memoryare obtained
`from a linkedlist of free buffers.
`
`ACM SIGGCOMM
`
`—63-
`
`Computer Communication Review
`
`DEFS-ALA0010793
`Alacritech, Ex. 2031 Page 5
`
`Alacritech, Ex. 2031 Page 5
`
`

`

`If the HP does notrecognize a packet headerthe entire packet is written to the data memory.In this case,
`the protocol processor performs the processing of the packet header in data memory. For anew connec-
`tion the protocol processor builds up the connection and programs the HP to recognize the header.
`
`Sender
`Onthe transmit side the protocol processor builds the layered protocol header in the header memory.It
`builds a structure which holdsthe pointers to the header and to the data, the length of the header and
`data, and the connection type. This structure is written to the send queue. The DMAUrunsthe send
`pipeline. It interprets the structure and forwards the connection type to the CG. The CG calculates the
`checksum onthefly as the packet is written to the MACU memory. In the MACUthe packets are stored
`to process the AAL and to segment the AAL frame into ATM cells. Once the CG hasfinished,it writes
`the checksum to its position in the packet frame and triggers the MACU to send the packet. Once the
`packet is sent, the DMAUappendsthe buffers to the corresponding free—lists.
`
`3. Protocol Processing
`
`3.1 Transport Protocol Stacks
`
`Transport protocol processing on the MPAin the example of TCP/IP is shownin Figure 3. The socket
`layeris split into a lower half serving TCP and an upperhalf which interfaces to the application. A more
`detailed description of our parallel TCP/IP implementation can be found in [Riitsche 92].
`
`Sending a packet: The send data are in a buffer allocated on the host. The application creates a socket
`and establishes a TCP/IP connection. The socketsend call triggers the write process which copies the
`data to the MPA and gives the control over the data toxtask. The xtask processis then responsible
`for the transmission and possible retransmissionsof the data. It builds the TCP packet and forwardsthe
`pointer to the packet to ip_send. Herethe IP headeris placed in front of the TCP segment. Then the
`pointer to the packet is written to the send queue and the DMAUsendsthe packetvia the MACUto the
`network.
`
`Receiving a packet: Uponreceipt of a packet the DMAUwrites the pointer to the packet to the receive
`queue. ip_demux reads the receive queue, checks the headerand,if no error or exception occurred,
`forwards the packet to tep_recv, or else to Lemp_demux. The tep_recv process analyzes the
`TCP header andcalls the appropriate handler function for a given protocolstate. To send an acknowl-
`edgement or a control packet tep_recv uses a Remote Procedure Call (RPC) to the transmitside.
`Correctly received packets are appendedto the receive list. rtagk forwards the received segmentsto
`the application process whichis blocked in the socket receive procedure. This procedurethenfills the
`user buffer with data from the receive list.
`
`3.2 Multimedia Protocols
`
`For multimedia traffic often real-time data and continuous data streams are required. ST-II is a good
`example ofa protocol that supports this typeoftraffic. After a connection has beenset up, the reception
`of data packets requires only the detection of the connection and the calculation of the header checksum,
`For sending, the header can be built only once in the header memory andthen usedfor all the data pack-
`ets of the connection. These functionsare done in a hardwarepipeline by the HP and the CG (see Figure
`2). The DMAUscatters and gathersthe header and the data withoutany interaction of the protocol pro-
`
`ACM SIGCOMM
`
`-64-
`
`Computer Communication Review
`
`DEFS-ALA0010794
`Alacritech, Ex. 2031 Page 6
`
`Alacritech, Ex. 2031 Page 6
`
`

`

`Application
`
`Upper
`Socket Layer
`Lower
`
`Access Conitro!
`
`Transmission
`gontrol
`rotocol
`
`Internet
`Protocol
`
`Media
`
`Figure 3. Parallel TCP/IP Implementation
`
`cessor. Therefore realtime processing of ST—U at the network speed of 622 Mb/sis possible. The inter-
`action of the processoris only required to handle the Stream Control Message Protocol (SCMP), which
`is responsible for creating and keeping mostof the state in a ST-II protocol connection.
`
`4. Performance Estimation
`
`4.1 The Method
`The measurements of the TCP/IP implementation on the PPE were used and adapted to the MPAarchi-
`tecture [Riitsche 92], The execution times of program segments accessing local memory Tigcalmem and
`data memory Tiatamem are calculated from the execution times on the PPE minusthe time saved by the
`hardware devices replacing software functions. These execution times are multiplied by a speedup fac-
`tor S, which is determined by the memorytiming andthe faster processor, and summedto get the execu-
`tion time Tyzp4 on the MPA.
`(1)
`TPA = Thocalmem * Stocalmem + Tgatamem * Ssharedmem
`
`This approachis valid for protocol processing because most operations are memoryoperationsto build
`a header or to compare header data with expected data in a control block. The control information is
`built with simple arithmetical and logical operations such as add, multiply, and, or etc.
`
`4.2 Cost of Basic Operations
`The transputer T9000 is downwards compatible with the T425 used in the PPE. The main differences
`are a higher link speed of 100 Mb/s, a sustained performance of more than 70 MIPSanda peak rate of
`
`ACM SIGCOMM
`
`-65-
`
`Computer Communication Review
`
`DEFS-ALA0010795
`Alacritech, Ex. 2031 Page 7
`
`Alacritech, Ex. 2031 Page 7
`
`

`

`200 MIPS. A function call or process switch costs less than 1 ys. The sustained MIPSrate improves the
`performanceat least seven times for the simple protocol processing operations. The memory functions
`are determined by the memory access time shown in Table 1. The access time to the header memory
`decreases by a factor of 19, the access time to the data memoryby a factor of 9.5. Therefore the full
`powerof the processorcan be utilized, and the typical speedup factor !/19 [inmos 91] can be assumed for
`Sdatamem. The speedup factor to the local memory is determined by the processor speedup, because the
`local memory and the cache provide an optimal memory interface to the processor. We assumea conser-
`vative speedup factor of Sjocaimem = '/7 for the local memory.
`The costs of basic operations for protocol handlingare listed in Table 2. The connection detection and
`the calculation of a CRC or a checksum are implementedin hardware. These operations run at network
`speed as the data is clocked in from the MACU. The T9000 improvesthe implementationofthe distrib-
`uted shared memory, becausethe peek and pokecalls are already implemented in the microcode. There-
`fore the costs of the distributed shared memory’are only the issuing©ofa Peekor poke instruction.
`
`
`Numberof Processor struction
`esisee
`Linked List addiremove ao
`
`Distributed shared memory
`300 + size[word] * 460
`
`
`read/write
`
`
`
`
`Connection detection
`0 (implemented in hardware)
`network speed
`
`
`Checksum/CRCcalculation
`0 Gmplemented in hardware)
`
`
`Table 2. Cost of Basic Operations
`
`4.3 TCP/IP Performance
`
`The performance of TCP/IP is evaluated using the measurements of our TCP/IP implementation on the
`PPE. The TCPstack,the socket layer and a test application run on the MPA. Thecostof the single pro-
`cesses of TCP/IP is calculated using (1). Table 3 lists the execution times on the PPE and the calculated
`execution times on the MPA.In the PPE implementation of the IP processes 60% of the accesses go to
`the shared memory, in tcp_send 47% and in tep_recv 10%. In the MPA architecture all of these
`accesses are replaced by accesses to the header memory. In the user_task and the ip_intrave
`most processing is replaced by the list handling in the DMAUand the BC. Howeverthe write process is
`still needed to control the send queue. All copy operations are implemented in the BC. The ip_demux
`process is supported by the HP, which extracts the header information.
`
`ACM SIGCOMM
`
`—-66—
`
`Computer Communication Review
`
`DEFS-ALA0010796
`Alacritech, Ex. 2031 Page 8
`
`Alacritech, Ex. 2031 Page 8
`
`

`

`
`
`Process(Procedure) onReceiver
`sa | “sa
`
` a
`
`i ,
`17+ 0.Sed
`
`
`
`
`driver_send
`AccesstoSharedMemory (pokecall)
`
`
`18.6+2)dus/word
`Table 3. Process Execution Times
`
`0.3+0.ae
`
`
`
`
`
`The TCP/IP process pipeline for bidirectional traffic is shown in Figure 4. The throughput is deter-
`mined by tep_recv and ip_demux,which add up to 26.7 us. The transmitter is less costly than in
`the PPE implementation becauseof the faster network speed.
`weeenwseeose ee eases see eee ee eee owe
`
`Receiver
`
`
`Transmitter
`
`DMAU
`
`Figure 4. TCP/IP Processing
`
`The throughputcalculated for unidirectional TCP/IP traffic between two MPA systems is 35720 TCP
`segments/s. For bidirectional traffic, the throughput is 20290 segments/s, if for every eight packets an
`acknowledgmentpacketis sent. The throughput numbersare independentof the packetsize becauseall
`data copying is done in hardware overlapped to protocol processing. Howeverfor large packets, the
`network becomes the bottleneck (4 kByte segments would result in more than 1 Gb/s), If we assume a
`segmentsize of 1024 bytes, the throughput is 292 Mb/s whichis more than mostcurrent workstation can
`handle.
`
`5. Conclusion
`
`The separation of isochronous and asynchronoustraffic permits processing of isochronous multimedia
`traffic at the network speed. The separate header and data memories provide optimized accessto the
`critical components. The parallelism between the transmitter and receiveris the most suitable form of
`moderate parallelism to speed up protocol processing and to lower hardware contention.
`The hardware components such as the HP, CG and DMAUcanbe built to process one Gb/s. The MPA
`could then process multimedia streamsat one Gb/s. A multimedia application could for example look as
`
`ACM SIGCOMM
`
`-67-
`
`Computer Communication Review
`
`DEFS-ALA0010797
`Alacritech, Ex. 2031 Page 9
`
`Alacritech, Ex. 2031 Page 9
`
`

`

`follows. The multimedia interface handles 700 Mb/s in hardware. The protocol processors perform
`transport protocol processing at a throughput of 300 Mb/s and forward the data to the workstation. This
`split of the bandwidth would makesense, because applications which require reliable transport connec-
`tions in the Gb/s range do not seem feasible in the near future because of the I/O bottleneck of the
`workstations. Howevertransport protocol processing at one Gb/sis already possible with an architec-
`ture based on the MPA.
`
`The efficient attachmentof the subsystem to the workstation is yet unsolved. To take advantageofthe
`high bandwidth available on the network and on the MPA, the current workstation hardware and soft-
`ware interfaces must be changed. Designing these interfaces especially for multimedia will be one of
`the goals of future work.
`
`6. References
`
`[Birch 92]
`
`[Chin 92]
`
`[Braun 92]
`
`[inmos 91]
`[Jain 90]
`
`[Kuiserswerth 92]
`
`[Riitsche 92]
`
`[Topoleic 90]
`
`[Traw 91]
`
`[Steenkiste 92]
`
`[ Wicki 90]
`
`Birch, J., Christensen, L. G., Skov, M., "A programmable 800Mbit/s CRC check / gen-
`erator unit for LANs and MANs”, Computer Networks and ISDN Systems, Nr. 24,
`North-Holland 1992.
`
`Chin, H. W., Edholm, Ph., Schwaderer, D. W., "Implementing PE—1000 Based Inter-
`networking Nodes, Part 2 of 3”, Transfer, Volume 5, Nr 3, March/April 1992.
`Braun,T., Zitterbart, M., "Parallel Transport System Design’, IFIP Conference on
`High Performance Networking, Liege (Belgium), 1992.
`“The T9000 Transputer Products Overview Manual”, inmos 1991.
`Jain, N., Schwartz, M., Bashkow,T. R., Transport Protocol Processing at GBPS
`Rates”, Proceedings of the SIGCOMM °90 Symposium , Sept. 1990.
`Kaiserswerth, M., ’The Parallel Protocol Engine”, IBM Research Report, RZ 2298
`(#77818), March 1992.
`Riitsche, E., Kaiserswerth, M., *TCP/IP on the Parallel Protocol Engine’, Proceedings,
`IFIP Conference on High Performance Networking, Li¢ge (Belgium), Dec. 1992.
`Topolcic, C. (Editor), "Experimental Intemet Stream Protocol, Version 2 (ST-ID”,
`RFC 1190, Oct. 1990.
`Traw. B., Smith, J.,”"A High-Performance Host Interface for ATM Networks”, Pro-
`ceedings ACM SIGCOMM '91, Ziirich, Switzerland, Sept. 1991.
`Stennkiste, P., et al., "A Host Interface Architecture for High-Speed Networks”, Pro-
`ceedings IFIP Conference on High Performance Networking, Liége (Belgium), Dec.
`1992.
`
`Wicki, T.,”’A Multiprocessor —Based Controller Architecture for High-Speed Commu-
`nication Protocol Processing’, Doctoral Thesis, IBM Research Report, RZ 2053
`(#72078), Vol 6, 1990.
`
`ACM SIGCOMM
`
`—68-
`
`Computer Communication Review
`
`DEFS-ALA0010798
`Alacritech, Ex. 2031 Page 10
`
`Alacritech, Ex. 2031 Page 10
`
`