This invention relates in general to management of high speed packet network traffic and in particular to a method for reducing network traffic congestion.
The Internet supports diverse types of traffic including graphic images, file transfer data, interactive multimedia, real-time video, and voice. Despite the rapid growth in the number of Internet users, their expectations about the quality and timely display of information received from the internet backbone networks continue to be very high.
Referring now to the figures, there is shown in
Regardless of the particular communication medium, the message is broken into packets of data and each packet includes both the sender's and the receiver's addresses. The addresses are assigned in accordance with an Internet Protocol (IP). The packets are received by the entry router 14 and forwarded to an adjacent intermediate gateway, or intermediate router 16, as indicated by the solid line in
Generally, IP is a connectionless protocol, which means that there is no continuing connection between the end points that are communicating. Thus, as each packet travels through the internet, it is treated as an independent unit of data without any relation to any other packet and the individual packets may well be sent over different paths as they cross the internet 10. As a result, the individual packets that comprise a message may well arrive at the receiver 20 out of their sending order. A Transmission Control Protocol (TCP) places the packets back into the correct sequence at the receiving end.
As the usage of the internet continues to increase, it has become desirable to provide enhanced handling for certain messages, rather than process each packet in sequence. For example, voice traffic requires a relatively uninterrupted flow of traffic while transmission of data files usually can be interrupted without undue disruption of services. Various attempts have been made to manage traffic to reflect the different levels of service requirements. Early versions applied priority handling tags to the packets. More recently, a Differentiated Services (DiffServ or DS) protocol has been adopted to provide precedence to certain classes of service by providing more complex policy of rule statements to determine how to forward a given network packet. Under the DiffServ protocol, different classes of service, such as e-mail, streaming video, large document file transfer and voice may be handled differently. Each class is may be assigned a type of service designation that specifies the desired optimization of delay, reliability and cost. For a given set of packets that comprise a message, each packet is given one of 64 possible forwarding behaviors, known as Per Hop Behaviors (PHB's). A six bit field, known as a Differentiated Services Code Point (DSCP), in the IP header specifies the PHB for a given flow of packets. The routers within a DiffServ network then handle the packets on different traffic flows by applying different PHB's based upon the settings of the DSCP, rather than sorting the packets at intermediate node within the network. In this manner, many traffic flows can be gathered into one of several predefined PHB's to reduce the processing and storage needed for classification and forwarding of packets.
The DiffServ protocol is an attempt to provide a priority queuing system that would operate in a manner similar to an interrupt system of an operating system where transient, or interrupt driven, users are allowed to momentarily interrupt the other users for a short period of time. Thus, in theory, the DiffServ protocol places high priority requests at the front of the priority queue. Unfortunately, data network messages often use very large groupings of data in a given packet or message, resulting in delays, even with priority queuing, as currently transmitting packets must complete transmission and equal priority packets must compete before “interrupt” level traffic may process. This condition is further exacerbated since similar queuing must occur at each intermediate router 16 as the packets are transmitted across the interne 10. Additionally, the complicated queuing algorithms utilized by the DiffServ protocol require a high level of processing of the packets at each intermediate router 16 along the transmission path. Accordingly, it would be desirable to provide a management mechanism for implementing admission control policy in a DiffServ network that would reduce traffic congestion.
This invention relates to a method for reducing network traffic congestion within a high speed packet network.
The present invention contemplates an apparatus for controlling the flow of message packets across a message packet network that includes an entry router that provides access to an internet backbone network having at least one transmission route dedicated to transmission of priority message packets. The apparatus also includes an admission controller that is connected to the entry router and adapted to receive message packets from an internet user. The admission controller is operative to examine the header of each message packet generated by the user. Upon determining that a message packet header includes a priority message identifier, the admission controller is further operative to compare the length of the priority message packet to a threshold priority message packet length. Upon determining that the priority message packet is less than or equal to the threshold priority message packet length, the admission controller forwards the priority message packet over the internet via said dedicated priority message route.
The admission controller is also operative, upon determining that the priority message is longer than the threshold priority message packet length, to remove the priority message identifier from the message header and forward the resulting message packet over the internet via a best effort route.
Additionally, upon determining that a marked priority message exceeds the threshold priority message packet length, the admission controller returns an error message to the sender. If the priority message requests were allowed to be arbitrarily long, some of the same queuing, or congestion, problems of prior art systems would result.
Various objects and advantages of this invention will become apparent to those skilled in the art from the following detailed description of the preferred embodiment, when read in light of the accompanying drawings.
Referring again to the drawings, there is illustrated in
Additionally, the interne 10 has been sub-divided to provide a plurality of priority service routes and non-priority routes for transferring messages. The priority routes are shown by dashed lines that are included in the upper portion of the interne 10 that is labeled 24 in
The non-priority routes are shown by solid lines that are included in the lower portion of the internet 10 that is labeled 32 in
The admissions controller 22 is operative to monitor and screen message packets arriving at the internet 10. The screening separates the message packets into the two portions 24 and 32. The present invention contemplates that the admissions controller 22 would separate priority packets, such as those identified by the DiffServ protocol, from the normal best effort traffic flow. The lengths of the priority message packets would be compared to a threshold packet length consistent with the bandwidth requirements for the dedicated priority routes shown in the upper portion 24 of the internet 10 in
An algorithm used by the admission controller 22 for implementing the segmentation of traffic over the internet 10 in accordance with the invention is illustrated by the flow chart shown in
In decision block 48, the message packet length is compared to a threshold length, TL, for admission to the priority routes. The threshold length is selected to be compatible with the transmission parameters for the priority routes. In general, the threshold length TL is selected as a function of the application since different applications have different control message lengths. For example, if the only valid control message is a HTTP get request, then the corresponding TL is selected to be slightly larger that the length of a get request. If the message packet length is less than or equal to the threshold length TL the packet qualifies as received for transmission over a priority route. Accordingly, the algorithm advances directly to functional block 50 where the packet is forwarded to the priority entry router 26 shown in
If, in decision block 48, the message packet length is greater than the threshold length TL, the message is denied entry into the priority routes and the algorithm advances to decision block 56. In functional block 56 the priority message code is removed from the message header to prevent confusion within the intermediate routers 16. The algorithm continues to functional block 58 where an error message is returned to the sender. The algorithm then advances to functional block 44 where the message is transmitted over the internet 10 via one of the best effort routes. The algorithm then exits through block 46 and awaits the arrival of the next message packet at the admission controller 22.
The algorithm shown in
For simplicity, only unidirectional movement has been shown in
An alternate embodiment of the invention is illustrated in
The invention further contemplates another alternate embodiment in which the number of available dedicated priority paths across the internet 10 is variable. In the alternate embodiment the admission controllers 22 and 60 are operative to continuously monitor the level of priority and non-priority packet traffic on the internet 10 and move routes between the priority routing region 24 and the non-priority routing region 32. Thus, if priority traffic demand falls off, some of the designated priority routes may be made available for best effort transmission of non-priority messages. Similarly, if priority traffic demand increases, some of the best effort routes can become dedicated for transmission of priority message packets only. Alternately, the redesignation of routes may be controlled by preset parameters, such as, for example time of day where it is known that the frequency of priority messages falls off during certain time periods.
By separating the transmission routes, the network links can be optimized for specific uses, thereby matching user requirements with network capabilities. As a result, it is expected that the user perception of slow network operation will be reduced without having to greatly overbuild the network to accommodate the traffic.
The principle and mode of operation of this invention have been explained and illustrated in its preferred embodiment. However, it must be understood that this invention may be practiced otherwise than as specifically explained and illustrated without departing from its spirit or scope.
Number | Name | Date | Kind |
---|---|---|---|
5276899 | Neches | Jan 1994 | A |
5367523 | Chang et al. | Nov 1994 | A |
5699521 | Iizuka et al. | Dec 1997 | A |
5727151 | Sugahara et al. | Mar 1998 | A |
5761534 | Lundberg et al. | Jun 1998 | A |
5867731 | Williams et al. | Feb 1999 | A |
5901156 | Botzenhardt et al. | May 1999 | A |
5903735 | Kidder et al. | May 1999 | A |
5920705 | Lyon et al. | Jul 1999 | A |
6141322 | Poretsky | Oct 2000 | A |
6147970 | Troxel | Nov 2000 | A |
6292489 | Fukushima et al. | Sep 2001 | B1 |
6324570 | Tonchev et al. | Nov 2001 | B1 |
6426943 | Spinney et al. | Jul 2002 | B1 |
6449253 | Ott | Sep 2002 | B1 |
6469983 | Narayana et al. | Oct 2002 | B2 |
6487170 | Chen et al. | Nov 2002 | B1 |
6584509 | Putzolu | Jun 2003 | B2 |
6622160 | Horvitz | Sep 2003 | B1 |
6633564 | Steer et al. | Oct 2003 | B1 |
6748435 | Wang et al. | Jun 2004 | B1 |
6845105 | Olsson et al. | Jan 2005 | B1 |
6859842 | Nakamichi et al. | Feb 2005 | B1 |
6877038 | Hakenberg et al. | Apr 2005 | B2 |
6901452 | Bertagna | May 2005 | B1 |
6973085 | Acharya | Dec 2005 | B1 |
7027402 | Hedden | Apr 2006 | B2 |
7174374 | Wang et al. | Feb 2007 | B2 |
7188188 | Madhavapeddi et al. | Mar 2007 | B1 |
20020087715 | De Cnodder et al. | Jul 2002 | A1 |
20020136217 | Christensen | Sep 2002 | A1 |
20030133411 | Ise et al. | Jul 2003 | A1 |
20040052214 | Teh et al. | Mar 2004 | A1 |
20060168336 | Koyanagi et al. | Jul 2006 | A1 |
Entry |
---|
Tutorial: Interworking Switched Circuit and Voice-over-Ip Networks, Performance Technologies, Inc., Aug. 22, 2001. |
SS7 Tutorial, Performance Technologies, Inc., Aug. 22, 2001. |
Zvolve, Executive Summary on Conscious [online], Retrieved from the intemet on Nov. 18, 2002, http://www.zvolve.com/. |
Zvolve, White Paper: The Need for Business Driven Real-Time Traffic Engineering [online], Retrieved from the internet on Nov. 18, 2002, http://www.zvolve.com/. |
Zvolve, Frequently Asked Questions, Conscious: The Business-Driven Real-Time Traffic Engineering System [online], Retrieved from the internet on Nov. 18, 2002, http://www.zvolve.com/. |
William E. Witowsky, White Paper: IP Telephone Design and Implementation Issues, Telogy Networks, Inc [online], Retrieved from the intemet on Dec. 16, 2002, http://www.telogy.com/. |
Ananthanayanan Ramanathan and Manish Parashar, Active Resource Management for the Differentiated Services Envirnoment, [online], Retrieved from the intemet on Apr. 28, 2003, http://www.interscience.wiley.com/. |
Markus Isomäki, Differentiated Service for the Internet, [online], Retrieved from the internet on Apr. 28, 2003, http://www.hut.fi/. |
John Sikora and Ben Teitelbaum, Differentiated Services for Internet2 (draft) [online], Retrieved from the intemet on Apr. 28, 2003, http://www.qos.internet2/may98 Workshop/html/diffserv.html. |