Network Working Group L-E. Jonsson
Request for Comments: 4995 G. Pelletier
Category: Standards Track K. Sandlund
Ericsson
July 2007
The RObust Header Compression (ROHC) Framework
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
ロバストヘッダ圧縮（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フレームワークは、圧縮プロファイルのセットと一緒に、最初ROHC仕様を改善し、単純化するためにRFC 3095.に定義された、この文書は、明示的にROHCフレームワークと別々に、非圧縮のためのプロファイルを定義します。より具体的には、フレームワークの定義は、RFC 3095で指定されたフレームワークの定義を変更したり更新しません。
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
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
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]内に搬送されたデータを搬送するアプリケーションは、次に、リンク層フレーミングに加えて、（12オクテットのIPv4 [10]ヘッダ（20オクテット）、UDP [12]ヘッダ（8つのオクテット）、およびRTPヘッダを有することになります）、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).
特定のフロー（またはアプリケーション）のための相対利得は、各パケットに使用されるペイロードのサイズに依存します。そのような符号化された音声を含むペイロードのサイズは15-20オクテットな限り小さくすることができますボイスオーバーIP、などのアプリケーションでは、このゲインは非常に重要になります。同様に、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.
ロバストヘッダ圧縮（ROHC）プロトコルは、効率的で柔軟、かつ将来性のヘッダ圧縮の概念を提供します。異なる特性を持つさまざまなリンク技術の上に、効率的かつ確実に動作するように設計されています。
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.
RFC 3095 [3]圧縮プロファイルの初期セットと共にROHCフレームワークを定義します。仕様を改善し、簡素化するために、フレームワークおよびプロファイルの部分は、別の文書に分割されています。この文書は、明示的にROHCフレームワークを定義していますが、それはRFC 3095で指定されたフレームワークの定義を変更または更新されません。両方の文書は、互いに独立して使用することができます。これはまた、いずれかの定義に基づいて実装が互いに互換性と相互運用性であろうことを意味します。しかし、この仕様は、将来的に定義されたすべてのプロファイルのための基本仕様としてRFC 3095に代わっする意図です。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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初期化と更新、動的な部分。 LSB最下位ビット（複数可）。 MRRU最大は、受信部を再構築します。 MSB最上位ビット（複数可）。 MSNマスターシーケンス番号。 NACK否定応答。 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 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).
コンプレッサのコンテキストは、ヘッダを圧縮するために使用する状態です。解凍器のコンテキストは、ヘッダを解凍するために使用する状態です。意図されている明確であるときに、これらのまたは組み合わせで2のいずれかが、通常は、「文脈」と呼ばれています。コンテキストは、静的フィールドと圧縮および圧縮解除のための可能な基準値としてパケットフロー内の前のヘッダからの関連情報が含まれています。また、パケットフローを説明する追加情報は、コンテキストの一部であり、例えば、フィールドの変化挙動（例えば、IP識別子挙動、またはシーケンス番号とタイムスタンプにおける典型的なパケット間の増加）に関する情報。
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.
コンテキスト修復メカニズムは、コンテキストの損傷が損失伝播を招くため、コンテキスト、重要なタスクを再同期するために使用されています。そのような機構の例は、通常は一方向操作で行わNACKベースのメカニズム、及び重要なコンテキスト情報の周期的リフレッシュです。例えば、コンテキスト矛盾確率を減らすことができる仕組みもありますが、コンテキストの更新情報を保護する複数のパケットとのCRCの情報の同じタイプの繰り返し。
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検証は、8ビットのCRCを使用して、受信したIR及びIR-DYNヘッダーのビットエラー（S）に対して整合性の検証を指す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.
CRC検証が3ビットのCRC又は圧縮パケットフォーマットのヘッダに含まれる7ビットの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.
コンテキスト損傷に誤っ解凍ヘッダの送達は、それが原因（すなわち、損失または損傷に）以前のヘッダ（S）またはフィードバックの誤差に、です。
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チャンネルを設定するとき、チャネルの両方のエンドポイントでサポートされているプロファイルのセットがネゴシエートされ、そして新たなコンテキストを初期化するとき、このネゴシエートセットからプロファイル識別子は、ある特定のプロファイルを有する各圧縮コンテキストを関連付けるために使用されます。
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.
（すなわち、損失または損傷に）の誤差に起因するヘッダの喪失、前ヘッダ（S）またはフィードバック。
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 compressor-decompressor pair operating on a separate ROHC channel in the opposite direction. See also [5].
必要に応じて反対方向に別個ROHCチャネル上で動作する別の圧縮伸長ペアの代わりにROHCフィードバック情報を運ぶ一のデコンプレッサ1つの圧縮機からROHCパケットを運ぶ論理単方向ポイントツーポイントチャネル。 [5]も参照してください。
This document also makes use of the conceptual terminology defined by "ROHC Terminology and Channel Mapping Examples", RFC 3759 [5].
この文書はまた、「ROHC用語及びチャネルマッピング例」によって定義された概念的な用語を利用して、RFC 3759 [5]。
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]。
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.
ヘッダフィールドの間に有意な冗長性があるので、ヘッダ圧縮が可能です。単一のパケットのヘッダ内に、同じフローに属する連続したパケット間の特定です。パス、エンド・ツー・エンドで、全体のヘッダ情報は、フロー内のすべてのパケットのために必要であるが、1つのリンクを介して、この情報の一部は、冗長になり、受信側であれば、それは透過的に回収されるように、低減することができますリンクの。ヘッダのサイズは、最初の（少なくともほとんどの）のために静的なままであると予想されるフィールド情報パケットフローの寿命を送信することによって低減することができます。さらなる圧縮は、それぞれ想定変化の挙動に合わせた圧縮方法を用いることにより、より動的に変化する情報を運ぶフィールドに達成されます。
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.
圧縮と解凍を達成するために、過去のパケットからのいくつかの必要な情報は、コンテキスト内で維持されています。コンプレッサとデコンプレッサは、必ずしも同期していない、特定のイベントの際に、それぞれのコンテキストを更新します。減損イベントは順番に間違った解凍を引き起こす可能性がデコンプレッサのコンテキスト（すなわち、コンテクスト損傷）、中に不整合が生じることがあります。ロバストヘッダ圧縮方式は、コンテキストの修理のためのメカニズムと組み合わせて、コンテキスト損傷の可能性を最小限にするためのメカニズムを必要とします。
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 repair mechanism does not require any explicit signaling between the compressor and decompressor.
最初のヘッダ圧縮方式は、圧縮されたTCP（CTCP）[15]は、バン・ジェイコブソンによって導入されました。 CTCPは、しばしばVJ圧縮と呼ばれる、ダウン4つのオクテットのTCP / IPヘッダの40個のオクテットを圧縮します。 CTCPが順次変化するフィールドのデルタ符号化を使用します。 CTCP圧縮機は、トランスポート・レベルの再送信を検出し、それらが発生したときに全体のコンテキストを更新ヘッダを送信します。この修復機構は、コンプレッサとデコンプレッサとの間の明示的なシグナリングを必要としません。
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ヘッダ圧縮（IPHC）は、任意のIP、TCP、およびUDPヘッダを圧縮することができます。非TCPヘッダを圧縮する場合、IPHCはデルタエンコーディングを使用し、堅牢ではありません。 CTCPの修理メカニズムは、修理をスピードアップCONTEXT_STATEメッセージと呼ばれる否定応答、で強化されています。このコンテキストの修復機構は、このように、リンクの往復時間によって制限されています。 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の拡張です。 CRTPは、UDPチェックサムが有効になっていない2つのオクテットの最小値へのIPv4 / UDP / RTPヘッダの40個のオクテットを圧縮します。 UDPチェックサムが有効になっている場合、最小の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圧縮パケットの流れが規則的であるとき、1つのパケットは圧縮点の間で失われた正しい推測は二回、現在のパケット内のアップデートを適用することであるという観察からその名の由来。 TWICE大幅CRTP性能を改善しながら、[20]もも2回、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呼ばCRTPの向上変異体は、[19]、CRTPからほとんど変わらないプロトコルを維持しながら、並べ替え、パケット損失の存在下で、CRTPのロバスト性を改善することを意味します。結果として、eCRTPはCRTPに比べて圧縮効率が低下する、追加のオーバーヘッドを犠牲にしてあるが、ロバスト性をある程度実装するより良い手段を提供しません。
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.
前述したように、ヘッダ圧縮が原因パケット内の、特に同じフローに属する連続するパケット間のヘッダフィールド値との間の多くの冗長性が存在するという事実に当たりリンクが可能です。ヘッダ圧縮のためにこれらの特性を利用するには、考慮すべきいくつかの重要なステップがあります。
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）、そのような同期ソース（SSRC）として、工程（ポート）番号、及び潜在的に追加の一意のアプリケーション識別子に基づいていますRTP [13]。コンプレッサとデコンプレッサ各パケットフローのためのコンテキストを確立し、識別子（CID）を各圧縮ヘッダに含まれるコンテキストとコンテキストを識別する。
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:
第二のステップは、様々なヘッダフィールドの変化パターンを理解することです。高いレベルでは、ヘッダフィールドは、次のクラスのいずれかに分類されます：
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.
推論これらのフィールドは、他のフィールドまたは外部ソースから推測することができる値は、例えば、パケットを運ぶフレームのサイズは、多くの場合、リンク層プロトコルに由来することができるので、圧縮方式によって送信される必要はない含みます。
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-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-知られているように分類さSTATIC知られているフィールドは、よく知られた値を有することが期待されるため、その値が通信する必要はありません。
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.
これらのフィールドを変更すると、限られた値のセットまたは範囲内、またはいくつかの他の方法のいずれかで、ランダムに変化することが予想されます。変化するフィールドは、通常、彼らの期待変化パターンのより詳細な分類に基づいて、より洗練された方法で処理されています。
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, where the most frequently occurring change patterns for a field should be encoded within the most efficient format(s).
最後に、最後のステップは、分類に基づいて様々な分野に適用される符号化方法（複数可）を選択することです。符号化方法は、識別されたフィールドの動作と組み合わせて、圧縮ヘッダフォーマットの設計への入力を提供します。識別された変化パターンの確率分布の分析は、フィールドのための最も頻繁に発生する変化パターンは、最も効率的な形式（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.
コンプレッサとデコンプレッサと、検出および伸長処理のエラーに対処する能力との間の損失及びエラーに対する符号化のロバスト性：しかし、圧縮効率は、二つの他の特性に対して取引されなければなりません。
The performance of a header compression protocol can be described with three parameters: its compression efficiency, its robustness, and its compression transparency.
その圧縮効率、堅牢性、およびその圧縮透明度：ヘッダ圧縮プロトコルの性能は、三つのパラメータで記述することができます。
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.
圧縮透明性スキームは、元のヘッダのセマンティクスを維持する程度の尺度です。全て解凍ヘッダは、対応する元のヘッダーと同じビット単位である場合、スキームは透明です。
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 by the Robust Header Compression (ROHC) WG were not designed with the above high-level objectives in mind.
これを達成するために、ヘッダ圧縮方式は、減圧を検証し、潜在的なコンテキストの損傷、ならびにフィードバックとしてコンテキスト回復メカニズムを検出するための減圧装置のための設備を提供しなければなりません。前ロバストヘッダ圧縮（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].
RFC 3095 [3]は、 "ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、ESP、および非圧縮"、ROHC WGの第一の出力として、2001年に出版されました。 ROHCは、プロファイルは異なるプロトコルヘッダの圧縮のために定義することができるの上に、ヘッダ圧縮のための一般的かつ拡張可能なフレームワークです。 [18]で説明したようにRFC 3095は、新しい圧縮技術の数を導入し、その上に置か要件まで住んで成功しました。
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.
RFC 3095の相互運用性テストは、その目的を満たすために、ROHCの能力を確認したが、実装者からのフィードバックは、プロトコル仕様が複雑で時々不明瞭であることを示しています。最も重要なのは、フレームワークとプロファイル間の明確な区別も面倒な追加のプロファイルの開発を行っている、[3]で明らかにされていません。仲間ドキュメント[8] RFC 3095の圧縮プロフィールの改訂版を指定しながら、この文書では、そのため、明示的に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フレームワークは、アプリケーションの広い範囲に対処するためのプロファイルの柔軟性を提供し、このセクションでは、（[5]も参照）ROHCチャネルの動作特性のいくつかを示しています。
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オーバーヘッドなしで単一のパケットフローに専用されるチャネルのためにそれを可能にしながら、複数のヘッダ圧縮フローを輸送するためにROHCをサポートする論理チャネルのためにことができます。より具体的には、ROHCは、論理チャネルごとに異なるコンテクスト識別子空間を使用し、小さなCID空間を使用するように構成されたときにコンテキスト識別子は、ROHCチャネル上のフローのために省略することができます。
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のための単一のリンク・レイヤ・ペイロードタイプを割り当てるために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]に記載されています。しかし、圧縮点が処理される前に並べ替え、すなわち、これらのプロファイルは、圧縮機に次のパケットを受信するという仮定をしません。
For the ROHCv2 profiles specified in [8], their definitions assume that the decompressor can receive packets out-of-order, i.e., not in the same order that the compressor sent them. Reordering before the compression point is also dealt with.
[8]で指定ROHCv2プロファイルのために、それらの定義は、減圧装置がない圧縮機がそれらを送ったのと同じ順序で、すなわち、アウトオブオーダーパケットを受信することができると仮定する。圧縮ポイントの前の並び替えも扱っています。
Duplication of packets
パケットの複製
The link supporting the ROHC channel is required to not duplicate packets (however, duplication of packets can occur before they reach the compressor, i.e., there is no assumption that the compressor will receive only one copy of each packet).
ROHCチャンネルをサポートするリンクが（ただし、これらはコンプレッサに到達する前にパケットの重複が発生する可能性があり、すなわち、圧縮機は各パケットのコピーを1つだけ受信するという仮定が存在しない）のパケットを複製しないことが要求されます。
Framing
フレーミング
The link layer must provide framing that makes it possible to distinguish frame boundaries and individual frames.
リンク層はフレーム境界と個々のフレームを区別することが可能となり、フレーミングを提供しなければなりません。
Error detection/protection
エラー検出/保護
ROHC profiles should be designed to cope with residual errors in the headers delivered to the decompressor. CRCs are used to detect decompression failures and to prevent or reduce damage propagation. However, it is recommended that lower layers deploy error detection for ROHC headers and that ROHC headers with high residual error rates not be delivered.
ROHCプロファイルは減圧装置に配信ヘッダ中の残留エラーに対処するように設計されるべきです。 CRCは減圧障害を検出し、防止または損傷の伝播を低減させるために使用されます。しかし、下位層はROHCヘッダのエラー検出を展開し、高い残留誤り率とのROHCヘッダが配信されないことをことをお勧めします。
Compression of header fields is based on the establishment of a function to a sequence number, called the master sequence number (MSN). This function describes the change pattern of the field with respect to a change in the MSN.
ヘッダフィールドの圧縮は、マスタシーケンス番号（MSN）と呼ばれ、配列番号への機能の確立に基づいています。この関数は、MSNの変化に対する磁界の変化パターンを記述する。
Change patterns include, for example, fields that increase monotonically or by a small value, fields that seldom change,and fields that remain unchanging for the entire lifetime of the packet flow, in which case the function to the MSN is equivalent to a constant value.
変化パターンは、例えば、MSNへの関数が一定値に相当する場合には単調または小さな値、ほとんど変化しないフィールド、及びパケットフローの全体の寿命のために不変のままフィールド増加フィールドを含みます。
The compressor first establishes functions for each of the header fields, and then reliably communicates the MSN. When the change pattern of the field does not match the established function, i.e., the existing function gives a result that is different from the field in the header being compressed, additional information can be sent to update the parameters of that function.
圧縮機は、第一のヘッダフィールドのそれぞれに対して機能を確立し、その後、確実MSNを通信します。フィールドの変更パターンが確立された機能と一致しない場合、すなわち、既存の機能は、圧縮されたヘッダ内のフィールドとは異なる結果を与える、追加情報は、その関数のパラメータを更新するために送信することができます。
The MSN is defined per profile. It can be either derived directly from one of the fields of the protocol being compressed (e.g., the RTP SN [8]), or it can be created and maintained by the compressor (e.g., the MSN for compression of UDP in profile 0x0102 [8] or the MSN in ROHC-TCP [9]).
MSNは、プロファイルごとに定義されています。 【それは（[8]例えば、RTP SN）圧縮されるプロトコルのフィールドのいずれかから直接導出することができるか、それが圧縮機（例えば、プロファイル0x0102におけるUDPの圧縮MSNによって作成および維持することができます8]又はROHC-TCPでMSN [9]）。
A compression context can be conceptually divided into two different parts, the static context and the dynamic context, each based on the properties of the fields that are being compressed.
圧縮コンテキストは、概念的に2つの異なる部分、静的コンテキストと動的コンテキスト、圧縮されているフィールドの特性に基づいてそれぞれに分割することができます。
The static part includes the information necessary to compress and decompress the fields whose change behavior is classified as STATIC, STATIC-KNOWN, or STATIC-DEF (as described in Section 4.1 above).
静的部分は、圧縮して、その変化挙動（上記セクション4.1に記載されているように）STATIC、STATIC知られ、又はSTATIC-DEFとして分類されたフィールドを解凍するために必要な情報を含みます。
The dynamic part includes the state maintained for all the other fields, i.e., those that are classified as CHANGING.
動的部分は、他のすべてのフィールド、すなわち、変更などに分類されるもののために維持状態を含みます。
This section normatively defines the parts common to all ROHC profiles, i.e., the framework. The framework specifies the requirements and functionality of the ROHC channel, including how to handle multiple compressed packet flows over the same channel.
このセクションでは、規範的に全てROHCプロファイル、すなわち、フレームワークと共通する部分を定義します。フレームワークは、同じチャネルを介して複数の圧縮されたパケット・フローを処理する方法を含む要件とROHCチャンネルの機能を、指定します。
Finally, this section specifies encoding methods used in the packet formats that are common to all profiles. These encoding methods may be reused within profile specifications for encoding fields in profile-specific parts of a packet format, without requiring their redefinition.
最後に、このセクションでは、すべてのプロファイルに共通するパケットフォーマットで使用される符号化方式を指定します。これらの符号化方法は、それらの再定義を必要とせずに、パケットフォーマットのプロファイル固有部分のフィールドを符号化するためのプロファイル仕様の範囲内で再利用することができます。
Associated with each compressed flow is a context. The context is the state that the compressor and the decompressor maintain in order to correctly compress or decompress the headers of the packet in the flow. Each context is identified using a CID.
各圧縮フローに関連付けられたコンテキストです。コンテキストは、圧縮器と解凍器が正しくフロー内のパケットのヘッダを圧縮または圧縮解除するために維持した状態です。各コンテキストは、CIDを使用して識別されます。
A context is considered to be a new context when the CID is associated with a profile for the first time since the creation of the ROHC channel, or when the CID gets associated from the reception of an IR (this does not apply to the IR-DYN) with a different profile than the profile in the context.
CIDは、ROHCチャンネルの作成以来のプロファイルに関連付けられた、またはCIDがIRを受信してから関連があったとき（これはIR-には適用されない場合、コンテキストは、新しいコンテキストであると考えられていますコンテキスト内のプロファイルとは異なるプロファイルを持つDYN）。
Context information is conceptually kept in a table. The context table is indexed using the CID, which is sent along with compressed headers and feedback information.
コンテキスト情報は、概念的に、テーブルに保存されます。コンテキストテーブルは、圧縮されたヘッダーとフィードバック情報と共に送信されるCIDを使用して索引付けされます。
The CID space can be either small, which means that CIDs can take the values 0 through 15, or large, which means that CIDs take values between 0 and 2^14 - 1 = 16383. Whether the CID space is large or small MUST be established, possibly by negotiation, before any compressed packet may be sent over the ROHC channel.
CID空間がなければなりません大きいか小さいか1 = 16383 - CID空間がのCIDがCIDを0および2 ^ 14の間の値をとることを意味し、0から15、または大きなを通しての値をとることができることを意味する、のいずれかで小さくすることができます任意の圧縮されたパケットは、ROHCチャネル上で送信できる前に、可能性交渉により、設立。
The CID space is distinct for each channel, i.e., CID 3 over channel A and CID 3 over channel B do not refer to the same context, even if the endpoints of A and B are the same nodes. In particular, CIDs for any pair of ROHC channels are not related (two associated ROHC channels serving as feedback channels for one another do not even need to have CID spaces of the same size).
CID空間は、AとBのエンドポイントが同じノードであっても、同じコンテキストを参照していないチャネルBの上に、チャネルA及びCID 3上、すなわち、CID 3チャネルごとに異なっています。具体的には、ROHCチャンネルの任意のペアのためのCIDは、（互いにためのフィードバックチャネルとして機能する2つの関連するROHCチャネルがあっても同じサイズのCID空間を持っている必要はない）関連するものではありません。
The ROHC channel is based on a number of parameters that form part of the established channel state and the per-context state. The state of the ROHC channel MUST be established before the first ROHC packet may be sent, which may be achieved using negotiation protocols provided by the link layer (see also [4], which describes an option for negotiation of ROHC parameters for PPP). This section describes some of this channel state information in an abstract way:
ROHCチャネルが確立されたチャネル状態ごとのコンテキスト状態の一部を形成するパラメータの数に基づいています。最初のROHCパケットはリンクレイヤ（PPP用ROHCパラメータのネゴシエーションのためのオプションが記載されている、[4]も参照）によって提供されるネゴシエーションプロトコルを使用して達成することができる、送信することができる前に、ROHCチャネルの状態が確立されなければなりません。このセクションでは、抽象的で、このチャネル状態情報の一部を説明しています。
LARGE_CIDS: Boolean; if false, the small CID representation (0 octets or 1 prefix octet, covering CID 0 to 15) is used; if true, the large CID representation (1 or 2 embedded CID octets covering CID 0 to 16383) is used. See also 5.1.1 and 5.2.1.3.
LARGE_CIDS：ブール。 falseの場合、小CID表現（15 CID 0を覆う0オクテットまたは1つのプレフィックスオクテットは、）が使用されます。 trueの場合、大CID表現（16383にCID 0を覆う1又は2埋め込みCIDオクテット）が使用されます。また、5.1.1と5.2.1.3を参照してください。
MAX_CID: Non-negative integer; highest CID number to be used by the compressor (note that this parameter is not coupled to, but in effect further constrained by, LARGE_CIDS). This value represents an agreement by the decompressor that it can provide sufficient memory resources to host at least MAX_CID+1 contexts; the decompressor MUST maintain established contexts within this space until either the CID gets re-used by the establishment of a new context, or until the channel is taken down.
MAX_CID：非正の整数;圧縮機で使用される最も高いCID数（このパラメータに結合されていないことに注意し、その効果にさらにLARGE_CIDS、によって制約）。この値は、少なくともMAX_CID + 1つのコンテキストをホストするのに十分なメモリ・リソースを提供することができるデコンプレッサによって合意を表します。デコンプレッサは、CIDのいずれかが新しいコンテキストの確立により再利用されるまで、この空間内でコンテキストを確立し維持しなければならない、またはチャネルが降ろされるまで。
PROFILES: Set of non-negative integers, where each integer indicates a profile supported by both the compressor and the decompressor. A profile is identified by a 16-bit value, where the 8 LSB bits indicate the actual profile, and the 8 MSB bits indicate the variant of that profile. The ROHC compressed header format identifies the profile used with only the 8 LSB bits; this means that if multiple variants of the same profile are available for a ROHC channel, the PROFILES set after negotiation MUST NOT include more than one variant of the same profile. The compressor MUST NOT compress using a profile that is not in PROFILES.
プロファイル：各整数圧縮と減圧の両方でサポートされているプロファイルを示す負でない整数のセット。プロファイルは8つのLSBビットが実際のプロファイルを示す16ビットの値によって識別され、8つのMSBビットは、そのプロファイルの変形を示します。 ROHC圧縮ヘッダフォーマットは、8 LSBビットで使用されるプロファイルを識別する。これは、同じプロファイルの複数の変異体がROHCチャンネルのために使用可能である場合、交渉の後に設定のプロファイルが同じプロファイルの複数の変異体を含んではならないことを意味します。コンプレッサーは、プロファイルではないプロファイルを使用して圧縮してはなりません。
FEEDBACK_FOR: Optional reference to a ROHC channel in the opposite direction between the same compression endpoints. If provided, this parameter indicates to which other ROHC channel any feedback sent on this ROHC channel refers (see [5]).
FEEDBACK_FOR：同じ圧縮エンドポイント間の逆方向のROHCチャンネルへのオプション参照。提供される場合、このパラメータは、このROHCチャネル上で送信されたフィードバックが参照する他のROHCチャネル（[5]参照）を示しています。
MRRU: Non-negative integer. Maximum Reconstructed Reception Unit. This is the size of the largest reconstructed unit in octets that the decompressor is expected to reassemble from segments (see Section 5.2.5). This size includes the segmentation CRC. If MRRU
MRRU：負でない整数。最大再構成受信部。これは、デコンプレッサは、セグメント（セクション5.2.5を参照）から再構築することが予想されるオクテットで最大の再構成されたユニットのサイズです。このサイズは、セグメンテーションCRCが含まれています。 MRRUの場合
is negotiated to be 0, segmentation MUST NOT be used on the channel, and received segments MUST be discarded by the decompressor.
0にネゴシエートされ、セグメント化、チャネル上で使用してはいけません、そして受信されたセグメントは、デコンプレッサによって廃棄されなければなりません。
As part of the negotiated channel parameters, the compressor and decompressor have through the MAX_CID parameter agreed on the highest context identification (CID) number to be used. By agreeing on the MAX_CID, the decompressor also agrees to provide memory resources to host at least MAX_CID+1 contexts, and an established context with a CID within this negotiated space SHOULD be kept by the decompressor until either the CID gets re-used, or the channel is taken down or re-negotiated.
ネゴシエートされたチャネルパラメータの一部、圧縮装置と解凍有するMAX_CIDパラメータスルーとして使用する最高コンテキスト識別子（CID）数に合意しました。 MAX_CIDについて合意することによって、解凍装置はまた、少なくともMAX_CID + 1つのコンテキストをホストするためにメモリリソースを提供することに同意、およびCIDのいずれかが再利用されるまで、このネゴシエート空間内のCIDと確立されたコンテキストは、解凍器によって維持されるべきである、またはチャネルは、ダウン取らまたは再交渉されます。
This section uses the following convention in the diagrams when representing various ROHC packet types, formats, and fields:
このセクションでは、様々なROHCパケットタイプ、フォーマット、およびフィールドを表す図で次の規則を使用します。
- colons ":" indicate that the part is optional - slashes "/" indicate variable length
- コロン「：」の部分がオプションであることを示し - スラッシュ「/」可変長を示します
The ROHC packet type indication scheme has been designed to provide optional padding, a feedback packet type, an optional Add-CID octet (which includes 4 bits of CID), and a simple segmentation and reassembly mechanism.
ROHCパケットタイプの表示方式は、オプションのパディング、フィードバックパケットタイプ、オプションの追加CIDオクテット（CIDの4ビットを含む）、および単純セグメンテーションとリアセンブリ機構を提供するように設計されています。
The following packet types are reserved at the ROHC framework level:
次のパケットタイプがROHCフレームワークレベルで予約されています。
11100000 : Padding 1110nnnn : Add-CID octet (nnnn=CID with values 0x1 through 0xF) 11110 : Feedback 11111000 : IR-DYN packet 1111110 : IR packet 1111111 : Segment
11100000：パディング1110nnnn：アドインCIDオクテット（0xFのスルー値は0x1とNNNN = CID）11110：フィードバック11111000：IR-DYNパケット1111110：IRパケット1111111：セグメント
Other packet types can be defined and used by individual profiles:
他のパケットタイプが定義され、個々のプロファイルで使用することができます。
0 : available (not reserved by ROHC framework) 10 : available (not reserved by ROHC framework) 110 : available (not reserved by ROHC framework) 1111101 : available (not reserved by ROHC framework) 11111001 : available (not reserved by ROHC framework)
0：使用可能（ROHCフレームワークによって予約されていない）10：利用可能な（ROHCフレームワークによって予約されていない）110：使用可能な（ROHCフレームワークによって予約されていない）1111101：あり（ROHCフレームワークによって予約されていない）11111001：（ROHCフレームワークによって予約されていない）が利用可能
A ROHC packet has the following general format:
ROHCパケットは、以下の一般的な形式になっています。
--- --- --- --- --- --- --- ---
: Padding :
--- --- --- --- --- --- --- ---
: Feedback :
--- --- --- --- --- --- --- ---
: Header :
--- --- --- --- --- --- --- ---
: Payload :
--- --- --- --- --- --- --- ---
Padding: Any number (zero or more) of padding octets, where the format of a padding octet is as defined in Section 5.2.1.1.
パディング：パディングオクテットのフォーマットは、セクション5.2.1.1で定義されたように、パディングオクテットの任意の数（ゼロ以上）。
Feedback: Any number (zero or more) of feedback elements, where the format of a feedback element is as defined in Section 5.2.4.1.
フィードバック：フィードバック要素のフォーマットは、セクション5.2.4.1で定義されたようにフィードバック要素の任意の数（ゼロ以上）。
Header: Either a profile-specific CO header (see Section 5.2.1.3), an IR or IR-DYN header (see Section 5.2.2), or a ROHC Segment (see Section 5.2.5). There can be at most one Header in a ROHC packet, but it may also be omitted (if the packet contains Feedback only).
ヘッダ：プロファイル固有COヘッダ（セクション5.2.1.3を参照）のいずれか、IRまたはIR-DYNヘッダー（セクション5.2.2参照）、あるいはROHCセグメント（セクション5.2.5を参照）。そこROHCパケットに最大1つのヘッダーでもよいが、（パケットのみフィードバックが含まれている場合）には、省略することも可能です。
Payload: Corresponds to zero or more octets of payload from the uncompressed packet, starting with the first octet in the uncompressed packet after the last header compressible by the current profile.
ペイロードは：現在のプロファイルによって圧縮最後のヘッダの後に圧縮されていないパケットの最初のオクテットから始まる、非圧縮パケットからペイロードのゼロオクテット以上に対応します。
At least one of Feedback or Header MUST be present.
フィードバックやヘッダの少なくとも一方が存在しなければなりません。
Padding octet:
パディングオクテット：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 0 0 0 0 |
+---+---+---+---+---+---+---+---+
Note: The Padding octet MUST NOT be interpreted as an Add-CID octet for CID 0.
注：パディングオクテットはCID 0のAdd-CIDのオクテットと解釈してはなりません。
Add-CID octet:
オクテット-CIDを追加します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | CID |
+---+---+---+---+---+---+---+---+
CID: 0x1 through 0xF indicates CIDs 1 through 15.
CID：0xFの通じ0x1のは、CIDを1〜15を示しています。
Note: The Padding octet looks like an Add-CID octet for CID 0.
注意：パディングオクテットはCID 0のAdd-CIDオクテットのように見えます。
All ROHC packet types have the following general Header format:
すべてのROHCパケットタイプは、以下の一般的なヘッダーの形式を持っています。
0 x-1 x 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if CID 1-15 and small CIDs
+--- --- --- --- ---+--- --- ---+
| type indication | body | 1 octet (8-x bits of body)
+--- --- --- --- ---+--- --- ---+
: :
/ 0, 1, or 2 octets of CID / 1 or 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
/ body / variable length
+---+---+---+---+---+---+---+---+
type indication: ROHC packet type.
タイプ表示：ROHCパケットタイプ。
body: Interpreted according to the packet type indication and CID information, as defined by individual profiles.
本体：個々のプロファイルによって定義されるように、パケットタイプの指示とCID情報に従って解釈。
Thus, the header either starts with a packet type indication or has a packet type indication immediately following an Add-CID octet.
したがって、ヘッダはパケットタイプの指示で開始または直ちにアドインCIDオクテット以下のパケットタイプの指示を有するいずれか。
When the ROHC channel is configured with a small CID space:
ROHCチャンネルは、小さなCIDスペースで構成されている場合：
o If an Add-CID immediately precedes the packet type indication, the packet has the CID of the Add-CID; otherwise, it has CID 0.
アドインCIDはすぐにパケットタイプ指示を先行した場合は、O、パケットは、Add-CIDのCIDを持っています。それ以外の場合は、CID 0を持っています。
o A small CID with the value 0 is represented using zero bits; therefore, a flow associated with CID 0 has no CID overhead in the compressed header. In such case, Header starts with a packet type indication.
O値0を持つ小さなCIDは、ゼロのビットを用いて表現されます。従って、CID 0に関連付けられたフローは、圧縮されたヘッダーにはCIDのオーバーヘッドを有していません。このような場合、ヘッダはパケットタイプの指示で始まります。
o A small CID with a value from 1 to 15 is represented using the Add-CID octet as described above. The Header starts with the Add-CID octet, followed by a packet type indication.
上記のようにO 1から15までの値を有する小さいCIDは、アドインCIDのオクテットを使用して表されています。ヘッダーは、パケットタイプ指示に続くアドオンCIDのオクテットで始まります。
o There is no large CID in the Header.
Oヘッダには大きなCIDはありません。
When the ROHC channel is configured with a large CID space:
ROHCチャンネルは、大きなCIDスペースで構成されている場合：
o The large CID is always present and is represented using the encoding scheme of Section 5.3.2, limited to two octets. In this case, the Header starts with a packet type indication.
O大CIDは常に存在し、2つのオクテットに限定されるもので、セクション5.3.2の符号化方式を使用して表されます。この場合、ヘッダはパケットタイプの指示で始まります。
IR packet types contain a profile identifier, which determines how the rest of the header is to be interpreted. They also associate a profile with a context. The stored profile parameter further determines the syntax and semantics of the packet type identifiers and packet types used with a specific context.
IRパケットタイプは、ヘッダの残りを解釈する方法を決定するプロファイル識別子を含みます。彼らはまた、コンテキストにプロファイルを関連付けます。保存されたプロファイルパラメータは、さらに、特定のコンテキストで使用されるパケットタイプ識別子とパケットタイプの構文及びセマンティクスを決定します。
The IR and IR-DYN packets always update the context for all context-updating fields carried in the header. They never clear the context, except when initializing a new context (see Section 5.1.1), or unless the profile indicated in the Profile field specifies otherwise.
IR及びIR-DYNパケットは、常にヘッダで運ばれるすべてのコンテキスト更新フィールドのコンテキストを更新します。彼らは、新しいコンテキスト（セクション5.1.1を参照）を初期化する場合を除いて、コンテキストをクリアしたことがない、またはプロファイルフィールドに示さプロファイルは、別の方法で指定しない限り。
The IR header associates a CID with a profile, and typically also initializes the context. It can typically also refresh all (or parts of) the context. For IR, Header has the following general format:
IRヘッダは、プロファイルとCIDを関連付け、そして典型的には、コンテキストを初期化します。それはまた、典型的には、すべての（または一部の）コンテキストを更新することができます。 IRのために、ヘッダは、以下の一般的な形式になっています。
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if CID 1-15 and small CID
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 | x | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1 or 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ profile specific information / variable length
| |
+---+---+---+---+---+---+---+---+
x: Profile specific information. Interpreted according to the profile indicated in the Profile field of the IR header.
X：特定の情報のプロファイルを作成します。 IRヘッダのプロファイルフィールドに示されたプロファイルに従って解釈。
Profile: The profile associated with the CID. In the IR header, the profile identifier is abbreviated to the 8 least significant bits (see Section 5.1.2).
プロフィール：CIDに関連付けられたプロファイル。 IRヘッダに、プロファイル識別子は、8つの最下位ビット（セクション5.1.2を参照）と略記します。
CRC: 8-bit CRC (see Section 5.3.1.1).
CRC：8ビットのCRC（5.3.1.1項を参照してください）。
Profile specific information: The content of this part of the IR header is defined by the individual profiles. It is interpreted according to the profile indicated in the Profile field.
特定の情報をプロフィール：IRヘッダのこの部分の内容は、個々のプロファイルによって定義されます。これは、プロファイルフィールドに示されたプロファイルに従って解釈されます。
In contrast to the IR header, the IR-DYN header can never initialize a non-initialized context. However, it can redefine what profile is associated with a context, if the profile indicated in the IR-DYN header allows this. Thus, this packet type is also reserved at the framework level. The IR-DYN header typically also initializes or refreshes parts of a context. For IR-DYN, Header has the following general format:
IRヘッダとは対照的に、IR-DYNヘッダーは非初期化コンテキストを初期化することはできません。しかし、IR-DYNヘッダーに示されたプロファイルがこれを許可している場合、コンテキストに関連付けられているもののプロファイルを再定義することができます。したがって、このパケットタイプは、フレームワーク・レベルで予約されています。 IR-DYNヘッダーは、典型的には、初期化またはコンテキストの部分をリフレッシュ。 IR-DYNの場合、ヘッダーには、以下の一般的な形式があります。
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if CID 1-15 and small CID
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 0 0 | IR-DYN type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1 or 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ profile specific information / variable length
| |
+---+---+---+---+---+---+---+---+
Profile: The profile associated with the CID. This is abbreviated in the same way as in IR packets.
プロフィール：CIDに関連付けられたプロファイル。これは、IRパケットと同様に省略されます。
CRC: 8-bit CRC (see Section 5.3.1.1).
CRC：8ビットのCRC（5.3.1.1項を参照してください）。
Profile specific information: The content of this part of the IR-DYN header is defined by the individual profiles. It is interpreted according to the profile indicated in the Profile field.
特定の情報をプロフィール：IR-DYNヘッダーのこの部分の内容は、個々のプロファイルによって定義されます。これは、プロファイルフィールドに示されたプロファイルに従って解釈されます。
Initially, all contexts are in no context state. Thus, all packets referencing a non-initialized context, except packets that have enough information on the static fields, cannot be decompressed by the decompressor.
最初は、すべてのコンテキストではありませんコンテキスト状態です。このように、静的フィールドの十分な情報を持っているパケットを除いて、非初期化されたコンテキストを参照するすべてのパケットは、デコンプレッサにより解凍することはできません。
When the decompressor receives a packet of type IR, the profile indicated in the IR packet determines how it is to be processed.
減圧装置が型IRのパケットを受信した場合、IRパケットに示されたプロファイルは、それが処理される方法を決定します。
o If the 8-bit CRC fails to verify the integrity of the Header, the packet MUST NOT be decompressed and delivered to upper layers. If a profile is indicated in the context, the logic of that profile determines what, if any, feedback is to be sent. If no profile is noted in the context, the logic used to determine what, if any, feedback to send is up to the implementation. However, it may be suitable to take no further actions, as any part of the IR header covered by the CRC may have caused the failure.
8ビットのCRCは、ヘッダの整合性を検証するために失敗した場合、O、パケットが解凍され、上位層に配信されてはなりません。プロファイルは文脈に示されている場合、そのプロファイルのロジックがある場合、フィードバックが送信されるもの、を判定する。プロファイルが文脈に注意されていない場合はロジックがあれば、何を決定するために使用する、送信するためのフィードバックは実装次第です。しかし、CRCによって覆わIRヘッダのいずれかの部分が故障の原因となったかもしれないように、さらなるアクションを取らないために適切であり得ます。
When the decompressor receives a packet of type IR-DYN, the profile indicated in the IR-DYN packet determines how it is to be processed.
減圧装置がタイプIR-DYNパケットを受信すると、IR-DYNパケットに示されたプロファイルは、それが処理される方法を決定します。
o If the 8-bit CRC fails to verify the integrity of the header, the packet MUST NOT be decompressed and delivered to upper layers. If a profile is indicated in the context, the logic of that profile determines what, if any, feedback is to be sent. If no profile is noted in the context, the logic used to determine what, if any, feedback to send is up to the implementation. However, it may be suitable to take no further actions, as any part of the IR-DYN header covered by the CRC may have caused the failure.
8ビットCRCは、ヘッダの完全性を検証するために失敗した場合はO、パケットは、解凍及び上位層に配信されてはいけません。プロファイルは文脈に示されている場合、そのプロファイルのロジックがある場合、フィードバックが送信されるもの、を判定する。プロファイルが文脈に注意されていない場合はロジックがあれば、何を決定するために使用する、送信するためのフィードバックは実装次第です。 CRCによって覆わIR-DYNヘッダーのいずれかの部分が故障の原因となったかもしれないしかし、さらなるアクションを取らないために適切であり得ます。
o If the context has not already been initialized, the packet MUST NOT be decompressed and delivered to upper layers. The logic of the profile indicated in the IR-DYN header (if verified by the 8-bit CRC), determines what, if any, feedback is to be sent.
コンテキストが既に初期化されていない場合は、O、パケットが解凍され、上位層に配信されてはなりません。 （8ビットのCRCにより確認した場合）IR-DYNヘッダーに示されたプロファイルのロジックがある場合、フィードバックが送信されるもの、を判定する。
If a parsing error occurs for any packet type, the decompressor MUST discard the packet without further processing. For example, a CID field is present in the compressed header when the large CID space is used for the ROHC channel, and the field is coded using the self-describing variable-length encoding of Section 5.3.2; if the field starts with 110 or 111, this would generate a parsing error for the decompressor because this field must not be encoded with a size larger than 2 octets.
解析エラーが任意のパケットタイプのために発生した場合、デコンプレッサは、さらなる処理なしでパケットを捨てなければなりません。大CID空間がROHCチャネルに使用され、フィールドは、セクション5.3.2の自己記述型可変長符号化を用いて符号化される場合、例えば、CIDフィールドは、圧縮されたヘッダー内に存在します。フィールド110または111で始まる場合、このフィールドは、2つのオクテットよりも大きいサイズで符号化されてはならないので、これは減圧装置のための解析エラーを生成します。
It is RECOMMENDED that profiles disallow the decompressor to make a decompression attempt for packets carrying only a 3-bit CRC after it has invalidated some or all of the entire dynamic context, until a packet that contains sufficient information on the dynamic fields is received, decompressed, and successfully verified by a 7- or 8-bit CRC.
減圧、プロファイルは動的フィールドの十分な情報を含むパケットを受信するまで、それは、全体の動的コンテキストの一部またはすべてを無効にした後にのみ、3ビットのCRCを運ぶパケットの解凍試行を行うために減圧装置を許可しないことが推奨されます、および正常7-または8-ビットCRCにより確認。
Feedback carries information from the decompressor to compressor. Feedback can be sent over a ROHC channel that operates in the same direction as the feedback.
フィードバックは、圧縮機に減圧装置からの情報を運びます。フィードバックは、フィードバックと同じ方向に動作ROHCチャネルを介して送信することができます。
The general ROHC packet format allows transport of feedback using interspersion or piggybacking (see [5]), or a combination of both, over a ROHC channel. This is facilitated by the following properties:
一般的なROHCパケットフォーマットは、ROHCチャネルを介して、（[5]参照）フィードバックの輸送が散在を使用するか、ピギーバックでき、または両方の組み合わせ。これは、次のプロパティによって促進されます。
Reserved packet type:
予約パケットタイプ：
A feedback packet type is reserved at the framework level. The packet type can carry variable-length feedback information.
フィードバックパケットタイプは、フレームワーク・レベルで予約されています。パケットタイプは、可変長のフィードバック情報を運ぶことができます。
CID information:
CID情報：
The feedback information sent on a particular channel is passed to, and interpreted by, the compressor associated with feedback on that channel. Thus, each feedback element contains CID information from the channel for which the feedback is sent. The ROHC feedback scheme thus requires that a channel carries feedback to at most one compressor. How a compressor is associated with the feedback for a particular channel is outside the scope of this specification. See also [5].
特定のチャネル上で送信されるフィードバック情報は、そのチャネル上のフィードバックに関連付けられている圧縮機に渡され、によって解釈されます。従って、各フィードバック要素は、フィードバックが送信されたチャネルからCID情報を含みます。 ROHCフィードバック方式は、このように、チャネルは最大1つの圧縮機にフィードバックを運ぶことを必要とします。圧縮機が特定のチャネルのためのフィードバックと関連している方法を本明細書の範囲外です。 [5]も参照してください。
Length information:
Length情報：
The length of a feedback element can be determined by examining the first few octets of the feedback. This enables piggybacking of feedback, and also the concatenation of more than one feedback element in a packet. The length information thus decouples the decompressor from the associated same-side compressor, as the decompressor can extract the feedback information from the compressed header without parsing its content and hand over the extracted information.
フィードバック素子の長さは、フィードバックの最初のいくつかのオクテットを調べることによって決定することができます。これは、フィードバックのピギーバック、及び、パケットに複数のフィードバック要素の連結を可能にします。減圧装置が抽出された情報の上に、その内容と手を解析することなく、圧縮されたヘッダからのフィードバック情報を抽出することができるように長さの情報は、このように、関連する同じ側の圧縮機からの減圧装置を切り離します。
The association between compressor-decompressor pairs operating in opposite directions, for the purpose of exchanging piggyback and/or interspersed feedback, SHOULD be maintained for the lifetime of the ROHC channel. Otherwise, it is RECOMMENDED that the compressor be notified if the feedback channel is no longer available: the compressor SHOULD then restart compression by creating a new context for each packet flow, and SHOULD use a CID value that was not previously associated with the profile used to compress the flow.
反対方向に動作する圧縮伸長ペア間の関連付けは、ピギーバックおよび/または散在フィードバックを交換するために、ROHCチャンネルの寿命のために維持されるべきです。圧縮機は、各パケットフローのための新しいコンテキストを作成して圧縮を再起動する必要があり、以前に使用されたプロファイルに関連付けられていなかったCID値を使用する必要があります。それ以外の場合は、圧縮機がフィードバックチャネルが使用できなくなった場合に通知されないことが推奨されます流れを圧縮します。
ROHC defines three different categories of feedback messages: acknowledgment (ACK), negative ACK (NACK), and NACK for the entire context (STATIC-NACK). Other types of information may be defined in profile-specific feedback information.
肯定応答（ACK）、否定的ACK（NACK）、及び全体のコンテキストのためのNACK（STATIC-NACK）：ROHCフィードバックメッセージの3つのカテゴリを定義します。他のタイプの情報は、プロファイル固有のフィードバック情報に定義されてもよいです。
ACK : Acknowledges successful decompression of a packet. Indicates that the decompressor considers its context to be valid.
ACKは：パケットの解凍の成功を認めています。デコンプレッサは、そのコンテキストが有効であると考えていることを示します。
NACK : Indicates that the decompressor considers some or all of the dynamic part of its context invalid.
NACKは：解凍器が無効にその文脈のダイナミックな部分の一部または全てを考慮していることを示します。
STATIC-NACK : Indicates that the decompressor considers its entire static context invalid, or that it has not been established.
STATIC-NACK：デコンプレッサが無効全体の静的文脈を考慮し、またはそれが確立されていないことをことを示します。
Feedback sent on a ROHC channel consists of one or more concatenated feedback elements, where each feedback element has the following format:
ROHCチャネル上で送信されたフィードバックは、各フィードバック要素には、以下のフォーマットを有する一つまたはそれ以上の連結フィードバック要素からなります：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | Code | feedback type
+---+---+---+---+---+---+---+---+
: Size : if Code = 0
+---+---+---+---+---+---+---+---+
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
: :
/ large CID (5.3.2 encoding) / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
/ FEEDBACK data / variable length
+---+---+---+---+---+---+---+---+
Code: 0 indicates that a Size octet is present. 1-7 indicates the size of the feedback data field, in octets.
コード：0サイズオクテットが存在することを示します。 1-7はオクテットで、フィードバックデータフィールドのサイズを示します。
Size: Indicates the size of the feedback data field, in octets.
サイズ：オクテットで、フィードバックデータフィールドのサイズを示します。
FEEDBACK data: FEEDBACK-1 or FEEDBACK-2 (see below).
フィードバックデータ：FEEDBACK-1又はFEEDBACK-2（下記参照）。
CID information in a feedback element indicates the context for which feedback is sent. The LARGE_CIDS parameter that controls whether a large CID is present is taken from the channel state of the receiving compressor's channel, not from the state of the channel carrying the feedback.
フィードバック素子におけるCID情報は、フィードバックが送信されたコンテキストを示します。大CIDが存在するかどうかを制御LARGE_CIDSパラメータがないフィードバックを搬送するチャネルの状態から、受信圧縮機のチャネルのチャネル状態から取られます。
The large CID field, if present, is encoded according to Section 5.3.2, and it MUST NOT be encoded using more than 2 octets.
大CIDフィールドは、存在する場合、第5.3.2節に従って符号化され、それは2つの以上のオクテットを使用して符号化されてはいけません。
The FEEDBACK data field can have either of the following two formats:
フィードバックデータ・フィールドは、次の2つの形式のいずれかを持つことができます。
FEEDBACK-1:
FEEDBACK-1：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| profile specific information | 1 octet
+---+---+---+---+---+---+---+---+
FEEDBACK-2:
FEEDBACK-2：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| |
+---+---+ profile specific / at least 2 octets
/ information |
+---+---+---+---+---+---+---+---+
Acktype: 0 = ACK 1 = NACK 2 = STATIC-NACK 3 is reserved (MUST NOT be used. Otherwise unparseable.)
Acktype：0 = ACK 1 = NACK 2 = STATIC-NACK 3に予約されている（そうでなければ解析できない使用してはいけません。）。
ROHC defines a simple segmentation protocol. The compressor may perform segmentation, e.g., to accommodate packets that are larger than a specific size configured for the channel.
ROHCは、単純なセグメント化プロトコルを定義しています。圧縮機は、チャネルのために設定特定のサイズより大きいパケットを収容するために、例えば、セグメント化を実行することができます。
The ROHC segmentation protocol is not particularly efficient. It is not intended to replace link layer segmentation functions; these SHOULD be used whenever available and efficient for the task at hand.
ROHC分割プロトコルは特に効率的ではありません。リンク層のセグメンテーション機能に代わるものではありません。これらは、当面の作業のためにいつでも利用でき、効率的な使用されるべきです。
The ROHC segmentation protocol has been designed with an assumption of in-order delivery of packets between the compressor and the decompressor, using only a CRC for error detection, and no sequence numbers. If in-order delivery cannot be guaranteed, ROHC segmentation MUST NOT be used.
ROHC分割プロトコルは、エラー検出、及び無シーケンス番号についてのみCRCを使用して、コンプレッサとデコンプレッサとの間のパケットの順序配信を想定して設計されています。順序どおりの配信が保証できない場合は、ROHCのセグメンテーションを使用してはいけません。
The segmentation protocol also assumes that all segments of a ROHC packet corresponding to one context are received without interference from other ROHC packets over the channel, including any ROHC packet corresponding to a different context. Based on this assumption, segments do not carry CID information, and therefore cannot be associated with a specific context until all segments have been received and the whole unit has been reconstructed.
セグメンテーション・プロトコルは、あるコンテキストに対応ROHCパケットのすべてのセグメントが異なるコンテキストに対応する任意のROHCパケットを含むチャネルを介して他のROHCパケットからの干渉なしに受信されることを前提としています。この仮定に基づいて、セグメントはCID情報を搬送せず、したがってすべてのセグメントが受信され、ユニット全体が再構築されるまで、特定のコンテキストに関連付けることができません。
ROHC segmentation is applied to the combination of the Header and the Payload fields of the ROHC packet, as defined in Section 5.2.1.
5.2.1項で定義されるようにROHC分割は、ヘッダ及びROHCパケットのペイロードフィールドの組み合わせに適用されます。
Segment format:
セグメント形式：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 1 | F | segment type
+---+---+---+---+---+---+---+---+
/ Segment / variable length
+---+---+---+---+---+---+---+---+
F: Final bit. If set, it indicates that this is the last segment of a reconstructed unit.
F：最終ビット。設定した場合、これは、再構成ユニットの最後のセグメントであることを示しています。
Padding and/or Feedback may precede the segment type octet. There is no per-segment CID, but CID information is of course part of the reconstructed unit. The reconstructed unit MUST NOT contain padding, segments, or feedback.
パディング及び/又はフィードバックセグメントタイプオクテットに先行してもよいです。そこにはごとのセグメントCIDはないが、CID情報は、再生単位のコースの一部です。再構成ユニットは、パディング、セグメント、またはフィードバックを含んではなりません。
When a final segment is received, the decompressor reassembles the segment carried in this packet and any non-final segments that immediately preceded it into a single reconstructed unit, in the order they were received. All segments for one reconstructed unit have to be received consecutively and in the correct order by the decompressor. If a non-segment ROHC packet directly follows a non-final segment, the reassembly of the current reconstructed unit is aborted and the decompressor MUST discard the non-final segments so far received on this channel.
最終セグメントが受信されると、減圧装置はこのパケットで運ばれたセグメントとすぐに、それらが受信された順に、単一の再構成ユニットにそれを先行任意の非最終セグメントを再構築します。 1つの再構成されたユニットのすべてのセグメントが連続と減圧によって正しい順序で受信されなければなりません。非セグメントROHCパケットを直接非最終セグメントに続く場合は、現在の再構成されたユニットの再組み立てが中止され、減圧装置は、これまで、このチャネル上で受信した非最終セグメントを捨てなければなりません。
Reconstructed unit:
再構成された単位：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
/ Header / (see Section 5.2.1)
+---+---+---+---+---+---+---+---+
: Payload : (see Section 5.2.1)
+---+---+---+---+---+---+---+---+
/ CRC / 4 octets
+---+---+---+---+---+---+---+---+
CRC: 32-bit CRC computed using the polynomial of Section 5.3.1.4.
CRC：32ビットCRCは、セクション5.3.1.4の多項式を用いて計算しました。
If the reconstructed unit is 4 octets or less, or if the CRC fails, or if it is larger than the channel parameter MRRU (see Section
再構成ユニットは、4つのオクテット以下である場合、またはCRCが失敗した場合、またはそれがチャネルパラメータMRRUより大きい場合（節を参照します
5.1.2), the reconstructed unit MUST be discarded by the decompressor. If the CRC succeeds, the reconstructed unit can be further processed.
5.1.2）、再構築されたユニットは、解凍装置によって廃棄されなければなりません。 CRCが成功した場合、再構成ユニットは、さらに処理することができます。
This section describes how to calculate the CRCs used by ROHC. For all CRCs, the algorithm used to calculate the CRC is the same as the one used in [2], defined in Appendix A of this document, with the polynomials specified in subsequent sections.
このセクションでは、ROHCが使用するCRCを計算する方法について説明します。全てのCRCは、CRCを計算するために使用されるアルゴリズムは、次のセクションで指定された多項式を用いて、この文書の付録Aで定義される[2]で使用したものと同じです。
The coverage for the 8-bit CRC in the IR and IR-DYN headers is profile-dependent, but it MUST cover at least the initial part of the header ending with the Profile field, including the CID or an Add-CID octet. Feedback and padding are not part of Header (Section 5.2.1) and are thus not included in the CRC calculation. As a rule of thumb for profile specifications, any other information that initializes the decompressor context SHOULD also be covered by a CRC.
IR及びIR-DYNヘッダーの8ビットのCRCの適用範囲は、プロファイルに依存しており、それは、CIDまたはアドインCIDオクテットを含むプロファイルフィールドで終わるヘッダの少なくとも最初の部分をカバーしなければなりません。フィードバック及びパディングは、ヘッダ（セクション5.2.1）の一部ではないので、CRC計算に含まれません。プロファイル仕様の経験則として、伸張器コンテキストを初期化する任意の他の情報もCRCによってカバーされるべきです。
More specifically, the 8-bit CRC does not cover only and entirely the original uncompressed header; therefore, it does not provide the means for the decompressor to verify a decompression attempt, or the means to verify the correctness of the entire decompressor context. However, when successful, it does provide enough robustness for the decompressor to update its context with the information carried within the IR or the IR-DYN header.
より具体的には、8ビットCRCだけと完全に元の非圧縮ヘッダを覆っていません。従って、それは減圧試み、または全解凍器のコンテキストの正当性を検証する手段を確認するための減圧装置のための手段を提供しません。しかし、成功した場合、それは減圧装置がIRまたはIR-DYNヘッダー内で搬送される情報とそのコンテキストを更新するための十分な堅牢性を提供しません。
The CRC polynomial for the 8-bit CRC is:
8ビットのCRCのためのCRC多項式です。
C(x) = 1 + x + x^2 + x^8
C（x）= 1 + X + X ^ 2 + X ^ 8
When computing the CRC, the CRC field in the header is set to zero, and the initial content of the CRC register is set to all 1's.
CRCを計算するとき、ヘッダ内のCRCフィールドはゼロに設定され、CRCレジスタの初期の内容はすべて1に設定されています。
The 3-bit CRC in compressed headers is calculated over all octets of the entire original header, before compression, in the following manner.
圧縮されたヘッダーの3ビットのCRCは、以下のように、圧縮前に、全体のオリジナルヘッダの全てのオクテットにわたって計算されます。
The initial content of the CRC register is set to all 1's.
CRCレジスタの初期の内容は、すべて1年代に設定されています。
The polynomial for the 3-bit CRC is:
3ビットのCRC多項式です。
C(x) = 1 + x + x^3
C（x）= 1 + X + X ^ 3
The purpose of the 3-bit CRC is to provide the means for the decompressor to verify the outcome of a decompression attempt for small compressed headers, and to detect context damage based on aggregated probability over a number of decompression attempts. It is however too weak to provide enough success guarantees from the decompression of one single header. Therefore, compressed headers carrying a 3-bit CRC are normally not suitable to perform context repairs at the decompressor; hence, profiles should refrain from allowing decompression of such a header when some or the entire decompressor context is assumed invalid.
3ビットのCRCの目的は、デコンプレッサ小さな圧縮ヘッダの解凍試行の結果を確認するため、そして減圧試行回数にわたって集約確率に基づいて、コンテキストの損傷を検出するための手段を提供することです。 1つのヘッダの解凍から十分な成功の保証を提供することが弱すぎます。したがって、3ビットのCRCを運ぶ圧縮ヘッダは、通常減圧装置で文脈修理を行うのに適していません。したがって、プロファイルは、一部または全体デコンプレッサコンテキストが無効としたとき、このようなヘッダの解凍を可能に控えるべきです。
The 7-bit CRC in compressed headers is calculated over all octets of the entire original header, before compression, in the following manner.
圧縮されたヘッダーの7ビットのCRCは、以下のように、圧縮前に、全体のオリジナルヘッダの全てのオクテットにわたって計算されます。
The initial content of the CRC register is set to all 1's.
CRCレジスタの初期の内容は、すべて1年代に設定されています。
The polynomial for the 7-bit CRC is:
7ビットのCRC多項式です。
C(x) = 1 + x + x^2 + x^3 + x^6 + x^7
C（x）= 1 + X + X ^ 2 + X ^ 3 + X ^ 6 + X ^ 7
The purpose of the 7-bit CRC is to provide the means for the decompressor to verify the outcome of a decompression attempt for a larger compressed header, and to provide enough protection to validate a context repair at the decompressor. The 7-bit CRC is strong enough to assume a repair to be successful from the decompression of one single header; hence, profiles may allow decompression of a header carrying a 7-bit CRC when some of the decompressor context is assumed invalid.
7ビットのCRCの目的は、デコンプレッサ大きな圧縮ヘッダの解凍試行の結果を確認するため、及び減圧装置におけるコンテキストの修復を検証するための十分な保護を提供するための手段を提供することです。 7ビットのCRCは、単一のヘッダの解凍から成功するために修復を想定するのに十分強力です。伸張器コンテキストの一部を無効とした場合、したがって、プロファイルは、7ビットのCRCを運ぶヘッダの解凍を可能にすることができます。
The 32-bit CRC is used by the segmentation scheme to verify the reconstructed unit, and it is thus calculated over the segmented unit, i.e., over the Header and the Payload fields of the ROHC packet.
32ビットCRCは、再構成ユニットを確認するために分割方式で使用され、それは、このようにヘッダーとROHCパケットのペイロードフィールドの上、すなわち、セグメント化ユニットに対して計算されます。
The initial content of the CRC register is set to all 1's.
CRCレジスタの初期の内容は、すべて1年代に設定されています。
The polynomial for the 32-bit CRC is:
32ビットのCRC多項式です。
C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32.
C（X）= X ^ 0 + X ^ 1 + X ^ 2 + X ^ 4 + X ^ 5 + X ^ 7 + X ^ 8 + X ^ 10 + X ^ 11 + X ^ 12 + X ^ 16 + X ^ 22 + X ^ 23 + X ^ 26 + X ^ 32。
The purpose of the 32-bit CRC is to verify the reconstructed unit.
32ビットCRCの目的は、再構成されたユニットを確認することです。
The values of many fields and compression parameters can vary widely. To optimize the transfer of such values, a variable number of octets are used to encode them. The first few bits of the first octet determine the number of octets used:
多くの分野と圧縮パラメータの値は、広く変えることができます。このような値の転送を最適化するために、オクテットの可変数は、それらをエンコードするために使用されます。最初のオクテットの最初の数ビットを使用オクテットの数を決定します。
First bit is 0: 1 octet. 7 bits transferred. Up to 127 decimal. Encoded octets in hexadecimal: 00 to 7F
1オクテット：最初のビットは0です。 7ビットが転送されます。 127小数点以下まで。 16進数でエンコードされたオクテット：00 7Fへ
First bits are 10: 2 octets. 14 bits transferred. Up to 16 383 decimal. Encoded octets in hexadecimal: 80 00 to BF FF
2オクテット：最初のビットは10です。 14ビットが転送されます。 16 383小数点以下まで。 16進数で符号化されたオクテット：BF FF 80〜00
First bits are 110: 3 octets. 21 bits transferred. Up to 2 097 151 decimal. Encoded octets in hexadecimal: C0 00 00 to DF FF FF
3オクテット：最初のビットが110です。 21ビットが転送されます。 2 097 151小数点以下まで。 16進数でエンコードされたオクテット：C0 00 00 DF FF FFへ
First bits are 111: 4 octets. 29 bits transferred. Up to 536 870 911 decimal. Encoded octets in hexadecimal: E0 00 00 00 to FF FF FF FF
4オクテット：最初のビットが111です。 29ビットが転送されます。 536 870 911小数点以下まで。 16進数でエンコードされたオクテット：E0 00 00 00 FF FF FF FFへ
This section describes the uncompressed ROHC profile. The profile identifier for this profile is 0x0000.
このセクションでは、非圧縮のROHCプロファイルを記述する。このプロファイルのプロファイルIDは0000です。
Profile 0x0000 provides a way to send IP packets without compressing them. This can be used for any packet for which a compression profile is not available in the set of profiles supported by the ROHC channel, or for which compression is not desirable for some reason.
プロファイル0000は、それらを圧縮せずにIPパケットを送信する方法を提供します。これは、圧縮プロファイルは、圧縮が何らかの理由で望ましくない、またはそのためROHCチャネルによってサポートされるプロファイルのセットで利用できるされていない任意のパケットのために使用することができます。
After initialization, the only overhead for sending packets using Profile 0x0000 is the size of the CID. When uncompressed packets are frequent, Profile 0x0000 should be associated with a CID the size of zero or one octet. Profile 0x0000 SHOULD be associated with at most one CID.
初期化後、プロファイル0000を使用してパケットを送信するための唯一のオーバーヘッドは、CIDのサイズです。圧縮されていないパケットが頻繁である場合、プロファイル0000は、CID 0または1オクテットのサイズに関連付けされるべきです。プロファイル0000は、最大1つのCIDに関連付けられている必要があり。
The initialization and refresh packet (IR packet) for Profile 0x0000 has the following Header format:
プロファイル0000の初期化およびリフレッシュパケット（IRパケット）は、以下のヘッダーフォーマットを有します。
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 |res|
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile = 0x00 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
res: MUST be set to zero; otherwise, the decompressor MUST discard the packet.
resがゼロに設定しなければなりません。そうでない場合、デコンプレッサはパケットを捨てなければなりません。
Profile: 0x00
プロフィール：$ 00
CRC: 8-bit CRC, computed using the polynomial of Section 5.3.1.1. The CRC covers the first octet of the IR Header through the Profile octet of the IR Header, i.e., it does not cover the CRC itself. Neither does it cover any preceding Padding or Feedback, nor the Payload.
CRC：8ビットCRCは、セクション5.3.1.1の多項式を用いて計算しました。 CRCは、IRヘッダのプロファイルオクテットを介してIRヘッダの最初のオクテットをカバーする、すなわち、それはCRC自体を覆っていません。どちらも、それはいずれかパディングやフィードバック、またペイロードをカバーしていないん。
For the IR packet, Payload has the following format:
IRパケットの場合、ペイロードの形式は次のとおりです。
--- --- --- --- --- --- --- ---
: : (optional)
/ IP packet / variable length
: :
--- --- --- --- --- --- --- ---
IP packet: An uncompressed IP packet may be included in the IR packet. The decompressor determines if the IP packet is present by considering the length of the IR packet.
IPパケット：非圧縮IPパケットがIRパケットに含まれていてもよいです。 IPパケットがIRパケットの長さを考慮して存在する場合には、デコンプレッサを判定する。
A Normal packet is a normal IP packet plus CID information. For the Normal Packet, the following format corresponds to the Header and Payload (as defined in Section 5.2.1):
通常のパケットは通常のIPパケットプラスCID情報です。通常のパケットのために、以下の形式は、ヘッダとペイロード（セクション5.2.1で定義されている）に対応します：
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| first octet of IP packet |
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| |
/ rest of IP packet / variable length
| |
+---+---+---+---+---+---+---+---+
Note that the first octet of the IP packet starts with the bit pattern 0100 (IPv4) or 0110 (IPv6). This does not conflict with any reserved packet types.
IPパケットの最初のオクテットは、ビットパターン0100（IPv4の）または0110（IPv6）の始まることに留意されたいです。これは、任意の予約パケットタイプと競合しません。
When the channel uses small CIDs, and profile 0x0000 is associated with a CID > 0, an Add-CID octet precedes the IP packet. When the channel uses large CIDs, the CID is placed so that it starts at the second octet of the combined Header/Payload format above.
チャンネルは小さなCIDを使用し、プロファイルは0x0000がCID> 0に関連付けられている場合、アドインCIDのオクテットは、IPパケットに先行します。チャネルが大きいCIDを使用する場合、それは上記の組み合わせヘッダ/ペイロードフォーマットの第2オクテットから始まるように、CIDが配置されています。
A Normal Packet may carry Padding and/or Feedback as any other ROHC packet, preceding the combined Header/Payload.
通常のパケットは、結合ヘッダー/ペイロードの前に、任意の他のROHCパケットとしてパディング及び/又はフィードバックを搬送することができます。
When an IR packet is received, the decompressor first validates its header using the 8-bit CRC.
IRパケットを受信したときに、減圧装置は、最初の8ビットのCRCを使用してヘッダを検証します。
o If the header fails validation, the decompressor MUST NOT deliver the IP packet to upper layers.
ヘッダが検証に失敗した場合は、O、デコンプレッサは、上位層にIPパケットを配信してはいけません。
o If the header is successfully validated, the decompressor
Oヘッダが正常に検証されている場合、デコンプレッサ
1) initializes the context if it has no valid context for the
given CID already associated to the specified profile,
2) delivers the IP packet to upper layers if present,
存在する場合2）、上位層にIPパケットを送出します
3) MAY send an ACK.
3）ACKを送信することができます。
When any other packet is received while the decompressor has no context, it is discarded without further action.
減圧装置がないコンテキストを持っていないときに任意の他のパケットを受信した場合、それがさらに作用することなく廃棄されます。
When a Normal packet is received and the decompressor has a valid context, the IP packet is extracted and delivered to upper layers.
通常のパケットを受信し、減圧装置が有効なコンテキストを有している場合、IPパケットを抽出し、上位レイヤに送達されます。
The only kind of feedback defined by Profile 0x0000 is ACK, using the FEEDBACK-1 format of Section 5.2.4.1, where the value of the profile-specific octet in the FEEDBACK-1 is 0 (zero). The FEEDBACK-2 format is thus not defined for Profile 0x0000.
プロファイル0000によって定義されたフィードバックの唯一の種類はFEEDBACK-1におけるプロファイル固有のオクテットの値が0（ゼロ）であり、セクション5.2.4.1、フィードバック-1フォーマットを使用して、ACKです。 FEEDBACK-2フォーマットは、このようにプロファイル0000のために定義されていません。
The ROHC protocol consists of a framework part and a profile part. The framework defines the mechanisms common to all profiles, while the profile defines the compression algorithm and profile specific packet formats.
ROHCプロトコルは、フレームワーク部及びプロファイル部分から成ります。プロファイルは、圧縮アルゴリズム及びプロファイルの特定のパケットフォーマットを定義しながら、フレームワークは、すべてのプロファイルに共通するメカニズムを定義しています。
Section 5 specifies the details of the ROHC framework. This section provides an informative overview of the elements that make a profile specification. The normative specification of individual profiles is outside the scope of this document.
第5節では、ROHCフレームワークの詳細を指定します。このセクションでは、プロファイル仕様を作る要素の有益な概要を説明します。個々のプロファイルの規範的な仕様は、このドキュメントの範囲外です。
A ROHC profile defines the elements that build up the compression protocol. A ROHC profile consists of:
ROHCプロファイルが圧縮プロトコルを構築要素を定義します。 ROHCプロファイルの構成は次のとおりです。
Packet formats:
パケットフォーマット：
o Bits-on-the-wire
Oビット・オン・ワイヤー
The profile defines the layout of the bits for profile-specific packet types that it defines, and for the profile-specific parts of packet types common to all profiles (e.g., IR and IR-DYN).
プロファイルは、それが定義するプロファイル固有のパケットタイプのためのビットのレイアウトを定義し、すべてのプロファイル（例えば、IR及びIR-DYN）に共通のパケットタイプのプロファイル固有の部品のため。
o Field encodings
Oフィールドのエンコーディング
Bits and groups of bits from the packet format layout, referred to as Compressed fields, represents the result of an encoding method specific for that compressed field within a specific packet format. The profile defines these encoding methods.
圧縮フィールドと呼ばれるパケットフォーマットのレイアウトからのビットのビット、グループは、特定のパケットフォーマット内のその圧縮フィールドのための特定の符号化方式の結果を表します。プロファイルは、これらの符号化方式を定義します。
o Updating properties
プロパティを更新するO
The profile-specific packet formats may update the state of the decompressor, and may do so in different ways. The profile defines how individual profile-specific fields, or entire profile-specific packet types, update the decompressor context.
プロファイル固有のパケットフォーマットは、デコンプレッサの状態を更新することができる、さまざまな方法で行うことができます。プロファイルは、個々のプロファイル固有のフィールド、または全体のプロファイル固有のパケット・タイプは、デコンプレッサ・コンテキストを更新する方法を定義します。
o Verification
O検証
Packets that update the state of the decompressor are verified to prevent incorrect updates to the decompressor context. The profile defines the mechanisms used to verify the decompression of a packet.
デコンプレッサの状態を更新したパケットは、デコンプレッサのコンテキストへの不正な更新を防止することが確認されています。プロファイルは、パケットの解凍を検証するために使用されるメカニズムを定義します。
Context management:
コンテキスト管理：
o Robustness logic
O堅牢ロジック
Packets may be lost or reordered between the compressor and the decompressor. The profile defines mechanism to minimize the impacts of such events and prevent damage propagation.
パケットが失われるか、またはコンプレッサとデコンプレッサとの間の並べ替えてもよいです。プロファイルは、イベントの影響を最小限にし、損傷の伝播を防止するための機構を定義します。
o Repair mechanism
O修復メカニズム
Despite the robustness logic, impairment events may still lead to decompression failure(s), and even to context damage at the decompressor. The profile defines context repair mechanisms, including feedback logic if used.
堅牢性・ロジックにもかかわらず、減損イベントはまだ解凍障害（複数可）に、さらには解凍器でのコンテクスト損傷につながる可能性があります。使用される場合、プロファイルは、フィードバックロジックを含むコンテクスト修復メカニズムを定義します。
Because encryption eliminates the redundancy that header compression schemes try to exploit, there is some inducement to forego encryption of headers in order to enable operation over low-bandwidth links.
暗号化は、ヘッダ圧縮スキームを活用しようという冗長性を排除しているため、低帯域幅のリンク上での動作を可能とするために、ヘッダの暗号化を見送るためにいくつかの誘因があります。
A malfunctioning or malicious header compressor could cause the header decompressor to reconstitute packets that do not match the original packets but still have valid headers and possibly also valid transport checksums. Such corruption may be detected with end-to-end authentication and integrity mechanisms, which will not be affected by the compression. Moreover, the ROHC header compression scheme uses an internal checksum for verification of reconstructed headers, which reduces the probability of producing decompressed headers not matching the original ones without this being noticed.
誤動作や悪意のあるヘッダ圧縮器は、ヘッダ復元は、元のパケットに一致するが、それでももおそらく有効なヘッダと有効な輸送チェックサムを持っていないパケットを再構成する可能性があります。そのような破損は、圧縮によって影響されないエンドツーエンド認証および完全性メカニズムを用いて検出することができます。また、ROHCヘッダ圧縮方式が注目され、このことなく、元のものと一致しない解凍ヘッダを生成する確率を低減する再構成されたヘッダの検証のための内部のチェックサムを使用します。
Denial-of-service attacks are possible if an intruder can introduce, for example, bogus IR, IR-DYN, or FEEDBACK packets onto the link and thereby cause compression efficiency to be reduced. However, an intruder having the ability to inject arbitrary packets at the link layer in this manner raises additional security issues that dwarf those related to the use of header compression.
サービス拒否攻撃は、侵入者が導入することができる場合、リンクに例えば、偽IR、IR-DYN、またはフィードバックパケットが可能であり、それにより、圧縮効率を低下させます。しかしながら、このように、リンク層で任意のパケットを注入する能力を有する侵入者は、ヘッダ圧縮の使用に関連するものを矮化追加のセキュリティ上の問題を提起します。
An IANA registry for "RObust Header Compression (ROHC) Profile Identifiers" [21] was created by RFC 3095 [3]. The assignment policy, as outlined by RFC 3095, is the following:
"ロバストヘッダ圧縮（ROHC）プロフィール識別子" [21]のためのIANAレジストリは、RFC 3095で作成された[3]。割り当てポリシーは、RFC 3095で概説され、以下の通りです。
The ROHC profile identifier is a non-negative integer. In many negotiation protocols, it will be represented as a 16-bit value. Due to the way the profile identifier is abbreviated in ROHC packets, the 8 least significant bits of the profile identifier have a special significance: Two profile identifiers with identical 8 LSBs should be assigned only if the higher-numbered one is intended to supersede the lower-numbered one. To highlight this relationship, profile identifiers should be given in hexadecimal (as in 0x1234, which would for example supersede 0x0A34).
ROHCプロファイル識別子は非負の整数です。多くの交渉プロトコルでは、16ビットの値として表現されます。プロファイル識別子は、ROHCパケットに略記するように、プロファイル識別子の8つの最下位ビットは、特別な意味を持っている：同じ8つのLSBを有する2つのプロファイル識別子は、より高い番号のいずれかが下に取って代わることを意図されている場合にのみ割り当てられるべきです-numbered 1。この関係を強調するために、プロファイル識別子（例えば0x0A34に取って代わるであろう、0x1234のように）進数で与えられるべきです。
Following the policies outlined in [22], the IANA policy for assigning new values for the profile identifier shall be Specification Required: values and their meanings must be documented in an RFC or in some other permanent and readily available reference, in sufficient detail that interoperability between independent implementations is possible. In the 8 LSBs, the range 0 to 127 is reserved for IETF standard-track specifications; the range 128 to 254 is available for other specifications that meet this requirement (such as Informational RFCs). The LSB value 255 is reserved for future extensibility of the present specification.
[22]に概説された方針以下、プロファイル識別子に新しい値を割り当てるためのIANAポリシーは、仕様が必要でなければならない：値とその意味は、相互運用することを十分に詳細に、RFCまたは何らかの他の永久的かつ容易に入手可能な文献に文書化されなければなりません独立した実装の間で可能です。 8個のLSBに、範囲は0〜127は、IETF標準トラック仕様のために予約されています。 254の範囲128は、（例えば、情報RFCとして）、この要件を満たす他の仕様のために利用可能です。 LSB値255は、本明細書の将来の拡張のために予約されています。
The following profile identifiers have so far been allocated:
次のプロファイル識別子は、これまでに割り当てられています：
Profile Identifier Usage Reference
------------------ ---------------------- ---------
0x0000 ROHC uncompressed RFC 4995
0x0001 ROHC RTP RFC 3095
0x0002 ROHC UDP RFC 3095
0x0003 ROHC ESP RFC 3095
0x0004 ROHC IP RFC 3843
0x0005 ROHC LLA RFC 3242
0x0105 ROHC LLA with R-mode RFC 3408
0x0006 ROHC TCP RFC 4996
0x0007 ROHC RTP/UDP-Lite RFC 4019
0x0008 ROHC UDP-Lite RFC 4019
New profiles will need new identifiers to be assigned by the IANA, but this document does not require any additional IANA action.
新しいプロファイルは、IANAによって割り当てられる新しい識別子が必要になりますが、この文書では、追加のIANAのアクションを必要としません。
The authors would like to acknowledge all who have contributed to previous ROHC work, and especially to the authors of RFC 3095 [3], which is the technical basis for this document. Thanks also to the various individuals who contributed to the RFC 3095 corrections and clarifications document [6], from which technical contents, when applicable, have been incorporated into this document. Committed WG document reviewers were Carl Knutsson and Biplab Sarkar, who reviewed the document during working group last-call.
著者は、前のROHC作業に貢献したすべての人に感謝し、特にRFC 3095の作者に[3]、本書の技術的基礎となるでしょう。また、[6]、技術的な内容、そこから、該当する場合RFC 3095点の修正と説明文書に貢献し、様々な個人のおかげで、この文書に組み込まれています。コミットWGドキュメントの校閲は、グループの最後のコールを作業中に文書を見直しカールKnutssonとBiplabサルカールでした。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[2]、STD 51、RFC 1662、1994年7月シンプソン、W.、 "HDLC様のフレーミングにおけるPPPを"。
[3] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[3]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、 ESP、および非圧縮」、RFC 3095、2001年7月。
[4] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[4]ボルマン、C.、 "PPPオーバーロバストヘッダ圧縮（ROHC）"、RFC 3241、2002年4月。
[5] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004.
[5]ヨンソン、L-E、 "ロバストヘッダ圧縮（ROHC）：用語とチャンネルマッピングの例"。、RFC 3759、2004年4月。
[6] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, "RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095", RFC 4815, February 2007.
[6]ジョンソン、L-E、Sandlund、K.、ペルティエ、G.、およびP.クレーメル、 "ロバストヘッダ圧縮（ROHC）：RFC 3095に修正及び明確化" を、RFC 4815、2007年2月。
[7] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets", RFC 4224, January 2006.
[7]ペルティエ、G.、ヨンソン、L-E、およびK. Sandlund、 "ロバストヘッダ圧縮（ROHC）：パケットの順序を変更できますチャンネル以上のROHC"。、RFC 4224、2006年1月。
[8] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP, and UDP Lite", Work in Progress, September 2006.
[8]ペルティエ、G.およびK. Sandlund、 "ロバストヘッダ圧縮バージョン2（ROHCv2）：RTP、UDP、IP、ESP、およびUDP Liteのプロファイル"、進歩、2006年9月での作業。
[9] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", RFC 4996, July 2007.
[9]ペルティエ、G.、Sandlund、K.、ヨンソン、L-E、およびM.西、 "ロバストヘッダ圧縮（ROHC）：TCP / IP（ROHC-TCP）のためのプロフィール"。、RFC 4996、2007年7月。
[10] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[10]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[11]デアリング、S.とR. Hindenと "インターネットプロトコル、バージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[12] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[12]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[13] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[13] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[14] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[14]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[15] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[15]ジェーコブソン、V.、RFC 1144、1990年2月 "低速シリアルリンク用のTCP / IPヘッダの圧縮"。
[16] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[16] Degermark、M.、Nordgren、B.、およびS.ピンク、 "IPヘッダー圧縮"、RFC 2507、1999年2月。
[17] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[17] Casner、S.とV.ヤコブソン、RFC 2508、1999年2月 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"。
[18] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
[18] Degermark、M.、 "ロバストIP / UDP / RTPヘッダ圧縮のための要件"、RFC 3096、2001年7月。
[19] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, July 2003.
[19]コレン、T.、Casner、S.、Geevarghese、J.、トンプソン、B.、およびP.ルディ、 "強化された圧縮RTP（CRTP）高遅延、パケットロス・順序付きリンクの"、RFC 3545、 2003年7月。
[20] Degermark, M., Hannu, H., Jonsson, L.E., and K. Svanbro, "Evaluation of CRTP Performance over Cellular Radio Networks", IEEE Personal Communication Magazine, Volume 7, number 4, pp. 20-25, August 2000.
[20] Degermark、M.、ハンヌ、H.、ジョンソン、LE、及びK. Svanbro、 "セルラ無線ネットワーク上CRTP性能評価"、IEEEパーソナル通信誌、7巻、番号4、PP。20-25、 2000年8月。
[21] IANA registry, "RObust Header Compression (ROHC) Profile Identifiers", http://www.iana.org/assignments/rohc-pro-ids
[21] IANAレジストリ、 "ロバストヘッダ圧縮（ROHC）プロファイル識別子"、http://www.iana.org/assignments/rohc-pro-ids
[22] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
、BCP 26、RFC 2434、1998年10月[22] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
Appendix A. CRC Algorithm
付録A. CRCアルゴリズム
#!/usr/bin/perl -w
use strict;
#=================================
#
# ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
#
# This little demo shows the four types of CRC in use in RFC 3095,
# the specification for robust header compression. Type your data in
# hexadecimal form and then press Control+D.
#
#---------------------------------
#
# utility
#
sub dump_bytes($) {
my $x = shift;
my $i;
for ($i = 0; $i < length($x); ) {
printf("%02x ", ord(substr($x, $i, 1)));
printf("\n") if (++$i % 16 == 0);
}
printf("\n") if ($i % 16 != 0);
}
#---------------------------------
#
# The CRC calculation algorithm.
#
sub do_crc($$$) {
my $nbits = shift;
my $poly = shift;
my $string = shift;
my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1);
for (my $i = 0; $i < length($string); ++$i) {
my $byte = ord(substr($string, $i, 1));
for( my $b = 0; $b < 8; $b++ ) {
if (($crc & 1) ^ ($byte & 1)) {
$crc >>= 1;
$crc ^= $poly;
} else {
$crc >>= 1;
}
$byte >>= 1;
}
} printf "%2d bits, ", $nbits;
printf "CRC: %02x\n", $crc;
}
#---------------------------------
#
# Test harness
#
$/ = undef;
$_ = <>; # read until EOF
my $string = ""; # extract all that looks hex:
s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg;
dump_bytes($string);
#---------------------------------
#
# 32-bit segmentation CRC
# Note that the text implies this is complemented like for PPP
# (this differs from 8, 7, and 3-bit CRC)
#
# C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 +
# x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32
#
do_crc(32, 0xedb88320, $string);
#---------------------------------
#
# 8-bit IR/IR-DYN CRC
#
# C(x) = x^0 + x^1 + x^2 + x^8
#
do_crc(8, 0xe0, $string);
#---------------------------------
#
# 7-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7
#
do_crc(7, 0x79, $string);
#---------------------------------
#
# 3-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^3
#
do_crc(3, 0x6, $string);
Authors' Addresses
著者のアドレス
Lars-Erik Jonsson Optand 737 SE-831 92 Ostersund, Sweden
ラース・エリックジョンソンOptand 737 SE-831 92エステルスンドスウェーデン
Phone: +46 70 365 20 58 EMail: lars-erik@lejonsson.com
電話：+46 70 365 20 58 Eメール：lars-erik@lejonsson.com
Ghyslain Pelletier Ericsson AB Box 920 SE-971 28 Lulea, Sweden
GhyslainペルティエエリクソンABボックス920 SE-971 28ルーレオ、スウェーデン
Phone: +46 8 404 29 43 Fax: +46 920 996 21 EMail: ghyslain.pelletier@ericsson.com
電話：+46 8 404 29 43ファックス：+46 920 996 21 Eメール：ghyslain.pelletier@ericsson.com
Kristofer Sandlund Ericsson AB Box 920 SE-971 28 Lulea, Sweden
クリストファーSandlundエリクソンABボックス920 SE-971 28ルーレオ、スウェーデン
Phone: +46 8 404 41 58 Fax: +46 920 996 21 EMail: kristofer.sandlund@ericsson.com
電話：+46 8 404 41 58ファックス：+46 920 996 21 Eメール：kristofer.sandlund@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。