RFC3321 日本語訳
3321 Signaling Compression (SigComp) - Extended Operations. H. Hannu,J. Christoffersson, S. Forsgren, K.-C. Leung, Z. Liu, R. Price. January 2003. (Format: TXT=39433 bytes) (Updated by RFC4896) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループH.ハンヌの要求をネットワークでつないでください: 3321年のJ.Christofferssonカテゴリ: 情報のエリクソンS.Forsgren K.C。 レオンテキサス工科大大学Z.リュウノキアR.価格シーメンス/Roke荘園2003年1月
Signaling Compression (SigComp) - Extended Operations
シグナリング圧縮(SigComp)--拡大手術
Status of this Memo
この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)インターネット協会(2003)。 All rights reserved。
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.
このドキュメントがSignaling Compression(SigComp)、使用と簡単な状態で比べて、圧縮効率をかなり高めることができる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は減圧に、Universal Decompressor Virtual Machine(UDVM)を使用します、そして、本書では説明されたメカニズムは、実行するのにおいてRFC3320で定義されたUDVM指示を使用することで可能です。
Hannu, et. al. Informational [Page 1] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[1ページ]のRFC3321SigComp--拡大手術2003年1月
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. 序論…2 2. 用語…3 3. フィードバックの建築視点…4 4. 規範モデルを述べてください…5 5. メカニズムを広げています…6 6. SigCompの上の含意…13 7. セキュリティ問題…17 8. IANA問題…17 9. 承認…17 10. 知的所有権問題…17 11. 参照…17 12. 作者のアドレス…18 13. 完全な著作権宣言文…19
1. Introduction
1. 序論
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]の概念に詳しいはずです。
Hannu, et. al. Informational [Page 2] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[2ページ]のRFC3321SigComp--拡大手術2003年1月
2. Terminology
2. 用語
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.
共有された圧縮に使用される状態は解凍されたメッセージだけから成ります。 これは圧縮アルゴリズムの如何にかかわらず状態を作ります。
Hannu, et. al. Informational [Page 3] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[3ページ]のRFC3321SigComp--拡大手術2003年1月
State identifier
州の識別子
Reference used to access a previously created item of state.
参照は以前はよく状態の以前に作成された項目にアクセスしていました。
- shared_state_id
- 共有された_状態_イド
State identifier of a shared state.
共有された状態に関する識別子を述べてください。
- acked_state_id
- _状態_イドをackedしました。
State identifier of a state that is acknowledged as
successfully saved by the decompressor.
減圧装置によって首尾よく救われるとして承認される状態に関する識別子を述べてください。
3. Architectural View of Feedback
3. フィードバックの建築視点
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.
図1は、SigCompには終点の間にフィードバックを提供するという要求/反応機構があるのを見ます。 SigCompのこの特定の機能性は、本書では説明されたメカニズムのサポートを提供するのに本書では使用されます。
+--------------------+ +--------------------+
| Endpoint 1 | | Endpoint 2 |
| +--------------+ | | +--------------+ |
| | Compressor 1 | | | |Decompressor 2| |
| | [------------+--+--------------+--+--] * | |
| +-|-------^----+ | | +--|---|-------+ |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| +-|-------|----+ | | +--v---|-------+ |
| | * [----+--+--------------+--+------] | |
| |Decompressor 1| | | | Compressor 2 | |
| +--------------+ | | +--------------+ |
+--------------------+ +--------------------+
+--------------------+ +--------------------+ | 終点1| | 終点2| | +--------------+ | | +--------------+ | | | コンプレッサー1| | | |減圧装置2| | | | [------------+--+--------------+--+--] * | | | +-|-------^----+ | | +--|---|-------+ | | | | | | | | | | | | | | | | | | | | | | | | | | +-|-------|----+ | | +--v---|-------+ | | | * [----+--+--------------+--+------] | | | |減圧装置1| | | | コンプレッサー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終点によって設立されているかを確認するようにメカニズムを提供するのに本書では使用されます。 確立した州の確認は承認と呼ばれます。 設立された州によって、この特定のタイプのフィードバックは、圧縮効率を増加させるのに使用されるかもしれません。
Hannu, et. al. Informational [Page 4] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[4ページ]のRFC3321SigComp--拡大手術2003年1月
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でいくつかのメカニズムの含意について説明します。
4. State Reference Model
4. 州の規範モデル
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に積むつもりであるなら、特定の状態の場所を見つけるように参照を必要とします。 この参照は州の識別子と呼ばれます。
4.1. Overview of State Reference with Dynamic Compression
4.1. 動的圧縮との州の参照の概観
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)
状態に救われます。(s)
A state which is expected to be used for compression/decompression
of later messages.
後のメッセージの圧縮/減圧に使用されると予想される状態。
Acked state(s)
状態をAckedしました。(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.
acked状態がコンプレッサーが承認を受けた救われた状態である、すなわち、リモート減圧装置で状態を設置してあります。 コンプレッサーはリモート減圧装置で設置される州を使用するだけでよいです。さもなければ、減圧失敗は起こるでしょう。 この理由で、承認が少なくとも頼り無い輸送に必要です。
Hannu, et. al. Informational [Page 5] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[5ページ]のRFC3321SigComp--拡大手術2003年1月
Compressor 1 Decompressor 2
+---+ +---+
| C | | D |
+---+ +---+
コンプレッサー1減圧装置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 | |
救われたAcked| | 州の状態に救われます。| | 状態-----------------------+------------+------------------ s0 s0| | s0 s1=s0+m1| --m1(s0)-->|、| <--ack(s1)| s0、s1 s0、s1 s0、s1| | | | s0、s1 s0、s1| --m2(s1)-->| (なくされたm2) 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は、州のs1が州のs0とメッセージm1からの情報を使用することで作成されることを意味します。ack(s1)は、州のs1の創造が反対の方向(図に示されない)に旅行しながらメッセージで便乗することで承諾されることを意味します。
5. Extended Mechanisms
5. 拡張メカニズム
The following subsections give a general description of the extended mechanisms.
以下の小区分は拡張メカニズムの概説を与えます。
5.1. Explicit Acknowledgement Scheme
5.1. 明白な承認計画
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.
コンプレッサーと減圧装置の間の経路で圧縮されたメッセージを失っているか、またはmisorderedすることができる場合では、ある状態を設置してあることをリモートコンプレッサーに通知するのに承認計画を使用しなければなりません。
Hannu, et. al. Informational [Page 6] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[6ページ]のRFC3321SigComp--拡大手術2003年1月
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つのセクションで説明されるでしょう。
5.1.1. Remote Compressor Initiated Acknowledgements
5.1.1. リモートコンプレッサー開始している承認
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バイトコードは、終点2で設立された州に関して知識を得るのに発表情報の要求されたフィードバック分野とSigCompヘッダーの返されたフィードバック分野を使用するでしょう。
Hannu, et. al. Informational [Page 7] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[7ページ]のRFC3321SigComp--拡大手術2003年1月
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は例えばstate(A)を取っておきます。 (2): state(A)がどちらかので、州が救う開始へのUDVMバイトコードを圧縮されたメッセージで運ぶか、または減圧装置2は、終点2で既に節約された状態から検索できます。 (3): コンプレッサー1がこの承認の創始者であるので、それはstate(A)が設立されたのを示すために返される任意の識別子を使用できます。 識別子は、間違った状態の承認を避けることができるくらいのビットから成る必要があります。 フィードバック項目と簡単さのためにそっと歩くのを避けるために、最低1つの八重奏が識別子に使用されるべきです。 識別子は要求された_のフィードバック_品目[SIGCOMP]の位置に置かれます。 END-MESSAGE指示は、要求された_のフィードバック_品目の位置を州の操作者に示すのに使用されます。 (4): それがコンプレッサー2にSigCompメッセージに置かれるとき、要求されたフィードバックデータは現在、返されたフィードバックデータと呼ばれます。 (5): 図4によると、返されたフィードバック商品はSigCompメッセージで運ばれます: セクション6.1と[SIGCOMP]を見てください。 (6): 以下に従って、返されたフィードバック項目は扱われます。 7を区分します。[SIGCOMP]
+--------------+ (2) +--------------+
| Compressor 1 |--------------------------->|Decompressor 2|
+------^-------+ +-------^------+
| (1) (3) |
+---v---+ +---v---+
|State | |State |
|handler| |handler|
+---^---+ +---^---+
| (6) (4) |
+------v-------+ (5) +-------v------+
|Decompressor 1|<---------------------------| Compressor 2 |
+--------------+ +--------------+
+--------------+ (2) +--------------+ | コンプレッサー1|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|減圧装置2| +------^-------+ +-------^------+ | (1) (3) | +---v---+ +---v---+ |状態| |状態| |操作者| |操作者| +---^---+ +---^---+ | (6) (4) | +------v-------+ (5) +-------v------+ |減圧装置1| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| コンプレッサー2| +--------------+ +--------------+
Figure 3. Simplified SigComp endpoints
図3。 簡易型のSigComp終点
Hannu, et. al. Informational [Page 8] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[8ページ]のRFC3321SigComp--拡大手術2003年1月
5.1.2. Local Endpoint Initiated Acknowledgements
5.1.2. 地方の終点開始している承認
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_状態_イドを運ぶでしょう: セクション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は例えばstate(A)を取っておきます。 (2): state(A)がどちらかので、州が救う開始へのUDVMバイトコードを圧縮されたメッセージで運ぶか、または減圧装置2は、終点2で既に節約された状態から検索できます。 (3): state(A)を求めるセーブ州の要求は、END-MESSAGE指示を使用することで州の操作者に渡されます。 次に、アプリケーションはstate(A)を取っておく州の操作者許可を与えるかもしれません: [SIGCOMP]を見てください。 (4): 終点2は、終点1にstate(A)を承認すると決めます。 state(A)のための州の識別子(_状態_イドをackedした)はコンプレッサー2から減圧装置1に送られたSigCompメッセージに置かれます。 (5): 終点1に明白な承認を開始する(通ります)UDVMバイトコードを圧縮されたメッセージで運ぶか、または減圧装置1は終点1で既に節約された状態から検索できます。 (6): state(A)のためのacked_状態_イドは、位置がEND-MESSAGE指示を使用することで州の操作者に与えられている「返されたSigCompパラメタ」[SIGCOMP]の位置にacked_状態_イドをみなすことによって、州の操作者に渡されます。
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において価値があるか、そして、フィードバック・メカニズムをサポートして、その結果、メカニズムを実行する可能性があると考えるべきです。
5.2. Shared Compression
5.2. 共有された圧縮
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で説明されるように、共有された状態の参照は共有された_状態_イドと呼ばれます。 共有された状態のパラメタは_アドレスと合わせてください指示を設定しなければならないゼロ州の_を述べます。 状態_保有_優先権を65535に設定しなければなりません、そして、[SIGCOMP]に従って、他の州のパラメタは設定されます。 これは異なった圧縮アルゴリズムが異なった方向に移動するアプリケーションメッセージを圧縮するのに使用されるかもしれないからです。 また、共有された状態は1コンパートメントあたり1個のベースに創設されます、すなわち、共有された状態が特定によってリモートな状態で創設された州と同じメモリに格納されます。
Hannu, et. al. Informational [Page 9] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[9ページ]のRFC3321SigComp--拡大手術2003年1月
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指示は、共有された_状態_イドについて状態(M)に計算するのに終点2で使用されます。 指示は州の操作者に渡されます、「返されたSigCompパラメタ」[SIGCOMP]の位置に共有された識別子をみなすことによって。 END-MESSAGE指示を使用することで「返されたSigCompパラメタ」の位置を州の操作者に与えます。 (4): 終点2が共有された圧縮を使用するなら、それは「返されたSigCompパラメタ」情報の州の識別子値を終点1から受け取られた現在の減圧されたメッセージのために計算した値にたとえます。 マッチがあって、共有された圧縮が次のメッセージを圧縮するために支持されないなら、終点2は通常、それが使用する状態と共に共有された状態を使用します。 (5): 望んでいるUDVMバイトコードは共有された状態を使用します。(減圧装置1における減圧の過程による状態(M))は、圧縮されたメッセージで運ぶか、または減圧装置1で終点1で既に節約された状態から検索できます。
5.3. Maintaining State Data Across Application Sessions
5.3. アプリケーションセッションの向こう側に州のデータを保守します。
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)に合図して、通常、セッションの概念を使ってください。 しかしながら、圧縮観点から、同じソースによって送られたメッセージはセッション境界を超えて冗長を含んでいます。 その結果、セッションの向こう側に同じソースからの州のデータを保守するのは、高性能があることができるくらい当然です。
Hannu, et. al. Informational [Page 10] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[10ページ]のRFC3321SigComp--拡大手術2003年1月
achieved and maintained, with the overhead amortized over a much longer period of time than one application session.
達成されて、オーバーヘッドが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).
単にただ一つのアプリケーションセッションの時間持続時間より長い間コンパートメントの生涯を作ることによって、アプリケーションセッションの向こう側に州を維持するのを達成できます。 ここの州が地球規模で(すなわち、コンパートメント特有でない)格納される局所的に利用可能な州ではなく、1コンパートメントあたり1個のベースに格納されたものについて言及していることに注意してください。
5.4. Use of User-Specific Dictionary
5.4. ユーザ特有の辞書の使用
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や、名前や、Eメールアドレスなどのユーザ特殊情報は、頻繁ベースでおそらく変化しないで、特定のユーザにかかわりながら、交換に合図する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を見てください。
5.5. Checkpoint State
5.5. チェックポイント州
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メッセージを送るとき、それは、新たに作成された状態が同じコンプレッサーによって送られる中で最も高い値の状態_保有_優先権[SIGCOMP]を設定することによってチェックポイント州になるのを示すことができます。 さらに、受信減圧装置でチェックポイント州を明らかに送付コンプレッサーに承認しなければなりません。
Hannu, et. al. Informational [Page 11] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[11ページ]のRFC3321SigComp--拡大手術2003年1月
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は例えばstate(A)を取っておきます。(それはチェックポイント州として減圧装置2でstate(A)が欲しいです)。 (2): state(A)がどちらかので、州が救うstate(A)と開始の州の優先権([SIGCOMP]状態_保有_優先権)を示すUDVMバイトコードを圧縮されたメッセージで運ぶか、または減圧装置2は、終点2で既に節約された状態から検索できます。 (3): state(A)を求めるセーブ州の要求はEND-MESSAGE指示を使用することで州の操作者に渡されます、州の優先権のしるしを含んでいて。 アプリケーションはstate(A)の節約を与えます: [SIGCOMP]を見てください。 (4): セクション5.1で説明されたメカニズムの1つを使用することでstate(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パラメタ状態_メモリ_サイズは推論するのにおいて使用されている場合があります。
5.6. Implicit Deletion for Dictionary Update
5.6. 辞書最新版のための暗黙の削除
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
明らかにメッセージ基礎あたりのaで削除されるべき辞書の必要性のどの部分に合図するかの代わりに、暗黙の削除アプローチは適用されるかもしれません。 明確に、辞書のいくつかの部分が、知られている明確なアルゴリズムに応じて削除されるために選ばれていて、コンプレッサーと減圧装置の両方で同じように適用されています。 例えば、アルゴリズムは2つのSigComp終点の間で同意される事前に定義されたUDVMバイトコードの一部であるかもしれません。 アルゴリズムに入力されるように、1つは削除されるためにバイトの総数を提供します。 そして、アルゴリズムは、削除されるために辞書の部分がどれであるかを指定します。 同じアルゴリズムが両方のSigComp終点で適用されるので、メッセージ基礎あたりのaの明白なシグナリングの必要は全くありません。 これは回避のためより高い圧縮効率に導くかもしれません。
Hannu, et. al. Informational [Page 12] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[12ページ]のRFC3321SigComp--拡大手術2003年1月
signaling overhead. It also means more robustness as there are no signaling bits on the wire that are subject to possible transmission errors/losses.
オーバーヘッドに合図します。 また、ワイヤでどんな可能な伝送エラー/損失を被りやすいシグナリングビットもないとき、それは、より多くの丈夫さを意味します。
6. Implications on SigComp
6. 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]の義務的なバイト以外の、使用される最終的なメッセージ・フォーマットは導入問題です。 明白な承認、そして/または、共有された圧縮を利用しない実現が影響を受けないことに注意してください、この種類のフィードバックを受けても。
6.1. Implications on SigComp Messages
6.1. 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_状態_イド。 - セクション2と5.2で説明される共有された_状態_イド。
Hannu, et. al. Informational [Page 13] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[13ページ]のRFC3321SigComp--拡大手術2003年1月
Figure 4 depicts the format of a SigComp message according to [SIGCOMP]:
[SIGCOMP]に従って、図4は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 | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | | | | : 返されたフィードバック項目: : 返されたフィードバック項目: | | | | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | | | コード_len| : 部分的な州の識別子: +---+---+---+---+---+---+---+---+ | | | コード_len| 目的地| +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | | | | : SigCompメッセージのままで、残っています: : アップロードされたUDVMバイトコード: | | | | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | | : SigCompメッセージのままで、残っています: | | +---+---+---+---+---+---+---+---+
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バイトコードを供給するコンプレッサーによる実現決定です。 したがって、本書では説明された拡張特徴のために必要情報を運ぶためにメッセージ・フォーマットを指定する必要は全くありません。
Hannu, et. al. Informational [Page 14] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[14ページ]のRFC3321SigComp--拡大手術2003年1月
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 +---+---+---+---+---+---+---+---+ | 図4に従った形式| : 呼ばれる分野を除いて: | 「SigCompメッセージのままで、残っています」| 「残っているSigCompメッセージ」分野+---+---+---+---+---+---+---+---+ -------- | s| a| r| 予約されます。| | +---+---+---+---+---+---+---+---+ | | | | : 共有された_状態_イド*: 's'があるなら、プレゼントはセットしました。| | | +---+---+---+---+---+---+---+---+ | | | | : acked_状態_イド*: 'a'があるなら、プレゼントはセットしました。| | | +---+---+---+---+---+---+---+---+ | | | | : SigCompメッセージの残り: | | | +に対して---+---+---+---+---+---+---+---+ --------------
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': 設定されるなら、この圧縮されたメッセージ(共有された状態)の減圧されたバージョンに対応する状態はコンプレッサーで節約されました。 * : 共有された_州の_イドとacked_州の_イド分野の長さは部分的な州の識別子と同じ長さのものです。
6.2. Extended SigComp Announcement/Feedback Format
6.2. 拡張SigComp発表/フィードバック形式
This section describes how the "returned_SigComp_parameters" [SIGCOMP] information is interpreted to provide feedback according to Section 5.1 and 5.2.
このセクションは「返された_SigComp_パラメタ」[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.
部分的な_状態_識別子がSigCompメッセージのレセプションの後に遠く離れた終点で設置された州への細切れ肉料理_値に対応している、すなわち、これらは、設立された州への承認であり、圧縮に使用されるかもしれません。 また、部分的な_状態_識別子はどんな特定のコンパートメントにも写像されないで、またSigCompメッセージの領収書に設立されない「グローバルな状態」を発表するかもしれません。
Hannu, et. al. Informational [Page 15] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[15ページ]のRFC3321SigComp--拡大手術2003年1月
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-ビットを提供します。それが共有された_状態_イド必須を受けたがっている終点はI-ビットを1に設定しませんでした。 /からリストまで局所的に利用可能な州(すなわち、共有された州か例えば、周知のアルゴリズムの州)の異なったタイプを遮断するか、または含んでいるかという決定を取るとき、共有された州を格納して、局所的に利用可能な州のリストを遠く離れた終点に送る終点は慎重であるに違いありません。
6.3. Acknowledgement Optimization
6.3. 承認最適化
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_状態_イドを不要にします)。
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は、圧縮の過程による終点2で状態(M)を使用できると合図するために、ビット'r'(図5を見ます)を設定します。 共有された状態(M)が圧縮の過程で使用されるなら、状態(S)へのacked_状態_イドはコンプレッサー2から圧縮されたメッセージに明らかに置かれる必要はないかもしれません。(状態はメッセージ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:
終点1が、共有された状態(M)が減圧装置1によって要求されるのに気付くと、それは、状態(S)が終点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には、状態(S)を節約する命令された減圧装置2があります。 * 首尾よく状態(S)を節約しなかったなら、コンプレッサー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.
以下に注意してください。 この特徴によって承認される唯一の状態がメッセージとメッセージ自体の要約に使用される状態を合併することによって創設された状態です。 いかなる他のケースのためにも、acked_状態_イドは使用されなければなりません。
Hannu, et. al. Informational [Page 16] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[16ページ]のRFC3321SigComp--拡大手術2003年1月
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.
以下に注意してください。 首尾よく発表情報を転送しますが、州のメモリの不足のため状態(S)を捨てる可能性があります。 この可能性を考慮に入れなければなりません(さもなければ、減圧失敗は起こるかもしれません)。 SigCompフィードバック・メカニズムによって発表されるSigCompパラメタ状態_メモリ_サイズを使用することによって、これができます。 州の創造要求がメモリの不足のため失敗したなら、終点は推論するこのパラメタを使用できます。
7. Security Considerations
7. セキュリティ問題
The features in this document are believed not to add any security risks to the ones mentioned in [SIGCOMP].
特徴が[SIGCOMP]で言及されたものに少しのセキュリティ危険も加えないと本書では信じられています。
8. IANA Considerations
8. IANA問題
This document does not require any IANA involvement.
このドキュメントは少しのIANAかかわり合いも必要としません。
9. Acknowledgements
9. 承認
Thanks to Carsten Bormann, Christopher Clanton, Miguel Garcia, Lars- Erik Jonsson, Khiem Le, Mats Nordberg, Jonathan Rosenberg and Krister Svanbro for valuable input.
貴重な入力をカルステン・ボルマン、クリストファーClanton、ミゲル・ガルシア、ラース・エリック・イェンソン、Khiem Le、マッツ・ノールベルグ、ジョナサン・ローゼンバーグ、およびKrister Svanbroをありがとうございます。
10. Intellectual Property Right Considerations
10. 知的所有権問題
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は本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。
11. References
11. 参照
[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.
[一口] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[SIGCOMP] Price R., Bormann, C., Christoffersson, J., Hannu, H.,
Liu, Z. and J. Rosenberg, "Signaling Compression
(SigComp)", RFC 3320, January 2003.
[SIGCOMP]はR.、ボルマン、C.、Christoffersson、J.、ハンヌ、H.、リュウ、Z.、およびJ.ローゼンバーグに値を付けます、「圧縮(SigComp)に合図し」て、RFC3320、2003年1月。
Hannu, et. al. Informational [Page 17] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[17ページ]のRFC3321SigComp--拡大手術2003年1月
12. Authors' Addresses
12. 作者のアドレス
Hans Hannu Box 920 Ericsson AB SE-971 28 Lulea, Sweden
ハンスハンヌBox920エリクソンAB SE-971 28ルーレオ(スウェーデン)
Phone: +46 920 20 21 84 EMail: hans.hannu@epl.ericsson.se
以下に電話をしてください。 +46 920 20 21 84はメールされます: hans.hannu@epl.ericsson.se
Jan Christoffersson Box 920 Ericsson AB SE-971 28 Lulea, Sweden
1月のChristoffersson箱920のエリクソンAB SE-971 28ルーレオ(スウェーデン)
Phone: +46 920 20 28 40 EMail: jan.christoffersson@epl.ericsson.se
以下に電話をしてください。 +46 920 20 28 40はメールされます: jan.christoffersson@epl.ericsson.se
Stefan Forsgren
ステファンForsgren
EMail: StefanForsgren@alvishagglunds.se
メール: StefanForsgren@alvishagglunds.se
Ka-Cheong Leung Department of Computer Science Texas Tech University Lubbock, TX 79409-3104 United States of America
ka-Cheongレオンコンピュータサイエンス学部テキサス工科大大学ラバック、テキサス79409-3104アメリカ合衆国
Phone: +1 806 742-3527 EMail: kcleung@cs.ttu.edu
以下に電話をしてください。 +1 806 742-3527 メールしてください: kcleung@cs.ttu.edu
Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA
テキサス 75039、ZhigangリュウノキアResearch Center6000接続Driveアービング(米国)
Phone: +1 972 894-5935 EMail: zhigang.c.liu@nokia.com
以下に電話をしてください。 +1 972 894-5935 メールしてください: zhigang.c.liu@nokia.com
Richard Price Roke Manor Research Ltd Romsey, Hants, SO51 0ZN, United Kingdom
リチャード・Price Roke荘園研究Ltdロムジー、Hants、SO51 0ZN、イギリス
Phone: +44 1794 833681 EMail: richard.price@roke.co.uk
以下に電話をしてください。 +44 1794 833681はメールされます: richard.price@roke.co.uk
Hannu, et. al. Informational [Page 18] RFC 3321 SigComp - Extended Operations January 2003
etハンヌ、アル。 情報[18ページ]のRFC3321SigComp--拡大手術2003年1月
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Hannu, et. al. Informational [Page 19]
etハンヌ、アル。 情報[19ページ]
一覧
スポンサーリンク
