Network Working Group H. Hannu
Request for Comments: 3321 J. Christoffersson
Category: Informational Ericsson
S. Forsgren
K.-C. Leung
Texas Tech University
Z. Liu
Nokia
R. Price
Siemens/Roke Manor
January 2003
Network Working Group H. Hannu
Request for Comments: 3321 J. Christoffersson
Category: Informational Ericsson
S. Forsgren
K.-C. Leung
Texas Tech University
Z. Liu
Nokia
R. Price
Siemens/Roke Manor
January 2003
Signaling Compression (SigComp) - Extended Operations
信令压缩（SigComp）-扩展操作
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes how to implement certain mechanisms in Signaling Compression (SigComp), RFC 3320, which can significantly improve the compression efficiency compared to using simple per-message compression.
本文档描述了如何在信令压缩（SigComp）RFC3320中实现某些机制，与使用简单的每消息压缩相比，RFC3320可以显著提高压缩效率。
SigComp uses a Universal Decompressor Virtual Machine (UDVM) for decompression, and the mechanisms described in this document are possible to implement using the UDVM instructions defined in RFC 3320.
SigComp使用通用解压器虚拟机（UDVM）进行解压，本文档中描述的机制可以使用RFC3320中定义的UDVM指令实现。
Table of Contents
目录
1. Introduction..................................................2
2. Terminology...................................................3
3. Architectural View of Feedback................................4
4. State Reference Model.........................................5
5. Extended Mechanisms...........................................6
6. Implications on SigComp......................................13
7. Security Considerations......................................17
8. IANA Considerations..........................................17
9. Acknowledgements.............................................17
10. Intellectual Property Right Considerations...................17
11. References...................................................17
12. Authors' Addresses...........................................18
13. Full Copyright Statement.....................................19
1. Introduction..................................................2
2. Terminology...................................................3
3. Architectural View of Feedback................................4
4. State Reference Model.........................................5
5. Extended Mechanisms...........................................6
6. Implications on SigComp......................................13
7. Security Considerations......................................17
8. IANA Considerations..........................................17
9. Acknowledgements.............................................17
10. Intellectual Property Right Considerations...................17
11. References...................................................17
12. Authors' Addresses...........................................18
13. Full Copyright Statement.....................................19
This document describes how to implement mechanisms with [SIGCOMP] to significantly improve the compression efficiency compared to per-message compression.
本文档描述了如何使用[SIGCOMP]实现机制，以显著提高与每条消息压缩相比的压缩效率。
One such mechanism is to use previously sent messages in the SigComp 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 acknowledgement.
其中一种机制是在SigComp压缩过程中使用以前发送的消息，称为动态压缩。为了利用来自先前发送的消息的信息，压缩器必须获得关于这些消息的接收的知识。对于可靠的传输，如TCP，这是有保证的。然而，对于不可靠的传输，SigComp协议本身可用于提供此类功能。该功能在本文档中描述，称为明确确认。
Another mechanism that will improve the compression efficiency of SigComp, especially when SigComp is applied to protocols that are of request/response type, is shared compression. This involves using received messages in the SigComp compression process. In particular the compression of the first few messages will gain from shared compression. Shared compression is described in this document.
另一种提高SigComp压缩效率的机制是共享压缩，特别是当SigComp应用于请求/响应类型的协议时。这涉及在SigComp压缩过程中使用接收到的消息。特别是前几条消息的压缩将从共享压缩中获益。本文档介绍了共享压缩。
For better understanding of this document the reader should be familiar with the concept of [SIGCOMP].
为了更好地理解本文件，读者应熟悉[SIGCOMP]的概念。
The reader should consult [SIGCOMP] for definitions of terminology, since this document uses the same terminology. Further terminology is defined below.
读者应参考[SIGCOMP]了解术语的定义，因为本文件使用相同的术语。进一步的术语定义如下。
Compressor
压缩机
Entity that encodes application messages using a certain compression algorithm and keeps track of state that can be used for compression. The compressor is responsible for ensuring that the messages it generates can be decompressed by the remote UDVM.
使用某种压缩算法对应用程序消息进行编码并跟踪可用于压缩的状态的实体。压缩器负责确保远程UDVM可以对其生成的消息进行解压缩。
Decompressor
减压器
The decompressor is responsible for converting a SigComp message into uncompressed data. Decompression functionality is provided by the UDVM.
解压器负责将SigComp消息转换为未压缩的数据。解压功能由UDVM提供。
Dynamic compression
动态压缩
Compression relative to messages sent prior to the current compressed message.
相对于当前压缩消息之前发送的消息的压缩。
Explicit acknowledgement
明确承认
Acknowledgement for a state. The acknowledgment is explicitly sent from a decompressor to its remote compressor. The acknowledgement should be piggybacked onto a SigComp message in order not to create additional security risks.
对国家的承认。确认从解压器显式发送到远程压缩器。应将确认信息附加到SigComp消息上，以免产生额外的安全风险。
Shared compression
共享压缩
Compression relative to messages received by the local endpoint prior to the current compressed message.
相对于本地端点在当前压缩消息之前接收的消息的压缩。
Shared state
共享状态
A state used for shared compression consists only of an uncompressed message. This makes the state independent of the compression algorithm.
用于共享压缩的状态仅由未压缩的消息组成。这使得状态独立于压缩算法。
State identifier
状态标识符
Reference used to access a previously created item of state.
用于访问以前创建的状态项的引用。
- shared_state_id
- 共享\u状态\u id
State identifier of a shared state.
共享状态的状态标识符。
- acked_state_id
- 已确认的状态id
State identifier of a state that is acknowledged as successfully saved by the decompressor.
解压缩程序确认已成功保存的状态的状态标识符。
SigComp has a request/response mechanism to provide feedback between endpoints, see Figure 1. This particular functionality of SigComp is used in this document to provide support for the mechanisms described in this document.
SigComp有一个请求/响应机制来提供端点之间的反馈，见图1。SigComp的这一特殊功能在本文档中用于为本文档中描述的机制提供支持。
+--------------------+ +--------------------+
| Endpoint 1 | | Endpoint 2 |
| +--------------+ | | +--------------+ |
| | Compressor 1 | | | |Decompressor 2| |
| | [------------+--+--------------+--+--] * | |
| +-|-------^----+ | | +--|---|-------+ |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| +-|-------|----+ | | +--v---|-------+ |
| | * [----+--+--------------+--+------] | |
| |Decompressor 1| | | | Compressor 2 | |
| +--------------+ | | +--------------+ |
+--------------------+ +--------------------+
+--------------------+ +--------------------+
| Endpoint 1 | | Endpoint 2 |
| +--------------+ | | +--------------+ |
| | Compressor 1 | | | |Decompressor 2| |
| | [------------+--+--------------+--+--] * | |
| +-|-------^----+ | | +--|---|-------+ |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| +-|-------|----+ | | +--v---|-------+ |
| | * [----+--+--------------+--+------] | |
| |Decompressor 1| | | | Compressor 2 | |
| +--------------+ | | +--------------+ |
+--------------------+ +--------------------+
Figure 1. Architectural view
图1。建筑视图
The feedback functionality of SigComp is used in this document to provide a mechanism for a SigComp endpoint to confirm which states have been established by its remote SigComp endpoint during the lifetime of a SigComp 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.
本文件中使用了SigComp的反馈功能，为SigComp端点提供了一种机制，以确认在SigComp隔间的使用寿命期间，远程SigComp端点已建立了哪些状态。已建立的状态确认称为确认。根据已建立的状态，这种特定类型的反馈可用于或不用于提高压缩效率。
The following sections describe how the SigComp functionality of providing feedback information is used to support the mechanisms described in this document. Section 4 describes the state reference model of SigComp. Section 5 continues with a general description of the mechanisms and Section 6 describes the implications of some of the mechanisms on basic SigComp.
以下各节描述了如何使用SigComp提供反馈信息的功能来支持本文档中描述的机制。第4节描述了SigComp的状态参考模型。第5节继续对机制进行一般性描述，第6节描述了一些机制对基本SigComp的影响。
A UDVM may want to save the status of its memory, and this status is referred to as a state. As explained in [SIGCOMP] a state save request may or may not be 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.
UDVM可能希望保存其内存的状态，此状态称为状态。如[SIGCOMP]中所述，状态保存请求可以由应用程序批准，也可以不批准。对于以后对已保存状态的引用，例如，如果要使用此状态加载UDVM，则需要引用来定位特定状态。此引用称为状态标识符。
When compressor 1 compresses a message m it uses the information corresponding to a SigComp state that its remote decompressor 2 has established and acknowledged. If compressor 1 wishes 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 together with an example of a message flow.
当压缩器1压缩消息m时，它使用与其远程解压缩器2已建立和确认的SigComp状态相对应的信息。如果压缩器1希望使用新状态压缩以后的消息，则必须保存新状态。新状态包含来自前状态和m的信息。当接收到此新状态的确认时，压缩器1可以在压缩过程中利用该新状态。下面是该模型的概述以及消息流的示例。
Saved state(s)
已保存状态
A state which is expected to be used for compression/decompression of later messages.
预期用于以后消息的压缩/解压缩的状态。
Acked state(s)
已确认状态
An acked state is a saved state for which the compressor 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, otherwise a decompression failure will occur. For this reason, acknowledgements are necessary, at least for unreliable transport.
确认状态是压缩机已接收到确认的保存状态，即，该状态已在远程解压缩器处建立。压缩机必须仅使用远程解压缩器上建立的状态，否则将发生解压缩故障。因此，至少对于不可靠的传输，确认是必要的。
Compressor 1 Decompressor 2
+---+ +---+
| C | | D |
+---+ +---+
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 | |
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 for dynamic compression
图2。用于动态压缩的消息流示例
Legend: Message 1 compressed making use of state s0 is denoted m1(s0). The notation s1=s0+m1 means that state s1 is created using information from state s0 and message m1. ack(s1) means that the creation of state s1 is acknowledged through piggybacking on a message traveling in the reverse direction (which is not shown in the figure).
图例：利用状态s0压缩的消息1表示为m1（s0）。符号s1=s0+m1表示使用来自状态s0和消息m1的信息创建状态s1。ack（s1）表示状态s1的创建是通过对反向（图中未显示）传输的消息进行背载来确认的。
The following subsections give a general description of the extended mechanisms.
以下小节给出了扩展机制的一般说明。
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, an acknowledgement scheme must be used to 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.
显式确认可以由远程压缩器上载到解压器的UDVM代码启动，也可以由已建立状态的端点启动。这两种情况将在以下两节中进行更详细的解释。
This is the case when e.g., compressor 1 has uploaded UDVM bytecode to decompressor 2. The UDVM bytecode will use the requested feedback field in the announcement information and the returned feedback field in the SigComp header to obtain knowledge about established states at endpoint 2.
例如，当压缩器1已将UDVM字节码上载到解压缩器2时，就是这种情况。UDVM字节码将使用公告信息中的请求反馈字段和SigComp头中的返回反馈字段来获取关于端点2处已建立状态的信息。
Consider Figure 3. An event flow for successful use of remote compressor initiated acknowledgements can be as follows:
请考虑图3。成功使用远程压缩机启动确认的事件流如下所示：
(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): 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 identifier 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]
（1） ：压缩机1保存例如状态（A）。（2） ：为状态（a）启动状态保存的UDVM字节码要么在压缩消息中携带，要么可由解压缩器2从端点2已保存的状态中检索。（3） ：由于压缩器1是此确认的发起方，因此它可以使用要返回的任意标识符来指示已建立状态（A）。标识符需要包含足够的位，以避免确认错误的状态。为避免对反馈项进行填充，并为简单起见，标识符至少应使用1个八位字节。标识符放置在请求的反馈项[SIGCOMP]的位置。结束消息指令用于向状态处理程序指示请求的\u反馈\u项的位置。（4） ：请求的反馈数据现在称为返回的反馈数据，因为它被放入压缩机2的SigComp消息中。（5） ：返回的反馈项根据图4在SigComp消息中携带：参见第6.1节和[SigComp]。（6） ：根据[SIGCOMP]第7节处理返回的反馈项
+--------------+ (2) +--------------+
| Compressor 1 |--------------------------->|Decompressor 2|
+------^-------+ +-------^------+
| (1) (3) |
+---v---+ +---v---+
|State | |State |
|handler| |handler|
+---^---+ +---^---+
| (6) (4) |
+------v-------+ (5) +-------v------+
|Decompressor 1|<---------------------------| Compressor 2 |
+--------------+ +--------------+
+--------------+ (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
图3。简化的SigComp端点
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:
当端点提供明确的确认时，SigComp消息也将携带确认，即所谓的确认状态id：参见第2节。考虑图3，用于成功使用显式端点发起确认的事件流可以如下：
(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], whose location is given to the state handler using the END-MESSAGE instruction.
（1） ：压缩机1保存例如状态（A）。（2） ：为状态（a）启动状态保存的UDVM字节码要么在压缩消息中携带，要么可由解压缩器2从端点2已保存的状态中检索。（3） ：使用结束消息指令将状态（A）的保存状态请求传递给状态处理程序。然后，应用程序可以授予状态处理程序保存状态（A）的权限：请参阅[SIGCOMP]。（4） ：端点2决定向端点1确认状态（A）。状态（A）的状态标识符（acked_state_id）位于从压缩机2发送到解压缩器1的SigComp消息中。（5） ：用于启动（传递）对端点1的显式确认的UDVM字节码要么包含在压缩消息中，要么可由解压缩器1从端点1上已保存的状态中检索。（6） ：状态（A）的已确认状态标识通过将已确认状态标识放置在“返回的SigComp参数”[SigComp]的位置传递给状态处理程序，该参数的位置使用结束消息指令提供给状态处理程序。
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.
注意：当请求的反馈长度为非零时，由于可能浪费带宽，不应使用端点发起的确认。当决定实现这一机制时，人们应该考虑这是否值得努力，因为所有的SigCOMP实现都将支持反馈机制，从而有可能实现第5.1.1节的机制。
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 Section 2 the reference 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 according 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
要使用共享压缩，压缩端点将压缩消息的未压缩版本保存为状态（共享状态）。如第2节所述，对共享状态的引用称为共享_state_id。共享状态的参数state_address和state_指令必须设置为零。state_retention_priority必须设置为65535，其他状态参数根据[SIGCOMP]设置。这是因为可以使用不同的压缩算法来压缩向不同方向传输的应用程序消息。共享状态也以每个隔室为基础创建，即，共享状态存储在与特定遥控器创建的状态相同的内存中
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 state pushed existing state out of the state memory buffer).
压缩机。选择如何在“普通”状态和共享状态之间划分状态内存是压缩器的实现决策。请注意，除非压缩器提供了足够的状态内存，否则不得创建新的共享状态项（因为如果共享状态将现有状态从状态内存缓冲区中推出，则可能会发生解压缩失败）。
A compressing endpoint must also indicate to the remote compressor that the shared state is available, but only if the local decompressor can retrieve the shared state. The retrieval of the shared state is done according to the state retrieval instruction of the UDVM.
压缩端点还必须向远程压缩器指示共享状态可用，但前提是本地解压缩程序可以检索共享状态。根据UDVM的状态检索指令检索共享状态。
Consider Figure 3. An event flow for successful use of shared compression can be as follows:
请考虑图3。成功使用共享压缩的事件流可以如下所示：
(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.
（1） ：压缩器1保存状态（M），即要压缩和发送的当前应用程序消息的未压缩版本。（2） ：用于指示端点1处存在状态（M）的UDVM字节码要么包含在压缩消息中，要么可由解压缩器2从端点2处已保存的状态中检索。（3） ：SHA-1指令在端点2处用于计算状态（M）的共享状态id。通过将共享标识符放置在“返回的SigComp参数”[SigComp]的位置，将指示传递给状态处理程序。使用结束消息指令将“返回的SigComp参数”的位置提供给状态处理程序。（4） ：如果端点2使用共享压缩，它会将“返回的SigComp参数”信息中的状态标识符值与为从端点1接收的当前解压缩消息计算的值进行比较。如果存在匹配项，那么端点2将使用共享状态以及在不支持共享压缩时通常使用的状态来压缩下一条消息。（5） ：将在解压缩程序1的解压缩过程中使用共享状态（状态（M））的UDVM字节码要么在压缩消息中携带，要么可由解压缩程序1从端点1已保存的状态中检索。
Usually, signaling protocols (e.g., SIP) employ 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
通常，信令协议（例如SIP）采用会话的概念。但是，从压缩的角度来看，由同一源发送的消息包含超出会话边界的冗余。因此，跨会话维护来自同一源的状态数据是很自然的，这样可以实现高性能
achieved and maintained, 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).
跨应用程序会话维护状态可以简单地通过使分区的生存期长于单个应用程序会话的持续时间来实现。请注意，此处的状态是指存储在每个隔间基础上的状态，而不是存储在全局基础上的本地可用状态（即，非特定隔间）。
The concept of the user-specific dictionary is based on the observation 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.
特定于用户的字典的概念是基于这样的观察：对于SIP等协议，给定的用户/设备组合将产生一些包含始终填充相同数据的字段的消息。
Take SIP as an example. Capabilities of the SIP endpoints are communicated during session initiation, and tend not to change unless the capabilities of the device change. Similarly, user-specific information such as the user's URL, name, and e-mail address will likely not change on a frequent basis, and will appear regularly in SIP signaling exchanges involving a specific user.
以SIP为例。SIP端点的功能在会话启动期间进行通信，除非设备的功能发生变化，否则不会发生变化。类似地，特定于用户的信息，例如用户的URL、名称和电子邮件地址，可能不会经常更改，并且会定期出现在涉及特定用户的SIP信令交换中。
Therefore, a SigComp compressor could include the user-specific dictionary as part of the initial messages to the decompressor, even before any time critical signaling messages are generated from a particular application. This enables an increase in compression efficiency once the messages start to flow.
因此，SigComp压缩器甚至可以在从特定应用生成任何时间关键的信令消息之前，将用户特定的字典作为到解压缩器的初始消息的一部分。一旦消息开始流动，这将提高压缩效率。
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.3节。
The following mechanism can be used to avoid decompression failure due to reference to a non-existent state. This may occur in three cases: a) a state is not established at the remote SigComp endpoint due to the loss of a SigComp message; b) a state is not established due to insufficient memory; c) a state has been established but was deleted later due to insufficient memory.
以下机制可用于避免由于引用不存在的状态而导致解压缩失败。这可能发生在三种情况下：a）由于SigComp消息丢失，远程SigComp端点未建立状态；b） 由于内存不足，未建立状态；c） 已建立状态，但后来由于内存不足而被删除。
When a compressor sends a SigComp message that will create a new state on the decompressor side, it can indicate that the newly created state will be a checkpoint state by setting state_retention_priority [SIGCOMP] to the highest value sent by the same compressor. In addition, a checkpoint state must be explicitly acknowledged by the receiving decompressor to the sending compressor.
当压缩器发送将在解压缩器端创建新状态的SigComp消息时，它可以通过将state_retention_priority[SigComp]设置为同一压缩器发送的最高值来指示新创建的状态将是检查点状态。此外，检查点状态必须由接收解压缩程序向发送压缩程序明确确认。
Consider Figure 3. An event flow for this kind of state management can be as follows:
请考虑图3。这种状态管理的事件流可以如下所示：
(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 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, including the indication of the state priority. The application grants the saving of state(A): see [SIGCOMP]. (4): An acknowledgement for state(A) (the checkpoint state) is returned to endpoint 2 using one of the mechanisms described in Section 5.1.
（1） ：压缩器1将状态（A）保存为解压器2的检查点状态。（2） ：UDVM字节码用于指示状态（A）的状态优先级（[SIGCOMP]状态\保留\优先级）并为状态（A）启动状态保存，它要么在压缩消息中携带，要么可由解压缩器2从端点2上已保存的状态中检索。（3） ：使用结束消息指令（包括状态优先级指示）将状态（A）的保存状态请求传递给状态处理程序。应用程序授予保存状态（A）：请参阅[SIGCOMP]。（4） ：使用第5.1节中描述的机制之一，将状态（A）（检查点状态）的确认返回给端点2。
Note: To avoid using a state that has been deleted due to insufficient memory a compressor must keep track of the memory available for saving states at the remote endpoint. The SigComp parameter state_memory_size which is announced by the SigComp feedback mechanism can be used to infer if a previous checkpoint state has been deleted (by a later checkpoint state creation request) due to lack of memory.
注意：为了避免使用由于内存不足而被删除的状态，压缩器必须跟踪可用于保存远程端点状态的内存。SigComp反馈机制宣布的SigComp参数state_memory_size可用于推断是否由于内存不足而删除了先前的检查点状态（通过稍后的检查点状态创建请求）。
Usually a state consists of two parts: UDVM bytecode and dictionary. When dynamic compression is applied, new content needs to be added to the dictionary. To keep an upper bound of the memory consumption such as in the case for a low end mobile terminal, existing content of the dictionary must be deleted to make room for the new content.
通常一个状态由两部分组成：UDVM字节码和字典。应用动态压缩时，需要将新内容添加到字典中。为了保持内存消耗的上限，例如在低端移动终端的情况下，必须删除词典的现有内容，以便为新内容腾出空间。
Instead of explicitly signaling which parts of the dictionary need to be deleted on a per message basis, an implicit deletion approach may be applied. Specifically, some parts of the dictionary are chosen to be deleted according to a well-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 to the algorithm, one provides the total number of bytes to be deleted. The algorithm then specifies which parts of the dictionary are to be deleted. Since the same algorithm is applied at both SigComp endpoints, there is no need for explicit signaling on a per message basis. This may lead to higher compression efficiency due to the avoidance of
可以应用隐式删除方法，而不是在每条消息的基础上明确表示需要删除字典的哪些部分。具体地说，字典的某些部分是根据一个定义良好的算法选择删除的，该算法在压缩器和解压器中都以相同的方式应用。例如，该算法可以是两个SigComp端点之间约定的预定义UDVM字节码的一部分。作为算法的输入，提供要删除的总字节数。然后，该算法指定要删除词典的哪些部分。由于相同的算法应用于两个SigComp端点，因此不需要基于每条消息的显式信令。由于避免了压缩，这可能导致更高的压缩效率
signaling overhead. It also means more robustness as there are no signaling bits on the wire that are subject to possible transmission errors/losses.
信令开销。这也意味着更具鲁棒性，因为导线上没有可能发生传输错误/丢失的信令位。
The extended features will have implications on the SigComp messages sent between the compressor and its remote decompressor, and on how to interpret e.g., returned SigComp parameters [SIGCOMP]. However, except for the mandatory bytes of the 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 affected, even if it receives this kind of feedback.
扩展功能将影响压缩机与其远程解压缩器之间发送的SigComp消息，以及如何解释返回的SigComp参数[SigComp]。但是，除了SigComp消息[SigComp]的强制字节外，使用的最终消息格式是实现问题。请注意，不使用显式确认和/或共享压缩的实现不会受到影响，即使它收到此类反馈。
To support the extended features, SigComp messages must carry 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:
为支持扩展功能，SigComp信息必须包含第5节中所述的指示和信息。例如，为了支持共享压缩和显式确认，SigComp消息需要传递以下信息：
- The acked_state_id as described in Sections 2 and 5.1. - The shared_state_id as described in Sections 2 and 5.2.
- 第2节和第5.1节所述的确认状态id。-第2节和第5.2节所述的共享状态id。
Figure 4 depicts the format of a SigComp message according to [SIGCOMP]:
图4根据[SigComp]描述了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 |
: partial state identifier : +---+---+---+---+---+---+---+---+
| | | code_len | destination |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: remaining SigComp message : : uploaded UDVM bytecode :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| |
: remaining SigComp message :
| |
+---+---+---+---+---+---+---+---+
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 |
: partial state identifier : +---+---+---+---+---+---+---+---+
| | | code_len | destination |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: remaining SigComp message : : uploaded UDVM bytecode :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| |
: remaining SigComp message :
| |
+---+---+---+---+---+---+---+---+
Figure 4. Format of a SigComp message
图4。SigComp消息的格式
The format of the field "remaining SigComp message" is an implementation decision by the compressor which supplies the UDVM bytecode. Therefore there is no need to specify a message format to carry the information necessary for the extended features described in this document.
字段“剩余SigComp消息”的格式是提供UDVM字节码的压缩器的实现决定。因此，无需指定携带本文档中所述扩展功能所需信息的消息格式。
Figure 5 depicts an example of what the "remaining SigComp message" with support for shared compression and explicit acknowledgements, could look like. Note that this is only an example; the format is an implementation decision.
图5描述了支持共享压缩和显式确认的“剩余SigComp消息”的示例。请注意，这只是一个示例；格式是一项实施决策。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Format according to Figure 4 |
: except for the field called :
| "remaining SigComp message" | "remaining SigComp message" field
+---+---+---+---+---+---+---+---+ --------
| s | a | r | Reserved | |
+---+---+---+---+---+---+---+---+ |
| | |
: shared_state_id* : Present if 's' is set
| | |
+---+---+---+---+---+---+---+---+ |
| | |
: acked_state_id* : Present if 'a' is set
| | |
+---+---+---+---+---+---+---+---+ |
| | |
: Rest of the SigComp message : |
| | v
+---+---+---+---+---+---+---+---+ --------------
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Format according to Figure 4 |
: except for the field called :
| "remaining SigComp message" | "remaining SigComp message" field
+---+---+---+---+---+---+---+---+ --------
| s | a | r | Reserved | |
+---+---+---+---+---+---+---+---+ |
| | |
: shared_state_id* : Present if 's' is set
| | |
+---+---+---+---+---+---+---+---+ |
| | |
: acked_state_id* : Present if 'a' is set
| | |
+---+---+---+---+---+---+---+---+ |
| | |
: Rest of the SigComp message : |
| | v
+---+---+---+---+---+---+---+---+ --------------
Figure 5. Example of SigComp message for some of the extended features.
图5。一些扩展功能的SigComp消息示例。
'r' : If set, then a state corresponding to the decompressed version of this compressed message (shared state) was saved at the compressor. * : The length of the shared_state_id and acked_state_id fields are of the same length as the partial state identifier.
“r”：如果已设置，则与此压缩消息的解压缩版本（共享状态）相对应的状态保存在压缩器中。*：共享_state_id和已确认_state_id字段的长度与部分状态标识符的长度相同。
This section describes how the "returned_SigComp_parameters" [SIGCOMP] information is interpreted to provide feedback according to Section 5.1 and 5.2.
本节描述如何根据第5.1节和第5.2节解释“返回的SigComp参数”[SigComp]信息以提供反馈。
The partial_state_identifiers correspond to the hash_value for states that have been established at the remote endpoint after the reception of SigComp messages, i.e., these are acknowledgements for established states and may be used for compression. The partial_state_identifiers may also announce "global state" that is not mapped to any particular compartment and is not established upon the receipt of a SigComp message.
部分_状态_标识符对应于在接收到SigComp消息之后在远程端点建立的状态的散列值，即，这些是对建立的状态的确认，并且可以用于压缩。部分_状态_标识符还可以宣布未映射到任何特定隔室且在接收到SigComp消息时未建立的“全局状态”。
It is up to the implementation 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 implementation, these identifiers will be ignored.
由实现来推断每个部分状态标识符所指的状态类型，例如，确认状态或共享状态。如果基本SigComp实现接收到包含共享状态和/或确认状态的状态标识符的SigComp消息，则将忽略这些标识符。
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 set the I-bit to 1. The endpoint storing shared states and sending the list of locally available states to its remote endpoint must be careful when taking the decision whether to exclude or include different types of the locally available states (i.e., shared states or states of e.g., well-known algorithms) from/to the list.
所请求反馈格式的I位用于关闭本地可用状态项的列表。希望接收共享_state_id的端点不得将I位设置为1。存储共享状态并将本地可用状态列表发送到远程端点的端点在决定是否从列表中排除或包括不同类型的本地可用状态（即共享状态或已知算法的状态）时必须小心。
If shared compression is used between two endpoints (see Figure 1) then there exists an optimization, which, if implemented, makes an acked_state_id in the SigComp message unnecessary:
如果在两个端点之间使用共享压缩（参见图1），则存在一个优化，如果实现了该优化，则SigComp消息中的acked_state_id就不必要了：
Compressor 1 saves a shared state(M), which is the uncompressed version of the current compressed message (message m) to be sent. Compressor 1 also sets bit 'r' (see Figure 5), to signal that state(M) can be used by endpoint 2 in the compression process. The acked_state_id for state(S), which was created at endpoint 2 upon the decompression of message m, may not have to be explicitly placed in the compressed messages from compressor 2 if the shared state(M) is used in the compression process.
压缩器1保存共享状态（M），即要发送的当前压缩消息（消息M）的未压缩版本。压缩器1还设置位“r”（见图5），以表示端点2可以在压缩过程中使用状态（M）。如果在压缩过程中使用共享状态（m），则在消息m解压缩时在端点2处创建的状态的已确认_state_id可能不必显式放置在来自压缩器2的压缩消息中。
When endpoint 1 notices that shared state(M) is requested by decompressor 1, it implicitly knows that state(S) was created at endpoint 2. This follows since:
当端点1注意到解压器1请求共享状态（M）时，它隐式地知道状态是在端点2创建的。这是因为：
* Compressor 1 has instructed decompressor 2 to save state(S). * The indication of shared state(M) would never have been received by compressor 2 if state(S) had not been successfully saved, because if a state save request is denied then the corresponding announcement information is discarded by the state handler.
* 压缩机1已指示减压器2保存状态。*如果未成功保存状态，则压缩器2将永远不会收到共享状态（M）的指示，因为如果状态保存请求被拒绝，则状态处理程序将丢弃相应的公告信息。
Note: Endpoint 1's state handler must maintain a mapping between state(M) and state(S) for this optimization to work.
注意：端点1的状态处理程序必须维护状态（M）和状态（s）之间的映射，才能使此优化工作。
Note: The only state that is acknowledged by this feature is the state that was created by combining the state used for compression of the message and the message itself. For any other case the acked_state_id has to be used.
注意：此功能确认的唯一状态是通过组合用于压缩消息的状态和消息本身而创建的状态。对于任何其他情况，必须使用已确认的状态id。
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); this can be done 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.
注意：即使已成功转发公告信息，也可能由于缺少状态内存而丢弃状态。必须考虑这种可能性（否则可能发生减压失败）；这可以通过使用SigComp反馈机制宣布的SigComp参数state_memory_size来实现。端点可以使用此参数推断状态创建请求是否由于内存不足而失败。
The features in this document are believed not to add any security risks to the ones mentioned in [SIGCOMP].
本文档中的功能被认为不会给[SIGCOMP]中提到的功能增加任何安全风险。
This document does not require any IANA involvement.
本文件不需要IANA的参与。
Thanks to Carsten Bormann, Christopher Clanton, Miguel Garcia, Lars-Erik Jonsson, Khiem Le, Mats Nordberg, Jonathan Rosenberg and Krister Svanbro for valuable input.
感谢Carsten Bormann、Christopher Clanton、Miguel Garcia、Lars Erik Jonsson、Khiem Le、Mats Nordberg、Jonathan Rosenberg和Krister Svanbro的宝贵意见。
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.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[SIP]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[SIGCOMP] Price R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z. and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.
[SIGCOMP]Price R.，Bormann，C.，Christofferson，J.，Hannu，H.，Liu，Z.和J.Rosenberg，“信号压缩（SIGCOMP）”，RFC 3320，2003年1月。
Hans Hannu Box 920 Ericsson AB SE-971 28 Lulea, Sweden
Hans Hannu信箱920爱立信AB SE-971 28瑞典卢利亚
Phone: +46 920 20 21 84
EMail: hans.hannu@epl.ericsson.se
Phone: +46 920 20 21 84
EMail: hans.hannu@epl.ericsson.se
Jan Christoffersson Box 920 Ericsson AB SE-971 28 Lulea, Sweden
Jan Christofferson信箱920爱立信AB SE-971 28瑞典卢利亚
Phone: +46 920 20 28 40
EMail: jan.christoffersson@epl.ericsson.se
Phone: +46 920 20 28 40
EMail: jan.christoffersson@epl.ericsson.se
Stefan Forsgren
斯特凡·福斯格伦
EMail: StefanForsgren@alvishagglunds.se
EMail: StefanForsgren@alvishagglunds.se
Ka-Cheong Leung Department of Computer Science Texas Tech University Lubbock, TX 79409-3104 United States of America
德克萨斯理工大学计算机科学系梁家昌美国德克萨斯州卢伯克79409-3104
Phone: +1 806 742-3527
EMail: kcleung@cs.ttu.edu
Phone: +1 806 742-3527
EMail: kcleung@cs.ttu.edu
Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA
刘志刚诺基亚研究中心，美国德克萨斯州欧文连接大道6000号，邮编75039
Phone: +1 972 894-5935
EMail: zhigang.c.liu@nokia.com
Phone: +1 972 894-5935
EMail: zhigang.c.liu@nokia.com
Richard Price Roke Manor Research Ltd Romsey, Hants, SO51 0ZN, United Kingdom
Richard Price Roke Manor研究有限公司罗姆西，汉茨，SO51 0ZN，英国
Phone: +44 1794 833681
EMail: richard.price@roke.co.uk
Phone: +44 1794 833681
EMail: richard.price@roke.co.uk
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。