|Publication number||US6493343 B1|
|Application number||US 09/224,114|
|Publication date||Dec 10, 2002|
|Filing date||Dec 30, 1998|
|Priority date||Jan 7, 1998|
|Also published as||US6724762, US20030053462, WO1999035793A1|
|Publication number||09224114, 224114, US 6493343 B1, US 6493343B1, US-B1-6493343, US6493343 B1, US6493343B1|
|Inventors||David J. Garcia, Richard O. Larson|
|Original Assignee||Compaq Information Technologies Group|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (15), Non-Patent Citations (3), Referenced by (78), Classifications (32), Legal Events (8)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application claims priority from Provisional Application No. 60/070,650, filed Jan. 7, 1998, the disclosure of which is hereby incorporated by reference.
Traditional network systems utilize either channel semantics (send/receive) or memory semantics (DMA) model. Channel semantics tend to be used in I/O environments and memory semantics in processor environments.
In the channel semantics model, the sender does not know where data is to be stored, it just puts the data on the channel. On the sending side, the sending process specifies the memory regions that contain the data to be sent. On the receiving side, the receiving process specifies the memory regions where the data will be stored.
In the memory semantics model, the sender directs data to a particular location in memory utilizing remote direct memory access (RDMA) transactions. The initiator of the data transfer specifies both the source buffer and destination buffer of the data transfer. There are two types of RDMA operations, read and write.
The virtual interface architecture (VIA) has been jointly developed by a number of computer and software companies. VIA provides consumer processes with a protected, directly accessible interface to network hardware, termed a virtual interface. VIA is especially designed to provide low latency message communication over a system area network (SAN) to facilitate multi-processing utilizing clusters of processors.
A SAN is used to interconnect nodes within a distributed computer system, such as a cluster. The SAN is a type of network that provides high bandwidth, low latency communication with a very low error rate. SANs often utilize a fault-tolerant network to provide continued message communications in the even of failure.
It is important for the SAN to provide high reliability and high-bandwidth, low latency communication to fulfill the goals of the VIA.
According to one aspect of the present invention, a SAN maintains local copies of a sequence number for each data transfer transaction at the requestor and responder nodes. Each data transfer is implemented by the SAN as a sequence of request/response packet pairs. An error condition arises if a response to any request packet is not received at the requesting node. Each request packet includes an ordering field which specifies whether or not the packets must be received at the responder in the order that they were sent. At the requestor and responder nodes, the local copy of the sequence number is incremented only if the ordering field in the packet sent or received, respectively, specifies that the packets must be received in the order sent.
According to another aspect of the invention, a sliding window protocol is utilized that allows a requestor to continue to send a specified number of request packets before receiving the matching response packets.
According to another aspect of the invention, RDMA transactions may be implemented utilizing multiple paths to increase bandwidth.
Other features and advantages of the invention will be apparent in view of the following detailed description and appended drawings.
FIG. 1 is a block diagram depicting ServerNet protocol layers implemented by hardware, where ServerNet is a SAN manufactured by the assignee of the present invention;
FIGS. 2 and 3 are block diagrams depicting SAN topologies;
FIG. 4 is a schematic diagram depicting logical paths between end nodes of a SAN;
FIG. 5 is a schematic diagram depicting routers and links connecting SAN end nodes; and
FIG. 6 is a graph depicting the transmission of request and response packets between a requestor and a responder end node. FIG. 6 shows the sequence numbers used in packets for three Send operations, an RDMA operation, and two additional Send operations. The diagram shows the sequence numbers maintained in the requester logic, the sequence number contained in each packet, and the sequence numbers maintained at the responder logic.
The preferred embodiments will be described implemented in the ServerNet II (ServerNet) architecture, manufactured by the assignee of the present invention, which is a layered transport protocol for a System Area Network (SAN) optimized to support the Virtual Interface (VI) architecture session layer which has stringent user-space to user-space latency and bandwidth requirements. These requirements mandate a reliable hardware (HW) message transport solution with minimal software (SW) protocol stack overhead. The ServerNet II protocol layers for an end node VI Network Interface controller/Card (NIC) and for a routing node are illustrated in FIG. 1. A single NIC and VI session layer may support one or two ports, each with its associated transaction, packet, link-level, MAC (media access) and physical layer. Similarly, routing nodes with a common routing layer may support multiple ports, each with its associated link-level, MAC and physical layer.
Support for two ports enables ServerNet II SAN to be configured in both non-redundant and redundant (fault tolerant, or FT) SAN configurations as illustrated in FIG. 2 and FIG. 3. On a fault tolerant network, a port of each end node may be connected to each network to provide continued VI message communication in the event of failure of one of the SANs. In the fault tolerant SAN, nodes may also be ported into a single fabric, or single ported end nodes may be grouped into pairs to provide duplex FT controllers. The fabric is the collection of routers, switches, connectors, and cables that connects the nodes in a network.
The following describes general ServerNet II terminology and concepts. The use of the term “layer” in the following description is intended to describe functionality and does not imply gate level partitioning.
Two ports are supported on a NIC for both performance and fault tolerance reasons. Both of these ports operate under the same session layer VIA engine. That is, data may arrive on any port and be destined for any VI. Similarly, the VIs on the end node can generate data for any of these ports.
ServerNet II packets are comprised of a series of data symbols followed by a packet framing command. Other commands, used for flow control, virtual channel support, and other link management functions, may be embedded within a packet. Each request or response packet defines a variety of information for routing, transaction type, verification, length and VI specific information.
i. Routing in the ServerNet II SAN is destination based using the first 3 bytes of the packet. Each NIC end node port in the network is uniquely defined by a 20 bit Port SNID (ServerNet Node ID). The first 3 bytes of a packet contain the Destination port's SNID or DID (destination port ID) field, a three bit Adaptive Control Bits (ACB) field and the fabric ID bit. The ACB is used to specify the path (deterministic or link-set adaptive) used to route the packet to its destination port as described in the following section.
ii. The transaction type fields define the type of session layer operation that this ServerNet II packet is carrying and other information such as whether it is a request or a response and, if a response, whether it is an Ack (acknowledgment) or a Nack (negative acknowledgment). the ServerNet II SAN also supports other transaction types.
iii. Transaction verification fields include the source port ID (SID) and a Transaction Serial Number. The transaction serial number enables a port with multiple requests outstanding to uniquely match responses to requests.
iv. The Length field consists of an encoding of the number of bytes of payload data in the packet. Payloads up to 512 bytes are supported and code space is reserved for future increases in payload size.
v. The VI Session Layer specific fields describe VI information such as the VI Operation, the VIA Sequence number, and the Virtual Interface ID number. The VI Operation field defines the type of VI transaction being sent (Send, RDMA Read, RDMA Write) and other control information such as whether the packet is ordered or unordered, whether there is immediate data and/or whether this is the first or last packet in a session layer multi-packet transfer. Based on the VI transaction type and control information, a 32 bit Immediate data field or a 64 bit Virtual address may follow the VI ID number.
vi. The payload data field carries up to 512 bytes of data between requestors and responders and may contain a pad byte.
vii. The CRC field contains a checksum computed over the entire packet.
The basic flow of transactions through the ServerNet II SAN will now be described. VI requires the support of Send, RDMA read and RDMA write transactions. These are translated by the VI session layer into a set of ServerNet II transactions (request/response packet pairs). All data transfers (e.g., reading a disk file to CPU memory, dumping large volumes of data from a disk farm directly over a high-speed communications link, one end node simply interrupting another) consist of one or more such transactions.
The VI User Agent provides the low level routines for VIA Send, RDMA Write, and RDMA Read operations. These routines place a descriptor for the desired transfer in the appropriate VI queue and notify the VIA hardware that the descriptor is ready for processing. The VIA hardware reads the descriptor, and based on the descriptor contents, builds the ServerNet request packet header and assembles the data payload (if appropriate).
In a NIC with two ports, it is possible for a single VIA interface to process Sends and RDMA operations from several different VIs in parallel. It is also possible for a large RDMA transfer from a single VI to be transferred on both of the ports simultaneously. This latter feature is called Multi-pathing.
ServerNet II end nodes can connect both their ports to a single network fabric so that there are up to four possible paths between ServerNet II end nodes. Each port of a single end node may have a unique ServerNet ID (SNID). FIG. 4 depicts the four possible paths that End node A can use when sending request to End node B:
1) End node A SNID to End node B SNID
2) End node A SNID to End node B SNID
3) End node A SNID to End node B SNID
4) End node A SNID to End node B SNID
FIG. 5 depicts a network topology utilizing routers and links. In FIG. 5, end nodes A-F, each having first and second send receive ports 0 and 1, are coupled by a ServerNet topology including routers R1-R5. Links are represented by lines coupling ports to routers or routers to routers. For example, a first adaptive set (fat pipe) 2 couples routers R1 and R3 and a second adaptive set (fat pipe) 4 couples routers R2 and R4.
Routing may be deterministic or link set adaptive. An adaptive link-set is a set of links (also called lanes) between two routers that have been grouped to provide higher bandwidth. The Adaptive Control Bits (ACB) specify which type of routing is in effect for a particular packet.
Deterministic routing preserves strict ordering for packets sent from a particular source port to a destination port. In deterministic routing the ACB field selects a single path or lane through an adaptive link-set. Send transactions for a particular VI require strict ordering and therefore use deterministic routing.
RDMA transactions, on the other hand, may make use of all possible paths in the network without regard for the ordering of packets within the transaction. These transactions may use link-set adaptive routing as described below. The ACB field specifies which specific link (or lane) in this link-set is to be used for deterministic routing.
Alternatively, the ACB field can specify link-set adaptivity which enables the packets to dynamically choose from any of the links in the link-set.
A sample topology with several different examples of multipathing using link and path adaptivity is shown in FIG. 5.
Multipathing allows large block transfers done with RDMA Read or Write operations to simultaneously use both ports as well as adaptive links between the two communicating NICs. Since the data transfer characteristics of any one VI are expected to be bursty, multipathing allows the end node to marshal all its resources for a single transfer. Note that multipathing does not increase the throughput of multiple Send operations from one VI. Sends from one VI must be sent strictly ordered. Since there are no ordering guarantees between packets originating from different ports on a NIC, only one port may be used per Send. Furthermore, only a single ordered path through the Network may be used, as described in the following.
The transaction layer builds the ServerNet II request packet by filling in the appropriate SID, Transaction Serial Number (TSN), and CRC. The SID assigned to a packet always corresponds to the SNID of the port that the packet originates from. The TSN can be used to help the port manage multiple outstanding requests and match the resulting responses uniquely to the appropriate request. The CRC enables the data integrity of the packet to be checked at the end node and by routers enroute.
Following the ServerNet II link protocol, the packet is encoded in a series of data symbols followed by a status command. The ServerNet II link layer uses other commands for flow control and link management. These commands may be inserted anywhere in the link data stream, including between consecutive data symbols of a packet. Finally, the symbols are passed through the MAC layer for transmission on the physical media to an intermediate routing node.
The routing control function is programmable so that the packet routing can be changed as needed when the network configuration changes (e.g., route to new end nodes). Router nodes serve as crossbar switches; a packet on any incoming (receive) side of a link can be switched to the outgoing (transmit) side of any link. As the incoming request packet arrives at a router node, the first three bytes, containing the DID, and ACB fields, are decoded and used to select a link leading to the destination node. If the transmit side of the selected link is not busy, the head of the packet is sent to the destination node whether or not the tail of the packet has arrived at the routing node. If the selected link is busy with another packet, the newly arrived packet must wait for the target port to become free before it can pass through the crossbar.
As the tail of the packet arrives, the router node checks the packet CRC and updates the packet status (good or bad). The packet status is carried by a link symbol TPG (this packet good) or TPB (this packet bad) appended at the end of the packet. Since packet status is checked on each link, a packet status transition (good to bad) can be attributed to a specific link. The packet routing process described above is repeated for each router node in the selected path to the destination node.
When the request packet arrives at the destination node, the ServerNet II interface receiver checks its validity (e.g., must contain correct destination node ID, the length is correct, the Fabric bit in the packet matches the Fabric bit associated with the receiving port, the request field encodes a valid request, and CRC must be good,). If the packet is invalid for any reason, the packet is discarded. The ServerNet II interface may save error status for evaluation by software. If these validity checks succeed, several more checks are made. Specifically, if the request specifies an RDMA Read or Write, the address is checked to ensure access has been enabled for that particular VI. Also, the input port and Source ID of the packet are checked to ensure access to the particular VI is allowed on that input port from the particular Source. If the packet is valid, the request can be completed.
A response is created based on the success (ACK response) or failure (NACK response) of the request packet. A successful read request, for example, would include the read data in the ACK response. The source node ID from the request packet is used as the destination node ID for the response packet. The response packet must be returned to the original source port. The path taken by the response is not necessarily the reverse of the path taken by the request. The network may be configured so that responses take very different paths than requests. If strict ordering is not required, the response, like the request, may use link-set adaptivity. The response packet is routed back to the SNID specified by the SID field of the request. The ACB field of the request packet is also duplicated for the response packet.
The response can be matched with the request using the TSN and the packet validity checks. If an ACK response passes these tests, the transaction layer passes the response data to the session layer, frees resources associated with the request, and reports the transaction as complete. If a NACK response passes these tests, the end node reports the failure of the transaction to the session layer. If a valid ACK/NACK response is not received within the allotted time limit, a time-out error is reported.
The requestor can stream many strictly ordered ServerNet II messages onto the wire before receiving an acknowledgment. The sliding window protocol allows the requestor to have up to 128 packets outstanding per VI.
The hardware can operate in one of two modes with respect to generating multiple outstanding request packets:
1. The hardware can stream packets from the same VI send queue onto the wire, and start the next descriptor before receiving all the acknowledgments from the current descriptor. This is referred to as “Next Descriptor After Launch” or NDAL.
2. The hardware can stream packets to a single descriptor onto the wire but wait for all the outstanding acknowledgments to complete before starting the next descriptor. This is referred to as “Next Descriptor after Ack” or NDAA.
The choice of NDAL or NDAA modes of operation is determined by how strongly ordered the packets are generated.
Ordered and unordered messages may be mixed on a single VI. When generating an unordered message, the requestor must wait for completion of all acknowledgments to unordered packets before starting the next descriptor.
The VI architecture has no explicit ordering rules as to how the packets that make up a single descriptor are ordered among themselves. That is, VIA only guarantees the message ordering the client will see. For example, VIA requires that Send descriptors for a particular VI be completed in order, but the VIA specification doesn't say how the packets will proceed on the wire.
The ServerNet II SAN requires that all Send packets destined for a particular VI be delivered by the SAN in strict order. As long as deterministic routing is used, the network assures strict ordering along a path from a particular source node to a particular destination node. This is necessary because the receiving node places the incoming packets into a scatter list. Each incoming packet goes to a destination determined by the sum total of bytes of the previous packets. The strict ordering of packets is necessary to preserve integrity of the entire block of data being transferred because incoming packets are placed in consecutive locations within the block of data. Each packet has a sequence number to allow the receiver to detect an out of order, missing, or repeated packet.
There are two ways for an end node to meet these ordering requirements:
a. The end node can wait for the acknowledgment from each Send packet to complete before starting another Send packet for that VI. By waiting for each acknowledgment the end node doesn't have to worry about the network providing strict ordering and can choose an arbitrary source port, adaptive link set, and destination port for each message.
b. The end node can restrict all the Send operations for a given VI to use the same source port, the same destination port, and a single adaptive path. By choosing only one path through the network, the end node is guaranteed that each Send packet it launches into the network will arrive at the destination in order.
The second approach requires the VIA end node to maintain state per VI that indicates which source port destination port and adaptive path is currently in use for that particular VI. Furthermore, the second approach allows the hardware to process descriptors in the higher performance NDAL mode.
With the second approach, Send packets from a single VI can stream onto the network without waiting for their accompanying acknowledgments. An incrementing sequence number is used so the destination node can detect missing, repeated, or unordered Send packets.
RDMA operations have slightly different ordering requirements than Send operations. An RDMA packet contains the address to which the destination end node writes the packet contents. This allows multiple RDMA packets within an RDMA message to complete out of order. The contents of each packet are written to the correct place in the end node's memory, regardless of the order in which they complete.
RDMA request packets may be sent ordered or unordered. A bit in the packet header is set to a 1 for ordered packets and is set to a 0 for unordered packets. As will be explained later, this bit is used by the responder logic to determine if it should increment its copy of the expected sequence number. Sequence numbers do not increment for unordered packets. The end node is free to use different source ports, destination ports and adaptive paths for the packets. This freedom can be exploited for a performance gain through multipathing; simultaneously sending the RDMA packets of a single message across multiple paths.
When RDMA Read or Write packets are sent over a path that does not exhibit strict ordering with the Send packets from the same VI, care must be taken when launching packets for the following message. The next message cannot be started until the last acknowledgment of the RDMA Read or Write operation successfully completes.
In other words, when multipathing is used to generate RDMA Read or Write requests, the hardware must operate in the NDAA mode. This ensures the RDMA Read or Write is completed before moving on to subsequent descriptors.
An end node may choose to send RDMA packets strictly ordered. This can be advantageous for smaller RDMA transfers as the hardware can operate in NDAL mode. The VI can proceed to the next descriptor immediately after launching the last packet of a message that is sent strictly ordered (and hence used incrementing sequence numbers).
The ServerNet II end node must respond to incoming Send requests and RDMA Write requests from a particular VI in strict order, and must write these packets to memory in strict order.
The ServerNet II end node must also respond to incoming RDMA Read requests from a particular VI in strict order.
Because response packets are transported by the network in strict order, the requestor will receive all incoming response packets for a particular VI in the same order as that in which the corresponding requests were generated.
The ServerNet SAN uses acknowledgment packets to inform the requester that a packet completed successfully. Sequence numbers in the packets (and acknowledgments) are used to allow the sender to support multiple outstanding requests to ensure adequate performance and to be able to recover from errors occurring in the network.
FIG. 6 is a graph depicting the generation, checking, and updating of VIA sequence numbers at requestor and responder nodes. In FIG. 6 time increases in the downward direction. Requests are indicated by solid arrows directed to the right and responses by dotted arrows directed to the left.
The requestor and responder logic each maintain an 8 bit sequence number for each VI in use. When the VI is created, the requestor on one node and the responder on the remote node initialize their sequence numbers to a common value, zero in the preferred embodiment.
After this, the requestor places its sequence number into each of the outgoing request packets. As depicted in FIG. 6, the sequence number, SEQ, is included in each request packet. The responder compares the sequence number from the incoming request packet with the responder's local copy. The responder uses this comparison to determine if the packet is valid, if it is a duplicate of a packet already received, or if it is an out-of-sequence packet. An out-of-sequence packet can only happen if the responder missed an incoming packet. The responder can choose to return a ‘sequence error NACK packet’ or it can simply ignore the out-of-sequence packet. In the latter case, the requestor will have a timeout on the request (and presumably on the packet the responder missed) and initiate error recovery. Generating a Sequence Error NACK Packet is preferred as it forces the requestor to start error recovery more quickly.
The following describes how the sequence numbers are generated and checked.
When transmitting ordered packets (i.e. transfers are on a specific source port to a specific destination port and the ACB specifies a specific lane) the request sequence number is incremented after each packet is sent. When transmitting unordered packets (i.e. multipathing is used and/or the ACB bits specify full link set adaptivity) the request sequence number is not incremented after such a packet is sent.
For example, in FIG. 6, during the first two Send transactions, the local copy of the request sequence number is incremented after the packet is sent (Rqst. SN=0 to 6). For the RDMA operation, which sends 2500 bytes unordered, the requestor does not increment local copy of the request sequence number (Rqst. SN=6). The requestor does not increment the local copy of the SN until after the first packet of the Send following the RDMA is transmitted.
Send packets are typically sent fully ordered lest the requestor have to wait for an acknowledgment for each packet before proceeding to the next. On the other hand, RDMA packets may be sent either ordered or unordered. To take advantage of multipathing, a requestor must use unordered RDMA packets.
The sender guarantees to never exceed the windowsize number of packets outstanding per VI. If S is the number of bits in the sequence number, then the windowsize is 2**(S-1).
A packet is outstanding until it and all its predecessors are acknowledged. The requestor does not mark a descriptor done until all packets requested by that descriptor are positively acknowledged.
The destination node responding to the incoming request packet checks each incoming request packet to verify its sequence number against the responder's local copy.
The responder logic compares its sequence number with the packet's sequence number to determine if the incoming packet is either:
the expected packet it's looking for (i.e., the packet's sequence number is the same as the sequence number maintained by the responder logic), in which case the responder processes the packet and if all other checks are passed, the packet is Acknowledged and committed to memory. If the transaction is ordered then the responder then increments its sequence number. If the transaction is unordered than the responder does not increment its sequence number;
an out-of-sequence packet (which means an earlier incoming packet must have gotten lost), beyond the one it is looking for in which case the responder NACKs the packet and throws it away. The receive logic in the VI is not stopped and the responder does not increment its sequence number; or
a duplicate packet (which is being resent because the requester must not have received an earlier ack) in which case the responder Acks the packet and throws it away. If the request had been an RDMA Read, the responder completes the read operation and returns the data with a positive acknowledgment.
An example of the responder checking sequence numbers for ordered and unordered packets is given in FIG. 6. In FIG. 6, during the first two Send transactions, the responder checks that the SEQ in the packet matches the local copy of Rsp. SN. Since the Send packets include ACB indicating ordered then the Rsp. SN is incremented after each response packet is transmitted. At the end of the first two Send transactions, Rqst. SN and Rsp. SN are both equal to 6. The packets for the RDMA include an ACB indicating unordered receipt is allowed. Neither the requestor nor responder increments its local copy of SN. Thus, at the end of the RDMA transaction both Rqst. SN and Rsp. SN=6. The first packet of the subsequent Send transaction has SEQ=6 and SEQ matches the local copy of Rsp. SN. Since Send packets are ordered, the responder increments its local copy of Rsp. SN.
When generating either a positive or negative acknowledgment, the responder logic copies the incoming sequence number and uses it in the sequence number field of the acknowledgment.
The requestor logic matches incoming responses with the originating request by comparing the SourcelD, VI number, Sequence number, transaction type, and Transaction Serial Number (TSN) with that of the originating request.
The invention has now been described with reference to the preferred embodiments. Alternatives and substitutions will now be apparent to persons of skill in the art. For example, the invention has been described in the context of the ServerNet II SAN, the principles of the invention are useful in any network that services both memory semantics and channel semantics or uses multi-pathing. Accordingly, it is not intended to limit the invention except as provided by the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4733350||Dec 17, 1984||Mar 22, 1988||Fujitsu Limited||Improved purge arrangement for an address translation control system|
|US5386524||Apr 16, 1992||Jan 31, 1995||Digital Equipment Corporation||System for accessing information in a data processing system|
|US5555405||Jul 6, 1993||Sep 10, 1996||Digital Equipment Corporation||Method and apparatus for free space management in a forwarding database having forwarding entry sets and multiple free space segment queues|
|US5563879 *||Dec 1, 1995||Oct 8, 1996||Motorola, Inc.||Method of reconstructing and delivering segmented messages|
|US5619274||May 13, 1994||Apr 8, 1997||Starsight Telecast, Inc.||Television schedule information transmission and utilization system and process|
|US5678007 *||Nov 22, 1994||Oct 14, 1997||Microsoft Corporation||Method and apparatus for supporting multiple outstanding network requests on a single connection|
|US5737595 *||Nov 26, 1993||Apr 7, 1998||Io Research Pty. Limited||Distributed database system and database receiver therefor|
|US5802050 *||Jun 10, 1996||Sep 1, 1998||Telefonaktiebolaget Lm Ericsson||Minicell sequence number count|
|US5920886||Mar 14, 1997||Jul 6, 1999||Music Semiconductor Corporation||Accelerated hierarchical address filtering and translation using binary and ternary CAMs|
|US5991797 *||Dec 23, 1997||Nov 23, 1999||Intel Corporation||Method for directing I/O transactions between an I/O device and a memory|
|US6119244 *||Aug 25, 1998||Sep 12, 2000||Network Appliance, Inc.||Coordinating persistent status information with multiple file servers|
|US6272591 *||Oct 19, 1998||Aug 7, 2001||Intel Corporation||Raid striping using multiple virtual channels|
|US6347337 *||Aug 20, 1999||Feb 12, 2002||Intel Corporation||Credit based flow control scheme over virtual interface architecture for system area networks|
|US20020029305 *||Jul 3, 2001||Mar 7, 2002||International Business Machines Corporation||Method and system for transmitting multiple data packets to reading device|
|EP0757318A2||Jun 6, 1996||Feb 5, 1997||Tandem Computers Incorporated||A router element for routing messages in a processing system|
|1||Dunning D. et al., "The Virtual Interface Architecture," IEEE Micro, vol. 18, No. 2, 3/98, pp. 66-76.|
|2||Eicken Von T. et al., "U-Net: A User-Level Network Interface for Parallel and Distributed Computing," Operating Systems Review (SIGOPS), vol. 29, No. 5, Dec. 1, 1995, pp. 40-53.|
|3||Garcia et al., "ServerNet II" Parallel Computer Routing and Communication, (2nd Int. WKSP), Jun. 26, 1997, pp. 119-135, XP002103164, Atlanta, GA.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US6675200 *||May 10, 2000||Jan 6, 2004||Cisco Technology, Inc.||Protocol-independent support of remote DMA|
|US6697878 *||Jan 4, 1999||Feb 24, 2004||Fujitsu Limited||Computer having a remote procedure call mechanism or an object request broker mechanism, and data transfer method for the same|
|US6724762 *||Oct 25, 2002||Apr 20, 2004||Hewlett-Packard Development Company, L.P.||System and method for implementing multi-pathing data transfers in a system area network|
|US6891801 *||May 5, 2000||May 10, 2005||Siemens Aktiengesellschaft||Method of operating a data transmission system|
|US6922393 *||Jan 10, 2001||Jul 26, 2005||Asustek Computer Inc.||Data discarding request acknowledgement in a wireless communications protocol|
|US7010607 *||Sep 14, 2000||Mar 7, 2006||Hewlett-Packard Development Company, L.P.||Method for training a communication link between ports to correct for errors|
|US7024479||Jan 22, 2001||Apr 4, 2006||Intel Corporation||Filtering calls in system area networks|
|US7089378||Mar 27, 2003||Aug 8, 2006||Hewlett-Packard Development Company, L.P.||Shared receive queues|
|US7103744||Mar 27, 2003||Sep 5, 2006||Hewlett-Packard Development Company, L.P.||Binding a memory window to a queue pair|
|US7152128 *||Aug 23, 2002||Dec 19, 2006||Intel Corporation||General input/output architecture, protocol and related methods to manage data integrity|
|US7184399 *||Dec 28, 2001||Feb 27, 2007||Intel Corporation||Method for handling completion packets with a non-successful completion status|
|US7191375||Dec 28, 2001||Mar 13, 2007||Intel Corporation||Method and apparatus for signaling an error condition to an agent not expecting a completion|
|US7353313 *||Oct 23, 2006||Apr 1, 2008||Intel Corporation||General input/output architecture, protocol and related methods to manage data integrity|
|US7404190||Sep 18, 2003||Jul 22, 2008||Hewlett-Packard Development Company, L.P.||Method and apparatus for providing notification via multiple completion queue handlers|
|US7430615 *||Dec 20, 2004||Sep 30, 2008||International Business Machines Corporation||RDMA server (OSI) global TCE tables|
|US7502826||Mar 27, 2003||Mar 10, 2009||Hewlett-Packard Development Company, L.P.||Atomic operations|
|US7509378 *||Mar 9, 2004||Mar 24, 2009||Bea Systems, Inc.||System and method for message ordering in a message oriented network|
|US7522590||Oct 14, 2003||Apr 21, 2009||International Business Machines Corporation||Managing message arrival to ensure proper matching of unordered messages|
|US7523216 *||Feb 1, 2002||Apr 21, 2009||Network Appliance, Inc.||System and method for using an endian-neutral data packet to define subsequent data packet byte-order|
|US7529245 *||Apr 4, 2005||May 5, 2009||Sun Microsystems, Inc.||Reorder mechanism for use in a relaxed order input/output system|
|US7554993||Mar 27, 2003||Jun 30, 2009||Hewlett-Packard Development Company, L.P.||Method and apparatus for performing connection management with multiple stacks|
|US7565504||Jul 21, 2009||Hewlett-Packard Development Company, L.P.||Memory window access mechanism|
|US7581026||Dec 28, 2001||Aug 25, 2009||Intel Corporation||Communicating transaction types between agents in a computer system using packet headers including format and type fields|
|US7617290 *||Nov 10, 2009||Cisco Technology, Inc.||Protocol-independent support of remote DMA|
|US7617376||Aug 14, 2003||Nov 10, 2009||Hewlett-Packard Development Company, L.P.||Method and apparatus for accessing a memory|
|US7624156 *||May 23, 2000||Nov 24, 2009||Intel Corporation||Method and system for communication between memory regions|
|US7757232||Aug 14, 2003||Jul 13, 2010||Hewlett-Packard Development Company, L.P.||Method and apparatus for implementing work request lists|
|US7953085 *||Dec 29, 2008||May 31, 2011||International Business Machines Corporation||Third party, broadcast, multicast and conditional RDMA operations|
|US8023520 *||Mar 27, 2003||Sep 20, 2011||Hewlett-Packard Development Company, L.P.||Signaling packet|
|US8116203||May 31, 2007||Feb 14, 2012||Broadcom Corporation||Multiple virtual channels for use in network devices|
|US8150996||Dec 16, 2003||Apr 3, 2012||Hewlett-Packard Development Company, L.P.||Method and apparatus for handling flow control for a data transfer|
|US8223828||Oct 22, 2007||Jul 17, 2012||Broadcom Corporation||Methods and systems for adaptive receiver equalization|
|US8250165||Dec 12, 2011||Aug 21, 2012||Intel Corporation||Method and system for communicating between memory regions|
|US8291176||Oct 16, 2012||Hewlett-Packard Development Company, L.P.||Protection domain groups to isolate access to memory windows|
|US8364849||Jan 29, 2013||International Business Machines Corporation||Snapshot interface operations|
|US8433020||Jun 5, 2006||Apr 30, 2013||Broadcom Corporation||High-speed serial data transceiver and related methods|
|US8472512||May 9, 2012||Jun 25, 2013||Broadcom Corporation||Methods and systems for adaptive receiver equalization|
|US8583755||Jul 17, 2012||Nov 12, 2013||Intel Corporation||Method and system for communicating between memory regions|
|US8621029 *||Apr 28, 2004||Dec 31, 2013||Netapp, Inc.||System and method for providing remote direct memory access over a transport medium that does not natively support remote direct memory access operations|
|US8750320||Jan 21, 2003||Jun 10, 2014||Broadcom Corporation||Fibre channel arbitrated loop bufferless switch circuitry to increase bandwidth without significant increase in cost|
|US8767756||Nov 19, 2008||Jul 1, 2014||Broadcom Corporation||Fibre channel arbitrated loop bufferless switch circuitry to increase bandwidth without significant increase in cost|
|US8774199||Jan 21, 2003||Jul 8, 2014||Broadcom Corporation||Fibre channel arbitrated loop bufferless switch circuitry to increase bandwidth without significant increase in cost|
|US8798091||Apr 30, 2008||Aug 5, 2014||Broadcom Corporation|
|US8798219||Feb 15, 2013||Aug 5, 2014||Broadcom Corporation||High-speed serial data transceiver and related methods|
|US8824538||May 16, 2013||Sep 2, 2014||Broadcom Corporation||Methods and systems for adaptive receiver equalization|
|US8959171||Sep 18, 2003||Feb 17, 2015||Hewlett-Packard Development Company, L.P.||Method and apparatus for acknowledging a request for data transfer|
|US20020031125 *||Aug 28, 2001||Mar 14, 2002||Jun Sato||Packet transfer communication apparatus, packet transfer communication method, and storage medium|
|US20020071421 *||Dec 12, 2001||Jun 13, 2002||Elan Microelectronics Corporation||Method and system for data loss detection and recovery in wireless communication process|
|US20020090005 *||Jan 10, 2001||Jul 11, 2002||Jiang Sam Shiaw-Shiang||Data discarding request acknowledgment in a wireless communications protocol|
|US20020099827 *||Jan 22, 2001||Jul 25, 2002||Shah Hemal V.||Filtering calls in system area networks|
|US20020099851 *||Jan 22, 2001||Jul 25, 2002||Shah Hemal V.||Decoupling TCP/IP processing in system area networks|
|US20020114275 *||Feb 19, 2002||Aug 22, 2002||Pioneer Corporation||Packet transmitter and method|
|US20030043794 *||Sep 6, 2001||Mar 6, 2003||Cayton Phil C.||Data stream multiplexing in data network|
|US20030126274 *||Dec 28, 2001||Jul 3, 2003||David Harriman||Communicating transaction types between agents in a computer system using packet headers including format and type fields|
|US20030126535 *||Dec 28, 2001||Jul 3, 2003||Gary Solomon||Method and apparatus for signaling an error condition to an agent not expecting a completion|
|US20030145134 *||Aug 23, 2002||Jul 31, 2003||Wehage Eric R.||General input/output architecture, protocol and related methods to manage data integrity|
|US20030174716 *||Dec 28, 2001||Sep 18, 2003||Lee David M.||Method for handling unexpected completion packets and completion packets with a non-successful completion status|
|US20040190533 *||Mar 27, 2003||Sep 30, 2004||Prashant Modi||Method and apparatus for performing connection management with multiple stacks|
|US20040190557 *||Mar 27, 2003||Sep 30, 2004||Barron Dwight L.||Signaling packet|
|US20040193734 *||Mar 27, 2003||Sep 30, 2004||Barron Dwight L.||Atomic operations|
|US20040193825 *||Mar 27, 2003||Sep 30, 2004||Garcia David J.||Binding a memory window to a queue pair|
|US20040193832 *||Mar 27, 2003||Sep 30, 2004||Garcia David J.||Physical mode windows|
|US20040193833 *||Mar 27, 2003||Sep 30, 2004||Kathryn Hampton||Physical mode addressing|
|US20040205141 *||Mar 9, 2004||Oct 14, 2004||Goland Yaron Y.||System and method for message ordering in a message oriented network|
|US20040205379 *||Mar 27, 2003||Oct 14, 2004||Jeffrey Hilland||Protection domain groups|
|US20050038918 *||Aug 14, 2003||Feb 17, 2005||Hilland Jeffrey R.||Method and apparatus for implementing work request lists|
|US20050066333 *||Sep 18, 2003||Mar 24, 2005||Krause Michael R.||Method and apparatus for providing notification|
|US20050078605 *||Oct 14, 2003||Apr 14, 2005||International Business Machines Corporaton||Managing message arrival to ensure proper matching of unordered messages|
|US20050131986 *||Dec 16, 2003||Jun 16, 2005||Randy Haagens||Method and apparatus for handling flow control for a data transfer|
|US20060047771 *||Dec 20, 2004||Mar 2, 2006||International Business Machines Corporation||RDMA server (OSI) global TCE tables|
|US20060075067 *||Dec 20, 2004||Apr 6, 2006||International Business Machines Corporation||Remote direct memory access with striping over an unreliable datagram transport|
|US20070038793 *||Oct 23, 2006||Feb 15, 2007||Wehage Eric R||General input/output architecture, protocol and related methods to manage data integrity|
|US20070237163 *||May 31, 2007||Oct 11, 2007||Broadcom Corporation||Multiple virtual channels for use in network devices|
|US20090125604 *||Dec 29, 2008||May 14, 2009||International Business Machines Corporation||Third party, broadcast, multicast and conditional rdma operations|
|US20100049883 *||Feb 25, 2010||Shmuel Ben-Yehuda||Method and system for memory address translation and pinning|
|US20110173520 *||Jul 14, 2011||Juniper Networks, Inc.||Systems and methods for routing data in a network device|
|US20140337680 *||Feb 12, 2014||Nov 13, 2014||Electronics And Telecommunications Research Institute||Can communication apparatus and method thereof|
|WO2003079612A1 *||Dec 11, 2002||Sep 25, 2003||Adaptec, Inc.||Method and apparatus for direct data placement over tcp/ip|
|U.S. Classification||370/394, 709/213, 370/474, 711/E12.014, 711/E12.067|
|International Classification||H04L29/06, H04L1/18, H04L29/08, H04L12/56, H04L1/16, H04L1/22, G06F12/10, G06F12/02|
|Cooperative Classification||H04L69/26, H04L69/326, H04L69/324, H04L49/557, G06F12/1081, H04L49/30, G06F12/023, G06F12/0292, H04L29/06, H04L1/188, H04L1/16, H04L1/22, H04L49/90|
|European Classification||H04L49/90, H04L49/30, H04L1/22, G06F12/02D6, H04L29/06, G06F12/10P|
|Mar 23, 1999||AS||Assignment|
Owner name: TANDEM COMPUTERS INCORPORATED, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GARCIA, DAVID J.;LARSON, RICHARD O.;REEL/FRAME:009848/0774;SIGNING DATES FROM 19990222 TO 19990226
|Nov 21, 2000||AS||Assignment|
Owner name: COMPAQ COMPUTER CORPORATION, TEXAS
Free format text: MERGER;ASSIGNOR:TANDEM COMPUTERS INCORPORATED;REEL/FRAME:011331/0212
Effective date: 19991222
|Dec 18, 2001||AS||Assignment|
Owner name: COMPAQ INFORMATION TECHNOLOGIES GROUP, L.P., TEXAS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:COMPAQ COMPUTER CORPORATION;REEL/FRAME:012375/0046
Effective date: 20010620
|Jun 22, 2005||AS||Assignment|
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS
Free format text: CHANGE OF NAME;ASSIGNOR:COMPAQ INFORMATION TECHNOLOGIES GROUP, L.P.;REEL/FRAME:016386/0526
Effective date: 20021001
|Jun 12, 2006||FPAY||Fee payment|
Year of fee payment: 4
|Jun 10, 2010||FPAY||Fee payment|
Year of fee payment: 8
|May 26, 2014||FPAY||Fee payment|
Year of fee payment: 12
|Nov 9, 2015||AS||Assignment|
Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, TEXAS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.;REEL/FRAME:037079/0001
Effective date: 20151027