Storing a frame header

Details Storing a frame header Storing a frame header

2002-07-02

2003-09-30

Meky, Moustafa M. (Department: 2157)

Electrical computers and digital processing systems: multicomput

Miscellaneous

C708S530000, C714S703000

Reexamination Certificate

active

06629125

ABSTRACT:

BACKGROUND
The invention relates to storing a frame header, for example in connection with a network controller.
Referring to
FIG. 1
, a server
12
may communicate with a client
10
by transmitting packets
8
of information over a network
18
pursuant to a network protocol. As an example, the network protocol may be a Transmission Control Protocol/Internet Protocol (TCP/IP), and as a result, the client
10
and server
12
may implement protocol stacks, such as TCP/IP stacks
17
and
19
, respectively. For the client
10
(as an example), the TCP/IP stack
17
conceptually divides the client's software and hardware protocol functions into five hierarchical layers
16
(listed in hierarchical order): an application layer
16
a
(the highest layer), a transport layer
16
b
, a network layer
16
c
, a data link layer
16
d
and a physical layer
16
e
(the lowest layer).
More particularly, the physical layer
16
e
typically includes hardware (a network controller, for example) that establishes physical communication with the network
18
by generating and receiving signals (on a network wire
9
) that indicate bits of the packets
8
. The physical layer
16
e
recognizes bits and does not recognize packets, as the data link layer
16
d
performs this function. In this manner, the data link layer
16
d
typically is both a software and hardware layer that may, for transmission purposes, cause the client
10
to package the data to be transmitted into the packets
8
. For purposes of receiving packets
8
, the data link layer
16
d
may, as another example, cause the client
10
to determine the integrity of the incoming packets
8
by determining if the incoming packets
8
generally conform to predefined formats and if the data of the packets comply with checksums (or cyclic redundancy check (CRC))of the packets, for example.
The network layer
16
c
typically is a software layer that is responsible for routing the packets
8
over the network
18
. In this manner, the network layer
16
c
typically causes the client
10
to assign and decode Internet Protocol (IP) addresses that identify entities that are coupled to the network
18
, such as the client
10
and the server
12
. The transport layer
16
b
typically is a software layer that is responsible for such things as reliable data transfer between two end points and may use sequencing, error control and general flow control of the packets
8
to achieve reliable data transfer. The transport layer
16
b
may cause the client
10
to implement the specific network protocol, such as the TCP/IP protocol or a User Datagram Protocol (UDP) or Realtime Transport Protocol(RTP) which exists on top of UDP, as examples. The application layer
16
a
typically includes network applications that, upon execution, cause the client
10
to generate and receive the data of the packets
8
.
Referring to
FIG. 2
, a typical packet
8
may include an IP header
20
that indicates such information as the source and destination IP addresses for the packet
8
. The packet
8
may also include a security header
23
that indicates a security protocol (e.g. IPSec) and attributes of the packet
8
and a protocol header
22
(a TCP or an UDP protocol header, as examples) that is specific to the transport protocol being used. As an example, a TCP protocol header might indicate a TCP destination port and a TCP source port that uniquely identify the applications that cause the client
10
and server
12
to transmit and receive the packets
8
. The packet
8
may also include a data portion
24
, the contents of which are furnished by the source application. The packet
8
may include additional information, such as a trailer
26
, for example, that is used in connection with encryption and/or authentication of the data portion
24
.
Referring to
FIG. 3
, as an example, a TCP protocol header
22
a
may include a field
30
that indicates the TCP source port address and a field
32
that indicates the TCP destination port address. Another field
34
of the TCP protocol header
22
a
may indicate a sequence number that is used to concatenate received packets of an associated flow. In this manner, packets
8
that have the same IP addresses, transport layer port addresses (and security attributes), are typically part of the same flow, and the sequence number indicates the order of a particular packet
8
in that flow. Thus, as an example, a packet
8
with a sequence number of “244” typically is transmitted before a packet
8
with a sequence number of “245.”
The TCP protocol header
22
a
may include a field
38
that indicates a length of the header
22
a
, a field
44
that indicates a checksum for the bytes in the header
22
a
and a field
40
that indicates control and status flags.
In order to transmit data from one application to another over the network wire, the data is segmented into frames. The maximum number of bytes that can be packed into one frame is called the maximal transmit unit (MTU). Thus, the operating system may pass data units down to hardware, such as network controller, in units that correspond to the MTU.
There is overhead associated with segmenting the data into MTUs, creating the frame header at all layers, and transmitting multiple messages down the stack to a miniport driver or other drivers for other operating systems or hardware. A driver, containing device specific information, communicates with non-device specific port drivers that in turn communicate with the protocol stack on behalf of the system. When the operating system wishes to offload some of that overhead, it may pass data to the miniport driver or hardware in data units larger than the MTU. This type of transfer is generally called a large send. The miniport driver or hardware can now segment the data and create the framing information.
Generally a large send requires that header information be recreated for successive frames. However, this will result in delay and overhead and also requires the header to be read across the system bus with every segment prior to its modification. This may increase the overall delay to complete the data exchange between the client and the server and consume bus resources that are important especially for server and multiple controller systems.
Thus, there is a continuing need for implementing a large send in a way which reduces the consumption of bus resources.
SUMMARY
In one embodiment of the invention, a method for use with a computer system, includes receiving output data from the computer system, extracting the header of the packet; storing a header from said data in a header memory, retrieving the header from header memory and parsing the header to add additional information to the header.


REFERENCES:
patent: 5608892 (1997-03-01), Wakerly
patent: 5664116 (1997-09-01), Gaytan et al.
patent: 5832235 (1998-11-01), Wilkes
patent: 5875466 (1999-02-01), Wakerly
patent: 5892924 (1999-04-01), Lyon et al.
patent: 6047304 (2000-04-01), Ladwig et al.
patent: 6141738 (2000-10-01), Munter et al.
patent: 6243720 (2001-06-01), Munter et al.
patent: 6289023 (2001-09-01), Dowling et al.
patent: 6343306 (2002-01-01), Lo

Affiliated with

Also associated with

Rating

Storing a frame header does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Storing a frame header, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Storing a frame header will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3037692