Network Working Group H. Hannu, Ericsson INTERNET-DRAFT J. Christoffersson, Ericsson Expires:
SeptemberNovember 2002 S. Forsgren. EricssonForsgren K. Leung, NokiaLeung Z. Liu, Nokia R. Price, Siemens/Roke Manor March 1,May 03, 2002 SigComp - Extended Operations <draft-ietf-rohc-sigcomp-extended-02.txt><draft-ietf-rohc-sigcomp-extended-03.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, email@example.com@ietf.org. Abstract This document defines extended operationdescribes mechanisms to be used with Signaling Compression (SigComp), RFC XXX, that significantly improve the compression efficiency compared to using per-message compression. The mechanisms, such as explicit acknowledgements and shared compression, for [SIGCOMP]. When these extended mechanisms are applied an increase of thecompression efficiency is expected.are defined and explained in this document. Table of contents 1. Introduction..................................................2Introduction....................................................2 2. Terminology...................................................2Terminology.....................................................2 3. Architectural viewView of feedback................................4Feedback..................................4 4. State reference model.........................................5Reference Model...........................................4 5. Extended operation mechanisms.................................6Mechanisms.............................................6 6. Implications on SigComp.......................................9SigComp........................................11 7. Security considerations......................................13Considerations........................................15 8. IANA considerations..........................................13Considerations............................................15 9. Acknowledgements.............................................14Acknowledgements...............................................15 10. Authors' addresses...........................................14Addresses.............................................15 11. Intellectual Property Right Considerations...................15Considerations.....................16 12. References...................................................15 Appendix A. Document history.....................................15References.....................................................16 1. Introduction This document defines extended operation mechanisms, such as explicit acknowledgements and shared compression, for [SIGCOMP]. Thesedescribes how to implement mechanisms are expectedwith [SIGCOMP] to significantly improve the compression efficiency,efficiency compared to per- messages compression. One such mechanism is to use previously sent messages in the caseSigComp compression process, referred to as dynamic compression. In order to utilize information from previously sent messages, it is necessary for a compressor to gain knowledge about the reception of these messages. For a reliable transport, such as TCP, this is guaranteed. For an unreliable transport however, the SigComp protocol can be used to provide such a functionality itself. That functionality is described in this document and is referred to as explicit acknowledgements. Another mechanism that will improve the compression efficiency of SigComp, especially when oneSigComp is applied to protocols that are of request/response type, is shared compression. This involves using received messages in the communicating implementations only supportsSigComp compression process. In particular the basic SigComp.compression of the first few messages will gain from shared compression. Shared compression is described in this document. For better understanding of this draft the reader should consultbe familiar with the concept of [SIGCOMP]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" inreader should consult [SIGCOMP] for definitions of terminology, since this document are to be interpreted as described in [RFC-2119]. Universal Decompressor Virtual Machine (UDVM) The virtual machine described in [SIGCOMP]. The UDVMdraft uses the same terminology. Further terminology is defined below. Compressor Entity that encodes application messages using a certain compression algorithm and keeps track of state that can be used for decompression of SigComp messages. Decompressorcompression. The decompressorcompressor is responsible for ensuring that the messages it generates can be decompressed by the remote UDVM. Decompressor The decompressor is responsible for converting a SigComp message into uncompressed data. Decompression functionality is provided by the UDVM. Compressor The compressor invokes an encoder, and keeps track of states that can be used for compression. It is responsible for supplying UDVM bytecodeDynamic compression Compression relative to messages sent prior to the remote decompressor in order forcurrent compressed data to be decompressed.message. Explicit acknowledgements Is defined as the case where anacknowledgement Acknowledgement for a state that is explicitly sent from a decompressor to its remote compressor. The acknowledgment can eitheracknowledgement should be sent standalone orpiggybacked withonto a SigComp message.message in order not to create additional security risks. Shared compression Compression relative to messages received by the local associated decompressorendpoint prior to the current compressed message. DynamicShared state A state used for shared compression Compression relative to messages sent prior to the current compressed message. Encoder Encodes data according to a (compression) algorithm into UDVM bytecode. The encoded data can be decoded by a UDVM. Application For the purposeconsists only of this document,an application is a text-based protocol software that: invokesuncompressed message. This makes the SigComp compressor and decompressor. State Data saved for retrieval by later SigComp messages. An item ofstate typically reflects the contentsindependent of the UDVM memory after decompressing a message, but state can also be created by the compressor or by the application.compression algorithm. State identifier Reference used to access an item of statea previously created by the compressor, the decompressor or the application.item of state. - state_identifier This is a reference to a state, whichshared_state_id State identifier of a compressor uses for compression.shared state. - shared_identifier This is a reference to a state, which consist only of an uncompressed message. This kindacked_state_id State identifier of a state that is necessary for efficient utilization of shared compression,acknowledged as remote compressors might use different compression algorithms. - acked_identifier This is a reference to a state, which issuccessfully saved and acknowledgedby athe decompressor. 3. Architectural View of Feedback SigComp message May containhas a compressed application message in the form of UDVM bytecode. In case of a message-based transport, such as UDP, a SigComp message corresponds to exactly one (UDP) datagram. For a stream-based transport, such as TCP, each SigComp message is separated by a 0xFFFF delimiter. Application message An uncompressed message, as provided from or to the application, which is to be compressed by the compressor. When delivered from the decompressor the data has passed through the decompression process and is referredrequest/response mechanism to as decompressed data. 3. Architectural view of feedback A SigComp endpoint mayprovide capability announcement information to its remote SigComp endpoint using the UDVM instruction END-MESSAGE. Thatfeedback between endpoints, see Figure 1. This particular functionality of SigComp is used in this document to provide support for extended operationthe mechanisms described in this document, e.g. shared compression and explicit acknowledgements. The capability announcement functionality of SigComp can be viewed as a particular type of feedback, which an endpoint provides to its remote endpoint, see Figure 1.document. +--------------------+ +--------------------+ | Endpoint 1 | | Endpoint 2 | | +--------------+ | | +--------------+ | | | Compressor 1 | | | |Decompressor 2| | | | [------------+--+--------------+--+--] * | | | +-|-------^----+ | | +--|---|-------+ | | | | | | | | | | | | | | | | | | | | | | | | | | +-|-------|----+ | | +--v---|-------+ | | | * [----+--+--------------+--+------] | | | |Decompressor 1| | | | Compressor 2 | | | +--------------+ | | +--------------+ | +--------------------+ +--------------------+ Figure 1. Architectural view ThisThe feedback functionality of SigComp is extendedused in this document to make it possibleprovide a mechanism for a SigComp endpoint to confirm which states thathave been established toby its remote SigComp endpoint during the lifetime of a SigComp session.compartment. The established state confirmations are referred to as acknowledgments. Depending on the established states this particular type of feedback may or may not be used to increase the compression efficiency. The following Sections describessections describe how the mechanism forSigComp functionality of providing the capability announcementfeedback information is used for providingto support for some ofthe extended SigCompmechanisms described in this document. Section 4 starts by describingdescribes the Statestate reference model of SigComp. Section 5 continues with a general description of SigComp extended operation mechanisms,the mechanisms and Section 6 describes the implications on basic SigComp forof some of the extended mechanisms.mechanisms on basic SigComp. 4. State reference modelReference Model A UDVM may want to save the status of its memorymemory, and this status is referred to as a state. As explained in [SIGCOMP] a state save request may or may not be granted.granted by the application. For later reference to a saved 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 a state identifier. 4.1. Overview of state referenceState Reference with dynamic compressionDynamic Compression When compressor 1 compresses a message m it uses the information corresponding to a UDVMSigComp state that its remote decompressor 2 has established and acknowledged. If compressor 1 would like to be ablewishes to use the new state for compression of later messages it must save the new state. The new state contains information from the former state and from m. When an acknowledgement is received for this new state, compressor 1 can utilize the new state in the compression process. Below is an overview of the model.model together with an example of a message flow. Saved state(s) Compressor: TheA state which is anticipatedexpected to be used for compressioncompression/decompression of later messages, and is therefore saved. Decompressor: The decompressor saves the state if it will acknowledge it.messages. Acked state(s) An acknowledgedacked state is a saved state may be usedfor compression. Acked state(s) Thewhich the compressor can only use a state(s)has received an acknowledgement, i.e. the state has been established at the remote decompressor. The compressor must only use states that are established at the remote decompressor has saved and acknowledged.decompressor, otherwise a decompression failure will occur. For this reason, acknowledgements are necessary, at least for unreliable transport. Compressor 1 Decompressor 2 +---+ +---+ | C | | D | +---+ +---+ Saved Acked | | Saved 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 | | Figure 2. Example of message flow. 5. Extended operation mechanismsMechanisms The following subsections give a general description forof the extended operation mechanisms and features, such as explicit acknowledgements and shared compression.mechanisms. 5.1. Explicit acknowledgement schemeAcknowledgement Scheme For a compressor to be able to utilize a certain state it must know that the remote decompressor has access to this state. In the case where compressed messages can be lost or misordered on the path between compressor and decompressor, some sort ofan acknowledgement scheme must be used by a decompressorto notify the remote compressor that a certain state has been established. Explicit acknowledgements can be initiated either by UDVM-code uploaded to the decompressor by the remote compressor or by the endpoint where the states have been established. These two cases will be explained in more detail in the following two sections. 5.1.1. Remote Compressor Initiated Acknowledgements This is also needed in SigComp becausethe case when e.g. compressor 1 has uploaded UDVM memory is reset after each compressed message due to security risks, and also as a requestbytecode to save a state may not be granted. A SigComp messagedecompressor 2. The UDVM bytecode will along withuse the compressed message carry a reference to which state that was used for compression ofrequested feedback field in the message. This reference isannouncement information and the state_identifier, as describedreturned feedback field in Section 2. Together with state_identifierthe SigComp message may also carry an acknowledgement, which would be the acked_identifier, see Sectionheader to obtain knowledge about established states at endpoint 2. The acknowledgementConsider Figure 3. An event flow for successful use of remote compressor initiated acknowledgements can be either standalone or piggybacked. For security reasonsas explained in SigComp it is RECOMMENDED that this particular feedback is piggybacked and not sent standalone. 5.2. Shared Compression To allow for shared compressionfollows: (1): Compressor 1 saves e.g. state(A). (2): The UDVM bytecode to initiate a compressing endpoint MUSTstate save the uncompressed version offor state(A) is either carried in the compressed message asmessage, or can be retrieved by decompressor 2 from a state.state already saved at endpoint 2. (3): As compressor 1 is the initiator of this acknowledgement it can use an arbitrary identifier to be returned to indicate that state(A) has been established. The referenceidentifier needs to consist of enough bits to avoid acknowledgement of wrong state. To avoid padding of the feedback items and for simplicity a minimum of 1 octet should be used for the identifier. The identifier is placed at the location of the requested_feedback_item [SigComp]. The END-MESSAGE instruction is used to indicate the location of the requested_feedback_item to the state handler. (4): The requested feedback data is now called returned feedback data as it is placed into the SigComp message at compressor 2. (5): The returned feedback item is carried in the SigComp message according to Figure 4: see Section 6.1 and [SIGCOMP]. (6): The returned feedback item is handled according to: Section 7 of [SIGCOMP] +--------------+ (2) +--------------+ | Compressor 1 |--------------------------->|Decompressor 2| +------^-------+ +-------^------+ | (1) (3) | +---v---+ +---v---+ |State | |State | |handler| |handler| +---^---+ +---^---+ | (6) (4) | +------v-------+ (5) +-------v------+ |Decompressor 1|<---------------------------| Compressor 2 | +--------------+ +--------------+ Figure 3. Simplified SigComp endpoints 5.1.2. Local Endpoint Initiated Acknowledgements When explicit acknowledgements are provided by an endpoint, the SigComp message will also carry acknowledgements, so-called acked_state_id: see Section 2. Consider Figure 3, an event flow for successful use of explicit endpoint initiated acknowledgements can be as follows: (1): Compressor 1 saves e.g. state(A). (2): The UDVM bytecode to initiate a state save for state(A) is either carried in the compressed message, or can be retrieved by decompressor 2 from a state already saved at endpoint 2. (3): A save state request for state(A) is passed to the state handler using the END-MESSAGE instruction. The application may then grant the state handler permission to save state(A): see [SIGCOMP]. (4): Endpoint 2 decides to acknowledge state(A) to endpoint 1. The state identifier (acked_state_id) for state(A) is placed in the SigComp message sent from compressor 2 to decompressor 1. (5): The UDVM bytecode to initiate (pass) the explicit acknowledgement to endpoint 1 is either carried in the compressed message, or can be retrieved by decompressor 1 from a state already saved at endpoint 1. (6): The acked_state_id for state(A) is passed to the state handler by placing the acked_state_id at the location of the "returned SigComp parameters" [SIGCOMP], which location is given to the state handler using the END-MESSAGE instruction. Note: When the requested feedback length is non-zero endpoint initiated acknowledgements should not be used, due to possible waste of bandwidth. When deciding to implement this mechanism one should consider whether this is worth the effort as all SigComp implementations will support the feedback mechanism and thus have the possibility to implement the mechanism of Section 5.1.1. 5.2. Shared Compression To make use of shared compression a compressing endpoint saves the uncompressed version of the compressed message as a state (shared state). As described in Chapter 2 the references to a shared state is referred to as shared_state_id. The shared state's parameters state_address and state_instruction must be set to zero. The state_retention_priority must be set to 65535, and the other state parameters are set accordingly to [SIGCOMP]. This is because different compression algorithms may be used to compress application messages traveling in different directions. The shared state is also created on a per-compartment basis, i.e. the shared state is stored in the same memory as the states created by the particular remote compressor. The choice of how to divide the state memory between "ordinary" states and shared states is an implementation decision at the compressor. Note that new shared state items must not be created unless the compressor has made enough state memory available (as decompression failure could occur if the shared_identifier, as described in Section 2. Itshared state pushed existing state out of the state memory buffer). A compressing endpoint must also indicate to itsthe remote decompressorcompressor that this compressed message's uncompressed version was saved as a state atthe compressor. If a compressing endpoint indicates that ashared compressionstate was saved, itsis available, but only if the local decompressor MUST be able tocan retrieve that particularthe shared state. The retrieval of this particularthe shared state is done accordingaccordingly to the state retrieval instructionsinstruction of the UDVM. Consider Figure 3. An event flow for successful use of shared compression can be as follows: (1): Compressor 1 saves e.g. state(M), which is the uncompressed version of the current application message to be compressed and sent. (2): The UDVM bytecode to indicate the presence of state(M) at endpoint 1 is either carried in the compressed message, or can be retrieved by decompressor 2 from a state already saved at endpoint 2. (3): The SHA-1 instruction is used at endpoint 2 to calculate the shared_state_id for state(M). The indication is passed to the state handler, by placing the shared identifier at the location of the "returned SigComp parameters" [SIGCOMP]. The location of the "returned SigComp parameters" is given to the state handler using the END-MESSAGE instruction. (4): If endpoint 2 uses shared compression, it compares the state identifier values in the "returned SigComp parameters" information with the value it has calculated for the current decompressed message received from endpoint 1. If there is a match then endpoint 2 uses the shared state together with the state it would normally use if shared compression is not supported to compress the next message. (5): The UDVM bytecode that will use the shared state (state(M)) in the decompression process at decompressor 1 is either carried in the compressed message, or can be retrieved by decompressor 1 from a state already saved at endpoint 1. 5.3. Maintaining state data across sessionState Data Across Application Sessions Usually, signaling protocols (e.g. SIP) haveemploy the concept of sessions. However, from the compression point of view, the messages sent by the same source contain redundancies beyond the session boundary. Consequently, it is natural to maintain the state data from the same source across sessions so that high performance can be achieved and maintainedmaintained, with the overhead amortized over a much longer period of time than one application session. Maintaining states across application sessions can be achieved simply by making the lifetime of a compartment longer than the time duration of a single application session. Note that the states here are referring to those stored on a per-compartment basis, not the locally available states that are stored on a global basis (i.e. not compartment specific). 5.4. Use of user-specific dictionaryUser-Specific Dictionary The concept of the user-specific dictionary is based on the followingobservation that for protocols such as SIP, a given user/device combination will produce some messages containing fields that are always populated with the same data. Take SIP as an example, capabilitiesexample. Capabilities of the SIP endpoints are communicated during session initiation, and do nottend not to change unless the device'scapabilities of the device change. Similarly, user-specificuser- specific information such as athe user's URL, a user'sname, and a user'se-mail address likely won'twill not change on a frequent basis, and will appear regularly in SIP signaling exchanges involving a specific user. Therefore, a SigComp compressor could start uploadinginclude the user- specific dictionary,user-specific dictionary as part of the initial state,messages to the decompressordecompressor, even before any time critical signaling messages are generated from a particular application .application. This enables the immediate compression/decompressionincreased compression efficiency once the messages start to flow. Obviously, the user-specific dictionary is a state item that would be good to have as a cross-session state: see Section 5.3. 5.5. Checkpoint state and rollback mechanismState The following mechanismsmechanism can be used to recover fromavoid decompression failure due to areference to a non-existnon-existent state. This may occur in three cases: a) a state (i.e.is not established at all orremote SigComp endpoint due to loss of a SigComp message; b) a state is not established due to insufficient memory; c) a state has been established but was deleted by the decompressor) or a corrupted state: 1)later due to insufficient memory. When a compressor sends a compressedSigComp message that will create a new decompressionstate on the decompressor side, it can set a CHK_PT bit in the message toindicate that the newly created state will be a checkpoint state. Astate by setting state_retention_priority [SIGCOMP] to the highest value sent by the same compressor. In addition, a checkpoint state means thatmust be explicitly acknowledged by the receiving decompressor SHOULD NOT delete it untilto the sending compressor. Consider Figure 3. An event flow for this kind of state management can be as follows: (1): Compressor 1 saves e.g. state(A), which it would like to have as a checkpoint state at decompressor 2. (2): The UDVM bytecode to indicate the state priority ([SIGCOMP] - state_retention_priority) of state(A) and initiate a state save for state(A) is explicitly instructed -- byeither carried in the compressor --compressed message, or can be retrieved by decompressor 2 from a state already saved at endpoint 2. (3): A save state request for state(A) is passed to do so. In addition,the checkpointstate MUST be explicitly acknowledged by the receiving decompressor tohandler using the sending compressor. 2) When a decompressor encounters a decompression failure as described above, it can send a rollback message to its remote compressor indicating such a failure. In addition,END-MESSAGE instruction, including the rollback message may carry a listindication of the state IDspriority. The application grants the saving of thosestate(A): see [SIGCOMP]. (4): An acknowledgement for state(A) (the checkpoint states that are currently maintained by the decompressor. Thisstate) is useful in the case whenreturned to endpoint B using one of the decompressormechanisms described in Section 5.1. Note: To avoid using a state that has to delete even checkpoint statesbeen deleted due to limited memory. When receiving suchinsufficient memory a rollback message, thecompressor MUST NOT use any state to compress subsequent messages other than those explicitly listed inmust keep track of the rollback message or ifmemory available for saving states at the listremote endpoint. The SigComp parameter state_memory_size which is empty, than thoseannounced by the SigComp feedback mechanism can be used to infer if a previous checkpoint states it stores locally and havestate has been acknowledged.deleted (by a later checkpoint state creation request) due to lack of memory. 5.6. Implicit deletion when creatingDeletion for Dictionary Update Usually a newstate consists of two parts: UDVM bytecode and dictionary. When dynamic compression is applied, new content needs to be added to the dictionary. To achievekeep an upper bound of the maximum compression efficiency,memory consumption such as in the case for a compressor may want to delete part (e.g. dictionary part)low end mobile terminal, existing content of byte bufferthe dictionary must be deleted to make room for the new content. This is especially important when implementing SigComp with limited memory (as in the caseInstead of explicitly signaling which parts of a mobile terminal). Withthe dictionary need to be deleted on a per message basis, an implicit deletion,deletion approach may be applied. Specifically, some part(s)parts of the byte bufferdictionary are chosen to be deleted according to a well definedwell-defined algorithm that is known and applied in the same way at both compressor and decompressor. For instance, the algorithm can be part of the predefined UDVM bytecode that is agreed between the two SigComp endpoints. As input into to the algorithm, one provides the total size to be deleted (e.g.number of bytes), and thebytes to be deleted. The algorithm then specifies which part(s)parts of dictionary are to be deleted. The freed room can then allow new content to be added to the byte buffer.Since the same algorithm is applied at both SigComp entities, there is no need to explicitly signal which part(s) have been deleted. In particular, when the allocated memory has been filled up, each SigComp entity, when it wants to add items of combined size S, will implicitly delete part(s) of combined size S. Sinceendpoints, there is no need for signaling, the scheme is more efficient (lower signaling overhead) and more robust (less prone to errors or losses affecting theexplicit signaling information). For example, the implicit deletionon a per message basis. This may be appliedlead to higher compression efficiency due to the entire writable UDVM memory defined by working_memory_start and working_memory_end or only some partsavoidance of the writable UDVM memory. In the latter case, it is assumed that the peer SigComp entities agreesignaling overhead. It also means more robustness as there are no signaling bit on which partsthe operation is appliedwire that are subject to and the total size of those parts.possible transmission errors/losses. 6. Implications on SigComp The extended operationsfeatures will have implicationimplications on the SigComp messages sent between the compressor and theits remote decompressor. It will also have implicationsdecompressor, and on how to interpret e.g. returned SigComp parameters [SIGCOMP]. However, except for the interface betweenmandatory bytes of the UDVM and its local decompressor functionalities.SigComp messages [SIGCOMP], the final message formats used are implementation issues. Note that an implementation that does not make use of explicit acknowledgements and/or shared compression is not effectedaffected, even if it receives this kind of feedback. The following sections described the implications due to explicit acknowledgements and shared compression.6.1. Implications on SigComp messages For theMessages To support ofthe extended operation mechanisms, shared compression and explicit acknowledgements,features, SigComp messages must be able tocarry the indications and information addressed in Section 5. For example to support shared compression and explicit acknowledgements the SigComp messages need to convey the following information: - The acked_state_id as described in Sections 5.12 and 220.127.116.11. - The basicshared_state_id as described in Sections 2 and 5.2. Figure 4, depicts the format of a SigComp message has the following format:according to: [SIGCOMP] 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 | T | len | | 1 1 1 1 1 | T | 0 | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | | | | : returned feedback item : : returned feedback item : | | | | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | | | code_len | : state_identifier (n-bytes)partial state identifier : +---+---+---+---+---+---+---+---+ | | | code_len | destination | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | | | | : remaining SigComp message : Remaining: uploaded UDVM bytecode : | | | | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | | : remaining SigComp message : | | +---+---+---+---+---+---+---+---+ Figure 3.4. Format of basica SigComp message. The contentformat of the UDVM byte codefield "remaining SigComp message" is an implementation decision. However, indecision by the case of extended operations it should conveycompressor which supplies the following information: - The shared_identifier as described in Section 2, and Section 5.2, MUST be conveyed when shared compressionUDVM bytecode. Therefore there is applied. - State identifiers of states that are acknowledged as successfully saved byno need to specify a message format to carry the decompressor, i.e. acked_identifiers.information necessary for the extended features described in this document. Figure 4,5, depicts an example of what an extended basicthe "remaining SigComp message,message" with thesupport offor shared compression and explicit acknowledgements, could look like. Note that this is only an example,example; the format is an implementation decision. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | Format according to Figure 4 | : state_identifier (n-bytes)except for the field called : | "remaining SigComp message" | "remaining SigComp message" field +---+---+---+---+---+---+---+---+ -------- | s | a | r | b |Reserved | | +---+---+---+---+---+---+---+---+ | | | | : shared_identifier (n-bytes)shared_state_id* : Present if 's' is set | | | +---+---+---+---+---+---+---+---+ | | | | : acked_identifier (n-bytes)acked_state_id* : Present if 'a' is set | | +---+---+---+---+---+---+---+---+ | Possible | : Compressed data : | | +---+---+---+---+---+---+---+---+ Figure 4. Example of SigComp message for extended operations. '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.2.2. For the explanation of (n-bytes) see [SIGCOMP]. 6.2. SigComp capability announcement format The SigComp capability announcement information mechanisms is, as explained in Section 3, used to provide the support for shared compression and explicit acknowledgements. The following format is specified in SigComp and is made available to the compressor by the UDVM instruction END-MESSAGE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDVM_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | overall_memory_size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cycles_per_bit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cycles_per_message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | id_length 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : id_value_1 : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | id_length n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || : id_value_n :+---+---+---+---+---+---+---+---+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | : reservedRest of the SigComp message : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+| v +---+---+---+---+---+---+---+---+ -------------- Figure 5. Example of SigComp capability announcement information For descriptionmessage for some of the items see [SigComp].extended features. 'r' : If set, then a state corresponding to the decompressed version of this compressed message (shared state) was saved at the compressor. * : The following Sectionlength of the shared_state_id and acked_state_id fields are of the same length as the partial state identifier. 6.2. Extended SigComp Announcement/Feedback Format This section describes how the capability announcement"returned_SigComp_parameters" [SIGCOMP] information is interpreted to provide feedback according to Section 5.1 and 5.2. 6.2.1. Extended SigComp feedback format When a SigComp message is not regarded as a capability announcement message, the END-MESSAGE instruction does not actually point to the capability announcement location but rather to a feedback location with the feedback format block as depicted in Figure 7.The id_length(s) and id_value(s) correspondspartial_state_identifiers correspond to the hash_length andhash_value for state(s)states that have been established at the remote end- point due toendpoint after received SigComp messages and may be used for compression,messages, i.e. these are acknowledgements for established states.states and may be used for compression. The 'r' bit indicatespartial_state_identifiers may also announce "global state" that an uncompressed version of the compressed message sent in this message has been saved at the remote endpoint, with the demands of Section 5.2. The 'b' bitis explained in Section 6.2.2. The format of the feedback information blocknot mapped to any particular compartment and is ofnot established upon the following form: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDVM_version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | overall_memory_size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cycles_per_bit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cycles_per_message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | id_length 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : id_value_1 : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | id_length n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : id_value_n : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |r|b| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : reserved : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7. Formatreceipt of a SigComp message. It is up to the extended feedback. Aimplementation to deduce what kind of state each partial_state_identifier refers to, e.g. an acknowledged state or a shared state. In case a SigComp message that includes state identifiers for shared states and/or acknowledged states is received by a basic SigComp implementationimplementation, these identifiers will be ignored. The I-bit of the requested feedback format is provided to switch off the list of locally available state items. An endpoint that wishes to receive shared_state_id must not recognizeset the identifier valuesI-bit to 1. The endpoint storing shared states and should not considersending the reserved field inlist of locally available states to its remote endpoint must be careful when taking the feedback location therefore it is not effected if it receives this kinddecision whether to excluded or include different types of feedback. 6.2.2. Acknowledgement optimization Considerthe following scenario, seelocally available states (i.e. shared states or states of e.g. well- known algorithms) from/to the list. 6.3. Acknowledgement Optimization If shared compression is used between two endpoints (see Figure 1. Compressor 1 sends a1) then there exists an optimization, which if implemented makes an acked_state_id in the SigComp message m, compressed with state s0, to decompressor 2. Asunnecessary: Compressor 1 supports shared compression itsaves a shared state(M), which is the uncompressed version of the current compressed message m as a state M, and(message m) to be sent. Compressor 1 also sets bit 'r','r' (see Figure 5), to signal that state Mstate(M) can be used by compressorendpoint 2 in the compression process. If decompressor_1 saves a new state, s1, using information in state s0 and m then this new state canThe acked_state_id for state(S), which was created at endpoint 2 upon the decompression of message m, may not have to be implicitly acknowledgedexplicitly placed in case compressor 2 utilizes shared compression by using state M for further compression. The implicit acknowledgement is given bythe compressed messages from compressor 2 which sets the 'b' bit andif the shared identifier. The shared identifier indicates that the state M has beenstate(M) is used for compression together with the state indicatedin the state_identifier. The 'b' bit indicatescompression process. When endpoint 1 notices that state s1 has been saved at decompressor 2. That is, the 'b' bit and theshared identifier for M indicatestate(M) is requested by decompressor 1, it implicitly knows that the state usedstate(S) was created at endpoint 2. This follows since: * Compressor 1 has instructed decompressor 2 to compress m together with the actual message m,save state(S). * The indication of shared state(M) would never have been saved asreceived by compressor 2 if state(S) had not been successfully saved, because if a new state (s1) at decompressor 2. This avoids the acked_identifier forstate s1 to be present in the SigComp message. Also,save request is denied then the compressor that setscorresponding announcement information is discarded by the 'r' bit should also holdstate handler. Note: Endpoint 1's state handler must maintain a mapping between the state Mstate(M) and state s1.state(S) for this optimization to work. Note: The only state thatacknowledge by this feature acknowledges,acknowledges is the state that was created by combining the state used for compression of the sharedmessage and the sharedmessage itself. For any other case the acked_identifieracked_state_id has to be used. Note: There is a possibility that state(S) is discarded due to lack of state memory even though the announcement information is successfully forwarded. This possibility must be taken into account (otherwise a decompression failure may occur), and can be so by using the SigComp parameter state_memory_size which is announced by the SigComp feedback mechanism. The endpoint can use this parameter to infer if a state creation request has failed due to lack of memory. 7. Security considerationsConsiderations The features in this document are believed not to add any additionalsecurity risks to the ones mentioned in [SIGCOMP]. 8. IANA considerations [Editor's note: TBW]Considerations This document does not require any IANA involvement. 9. Acknowledgements Thanks to Carsten Bormann (firstname.lastname@example.org)Bormann, Christopher Clanton (email@example.com)Clanton, Miguel Garcia (Miguel.A.Garcia@ericsson.com)Garcia, Lars-Erik Jonsson (firstname.lastname@example.org)Jonsson, Khiem Le (email@example.com)Le, Mats Nordberg (firstname.lastname@example.org)Nordberg, Jonathan Rosenberg (email@example.com)and Krister Svanbro (firstname.lastname@example.org)for valuable input and review.input. 10. Authors' addressesAddresses Hans Hannu Box 920 Ericsson AB SE-971 28 Lulea, Sweden Phone: +46 920 20 21 84 Fax: +46 920 20 20 99E-Mail: email@example.com Jan Christoffersson Box 920 Ericsson AB SE-971 28 Lulea, Sweden Phone: +46 920 20 28 40 Fax: +46 920 20 20 99E-Mail: firstname.lastname@example.org Stefan Forsgren Phone: +46 920 20 23 39 Fax: +46 920 20 20 99E-Mail: email@example.com Box 920 Ericsson Erisoft AB SE-971 28 Lulea, Swedenstefan.firstname.lastname@example.org Ka Cheong Leung Phone: +1 972 374-0630 Fax: +1 972 894-4589E-mail: email@example.com@eee.hku.hk Zhigang Liu Phone: +1 972 894-5935 Fax: +1 972 894-4589 E-Mail: firstname.lastname@example.orgNokia Research Center 6000 Connection Drive Irving, TX 75039, USA Phone: +1 972 894-5935 E-Mail: email@example.com Richard Price Phone: +44 1794 833681 E-mail: firstname.lastname@example.orgRoke Manor Research Ltd Romsey, Hants, SO51 0ZN0ZN, United Kingdom Phone: +44 1794 833681 E-mail: email@example.com 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 [SIP] M. Handley et. al., SIP: Session Initiation Protocol, RFC 2543, Internet Engineering Task Force, March 1999 [SIGCOMP] H. HannuR. Price et. al., Signaling Compression (SigComp), Internet Draft (work in progress), MarchMay 2002. <draft-ietf-rohc-sigcomp-05.txt> Appendix A. 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. - February 15, 2002, version 01 Second version. Updated to reflect the changes made in SigComp-04. - March 1, 2002, version 02 Third version. Updated to reflect the changes made in [SIGCOMP].<draft-ietf-rohc-sigcomp-06.txt> This Internet-Draft expires in SeptemberNovember 03, 2002.