Multiplex communications – Data flow congestion prevention or control
Reexamination Certificate
2002-10-28
2004-07-06
Ton, Dang (Department: 2666)
Multiplex communications
Data flow congestion prevention or control
C370S389000
Reexamination Certificate
active
06760304
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention generally relates to the management of received network events handled by a plurality of processing nodes. More specifically, the invention relates to a highly scalable apparatus for management of a receive transport protocol termination through the use of queues and pointers to memory locations.
2. Discussion of the Related Art
In the related art, operation in multiprocessing environments is known for handling various tasks requiring significant amounts of computing power, and which is best achieved by plurality of processors operating in parallel. Over time, it has become increasingly easy in the related art to integrate more than one processing node on a single chip, and thus create a powerful parallel processing unit. While the related art integration is highly effective in general processing applications, in other areas it would be advantageous to employ multiprocessing capabilities.
For example, in the related art area of network processing, many generally independent events occur in parallel and over short periods of time. For example, a file transfer protocol (FTP) session initiated by one user may be handled in parallel with another FTP session initiated by the same or another user, as well as other types of protocols that may be handled in parallel. Each FTP session generates its own events which, while adhering to the FTP requirements, are independent of each other. To achieve higher system throughput, it may be advantageous to handle these FTP sessions in parallel.
In the related art of the seven-layer communication model, data transferred over the network moves through the different layers to reach its final stage. The first layer is the physical layer that provides mechanical, electrical, functional and procedural means to activate, maintain and de-activate physical connections for bit transmission between data-link-entities, while the second layer is the data link layer that handles the transmission of frames (blocks) in a substantially error-free manner. Also, the third layer is the network layer that determines how messages are routed within the network, and allows transport entities to be independent from routing and relay considerations, including sub-network nodes.
The fourth layer is the transport layer that hides details of any network-dependent information from the higher layers by providing transparent data transfer. The transport layer is concerned with node to node transfer of data, rather than process to process. At the receiver portion, the data is reassembled in the correct sequence. Commonly, the activities associated with the handling of the third and fourth layer are performed by software.
The fifth layer is the session layer, as described in the related art standard communication model, and is responsible for establishing and releasing session connection. The sixth and seventh layers are the presentation and application layers, respectively, and are responsible for transforming application data into the common network format, and for communicating application process parameters.
In the related art, traffic is transported over the network using the transmission control protocol (TCP) or user datagram protocol (UDP). TCP is a connection-oriented transport media that sends data as unstructured streams of bytes. By using a sequence number and acknowledgment messages, TCP provides the source node with status on the bytes transmitted to the destination node. TCP is used when a reliable transport medium is required.
When data is lost, TCP can resend lost data, thereby ensuring reliable connectivity. TCP sends data as a sequence of “segments”. A segment is a collection of data bytes sent as a single message. Each segment is sent through the network individually, with certain header information affixed to the segment. As a whole, the sequence of segments is referred to as a datagram.
When datagrams are received from a source at a destination, the original information is reconstructed. The reconstruction may take various forms in the related art to support the specific application that began the process on the transmitting side. For example, if a file transfer protocol (FTP) takes place, then an application capable of reconstructing the original data from the datagrams received is used. In addition to its payload, each datagram contains additional information including the source address, the destination address, the source port and destination port numbers, checksum information, segment length and a byte sequence number.
The checksum field contains a digest of the header and the payload, and is used to confirm correct reception of data. The segment length field in the header specifies the number of payload bytes contained in the segment, and the sequence number indicates the position of the last byte of the segment in the continuous byte stream.
If the data has been received correctly, then an acknowledgement signal is sent to the source to confirm successful receipt of the datagram. However, if such an acknowledgement is not received at the source from the destination, or an error notification is received, the datagram is retransmitted from the destination to the source. Once all of the data segments have been received and reconstructed to the original data, the transmitted data segments may be used by the destination.
With the advent of related art high speed network systems, transmitting at speeds of over one gigabit per second (1 Gbps and 10 Gbps systems are currently in various stages of deployment), it is becoming increasingly advantageous to move traditionally software based activities of TCP to high performance hardware implementations. Scaling software based solutions for higher performance is normally considered a significant challenge in the related art. For example, but not by way of limitation, the number of bits per second to be transferred is correlated with the number of instructions per second to be processed. Therefore, it would be necessary at the TCP level to have processors capable of providing performance of 10 giga instructions per second for a 10 Gbps network, which would result in a high cost system.
Accordingly, it would be advantageous to provide a hardware solution for processing TCP level activities, and for such a solution to be easily scalable. For example, a plurality of processing nodes operating in parallel can be provided. The solution must be consistent with the standard communication model as developed by the International Standards Organization (ISO) and known as the Open Systems Interconnection (OSI) networking suite. It consists of seven layers: physical (L
1
), logical or data link (L
2
), network (L
3
), transport (L
4
), session (L
5
), presentation (L
6
), and application (L
7
). Each layer handles a different facet of the communication providing clear definitions on how data received from the network is to be handled on its way to the application layer (L
7
), and vice versa, how data from the application layer is to be transferred onto the network by the physical layer (L
1
). A significant amount of processing takes place in each of these stages to ensure proper operation and interoperability between software and hardware components of the system and those of different vendors. Data moving between the layers is generally accompanies by a layer header containing information about the data attached to the data construct, e.g., a data packet of a data block.
However, the challenges that require addressing in a multiprocessing environment for transmit transport termination in a computer network are different from those in general application multiprocessing. For example, but not by way of limitation, traffic flowing over the network must be handled efficiently without impacting overall system performance. It would also be advantageous to provide easily scalable solutions, hence overcoming the significant costs and complexities associated with the aforementioned prior art solutions.
However, the related art does not provide any scalable
Har-Chen Dror
Uzrad-Nali Oran
Silverback Systems Inc.
Ton Dang
LandOfFree
Apparatus and method for receive transport protocol termination does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Apparatus and method for receive transport protocol termination, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Apparatus and method for receive transport protocol termination will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3239304