Electrical computers and digital processing systems: multicomput – Computer network managing – Computer network monitoring
Reexamination Certificate
1999-07-30
2002-07-30
Meky, Moustafa M. (Department: 2153)
Electrical computers and digital processing systems: multicomput
Computer network managing
Computer network monitoring
C370S401000
Reexamination Certificate
active
06427169
ABSTRACT:
BACKGROUND
The invention relates to parsing a packet header.
Referring to
FIG. 1
, a server
12
may communicate with a client
10
by transmitting packets
8
, or frames, 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 the bits that make up 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 cyclic redundancy check (CRC) codes or other error correction codes of the packets. The data link layer
16
d
may also perform address filtering.
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 endpoints and may use sequencing, error control and general flow control of the packets
8
to achieve it. The transport layer
16
b
may cause the client
10
to implement a specific protocol, such as the TCP protocol or a User Datagram Protocol (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 include a security header
23
that indicates a security protocol (e.g., an IPSec protocol) and attributes of the packet
8
, and the packet
8
may include a transport 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; and a trailer
26
that is used for encryption purposes.
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. Packets
8
that have the same IP addresses, transport layer port addresses and security attributes are part of the same flow, and a sequence number (described below) indicates the order of a particular packet
8
in that flow.
In this manner, the data bytes of the flow may be sequentially numbered even though the data bytes may be divided among the different packets
8
of the flow. To accomplish this, a field
34
of the TCP protocol header
22
a
may indicate a sequence number that identifies the first byte number of the next packet
8
. Therefore, if the last byte of data in a particular packet
8
has a byte number of “1000,” then the sequence number for this packet
8
is “1001” to indicate the first byte in the next packet
8
of the flow.
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. For example, the field
40
may indicate whether the packet
8
is the first or last packet
8
of a particular flow. As another example, the field
40
may indicate whether or not a particular packet
8
carries acknowledgment information that is used for purposes of “handshaking.” In this manner, an acknowledgment packet typically does not (but may) include data, and the receiver of a flow transmits an acknowledgment packet after the receiver receives a predetermined number (two, for example) of packets from the sender. In this manner, the receipt of an acknowledgment packet by the sender indicates that a predetermined number of packets were successfully transmitted. The TCP protocol header
22
a
may also include a field
43
that indicates a maximum number of bytes (called a “window”) that the sender may transmit before receiving an acknowledgment packet that at least indicates some of the bytes were successively received. Other fields are possible, such as a checksum field
44
and an urgent pointer field
42
, as examples. The urgent pointer field
42
indicates an offset from the current sequence number at which urgent data is located.
As an example, software that is associated with the transport
16
b
and network
16
c
layers, when executed by a processor of the client
10
, typically causes the client
10
to parse the information that is indicated by the protocol header
22
to facilitate additional processing of the packet
8
. However, the execution of the software may introduce delays that impede the communication of packets
8
between the client
10
and the server
12
.
Thus, there is a continuing need to address one or more of the problems stated above.
SUMMARY
In one embodiment of the invention, a method for use with a computer system includes receiving a packet that includes a header. The header indicates at least one characteristic that is associated with a layer of a protocol stack. The packet is parsed with a network controller to extract the characteristic(s), and the handle is passed from the network controller to indicate the characteristic(s).
In another embodiment, an apparatus is used with a computer system that is capable of executing software of a protocol stack to extract at least one characteristic of a packet. The apparatus includes an interface and a circuit. The interface is adapted to receive the packet, and the packet includes a header that indicates the characteristic(s). The circuit is adapted to parse the header to extract the characteristic(s) of the packet without causing the computer to execute the software and process the packet based on the extracted characteristic(s).
In yet another embodiment, a computer system includes a processor and a peripheral device. The processor is adapted to execute software of a network stack to extract at least one characteristic of a packet. The packet includes a header that indicates the characteristic(s). The peripheral device is adapted to receive the packet and parse the header to extract the characteristic(s). The peripheral device is
Intel Corporation
Meky Moustafa M.
Trop Pruner & Hu P.C.
LandOfFree
Parsing a packet 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 Parsing a packet header, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Parsing a packet header will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2825644