Method and system for writing network data

[0001] 1. Field of the Invention

[0002] The present invention relates to networks, and more particularly, to writing network data.

[0003] 2. Background of the Invention

[0004] Computer networks are commonly used. Storage area networks (“SANs”) are a type of network used to store and access data. A SAN maintains a sub-network of shared storage devices, for example, disks and tape drives. A computer system (may also be referred to as a “host”) can access data stored in the SAN.

[0005] Typical SAN architecture makes storage devices available to all servers that are connected using a computer network, for example, a local area network or a wide area network. The term server in this context means any computing system or device coupled to a network that manages network resources. For example, a file server is a computer and storage device dedicated to storing files. Any user on the network can store files on the server.

[0006] Conventional SAN systems have delay and latency when data is moved from one network location to another. The delay and latency becomes worse, if long distance (for example, 100 km) network connections are used to move data. Therefore, there is a need for a method and system to reduce the number of roundtrips to deliver data in network communication.

[0007] In one aspect of the present invention, a method for writing data in a network is provided. The method includes receiving an original write command from a host system to write data to a target; sending a command notifying the host system to send data, wherein a local router sends the command to the host system; receiving data from the host system, wherein the local router receives data; segmenting the original write command into a plurality of write commands; sending the plurality of write commands with data to a remote router; sending a status command to the local router for the plurality of write commands except for a first write command; assembling the plurality of write commands with data to a single write command, wherein the remote router assembles the plurality of write commands with data; sending the single write command to the target; sending data to the target after receiving a command from the target notifying the remote router that the target is ready to receive the data; and sending a status command to the local router, wherein the remote router sends the status command; and sending the status command to the host system, wherein the local router sends the status command.

[0008] In another aspect of the present invention, a network system is provided. The system includes a host system for sending an original write command to write data to a target; and a local router for sending a command to the host system notifying the host system that the target is ready to receive data and the hosts system sends the data to the local router; and the local router segments the original write command and data into a plurality of write commands and data; and sends the plurality of write commands and data to a remote router; wherein the remote router sends a status command to the local router for all the plurality of write commands except for a first write command; and the remote router assembles the plurality of write commands to a single write command and data and sends the single write command to the target and sends data to the target after receiving a command from the target notifying the remote router that the target is ready to receive data

[0009] This brief summary has been provided so that the nature of the invention may be understood quickly. A more complete understanding of the invention can be obtained by reference to the following detailed description of the preferred embodiments thereof concerning the attached drawings.

[0017] To facilitate an understanding of the preferred embodiment, the general architecture and operation of a SAN using storage devices will be described. The specific architecture and operation of the preferred embodiment will then be described with reference to the general architecture.

[0018] Before describing the general architecture, the following provides a brief introduction to various standard protocol/interface (for example, Fibre Channel, iSCSI and others) that may be used to move data in a SAN. Fibre Channel (incorporated herein by reference in its entirety) is an American National Standard Institute (ANSI) set of standards, which provides a serial transmission protocol for storage and network protocols such as HIPPI, SCSI (small computer system interface), IP, ATM and others. Fibre Channel provides an input/output interface for both channel and network users.

[0019] The iSCSI standard (incorporated herein by reference in its entirety) is based on Small Computer Systems Interface (“SCSI”), which enables a computer system to perform block data input/output (“I/O”) operations with a variety of peripheral devices including disk and tape devices, optical storage devices, as well as printers and scanners. A traditional SCSI connection between a host system and a peripheral device is through parallel cabling and is limited by distance and device support constraints. For storage applications, iSCSI was developed to take advantage of network architectures based on Fibre Channel and Gigabit Ethernet standards.

[0020] iSCSI leverages the SCSI protocol over established networked infrastructures and defines the means for enabling block storage applications over TCP/IP networks. iSCSI defines mapping of the SCSI protocol with TCP/IP. The iSCSI standard includes an “immediate data” mode, which allows one to send command and data together.

[0021] The iSCSI architecture is based on a client/server model. Typically, the client is a host computing system such as a file server that issues a read or write command. The server may be a disk array that responds to the client request. Devices that request input/output (“I/O”) processes are called initiators. Targets are devices that perform operations requested by initiators. Each target can accommodate up to a certain, number of devices, known as logical units, and each is assigned a Logical Unit Number (LUN).

[0022] Network System: FIG. 1 shows a top-level block diagram of a network system 100. Network system 100 includes a computing system (host) 101 that is coupled to a router 102 via host bus adapter (HBA) (or network interface) 109. Router 102 is labeled as a local router because it is geographically closer to host 101 than router 104 (labeled as remote router). Local router 102 is coupled to a local area network/wide area network 103, which is coupled to remote router 104.

[0023] Storage system 105 is coupled to remote router 104. Functionally, remote router 104 is a local router for storage system 105. Storage system 105 is operationally coupled to storage devices 106/107. Although only two storage devices have been shown, system 100 may include any number of storage devices. Furthermore, although only one host 101 and storage system 105 are shown, system 100 may include any number of hosts and storage systems.

[0024] Host system 101 typically includes several functional components. These components may include a central processing unit (CPU) 108, main memory 110, input/output (“I/O”) devices 111, and HBA (may also be referred to as “network interface”) 109. Main memory 110 is coupled to CPU 108 via a system bus 112 or a local memory bus (not shown). Main memory 110 is used to provide CPU 108 access to data and/or program information that is stored in main memory 110 at execution time. Typically, main memory 110 is composed of random access memory (RAM) circuits.

[0025] Read only memory (ROM, not shown) is provided to store invariant instruction sequences such as start-up instruction sequences or basic input/output operating system (BIOS) sequences.

[0026] Network interface 109 facilitates network communication between host 101 and other devices, for example, storage system 105. Network interface 109 includes hardware/software modules to handle such network communication.

[0027] Local router 102 and remote router 104 have hardware and software (firmware) to route network packets (or frames) between plural network devices.

[0028] FIG. 2 shows a flow chart of a conventional process for writing data to a target. The process starts in step S200, when an initiator (host 101) issues a write command to a target, for example, storage device 107.

[0029] In step S202, storage device 107 (via storage system 105, remote router 104, LAN/WAN 103 and local router 102) sends a response to host 101 notifying that it is ready to receive data. This response is a XFER_RDY command/primitive in a SCSI transfer.

[0030] After host 101 receives the XFER_RDY, in step S204, host 101 sends data to storage device 107.

[0031] In step S206, storage device 107 sends a status command to host 101.

[0032] The process of FIG. 2 has built in latency of at least two round trip delays before data write operation is complete, i.e. (1) A firs, round trip for sending the command; and receiving the XFER_RDY; and (2) A second round trip for sending the data and receiving the status. Short network connections may attempt to compromise with this number of roundtrips, but in long distance network connections, these round trips are undesirable.

[0033] The adaptive aspects of the present invention reduce the round trip delay to a single round trip regardless of data transfer size. The term round trip as used herein means, the trip from an initiator to a target and from a target to the initiator.

[0034] FIG. 3A shows a top-level block diagram of a router (102 or 104, operating as a local or remote router) used according to one aspect of the present invention. Local router 102 receives data and commands from a host application. Data and commands are segregated into plural write commands (may be referred to as “SmartWrite” commands). Remote router 104 receives the SmartWrite commands and data and assembles them into a single command and data as received by local router 102. The single command and data is then delivered to a target (107), in the same order it was received.

[0035] Router 102 includes a processor (also referred to as Processing Module) 300 with access to memory 301. Processor 300 executes firmware (software) instructions out of memory 301 to perform various router functions. Ports 302 and 303 support communication between host 101 and LAN/WAN 103, respectively. Router 102 also includes a compression unit 304 that is used to compress and de-compress data for achieving better throughput.

[0036] In one aspect, router 102 operates as a bridge between host 101 and storage system 105. Router 102 receives write commands (or a command data block (CDB) for a SCSI transaction) from host 101. Router 102 sends a XFER_RDY to host 101 instead of waiting for a target response. Host 101 sends data to router 102 and router 102 sends original write command and all the data with one or multiple SmartWrite commands to remote router 104. Remote router 104 responds with a status to all the write commands, except the first write command of this sequence.

[0037] Remote router 104 then assembles all the data and sends an original write command the target. The target responds to the write command, and when target indicates it is ready to receive the data, remote router 104 sends the data. Upon receiving the status from a target, Remote router 104 also sends a status to local router 102. Thereafter, local router 102 sends a status command to host 101.

[0038] FIG. 3B shows an example of a COB (called original CDB) 306 received from a host system. Data payload 307 accompanies CDB 306 using the “immediate data” feature provided by iSCSI. Router 102 breaks the original CDB into multiple SmartWrite commands. The first SmartWrite command is shown as 308 and includes a header 309 with the original CDB 306. The other commands and payload are shown as 311 and 312.

[0039] For example, if router 102 negotiates a data transfer size of 32 kb with router 104 and the actual write operation is for 128 kb, then the CDB/payload is split into 32 kb segments to meet the negotiated transfer size. When router 104 receives the 32 kb command/data payload segments, it reassembles the split CDB/payload before transferring it to the storage system/destination.

[0040] FIG. 3C shows an example of a SmartWrite header 309 and a CDB format 313 to break an original I/O request into plural segments. The CDB format 313 may be customized by a hardware vendor (for example, QLogic Corporation, the assignee of the present application) and includes plural flags/values. For example, format 313 includes a flag that indicates whether the CDB is compressed, whether the segment is the first segment, middle segment or the last segment. CDB format 313 also includes the “data length” of the segment. Format 313 allows a vendor to split original CDB 306 (FIG. 3B) into plural segments (308, 311 and 312, FIG. 3B).

[0041] Header 309 includes the original CDB length, original CDB, length of compressed data, if any, the type of compression algorithm that may have been used and other information.

[0042] Compression/decompression is performed by compression unit 304 (FIG. 3A).

[0043] FIG. 4 shows a process flow diagram for processing write commands, according to one aspect of the present invention. The process reduces the number of round trips to complete a write command, for example, to a single round trip.

[0044] Turning in detail to FIG. 4, in step S400, an initiator issues a write command (or write command block (CDB)). In this example, host 101 is an initiator that attempts to write to a target (storage device 107). Local router 102 receives the command (or CDB, used interchangeably).

[0045] In step S402, local router 102 sends a status/confirmation command/message to host 101 indicating that it is ready to receive data. For a SCSI based transfer, local router 102 sends the XFER_RDY primitive to host 101. Host 101 is not aware that local router 102 is sending the XFER_RDY command, instead of storage device 107. This is different from a conventional transaction, where the target device typically sends the XFER_RDY.

[0046] In step S404, host 101 transfers data to local router 102.

[0047] In step S406, local router 102 splits the original command/data into plural segments. Local router 102 uses SmartWrite commands similar to the example shown in FIG. 3B. The number of segments and the segment size will depend on a negotiated transfer size between local router 102 and remote router 104. Local router 102 sends plural write command blocks and data to remote router 104. Local router 102 uses the “immediate data” mode that allows host 101 to send data/command to router 102.

[0048] In step S408, remote router 104 sends status to local router 102 for all command blocks except for the first command block (308, FIG. 3B).

[0049] In step S410, remote router 104 assembles data and CDBs for delivery to target 107. In step S412, remote router 104 sends a write command to target 107. In step S414, target 107 sends a XFER_RDY primitive/command to remote router 104 indicating it is ready to receive data.

[0050] In step S416, remote router 104 sends assembled data to target 107. In step S418, remote target 107 sends status to remote router 104 and in step S420, remote router 104 sends status to local router 102. Thereafter, in step S422, local router 102 sends a status command to host 101.

[0051] In one aspect of the present invention, round trip delay for a write operation is minimized, for example, to a single round trip, instead of two/three round trips, regardless of the size of the data transfer. In another aspect, command and data are delivered in the same sequence as they are received by a local port (i.e. local router).

[0052] Although the present invention has been described with reference to specific embodiments, these embodiments are illustrative only and not limiting. Many other applications and embodiments of the present invention will be apparent in light of this disclosure and the following claims.