RFC3320 日本語訳
3320 Signaling Compression (SigComp). R. Price, C. Bormann, J.Christoffersson, H. Hannu, Z. Liu, J. Rosenberg. January 2003. (Format: TXT=137035 bytes) (Updated by RFC4896) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Price
Request for Comments: 3320 Siemens/Roke Manor
Category: Standards Track C. Bormann
TZI/Uni Bremen
J. Christoffersson
H. Hannu
Ericsson
Z. Liu
Nokia
J. Rosenberg
dynamicsoft
January 2003
コメントを求めるワーキンググループR.価格要求をネットワークでつないでください: 3320年のシーメンス/Roke荘園カテゴリ: 規格Track C.ボルマンTZI/UniブレーメンJ.Christoffersson H.ハンヌエリクソンZ.リュウノキアJ.ローゼンバーグdynamicsoft2003年1月
Signaling Compression (SigComp)
シグナリング圧縮(SigComp)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document defines Signaling Compression (SigComp), a solution for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP) (RFC 3261) and the Real Time Streaming Protocol (RTSP) (RFC 2326). The architecture and prerequisites of SigComp are outlined, along with the format of the SigComp message.
このドキュメントはSignaling Compression(SigComp)(Session Initiationプロトコル(SIP)(RFC3261)やレアルTime Streamingプロトコル(RTSP)(RFC2326)などのアプリケーション・プロトコルによって生成されたメッセージを圧縮するためのソリューション)を定義します。 SigCompのアーキテクチャと前提条件はSigCompメッセージの形式と共に概説されています。
Decompression functionality for SigComp is provided by a Universal Decompressor Virtual Machine (UDVM) optimized for the task of running decompression algorithms. The UDVM can be configured to understand the output of many well-known compressors such as DEFLATE (RFC-1951).
減圧アルゴリズムを実行するタスクのために最適化されたUniversal Decompressor Virtual Machine(UDVM)はSigCompのための減圧の機能性を提供します。DEFLATE(RFC-1951)などのよく知られる多くのコンプレッサーの出力を理解するためにUDVMを構成できます。
Price, et. al. Standards Track [Page 1] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[1ページ]RFC3320
Table of Contents
目次
1. Introduction...................................................2 2. Terminology....................................................3 3. SigComp architecture...........................................5 4. SigComp dispatchers...........................................15 5. SigComp compressor............................................18 6. SigComp state handler.........................................20 7. SigComp message format........................................23 8. Overview of the UDVM..........................................28 9. UDVM instruction set..........................................37 10. Security Considerations.......................................56 11. IANA Considerations...........................................58 12. Acknowledgements..............................................59 13. References....................................................59 14. Authors' Addresses............................................60 15. Full Copyright Statement......................................62
1. 序論…2 2. 用語…3 3. SigCompアーキテクチャ…5 4. SigComp発送者…15 5. SigCompコンプレッサー…18 6. SigCompは操作者を述べます…20 7. SigCompメッセージ・フォーマット…23 8. UDVMの概要…28 9. UDVM命令セット…37 10. セキュリティ問題…56 11. IANA問題…58 12. 承認…59 13. 参照…59 14. 作者のアドレス…60 15. 完全な著作権宣言文…62
1. Introduction
1. 序論
Many application protocols used for multimedia communications are text-based and engineered for bandwidth rich links. As a result the messages have not been optimized in terms of size. For example, typical SIP messages range from a few hundred bytes up to two thousand bytes or more [RFC3261].
マルチメディア通信に使用される多くのアプリケーション・プロトコルが、テキストベースで帯域幅の豊かなリンクに設計されています。 その結果、メッセージはサイズで最適化されていません。 例えば、典型的なSIPメッセージは2,000よりバイト[RFC3261]までの数100バイトから変化します。
With the planned usage of these protocols in wireless handsets as part of 2.5G and 3G cellular networks, the large message size is problematic. With low-rate IP connectivity the transmission delays are significant. Taking into account retransmissions, and the multiplicity of messages that are required in some flows, call setup and feature invocation are adversely affected. SigComp provides a means to eliminate this problem by offering robust, lossless compression of application messages.
2.5Gの一部としてのワイヤレスの受話器と3Gセルラー・ネットワークにおけるこれらのプロトコルの計画された用法で、大きいメッセージサイズは問題が多いです。 低率IPの接続性によって、トランスミッション遅れは重要です。 「再-トランスミッション」を考慮に入れて、いくつかの流れで必要であるメッセージの多様性、呼び出しセットアップと特徴実施は悪影響を受けます。 SigCompはアプリケーションメッセージの体力を要しているlossless要約を提供することによってこの問題を解決する手段を提供します。
This document outlines the architecture and prerequisites of the SigComp solution, the format of the SigComp message and the Universal Decompressor Virtual Machine (UDVM) that provides decompression functionality.
このドキュメントはSigCompソリューションのアーキテクチャと前提条件、SigCompメッセージの形式、および減圧の機能性を提供するUniversal Decompressor Virtual Machine(UDVM)について概説します。
SigComp is offered to applications as a layer between the application and an underlying transport. The service provided is that of the underlying transport plus compression. SigComp supports a wide range of transports including TCP, UDP and SCTP [RFC-2960].
アプリケーションと基本的な輸送の間の層としてSigCompをアプリケーションに提供します。 提供されたサービスは基本的な輸送と圧縮のものです。 SigCompはTCP、UDP、およびSCTP[RFC-2960]を含むさまざまな輸送をサポートします。
Price, et. al. Standards Track [Page 2] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[2ページ]RFC3320
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC-2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC-2119]で説明されるように本書では解釈されることであるべきです。
Application
アプリケーション
Entity that invokes SigComp and performs the following tasks:
SigCompを呼び出して、以下を実行する実体が以下に仕事を課します。
1. Supplying application messages to the compressor dispatcher
2. Receiving decompressed messages from the decompressor
dispatcher
3. Determining the compartment identifier for a decompressed
message.
1. コンプレッサー発送者2にアプリケーションメッセージを供給します。 受信は減圧装置発送者3からのメッセージを減圧しました。 減圧されたメッセージのためのコンパートメント識別子を決定します。
Bytecode
バイトコード
Machine code that can be executed by a virtual machine.
仮想計算機で実行できる機械コード。
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がそれが生成するメッセージを減圧できるのを確実にするのにコンプレッサーは原因となります。
Compressor Dispatcher
コンプレッサー発送者
Entity that receives application messages, invokes a compressor,
and forwards the resulting SigComp compressed messages to a remote
endpoint.
アプリケーションメッセージを受け取って、コンプレッサーを呼び出して、結果として起こるSigCompを進める実体が遠く離れた終点にメッセージを圧縮しました。
UDVM Cycles
UDVMサイクルズ
A measure of the amount of "CPU power" required to execute a UDVM
instruction (the simplest UDVM instructions require a single UDVM
cycle). An upper limit is placed on the number of UDVM cycles
that can be used to decompress each bit in a SigComp message.
「CPUパワー」の量の基準がUDVM指示を実行するのが必要です(最も簡単なUDVM指示は1UDVMサイクルを必要とします)。 上限は、費やすことができるUDVMサイクルの数に関して各ビット単位でSigCompメッセージで減圧するために課されます。
Decompressor Dispatcher
減圧装置発送者
Entity that receives SigComp messages, invokes a UDVM, and
forwards the resulting decompressed messages to the application.
SigCompメッセージを受け取って、UDVMを呼び出して、結果になることを進める実体がメッセージをアプリケーションに減圧しました。
Price, et. al. Standards Track [Page 3] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[3ページ]RFC3320
Endpoint
終点
One instance of an application, a SigComp layer, and a transport
layer for sending and/or receiving SigComp messages.
SigCompメッセージを送る、そして/または、受け取るためのアプリケーション、SigComp層、およびトランスポート層の1つのインスタンス。
Message-based Transport
メッセージベースの輸送
A transport that carries data as a set of bounded messages.
1セットの境界があるメッセージとしてデータを運ぶ輸送。
Compartment
コンパートメント
An application-specific grouping of messages that relate to a peer
endpoint. Depending on the signaling protocol, this grouping may
relate to application concepts such as "session", "dialog",
"connection", or "association". The application allocates state
memory on a per-compartment basis, and determines when a
compartment should be created or closed.
同輩終点に関連するメッセージのアプリケーション特有の組分け。 シグナリングプロトコルによって、この組分けは「セッション」、「対話」、「接続」、または「協会」などのアプリケーション概念に関連するかもしれません。 アプリケーションは、1コンパートメントあたり1個のベースに関する州のメモリを割り当てて、コンパートメントがいつ作成されるべきであるか、または閉じられるべきであるかを決定します。
Compartment Identifier
コンパートメント識別子
An identifier (in a locally chosen format) that uniquely
references a compartment.
唯一コンパートメントに参照をつける識別子(局所的に選ばれた形式の)。
SigComp
SigComp
The overall compression solution, comprising the compressor, UDVM,
dispatchers and state handler.
総合的な圧縮対策、コンプレッサーを包括する、UDVM、発送者、および州の操作者。
SigComp Message
SigCompメッセージ
A message sent from the compressor dispatcher to the decompressor
dispatcher. In case of a message-based transport such as UDP, a
SigComp message corresponds to exactly one datagram. For a
stream-based transport such as TCP, the SigComp messages are
separated by reserved delimiters.
メッセージはコンプレッサー発送者から減圧装置発送者まで発信しました。 UDPなどのメッセージベースの輸送の場合には、SigCompメッセージはちょうど1個のデータグラムに対応しています。 TCPなどのストリームベースの輸送において、SigCompメッセージは予約されたデリミタによって切り離されます。
Stream-based transport
ストリームベースの輸送
A transport that carries data as a continuous stream with no
message boundaries.
連続したストリームとしてメッセージ限界なしでデータを運ぶ輸送。
Transport
輸送
Mechanism for passing data between two endpoints. SigComp is
capable of sending messages over a wide range of transports
including TCP, UDP and SCTP [RFC-2960].
2つの終点の間にデータを向かわせるためのメカニズム。 SigCompはTCP、UDP、およびSCTP[RFC-2960]を含むさまざまな輸送の上にメッセージを送ることができます。
Price, et. al. Standards Track [Page 4] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[4ページ]RFC3320
Universal Decompressor Virtual Machine (UDVM)
普遍的な減圧装置仮想計算機(UDVM)
The machine architecture described in this document. The UDVM is
used to decompress SigComp messages.
本書では説明されたマシンアーキテクチャ。 UDVMは、SigCompメッセージを減圧するのに使用されます。
State
状態
Data saved for retrieval by later SigComp messages.
データは検索のために後のSigCompメッセージによって保存されました。
State Handler
州の操作者
Entity responsible for accessing and storing state information
once permission is granted by the application.
アプリケーションでいったん許可を与えると、アクセスに原因となる実体と保存は情報を述べます。
State Identifier
州の識別子
Reference used to access a previously created item of state.
参照は以前はよく状態の以前に作成された項目にアクセスしていました。
3. SigComp Architecture
3. SigCompアーキテクチャ
In the SigComp architecture, compression and decompression is performed at two communicating endpoints. The layout of a single endpoint is illustrated in Figure 1:
SigCompアーキテクチャでは、圧縮と減圧は2つの交信終点で実行されます。 単一の終点のレイアウトは図1で例証されます:
Price, et. al. Standards Track [Page 5] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[5ページ]RFC3320
+-------------------------------------------------------------------+
| |
| Local application |
| |
+-------------------------------------------------------------------+
| ^ |
Application message & | Decompressed | | Compartment
compartment identifier | message | | identifier
| | |
+-- -- -- -- -- -- -- --|-- -- -- -- -- -- -- --|--|-- -- -- -- -- -+
v | v
| +------------------------+ +----------------------+ |
| | | |
| +--| Compressor | | Decompressor |<-+ |
| | dispatcher | | dispatcher | |
| | | | | | | |
| +------------------------+ +----------------------+ |
| | ^ ^ ^ | |
| | | | |
| | | v | | |
| | +--------------+ +---------------+ | |
| | | | | | +-------+ | v | |
| | | Compressor 1 |<----->|State 1| | +--------------+ |
| | | | | | +-------+ | | | | |
| | +--------------+ | | | Decompressor | |
| | | | State handler |<-->| | | |
| | +--------------+ | | | (UDVM) | |
| | | | | | +-------+ | | | | |
| +->| Compressor 2 |<----->|State 2| | +--------------+ |
| | | | | +-------+ | | |
| +--------------+ +---------------+ SigComp layer |
| | | |
+-| -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --|-+
| |
| SigComp SigComp |
| message message |
v |
+-------------------------------------------------------------------+
| |
| Transport layer |
| |
+-------------------------------------------------------------------+
+-------------------------------------------------------------------+ | | | 局所塗布| | | +-------------------------------------------------------------------+ | ^ | アプリケーションメッセージ| 減圧されます。| | コンパートメントコンパートメント識別子| メッセージ| | 識別子| | | +-- -- -- -- -- -- -- --|-- -- -- -- -- -- -- --|--|-- -- -- -- -- -+ v| v| +------------------------+ +----------------------+ | | | | | | +--| コンプレッサー| | 減圧装置| <、-+ | | | 発送者| | 発送者| | | | | | | | | | | +------------------------+ +----------------------+ | | | ^ ^ ^ | | | | | | | | | | v| | | | | +--------------+ +---------------+ | | | | | | | | +-------+ | v| | | | | コンプレッサー1| <、-、-、-、--、>|状態1| | +--------------+ | | | | | | | +-------+ | | | | | | | +--------------+ | | | 減圧装置| | | | | | 州の操作者| <-->、|、|、|、|、|、| +--------------+ | | | (UDVM) | | | | | | | | +-------+ | | | | | | +->| コンプレッサー2| <、-、-、-、--、>|状態2| | +--------------+ | | | | | | +-------+ | | | | +--------------+ +---------------+ SigComp層| | | | | +-| -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --|-+ | | | SigComp SigComp| | メッセージメッセージ| v| +-------------------------------------------------------------------+ | | | トランスポート層| | | +-------------------------------------------------------------------+
Figure 1: High-level architectural overview of one SigComp endpoint
図1: 1つのSigComp終点のハイレベルの建築概要
Price, et. al. Standards Track [Page 6] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[6ページ]RFC3320
Note that SigComp is offered to applications as a layer between the application and the underlying transport, and so Figure 1 is an endpoint when viewed from a transport layer perspective. From the perspective of multi-hop application layer protocols however, SigComp is applied on a per-hop basis.
トランスポート層見解から見られたら、SigCompが図1が終点であるためにアプリケーションと基本的な輸送の間の層としてアプリケーションに提供されることに注意してください。 しかしながら、マルチホップ応用層プロトコルの見解から、SigCompは1ホップあたり1個のベースで適用されます。
The SigComp layer is further decomposed into the following entities:
SigComp層はさらに以下の実体に分解されます:
1. Compressor dispatcher - the interface from the application. The
application supplies the compressor dispatcher with an application
message and a compartment identifier (see Section 3.1 for further
details). The compressor dispatcher invokes a particular
compressor, which returns a SigComp message to be forwarded to the
remote endpoint.
1. コンプレッサー発送者--アプリケーションからのインタフェース。 アプリケーションはアプリケーションメッセージとコンパートメント識別子をコンプレッサー発送者に提供します(さらに詳しい明細についてはセクション3.1を見てください)。 コンプレッサー発送者は特定のコンプレッサーを呼び出します。(それは、遠く離れた終点に送られるべきSigCompメッセージを返します)。
2. Decompressor dispatcher - the interface towards the application.
The decompressor dispatcher receives a SigComp message and invokes
an instance of the Universal Decompressor Virtual Machine (UDVM).
It then forwards the resulting decompressed message to the
application, which may return a compartment identifier if it
wishes to allow state to be saved for the message.
2. 減圧装置発送者--アプリケーションに向かったインタフェース。 減圧装置発送者は、SigCompメッセージを受け取って、Universal Decompressor Virtual Machine(UDVM)のインスタンスを呼び出します。 そして、それは結果として起こる減圧されたメッセージをアプリケーションに転送します。(状態がメッセージのために節約されるのを許容したいなら、それは、コンパートメント識別子を返すかもしれません)。
3. One or more compressors - the entities that convert application
messages into SigComp messages. Distinct compressors are invoked
on a per-compartment basis, using the compartment identifiers
supplied by the application. A compressor receives an application
message from the compressor dispatcher, compresses the message,
and returns a SigComp message to the compressor dispatcher. Each
compressor chooses a certain algorithm to encode the data (e.g.,
DEFLATE).
3. 1個以上のコンプレッサー--アプリケーションメッセージをSigCompメッセージに変換する実体。 アプリケーションで提供されたコンパートメント識別子を使用して、異なったコンプレッサーは1コンパートメントあたり1個のベースに呼び出されます。 コンプレッサーは、コンプレッサー発送者にコンプレッサー発送者からアプリケーションメッセージを受け取って、メッセージを圧縮して、SigCompメッセージを返します。 各コンプレッサーは、データ(例えば、DEFLATE)をコード化するためにあるアルゴリズムを選びます。
4. UDVM - the entity that decompresses SigComp messages. Note that
since SigComp can run over an unsecured transport layer, a
separate instance of the UDVM is invoked on a per-message basis.
However, during the decompression process the UDVM may invoke the
state handler to access existing state or create new state.
4. UDVM--SigCompメッセージを減圧する実体。 SigCompが非機密保護しているトランスポート層をひくことができるのでUDVMの別々のインスタンスが1メッセージあたり1個のベースに呼び出されることに注意してください。 しかしながら、減圧プロセスの間、UDVMは、現状にアクセスするか、または新しい状態を創設するために州の操作者を呼び出すかもしれません。
5. State handler - the entity that can store and retrieve state.
State is information that is stored between SigComp messages,
avoiding the need to upload the data on a per-message basis. For
security purposes it is only possible to create new state with the
permission of the application. State creation and retrieval are
further described in Chapter 6.
5. 操作者を述べてください--状態を保存して、検索できる実体。 状態は1メッセージあたり1個のベースにデータをアップロードする必要性を避けて、SigCompメッセージの間に保存される情報です。 単にセキュリティ目的のために、アプリケーションの許可で新しい状態を創設するのは可能です。 州の作成と検索は第6章でさらに説明されます。
Price, et. al. Standards Track [Page 7] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[7ページ]RFC3320
When compressing a bidirectional application protocol the choice to use SigComp can be made independently in both directions, and compression in one direction does not necessarily imply compression in the reverse direction. Moreover, even when two communicating endpoints send SigComp messages in both directions, there is no need to use the same compression algorithm in each direction.
双方向のアプリケーション・プロトコルを圧縮するとき、独自にSigCompを使用する選択を両方の方向にすることができます、そして、一方向への圧縮は必ず反対の方向に圧縮を含意するというわけではありません。 2つの交信終点が両方の方向によるメッセージをSigCompに送るときさえ、そのうえ、同じ圧縮アルゴリズムを各方向に使用する必要は全くありません。
Note that a SigComp endpoint can decompress messages from multiple remote endpoints at different locations in a network, as the architecture is designed to prevent SigComp messages from one endpoint interfering with messages from a different endpoint. A consequence of this design choice is that it is difficult for a malicious user to disrupt SigComp operation by inserting false compressed messages on the transport layer.
SigComp終点がネットワークで別の場所の複数の遠く離れた終点からのメッセージを減圧できることに注意してください、アーキテクチャが1つの終点からSigCompメッセージを防ぐように異なった終点からのメッセージを妨げながら設計されているとき。 このデザイン選択の結果は悪意あるユーザーが誤った圧縮されたメッセージをトランスポート層に挿入することによってSigComp操作を中断するのが、難しいということです。
3.1. Requirements on the Application
3.1. アプリケーションに関する要件
From an application perspective the SigComp layer appears as a new transport, with similar behavior to the original transport used to carry uncompressed data (for example SigComp/UDP behaves similarly to native UDP).
アプリケーションから、SigComp層が運ぶのに使用されるオリジナルの輸送への同様の振舞いと共に新しい輸送として見える見解はデータを解凍しました(例えば、SigComp/UDPは同様にネイティブのUDPに振る舞います)。
Mechanisms for discovering whether an endpoint supports SigComp are beyond the scope of this document.
終点がSigCompをサポートするかどうか発見するためのメカニズムはこのドキュメントの範囲を超えています。
All SigComp messages contain a prefix (the five most-significant bits of the first byte are set to one) that does not occur in UTF-8 encoded text messages [RFC-2279], so for applications which use this encoding (or ASCII encoding) it is possible to multiplex uncompressed application messages and SigComp messages on the same port. Applications can still reserve a new port specifically for SigComp however (e.g., as part of the discovery mechanism).
すべてのSigCompメッセージがコード化されたテキストが通信させるUTF-8[RFC-2279]に起こらない接頭語(最初のバイトの5つの最上位ビットが1つに設定される)を含んでいるので、アプリケーションのために、どれが多重送信するのが可能であるこのコード化(または、ASCIIコード化)を使用するかが同じポートに関するアプリケーションメッセージとSigCompメッセージを解凍しました。 しかしながら(例えば、発見メカニズムの一部として)、アプリケーションは特にSigCompのためにまだ新しいポートを予約できます。
If a particular endpoint wishes to be stateful then it needs to partition its decompressed messages into "compartments" under which state can be saved. SigComp relies on the application to provide this partition. So for stateful endpoints a new interface is required to the application in order to leverage the authentication mechanisms used by the application itself.
特定の終点がstatefulになりたがっているなら、それは、状態を節約できる「コンパートメント」に減圧されたメッセージを仕切る必要があります。 SigCompは、このパーティションを提供するためにアプリケーションに依存します。 それで、stateful終点に関して、新しいインタフェースが、認証がアプリケーション自体で使用されるメカニズムであると利用するのにアプリケーションに必要です。
When the application receives a decompressed message it maps the message to a certain compartment and supplies the compartment identifier to SigComp. Each compartment is allocated a separate compressor and a certain amount of memory to store state information, so the application must assign distinct compartments to distinct remote endpoints. However it is possible for a local endpoint to establish several compartments that relate to the same remote endpoint (this should be avoided where possible as it may waste
アプリケーションが減圧されたメッセージを受け取るとき、それは、あるコンパートメントにメッセージを写像して、コンパートメント識別子をSigCompに供給します。 州の情報を保存するために別々のコンプレッサーとある量のメモリを各コンパートメントに割り当てるので、アプリケーションは異なった遠く離れた終点に異なったコンパートメントを割り当てなければなりません。 しかしながら、地方の終点が同じ遠く離れた終点に関連するいくつかのコンパートメントを設置するのが、可能である、(むだになるかもしれなくて、これは可能であるところで避けられるべきです。
Price, et. al. Standards Track [Page 8] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[8ページ]RFC3320
memory and reduce the overall compression ratio, but it does not cause messages to be incorrectly decompressed). In this case, reliable stateful operation is possible only if the decompressor does not lump several messages into one compartment when the compressor expected them to be assigned different compartments.
メモリ、総合的な圧縮比を低下させてくださいが、それが不当に減圧されるべきメッセージを引き起こさない、) この場合、コンプレッサーが、異なったコンパートメントがそれらに割り当てられると予想したとき、減圧装置がいくつかのメッセージを1つのコンパートメントにひとまとめにしない場合にだけ、信頼できるstateful操作は可能です。
The exact format of the compartment identifier is unimportant provided that different identifiers are given to different compartments.
異なった識別子を異なったコンパートメントに与えれば、コンパートメント識別子の正確な形式は重要ではありません。
Applications that wish to communicate using SigComp in a stateful fashion should use an authentication mechanism to securely map decompressed messages to compartment identifiers. They should also agree on any limits to the lifetime of a compartment, to avoid the case where an endpoint accesses state information that has already been deleted.
statefulファッションでSigCompを使用することで交信したがっているアプリケーションは、しっかりと減圧されたメッセージをコンパートメント識別子に写像するのに認証機構を使用するべきです。 また、彼らは、終点が既に削除された州の情報にアクセスするケースを避けるためにコンパートメントの生涯へのどんな限界にも同意するべきです。
3.2. SigComp feedback mechanism
3.2. SigCompフィードバック・メカニズム
If a signaling protocol sends SigComp messages in both directions and
there is a one-to-one relationship between the compartments
established by the applications on both ends ("peer compartments"),
the two endpoints can cooperate more closely. In this case, it is
possible to send feedback information that monitors the behavior of
an endpoint and helps to improve the overall compression ratio.
SigComp performs feedback on a request/response basis, so a
compressor makes a feedback request and receives some feedback data
in return. The procedure for requesting and returning feedback in
SigComp is illustrated in Figure 2:
シグナリングプロトコルが両方の方向によるメッセージをSigCompに送って、両端(「同輩コンパートメント」)でアプリケーションで設置されたコンパートメントの間には、1〜1つの関係があれば、2つの終点が、より密接に協力できます。 この場合、終点の振舞いをモニターして、総合的な圧縮比を改良するのを助けるフィードバック情報を送るのは可能です。 SigCompが要求/応答ベースのフィードバックを実行するので、コンプレッサーは、フィードバック要求をして、代わりにいくつかのフィードバックデータを受け取ります。 SigCompでのフィードバックを要求して、返すための手順は図2で例証されます:
Price, et. al. Standards Track [Page 9] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[9ページ]RFC3320
+---------------------+ +---------------------+
| +-----------------+ | | +-----------------+ |
-->| Compressor |------------------------>| UDVM |<->
| | sending to B | | SigComp message | | | |2
| +-----------------+ | requesting feedback | +-----------------+ |
| ^ 1,9 | | 3 | |
| | | | v |
| +-----------------+ | | +-----------------+ |
| | State | | | | State | |
| | handler | | | | handler | |
| +-----------------+ | | +-----------------+ |
| ^ 8 | | 4 | |
| | | | v |
| +-----------------+ | | +-----------------+ |
| | UDVM | | | | Compressor | |
<->| |<------------------------| sending to A |<--
6| +-----------------+ | SigComp message | +-----------------+ |
| 7 | returning feedback | 5 |
| Endpoint A | | Endpoint B |
+---------------------+ +---------------------+
+---------------------+ +---------------------+ | +-----------------+ | | +-----------------+ | -->| コンプレッサー|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| UDVM| <->|、| Bに発信します。| | SigCompメッセージ| | | |2 | +-----------------+ | フィードバックを要求します。| +-----------------+ | | ^ 1,9 | | 3 | | | | | | v| | +-----------------+ | | +-----------------+ | | | 状態| | | | 状態| | | | 操作者| | | | 操作者| | | +-----------------+ | | +-----------------+ | | ^ 8 | | 4 | | | | | | v| | +-----------------+ | | +-----------------+ | | | UDVM| | | | コンプレッサー| | <->| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| Aに発信します。| <-- 6| +-----------------+ | SigCompメッセージ| +-----------------+ | | 7 | 戻っているフィードバック| 5 | | 終点A| | 終点B| +---------------------+ +---------------------+
Figure 2: Steps involved in the transmission of feedback data
図2: フィードバックデータの伝達にかかわるステップ
The dispatchers, the application and the transport layer are omitted from the diagram for clarity. Note that the decompressed messages pass via the decompressor dispatcher to the application; moreover the SigComp messages transmitted from the compressor to the remote UDVM are sent via first the compressor dispatcher, followed by the transport layer and finally the decompressor dispatcher.
発送者、アプリケーション、およびトランスポート層は明快ためにダイヤグラムから省略されます。 減圧されたメッセージがアプリケーションへの減圧装置発送者を通して終わることに注意してください。 そのうえ、最初に、トランスポート層が支えたコンプレッサー発送者と最終的に減圧装置発送者を通してコンプレッサーからリモートUDVMまで送られたSigCompメッセージを送ります。
The steps for requesting and returning feedback data are described in more detail below:
フィードバックデータを要求して、返すためのステップはさらに詳細に以下で説明されます:
1. The compressor that sends messages to Endpoint B piggybacks a
feedback request onto a SigComp message.
1. Endpoint Bにメッセージを送るコンプレッサーはフィードバック要求をSigCompメッセージに背負います。
2. When the application receives the decompressed message, it may
return the compartment identifier for the message.
2. アプリケーションが減圧されたメッセージを受け取るとき、それはメッセージのためのコンパートメント識別子を返すかもしれません。
3. The UDVM in Endpoint B forwards the requested feedback data to the
state handler.
3. Endpoint BのUDVMは要求されたフィードバックデータを州の操作者に転送します。
4. If the UDVM can supply a valid compartment identifier, then the
state handler forwards the feedback data to the appropriate
compressor (namely the compressor sending to Endpoint A).
4. UDVMが有効なコンパートメント識別子を提供できるなら、州の操作者は適切なコンプレッサー(すなわち、Endpoint Aに発信するコンプレッサー)にフィードバックデータを転送します。
5. The compressor returns the requested feedback data to Endpoint A
piggybacked onto a SigComp message.
5. コンプレッサーはSigCompメッセージに背負われたEndpoint Aに要求されたフィードバックデータを返します。
Price, et. al. Standards Track [Page 10] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[10ページ]RFC3320
6. When the application receives the decompressed message, it may
return the compartment identifier for the message.
6. アプリケーションが減圧されたメッセージを受け取るとき、それはメッセージのためのコンパートメント識別子を返すかもしれません。
7. The UDVM in Endpoint A forwards the returned feedback data to the
state handler.
7. Endpoint AのUDVMは返されたフィードバックデータを州の操作者に転送します。
8. If the UDVM can supply a valid compartment identifier, then the
state handler forwards the feedback data to the appropriate
compressor (namely the compressor sending to Endpoint B).
8. UDVMが有効なコンパートメント識別子を提供できるなら、州の操作者は適切なコンプレッサー(すなわち、Endpoint Bに発信するコンプレッサー)にフィードバックデータを転送します。
9. The compressor makes use of the returned feedback data.
9. コンプレッサーは返されたフィードバックデータを利用します。
The detailed role played by each entity in the transmission of feedback data is explained in subsequent chapters.
フィードバックデータの伝達における各実体によって果たされた詳細な役割はすぐ次の章で説明されます。
3.3. SigComp Parameters
3.3. SigCompパラメタ
An advantage of using a virtual machine for decompression is that almost all of the implementation flexibility lies in the SigComp compressors. When receiving SigComp messages an endpoint generally behaves in a predictable manner.
減圧に仮想計算機を使用する利点は実装の柔軟性のほとんどすべてがSigCompコンプレッサーにあるということです。 SigCompメッセージを受け取るとき、一般に、終点は予測できる態度で振る舞います。
Note however that endpoints implementing SigComp will typically have a wide range of capabilities, each offering a different amount of working memory, processing power etc. In order to support this wide variation in endpoint capabilities, the following parameters are provided to modify SigComp behavior when receiving SigComp messages:
しかしながら、SigCompを実装する終点がさまざまな能力を通常持つことに注意してください、それぞれ異なった量の処理能力ワーキングメモリなどを提供して 終点能力のこの広い変化をサポートして、SigCompメッセージを受け取るとき、SigCompの振舞いを変更するために以下のパラメタを提供します:
decompression_memory_size state_memory_size cycles_per_bit SigComp_version locally available state (a set containing 0 or more state items)
減圧_メモリ_サイズ状態_メモリ_サイズは局所的に利用可能な状態を_噛み付いているSigComp_バージョンあたりの_に循環させます。(0つ以上の州の項目を含むセット)
Each parameter has a minimum value that MUST be offered by all receiving SigComp endpoints. Moreover, endpoints MAY offer additional resources if available; these resources can be advertised to remote endpoints using the SigComp feedback mechanism.
各パラメタには、SigComp終点を受けて、すべてで提供しなければならない最小値があります。 そのうえ、利用可能であるなら、終点は追加リソースを提供するかもしれません。 SigCompフィードバック・メカニズムを使用することで遠く離れた終点にこれらのリソースの広告を出すことができます。
Particular applications may also agree a-priori to offer additional resources as mandatory (e.g., SigComp for SIP offers a dictionary of common SIP phrases as a mandatory state item).
また、特定用途は、義務的であるとして追加リソースを提供するのに先験的に同意するかもしれません(例えば、SIPのためのSigCompは義務的な州の項目として一般的なSIP句の辞書を提供します)。
Each of the SigComp parameters is described in greater detail below.
それぞれのSigCompパラメタは以下で詳細によりすばらしい説明されます。
Price, et. al. Standards Track [Page 11] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[11ページ]RFC3320
3.3.1. Memory Size and UDVM Cycles
3.3.1. 記憶容量とUDVMサイクルズ
The decompression_memory_size parameter specifies the amount of memory available to decompress one SigComp message. (Note that the term "amount of memory" is used on a conceptual level in order to specify decompressor behavior and allow resource planning on the side of the compressor -- an implementation could require additional, bounded amounts of actual memory resources or could even organize its memory in a completely different way as long as this does not cause decompression failures where the conceptual model would not.) A portion of this memory is used to buffer a SigComp message before it is decompressed; the remainder is given to the UDVM. Note that the memory is allocated on a per-message basis and can be reclaimed after the message has been decompressed. All endpoints implementing SigComp MUST offer a decompression_memory_size of at least 2048 bytes.
減圧_メモリ_サイズ・パラメータは1つのSigCompメッセージを減圧するために有効なメモリー容量を指定します。 (「メモリー容量」という用語がコンプレッサーの側面に減圧装置の振舞いを指定して、資源計画を許容するのに概念的なレベルで使用されることに注意してください--実現は、概念モデルが組織化しないだろうところで追加していて、境界がある量の実際のメモリリソースを必要とすることができたか、またはこれが減圧失敗を引き起こさない限り、完全に異なった方法でメモリを組織化さえするかもしれません。) このメモリの部分はそれが減圧される前にSigCompメッセージをバッファリングするのに使用されます。 残りをUDVMに与えます。 メモリを1メッセージあたり1個のベースに割り当てて、メッセージが減圧された後に取り戻すことができることに注意してください。 SigCompを実行するすべての終点が少なくとも2048バイトの減圧_メモリ_サイズを提供しなければなりません。
The state_memory_size parameter specifies the number of bytes offered to a particular compartment for the creation of state. This parameter is set to 0 if the endpoint is stateless.
状態_メモリ_サイズ・パラメータは状態の創設のために特定のコンパートメントに提供されたバイト数を指定します。 終点が国がないなら、このパラメタは0に設定されます。
Unlike the other SigComp parameters, the state_memory_size is offered on a per-compartment basis and may vary for different compartments. The memory for a compartment is reclaimed when the application determines that the compartment is no longer required.
他のSigCompパラメタと異なって、状態_メモリ_サイズは、1コンパートメントあたり1個のベースに対しては提供されて、異なったコンパートメントに異なるかもしれません。 アプリケーションが、コンパートメントはもう必要でないことを決定すると、コンパートメントのためのメモリが取り戻されます。
The cycles_per_bit parameter specifies the number of "UDVM cycles" available to decompress each bit in a SigComp message. Executing a UDVM instruction requires a certain number of UDVM cycles; a complete list of UDVM instructions and their cost in UDVM cycles can be found in Chapter 9. An endpoint MUST offer a minimum of 16 cycles_per_bit.
1_あたりの_に噛み付いたサイクルに、パラメタはSigCompメッセージで各ビットを減圧するために利用可能な「UDVMサイクル」の数を指定します。 UDVM指示を実行するのはある数のUDVMサイクルを必要とします。 第9章でUDVM指示に関する全リストとUDVMサイクルのそれらの費用を見つけることができます。 終点は_ビットあたりの最低16サイクルの_を提供しなければなりません。
Each of the three parameter values MUST be chosen from the limited set given below, so that the parameters can be efficiently encoded for transmission using the SigComp feedback mechanism.
以下に与えられた限られたセットからそれぞれの3つのパラメタ値を選ばなければなりません、トランスミッションのためにSigCompフィードバック・メカニズムを使用することで効率的にパラメタをコード化できるように。
The cycles_per_bit parameter is encoded using 2 bits, whilst the decompression_memory_size and state_memory_size are both encoded using 3 bits. The bit encodings and their corresponding values are as follows:
1_あたりの_に噛み付いたサイクルに、パラメタは2ビットを使用することでコード化されますが、減圧_メモリ_サイズと州の_メモリ_サイズは、3ビットを使用することでともにコード化されます。 ビットencodingsと彼らの換算値は以下の通りです:
Price, et. al. Standards Track [Page 12] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[12ページ]RFC3320
Encoding: cycles_per_bit: Encoding: state_memory_size (bytes):
コード化します: 1_あたりのサイクル_に噛み付きました: コード化します: _メモリ_サイズ(バイト)を述べてください:
00 16 000 0
01 32 001 2048
10 64 010 4096
11 128 011 8192
100 16384
101 32768
110 65536
111 131072
00 16 000 0 01 32 001 2048 10 64 010 4096 11 128 011 8192 100 16384 101 32768 110 65536 111 131072
The decompression_memory_size is encoded in the same manner as the state_memory_size, except that the bit pattern 000 cannot be used (as an endpoint cannot offer a decompression_memory_size of 0 bytes).
減圧_メモリ_サイズは状態_メモリ_サイズと同じ方法でコード化されます、ビット・パターン000を使用できないのを除いて(終点が0バイトの減圧_メモリ_サイズを提供できないとき)。
3.3.2. SigComp Version
3.3.2. SigCompバージョン
The SigComp_version parameter specifies whether only the basic version of SigComp is available, or whether an upgraded version is available offering additional instructions etc. Within the UDVM, it is available as a 2-byte value, generated by zero-extending the 1- byte SigComp_version parameter (i.e., the first byte of the 2-byte value is always zero).
追加指示になどを提供するSigCompの基本的なバージョンだけが利用可能であるか、またはアップグレードしたバージョンが利用可能であることにかかわらず_バージョンパラメタが指定するSigComp UDVMの中では、それは2バイトの値として利用可能です、無の広がりによる1の発生しているバイトSigComp_バージョンパラメタ(いつもすなわち、2バイトの価値の最初のバイトはゼロです)。
The basic version of SigComp is Version 0x01, which is the version described in this document.
SigCompの基本的なバージョンはバージョン0x01です。(そのバージョンは本書では説明されたバージョンです)。
To ensure backwards compatibility, if a SigComp message is successfully decompressed by Version 0x01 of SigComp then it will be successfully decompressed on upgraded versions. Similarly, if the message triggers a manual decompression failure (see Section 8.7), then it will also continue to do so.
後方に互換性を確実にするために、SigCompメッセージがSigCompのバージョン0x01によって首尾よく減圧されると、それはアップグレードしたバージョンで首尾よく減圧されるでしょう。 また、メッセージが手動の減圧失敗の引き金となると(セクション8.7を見てください)、それは、同様に、そうし続けるでしょう。
However, messages that cause an unexpected decompression failure on Version 0x01 of SigComp may be successfully decompressed by upgraded versions.
しかしながら、SigCompのバージョン0x01で予期していなかった減圧失敗を引き起こすメッセージはアップグレードしたバージョンによって首尾よく減圧されるかもしれません。
The simplest way to upgrade SigComp in a backwards-compatible manner is to add additional UDVM instructions, as this will not affect the decompression of SigComp messages compatible with Version 0x01. Reserved addresses in the UDVM memory (Useful Values, see Section 7.2) may also be assigned values in future versions of SigComp.
後方にコンパチブル方法でSigCompをアップグレードさせる最も簡単な方法は追加UDVM指示を加えることです、これがバージョン0x01とのコンパチブルSigCompメッセージの減圧に影響しないとき。 また、UDVMメモリ(役に立つValues、セクション7.2を見る)の予約されたアドレスはSigCompの将来のバージョンの割り当てられた値であるかもしれません。
Price, et. al. Standards Track [Page 13] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[13ページ]RFC3320
3.3.3. Locally Available State Items
3.3.3. 局所的に利用可能な州の項目
A SigComp state item is an item of data that is retained between SigComp messages. State items can be retrieved and loaded into the UDVM memory as part of the decompression process, often significantly improving the compression ratio as the same information does not have to be uploaded on a per-message basis.
SigComp州の品目はSigCompメッセージの間で保有されるデータの項目です。 州の項目を検索して、減圧の過程の一部としてUDVMメモリにロードできます、同じ情報が1メッセージあたり1個のベースでアップロードされる必要はないので圧縮比をしばしばかなり改良して。
Each endpoint maintains a set of state items where every item is composed of the following information:
各終点はあらゆる項目が以下の情報で構成される1セットの州の項目を維持します:
Name: Type of data:
以下を命名してください。 データのタイプ:
state_identifier 20-byte value state_length 2-byte value state_address 2-byte value state_instruction 2-byte value minimum_access_length 2-byte value from 6 to 20 inclusive state_value String of state_length consecutive bytes
状態_識別子の20バイトの値の状態_長さの2バイトの値の状態_アドレスの2バイトの値の状態_指示の2バイトの値の最小の_は状態_長さの連続したバイトの6〜20の包括的な状態_値のStringから_長さの2バイトの値にアクセスします。
State items are typically created at an endpoint upon successful decompression of a SigComp message. The remote compressor sending the message makes a state creation request by invoking the appropriate UDVM instruction, and the state is saved once permission is granted by the application.
州の項目はSigCompメッセージのうまくいっている減圧のときに終点で通常作成されます。 アプリケーションでいったん許可を与えると、州の創造がメッセージから適切なUDVM指示、および状態を呼び出すことによって要求するリモートコンプレッサー発信を救います。
However, an endpoint MAY also wish to offer a set of locally available state items that have not been uploaded as part of a SigComp message. For example it might offer well-known decompression algorithms, dictionaries of common phrases used in a specific signaling protocol, etc.
しかしながら、また、終点はSigCompメッセージの一部としてアップロードされていない1セットの局所的に利用可能な州の商品を提供したがっているかもしれません。 例えば、それは周知の減圧アルゴリズム、特定のシグナリングプロトコルなどに使用される普通の文句の辞書を提供するかもしれません。
Since these state items are established locally without input from a remote endpoint, they are most useful if publicly documented so that a wide collection of remote endpoints can determine the data contained in each state item and how it may be used. Further Internet Documents and RFCs may be published to describe particular locally available state items.
これらの州の項目が遠く離れた終点からの入力なしで局所的に確立されるので、遠く離れた終点の広い収集がそれぞれの州の項目に含まれたデータとそれがどう使用されるかもしれないかを決定できるように公的に記録されるなら、それらは最も役に立ちます。 さらに、インターネットDocumentsとRFCsは、特定の局所的に利用可能な州の項目について説明するために発行されるかもしれません。
Although there are no locally available state items that are mandatory for every SigComp endpoint, certain state items can be made mandatory in a specific environment (e.g., the dictionary of common phrases for a specific signaling protocol could be made mandatory for that signaling protocol's usage of SigComp). Also, remote endpoints can indicate their interest in receiving a list of some of the state items available locally at an endpoint using the SigComp feedback mechanism.
どんなあらゆるSigComp終点に義務的な局所的に利用可能な州の項目もありませんが、ある州の項目を特定の環境で義務的にすることができます(例えば特定のシグナリングプロトコルのための普通の文句の辞書をそのシグナリングプロトコルのSigCompの使用法に義務的にすることができました)。 また、遠く離れた終点は終点にSigCompフィードバック・メカニズムを使用することで局所的に利用可能ないくつかの州の項目のリストを受け取ることへの彼らの関心を示すことができます。
Price, et. al. Standards Track [Page 14] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[14ページ]RFC3320
It is a matter of local decision for an endpoint what items of locally available state it advertises; this decision has no influence on interoperability, but may increase or decrease the efficiency of the compression achievable between the endpoints.
それが局所的に利用可能な状態のどんな項目の広告を出すかは、終点のためのローカルの決定の問題です。 この決定は影響を全く相互運用性に与えません、終点の間で達成可能な圧縮の効率を増加するか、または減少させるかもしれないのを除いて。
4. SigComp Dispatchers
4. SigComp発送者
This chapter defines the behavior of the compressor and decompressor dispatcher. The function of these entities is to provide an interface between SigComp and its environment, minimizing the effort needed to integrate SigComp into an existing protocol stack.
本章はコンプレッサーと減圧装置発送者の振舞いを定義します。 これらの実体の関数はSigCompとその環境とのインタフェースを提供することです、既存のプロトコル・スタックとSigCompを統合するのに必要である努力を最小にして。
4.1. Compressor Dispatcher
4.1. コンプレッサー発送者
The compressor dispatcher receives messages from the application and passes the compressed version of each message to the transport layer.
コンプレッサー発送者は、トランスポート層にアプリケーションからメッセージを受け取って、それぞれのメッセージの圧縮されたバージョンを移ります。
Note that SigComp invokes compressors on a per-compartment basis, so when the application provides a message to be compressed it must also provide a compartment identifier. The compressor dispatcher forwards the application message to the correct compressor based on the compartment identifier (invoking a new compressor if a new compartment identifier is encountered). The compressor returns a SigComp message that can be passed to the transport layer.
また、アプリケーションが圧縮されるべきメッセージを提供するときコンパートメント識別子を提供しなければならないためにSigCompが1コンパートメントあたり1個のベースにコンプレッサーを呼び出すことに注意してください。 コンプレッサー発送者はコンパートメント識別子に基づく正しいコンプレッサーにアプリケーションメッセージを転送します(新しいコンパートメント識別子が遭遇するなら新しいコンプレッサーを呼び出して)。 コンプレッサーはトランスポート層に通過できるSigCompメッセージを返します。
Additionally, the application should indicate to the compressor dispatcher when it wishes to close a particular compartment, so that the resources taken by the corresponding compressor can be reclaimed.
さらに、アプリケーションは、それがいつ特定のコンパートメントを閉じたがっているかをコンプレッサー発送者に示すべきです、対応するコンプレッサーによって取られたリソースは取り戻すことができるように。
4.2. Decompressor Dispatcher
4.2. 減圧装置発送者
The decompressor dispatcher receives messages from the transport layer and passes the decompressed version of each message to the application.
減圧装置発送者は、トランスポート層からメッセージを受け取って、それぞれのメッセージの減圧されたバージョンをアプリケーションに移ります。
To ensure that SigComp can run over an unsecured transport layer, the decompressor dispatcher invokes a new instance of the UDVM for each new SigComp message. Resources for the UDVM are released as soon as the message has been decompressed.
SigCompが非安全にされたトランスポート層をひくことができるのを保証するために、減圧装置発送者はそれぞれの新しいSigCompメッセージのためにUDVMの新しい例を呼び出します。 メッセージが減圧されるとすぐに、UDVMのためのリソースは発表されます。
The dispatcher MUST NOT make more than one SigComp message available to a given instance of the UDVM. In particular, the dispatcher MUST NOT concatenate two SigComp messages to form a single message.
発送者は1つ以上のSigCompメッセージをUDVMの与えられた例に利用可能にしてはいけません。 特に、発送者はただ一つのメッセージを形成する2つのSigCompメッセージを連結してはいけません。
Price, et. al. Standards Track [Page 15] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[15ページ]RFC3320
4.2.1. Decompressor Dispatcher Strategies
4.2.1. 減圧装置発送者戦略
Once the UDVM has been invoked it is initialized using the SigComp message of Chapter 7. The message is then decompressed by the UDVM, returned to the decompressor dispatcher, and passed on to the receiving application. Note that the UDVM has no awareness of whether the underlying transport is message-based or stream-based, and so it always outputs decompressed data as a stream. It is the responsibility of the dispatcher to provide the decompressed message to the application in the expected form (i.e., as a stream or as a distinct, bounded message). The dispatcher knows that the end of a decompressed message has been reached when the UDVM instruction END- MESSAGE is invoked (see Section 9.4.9).
UDVMがいったん呼び出されると、それは、第7章のSigCompメッセージを使用することで初期化されます。 メッセージは、次に、減圧装置発送者に返されたUDVMが減圧されて、受信アプリケーションに通過されます。 UDVMには基本的な輸送がメッセージベースである、または流れのベースであるかに関する認識が全くないことに注意してくださいので、それは流れとしていつも減圧されたデータを出力します。 発送者は予想されたフォーム(流れとした、または、すなわち、異なって、境界があるメッセージとした)で減圧されたメッセージをアプリケーションに提供する責任です。 発送者は、UDVM指示END- MESSAGEが呼び出されるとき(セクション9.4.9を見てください)、減圧されたメッセージの端に達したのを知っています。
For a stream-based transport, two strategies are therefore possible for the decompressor dispatcher:
したがって、流れのベースの輸送のために、減圧装置発送者に、2つの戦略が可能です:
1) The dispatcher collects a complete SigComp message and then
invokes the UDVM. The advantage is that, even in implementations
that have multiple incoming compressed streams, only one instance
of the UDVM is ever required.
1) 発送者は、完全なSigCompメッセージを集めて、次に、UDVMを呼び出します。 利点はUDVMの1つの例だけが今までに複数の入って来る圧縮された流れを持っている実現でさえ必要であるということです。
2) The dispatcher collects the SigComp header (see Section 7) and
invokes the UDVM; the UDVM stays active while the rest of the
message arrives. The advantage is that there is no need to buffer
up the rest of the message; the message can be decompressed as it
arrives, and any decompressed output can be relayed to the
application immediately.
2) 発送者は、SigCompヘッダー(セクション7を見る)を集めて、UDVMを呼び出します。 メッセージの残りは到着しますが、UDVMはアクティブなままです。 利点はメッセージの残りにバッファリングする必要は全くないということです。 到着するとき、メッセージを減圧できます、そして、すぐに、どんな減圧された出力もアプリケーションにリレーできます。
In general, which of the strategies is used is an implementation choice.
一般に、戦略のどれが使用されているかは、実現選択です。
However, the compressor may want to take advantage of strategy 2 by
expecting that some of the application message is passed on to the
application before the SigComp message is terminated, e.g., by
keeping the UDVM active while expecting the application to
continuously receive decompressed output. This approach ("continuous
mode") invalidates some assumptions of the SigComp security model and
can only be used if the transport itself can provide the required
protection against denial of service attacks. Also, since only
strategy 2 works in this approach, the use of continuous mode
requires previous agreement between the two endpoints.
しかしながら、SigCompメッセージが終えられる前にアプリケーションメッセージのいくつかがアプリケーションに通過されると予想することによって、コンプレッサーは戦略2を利用したがっているかもしれません、例えば、絶え間なく受け取るアプリケーションが出力を減圧したと予想している間、UDVMをアクティブに保つことによって。 輸送自体がサービス不能攻撃に対する必要な保護を提供できる場合にだけ、このアプローチ(「連続モード」)は、SigComp機密保護モデルのいくつかの仮定を無効にして、使用できます。 また、戦略2だけがこのアプローチで利くので、連続モードの使用は2つの終点の間の前の協定を必要とします。
4.2.2. Record Marking
4.2.2. マークを記録してください。
For a stream-based transport, the dispatcher delimits messages by parsing the compressed data stream for instances of 0xFF and taking the following actions:
流れのベースの輸送のために、発送者は0xFFの例のための圧縮されたデータ・ストリームを分析して、以下の行動を取ることによって、メッセージを区切ります:
Price, et. al. Standards Track [Page 16] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[16ページ]RFC3320
Occurs in data stream: Action:
データ・ストリームで、起こります: 動作:
0xFF 00 one 0xFF byte in the data stream
0xFF 01 same, but the next byte is quoted (could
be another 0xFF)
: :
0xFF 7F same, but the next 127 bytes are quoted
0xFF 80 to 0xFF FE (reserved for future standardization)
0xFF FF end of SigComp message
データの0xFF00 1 0xFFのバイトは同じ状態で0xFF01を流しますが、次のバイトは引用されます(別の0xFFであるかもしれません): : 0xFF7F同じであることで、SigCompメッセージの0xFF FE(今後の標準化のために、予約される)0xFF FFエンドまで次の127バイトだけが引用された0xFF80です。
The combinations 0xFF01 to 0xFF7F are useful to limit the worst case expansion of the record marking scheme: the 1 (0xFF01) to 127 (0xFF7F) bytes following the byte combination are copied literally by the decompressor without taking any special action on 0xFF. (Note that 0xFF00 is just a special case of this, where zero following bytes are copied literally.)
0xFF7Fへの組み合わせ0xFF01は計画にマークする記録の最悪の場合拡大を制限するために役に立ちます: 1 0xFFへのどんな特別な行動も取らないで、バイト組み合わせに続く127(0xFF7F)バイトへの(0xFF01)は文字通り減圧装置によってコピーされます。 (0xFF00がただこの特別なケースであることに注意してください。)(そこでは、次のバイトが全く文字通りコピーされません)。
In UDVM version 0x01, any occurrence of the combinations 0xFF80 to 0xFFFE that are not protected by quoting causes decompression failure; the decompressor SHOULD close the stream-based transport in this case.
UDVMバージョン0x01、保護されない0xFFFEへの0xFF80が減圧失敗を引き起こすのを引用する組み合わせのどんな発生でも。 減圧装置SHOULDはこの場合流れのベースの輸送を終えます。
4.3. Returning a Compartment Identifier
4.3. コンパートメント識別子を返します。
Upon receiving a decompressed message the application may supply the dispatcher with a compartment identifier. Supplying this identifier grants permission for the following:
減圧されたメッセージを受け取ると、アプリケーションはコンパートメント識別子を発送者に提供するかもしれません。 この識別子を提供するのは以下のために許可を与えます:
1. Items of state accompanying the decompressed message can be saved
using the state memory reserved for the specified compartment.
1. 指定されたコンパートメントに予約された州のメモリを使用することで減圧されたメッセージに伴う州の項目を保存できます。
2. The feedback data accompanying the decompressed message can be
trusted sufficiently that it can be used when sending SigComp
messages that relate to the compressor's equivalent for the
compartment.
2. 減圧されたメッセージに伴うフィードバックデータはコンパートメントのためにコンプレッサーの同等物に関連するメッセージをSigCompに送るとき、それを使用できるように十分信じることができます。
The dispatcher passes the compartment identifier to the UDVM, where it is used as per the END-MESSAGE instruction (see Section 9.4.9).
発送者はコンパートメント識別子をUDVMに通過します。そこでは、それがEND-MESSAGE指示に従って使用されます(セクション9.4.9を見てください)。
The application uses a suitable authentication mechanism to determine whether the decompressed message belongs to a legitimate compartment or not. If the application fails to authenticate the message with sufficient confidence to allow state to be saved or feedback data to be trusted, it supplies a "no valid compartment" error to the dispatcher and the UDVM is terminated without creating any state or forwarding any feedback data.
アプリケーションは、減圧されたメッセージが正統のコンパートメントに属すかどうか決定するのに適当な認証機構を使用します。 アプリケーションが節約される状態かフィードバックデータが信じられるのを許容できるくらいの自信を伴うメッセージを認証しないなら、「有効なコンパートメントがありません」誤りを発送者に提供します、そして、どんな状態も創設するか、またはどんなフィードバックデータも転送しないで、UDVMは終えられます。
Price, et. al. Standards Track [Page 17] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[17ページ]RFC3320
5. SigComp Compressor
5. SigCompコンプレッサー
An important feature of SigComp is that decompression functionality is provided by a Universal Decompressor Virtual Machine (UDVM). This means that the compressor can choose any algorithm to generate compressed SigComp messages, and then upload bytecode for the corresponding decompression algorithm to the UDVM as part of the SigComp message.
SigCompの重要な特徴は減圧の機能性がUniversal Decompressor Virtual Machine(UDVM)によって提供されるということです。 これは、コンプレッサーが圧縮されたSigCompメッセージを発生させるようにどんなアルゴリズムも選んで、次に、対応する減圧アルゴリズムのためにSigCompメッセージの一部としてバイトコードをUDVMにアップロードできることを意味します。
To help with the implementation and testing of a SigComp endpoint, further Internet Documents and RFCs may be published to describe particular compression algorithms.
さらなるインターネットのSigComp終点、Documents、およびRFCsの実現とテストで助けるのは、特定の圧縮アルゴリズムを説明するために発行されるかもしれません。
The overall requirement placed on the compressor is that of transparency, i.e., the compressor MUST NOT send bytecode which causes the UDVM to incorrectly decompress a given SigComp message.
コンプレッサーに置かれた総合的な要件は透明では、すなわち、コンプレッサーがUDVMが不当に与えられたSigCompメッセージを減圧するバイトコードを送ってはいけないということです。
The following more specific requirements are also placed on the compressor (they can be considered particular instances of the transparency requirement):
また、以下の、より特定の要件はコンプレッサーに置かれます(透明要件の特定の例であるとそれらを考えることができます):
1. For robustness, it is recommended that the compressor supply some
form of integrity check (not necessarily of cryptographic
strength) over the application message to ensure that successful
decompression has occurred. A UDVM instruction is provided for
CRC verification; also, another instruction can be used to compute
a SHA-1 cryptographic hash.
1. 丈夫さにおいて、或るものが形成する保全のコンプレッサー供給がうまくいっている減圧が起こったのを保証するアプリケーションメッセージの上でチェックするのは(必ずどんな暗号の強さについてもそうしません)、お勧めです。 UDVM指示をCRC検証に提供します。 また、SHA-1の暗号の細切れ肉料理を計算するのに別の指示を使用できます。
2. The compressor MUST ensure that the message can be decompressed
using the resources available at the remote endpoint.
2. コンプレッサーは、遠く離れた終点で利用可能なリソースを使用することでメッセージを減圧できるのを確実にしなければなりません。
3. If the transport is message-based, then the compressor MUST map
each application message to exactly one SigComp message.
3. 輸送がメッセージベースであるなら、コンプレッサーはまさに1つのSigCompメッセージにそれぞれのアプリケーションメッセージを写像しなければなりません。
4. If the transport is stream-based but the application defines its
own internal message boundaries, then the compressor SHOULD map
each application message to exactly one SigComp message.
4. 輸送が流れのベースですが、アプリケーションがそれ自身の社内通信文限界を定義するなら、コンプレッサーSHOULDはまさに1つのSigCompメッセージにそれぞれのアプリケーションメッセージを写像します。
Message boundaries should be preserved over a stream-based transport so that accidental or malicious damage to one SigComp message does not affect the decompression of subsequent messages.
メッセージ限界が流れのベースの輸送の上に保持されるべきであるので、1つのSigCompメッセージへの偶然の、または、悪意がある損害はその後のメッセージの減圧に影響しません。
Additionally, if the state handler passes some requested feedback to the compressor, then it SHOULD be returned in the next SigComp message generated by the compressor (unless the state handler passes some newer requested feedback before the older feedback has been sent, in which case the older feedback is deleted).
州の操作者が通るなら、さらに、或るものはコンプレッサーにフィードバックを要求して、次に、それはSHOULDです。コンプレッサーで発生する次のSigCompメッセージで返してください(より古いフィードバックを送る前に州の操作者が何らかのより新しい要求されたフィードバックを通過しない場合、その場合、より古いフィードバックは削除されます)。
Price, et. al. Standards Track [Page 18] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[18ページ]RFC3320
If present, the requested feedback item SHOULD be copied unmodified into the returned_feedback_item field provided in the SigComp message. Note that there is no need to transmit any requested feedback item more than once.
存在している、フィードバック項目SHOULDがSigCompメッセージに提供された返された_フィードバック_項目野原の中に変更されていなくコピーされるよう要求しました。 どんな要求されたフィードバック項目ももう少し伝える必要は全く一度よりないことに注意してください。
The compressor SHOULD also upload the local SigComp parameters to the remote endpoint, unless the endpoint has indicated that it does not wish to receive these parameters or the compressor determines that the parameters have already successfully arrived (see Section 5.1 for details of how this can be achieved). The SigComp parameters are uploaded to the UDVM memory at the remote endpoint as described in Section 9.4.9.
また、コンプレッサーSHOULDはローカルのSigCompパラメタを遠く離れた終点にアップロードします、終点が、これらのパラメタを受け取りたがっていないのを示したか、またはコンプレッサーが、パラメタが既に首尾よく到着したことを決定しない場合(どうこれを達成できるかに関する詳細に関してセクション5.1を見てください)。 SigCompパラメタはセクション9.4.9で説明されるように遠く離れた終点のUDVMメモリにアップロードされます。
5.1. Ensuring Successful Decompression
5.1. うまくいっている減圧を確実にします。
A compressor MUST be certain that all of the data needed to decompress a SigComp message is available at the receiving endpoint. One way to ensure this is to send all of the needed information in every SigComp message (including bytecode to decompress the message). However, the compression ratio for this method will be relatively low.
コンプレッサーは受信終点でSigCompメッセージを減圧するのに必要であるデータのすべてが利用可能であることを確信しているに違いありません。 これを確実にする1つの方法はあらゆるSigCompメッセージの必要な情報のすべてを送る(メッセージを減圧するためにバイトコードを含んでいて)ことです。 しかしながら、この方法のための圧縮比は比較的低くなるでしょう。
To obtain the best overall compression ratio the compressor needs to request the creation of new state items at the remote endpoint. The information saved in these state items can then be accessed by later SigComp messages, avoiding the need to upload the data on a per- message basis.
最も良い総合的な圧縮比を得るために、コンプレッサーは、遠く離れた終点で新しい州の項目の創造を要求する必要があります。 次に、後のSigCompメッセージからこれらの州の項目に保存された情報にアクセスできます、データをaにアップロードする必要性を避けて-、メッセージ基礎。
Before the compressor can access saved state however, it must ensure that the SigComp message carrying the state creation request arrived successfully at the receiving endpoint. For a reliable transport (e.g., TCP or SCTP) this is guaranteed. For an unreliable transport however, the compressor must provide a suitable mechanism itself (see [RFC-3321] for further details).
しかしながら、コンプレッサーが救われた状態にアクセスできる前に、それは、州の創造要求を運ぶSigCompメッセージが首尾よく受信終点に到着したのを確実にしなければなりません。 信頼できる輸送(例えば、TCPかSCTP)において、これは保証されます。 しかしながら、頼り無い輸送のために、コンプレッサーは適当なメカニズム自体を提供しなければなりません(さらに詳しい明細については[RFC-3321]を見てください)。
The compressor must also ensure that the state item it wishes to access has not been rejected due to a lack of state memory. This can be accomplished by checking the state_memory_size parameter using the SigComp feedback mechanism (see Section 9.4.9 for further details).
また、コンプレッサーは、それがアクセスしたがっている州の項目が州のメモリの不足のため拒絶されていないのを確実にしなければなりません。 SigCompフィードバック・メカニズムを使用することで状態_メモリ_サイズ・パラメータをチェックすることによって、これを達成できます(さらに詳しい明細についてはセクション9.4.9を見てください)。
5.2. Compression Failure
5.2. 圧縮失敗
The compressor SHOULD make every effort to successfully compress an application message, but in certain cases this might not be possible (particularly if resources are scarce at the receiving endpoint). In this case a "compression failure" is called.
コンプレッサーSHOULDは首尾よくアプリケーションメッセージを圧縮するためのあらゆる努力をしますが、ある場合には、これは可能でないかもしれません(特にリソースが受信終点で不十分であるなら)。 この場合、「圧縮失敗」は呼ばれます。
Price, et. al. Standards Track [Page 19] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[19ページ]RFC3320
If a compression failure occurs then the compressor informs the dispatcher and takes no further action. The dispatcher MUST report this failure to the application so that it can try other methods to deliver the message.
圧縮失敗が起こるなら、コンプレッサーは、発送者を知らせて、これ以上行動を取りません。 発送者は、メッセージを送る他の方法を試みることができるように、この失敗をアプリケーションに報告しなければなりません。
6. State Handling and Feedback
6. 州の取り扱いとフィードバック
This chapter defines the behavior of the SigComp state handler. The function of the state handler is to retain information between received SigComp messages; it is the only SigComp entity that is capable of this function, and so it is of particular importance from a security perspective.
本章はSigComp州の操作者の振舞いを定義します。 州の操作者の機能は受信されたSigCompメッセージの間で情報を保有することです。 唯一のこの機能ができるSigComp実体であるので、それはセキュリティ見解から特別に重要です。
6.1. Creating and Accessing State
6.1. 状態を作成して、アクセスします。
To provide security against the malicious insertion or modification of SigComp messages, a separate instance of the UDVM is invoked to decompress each message. This ensures that damaged SigComp messages do not prevent the successful decompression of subsequent valid messages.
SigCompメッセージの悪意がある挿入か変更に対してセキュリティを提供するなら、UDVMの別々の例は、各メッセージを減圧するために呼び出されます。 これは、破損しているSigCompメッセージがその後の有効なメッセージのうまくいっている減圧を防がないのを確実にします。
Note, however, that the overall compression ratio is often significantly higher if messages can be compressed relative to the information contained in previous messages. For this reason, it is possible to create state items for access when a later message is being decompressed. Both the creation and access of state are designed to be secure against malicious tampering with the compressed data. The UDVM can only create a state item when a complete message has been successfully decompressed and the application has returned a compartment identifier under which the state can be saved.
しかしながら、前のメッセージに含まれた情報に比例してメッセージを圧縮できるなら総合的な圧縮比がしばしばかなり高いことに注意してください。 この理由で、後のメッセージが減圧されているときのアクセスのために州の項目を作成するのは可能です。 創造と状態のアクセスの両方が、圧縮されたデータの悪意があるいじることに対して安全になるように設計されています。 完全なメッセージが首尾よく減圧されて、アプリケーションが状態を節約できるコンパートメント識別子を返したときだけ、UDVMは州の項目を作成できます。
State access cannot be protected by relying on the application alone, since the authentication mechanism may require information from the decompressed message (which of course is not available until after the state has been accessed). Instead, SigComp protects state access by creating a state identifier that is a hash over the item of state to be retrieved. This state_identifier must be supplied to retrieve an item of state from the state handler.
単独でアプリケーションに依存することによって、州のアクセスを保護できません、認証機構が減圧されたメッセージ(状態がアクセスされた後までもちろん利用可能でない)からの情報を必要とするかもしれないので。 代わりに、SigCompは、検索されるために細切れ肉料理である州の識別子を状態の項目の上に作成することによって、州のアクセスを保護します。 州の操作者から状態の項目を検索するためにこの状態_識別子を提供しなければなりません。
Also note that state is not deleted when it is accessed. So even if a malicious sender manages to access some state information, subsequent messages compressed relative to this state can still be successfully decompressed.
また、それがアクセスされているとき、状態が削除されないことに注意してください。 それで、悪意がある送付者が何とか何らかの州の情報にアクセスしても、まだ首尾よくこの状態に比例して圧縮されたその後のメッセージは減圧できます。
Each state item contains a state_identifier that is used to access the state. One state identifier can be supplied in the SigComp message header to initialize the UDVM (see Chapter 7); additional state items can be retrieved using the STATE-ACCESS instruction. The
それぞれの州の項目は状態にアクセスするのに使用される状態_識別子を含んでいます。 UDVMを初期化するためにSigCompメッセージヘッダーで1つの州の識別子を提供できます(第7章を参照してください)。 州-ACCESS指示を使用することで追加州の項目を検索できます。 The
Price, et. al. Standards Track [Page 20] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[20ページ]RFC3320
UDVM can also request the creation of a new state item by using the STATE-CREATE and END-MESSAGE instructions (see Chapter 9 for further details).
また、UDVMは、州-CREATEとEND-MESSAGE指示を使用することによって、新しい州の項目の創造を要求できます(さらに詳しい明細については第9章を参照してください)。
6.2. Memory Management
6.2. メモリ管理
The state handler manages state memory on a per-compartment basis. Each compartment can store state up to a certain state_memory_size (where the application may assign different values for the state_memory_size parameter to different compartments).
州の操作者は1コンパートメントあたり1個のベースに関する州のメモリを管理します。 各コンパートメントは状態をある状態_メモリ_サイズ(アプリケーションが状態_メモリ_サイズ・パラメータのために異なったコンパートメントに異価を割り当てるかもしれないところ)まで格納できます。
As well as storing the state items themselves, the state handler maintains a list of the state items created by a particular compartment and ensures that no compartment exceeds its allocated state_memory_size. For the purpose of calculation, each state item is considered to cost (state_length + 64) bytes.
州の項目自体を格納することと同様に、州の操作者は、特定のコンパートメントによって作成された州の項目のリストを主張して、どんなコンパートメントも割り当てられた状態_メモリ_サイズを超えていないのを保証します。 計算の目的のために、それぞれの州の項目が(状態_長さ+64)バイトかかると考えられます。
Each instance of the UDVM can pass up to four state creation requests to the state handler, as well as up to four state free requests (the latter are requests to free the memory taken by a state item in a certain compartment). When the state handler receives a state creation request from the UDVM it takes the following steps:
UDVMの各例は、州の操作者への創造要求を最大4状態に向かわせて、最大4状態に無料の要求を向かわせることができます(後者はあるコンパートメントで州の項目によって取られたメモリを解放するという要求です)。 州の操作者が州の創造を受けたら、UDVMから以下の方法を採るよう要求してください:
1. The state handler MUST reject all state creation requests that are
not accompanied by a valid compartment identifier, or if the
compartment is allocated 0 bytes of state memory. Note that if a
state creation request fails due to lack of state memory then it
does not mean that the corresponding SigComp message is damaged;
compressors will often make state creation requests in the first
SigComp message of a compartment, before they have discovered the
state_memory_size using the SigComp feedback mechanism.
1. 州の操作者は有効なコンパートメント識別子かそれとも0バイトの州のメモリをコンパートメントに割り当てるかどうかによって伴われないすべての州の創造要求を拒絶しなければなりません。 州の創造要求が州のメモリの不足のため失敗するなら対応するSigCompメッセージが破損されていることを意味しないことに注意してください。 コンプレッサーはしばしば状態をコンパートメントの最初のSigCompメッセージにおける創造要求にするでしょう、SigCompフィードバック・メカニズムを使用することで状態_メモリ_サイズを発見する前に。
2. If the state creation request needs more state memory than the
total state_memory_size for the compartment, the state handler
deletes all but the first (state_memory_size - 64) bytes from the
state_value. It sets the state_length to (state_memory_size -
64), and recalculates the state_identifier as defined in Section
9.4.9.
2. 州の創造要求が総状態_メモリ_サイズより多くの州のメモリをコンパートメントに必要とするなら、州の操作者は状態_値から最初(状態_メモリ_サイズ--64)のバイト以外のすべてを削除します。 それが状態_長さを設定する、(_メモリ_サイズを述べてください--64)、recalculatesはセクション9.4で.9に定義される状態_識別子を64です。
3. If the state creation request contains a state_identifier that
already exists then the state handler checks whether the requested
state item is identical to the established state item and counts
the state creation request as successful if this is the case. If
not then the state creation request is unsuccessful (although the
probability that this will occur is vanishingly small).
3. 州の創造要求が既に存在する状態_識別子を含んでいるなら、州の操作者は、要求された州の項目が確立した州の項目と同じであるかどうかチェックして、これがそうであるならうまくいくとして州の創造要求を数えます。 そうでなければ、その時、州の創造要求は失敗しています(これが起こるという確率が消え失せてわずかですが)。
Price, et. al. Standards Track [Page 21] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[21ページ]RFC3320
4. If the state creation request exceeds the state memory allocated
to the compartment, sufficient items of state created by the same
compartment are freed until enough memory is available to
accommodate the new state. When a state item is freed, it is
removed from the list of states created by the compartment and the
memory cost of the state item no longer counts towards the total
cost for the compartment. Note, however, that identical state
items may be created by several different compartments, so a state
item must not be physically deleted unless the state handler
determines that it is no longer required by any compartment.
4. 州の創造要求がコンパートメントに割り当てられた州のメモリを超えているなら、十分なメモリが新しい状態を収容するために利用可能になるまで、同じコンパートメントによって創設された状態の十分な項目は解放されます。 州の項目が解放されるとき、それはコンパートメントによって創設された州のリストから移されます、そして、州の項目のメモリ費用はコンパートメントのためにもう総費用に向かって重要ではありません。 しかしながら、州の操作者が、それがもうどんなコンパートメントによっても必要とされないと決心していない場合物理的に州の項目を削除してはいけないために同じ州の項目がいくつかの異なったコンパートメントによって作成されるかもしれないことに注意してください。
5. The order in which the existing state items are freed is
determined by the state_retention_priority, which is set when the
state items are created. The state_retention_priority of 65535 is
reserved for locally available states; these states must always be
freed first. Apart from this special case, states with the lowest
state_retention_priority are always freed first. In the event of
a tie, then the state item created first in the compartment is
also the first to be freed.
5. 現状項目が解放される順番は状態_保有_優先権で決定します。(州の項目が作成されるとき、それは、設定されます)。 65535の状態_保有_優先権は局所的に利用可能な州に保有されます。 最初に、いつもこれらの州を解放しなければなりません。 この特別なケースは別として、最も低い状態_保有_優先度がある州は最初に、いつも解放されます。 そして、繋がりの場合、また、最初にコンパートメントで作成された州の項目は解放されるべき第1です。
The state_retention_priority is always stored on a per-compartment basis as part of the list of state items created by each compartment. In particular, the same state item might have several priority values if it has been created by several different compartments.
状態_保有_優先権は各コンパートメントによって作成された州の項目のリストの一部として1コンパートメントあたり1個のベースにいつも格納されます。 それがいくつかの異なったコンパートメントによって作成されたなら、同じ州の項目には特に、いくつかの優先順位の値があるかもしれません。
Note that locally available state items (as described in Section 3.3.3) need not be mapped to any particular compartment. However, if they are created on a per-compartment basis, then they must not interfere with the state created at the request of the remote endpoint. The special state_retention_priority of 65535 is reserved for locally available state items to ensure that this is the case.
項目(セクション3.3.3で説明されるように)が必要とする局所的に利用可能な状態がどんな特定のコンパートメントにも写像されないことに注意してください。 しかしながら、それらが1コンパートメントあたり1個のベースで作成されるなら、彼らは遠く離れた終点の依頼で創設された状態を妨げてはいけません。 局所的に利用可能な州の項目が、これがそうであることを保証するように、65535の特別な状態_保有_優先権は保有されます。
The UDVM may also explicitly request the state handler to free a specific state item in a compartment. In this case, the state handler deletes the state item from the list of state items created by the compartment (as before the state item itself must not be physically deleted unless the state handler determines that it is not longer required by any compartment).
また、UDVMは、コンパートメントで特定の州の項目を解放するよう明らかに州の操作者に要求するかもしれません。 この場合、州の操作者はコンパートメントによって作成された州の項目のリストから州の項目を削除します(州の操作者が、それが、より長い間どんなコンパートメントによっても必要とされないと決心していない場合、物理的に従来と同様州の項目自体を削除してはいけません)。
The application should indicate to the state handler when it wishes to close a particular compartment, so that the resources taken by the corresponding state can be reclaimed.
アプリケーションは、それがいつ特定のコンパートメントを閉じたがっているかを州の操作者に示すべきです、対応する州によって取られたリソースは取り戻すことができるように。
Price, et. al. Standards Track [Page 22] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[22ページ]RFC3320
6.3. Feedback Data
6.3. フィードバックデータ
The SigComp feedback mechanism allows feedback data to be received by a UDVM and forwarded via the state handler to the correct compressor.
SigCompフィードバック・メカニズムは、フィードバックデータが正しいコンプレッサーにUDVMによって受け取られて、州の操作者を通して転送されるのを許容します。
Since this feedback data is retained between SigComp messages, it is considered to be part of the overall state and can only be forwarded if accompanied by a valid compartment identifier. If this is the case, then the state handler forwards the feedback data to the compressor responsible for sending messages that pertain to the peer compartment of the specified compartment.
このフィードバックデータがSigCompメッセージの間で保有されるので、それを総合的な状態の一部であると考えて、有効なコンパートメント識別子で伴う場合にだけ、進めることができます。 これがそうであるなら、州の操作者は指定されたコンパートメントの同輩コンパートメントに関係する送付メッセージに原因となるコンプレッサーにフィードバックデータを転送します。
7. SigComp Message Format
7. SigCompメッセージ・フォーマット
This chapter describes the format of the SigComp message and how the message is used to initialize the UDVM memory.
本章はSigCompメッセージとメッセージがUDVMメモリを初期化するのにどう使用されるかに関する形式について説明します。
Note that the SigComp message is not copied into the UDVM memory as soon as it arrives; instead, the UDVM indicates when it requires compressed data using a specific instruction. It then pauses and waits for the information to be supplied before executing the next instruction. This means that the UDVM can begin to decompress a SigComp message before the entire message has been received.
到着するとすぐに、SigCompメッセージがUDVMメモリにコピーされないことに注意してください。 代わりに、UDVMは、それがいつ特定の指示を使用することで圧縮されたデータを必要とするかを示します。 それは、次に、止まって、次の指示を実行する前に情報が提供されるのを待っています。 これは、全体のメッセージを受け取る前にUDVMがSigCompメッセージを減圧し始めることができることを意味します。
A consequence of the above behavior is that when the UDVM is invoked, the size of the UDVM memory depends on whether the transport used to provide the SigComp message is stream-based or message-based. If the transport is message-based then sufficient memory must be available to buffer the entire SigComp message before it is passed to the UDVM. So if the message is n bytes long, then the UDVM memory size is set to (decompression_memory_size - n), up to a maximum of 65536 bytes.
上の振舞いの結果はUDVMが呼び出されるとき、UDVMメモリのサイズをSigCompメッセージを提供するのに使用される輸送が流れのベースかそれともメッセージベースであるかに依存するということです。 輸送がメッセージベースであるなら、十分な記憶は、それがUDVMに通過される前に全体のSigCompメッセージをバッファリングするように利用可能でなければなりません。 それで、UDVM記憶容量はメッセージがnバイト長であるなら設定されます(減圧_メモリ_サイズ--n)、最大65536バイトまで。
If the transport is stream-based however, then a fixed-size input buffer is required to accommodate the stream, independently of the size of each SigComp message. So, for simplicity, the UDVM memory size is set to (decompression_memory_size / 2).
しかしながら、輸送が流れのベースであるなら、固定サイズ入力バッファが流れを収容するのに必要です、それぞれのSigCompメッセージのサイズの如何にかかわらず。 それで、簡単さにおいて、UDVM記憶容量は(減圧_メモリ_サイズ/2)に設定されます。
As a separate instance of the UDVM is invoked on a per-message basis, each SigComp message must explicitly indicate its chosen decompression algorithm as well as any additional information that is needed to decompress the message (e.g., one or more previously received messages, a dictionary of common SIP phrases etc.). This information can either be uploaded as part of the SigComp message or retrieved from an item of state.
UDVMの別々の例が1メッセージあたり1個のベースに呼び出されるとき、それぞれのSigCompメッセージは明らかにメッセージを減圧するのに必要であるどんな追加情報と同様に選ばれた減圧アルゴリズムを示さなければなりません(例えば、より多くのあるものが以前にメッセージを受け取って、一般的なSIPの辞書は句のなどです)。 この情報をSigCompメッセージの一部としてアップロードするか、または状態の項目から検索できます。
Price, et. al. Standards Track [Page 23] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[23ページ]RFC3320
A SigComp message takes one of two forms depending on whether it accesses a state item at the receiving endpoint. The two variants of a SigComp message are given in Figure 3. (The T-bit controls the format of the returned feedback item and is defined in Section 7.1.)
SigCompメッセージはそれが受信終点で州の項目にアクセスするかどうかに依存する2つのフォームの1つを取ります。 図3でSigCompメッセージの2つの異形を与えます。 定義されたコネはセクションです。そして、(T-ビット制御、返されたフィードバック項目の形式、7.1)。
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 3: Format of a SigComp message
図3: SigCompメッセージの形式
Decompression failure occurs if the SigComp message is too short to contain the expected fields (see Section 8.7 for further details).
SigCompメッセージが予想された分野を含むことができないくらい不足しているなら(さらに詳しい明細についてはセクション8.7を見てください)、減圧失敗は起こります。
The fields except for the "remaining SigComp message" are referred to as the "SigComp header" (note that this may include the uploaded UDVM bytecode).
「残っているSigCompメッセージ」を除いた野原は「SigCompヘッダー」と呼ばれます(これがアップロードされたUDVMバイトコードを含むかもしれないことに注意してください)。
7.1. Returned feedback item
7.1. 返されたフィードバック項目
For both variants of the SigComp message, the T-bit is set to 1 whenever the SigComp message contains a returned feedback item. The format of the returned feedback item is illustrated in Figure 4.
SigCompメッセージの両方の異形において、SigCompメッセージが返されたフィードバック項目を含んでいるときはいつも、T-ビットは1に設定されます。 返されたフィードバック項目の形式は図4で例証されます。
Price, et. al. Standards Track [Page 24] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[24ページ]RFC3320
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | returned_feedback_field | | 1 | returned_feedback_length |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| |
: returned_feedback_field :
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | 0 | 返された_フィードバック_分野| | 1 | 返された_のフィードバック_長さ| +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | | : 返された_フィードバック_分野: | | +---+---+---+---+---+---+---+---+
Figure 4: Format of returned feedback item
図4: 返されたフィードバック項目の形式
Note that the returned feedback length specifies the size of the returned feedback field (from 0 to 127 bytes). So the total size of the returned feedback item lies between 1 and 128 bytes.
返されたフィードバックの長さが返されたフィードバック分野(0〜127バイト)のサイズを指定することに注意してください。 それで、返されたフィードバック項目の総サイズが1〜128バイトあります。
The returned feedback item is not copied to the UDVM memory; instead, it is buffered until the UDVM has successfully decompressed the SigComp message. It is then forwarded to the state handler with the rest of the feedback data (see Section 9.4.9 for further details).
返されたフィードバック項目はUDVMメモリにコピーされません。 代わりに、UDVMが首尾よくSigCompメッセージを減圧するまで、それはバッファリングされます。 そして、フィードバックデータの残りは州の操作者にそれを送ります(さらに詳しい明細についてはセクション9.4.9を見てください)。
7.2. Accessing Stored State
7.2. アクセスは状態を格納しました。
The len field of the SigComp message determines which fields follow the returned feedback item. If the len field is non-zero, then the SigComp message contains a state identifier to access a state item at the receiving endpoint. All state items include a 20-byte state identifier as per Section 3.3.3, but it is possible to transmit as few as 6 bytes from the identifier if the sender believes that this is sufficient to match a unique state item at the receiving endpoint.
SigCompメッセージのlen分野は、どの分野が返されたフィードバック商品に従うかを決定します。 len分野が非ゼロであるなら、SigCompメッセージは受信終点で州の項目にアクセスする州の識別子を含んでいます。 すべての州の項目がセクション3.3.3に従って20バイトの州の識別子を含んでいますが、送付者が、これが受信終点でユニークな州の項目を合わせるために十分であると信じているなら、識別子から最小6バイト伝わるのは可能です。
The len field encodes the number of transmitted bytes as follows:
len分野は以下の伝えられたバイトの数をコード化します:
Encoding: Length of partial state identifier
コード化します: 部分的な州の識別子の長さ
01 6 bytes 10 9 bytes 11 12 bytes
01 6バイト10 9バイト11 12バイト
The partial state identifier is passed to the state handler, which compares it with the most significant bytes of the state_identifier in every currently stored state item. Decompression failure occurs if no state item is matched or if more than one state item is matched.
部分的な州の識別子は州の操作者に渡されます。(その操作者は、状態_識別子のあらゆる現在格納された州の項目で最も重要なバイトとそれを比べます)。 どんな州の項目も取り組まないか、または複数の州の項目が取り組むなら、減圧失敗は起こります。
Price, et. al. Standards Track [Page 25] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[25ページ]RFC3320
Decompression failure also occurs if exactly one state item is matched but the state item contains a minimum_access_length greater than the length of the partial state identifier. This prevents especially sensitive state items from being accessed maliciously by brute force guessing of the state_identifier.
また、まさに1つの州の項目が取り組んでいますが、州の項目が部分的な州の識別子の長さより大きい最小の_のアクセス_長さを含んでいるなら、減圧失敗は起こります。 これは、特に敏感な州の項目が暴力で状態_識別子を推測しながら陰湿にアクセスされるのを防ぎます。
If a state item is successfully accessed then the state_value byte string is copied into the UDVM memory beginning at state_address.
州の項目が首尾よくアクセスされるなら、状態_値のバイトストリングは状態_アドレスで始まるUDVMメモリにコピーされます。
The first 32 bytes of UDVM memory are then initialized to special values as illustrated in Figure 5.
そして、最初の32バイトのUDVMメモリは図5で例証されるように特別な値に初期化されます。
0 7 8 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDVM_memory_size | 0 - 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cycles_per_bit | 2 - 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SigComp_version | 4 - 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partial_state_ID_length | 6 - 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| state_length | 8 - 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: reserved : 10 - 31
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 7 8 15 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDVM_メモリ_サイズ| 0 - 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _ビットあたりの_を循環させます。| 2 - 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SigComp_バージョン| 4 - 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 部分的な_状態_ID_の長さ| 6 - 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 状態_長さ| 8 - 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 予約される: 10 - 31 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Initializing Useful Values in UDVM memory
図5: UDVMメモリでUseful Valuesを初期化します。
The first five 2-byte words are initialized to contain some values that might be useful to the UDVM bytecode (Useful Values). Note that these values are for information only and can be overwritten when executing the UDVM bytecode without any effect on the endpoint. The MSBs of each 2-byte word are stored preceding the LSBs.
最初の5つの2バイトの単語が、UDVMバイトコード(役に立つValues)の役に立つかもしれないいくつかの値を含むように初期化されます。 終点への少しも効果なしでUDVMバイトコードを実行するとき、これらの値は情報だけのためにあって、上書きできることに注意してください。 それぞれの2バイトの単語のMSBsは、LSBsに先行しながら、格納されます。
Addresses 0 to 5 indicate the resources available to the receiving endpoint. The UDVM memory size is expressed in bytes modulo 2^16, so in particular, it is set to 0 if the UDVM memory size is 65536 bytes. The cycles_per_bit is expressed as a 2-byte integer taking the value 16, 32, 64 or 128. The SigComp_version is expressed as a 2-byte value as per Section 3.3.2.
アドレス0〜5は受信終点に利用可能なリソースを示します。 UDVM記憶容量がバイト法2^16で表されるので、特に、それはUDVM記憶容量が65536バイトであるなら0に設定されます。 _ビットあたりのサイクル_は値16、32、64または128を取る2バイトの整数として急送されます。 SigComp_バージョンはセクション3.3.2に従って2バイトの値として言い表されます。
Addresses 6 to 9 are initialized to the length of the partial state identifier, followed by the state_length from the retrieved state item. Both are expressed as 2-byte values.
アドレス6〜9は状態_長さが検索された州の項目からあとに続いた部分的な州の識別子の長さに初期化されます。 両方が2バイトの値として言い表されます。
Price, et. al. Standards Track [Page 26] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[26ページ]RFC3320
Addresses 10 to 31 are reserved and are initialized to 0 for Version 0x01 of SigComp. Future versions of SigComp can use these locations for additional Useful Values, so a decompressor MUST NOT rely on these values being zero.
アドレス10〜31は、予約されていて、SigCompのバージョン0x01のために0に初期化されます。 SigCompの将来のバージョンが追加Useful Valuesにこれらの位置を使用できるので、減圧装置はゼロであるこれらの値を当てにしてはいけません。
Any remaining addresses in the UDVM memory that have not yet been initialized MUST be set to 0.
UDVMメモリのまだ初期化されていない少しの残っているアドレスも0に設定しなければなりません。
The UDVM then begins executing instructions at the memory address contained in state_instruction (which is part of the retrieved item of state). Note that the remaining SigComp message is held by the decompressor dispatcher until requested by the UDVM.
そして、UDVMは状態_指示(状態の検索された項目の一部である)に含まれたメモリアドレスで指示を実行し始めます。 UDVMによって要求されるまで残っているSigCompメッセージが減圧装置発送者によって保持されることに注意してください。
(Note that the Useful Values are only set at UDVM startup; there is no special significance to this memory area afterwards. This means that the UDVM bytecode is free to use these locations for any other purpose a memory location might be used for; it just has to be aware they are not necessarily initialized to zero.)
(Useful ValuesがUDVM始動で用意ができているだけであることに注意してください。 その後、このメモリ領域へのどんな特別な意味もありません。 これは、UDVMバイトコードが記憶域が使用されるかもしれないいかなる他の目的にも自由にこれらの位置を使用できることを意味します。 それは、ゼロに合わせるためにそれらが必ず初期化されるというわけではないのをただ意識していなければなりません。)
7.3. Uploading UDVM bytecode
7.3. アップロードUDVMバイトコード
If the len field is set to 0 then the bytecode needed to decompress the SigComp message is supplied as part of the message itself. The 12-bit code_len field specifies the size of the uploaded UDVM bytecode (from 0 to 4095 bytes inclusive); eight most significant bits are in the first byte, followed by the four least significant bits in the most significant bits in the second byte. The remaining bits in the second byte are interpreted as a 4-bit destination field that specifies the starting memory address to which the bytecode is copied. The destination field is encoded as follows:
len分野を0に設定するなら、メッセージ自体の一部としてSigCompメッセージを減圧するのに必要であるバイトコードを供給します。 12ビットのコード_len分野は(包括的0〜4095バイトまで)でアップロードされたUDVMバイトコードのサイズを指定します。 2番目のバイトにおける最も重要なビットの4つの最下位ビットがあとに続いた最初のバイトには8つの最上位ビットがあります。 2番目のバイトにおける残っているビットはバイトコードがコピーされる始めのメモリアドレスを指定する4ビットのあて先フィールドとして解釈されます。 あて先フィールドは以下の通りコード化されます:
Encoding: Destination address:
コード化します: 送付先アドレス:
0000 reserved
0001 2 * 64 = 128
0010 3 * 64 = 196
0011 4 * 64 = 256
: :
1111 16 * 64 = 1024
0000は0001 2*64 = 128 0010 3*64 = 196 0011 4*64 = 256を予約しました: : 1111 16 * 64 = 1024
Note that the encoding 0000 is reserved for future SigComp versions, and causes a decompression failure in Version 0x01.
コード化0000が将来のSigCompバージョンのために予約されて、バージョン0x01で減圧失敗を引き起こすことに注意してください。
Price, et. al. Standards Track [Page 27] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[27ページ]RFC3320
The UDVM memory is initialized as per Figure 5, except that addresses 6 to 9 inclusive are set to 0 because no state item has been accessed. The UDVM then begins executing instructions at the memory address specified by the destination field. As above, the remaining SigComp message is held by the decompressor dispatcher until needed by the UDVM.
UDVMメモリは図5に従って初期化されます、そのアドレスを除いて。6〜9に、州の項目が全くアクセスされていないので、包括的であるのは、0へのセットです。 そして、UDVMはあて先フィールドによって指定されたメモリアドレスで指示を実行し始めます。 同じくらい上では、UDVMが必要になるまで、残っているSigCompメッセージが減圧装置発送者によって保持されます。
8. Overview of the UDVM
8. UDVMの概観
Decompression functionality for SigComp is provided by a Universal Decompressor Virtual Machine (UDVM). The UDVM is a virtual machine much like the Java Virtual Machine but with a key difference: it is designed solely for the purpose of running decompression algorithms.
SigCompのための減圧の機能性はUniversal Decompressor Virtual Machine(UDVM)によって提供されます。 UDVMはJava仮想マシンにもかかわらず、主要な違いなどのように仮想計算機です: それは唯一減圧アルゴリズムを走らせる目的のために設計されています。
The motivation for creating the UDVM is to provide flexibility when choosing how to compress a given application message. Rather than picking one of a small number of pre-negotiated algorithms, the compressor implementer has the freedom to select an algorithm of their choice. The compressed data is then combined with a set of UDVM instructions that allow the original data to be extracted, and the result is outputted as a SigComp message. Since the UDVM is optimized specifically for running decompression algorithms, the code size of a typical algorithm is small (often sub 100 bytes). Moreover, the UDVM approach does not add significant extra processing or memory requirements compared to running a fixed preprogrammed decompression algorithm.
UDVMを作成することに関する動機は与えられたアプリケーションメッセージを圧縮する方法を選ぶとき、柔軟性を提供することです。 少ない数のあらかじめ交渉されたアルゴリズムの1つを選ぶよりむしろ、コンプレッサーimplementerには、彼らの選択のアルゴリズムを選択する自由があります。 次に、圧縮されたデータはオリジナルのデータが抜粋されるのを許容する1セットのUDVM指示に結合されます、そして、結果はSigCompメッセージとしてoutputtedされます。 UDVMが特に走行減圧アルゴリズムのために最適化されるので、典型的なアルゴリズムのコードサイズは小さいです(しばしば100バイト代理をしてください)。 そのうえ、固定前プログラムされた減圧アルゴリズムを走らせると比べて、UDVMアプローチは重要な余分な処理かメモリ要件を加えません。
Figure 6 gives a detailed view of the interfaces between the UDVM and its environment.
図6はUDVMとその環境とのインタフェースの詳細な意見を与えます。
Price, et. al. Standards Track [Page 28] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[28ページ]RFC3320
+----------------+ +----------------+ | | Request compressed data | | | |-------------------------------->| | | |<--------------------------------| | | | Provide compressed data | | | | | | | | Output decompressed data | Decompressor | | |-------------------------------->| dispatcher | | | | | | | Indicate end of message | | | |-------------------------------->| | | |<--------------------------------| | | UDVM | Provide compartment identifier | | | | +----------------+ | | | | +----------------+ | | Request state information | | | |-------------------------------->| | | |<--------------------------------| | | | Provide state information | State | | | | handler | | | Make state creation request | | | |-------------------------------->| | | | Forward feedback information | | +----------------+ +----------------+
+----------------+ +----------------+ | | 圧縮されたデータを要求してください。| | | |-------------------------------->| | | |<--------------------------------| | | | 圧縮されたデータを提供してください。| | | | | | | | 出力はデータを減圧しました。| 減圧装置| | |-------------------------------->| 発送者| | | | | | | メッセージの終わりを示してください。| | | |-------------------------------->| | | |<--------------------------------| | | UDVM| コンパートメント識別子を提供してください。| | | | +----------------+ | | | | +----------------+ | | 州の情報を要求してください。| | | |-------------------------------->| | | |<--------------------------------| | | | 州の情報を提供してください。| 状態| | | | 操作者| | | 州の創造要求をしてください。| | | |-------------------------------->| | | | 前進のフィードバック情報| | +----------------+ +----------------+
Figure 6: Interfaces between the UDVM and its environment
図6: UDVMとその環境とのインタフェース
Note that once the UDVM has been initialized, additional compressed data and state information are only provided at the request of a specific UDVM instruction.
UDVMがいったん初期化される後、追加圧縮されたデータと州の情報が特定のUDVM指示の依頼で提供されるだけであることに注意してください。
This chapter describes the basic features of the UDVM including the UDVM registers and the format of UDVM bytecode.
本章はUDVMレジスタを含むUDVMに関する基本的特徴とUDVMバイトコードの形式について説明します。
8.1. UDVM Registers
8.1. UDVMレジスタ
The UDVM registers are 2-byte words in the UDVM memory that have special tasks, for example specifying the location of the stack used by the CALL and RETURN instructions.
UDVMレジスタはUDVMメモリの特別なタスクを持っている2バイトの単語です、例えば、CALLとRETURN指示で使用されるスタックの位置を指定して。
The UDVM registers are illustrated in Figure 7.
UDVMレジスタは図7で例証されます。
Price, et. al. Standards Track [Page 29] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[29ページ]RFC3320
0 7 8 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| byte_copy_left | 64 - 65
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| byte_copy_right | 66 - 67
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| input_bit_order | 68 - 69
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| stack_location | 70 - 71
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 7 8 15 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バイト_コピー_は残っています。| 64 - 65 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バイト_コピー_権利| 66 - 67 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 入力_ビット_命令| 68 - 69 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | スタック_位置| 70 - 71 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Memory addresses of the UDVM registers
図7: UDVMレジスタのメモリアドレス
The MSBs of each register are always stored before the LSBs. So, for example, the MSBs of byte_copy_left are stored at Address 64 whilst the LSBs are stored at Address 65.
それぞれのレジスタのMSBsはいつもLSBsの前に格納されます。 そのように、例えば、LSBsはAddress65に格納されますが、あとバイト_コピー_のMSBsはAddress64に格納されます。
The use of each UDVM register is defined in the following sections.
それぞれのUDVMレジスタの使用は以下のセクションで定義されます。
(Note that the UDVM registers start at Address 64, that is 32 bytes after the area reserved for Useful Values. The intention is that the gap, i.e., the area between Address 32 and Address 63, will often be used as scratch-pad memory that is guaranteed to be zero at UDVM startup and is efficiently addressable in operand types reference ($) and multitype (%).)
(UDVMレジスタがすなわち、Address64、Useful Valuesのために予約された領域の後の32バイトで始まることに注意してください。 意志はスクラッチパッドメモリが効率的にオペランドタイプ参照の($)と「マルチ-タイプ」(%)でアドレス可能な状態でUDVMのゼロが始動であったなら保証して、あってギャップ(すなわち、Address32とAddress63の間の領域)がしばしば使用されるということです。)
8.2. Requesting Additional Compressed Data
8.2. 追加圧縮されたデータを要求します。
The decompressor dispatcher stores the compressed data from the SigComp message before it is requested by the UDVM via one of the INPUT instructions. When the UDVM bytecode is first executed, the dispatcher contains the remaining SigComp message after the header has been used to initialize the UDVM as per Chapter 7.
それがINPUT指示の1つを通してUDVMによって要求されている前に減圧装置発送者はSigCompメッセージから圧縮されたデータを格納します。 UDVMバイトコードが最初に実行されるとき、ヘッダーが第7章に従ってUDVMを初期化するのに使用された後に発送者は残っているSigCompメッセージを含んでいます。
Note that the INPUT-BITS and INPUT-HUFFMAN instructions retrieve a stream of individual compressed bits from the dispatcher. To provide bitwise compatibility with various well-known compression algorithms, the input_bit_order register can modify the order in which individual bits are passed within a byte.
INPUT-BITSとINPUT-ハフマン指示が発送者からの個々の圧縮されたビットの流れを検索することに注意してください。 提供するのは様々な周知の圧縮アルゴリズムとの互換性をbitwiseして、入力_ビット_オーダーレジスタは個々のビットが1バイト以内で渡されるオーダーを変更できます。
The input_bit_order register contains the following three flags:
入力_ビット_オーダーレジスタは以下の3個の旗を含んでいます:
0 7 8 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |F|H|P| 68 - 69
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 7 8 15 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。|F|H|P| 68 - 69 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Price, et. al. Standards Track [Page 30] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[30ページ]RFC3320
The P-bit controls the order in which bits are passed from the dispatcher to the INPUT instructions. If set to 0, it indicates that the bits within an individual byte are passed to the INPUT instructions in MSB to LSB order. If it is set to 1, the bits are passed in LSB to MSB order.
P-ビットは制御されます。ビットが発送者からINPUT指示まで渡される注文。 0に設定されるなら、それは、個々のバイトの中のビットがLSBオーダーへのMSBでのINPUT指示に渡されるのを示します。 それが1に設定されるなら、ビットはLSBでMSBオーダーに渡されます。
Note that the input_bit_order register cannot change the order in which the bytes themselves are passed to the INPUT instructions (bytes are always passed in the same order as they occur in the SigComp message).
入力_ビット_オーダーレジスタがバイト自体がINPUT指示に通過されるオーダーを変えることができないことに注意してください(SigCompメッセージに起こるのに応じて、バイトは同次でいつも通過されます)。
The following diagram illustrates the order in which bits are passed to the INPUT instructions for both cases:
以下のダイヤグラムはビットが両方のケースのためのINPUT指示に渡されるオーダーを例証します:
MSB LSB MSB LSB MSB LSB MSB LSB
MSB LSB MSB LSB MSB LSB MSB LSB
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 2 3 4 5 6 7|8 9 ... | |7 6 5 4 3 2 1 0| ... 9 8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 2 3 4 5 6 7|8 9 ... | |7 6 5 4 3 2 1 0| ... 9 8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Byte 0 Byte 1 Byte 0 Byte 1
バイト0バイト1 0バイト1のバイト
P = 0 P = 1
P=0P=1
Note that after one or more INPUT instructions the dispatcher may hold a fraction of a byte (what used to be the LSBs if P = 0, or, the MSBs, if P = 1). If an INPUT instruction is encountered and the P- bit has changed since the last INPUT instruction, any fraction of a byte still held by the dispatcher MUST be discarded (even if the INPUT instruction requests zero bits). The first bit passed to the INPUT instruction is taken from the subsequent byte.
または、Pであるなら何が以前、LSBsであったかは0と等しいです。1つ以上のINPUT指示の後に発送者が1バイトの何分の一を開催するかもしれないことに注意してください、(MSBs Pが1と)等しいなら。 INPUT指示が遭遇して、最後のINPUT指示以来Pビットが変化しているなら、発送者によってまだ保持されていた1バイトのどんな何分の一も捨てなければなりません(INPUT指示要求がビットのゼロに合っても)。 その後のバイトからINPUT指示に渡された最初のビットを取ります。
When an INPUT instruction requests n bits of compressed data, it interprets the received bits as an integer between 0 and 2^n - 1. The F-bit and the H-bit specify whether the bits in these integers are considered to arrive in MSB to LSB order (bit set to 0) or in LSB to MSB order (bit set to 1).
INPUT指示がnビットの圧縮されたデータを要求するとき、0と2^nの間の整数として容認されたビットを解釈します--1。 F-ビットとH-ビットは、これらの整数におけるビットがLSBオーダー(ビットは0にセットした)へのMSBかLSBに到着すると考えられるかどうかMSBオーダーに指定します(ビットは1にセットしました)。
If the F-bit is set to 0, the INPUT-BITS instruction interprets the received bits as arriving MSBs first, and if it is set to 1, it interprets the bits as arriving LSBs first. The H-bit performs the same function for the INPUT-HUFFMAN instruction. Note that it is possible to set these two bits to different values in order to use different bit orders for the two instructions (certain algorithms actually require this, e.g., DEFLATE [RFC-1951]). (Note that there are no special considerations for changing the F- or H-bit between INPUT instructions, unlike the discard rule for the P-bit described above.)
F-ビットが0に設定されるなら、INPUT-BITS指示は最初に到着MSBsとして容認されたビットを解釈します、そして、1に設定されるなら、それは最初に、到着LSBsとしてビットを解釈します。 H-ビットはINPUT-ハフマン指示のために同じ機能を実行します。 2つの指示に異なった噛み付いている命令を使用するためにこれらの2ビットを異価に設定するのが可能であることに注意してください(あるアルゴリズムは実際にこれを必要とします、例えば、DEFLATE[RFC-1951])。 (上で説明されたP-ビットのためにFかHで破棄と異なったINPUT指示の間で噛み付いている規則を変えるためのどんな特別な問題もないことに注意してください。)
Price, et. al. Standards Track [Page 31] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[31ページ]RFC3320
Decompression failure occurs if an INPUT-BITS or an INPUT-HUFFMAN instruction is encountered and the input_bit_order register does not lie between 0 and 7 inclusive.
INPUT-ハフマン指示は遭遇します、そして、減圧失敗がINPUT-BITSであるなら起こるか、または入力_ビット_オーダーレジスタが包括的に0と7の間ありません。
8.3. UDVM Stack
8.3. UDVMスタック
Certain UDVM instructions make use of a stack of 2-byte words stored at the memory address specified by the 2-byte word stack_location. The stack contains the following words:
あるUDVM指示はスタック_位置という2バイトの単語によって指定されたメモリアドレスで格納された2バイトの単語のスタックを利用します。 スタックは以下の単語を含んでいます:
Name: Starting memory address:
以下を命名してください。 メモリアドレスを始めます:
stack_fill stack_location
stack[0] stack_location + 2
stack[1] stack_location + 4
stack[2] stack_location + 6
: :
スタック_中詰めスタック_位置のスタック[0]スタック_位置+2スタック[1]スタック_位置+4スタック[2]は_位置+6を積み重ねます: :
The notation stack_location is an abbreviation for the contents of the stack_location register, i.e., the 2-byte word at locations 70 and 71. The notation stack_fill is an abbreviation for the 2-byte word at stack_location and stack_location+1. Similarly, the notation stack[n] is an abbreviation for the 2-byte word at stack_location+2*n+2 and stack_location+2*n+3. (As always, the arithmetic is modulo 2^16.)
The notation stack_location is an abbreviation for the contents of the stack_location register, i.e., the 2-byte word at locations 70 and 71. The notation stack_fill is an abbreviation for the 2-byte word at stack_location and stack_location+1. Similarly, the notation stack[n] is an abbreviation for the 2-byte word at stack_location+2*n+2 and stack_location+2*n+3. (As always, the arithmetic is modulo 2^16.)
The stack is used by the CALL, RETURN, PUSH and POP instructions.
The stack is used by the CALL, RETURN, PUSH and POP instructions.
"Pushing" a value on the stack is an abbreviation for copying the value to stack[stack_fill] and then increasing stack_fill by 1. CALL and PUSH push values on the stack.
"Pushing" a value on the stack is an abbreviation for copying the value to stack[stack_fill] and then increasing stack_fill by 1. CALL and PUSH push values on the stack.
"Popping" a value from the stack is an abbreviation for decreasing stack_fill by 1, and then using the value stored in stack[stack_fill]. Decompression failure occurs if stack_fill is zero at the commencement of a popping operation. POP and RETURN pop values from the stack.
"Popping" a value from the stack is an abbreviation for decreasing stack_fill by 1, and then using the value stored in stack[stack_fill]. Decompression failure occurs if stack_fill is zero at the commencement of a popping operation. POP and RETURN pop values from the stack.
For both of these abstract operations, the UDVM first takes note of the current value of stack_location and uses this value for both sub-operations (accessing the stack and manipulating stack_fill), i.e., overwriting stack_location in the course of the operation is inconsequential for the operation.
For both of these abstract operations, the UDVM first takes note of the current value of stack_location and uses this value for both sub-operations (accessing the stack and manipulating stack_fill), i.e., overwriting stack_location in the course of the operation is inconsequential for the operation.
Price, et. al. Standards Track [Page 32] RFC 3320 Signaling Compression (SigComp) January 2003
Price, et. al. Standards Track [Page 32] RFC 3320 Signaling Compression (SigComp) January 2003
8.4. Byte copying
8.4. Byte copying
A number of UDVM instructions require a string of bytes to be copied to and from areas of the UDVM memory. This section defines how the byte copying operation should be performed.
A number of UDVM instructions require a string of bytes to be copied to and from areas of the UDVM memory. This section defines how the byte copying operation should be performed.
The string of bytes is copied in ascending order of memory address, respecting the bounds set by byte_copy_left and byte_copy_right. More precisely, if a byte is copied from/to Address m then the next byte is copied from/to Address n where n is calculated as follows:
The string of bytes is copied in ascending order of memory address, respecting the bounds set by byte_copy_left and byte_copy_right. More precisely, if a byte is copied from/to Address m then the next byte is copied from/to Address n where n is calculated as follows:
Set k := m + 1 (modulo 2^16) If k = byte_copy_right then set n := byte_copy_left, else set n := k
Set k := m + 1 (modulo 2^16) If k = byte_copy_right then set n := byte_copy_left, else set n := k
Decompression failure occurs if a byte is copied from/to an address beyond the UDVM memory.
Decompression failure occurs if a byte is copied from/to an address beyond the UDVM memory.
Note that the string of bytes is copied one byte at a time. In particular, some of the later bytes to be copied may themselves have been written into the UDVM memory by the byte copying operation currently being performed.
Note that the string of bytes is copied one byte at a time. In particular, some of the later bytes to be copied may themselves have been written into the UDVM memory by the byte copying operation currently being performed.
Equally, it is possible for a byte copying operation to overwrite the instruction that invoked the byte copy. If this occurs, then the byte copying operation MUST be completed as if the original instruction were still in place in the UDVM memory (this also applies if byte_copy_left or byte_copy_right are overwritten).
Equally, it is possible for a byte copying operation to overwrite the instruction that invoked the byte copy. If this occurs, then the byte copying operation MUST be completed as if the original instruction were still in place in the UDVM memory (this also applies if byte_copy_left or byte_copy_right are overwritten).
Byte copying is used by the following UDVM instructions:
Byte copying is used by the following UDVM instructions:
SHA-1, COPY, COPY-LITERAL, COPY-OFFSET, MEMSET, INPUT-BYTES, STATE- ACCESS, OUTPUT, END-MESSAGE
SHA-1, COPY, COPY-LITERAL, COPY-OFFSET, MEMSET, INPUT-BYTES, STATE- ACCESS, OUTPUT, END-MESSAGE
8.5. Instruction operands and UDVM bytecode
8.5. Instruction operands and UDVM bytecode
Each of the UDVM instructions in a piece of UDVM bytecode is represented by a single byte, followed by 0 or more bytes containing the operands required by the instruction.
Each of the UDVM instructions in a piece of UDVM bytecode is represented by a single byte, followed by 0 or more bytes containing the operands required by the instruction.
During instruction execution, conceptually the UDVM first fetches the first byte of the instruction, determines the number and types of operands required for this instruction, and then decodes all the operands in sequence before starting to act on the instruction. (Note that the UDVM instructions have been designed in such a way that this sequence remains conceptual in those cases where it would result in an unreasonable burden on the implementation.)
During instruction execution, conceptually the UDVM first fetches the first byte of the instruction, determines the number and types of operands required for this instruction, and then decodes all the operands in sequence before starting to act on the instruction. (Note that the UDVM instructions have been designed in such a way that this sequence remains conceptual in those cases where it would result in an unreasonable burden on the implementation.)
Price, et. al. Standards Track [Page 33] RFC 3320 Signaling Compression (SigComp) January 2003
Price, et. al. Standards Track [Page 33] RFC 3320 Signaling Compression (SigComp) January 2003
To reduce the size of typical UDVM bytecode, each operand for a UDVM instruction is compressed using variable-length encoding. The aim is to store more common operand values using fewer bytes than rarely occurring values.
To reduce the size of typical UDVM bytecode, each operand for a UDVM instruction is compressed using variable-length encoding. The aim is to store more common operand values using fewer bytes than rarely occurring values.
Four different types of operand are available: the literal, the reference, the multitype and the address. Chapter 9 gives a complete list of UDVM instructions and the operand types that follow each instruction.
Four different types of operand are available: the literal, the reference, the multitype and the address. Chapter 9 gives a complete list of UDVM instructions and the operand types that follow each instruction.
The UDVM bytecode for each operand type is illustrated in Figure 8 to Figure 10, together with the integer values represented by the bytecode.
The UDVM bytecode for each operand type is illustrated in Figure 8 to Figure 10, together with the integer values represented by the bytecode.
Note that the MSBs in the bytecode are illustrated as preceding the LSBs. Also, any string of bits marked with k consecutive "n"s is to be interpreted as an integer N from 0 to 2^k - 1 inclusive (with the MSBs of n illustrated as preceding the LSBs).
Note that the MSBs in the bytecode are illustrated as preceding the LSBs. Also, any string of bits marked with k consecutive "n"s is to be interpreted as an integer N from 0 to 2^k - 1 inclusive (with the MSBs of n illustrated as preceding the LSBs).
The decoded integer value of the bytecode can be interpreted in two ways. In some cases it is taken to be the actual value of the operand. In other cases it is taken to be a memory address at which the 2-byte operand value can be found (MSBs found at the specified address, LSBs found at the following address). The latter cases are denoted by memory[X] where X is the address and memory[X] is the 2- byte value starting at Address X.
The decoded integer value of the bytecode can be interpreted in two ways. In some cases it is taken to be the actual value of the operand. In other cases it is taken to be a memory address at which the 2-byte operand value can be found (MSBs found at the specified address, LSBs found at the following address). The latter cases are denoted by memory[X] where X is the address and memory[X] is the 2- byte value starting at Address X.
The simplest operand type is the literal (#), which encodes a constant integer from 0 to 65535 inclusive. A literal operand may require between 1 and 3 bytes depending on its value.
The simplest operand type is the literal (#), which encodes a constant integer from 0 to 65535 inclusive. A literal operand may require between 1 and 3 bytes depending on its value.
Bytecode: Operand value: Range:
Bytecode: Operand value: Range:
0nnnnnnn N 0 - 127 10nnnnnn nnnnnnnn N 0 - 16383 11000000 nnnnnnnn nnnnnnnn N 0 - 65535
0nnnnnnn N 0 - 127 10nnnnnn nnnnnnnn N 0 - 16383 11000000 nnnnnnnn nnnnnnnn N 0 - 65535
Figure 8: Bytecode for a literal (#) operand
Figure 8: Bytecode for a literal (#) operand
The second operand type is the reference ($), which is always used to access a 2-byte value located elsewhere in the UDVM memory. The bytecode for a reference operand is decoded to be a constant integer from 0 to 65535 inclusive, which is interpreted as the memory address containing the actual value of the operand.
The second operand type is the reference ($), which is always used to access a 2-byte value located elsewhere in the UDVM memory. The bytecode for a reference operand is decoded to be a constant integer from 0 to 65535 inclusive, which is interpreted as the memory address containing the actual value of the operand.
Price, et. al. Standards Track [Page 34] RFC 3320 Signaling Compression (SigComp) January 2003
Price, et. al. Standards Track [Page 34] RFC 3320 Signaling Compression (SigComp) January 2003
Bytecode: Operand value: Range:
Bytecode: Operand value: Range:
0nnnnnnn memory[2 * N] 0 - 65535 10nnnnnn nnnnnnnn memory[2 * N] 0 - 65535 11000000 nnnnnnnn nnnnnnnn memory[N] 0 - 65535
0nnnnnnn memory[2 * N] 0 - 65535 10nnnnnn nnnnnnnn memory[2 * N] 0 - 65535 11000000 nnnnnnnn nnnnnnnn memory[N] 0 - 65535
Figure 9: Bytecode for a reference ($) operand
Figure 9: Bytecode for a reference ($) operand
Note that the range of a reference operand is always 0 - 65535 independently of how many bits are used to encode the reference, because the operand always references a 2-byte value in the memory.
Note that the range of a reference operand is always 0 - 65535 independently of how many bits are used to encode the reference, because the operand always references a 2-byte value in the memory.
The third kind of operand is the multitype (%), which can be used to encode both actual values and memory addresses. The multitype operand also offers efficient encoding for small integer values (both positive and negative) and for powers of 2.
The third kind of operand is the multitype (%), which can be used to encode both actual values and memory addresses. The multitype operand also offers efficient encoding for small integer values (both positive and negative) and for powers of 2.
Bytecode: Operand value: Range:
Bytecode: Operand value: Range:
00nnnnnn N 0 - 63 01nnnnnn memory[2 * N] 0 - 65535 1000011n 2 ^ (N + 6) 64 , 128 10001nnn 2 ^ (N + 8) 256 , ... , 32768 111nnnnn N + 65504 65504 - 65535 1001nnnn nnnnnnnn N + 61440 61440 - 65535 101nnnnn nnnnnnnn N 0 - 8191 110nnnnn nnnnnnnn memory[N] 0 - 65535 10000000 nnnnnnnn nnnnnnnn N 0 - 65535 10000001 nnnnnnnn nnnnnnnn memory[N] 0 - 65535
00nnnnnn N 0 - 63 01nnnnnn memory[2 * N] 0 - 65535 1000011n 2 ^ (N + 6) 64 , 128 10001nnn 2 ^ (N + 8) 256 , ... , 32768 111nnnnn N + 65504 65504 - 65535 1001nnnn nnnnnnnn N + 61440 61440 - 65535 101nnnnn nnnnnnnn N 0 - 8191 110nnnnn nnnnnnnn memory[N] 0 - 65535 10000000 nnnnnnnn nnnnnnnn N 0 - 65535 10000001 nnnnnnnn nnnnnnnn memory[N] 0 - 65535
Figure 10: Bytecode for a multitype (%) operand
Figure 10: Bytecode for a multitype (%) operand
The fourth operand type is the address (@). This operand is decoded as a multitype operand followed by a further step: the memory address of the UDVM instruction containing the address operand is added to obtain the correct operand value. So if the operand value from Figure 10 is D then the actual operand value of an address is calculated as follows:
The fourth operand type is the address (@). This operand is decoded as a multitype operand followed by a further step: the memory address of the UDVM instruction containing the address operand is added to obtain the correct operand value. So if the operand value from Figure 10 is D then the actual operand value of an address is calculated as follows:
operand_value = (memory_address_of_instruction + D) modulo 2^16
operand_value = (memory_address_of_instruction + D) modulo 2^16
Address operands are always used in instructions that control program flow, because they ensure that the UDVM bytecode is position- independent code (i.e., it will run independently of where it is placed in the UDVM memory).
Address operands are always used in instructions that control program flow, because they ensure that the UDVM bytecode is position- independent code (i.e., it will run independently of where it is placed in the UDVM memory).
Price, et. al. Standards Track [Page 35] RFC 3320 Signaling Compression (SigComp) January 2003
Price, et. al. Standards Track [Page 35] RFC 3320 Signaling Compression (SigComp) January 2003
8.6. UDVM Cycles
8.6. UDVM Cycles
Once the UDVM has been invoked it executes the instructions contained in its memory consecutively unless otherwise indicated (for example when the UDVM encounters a JUMP instruction). If the next instruction to be executed lies outside the available memory then decompression failure occurs (see Section 8.7).
Once the UDVM has been invoked it executes the instructions contained in its memory consecutively unless otherwise indicated (for example when the UDVM encounters a JUMP instruction). If the next instruction to be executed lies outside the available memory then decompression failure occurs (see Section 8.7).
To ensure that a SigComp message cannot consume excessive processing resources, SigComp limits the number of "UDVM cycles" allocated to each message. The number of available UDVM cycles is initialized to 1000 plus the number of bits in the SigComp header (as described in Section 7); this sum is then multiplied by cycles_per_bit. Each time an instruction is executed the number of available UDVM cycles is decreased by the amount specified in Chapter 9. Additionally, if the UDVM successfully requests n bits of compressed data using one of the INPUT instructions then the number of available UDVM cycles is increased by n * cycles_per_bit once the instruction has been executed.
To ensure that a SigComp message cannot consume excessive processing resources, SigComp limits the number of "UDVM cycles" allocated to each message. The number of available UDVM cycles is initialized to 1000 plus the number of bits in the SigComp header (as described in Section 7); this sum is then multiplied by cycles_per_bit. Each time an instruction is executed the number of available UDVM cycles is decreased by the amount specified in Chapter 9. Additionally, if the UDVM successfully requests n bits of compressed data using one of the INPUT instructions then the number of available UDVM cycles is increased by n * cycles_per_bit once the instruction has been executed.
This means that the maximum number of UDVM cycles available for processing an n-byte SigComp message is given by the formula:
This means that the maximum number of UDVM cycles available for processing an n-byte SigComp message is given by the formula:
maximum_UDVM_cycles = (8 * n + 1000) * cycles_per_bit
maximum_UDVM_cycles = (8 * n + 1000) * cycles_per_bit
The reason that this total is not allocated to the UDVM when it is invoked is that the UDVM can begin to decompress a message that has only been partially received. So the total message size may not be known when the UDVM is initialized.
The reason that this total is not allocated to the UDVM when it is invoked is that the UDVM can begin to decompress a message that has only been partially received. So the total message size may not be known when the UDVM is initialized.
Note that the number of UDVM cycles MUST NOT be increased if a request for additional compressed data fails.
Note that the number of UDVM cycles MUST NOT be increased if a request for additional compressed data fails.
The UDVM stops executing instructions when it encounters an END- MESSAGE instruction or if decompression failure occurs (see Section 8.7 for further details).
The UDVM stops executing instructions when it encounters an END- MESSAGE instruction or if decompression failure occurs (see Section 8.7 for further details).
8.7. Decompression Failure
8.7. Decompression Failure
If a compressed message given to the UDVM is corrupted (either accidentally or maliciously), then the UDVM may terminate with a decompression failure.
If a compressed message given to the UDVM is corrupted (either accidentally or maliciously), then the UDVM may terminate with a decompression failure.
Price, et. al. Standards Track [Page 36] RFC 3320 Signaling Compression (SigComp) January 2003
Price, et. al. Standards Track [Page 36] RFC 3320 Signaling Compression (SigComp) January 2003
Reasons for decompression failure include the following:
Reasons for decompression failure include the following:
1. A SigComp message contains an invalid header as per Chapter 7.
1. A SigComp message contains an invalid header as per Chapter 7.
2. A SigComp message is larger than the decompression_memory_size.
2. A SigComp message is larger than the decompression_memory_size.
3. An instruction costs more than the number of remaining UDVM
cycles.
3. An instruction costs more than the number of remaining UDVM cycles.
4. The UDVM attempts to read from or write to a memory address beyond
its memory size.
4. The UDVM attempts to read from or write to a memory address beyond its memory size.
5. An unknown instruction is encountered.
5. An unknown instruction is encountered.
6. An unknown operand is encountered.
6. An unknown operand is encountered.
7. An instruction is encountered that cannot be processed
successfully by the UDVM (for example a RETURN instruction when no
CALL instruction has previously been encountered).
7. An instruction is encountered that cannot be processed successfully by the UDVM (for example a RETURN instruction when no CALL instruction has previously been encountered).
8. A request to access some state information fails.
8. A request to access some state information fails.
9. A manual decompression failure is triggered using the
DECOMPRESSION-FAILURE instruction.
9. A manual decompression failure is triggered using the DECOMPRESSION-FAILURE instruction.
If a decompression failure occurs when decompressing a message then the UDVM informs the dispatcher and takes no further action. It is the responsibility of the dispatcher to decide how to cope with the decompression failure. In general a dispatcher SHOULD discard the compressed message (or the compressed stream if the transport is stream-based) and any decompressed data that has been outputted but not yet passed to the application.
If a decompression failure occurs when decompressing a message then the UDVM informs the dispatcher and takes no further action. It is the responsibility of the dispatcher to decide how to cope with the decompression failure. In general a dispatcher SHOULD discard the compressed message (or the compressed stream if the transport is stream-based) and any decompressed data that has been outputted but not yet passed to the application.
9. UDVM Instruction Set
9. UDVM Instruction Set
The UDVM currently understands 36 instructions, chosen to support the widest possible range of compression algorithms with the minimum possible overhead.
The UDVM currently understands 36 instructions, chosen to support the widest possible range of compression algorithms with the minimum possible overhead.
Figure 11 lists the different instructions and the bytecode values used to encode the instructions. The cost of each instruction in UDVM cycles is also given:
Figure 11 lists the different instructions and the bytecode values used to encode the instructions. The cost of each instruction in UDVM cycles is also given:
Price, et. al. Standards Track [Page 37] RFC 3320 Signaling Compression (SigComp) January 2003
Price, et. al. Standards Track [Page 37] RFC 3320 Signaling Compression (SigComp) January 2003
Instruction: Bytecode value: Cost in UDVM cycles:
Instruction: Bytecode value: Cost in UDVM cycles:
DECOMPRESSION-FAILURE 0 1 AND 1 1 OR 2 1 NOT 3 1 LSHIFT 4 1 RSHIFT 5 1 ADD 6 1 SUBTRACT 7 1 MULTIPLY 8 1 DIVIDE 9 1 REMAINDER 10 1 SORT-ASCENDING 11 1 + k * (ceiling(log2(k)) + n) SORT-DESCENDING 12 1 + k * (ceiling(log2(k)) + n) SHA-1 13 1 + length LOAD 14 1 MULTILOAD 15 1 + n PUSH 16 1 POP 17 1 COPY 18 1 + length COPY-LITERAL 19 1 + length COPY-OFFSET 20 1 + length MEMSET 21 1 + length JUMP 22 1 COMPARE 23 1 CALL 24 1 RETURN 25 1 SWITCH 26 1 + n CRC 27 1 + length INPUT-BYTES 28 1 + length INPUT-BITS 29 1 INPUT-HUFFMAN 30 1 + n STATE-ACCESS 31 1 + state_length STATE-CREATE 32 1 + state_length STATE-FREE 33 1 OUTPUT 34 1 + output_length END-MESSAGE 35 1 + state_length
DECOMPRESSION-FAILURE 0 1 AND 1 1 OR 2 1 NOT 3 1 LSHIFT 4 1 RSHIFT 5 1 ADD 6 1 SUBTRACT 7 1 MULTIPLY 8 1 DIVIDE 9 1 REMAINDER 10 1 SORT-ASCENDING 11 1 + k * (ceiling(log2(k)) + n) SORT-DESCENDING 12 1 + k * (ceiling(log2(k)) + n) SHA-1 13 1 + length LOAD 14 1 MULTILOAD 15 1 + n PUSH 16 1 POP 17 1 COPY 18 1 + length COPY-LITERAL 19 1 + length COPY-OFFSET 20 1 + length MEMSET 21 1 + length JUMP 22 1 COMPARE 23 1 CALL 24 1 RETURN 25 1 SWITCH 26 1 + n CRC 27 1 + length INPUT-BYTES 28 1 + length INPUT-BITS 29 1 INPUT-HUFFMAN 30 1 + n STATE-ACCESS 31 1 + state_length STATE-CREATE 32 1 + state_length STATE-FREE 33 1 OUTPUT 34 1 + output_length END-MESSAGE 35 1 + state_length
Figure 11: UDVM instructions and corresponding bytecode values
Figure 11: UDVM instructions and corresponding bytecode values
Each UDVM instruction costs a minimum of 1 UDVM cycle. Certain instructions may cost additional cycles depending on the values of the instruction operands. Named variables in the cost expressions refer to the values of the instruction operands with these names.
Each UDVM instruction costs a minimum of 1 UDVM cycle. Certain instructions may cost additional cycles depending on the values of the instruction operands. Named variables in the cost expressions refer to the values of the instruction operands with these names.
Note that for the SORT instructions, the formula ceiling(log2(k)) calculates the smallest value i such that k <= 2^i.
Note that for the SORT instructions, the formula ceiling(log2(k)) calculates the smallest value i such that k <= 2^i.
Price, et. al. Standards Track [Page 38] RFC 3320 Signaling Compression (SigComp) January 2003
Price, et. al. Standards Track [Page 38] RFC 3320 Signaling Compression (SigComp) January 2003
The UDVM instruction set offers a mix of low-level and high-level instructions. The high-level instructions can all be emulated using combinations of low-level instructions, but given a choice it is generally preferable to use a single instruction rather than a large number of general-purpose instructions. The resulting bytecode will be more compact (leading to a higher overall compression ratio) and decompression will typically be faster because the implementation of the high-level instructions can be more easily optimized.
The UDVM instruction set offers a mix of low-level and high-level instructions. The high-level instructions can all be emulated using combinations of low-level instructions, but given a choice it is generally preferable to use a single instruction rather than a large number of general-purpose instructions. The resulting bytecode will be more compact (leading to a higher overall compression ratio) and decompression will typically be faster because the implementation of the high-level instructions can be more easily optimized.
All instructions are encoded as a single byte to indicate the instruction type, followed by 0 or more bytes containing the operands required by the instruction. The instruction specifies which of the four operand types of Section 8.5 is used in each case. For example the ADD instruction is followed by two operands:
All instructions are encoded as a single byte to indicate the instruction type, followed by 0 or more bytes containing the operands required by the instruction. The instruction specifies which of the four operand types of Section 8.5 is used in each case. For example the ADD instruction is followed by two operands:
ADD ($operand_1, %operand_2)
ADD ($operand_1, %operand_2)
When converted into bytecode the number of bytes required by the ADD instruction depends on the value of each operand, and whether the multitype operand contains the operand value itself or a memory address where the actual value of the operand can be found.
When converted into bytecode the number of bytes required by the ADD instruction depends on the value of each operand, and whether the multitype operand contains the operand value itself or a memory address where the actual value of the operand can be found.
Each instruction is explained in more detail below.
Each instruction is explained in more detail below.
Whenever the description of an instruction uses the expression "and then", the intended semantics is that the effect explained before "and then" is completed before work on the effect explained after the "and then" is commenced.
Whenever the description of an instruction uses the expression "and then", the intended semantics is that the effect explained before "and then" is completed before work on the effect explained after the "and then" is commenced.
9.1. Mathematical Instructions
9.1. Mathematical Instructions
The following instructions provide a number of mathematical operations including bit manipulation, arithmetic and sorting.
The following instructions provide a number of mathematical operations including bit manipulation, arithmetic and sorting.
9.1.1. Bit Manipulation
9.1.1. Bit Manipulation
The AND, OR, NOT, LSHIFT and RSHIFT instructions provide simple bit manipulation on 2-byte words.
The AND, OR, NOT, LSHIFT and RSHIFT instructions provide simple bit manipulation on 2-byte words.
AND ($operand_1, %operand_2) OR ($operand_1, %operand_2) NOT ($operand_1) LSHIFT ($operand_1, %operand_2) RSHIFT ($operand_1, %operand_2)
AND ($operand_1, %operand_2) OR ($operand_1, %operand_2) NOT ($operand_1) LSHIFT ($operand_1, %operand_2) RSHIFT ($operand_1, %operand_2)
Price, et. al. Standards Track [Page 39] RFC 3320 Signaling Compression (SigComp) January 2003
Price, et. al. Standards Track [Page 39] RFC 3320 Signaling Compression (SigComp) January 2003
After the operation is complete, the value of the first operand is overwritten with the result. (Note that since this operand is a reference, it is the 2-byte word at the memory address specified by the operand that is overwritten.)
After the operation is complete, the value of the first operand is overwritten with the result. (Note that since this operand is a reference, it is the 2-byte word at the memory address specified by the operand that is overwritten.)
The precise definitions of LSHIFT and RSHIFT are given below. Note that m and n are the 2-byte values encoded by the operands, and that floor(x) calculates the largest integer not greater than x:
The precise definitions of LSHIFT and RSHIFT are given below. Note that m and n are the 2-byte values encoded by the operands, and that floor(x) calculates the largest integer not greater than x:
LSHIFT (m, n) := m * 2^n (modulo 2^16) RSHIFT (m, n) := floor(m / 2^n)
LSHIFT (m, n) := m * 2^n (modulo 2^16) RSHIFT (m, n) := floor(m / 2^n)
9.1.2. Arithmetic
9.1.2. Arithmetic
The ADD, SUBTRACT, MULTIPLY, DIVIDE and REMAINDER instructions perform arithmetic on 2-byte words.
The ADD, SUBTRACT, MULTIPLY, DIVIDE and REMAINDER instructions perform arithmetic on 2-byte words.
ADD ($operand_1, %operand_2) SUBTRACT ($operand_1, %operand_2) MULTIPLY ($operand_1, %operand_2) DIVIDE ($operand_1, %operand_2) REMAINDER ($operand_1, %operand_2)
ADD ($operand_1, %operand_2) SUBTRACT ($operand_1, %operand_2) MULTIPLY ($operand_1, %operand_2) DIVIDE ($operand_1, %operand_2) REMAINDER ($operand_1, %operand_2)
After the operation is complete, the value of the first operand is overwritten with the result.
After the operation is complete, the value of the first operand is overwritten with the result.
The precise definition of each instruction is given below:
The precise definition of each instruction is given below:
ADD (m, n) := m + n (modulo 2^16) SUBTRACT (m, n) := m - n (modulo 2^16) MULTIPLY (m, n) := m * n (modulo 2^16) DIVIDE (m, n) := floor(m / n) REMAINDER (m, n) := m - n * floor(m / n)
ADD (m, n) := m + n (modulo 2^16) SUBTRACT (m, n) := m - n (modulo 2^16) MULTIPLY (m, n) := m * n (modulo 2^16) DIVIDE (m, n) := floor(m / n) REMAINDER (m, n) := m - n * floor(m / n)
Decompression failure occurs if a DIVIDE or REMAINDER instruction encounters an operand_2 that is zero.
Decompression failure occurs if a DIVIDE or REMAINDER instruction encounters an operand_2 that is zero.
9.1.3. Sorting
9.1.3. Sorting
The SORT-ASCENDING and SORT-DESCENDING instructions sort lists of 2- byte words.
The SORT-ASCENDING and SORT-DESCENDING instructions sort lists of 2- byte words.
SORT-ASCENDING (%start, %n, %k) SORT-DESCENDING (%start, %n, %k)
SORT-ASCENDING (%start, %n, %k) SORT-DESCENDING (%start, %n, %k)
The start operand specifies the starting memory address of the block of data to be sorted.
The start operand specifies the starting memory address of the block of data to be sorted.
Price, et. al. Standards Track [Page 40] RFC 3320 Signaling Compression (SigComp) January 2003
Price, et. al. Standards Track [Page 40] RFC 3320 Signaling Compression (SigComp) January 2003
The block of data itself is divided into n lists each containing k 2-byte words. The SORT-ASCENDING instruction applies a certain permutation to the lists, such that the first list is sorted into ascending order (treating each 2-byte word as an unsigned integer). The same permutation is applied to all n lists, so lists other than the first will not necessarily be sorted into order.
The block of data itself is divided into n lists each containing k 2-byte words. The SORT-ASCENDING instruction applies a certain permutation to the lists, such that the first list is sorted into ascending order (treating each 2-byte word as an unsigned integer). The same permutation is applied to all n lists, so lists other than the first will not necessarily be sorted into order.
In the case that two words have the same value, the original ordering of the list is preserved.
In the case that two words have the same value, the original ordering of the list is preserved.
For example, the first list might contain a set of integers to be sorted whilst the second list might be used to keep track of where the integers appear in the sorted list:
For example, the first list might contain a set of integers to be sorted whilst the second list might be used to keep track of where the integers appear in the sorted list:
Before sorting After sorting
Before sorting After sorting
List 1 List 2 List 1 List 2
List 1 List 2 List 1 List 2
8 1 1 2
1 2 1 3
1 3 3 4
3 4 8 1
8 1 1 2 1 2 1 3 1 3 3 4 3 4 8 1
The SORT-DESCENDING instruction behaves as above, except that the first list is sorted into descending order.
The SORT-DESCENDING instruction behaves as above, except that the first list is sorted into descending order.
9.1.4. SHA-1
9.1.4. SHA-1
The SHA-1 instruction calculates a 20-byte SHA-1 hash [RFC-3174] over the specified area of UDVM memory.
The SHA-1 instruction calculates a 20-byte SHA-1 hash [RFC-3174] over the specified area of UDVM memory.
SHA-1 (%position, %length, %destination)
SHA-1 (%position, %length, %destination)
The position and length operands specify the starting memory address and the length of the byte string over which the SHA-1 hash is calculated. Byte copying rules are enforced as per Section 8.4.
The position and length operands specify the starting memory address and the length of the byte string over which the SHA-1 hash is calculated. Byte copying rules are enforced as per Section 8.4.
The destination operand gives the starting address to which the resulting 20-byte hash will be copied. Byte copying rules are enforced as above.
The destination operand gives the starting address to which the resulting 20-byte hash will be copied. Byte copying rules are enforced as above.
9.2. Memory Management Instructions
9.2. Memory Management Instructions
The following instructions are used to set up the UDVM memory, and to copy byte strings from one memory location to another.
The following instructions are used to set up the UDVM memory, and to copy byte strings from one memory location to another.
Price, et. al. Standards Track [Page 41] RFC 3320 Signaling Compression (SigComp) January 2003
Price, et. al. Standards Track [Page 41] RFC 3320 Signaling Compression (SigComp) January 2003
9.2.1. LOAD
9.2.1. LOAD
The LOAD instruction sets a 2-byte word to a certain specified value. The format of a LOAD instruction is as follows:
The LOAD instruction sets a 2-byte word to a certain specified value. The format of a LOAD instruction is as follows:
LOAD (%address, %value)
LOAD (%address, %value)
The first operand specifies the starting address of a 2-byte word, whilst the second operand specifies the value to be loaded into this word. As usual, MSBs are stored before LSBs in the UDVM memory.
The first operand specifies the starting address of a 2-byte word, whilst the second operand specifies the value to be loaded into this word. As usual, MSBs are stored before LSBs in the UDVM memory.
9.2.2. MULTILOAD
9.2.2. MULTILOAD
The MULTILOAD instruction sets a contiguous block of 2-byte words in the UDVM memory to specified values.
The MULTILOAD instruction sets a contiguous block of 2-byte words in the UDVM memory to specified values.
MULTILOAD (%address, #n, %value_0, ..., %value_n-1)
MULTILOAD (%address, #n, %value_0, ..., %value_n-1)
The first operand specifies the starting address of the contiguous 2-byte words, whilst the operands value_0 through to value_n-1 specify the values to load into these words (in the same order as they appear in the instruction).
The first operand specifies the starting address of the contiguous 2-byte words, whilst the operands value_0 through to value_n-1 specify the values to load into these words (in the same order as they appear in the instruction).
Decompression failure occurs if the set of 2-byte words set by the instruction would overlap the memory locations held by the instruction (including its operands) itself, i.e., if the instruction would be self-modifying. (This restriction makes it simpler to implement MULTILOAD step-by-step instead of having to decode all operands before being able to copy data, as is implied by the conceptual model of instruction execution.)
Decompression failure occurs if the set of 2-byte words set by the instruction would overlap the memory locations held by the instruction (including its operands) itself, i.e., if the instruction would be self-modifying. (This restriction makes it simpler to implement MULTILOAD step-by-step instead of having to decode all operands before being able to copy data, as is implied by the conceptual model of instruction execution.)
9.2.3. PUSH and POP
9.2.3. PUSH and POP
The PUSH and POP instructions read from and write to the UDVM stack (as defined in Section 8.3).
The PUSH and POP instructions read from and write to the UDVM stack (as defined in Section 8.3).
PUSH (%value) POP (%address)
PUSH (%value) POP (%address)
The PUSH instruction pushes the value specified by its operand on the stack.
The PUSH instruction pushes the value specified by its operand on the stack.
The POP instruction pops a value from the stack and then copies the value to the specified memory address. (Note that the expression "and then" implies that the copying of the value is inconsequential for the stack operation itself, which happens beforehand.)
The POP instruction pops a value from the stack and then copies the value to the specified memory address. (Note that the expression "and then" implies that the copying of the value is inconsequential for the stack operation itself, which happens beforehand.)
See Section 8.3 for possible error conditions.
See Section 8.3 for possible error conditions.
Price, et. al. Standards Track [Page 42] RFC 3320 Signaling Compression (SigComp) January 2003
Price, et. al. Standards Track [Page 42] RFC 3320 Signaling Compression (SigComp) January 2003
9.2.4. COPY
9.2.4. COPY
The COPY instruction is used to copy a string of bytes from one part of the UDVM memory to another.
The COPY instruction is used to copy a string of bytes from one part of the UDVM memory to another.
COPY (%position, %length, %destination)
COPY (%position, %length, %destination)
The position operand specifies the memory address of the first byte in the string to be copied, and the length operand specifies the number of bytes to be copied.
The position operand specifies the memory address of the first byte in the string to be copied, and the length operand specifies the number of bytes to be copied.
The destination operand gives the address to which the first byte in the string will be copied.
The destination operand gives the address to which the first byte in the string will be copied.
Byte copying is performed as per the rules of Section 8.4.
Byte copying is performed as per the rules of Section 8.4.
9.2.5. COPY-LITERAL
9.2.5. COPY-LITERAL
A modified version of the COPY instruction is given below:
A modified version of the COPY instruction is given below:
COPY-LITERAL (%position, %length, $destination)
COPY-LITERAL (%position, %length, $destination)
The COPY-LITERAL instruction behaves as a COPY instruction except that after copying is completed, the value of the destination operand is replaced by the address to which the next byte of data would be copied. More precisely it is replaced by the value n, derived as per Section 8.4 with m set to the destination address of the last byte to be copied, if any (i.e., if the value of the length operand is zero, the value of the destination operand is not changed).
The COPY-LITERAL instruction behaves as a COPY instruction except that after copying is completed, the value of the destination operand is replaced by the address to which the next byte of data would be copied. More precisely it is replaced by the value n, derived as per Section 8.4 with m set to the destination address of the last byte to be copied, if any (i.e., if the value of the length operand is zero, the value of the destination operand is not changed).
9.2.6. COPY-OFFSET
9.2.6. COPY-OFFSET
A further version of the COPY-LITERAL instruction is given below:
A further version of the COPY-LITERAL instruction is given below:
COPY-OFFSET (%offset, %length, $destination)
COPY-OFFSET (%offset, %length, $destination)
The COPY-OFFSET instruction behaves as a COPY-LITERAL instruction except that an offset operand is given instead of a position operand.
The COPY-OFFSET instruction behaves as a COPY-LITERAL instruction except that an offset operand is given instead of a position operand.
To derive the value of the position operand, starting at the memory address specified by destination, the UDVM counts backwards a total of offset memory addresses.
To derive the value of the position operand, starting at the memory address specified by destination, the UDVM counts backwards a total of offset memory addresses.
If the memory address specified in byte_copy_left is reached, the next memory address is taken to be (byte_copy_right - 1) modulo 2^16.
If the memory address specified in byte_copy_left is reached, the next memory address is taken to be (byte_copy_right - 1) modulo 2^16.
Price, et. al. Standards Track [Page 43] RFC 3320 Signaling Compression (SigComp) January 2003
Price, et. al. Standards Track [Page 43] RFC 3320 Signaling Compression (SigComp) January 2003
The COPY-OFFSET instruction then behaves as a COPY-LITERAL instruction, taking the value of the position operand to be the last memory address reached in the above step.
The COPY-OFFSET instruction then behaves as a COPY-LITERAL instruction, taking the value of the position operand to be the last memory address reached in the above step.
9.2.7. MEMSET
9.2.7. MEMSET
The MEMSET instruction initializes an area of UDVM memory to a specified sequence of values. The format of a MEMSET instruction is as follows:
The MEMSET instruction initializes an area of UDVM memory to a specified sequence of values. The format of a MEMSET instruction is as follows:
MEMSET (%address, %length, %start_value, %offset)
MEMSET(%アドレス、%スタート_が、%が相殺するのを評価する%の長さ)
The sequence of values used by the MEMSET instruction is specified by the following formula:
MEMSET指示で使用される値の系列は以下の公式によって指定されます:
Seq[n] := (start_value + n * offset) modulo 256
Seq[n]:=(始め_値+n*は相殺された)法256
The values Seq[0] to Seq[length - 1] inclusive are each interpreted as a single byte, and then concatenated to form a byte string where the first byte has value Seq[0], the second byte has value Seq[1] and so on up to the last byte which has value Seq[length - 1].
Seq[長さ--1]に包括的な値のSeq[0]は、1バイトとしてそれぞれ解釈されて、次に、最初のバイトには値のSeq[0]があって、2番目のバイトが値のSeq[1]などを値のSeq[長さ--1]を持っている最後のバイトまで持っているバイトストリングを形成するために連結されます。
The string is then byte copied into the UDVM memory beginning at the memory address specified as an operand to the MEMSET instruction, obeying the rules of Section 8.4. (Note that the byte string may overwrite the MEMSET instruction or its operands; as explained in Section 8.5, the MEMSET instruction must be executed as if the original operands were still in place in the UDVM memory.)
次に、ストリングはオペランドとしてMEMSET指示に指定されたメモリアドレスで始まるUDVMメモリにコピーされたバイトです、セクション8.4の規則に従って。 (バイトストリングがMEMSET指示かそのオペランドを上書きするかもしれないことに注意してください; セクション8.5で説明されるように、まるで元のオペランドがUDVMメモリにまだ適所にあるかのようにMEMSET指示を実行しなければなりません。)
9.3. Program Flow Instructions
9.3. プログラム流れ指示
The following instructions alter the flow of UDVM code. Each instruction jumps to one of a number of memory addresses based on a certain specified criterion.
以下の指示はUDVMコードの流れを変更します。 各指示はある指定された評価基準に基づく多くのメモリアドレスの1つまでジャンプします。
Note that certain I/O instructions (see Section 9.4) can also alter program flow.
また、ある入出力指示(セクション9.4を見る)がプログラム流動を変更できることに注意してください。
9.3.1. JUMP
9.3.1. ジャンプ
The JUMP instruction moves program execution to the specified memory address.
JUMP指示はプログラム実行を指定されたメモリアドレスに動かします。
JUMP (@address)
ジャンプ(@address)
Decompression failure occurs if the value of the address operand lies beyond the overall UDVM memory size.
アドレスオペランドの値が総合的なUDVM記憶容量を超えてあるなら、減圧失敗は起こります。
Price, et. al. Standards Track [Page 44] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[44ページ]RFC3320
9.3.2. COMPARE
9.3.2. 比較してください。
The COMPARE instruction compares two operands and then jumps to one of three specified memory addresses depending on the result.
COMPARE指示は、二つのオペランドを比較して、次に、結果に依存する3つの指定されたメモリアドレスの1つまでジャンプします。
COMPARE (%value_1, %value_2, @address_1, @address_2, @address_3)
比較してください。(%値_1、%値の_2、@address_1、@address_2、@address_3)
If value_1 < value_2 then the UDVM continues instruction execution at the memory address specified by address 1. If value_1 = value_2 then it jumps to the address specified by address_2. If value_1 > value_2 then it jumps to the address specified by address_3.
値_1<値_2であるなら、UDVMはアドレス1によって指定されたメモリアドレスで指示実行を続けています。 値_1が値の_2と等しいなら、それはアドレス_2つ指定されたアドレスまでジャンプします。 値_1>値_2であるなら、それはアドレス_3つ指定されたアドレスまでジャンプします。
9.3.3. CALL and RETURN
9.3.3. 呼び出しとリターン
The CALL and RETURN instructions provide support for compression algorithms with a nested structure.
CALLとRETURN指示は圧縮アルゴリズムのサポートに入れ子構造を提供します。
CALL (@address) RETURN
リターンに(@address)に電話をしてください。
Both instructions use the UDVM stack of Section 8.3. When the UDVM reaches a CALL instruction, it finds the memory address of the instruction immediately following the CALL instruction and pushes this 2-byte value on the stack, ready for later retrieval. It then continues instruction execution at the memory address specified by the address operand.
両方の指示はセクション8.3のUDVMスタックを使用します。 UDVMがCALL指示に達すると、指示のメモリアドレスがすぐにCALL指示に従うのがわかって、スタックのこの2バイトの値を押します、後の検索の、準備ができています。 そして、それはアドレスオペランドによって指定されたメモリアドレスで指示実行を続けています。
When the UDVM reaches a RETURN instruction it pops a value from the stack and then continues instruction execution at the memory address just popped.
UDVMがRETURN指示に達すると、それは、スタックから値を飛び出させて、ただ飛び出すメモリアドレスで指示実行を続けています。
See Section 8.3 for error conditions.
エラー条件に関してセクション8.3を見てください。
9.3.4. SWITCH
9.3.4. スイッチ
The SWITCH instruction performs a conditional jump based on the value of one of its operands.
SWITCH指示はオペランドの1つの値に基づく条件付きのジャンプを実行します。
SWITCH (#n, %j, @address_0, @address_1, ... , @address_n-1)
スイッチ(#、n%j、@address_0、@address_1、…、@address-1)
When a SWITCH instruction is encountered the UDVM reads the value of j. It then continues instruction execution at the address specified by address j.
SWITCH指示が遭遇するとき、UDVMはjの値を読みます。 そして、それはアドレスjによって指定されたアドレスで指示実行を続けています。
Decompression failure occurs if j specifies a value of n or more, or if the address lies beyond the overall UDVM memory size.
jがより多くのnの値を指定するか、またはアドレスが総合的なUDVM記憶容量を超えてあるなら、減圧失敗は起こります。
Price, et. al. Standards Track [Page 45] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[45ページ]RFC3320
9.3.5. CRC
9.3.5. CRC
The CRC instruction verifies a string of bytes using a 2-byte CRC.
CRC指示は、2バイトのCRCを使用することで一連のバイトについて確かめます。
CRC (%value, %position, %length, @address)
CRC(%値、%位置、%の長さ、@address)
The actual CRC calculation is performed using the generator polynomial x^16 + x^12 + x^5 + 1, which coincides with the 2-byte Frame Check Sequence (FCS) of PPP [RFC-1662].
実際のCRC計算は、ジェネレータ多項式x^16+x^12+x^5+1(PPP[RFC-1662]の2バイトのFrame Check Sequence(FCS)と同時に起こります)を使用することで実行されます。
The position and length operands define the string of bytes over which the CRC is evaluated. Byte copying rules are enforced as per Section 8.4.
位置と長さのオペランドはCRCが評価される何バイトものストリングを定義します。 バイト転写規則はセクション8.4に従って励行されます。
The CRC value is computed exactly as defined for the 16-bit FCS calculation in [RFC-1662].
CRC値はちょうど[RFC-1662]の16ビットのFCS計算のために定義されるように計算されます。
The value operand contains the expected integer value of the 2-byte CRC. If the calculated CRC matches the expected value then the UDVM continues instruction execution at the following instruction. Otherwise the UDVM jumps to the memory address specified by the address operand.
値のオペランドは2バイトのCRCの予想された整数値を含んでいます。 計算されたCRCが期待値に合っているなら、UDVMは以下の指示のときに指示実行を続けています。 さもなければ、UDVMはアドレスオペランドによって指定されたメモリアドレスまでジャンプします。
9.4. I/O instructions
9.4. 入出力指示
The following instructions allow the UDVM to interface with its environment. Note that in the overall SigComp architecture all of these interfaces pass to the decompressor dispatcher or to the state handler.
以下の指示で、UDVMは環境に連結できます。 総合的なSigComp構造では、これらのインタフェースのすべてが減圧装置発送者、または、州の操作者に通ることに注意してください。
9.4.1. DECOMPRESSION-FAILURE
9.4.1. 減圧失敗
The DECOMPRESSION-FAILURE instruction triggers a manual decompression failure. This is useful if the UDVM bytecode discovers that it cannot successfully decompress the message (e.g., by using the CRC instruction).
DECOMPRESSION-FAILURE指示は手動の減圧失敗の引き金となります。 UDVMバイトコードが、それが首尾よく、メッセージ(例えば、CRC指示を使用するのによる)を減圧できないと発見するなら、これは役に立ちます。
This instruction has no operands.
この指示には、オペランドが全くありません。
9.4.2. INPUT-BYTES
9.4.2. 入力バイト
The INPUT-BYTES instruction requests a certain number of bytes of compressed data from the decompressor dispatcher.
INPUT-BYTES指示は減圧装置発送者からあるバイト数の圧縮されたデータを要求します。
INPUT-BYTES (%length, %destination, @address)
入力バイト(%の長さ、%の目的地、@address)
Price, et. al. Standards Track [Page 46] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[46ページ]RFC3320
The length operand indicates the requested number of bytes of compressed data, and the destination operand specifies the starting memory address to which they should be copied. Byte copying is performed as per the rules of Section 8.4.
長さのオペランドはバイトの圧縮されたデータの要求された数を示します、そして、目的地オペランドはそれらがコピーされるべきである始めのメモリアドレスを指定します。 バイトコピーはセクション8.4の規則に従って実行されます。
If the instruction requests data that lies beyond the end of the SigComp message, no data is returned. Instead the UDVM moves program execution to the address specified by the address operand.
指示がSigCompメッセージの終わりに、あるデータを要求するなら、データを全く返しません。 代わりに、UDVMはプログラム実行をアドレスオペランドによって指定されたアドレスに動かします。
If the INPUT-BYTES is encountered after an INPUT-BITS or an INPUT- HUFFMAN instruction has been used, and the dispatcher currently holds a fraction of a byte, then the fraction MUST be discarded before any data is passed to the UDVM. The first byte to be passed is the byte immediately following the discarded data.
INPUT-BYTESがINPUT-BITSの後に遭遇するか、INPUTハフマン指示が使用されて、または発送者が現在1バイトの何分の一を開催するなら、どんなデータもUDVMに通過される前に断片を捨てなければなりません。 通過するべき最初のバイトはすぐに捨てられたデータに従うバイトです。
9.4.3. INPUT-BITS
9.4.3. 入力ビット
The INPUT-BITS instruction requests a certain number of bits of compressed data from the decompressor dispatcher.
INPUT-BITS指示は減圧装置発送者からある数のビットの圧縮されたデータを要求します。
INPUT-BITS (%length, %destination, @address)
入力ビット(%の長さ、%の目的地、@address)
The length operand indicates the requested number of bits. Decompression failure occurs if this operand does not lie between 0 and 16 inclusive.
長さのオペランドはビットの要求された数を示します。 このオペランドが包括的に0と16の間ないなら、減圧失敗は起こります。
The destination operand specifies the memory address to which the compressed data should be copied. Note that the requested bits are interpreted as a 2-byte integer ranging from 0 to 2^length - 1, as explained in Section 8.2.
目的地オペランドは圧縮されたデータがコピーされるべきであるメモリアドレスを指定します。 要求されたビットが0〜2^の長さから変化する2バイトの整数として解釈されるというメモ--1 セクション8.2で説明されるように。
If the instruction requests data that lies beyond the end of the SigComp message, no data is returned. Instead the UDVM moves program execution to the address specified by the address operand.
指示がSigCompメッセージの終わりに、あるデータを要求するなら、データを全く返しません。 代わりに、UDVMはプログラム実行をアドレスオペランドによって指定されたアドレスに動かします。
9.4.4. INPUT-HUFFMAN
9.4.4. ハフマンは入力されます。
The INPUT-HUFFMAN instruction requests a variable number of bits of compressed data from the decompressor dispatcher. The instruction initially requests a small number of bits and compares the result against a certain criterion; if the criterion is not met, then additional bits are requested until the criterion is achieved.
INPUT-ハフマン指示は減圧装置発送者から可変数のビットの圧縮されたデータを要求します。 指示は、初めは、少ない数のビットを要求して、ある評価基準に対して結果をたとえます。 評価基準が満たされないなら、評価基準が達成されるまで、追加ビットは要求されます。
The INPUT-HUFFMAN instruction is followed by three mandatory operands plus n additional sets of operands. Every additional set contains four operands as shown below:
3つの義務的なオペランドと追加nセットのオペランドはINPUT-ハフマン指示のあとに続いています。 あらゆる追加セットが以下に示すように4つのオペランドを含んでいます:
Price, et. al. Standards Track [Page 47] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[47ページ]RFC3320
INPUT-HUFFMAN (%destination, @address, #n, %bits_1, %lower_bound_1, %upper_bound_1, %uncompressed_1, ... , %bits_n, %lower_bound_n, %upper_bound_n, %uncompressed_n)
ハフマンは入力されます。(… %の目的地、@address、#、n%ビット_1、%の下側の_は_1を縛って、%の上側の_は_1を縛って、%は_1を解凍して、%ビットであり、%は_バウンド、何%も、より上側の_バウンドを下ろして、%は解凍しました)
Note that if n = 0 then the INPUT-HUFFMAN instruction is ignored and program execution resumes at the following instruction. Decompression failure occurs if (bits_1 + ... + bits_n) > 16.
INPUT-ハフマン指示がn=0であるなら無視されて、プログラム実行が以下の指示のときに再開することに注意してください。 減圧失敗は(…ビット_1++ビット)>16であるなら起こります。
In all other cases, the behavior of the INPUT-HUFFMAN instruction is defined below:
他のすべての場合では、INPUT-ハフマン指示の振舞いは以下で定義されます:
1. Set j := 1 and set H := 0.
1. j:=1を設定してください、そして、H:=0を設定してください。
2. Request bits_j compressed bits. Interpret the returned bits as an
integer k from 0 to 2^bits_j - 1, as explained in Section 8.2.
2. ビット_j圧縮されたビットを要求してください。 整数kとして0〜2まで返されたビットを解釈してください。^ビット_j--1 セクション8.2で説明されるように。
3. Set H := H * 2^bits_j + k.
3. H:=H*2^ビット_j+kを設定してください。
4. If data is requested that lies beyond the end of the SigComp
message, terminate the INPUT-HUFFMAN instruction and move program
execution to the memory address specified by the address operand.
4. SigCompメッセージの終わりに、あるデータが要求されるなら、INPUT-ハフマン指示を終えてください、そして、プログラム実行をアドレスオペランドによって指定されたメモリアドレスに動かしてください。
5. If (H < lower_bound_j) or (H > upper_bound_j) then set j := j + 1.
Then go back to Step 2, unless j > n in which case decompression
failure occurs.
5. (H<の下側の_バウンド_j)か(H>の上側の_バウンド_j)であるなら、j:=j+1を設定してください。 そして、j>nがどのケース減圧の故障に現れないか場合、Step2に戻ってください。
6. Copy (H + uncompressed_j - lower_bound_j) modulo 2^16 to the
memory address specified by the destination operand.
6. メモリアドレスへのコピー(H+解凍された_j--下側の_バウンド_j)法2^16は目的地オペランドで指定しました。
9.4.5. STATE-ACCESS
9.4.5. 州アクセス
The STATE-ACCESS instruction retrieves some previously stored state information.
州-ACCESS指示は何らかの以前に格納された州の情報を検索します。
STATE-ACCESS (%partial_identifier_start, %partial_identifier_length, %state_begin, %state_length, %state_address, %state_instruction)
州アクセス(%部分的な_識別子_は始動して、%部分的な_の識別子_長さ、%州の_は始まって、%は_長さを述べて、%は_アドレスを述べて、%は_指示を述べます)
The partial_identifier_start and partial_identifier_length operands specify the location of the partial state identifier used to retrieve the state information. This identifier has the same function as the partial state identifier transmitted in the SigComp message as per Section 7.2.
部分的な_識別子_始めと部分的な_識別子_長さのオペランドは州の情報を検索するのに使用される部分的な州の識別子の位置を指定します。 この識別子で、部分的な州の識別子がセクション7.2に従ってSigCompメッセージを伝わったように同じくらいは機能します。
Decompression failure occurs if partial_identifier_length does not lie between 6 and 20 inclusive. Decompression failure also occurs if no state item matching the partial state identifier can be found, if
部分的な_の識別子_長さが包括的に6と20の間ないなら、減圧失敗は起こります。 また、部分的な州の識別子に合っている州の項目を全く見つけることができないなら、減圧失敗は起こります。
Price, et. al. Standards Track [Page 48] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[48ページ]RFC3320
more than one state item matches the partial identifier, or if partial_identifier_length is less than the minimum_access_length of the matched state item. Otherwise, a state item is returned from the state handler.
さらに、または部分的な_の識別子_長さが取り組んでいる州の項目の最小の_のアクセス_長さより1つの州の項目が部分的な識別子に合っているより少ないなら。 さもなければ、州の操作者から州の商品を返します。
If any of the operands state_address, state_instruction or state_length is set to 0 then its value is taken from the returned item of state instead.
オペランド状態_アドレス、州の_指示または州の_の長さのどれかを0に設定するなら、代わりに状態の返された項目から値を取ります。
Note that when calculating the number of UDVM cycles the STATE-ACCESS instruction costs (1 + state_length) cycles. The value of state_length MUST be taken from the returned item of state in the case that the state_length operand is set to 0.
UDVM州-ACCESS指示コスト(1+州の_の長さ)サイクルサイクルの数について計算するときにはそれに注意してください。 状態_長さのオペランドが0に設定されて、状態の返された項目から状態_長さの値を取らなければなりません。
The state_begin and state_length operands define the starting byte and number of bytes to copy from the state_value contained in the returned item of state. Decompression failure occurs if bytes are copied from beyond the end of the state_value. Note that decompression failure will always occur if the state_length operand is set to 0 but the state_begin operand is non-zero.
州の_は始まります、そして、状態_長さのオペランドは状態の返された項目に含まれた状態_値からコピーするために始めのバイトとバイト数を定義します。 バイトが状態_価値の終わりを超えてコピーされるなら、減圧失敗は起こります。 状態_長さのオペランドが0に設定されますが、州の_がオペランドを始めると減圧失敗がいつも起こるというメモは非ゼロです。
The state_address operand contains a UDVM memory address. The requested portion of the state_value is byte copied to this memory address using the rules of Section 8.4.
状態_アドレスオペランドはUDVMメモリアドレスを含んでいます。 状態_価値の要求された部分はセクション8.4の規則を使用することでこのメモリアドレスにコピーされたバイトです。
Program execution then resumes at the memory address specified by state_instruction, unless this address is 0 in which case program execution resumes at the next instruction following the STATE-ACCESS instruction. Note that the latter case only occurs if both the state_instruction operand and the state_instruction value from the requested state are set to 0.
次に、プログラム実行は状態_指示で指定されたメモリアドレスで再開します、このアドレスがケースプログラム実行が州-ACCESS指示に従う次の指示のときに再開する0でないなら。 州の_指示オペランドと要求された状態からの州の_指示価値の両方が0に設定される場合にだけ後者のケースが現れることに注意してください。
9.4.6. STATE-CREATE
9.4.6. 状態で作成します。
The STATE-CREATE instruction requests the creation of a state item at the receiving endpoint.
州-CREATE指示は受信終点で州の項目の創造を要求します。
STATE-CREATE (%state_length, %state_address, %state_instruction, %minimum_access_length, %state_retention_priority)
状態で作成します。(%は_長さを述べて、%は_アドレスを述べて、%は_指示を述べて、%の最小の_は_長さにアクセスして、%は_保有_優先権を述べます)
Note that the new state item cannot be created until a valid compartment identifier has been returned by the application. Consequently, when a STATE-CREATE instruction is encountered the UDVM simply buffers the five supplied operands until the END-MESSAGE instruction is reached. The steps taken at this point are described in Section 9.4.9.
アプリケーションで有効なコンパートメント識別子を返すまで新しい州の項目を作成できないことに注意してください。 州-CREATE指示が遭遇するとき、その結果、END-MESSAGE指示に達するまで、UDVMは単に5つの供給されたオペランドをバッファリングします。 ここの取られた方法はセクション9.4.9で説明されます。
Price, et. al. Standards Track [Page 49] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[49ページ]RFC3320
Decompression failure MUST occur if more than four state creation requests are made before the END-MESSAGE instruction is encountered. Decompression failure also occurs if the minimum_access_length does not lie between 6 and 20 inclusive, or if the state_retention_priority is 65535.
END-MESSAGE指示に遭遇する前に4つ以上の州の創造要求をするなら、減圧失敗は起こらなければなりません。 また、減圧失敗は最小の_のアクセス_長さが包括的に6と20の間ないか、または状態_保有_優先権が65535であるなら起こります。
9.4.7. STATE-FREE
9.4.7. 州なしです。
The STATE-FREE instruction informs the receiving endpoint that the sender no longer wishes to use a particular state item.
無州の指示は、送付者がもう特定の州の項目を使用したがっていないことを受信終点に知らせます。
STATE-FREE (%partial_identifier_start, %partial_identifier_length)
州なしです。(%部分的な_識別子_は始動して、%は部分的な_の識別子_長さです)
Note that the STATE-FREE instruction does not automatically delete a state item, but instead reclaims the memory taken by the state item within a certain compartment, which is generally not known before the END-MESSAGE instruction is reached. So just as for the STATE-CREATE instruction, when a STATE-FREE instruction is encountered the UDVM simply buffers the two supplied operands until the END-MESSAGE instruction is reached. The steps taken at this point are described in Section 9.4.9.
無州の指示が自動的に州の項目を削除しませんが、代わりにEND-MESSAGE指示に達する前に一般に、知られていないあるコンパートメントの中で州の項目によって取られたメモリを取り戻すことに注意してください。 それで、まさしく州-CREATE指示に関して、無州の指示が遭遇するとき、END-MESSAGE指示に達するまで、UDVMは単に2つの供給されたオペランドをバッファリングします。 ここの取られた方法はセクション9.4.9で説明されます。
Decompression failure MUST occur if more than four state free requests are made before the END-MESSAGE instruction is encountered. Decompression failure also occurs if partial_identifier_length does not lie between 6 and 20 inclusive.
4以上が、END-MESSAGE指示に遭遇する前に無料の要求をすると述べるなら、減圧失敗は起こらなければなりません。 また、部分的な_の識別子_長さが包括的に6と20の間ないなら、減圧失敗は起こります。
9.4.8. OUTPUT
9.4.8. 出力
The OUTPUT instruction provides successfully decompressed data to the dispatcher.
OUTPUT指示は首尾よく減圧されたデータを発送者に提供します。
OUTPUT (%output_start, %output_length)
出力(%出力_は始動して、%は_長さを出力しました)
The operands define the starting memory address and length of the byte string to be provided to the dispatcher. Note that the OUTPUT instruction can be used to output a partially decompressed message; each time the instruction is encountered it provides a new byte string that the dispatcher appends to the end of any bytes previously passed to the dispatcher via the OUTPUT instruction.
オペランドは、発送者に提供するためにバイトストリングの始めのメモリアドレスと長さを定義します。 部分的に減圧されたメッセージを出力するのにOUTPUT指示を使用できることに注意してください。 指示が遭遇するたびにそれは発送者が以前にOUTPUT指示で発送者に渡されたどんなバイトの終わりまでも追加する新しいバイトストリングを提供します。
The string of data is byte copied from the UDVM memory obeying the rules of Section 8.4.
一連のデータはセクション8.4の規則に従うUDVMメモリからコピーされたバイトです。
Decompression failure occurs if the cumulative number of bytes provided to the dispatcher exceeds 65536 bytes.
発送者に提供された累積しているバイト数が65536バイトを超えているなら、減圧失敗は起こります。
Price, et. al. Standards Track [Page 50] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[50ページ]RFC3320
Since there is technically a difference between outputting a 0-byte decompressed message, and not outputting a decompressed message at all, the OUTPUT instruction needs to distinguish between the two cases. Thus, if the UDVM terminates before encountering an OUTPUT instruction it is considered not to have outputted a decompressed message. If it encounters one or more OUTPUT instructions, each of which provides 0 bytes of data to the dispatcher, then it is considered to have outputted a 0-byte decompressed message.
0バイトの減圧されたメッセージを出力して、全く減圧されたメッセージは出力しないとき、違いが技術的にあるので、OUTPUT指示は、2つのケースを見分ける必要があります。 したがって、OUTPUT指示に遭遇する前にUDVMが終わるなら、減圧されたメッセージをoutputtedしていないのは考えられます。 1つ以上のOUTPUT指示(それのそれぞれが0バイトのデータを発送者に提供する)に遭遇するなら、0バイトの減圧されたメッセージをoutputtedしたのは考えられます。
9.4.9. END-MESSAGE
9.4.9. 終わりメッセージ
The END-MESSAGE instruction successfully terminates the UDVM and forwards the state creation and state free requests to the state handler together with any supplied feedback data.
END-MESSAGE指示は、どんな供給されたフィードバックデータと共にも創造を状態に転送して、首尾よくUDVMを終えて、州の操作者への無料の要求を状態に転送します。
END-MESSAGE (%requested_feedback_location, %returned_parameters_location, %state_length, %state_address, %state_instruction, %minimum_access_length, %state_retention_priority)
終わりメッセージ(%は_フィードバック_位置を要求して、%は_パラメタ_位置を返して、%は_長さを述べて、%は_アドレスを述べて、%は_指示を述べて、%の最小の_は_長さにアクセスして、%は_保有_優先権を述べます)
When the END-MESSAGE instruction is encountered, the decompressor dispatcher indicates to the application that a complete message has been decompressed. The application may return a compartment identifier, which the UDVM forwards to the state handler together with the state creation and state free requests and any supplied feedback data.
END-MESSAGE指示が遭遇するとき、減圧装置発送者は、完全なメッセージが減圧されたのをアプリケーションに示します。 アプリケーションは、コンパートメント識別子を返して、無料の要求とどんな供給されたフィードバックデータも述べるかもしれません。(UDVMは州の創造と共に州の操作者に識別子を転送します)。
The actual decompressed message is outputted separately using the OUTPUT instruction; this conserves memory at the UDVM because there is no need to buffer an entire decompressed message before it can be passed to the dispatcher.
実際の減圧されたメッセージは別々にOUTPUT指示を使用することでoutputtedされます。 それを発送者に渡すことができる前に全体の減圧されたメッセージをバッファリングする必要は全くないので、これはUDVMにメモリを保存します。
The END-MESSAGE instruction may pass up to four state creation requests and up to four state free requests to the state handler. The requests are passed to the state handler in the same order as they are made; in particular it is possible for the state creation requests and the state free requests to be interleaved.
END-MESSAGE指示は、最大4状態に創造要求を向かわせて、州の操作者への無料の要求を最大4状態に向かわせるかもしれません。 それらが作られているとき、要求は同次で州の操作者に渡されます。 状態に、創造要求と州がはさみ込まれるという要求を解放するのは、特に、可能です。
The state creation requests are made by the STATE-CREATE instruction. Note however that the END-MESSAGE can make one state creation request itself using the supplied operands. If the specified minimum_access_length does not lie between 6 and 20 inclusive, or if the state_retention_priority is 65535 then the END-MESSAGE instruction fails to make a state creation request of its own (however decompression failure does not occur and the state creation requests made by the STATE-CREATE instruction are still valid).
州-CREATE指示で州の創造要求をします。 しかしながら、END-MESSAGEが1つの州の創造に供給されたオペランドを使用することでそれ自体を要求させることができることに注意してください。 指定された最小の_のアクセス_長さが包括的に6と20の間ないか、または状態_保有_優先権が65535であるなら、END-MESSAGE指示はそれ自身の州の創造要求をしません(しかしながら、減圧失敗が起こりません、そして、州-CREATE指示でされた州の創造要求はまだ有効です)。
Price, et. al. Standards Track [Page 51] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[51ページ]RFC3320
Note that there is a maximum limit of four state creation requests per instance of the UDVM. Therefore, decompression failure occurs if the END-MESSAGE instruction makes a state creation request and four instances of the STATE-CREATE instruction have already been encountered.
UDVMの例あたり4つの州の創造要求の最大の限界があることに注意してください。 したがって、END-MESSAGE指示が州の創造要求をするなら、減圧失敗は起こります、そして、州-CREATE指示の4つの例が既に遭遇しました。
When creating a state item it is necessary to give the state_length, state address, state_instruction and minimum_access_length; these are supplied as operands in the STATE-CREATE instruction (or the END- MESSAGE instruction). A complete item of state also requires a state_value and a state_identifier, which are derived as follows:
州の項目を作成するとき、州の_の長さ、州のアドレス、州の_指示、および最小の_のアクセス_長さを与えるのが必要です。 州-CREATE指示(または、END- MESSAGE指示)におけるオペランドとしてこれらを供給します。 また、状態の完全な項目は州の_価値と州の_識別子を必要とします:(識別子は以下の通り引き出されます)。
The UDVM byte copies a string of state_length bytes from the UDVM memory beginning at state_address (obeying the rules of Section 8.4). This is the state_value.
UDVMバイトは状態_アドレス(セクション8.4について規則を守る)で始まるUDVMメモリからの一連の状態_長さのバイトをコピーします。 これは状態_値です。
The UDVM then calculates a 20-byte SHA-1 hash [RFC-3174] over the byte string formed by concatenating the state_length, state_address, state_instruction, minimum_access_length and state_value (in the order given). This is the state_identifier.
そして、UDVMは州の_の長さ、州の_アドレス、州の_指示、最小の_のアクセス_長さ、および州の_価値(オーダーでは、与える)を連結することによって形成されたバイトストリングに関して20バイトのSHA-1細切れ肉料理[RFC-3174]について計算します。 これは状態_識別子です。
The state_retention_priority is not part of the state item itself, but instead determines the order in which state will be deleted when the compartment exceeds its allocated state memory. The state_retention_priority is supplied as an operand in the STATE- CREATE or END-MESSAGE instruction and is passed to the state handler as part of each state creation request.
状態_保有_優先権は、州の項目自体の一部ではありませんが、コンパートメントが割り当てられた州のメモリを超えていると、代わりに、状態が削除される順番を決定します。 状態_保有_優先権は、州CREATEかEND-MESSAGE指示におけるオペランドとして提供されて、それぞれの州の創造要求の一部として州の操作者に渡されます。
The state free requests are made by the STATE-FREE instruction. Each STATE-FREE instruction supplies the values partial_identifier_start and partial_identifier_length; upon reaching the END-MESSAGE instruction these values are used to byte copy a partial state identifier from the UDVM memory. If no state item matching the partial state identifier can be found or if more than one state item in the compartment matches the partial state identifier, then the state free request is ignored (this does not cause decompression failure to occur). Otherwise, the state handler frees the matched state item as specified in Section 6.2.
無料の要求が無州の指示でされる状態。 それぞれの無州の指示は部分的な_識別子_始めと部分的な_識別子_の長さを値に供給します。 END-MESSAGE指示に達すると、使用されるこれらの値はUDVMメモリからの部分的な州の識別子をバイトまでコピーします。 部分的な州の識別子に合っている州の項目に全く当たることができないか、またはコンパートメントの複数の州の項目が部分的な州の識別子に合っているなら、州の無料の要求は無視されます(これは起こらない減圧のことを引き起こしません)。 さもなければ、州の操作者はセクション6.2の指定されるとしての取り組んでいる州の項目を解放します。
As well as forwarding the state creation and state free requests, the END-MESSAGE instruction may also pass feedback data to the state handler. Feedback data is used to inform the receiving endpoint about the capabilities of the sending endpoint, which can help to improve the overall compression ratio and to reduce the working memory requirements of the endpoints.
また、創造を状態に転送して、無料の要求を状態に転送することと同様に、END-MESSAGE指示はフィードバックデータを州の操作者に渡すかもしれません。 フィードバックデータは、総合的な圧縮比を改良して、終点のワーキングメモリ要件を減らすのを助けることができる送付終点の能力に関して受信終点を知らせるのに使用されます。
Price, et. al. Standards Track [Page 52] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[52ページ]RFC3320
Two types of feedback data are available: requested feedback and returned feedback. The format of the requested feedback data is given in Figure 12. As outlined in Section 3.2, the requested feedback data can be used to influence the contents of the returned feedback data in the reverse direction.
2つのタイプのフィードバックデータは利用可能です: フィードバックを要求して、フィードバックを返しました。 図12で要求されたフィードバックデータの書式を与えます。 セクション3.2に概説されているように、反対の方向の返されたフィードバックデータのコンテンツに影響を及ぼすのに要求されたフィードバックデータを使用できます。
The returned feedback data is itself subdivided into a returned feedback item and a list of returned SigComp parameters. The returned feedback item is of sufficient importance to warrant its own field in the SigComp header as described in Section 7.1. The returned SigComp parameters are illustrated in Figure 13.
返されたフィードバックデータは返されたフィードバック項目と返されたSigCompパラメタのリストに細分されます。 返されたフィードバック項目は、それ自身の分野を保証するためにセクション7.1で説明されるようにSigCompヘッダーで十分重要です。 返されたSigCompパラメタは図13で例証されます。
Note that the formats of Figure 12 and Figure 13 are only for local presentation of the feedback data on the interface between the UDVM and state handler. The formats do not mandate any bits on the wire; the compressor can transmit the data in any form provided that it is loaded into the UDVM memory at the correct addresses.
図12と図13の形式がUDVMと州の操作者とのインタフェースにおけるフィードバックデータの地方のプレゼンテーションのためだけのものであることに注意してください。 形式はワイヤのどんなビットも強制しません。 それが正しいアドレスのUDVMメモリにロードされれば、コンプレッサーはどんなフォームでもデータを送ることができます。
Moreover, the responsibility for ensuring that feedback data arrives successfully over an unreliable transport lies with the sender. The receiving endpoint always uses the last received value for each field in the feedback data, even if the values are out of date due to packet loss or misordering.
そのうえ、送付者にはフィードバックデータが頼り無い輸送の上で首尾よく到着するのを確実にすることへの責任があります。 受信終点はフィードバックデータの各分野にいつも最後の容認された値を使用します、値がパケット損失かmisorderingのために時代遅れであっても。
If the requested_feedback_location operand is set to 0, then no feedback request is made; otherwise, it points to the starting memory address of the requested feedback data as shown in Figure 12.
要求された_フィードバック_位置のオペランドを0に設定するなら、フィードバック要求を全くしません。 さもなければ、それは図12に示されるように要求されたフィードバックデータの始めのメモリアドレスを示します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| reserved | Q | S | I | requested_feedback_location
+---+---+---+---+---+---+---+---+
| |
: requested feedback item : if Q = 1
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 予約されます。| Q| S| I| 要求された_フィードバック_位置+---+---+---+---+---+---+---+---+ | | : 要求されたフィードバック項目: Qが1と等しいなら| | +---+---+---+---+---+---+---+---+
Figure 12: Format of requested feedback data
図12: 要求されたフィードバックデータの形式
The reserved bits may be used in future versions of SigComp, and are set to 0 in Version 0x01. Non-zero values should be ignored by the receiving endpoint.
予約されたビットは、SigCompの将来のバージョンで使用されるかもしれなくて、バージョン0x01で0に設定されます。 非ゼロ値は受信終点によって無視されるべきです。
The Q-bit indicates whether a requested feedback item is present or not. The compressor can set the requested feedback item to an arbitrary value, which will then be transmitted unmodified in the reverse direction as a returned feedback item. See Chapter 5 for further details of how the requested feedback item is returned.
Q-ビットは、要求されたフィードバック項目が存在しているかどうかを示します。 コンプレッサーは要求されたフィードバック項目を任意の値に設定できます。(次に、それは、返されたフィードバック項目として反対の方向に変更されていなく送られるでしょう)。 どう要求されたフィードバック商品を返すかに関する詳細に関して第5章を参照してください。
Price, et. al. Standards Track [Page 53] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[53ページ]RFC3320
The format of the requested feedback item is identical to the format of the returned feedback item illustrated in Figure 4.
要求されたフィードバック項目の形式は図4で例証された返されたフィードバック項目の形式と同じです。
The compressor sets the S-bit to 1 if it does not wish (or no longer wishes) to save state information at the receiving endpoint and also does not wish to access state information that it has previously saved. Consequently, if the S-bit is set to 1 then the receiving endpoint can reclaim the state memory allocated to the remote compressor and set the state_memory_size for the compartment to 0.
それが受信終点に州の情報を保存することを願わないで(または、もう、願っていません)、また、以前に節約したという州の情報にアクセスしたくないなら、コンプレッサーはS-ビットを1に設定します。 その結果、S-ビットが1に設定されるなら、受信終点は、リモートコンプレッサーに割り当てられた州のメモリを取り戻して、状態_メモリ_サイズを0へのコンパートメントに設定できます。
The compressor may change its mind and switch the S-bit back to 0 in a later message. However, the receiving endpoint is under no obligation to use the original state_memory_size for the compartment; it may choose to allocate less memory to the compartment or possibly none at all.
コンプレッサーは、気が変わって、後のメッセージの0にS-ビットに元に戻らせるかもしれません。 しかしながら、受信終点がコンパートメントに原状_メモリ_サイズを使用するどんな義務の下にもありません。 それは、コンパートメントかことによると全くなにもにより少ないメモリを割り当てないのを選ぶかもしれません。
Similarly the compressor sets the I-bit to 1 if it does not wish (or no longer wishes) to access any of the locally available state items offered by the receiving endpoint. This can help to conserve bandwidth because the list of locally available state items no longer needs to be returned in the reverse direction. It may also conserve memory at the receiving endpoint, as the state handler can delete any locally available state items that it determines are no longer required by any remote endpoint. Note that the compressor can set the I-bit back to 0 in a later message, but it cannot access any locally available state items that were previously offered by the receiving endpoint unless they are subsequently re-announced.
同様に、それが受信終点によって提供された局所的に利用可能な州の商品のどれかにアクセスしたくないなら(または、もう、願っていません)、コンプレッサーはI-ビットを1に設定します。 これは、もう局所的に利用可能な州の項目のリストによって反対の方向に返される必要はないので帯域幅を保存するのを助けることができます。 また、それは受信終点にメモリを保存するかもしれません、州の操作者がもう必要でないそれがどんな遠く離れた終点も決定するどんな局所的に利用可能な州の項目も削除できるとき。 コンプレッサーがI-ビットを後のメッセージの0に遅らせることができますが、それらが次に再発表されない場合以前に受信終点によって提供されたどんな局所的に利用可能な州の商品にもアクセスできないことに注意してください。
If the returned_parameters_location operand is set to 0, then no SigComp parameters are returned; otherwise, it points to the starting memory address of the returned parameters as shown in Figure 13.
返された_パラメタ_位置のオペランドが0に設定されるなら、SigCompパラメタは全く返されません。 さもなければ、それは図13に示されるように返されたパラメタの始めのメモリアドレスを示します。
Price, et. al. Standards Track [Page 54] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[54ページ]RFC3320
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| cpb | dms | sms | returned_parameters_location
+---+---+---+---+---+---+---+---+
| SigComp_version |
+---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_1 |
+---+---+---+---+---+---+---+---+
| |
: partial_state_identifier_1 :
| |
+---+---+---+---+---+---+---+---+
: :
+---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_n |
+---+---+---+---+---+---+---+---+
| |
: partial_state_identifier_n :
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | cpb| dms| sms| 返された_パラメタ_位置+---+---+---+---+---+---+---+---+ | SigComp_バージョン| +---+---+---+---+---+---+---+---+ | _部分的な_州の_ID_1の長さの_| +---+---+---+---+---+---+---+---+ | | : 部分的な_州の_識別子_1: | | +---+---+---+---+---+---+---+---+ : : +---+---+---+---+---+---+---+---+ | _部分的な_状態_IDの長さの_| +---+---+---+---+---+---+---+---+ | | : 部分的な_状態_識別子: | | +---+---+---+---+---+---+---+---+
Figure 13: Format of returned SigComp parameters
図13: 返されたSigCompパラメタの形式
The first byte encodes the SigComp parameters cycles_per_bit, decompression_memory_size and state_memory_size as per Section 3.3.1. The byte can be set to 0 if the three parameters are not included in the feedback data. (This may be useful to save bits in the compressed message if the remote endpoint is already satisfied all necessary information has reached the endpoint receiving the message.)
最初のバイトが_ビットあたりの_にSigCompパラメタサイクルをコード化して、減圧は、セクション3.3.1に従って_メモリ_サイズと州の_メモリ_サイズです。 3つのパラメタがフィードバックデータに含まれていないなら、0にバイトを設定できます。 (情報がメッセージを受け取りながら終点に達したのがすべて必要な状態で遠く離れた終点が既に満たされているなら、これは圧縮されたメッセージでビットを節約するために役に立つかもしれません。)
The second byte encodes the SigComp_version as per Section 3.3.2. Similar to the first byte, the second byte can be set to 0 if the parameter is not included in the feedback data.
2番目のバイトはセクション3.3.2に従ってSigComp_バージョンをコード化します。 最初のバイトと同様です、パラメタがフィードバックデータに含まれていないなら、2番目のバイトを0に設定できます。
The remaining bytes encode a list of partial state identifiers for the locally available state items offered by the sending endpoint. Each state item is encoded as a 1-byte length field, followed by a partial state identifier containing as many bytes as indicated in the length field. The sender can choose to send as few as 6 bytes if it believes that this is sufficient for the receiver to determine which state item is being offered.
残っているバイトは送付終点によって提供された局所的に利用可能な州の商品のための部分的な州の識別子のリストをコード化します。 それぞれの州の項目は長さの分野にみられるように同じくらい多くのバイトを含む部分的な州の識別子があとに続いた1バイトの長さの分野としてコード化されます。 受信機が、どの州の商品が提供されているかをこれが決定できるくらい信じているなら、送付者は、最小6バイト発信するのを選ぶことができます。
The list of state identifiers is terminated by a byte in the position where the next length field would be expected that is set to a value below 6 or above 20. Note that upgraded SigComp versions may append additional items of data after the final length field.
州の識別子のリストは次の長さの分野が予想される位置の6より下であるか20より上で値に設定される1バイト終えられます。 アップグレードしたSigCompバージョンが最終的な長さの分野の後にデータの追加商品を追加するかもしれないことに注意してください。
Price, et. al. Standards Track [Page 55] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[55ページ]RFC3320
10. Security Considerations
10. セキュリティ問題
10.1. Security Goals
10.1. セキュリティ目標
The overall security goal of the SigComp architecture is to not create risks that are in addition to those already present in the application protocols. There is no intention for SigComp to enhance the security of the application, as it always can be circumvented by not using compression. More specifically, the high-level security goals can be described as:
SigCompアーキテクチャの総合的なセキュリティ目標はアプリケーション・プロトコルで既に出席しているそれらに加えている危険を作成しないことです。 SigCompがアプリケーションのセキュリティを高めるという意志が全くありません、圧縮を使用しないことによってそれをいつも回避できるとき。 より明確に、ハイレベルのセキュリティ目標を以下と説明できます。
1. Do not worsen security of existing application protocol
1. 既存のアプリケーション・プロトコルのセキュリティを悪化させないでください。
2. Do not create any new security issues
2. 少しの新しい安全保障問題も作成しないでください。
3. Do not hinder deployment of application security.
3. アプリケーションセキュリティの展開を妨げないでください。
10.2. Security Risks and Mitigation
10.2. セキュリティリスクと緩和
This section identifies the potential security risks associated with SigComp, and explains how each risk is minimized by the scheme.
このセクションは、SigCompに関連している潜在的セキュリティ危険を特定して、各危険が体系によってどう最小にされるかを説明します。
10.2.1. Confidentiality Risks
10.2.1. 秘密性リスク
- Attacking SigComp by snooping into state of other users:
- 他のユーザの状態に以下について詮索することによって、SigCompを攻撃すること。
State is accessed by supplying a state identifier, which is a cryptographic hash of the state being referenced. This implies that the referencing message already needs knowledge about the state. To enforce this, a state item cannot be accessed without supplying a minimum of 48 bits from the hash. This also minimizes the probability of an accidental state collision. A compressor can, using the minimum_access_length operand of the STATE-CREATE and END- MESSAGE instructions, increase the number of bits that need to be supplied to access the state, increasing the protection against attacks.
州の識別子を提供することによって、状態はアクセスされます。(参照をつけられて、識別子は状態の暗号のハッシュです)。 これは、参照箇所メッセージが既に状態に関する知識を必要とするのを含意します。 これを実施するために、ハッシュから最低48ビットを供給しないで、州の項目にアクセスできません。 また、これは偶然の州の衝突の確率を最小にします。 州-CREATEとEND- MESSAGE指示の最小の_アクセス_長さのオペランドを使用して、コンプレッサーは状態にアクセスするために供給される必要があるビットの数を増強できます、攻撃に対する保護を増強して。
Generally, ways to obtain knowledge about the state identifier (e.g., passive attacks) will also easily provide knowledge about the referenced state, so no new vulnerability results.
また、一般に、州の識別子(例えば、受け身の攻撃)に関して知識を得る方法が容易に参照をつけられた状態に関する知識を提供するので、どんな新しい脆弱性も結果として生じません。
An endpoint needs to handle state identifiers with the same care it would handle the state itself.
それがそうする同じ注意で州の識別子を扱う終点の必要性は状態自体を扱います。
Price, et. al. Standards Track [Page 56] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[56ページ]RFC3320
10.2.2. Integrity Risks
10.2.2. 保全リスク
The SigComp approach assumes that there is appropriate integrity protection below and/or above the SigComp layer. The state creation mechanism provides some additional potential to compromise the integrity of the messages; however, this would most likely be detectable at the application layer.
SigCompアプローチは、適切な保全保護が層SigComp層を超えていると仮定します。 州の作成メカニズムはメッセージの保全に感染する何らかの追加可能性を提供します。 しかしながら、これはたぶん応用層で検出可能でしょう。
- Attacking SigComp by faking state or making unauthorized changes to
state:
- 見せかけるのによるSigCompが述べる攻撃か未承認の変更を作ります述べる:
State cannot be destroyed by a malicious sender unless it can send messages that the application identifies as belonging to the same compartment the state was created under; this adds additional security risks only when the application allows the installation of SigComp state from a message where it would not have installed state itself.
アプリケーションが状態が創設された同じコンパートメントに属すとして特定するメッセージを送ることができないなら、悪意がある送付者は状態を破壊できません。 アプリケーションがそれが状態自体をインストールしていないメッセージからSigComp状態のインストールを許容するときだけ、これは追加担保危険を加えます。
Faking or changing state is only possible if the hash allows intentional collision.
ハッシュが意図的な衝突を許す場合にだけ、状態を見せかけるか、または変えるのが可能です。
10.2.3. Availability Risks (Avoiding DoS Vulnerabilities)
10.2.3. 有用性リスク(DoS脆弱性を避けます)
- Use of SigComp as a tool in a DoS attack to another target:
- 別の目標に対するDoS攻撃におけるツールとしてのSigCompの使用:
SigComp cannot easily be used as an amplifier in a reflection attack, as it only generates one decompressed message per incoming compressed message. This message is then handed to the application; the utility as a reflection amplifier is therefore limited by the utility of the application for this purpose.
アンプとして反射攻撃に容易にSigCompを使用できません、入って来る圧縮されたメッセージあたり1つの減圧されたメッセージしか生成しないとき。 次に、このメッセージはアプリケーションに手渡されます。 したがって、反射アンプとしてのユーティリティはアプリケーションに関するユーティリティによってこのために制限されます。
However, it must be noted that SigComp can be used to generate larger messages as input to the application than have to be sent from the malicious sender; this therefore can send smaller messages (at a lower bandwidth) than are delivered to the application. Depending on the reflection characteristics of the application, this can be considered a mild form of amplification. The application MUST limit the number of packets reflected to a potential target - even if SigComp is used to generate a large amount of information from a small incoming attack packet.
しかしながら、アプリケーションに入力されるように、より大きいメッセージを生成するのに悪意がある送付者から送らなければならないよりSigCompを使用できることに注意しなければなりません。 したがって、これはアプリケーションに提供されるより小さいメッセージ(下側の帯域幅の)を送ることができます。 アプリケーションの反射の特性によって、軽症型の増幅であるとこれを考えることができます。 SigCompが小さい入って来る攻撃パケットから多量の情報を生成するのに使用されても、アプリケーションは仮想ターゲットに反映されたパケットの数を制限しなければなりません。
Price, et. al. Standards Track [Page 57] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[57ページ]RFC3320
- Attacking SigComp as the DoS target by filling it with state:
- DoSとしてSigCompを攻撃して、状態でそれを満たすことによって、以下を狙ってください。
Excessive state can only be installed by a malicious sender (or a set of malicious senders) with the consent of the application. The system consisting of SigComp and application is thus approximately as vulnerable as the application itself, unless it allows the installation of SigComp state from a message where it would not have installed application state itself.
悪意がある送付者(または、1セットの悪意がある送付者)はアプリケーションの同意で過度の状態をインストールできるだけです。 その結果、SigCompとアプリケーションから成るシステムはアプリケーション自体とほぼ同じくらい害を被りやすいです、アプリケーション状態自体をインストールしていないメッセージからSigComp状態のインストールを許容しない場合。
If this is desirable to increase the compression ratio, the effect can be mitigated by making use of feedback at the application level that indicates whether the state requested was actually installed - this allows a system under attack to gracefully degrade by no longer installing compressor state that is not matched by application state.
これが圧縮比を増強するのにおいて望ましいなら、要求された状態が実際にインストールされたかどうかを示すアプリケーションレベルでフィードバックを利用することによって、効果を緩和できます--これはもうまでにアプリケーション状態によって合われていないコンプレッサー状態をインストールしながら優雅に退行するために攻撃でシステムを許容します。
Obviously, if a stream-based transport is used, the streams themselves constitute state that has to be handled in the same way that the application itself would handle a stream-based transport; if an application is not equipped for stream-based transport, it should not allow SigComp connections on a stream-based transport. For the alternative SigComp usage described as "continuous mode" in Section 4.2.1, an attacker could create any number of active UDVMs unless there is some DoS protection at a lower level (e.g., by using TLS in appropriate configurations).
ストリームベースの輸送が使用されているなら、明らかに、ストリーム自体はそれが同様に、扱われるために持っているアプリケーション自体が構成する状態を構成します。ストリームベースの輸送を扱ってください。 ストリームベースの輸送のためにアプリケーションを備えていないなら、それはストリームベースの輸送のときにSigComp接続を許すべきではありません。 セクション4.2.1における「連続モード」として記述された代替のSigComp用法のために、何らかのDoS保護が下のレベル(例えば、適切な構成にTLSを使用するのによる)にない場合、攻撃者はいろいろなアクティブなUDVMsを作成するかもしれません。
- Attacking the UDVM by faking state or making unauthorized changes
to state:
- 見せかけるのによるUDVMが述べる攻撃か未承認の変更を作ります述べる:
This is covered in Section 10.2.2.
これはセクション10.2.2でカバーされています。
- Attacking the UDVM by sending it looping code:
- 輪にさせることによってUDVMを攻撃して、以下をコード化してください。
The application sets an upper limit to the number of "UDVM cycles" that can be used per compressed message and per input bit in the compressed message. The damage inflicted by sending packets with looping code is therefore limited, although this may still be substantial if a large number of UDVM cycles are offered by the UDVM. However, this would be true for any decompressor that can receive packets over an unsecured transport.
アプリケーションは圧縮されたメッセージに圧縮されたメッセージと1入力ビット単位で使用できる「UDVMサイクル」の数に上限を設定します。 したがって、ループコードがあるパケットを送ることによって課された損害は制限されます、UDVM何サイクルもUDVMによって提供されるなら、これがまだ実質的であるかもしれませんが。 しかしながら、非機密保護している輸送の上にパケットを受けることができるどんな減圧装置にも、これは本当でしょう。
11. IANA Considerations
11. IANA問題
SigComp requires a 1-byte name space, the SigComp_version, which has been created by the IANA. Upgraded versions of SigComp must be backwards-compatible with Version 0x01, described in this document. Adding additional UDVM instructions and assigning values to the reserved UDVM memory addresses are two possible upgrades for which this is the case.
SigCompは1バイトの名前スペース、SigComp_バージョンを必要とします。(それは、IANAによって作成されました)。 SigCompのアップグレードしたバージョンは後方に本書では説明されたバージョン0x01と互換性があるに違いありません。 追加UDVM指示を加えて、予約されたUDVMメモリアドレスに値を割り当てるのは、これがそうである2つの可能なアップグレードです。
Price, et. al. Standards Track [Page 58] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[58ページ]RFC3320
Following the policies outlined in [RFC-2434], the IANA policy for assigning a new value for the SigComp_version shall require a Standards Action. Values are thus assigned only for Standards Track RFCs approved by the IESG.
[RFC-2434]に概説された方針に従って、SigComp_バージョンのために新しい値を割り当てるためのIANA方針はStandards Actionを必要とするものとします。 値はIESGによって承認されたStandards Track RFCsのためだけにこのようにして割り当てられます。
12. Acknowledgements
12. 承認
Thanks to
おかげ
Abigail Surtees
Mark A West
Lawrence Conroy
Christian Schmidt
Max Riegel
Lars-Erik Jonsson
Stefan Forsgren
Krister Svanbro
Miguel Garcia
Christopher Clanton
Khiem Le
Ka Cheong Leung
Robert Sugar
アビゲール・サーティーズは、西ローレンスのマックスリーゲルラース-エリックイェンソンステファンコンロイクリスチャンシュミットForsgren Krister SvanbroがミゲルガルシアクリストファーClanton Khiem Le ka Cheongレオンロバート砂糖であるとマークします。
for valuable input and review.
貴重な入力とレビューのために。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[RFC-1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC
1662, July 1994.
[RFC-1662] シンプソン、W.、「HDLCのような縁どりにおけるppp」、STD51、RFC1662、1994年7月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC-3174] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm
1 (SHA1)", RFC 3174, September 2001.
[RFC-3174]イーストレークと3番目とD.とP.ジョーンズ、「米国安全なハッシュアルゴリズム1(SHA1)」、RFC3174 2001年9月。
13.2. Informative References
13.2. 有益な参照
[RFC-1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951, May 1996.
ドイツ語、[RFC-1951]P.、「DEFLATE Compressed Data Format Specification、バージョン1.3インチ、RFC1951、1996インチ年5月。
[RFC-2026] Bradner, S., "The Internet Standards Process - Revision
3", BCP 9, RFC 2026, October 1996.
[RFC-2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC-2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC-2279]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
Price, et. al. Standards Track [Page 59] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[59ページ]RFC3320
[RFC-2326] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC-2326] SchulzrinneとH.とラオとA.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」、RFC2326 1998年4月。
[RFC-2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC-2434]Alvestrand、H.とT.Narten、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC-2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwartzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L. and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC-2960]スチュワート、R.、シェ、Q.、Morneault、K.、鋭く、C.、Schwartzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、およびV.パクソンは「制御伝動プロトコルを流します」、RFC2960、2000年10月。
[RFC-3261] 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.
[RFC-3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC-3321] Hannu, H., Christoffersson, J., Forsgren, S., Leung,
K.-C., Liu, Z. and R. Price, "Signaling Compression
(SigComp) - Extended Operations", RFC 3321, January
2003.
[RFC-3321] ハンヌ、H.、Christoffersson、J.、Forsgren、S.、レオン、K.C.、リュウ、Z.、およびR.は「圧縮(SigComp)--操作を広げると合図すること」でのRFC3321(2003年1月)に値を付けます。
14. Authors' Addresses
14. 作者のアドレス
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
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
カルステンボルマンUniversitaetブレーメンTZI Postfach330440D-28334ブレーメン(ドイツ)
Phone: +49 421 218 7024 EMail: cabo@tzi.org
以下に電話をしてください。 +49 7024年の421 218メール: cabo@tzi.org
Price, et. al. Standards Track [Page 60] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[60ページ]RFC3320
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
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
Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039
ZhigangリュウノキアResearch Center6000接続Driveアービング、テキサス 75039
Phone: +1 972 894-5935 EMail: zhigang.c.liu@nokia.com
以下に電話をしてください。 +1 972 894-5935 メールしてください: zhigang.c.liu@nokia.com
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
ジョナサンローゼンバーグdynamicsoft72Eagle Rock AvenueのFirst Floorの東ハノーバー王家、ニュージャージー 07936
EMail: jdrosen@dynamicsoft.com
メール: jdrosen@dynamicsoft.com
Price, et. al. Standards Track [Page 61] RFC 3320 Signaling Compression (SigComp) January 2003
et価格、アル。 2003年1月に圧縮(SigComp)に合図する標準化過程[61ページ]RFC3320
15. Full Copyright Statement
15. 完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Price, et. al. Standards Track [Page 62]
et価格、アル。 標準化過程[62ページ]
一覧
スポンサーリンク
