Network Working Group H. Hannu (Editor), Ericsson INTERNET-DRAFT J. Christoffersson, Ericsson Expires: May 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 November 21, 2001 Signaling Compression (SigComp) draft-ietf-rohc-sigcomp-02.txt 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. Hannu, et al. [Page 1] INTERNET-DRAFT SigComp November 21 , 2001 Abstract The Session Initiation Protocol (SIP), along with many other protocols used for multimedia communications, such as RTSP, are textual protocols engineered for bandwidth rich links. With the planned usage of these protocols in wireless handsets as part of 2.5G and 3G cellular networks, the large size of their messages and the chatty nature of the protocols are problematic. This document provides a modular, robust and efficient message compression scheme, suitable for compression of ASCII based protocols' messages. 0. Document History - October 19, 2001, version 00 First version. The draft describes the current ideas, from people involved in the ROHC WG, of how to perform compression of application signaling messages. - October 31, 2001, version 01 Second version. Additional section, 5.2.1, which describes when a message identifier can be reused. - November 21, 2001, version 02 Third version. Section 6 has been moved to a separate draft. The third version describes a modular solution, providing flexibility for implementers to decide which functions they want to integrate. Table of contents 1. Introduction..................................................3 2. Terminology...................................................3 3. High-level description of SigComp.............................4 4. The SigComp protocol..........................................5 5. Compression Framework Component...............................9 6. Capability exchange...........................................13 7. Security considerations.......................................14 8. IANA considerations...........................................14 9. Authors' addresses............................................14 10. Intellectual Property Right Considerations....................16 11. References....................................................16 Hannu, et al. [Page 2] INTERNET-DRAFT SigComp November 21 , 2001 1. Introduction The Session Initiation Protocol (SIP) [SIP], along with many other application protocols used for multimedia communications, such as RTSP [RTSP], are textual protocols engineered for bandwidth rich links. As a result, these messages have not been optimized for message size. Typical SIP messages are from a few hundred bytes to as high as 2000. To date, this has not been a significant problem. With the planned usage of these protocols in wireless handsets as part of 2.5G and 3G cellular networks, the large size of these messages is problematic. The problem is not bandwidth efficiency (the media stream still consumes the majority of the bandwidth), but rather latency. With low-rate IP connectivity, store-and-forward delays are significant. For CDMA2000, for example, the basic channel will support only 9.6 kbps. At this rate, transmission of each byte requires 0.8ms. A 500 byte SIP message requires nearly half a second to transmit. Taking into account retransmits, and the multiplicity of messages that are required in some flows, call setup and feature invocation are adversely affected. Therefore, we believe there is merit in investigating ways to reduce message sizes. This document defines SigComp, a modular, robust and efficient message compression scheme, even when the transport path between the compressor and decompressor is unreliable, i.e. prone to errors, losses and misordering. From the view of external users, SigComp is only to provide compression service. What you get is the service of the underlying transport + compression. Nothing more. Nothing less. SigComp consists of a compression component and a protocol component. The protocol component should not be "extracted" out of the contents of this document for other purpose. This document does not specify a negotiation mechanism. The application that would like to apply SigComp should also negotiate the usage of 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]. Byte buffer The decompressor used by SigComp maintains a byte buffer, which depending on the implementation choice, contain any previously received text strings that might be useful for future compression. Hannu, et al. [Page 3] INTERNET-DRAFT SigComp November 21 , 2001 Context The context of SigComp is the necessary information to perform compression and decompression. The correct context to use is identified by the IP Source and Destination addresses. 3. High-level description of SigComp Compression and decompression is performed at two communicating end- points, A and B, see Figure 1. When a message is to be compressed the compressing entity looks up the IP source and destination addresses and identifies the correct context to use. If no context exists, one is created. Depending on the implementation of the SigComp compressing entity the protocol might add a header to the output of the compressor. The final SigComp message is then passed on to underlying layers for transport to the decompressing entity. Upon the arrival of a SigComp message the SigComp decompressing entity will, if no context exists create one. If the SigComp message carries a header it removes the header and takes the appropriate actions (which depends on the implementation of the decompressing entity), then it gives the remaining SigComp message as input to the decompressor. After a correct decompression the uncompressed message will be passed on to the receiver. original +------------------+ SigComp +--------------------+ message | +----------+ | message | +------------+ | ------------+>|Compressor|-- - + - - - - - -+>|Decompressor|-----+-> | +-----|----+ | | +----|-------+ | | +---|---+ | | +---|---+ | | |Context| | | |Context| | | +---+---+ | | +---+---+ | | +---+---+ | | +---+---+ | | |Context| | | |Context| | decompressed | +---|---+ | SigComp | +---|---+ | message | +-----|--------+ | message | +----|-----------+ | <------------+-| Decompressor |<+- - - - - - +-| Compressor |<+-- | +--------------+ | | +----------------+ | +------------------+ +--------------------+ A B Figure 1. SigComp High-level view. Note: There is no need for one uncompressed message to correspond to exactly one compressed message. Two or more compressed messages can be sent to reconstruct a single uncompressed message, which is useful for segmenting compressed messages that are larger than the MTU of the transport protocol, see [ALG]. Hannu, et al. [Page 4] INTERNET-DRAFT SigComp November 21 , 2001 4. The SigComp protocol The main task of the SigComp protocol is to provide feedback from the decompressor to its peer compressor. The amount of feedback information and how the compressor react to the feedback are choices of the implementation. An implementation may also choose not to implement any feedback mechanisms. For the purpose of feedback, SigComp has a set of headers, as defined in Section 4.1. The use of headers is established at the capability exchange phase, see Section 6. The acknowledgment procedure in Section 4.2 together with the headers MAY be used by a decompressing entity to provide knowledge to the compressing entity about what SigComp messages it has received. This would allow the compressor to use previously sent messages in the compression process, even when the underlying transport protocol is unreliable, see Section 5. 4.1. The SigComp headers The SigComp headers consist of the following fields: Message IDentification (MID) number The MID number is used to keep track of sent and received messages, and is useful for detecting message loss and/or misordering. CRC-verification of messages (CRC-M) This CRC is calculated over the uncompressed message, e.g. the SIP INVITE message, and is used to verify the correctness of a decompressed SigComp message. Acknowledgement A SigComp acknowledgement can either be carried within a SigComp message (Piggybacked) or be sent by itself (Standalone). Note: It is assumed that the total length of a SigComp message is provided by the underlying transport layer. Since the length of the header part is self-contained the length of the compressed information can be derived by subtracting the header length from the total SigComp message length. The compressed information length could be zero in the case of a Standalone acknowledgement. Header formats are described in the following sub-sections. Hannu, et al. [Page 5] INTERNET-DRAFT SigComp November 21 , 2001 4.1.1. Normal header formats These are the normal header formats to use. Format 1 SHOULD be used when there has been no gap in the received MID numbers up to the generation of this SigComp message. To acknowledge received SigComp messages after a gap in the received MID numbers, Format 2 MUST be used Format 1 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | MID | Cumulative ACK| +---+---+---+---+---+---+---+---+ | CRC-M | +---+---+---+---+---+---+---+---+ / Compressed information / / according to Section 5 / +---+---+---+---+---+---+---+---+ Format 2 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 0 | MID | +---+---+---+---+---+---+---+---+ | CRC-M | +---+---+---+---+---+---+---+---+ | AC | RMID (1) | +---+---+---+---+---+---+---+---+ | RMID (2) | RMID (3) | +---+---+---+---+---+---+---+---+ : : / / : : +---+---+---+---+---+---+---+---+ | RMID (C-1) | RMID (C) | +---+---+---+---+---+---+---+---+ / Compressed information / / according to Section 5 / +---+---+---+---+---+---+---+---+ MID: "0000" to "1101". The Message IDentification (MID) number is commonly increased with one for each sent message. However, there is the exception when the next MID to be assigned is not "free", see Section 4.2.1. Hannu, et al. [Page 6] INTERNET-DRAFT SigComp November 21 , 2001 Cumulative ACK Acknowledges all SigComp messages with MID number equal to or less than the value of this field. The value of this field MUST NOT be set to a value so that non-received SigComp messages are acknowledged. A received acknowledgement with higher value than the maximum MID MUST be ignored and MUST NOT be considered as an acknowledgement for SigComp messages. CRC-M TBW RMID Received MID of a SigComp message, which is being acknowledged. AC Number of received SigComp message being acknowledged (RMID), which are included in the List. If AC is an even number the last RMID, RMID(C), is only padding, in order to get octet aligned. 4.1.2. Extended message formats Format 3 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 | TBD | +---+---+---+---+ + / TBD / : : / / +---+---+---+---+---+---+---+---+ Note: The usage of this format is yet to be determined. (Decompressing failure etc.) 4.2. Acknowledgement procedure The acknowledgement procedure is dependent on the information carried in the SigComp headers. It is RECOMMENDED that all SigComp messages are acknowledged. Three functions are needed: - A function that holds the received MID-numbers which should be acknowledged. Hannu, et al. [Page 7] INTERNET-DRAFT SigComp November 21 , 2001 - A function that keeps a mapping between sent MID numbers and acknowledged MID numbers. - A function that controls which MID numbers that an entity is allowed to use. It is up to the implementation to realize these functions The acknowledgement procedure is best described using an example, see Figure 3. A B | | Step (0) |<----------- MID 1B ----------| | | Step (1) |-------- MID 1A, ACK 1B ---->| | | Step (2) |<--------MID 2B, ACK 1A ------| | | Figure 3. Example of the acknowledgement procedure. Step (0): A SigComp message with Message IDenitifcation number 1 is sent from B to A, denoted MID 1B in Figure 3. MID 1B MUST be acknowledged by A until A is confident that B knows that MID 1B is received. Step (1): Entity A acknowledges MID 1B with SigComp message MID 1A. A mapping between MID 1A and MID 1B is stored at A. Note that MID 1A do not have to carry compressed information, it can be a Standalone Acknowledgement. Step (2): Entity B acknowledges MID 1A and stores a mapping between MID 2B and MID 1A. When Entity A receives MID 2B it uses the mapping to find out which SigComp message(s) from B was acknowledged by MID 1A. The mapping is removed and MID 1B MUST NOT be acknowledged anymore. 4.2.1. Reuse of Message IDentification numbers This section describe when a MID can be reused to avoid misinterpretations in case of wraparound of MID numbers combined with message loss and/or misordering. A MID number MUST NOT be reused until the SigComp message with that particular MID number has been acknowledged and stopped being acknowledged, or that the message can be regarded as lost. Hannu, et al. [Page 8] INTERNET-DRAFT SigComp November 21 , 2001 Figure 4, is a continuation of the example given in Figure 3. The Figure depicts an example when it is allowed to reuse a MID number that has been acknowledged and stopped being acknowledged. A B | | Step (3) |-------- MID 2A, ACK 2B ---->| | | Figure 4. Continuation of Figure 3. Step (3): When Entity B receives an acknowledgement for MID 2B it knows that the mapping for MID 1B is removed at A. Therefore it is safe for entity B to reuse MID 1B. A message can be regarded as lost, if the SigComp entity has received acknowledgments for higher MID numbers than the MID number the entity wishes to reuse. However, as SigComp must stand against moderate misordering according to [REQ], a MID number X MUST NOT be regarded as lost until an acknowledgement for message(s) with MID numbers > (X+2) has been received. 5. Compression Framework Component SigComp uses the "Universal Decompression Algorithm" described in [ALG] for the actual compression. The "universal decompressor" is capable of interoperating with a wide range of compression algorithms. It is the compressor which decides what information that is stored in the dictionary of the decompressor. The compressor also controls how the decompressor performs the decompression. This section describes various features that a SigComp implementation may use to improve the compression efficiency. Some of these feature requires additional entries in the byte buffer of the "universal decompressor". 5.1. Pre-population A compressor MAY pre-populate the dictionary with well-known information (text-strings), in order to increase the compression efficiency. This is a rather simple approach with the "universal decompressor", see [ALG]. 5.2. Per-message compression Compressing a message without any relation to any other message is referred to as per-message compression. Per-message compression can be used regardless of the reliability of the underlying transport and Hannu, et al. [Page 9] INTERNET-DRAFT SigComp November 21 , 2001 the usage of the SigComp headers, as it is not dependent on any previously transmitted messages. To get compression of messages at all, this is the approach which all implementations of SigComp MUST support. Implementation support for the features in the following sections is optional. 5.3. Dynamic compression A compressing entity MAY choose to use previously sent messages in the compression process in an attempt to improve the compression efficiency. This is referred to as dynamic compression. To ensure reliable operation of the compression algorithm a compressor MUST NOT use dynamic compression, unless it is certain of that the message it is about to compress can be decompressed by the decompressor. If SigComp is used over reliable transport, such as TCP, dynamic compression does not introduce any robustness problem. To withhold robustness over unreliable transport, such as UDP, the SigComp acknowledgement procedure MUST be used when dynamic compression is applied. Thus, a previously sent message MUST NOT be used in the compression process until it has been acknowledged. Referring to Figure 3, B MAY use information in 1B to improve the compression efficiency of the message corresponding to 2B. 5.4. Shared compression Shared compression is referred to the case when a compressor 'A' make use of decompressed messages received by the decompressor located at the same SigComp entity. These decompressed messages MUST originate from the corresponding SigComp entity, which decompressor is controlled by compressor 'A'. Shared compression is OPTIONAL and its support is established in the capability exchange. To allow shared compression it is REQUIRED to use the SigComp acknowledgment procedure regardless of the reliability of the underlying transport. Referring to Figure 3, B MAY use information in 1A to improve the compression efficiency of the message corresponding to 2B. For shared compression to be applicable with the "universal decompressor" a SigComp entity supporting shared compression MUST implement two additional entries in the byte buffer of the decompressor: shared_start This is the start address in the byte buffer where original Hannu, et al. [Page 10] INTERNET-DRAFT SigComp November 21 , 2001 messages (not compressed) from this entity, which are being acknowledged, are to be placed into the byte buffer of the decompressor. By setting shared_start = 0, a compressor can avoid that any acknowledged message is written to the byte buffer. shared_length This is used by the protocol part to inform the decompressor algorithm if there was any new information, and the length of it, written to the shared compression part of the byte buffer. To avoid that same message information is processed twice, in case of multiple acknowledges for one message, the protocol MUST set shared_length = 0. Figure 5. depicts a logical view of the decompressor byte buffer at a SigComp entity which supports shared compression. +----A----------------------B---------------------+ | | Circular buffer for | Circular buffer for | | | received messages | shared compression | +----A----------------------B---------------------+ Figure 5. Logical view of the decompressor byte buffer. A and B are the addresses which circular_buffer and shared_start point to. The received circular buffer will be between circular_buffer and shared_start-1. When the decompressing SigComp entity receives a SigComp message containing acknowledgements for e.g. MID-2 and MID-3 it will copy the original messages corresponding to MID-2 and MID-3 to the decompressor buffer at the address specified in shared_start. 5.4.1. Specification of ordering constraints Inconsistency in the dynamic context data can happen if the context is shared and messages, which will update the dynamic context data, are sent concurrently by both entities. The approach to deal with this problem is to specify ordering constraints of all update messages sent by both entities so that the order is total and the same at both entities, at least for the eligible updates. Three rules are defined; local, causality and concurrent rule. With the first two rules and the use of the 3-way handshake, it is possible to ensure consistency during updates of dynamic context data, but there is one case that these do not resolve; dynamic context data updates issued concurrently by both entities. With an update request in the description of the rules below means; Every message that carries information that is used to update the dynamic context data. Hannu, et al. [Page 11] INTERNET-DRAFT SigComp November 21 , 2001 Local Rule When a dynamic context data update request R' is sent before R" at the same entity, R' is scheduled to perform an update before R" at both entities. A sending entity schedules its own update requests according to their sequence numbers, whereas a receiving entity schedules these requests according to the request sequence numbers, which can be inferred from the sequence numbers of those SigComp messages containing these requests. Causality rule When a SigComp message containing a dynamic context data update request R' piggybacks with acknowledgements, R' is scheduled to perform an update after all the updates corresponding to the acknowledged update requests. Concurrent rule The problem explained above can be eliminated by requiring the maintenance of a total order relationship for a sequence of all known context update requests at each entity. This requires that one entity is the master and one is the slave. An example showing how the scheme with the total order relationship solves the inconsistent context update problem is shown in Figure 6. Suppose all messages exchanged between Entity X (a master entity) and Entity Y (a slave entity) are employed for subsequent compression/decompression, and all received messages are acknowledged and piggybacked in all subsequent messages sent by the receiver. Whenever concurrent dictionary updates are happened, update requests initiated from the master entity are ordered first. For example, the update requests for Messages 1, 2, and 3 are ordered before those for Messages 101, 102, and 103 respectively in the list of the total order relationship for a sequence of dictionary updates (TOL). DD is a logical representation of the Dynamic Context Data, TSS is the logical representation of sent SigComp messages and TRS is the logical representation storage of received SigComp messages. Since the update request for Message 1 is ordered before that for Message 101 according to the total order relationship, the update request for Message 101 at Entity Y is blocked until that for Message 1 becomes ready to be moved, as indicated by the reception of the acknowledgement piggybacked with Message 3. | | DD = {} | | DD = {} TSS = {1} | | TSS = {101} TRS = {} | | TRS = {} TOL = {1} | | TOL = {} | [1] [101] | Hannu, et al. [Page 12] INTERNET-DRAFT SigComp November 21 , 2001 |-----------\ /-----------| | \/ | | /\ | |<----------/ \---------->| | | DD = {} | | DD = {} TSS = {1, 2} | | TSS = {101, 102} TRS = {101} | | TRS = {1} TOL = {1, 101, 2} | | TOL = {1} | [2] [102] | |-----------\ /-----------| | \/ | | /\ | |<----------/ \---------->| | | DD = {1} | | DD = {} TSS = {2, 3} | | TSS = {101 - 103} TRS = {101, 102} | | TRS = {1, 2} TOL = {101, 2, | | TOL = {1, 101, 2} 102, 3} | | | [3] [103] | |-----------\ /-----------| | \/ | | /\ | |<----------/ \---------->| | | DD = {1, 101, 2} | | DD = {1, 101} TSS = {3} | | TSS = {102, 103} TRS = {102, 103} | | TRS = {2, 3} TOL = {102,3,103} | | TOL = {2, 102, 3} | | CD Entity X CD Entity Y Figure 6. An Example of Proposed Scheme with Total Order Relationship for Dynamic Context Data Updates. 6. Capability exchange Before two SigComp entities start to send compressed messages between them, they MUST agree on the capabilities they will use. This section does not specify how to perform the exchange, but preferably it should be conducted at the negotiation of applying SigComp. Buffer size The available byte buffer size of the decompressor MUST be exchanged. Hannu, et al. [Page 13] INTERNET-DRAFT SigComp November 21 , 2001 SigComp headers Only in the case when both SigComp entities indicate the use of headers, the SigComp protocol MUST add a SigComp header to the compressor output. In any other case the protocol MUST NOT add a header. Shared compression If a SigComp entity supports shared compression it MAY indicate that. However, shared compression can only be used in combination with SigComp headers. A SigComp entity is not required to use shared compression even if it is supported by the corresponding entity. CPU power TBW 7. Security considerations TBW 8. IANA considerations TBW 9. Authors' addresses Hans Hannu, Editor Box 920 Ericsson Erisoft AB SE-971 28 Lulea, Sweden Phone: +46 920 20 21 84 Fax: +46 920 20 20 99 EMail: hans.hannu@epl.ericsson.se Jan Christoffersson Box 920 Ericsson Erisoft AB SE-971 28 Lulea, Sweden Phone: +46 920 20 28 40 Fax: +46 920 20 20 99 EMail: jan.christoffersson@epl.ericsson.se Hannu, et al. [Page 14] INTERNET-DRAFT SigComp November 21 , 2001 Christopher Clanton Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 894-4886 Fax: +1 972 894-4589 E-mail: christopher.clanton@nokia.com Stefan Forsgren Box 920 Ericsson Erisoft AB SE-971 28 Lulea, Sweden Phone: +46 920 20 23 39 Fax: +46 920 20 20 99 EMail: stefan.forsgren@epl.ericsson.se Khiem Le Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 894-4882 Fax: +1 972 894-4589 E-mail: khiem.le@nokia.com Ka Cheong Leung Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972 374-0630 Fax: +1 972 894-4589 E-mail: kacheong.leung@nokia.com Zhigang Liu 2-700 Mobile Networks Laboratory Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA Phone: +1 972 894-5935 Fax: +1 972 894-4589 Hannu, et al. [Page 15] INTERNET-DRAFT SigComp November 21 , 2001 EMail: zhigang.liu@nokia.com Richard Price Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom Phone: +44 1794 833681 Email: richard.price@roke.co.uk Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 Email: jdrosen@dynamicsoft.com Krister Svanbro Box 920 Ericsson Erisoft AB SE-971 28 Lulea, Sweden Phone: +46 920 20 20 77 Fax: +46 920 20 20 99 EMail: krister.svanbro@epl.ericsson.se 10. 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. 11. References [ALG] R. Price et. al., Universal Decompression Algorithm, Internet Draft (work in progress), November 2001. [DEFLATE] "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, P. Deutsch, May 1996 [RTSP] H. Schulzrinne, A. Rao and R. Lanphier, Real Time Streaming Protocol (RTSP), RFC 2326, April 1998. Hannu, et al. [Page 16] INTERNET-DRAFT SigComp November 21 , 2001 [REQ] H. Hannu (Editor), Signaling Compression Requirements & Assumptions, Internet Draft (work in progress),November 2001. [SIP] M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg, SIP: Session Initiation Protocol, RFC 2543, August 2000. This Internet-Draft expires in May 2002. Hannu, et al. [Page 17]