[要約] RFC 5795は、ROHC（RObust Header Compression）フレームワークに関する規格であり、ヘッダの圧縮と伸張のための手法を提供します。その目的は、ネットワーク上での帯域幅の節約と通信の効率化です。
Internet Engineering Task Force (IETF) K. Sandlund
Request for Comments: 5795 G. Pelletier
Obsoletes: 4995 Ericsson
Category: Standards Track L-E. Jonsson
ISSN: 2070-1721 March 2010
The RObust Header Compression (ROHC) Framework
堅牢なヘッダー圧縮（ROHC）フレームワーク
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フレームワークは、圧縮プロファイルのセットとともに、RFC 3095で最初に定義されていました。ROHC仕様を改善および簡素化するために、このドキュメントはROHCフレームワークと非圧縮のプロファイルを個別に定義します。より具体的には、フレームワークの定義は、RFC 3095で指定されたフレームワークの定義を変更または更新しません。
This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications.
この仕様はRFC 4995を廃止します。これは、RFC 4995で誤って導入された1つの相互運用性の問題を修正し、いくつかの小さな説明を追加します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5795.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5795で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. ROHC Terminology . . . . . . . . . . . . . . . . . . . . . 5
3. Background (Informative) . . . . . . . . . . . . . . . . . . . 8
3.1. Header Compression Fundamentals . . . . . . . . . . . . . 8
3.2. A Short History of Header Compression . . . . . . . . . . 9
4. Overview of ROHC (Informative) . . . . . . . . . . . . . . . . 10
4.1. General Principles . . . . . . . . . . . . . . . . . . . . 10
4.2. Compression Efficiency, Robustness, and Transparency . . . 11
4.3. Developing the ROHC Protocol . . . . . . . . . . . . . . . 12
4.4. Operational Characteristics of the ROHC Channel . . . . . 13
4.5. Compression and Master Sequence Number (MSN) . . . . . . . 14
4.6. Static and Dynamic Parts of a Context . . . . . . . . . . 15
5. The ROHC Framework (Normative) . . . . . . . . . . . . . . . . 15
5.1. The ROHC Channel . . . . . . . . . . . . . . . . . . . . . 15
5.1.1. Contexts and Context Identifiers . . . . . . . . . . . 15
5.1.2. Per-Channel Parameters . . . . . . . . . . . . . . . . 16
5.1.3. Persistence of Decompressor Contexts . . . . . . . . . 17
5.2. ROHC Packets and Packet Types . . . . . . . . . . . . . . 17
5.2.1. General Format of ROHC Packets . . . . . . . . . . . . 18
5.2.1.1. Format of the Padding Octet . . . . . . . . . . . 19
5.2.1.2. Format of the Add-CID Octet . . . . . . . . . . . 19
5.2.1.3. General Format of Header . . . . . . . . . . . . . 19
5.2.2. Initialization and Refresh (IR) Packet Types . . . . . 20
5.2.2.1. ROHC IR Header Format . . . . . . . . . . . . . . 20
5.2.2.2. ROHC IR-DYN Header Format . . . . . . . . . . . . 21
5.2.3. ROHC Initial Decompressor Processing . . . . . . . . . 22
5.2.4. ROHC Feedback . . . . . . . . . . . . . . . . . . . . 23
5.2.4.1. ROHC Feedback Format . . . . . . . . . . . . . . . 24
5.2.5. ROHC Segmentation . . . . . . . . . . . . . . . . . . 26
5.2.5.1. Segmentation Usage Considerations . . . . . . . . 26
5.2.5.2. Segmentation Protocol . . . . . . . . . . . . . . 26
5.3. General Encoding Methods . . . . . . . . . . . . . . . . . 28
5.3.1. Header Compression CRCs, Coverage, and Polynomials . . 28
5.3.1.1. 8-bit CRC in IR and IR-DYN Headers . . . . . . . . 28
5.3.1.2. 3-bit CRC in Compressed Headers . . . . . . . . . 28
5.3.1.3. 7-bit CRC in Compressed Headers . . . . . . . . . 29
5.3.1.4. 32-bit Segmentation CRC . . . . . . . . . . . . . 29
5.3.2. Self-Describing Variable-Length Values . . . . . . . . 30
5.4. ROHC UNCOMPRESSED -- No Compression (Profile 0x0000) . . 30
5.4.1. IR Packet . . . . . . . . . . . . . . . . . . . . . . 31
5.4.2. Normal Packet . . . . . . . . . . . . . . . . . . . . 32
5.4.3. Context Initialization . . . . . . . . . . . . . . . . 32
5.4.4. Decompressor Operation . . . . . . . . . . . . . . . . 33
5.4.5. Feedback . . . . . . . . . . . . . . . . . . . . . . . 33
6. Overview of a ROHC Profile (Informative) . . . . . . . . . . . 33
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1. Normative References . . . . . . . . . . . . . . . . . . . 37
10.2. Informative References . . . . . . . . . . . . . . . . . . 37
Appendix A. CRC Algorithm . . . . . . . . . . . . . . . . . . . . 39
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 transferring data carried within RTP [RFC3550] will then, in addition to link-layer framing, have an IPv4 [RFC0791] header (20 octets), a UDP [RFC0768] header (8 octets), and an RTP header (12 octets), for a total of 40 octets. With IPv6 [RFC2460], the IPv6 header is 40 octets for a total of 60 octets. Applications transferring data using TCP [RFC0793] will have 20 octets for the transport header, for a total size of 40 octets for IPv4 and 60 octets for IPv6.
IPヘッダーのオーバーヘッドに問題があるリンクの場合、ヘッダーの合計サイズが重要になる可能性があります。RTP [RFC3550]内で運ばれたデータを転送するアプリケーションは、リンク層フレーミングに加えて、IPv4 [RFC0791]ヘッダー（20オクテット）、UDP [RFC0768]ヘッダー（8オクテット）、およびRTPヘッダー（12オクテット）を持っています。）、合計40オクテット。IPv6 [RFC2460]を使用すると、IPv6ヘッダーは40オクテットで、合計60オクテットです。TCP [RFC0793]を使用してデータを転送するアプリケーションには、トランスポートヘッダーに20オクテットがあり、IPv4の合計40オクテット、IPv6で60オクテットがあります。
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オーバー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 [RFC2507] and [RFC2508], 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トラフィックを運ぶには、ヘッダー圧縮アルゴリズム内のこれらのテクノロジーの特定の特性に対処するために注意する必要があります。[RFC2507]や[RFC2508]で定義されているものなどのレガシーヘッダー圧縮スキームは、たとえば観察されたように、損失のある動作と往復時間の両方が無視できないリンクに対して不十分に実行されることが示されています。ワイヤレスリンクと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 [RFC4224].
さらに、ヘッダー圧縮スキームは、しばしば自明でない残差エラーを処理する必要があります。つまり、下層が解読者に検出されないビットエラーを含むパケットを渡す場合があります。また、圧縮ポイントの前に、および圧縮ポイントと減圧ポイント[RFC4224]の間のリンク上の損失と並べ替えを処理する必要があります。
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 [RFC3095] 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 [RFC3095]は、ROHCフレームワークと圧縮プロファイルの初期セットを定義します。仕様を改善および簡素化するために、フレームワークとプロファイルの部分は個別のドキュメントに分割されています。このドキュメントは、ROHCフレームワークを明示的に定義していますが、RFC 3095で指定されたフレームワークの定義を変更または更新しません。両方のドキュメントは、互いに独立して使用できます。これは、いずれかの定義に基づく実装が互いに互換性があり、相互運用可能であることを意味します。ただし、この仕様を将来定義されたすべてのプロファイルの基本仕様として、この仕様をRFC 3095に置き換えることを目的としています。
This document fixes one interoperability issue that was erroneously introduced in RFC 4995. The fix for this issue is located in Section 5.2.4.1 and clarifies the interpretation of the Size field in ROHC feedback.
このドキュメントは、RFC 4995で誤って導入された1つの相互運用性の問題を修正します。この問題の修正は、セクション5.2.4.1にあり、ROHCフィードバックのサイズフィールドの解釈を明確にします。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
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. MRRU Maximum Reconstructed Reception Unit. MSB Most Significant Bit. MSN Master Sequence Number. NACK Negative Acknowledgment. ROHC RObust Header Compression.
ACK謝辞。CIDコンテキスト識別子。CO圧縮パケット形式。CRC周期的冗長性チェック。IR初期化と更新。IR-Dynの初期化と更新、動的部分。LSBは最小重要なビットです。MRRU最大再構築レセプションユニット。MSBの最も重要なビット。MSNマスターシーケンス番号。否定的な謝辞。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 that 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 mechanisms
コンテキスト修復メカニズム
Mechanisms 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 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.
IR/IR-Dynヘッダーに含まれる8ビットCRCを使用して、受信したIRおよびIR-Dynヘッダーのビットエラーに対する整合性の検証。
CRC verification
CRC検証
The verification of the result of a decompression attempt using the 3-bit CRC or 7-bit CRC included in the header of a compressed packet format.
圧縮パケット形式のヘッダーに含まれる3ビットCRCまたは7ビットCRCを使用した減圧試行の結果の検証。
Damage propagation
損傷伝播
Delivery of incorrect decompressed headers due to context damage, such as errors in (i.e., loss of or damage to) previous header(s) or feedback.
以前のヘッダーまたはフィードバックのエラー（つまり、損失または損傷）やフィードバックなど、コンテキストの損傷による誤った減圧ヘッダーの配信。
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 compression protocol that 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 [ROHC-ids]. 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-ID]。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.
以前のヘッダーまたはフィードバックのエラー（つまり、損傷の損失または損傷）によるヘッダーの喪失。
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
残留エラー
Error 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 [RFC3759].
1つのコンプレッサーから1つの減圧装置までROHCパケットを運ぶ論理的な一方向からポイントチャネル。[RFC3759]も参照してください。
This document also makes use of the conceptual terminology defined by "ROHC Terminology and Channel Mapping Examples", RFC 3759 [RFC3759].
このドキュメントでは、「ROHC用語とチャネルマッピングの例」、RFC 3759 [RFC3759]で定義された概念用語を使用しています。
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 [RFC3095].
このセクションでは、ヘッダー圧縮の主題の背景を提供します。基本的なアイデアは、ヘッダー圧縮スキームの歴史に関する議論とともに説明されています。さまざまなスキームの開発を促進する動機が議論され、それらの欠点が特定され、それによってROHCフレームワークとプロファイルの設計の基礎を提供します[RFC3095]。
Header compression is possible because there is significant redundancy between header field values within packets, but in particular between consecutive packets belonging to the same flow. On the path end-to-end, the entire header information is necessary for all packets in the flow, but over a single link, some of this information becomes redundant and can be reduced, as long as it is transparently recovered at the receiving end of the link. The header size can be reduced by first sending field information that is expected to remain static for (at least most of) the lifetime of the packet flow. Further compression is achieved for the fields carrying information that changes more dynamically by using compression methods tailored to their respective assumed change behavior.
ヘッダー圧縮は、パケット内のヘッダーフィールド値の間に有意な冗長性があるが、特に同じフローに属する連続したパケット間で有意な冗長性があるため、可能です。パスエンドツーエンドでは、フロー内のすべてのパケットにヘッダー情報全体が必要ですが、単一のリンクで、この情報の一部が冗長になり、受信側で透過的に回復する限り、減少させることができます。リンクの。ヘッダーサイズは、パケットフローの寿命の（少なくともほとんど）の間で静的であると予想されるフィールド情報を最初に送信することで縮小できます。それぞれの想定された変化挙動に合わせた圧縮方法を使用することにより、より動的に変化する情報を運ぶフィールドでは、さらなる圧縮が達成されます。
To achieve compression and decompression, some necessary information from past packets is maintained in a context. The compressor and the decompressor update their respective contexts upon certain, not necessarily synchronized, events. Impairment events may lead to inconsistencies in the decompressor context (i.e., context damage), which in turn may cause incorrect decompression. A Robust Header Compression scheme needs mechanisms to minimize the possibility of context damage, in combination with mechanisms for context repair.
圧縮と減圧を実現するために、過去のパケットから必要な情報がコンテキストで維持されます。コンプレッサーと減圧装置は、必ずしも同期したイベントではなく、特定のコンテキストを特定します。障害のイベントは、減圧装置のコンテキスト（つまり、コンテキスト損傷）で不整合につながる可能性があり、それが誤った減圧を引き起こす可能性があります。堅牢なヘッダー圧縮スキームは、コンテキスト修復のメカニズムと組み合わせて、コンテキスト損傷の可能性を最小限に抑えるためのメカニズムを必要とします。
The first header compression scheme, compressed TCP (CTCP) [RFC1144], 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）[RFC1144]は、Van Jacobsonによって導入されました。VJ圧縮とも呼ばれるCTCPは、TCP/IPヘッダーの40オクテットを4オクテットに圧縮します。CTCPは、シーケンシャルに変化するフィールドにデルタエンコードを使用します。CTCPコンプレッサーは、輸送レベルの再送信を検出し、コンテキスト全体を更新するヘッダーを送信します。この修復メカニズムでは、コンプレッサーと減圧装置間の明示的なシグナル伝達は必要ありません。
A general IP header compression scheme, IP header compression [RFC2507], 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 speed 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ヘッダー圧縮[RFC2507]は、CTCPで多少改善されます。IPヘッダー圧縮（IPHC）は、任意のIP、TCP、およびUDPヘッダーを圧縮できます。非TCPヘッダーを圧縮する場合、IPHCはデルタエンコードを使用せず、堅牢です。CTCPの修復メカニズムは、Context_Stateメッセージと呼ばれる否定的な確認で増強され、修理を高速化します。したがって、このコンテキスト修復メカニズムは、リンクの往復時間によって制限されます。IPHCはRTPヘッダーを圧縮しません。
CRTP [RFC2508] 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 [RFC2508]は、IPHCのRTP拡張です。CRTPは、UDPチェックサムが有効になっていない場合、IPv4/UDP/RTPヘッダーの40オクテットを最低2オクテットに圧縮します。UDPチェックサムが有効になっている場合、最小CRTPヘッダーは4オクテットです。
On lossy links with long round-trip times, CRTP does not perform well [CRTP-eval]. 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はうまく機能しません[CRTP-EVAL]。リンクを介して失われた各パケットにより、コンテキストが失われたパケットから少なくとも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, [CRTP-eval] also found that even with TWICE, CRTP doubled the number of lost packets.
CRTPは、IPHCによって導入された2回と呼ばれるローカル修復メカニズムを使用します。圧縮パケットのフローが規則的である場合、圧縮ポイント間に1つのパケットが失われたときの正しい推測は、現在のパケットのアップデートを2回適用することであるという観察結果から2回その名前を導き出します。CRTPのパフォーマンスは2回大幅に改善されますが、[CRTP-Eval]は2回でさえ、CRTPが失われたパケットの数を2倍にすることも発見しました。
An enhanced variant of CRTP, called eCRTP [RFC3545], 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 [RFC3545]と呼ばれるCRTPの強化されたバリアントは、プロトコルを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 [RFC3550]. 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 [RFC3550]。コンプレッサーと分解器はそれぞれ、パケットフローのコンテキストを確立し、各圧縮ヘッダーに含まれるコンテキスト識別子（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:
2番目のステップは、さまざまなヘッダーフィールドの変更パターンを理解することです。高いレベルでは、ヘッダーフィールドは次のクラスの1つに分類されます。
INFERRED These fields contain values that can be inferred from other fields or external sources; for example, the size of the frame carrying the packet can often be derived from the link-layer protocol, and thus does not have to be transmitted by the compression scheme.
これらのフィールドには、他のフィールドまたは外部ソースから推測できる値が含まれています。たとえば、パケットを運ぶフレームのサイズは、多くの場合、リンク層プロトコルから導出できるため、圧縮スキームによって送信する必要はありません。
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-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に分類された静的DEFフィールドは、上記のようにパケットフローを定義するために使用されます。これらのフィールドのそれぞれの値が異なるパケットは、異なるフローに属するものとして扱われます。これらのフィールドは、一般に静的フィールドとして圧縮されています。
STATIC-KNOWN Fields classified as STATIC-KNOWN are expected to have well-known values, and therefore their values do not need to be communicated.
静的な既知として分類された静的なフィールドは、よく知られている値を持つと予想されるため、その値を伝える必要はありません。
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).
最後に、最後のステップは、分類に基づいて異なるフィールドに適用されるエンコード方法を選択することです。識別されたフィールドの動作と組み合わせたエンコード方法は、圧縮ヘッダー形式の設計に入力を提供します。特定された変化パターンの確率分布の分析は、パケット形式を最適化する手段を提供します。ここでは、フィールドの最も頻繁に発生する変更パターンを最も効率的な形式でエンコードする必要があります。
However, compression efficiency has to be traded against two other properties: the robustness of the encoding to losses and errors between the compressor and the decompressor, and the ability to detect and cope with errors in the decompression process.
ただし、圧縮効率は、コンプレッサーと減圧器間の損失とエラーへのエンコードの堅牢性と、減圧プロセスのエラーを検出および対処する能力の2つの他のプロパティに対して取引する必要があります。
The performance of a header compression protocol can be described with three parameters: its compression efficiency, its robustness, and its compression transparency.
ヘッダー圧縮プロトコルのパフォーマンスは、その圧縮効率、その堅牢性、および圧縮透明度の3つのパラメーターで説明できます。
Compression efficiency
圧縮効率
The compression efficiency is determined by how much the average header size is reduced by applying the compression protocol.
圧縮効率は、圧縮プロトコルを適用することにより、平均ヘッダーサイズがどれだけ削減されるかによって決まります。
Robustness
堅牢性
A robust protocol tolerates packet losses, residual bit errors, and out-of-order delivery on the link over which header compression takes place, without losing additional packets or introducing additional errors in decompressed headers.
堅牢なプロトコルは、追加のパケットを失ったり、減圧ヘッダーに追加のエラーを導入することなく、ヘッダー圧縮が行われるリンク上のパケット損失、残留ビットエラー、および秩序外配信を許容します。
Compression transparency
圧縮透明度
The compression transparency is a measure of the extent to which the scheme maintains the semantics of the original headers. If all decompressed headers are bitwise identical to the corresponding original headers, the scheme is transparent.
圧縮透明性は、スキームが元のヘッダーのセマンティクスを維持する程度の尺度です。すべての減圧ヘッダーが対応する元のヘッダーと少し同一である場合、スキームは透明です。
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) Working Group (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は、現在および将来のリンクテクノロジーのニーズを満たすために、ヘッダー圧縮ソリューションを開発しました。ワイヤレスリンクの特性に起因するより厳しい要件を満たすことに特別な注意が払われていますが、結果は他の多くのリンクテクノロジーに等しく適用できます。
"RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed" [RFC3095] 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 [RFC3096].
「ロバストヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮されていない」[RFC3095]は、ROHC WGの最初の出力として2001年に公開されました。ROHCは、ヘッダー圧縮の一般的で拡張可能なフレームワークであり、その上に、さまざまなプロトコルヘッダーの圧縮のプロファイルを定義できます。RFC 3095は多くの新しい圧縮技術を導入し、[RFC3096]に記載されているように、それに掲載された要件に応えることに成功しました。
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 [RFC3095], which also makes development of additional profiles troublesome. This document therefore aims at explicitly specifying the ROHC framework, while a companion document [RFC5225] specifies revised versions of the compression profiles of RFC 3095.
RFC 3095の相互運用性テストは、ROHCの目的を満たす能力を確認しますが、実装者からのフィードバックは、プロトコルの仕様が複雑であり、時には不明瞭であることを示しています。最も重要なことは、[RFC3095]では、フレームワークとプロファイルの明確な区別が明らかではなく、追加のプロファイルの開発も面倒です。したがって、このドキュメントは、ROHCフレームワークを明示的に指定することを目的としていますが、コンパニオンドキュメント[RFC5225]は、RFC 3095の圧縮プロファイルの修正バージョンを指定します。
Robust header compression can be used over many types 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 [RFC3759]).
堅牢なヘッダー圧縮は、多くの種類のリンクテクノロジーで使用できます。ROHCフレームワークは、プロファイルが幅広いアプリケーションに対処するための柔軟性を提供し、このセクションにはROHCチャネルの運用特性の一部をリストします（[RFC3759も参照]）。
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 CID space per logical channel, and the CID can be omitted for one of the flows over the ROHC channel when configured to use a small CID space.
ROHCチャネルは、一般的なROHCパケット形式内のコンテキストを識別するメカニズムを提供します。CIDにより、ROHCをサポートする論理チャネルが複数のヘッダー圧縮フローを輸送することを可能にし、CIDオーバーヘッドなしで1つのパケットフローに専念するチャネルを可能にします。より具体的には、ROHCは論理チャネルごとに異なるCIDスペースを使用し、小さなCIDスペースを使用するように構成された場合、ROHCチャネル上のフローの1つについてCIDを省略できます。
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に1つのリンクレイヤーペイロードタイプを割り当てることができます。
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 [RFC3095], 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 are described in [RFC4224]. However, reordering before the compression point is handled, i.e., these profiles make no assumption that the compressor will receive packets in order.
[RFC3095]で指定されたプロファイルの場合、コンプレッサーと減圧器の間のチャネルは、パケットの順序配信を維持するために必要です。つまり、これらのプロファイルの定義は、減圧器がコンプレッサーが送信したのと同じ順序で常にパケットを受信することを前提としています。これらのプロファイルのパフォーマンスに対する並べ替えの影響は、[RFC4224]で説明されています。ただし、圧縮点が処理される前に並べ替えること、つまり、これらのプロファイルは、コンプレッサーが順番にパケットを受信すると仮定しません。
For the ROHCv2 profiles specified in [RFC5225], 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.
[RFC5225]で指定された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 [RFC5225]), or it can be created and maintained by the compressor (e.g., the MSN for compression of UDP in profile 0x0102 [RFC5225] or the MSN in ROHC-TCP [RFC4996]).
MSNはプロファイルごとに定義されています。圧縮されているプロトコルのフィールドの1つ（たとえば、RTP SN [RFC5225]）から直接導出されるか、コンプレッサーによって作成および維持される可能性があります（たとえば、UDPのMSNプロファイル0x0102 [RFC5225]またはROHC-TCPのMSN [RFC4996]）。
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).
静的部分には、変化挙動が静的、静的、または静的DEFとして分類されているフィールドを圧縮および解凍するために必要な情報が含まれます（上記のセクション4.1で説明されているように）。
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に適用されない場合、CIDがプロファイルに関連付けられている場合、コンテキストは新しいコンテキストと見なされます。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スペースは小さい場合があります。つまり、CIDは0〜15から15、または大規模な値を取得できます。つまり、CIDは0〜2^14-1 = 16383の値を取得できます。おそらく交渉により、圧縮されたパケットが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上のCID 3およびチャネルB上のCID 3は、AとBのエンドポイントが同じノードであっても、同じコンテキストを参照しません。特に、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 [RFC3241], 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チャネルの状態は、最初のROHCパケットを送信する前に確立する必要があります。これは、リンクレイヤーによって提供されるネゴシエーションプロトコルを使用して達成できます（PPPの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 Section 5.1.1 and Section 5.2.1.3.
large_cids：boolean;FALSEの場合、小さなCID表現（0オクテットまたは1のプレフィックスオクテット、CID 0〜15をカバーする）が使用されます。Trueの場合、CID 0〜16383を覆う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.
プロファイル：非陰性整数のセット。各整数は、コンプレッサーと減圧器の両方でサポートされているプロファイルを示します。プロファイルは16ビット値によって識別され、8 LSBビットは実際のプロファイルを示し、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 [RFC3759]).
Feedback_for：同じ圧縮エンドポイント間の反対方向にあるROHCチャネルへのオプションの参照。提供されている場合、このパラメーターは、他のROHCチャネルがこのROHCチャネルに送信されたフィードバックがどのように言及しているかを示します（[RFC3759]を参照）。
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 is negotiated to be 0, segmentation MUST NOT be used on the channel, and received segments MUST be discarded by the decompressor.
MRRU：非陰性整数。最大再構築レセプションユニット。これは、減圧装置がセグメントから再組み立てられると予想されるオクテットの最大の再構築ユニットのサイズです（セクション5.2.5を参照）。このサイズにはセグメンテーションCRCが含まれます。MRRUが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が再利用されるか、または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オクター（4ビットのCIDを含む）、および簡単なセグメンテーションと再組み立てメカニズムを提供するように設計されています。
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：ADD-CID OCTET（NNNN = CID 0x1〜0XF）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.
少なくとも1つのフィードバックまたはヘッダーが存在する必要があります。
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の追加CIDオクテットとして解釈してはなりません。
Add-CID octet:
Add-CIDオクテット：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | CID |
+---+---+---+---+---+---+---+---+
CID: 0x1 through 0xF indicates CIDs 1 through 15.
CID：0x1〜0xfは、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.
したがって、ヘッダーはパケットタイプの表示で始まるか、ADD-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.
o 追加CIDがパケットタイプの表示の直前にある場合、パケットには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は、上記のようにAdd-CIDオクテットを使用して表されます。ヘッダーは、Add-CID Octetから始まり、パケットタイプの表示が続きます。
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は常に存在し、セクション5.3.2のエンコードスキームを使用して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.
o 8ビットCRCがヘッダーの整合性を確認できない場合、パケットを解凍して上層に配信する必要はありません。コンテキストでプロファイルが示されている場合、そのプロファイルのロジックは、フィードバックが送信されるものを決定します。コンテキストでプロファイルが記載されていない場合、ロジックは、送信するフィードバックが実装にまで及ぶものを決定するために使用されます。ただし、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.
o 8ビットCRCがヘッダーの整合性を確認できない場合、パケットを解凍して上層に配信する必要はありません。コンテキストでプロファイルが示されている場合、そのプロファイルのロジックは、フィードバックが送信されるものを決定します。コンテキストでプロファイルが記載されていない場合、ロジックは、送信するフィードバックが実装にまで及ぶものを決定するために使用されます。ただし、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 コンテキストがまだ初期化されていない場合、パケットを解凍して上層に配信する必要はありません。IR-Dynヘッダー（8ビットCRCによって検証された場合）に示されているプロファイルのロジックは、フィードバックが送信されるものを決定します。
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.
任意のパケットタイプで解析エラーが発生した場合、減圧器はさらに処理せずにパケットを破棄する必要があります。たとえば、ROHCチャネルに大きなCIDスペースが使用されると、CIDフィールドが圧縮ヘッダーに存在し、セクション5.3.2の自己記述変数変数エンコードを使用してフィールドがコード化されています。フィールドが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の一部またはすべてを無効にした後、3ビットCRCのみを運ぶパケットの減圧試行を行うように禁止することをお勧めします。、および7ビットまたは8ビットCRCによって正常に検証されました。
Feedback carries information from the decompressor to the 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 [RFC3759]), or a combination of both, over a ROHC channel. This is facilitated by the following properties:
一般的なROHCパケット形式では、ROHCチャネルを介して、散布またはピギーバック（[RFC3759]を参照）、または両方の組み合わせを使用したフィードバックの輸送が可能になります。これは、次のプロパティによって促進されます。
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 [RFC3759].
特定のチャネルで送信されたフィードバック情報は、そのチャネルのフィードバックに関連付けられたコンプレッサーに渡され、解釈されます。したがって、各フィードバック要素には、フィードバックが送信されるチャネルからのCID情報が含まれています。したがって、ROHCフィードバックスキームでは、チャネルが最大1つのコンプレッサーにフィードバックを搭載する必要があります。コンプレッサーが特定のチャネルのフィードバックにどのように関連付けられているかは、この仕様の範囲外です。[RFC3759]も参照してください。
Length information:
長さの情報：
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.
Piggybackおよび/または散在するフィードバックを交換する目的で、反対方向に動作するコンプレッサー抑制ペア間の関連は、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.
ROHCは、フィードバックメッセージの3つの異なるカテゴリを定義しています。COUNDAMENT（ACK）、ネガティブACK（NACK）、およびNACK全体のNACK（Static-Nack）。他のタイプの情報は、プロファイル固有のフィードバック情報で定義される場合があります。
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：Decompressorが静的コンテキスト全体が無効であると見なしていること、または確立されていないことを示します。
Feedback sent on a ROHC channel consists of one or more concatenated feedback elements, where each feedback element has the following format:
ROHCチャネルで送信されたフィードバックは、1つ以上の連結フィードバック要素で構成されています。各フィードバック要素には次の形式があります。
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 / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
/ FEEDBACK data / variable length
+---+---+---+---+---+---+---+---+
Code:
コード：
0 indicates that a Size octet is present.
0は、サイズのオクテットが存在することを示します。
1-7 indicates the total size of the FEEDBACK data field and the CID field (if any), in octets.
1-7は、フィードバックデータフィールドの合計サイズとオクテットのCIDフィールド（ある場合）を示します。
Size: Indicates the total size of the FEEDBACK data field and the CID field (if any), in octets.
サイズ：フィードバックデータフィールドとCIDフィールド（ある場合）の合計サイズをオクテットで示します。
FEEDBACK data: FEEDBACK-1 or FEEDBACK-2 (see below).
フィードバックデータ：フィードバック1またはフィードバック-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:
フィードバック1：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| profile-specific information | 1 octet
+---+---+---+---+---+---+---+---+
FEEDBACK-2:
フィードバック-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 unparsable.)
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.
また、セグメンテーションプロトコルは、1つのコンテキストに対応する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.
ROHCセグメンテーションは、セクション5.2.1で定義されているように、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つの再構築されたユニットに、受信した順序で1つの再構成ユニットに再構成します。1つの再構築されたユニットのすべてのセグメントは、減圧器が連続して正しい順序で受信する必要があります。非セグメントROHCパケットが非ファイナルセグメントに直接従う場合、現在の再構築されたユニットの再組み立てが中止され、減圧装置はこのチャネルでこれまでに受け取った非ファイナルセグメントを破棄する必要があります。
Reconstructed unit:
再構築されたユニット：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
/ Header /
+---+---+---+---+---+---+---+---+
: Payload :
+---+---+---+---+---+---+---+---+
/ CRC / 4 octets
+---+---+---+---+---+---+---+---+
Header: See Section 5.2.1
ヘッダー：セクション5.2.1を参照してください
Payload: See Section 5.2.1
ペイロード：セクション5.2.1を参照してください
CRC: 32-bit CRC computed using the polynomial of Section 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 5.1.2), the reconstructed unit MUST be discarded by the decompressor. If the CRC succeeds, the reconstructed unit can be further processed.
CRC：セクション5.3.1.4の多項式を使用して計算された32ビットCRCは、再構築されたユニットが4オクテット以下の場合、またはCRCが故障した場合、またはチャネルパラメーターMRRU（セクション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 [RFC1662], defined in Appendix A of this document, with the polynomials specified in subsequent sections.
このセクションでは、ROHCが使用するCRCを計算する方法について説明します。すべてのCRCについて、CRCの計算に使用されるアルゴリズムは、このドキュメントの付録Aで定義されている[RFC1662]で使用されたアルゴリズムと同じであり、後続のセクションで多項式が指定されています。
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やAdd-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は、元の非圧縮ヘッダーだけでなく、完全にカバーするものではありません。したがって、減圧試行の試みを検証する手段、または減圧器のコンテキスト全体の正確性を検証する手段を提供するものではありません。ただし、成功した場合、ded decompressorがIRまたはIR-Dynヘッダー内で運ばれる情報でコンテキストを更新するのに十分な堅牢性を提供します。
The CRC polynomial for the 8-bit CRC is:
8ビットCRCのCRC多項式は次のとおりです。
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
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. However, it is 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
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
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
最初のビットは0：1オクテットです。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
最初のビットは10：2オクテットです。14ビット転送。最大16 383 10進数。16進数でエンコードされたオクテット：80 00〜BF ff
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
最初のビットは110：3オクテットです。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
最初のビットは111：4オクテットです。29ビット転送。最大536 870 911 10進数。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プロファイルについて説明します。このプロファイルのプロファイル識別子は0x0000です。
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.
プロファイル0x0000は、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.
初期化後、プロファイル0x0000を使用してパケットを送信するための唯一のオーバーヘッドは、CIDのサイズです。非圧縮パケットが頻繁に発生する場合、プロファイル0x0000は、ゼロまたは1オクテットのサイズのCIDに関連付けられる必要があります。プロファイル0x0000は、せいぜい1つのCIDに関連付けられている必要があります。
The initialization and refresh packet (IR packet) for Profile 0x0000 has the following Header format:
プロファイル0x0000の初期化と更新パケット（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
プロファイル：0x00
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パケットに含まれる場合があります。減圧装置は、IRパケットの長さを考慮することにより、IPパケットが存在するかどうかを判断します。
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に関連付けられている場合、ADD-CIDオクテットはIPパケットの前にあります。チャネルが大きなCIDを使用すると、CIDが配置され、上記のヘッダー/ペイロード形式の2番目のオクテットから始まります。
A Normal Packet may carry Padding and/or Feedback as any other ROHC packet, preceding the combined Header/Payload.
通常のパケットは、ヘッダー/ペイロードを組み合わせた他のROHCパケットと同様に、パディングやフィードバックを運ぶ場合があります。
The compressor initializes the static context associated with the UNCOMPRESSED profile by sending IR packets (see Section 5.4.1). During context initialization, it is RECOMMENDED that the compressor sends IR packets until it is reasonably confident that the decompressor has successfully received at least one IR packet. For example, this confidence can be based on feedback from the decompressor, or on knowledge of the characteristics of the link.
コンプレッサーは、IRパケットを送信することにより、非圧縮プロファイルに関連付けられた静的コンテキストを初期化します（セクション5.4.1を参照）。コンテキストの初期化中に、コンプレッサーは、減圧器が少なくとも1つのIRパケットを正常に受信したことを合理的に確信するまでIRパケットを送信することをお勧めします。たとえば、この信頼性は、減圧器からのフィードバック、またはリンクの特性に関する知識に基づいています。
The compressor SHOULD periodically transmit IR packets for a context associated with the UNCOMPRESSED profile, at least until it receives feedback from the decompressor for that context. The compressor MAY stop the periodic sending of IR packets once it has received feedback.
コンプレッサーは、少なくともそのコンテキストの減圧器からフィードバックを受信するまで、非圧縮プロファイルに関連付けられたコンテキストのIRパケットを定期的に送信する必要があります。コンプレッサーは、フィードバックを受け取ったら、IRパケットの定期的な送信を停止する場合があります。
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,
1. 指定されたプロファイルに既に関連付けられている特定のCIDに対して有効なコンテキストがない場合、コンテキストを初期化します。
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.
プロファイル0x0000で定義されたフィードバックの唯一の種類は、ACKです。セクション5.2.4.1のフィードバック1形式を使用します。ここで、フィードバック1のプロファイル固有のオクテットの値は0（ゼロ）です。したがって、フィードバック-2形式は、プロファイル0x0000で定義されていません。
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: Packet formats:
ROHCプロファイルは、圧縮プロトコルを構築する要素を定義します。ROHCプロファイルは次のとおりです。パケット形式：
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, represent 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 mechanisms 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.
堅牢性の論理にもかかわらず、障害のイベントは依然として減圧の失敗につながり、さらには減圧器での文脈的損傷につながる可能性があります。プロファイルは、使用した場合のフィードバックロジックを含むコンテキスト修復メカニズムを定義します。
The authors would like to acknowledge all who have contributed to previous ROHC work, and especially to the authors of RFC 3095 [RFC3095], which is the technical basis for this document. Thanks also to the various individuals who contributed to the RFC 3095 corrections and clarifications document [RFC4815], from which technical contents, when applicable, have been incorporated into this document. Thanks to Jani Juvan for discovering an inconsistency between the feedback structure described in [RFC4995] and the one described in [RFC3095], which made this update to [RFC4995] necessary.
著者は、以前のROHC作業に貢献したすべての人、特にこのドキュメントの技術的根拠であるRFC 3095 [RFC3095]の著者に認めたいと考えています。また、RFC 3095の修正と明確化文書[RFC4815]に貢献してくれたさまざまな個人にも感謝します。この文書は、この文書に技術的なコンテンツが組み込まれています。[RFC4995]に記載されているフィードバック構造と[RFC3095]で説明されているフィードバック構造と[RFC4995]への更新が必要になったことを発見してくれたJani Juvanに感謝します。
Committed WG document reviewers were Carl Knutsson, Biplab Sarkar, and Robert Stangarone, who reviewed the document during working group last calls. Additional thanks to Bert Wijnen and Brian Carpenter for comments during IETF Last Call.
コミットしたWGドキュメントレビュー担当者は、ワーキンググループの最後の電話でドキュメントをレビューしたCarl Knutsson、Biplab Sarkar、およびRobert Stangaroneでした。IETFの最後の電話でコメントをしてくれたBert WijnenとBrian Carpenterに感謝します。
An IANA registry for "RObust Header Compression (ROHC) Profile Identifiers" [ROHC-ids] was created by RFC 3095 [RFC3095]. The assignment policy, as outlined by RFC 3095, is the following:
「堅牢なヘッダー圧縮（ROHC）プロファイル識別子」[ROHC-IDS]のIANAレジストリは、RFC 3095 [RFC3095]によって作成されました。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 LSBs 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 (for example, as in 0x1234, which would supersede 0x0A34).
ROHCプロファイル識別子は、非陰性整数です。多くの交渉プロトコルでは、16ビット値として表されます。ROHCパケットでプロファイル識別子が略される方法により、プロファイル識別子の8つのLSBには特に重要性があります。一。この関係を強調するには、プロファイル識別子を16進数で提供する必要があります（たとえば、0x1234のように、0x0A34に取って代わる）。
Following the policies outlined in [RFC5226], the IANA policy for assigning new values for the profile identifier is 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.
[RFC5226]で概説されているポリシーに従って、プロファイル識別子に新しい値を割り当てるためのIANAポリシーが必要です：値とその意味は、RFCまたは他の永続的で容易に利用可能な参照で、相互運用性の間の相互運用性を十分に詳細に文書化する必要があります。独立した実装が可能です。8つのLSBでは、0〜127の範囲はIETF標準トラック仕様用に予約されています。範囲128〜254は、この要件を満たす他の仕様（情報RFCなど）で利用できます。LSB値255は、現在の仕様の将来の拡張性のために予約されています。
The following profile identifiers have so far been allocated:
これまでのところ、次のプロファイル識別子が割り当てられています。
Profile Identifier Usage Reference
------------------ ---------------------- ---------
0x0000 ROHC uncompressed RFC 5795
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
0x0101 ROHCv2 RTP RFC 5225
0x0102 ROHCv2 UDP RFC 5225
0x0103 ROHCv2 ESP RFC 5225
0x0104 ROHCv2 IP RFC 5225
0x0107 ROHCv2 RTP/UDP-Lite RFC 5225
0x0108 ROHCv2 UDP-Lite RFC 5225
New profiles will need new identifiers to be assigned by the IANA, but this document does not require any additional IANA action.
新しいプロファイルでは、IANAによって新しい識別子を割り当てる必要がありますが、このドキュメントでは追加のIANAアクションは必要ありません。
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、またはフィードバックパケットを導入し、それにより圧縮効率を低下させる場合、サービス拒否攻撃が可能です。ただし、この方法でリンクレイヤーに任意のパケットを注入する機能を持つ侵入者は、ヘッダー圧縮の使用に関連する追加のセキュリティ問題を提起します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[CRTP-eval] Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro, ""Evaluation of CRTP Performance over Cellular Radio Networks", IEEE Personal Communication Magazine, Volume 7, number 4, pp. 20-25, August 2000.", 2000.
[CRTP-EVAL] DeGermark、M.、Hannu、H.、Jonsson、L.、K。Svanbro、「セルラー無線ネットワーク上のCRTPパフォーマンスの評価」、IEEE Personal Communication Magazine、Volume 7、Number 4、pp。20-25、2000年8月。」、2000年。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] POSTEL、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[RFC1144] Jacobson、V。、「低速シリアルリンクのTCP/IPヘッダーの圧縮」、RFC 1144、1990年2月。
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[RFC1662]シンプソン、W。、「HDLCのようなフレーミングのPPP」、STD 51、RFC 1662、1994年7月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507] Degermark、M.、Nordgren、B。、およびS. Pink、「IPヘッダー圧縮」、RFC 2507、1999年2月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508] Casner、S。およびV. Jacobson、「低速シリアルリンクのIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[RFC3095] 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.
[RFC3095] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-e。、Hakenberg、R.、Koren、T.、Le、K.、Liu、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH. Zheng、 "堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮」、RFC 3095、2001年7月。
[RFC3096] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
[RFC3096] Degermark、M。、「堅牢なIP/UDP/RTPヘッダー圧縮の要件」、RFC 3096、2001年7月。
[RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[RFC3241]ボルマン、C。、「PPP上の堅牢なヘッダー圧縮（ROHC）」、RFC 3241、2002年4月。
[RFC3545] 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.
[RFC3545] Koren、T.、Casner、S.、Geevarghese、J.、Thompson、B。、およびP. Ruddy、「高度な遅延、パケット損失、再注文を伴うリンクのための圧縮RTP（CRTP）の強化」、RFC 3545、2003年7月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004.
[RFC3759] Jonsson、L-E。、「ロバストヘッダー圧縮（ROHC）：用語とチャネルマッピングの例」、RFC 3759、2004年4月。
[RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets", RFC 4224, January 2006.
[RFC4224] Pelletier、G.、Jonsson、L-E。、およびK. Sandlund、「Robust Header Compression（ROHC）：Packetsを並べ替えることができるROHC上のROHC」、RFC 4224、2006年1月。
[RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, "RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095", RFC 4815, February 2007.
[RFC4815] Jonsson、L-E。、Sandlund、K.、Pelletier、G。、およびP. Kremer、「堅牢なヘッダー圧縮（ROHC）：RFC 3095への修正と明確化」、RFC 4815、2007年2月。
[RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust Header Compression (ROHC) Framework", RFC 4995, July 2007.
[RFC4995] Jonsson、L-E。、Pelletier、G。、およびK. Sandlund、「The Robust Header Compression（ROHC）フレームワーク」、RFC 4995、2007年7月。
[RFC4996] 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.
[RFC4996] Pelletier、G.、Sandlund、K.、Jonsson、L-E。、およびM. West、 "Robust Header Compression（ROHC）：TCP/IP（ROHC-TCP）のプロファイル、RFC 4996、2007年7月。
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008.
[RFC5225] Pelletier、G。およびK. Sandlund、「堅牢なヘッダー圧縮バージョン2（ROHCV2）：RTP、UDP、IP、ESP、UDP-Liteのプロファイル」、RFC 5225、2008年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[ROHC-ids] IANA, "RObust Header Compression (ROHC) Profile Identifiers", <http://www.iana.org>.
[ROHC-IDS] IANA、「ロバストヘッダー圧縮（ROHC）プロファイル識別子」、<http://www.iana.org>。
#!/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
著者のアドレス
Kristofer Sandlund Ericsson Box 920 Lulea SE-971 28 Sweden
Kristofer Sandlund Ericsson Box 920 Lulea SE-971 28スウェーデン
Phone: +46 (0) 8 404 41 58
EMail: kristofer.sandlund@ericsson.com
Ghyslain Pelletier Ericsson Box 920 Lulea SE-971 28 Sweden
Ghyslain Pelletier Ericsson Box 920 Lulea SE-971 28スウェーデン
Phone: +46 (0) 8 404 29 43
EMail: ghyslain.pelletier@ericsson.com
Lars-Erik Jonsson Optand 737 Ostersund SE-831 92 Sweden
Lars-Erik Jonsson Optand 737 Ostersund SE-831 92スウェーデン
Phone: +46 76 830 03 12
EMail: lars-erik@lejonsson.com