Patent Grant
7978699
The present invention relates to data compression and decompression where two or more protocol layers are required for transmission of packets between communication nodes in a computer network.
Computer networks support data communications using layered protocols. The commonly used TCP/IP protocols typically have layers of protocols for link, network, transport and application protocol. Efficiency of network communications is of particular concern for wireless or other limited bandwidth networks. Data units used by each of the many layers of protocols in a data communication system are required to carry a protocol header comprised of information used for the data communication system. In the prior art, protocol headers in one layer have contained redundant information as compared with protocol headers in another layer. Due to current protocol specifications for protocol headers among the protocol layers, protocol header information has become to be major percentage of the data communication traffic. The actual data carried in the protocol and data units of a communication layer can often be small in comparison with information contained in the protocol header. While reducing the information contained in the protocol header is a conceptually simple solution to this transmission inefficiency, specifications of each protocol provide for a fixed amount of information in the protocol header and cannot be changed without substantial time and cooperation of the standards authorities. The substantial effect of protocol header traffic is particularly apparent for Internet Protocol-based telephony. Voice communications on IP networks are typically carried out under an RTP protocol. A standards organization for the 3GPP protocol has authoritatively defined data packet structure for data transmission of voice traffic (IP Multimedia Subsystems—IMS) so that the voice data can occupy just 12 bytes of a 112 byte IP packet payload. The following is an example of a protocol header for the IPsec protocol packets, identifying other well known packet fields for this packet:
An obvious inefficiency of transmitting a payload that is small compared to the total IP packet size has led to the development of only a few protocol compression solutions.
A header compression method has been established under IETF standards RFC 1108 or RFC 2508, but these are not suitable for networks that carry voice communications. Another such standard, RFC 1108 is directed to the complexities of TCP traffic and does not provide support for low latency communications. The techniques described in yet another standard, RFC 2508, provide for compression by calculating differences between successive packets. If a packet is lost, the compression algorithms must retransmit and reset the state of the compression. This causes unacceptable latencies and data voice corruption. The Robust Header Compression (ROHC—RFC 3095) specification (described in U.S. Pat. No. 6,608,841) also use a header difference mechanism. Yet another standard, RFC 3095, provides improvements in environments with packet loss, but still uses a difference based dynamic compression.
Existing header compression solutions do not support encryption. Encryption of communications with a protocol like the IETF defined Encapsulating Security Protocol (RFC 2406) encrypts all of the contained headers making them uncompressible, and thereby unavailable for use until decrypted. Compression applied to the protocols within the ESP packet would result in a minor benefit to packet size but would still result in protocol and data unit redundancy among the layers' protocol headers and the potential for compression in the ESP protocol.
Some prior art protocol compression techniques require that only the information that is different on each packet is identified. These differences can vary from packet to packet and require the use of difference fields that are type/length/value delimited. These differences are often predictable and this predictability is not considered in the existing designs making them considerably more complex than is necessary. Specifically, a preferred traffic method for voice communications has a simple profile. Complex techniques for more stateful protocols that support retransmission are not required and more simple template based mechanism can be used. More efficient implementations are possible when the protocols used for carrying data can be constrained to profiles that do not support retransmission or fragmentation. In this case, and sequences numbers carried in the protocol layers will always be synchronized. As a lower layer protocols sequence number increases, the higher level protocols sequence number will be incremented identically. In this manner, given an appropriate template for the header compression that describes which fields need to be left out, the sequence numbers can be directly reconstructed.
These templates can be even more efficient if they use knowledge from lower uncompressed layers (like ESP). The ESP protocol provides sequence numbers, data confidentiality (encryption) and data integrity (cryptographic checksum). The ESP sequence number can be used to directly determine the sequence number of a upper layer protocol that is uniquely bound to the ESP protocols security association. The services provided by ESP data integrity can be used to completely replace any checksum carried internal to the ESP packet. Specifically UDP checksums are not required. There is no need to carry this field.
Current specifications for 3GPP and IETF are easily obtained.
3GPP Specifications may be obtained at http://www.3gpp.org/specs/numbering.htm. The following are a selection of those specifications:
IETF Specifications are also well known in the art. The following a current list thereof:
There is a need for a system of communication via packet networks where protocol processing, compression and encryption is made more efficient by adaptation of coordination of sequence numbers between layer protocols and the integration of encryption protocol processing into the compression and decompression process.
The present invention is a method and system for a more efficient transmission of data packets over a packet network operating under multiple protocol layers, where two or more adjacent protocol layers require that each protocol and data unit comprise a protocol header containing information usable by the protocol. Protocol layers are defined as being above another protocol layer if the higher protocol layer requires fewer steps to reach or identical with an application layer. The system of the present invention provides for compression and decompression of data packet protocols in order to reduce the total IP packet size. This sizes reduction can be accomplished by the removal of certain protocol fields and their replacement with invention means without loss of the functions intended for performance of the protocol for the changed packet.
In a preferred embodiment, a compression/decompression template is created for certain fields in protocol headers of two or more protocol layers based upon a relating sequence numbers of at least one higher level protocol field to a sequence number of a lower level protocol field, where the higher level protocol field is nested in a lower level protocol for an efficient transmission between the sending and receiving nodes. The predictable relationship of a sequence number of one protocol layer to a sequence number of another protocol layer handling the same data load is referred to herein as synchronization. Predictability means causing sequence numbers of such data-load related process data units and to be identical or to be related to each other by a predetermined algorithm whereby, at any time, a sequence number of a protocol data unit of one layer can be used to exactly determine a sequence number of a protocol data unit of another layer. Sequence numbers in the available protocols are predictable, providing a basis for synchronization algorithms for relating sequence numbers from protocol data units of different communication system layers.
In one embodiment, the invention method and system acts to remove one or more protocol fields from protocol headers formed by operation of a layer's protocol. The device performing the protocol field removal is a sending node or device (such as a cellular, VoIP or similarly equipped telephone or from a device where an IP network forms a link in a data communications path from a sending node to a receiving node).
Removal of a protocol field which would have resided in a nested protocol header reduces the total IP packet size for transmission by a sending node. With reference to the above example of a voice data packet, it will be appreciated that removing one or more nested sequence number fields from the packet will significantly reduce the total IP packet size.
At a receiving node or unit, a microprocessor with a control program acts to receive the invention data packet having one or more nested protocol fields removed for transmission. The receiving node or unit, having stored information and functions in the microprocessor for acting upon the invention data packet, uses a predefined template and predefined expansion functions so that the protocol fields removed by the sending node's microprocessor and control program are replaced at the receiving node for full utilization of the functions of each layer of protocols for receipt of the invention packets. The receiving node comprises means for, from comparison of a received invention packet to a field replacement template, predicting and replacing removed, synchronized sequence numbers.
By imposing synchronization of sequence number fields that remain the same or predictably change to be synchronized in different protocol layers, the process of protocol processing and compression can be greatly simplified, thereby enhancing transmission speed and reducing bandwidth use. This synchronization is viable for layered protocols that support comparable retransmission mechanisms and comparable fragmentation mechanisms.
The various protocol header fields of data communications protocols are well known. Sequence number fields in the header fields and methods for providing an initiating sequence number are also well known. Sequence numbers in a sequence number field are generally increased by a single unit for each successive protocol data unit. In many protocols, sequence numbers are chosen at random to minimize the risk of system mis-use or hacking. In the invention system, a reference sequence number can be chosen at random, or by a predetermined mechanism, whereafter sequence numbers for header fields of other protocols are predictably related or synchronized to the reference sequence number.
The following is a specific example of synchronization for a protocol stack for Internet Protocol Multimedia Subsystem. The Internet Protocol Multimedia Subsystem (IMS) is described above. Network and transport layer protocols, respectively, Internet protocol (IP) and real-time transport protocol (RTP), use sequence numbers independently generated by their respective protocols. Both IP and RTP use sequence numbers that track lost data by identifying sequence numbers of protocol data units (PDU's) that have not been received at a receiver's node. The sequence numbers of PDU's identified as lost or not received under IP and TCP of a receiver's node do not directly cause a sender's node to re-transmit lost or missing PDU's.
An exemplary protocol stack is as follows for this example: IP, UDP, ESP, IDP, UDP and RTP. The protocols themselves are modified to provide for synchronization of sequence numbers which occur in some PDU's of the communication protocols. Processing at the sender's node of these modified network and transport layer protocols results in a sequence number of a lowest layer protocol from which the sequence number of any higher layer can be predicted and/or calculated.
In a particularly and surprisingly beneficial application of synchronization of sequence numbers of these protocols, sequence number and Security Parameters Index (SPI, as a session identifier) fields of an Encapsulating Security Payload (ESP of the IP Security suite of network protocols) are used to effectively predict or establish by calculation sequence numbers of the encrypted IP, UDP, and RTP PDU's within the ESP PDU. It will be apparent from this disclosure that lower layer ESP session identifiers and sequence numbers can be modified so that sequence numbers of higher layer protocols other than those shown in the specific example above may be encapsulated, compressed or encrypted in the payload are predicted or calculable from information in the ESP session identifiers and sequence numbers. In short, IPsec-UDP-RTP protocols can be compressed (and whose sequence numbers are thereby made unavailable without decompression—re-compression steps) without loss of access to those inner sequence numbers by using knowledge that a particular IPsec Security Association directly implies a UDP format and specific RTP header within the payload. The sequence number in the RTP header encapsulated thereby can be predicted and/or calculated after compression by using a known starting sequence number of the RTP sequence numbers and incrementing the recreated counter by the same amount as the necessarily increased IPsec sequence number.
Another surprising benefit of the synchronization and linkage of security processing to the upper layer protocol processing is the ability to completely remove changing but redundant fields. As a specific example using the previous example of IMS protocols stacks, the inner UDP checksum does not need to be transmitted and can be removed even though it is different for every packet. The services provided by the synchronized protocol layers can be treated as a whole. In the IMS protocol stack, the ESP protocol provides a integrity check. The integrity of the UDP packet is not required since the ESP integrity check fully covers the inner protocols.
One object of the invention is to provide for synchronization, duplication, relation and/or algorithm-based prediction among sequence numbers generated for PDU's of two or more communications protocols, thereby enabling compression of higher layer PDU's and implicit determination of higher layer protocol sequence numbers.
Another object of the invention is to provide adapted field generation of ESP headers to contain sufficient information from which option fields of compressed or encrypted payload PDU's can be determined.
Yet another object of the invention is to provide an ESP sequence number to map (by prediction or calculation) to an RTP sequence number compressed or encrypted in the payload, whereby RTP frame formats are determined solely by reference to the ESP sequence number.
Further objects of the invention are as follows:
The identification of first and second communications protocols do not limit the total number of successively processing communications protocols which may act upon readying a data load for transmission at the sending node. Neither do the first and second communications protocols be immediately successive in such processing, such that the first communications protocol may be, for example, a first, second or third communications protocol acting on said data load and the second communications protocol may be the second or higher communications protocol acting upon said data load.
At a first, lowest layer processing, the ESP packet is received an then further processed to provide an ESP SPI, from which the control program of the receive (recipient) node acts to detect that nested protocol fields have been removed, act upon values in the ESP SPI for comparison values or algorithms in an SPI based look up table which are further acted upon to determine values of the removed nested protocol fields, and thereafter process said received packet to restore to the nested removed protocol fields their original values prior to decoding for playout of the received packet.
The above design options will sometimes present the skilled designer with considerable and wide ranges from which to choose appropriate apparatus and method modifications for the above examples. However, the objects of the present invention will still be obtained by that skilled designer applying such design options in an appropriate manner.
The present application claims benefit of Provisional Application No. 60/860,625 filed Nov. 21, 2006, the contents of which are incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5738583 | Comas et al. | Apr 1998 | A |
| 6272120 | Alexander | Aug 2001 | B1 |
| 6600726 | Nevo et al. | Jul 2003 | B1 |
| 6690935 | Calot et al. | Feb 2004 | B1 |
| 6704866 | Benayoun et al. | Mar 2004 | B1 |
| 6707801 | Hsu | Mar 2004 | B2 |
| 6760587 | Holtzman et al. | Jul 2004 | B2 |
| 6785892 | Miller | Aug 2004 | B1 |
| 6788675 | Yang | Sep 2004 | B1 |
| 6793580 | Sinclair et al. | Sep 2004 | B2 |
| 6795701 | Baker et al. | Sep 2004 | B1 |
| 6799056 | Curley et al. | Sep 2004 | B2 |
| 6859460 | Chen | Feb 2005 | B1 |
| 6879574 | Naghian et al. | Apr 2005 | B2 |
| 6879812 | Agrawal et al. | Apr 2005 | B2 |
| 6909705 | Lee et al. | Jun 2005 | B1 |
| 6932698 | Sprogis | Aug 2005 | B2 |
| 7013391 | Herle et al. | Mar 2006 | B2 |
| 7072323 | Roberts et al. | Jul 2006 | B2 |
| 7073129 | Robarts et al. | Jul 2006 | B1 |
| 7085257 | Karves et al. | Aug 2006 | B1 |
| 7097562 | Gagner | Aug 2006 | B2 |
| 7143171 | Eriksson et al. | Nov 2006 | B2 |
| 7181544 | Vangal et al. | Feb 2007 | B2 |
| 7224964 | Souissi et al. | May 2007 | B2 |
| 7236772 | Botzas | Jun 2007 | B1 |
| 7251235 | Wentink | Jul 2007 | B2 |
| 7308263 | Gallagher et al. | Dec 2007 | B2 |
| 7324444 | Liang et al. | Jan 2008 | B1 |
| 7400722 | Qi et al. | Jul 2008 | B2 |
| 7440430 | Jagadeesan et al. | Oct 2008 | B1 |
| 7452278 | Chen et al. | Nov 2008 | B2 |
| 20020151366 | Walker et al. | Oct 2002 | A1 |
| 20020191560 | Chen et al. | Dec 2002 | A1 |
| 20020199124 | Adkisson | Dec 2002 | A1 |
| 20030069018 | Matta et al. | Apr 2003 | A1 |
| 20030182454 | Huth et al. | Sep 2003 | A1 |
| 20030231625 | Calvignac et al. | Dec 2003 | A1 |
| 20040066751 | Tseng et al. | Apr 2004 | A1 |
| 20040105415 | Fujiwara et al. | Jun 2004 | A1 |
| 20040127277 | Walker et al. | Jul 2004 | A1 |
| 20040174829 | Ayyagari | Sep 2004 | A1 |
| 20040185851 | Nagai | Sep 2004 | A1 |
| 20040196808 | Chaskar et al. | Oct 2004 | A1 |
| 20050025163 | Christie | Feb 2005 | A1 |
| 20050032577 | Blackburn et al. | Feb 2005 | A1 |
| 20050041660 | Pennec et al. | Feb 2005 | A1 |
| 20050041793 | Fulton et al. | Feb 2005 | A1 |
| 20050073980 | Thomson et al. | Apr 2005 | A1 |
| 20050079873 | Caspi et al. | Apr 2005 | A1 |
| 20050099977 | Williams et al. | May 2005 | A1 |
| 20050157661 | Cho | Jul 2005 | A1 |
| 20050177639 | Reunamaki et al. | Aug 2005 | A1 |
| 20050181872 | Acharya et al. | Aug 2005 | A1 |
| 20050197189 | Schultz | Sep 2005 | A1 |
| 20050250487 | Miwa et al. | Nov 2005 | A1 |
| 20050250497 | Ghosh et al. | Nov 2005 | A1 |
| 20050268003 | Wang et al. | Dec 2005 | A1 |
| 20050286456 | McNew et al. | Dec 2005 | A1 |
| 20060041750 | Carter et al. | Feb 2006 | A1 |
| 20060045138 | Black et al. | Mar 2006 | A1 |
| 20060063539 | Beyer | Mar 2006 | A1 |
| 20060135262 | Kennedy et al. | Jun 2006 | A1 |
| 20060172736 | Nevo | Aug 2006 | A1 |
| 20060205409 | Chiou et al. | Sep 2006 | A1 |
| 20060221857 | Bushnell et al. | Oct 2006 | A1 |
| 20060268711 | Doradla et al. | Nov 2006 | A1 |
| 20070026866 | Krishnamurthi et al. | Feb 2007 | A1 |
| 20070035513 | Sherrard et al. | Feb 2007 | A1 |
| 20070047547 | Conner et al. | Mar 2007 | A1 |
| 20070047697 | Drewry et al. | Mar 2007 | A1 |
| 20070060355 | Amaitis et al. | Mar 2007 | A1 |
| 20070060358 | Amaitis et al. | Mar 2007 | A1 |
| 20070076683 | Chung | Apr 2007 | A1 |
| 20070082671 | Feng et al. | Apr 2007 | A1 |
| 20070086394 | Yamada et al. | Apr 2007 | A1 |
| 20070099703 | Terebilo | May 2007 | A1 |
| 20070197237 | Powell et al. | Aug 2007 | A1 |
| 20070202910 | Brewer et al. | Aug 2007 | A1 |
| 20080039015 | Nakata et al. | Feb 2008 | A1 |
| 20080069105 | Costa et al. | Mar 2008 | A1 |
| 20080095112 | Wiemann et al. | Apr 2008 | A1 |
| 20080123608 | Edge et al. | May 2008 | A1 |
| 20090191878 | Hedqvist et al. | Jul 2009 | A1 |
| 20090222358 | Bednarek | Sep 2009 | A1 |
| 20100093374 | Dacosta et al. | Apr 2010 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 60860625 | Nov 2006 | US |
