Multiplex communications – Communication techniques for information carried in plural... – Adaptive
Reexamination Certificate
1999-07-30
2004-04-27
Sam, Phirin (Department: 2661)
Multiplex communications
Communication techniques for information carried in plural...
Adaptive
C370S395400, C370S395420
Reexamination Certificate
active
06728265
ABSTRACT:
BACKGROUND
The invention relates to controlling frame transmission, 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 endpoints 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), 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., 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 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 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.
Because of bandwidth limitations, networks may provide different quality of service or class of service for different users or different applications. The data may flow through the network in a controlled fashion based on the specific class of service policy or a quality of service agreement. These policies and agreements are generally implemented in existing systems using software. Thus, the granularity of the pacing of the data through the network is limited by the speed possible with software.
Thus, there is a continuing need for a way of controlling frame transmission which allows the data pace through the network to be increased.
SUMMARY
In one embodiment of the invention, a method for controlling frame transmission includes assigning a time based transmission priority to a plurality of frames. The time is monitored and a frame is selected for transmission based on the time and the time based transmission priority.
REFERENCES:
patent: 5485457 (1996-01-01), Aramaki
patent: 5521923 (1996-05-01), Willmann et al.
patent: 5548590 (1996-08-01), Grant et al.
patent: 5640389 (1997-06-01), Masaki et al.
patent: 5699519 (1997-12-01), Shiobara
patent: 5724513 (1998-03-01), Ben-Nun et al.
patent: 5757771 (1998-05-01), Li et al.
patent: 5818818 (1998-10-01), Soumiya et al.
patent: 5844890 (1998-12-01), Delp et al.
patent: 5845043 (1998-12-01), Yanagihara
patent: 5859835 (1999-01-01), Varma et al.
patent: 5870629 (1999-02-01), Borden et al.
patent: 5898668 (1999-04-01), Shaffer
patent: 5926458 (1999-07-01), Yin
patent: 5982748 (1999-11-01), Yin et al.
patent: 5999534 (1999-12-01), Kim
patent: 6023453 (2000-02-01), Ruutu et al.
patent: 6067301 (2000-05-01), Aatresh
patent: 6104700 (2000-08-01), Haddock et al.
patent: 6108307 (2000-08-01), McConnell et al.
patent: 6205150 (2001-03-01), Ruszczyk
patent: 6205151 (2001-03-01), Quay et al.
patent: 6377546 (2002-04-01), Guerin et al.
patent: 6377583 (2002-04-01), Lyles et al.
patent: 6389019 (2002-05-01), Fan et al.
patent: 6570876 (2003-05-01), Aimoto
Uri Elzur et al., U.S. patent application Ser. No. 09/364,374, filed Jul. 30. 1999, entitled “Storing a Frame Header”.
Uri Elzur et al., U.S. patent application Ser. No. 09/364,195, filed Jul. 30, 1999, entitled “Coordinating Authentication and Encryption/Decryption”.
Ronen Chayat, U.S. patent application Ser. No. 09/364,375, filed Jul. 30, 1999, entitled “Selectively Transmitting Packets”.
Elzur Uri
Tai Charles
Yavatkar Raj
LandOfFree
Controlling frame transmission does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Controlling frame transmission, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Controlling frame transmission will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3235223