Patent Application
20060146825
1. Field of the Invention
The present invention relates to the field of data communications. More particularly, the present invention relates to providing quality of service measures to network traffic when routing data over multiple networks.
2. Background Information
Advances in technology have impacted many areas of computer automation; for example, computer applications are becoming increasingly ‘intelligent’. Traditionally, applications were developed to operate as stand-alone entities. Applications like word processors, spreadsheets, or database applications were traditionally confined to a single computer with minimal methods for direct data sharing. Data could only be shared by exchanging floppy discs or other removable storage mediums. However, by leveraging these mediums, Users experienced problems with synchronizing the data when they wanted to collaborate or share documents. Specifically, how can the data be synchronized when data is copied to floppies and modified? In most cases, synchronization results in data being changed in two locations.
Local Area Networks quickly changed the course of events for sharing application data. Instead of having applications each storing their own data on their own PCs, computers were interconnected with each other. Therefore, the persistent storage of the data occurred on file servers or other machines. Applications became network aware and were therefore designed to inherently share the data. The sharing of data was accomplished using two methods. In a client-server mode, applications would send a request and then the servers would respond with the appropriate data. In a batch mode, sharing occurred in batches where data would be synchronized at the end of a day or the end of a work shift.
As more applications were designed to facilitate the sharing of data, and networks improved, applications relied on networks more. Networking infrastructures like gigabit Ethernet provided a very fast connection for applications. Since many people realized the advantages of using network connections while stationary (i.e., connected to a physical LAN), they also began to see the advantages of network connections while in a mobile environment. Wireless networks are increasing in speed and provide developers with better opportunities for adding new services to applications. In addition, because of the power of performing work on the go, users began to request new types of applications: real time communication systems.
While traditional applications did not require a link in real time, new applications are being and have been developed that require constant streaming of data to mobile users. Applications like Voice over IP require a continuous stream of data packets between a mobile worker and the servers. In addition, applications like video surveillance, music, and movie broadcasts also require a constant stream of data. In traditional non-time-sensitive applications, if a packet is delayed due to network congestion or it is lost or corrupted during network transmission, the application can simply request the packet again with no adverse effect. However, in real time environments, delaying a packet may have an adverse effect on the data quality. In time-sensitive applications (such as streaming media applications), delayed packets can cause unexpected and noticeable pauses in the transmissions and dropped packets can cause corruption in the data stream for the receiver. In either case, the result can be an unacceptable loss of quality such that the transmission itself loses all value.
While delayed or dropped packets is a natural occurrence in data communications, the problem becomes more consequential in time-sensitive applications. In addition, the issue is exacerbated when there are multiple applications vying for the network link at the same time. For example, if a user is downloading a full motion video stream while printing a large document to a network printer, the network connection can be saturated thereby incurring delayed or dropped packets. In this example, the solution is to allow the time-sensitive application traffic to have priority. In the above example, full motion video should have transmission priority so that its data is not delayed or lost, while the printing can have a lower priority. If packets are dropped in the non time-sensitive applications, there will be minimal impact. In many cases, this type of network prioritization is called Quality of Service (QoS).
The problem is more serious when there are multiple networks being used. While there exist methods for prioritizing network activity within a single network, there is no additional mechanism to provide application quality of service between different networks. In addition, there is no easy method to provide quality of service functionality to applications that were not already designed to support quality of service.
In view of the foregoing, the present invention is directed to providing quality of service functionality for various applications when used over multiple networks, both wireless and wireline. The present invention, which may be embodied as network based QoS, allows a mobile data user to simultaneously and transparently communicate over multiple networks to a local area network or other mobile device while allowing certain data traffic to take priority over non-essential data traffic. Another aspect of the current invention gives users the ability to easily add quality of service functionality to applications without requiring costly source code changes.
According to an aspect of the present invention, a network-based quality of service routing method operates within a system including multiple parallel networks connecting a client device and a host device. The method includes routing a packet between the client device and the host device across one of the parallel networks. The network is selected based upon a priority assigned to the packet. In one embodiment, at least one other network is also selected, in addition to the first selected network, to transmit the packet based upon the priority. In the case of multiple packets having the same priority level, the packets may be routed over multiple selected networks, the selection being based upon the priority level.
In another aspect, a method is provided for propagating a QoS tag from an internal packet that is encapsulated by an outside packet to the outside packet. The method includes determining the QoS level of the internal encapsulated packet and setting the QoS level in the outside packet to the QoS level determined for the internal packet.
In yet another aspect, a method is provided for assigning a QoS value to a data packet based upon characteristics of the data packet, the data packet being received from a source application. The method includes determining whether the characteristics of the data packet match a user-defined criteria. When the characteristics of the data packet match the criteria, the method sets a QoS level within the packet. The QoS level was previously associated with the criteria by a user. Consequently, the packet is assigned the QoS level without processing by the source application.
In an aspect of the invention, a quality of service routing method operates within a system including multiple parallel dissimilar wireless networks connecting a client device and a host device. The method includes selecting one of the networks based upon criteria, including priority, of a packet received from a source application. The method also includes routing the packet between the client device and the host device across the selected network, the source application being unaware of the network selected for the packet.
The method may also include selecting at least one other network, in addition to the first selected network, to transmit the packet based upon the packet priority, and routing the packet over multiple selected networks.
In one embodiment, the selected network is a default network. The selected network may also be at least one alternate network. In this case, when multiple alternate networks are selected, the networks are listed in a priority order. The criteria can include at least one of a port, protocol, and an IP address.
The method can also include receiving at least one additional packet; and analyzing criteria, including priority, of the at least one additional packet. When the criteria matches predefined criteria, the at least one additional packet is discarded without transmitting the at least one additional packet.
In another aspect of the present invention, a method is provided for propagating a QoS tag from an internal packet that is encapsulated by an outside packet to the outside packet. The method includes determining a QoS level of the internal encapsulated packet; and setting the QoS level in the outside packet to the QoS level determined for the internal packet.
In still another aspect, a method is provided for assigning a QoS value to a data packet based upon characteristics of the data packet, the data packet being received from a source application that operates within a system including multiple parallel dissimilar wireless networks connecting a client device and a host device. The method includes determining whether the characteristics of the data packet match a user-defined criteria; and setting a QoS level within the packet when the characteristics of the data packet match the criteria. The QoS level was previously associated with the matched criteria by a user. Consequently, the packet is assigned the QoS level without processing by the source application.
In yet another aspect, a system assigns quality of service tags to data received from a source application without processing by the source application. The system operates with dissimilar, parallel wireless networks connecting a client device and a host device, and with data that is routed between the client device and the host device across selected networks while the source application is unaware of the networks selected. The system includes a partner process that receives data from the source application, and a QoS system. The QoS system receives data from the partner process and analyzes the data to determine whether the data matches criteria. The QoS system assigns a quality of service tag, associated with matching criteria, to the data. The QoS system also returns the data and quality of service tag information to the partner process. The criteria can include a port, protocol, and/or an IP address.
In another aspect, a system is provided for assigning quality of service tags to data received from a source application without processing by the source application. The system includes a routing process that receives data from the source application and selects multiple wireless networks for transmitting the data. The wireless networks are dissimilar, parallel, and connect a client device and a host device. The routing process routes the data between the client device and the host device across the selected networks with the source application being unaware of the networks selected. The system also includes a QoS system that receives data from the routing process and analyzes the data to determine whether the data matches criteria. The QoS system assigns a quality of service tag, associated with matching criteria, to the data when the criteria is matched. The QoS system returns the quality of service tag information and the data to the routing process for routing.
In one embodiment, the routing process selects the networks based upon the quality of service tag information. The QoS system can also analyze the data to determine whether the data matches criteria including the quality of service tag. The QoS system selects at least one network for the data based upon the matching criteria and returns the data and a network indicator to the routing process. The routing process can also select the networks based upon the network indicator.
In yet another aspect, a system routes data based upon quality of service tags associated with data received from a source application. The system operates with dissimilar, parallel wireless networks connecting a client device and a host device. The data is routed between the client device and the host device across selected networks while the source application is unaware of the networks selected. The system includes a partner process that receives data from the source application, and a QoS system. The QoS system receives data from the partner process and analyzes the data to determine whether the data matches criteria including a quality of service tag. The QoS system selects at least one network for the data based upon matching criteria, and returns the data and a network indicator to the partner process. The criteria can be a port.
In a further aspect, a system routes data based upon quality of service tags associated with data received from a source application. The system includes a routing system that receives data from the source application and routes the data over at least one wireless network selected based upon a network indicator associated with the data. The wireless network(s) are selected from dissimilar, parallel wireless networks that connect a client device and a host device. The routing system routes the data between the client device and the host device across the selected network(s) while the source application remains unaware of the network(s) being used. The system also includes a QoS system that receives data from the routing system and analyzes the data to determine whether the data matches criteria including a quality of service tag. The QoS system selects at least one network for the data based upon matching criteria, and returns the data and the network indicator to the routing system.
In one embodiment, the network indicator indicates a default network. The network indicator can also be at least one alternate network, so that when multiple alternate networks are indicated, the networks are listed in a priority order. The network indicator can indicates that the data is not to be sent, in which case the routing system does not send the data.
The present invention is further described in the detailed description that follows, by reference to the noted drawings by way of non-limiting examples of preferred embodiments of the present invention, in which like reference numerals represent similar parts throughout several views of the drawings, and in which:
Network based QoS functionality provides network administrators with added control over the data that flows over networks. While in certain cases, a mobile user will be using a single network; in many cases multiple wireless networks will be leveraged. To achieve an optimum multi-network experience, a mobile user should be able to seamlessly roam between different wireless networks using a wireless router. An exemplary router is described in U.S. Pat. No. 6,198,920, to DOVIAK et al., issued Mar. 6, 2001; U.S. Pat. No. 6,418,324, to DOVIAK et al., issued Jul. 9, 2002; and U.S. Pat. No. 6,826,405, to DOVIAK et al., issued Nov. 30, 2004, the disclosures of which are expressly incorporated by reference herein in their entireties.
Network based QoS builds upon the function of tagging application data traffic. QoS tags have existed since the early days of network design. The first description of the IP protocol included a field called “precedence” which serves as the basis for QoS tagging. Routers and other infrastructure devices interpret these tags to represent a priority value for the particular packet. As the packet flows through the network, the packet has priority through the network intermediary point if its tagged value is higher than other data.
Basic network tagging has been around for a long time, however, historically it has been the responsibility of the application developer to build support for the tags within their application. One aspect of this invention provides system administrators a user interface. One embodiment of the user interface may be a user-friendly graphical user interface (GUI) although other possibilities such as command line interfaces (CLI), configuration files, and programmatic APIs are possible as well. The system administrator may employ the user interface to define rules that, when matched for a packet emitted from an application, will allow tags to be imposed on that application traffic. This functionality occurs after the packet is emitted by the application and so is transparent to the application. Therefore, the applications do not have to be rewritten to support the addition of QoS tagging on the packets. This functionality has benefits for any type of application on any combination of networks since the system administrator can automatically choose which tags are used for which applications while not requiring costly application rewrites or application development.
Another feature of network based QoS provides QoS tag propagation. In many network applications, data encapsulation is used to communicate between a client and a server. Encapsulation is also known as “tunneling.” Encapsulation within the data communication industry is defined as the inclusion of one data structure within another structure so that the first data structure is temporarily hidden. For example, a TCP/IP-formatted data packet can be encapsulated within an ATM frame. Within the context of transmitting and receiving the ATM frame, the encapsulated packet is simply a stream of bits within the ATM data that describes the transfer. Many types of applications leverage encapsulation, including virtual private networks and network bridging apparatuses.
When using encapsulation, the original data packet may have certain characteristics that are lost when placed into the encapsulated data form. QoS tagging is an example of data that could be lost. If an application has tagged a packet with a high priority tag and that packet is subsequently encapsulated, the new header that is placed on the packet will not have the tag present. Therefore, network intermediaries have no way of determining the priority of the packet originally intended by the application. Therefore, the encapsulated packet will be routed according to a default priority. In addition, if the packet is encrypted, as through a VPN, the same problem occurs. The data priority of the packet is lost, and the packet is sent with a default level of priority.
Finally, network based QoS functionality can be used as criteria for routing data in a multiple network solution. In this example, a mobile user may be using two different networks in a multipathing format, e.g., as described in U.S. patent application Ser. No. 10/835,396, to HOFSTAEDTER et al., filed on Apr. 30, 2004, the disclosure of which is expressly incorporated by reference herein in its entirety, or in a prioritized port routing format as described in U.S. patent application Ser. No. 10/374,070, to HOFSTAEDTER et al, filed on Feb. 27, 2003, the disclosure of which is expressly incorporated by reference herein in its entirety, or in a broadcasting data over multiple dissimilar wireless networks format as described in U.S. patent application Ser. No. 10/967,130, to HOFSTAEDTER et al, filed on Oct. 20, 2004, the disclosure of which is expressly incorporated by reference herein in its entirety, or in a router environment as described in U.S. Pat. No. 6,198,920, to DOVIAK et al., issued Mar. 6, 2001; U.S. Pat. No. 6,418,324, to DOVIAK et al., issued Jul. 9, 2002; and U.S. Pat. No. 6,826,405, to DOVIAK et al., issued Nov. 30, 2004, the disclosures of which are expressly incorporated by reference herein in their entireties.
Criteria can be added that will allow the appropriate transmission type to be chosen based upon the QoS tags of the data. In a multipathing environment, it may be determined that voice over IP data packets should have a QoS tag of five. In addition, it may be determined that data with QoS tags of five should flow through the multipathing subsystem. Therefore, when the data is received at the router, the system will compare the tags with the pre-determined lists and the data will be automatically split over the multiple networks. In one embodiment, non-voice over IP traffic is not split using the multipathing subsystem. Therefore, its QoS tags will be set to a value different from five.
In addition, if the user is seamlessly roaming between the dissimilar networks, it may be worthwhile to specify that if the user is in range of a particular network, then only data with the appropriate QoS tag will flow over the appropriate network. If we take the previous example, it may be specified that any packets with a QoS tag of five should be constrained to Wireless LAN. Therefore, when the data is received at the router, the system will compare the tags with the rules and decide to route the priority five data over a specific network (i.e., Wireless LAN), while data without a QoS tag of five will be routed using any of the current networks.
Besides the alternate routing of data over networks as specified in this example, other decisions can be made based upon the QoS tags. Current examples include, “Ignore” (Drop any packets with the appropriate tag), “Alternate” (Route the packets with the appropriate tag over the secondary network, “Default” (Route the packets with the appropriate tag over the default network), “Multipath” (Route the packets simultaneously over multiple wireless networks via the Multipathing subsystem), “Multicast” (Route the packets to multiple clients via the Multicasting protocols), or “Broadcast” (Route the packets to all clients via transport network broadcast mechanisms). However, other types of actions can be incorporated in further embodiments of a network based QoS system. For example, a “Convert” rule could be added that would allow various aspects of the packet header or payload to be transformed prior to other routing mechanisms.
As shown in
If the mobile devices are mobile computers, then exemplary applications may include streaming media applications (video, voice, stock tickers, etc.), database applications, client-server applications, messaging or dispatch applications, web browser clients, file transfer applications, or email clients. If the mobile devices are not mobile computers, then exemplary applications may include firmware that provides video surveillance or still pictures via streaming media, reads sensors and sends readings, or receives data from a host application to control a device.
An alternative embodiment provides for the network based QoS system to operate transparently to either the host application or the mobile router by hooking into the IP stack of the mobile computer. In this scenario, the network based QoS system intercepts the packets prior to the mobile router, performs its processing modifying the packet as necessary (i.e., updating the QoS tag if the matching rule indicates that this should take place), and reintroduces the packet into the IP stack so that the mobile router may then intercept the packet and perform its services.
The network based QoS system can reside on the sender (e.g., mobile device) and the receiver (e.g., Host Network Server). Each network based QoS system will be responsible for processing outbound traffic. In this case, the Host Network Server is responsible for maintaining outbound communications to the mobile clients.
The network based QoS system requires a configuration interface to provide control to system administrators to alter the behavior of the network based QoS system. In an embodiment, this configuration interface is located on each system that includes the network based QoS system. An alternative embodiment specifies the configuration will be only entered on the Host Network Server, and the mobile clients will automatically learn the configuration options through the networks. This type of system has the advantage of reducing and centralizing the configuration required for the network based QoS system. In this example, the configuration screens for the mobile clients may only display an IP address that is used as a location to request the configuration of the system from.
A further refinement of the previous example would provide for the network based QoS system to share configuration settings with the mobile router. For example, the mobile router may already maintain an IP address from which to request its own configuration settings. This same IP address may be used by the network based QoS system. The system may use industry standard techniques like HTTP, FTP or TFTP or it may use proprietary techniques to download the configuration options from the centralized server. Regardless of what method is used to configure the system, the data is stored in persistent storage; exemplary types of storage include, but are not limited to hard disk drives, flash memory or relational databases. Alternatively, the configuration may only be stored on the Host Network Controller and not on the mobile computers thereby requiring that the network based QoS subsystem on the mobile computers acquire their configuration dynamically each time the system is started.
If the operating system on the machine provides a graphical user interface, the configuration can be performed using a graphical application residing on the host. As indicated previously, the configuration host may be either the Host Network Controller only, both the Host Network Controller and the mobile computer, or another host altogether. If the host on which the network based QoS system is installed or configured does not provide a graphical user interface, then some other means will be required to receive the configuration. One exemplary type is a configuration interface that receives configuration packets at a UDP port over the networks or accepts configuration via a download of a file. Another exemplary type is a command line interface (CLI).
Any time the user presses the Add button 611, the Add Network Based QoS Configuration screen 701 that is displayed in
When the user attempts to create a Network QoS Entry by selecting the radio button 702, an Add Network QoS Entry screen 801, as depicted in
If the user presses the OK button 811, the settings will be saved into persistent storage. If the user presses the Cancel button 812, then the screen 801 will clear and control is passed to the previous Network Based QoS Configuration window 601 without saving the configuration.
When the user attempts to create a Network QoS Rules Based Routing Entry by selecting the Radio button 703, the Add Network QoS Rules Based Routing Configuration screen 901 as depicted in
In addition to the above mentioned fields, the window also includes information regarding the selection of networks when the packet disposition is set to “Alternate”. The Selected Networks list 906 lists the appropriate networks that should be used. The All Available Networks list 907 shows all networks currently configured in the system. The user can press the “<<” button 909 to move networks from the All Available Networks list 907 to Selected Networks list 906 or press the “>>” button 910 to move the networks from the Selected Networks list 906 to the All Available Networks list 907. In addition, the user has the option of organizing the networks in the Selected Networks list box by pressing the up arrow button 908 and down arrow button 911. When the user selects multiple networks in the Selected Networks list 906, they will be listed in the priority that will be used. Therefore, if the first network is not available, then the second network will be chosen. Finally, if the user presses the OK button 912, the settings are saved. If the user presses the Cancel button 913, then the screen will clear and control is passed to the previous Network Based QoS Configuration window 601.
While this specification describes several items that can be used as criteria when matching data packets, the criteria can be expanded to include any type of criteria found within data packets. Other non-limiting examples of criteria include: packet size, fragmentation status, time to live, identification bytes, or payload contents. If the payload contents are used as criteria, regular expression matching or a similar mechanism could be used when evaluating the criteria. When matching such criteria against data that could reasonably contain binary data (such as a packet payload), the criteria will need to take this into account when it is displayed to the user for configuration purposes. One manner in which this could be taken into account would be to represent the criteria in a format such as hexadecimal. Even if the criteria were displayed to the user in such a manner, there would be no limitation on the actual storage format. This would allow the configured criteria to be stored in raw binary just as it would be used when evaluating the criteria at run-time. The system disclosed in this application can be extended to support these new criteria.
Process Flow
We will now describe an exemplary process flow of data through the network based QoS system.
Initialization
The first step to be performed upon startup of the network based QoS system is to determine the current configuration settings. As stated previously, this may be acquired dynamically from the Host Network Controller at run-time. Alternatively, it may be configured and read-in locally. The ability for a client network based QoS system to acquire its configuration dynamically, as described previously, may be via standard means (FTP, TFTP, etc) and therefore is not described in detail herein. Additionally, local storage and retrieval of the configuration may also be handled via standard means (File System, Registry, etc.) and therefore is also not described in detail herein. The initialization processing that is described in detail is that of populating the internal data structures from the configuration data however it may be acquired.
Upon startup, the network based QoS system will begin by initializing all internal data structures. There is at least a single map data structure responsible for tracking the rules created within the Network Based QoS Configuration screen 601. This structure will be initialized to be empty. After the initialization occurs, the network based QoS system will read the single configuration setting that indicates whether network based QoS processing is enabled. If it is not enabled, there is no need to continue and initialization processing terminates. If the network based QoS processing is enabled, the system will begin to read the configuration rules directly into the QoS Configuration Map 1001. An exemplary version of this data structure is depicted in
While there are many different container and data model options for storing the data,
The Rule Descriptions 1005 is a linked list that will store the individual details of the actual rule. Each entry in the linked list will have several fields:
In addition to inserting each record from persistent storage to the Map, the initialization routine will also keep track of the unique QoS values associated with any rules with the action field set to “QoS.” This counter ensures that the partner process is aware of the number of priority queues required for maintaining the priority of the data transmissions.
Once the QoS Configuration Map 1001 has been successfully populated, the network based QoS system sends the partner process a message through a standard Interprocess Communications (IPC) mechanism. This IPC message states that the network based QoS system is available.
In addition, to alerting the partner process that the network based QoS System is available, the message also alerts the process as to the number of unique outbound transmission queues that should be maintained for the QoS functionality. To effectively prioritize traffic, the system should ensure that all data with higher QoS values should be sent before data with lower QoS values. Therefore, for each QoS value, a priority transmission queue will be created. When outbound packets are to be sent, they will be placed into the appropriate outbound priority queue. Finally, the functions within the partner process responsible for sending the data will ensure that data from the highest priority queue will be sent before data from the lower priority queue(s). In an alternative embodiment, the partner process creates the maximum number of queues necessary at all times. Since the exemplary QoS processing described herein provides for only three bits of precedence values, the maximum number of priority queues is only eight. Behavior such as this may have an advantage in that it could reduce processing necessary to handle configuration changes requiring the addition or deletion of priority queues. It could also have the disadvantage of using extraneous system resources. The particular implementation would need to weigh these tradeoffs.
If any error occurred during the initialization, the partner process is notified via IPC the initialization was unsuccessful and the appropriate functionality provided by the network based QoS System will be unavailable.
Main Processing
Once the network based QoS system has been initialized, it is responsible primarily for rules processing. QoS tag propagation to the outer encapsulating packet is another task that must be performed. One embodiment provides for the partner process to perform this propagation on behalf of the network based QoS system. In this case, the network based QoS system merely indicates via IPC that this action is required. Another alternative embodiment provides for the partner process to pass all encapsulated packets back to the network based QoS system for a second pass of processing so that the network based QoS system could propagate the tags itself. A third alternative embodiment provides for the partner process to defer all calls to the network based QoS system until the packet gets encapsulated.
The preferred embodiment of having the partner process perform the propagation is further described below. The second approach has the advantage of reducing coupling, but has the disadvantage of increasing the amount of processing resources necessary to route each packet. The third approach has the advantage of minimizing coupling and limiting processing resources but reduces the flexibilities of the rules lookup to only allow actions that can be carried out after multi-network routing decisions are made. These multi-network routing decisions include those such as “Alternate” rules as described in U.S. patent application Ser. No. 10/374,070, to HOFSTAEDTER et al., filed on Feb. 27, 2003, the disclosure of which is expressly incorporated by reference herein in its entirety.
The network based QoS system will receive requests from the partner process. In one embodiment, these requests are in the form of an IPC message. In a simplistic example, the IPC message consist of at least a Type Field, Additional Information Field, Data Field and Data Length. These fields are described below:
All requests made of the network based QoS system by the partner process are requests for rules processing. As such, the data packet will be processed according to the rules associated with the packet. The network based QoS system begins by identifying both the source and destination IP address in the packet header. It will then look up both the source and destination IP address within the QoS Configuration Map 1001. If the entry is not found, then the network based QoS system will send an IPC message back to the partner process that contains a type field of “No Action Required.” Of course, other criteria could be designated by the rule, in which case other comparisons will occur.
The packet is first compared with all QoS entries. If the packet matches a QoS entry, in one embodiment the QoS system updates the packet's QoS tag to the designated value and then performs another lookup in the table to see if the updated packet matches criteria of non-QoS entries. If not, in one embodiment the packet is returned to the partner process with the updated QoS value and then queued by the partner process in accordance with its new QoS value. If the updated packet matches another entry in the table (i.e., a routing entry), the designated routing action is noted (e.g., default), and a response packet is generated that includes the action that should be taken with the packet.
The type field of the response packet includes the “Action Required” flag. In one embodiment, there are four types of actions:
Note that if the matching rule indicates that a “QoS” action should be taken but the packet already contains a QoS value equal to that described in the rule, this special case will translate into a “No Action Required” response. If the matching rule indicates that a “QoS” action should be taken but that the packet already contains a QoS value that is greater than that described in the rule, then a “No Action Required” response is generated. An alternative embodiment for this second condition allows for an additional configuration setting for QoS rules allowing the configured value to override (or downgrade) the QoS value to the lower value as specified in the rule.
Once the IPC packet has been created, it will then be sent back to the partner process. In addition to sending the packet back to the partner process, the application will also update the counter field within the QoS Configuration Map 1001. It increases the counter value by one to indicate that the rule has been applied to the current packet. If there are any other statistical fields within the QoS Configuration Map 1001, then these fields will be updated as well.
As with all statistical counters, the potential for numeric overflow is a possibility. The exemplary embodiment described herein may take this into account by either ensuring that the single counter field is large enough that there is reasonable assurance that such an overflow will not occur during normal extended operations or it must include a process to propagate its value to an external entity recording historical statistics and then reset itself during a period within which such an overflow is not realistically possible. The exemplary embodiment described herein makes use of the former approach by employing 64-bit counters. This approach provides for over eighteen quintillion packets to be routed before a numeric overflow occurs.
Once the packet is sent to the partner process, the partner process performs the functionality described in the “Response” packet. If the IPC message is an “Alternate” message, the partner process will identify each alternate network listed within the “Additional Data Field”. The partner process will then use this information to determine which network should be chosen for the packet, for example, based upon network availability. If the IPC message is a “Discard” message, the partner process will discard the packet. If the IPC is a “Default” message, the partner process will send the packet through the default network. Finally, if the message is a QoS message, in one embodiment the partner process will update the QoS field within the IP header of the data packet to match the appropriate value in the “Additional Data Field” entry. As noted above, in another embodiment the QoS system itself updates the QoS value and thus returns the updated packet and no data in the “Additional Data Field.”
In the preceding description, “Alternate” and “Default” route messages were passed to the partner process. The partner process then determined which network to use based upon the message. In another embodiment, the QoS system returns the actual network to be used rather than a “Default” or “Alternate” indicator. In this case, the partner process need not determine which network should be used for transmitting the packet.
A typical location for the QoS values is shown in
Regardless of what rule is processed, anytime the partner process determines that the network based QoS system is active, any network encapsulation performed by the partner process will also propagate the original QoS value to the outer header. An alternative embodiment allows for QoS tag propagation to occur independently of the enablement of the rest of the rules-processing capabilities of the network based QoS system. Such behavior allows tag propagation to the outer encapsulating packet to occur for applications that do properly provide native QoS tagging.
This specification describes the ability to set the QoS field or the precedence field within the IP header. While we are specifically using IP as an example, the same framework can be used to provide the QoS setting in any type of network protocol. In addition, when using the QoS propagation, the invention can be extended to provide any generic propagation or transposition algorithms. For example, instead of just copying the precedent header from the inside to the outside, higher functionality can be provided to transpose different bytes between the inside and outside headers. One method encapsulates data from one medium to other mediums (e.g., ATM versus IP).
Although the invention has been described with reference to several exemplary embodiments, it is understood that the words that have been used are words of description and illustration, rather than words of limitation. Changes may be made within the purview of the appended claims, as presently stated and as amended, without departing from the scope and spirit of the invention in its aspects. Although the invention has been described with reference to particular means, materials and embodiments, the invention is not intended to be limited to the particulars disclosed; rather, the invention extends to all functionally equivalent structures, methods, and uses such as are within the scope of the appended claims.
In accordance with various embodiments of the present invention, the methods described herein are intended for operation as software programs running on a computer processor. Dedicated hardware implementations including, but not limited to, application specific integrated circuits, programmable logic arrays and other hardware devices can likewise be constructed to implement the methods described herein. Furthermore, alternative software implementations including, but not limited to, distributed processing or component/object distributed processing, parallel processing, or virtual machine processing can also be constructed to implement the methods described herein.
It should also be noted that the software implementations of the present invention as described herein are optionally stored on a tangible storage medium, such as: a magnetic medium like a disk or tape; a magneto-optical or optical medium like a disk; or a solid state medium such as a memory card or other package that houses one or more read-only (non-volatile) memories, random access memories, or other re-writable (volatile) memories. A digital file attachment to email or other self-contained information archive or set of archives is considered a distribution medium equivalent to a tangible storage medium. Accordingly, the invention is considered to include a tangible storage medium or distribution medium, as listed herein and including art-recognized equivalents and successor media, in which the software implementations herein are stored.
Although the present specification describes components and functions implemented in the embodiments with reference to particular standards and protocols, the invention is not limited to such standards and protocols. Each of the standards for communications (e.g., IPC, FTP, TFTP, HTTP, DCOM, CORBA), Internet and other packet switched network transmission (e.g., IP version 4, IP version 6, UDP/IP, TCP/IP, ICMP), and wireless networking (802.11a, 802.11b, 802.11g, CDMA 1xRTT, CDMA 1xEVDO, GSM, CDPD, GPRS, EDGE, UMTS, RD-LAP, SMR, LMR) represent examples of the state of the art. Such standards are periodically superseded by faster or more efficient equivalents having essentially the same functions. Accordingly, replacement standards and protocols having the same functions are considered equivalents.
This application claims the benefit of U.S. Provisional Application No. 60/640,046, filed on Dec. 30, 2004, the disclosure of which is expressly incorporated by reference herein in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 60640046 | Dec 2004 | US |
