[要約] RFC 3321は、SigCompプロトコルの拡張操作に関する仕様であり、シグナリングの圧縮を目的としています。このRFCの目的は、ネットワークの帯域幅を節約し、通信の効率を向上させることです。
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.
Copyright（c）The Internet Society（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）であるRFC 3320に特定のメカニズムを実装する方法について説明します。
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）を使用しており、このドキュメントで説明されているメカニズムは、RFC 3320で定義された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
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.
そのようなメカニズムの1つは、動的圧縮と呼ばれる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
- shared_state_id
State identifier of a shared state.
共有状態の状態識別子。
- acked_state_id
- acked_state_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 | |
| +--------------+ | | +--------------+ |
+--------------------+ +--------------------+
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がメッセージを圧縮する場合、そのリモートDecompressor 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)
Acked状態
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.
Acked状態は、コンプレッサーが認識を受け取った救われた状態です。つまり、状態はリモート減圧装置に設立されました。コンプレッサーは、リモート減圧器で確立された状態のみを使用する必要があります。そうしないと、減圧障害が発生します。このため、少なくとも信頼性の低い輸送には、謝辞が必要です。
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 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).
凡例：メッセージ1状態S0を使用して圧縮されていることは、M1（S0）と表示されます。表記S1 = S0 M1は、状態S1が状態S0およびメッセージM1からの情報を使用して作成されることを意味します。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コードまたは状態が確立されたエンドポイントによって開始できます。これらの2つのケースについては、次の2つのセクションで詳細に説明します。
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バイトコードをDecompressor 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）：状態貯蓄を開始するUDVMバイトコード（a）は圧縮メッセージに掲載されるか、エンドポイント2ですでに保存されている状態から減圧器2によって取得できます。（3）：コンプレッサー1はこの承認の開始者は、任意の識別子を使用して返され、状態（a）が確立されていることを示すことができます。識別子は、間違った状態の認識を回避するのに十分なビットで構成する必要があります。フィードバック項目のパディングを避け、簡単にするには、識別子に最低1オクテットを使用する必要があります。識別子は、requested_feedback_item [sigcomp]の場所に配置されます。最終説明は、Requested_feedback_itemの位置をStateハンドラーに示すために使用されます。（4）：要求されたフィードバックデータは、Compressor 2のSigCompメッセージに配置されると、返されたフィードバックデータと呼ばれるようになりました。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 |
+--------------+ +--------------+
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メッセージには謝辞も含まれます。いわゆるACKED_STATE_ID：セクション2を参照してください。
(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）：状態貯蓄を開始するUDVMバイトコード（a）は圧縮メッセージに掲載されるか、エンドポイント2で既に保存されている状態から減圧器2によって取得できます。（3）：保存状態リクエスト状態（a）は、終了命令を使用して州ハンドラーに渡されます。申請は、州（a）を節約するために州ハンドラーに許可を付与する場合があります。[sigcomp]を参照してください。（4）：エンドポイント2は、状態（a）からエンドポイントまでの状態（a）を確認することを決定します（a）の状態識別子（acked_state_id）は、コンプレッサー2から減圧器1に送信されるsigcompメッセージに配置されます。（5）：udvm bytecodeに開始（合格）エンドポイント1の明示的な承認は、圧縮メッセージに携帯されるか、エンドポイント1ですでに保存されている状態から減圧器1によって取得できます。ハンドラーは、ACKED_STATE_IDを「返された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 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).
共有圧縮を使用するために、圧縮エンドポイントは、圧縮されていないバージョンの圧縮メッセージを状態（共有状態）として保存します。セクション2で説明されているように、共有状態への参照は、shared_state_idと呼ばれます。共有状態のパラメーターState_AddressとState_Instructionはゼロに設定する必要があります。State_retention_priorityは65535に設定する必要があり、他の状態パラメーターは[SigComp]に従って設定されます。これは、異なる圧縮アルゴリズムを使用して、さまざまな方向に移動するアプリケーションメッセージを圧縮できるためです。共有状態は、コンパートメントごとに作成されます。つまり、共有状態は、特定のリモートコンプレッサーによって作成された状態と同じメモリに保存されます。「通常の」状態と共有状態の間で状態記憶を分割する方法の選択は、コンプレッサーでの実装決定です。コンプレッサーが十分な状態メモリを利用できるようにしない限り（共有状態が既存の状態を状態メモリバッファーから押し出した場合に減圧障害が発生する可能性があるため）。
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 Endpoint 2で1命令を使用して、状態（M）のshared_state_idを計算します。「返されたsigcompパラメーター」[Sigcomp]の場所に共有識別子を配置することにより、適応症は州ハンドラーに渡されます。「返されたsigcompパラメーター」の場所は、最終説明を使用して州ハンドラーに与えられます。（4）：エンドポイント2が共有圧縮を使用する場合、「返されたsigcompパラメーター」情報の状態識別子値を、エンドポイント1から受信した現在の減圧メッセージに対して計算された値を比較します。共有状態は、共有圧縮が次のメッセージを圧縮するためにサポートされていない場合に通常使用します。（5）：Decompressor 1の減圧プロセスで共有状態（状態（M））を使用するUDVMバイトコードは、圧縮メッセージに掲載されるか、Endpoint 1ですでに保存されている状態からDecompressor 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 achieved and maintained, with the overhead amortized over a much longer period of time than one application session.
通常、シグナリングプロトコル（SIPなど）はセッションの概念を採用しています。ただし、圧縮の観点からは、同じソースから送信されたメッセージには、セッション境界を越えた冗長性が含まれています。したがって、セッション全体で同じソースからの状態データを維持して、1回のアプリケーションセッションよりもはるかに長い期間にわたってオーバーヘッドが償却されて、高性能を達成および維持できるようにすることは自然です。
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コンプレッサーには、特定のアプリケーションから批判的なシグナリングメッセージが生成される前であっても、Decompressorへの最初のメッセージの一部としてユーザー固有の辞書を含めることができます。これにより、メッセージが流れ始めると、圧縮効率の向上が可能になります。
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.
次のメカニズムを使用して、存在しない状態を参照するための減圧障害を回避できます。これは、3つのケースで発生する場合があります。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）を保存します。これは、decompressor 2のチェックポイント状態として持ちたいと考えています。（2）：状態の優先順位を示すUDVMバイトコード）および状態を開始する状態（a）は圧縮メッセージで運ばれるか、エンドポイント2ですでに保存されている状態から減圧器2によって取得できます。国家の優先順位の兆候を含む、最終説明の指示を使用した州のハンドラーに。アプリケーションは、州（a）の節約を付与します。[sigcomp]を参照してください。（4）：状態（a）（チェックポイント状態）の謝辞は、セクション5.1で説明したメカニズムの1つを使用してエンドポイント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.
通常、状態は2つの部分で構成されています：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 signaling overhead. It also means more robustness as there are no signaling bits on the wire that are subject to possible transmission errors/losses.
辞書のどの部分をメッセージごとに削除する必要があるかを明示的に信号する代わりに、暗黙の削除アプローチを適用することができます。具体的には、辞書の一部は、コンプレッサーと減圧器の両方で既知および適用されている明確なアルゴリズムに従って削除されるように選択されます。たとえば、アルゴリズムは、2つのSIGCOMPエンドポイント間で合意された事前定義されたUDVMバイトコードの一部になります。アルゴリズムへの入力として、削除するバイトの総数を提供します。アルゴリズムは、辞書のどの部分を削除するかを指定します。同じアルゴリズムが両方のSIGCOMPエンドポイントに適用されるため、メッセージごとに明示的なシグナリングは必要ありません。これにより、オーバーヘッドのシグナル伝達の回避により、圧縮効率が高くなる可能性があります。また、可能性のある伝送エラー/損失の影響を受けるワイヤにシグナル伝達ビットがないため、より堅牢性を意味します。
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メッセージの必須バイト[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で説明されているACKED_STATE_ID。 - セクション2および5.2で説明されているShared_state_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 :
| |
+---+---+---+---+---+---+---+---+
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
+---+---+---+---+---+---+---+---+ --------------
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'：設定されている場合、この圧縮メッセージ（共有状態）の減圧バージョンに対応する状態がコンプレッサーに保存されました。*：shared_state_idおよびacked_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.
このセクションでは、「returned_sigcomp_parameters」[Sigcomp]情報が、セクション5.1および5.2に従ってフィードバックを提供するように解釈される方法について説明します。
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.
partial_state_identifiersは、SigCompメッセージの受信後にリモートエンドポイントで確立された状態のHash_valueに対応しています。つまり、これらは確立された状態の認識であり、圧縮に使用される場合があります。Partial_state_identifiersは、特定のコンパートメントにマッピングされず、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.
各partial_state_identifierが、例えば、認められた状態または共有状態を参照する状態を推測するのは、実装次第です。共有状態および/または確認された状態の状態識別子を含む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ビットは、ローカルで利用可能な状態アイテムのリストをオフにするために提供されます。shared_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:
共有圧縮が2つのエンドポイント間で使用される場合（図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.
Compressor 1は、共有状態（M）を保存します。これは、送信される現在の圧縮メッセージ（メッセージM）の非圧縮バージョンです。コンプレッサー1はビット 'r'（図5を参照）も設定し、圧縮プロセスでエンドポイント2で状態（m）が使用できることを示します。メッセージMの減圧時にエンドポイント2で作成された状態のACKED_STATE_IDは、圧縮プロセスで共有状態（M）が使用されている場合、コンプレッサー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:
Endpoint 1が共有状態（M）がDecompressor 1によって要求されていることに気付いた場合、それは状態がエンドポイント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は、decompressor 2に状態を保存するよう指示しました。*状態が正常に保存されていない場合、共有状態（m）の兆候はコンプレッサー2によって受信されなかったでしょう。なぜなら、州の保存要求が拒否された場合、対応するアナウンス情報は州のハンドラーによって破棄されるからです。
Note: Endpoint 1's state handler must maintain a mapping between state(M) and state(S) for this optimization to work.
注：エンドポイント1の状態ハンドラーは、この最適化が機能するために、状態（M）と状態の間のマッピングを維持する必要があります。
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.
注：この機能によって認められる唯一の状態は、メッセージの圧縮に使用される状態とメッセージ自体を組み合わせることによって作成された状態です。他の場合には、ACKED_STATE_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 Parameter 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。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.、Christoffersson、J.、Hannu、H.、Liu、Z。、J。Rosenberg、「Signaling Compression（Sigcomp）」、RFC 3320、2003年1月。
Hans Hannu Box 920 Ericsson AB SE-971 28 Lulea, Sweden
Hans Hannu Box 920 Ericsson AB SE-971 28 Lulea、Sweden
Phone: +46 920 20 21 84
EMail: hans.hannu@epl.ericsson.se
Jan Christoffersson Box 920 Ericsson AB SE-971 28 Lulea, Sweden
Jan Christoffersson Box 920 Ericsson AB SE-971 28 Lulea、Sweden
Phone: +46 920 20 28 40
EMail: jan.christoffersson@epl.ericsson.se
Stefan Forsgren
ステファン・フォースグレン
EMail: StefanForsgren@alvishagglunds.se
Ka-Cheong Leung Department of Computer Science Texas Tech University Lubbock, TX 79409-3104 United States of America
Ka-Cheong Leungコンピュータサイエンス学部テキサス工科大学ラボック、テキサス州79409-3104アメリカ合衆国アメリカ
Phone: +1 806 742-3527
EMail: kcleung@cs.ttu.edu
Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA
Zhigang Liu Nokia Research Center 6000 Connection Drive Irving、TX 75039、米国
Phone: +1 972 894-5935
EMail: zhigang.c.liu@nokia.com
Richard Price Roke Manor Research Ltd Romsey, Hants, SO51 0ZN, United Kingdom
リチャード・プライス・ローク・マナー・リサーチ・リミテッド・ロムシー、ハンツ、SO51 0ZN、イギリス
Phone: +44 1794 833681
EMail: richard.price@roke.co.uk
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。