Network Working Group H. Hannu (Editor), Ericsson INTERNET-DRAFT J. Christoffersson, Ericsson Expires: July 2002 C. Clanton, Nokia S. Forsgren. Ericsson K. Le, Nokia K. Leung, Nokia Z. Liu, Nokia R. Price, Siemens/Roke Manor J. Rosenberg, Dynamicsoft K. Svanbro, Ericsson January 28, 2002 SigComp - Extended Operations 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is a submission of the IETF ROHC WG. Comments should be directed to its mailing list, rohc@cdt.luth.se. Abstract This document defines extended operation mechanisms, explicit acknowledgements and shared compression, for [SIGCOMP]. When extended SigComp implementations communicate an increase of the compression efficiency is expected. Hannu, et al. [Page 1] INTERNET-DRAFT SigComp - Extended Operations January 28 , 2002 0. Document History - January 28, 2002, version 00 First version. This draft describes the extended operation mechanisms, explicit acknowledgements and shared compression from draft-ietf-rohc-sigcomp-02.txt. Table of contents 1. Introduction..................................................2 2. Terminology...................................................2 3. The Extended SigComp Architecture.............................4 4. State reference model.........................................5 4.1. Overview of state reference with dynamic compression........6 5. Extended operation mechanisms.................................7 5.1. Explicit acknowledgement scheme.............................7 5.2. Shared Compression..........................................7 6. Implications on SigComp.......................................8 6.1. Acknowledgement optimization................................9 6.2. Saving state information....................................9 7. Security considerations......................................10 8. IANA considerations..........................................10 9. Acknowledgements.............................................10 10. Authors' addresses...........................................10 11. Intellectual Property Right Considerations...................11 12. References...................................................11 1. Introduction This document defines extended operation mechanisms, explicit acknowledgements and shared compression, for [SIGCOMP]. These mechanisms are expected to improve the compression efficiency between communicating extended SigComp implementations, compared to the case when one of the communicating implementations only support basic SigComp. For better understanding of this draft the reader should consult [SIGCOMP]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. Hannu, et al. [Page 2] INTERNET-DRAFT SigComp - Extended Operations January 28 , 2002 Universal Decompressor Virtual Machine (UDVM) The virtual machine described in [UDVM]. The UDVM is used for decompression of SigComp messages. The UDVM is capable of interoperating with a wide range of compression algorithms. Decompressor The decompressor invokes the UDVM. It is responsible for supplying the UDVM with compressed data and make decompressed data available for the application. Compressor The compressor invokes the encoder, and keeps track of states that can be used for compression. Responsible for supplying UDVM instructions to the peer decompressor in order for compressed data to be decompressed. Explicit acknowledgements Is defined as the case where an acknowledgement for a state is explicitly sent from a decompressor to a compressor. The acknowledgment can either be sent standalone or piggybacked with a SigComp message. Shared compression Is defined as the case when a compressor uses data that has been received by the associated decompressor. Dynamic compression Is defined as the case when a compressor uses data, which are related to previous SigComp messages. Encoder Encodes data according to a (compression) algorithm into UDVM readable code. The encoded data can be decoded by a UDVM provided with the needed instructions. Application Invokes the SigComp compressor and decompressor. State Data saved either by a compressor or a decompressor. The data reflects the contents of a UDVM memory. Hannu, et al. [Page 3] INTERNET-DRAFT SigComp - Extended Operations January 28 , 2002 State index Reference to a state saved either by a compressor or a decompressor. - state_index This is a reference to a state, which a compressor uses for compression. - shared_index This is a reference to a state, which consist only of an uncompressed message. This kind of state is necessary for efficient utilization of shared compression, as peer compressors might use different compression algorithms. - acked_index This is a reference to a state, which is acknowledged and saved by a decompressor. SigComp message In case of a message oriented transport mechanism, such as UDP, a SigComp message corresponds to exactly one (UDP) packet. For a stream oriented transport, such as TCP, each SigComp message is separated by a 0xFFFF delimiter, see [UDVM]. Application data (message) Data, also referred to as message, which is to be compressed by the compressor. When delivered from the decompressor the data has passed through the decompression process and is referred to as decompressed data or decompressed message. 3. The Extended SigComp Architecture Compression and decompression is performed at two communicating end- points, see Figure 1. Hannu, et al. [Page 4] INTERNET-DRAFT SigComp - Extended Operations January 28 , 2002 +--------------------+ +--------------------+ | Compressor 1 | | Decompressor 1 | | +---------+ | | +---------+ | | | Encoder | | | | UDVM | | | +---------+ | | +---------+ | +--------------------+ +--------------------+ ^ ^ App. ^ | ^ | App. ^ | | | data | | | v data | v +-|--|-------------|-+ +-|-------------|--|-+ | | | | | SigComp | | | | | |[E] | Application v | message | | Application | | | | | v +---------->----------+ v | | | | +-------+ | | +-------+ | | | | | State | | Data transport | | State | | | | | +-------+ | | +-------+ | | | | ^ +----------<----------+ ^ | | | | | | | SigComp | ^ | [E]| | | | | | message | | | | | +-|--|-------------|-+ +-|-------------|--|-+ ^ | App. ^ | | | App. | | | v data | v | v data v v +--------------------+ +--------------------+ | Decompressor 2 | | Compressor 2 | | +---------+ | | +---------+ | | | UDVM | | | | Encoder | | | +---------+ | | +---------+ | +--------------------+ +--------------------+ Figure 1. Extended SigComp High-level view. The difference between SigComp and extended SigComp is the availability of "interface" E (symbol [E]). With the extended operation, explicit acknowledgements (symbol [E]), it is possible for e.g. decompressor 1 to inform compressor 1 about states that have been established at decompressor 1. Compressor 1 can then use these states in the compression process. Depending on the established states, this is expected to increase the compression efficiency. See Section 6 for the extended SigComp message format. 4. State reference model A UDVM [UDVM] may want to save the status of its memory. This status is referred to as a state. The decompressor may allow the state to be saved. For later reference to this state, e.g. if the UDVM is to be loaded with this state, a reference is needed to locate the specific state. This reference is called state index. Hannu, et al. [Page 5] INTERNET-DRAFT SigComp - Extended Operations January 28 , 2002 4.1. Overview of state reference with dynamic compression When compressor 1 (comp_1) compresses a message M it uses the information corresponding to a UDVM state that the peer decompressor (decomp_1) has established and acknowledged. If comp_1 decides that it for compression of later messages would like to be able to use the new state, which is the former state with the addition of information from M, it must save the new state. If an acknowledgement is received for this new state, comp_1 can utilize the new state in the compression process. Below is an overview of the model. Available state(s) Compressor: The state is anticipated for compression of later messages, and is therefore saved. Decompressor: The decompressor saves the state if it will acknowledge it. An acknowledged state may be used for compression. Acked state(s) The compressor can only use a state(s) that the peer decompressor has saved and acknowledged. Compressor 1 Decompressor 1 +---+ +---+ | C | | D | +---+ +---+ Available Acked | | Available State(s) State(s) | | State(s) -----------------------+------------+------------------ s0 s0 | | s0 s1=s0+m1 | --m1(s0)-->| | <--ack(s1) | s0,s1 s0,s1 s0,s1 | | | | s0,s1 s0,s1 | --m2(s1)-->| (m2 Lost) s2=s1+m1 | | | | s0-s2 s0,s1 | | s3=s1+m3 | --m3(s1)-->| s0,s1 | | | | | <--ack(s3) | s0,s1,s3=s1+m3 s0-s3 s0,s1,s3 | | Hannu, et al. [Page 6] INTERNET-DRAFT SigComp - Extended Operations January 28 , 2002 5. Extended operation mechanisms For a compressor to be able to utilize a certain state it must know that the peer decompressor has access to this state. In case where compressed messages can be lost or misordered on the path between compressor and decompressor, some sort of acknowledgement must be used by a decompressor to notify the peer compressor that a certain state has been established. Over reliable and ordered transport the most recent state can always be used, if the compressor has downloaded such a UDVM instruction code to the peer decompressor. The following subsections describe how an explicit acknowledgement scheme and shared compression can be used in SigComp. 5.1. Explicit acknowledgement scheme As described above, a SigComp message will along with the compressed message carry a reference to which state that was used for compression of the message. This reference is the state_index, as described in Section 2. Together with state_index the SigComp message may also carry an acknowledgement, which would be the acked_index, see Section 2. The acknowledgement can be either standalone or piggybacked. 5.2. Shared Compression To allow for shared compression a compressor must save a state, which is the uncompressed version of the compressed message. The reference to this uncompressed version is the shared_index, as described in Section 2. It must also indicate to the peer decompressor that this compressed message's uncompressed version was saved as a state at the compressor. When a decompressor receives a compressed message utilizing shared compression, the state indicated by state_index in the SigComp message is loaded to the UDVM. Thereafter the state indicated by shared_state is loaded to the UDVM. The shared state is loaded to the UDVM by setting the first_token to the shared_pointer (a pointer at a defined position), which points to the code that will insert the shared state into the "live dictionary" of the UDVM. The shared state data is copied into compressed_start and compressed_end is updated, and the UDVM is invoked. Then first_token is set to its previous value, and the message can be compressed by invoking the UDVM. Hannu, et al. [Page 7] INTERNET-DRAFT SigComp - Extended Operations January 28 , 2002 6. Implications on SigComp For the support of the extended operation mechanisms, SigComp messages must be able to carry the indications and information addressed in Section 5. A decompressor that does not support the extended operations, must be able to derive the length of the information in a SigComp message, which the peer compressor might have added for the extended operation mechanisms, see [SIGCOMP]. In case that shared compression and/or explicit acknowledgements are not supported the information is discarded before the SigComp message is processed any further. Figure 1, depicts a complete SigComp message, with the support of all extended operation mechanisms. An Optimization of this message is also shown and explained in Section 6.1. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | i | c | s | a | r | b |Reserv.| +---+---+---+---+---+---+---+---+ | | : state_index (n-bytes) : Present if 'i' is set | | +---+---+---+---+---+---+---+---+ | | : CRC : Present if 'c' is set | | +---+---+---+---+---+---+---+---+ | | : shared_index (n-bytes) : Present if 's' is set | | +---+---+---+---+---+---+---+---+ | | : acked_index (n-bytes) : Present if 'a' is set | | +---+---+---+---+---+---+---+---+ | Possible | : Compressed data that should : | be given as input to the UDVM | +---+---+---+---+---+---+---+---+ Figure 1. SigComp message. 'r' : If set, then a state corresponding to the decompressed version of this compressed message was saved at the compressor. 'b' : Explained in Section 6.1. The CRC is calculated over the uncompressed message and can e.g. be used for verification of successful decompression. Hannu, et al. [Page 8] INTERNET-DRAFT SigComp - Extended Operations January 28 , 2002 For the explanation of (n-bytes) see [SIGCOMP]. 6.1. Acknowledgement optimization This section describes an optimization for the case when shared compression is used and an acknowledgement is piggybacked. Consider the following. Comp_1 sends a message M compressed, with state(s0) to decomp_1. As comp_1 supports shared compression it saves state(M), and sets bit 'r', to signal that state(M) can be used by comp_2 in the compression process. If decomp_1 saves state(s0+M) = state(s1), which is the new state of the UDVM after decompression of M, then state(s1) can be implicitly acknowledged, if comp_2 uses M for further compression. Comp_2 sets the 'b' bit, which indicates that state(s0+M) is saved, which can be found from state(M), which is referenced by shared_index. This avoids acked_index to be present in the SigComp message for state(s0+M). Thus, a compressor that sets the 'r' bit should also hold a mapping between state(M) and state(s0+M). Note: The only state that this feature acknowledges, is the state that was created by combining the state used for compression of the shared message and the shared message itself. For any other case the acked_index has to be used. 6.2. Saving state information There are some simple rules, which must be followed, when a state is to be saved. Decompressor If there already exists a state for a state index, it must not be replaced with the requested state to be saved. This is to avoid that a compressed message cannot be decompressed because its state has been replace with another one. Compressor If there already exists a state for a state index, generated by the compressor, the compressor must not use that state for compression of any later messages even if an acknowledgement for this state is received. These states (state indexes) should be kept for a reasonable amount of time to avoid that a state used by the compressor is not actually the same as the one stored at the peer decompressor, even though the state index is the same. Hannu, et al. [Page 9] INTERNET-DRAFT SigComp - Extended Operations January 28 , 2002 7. Security considerations The features in this document are believed not to add any additional security risks to the ones in [SIGCOMP] and [UDVM]. 8. IANA considerations [Editors note: This section is TBW] 9. Acknowledgements [Editors note: This section is TBW] 10. Authors' addresses Hans Hannu, Editor Phone: +46 920 20 21 84 Fax: +46 920 20 20 99 E-Mail: hans.hannu@epl.ericsson.se Jan Christoffersson Phone: +46 920 20 28 40 Fax: +46 920 20 20 99 E-Mail: jan.christoffersson@epl.ericsson.se Stefan Forsgren Phone: +46 920 20 23 39 Fax: +46 920 20 20 99 E-Mail: stefan.forsgren@epl.ericsson.se Krister Svanbro Phone: +46 920 20 20 77 Fax: +46 920 20 20 99 E-Mail: krister.svanbro@epl.ericsson.se Box 920 Ericsson Erisoft AB SE-971 28 Lulea, Sweden Christopher Clanton Phone: +1 972 894-4886 Fax: +1 972 894-4589 E-mail: christopher.clanton@nokia.com Hannu, et al. [Page 10] INTERNET-DRAFT SigComp - Extended Operations January 28 , 2002 Khiem Le Phone: +1 972 894-4882 Fax: +1 972 894-4589 E-mail: khiem.le@nokia.com Ka Cheong Leung Phone: +1 972 374-0630 Fax: +1 972 894-4589 E-mail: kacheong.leung@nokia.com Zhigang Liu Phone: +1 972 894-5935 Fax: +1 972 894-4589 E-Mail: zhigang.liu@nokia.com Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA Richard Price Phone: +44 1794 833681 E-mail: richard.price@roke.co.uk Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom Jonathan Rosenberg E-mail: jdrosen@dynamicsoft.com dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 11. Intellectual Property Right Considerations The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 12. References [SIGCOMP] H. Hannu et. al., Signaling Compression (SigComp), Internet Draft (work in progress), January 2002. Hannu, et al. [Page 11] INTERNET-DRAFT SigComp - Extended Operations January 28 , 2002 [UDVM] R. Price et. al., Universal Decompressor Virtual Machine (UDVM), Internet Draft (work in progress), January 2002. This Internet-Draft expires in July 2002. Hannu, et al. [Page 12]