throbber
The Architecture of a Gb/s
`
`Muitimedia Protocol Adapter
`
`Erich RUtsche
`
`IBM Research Division,
`
`Zurich Research Laboratory
`Séumerstrasse 4, 8803 RUschiikon, Switzerland
`
`Abstract
`
`In this paper a new multipr‘oce.ssor~based communication adapter is presented. The adapter architec-
`ture supports isochronous multimedia trafi‘ic and asynchronous data traffic by handling them separate—
`ly. The adapter architecture and its components are explained and theprotocolprocessing performance
`for TCP/IP andfor ST~11 is evaluated. The architecture supports the processing ofST—II at the network
`speed of622 Mb/s. The calculated performancefor TCP/IP is more than 30000 segments/sec. The ar-
`chitecture can be extended to protocol processing at one Gb/s.
`
`Keywords: Multimedia Communication Subsystems; Network Protocols; Parallel Protocol
`Processing
`
`1. Introduction
`
`As data transmission speeds have increased dramatically in recent years, the processing of protocols has
`become one of 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 proposed in the literature are multiprocessor architec-
`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 connect to
`a 622 Mb/s ATM network. The MPA architecture exploits the inherent parallelism between the trans-
`mitter and receiver parts of a protocol and provides support for the handling of new multimedia proto-
`0015.
`
`The goal of this architecture is to speed up the handling of multiple protocol stacks and of multimedia
`protocols such as the Internet Stream Protocol (ST—II) [Topolcic 90]. Multimedia traffic often requires
`isochronous transmission in contrast to conventional asynchronous traffic for file transfer or for remote
`procedure call. To guarantee the isochronous processing of multimedia data streams, the asynchronous
`and isochronous traffic are handled separately. A Header Parser scans incoming packets, detects the
`header fields and extracts the header information. This information is used to separate isochronous and
`asynchronous traffic and to split the header and the data portions of 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 MPA architecture are presented. Section 3 explains protocol processing
`on the MPA. In Section 4 the performance of the MPA is evaluated by adapting the measurements of our
`TCP/IP implementation on the PPE to the MPA architecture. The last section gives the conclusions.
`
`2. Architecture
`
`The architecture of the MPA is based on our experiments with the PPE [Kaiserswerth 92] ,[Riitsche 92].
`The PPE is 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 for storing and processing protocol data. Transmit and receive side are
`only connected via serial transputer links.
`
`2.1 Concept
`
`The protocol 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 streams with low delay and low jitter but may accept bit errors or packet loss. Asynchronous traffic,
`such as file transfer or remote procedure call, requires more moderate throughput but tolerates no er-
`rors. In a file transfer between a file server and a client the throughput is 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 must be clone in software to handle a multitude of protocols. Only functions that are
`common to all or most of the protocols are implemented in hardware. The MAC layer for ATM and the
`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 shown that the processors were not equally loaded be-
`cause of the different processing requirements of the protocol layers and because of 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 speedup of 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 memory of both parts 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 message links.
`
`2.2 Main Building Blocks
`
`The MPA is split into two parts, a receiver and a transmitter, as shown in Figure l. 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
`
`

`

`
`
`
`
`
`<-Data
`
`
`
`§I g
`(A
`CD
`3 E'
`$12
`
`a
`
`,
`
`
`
`
`
`Media Access Control Unit (MACU)
`mus,“ ”,7
`,
`,,
`,
`,
`,,,,,:
`
`Hews“
`
`
`
`,
`
`
`Media Access Control Unit (MAC
`,
`,,
`,
`,
`, ,1,” ,, J
`'
`,
`
`
`Checksum
`Gna(CGeertor)
`
`
`
`
`
`
`Checksum
`VGeeratorCG)
`
`
`7
`
`
`Q
`
`_.
`
`l
`
`(D
`
`3E
`3%
`3 7

`n)
`
`I
`:U
`I
`9i i
`|
`I
`,
`|
`
`I
`77
`7
`, Processor -
`I
`,
`.
`:
`
`
`
`7
`Direct
`7
`7
`Direct
`Device
`gustmuc)
`Device
`
`
`
`WOtIertiachement
`roer
`Attachement
`
`
`
`
`
`Workstation Bus
`I
`Workstation Bus
`
`
`
`Z:
`TE
`5'
`8,
`s“
`
`Figure 1. MFA Architecture
`
`Media Access Control Unit (MACU): The MPA is designed to be connected to any hi gh—speed net-
`work. The design of the MAC is beyond the scope of this paper. [Traw 91] for example describes an
`interface to the Aurora ATM network.
`
`Header Parser (HP): The HP is similar to the ProtoParser1 [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.
`
`Checksum Generator (CG): The CG is triggered by the HP to calculate the appropriate checksum or
`Cyclic Redundancy Check (CRC) for the packet on the fly. The algorithms are implemented in hard-
`ware and selected by decoding the HP signal. On the sender side the CG is triggered by the DMA unit.
`[Birch 92], for example, describes a programmable CRC generator which is capable of processing 800
`Mb/s.
`
`The Protocol Processor T9000: The selection of the inmos2 T9000 [inmos 91] is based on our good
`experience with the transputer family of processors in the PPE. The most significant 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 [NMOS Limited.
`
`ACM SIGCOMM
`
`-sia
`
`Computer Communication Fieview
`
`DEFS-ALA0010791
`
`Alacritech, Ex. 2031 Page 3
`
`Alacritech, Ex. 2031 Page 3
`
`

`

`Mb/s plus a set of instructions to use the links for control purposes. The peek and poke instructions issue
`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 memory at identical physical addresses in 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 components that 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. The seri-
`
`al port of the VRAM provides guaranteed access via the DMA Unit to the network. The parallel
`
`port of the VRAM is 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 processor for synchronization with asynchronous data 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
`
`7
`
`Header Memory
`
`Static RAM .
`
`7
`
`Local Memory
`
`7
`
`7
`
`Dynamic RAM
`
`Table 1. Memory Access Time
`
`Average Access Time
`60 ns
`
`30 ns
`
`
`
`
`
`,
`
`ns
`
`
`Direct Memory Access Unit (DMAU): The DMAU directs the in* and outgoing data streams to the
`correct destination. The DMAU splits an incoming packet into its header and data part and moves the
`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 DMAU handles this linked list in hardware and thereby off—
`loads part of the memory management from the protocol processor.
`
`Bus Controller (B C): The BC is a programmable busmaster DMA controller. It provides a small FIFO
`and a table for DMA requests. The FIFO contains a pointer to the linked list of source data and a connec-
`tion identifier. The BC determines the destination memory address through the connection identifier in
`the table. The list format is the same for the BC and the DMAU. In the transmit BC the host writes to the
`
`ACM SlGCOMM
`
`—62—
`
`Computer Communication Review
`
`DEFS-ALA0010792
`
`Alacritech, Ex. 2031 Page 4
`
`Alacritech, Ex. 2031 Page 4
`
`

`

`FIFO and the protocol processor to the table. In the receive BC the protocol processor writes 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 packet proces-
`sing is shown in Figure 2.
`
`Receiver
`
`The MACU receives cells from the ATM network, processes the AAL, and triggers the receive pipeline
`to start. The receive pipeline is run by the DMAU. The HP and the CG process the data as they are co=
`pied from the MACU to the destination 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 uses this information to detect which checksum or CRC it must calculate. The CG
`
`calculates the checksum on the fly as the packet is copied by the DMAU and forwards the result to the
`DMAU. The DMAU uses the information generated by the HP to determine the format and the connec-
`tion of the packet. For a multimedia connection the DMAU removes the header from the packet and
`writes the data part to the Multimedia FIFO.
`
`Data
`
`Multimedia
`Header
`
` Receive Pipeline Header
`
`Multimedia
`
`_
`write aa 7
`write hdeaer
`
`DMAU _________ wwwmmflnxwgg““‘u _______
`
`
`calculate , write checksum
`______________ Li‘i“i‘ii§i§i .....
`
`CG
`
`Figure 2. Pipelined Packet Processing
`
`For asynchronous traffic 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
`pointer to the header structure to the receive queue. The protocol processor is then responsible for pro-
`cessing of the header structure. The addresses of free buffers in header and data memory are obtained
`from a linked list of free buffers.
`
`ACM SIGCOMM
`
`—63—
`
`Computer Communication Review
`
`DEFS-ALA0010793
`
`Alacritech, Ex. 2031 Page 5
`
`Alacritech, Ex. 2031 Page 5
`
`

`

`If the HP does not recognize a packet header the 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 a new connec-
`tion the protocol processor builds up the connection and programs the HP to recognize the header.
`
`Sender
`
`On the transmit side the protocol processor builds the layered protocol header in the header memory. It
`builds a structure which holds the 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 DMAU runs the send
`pipeline. It interprets the structure and forwards the connection type to the CG. The CG calculates the
`checksum on the fly as the packet is written to the MACU memory. In the MACU the packets are stored
`to process the AAL and to segment the AAL frame into ATM cells. Once the CG has finished, 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 DMAU appends the buffers to the corresponding free—lists.
`
`3. Protocol Processing
`
`3.1 Transport Protocol Stacks
`
`Transport protocol processing on the MFA in the example of TCP/IP is shown in Figure 3. The socket
`layer is split into a lower half serving TCP and an upper half which interfaces to the application. A more
`detailed description of our parallel TCP/[P 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 socket send call triggers the write process which copies the
`data to the MPA and gives the control over the data to xtask. The xtask process is then responsible
`for the transmission and possible retransmissions of the data. It builds the TCP packet and forwards the
`pointer to the packet to ip_s and. Here the 1P header is placed in front of the TCP segment. Then the
`pointer to the packet is written to the send queue and the DMAU sends the packet via the MACU to the
`network.
`
`Receiving a packet: Upon receipt of a packet the DMAU writes the pointer to the packet to the receive
`queue. ip_demux reads the receive queue, checks the header and, if no error or exception occurred,
`forwards the packet to tcp__recv, or else to icmp_demux. The tcp_recv process analyzes the
`TCP header and calls the appropriate handler function for a given protocol state. To send an acknowl-
`edgement or a control packet tcp_recv uses a Remote Procedure Call (RPC) to the transmit side.
`Correctly received packets are appended to the receive list. rtask forwards the received segments to
`the application process which is blocked in the socket receive procedure. This procedure then fills 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—lI is a good
`example of a protocol that supports this type of traffic. After a connection has been set 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 and then used for all the data pack-
`ets of the connection. These functions are done in a hardware pipeline by the HP and the CG (see Figure
`2). The DMAU scatters and gathers the header and the data without any 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 Control
`
`Transmission
`ontroi
`rotocoi
`
`Internet
`Protocol
`
`Media
`
`Figure 3. Parallel flop/llplwentllon
`
`cessor. Therefore real—time processing of ST—H at the network speed of 622 Mb/s is possible. The inter-
`action of the processor is only required to handle the Stream Control Message Protocol (SCMP), which
`is responsible for creating and keeping most of 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 MPA archi-
`tecture [Riitsche 92], The execution times of program segments accessing local memory Tmagma," and
`data memory Tdatamem are calculated from the execution times on the PPE minus the 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 memory timing and the faster processor, and summed to get the execu-
`tion time TMpA on the MPA.
`(1)
`TMPA = Tlocalmem * Siccabnem + Tdatamem * Ssharedmem
`
`This approach is valid for protocol processing because most operations are memory operations to 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 MIPS and a 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 us. The sustained MIPS rate improves the
`performance at least seven times for the simple protocol processing operations. The memory functions
`are determined by the memory access time shown in Table l. The access time to the header memory
`decreases by a factor of 19, the access time to the data memory by a factor of 9.5. Therefore the full
`power of the processor can be utilized, and the typical speedup factor 1/10 [inmos 91] can be assumed for
`Sdammem. 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 assume a conser-
`vative speedup factor of Slocazmem = 1/7 for the local memory.
`
`The costs of basic operations for protocol handling are listed in Table 2. The connection detection and
`the calculation of a CRC or a checksum are implemented in hardware. These operations run at network
`speed as the data is clocked in from the MACU. The T9000 improves the implementation of the distrib-
`uted shared memory, because the peek and poke calls are already implemented in the microcode. There-
`fore the costs of the distributed ’shared memory’ are only the issuing of a peek or poke instruction.
`
`
`
`N—umberof Processor Instructions E—stimatedTime'in ns
`
`
`Processor Operation
`Queue read / write
`Linked mad/remove __—
`
`300 + size[word] * 460
`Distributed shared memory
`
`
`read/write
`
`
`
`
`
`
`
`
`
`
`0 (implemented in hardware)
`Connection detection
`0 (implemented1n hardware)
`Checksum/CRC calculation
`Table 2. Cost of Basic Operations
`
`network speed
`
`4.3 TCP/IP Performance
`
`The performance of TCP/lP is evaluated using the measurements of our TCP/IP implementation on the
`PPE. The TCP stack, the socket layer and a test application run on the MPA. The cost of the single pro-
`cesses of TCP/lP 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 [P processes 60% of the accesses go to
`the shared memory, in tcp__send 47% and in tcp_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_intrsvc
`most processing is replaced by the list handling in the DMAU and the BC. However the 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
`
`

`

`,
`
`777
`
`, us/Pkeact
`
`
`
`
`
`
`/Packet
`Pocess (Procedre) on Receiver
`
`235
`
`tc_recv
`
`
`
`7 7731+0 5775us/word
`7
`,
`users_tak (ksocetrecfl/pyco
`7
`7
`Mme
`, —
`
`77
`23
`77
`ipudemux
`its/Packet
`‘ 7 _ps/Pact
`r Pd) T7nmrsitert
`
`
`77
`77
`77
`7 777
`77
`
`
`7 -30+0545us/wod_77 7 7
`
`
`
`
`
`tc_7spnddata 7
`7 77 7
`7
`777777417 777 —7 n-
`
`23
`
`170W —
`diwriverendr J 7
`,,
`7
`,
`7
`,,
`,
`,
`
`
`
`
`Achtoh‘mory (poke cal) 7 fl
`Table 3. Process Execution Times
`
`
`
`
`
`The TCP/1P process pipeline for bidirectional traffic is shown in Figure 4. The throughput is deter-
`mined by tcp_recv and ip__demux, which add up to 26.7 us. The transmitter is less costly than in
`the PPE implementation because of the faster network speed.
`--------------------------------
`
`0.7 Receiver
`ip_send driver_send
`1
`
`Transmitter
`
`
`DMAU
`
`Figure 4. TCP/IF Processlng
`
`The throughput calculated for unidirectional TCP/1P 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
`acknowledgment packet is sent. The throughput numbers are independent of the packet size because all
`data copying is done in hardware overlapped to protocol processing. However for large packets, the
`network becomes the bottleneck (4 kByte segments would result in more than 1 Gb/s). If we assume a
`segment size of 1024 bytes, the throughput is 292 Mb/s which is more than most current workstation can
`handle.
`
`5. Conclusion
`
`The separation of isochronous and asynchronous traffic permits processing of isochronous multimedia
`traffic at the network speed. The separate header and data memories provide optimized access to the
`critical components. The parallelism between the transmitter and receiver is 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 DMAU can be built to process one Gb/s. The MPA
`could then process multimedia streams at 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 make sense, 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. However transport protocol processing at one Gb/s is already possible with an architec—
`ture based on the MPA.
`
`The efficient attachment of the subsystem to the workstation is yet unsolved. To take advantage of the
`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]
`
`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—lOOO 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 92] Kaiserswerth, M., "The Parallel Protocol Engine”, IBM Research Report, R2 2298
`(#77818), March 1992.
`
`[Rutsche 92]
`
`[Topolcic 90]
`
`[’II'aw 91]
`
`[Steenkiste 92]
`
`[Wicki 90]
`
`Rfitsche, B., Kaiserswerth, M., ”TCP/[P on the Parallel Protocol Engine”, Proceedings,
`IFIP Conference on High Performance Networking, Liege (Belgium), Dec. 1992.
`
`Topolcic, C. (Editor), ”Experimental Internet Stream Protocol, Version 2 (ST—II)”,
`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, Liege (Belgium), Dec.
`1992.
`
`Wicki. T., ”A Multiprocessor —Based Controller Architecture for High—Speed Commu-
`nication Protocol Processing”, Doctoral Thesis, IBM Research Report, R2 2053
`(#72078), Vol 6, 1990.
`
`ACM SIGCOMM
`
`—68—
`
`Computer Communication Review
`
`DEFS-ALA0010798
`
`Alacritech, Ex. 2031 Page 10
`
`Alacritech, Ex. 2031 Page 10
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket