Network Working Group Zhigang Liu INTERNET-DRAFT Nokia Expires: May 2003 November 1, 2002 A Recovery Mechanism for Signaling Compression 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 obsoleted 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. This document is a submission to the IETF ROHC WG. Comments should be directed to its mailing list, rohc@ietf.org. Abstract This document defines a recovery mechanism for signaling compression (SigComp). It allows a decompressor to signal to its peer compressor in case it has lost synchronization with the compressor. The compressor can thereafter take appropriate recovery actions. The signals are carried using the state announcement mechanism as defined in SigComp. Liu [Page 1] INTERNET-DRAFT SigComp Recovery November 1, 2002 1. Introduction [SIGCOMP] defines a solution for compressing messages generated by application protocols such as SIP [RFC-3261] and RTSP [RFC-2326]. To guarantee successful decompression, the compressor and decompressor must maintain synchronization on states. [SIGCOMP-EXT] describes a few mechanisms (e.g. acknowledgments, checkpoint state) that can be used for this purpose. However, there are still certain scenarios that cannot be handled by current SigComp specification. For example, if a decompressor loses some or all of its states due to a sudden shortage of memory, memory corruption or even crash, there is no standardized mechanism in SigComp that allows the decompressor to inform the loss of synchronization to its peer compressor. This document introduces a solution to address the problem. 2. Discussions in the Past The issue has been discussed during the development of SigComp. A few solutions were proposed which did not require work within SigComp. 1) Sender timeout and retransmission. Usually, a signaling protocol has the request-response message sequence. If the sender has not received a response to a compressed message sent earlier after certain timeout period, it may assume the compressed message was lost or corrupted and retransmit the compressed message. It repeats this for N timeout periods. After that, it may assume the reason of not receiving a response is decompression failure due to loss of synchronization. It can then start resynchronization procedure (e.g. re-upload states). Before the procedure is finished, it can either compresses subsequent messages by using only static dictionary [SIP-DICT], or it can send them uncompressed. One fundamental problem with above solution is that there are many possible reasons for the sender not to receive the expected response: a) the compressed message sent by the sender is lost; b) the compressed message is corrupted and thus causes decompression failure; c) decompressor loses synchronization and therefore cannot decompress; and d) the response message is lost. The sender simply cannot tell which case it is dealing with. In the case when a loss of synchronization indeed happened, the sender still blindly performs N retransmissions of compressed messages which are deemed to be discarded by the receiver. This leads to unnecessary delay. Note that setting N to 1 does not solve the problem either as that means all the other cases will be incorrectly treated as loss of synchronization. The consequence is Liu [Page 2] INTERNET-DRAFT SigComp Recovery November 1, 2002 lower compression ratio and higher transmission latency. 2) Signal the loss of synchronization outside of SigComp, e.g. at application layer. This simplifies SigComp. However, it means extra standardization work at application layer. In particular, it may require modifications to existing specifications. Since the synchronization problem is introduced at SigComp layer, it would be good to have the problem resolved within SigComp. This will ease the deployment of SigComp into various application environments. 3. Solution Within SigComp Essentially, all we need is an in-band (i.e. within SigComp layer) signaling mechanism that allows decompressor to inform its peer compressor when a loss of synchronization has happened. This can be done by using the state announcement mechanism that already exists in current SigComp specification. 3.1. Sending Signals Using State Announcement [SIGCOMP] defines a state announcement mechanism that allows a SigComp endpoint to announce its locally available states to any remote endpoints. Basically, the announcing endpoint can encode a list of partial state identifiers for those locally available states as part of the returned SigComp parameters ([SIGCOMP], section 9.4.9). A state identifier is the (SHA-1) cryptographic hash calculated over the state. When a remote endpoint receives such an announcement, it can use those locally available states to compress messages sent to the announcing endpoint. This makes it possible to improve compression efficiency without the need of actually uploading those states, assuming that the content of those states are known by the receiving endpoint out of band, e.g. pre-defined in a published document. We can use the above mechanism to send signals as follows. - For each signal, define a locally available state that maps to it. Details will be given below. - To send a signal, a SigComp endpoint simply announces the corresponding state following the state announcement procedure. - When receiving a state announcement, the receiving SigComp endpoint will check the (partial) state identifier received against those of known states that are defined for signaling Liu [Page 3] INTERNET-DRAFT SigComp Recovery November 1, 2002 purpose. If a match is found, the endpoint will translate the state announcement back to the signal semantics it carries. The definition of a state for signaling purpose can be quite arbitrary. However, one key requirement is that it must be globally unique and cannot be easily generated by accident. This is to guarantee the interoperability with those SigComp endpoints that are unaware of this document. Namely, they simply discard the received state announcement since they cannot find the corresponding state. The uniqueness of a state can be achieved by adding a "random salt" to the state value. In general, the length of a random salt should be at least 20 bytes (the length of a state identifier). Note: a SigComp endpoint does not need to store the states themselves defined for signaling purpose. That is because only state identifier is of significance to derive the corresponding signal. The advantages of this approach: - It does not require any changes to current SigComp specification. - There are no interoperability issues (see above). Of course, if a SigComp endpoint is not aware of a particular state, the signals embedded in the state announcement will be discarded. - The signal can be either piggybacked on a compressed application message or sent in a standalone SigComp message (i.e. without application message). The former is required under the generic security model of [SIGCOMP]. The latter is allowed if the receiving endpoint has means to authenticate the standalone message, e.g. when SigComp runs over IPsec as in the case of 3GPP. - Extensibility. New signals can be easily added by defining new states. Disadvantages: - Slight overhead at SigComp endpoints. An endpoint needs to store 20 bytes state identifier for each signal. However, the overhead is negligible in practice, considering that a mobile phone nowadays can easily store 200 entries in its "phone book" and each entry can be tens of characters long. - Overhead on the wire. This depends on how the state announcement is implemented. A simple implementation that sends the (partial) state identifiers explicitly in a SigComp Liu [Page 4] INTERNET-DRAFT SigComp Recovery November 1, 2002 message will cost 6 - 20 bytes per signal. However, a smarter implementation may upload a byte code that can parse some bit flags in a SigComp message and generate the state announcement locally according to the bit flags. In that case, the overhead on the wire is 1 bit per signal plus the one time cost of uploading the byte code. Either way, the signals are only sent for abnormal situations that should not occur frequently. Therefore, the overhead on the wire is an insignificant factor. 3.2. Proposed Recovery Mechanism To address the loss of synchronization problem, we propose to standardize a RESET signal that can be carried by state announcement as described in previous section. Specifically, we define the following two states for RESET signal. One is to signal RESET at endpoint level and another one at compartment level. 1) "RESET-endpoint" state - State definition. The state_value consists of a 22-byte text string "SigComp-RESET-endpoint" followed a random salt of 34 bytes long. The state_length is chosen such that the total size of the state (for the purpose of state identifier calculation) is 64 bytes - the block size of SHA-1[PUB-180-1]. This avoids the padding. Name: Value: ===================== ======================== state_identifier 0x4B7ECDE7DA493EB3430C67ACA230B99F58FE9DB3 state_length 0x0038 state_address 0x0000 (not relevant for the dictionary) state_instruction 0x0000 (not relevant for the dictionary) minimum_access_length 0x0006 state_value see below 0000 5369 6743 6F6D 702D 5245 5345 542D 656E SigComp-RESET-en 0010 6470 6F69 6E74 88C3 B6D1 A3AB 09A0 373C dpoint........7< 0020 4BBA 30DC 729C 91E9 B3C3 F0E5 DD40 52B6 K.0.r........@R. 0030 B746 844F EBE5 55C2 .F.O..U. - Signal semantics. The signal indicates that the sending SigComp endpoint has lost all states except the following: a) any mandatory static states; and b) any locally available states that are announced together in the same message that carries this Liu [Page 5] INTERNET-DRAFT SigComp Recovery November 1, 2002 signal. The SigComp endpoint that receives the signal should take appropriate recovery actions accordingly. For example, it may re- upload dynamic states and in the meanwhile it should send application messages uncompressed or compressed only using those states as described in a) and b). 2) "RESET-compartment" state - State definition. The state_value consists of a 25-byte text string "SigComp-RESET-compartment" followed by a random salt of 31 bytes long. Name: Value: ===================== ======================== state_identifier 0x0A7DC62D273EB06020AC06AD7DA9CFCB61D9AD6E state_length 0x0038 state_address 0x0000 (not relevant for the dictionary) state_instruction 0x0000 (not relevant for the dictionary) minimum_access_length 0x0006 state_value see below 0000 5369 6743 6F6D 702D 5245 5345 542D 636F SigComp-RESET-co 0010 6D70 6172 746D 656E 747F 1ABB 6011 C4BE mpartment...`... 0020 86D7 E632 7BC8 1BB7 768B 746C C203 FE95 ...2{...v.tl.... 0030 EDD1 D31C 718F 860B ....q... - Signal semantics. The signal has the same meaning as that of RESET-endpoint with one important exception: it indicates the sending SigComp endpoint has only lost states saved in the compartment from which the announcement is sent. In other words, it does not carry any information about states that have been saved in other compartments. The SigComp endpoint that receives the signal can identify the announcing compartment in the same way as described in [SIGCOMP]. Namely, if the signal is piggybacked on a (compressed) application message, the compartment identifier will be provided by the application. If the signal is sent in a standalone SigComp message, that means there already exists other means (e.g. IPsec) that can authenticate the message and provide the compartment identifier. Otherwise, a standalone SigComp message would not have been allowed in the first place. Note: which level of RESET signal to use depends on the particular scenario where synchronization of states is lost. Obviously, it does not make sense for a SigComp endpoint to signal RESET at both levels simultaneously. In case that happens, the RESET-compartment signal will be ignored by the receiving endpoint. Liu [Page 6] INTERNET-DRAFT SigComp Recovery November 1, 2002 Note: even though the explicit RESET signal allows a SigComp endpoint to indicate a loss of synchronization, it is still recommended that the sender timeout and retransmission as described in previous section be implemented as a fallback. That is needed when a SigComp endpoint aware of this document communicates with a SigComp endpoint unaware of this document. Note: the recovery mechanism defined here is complementary to the synchronization mechanisms already described in [SIGCOMP] and [SIGCOMP-EXT]. Note: if needed, more signals can be defined under the same framework. 4. Security Considerations The mechanism described in this document is believed not to add any security risks to those mentioned in [SIGCOMP]. 5. IANA Considerations This document does not require any IANA involvement. 6. Intellectual Property Right Notice On IPR related issues, Nokia refers to its statement on patent licensing. Please see http://www.ietf.org/ietf/IPR/NOKIA. 7. References [SIGCOMP] Price, et al., "Signaling Compression", (work in progress), Internet Engineering Task Force, June 2002. [SIGCOMP-EXT] Hannu, et al., "SigComp - Extended Operations", (work in progress), Internet Engineering Task Force, June 2002. [RFC-3261] Rosenberg, et al., "SIP: Session Initiation Protocol", RFC 3261, Internet Engineering Task Force, June 2002. [RFC-2326] H. Schulzrinne, A. Rao and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, Internet Liu [Page 7] INTERNET-DRAFT SigComp Recovery November 1, 2002 Engineering Task Force, April 1998. [SIP-DICT] Garcia, et al., "The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) static dictionary for Signaling Compression (SigComp)", (work in progress), Internet Engineering Task Force, August 2002. [PUB-180-1] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995. 8. Authors' Addresses Zhigang Liu Nokia Research Center Phone: +1 972 894-5935 6000 Connection Drive Fax: +1 972 894-4589 Irving, TX 75039 E-mail: zhigang.c.liu@nokia.com USA 9. Full copyright statement Copyright (C) The Internet Society (2002). 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Liu [Page 8] INTERNET-DRAFT SigComp Recovery November 1, 2002 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This Internet-Draft expires May 1, 2003. Liu [Page 9]