Multiplex communications – Data flow congestion prevention or control – Flow control of data transmission through a network
Reexamination Certificate
2000-04-19
2003-06-03
Ton, Dang (Department: 2666)
Multiplex communications
Data flow congestion prevention or control
Flow control of data transmission through a network
C370S395420
Reexamination Certificate
active
06574195
ABSTRACT:
BACKGROUND
1. Technical Field
This invention relates generally to the field of computer networks, and particularly to quality of service management of data transmitted over a computer network.
2. Background of the Present Invention
Currently, one of the fastest growing markets is the network services provider market, such as wide area network (“WAN”) backbones and Internet core switch services, in which bandwidth needs are exploding. For network services providers to differentiate themselves from each other, value-added services, such as quality voice capability over a network, is a desirable service to offer. However, with such value-added services, even greater amount of bandwidth as well as a greater control over the network is needed.
Currently, network service providers rely upon conventional switches to connect dial-in port concentrators to the backbone of the network, such as the Internet, as well as to network computer servers. These servers and port concentrators typically communicate with each other through the use of the Internet protocol (“IP”). The port concentrators typically communicate with the backbone of the network through the use of the asynchronous transfer mode (“ATM”) protocol. Due to the high bandwidth associated with ATM, ATM switches typically are the preferred type of switches for the network service provider's core network. In particular, this high bandwidth is due to the use in ATM of fast explicit rate (“ER”) flow control, hard quality of service (“QoS”), good QoS routing and virtual circuit (“VC”) switching. However, there are certain limitations that exist with ATM that discourage the future use of this protocol within higher capacity switches.
The primary problems with ATM switches are the fixed sizes of ATM cells, too many operating system interrupts that reduce peak speed, costly network interface card, a 20% “cell tax” overhead, signaling too slow for data (e.g., due to round trip path set-up and closure) and poor routing stability. For example, in ATM, VC technology typically is used to achieve bandwidth that is needed for voice and video data. In addition, VC technology is able to achieve better flow control and quality of service (“QoS”) for data than a conventional IP-based system. The VC concept, which was developed by Dr. Lawrence Roberts for X.25, establishes a simple marked path through the network that not only greatly increases switching speed, but also creates a context for the QoS and flow control for each call transmission. Without VC-based ATM in a conventional system, it is nearly impossible to provide “hard QoS” or controlled delay variation that is required for toll quality two-way voice and video.
ER flow control is needed in ATM to stop the delay creep associated with world wide web access. However, ER flow control only is beneficial for switches that also have VC switching. Switches along a VC path, which are supporting ER flow control, mark small out of band packets to indicate the maximum rate that can be for sending data. The ATM switch needs the VC context to identify VC's and to mark the path back to the source. Fast signaled VC ATM-based switching can accomplish this transmission rate and still operate 20 times faster than a conventional IP packet switch. However, ER flow control is very difficult to design and to support the many to one joints in the VC mesh-type structure. This configuration typically requires approximately 100 times the processing time per packet that normal packet processing requires. Such requirements are infeasible with today's conventional high speed switches. Furthermore, the scalability of the VC ATM-based switch is limited by the number of VC's available in ATM. In particular, this characteristic limits the number of destinations ATM can set up. As the Internet grows, this limitation will create a serious limitation for ATM. Furthermore, without the capability to join together on a certain trunk VC's that are going toward the same destination, the size of a conventional network that can be supported is further severely limited. In addition, with regard to failure recovery, when a trunk or switch fails within a VC mesh, the routes must be rebuilt. If there are pre-formed alternate paths, the alternate routes also must be rebuilt. The time to rebuild depends upon the call setup rate of the switch technology and if that is not much faster than ATM call setup is today, the rebuild time can become excessive and intolerable in conventional networks. In addition, if the network
100
utilizes the synchronous optical network (“SONET”) protocol, failure of a trunk line results in the need for all traffic to be redirected from that trunk, which typically results in a 50 millisecond outage.
Because of protocol complexity and because of the reliance upon software-implemented protocols for ATM switches, the signaling protocol is too slow and the virtual circuit (“VC”) allocation is too low for conventional ATM switches to provide the necessary capacity for next generation services. In addition, with world wide web applications permeating all across the Internet and Intranets, the signaling rates and VC counts are becoming far too high for current conventional ATM switches to be useful. Thus, even though ATM's protocol stack is currently viewed as superior to other protocol stacks, such as IP, ATM is becoming limited because it cannot compete with IP in cost to the user and in signaling capacity on the network backbone for the network service provider.
To attempt to offer the robustness of ATM, but through the use of IP, alternative conventional protocols for IP have been proposed for offering a certain quality of service (“QoS”). In particular, the specific advantages associated with transmission control protocol (“TCP”)/IP include the ability to have variable size packets, less operating systems interrupts, cheaper NICs, fast routing for data calls and packets can be efficiently transmitted over a trunk.
However, conventional networks
100
utilizing TCP/IP as illustrated in
FIG. 9
are very slow due to TCP flow control, the lack of availability of standard or hard QoS, the lack of Qos routing and the limitations associated with analyzing each packet for routing purposes. In particular, since conventional networks
100
cannot route information based upon per-flow state information, conventional networks
100
are unable to route each flow on a path with sufficient capacity. Rather, as illustrated in
FIG. 1A
, a conventional network
100
focuses upon total capacity available and not on the availability of guaranteed rate (“GR”) capacity. In particular, a conventional network
100
selects the shortest path for a group of micro-flows (“composite flow”) and transmits that composite flow entirely over that designated path. This technique typically leads to the overloading of a specific trunk line, thereby making QoS very difficult to implement. Without state information, a switch cannot identify which path each micro-flow should be sent over. This limitation prevents the switch from splitting the composite flow into smaller micro-flows that can be routed over specific routes that have available capacity.
Without the ability to avoid having to rely upon composite flows, the network
100
is unable to route these micro-flows in the most efficient manner over the network
100
. For example, if a trunk line on the network
100
was not able to manage the additional capacity associated with a composite flow (e.g., composite flow (A+B)), that composite flow would have to be rerouted onto another trunk line. Because the composite flow could not be resized, composite flow (A+B) could only be rerouted onto a trunk with at least the capacity needed for this composite flow. Any trunk lines that have less than the capacity needed for composite flow (A+B) would remain unused.
If all paths within a network
100
were fully loaded, conventional networks
100
also cannot discard packets from a specific micro-flow, thereby limiting the efficiency of the network
100
. Dis
Caspian Networks, Inc.
Fenwick & West LLP
Ton Dang
LandOfFree
Micro-flow management does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Micro-flow management, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Micro-flow management will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3158369