RFC4995 日本語訳
4995 The RObust Header Compression (ROHC) Framework. L-E. Jonsson, G.Pelletier, K. Sandlund. July 2007. (Format: TXT=87198 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group L-E. Jonsson
Request for Comments: 4995 G. Pelletier
Category: Standards Track K. Sandlund
Ericsson
July 2007
ワーキンググループL-Eをネットワークでつないでください。 コメントを求めるイェンソンRequest: 4995年のG.ペレティアカテゴリ: 標準化過程K.Sandlundエリクソン2007年7月
The RObust Header Compression (ROHC) Framework
体力を要しているヘッダー圧縮(ROHC)枠組み
Status of This 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 IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.
Robust Header Compression(ROHC)プロトコルは効率的、そして、フレキシブル、そして、耐未来のヘッダー圧縮概念を提供します。 それは、様々なリンク技術の上で異なった特性で効率的に、そして強壮に作動するように設計されています。
The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095.
ROHC枠組みは初めは、1セットの圧縮プロフィールと共にRFC3095で定義されました。 明らかにROHC仕様、このドキュメントを改良して、簡素化してください。別々に解凍されて、ROHC枠組みとプロフィールを定義します。 より明確に、枠組みの定義は、RFC3095によって指定された枠組みの定義を変更もしませんし、アップデートもしません。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
2.1. Acronyms ...................................................4
2.2. ROHC Terminology ...........................................4
3. Background (Informative) ........................................7
3.1. Header Compression Fundamentals ............................7
3.2. A Short History of Header Compression ......................7
4. Overview of Robust Header Compression (ROHC) (Informative) ......8
4.1. General Principles .........................................8
4.2. Compression Efficiency, Robustness, and Transparency ......10
4.3. Developing the ROHC Protocol ..............................10
1. 序論…3 2. 用語…4 2.1. 頭文字語…4 2.2. ROHC用語…4 3. バックグラウンド(有益な)…7 3.1. ヘッダー圧縮原理…7 3.2. ヘッダー圧縮の短い歴史…7 4. 体力を要しているヘッダー圧縮(ROHC)(有益な)の概観…8 4.1. 綱領…8 4.2. 圧縮効率、丈夫さ、および透明…10 4.3. ROHCを開発して、議定書を作ってください…10
Jonsson, et al. Standards Track [Page 1] RFC 4995 The ROHC Framework July 2007
イェンソン、他 規格はROHC枠組みの2007年7月にRFC4995を追跡します[1ページ]。
4.4. Operational Characteristics of the ROHC Channel ...........11
4.5. Compression and Master Sequence Number (MSN) ..............13
4.6. Static and Dynamic Parts of a Context .....................13
5. The ROHC Framework (Normative) .................................14
5.1. The ROHC Channel ..........................................14
5.1.1. Contexts and Context Identifiers ...................14
5.1.2. Per-Channel Parameters .............................15
5.1.3. Persistence of Decompressor Contexts ...............16
5.2. ROHC Packets and Packet Types .............................16
5.2.1. General Format of ROHC Packets .....................17
5.2.1.1. Format of the Padding Octet ...............17
5.2.1.2. Format of the Add-CID Octet ...............18
5.2.1.3. General Format of Header ..................18
5.2.2. Initialization and Refresh (IR) Packet Types .......19
5.2.2.1. ROHC IR Packet Type .......................20
5.2.2.2. ROHC IR-DYN Packet Type ...................20
5.2.3. ROHC Initial Decompressor Processing ...............21
5.2.4. ROHC Feedback ......................................22
5.2.4.1. ROHC Feedback Format ......................23
5.2.5. ROHC Segmentation ..................................25
5.2.5.1. Segmentation Usage Considerations .........25
5.2.5.2. Segmentation Protocol .....................26
5.3. General Encoding Methods ..................................27
5.3.1. Header Compression CRCs, Coverage and Polynomials ..27
5.3.1.1. 8-bit CRCs in IR and IR-DYN Headers .......27
5.3.1.2. 3-bit CRC in Compressed Headers ...........27
5.3.1.3. 7-bit CRC in Compressed Headers ...........28
5.3.1.4. 32-bit Segmentation CRC ...................28
5.3.2. Self-Describing Variable-Length Values .............29
5.4. ROHC UNCOMPRESSED -- No Compression (Profile 0x0000) .....29
5.4.1. IR Packet ..........................................30
5.4.2. Normal Packet ......................................31
5.4.3. Decompressor Operation .............................31
5.4.4. Feedback ...........................................32
6. Overview of a ROHC Profile (Informative) .......................32
7. Security Considerations ........................................33
8. IANA Considerations ............................................34
9. Acknowledgments ................................................35
10. References ....................................................35
10.1. Normative References .....................................35
10.2. Informative References ...................................35
Appendix A. CRC Algorithm ........................................37
4.4. ROHCチャンネルの操作上の特性…11 4.5. 圧縮とマスター配列番号(MSN)…13 4.6. 文脈の静的でダイナミックな部分…13 5. ROHC枠組み(標準の)…14 5.1. ROHCは精神を集中します…14 5.1.1. 文脈と文脈識別子…14 5.1.2. 1チャンネルあたりのパラメタ…15 5.1.3. 減圧装置文脈の固執…16 5.2. ROHCパケットとパケットタイプ…16 5.2.1. ROHCパケットの一般形式…17 5.2.1.1. 詰め物八重奏の形式…17 5.2.1.2. Cidを加えている八重奏の形式…18 5.2.1.3. ヘッダーの一般形式…18 5.2.2. 初期設定、パケットがタイプする(IR)をリフレッシュしてください… …19 5.2.2.1. ROHC IRパケットタイプ…20 5.2.2.2. ROHC IRダインパケットタイプ…20 5.2.3. ROHCは減圧装置処理に頭文字をつけます…21 5.2.4. ROHCフィードバック…22 5.2.4.1. ROHCフィードバック形式…23 5.2.5. ROHC分割…25 5.2.5.1. 分割用法問題…25 5.2.5.2. 分割プロトコル…26 5.3. 一般コード化方法…27 5.3.1. ヘッダー圧縮CRCs、適用範囲、および多項式。27 5.3.1.1. IRにおける8ビットのCRCsとIRダインヘッダー…27 5.3.1.2. 圧縮されたヘッダーの3ビットのCRC…27 5.3.1.3. 圧縮されたヘッダーの7ビットのCRC…28 5.3.1.4. 32ビットの分割CRC…28 5.3.2. 自己について説明する可変長の値…29 5.4. ROHCは解凍しました--圧縮がありません(プロフィール0x0000)。29 5.4.1. IRパケット…30 5.4.2. 正常なパケット…31 5.4.3. 減圧装置操作…31 5.4.4. フィードバック…32 6. ROHCプロフィール(有益な)の概観…32 7. セキュリティ問題…33 8. IANA問題…34 9. 承認…35 10. 参照…35 10.1. 標準の参照…35 10.2. 有益な参照…35付録A.CRCアルゴリズム…37
Jonsson, et al. Standards Track [Page 2] RFC 4995 The ROHC Framework July 2007
イェンソン、他 規格はROHC枠組みの2007年7月にRFC4995を追跡します[2ページ]。
1. Introduction
1. 序論
For many types of networks, reducing the deployment and operational costs by improving the usage of the bandwidth resources is of vital importance. Header compression over a link is possible because some of the information carried within the header of a packet becomes compressible between packets belonging to the same flow.
多くのタイプのネットワークにおいて、帯域幅リソースの用法を改良することによって展開と運用コストを抑えるのは、不可欠な重要性のものです。 パケットのヘッダーの中に運ばれた何らかの情報が同じ流れに属すパケットの間で圧縮性になるので、リンクの上のヘッダー圧縮は可能です。
For links where the overhead of the IP header(s) is problematic, the total size of the header may be significant. Applications carrying data carried within RTP [13] will then, in addition to link-layer framing, have an IPv4 [10] header (20 octets), a UDP [12] header (8 octets), and an RTP header (12 octets), for a total of 40 octets. With IPv6 [11], the IPv6 header is 40 octets for a total of 60 octets. Applications transferring data using TCP [14] will have 20 octets for the transport header, for a total size of 40 octets for IPv4 and 60 octets for IPv6.
IPヘッダーのオーバーヘッドが問題が多いリンクに関しては、ヘッダーの総サイズは重要であるかもしれません。 RTP[13]の中で運ばれたデータを載せるアプリケーションには、リンクレイヤ縁どりに加えて、IPv4[10]ヘッダー(20の八重奏)、UDP[12]ヘッダー(8つの八重奏)、およびRTPヘッダー(12の八重奏)が次に、あるでしょう、合計40の八重奏のために。 IPv6[11]と共に、IPv6ヘッダーは合計60の八重奏のための40の八重奏です。 TCP[14]を使用することでデータを移すアプリケーションが輸送ヘッダー、IPv4のための40の八重奏とIPv6のための60の八重奏の総サイズのための20の八重奏を持つでしょう。
The relative gain for specific flows (or applications) depends on the size of the payload used in each packet. For applications such as Voice-over-IP, where the size of the payload containing coded speech can be as small as 15-20 octets, this gain will be quite significant. Similarly, relative gains for TCP flows carrying large payloads (such as file transfers) will be less than for flows carrying smaller payloads (such as application signaling, e.g., session initiation).
特定の流れ(または、アプリケーション)のための相対的な利得は各パケットで使用されるペイロードのサイズに依存します。 この利得はVoice-over-IPなどのアプリケーションに、かなり重要になるでしょう。そこでは、コード化されたスピーチを含むペイロードのサイズが15-20 八重奏と同じくらい小さいことができます。 同様に、TCPが大きいペイロード(ファイル転送などの)を運びながら流れるので、相対的な利得は、よりわずかなペイロード(アプリケーションシグナリング、例えば、セッション開始などの)を運ぶ流れより少なくなるでしょう。
As more and more wireless link technologies are being deployed to carry IP traffic, care must be taken to address the specific characteristics of these technologies within the header compression algorithms. Legacy header compression schemes, such as those defined in [16] and [17], have been shown to perform inadequately over links where both the lossy behavior and the round-trip times are non- negligible, such as those observed for example in wireless links and IP tunnels.
ますます無線のリンク技術が配備することにされるのであるので、IP交通を運ぶためにヘッダー圧縮アルゴリズムの中にこれらの技術の特定の特性を記述するために注意しなければなりません。[16]と[17]で定義されたものなどの遺産ヘッダー圧縮技術は損失性の振舞いと往復の回の両方が非取るにたらないリンクの上に不十分に働くために示されました、例えば、無線のリンクで観測されたものやIPトンネルのように。
In addition, a header compression scheme should handle the often non-trivial residual errors, i.e., where the lower layer may pass a packet that contains undetected bit errors to the decompressor. It should also handle loss and reordering before the compression point, as well as on the link between the compression and decompression points [7].
さらに、すなわち、ヘッダー圧縮技術は下層が非検出されたビットを含むパケットに誤りを通過するかもしれないところでしばしば重要な見逃し誤りを減圧装置に扱うべきです。 また、それは圧縮と減圧ポイント[7]の間で圧密点の前とリンクの上の損失と再命令を扱うべきです。
The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.
Robust Header Compression(ROHC)プロトコルは効率的、そして、フレキシブル、そして、耐未来のヘッダー圧縮概念を提供します。 それは、様々なリンク技術の上で異なった特性で効率的に、そして強壮に作動するように設計されています。
Jonsson, et al. Standards Track [Page 3] RFC 4995 The ROHC Framework July 2007
イェンソン、他 規格はROHC枠組みの2007年7月にRFC4995を追跡します[3ページ]。
RFC 3095 [3] defines the ROHC framework along with an initial set of compression profiles. To improve and simplify the specification, the framework and the profiles' parts have been split into separate documents. This document explicitly defines the ROHC framework, but it does not modify or update the definition of the framework specified by RFC 3095; both documents can be used independently of each other. This also implies that implementations based on either definition will be compatible and interoperable with each other. However, it is the intent to let this specification replace RFC 3095 as the base specification for all profiles defined in the future.
RFC3095[3]は1人の始発の圧縮プロフィールに伴うROHC枠組みを定義します。 仕様、枠組み、およびプロフィールの部品を改良して、簡素化するには、別々のドキュメントに分けられてください、そうした。 このドキュメントが明らかにROHC枠組みを定義しますが、RFC3095によって指定された枠組みの定義を変更しないか、またはアップデートしません。 互いの如何にかかわらず両方のドキュメントを使用できます。 また、これは、定義に基づく実現が互いと共に互換性があって共同利用できるようになるのを含意します。 しかしながら、この仕様を将来定義されたすべてのプロフィールのための基礎仕様としてRFC3095に取って代わらせるのは、意図です。
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 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[1]で説明されるように本書では解釈されることであるべきですか?
2.1. Acronyms
2.1. 頭文字語
This section lists most acronyms used for reference.
このセクションは参照に使用されるほとんどの頭文字語を記載します。
ACK Acknowledgment.
CID Context Identifier.
CO Compressed Packet Format.
CRC Cyclic Redundancy Check.
IR Initialization and Refresh.
IR-DYN Initialization and Refresh, Dynamic part.
LSB Least Significant Bit(s).
MRRU Maximum Reconstructed Reception Unit.
MSB Most Significant Bit(s).
MSN Master Sequence Number.
NACK Negative Acknowledgment.
ROHC RObust Header Compression.
ACK承認。 Cid文脈識別子。 COはパケット・フォーマットを圧縮しました。 CRC周期冗長検査。 そして、IR初期設定、リフレッシュしてください。 IR-DYN初期設定とRefresh、Dynamicは離れています。 LSB最下位ビット。 MRRU最大はレセプションユニットを再建しました。 MSB最上位ビット。 MSNは系列番号を習得します。 ナックの否定応答。 ROHCの体力を要しているヘッダー圧縮。
2.2. ROHC Terminology
2.2. ROHC用語
Context
文脈
The context of the compressor is the state it uses to compress a
header. The context of the decompressor is the state it uses to
decompress a header. Either of these or the two in combination
are usually referred to as "context", when it is clear which is
intended. The context contains relevant information from previous
headers in the packet flow, such as static fields and possible
reference values for compression and decompression. Moreover,
additional information describing the packet flow is also part of
コンプレッサーの文脈はそれがヘッダーを圧縮するのに使用する状態です。 減圧装置の文脈はそれがヘッダーを減圧するのに使用する状態です。 通常、これらのどちらかか組み合わせにおける2が「文脈」と呼ばれます、どれが意図するかが、明確であるときに。 文脈はパケット流動に前のヘッダーからの関連情報を含んでいます、圧縮のための静的な分野と可能な基準値や減圧のように。 そのうえ、また、パケット流動について説明する追加情報は部分です。
Jonsson, et al. Standards Track [Page 4] RFC 4995 The ROHC Framework July 2007
イェンソン、他 規格はROHC枠組みの2007年7月にRFC4995を追跡します[4ページ]。
the context, for example, information about the change behavior of
fields (e.g., the IP Identifier behavior, or the typical inter-
packet increase in sequence numbers and timestamps).
文脈、例えば、分野(例えば、IP Identifierの振舞い、または一連番号とタイムスタンプの典型的な相互パケット増加)の変化の振舞いの情報。
Context damage
文脈損害
When the context of the decompressor is not consistent with the
context of the compressor, decompression may fail to reproduce the
original header. This situation can occur when the context of the
decompressor has not been initialized properly or when packets
have been lost or damaged between the compressor and decompressor.
減圧装置の文脈がコンプレッサーの文脈と一致していないとき、減圧はオリジナルのヘッダーを再生させないかもしれません。 パケットがコンプレッサーと減圧装置の間で減圧装置の文脈が適切に初期化されていないか、失われているか、または破損したとき、この状況は起こることができます。
Packets which cannot be decompressed due to inconsistent contexts
are said to be lost due to context damage. Packets that are
decompressed but contain errors due to inconsistent contexts are
said to be damaged due to context damage.
矛盾した関係のため減圧できないパケットは文脈損害のため失われると言われています。 矛盾した関係のため減圧されますが、誤りを含むパケットは文脈損害のため破損すると言われています。
Context repair mechanism
文脈修理メカニズム
Context repair mechanisms are used to resynchronize the contexts,
an important task since context damage causes loss propagation.
Examples of such mechanisms are NACK-based mechanisms, and the
periodic refreshes of important context information, usually done
in unidirectional operation. There are also mechanisms that can
reduce the context inconsistency probability, for example,
repetition of the same type of information in multiple packets and
CRCs that protect context-updating information.
文脈損害が損失伝播を引き起こすので、文脈修理メカニズムは文脈、重要な仕事を再連動させるのにおいて使用されています。 そのようなメカニズムに関する例はナックベースのメカニズムです、そして、周期的は通常、単方向の操作で行われた重要な文脈情報をリフレッシュします。 文脈矛盾確率、例えば文脈をアップデートする情報を保護する複数のパケットとCRCsでの同じ情報の種類の反復を抑えることができるメカニズムもあります。
CRC-8 validation
CRC-8合法化
The CRC-8 validation refers to the validation of the integrity
against bit error(s) in a received IR and IR-DYN header using the
8-bit CRC included in the IR/IR-DYN header.
CRC-8合法化は、IR IR/DYNヘッダーにCRCを含んでいて、8ビットを使用することで容認されたIRとIR-DYNヘッダーの噛み付いている誤りに対して保全の合法化を呼びます。
CRC verification
CRC検証
The CRC verification refers to the verification of the result of a
decompression attempt using the 3-bit CRC or 7-bit CRC included in
the header of a compressed packet format.
圧縮されたパケット・フォーマットのヘッダーに含まれていた3ビットのCRCか7ビットのCRCを使用することでCRC検証は減圧試みの結果の検証について言及します。
Damage propagation
損害伝播
Delivery of incorrect decompressed headers due to context damage,
that is, due to errors in (i.e., loss of or damage to) previous
header(s) or feedback.
すなわち、文脈損害、中の誤りのため不正確な減圧されたヘッダーの配送、(すなわち、損失、損害、)、前のヘッダーかフィードバック。
Jonsson, et al. Standards Track [Page 5] RFC 4995 The ROHC Framework July 2007
イェンソン、他 規格はROHC枠組みの2007年7月にRFC4995を追跡します[5ページ]。
Error detection
誤り検出
Detection of errors by lower layers. If error detection is not
perfect, there will be residual errors.
下層による誤りの検出。 誤り検出が完全でないなら、見逃し誤りがあるでしょう。
Error propagation
誤り伝播
Damage propagation or loss propagation.
伝播か損失伝播を破損してください。
ROHC profile
ROHCプロフィール
A ROHC profile is a compression protocol, which specifies how to
compress specific header combinations. A ROHC profile may be
tailored to handle a specific set of link characteristics, e.g.,
loss characteristics, reordering between compression points, etc.
ROHC profiles provide the details of the header compression
framework defined in this document, and each compression profile
is associated with a unique ROHC profile identifier [21]. When
setting up a ROHC channel, the set of profiles supported by both
endpoints of the channel is negotiated, and when initializing new
contexts, a profile identifier from this negotiated set is used to
associate each compression context with one specific profile.
ROHCプロフィールは圧縮プロトコルです。(そのプロトコルは特定のヘッダー組み合わせを圧縮する方法を指定します)。 ROHCプロフィールは特定のセットのリンクの特性を扱うために仕立てられるかもしれません、例えば、損失の特性、圧密点などの間で再命令して ROHCプロフィールは本書では定義されたヘッダー圧縮枠組みの詳細を明らかにします、そして、それぞれの圧縮プロフィールはユニークなROHCプロフィール識別子[21]に関連しています。 ROHCチャンネルをセットアップするとき、チャンネルの両方の終点によって支えられたプロフィールのセットは交渉されます、そして、新しい関係を初期化するとき、この交渉されたセットからのプロフィール識別子は、それぞれの圧縮文脈を1個の特定のプロフィールに関連づけるのに使用されます。
Link
リンク
A physical transmission path that constitutes a single IP hop.
単一のIPホップを構成する物理的なトランスミッション経路。
Loss propagation
損失伝播
Loss of headers, due to errors in (i.e., loss of or damage to)
previous header(s) or feedback.
中の誤りによるヘッダーの損失、(すなわち、損失、損害、)、前のヘッダーかフィードバック。
Packet flow
パケット流動
A sequence of packets where the field values and change patterns
of field values are such that the headers can be compressed using
the same context.
分野値の分野値と変化パターンが同じ文脈を使用することでヘッダーを圧縮できるようにものであるパケットの系列。
Residual error
見逃し誤り
Errors introduced during transmission and not detected by lower-
layer error detection schemes.
トランスミッションの間、導入されて、下側の層の誤り検出計画によって検出されなかった誤り。
ROHC channel
ROHCチャンネル
A logical unidirectional point-to-point channel carrying ROHC
packets from one compressor to one decompressor, optionally
carrying ROHC feedback information on the behalf of another
任意に別のものに代わってROHCフィードバック情報を運んで、1個のコンプレッサーから1つの減圧装置までROHCパケットを運ぶ単方向の論理的なポイントツーポイントチャンネル
Jonsson, et al. Standards Track [Page 6] RFC 4995 The ROHC Framework July 2007
イェンソン、他 規格はROHC枠組みの2007年7月にRFC4995を追跡します[6ページ]。
compressor-decompressor pair operating on a separate ROHC channel
in the opposite direction. See also [5].
別々のROHCを運用するコンプレッサー減圧装置組が逆方向に精神を集中します。 また、[5]を見てください。
This document also makes use of the conceptual terminology defined by "ROHC Terminology and Channel Mapping Examples", RFC 3759 [5].
また、このドキュメントは「ROHC用語とチャンネルマッピングの例」によって定義された、概念的な用語、RFC3759[5]を利用します。
3. Background (Informative)
3. バックグラウンド(有益)です。
This section provides a background to the subject of header compression. The fundamental ideas are described together with a discussion about the history of header compression schemes. The motivations driving the development of the various schemes are discussed and their drawbacks identified, thereby providing the foundations for the design of the ROHC framework and profiles [3].
このセクションはヘッダー圧縮の対象にバックグラウンドを供給します。 基本的な考えはヘッダー圧縮技術の歴史についての議論と共に説明されます。 様々な計画の開発を追い立てる動機は、議論していて特定された、その結果、ROHC枠組みとプロフィール[3]のデザインの基礎を提供したそれらの欠点です。
3.1. Header Compression Fundamentals
3.1. ヘッダー圧縮原理
Header compression is possible because there is significant redundancy between header fields; within the headers of a single packet, but in particular between consecutive packets belonging to the same flow. On the path end-to-end, the entire header information is necessary for all packets in the flow, but over a single link, some of this information becomes redundant and can be reduced, as long as it is transparently recovered at the receiving end of the link. The header size can be reduced by first sending field information that is expected to remain static for (at least most of) the lifetime of the packet flow. Further compression is achieved for the fields carrying information that changes more dynamically by using compression methods tailored to their respective assumed change behavior.
ヘッダーフィールドの間には、重要な冗長があるので、ヘッダー圧縮は可能です。 単一のパケットのヘッダー、しかし、特に同じくらいに属す連続したパケットの間では、流れてください。 経路の終わりから終わりでは、全体のヘッダー情報が流れですべてのパケットに必要ですが、単一のリンクの上では、余分になって、この何らかの情報は減らすことができます、それがリンクの犠牲者で透明に回復される限り。 ヘッダーサイズは、最初にパケット流動の(少なくともだいたいの)生涯静的に残っていると予想される分野情報を送ることによって、減少できます。 さらなる圧縮は彼らのそれぞれの想定された変化の振舞いに適合した圧縮方法を使用することによって、よりダイナミックに変化する情報を運ぶ分野に達成されます。
To achieve compression and decompression, some necessary information from past packets is maintained in a context. The compressor and the decompressor update their respective contexts upon certain, not necessarily synchronized, events. Impairment events may lead to inconsistencies in the decompressor context (i.e., context damage), which in turn may cause incorrect decompression. A Robust Header Compression scheme needs mechanisms to minimize the possibility of context damage, in combination with mechanisms for context repair.
圧縮と減圧を達成するために、過去のパケットからの何らかの必要事項が文脈で維持されます。 コンプレッサーとあるそれらのそれぞれの関係をアップデートして、必ず同期するというわけではない減圧装置、出来事。 損傷出来事は減圧装置文脈(すなわち、文脈損害)における矛盾に通じるかもしれません。(順番に、文脈は不正確な減圧を引き起こすかもしれません)。 Robust Header Compression計画は、メカニズムが文脈損害の可能性を最小にする必要があります、文脈修理のためのメカニズムと組み合わせて。
3.2. A Short History of Header Compression
3.2. ヘッダー圧縮の短い歴史
The first header compression scheme, compressed TCP (CTCP) [15], was introduced by Van Jacobson. CTCP, also often referred to as VJ compression, compresses the 40 octets of the TCP/IP header down to 4 octets. CTCP uses delta encoding for sequentially changing fields. The CTCP compressor detects transport-level retransmissions and sends a header that updates the entire context when they occur. This
最初のヘッダー圧縮技術(圧縮されたTCP(CTCP)[15])はヴァン・ジェーコブソンによって導入されました。 また、しばしばVJ圧縮と呼ばれたCTCPはTCP/IPヘッダーの40の八重奏を4つの八重奏まで圧縮します。 CTCPは、連続して職業を替えるのにデルタコード化を使用します。 CTCPコンプレッサーは、輸送レベル「再-トランスミッション」を検出して、起こると全体の文脈をアップデートするヘッダーを送ります。 これ
Jonsson, et al. Standards Track [Page 7] RFC 4995 The ROHC Framework July 2007
イェンソン、他 規格はROHC枠組みの2007年7月にRFC4995を追跡します[7ページ]。
repair mechanism does not require any explicit signaling between the compressor and decompressor.
修理メカニズムはコンプレッサーと減圧装置の間の少しの明白なシグナリングも必要としません。
A general IP header compression scheme, IP header compression [16], improves somewhat on CTCP. IP Header Compression (IPHC) can compress arbitrary IP, TCP, and UDP headers. When compressing non-TCP headers, IPHC does not use delta encoding and is robust. The repair mechanism of CTCP is augmented with negative acknowledgments, called CONTEXT_STATE messages, which speeds up the repair. This context repair mechanism is thus limited by the round-trip time of the link. IPHC does not compress RTP headers.
一般的なIPヘッダー圧縮技術(IPヘッダー圧縮[16])はCTCPをいくらか改良します。 IP Header Compression(IPHC)は任意のIP、TCP、およびUDPヘッダーを圧縮できます。 非TCPヘッダーを圧縮するとき、IPHCはデルタコード化を使用しないで、強健です。 CONTEXT_州メッセージと呼ばれる否定応答に従って、CTCPの修理メカニズムは増大します(修理を早くします)。 この文脈修理メカニズムはリンクの往復の時間までにこのようにして制限されます。 IPHCはRTPヘッダーを圧縮しません。
CRTP [17] is an RTP extension to IPHC. CRTP compresses the 40 octets of IPv4/UDP/RTP headers to a minimum of 2 octets when the UDP Checksum is not enabled. If the UDP Checksum is enabled, the minimum CRTP header is 4 octets.
CRTP[17]はIPHCへのRTP拡張子です。 UDP Checksumが有効にされないとき、CRTPはIPv4/UDP/RTPヘッダーの40の八重奏を最低2つの八重奏に圧縮します。 UDP Checksumが有効にされるなら、最小のCRTPヘッダーは4つの八重奏です。
On lossy links with long round-trip times, CRTP does not perform well [20]. Each packet lost over the link causes decompression of several subsequent packets to fail, because the context becomes invalidated during at least one link round-trip time from the lost packet. Unfortunately, the large headers that CRTP sends when updating the context waste additional bandwidth.
長い往復の回との損失性リンクには、CRTPは井戸[20]を実行しません。 リンクの上に失われた各パケットはいくつかのその後のパケットの減圧に失敗されます、文脈が無くなっているパケットから往復の少なくとも1リンク回の間、無効にされるようになるので。 残念ながら、文脈をアップデートするときCRTPが送る大きいヘッダーは追加帯域幅を浪費します。
CRTP uses a local repair mechanism known as TWICE, which was introduced by IPHC. TWICE derives its name from the observation that when the flow of compressed packets is regular, the correct guess when one packet is lost between the compression points is to apply the update in the current packet twice. While TWICE improves CRTP performance significantly, [20] also found that even with TWICE, CRTP doubled the number of lost packets.
CRTPはIPHCによって導入されたTWICEとして知られている局部的修繕メカニズムを使用します。 TWICEが名前に正しい推測が圧縮されたパケットの流れが通常であるときに、1つのパケットが圧密点の間で失われているとき、現在のパケットで二度アップデートを適用することであるという観測に由来しています。 TWICEはCRTP性能をかなり向上させますが、また、[20]は、TWICEがあっても、CRTPが無くなっているパケットの数を倍にしたのがわかりました。
An enhanced variant of CRTP, called eCRTP [19], means to improve the robustness of CRTP in the presence of reordering and packet losses, while keeping the protocol almost unchanged from CRTP. As a result, eCRTP does provide better means to implement some degree of robustness, albeit at the expense of additional overhead, leading to a reduction in compression efficiency in comparison to CRTP.
eCRTP[19]と呼ばれるCRTPの高められた異形は、CRTPからほとんど変わりがなくプロトコルを保っている間、再命令とパケット損失の面前でCRTPの丈夫さを改良することを意味します。 その結果、eCRTPはいくらかの丈夫さを実行するより良い手段を提供します、追加オーバーヘッドを犠牲にして、CRTPとの比較における圧縮効率で減少に通じて。
4. Overview of Robust Header Compression (ROHC) (Informative)
4. 体力を要しているヘッダー圧縮(ROHC)の概観(有益)です。
4.1. General Principles
4.1. 綱領
As mentioned earlier, header compression is possible per-link due to the fact that there is much redundancy between header field values within packets, and especially between consecutive packets belonging to the same flow. To utilize these properties for header compression, there are a few essential steps to consider.
先に述べたように、パケットの中のヘッダーフィールド値の間と、そして、同じ流れに属す連続したパケットの特に間には、多くの冗長があるという事実のためにヘッダー圧縮は可能なリンクです。 ヘッダー圧縮にこれらの特性を利用するために、考える不可欠の数ステップがあります。
Jonsson, et al. Standards Track [Page 8] RFC 4995 The ROHC Framework July 2007
イェンソン、他 規格はROHC枠組みの2007年7月にRFC4995を追跡します[8ページ]。
The first step consists of identifying and grouping packets together into different "flows", so that packet-to-packet redundancy is maximized in order to improve the compression ratio. Grouping packets into flows is usually based on source and destination host (IP) addresses, transport protocol type (e.g., UDP or TCP), process (port) numbers, and potentially additional unique application identifiers, such as the synchronization source (SSRC) in RTP [13]. The compressor and decompressor each establish a context for the packet flow and identify the context with a Context Identifier (CID) included in each compressed header.
第一歩はパケットを異なった「流れ」に一緒に特定して、分類するのから成ります、パケットからパケットへの冗長が圧縮比を改良するために最大にされるように。 通常、パケットを流れに分類するのはソースとあて先ホスト(IP)アドレス、トランスポート・プロトコルタイプ(例えば、UDPかTCP)、過程(ポート)番号、および潜在的に追加しているユニークなアプリケーション識別子に基づいています、RTP[13]の同期ソース(SSRC)などのように。 コンプレッサーと減圧装置は、それぞれパケット流動のための文脈を確立して、それぞれの圧縮されたヘッダーに(CID)を含んでいて、文脈をContext Identifierと同一視します。
The second step is to understand the change patterns of the various header fields. On a high level, header fields fall into one of the following classes:
第2ステップは様々なヘッダーフィールドの変化パターンを理解することです。 高いレベルでは、ヘッダーフィールドは以下のクラスの1つになります:
INFERRED These fields contain values that can be inferred from
other fields or external sources, for example, the size
of the frame carrying the packet can often be derived
from the link layer protocol, and thus does not have to
be transmitted by the compression scheme.
INFERRED These分野が他の分野か外部電源から推論できる値を含んでいて、例えば、パケットを運ぶフレームのサイズは、リンクレイヤプロトコルからしばしば得ることができて、その結果、圧縮技術によって伝えられる必要はありません。
STATIC Fields classified as STATIC are assumed to be constant
throughout the lifetime of the packet flow. The value
of each field is thus only communicated initially.
STATICとして分類されたSTATICフィールズがパケット流動の生涯の間中一定であると思われます。 それぞれの分野の値は初めは、このようにして伝えられるだけです。
STATIC-DEF Fields classified as STATIC-DEF are used to define a
packet flow as discussed above. Packets for which
respective values of these fields differ are treated as
belonging to different flows. These fields are in
general compressed as STATIC fields.
STATIC-DEFとして分類されたSTATIC-DEFフィールズは、パケット流動を定義するのに上で議論するように使用されます。 これらの分野のそれぞれの値が異なるパケットは異なった流れに属すとして扱われます。 一般に、これらの分野はSTATIC分野として圧縮されます。
STATIC-KNOWN Fields classified as STATIC-KNOWN are expected to have
well-known values, and therefore their values do not
need to be communicated.
STATIC-KNOWNとして分類されたSTATIC-KNOWNフィールズには周知の値があると予想されて、したがって、それらの値はコミュニケートする必要はありません。
CHANGING These fields are expected to vary randomly, either
within a limited value set or range, or in some other
manner. CHANGING fields are usually handled in more
sophisticated ways based on a more detailed
classification of their expected change patterns.
CHANGING These分野が無作為か限られた選択値群か範囲以内かある他の方法で異なると予想されます。 通常、CHANGING分野はそれらの予想された変化パターンの、より詳細な分類に基づくより高度な方法で扱われます。
Finally, the last step is to choose the encoding method(s) that will be applied onto different fields based on classification. The encoding methods, in combination with the identified field behavior, provide the input to the design of the compressed header formats. The analysis of the probability distribution of the identified change patterns then provides the means to optimize the packet formats,
最終的に、最後のステップは分類に基づく異なったフィールドに適用されるコード化方法を選ぶことです。 特定された分野の振舞いと組み合わせて、コード化方法は圧縮されたヘッダー形式のデザインに入力を提供します。 そして、特定された変化パターンの確率分布の分析はパケット・フォーマットを最適化する手段を提供します。
Jonsson, et al. Standards Track [Page 9] RFC 4995 The ROHC Framework July 2007
イェンソン、他 規格はROHC枠組みの2007年7月にRFC4995を追跡します[9ページ]。
where the most frequently occurring change patterns for a field should be encoded within the most efficient format(s).
最も頻繁に起こるところでは、分野への変化パターンが最も効率的な形式の中でコード化されるべきです。
However, compression efficiency has to be traded against two other properties: the robustness of the encoding to losses and errors between the compressor and the decompressor, and the ability to detect and cope with errors in the decompression process.
しかしながら、他の2つの特性に対して圧縮効率を取り引きしなければなりません: 損失へのコード化とコンプレッサーと、減圧装置と、減圧の過程における誤りを検出して、対処する能力の間の誤りの丈夫さ。
4.2. Compression Efficiency, Robustness, and Transparency
4.2. 圧縮効率、丈夫さ、および透明
The performance of a header compression protocol can be described with three parameters: its compression efficiency, its robustness, and its compression transparency.
3つのパラメタでヘッダー圧縮プロトコルの性能について説明できます: 圧縮効率、丈夫さ、およびその圧縮透明。
Compression efficiency
圧縮効率
The compression efficiency is determined by how much the average
header size is reduced by applying the compression protocol.
平均したヘッダーサイズが圧縮プロトコルを適用することによってどれほど減少するかによって圧縮効率は測定されます。
Robustness
丈夫さ
A robust protocol tolerates packet losses, residual bit errors,
and out-of-order delivery on the link over which header
compression takes place, without losing additional packets or
introducing additional errors in decompressed headers.
強健なプロトコルはヘッダー圧縮が行われるリンクの上にパケット損失、残りの噛み付いている誤り、および不適切な配送を許容します、追加パケットを失うか、または減圧されたヘッダーで追加誤りを導入しないで。
Compression transparency
圧縮透明
The compression transparency is a measure of the extent to which
the scheme maintains the semantics of the original headers. If
all decompressed headers are bitwise identical to the
corresponding original headers, the scheme is transparent.
圧縮透明は計画がオリジナルのヘッダーの意味論を維持する範囲の基準です。 すべて減圧されるならヘッダーがそうである、bitwiseする、対応するオリジナルのヘッダーに同じであることで、計画は透明です。
4.3. Developing the ROHC Protocol
4.3. ROHCプロトコルを開発します。
The challenge in developing a header compression protocol is to conciliate compression efficiency and robustness while maintaining transparency, as increasing robustness will always come at the expense of a lower compression efficiency, and vice-versa. The scheme should also be flexible enough in its design to minimize the impacts from the varying round-trip times and loss patterns of links where header compression will be used.
ヘッダー圧縮プロトコルを開発することにおける挑戦は透明を維持している間、圧縮効率と丈夫さを懐柔することです、増加する丈夫さがいつも下側の圧縮効率を犠牲にして来るとき逆もまた同様です。 また、計画もヘッダー圧縮が使用されるリンクの異なった往復の回と損失パターンから衝撃を最小にするデザインで十分フレキシブルであるべきです。
To achieve this, the header compression scheme must provide facilities for the decompressor to verify decompression and detect potential context damage, as well as context recovery mechanisms such as feedback. Header compression schemes prior to the ones developed
ヘッダー圧縮技術は減圧について確かめて、潜在的文脈損害を検出するために施設を減圧装置に提供しなければなりません、これを達成するならフィードバックなどの文脈回収機構と同様に。 ものの前のヘッダー圧縮技術は展開しました。
Jonsson, et al. Standards Track [Page 10] RFC 4995 The ROHC Framework July 2007
イェンソン、他 規格はROHC枠組みの2007年7月にRFC4995を追跡します[10ページ]。
by the Robust Header Compression (ROHC) WG were not designed with the above high-level objectives in mind.
Robust Header Compression(ROHC)によって、WGは上のハイレベルの目的で念頭に設計されませんでした。
The ROHC WG has developed header compression solutions to meet the needs of present and future link technologies. While special attention has been put towards meeting the more stringent requirements stemming from the characteristics of wireless links, the results are equally applicable to many other link technologies.
ROHC WGは、現在の、そして、将来のリンク技術の需要を満たすためにヘッダー圧縮解決策を見いだしました。 無線のリンクの特性によるより厳しい必要条件を満たすことに向かって特別な注意は置かれましたが、結果は等しく他の多くのリンク技術に適切です。
RFC 3095 [3], "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", was published in 2001, as the first output of the ROHC WG. ROHC is a general and extendable framework for header compression, on top of which profiles can be defined for compression of different protocols headers. RFC 3095 introduced a number of new compression techniques, and was successful at living up to the requirements placed on it, as described in [18].
RFC3095[3]、「体力を要しているヘッダー圧縮(ROHC):」 枠組みと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP」は2001年にROHC WGの最初の出力として発行されました。 ROHCはヘッダー圧縮のための一般的で「広げ-可能」な枠組みです、異なったプロトコルヘッダーの圧縮のためにどのプロフィールを定義できるかの上で。 RFC3095は多くの新しい圧縮のテクニックを導入して、それに置かれた要件を満たすところにうまくいきました、[18]で説明されるように。
Interoperability testing of RFC 3095 confirms the capabilities of ROHC to meet its purposes, but feedback from implementers has also indicated that the protocol specification is complex and sometimes obscure. Most importantly, a clear distinction between framework and profiles is not obvious in [3], which also makes development of additional profiles troublesome. This document therefore aims at explicitly specifying the ROHC framework, while a companion document [8] specifies revised versions of the compression profiles of RFC 3095.
RFC3095の相互運用性テストはROHCが目的を満たす能力を確認しますが、また、implementersからのフィードバックは、プロトコル仕様が複雑であって、時々不鮮明であることを示しました。 最も重要に、枠組みとプロフィールの明らかな区別は[3]で明白ではありません。(また、[3]は追加プロフィールの開発を厄介にします)。 したがって、このドキュメントは明らかにROHC枠組みを指定するのを目的とします、仲間ドキュメント[8]はRFC3095の圧縮プロフィールの改訂版を指定しますが。
4.4. Operational Characteristics of the ROHC Channel
4.4. ROHCチャンネルの操作上の特性
Robust header compression can be used over many type of link technologies. The ROHC framework provides flexibility for profiles to address a wide range of applications, and this section lists some of the operational characteristics of the ROHC channel (see also [5]).
多くのタイプのリンク技術の上で体力を要しているヘッダー圧縮を使用できます。 プロフィールがさまざまなアプリケーションを記述するように、ROHC枠組みは柔軟性を提供します、そして、このセクションはROHCチャンネルの操作上の特性のいくつかを記載します。(また、[5])を見てください。
Multiplexing over a single logical channel
ただ一つの論理チャネルの上で多重送信します。
The ROHC channel provides a mechanism to identify a context within
the general ROHC packet format. The CID makes it possible for a
logical channel that supports ROHC to transport multiple header-
compressed flows, while still making it possible for a channel to
be dedicated to one single packet flow without any CID overhead.
More specifically, ROHC uses a distinct context identifier space
per logical channel, and the context identifier can be omitted for
one of the flows over the ROHC channel when configured to use a
small CID space.
ROHCチャンネルは、一般的なROHCパケット・フォーマットの中で文脈を特定するためにメカニズムを提供します。 CIDはまだチャンネルが少しもCIDオーバーヘッドなしで1つのただ一つのパケット流動に専念するのを可能にしている間、複数のヘッダーの圧縮された流れを輸送するのをROHCを支持する論理チャネルに可能にします。 より明確に、ROHCは1論理チャネルあたり1つの異なった文脈識別子スペースを使用します、そして、小さいCIDスペースを使用するために構成されると、ROHCチャンネルの上の流れの1つのために文脈識別子は省略できます。
Jonsson, et al. Standards Track [Page 11] RFC 4995 The ROHC Framework July 2007
イェンソン、他 規格はROHC枠組みの2007年7月にRFC4995を追跡します[11ページ]。
Establishment of channel parameters
チャンネルパラメタの確立
A link layer defining support for the ROHC channel must provide
the means to establish header compression channel parameters (see
Section 5.1). This can be achieved through a negotiation
mechanism, static provisioning, or some out-of-band signaling.
ROHCチャンネルのサポートを定義するリンクレイヤはヘッダー圧縮チャンネルパラメタを確立する手段を提供しなければなりません(セクション5.1を見てください)。 合図しながら、交渉メカニズム、静的な食糧を供給すること、またはいくつかを通してバンドの外にこれを達成できます。
Packet type identification
パケットタイプ確認
The ROHC channel defines a packet type identifier space, and puts
restrictions with respect to the use of a number of identifiers
that are common for all ROHC profiles. Identifiers that have no
restrictions, i.e., identifiers that are not defined by this
document, are available to each profile. The identifier is part
of each compressed header, and this makes it possible for the link
that supports the ROHC channel to allocate one single link layer
payload type for ROHC.
ROHCチャンネルは、パケットタイプ識別子スペースを定義して、多くのすべてのROHCプロフィールに、一般的な識別子の使用に関して制限します。 制限が全くない識別子(すなわち、このドキュメントによって定義されない識別子)は各プロフィールに利用可能です。 識別子はそれぞれの圧縮されたヘッダーの一部です、そして、これで、ROHCのための1つの単独のリンクレイヤペイロードタイプを割り当てるのはROHCチャンネルを支えるリンクに可能になります。
Out-of-order delivery between compression endpoints
圧縮終点の間の不適切な配送
Each profile defines its own level of robustness, including
tolerance to reordering of packets before but especially between
compression endpoints, if any.
各プロフィールはもしあればそれ自身の終点の前にもかかわらず、圧縮終点の特に間のパケットを再命令するのに寛容を含む丈夫さのレベルを定義します。
For profiles specified in [3], the channel between the compressor
and decompressor is required to maintain in-order delivery of the
packets, i.e., the definition of these profiles assumes that the
decompressor always receives packets in the same order as the
compressor sent them. The impacts of reordering on the
performance of these profiles is described in [7]. However,
reordering before the compression point is handled, i.e., these
profiles make no assumption that the compressor will receive
packets in-order.
[3]で指定されたプロフィールに関しては、コンプレッサーと減圧装置の間のチャンネルがオーダーにおける、パケットの配送を維持するのに必要です、すなわち、これらのプロフィールの定義はコンプレッサーがそれらを送ったので、減圧装置が同次でパケットをいつも受けると思います。 これらのプロフィールの性能のときに再命令する衝撃は[7]で説明されます。 すなわち、圧密点が扱われる前に再命令するこれらのプロフィールがどのように、コンプレッサーが受信されるという仮定を全くしないでも、パケットは中で注文されます。
一覧
スポンサーリンク
