ROHC Ishita Majumdar John O'Hare Andrew Allen Steve Magee Colleen Cheung Gerry Foster Nigel Ziyad Internet Draft Motorola Inc. Document: draft-ziyad-rohc-tccb-00.txt July 2001 Category: Draft Text-based Compression Using Cache and Blank Approach (TCCB) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines an efficient, robust, and scalable scheme for the compression of text-based protocols. Such protocols (e.g. SIP, SDP) when sent uncompressed over limited bandwidth networks (such as Cellular or the upstream of Hybrid Fiber Coax (HFC)) causes inadvertent delays in call set up. TCCB addresses these problems and proposes a simple mechanism to reduce the size of the messages and hence the recurrent delay. Contents 1. Introduction 2 2. Basic Framework of TCCB 2 2.1 Assumptions 3 2.2 TCCB Functions 3 2.3 Algorithm 4 3. Examples 5 4. Requirements 20 5. Evaluation 22 6. Conclusion 23 7. Intellectual Property Rights Consideration 23 8. References 23 9. AuthorÆs Addresses 23 Majumdar et. al. Draft [1] Text-based Compression Using Cache and Blank Approach July 2001 1.0 Introduction Telephony service today is provided for the most part over circuit switched networks. The new trend that is fast emerging is to provide telephony service over IP networks known as IP telephony. The motivating factors for carrying voice traffic over data networks are the integration of voice and data applications, which can result in more effective business process, cost savings for voice calls, enabling of many new services for business and customers. The flexibility offered by IP telephony by moving the intelligence from the network to the end stations enables many new services, which did not exist before. In order to merge Internet and cellular telephony, two aspects had to be focused on, the end-to-end call set up delay and the voice quality. Protocols such as SIP and SDP will be typically used to set up and tear down calls. However, the problem of adopting ASCII based protocol in access networks of limited bandwidth, incurs a huge delay for call set up. Large text messages being passed over the air interface also result in a very inefficient use of the transmission medium. In addition, some legacy based enhanced TDM cellular transceivers such as GERAN (GSM EDGE Radio Access Network) will need to "steal" audio bandwidth for the transmission of intercall SIP signaling messages resulting in long audio mutes. Compression of such messages is therefore required in order to increase spectrum efficiency, reduce transmission delay and to provide a comparable level of quality of service compared with circuit switched systems. Section 2 provides a high-level overview of the techniques. Section 3 provides a more detailed explanation of the techniques introduced in section 2. Section 4 explains the TCCB's adherence to draft requirements for signaling compression. Section 5 contains a table of message sizes from the examples in section 3 followed by a conclusion statement in section 6. 2.0 Basic Framework of TCCB TCCB is designed to be extensible. It can work over various access technologies and the principle applies to all text based protocols. The added advantage of this method is that only the User Agents and the Peer Core Network Entity (e.g. Proxy CSCF) need be involved in the storage and retrieval of information to compress or decompress the text based messages. The purpose of the TCCB layer is to remove all redundant header information and redundant payload information wherever applicable. It caches this information in the local memory for future decompression purposes. Majumdar et. al. Category - Draft [2] Text-based Compression Using Cache and Blank Approach July 2001 TCCB is contained within a new layer that sits between the text-based- protocol layer and the lower transport layers (e.g. UDP or TCP). This additional layer would be added to the stacks of both entities that wish to communicate using compression (e.g. in the UE and the P-CSCF in the case of 3GPP Rel5 IP Multimedia architecture). 2.1. Assumptions When applied to SIP messages, the algorithm at a compressor endpoint (e.g. Proxy CSCF) takes as input a SIP message to be compressed, and produces as output a compressed SIP message. The compressor further caches the original message in the caching table indexed by a unique identifier. The decompressor (e.g. the UE) takes a compressed message and pre-cached messages as input and produces as output a decompressed message based on the same unique identifier. Both the original and decompressed messages are identical. 2.2 TCCB Functions The purpose of the TCCB layer is to remove all redundant header information. Redundant header information is identified as header contents, which the sending node "knows" is already stored in the cache of the receiving node. An example in the SIP case is where a header fieldÆs contents have not changed since the last message for a particular session. +---------------+ +---------------+ | APPLICATION | | APPLICATION | | LAYER | | LAYER | | (Text based | | (Text based | | Protocol) | | Protocol) | +---------------+ +---------------+ | TCCB | | TCCB | | | | | +---------------+ +---------------+ | UDP/TCP | | UDP/TCP | +---------------+ +---------------+ | IP | | IP | +---------------+ +---------------+ | Physical | +----------+ | Physical | | |<- - > | Physical | < - -> | | +---------------+ | Channel | +---------------+ +----------+ Figure 1-TCCB Architecture If the TCCB layer sees that a header field is the same as previously sent or received for a particular sequence, it simply blanks the header contents. Majumdar et. al. Category - Draft [3] Text-based Compression Using Cache and Blank Approach July 2001 If the TCCB layer receives a message (or method in SIP) with a "blank" header field, it reconstructs the header from its cache for that particular sequence. 2.3 Algorithm: The following is the basic algorithm of TCCB. For all messages, (a) determine message characteristics (b) extract index information from certain fields within the message. For outbound messages, perform the compressor function on each message element within message (c) using index information from (b), extract entry from cache. IF message element matches element stored in cache then Blank message element contents in message ELSE Update cache with latest element information (d) Forward processed message to UDP layer for sending. For inbound messages, perform the decompressor function on each message element within message (e) If message element has been blanked THEN using index information from (b), extract entry from cache to reconstruct message element ELSE Ensure entry (using index information from (b)) in cache is up-to-date with received contents (f) Forward inbound reconstructed message up to the application layer Notes: 1) All TCCB layers contain compressor and decompressor functionality. 2) The algorithm requires that TCCB be aware of the text-based-protocol that it is compressing. For example, when applied to SIP, TCCB needs to have the ability to determine the type of message (method) received. 3) Multiple Levels of Indexing: The algorithm uses certain fields from the message to act as an index for accessing information in the cache. A useful technique is to use multiple levels of indexing e.g. in the case of cellular telephony message elements are stored based on a combination of one or more of caller, called and session leg identifiers to capture the concept of From: To: and Cseq:. The indexes are combined such that finer granularity is only used when required i.e. if there is a conflict between the received message and the information stored in the cache. 4) It is NOT necessary to send mandatory message element names. The idea here is that it is not necessary to send mandatory message elements, when the contents of that particular message is to be blanked. The receiving TCCB (decompressor) would search for missing mandatory message elements, and reconstruct these based on information from its cache. Note: Only non- indexed headers can be omitted. Majumdar et. al. Category - Draft [4] Text-based Compression Using Cache and Blank Approach July 2001 5) Error Checking and Error Handling: In the current algorithm as described above, this aspect is not addressed. This is an area for further study. 6) Bitwise tags may be used rather than the text format for message element, e.g. when applied to SIP, the TCCB layer in both nodes may be initialized with the following mappings: Via: 0x000158 From: 0x000258 To: 0x000358 Call-ID: 0x000458 Cseq: 0x000558 Content-length: 0x000658 When sending the compressed message "Via:" would be replaced with 0x000158 etc. Alternatively, Huffman encoding could be used for the tag format in order that the bitwise tags can be shorter. For the most common headers, this might be the ASCII code for the Compact form of the common headers (per RFC2543bis) with an additional byte for the others. The tags are not considered a required part of TCCB. 7) Memory Leaks: In order to avoid memory leaks either at the TCCB in the Client or Server a mechanism is required to free-up memory. A certain amount of memory will be updated by overwriting existing contents. However, certain information such as that specific to a particular call- leg may need to be deleted when TCCB recognizing messages which indicate the tear down of that particular-leg. Timer based clean-up may also be required to ensure that hashing delays are kept to a minimum. 3.0 Examples: In order to understand the algorithm, a simple set of examples based on registrations and the first couple of messages of a session establishment are given. The following abbreviations are used throughout the examples: C: Client S: Server CT: Client TCCB CTC: Client TCCB Cache ST: Server TCCB STC: Server TCCB Cache The following is an overview of the examples: Example 1: First Registration after power up Example 2: A Re-registration Example 3: First few messages in a session establishment Example 4: New INVITE for a Secondary session Example 1: First Registration Step 1.1: REGISTER C->CT Majumdar et. al. Category - Draft [5] Text-based Compression Using Cache and Blank Approach July 2001 A REGISTER request is sent from the Client (UAC), to the TCCB layer of the Client (CT) REGISTER sip:bell-tel.com SIP/2.0 Via: SIP/2.0/UDP saturn.bell-tel.com From: ;tag=19al To: sip:watson@bell-tel.com Call-ID: 70710@saturn.bell-tel.com CSeq: 1 REGISTER Contact: Expires: 7200 Step 1.2: REGISTER CT->ST The SIP aware TCCB checks to see which type of method it received. Upon determining itÆs a REGISTER, it uses the "To:" header contents to check the cache. Each header is processed individually and the cache (CTC) checked for a match. If no match found, the cache is updated with the latest information. If a match is found, that particular header contents are blanked. CTC: The following are the set of tables stored in the UA after TCCB processing Table: Request Line Index Contents ----- -------- sip:watson@bell-tel.com sip:bell-tel.com SIP/2.0 Table: Via Index Contents ----- -------- sip:watson@bell-tel.com SIP/2.0/UDP saturn.bell-tel.com Table: From Index Contents ----- -------- sip:watson@bell-tel.com ;tag=19al Table: Call-ID Index Contents ----- -------- sip:watson@bell-tel.com 70710@saturn.bell-tel.com Table: Cseq Index Contents ----- -------- sip:watson@bell-tel.com 1 REGISTER Table: Contact Index Contents ----- -------- sip:watson@bell-tel.com Table: Expires Index Contents Majumdar et. al. Category - Draft [6] Text-based Compression Using Cache and Blank Approach July 2001 ----- -------- sip:watson@bell-tel.com 7200 In this particular example, this was the first method after power-up so no compression was possible on the message. Note: In the current application of TCCB we do not obtain the compression of the first messages. With a dictionary approach, synchronizing messages over the air would add to the delay; however, it would compress the messages by a higher percentage. TCCB thus could be used as-is for certain scenarios and with other methods to enhance compression. REGISTER sip:bell-tel.com SIP/2.0 Via: SIP/2.0/UDP saturn.bell-tel.com From: ;tag=19al To: sip:watson@bell-tel.com Call-ID: 70710@saturn.bell-tel.com CSeq: 1 REGISTER Contact: Expires: 7200 Step 1.3: REGISTER ST->S The SIP aware TCCB checks to see which type of method it received. Upon determining itÆs a REGISTER, it uses the "To:" header contents to check the cache. Each header is processed individually and the cache (CTS) checked for a match. If a received header is "blanked", the contents are retrieved from the cache, else the cache is updated with the latest contents. CTS: The following are the extract of tables stored in the Server after TCCB processing for this particular registration Table: Request Line Index Contents ----- -------- sip:watson@bell-tel.com sip:bell-tel.com SIP/2.0 Table: Via Index Contents ----- -------- sip:watson@bell-tel.com SIP/2.0/UDP saturn.bell-tel.com Table: From Index Contents ----- -------- sip:watson@bell-tel.com ;tag=19al Table: Call-ID Index Contents ----- -------- sip:watson@bell-tel.com 70710@saturn.bell-tel.com Table: Cseq Index Contents ----- -------- sip:watson@bell-tel.com 1 REGISTER Majumdar et. al. Category - Draft [7] Text-based Compression Using Cache and Blank Approach July 2001 Table: Contact Index Contents ----- -------- sip:watson@bell-tel.com Table: Expires Index Contents ----- -------- sip:watson@bell-tel.com 7200 In this particular example, after populating the cache the method is forwarded up the stack to the Server SIP application. REGISTER sip:bell-tel.com SIP/2.0 Via: SIP/2.0/UDP saturn.bell-tel.com From: ;tag=19al To: sip:watson@bell-tel.com Call-ID: 70710@saturn.bell-tel.com CSeq: 1 REGISTER Contact: Expires: 7200 Step 1.4: 200 OK S->ST SIP/2.0 200 OK Via: SIP/2.0/UDP saturn.bell-tel.com From: ;tag=19al To: sip:watson@bell-tel.com Call-ID: 70710@saturn.bell-tel.com CSeq: 1 REGISTER Contact: Step 1.5: 200 OK ST->CT TCCB in the Server first determines that the method is a 200 OK and then reads to the "To:" header contents and uses it as an index to the cache tables. Each header is processed in turn using the same set of rules as in Step 1.2. In this particular instance the cache will remain unchanged from Step 1.3. After Cache processing each header, the initial compressed 200 OK will look as follows: SIP/2.0 200 OK Via: From: To: sip:watson@bell-tel.com Call-ID: CSeq: Contact: Now elimination of mandatory headers that have their contents cached takes place. Majumdar et. al. Category - Draft [8] Text-based Compression Using Cache and Blank Approach July 2001 The following headers are mandatory for 200 OK; Via, From, To, Call-ID, Cseq. After mandatory header elimination the final compressed 200 OK will look as follows: SIP/2.0 200 OK To: sip:watson@bell-tel.com Contact: Step 1.6: 200 OK CT -> C The TCCB layer in the Client receives the compressed 200 OK and first checks method type. All mandatory headers that are not present are populated from the cache along with the blanked header contents using the "To:" header contents as an index. After processing, the reconstructed method is forwarded up the stack to the Client (UAC) SIP/2.0 200 OK Via: SIP/2.0/UDP saturn.bell-tel.com From: ;tag=19al To: sip:watson@bell-tel.com Call-ID: 70710@saturn.bell-tel.com CSeq: 1 REGISTER Contact: Note that the CTC remains as per Step 1.2 Example 2: ReRegistration Step 2.1: REGISTER C->CT A REGISTER request is sent from the Client (UAC), to the TCCB layer of the Client (CT) REGISTER sip:bell-tel.com SIP/2.0 Via: SIP/2.0/UDP saturn.bell-tel.com From: ;tag=19al To: sip:watson@bell-tel.com Call-ID: 70710@saturn.bell-tel.com CSeq: 2 REGISTER Contact: Expires: 7200 Step 2.2: REGISTER CT->ST The SIP aware TCCB checks to see which type of method it received. Upon determining itÆs a REGISTER, it uses the "To:" header contents to check the cache. Each header is processed individually and the cache (CTC) checked for a match. If no match found, the cache is updated with the latest information. If a match is found, that particular header contents are blanked. CTC: The following are the set of tables stored in the UA Majumdar et. al. Category - Draft [9] Text-based Compression Using Cache and Blank Approach July 2001 after TCCB processing Table: Request Line Index Contents ----- -------- sip:watson@bell-tel.com sip:bell-tel.com SIP/2.0 Table: Via Index Contents ----- -------- sip:watson@bell-tel.com SIP/2.0/UDP saturn.bell-tel.com Table: From Index Contents ----- -------- sip:watson@bell-tel.com ;tag=19al Table: Call-ID Index Contents ----- -------- sip:watson@bell-tel.com 70710@saturn.bell-tel.com Table: Cseq Index Contents ----- -------- sip:watson@bell-tel.com 2 REGISTER Table: Contact Index Contents ----- -------- sip:watson@bell-tel.com Table: Expires Index Contents ----- -------- sip:watson@bell-tel.com 7200 In this particular example, only the Cseq table was updated. However, a match was found for a significant number of headers so the initial compressed REGISTER is as follows REGISTER Via: From: To: sip:watson@bell-tel.com Call-ID: CSeq: 2 REGISTER Contact: Expires: Now elimination of mandatory headers that have their contents cached takes place. The following headers are mandatory for REGISTER; Via, From, To, Call-ID, Cseq. Majumdar et. al. Category - Draft [10] Text-based Compression Using Cache and Blank Approach July 2001 After mandatory header elimination the final compressed REGISTER will look as follows: REGISTER To: sip:watson@bell-tel.com CSeq: 2 REGISTER Contact: Expires: Step 2.3: REGISTER ST->S The SIP aware TCCB checks to see which type of method it received. Upon determining itÆs a REGISTER, it uses the "To:" header contents to check the cache. All mandatory headers that are not present are populated along with their contents from the cache. Each header is processed individually and the cache (CTS) checked for a match. If a received header is "blanked", the contents are retrieved from the cache, else the cache is updated with the latest contents. CTS: The following are the extract of tables stored in the Server after TCCB processing for this particular registration Table: Request Line Index Contents ----- -------- sip:watson@bell-tel.com sip:bell-tel.com SIP/2.0 Table: Via Index Contents ----- -------- sip:watson@bell-tel.com SIP/2.0/UDP saturn.bell-tel.com Table: From Index Contents ----- -------- sip:watson@bell-tel.com ;tag=19al Table: Call-ID Index Contents ----- -------- sip:watson@bell-tel.com 70710@saturn.bell-tel.com Table: Cseq Index Contents ----- -------- sip:watson@bell-tel.com 2 REGISTER Table: Contact Index Contents ----- -------- sip:watson@bell-tel.com Table: Expires Index Contents Majumdar et. al. Category - Draft [11] Text-based Compression Using Cache and Blank Approach July 2001 ----- -------- sip:watson@bell-tel.com 7200 In this particular example, after updating the Cseq table, the REGISTER is forwarded up the stack to the Server SIP application. REGISTER sip:bell-tel.com SIP/2.0 Via: SIP/2.0/UDP saturn.bell-tel.com From: ;tag=19al To: sip:watson@bell-tel.com Call-ID: 70710@saturn.bell-tel.com CSeq: 2 REGISTER Contact: Expires: 7200 Step 2.4: 200 OK S->ST SIP/2.0 200 OK Via: SIP/2.0/UDP saturn.bell-tel.com From: ;tag=19al To: sip:watson@bell-tel.com Call-ID: 70710@saturn.bell-tel.com CSeq: 2 REGISTER Contact: Step 2.5: 200 OK ST->CT TCCB in the Server first determines that the method is a 200 OK and then reads to the "To:" header contents and uses it as an index to the cache tables. Each header is processed in turn using the same set of rules as in Step 2.2. In this particular instance the cache will remain unchanged from Step 2.3. After processing each header, the initial compressed 200 OK will look as follows: SIP/2.0 200 OK Via: From: To: sip:watson@bell-tel.com Call-ID: CSeq: Contact: Now elimination of mandatory headers that have their contents cached takes place. The following headers are mandatory for 200 OK; Via, From, To, Call-ID, Cseq. Majumdar et. al. Category - Draft [12] Text-based Compression Using Cache and Blank Approach July 2001 After mandatory header elimination the final compressed 200 OK will look as follows: SIP/2.0 200 OK To: sip:watson@bell-tel.com Contact: Step 2.6: 200 OK CT -> C The TCCB layer in the client receives the compressed 200 OK and first checks method type. All mandatory headers that are not present are populated from the cache along with the blanked header contents using the "To:" header contents as an index. After processing, the reconstructed method is forwarded up the stack to the Client (UAC) SIP/2.0 200 OK Via: SIP/2.0/UDP saturn.bell-tel.com From: ;tag=19al To: sip:watson@bell-tel.com Call-ID: 70710@saturn.bell-tel.com CSeq: 1 REGISTER Contact: Note that the CTC remains as per Step 2.2 Example 3: Session Origination - Watson decides to call Homer Simpson to discuss the latest trends in SIP compression. Step 3.1: INVITE C->CT An INVITE is sent from the UAC to the TCCB adaptation layer in the Client. The following are the contents of the INVITE, with the SDP information removed. INVITE sip:simpson@springfield.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP saturn.bell-tel.com From: T. Watson To: H. Simpson Call-ID: 662606876@saturn.bell-tel.com CSeq: 6 INVITE Contact: Subject: Mr. Simpson, Going to MoeÆs? Content-Type: application/sdp Content-Length: ... ..SDP information.. Step 3.2: INVITE CT->ST The SIP aware TCCB checks to see which type of method it received. Upon determining itÆs an INVITE, it uses the "From:" and "To:" headers to access the cache. The "From:" contents provides the first level of Majumdar et. al. Category - Draft [13] Text-based Compression Using Cache and Blank Approach July 2001 indexing while the "To:" offers a further level of granularity should it be required. Each header is processed individually and the cache (CTC) checked for a match. If no match found, the cache is updated with the latest information. If a match is found, that particular header contents are blanked. CTC: The following are the set of tables stored in the UA after TCCB processing Table: Request Line Index Contents ----- -------- sip:watson@bell-tel.com sip:bell-tel.com SIP/2.0 +sip:simpson@bell-tel.com sip:simpson@springfield.bell-tel.com SIP/2.0 Table: Via Index Contents ----- -------- sip:watson@bell-tel.com SIP/2.0/UDP saturn.bell-tel.com Table: From Index Contents ----- -------- sip:watson@bell-tel.com ;tag=19al +sip:simpson@bell-tel.com T. Watson Table: Call-ID Index Contents ----- -------- sip:watson@bell-tel.com 70710@saturn.bell-tel.com +sip:simpson@bell-tel.com 662606876@saturn.bell-tel.com Table: Cseq Index Contents ----- -------- sip:watson@bell-tel.com 1 REGISTER +sip:simpson@bell-tel.com 6 INVITE Table: Contact Index Contents ----- -------- sip:watson@bell-tel.com +sip:simpson@bell-tel.com Table: Expires Index Contents ----- -------- sip:watson@bell-tel.com 7200 Table: Subject Index Contents ----- -------- Majumdar et. al. Category - Draft [14] Text-based Compression Using Cache and Blank Approach July 2001 sip:watson@bell-tel.com Mr. Simpson, Going to MoeÆs? +sip:simpson@bell-tel.com Mr. Simpson, Going to MoeÆs? Table: Content-Type Index Contents ----- -------- sip:watson@bell-tel.com application/sdp +sip:simpson@bell-tel.com application/sdp In this particular example, the only match found was for the Via: header. The cache was updated for all other fields, with the combination of From and To used to provide a further level of granularity where required. The following is the initial compressed INVITE INVITE sip:simpson@springfield.bell-tel.com SIP/2.0 Via: From: T. Watson To: H. Simpson Call-ID: 662606876@saturn.bell-tel.com CSeq: 6 INVITE Contact: Subject: Mr. Simpson, Going to MoeÆs? Content-Type: application/sdp Content-Length: ... ..SDP information.. Now elimination of mandatory headers that have their contents cached takes place. The following headers are mandatory for INVITE; Via, From, To, Call-ID, Cseq. After mandatory header elimination the final compressed INVITE will look as follows: INVITE sip:simpson@springfield.bell-tel.com SIP/2.0 From: T. Watson To: H. Simpson Call-ID: 662606876@saturn.bell-tel.com CSeq: 6 INVITE Contact: Subject: Mr. Simpson, Going to MoeÆs? Content-Type: application/sdp Content-Length: ... ..SDP information.. Step 3.3: INVITE ST->S The SIP aware TCCB checks to see which type of method it received. Upon determining itÆs an INVITE, it uses the "From:" and "To:" headers to access the cache. The "From:" contents provides the first level of Majumdar et. al. Category - Draft [15] Text-based Compression Using Cache and Blank Approach July 2001 indexing while the "To:" offers a further level of granularity should it be required. If a mandatory header is missing or a received header is "blanked", the contents are retrieved from the cache, else the cache is updated with the latest contents. CTS: The following are the extract of tables stored in the Server after TCCB processing for this particular INVITE Table: Request Line Index Contents ----- -------- sip:watson@bell-tel.com sip:bell-tel.com SIP/2.0 +sip:simpson@bell-tel.com sip:simpson@springfield.bell-tel.com SIP/2.0 Table: Via Index Contents ----- -------- sip:watson@bell-tel.com SIP/2.0/UDP saturn.bell-tel.com Table: From Index Contents ----- -------- sip:watson@bell-tel.com ;tag=19al +sip:simpson@bell-tel.com T. Watson Table: Call-ID Index Contents ----- -------- sip:watson@bell-tel.com 70710@saturn.bell-tel.com +sip:simpson@bell-tel.com 662606876@saturn.bell-tel.com Table: Cseq Index Contents ----- -------- sip:watson@bell-tel.com 1 REGISTER +sip:simpson@bell-tel.com 6 INVITE Table: Contact Index Contents ----- -------- sip:watson@bell-tel.com +sip:simpson@bell-tel.com Table: Expires Index Contents ----- -------- sip:watson@bell-tel.com 7200 Table: Subject Index Contents ----- -------- sip:watson@bell-tel.com Mr. Simpson, Going to MoeÆs? +sip:simpson@bell-tel.com Mr. Simpson, Going to MoeÆs? Majumdar et. al. Category - Draft [16] Text-based Compression Using Cache and Blank Approach July 2001 Table: Content-Type Index Contents ----- -------- sip:watson@bell-tel.com application/sdp +sip:simpson@bell-tel.com application/sdp The only header that was compressed is re-constructed using the contents from the Cache. INVITE sip:simpson@springfield.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP saturn.bell-tel.com From: T. Watson To: H. Simpson Call-ID: 662606876@saturn.bell-tel.com CSeq: 6 INVITE Contact: Subject: Mr. Simpson, Going to MoeÆs? Content-Type: application/sdp Content-Length: ... ..SDP information.. Step 3.4: 100 TRYING S->ST SIP/2.0 100 TRYING Via: SIP/2.0/UDP saturn.bell-tel.com From: T. Watson To: H. Simpson Call-ID: 662606876@saturn.bell-tel.com CSeq: 6 INVITE Content-Length: 0 Step 3.5: 100 TRYING ST->CT TCCB in the Server determines that the message is 100 TRYING. It uses the "From:" and "To:" header contents to access the information in the cache. Each header is processed individually. Only header fields that can be compressed are Via:, Call-ID and Cseq. SIP/2.0 100 TRYING Via: From: T. Watson To: H. Simpson Call-ID: CSeq: Content-Length: 0 Now elimination of mandatory headers that have their contents cached takes place. The following headers are mandatory for 1XX responses; Via, From, To, Call-ID, Cseq. Majumdar et. al. Category - Draft [17] Text-based Compression Using Cache and Blank Approach July 2001 After mandatory header elimination the final compressed 100 TRYING will look as follows: SIP/2.0 100 TRYING From: T. Watson To: H. Simpson Content-Length: 0 Note that CTS remains the same as in Step 3.3 Step 3.6: 100 TRYING CT->C TCCB in the Client determines that the message is 100 TRYING. It uses the "From:" and "To:" header contents to access the information in the cache. Each header is processed individually. The missing mandatory headers and blanked header fields are reconstructed. SIP/2.0 100 TRYING Via: SIP/2.0/UDP saturn.bell-tel.com From: T. Watson To: H. Simpson Call-ID: 662606876@saturn.bell-tel.com CSeq: 6 INVITE Content-Length: 0 Note that CTC remains the same as in Step 3.2 Example 4: Session Origination - Watson decides to call Homer Simpson to show video during their discussion, so Watson establishes another call with Simpson. This call follows after the steps in example 3. Step 4.1: INVITE C->CT An INVITE is sent from the UAC to the TCCB adaptation layer in the Client. The following are the contents of the INVITE, with the SDP information removed. INVITE sip:simpson@springfield.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP saturn.bell-tel.com From: T. Watson To: H. Simpson Call-ID: 772276776@saturn.bell-tel.com CSeq: 7 INVITE Contact: Content-Type: application/sdp Content-Length: ... ..SDP information.. Step 4.2: INVITE CT->ST The SIP aware TCCB checks to see which type of method it received. Upon determining itÆs an INVITE, it uses the "From:" and "To:" headers to access the cache. As before, each header is processed individually and the cache (CTC) checked for a match. Majumdar et. al. Category - Draft [18] Text-based Compression Using Cache and Blank Approach July 2001 CTC: The following are the set of tables stored in the UA after TCCB processing Table: Request Line Index Contents ----- -------- sip:watson@bell-tel.com sip:bell-tel.com SIP/2.0 +sip:simpson@bell-tel.com sip:simpson@springfield.bell-tel.com SIP/2.0 Table: Via Index Contents ----- -------- sip:watson@bell-tel.com SIP/2.0/UDP saturn.bell-tel.com Table: From Index Contents ----- -------- sip:watson@bell-tel.com ;tag=19al +sip:simpson@bell-tel.com T. Watson Table: Call-ID Index Contents ----- -------- sip:watson@bell-tel.com 70710@saturn.bell-tel.com +sip:simpson@bell-tel.com 772276776@saturn.bell-tel.com Table: Cseq Index Contents ----- -------- sip:watson@bell-tel.com 1 REGISTER +sip:simpson@bell-tel.com 7 INVITE Table: Contact Index Contents ----- -------- sip:watson@bell-tel.com +sip:simpson@bell-tel.com Table: Expires Index Contents ----- -------- sip:watson@bell-tel.com 7200 Table: Subject Index Contents ----- -------- sip:watson@bell-tel.com Mr. Simpson, Going to MoeÆs? +sip:simpson@bell-tel.com Mr. Simpson, Going to MoeÆs? Table: Content-Type Index Contents ----- -------- sip:watson@bell-tel.com application/sdp Majumdar et. al. Category - Draft [19] Text-based Compression Using Cache and Blank Approach July 2001 +sip:simpson@bell-tel.com application/sdp In this example, matches were found in the Via:, To: , and From: headers. The cache was updated for all other fields. The following is the initial compressed INVITE INVITE sip:simpson@springfield.bell-tel.com SIP/2.0 Via: From: T. Watson To: H. Simpson Call-ID: 772276776@saturn.bell-tel.com CSeq: 7 INVITE Contact: Content-Type: Content-Length: ... ..SDP information.. Now elimination of mandatory headers that have their contents cached takes place. The following headers are mandatory for INVITE; Via, From, To, Call-ID, Cseq. After mandatory header elimination the final compressed INVITE will look as follows: INVITE sip:simpson@springfield.bell-tel.com SIP/2.0 From: T. Watson To: H. Simpson Call-ID: 772276776@saturn.bell-tel.com CSeq: 7 INVITE Contact: Content-Type: Content-Length: ... ..SDP information.. 4.0 Requirements 4.1 Impact on Protocols and Internet Infrastructure a) Transparency When a message is compressed and then decompressed, the resulting message must be bit-wise identical to the original message. 4.2 Coexisting with other schemes Majumdar et. al. Category - Draft [20] Text-based Compression Using Cache and Blank Approach July 2001 a) Header compression TCCB is flexible enough to be used in conjunction with any TCP/IP header compression schemes, in particular as defined by ROHC. For SIP messages it can be further used with any SIP aware compression schemes so defined. b) Encryption TCCB can also be used in conjunction with any end-to-end message encryption scheme and the compression ratio is unaffected by the encryption method used providing that TCCB compression and decompression is done at the same nodes as the encryption/decryption. 4.3 Robustness a) If a message is lost between a compressor and decompressor then the compression scheme still compresses/decompresses correctly and the only loss could be the efficiency of the compression of the messages. Retransmission of SIP messages will take place based on the timer and will be compressed and decompresses as before. TCCB in the adaptation layer is completely ignorant of the retransmission of SIP messages in the Application layer. b) Resilience against residual errors between compressor and decompressor: If the lower layers are unable to detect residual errors in messages, then the compression scheme will still be able to compress/decompress correctly c) Resilience against message misordering between compressor and decompressor. TCCB in the adaptation layer will not be aware the out of sequence messaging and will always be able to compress/decompress all messages which it receives either from an upper layer or from a lower layer. 4.4 Scalability a) Memory Scalability The scheme must be scalable to accommodate a range of compressor/decompressors with varying storage capabilities. A more capable compressor must be able to interoperate with a less capable decompressor and vice versa. b) Processing scalability The scheme must be capable to accommodate a range of compressors/decompressors with varying processing capabilities c) Compression scalability The scheme should allow one to use additional mechanisms and /or more advanced compression methods to boost the compression method 4.5 Compression efficiency a) Average Ratio Majumdar et. al. Category - Draft [21] Text-based Compression Using Cache and Blank Approach July 2001 Must provide the highest compression ratio under constraints that the above requirements are met. b) Compression efficiency should not be affected by handover The compression ratio would be the same as if handover had not occurred. 5.0 Evaluation Here are the sizes of messages before and after compression. Table 1: Comparison of message sizes before and after compression Message Original Using Original Compact Percent size Compact Compressed Headers Decrease Headers Compressed __________________________________________________________________________ REGISTER 267 249 92 74 73% 200 ok 234 216 78 60 74% INVITE(w/o SDP) 357 309 325 277 22.4% 100 TRYING 212 187 141 116 45.2% New INVITE 319 277 238 196 38.6% (w/o SDP) Table 2: Examples of messages compressed with mandatory header removal. Message Original Mandatory Mandatory Percent Overall (bytes) Compressed Headers Headers removed Decrease Percent removed using compact Decrease headers ___________________________________________________________________________ ReREGISTER 92 72 65 29.3% 75.7% 200 ok 77 51 44 42.9% 81.2% INVITE 325 320 274 15.7% 23.2% (w/o SDP) Note: a) The first REGISTER message on power on is the only message, which goes uncompressed b) All consecutive register messages (during the same session) will be almost 75% compressed c) All 200 OK (for REGISTER) messages will be almost 75% compressed d) The first INVITE messages (without SDP information) will be 23% compressed e) All consecutive INVITE messages (for a certain time period) will be further compressed Majumdar et. al. Category - Draft [22] Text-based Compression Using Cache and Blank Approach July 2001 f) Additionally, removal of mandatory headers over TCCB and compression of the "index information" will result in further compression, which we are in the process of evaluating. 6.0 Conclusion In conclusion, TCCB is a simple yet robust and flexible compression mechanism based on the blank and cache approach. Note, the implementation of TCCB in the adaptation layer does not need prior implementations of static dictionaries in the two end points. Furthermore, the caching mechanism could be as simple as a table to as complicated as a dynamic dictionary as proposed by the ROGER and the SCRIBE methods. Optionally TCCB has the flexibility to work with different caching mechanisms at different layers. 7.0 Intellectual Property Rights Considerations Motorola has filed patent applications that might possibly have technical relations to the contribution. 8.0 References 1 H.Hannu, J. Christoffersson and K.Svanbro, "Robust Generic Message Size Reduction (ROGER)" Internet Draft 2. M. Handley and V. Jacobson, SDP: Session Description Protocol. RFC 2327, April 1998 3.M Handley, H.Schulzrinne, E. Scholer and J. Rosenberg, SIP: Session Initiation Protocol. RFC 2543 August 2000 4.Zhigang Liu, Khiem Le, Ka-Cheong Leung, Christopher Clanton,Scalable Robust Efficient Dictionary-Based Compression (SCRIBE) 5.V.Jacobson "Compressing TCP/IP Headers for Low Speed Serial Links" 9.0 Author's Addresses Ishita Majumdar Motorola 1501 W. Shure Drive Arlington Heights, IL 60004 Phone: 847-435-2067 Email: Ishita.Majumdar@motorola.com John O'Hare Majumdar et. al. Category - Draft [23] Text-based Compression Using Cache and Blank Approach July 2001 Motorola, Mahon Ind Estate, Blackrock, Cork, Ireland. Phone: +353-21-451-1333 Email: John.O'Hare@motorola.com Andrew Allen Motorola, 1501 W Shure Dr, Arlington Hts, IL 60004 Phone: 847-435-0016 Email: Allen Andrew-CAA019@email.mot.com Steve Magee MOTOROLA INC. 8075 S. RIVER PKWY. Tempe , AZ 85284 Phone: 480-456-2518 Email: Steve.Magee@motorola.com Colleen Cheung MOTOROLA LTD. 16 EURO-WAY BLAGROVE Swindon, United Kingdom Phone: +44(0)1793 566247 Email: Colleen.Cheung@motorola.com Gerry Foster MOTOROLA LTD. 16 EURO-WAY BLAGROVE Swindon, United Kingdom Phone: +44(0)1793 566519 Email: Gerry.Foster@motorola.com Dr. Nigel A. Ziyad Motorola 1501 W. Shure Drive Arlington Heights, IL 60004 Phone: 847-632-2098 Email: Nigel.A.Ziyad@motorola.com Majumdar et. al. Category - Draft [24] Text-based Compression Using Cache and Blank Approach July 2001 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Majumdar et. al. Category - Draft [25]