Source: http://www.google.com/patents/US8150935?dq=7,682,496
Timestamp: 2015-05-05 09:27:17
Document Index: 408837346

Matched Legal Cases: ['art 126', 'art 128', 'art 130', 'art 126', 'art 126', 'art 126']

Patent US8150935 - iSCSI receiver implementation - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA method for communication is disclosed and may include, in a network interface device, parsing a portion of a TCP segment into one or more portions of Internet Small Computer Systems Interface (iSCSI) Protocol Data Units (PDUs). A header and/or a payload for one or more of the parsed iSCSI PDUs may...http://www.google.com/patents/US8150935?utm_source=gb-gplus-sharePatent US8150935 - iSCSI receiver implementationAdvanced Patent SearchPublication numberUS8150935 B2Publication typeGrantApplication numberUS 12/619,833Publication dateApr 3, 2012Filing dateNov 17, 2009Priority dateSep 6, 2001Also published asUS7620692, US20030058870, US20100241725Publication number12619833, 619833, US 8150935 B2, US 8150935B2, US-B2-8150935, US8150935 B2, US8150935B2InventorsShay Mizrachi, Rafi Shalom, Ron GrinfeldOriginal AssigneeBroadcom CorporationExport CitationBiBTeX, EndNote, RefManPatent Citations (18), Non-Patent Citations (9), Referenced by (1), Classifications (17) External Links: USPTO, USPTO Assignment, EspacenetiSCSI receiver implementation
US 8150935 B2Abstract
1. A method for communication, the method comprising, in a network interface device (NID):
recovering a header and a payload for one or more of said parsed iSCSI PDUs; and
while said parsing continues for a remaining portion of said received TCP segment to recover a remaining portion of said iSCSI PDUs:
evaluating said recovered header; and
routing said recovered payload to a destination memory external to said network interface device for processing, wherein said evaluating and said routing occur independently of said parsing within said network interface device.
2. The method according to claim 1, comprising using respective separate physical processors for said parsing and said recovering.
3. The method according to claim 1, comprising using respective separate processors for said evaluating and said routing.
4. The method according to claim 1, comprising routing said recovered payload to a system memory external to said NID for processing.
5. The method according to claim 1, comprising routing said recovered payload to said destination memory external to said NID without intermediate buffering within said NID.
6. The method according to claim 1, comprising sharing a common memory space within said NID for said parsing and said recovering.
7. The method according to claim 6, comprising handling exchanging events for said parsing and said recovering in said single common memory space within said NID.
8. The method according to claim 1, comprising generating one or more events for handling said parsing.
9. The method according to claim 1, comprising generating one or more events for handling said recovering.
10. The method according to claim 9, wherein said generated one or more events comprises one or more of the following: a header event, a pass-PDU-data event, a handle-PDU-event and a data-digest-result event.
11. A non-transitory computer readable medium having stored thereon, a computer program having at least one code section for providing network communication, the at least one code section being executable by a computer system for causing the computer system to perform steps in a network interface device (NID), comprising:
while said parsing continues for a remaining portion of said TCP segment to recover a remaining portion of said iSCSI PDUs:
12. The non-transitory computer readable medium according to claim 11, wherein said at least one code section comprises code for controlling respective separate physical processors for said parsing and said recovering.
13. The non-transitory computer readable medium according to claim 11, wherein said at least one code section comprises code for controlling respective separate processors for said evaluating and said routing.
14. The non-transitory computer readable medium according to claim 11, wherein said at least one code section comprises code for controlling routing said recovered payload to a system memory external to said NID for processing.
15. The non-transitory computer readable medium according to claim 11, wherein said at least one code section comprises code for controlling routing said recovered payload to said destination memory external to said network interface device without intermediate buffering within said NID.
16. The non-transitory computer readable medium according to claim 11, wherein said at least one code section comprises code for controlling sharing a common memory space within said NID for said parsing and said recovering.
17. The non-transitory computer readable medium according to claim 16, wherein said at least one code section comprises code for controlling handling exchanging events for said parsing and said recovering in said single common memory space within said NID.
18. The non-transitory computer readable medium according to claim 11, wherein said at least one code section comprises code for controlling generating one or more events for handling said parsing.
19. The non-transitory computer readable medium according to claim 11, wherein said at least one code section comprises code for controlling generating one or more events for handling said recovering.
20. The non-transitory computer readable medium according to claim 19, wherein said generated one or more events comprises one or more of the following: a header event, a pass-PDU-data event, a handle-PDU-event and a data-digest-result event.
21. A system for communication, the system comprising:
a second processor to enable recovering a header and a payload for one or more of said parsed iSCSI PDUs, wherein while said parsing continues for a remaining portion of said TCP segment to recover a remaining portion of said iSCSI PDUs, said second processor enables:
22. The system according to claim 21, wherein a third processor within said NID enables performing of said evaluating.
23. The system according to claim 22, wherein said third processor within said NID enables performing of said routing.
24. The system according to claim 21, wherein said second processor enables routing of said recovered payload to a system memory external to said NID for processing.
25. The system according to claim 21, wherein said second processor enables routing of said recovered payload to said destination memory external to said network interface device without intermediate buffering within said NID.
26. The system according to claim 21, wherein said first processor and said second processor shares a common memory space within said NID for said parsing and said recovering.
27. The system according to claim 26, wherein said first processor enables handling exchanging of events for said parsing and said recovering in said single common memory space within said NID.
28. The system according to claim 21, wherein said first processor enables generating of one or more events for handling said parsing.
29. The system according to claim 21, wherein said second processor enables generating one or more events for handling said recovering.
30. The system according to claim 29, wherein said generated one or more events comprises one or more of the following: a header event, a pass-PDU-data event, a handle-PDU-event and a data-digest-result event.
31. A system for communication, the system comprising:
recover a header and a payload for one or more of said parsed iSCSI PDUs; and
evaluate said recovered header; and
route said recovered payload to a destination memory external to said NID for processing, wherein said evaluating and said routing occur independently of said parsing within said NID.
32. The system according to claim 31, wherein a first of said plurality of processors is operable to perform said parsing and a second of said plurality of said processors performs said recovering.
33. The system according to claim 32, wherein a third of said plurality of processors is operable to perform said evaluating and a fourth of said plurality of processors is operable to perform said routing.
34. The system according to claim 31, wherein said one or more processors are operable to route said recovered payload to a system memory external to said NID for processing.
35. The system according to claim 31, wherein said one or more processors are operable to recover payload to said destination memory external to said NID without intermediate buffering within said NID.
36. The system according to claim 31, wherein a first of said plurality of processors and a second of said plurality of processors are operable to share a common memory space within said NID for said parsing and said recovering.
37. The system according to claim 36, wherein said first of said plurality of processors is operable to handle exchanging events for said parsing, and said second of said plurality of processors is operable to handle exchanging events for said recovering, utilizing said single common memory space within said NID.
38. The system according to claim 31, wherein a first one of said one or more processors is operable to generate one or more events for handling said parsing.
39. The system according to claim 31, wherein a second one of said one or more processors is operable to generate one or more events for handling said recovering.
40. The system according to claim 39, wherein said generated one or more events comprises one or more of the following: a header event, a pass-PDU-data event, a handle-PDU-event and a data-digest-result event.
This application is a continuation of U.S. application Ser. No. 10/236,768 filed Sep. 6, 2002, which in turn makes reference to, claims priority to and claims the benefit of: U.S. Provisional Patent Application Ser. No. 60/317,620 filed on Sep. 6, 2001.
The need for fast access to massive amounts of shared data in today's networked computing environment has given rise to a data storage and retrieval technology called Storage Area Networks (SANs). Increasingly, SAN deployments depend on existing Transmission Control Protocol/Internet Protocol (TCP/IP) networks via an emerging standard Internet Small Computer Systems Interface (iSCSI) protocol. The Internet Engineering Task Force (IETF) Internet Protocol Storage Working Group has proposed a standard for iSCSI, which was submitted in June, 2002 as an Internet-Draft on the standards track of the IETF. The Internet-Draft, titled �iSCSI� by Julian Satran, et al., can be found at http://ietf.org/internet-drafts/draft-ietf-ips-iscsi-13.txt, and is incorporated herein by reference, and is herein referred to as the IETF iSCSI Internet-Draft. Dependence on existing TCP/IP networks creates a need to streamline communication of SCSI commands over TCP/IP networks, in order to achieve maximal performance levels.
In a traditional approach to data storage, called Direct Attached Storage (DAS), storage devices are linked to a server with a fixed, dedicated connection. Only one server can normally access data on a particular disk, via a local bus, commonly using a Small Computer Systems Interface (SCSI) protocol. The original SCSI protocol was standardized in 1986 by the American National Standards Institute (ANSI) as X3.131-1986. The current evolving SCSI standard is described in a document titled �SCSI Architecture Model-2 (SAM-2),� produced by T10, Technical Committee of the National Committee on Information Technology Standards, which may be found on the T10 Internet site at ftp://ftp.t10.org/t10/drafts/sam2, and which is incorporated herein by reference. DAS suffers from a number of limitations, for example, the SCSI protocol limits the length of a bus connecting to a device to about 6 meters. Additional limitations and drawbacks include upper limits on speed, and number of attached storage devices, limited scalability and reliability, and limitations of exclusive ownership of attached storage. These limitations are addressed by SANs.
SANs handle communication between storage devices and storage clients. As noted above, the SCSI protocol acts as a common, standard interface to storage devices. Devices using the SCSI protocol include input/output (I/O) devices, hard drives, tape drives, CD and DVD drives, printers, and scanners. As well as defining hardware characteristics of an SCSI bus, the SCSI protocol specifies the formats and rules governing commands and responses communicated between storage devices, called �targets� in SCSI terminology, and storage clients, known as �initiators.�
In an article entitled �Overview and History of the SCSI Interface� by Charles M. Kozierok, published in the PC Guide which can be found at http://www.pcguide.com/ref/hdd/if/scsi/over-c.html, and which is incorporated herein by reference, the author emphasizes the general nature of the SCSI interface: �It's important to remember that SCSI is, at its heart, a system interface, as the name suggests. It was first developed for hard disks, is still used most for hard disks . . . . For those reasons, SCSI is sometimes thought of as a hard disk interface . . . . However, SCSI is not an interface tied specifically to hard disks. Any type of device can be present on the bus . . . .�
The iSCSI protocol is a transport protocol for SCSI commands over TCP networks. TCP is described by Postel in Request For Comments (RFC) 793 of the U.S. Defense Advanced Research Projects Agency (DARPA), entitled �Transmission Control Protocol: DARPA Internet Program Protocol Specification� (1981), which is incorporated herein by reference. The IETF iSCSI Internet-Draft document defines methods for encapsulating SCSI command descriptor blocks (CDBs) and responses into iSCSI messages, known as Protocol Data Units (PDUs), controlling flow, establishing iSCSI sessions, identifying PDUs in the TCP stream, mapping a session to multiple connections, and adding correction code on top of the TCP protocol, among other protocol elements.
A related, informational Internet-Draft by the IP Storage Working Group entitled �iSCSI Requirements and Design Considerations� by Marjorie Krueger, et al. can be found at http://ietf.org/internet-drafts/draft-ietf-ips-iscsi-regmts-05.txt, and is incorporated herein by reference. Krueger, et al. describe the charter of the IP Storage Working Group as �developing comprehensive technology to transport block storage data over IP protocols . . . . The initial version of the iSCSI protocol will define a mapping of SCSI transport protocol over TCP/IP so that SCSI storage controllers (principally disk and tape arrays and libraries) can be attached to IP networks, notably Gigabit Ethernet (GbE) and 10 Gigabit Ethernet (10 GbE).�
The benefits to SAN implementations based on iSCSI derive primarily from the large body of experience, knowledge, tools, and equipment that exist in the industry in both the fields of SCSI and TCP/IP. As Krueger, et al. go on to note, the IP Storage Working Group �has chosen to focus the first version of the protocol to work with the existing SCSI architecture and commands, and the existing TCP/IP transport layer. Beth these protocols are widely deployed and well understood. The thought is that using these mature protocols will entail a minimum of new invention, the most rapid possible adoption, and the greatest compatibility with Internet architecture, protocols, and equipment.�
The standard layered architectural model for communications between two users in a network is known as the International Standards Organization's Open Systems Interconnection (ISO/OSI) and is specified in standard ISO/IEC 7498-1:1994, �Open Systems Interconnection�Basic Reference Model: The Basic Model.� An overview of the OSI reference model is provided in an article entitled �OSI,� which can be found at the Internet site http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci212725,00.html, and which is incorporated herein by reference.
In the context of the present patent application and the claims, the term �machine� is defined as a hardware processing unit, which may be implemented as a software-driven central processing unit (CPU) or as a hard-wired or programmable logic device, or as a combination of such elements. Multiple such �machines� may be provided on a single integrated circuit chip, each carrying out its assigned tasks substantially autonomously. Also in the context of the present patent application and the claims, the term �event� is defined as a message conveyed to a processing unit indicative of a significant activity or state change. Events typically comprise an identification indicating a type of activity or state change and additional parameters qualifying and detailing the activity or state change. Events may be implemented in hardware, e.g., via hard-wired signals, or in software, e.g., using operating system resources or shared memory, or in a combination of such methods.
The pointer to the beginning of the PDU in the destination memory is subsequently passed to D-machine 157 via a data event Handle-initial-PDU-data 170, also comprising a partial PDU payload. After the D-machine has established that a first data portion has been handled for a given PDU (by setting a first_flag to false), subsequent data portions are processed via a data event Handle-PDU-data 174, received from the P-machine. The D-machine routes PDU data 178, comprising a partial PDU payload received in the data events, to destination memory 180 via device interface 179. D-machine 157 also manages processing of a data digest 160, if digests are defined in a login phase of the session. A further description of the operation of D-machine 157 is given below, with reference to FIG. 7.
If comparison 204 is false, the P-machine may also receive received-pass-PDU events 172, as checked in a condition 206. The received-pass-PDU event signifies that an initial portion or portions of a given PDU have been received, and that the D-machine 157 is set up to receive subsequent parts of the payload directly from the P-machine 153. The P-machine 153 indicates reception of a received-pass-PDU event 172 by setting a variable ACK rec to true in a step 208.
If comparison 214 is false, a comparison 223 is performed to check if the section is a data chunk, in which case, processing continues in a condition 222 which analyzes the section to determine whether it contains a portion of data in a range for an identified PDU. If not, a send data step 224 sends the data to a temporary buffer. If the data belongs to a known range, a condition 226 checks if ACK_rec is true. If so, the P-machine 153 sends a pass-PDU-data event 228 to the D-machine 157. If ACK_rec is false, in a step 230 the P-machine 152 sends a handle-PDU-data event 174 to the D-machine 157, when first_flag (for the first data)=1.
Reference is now made to FIG. 7, which is a flow chart that schematically illustrates logic comprised in the D-machine 157 of FIG. 5, according to a preferred embodiment of the present invention. D-machine 157 begins in a wait-for-data-event step 242. A condition 244 tests if an incoming event is a handle-initial-PDU-data event 170 (FIG. 5). If so, a condition 248 queries first_flag to determine if it is the first handle-initial-PDU-data event 170 received on that PDU. If first_flag is true, the D-machine 157 sends a received-pass-PDU event 172 to the P-machine 153. Processing continues in a calculation step 252 wherein a destination address is calculated for the portion of data received with the handle-initial-PDU-data 170 or handle-PDU-data events 174. An optional compute data digest step 254 is executed, which maintains a running calculation of a data digest for one or more portions of a payload of the PDU.
D-machine 157 can also receive a handle-PDU-data event 174, as determined in condition 246. The handle-PDU-data event 174 is sent to the D-machine 157 after it has acknowledged receiving a first portion of the data for the PDU, i.e., after the D-machine 157 sends a received-pass-PDU event 172. Thus, handling of the handle-PDU-data event 174 begins at calculate destination address step 252, and proceeds through steps 254, 256, 258, 260, 266, 268, and 270, substantially as described above for the handle-initial-PDU-data event 170.
Reference is now made to FIG. 8, which is a flow chart that schematically illustrates logic comprised in the H-machine 155 of FIG. 5, according to a preferred embodiment of the present invention. H-machine 155 begins in a wait-for-header-event step 282. A condition 284 tests if an incoming header event is a pass-PDU-data event 166. If so, a condition 290 tests the value of first flag. If first flag is true, i.e., the current event is among the first for the PDU, a determine pointer step 292 calculates a pointer to the start of the PDU's data in destination memory; The pointer is sent to the D-machine 157 in a send event step 294, which sends a handle-initial-PDU-data event 170 to the D-machine 157. If condition 290 determined that first flag is false, i.e., the pointer was already calculated for a prior pass-PDU-data event 166 for the current PDU, processing continues in send event 294.
H-machine 155 may also receive a handle-PDU-header event 164, as checked in condition 286. In case of this event, a process PDU header step 296 is executed. Process PDU header step 296 comprises, inter alia, identifying an embedded SCSI command, identifying an iSCSI session and task tag, and handling iSCSI flow control. The H-machine 155 most preferably also stores a data base that is relevant to the processing of iSCSI headers according to the iSCSI protocol (e.g. data to connect a PDU to the entire task). H-machine 155 may receive a data-digest-result event 168 from D-machine 157 (the D-machine 157 sends a flag to the H-machine 155 after the D-machine 157 has compared a calculated and a received digest). A condition 288 tests if a received event is a data-digest-result event 168. If the data-machine 157 indicates an error in the data digest 160, the H-machine 155 will initiate processing this error event as required in the system, according to step 298.
It will be apparent to those skilled in the art that partitioning iSCSI receiver processing as described above enables immediate handling of partial PDUs arriving in TCP segments, without waiting to assemble an entire PDU. Handling of iSCSI PDU 1 in FIG. 4 illustrates this property of preferred embodiments of the present invention. PDU 1 is transmitted in three separate TCP segments: TCP segment 1 (comprising all of header 1 and an initial part 126 of PDU data 1), TCP segment 2 (comprising a second part 128 of PDU data 1), and TCP segment 3 (comprising a final part 130 of PDU data 1). When TCP segment 1 is received by P-machine 153, header 1 is parsed in parsing step 210 (FIG. 6A) and passed to H-machine 155 in send event step 216 (FIG. 6B). Since TCP segment 1 is the first event for PDU 1, first flag is true, as set in step 230 (FIG. 6B). Thus, first part 126 of PDU 1's data is passed to the H-machine 155 in a send event step 230 (FIG. 6). The H-machine 155 processes iSCSI header 1 in process header step 296 (FIG. 8), and sends initial part 126 of PDU 1's data to D-machine 157 in send event step 294. The D-machine 157 acknowledges receipt of initial part 126 in a send event step 250 (FIG. 7), transfers the data to destination memory in transfer step 256 (FIG. 7), and creates an entry in its incomplete PDU table in step 270 (FIG. 7). Therefore, TCP segment 1 is processed completely upon receipt, despite the fact that it contains only a fragment of PDU 1.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5440545Aug 2, 1993Aug 8, 1995Motorola, Inc.Packet delivery systemUS5493667Feb 9, 1993Feb 20, 1996Intel CorporationApparatus and method for an instruction cache locking schemeUS5809527Dec 23, 1993Sep 15, 1998Unisys CorporationOutboard file cache systemUS5809543Nov 7, 1996Sep 15, 1998Unisys CorporationFault tolerant extended processing complex for redundant nonvolatile file cachingUS5963963Jul 11, 1997Oct 5, 1999International Business Machines CorporationParallel file system and buffer management arbitrationUS5970391Jul 14, 1997Oct 19, 1999Motorola, Inc.Method for a subscriber unit to compile message fragments transmitted from different zonesUS6034963 *Oct 31, 1996Mar 7, 2000Iready CorporationMultiple network protocol encoder/decoder and data processorUS6438655Nov 10, 1999Aug 20, 2002Lucent Technologies Inc.Method and memory cache for cache locking on bank-by-bank basisUS6601143Jul 20, 2000Jul 29, 2003International Business Machines CorporationSelf-adapting cache management method and systemUS6631130Nov 21, 2000Oct 7, 2003Transwitch CorporationMethod and apparatus for switching ATM, TDM, and packet data through a single communications switch while maintaining TDM timingUS6643710Sep 17, 1999Nov 4, 20033Com CorporationArchitecture to fragment transmitted TCP packets to a requested window sizeUS6654811Apr 13, 2000Nov 25, 2003Nokia Inc.Backpressure arrangement in client-server environmentUS6742045Jul 2, 1999May 25, 2004Cisco Technology, Inc.Handling packet fragments in a distributed network service environmentUS6771646Jun 30, 2000Aug 3, 2004Hi/Fn, Inc.Associative cache structure for lookups and updates of flow records in a network monitorUS6795866Sep 15, 2000Sep 21, 2004Sun Microsystems, Inc.Method and apparatus for forwarding packet fragmentsUS7289499 *Jul 16, 2002Oct 30, 2007Network Appliance, Inc.Integrated system and method for controlling telecommunication network data communicated over a local area network and storage data communicated over a storage area networkUS7583681 *Jul 30, 2002Sep 1, 2009Brocade Communications Systems, Inc.Method and apparatus for establishing metazones across dissimilar networksUS20030093567 *Jan 18, 2002May 15, 2003Lolayekar Santosh C.Serverless storage services* Cited by examinerNon-Patent CitationsReference1Charles M. Kozierok, Overview and History of the SCSI Interface, PC Guide (http://www.pcguide.com/ref/hdd/if/scsi/over-c.html), 2002.2 *Cisco Systems. iSCSI Protocols Concepts and Implementations. May 2001. pp. 1-12.3Julian Satran, et al., The Internet-Draft titled "iSCSI" (http://ietf.org/internet-drafts/draft-ietf-ips-iscsi-13.txt), Jun. 2002.4Marjorie Krueger, et al., iSCSI Requirements and Design Considerations (http://ietf.org/internet-drafts/draft-ietf-ips-iscsi-reqmts-05.txt), 2001.5Office Action for U.S. Appl. No. 10/236,742 mailed on Nov. 4, 2005.6OSI (http://searchnetworking.techtarget.com/sDefinition/0,sid7-gci212725,00.htm), 2001.7OSI (http://searchnetworking.techtarget.com/sDefinition/0,sid7�gci212725,00.htm), 2001.8Postel, RFC 793 of the U.S. DARPA, Transmission Control Protocol: DARPA Internet Program Protocol Specification, 1981.9 *Satran et al. draft-ietf-ips-iscsi-07.txt. Jul. 20, 2001. pp. 1-189.* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS20140101348 *Dec 10, 2013Apr 10, 2014Marvell World Trade Ltd.Hard disk drive with integrated ethernet interface* Cited by examinerClassifications U.S. Classification709/212, 709/230International ClassificationH04L29/06, G06F15/167, H04L29/08Cooperative ClassificationH04L69/16, H04L69/12, H04L67/1097, H04L69/168, H04L69/161, H04L69/22European ClassificationH04L29/06J17, H04L29/06G, H04L29/06J, H04L29/06N, H04L29/06J3, H04L29/08N9SRotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services