Modern packet-switched networks accommodate a greater number of users and larger amount of traffic than ever before. Unfortunately, the services desired by users now require a much greater bandwidth, while demanding near real-time service in many cases. Consider, for example, a typical user's experience with a mobile phone. While, several years ago, many users were content with voice-only service, many mobile phones now double as personal computers, providing access to streaming video, peer-to-peer applications, and other high bandwidth applications. Furthermore, non-mobile networks have also experienced a significant increase in traffic, as Voice Over Internet Protocol (VoIP), IP Television (IPTV), and similar services have gradually increased in popularity.
Service providers have struggled to keep pace with the ever-increasing bandwidth requirements. Given the significant expenses associated with adding additional equipment, service providers are reluctant to address this problem by simply increasing the capacity of the network. Instead, many service providers desire to decrease costs and simultaneously improve the user's quality of experience by optimizing the efficiency of data transfer over the network.
One such optimization relates to compression of headers associated with packets transferred over the network. In bandwidth-sensitive portions of the network, many service providers employ a header compression algorithm to decrease the amount of data sent over the network. As an example, this header compression may be implemented according to Request for Comments 2507, “IP Header Compression,” published by the Internet Engineering Task Force (IETF) and incorporated herein by reference. More specifically, during an initialization phase, a node known as a compressor sends a full header including a context identifier (“CID”), which identifies the flow associated with the packet. A node known as a decompressor receives the full header and stores the associated CID. Subsequently, the compressor may send a “compressed” version of the header, which includes the CID, but omits much of the information included in the uncompressed header. This omitted information is stored as the “context” for the flow. Because the decompressor maintains a record of the CID and associated context, the decompressor may reconstruct the uncompressed header using the information contained in the compressed version.
Periodically, the header associated with a flow might change. For example, the value of the Time to Live (TTL) field in the IP header might change from 128 to 64. In order for the packets to be properly decompressed, the decompressor must know that the context has changed. To accomplish this, the compressor first increments a generation value associated with the CID of the flow and stores the new context. The compressor will then enter slow-start mode for the flow. Slow-start mode is a pattern of full header and compressed header packets, characterized by an exponentially increasing number of compressed header packets being sent between full header packets. For example, a compressor in slow start mode may send one full header, one compressed header, one full header, two compressed headers, one full header, four compressed headers, and so on. This ensures that the decompressor receives at least one full header so it may recognize the generation change and update the context stored for the CID accordingly.
While, in theory, this solution is capable of dramatically decreasing the bandwidth needed for most types of traffic and thus enabling faster communications, the process of compressing headers and ensuring that the decompressor is aware of each new context is, in practice, quite resource-intensive. Because a traffic management node implementing IPHC must expend extra processing power on each packet, a lesser number of packets may be processed in a given time period than if IPHC were not implemented at all. As an example, current solutions implementing IPHC might decrease the throughput of a traffic management node down to 60% of its full capacity. Full throughput could, in theory, be maintained by utilizing components capable of operating at faster speeds, but this approach would be quite expensive and would require additional real estate within the node. Accordingly, there is a need for a system capable of providing IPHC functionality while retaining near 100% throughput, without necessitating more expensive, bulkier components.
The foregoing objects and advantages of the invention are illustrative of those that can be achieved by the various exemplary embodiments and are not intended to be exhaustive or limiting of the possible advantages that can be realized. Thus, these and other objects and advantages of the various exemplary embodiments will be apparent from the description herein or can be learned from practicing the various exemplary embodiments, both as embodied herein or as modified in view of any variation that may be apparent to those skilled in the art. Accordingly, the present invention resides in the novel methods, arrangements, combinations, and improvements herein shown and described in various exemplary embodiments.