Network Working Group G. Pelletier
Request for Comments: 4996 K. Sandlund
Category: Standards Track Ericsson
L-E. Jonsson
M. West
Siemens/Roke Manor
July 2007
RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)
ロバストヘッダ圧縮（ROHC）：TCP / IPのためのプロファイル（ROHC-TCP）
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as SACK (Selective Acknowledgments) and Timestamps.
この文書では、TCP / IPパケットの圧縮のためのROHC（ロバストヘッダ圧縮）プロファイルを指定します。 ROHC-TCPと呼ばれるプロファイルは、そのようなSACK（選択的確認応答）およびタイムスタンプなどの頻繁に使用されるTCPオプションを含むTCPヘッダの効率的かつ堅牢な圧縮を提供します。
ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common.
重大なエラー率と長い往復時間とのリンク上で使用する場合ROHC-TCPはうまく動作します。ヘッダ圧縮が不可欠である多くの帯域幅が制限されたリンクについては、このような特性は一般的です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Existing TCP/IP Header Compression Schemes . . . . . . . . 5
3.2. Classification of TCP/IP Header Fields . . . . . . . . . . 6
4. Overview of the TCP/IP Profile (Informative) . . . . . . . . . 8
4.1. General Concepts . . . . . . . . . . . . . . . . . . . . . 8
4.2. Compressor and Decompressor Interactions . . . . . . . . . 8
4.2.1. Compressor Operation . . . . . . . . . . . . . . . . . 8
4.2.2. Decompressor Feedback . . . . . . . . . . . . . . . . 9
4.3. Packet Formats and Encoding Methods . . . . . . . . . . . 9
4.3.1. Compressing TCP Options . . . . . . . . . . . . . . . 10
4.3.2. Compressing Extension Headers . . . . . . . . . . . . 10
4.4. Expected Compression Ratios with ROHC-TCP . . . . . . . . 10
5. Compressor and Decompressor Logic (Normative) . . . . . . . . 11
5.1. Context Initialization . . . . . . . . . . . . . . . . . . 11
5.2. Compressor Operation . . . . . . . . . . . . . . . . . . . 11
5.2.1. Compression Logic . . . . . . . . . . . . . . . . . . 11
5.2.2. Feedback Logic . . . . . . . . . . . . . . . . . . . . 13
5.2.3. Context Replication . . . . . . . . . . . . . . . . . 14
5.3. Decompressor Operation . . . . . . . . . . . . . . . . . . 14
5.3.1. Decompressor States and Logic . . . . . . . . . . . . 14
5.3.2. Feedback Logic . . . . . . . . . . . . . . . . . . . . 18
5.3.3. Context Replication . . . . . . . . . . . . . . . . . 18
6. Encodings in ROHC-TCP (Normative) . . . . . . . . . . . . . . 18
6.1. Control Fields in ROHC-TCP . . . . . . . . . . . . . . . . 18
6.1.1. Master Sequence Number (MSN) . . . . . . . . . . . . . 19
6.1.2. IP-ID Behavior . . . . . . . . . . . . . . . . . . . . 19
6.1.3. Explicit Congestion Notification (ECN) . . . . . . . . 20
6.2. Compressed Header Chains . . . . . . . . . . . . . . . . . 21
6.3. Compressing TCP Options with List Compression . . . . . . 23
6.3.1. List Compression . . . . . . . . . . . . . . . . . . . 23
6.3.2. Table-Based Item Compression . . . . . . . . . . . . . 24
6.3.3. Encoding of Compressed Lists . . . . . . . . . . . . . 25
6.3.4. Item Table Mappings . . . . . . . . . . . . . . . . . 26
6.3.5. Compressed Lists in Dynamic Chain . . . . . . . . . . 28
6.3.6. Irregular Chain Items for TCP Options . . . . . . . . 28
6.3.7. Replication of TCP Options . . . . . . . . . . . . . . 28
6.4. Profile-Specific Encoding Methods . . . . . . . . . . . . 29
6.4.1. inferred_ip_v4_header_checksum . . . . . . . . . . . . 29
6.4.2. inferred_mine_header_checksum . . . . . . . . . . . . 30
6.4.3. inferred_ip_v4_length . . . . . . . . . . . . . . . . 30
6.4.4. inferred_ip_v6_length . . . . . . . . . . . . . . . . 31
6.4.5. inferred_offset . . . . . . . . . . . . . . . . . . . 31
6.4.6. baseheader_extension_headers . . . . . . . . . . . . . 31
6.4.7. baseheader_outer_headers . . . . . . . . . . . . . . . 32
6.4.8. Scaled Encoding of Fields . . . . . . . . . . . . . . 32
6.5. Encoding Methods With External Parameters . . . . . . . . 34
7. Packet Types (Normative) . . . . . . . . . . . . . . . . . . . 36
7.1. Initialization and Refresh (IR) Packets . . . . . . . . . 36
7.2. Context Replication (IR-CR) Packets . . . . . . . . . . . 38
7.3. Compressed (CO) Packets . . . . . . . . . . . . . . . . . 41
8. Header Formats (Normative) . . . . . . . . . . . . . . . . . . 42
8.1. Design Rationale for Compressed Base Headers . . . . . . . 42
8.2. Formal Definition of Header Formats . . . . . . . . . . . 45
8.3. Feedback Formats and Options . . . . . . . . . . . . . . . 86
8.3.1. Feedback Formats . . . . . . . . . . . . . . . . . . . 86
8.3.2. Feedback Options . . . . . . . . . . . . . . . . . . . 87
9. Security Considerations . . . . . . . . . . . . . . . . . . . 89
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 90
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 90
12.1. Normative References . . . . . . . . . . . . . . . . . . . 90
12.2. Informative References . . . . . . . . . . . . . . . . . . 91
There are several reasons to perform header compression on low- or medium-speed links for TCP/IP traffic, and these have already been discussed in [RFC2507]. Additional considerations that make robustness an important objective for a TCP [RFC0793] compression scheme are introduced in [RFC4163]. Finally, existing TCP/IP header compression schemes ([RFC1144], [RFC2507]) are limited in their handling of the TCP options field and cannot compress the headers of handshaking packets (SYNs and FINs).
そこTCP / IPトラフィック用の低、中速リンクでヘッダ圧縮を実行するには、いくつかの理由があり、これらはすでに[RFC2507]で議論されています。堅牢TCP [RFC0793]圧縮方式のための重要な目的にするその他の考慮事項は、[RFC4163]で導入されています。最後に、既存のTCP / IPヘッダ圧縮方式（[RFC1144]、[RFC2507]）は、TCPオプションフィールドのそれらの処理に限定され、ハンドシェイクパケット（SYNのフィン）のヘッダを圧縮することができません。
It is thus desirable for a header compression scheme to be able to handle loss on the link between the compression and decompression points as well as loss before the compression point. The header compression scheme also needs to consider how to efficiently compress short-lived TCP transfers and TCP options, such as SACK ([RFC2018], [RFC2883]) and Timestamps ([RFC1323]).
ヘッダ圧縮方式は、圧縮ポイントの前に圧縮および解凍点との間のリンク上の損失、ならびに損失を扱うことができることがことが望ましいです。ヘッダ圧縮方式は、効率的にそのようなSACK（[RFC2018]、[RFC2883]）とタイムスタンプ（[RFC1323]）のような短命のTCP転送とTCPオプションを、圧縮する方法を検討する必要があります。
The ROHC WG has developed a header compression framework on top of which various profiles can be defined for different protocol sets, or for different compression strategies. This document defines a TCP/IP compression profile for the ROHC framework [RFC4995], compliant with the requirements listed in [RFC4163].
ROHC WGは、様々なプロファイルは、異なるプロトコルのセットについて、又は異なる圧縮戦略を定義することができるの上にヘッダ圧縮フレームワークを開発しました。この文書では、[RFC4163]に記載されている要件に準拠しROHCフレームワーク[RFC4995]のためのTCP / IP圧縮プロファイルを定義します。
Specifically, it describes a header compression scheme for TCP/IP header compression (ROHC-TCP) that is robust against packet loss and that offers enhanced capabilities, in particular for the compression of header fields including TCP options. The profile identifier for TCP/IP compression is 0x0006.
具体的には、パケットロスに対してロバストであり、それは、TCPオプションを含むヘッダフィールドの圧縮のために、特に、拡張機能を提供していますTCP / IPヘッダ圧縮（ROHC-TCP）のヘッダ圧縮方式を説明しています。 TCP / IP圧縮のためのプロファイル識別子は0x0006です。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This document reuses some of the terminology found in [RFC4995]. In addition, this document uses or defines the following terms:
この文書では、[RFC4995]で見つかった用語の一部を再利用します。また、このドキュメントでは、次の用語を使用していますか定義しています。
Base context
ベースコンテキスト
The base context is a context that has been validated by both the compressor and the decompressor. A base context can be used as the reference when building a new context using replication.
ベースコンテキストは、圧縮器と解凍器の両方によって検証されたコンテキストです。レプリケーションを使用して新しいコンテキストを構築するときにベースコンテキストを基準として使用することができます。
Base Context Identifier (Base CID)
ベースコンテキスト識別子（CIDベース）
The Base CID is the CID that identifies the base context, from which information needed for context replication can be extracted.
基本CIDは、コンテキストの複製に必要な情報を抽出することができ、そこからベースコンテキストを識別するCIDです。
Base header
ベースヘッダ
A compressed representation of the innermost IP and TCP headers of the uncompressed packet.
非圧縮パケットの最も内側のIPおよびTCPヘッダの圧縮された表現。
Chaining of items
アイテムの連鎖
A chain groups fields based on similar characteristics. ROHC-TCP defines chain items for static, dynamic, replicable, or irregular fields. Chaining is done by appending an item for each header e.g., to the chain in their order of appearance in the uncompressed packet. Chaining is useful to construct compressed headers from an arbitrary number of any of the protocol headers for which ROHC-TCP defines a compressed format.
同様の特性に基づいて鎖基フィールド。 ROHC-TCPは、静的、動的、複製、または不規則なフィールドのチェーン項目を定義します。連鎖は、非圧縮パケット内の出現の順序でチェーンに、例えば各ヘッダーの項目を追加することによって行われます。連鎖は、ROHC-TCPは圧縮形式を定義するためのプロトコルヘッダのいずれかの任意の数から圧縮ヘッダを構築することが有用です。
Context Replication (CR)
コンテキストレプリケーション（CR）
Context replication is the mechanism that establishes and initializes a new context based on another existing valid context (a base context). This mechanism is introduced to reduce the overhead of the context establishment procedure, and is especially useful for compression of multiple short-lived TCP connections that may be occurring simultaneously or near-simultaneously.
コンテキスト複製が確立し、別の既存の有効なコンテキスト（ベースコンテキスト）に基づいて新たなコンテキストを初期化する機構です。このメカニズムは、コンテキスト確立手順のオーバーヘッドを低減するために導入され、同時に又はほぼ同時に発生することができる複数の短命のTCP接続の圧縮のために特に有用です。
ROHC-TCP packet types
ROHC - TCPパケットタイプ
ROHC-TCP uses three different packet types: the Initialization and Refresh (IR) packet type, the Context Replication (IR-CR) packet type, and the Compressed packet (CO) type.
ROHC-TCPは、3つの異なるパケット・タイプの使用：初期化および更新（IR）パケットタイプを、コンテキストレプリケーション（IR-CR）パケットタイプ、および圧縮されたパケット（CO）タイプ。
Short-lived TCP transfer
短命のTCP転送
Short-lived TCP transfers refer to TCP connections transmitting only small amounts of packets for each single connection.
短命のTCP転送は、各単一の接続のためのパケットの少量のみを送信するTCP接続を参照してください。
This section provides some background information on TCP/IP header compression. The fundamentals of general header compression can be found in [RFC4995]. In the following subsections, two existing TCP/IP header compression schemes are first described along with a discussion of their limitations, followed by the classification of TCP/IP header fields. Finally, some of the characteristics of short-lived TCP transfers are summarized.
このセクションでは、TCP / IPヘッダー圧縮に関するいくつかの背景情報を提供します。一般的なヘッダ圧縮の基礎は、[RFC4995]に見出すことができます。以下のサブセクションでは、2つの既存のTCP / IPヘッダ圧縮方式は、最初のTCP / IPヘッダーフィールドの分類に続いて、それらの制限の議論と一緒に記載されています。最後に、短命のTCP転送の特性のいくつかが要約されています。
A behavior analysis of TCP/IP header fields is found in [RFC4413].
TCP / IPヘッダーフィールドの挙動解析は、[RFC4413]に見出されます。
Compressed TCP (CTCP) and IP Header Compression (IPHC) are two different schemes that may be used to compress TCP/IP headers. Both schemes transmit only the differences from the previous header in order to reduce the size of the TCP/IP header.
圧縮されたTCP（CTCP）とIPヘッダー圧縮（IPHC）は、TCP / IPヘッダを圧縮するために使用することができる二つの異なるスキームです。両方の方式は、TCP / IPヘッダのサイズを小さくするために、前のヘッダからの差分のみを送信します。
The CTCP [RFC1144] compressor detects transport-level retransmissions and sends a header that updates the context completely when they occur. While CTCP works well over reliable links, it is vulnerable when used over less reliable links as even a single packet loss results in loss of synchronization between the compressor and the decompressor. This in turn leads to the TCP receiver discarding all remaining packets in the current window because of a checksum error. This effectively prevents the TCP fast retransmit algorithm [RFC2581] from being triggered. In such a case, the compressor must wait until TCP times out and retransmits a packet to resynchronize.
CTCP [RFC1144]圧縮機は、トランスポート・レベルの再送信を検出し、それらが発生したときに完全にコンテキストを更新ヘッダを送信します。 CTCPは、信頼性の高いリンク上でうまく動作しながら、コンプレッサとデコンプレッサとの間の同期の損失であっても、単一のパケット損失の結果として信頼性の低いリンク上で使用される場合、それは脆弱です。これは、順番にあるため、チェックサム・エラーの現在のウィンドウ内の残りのすべてのパケットを破棄するTCP受信機につながります。これは、効果的にトリガされることからTCP高速再送アルゴリズム[RFC2581]を防ぎます。そのような場合には、コンプレッサーはアウトTCP時間まで待つと再同期するパケットを再送しなければなりません。
To reduce the errors due to the inconsistent contexts between compressor and decompressor when compressing TCP, IPHC [RFC2507] improves somewhat on CTCP by augmenting the repair mechanism of CTCP with a local repair mechanism called TWICE and with a link-layer mechanism based on negative acknowledgments to request a header that updates the context.
TCPを圧縮するときにコンプレッサとデコンプレッサとの間の一貫性のない状況に起因する誤差を低減することは、IPHC [RFC2507]は否定応答に基づいて、二度と呼ばれるローカル修復機構を、リンクレイヤ機構をCTCPの修復メカニズムを増強することによってCTCPに幾分改善しますコンテキストを更新ヘッダを要求します。
The TWICE algorithm assumes that only the Sequence Number field of TCP segments is changing with the deltas between consecutive packets being constant in most cases. This assumption is however not always true, especially when TCP Timestamps and SACK options are used.
TWICEアルゴリズムはTCPセグメントの唯一のシーケンス番号フィールドは、ほとんどの場合一定である連続したパケット間のデルタと変化していることを前提としています。この仮定は、TCPタイムスタンプとSACKオプションが使用されている場合は特に、常にしかし、真実ではありません。
The full header request mechanism requires a feedback channel that may be unavailable in some circumstances. This channel is used to explicitly request that the next packet be sent with an uncompressed header to allow resynchronization without waiting for a TCP timeout. In addition, this mechanism does not perform well on links with long round-trip times.
フルヘッダー要求機構は、いくつかの状況で使用できないことがあり、フィードバックチャネルを必要とします。このチャネルは、次のパケットがTCPのタイムアウトを待たずに再同期を可能にするために、非圧縮ヘッダで送られることを明示的に要求するために使用されます。また、このメカニズムは長い往復時間とのリンクでうまく実行されません。
Both CTCP and IPHC are also limited in their handling of the TCP options field. For IPHC, any change in the options field (caused by Timestamps or SACK, for example) renders the entire field uncompressible, while for CTCP, such a change in the options field effectively disables TCP/IP header compression altogether.
CTCPとIPHCどちらもTCPオプションフィールドの彼らの扱いに限定されています。 CTCPために、オプションフィールドにおけるそのような変化を効果的に完全にTCP / IPヘッダー圧縮を無効にしながらIPHCのために、オプションフィールドの任意の変化（例えば、タイムスタンプまたはSACKによって引き起こされる）は、フィールド全体が非圧縮にします。
Finally, existing TCP/IP compression schemes do not compress the headers of handshaking packets (SYNs and FINs). Compressing these packets may greatly improve the overall header compression ratio for the cases where many short-lived TCP connections share the same channel.
最後に、既存のTCP / IPの圧縮方式は、ハンドシェイクパケット（SYNのフィン）のヘッダを圧縮しないでください。これらのパケットを圧縮すると大幅に多くの短命のTCP接続が同じチャネルを共有する場合の全体的なヘッダ圧縮率を向上させることができます。
Header compression is possible due to the fact that there is much redundancy between header field values within packets, especially between consecutive packets. To utilize these properties for TCP/IP header compression, it is important to understand the change patterns of the various header fields.
ヘッダ圧縮が原因パケット内のヘッダフィールド値の間に大きな冗長性は、特に連続するパケットの間、存在するという事実のために可能です。 TCP / IPヘッダー圧縮のためにこれらの特性を利用するには、様々なヘッダフィールドの変化パターンを理解することが重要です。
All fields of the TCP/IP packet header have been classified in detail in [RFC4413]. The main conclusion is that most of the header fields can easily be compressed away since they seldom or never change. The following fields do however require more sophisticated mechanisms:
TCP / IPパケットヘッダのすべてのフィールドは、[RFC4413]で詳細に分類されています。主な結論は、彼らはほとんどまたは決して変わらないので、ヘッダフィールドのほとんどは簡単に離れて圧縮することができるということです。次のフィールドは、しかし、より洗練されたメカニズムを必要とします：
- IPv4 Identification (16 bits) - IP-ID - TCP Sequence Number (32 bits) - SN - TCP Acknowledgment Number (32 bits) - TCP Reserved ( 4 bits) - TCP ECN flags ( 2 bits) - ECN - TCP Window (16 bits)
- IPv4の識別（16ビット） - IP-ID - TCPシーケンス番号（32ビット） - SN - TCP確認応答番号（32ビット） - TCP予約（4ビット） - TCP ECNフラグ（2ビット） - ECN - TCPウィンドウ（ 16ビット）
- TCP Options o Maximum Segment Size (32 bits) - MSS o Window Scale (24 bits) - WSCALE o SACK Permitted (16 bits) o TCP SACK (80, 144, 208, or 272 bits) - SACK o TCP Timestamp (80 bits) - TS
- TCPオプション最大セグメントサイズ（32ビット）O - MSS Oウィンドウスケール（24ビット） - TCP SACK（80、144、208、または272ビット）O許可WSCALE 0のSACK（16ビット） - TCPタイムスタンプO SACK（80ビット） - TS
The assignment of IP-ID values can be done in various ways, usually one of sequential, sequential jump, or random, as described in Section 4.1.3 of [RFC4413]. Some IPv4 stacks do use a sequential assignment when generating IP-ID values but do not transmit the contents of this field in network byte order; instead, it is sent with the two octets reversed. In this case, the compressor can compress the IP-ID field after swapping the bytes. Consequently, the decompressor also swaps the bytes of the IP-ID after decompression to regenerate the original IP-ID. With respect to TCP compression, the analysis in [RFC4413] reveals that there is no obvious candidate among the TCP fields suitable to infer the IP-ID.
[RFC4413]のセクション4.1.3に記載したようにIP-ID値の割り当ては、逐次、逐次ジャンプ、またはランダムの通常1、さまざまな方法で行うことができます。いくつかのIPv4スタックがIP-ID値を生成するときに、順次割り当てを使用しますが、ネットワークバイトオーダーでこのフィールドの内容を送信することはありません。代わりに、それが逆の2つのオクテットで送信されます。この場合、圧縮機は、バイトを交換した後にIP-IDフィールドを圧縮することができます。したがって、解凍装置は、元のIP-IDを再生成するために減圧した後、IP-IDのバイトをスワップ。 TCP圧縮に関しては、[RFC4413]での分析は、IP-IDを推測するのに適したTCPフィールドのうち明らかな候補が存在しないことを明らかにする。
The change pattern of several TCP fields (Sequence Number, Acknowledgment Number, Window, etc.) is very hard to predict. Of particular importance to a TCP/IP header compression scheme is the understanding of the sequence and acknowledgment numbers [RFC4413].
いくつかのTCPフィールド（シーケンス番号、確認応答番号、ウィンドウなど）の変化パターンを予測することは非常に困難です。 TCP / IPヘッダ圧縮方式に特に重要なのシーケンスおよび確認応答番号[RFC4413]の理解です。
Specifically, the TCP Sequence Number can be anywhere within a range defined by the TCP Window at any point on the path (i.e., wherever a compressor might be deployed). Missing packets or retransmissions can cause the TCP Sequence Number to fluctuate within the limits of this window. The TCP Window also bounds the jumps in acknowledgment number.
具体的には、TCPシーケンス番号は、経路上の任意の点でTCPウィンドウによって定義された範囲内の任意の場所とすることができる（即ち、圧縮機が展開されるかもしれない限り）。欠落パケットまたは再送信は、TCPのシーケンス番号は、このウィンドウの範囲内で変動することがあります。 TCPウィンドウには、確認応答番号にジャンプの境界。
Another important behavior of the TCP/IP header is the dependency between the sequence number and the acknowledgment number. TCP connections can be either near-symmetrical or show a strong asymmetrical bias with respect to the data traffic. In the latter case, the TCP connections mainly have one-way traffic (Web browsing and file downloading, for example). This means that on the forward path (from server to client), only the sequence number is changing while the acknowledgment number remains constant for most packets; on the backward path (from client to server), only the acknowledgment number is changing and the sequence number remains constant for most packets. A compression scheme for TCP should thus have packet formats suitable for either cases, i.e., packet formats that can carry either only sequence number bits, only acknowledgment number bits, or both.
TCP / IPヘッダのもう一つの重要な行動は、シーケンス番号と確認番号の間の依存関係です。 TCP接続は、どちらかの近くに対称であるか、またはデータトラフィックに関して強い非対称バイアスを表示することができます。後者の場合、TCP接続は、主に（例えばWeb閲覧やファイルのダウンロード、）一方通行を持っています。これは、確認応答番号は、ほとんどのパケットのために一定のままで（サーバからクライアントへの）フォワードパス上で、唯一のシーケンス番号が変更されていることを意味します。 （クライアントからサーバーへの）復路上、唯一の承認番号が変更され、シーケンス番号は、ほとんどのパケットに対して一定のまま。 TCPの圧縮方式は、このようにのみシーケンス番号ビットのみ確認応答番号ビット、あるいはその両方を運ぶことができるいずれかの場合、すなわち、パケットフォーマットに適したパケットフォーマットを有するべきです。
In addition, TCP flows can be short-lived transfers. Short-lived TCP transfers will degrade the performance of header compression schemes that establish a new context by initially sending full headers. Multiple simultaneous or near simultaneous TCP connections may exhibit much similarity in header field values and context values among each other, which would make it possible to reuse information between flows when initializing a new context. A mechanism to this end, context replication [RFC4164], makes the context establishment step faster and more efficient, by replicating part of an existing context to a new flow. The conclusion from [RFC4413] is that part of the IP sub-context, some TCP fields, and some context values can be replicated since they seldom change or change with only a small jump.
また、TCPフローは短命転送することができます。短命のTCP転送は、最初は完全なヘッダを送信することによって、新しいコンテキストを確立し、ヘッダ圧縮スキームの性能が低下します。同時複数または同時TCP接続の近くに新しいコンテキストを初期化するときのフロー間で情報を再利用することを可能にするであろう、お互いの間のヘッダフィールド値とコンテキスト値にあまり類似性を示すことができます。この目的のためのメカニズムは、コンテキスト複製[RFC4164]は、新しいフローに既存のコンテキストの一部を複製することによって、コンテキスト確立工程より速く、より効率的にします。 [RFC4413]からの結論は、IPサブコンテキスト、いくつかのTCPフィールドの一部であり、それらはほとんど変化しないか、またはわずかにジャンプに伴って変化するので、いくつかのコンテキスト値を複製することができます。
ROHC-TCP also compresses the following headers: IPv6 Destination Options header [RFC2460], IPv6 Routing header [RFC2460], IPv6 Hop-by-Hop Options header [RFC2460], Authentication Header (AH) [RFC4302], NULL-encrypted Encapsulating Security Payload (ESP) header [RFC4303], Generic Routing Encapsulation (GRE) [RFC2784][RFC2890] and the Minimal Encapsulation header (MINE) [RFC2004].
ROHC-TCPは、次のヘッダーを圧縮：IPv6宛先オプションは、[RFC2460]、IPv6ルーティングヘッダ[RFC2460]、IPv6のホップバイホップオプションヘッダ[RFC2460]、認証ヘッダ（AH）[RFC4302]、NULL暗号化カプセル化セキュリティヘッダペイロード（ESP）ヘッダ[RFC4303]、総称ルーティングカプセル化（GRE）[RFC2784]、[RFC2890]と最小カプセル化ヘッダ（MINE）[RFC2004]。
Headers specific to Mobile IP (for IPv4 or IPv6) do not receive any special treatment in this document, for reasons similar to those described in [RFC3095].
（IPv4またはIPv6のための）モバイルIPに特有のヘッダーは[RFC3095]で説明したものと同様の理由により、この文書に記載されている特別な治療を受けていません。
ROHC-TCP uses the ROHC protocol as described in [RFC4995]. ROHC-TCP supports context replication as defined in [RFC4164]. Context replication can be particularly useful for short-lived TCP flows [RFC4413].
[RFC4995]に記載されているようにROHC-TCPは、ROHCプロトコルを使用します。 [RFC4164]で定義されているようROHC-TCPは、コンテキストのレプリケーションをサポートしています。コンテキストの複製が短命TCPのために特に有用である可能性がある[RFC4413]を流れています。
Header compression with ROHC can be conceptually characterized as the interaction of a compressor with a decompressor state machine. The compressor's task is to minimally send the information needed to successfully decompress a packet, based on a certain confidence regarding the state of the decompressor context.
ROHCとヘッダ圧縮は、概念的に解凍器状態機械と圧縮機との相互作用として特徴づけることができます。コンプレッサーのタスクは最小限に成功したデコンプレッサのコンテキストの状態に関する一定の信頼に基づいてパケットを、解凍するために必要な情報を送信することです。
For ROHC-TCP compression, the compressor normally starts compression with the initial assumption that the decompressor has no useful information to process the new flow, and sends Initialization and Refresh (IR) packets. Alternatively, the compressor may also support Context Replication (CR) and use IR-CR packets [RFC4164], which attempts to reuse context information related to another flow.
ROHC-TCP圧縮のため、圧縮機は通常減圧装置が新たなフローを処理するために有用な情報を持っていないこと初期仮定して圧縮を開始し、初期化および更新（IR）パケットを送信します。あるいは、コンプレッサは、コンテキストレプリケーション（CR）をサポートし、他のフローに関連するコンテキスト情報を再利用しようとIR-CRパケット[RFC4164]を使用することができます。
The compressor can then adjust the compression level based on its confidence that the decompressor has the necessary information to successfully process the Compressed (CO) packets that it selects. In other words, the task of the compressor is to ensure that the decompressor operates in the state that allows decompression of the most efficient CO packet(s), and to allow the decompressor to move to that state as soon as possible otherwise.
圧縮機は、次に、減圧装置が正常にそれが選択圧縮（CO）パケットを処理するために必要な情報を持っていることを、その信頼度に基づいて圧縮レベルを調整することができます。換言すれば、圧縮機のタスクは、減圧装置が最も効率的なCOパケット（単数または複数）の伸長を可能にする状態で動作することを保証するために、及び解凍器がそうでなければ、できるだけ早くその状態に移行できるようにすることです。
The ROHC-TCP profile can be used in environments with or without feedback capabilities from decompressor to compressor. ROHC-TCP however assumes that if a ROHC feedback channel is available and if this channel is used at least once by the decompressor for a specific ROHC-TCP context, this channel will be used during the entire compression operation for that context. If the feedback channel disappears, compression should be restarted.
ROHC-TCPプロファイルは、圧縮機への解凍器からのフィードバック機能を持つ又は無しの環境で使用することができます。 ROHC-TCPしかしROHCフィードバックチャネルが利用可能であり、このチャネルは、特定のROHC-TCPコンテキストのデコンプレッサによって少なくとも一度使用された場合、このチャネルは、そのコンテキストの全体の圧縮動作中に使用される場合と仮定しています。フィードバックチャネルが消えた場合、圧縮は再起動する必要があります。
The reception of either positive acknowledgment (ACKs) or negative acknowledgment (NACKs) establishes the feedback channel from the decompressor for the context for which the feedback was received. Once there is an established feedback channel for a specific context, the compressor should make use of this feedback to estimate the current state of the decompressor. This helps in increasing the compression efficiency by providing the information needed for the compressor to achieve the necessary confidence level.
肯定応答（ACKの）または否定応答（NACK信号）のいずれかの受信フィードバックが受信されたのコンテキストのために解凍器からのフィードバックチャネルを確立します。特定のコンテキストのために確立されたフィードバックチャネルが存在すると、圧縮機は、減圧装置の現在の状態を推定するために、このフィードバックを利用するべきです。これは、必要な信頼性のレベルを達成するために、圧縮機の必要な情報を提供することにより、圧縮効率を高めるのに役立ちます。
The ROHC-TCP feedback mechanism is limited in its applicability by the number of (least significant bit (LSB) encoded) master sequence number (MSN) (see Section 6.1.1) bits used in the FEEDBACK-2 format (see Section 8.3). It is not suitable for a decompressor to use feedback altogether where the MSN bits in the feedback could wrap around within one round-trip time. Instead, unidirectional operation -- where the compressor periodically sends larger context-updating packets -- is more appropriate.
ROHC-TCPフィードバック機構はFEEDBACK-2形式（セクション8.3を参照）で使用される数（最下位ビット（LSB）符号化された）マスタシーケンス番号（MSN）（セクション6.1.1を参照）ビットによってその適用が制限されます。フィードバックにおけるMSNビットが1往復時間内に折り返すことができどこ解凍器は完全なフィードバックを使用することは適切ではありません。代わりに、一方向操作 - 圧縮機は、定期的に、より大きなコンテキスト更新パケットを送信する - より適切です。
The packet formats and encoding methods used for ROHC-TCP are defined using the formal notation [RFC4997]. The formal notation is used to provide an unambiguous representation of the packet formats and a clear definition of the encoding methods.
ROHC-TCPに使用されるパケットフォーマット及び符号化方法は、正式な表記法[RFC4997]を使用して定義されています。正式な表記は、パケットフォーマット及び符号化方法の明確な定義の明確な表現を提供するために使用されます。
The TCP options in ROHC-TCP are compressed using a list compression encoding that allows option content to be established so that TCP options can be added to the context without having to send all TCP options uncompressed.
ROHC-TCPでTCPオプションはTCPオプションは、圧縮されていないすべてのTCPオプションを送信することなく、コンテキストに追加することができるように、オプションの内容を確立することを可能にするリストの圧縮符号化を用いて圧縮されます。
ROHC-TCP compresses the extension headers as listed in Section 3.2. These headers are treated exactly as other headers and thus have a static chain, a dynamic chain, an irregular chain, and a chain for context replication (Section 6.2).
3.2節に記載されているようにROHC-TCPは、拡張ヘッダを圧縮します。これらのヘッダーは、正確に他のヘッダーとして扱われ、従って静的鎖、動的鎖、不規則な鎖、およびコンテキスト複製用チェーン（6.2）を有しています。
This means that headers appearing in or disappearing from the flow being compressed will lead to changes to the static chain. However, the change pattern of extension headers is not deemed to impair compression efficiency with respect to this design strategy.
これは圧縮されて流れからに登場するか消えるのヘッダーは、静的チェーンへの変更につながることを意味します。しかし、拡張ヘッダの変更パターンは、この設計戦略に対する圧縮効率を損なうものではありません。
The following table illustrates typical compression ratios that can be expected when using ROHC-TCP and IPHC [RFC2507].
次の表は、ROHC-TCPおよびIPHC [RFC2507]を使用するときに期待することができる典型的な圧縮率を示します。
The figures in the table assume that the compression context has already been properly initialized. For the TS option, the Timestamp is assumed to change with small values. All TCP options include a suitable number of No Operation (NOP) options [RFC0793] for padding and/or alignment. Finally, in the examples for IPv4, a sequential IP-ID behavior is assumed.
表中の数字は、圧縮コンテキストがすでに適切に初期化されていることを前提としています。 TSオプションの場合、タイムスタンプは小さな値で変更することが想定されます。すべてのTCPオプションはパディング及び/又は位置合わせのためのノーオペレーション（NOP）オプション[RFC0793]の適切な数を含みます。最後に、IPv4の例では、シーケンシャルIP-IDの挙動が想定されます。
Total Header Size (octets) ROHC-TCP IPHC Unc. DATA ACK DATA ACK IPv4+TCP+TS 52 8 8 18 18 IPv4+TCP+TS 52 7 6 16 16 (1) IPv6+TCP+TS 72 8 7 18 18 IPv6+TCP+no opt 60 6 5 6 6 IPv6+TCP+SACK 80 - 15 - 80 (2) IPv6+TCP+SACK 80 - 9 - 26 (3)
総ヘッダサイズ（オクテット）ROHC-TCP IPHC UNC。 DATA ACK DATA ACKのIPv4 + TCP + TS 52 8 8 18 18のIPv4 + TCP + TS 52 7 6 16 16（1）は、IPv6 + TCP + TS 72の8 7 18 18のIPv6 + TCP +無OPT 60の6 5 6 6つのIPv6 + TCP + SACK 80 - 14 - 80（2）は、IPv6 + TCP + SACK 80から9 - 図26（3）
(1) The payload size of the data stream is constant. (2) The SACK option appears in the header, but was not present in the previous packet. Two SACK blocks are assumed. (3) The SACK option appears in the header, and was also present in the previous packet (with different SACK blocks). Two SACK blocks are assumed.
（1）データストリームのペイロードサイズは一定です。 （2）SACKオプションがヘッダーに表示されますが、前のパケットには存在しませんでした。二つのSACKブロックを想定しています。 （3）SACKオプションがヘッダに表示され、（異なるSACKブロックを有する）前のパケットにも存在しました。二つのSACKブロックを想定しています。
The table below illustrates the typical initial compression ratios for ROHC-TCP and IPHC. The data stream in the example is assumed to be IPv4+TCP, with a sequential behavior for the IP-ID. The following options are assumed present in the SYN packet: TS, MSS, and WSCALE, with an appropriate number of NOP options.
以下の表は、ROHC-TCPおよびIPHCのための典型的な最初の圧縮比を示します。例のデータストリームは、IP-IDのためのシーケンシャル動作と、IPv4の+ TCPであると仮定されます。 NOPオプションの適切な数で、TS、MSS、およびWSCALE：以下のオプションは、SYNパケット内に存在すると仮定されます。
Total Header Size (octets) Unc. ROHC-TCP IPHC 1st packet (SYN) 60 49 60 2nd packet 52 12 52
総ヘッダサイズ（オクテット）UNC。 ROHC - TCP IPHCの第一パケット（SYN）60 49 60第二のパケット52 12 52
The figures in the table assume that the compressor has received an acknowledgment from the decompressor before compressing the second packet, which can be expected when feedback is used in ROHC-TCP. This is because in the most common case, the TCP ACKs are expected to take the same return path, and because TCP does not send more packets until the TCP SYN packet has been acknowledged.
表中の数字は、圧縮機がフィードバックがROHC-TCPで使用される場合に期待することができる第2のパケットを圧縮する前に解凍装置から肯定応答を受信したと仮定する。これは、最も一般的なケースでは、TCPのACKが同じリターンパスを取ることが期待されているためであり、TCPは、より多くのパケットを送信しないため、TCP SYNパケットが認識されているまで。
The static context of ROHC-TCP flows can be initialized in either of two ways:
ROHC - TCPフローの静的文脈は、2つの方法のいずれかで初期化することができます。
1. By using an IR packet as in Section 7.1, where the profile number is 0x06 and the static chain ends with the static part of a TCP header.
プロファイル番号は0x06であり、静的チェーンは、TCPヘッダの静的部分で終わるセクション7.1、同様にIRパケットを用いることにより1。
2. By replicating an existing context using the mechanism defined by [RFC4164]. This is done with the IR-CR packet defined in Section 7.2, where the profile number is 0x06.
[RFC4164]で定義されたメカニズムを使用して、既存のコンテキストを複製することによって2。これは、プロファイルの数が0x06であるセクション7.2で定義されたIR-CRパケットを用いて行われます。
The task of the compressor is to determine what data must be sent when compressing a TCP/IP packet, so that the decompressor can successfully reconstruct the original packet based on its current state. The selection of the type of compressed header to send thus depends on a number of factors, including:
コンプレッサーのタスクは、デコンプレッサが正常に現在の状態に基づいて元のパケットを再構築することができるように、TCP / IPパケットを圧縮する際にデータが送信されなければならないかを決定することです。このように送信する圧縮ヘッダの種類の選択は、以下を含む、多くの要因に依存します。
o The change behavior of header fields in the flow, e.g., conveying the necessary information within the restrictions of the set of available packet formats.
利用可能なパケットフォーマットのセットの制限内で、必要な情報を伝達する、例えば、フローのヘッダーフィールドの変化挙動O。
o The compressor's level of confidence regarding decompressor state, e.g., by selecting header formats updating the same type of information for a number of consecutive packets or from the reception of decompressor feedback (ACKs and/or NACKs).
連続するパケットの数または解凍装置からのフィードバックを受信してから同じ種類の情報（ACKおよび/またはNACKを）更新ヘッダフォーマットを選択することにより、例えば、デコンプレッサの状態に関する信頼の圧縮のレベル、O。
o Additional robustness required for the flow, e.g., periodic refreshes of static and dynamic information using IR and IR-DYN packets when decompressor feedback is not expected.
Oフローに必要な追加の堅牢性は、例えば、IR及びIR-DYNパケットを使用して、静的および動的情報の定期的な更新は、減圧装置フィードバックが予想されていない場合。
The impact of these factors on the compressor's packet type selection is described in more detail in the following subsections.
コンプレッサのパケットタイプの選択にこれらの要因の影響は、以下のサブセクションにおいてより詳細に記載されています。
In this section, a "higher compression state" means that less data will be sent in compressed packets, i.e., smaller compressed headers are used, while a lower compression state means that a larger amount of data will be sent using larger compressed headers.
このセクションでは、「より高い圧縮状態は、」低い圧縮状態は、データのより大きな量が大きく圧縮ヘッダを使用して送信されることを意味する少ないデータ、すなわち、より小さな圧縮ヘッダが使用され、圧縮されたパケットで送信されることを意味します。
The optimistic approach is the principle by which a compressor sends the same type of information for a number of packets (consecutively or not) until it is fairly confident that the decompressor has received the information. The optimistic approach is useful to ensure robustness when ROHC-TCP is used to compress packet over lossy links.
楽観的アプローチは、減圧装置が情報を受信したことをかなり確信するまで圧縮機はパケット（連続か）の数の同じ種類の情報を送信する原理です。楽観的なアプローチは、ROHC-TCPは、損失の多いリンク上のパケットを圧縮するために使用されたときに堅牢性を確保するために有用です。
Therefore, if field X in the uncompressed packet changes value, the compressor MUST use a packet type that contains an encoding for field X until it has gained confidence that the decompressor has received at least one packet containing the new value for X. The compressor SHOULD choose a compressed format with the smallest header that can convey the changes needed to fulfill the optimistic approach condition used.
非圧縮パケット内のフィールドXには値を変更した場合、したがって、圧縮機は、減圧装置が圧縮機SHOULD Xの新しい値を含む少なくとも一つのパケットを受信したという確信を得たまで、フィールドXのエンコーディングを含むパケットタイプを使用しなければなりません使用楽観アプローチの条件を満たすために必要な変更を伝えることができる最小のヘッダを持つ圧縮形式を選択します。
When the optimistic approach is used, there will always be a possibility of decompression failures since the decompressor may not have received sufficient information for correct decompression.
楽観的アプローチが使用されるとき減圧装置が正しい減圧のための十分な情報を受信していないかもしれないので、常に解凍失敗の可能性が存在することになります。
Therefore, until the decompressor has established a feedback channel, the compressor SHOULD periodically move to a lower compression state and send IR and/or IR-DYN packets. These refreshes can be based on timeouts, on the number of compressed packets sent for the flow, or any other strategy specific to the implementation. Once the feedback channel is established, the decompressor MAY stop performing periodic refreshes.
減圧装置がフィードバックチャネルを確立するまでそのため、圧縮機は、定期的に低い圧縮状態に移動し、IR及び/又はIR-DYNパケットを送信すべきです。これらのリフレッシュは、フローのために送られ圧縮されたパケットの数、または実装に固有の他の戦略に、タイムアウトに基づくことができます。フィードバック・チャネルが確立されると、デコンプレッサは、定期的なリフレッシュを行って停止することがあります。
The semantics of feedback messages, acknowledgments (ACKs) and negative acknowledgments (NACKs or STATIC-NACKs), are defined in Section 5.2.4.1 of [RFC4995].
フィードバック・メッセージは、肯定応答（ACKの）および否定応答（NACKの又はSTATIC-NACK信号）の意味は、[RFC4995]のセクション5.2.4.1で定義されています。
The compressor MAY use acknowledgment feedback (ACKs) to move to a higher compression state.
圧縮機はより高い圧縮状態へ移動する肯定応答フィードバック（ACKを）を使用することができます。
Upon reception of an ACK for a context-updating packet, the compressor obtains confidence that the decompressor has received the acknowledged packet and that it has observed changes in the packet flow up to the acknowledged packet.
コンテキスト更新パケットに対するACKを受信すると、圧縮機は、減圧装置が承認パケットを受信したという確信を得て、それはパケットの変更が承認パケットまで流れ観察されたこと。
This functionality is optional, so a compressor MUST NOT expect to get such ACKs, even if a feedback channel is available and has been established for that flow.
この機能はオプションであり、圧縮機は、フィードバック・チャネルが利用可能であり、その流れのために確立された場合でも、そのようなACKを得ると予想してはいけません。
The compressor uses feedback from the decompressor to move to a lower compression state (NACKs).
コンプレッサは、低い圧縮状態（のNACK）に移動する解凍器からのフィードバックを使用します。
On reception of a NACK feedback, the compressor SHOULD:
NACKフィードバックの受信に、圧縮する必要があります。
o assume that only the static part of the decompressor is valid, and
O解凍器の静的な部分が有効であることを前提とし、
o re-send all dynamic information (via an IR or IR-DYN packet) the next time it compresses a packet for the indicated flow
Oそれは指示流量のためにパケットを圧縮する次の時間（IRまたはIR-DYNパケットを介して）すべての動的情報を再送信します
unless it has confidence that information sent after the packet being acknowledged already provides a suitable response to the NACK feedback. In addition, the compressor MAY use a CO packet carrying a 7-bit Cyclic Redundancy Check (CRC) if it can determine with enough confidence what information provides a suitable response to the NACK feedback.
それは自信を持っていない限り、パケットが確認された後に送信される情報は、既にNACKフィードバックに適した応答を提供すること。それはNACKフィードバックに適切な応答を提供するどのような情報を十分に自信を持って決定することができる場合に加えて、圧縮機は7ビット巡回冗長検査（CRC）を有するCOパケットを使用するかもしれません。
On reception of a STATIC-NACK feedback, the compressor SHOULD:
STATIC-NACKフィードバックの受信に、圧縮する必要があります。
o assume that the decompressor has no valid context, and
O解凍器が有効なコンテキストを持っていないと仮定し、
o re-send all static and all dynamic information (via an IR packet) the next time it compresses a packet for the indicated flow
O（IRパケットを介して）ことが示されたフローのためのパケットを圧縮次回すべての静的および動的な情報をすべて再送信します
unless it has confidence that information sent after the packet that is being acknowledged already provides a suitable response to the STATIC-NACK feedback.
それはすでに認知されているパケットの後に送信される情報は、STATIC-NACKフィードバックに適した応答を提供することを自信を持っていない限り。
A compressor MAY support context replication by implementing the additional compression and feedback logic defined in [RFC4164].
圧縮機は、[RFC4164]で定義された追加の圧縮およびフィードバック論理回路を実装することにより、コンテキストの複製をサポートするかもしれません。
The three states of the decompressor are No Context (NC), Static Context (SC), and Full Context (FC). The decompressor starts in its lowest compression state, the NC state. Successful decompression will always move the decompressor to the FC state. The decompressor state machine normally never leaves the FC state once it has entered this state; only repeated decompression failures will force the decompressor to transit downwards to a lower state.
解凍器の3つの状態が何コンテキスト（NC）、静的コンテキスト（SC）、および完全なコンテキスト（FC）ではありません。デコンプレッサは最も低い圧縮状態、NCの状態で起動します。解凍の成功は常に、FC状態にデコンプレッサを移動します。それがこの状態に入った後、デコンプレッサ・ステート・マシンは、通常、FC状態を離れることはありません。だけ繰り返し減圧障害が低い状態に遷移下方にデコンプレッサを強制します。
Below is the state machine for the decompressor. Details of the transitions between states and decompression logic are given in the subsections following the figure.
以下は、デコンプレッサのためのステートマシンです。州と解凍ロジック間の移行の詳細については、以下の図のサブセクションに記載されています。
Success
+-->------>------>------>------>------>--+
| |
No Static | No Dynamic Success | Success
+-->--+ | +-->--+ +--->----->---+ +-->--+
| | | | | | | | |
| v | | v | v | v
+-----------------+ +---------------------+ +-------------------+
| No Context (NC) | | Static Context (SC) | | Full Context (FC) |
+-----------------+ +---------------------+ +-------------------+
^ | ^ |
| Static Context | | Context Damage Assumed |
| Damage Assumed | | |
+-----<------<------<-----+ +-----<------<------<-----+
When decompressing an IR or an IR-DYN packet, the decompressor MUST validate the integrity of the received header using CRC-8 validation [RFC4995]. If validation fails, the packet MUST NOT be delivered to upper layers.
IRまたはIR-DYNパケットを解凍するとき、デコンプレッサは、CRC-8検証[RFC4995]を使用して、受信したヘッダの完全性を検証する必要があります。検証が失敗した場合、パケットは上位層に配信されてはなりません。
Upon receiving an IR-CR packet, the decompressor MUST perform the actions as specified in [RFC4164].
[RFC4164]で指定されるようにIR-CRパケットを受信すると、デコンプレッサは、アクションを実行しなければなりません。
When decompressing other packet types (e.g., CO packets), the decompressor MUST validate the outcome of the decompression attempt using CRC verification [RFC4995]. If verification fails, a decompressor implementation MAY attempt corrective or repair measures on the packet, and the result of any attempt MUST be validated using the CRC verification; otherwise, the packet MUST NOT be delivered to upper layers.
他のパケットタイプ（例えば、COパケット）を解凍するとき、逆圧縮器は、CRC検証[RFC4995]を使用して解凍試行の結果を検証する必要があります。検証が失敗した場合、デコンプレッサの実装では、パケットの是正や修理対策を試みたり、任意の試みの結果は、CRC検証を使用して検証する必要があります。そうでない場合、パケットは上位層に配信されてはなりません。
When the CRC-8 validation or the CRC verification of the received header is successful, the decompressor SHOULD update its context with the information received in the current header; the decompressor then passes the reconstructed packet to the system's network layer. Otherwise, the decompressor context MUST NOT be updated.
CRC-8検証や受信したヘッダのCRC検証が成功した場合、デコンプレッサは、現在のヘッダ内の受信された情報とそのコンテキストを更新すべきです。デコンプレッサは、システムのネットワーク層に再構築されたパケットを渡します。それ以外の場合は、デコンプレッサのコンテキストが更新されてはなりません。
If the received packet is older than the current reference packet, e.g., based on the master sequence number (MSN) in the compressed packet, the decompressor MAY refrain from updating the context using the information received in the current packet, even if the correctness of its header was successfully verified.
受信パケットが圧縮されたパケットのマスタシーケンス番号（MSN）に基づいて、現在の基準パケット、例えば、より古い場合、減圧装置は、現在のパケットで受信した情報を使用してコンテキストを更新することを控える得るにも正当の場合そのヘッダが正常に確認されました。
All header formats carry a CRC and are context updating. A packet for which the CRC succeeds updates the reference values of all header fields, either explicitly (from the information about a field carried within the compressed header) or implicitly (fields that are inferred from other fields).
すべてのヘッダ・フォーマットは、CRCを搬送し、コンテキスト更新しています。 CRCが成功したためにパケットが明示的または暗黙（他のフィールドから推測されたフィールド）（圧縮ヘッダ内で運ばフィールドに関する情報から）、全てのヘッダフィールドの基準値を更新します。
The decompressor may assume that some or the entire context is invalid, following one or more failures to validate or verify a header using the CRC. Because the decompressor cannot know the exact reason(s) for a CRC failure or what field caused it, the validity of the context hence does not refer to what exact context entry is deemed valid or not.
デコンプレッサは、一部または全体のコンテキストがCRCを使用してヘッダを検証または確認するための1つまたは複数の障害以下、無効であると仮定することができます。デコンプレッサは、CRCの失敗の正確な理由（複数可）を知ることができないか、どのようなフィールドがそれを引き起こしたので、コンテキストの有効性は、それゆえ有効かないとみなされ、正確なものをコンテキストエントリを指すものではありません。
Validity of the context rather relates to the detection of a problem with the context. The decompressor first assumes that the type of information that most likely caused the failure(s) is the state that normally changes for each packet, i.e., context damage of the dynamic part of the context. Upon repeated failures and unsuccessful repairs, the decompressor then assumes that the entire context, including the static part, needs to be repaired, i.e., static context damage.
コンテキストの有効性はなく、コンテキストに問題の検出に関する。減圧装置は最初に最も可能性の高い障害（複数可）を引き起こした情報の種類は、通常、各パケットのためのコンテキストの動的部分の、すなわち、コンテキストの損傷を変更する状態であると仮定する。繰り返し失敗と失敗修理時に、減圧装置は、静的部分を含む全体のコンテキストは、、すなわち、静的コンテキストの損傷を修復する必要があることを前提としています。
Context Damage Detection
コンテキスト損傷検出
The assumption of context damage means that the decompressor will not attempt decompression of a CO header that carries a 3-bit CRC, and only attempt decompression of IR, IR-DYN, or IR-CR headers or CO headers protected by a CRC-7.
コンテキスト損傷の仮定は、減圧装置が3ビットのCRCを運ぶCOヘッダの復元を試み、そしてのみCRC-7によって保護IR、IR-DYN、またはIR-CRヘッダーまたはCOヘッダの解凍を試みないことを意味します。
Static Context Damage Detection
静的コンテキストの損傷検出
The assumption of static context damage means that the decompressor refrains from attempting decompression of any type of header other than the IR header.
静的コンテクスト損傷の仮定は、IRヘッダ以外のヘッダの任意のタイプの解凍を試みるから解凍控えることを意味します。
How these assumptions are made, i.e., how context damage is detected, is open to implementations. It can be based on the residual error rate, where a low error rate makes the decompressor assume damage more often than on a high-rate link.
これらの仮定がなされている方法、すなわち、文脈損害が検出されたか、実装に開放されています。これは、低エラーレートはデコンプレッサは、より頻繁に高速リンク上よりも被害を想定せ、残留誤り率に基づくことができます。
The decompressor implements these assumptions by selecting the type of compressed header for which it may attempt decompression. In other words, validity of the context refers to the ability of a decompressor to attempt or not attempt decompression of specific packet types.
デコンプレッサは、それが圧縮解除を試みることができるため、圧縮ヘッダの種類を選択することにより、これらの仮定を実現します。換言すれば、コンテキストの有効性は、特定のパケットタイプの復元を試行しようかする減圧装置の能力を指します。
Initially, while working in the No Context (NC) state, the decompressor has not yet successfully decompressed a packet.
いいえ文脈（NC）状態での作業中に最初は、デコンプレッサは、まだパケットを正常に解凍されていません。
Allowing decompression:
解凍を許可します：
In the NC state, only packets carrying sufficient information on the static fields (IR and IR-CR packets) can be decompressed; otherwise, the packet MUST NOT be decompressed and MUST NOT be delivered to upper layers.
NC状態では、唯一の解凍することができる静的フィールド（IR及びIR-CRパケット）に関する十分な情報を搬送するパケット。そうでない場合、パケットは、解凍してはならないし、上位層に配信されてはなりません。
Feedback logic:
フィードバック・ロジック：
In the NC state, the decompressor should send a STATIC-NACK if a packet of a type other than IR is received, or if decompression of an IR packet has failed, subject to the feedback rate limitation as described in Section 5.3.2
IR以外のタイプのパケットを受信した場合NC状態において、圧縮解除装置はSTATIC-NACKを送信しなければならない、またはIRパケットの復元が失敗した場合、フィードバックレート制限は、セクション5.3.2に記載のように
Once a packet has been validated and decompressed correctly, the decompressor MUST transit to the FC state.
パケットが検証され、正常に解凍された後、FC状態に解凍MUSTトランジット。
When the decompressor is in the Static Context (SC) state, only the static part of the decompressor context is valid.
解凍器は静的文脈（SC）状態にある場合、減圧装置文脈の唯一静的部分は有効です。
From the SC state, the decompressor moves back to the NC state if static context damage is detected.
静的コンテキストの損傷が検出された場合、SC状態から、解凍器は、バックNC状態に移動します。
Allowing decompression:
解凍を許可します：
In the SC state, packets carrying sufficient information on the dynamic fields covered by an 8-bit CRC (e.g., IR and IR-DYN) or CO packets covered by a 7-bit CRC can be decompressed; otherwise, the packet MUST NOT be decompressed and MUST NOT be delivered to upper layers.
SC状態で、伸長させることができる7ビットのCRCにより覆われた8ビットのCRC（例えば、IR及びIR-DYN）またはCOパケットによって覆わ動的フィールドの十分な情報を搬送するパケット。そうでない場合、パケットは、解凍してはならないし、上位層に配信されてはなりません。
Feedback logic:
フィードバック・ロジック：
In the SC state, the decompressor should send a STATIC-NACK if CRC validation of an IR/IR-DYN/IR-CR fails and static context damage is assumed. If any other packet type is received, the decompressor should send a NACK. Both of the above cases are subject to the feedback rate limitation as described in Section 5.3.2.
SC状態において、IRのCRC検証場合に減圧装置がSTATIC-NACKを送信しなければならない/ IR-DYN / IR-CRは失敗し、静的コンテクスト損傷が想定されます。他のパケットタイプを受信した場合、デコンプレッサは、NACKを送信する必要があります。第5.3.2節で説明したように、上記ケースの両方がフィードバックレート制限の対象となっています。
Once a packet has been validated and decompressed correctly, the decompressor MUST transit to the FC state.
パケットが検証され、正常に解凍された後、FC状態に解凍MUSTトランジット。
In the Full Context (FC) state, both the static and the dynamic parts of the decompressor context are valid. From the FC state, the decompressor moves back to the SC state if context damage is detected.
フルコンテキスト（FC）状態では、静的および解凍器コンテクストの動的部分の両方が有効です。コンテキストの損傷が検出された場合FC状態から、解凍器はSC状態に戻ります。
Allowing decompression:
解凍を許可します：
In the FC state, decompression can be attempted regardless of the type of packet received.
FC状態では、減圧にかかわらず、受信したパケットの種類を図ることができます。
Feedback logic:
フィードバック・ロジック：
In the FC state, the decompressor should send a NACK if the decompression of any packet type fails and context damage is assumed, subject to the feedback rate limitation as described in Section 5.3.2.
任意のパケットタイプの減圧が失敗し、第5.3.2節に記載したように、コンテキストの損傷は、フィードバック・レート制限の対象とするとFC状態において、減圧装置は、NACKを送信しなければなりません。
The decompressor MAY send positive feedback (ACKs) to initially establish the feedback channel for a particular flow. Either positive feedback (ACKs) or negative feedback (NACKs) establishes this channel.
減圧装置は最初に特定のフローのためのフィードバックチャネルを確立するために正のフィードバック（ACKを）を送信することができます。正帰還（のACK）または負のフィードバック（NACK信号）のいずれかは、このチャネルを確立します。
Once the feedback channel is established, the decompressor is REQUIRED to continue sending NACKs or STATIC-NACKs for as long as the context is associated with the same profile, in this case with profile 0x0006, as per the logic defined for each state in Section 5.3.1.
フィードバック・チャネルが確立されると、デコンプレッサはセクション5.3に各状態に対して定義されたロジックに従って、プロファイル0x0006この場合に限りコンテキストが同じプロファイルに関連付けられるようにするためのNACK又はSTATIC-NACKを送信し続けることが要求されます0.1。
The decompressor MAY send ACKs upon successful decompression of any packet type. In particular, when a packet carrying a significant context update is correctly decompressed, the decompressor MAY send an ACK.
デコンプレッサは、任意のパケットタイプの解凍の成功時にACKを送るかもしれません。特に、重要なコンテキスト更新を運ぶパケットが正しく解凍されるとき、デコンプレッサは、ACKを送信することができます。
The decompressor should limit the rate at which it sends feedback, for both ACKs and STATIC-NACK/NACKs, and should avoid sending unnecessary duplicates of the same type of feedback message that may be associated to the same event.
解凍装置は、ACK及びSTATIC-NACK / NACKの両方のために、フィードバックを送信する速度を制限する必要があり、同一のイベントに関連付けることができるフィードバックメッセージの同じ種類の不必要な重複を送信避けるべきです。
ROHC-TCP supports context replication; therefore, the decompressor MUST implement the additional decompressor and feedback logic defined in [RFC4164].
ROHC - TCPは、コンテキストのレプリケーションをサポートしています。したがって、減圧装置は、[RFC4164]で定義された追加の解凍器とフィードバックロジックを実装しなければなりません。
In ROHC-TCP, a number of control fields are used by the decompressor in its interpretation of the format of the packets received from the compressor.
ROHC-TCPでは、制御フィールドの数は、圧縮機から受信したパケットのフォーマットの解釈に減圧装置によって使用されます。
A control field is a field that is transmitted from the compressor to the decompressor, but is not part of the uncompressed header. Values for control fields can be set up in the context of both the compressor and the decompressor. Once established at the decompressor, the values of these fields should be kept until updated by another packet.
制御フィールドは、デコンプレッサに圧縮機から送信されるフィールドであるが、非圧縮ヘッダの一部ではありません。制御フィールドの値は、圧縮及び解凍器の両方のコンテキストで設定することができます。解凍器で確立したら、別のパケットによって更新されるまで、これらのフィールドの値を保持する必要があります。
There is no field in the TCP header that can act as the master sequence number for TCP compression, as explained in [RFC4413], Section 5.6.
[RFC4413]で説明したように、TCP圧縮のマスタシーケンス番号として作用することができるTCPヘッダ、5.6節にはフィールドがありません。
To overcome this problem, ROHC-TCP introduces a control field called the Master Sequence Number (MSN) field. The MSN field is created at the compressor, rather than using one of the fields already present in the uncompressed header. The compressor increments the value of the MSN by one for each packet that it sends.
この問題を克服するために、ROHC - TCPは、マスターシーケンス番号（MSN）フィールドと呼ばれる制御フィールドを紹介します。 MSNフィールドはなく、非圧縮ヘッダ内に既に存在するフィールドのいずれかを使用するよりも、圧縮機で作成されています。圧縮機は、送信する各パケットのための1つによりMSNの値をインクリメントします。
The MSN field has the following two functions:
MSNフィールドは、次の2つの機能があります。
The MSN field is present in every packet sent by the compressor. The MSN is LSB encoded within the CO packets, and the 16-bit MSN is sent in full in IR/IR-DYN packets. The decompressor always sends the MSN as part of the feedback information. The compressor can later use the MSN to infer which packet the decompressor is acknowledging.
MSNフィールドは、コンプレッサにより送信されたすべてのパケットに存在しています。 MSNは、LSB COパケット内に符号化され、16ビットのMSNは、IR / IR-DYNパケットで完全に送信されます。デコンプレッサは、常にフィードバック情報の一部としてMSNを送信します。圧縮機は、後で解凍器が肯定応答されたパケット推論するMSNを使用することができます。
When the MSN is initialized, it SHOULD be initialized to a random value. The compressor should only initialize a new MSN for the initial IR or IR-CR packet sent for a CID that corresponds to a context that is not already associated with this profile. In other words, if the compressor reuses the same CID to compress many TCP flows one after the other, the MSN is not reinitialized but rather continues to increment monotonically.
MSNが初期化されると、それはランダムな値に初期化する必要があります。圧縮機は、すでにこのプロファイルに関連付けられていない状況に対応するCIDのために送ら初期IRまたはIR-CRパケットの新しいMSNを初期化しなければなりません。圧縮機は、多くのTCPを圧縮するために同じCIDを再利用言い換えれば、次々に流れるMSNは再初期化されず、むしろ単調にインクリメントし続けます。
For context replication, the compressor does not use the MSN of the base context when sending the IR-CR packet, unless the replication process overwrites the base context (i.e., Base CID == CID). Instead, the compressor uses the value of the MSN if it already exists in the ROHC-TCP context being associated with the new flow (CID); otherwise, the MSN is initialized to a new value.
IR-CRパケットを送信するとき、複製プロセスは、ベースコンテキスト（すなわち、基本CIDの==のCID）を上書きしない限り、コンテキストの複製のために、圧縮機は、ベースコンテキストのMSNを使用していません。それは既に新たなフロー（CID）に関連付けられるROHC-TCPコンテキストに存在する場合、その代わりに、圧縮機は、MSNの値を使用します。そうでない場合は、MSNは、新しい値に初期化されます。
The IP-ID field of the IPv4 header can have different change patterns. Conceptually, a compressor monitors changes in the value of the IP-ID field and selects encoding methods and packet formats that are the closest match to the observed change pattern.
IPv4ヘッダのIP-IDフィールドは、異なる変化パターンを持つことができます。概念的には、圧縮機がIP-IDフィールドの値の変化を監視し、観察された変化パターンに最も近いものである符号化方法及びパケットフォーマットを選択します。
ROHC-TCP defines different types of compression techniques for the IP-ID, to provide the flexibility to compress any of the behaviors it may observe for this field: sequential in network byte order (NBO), sequential byte-swapped, random (RND), or constant to a value of zero.
ROHC - TCPは、このフィールドに観察することができる行動のいずれかを圧縮するための柔軟性を提供するために、IP-IDのための圧縮技術のさまざまなタイプを定義します。ネットワークバイトオーダー（NBO）で、順次、シーケンシャルバイトスワップ、ランダム（RND） 、またはゼロの値に定数。
The compressor monitors changes in the value of the IP-ID field for a number of packets, to identify which one of the above listed compression alternatives is the closest match to the observed change pattern. The compressor can then select packet formats and encoding methods based on the identified field behavior.
圧縮機は、上記圧縮選択肢のうちの1つが観察された変化パターンに最も近い一致であるかを識別するために、パケット数のIP-IDフィールドの値の変化を監視します。圧縮機は、次に、識別されたフィールドの動作に基づいて、パケットフォーマット及び符号化方式を選択することができます。
If more than one level of IP headers is present, ROHC-TCP can assign a sequential behavior (NBO or byte-swapped) only to the IP-ID of the innermost IP header. This is because only this IP-ID can possibly have a sufficiently close correlation with the MSN (see also Section 6.1.1) to compress it as a sequentially changing field. Therefore, a compressor MUST NOT assign either the sequential (NBO) or the sequential byte-swapped behavior to tunneling headers.
IPヘッダーの複数のレベルが存在する場合、ROHC-TCPは、連続動作（NBOまたはバイトスワップ）は最も内側のIPヘッダのIP-IDを割り当てることができます。これだけIP-IDはおそらくMSNと十分に密接な相関関係を持つことができるので、これは（セクション6.1.1を参照）を順次変更フィールドとしてそれを圧縮することです。したがって、圧縮機は、順次（NBO）、又はトンネルヘッダに逐次バイトスワップ動作のいずれかを割り当ててはいけません。
The control field for the IP-ID behavior determines which set of packet formats will be used. These control fields are also used to determine the contents of the irregular chain item (see Section 6.2) for each IP header.
IP-IDの動作のための制御フィールドはパケットフォーマットのセットが使用されるかを決定します。これらの制御フィールドはまた、不規則なチェーン項目の内容を決定するために使用される各IPヘッダの（セクション6.2を参照）。
When ECN [RFC3168] is used once on a flow, the ECN bits could change quite often. ROHC-TCP maintains a control field in the context to indicate whether or not ECN is used. This control field is transmitted in the dynamic chain of the TCP header, and its value can be updated using specific compressed headers carrying a 7-bit CRC.
ECN [RFC3168]はフローに一度使用された場合、ECNビットはかなり頻繁に変更することができます。 ROHC - TCPは、ECNが使用されているかどうかを示すために、文脈に制御フィールドを保持します。この制御フィールドは、TCPヘッダの動的鎖で送信され、その値は7ビットのCRCを運ぶ特定の圧縮ヘッダを使用して更新することができます。
When this control field indicates that ECN is being used, items of all IP and TCP headers in the irregular chain include bits used for ECN. To preserve octet-alignment, all of the TCP reserved bits are transmitted and, for outer IP headers, the entire Type of Service/ Traffic Class (TOS/TC) field is included in the irregular chain. When there is only one IP header present in the packet (i.e., no IP tunneling is used), this compression behavior allows the compressor to handle changes in the ECN bits by adding a single octet to the compressed header.
この制御フィールドは、ECNが使用されていることを示す場合、不規則なチェーン内のすべてのIPおよびTCPヘッダの項目は、ECNのために使用されるビットを含みます。オクテット整列を維持するために、TCPのすべての予約ビットが送信されると、外側IPヘッダのため、サービス/トラフィッククラス（TOS / TC）の全体のタイプはフィールドが不規則なチェーンに含まれています。パケットの中に存在する唯一のIPヘッダ（すなわち、いかなるIPトンネリングが使用されていない）がある場合、この圧縮動作は、圧縮機は、圧縮ヘッダに単一のオクテットを追加することにより、ECNビットの変更を処理することを可能にします。
The reason for including the ECN bits of all IP headers in the compressed packet when the control field is set is that the profile needs to efficiently compress flows containing IP tunnels using the "full-functionality option" of Section 9.1 of [RFC3168]. For these flows, a change in the ECN bits of an inner IP header is propagated to the outer IP headers. When the "limited-functionality" option is used, the compressor will therefore sometimes send one octet more than necessary per tunnel header, but this has been considered a reasonable tradeoff when designing this profile.
制御フィールドが設定された圧縮パケット内のすべてのIPヘッダのECNビットを含む理由は、プロファイルが効率的に[RFC3168]のセクション9.1の「フル機能のオプション」を使用してIPトンネルを含む流れを圧縮する必要があることです。これらの流れのために、内部IPヘッダのECNビットの変化は、外側のIPヘッダに伝播されます。 「制限された機能」オプションを使用した場合、圧縮機は、したがって、時々、よりトンネルヘッダごとに必要な数のオクテットを送信しますが、このプロファイルを設計するとき、これは合理的なトレードオフと考えられてきました。
Some packet types use one or more chains containing sub-header information. The function of a chain is to group fields based on similar characteristics, such as static, dynamic, or irregular fields. Chaining is done by appending an item for each header to the chain in their order of appearance in the uncompressed packet, starting from the fields in the outermost header.
いくつかのパケットタイプは、サブヘッダ情報を含む1つの以上の鎖を使用します。鎖の機能は、例えば、静的、動的、または不規則なフィールドと同様の特性に基づいてグループ・フィールドです。チェーンは、最も外側のヘッダ内のフィールドから出発して、非圧縮パケットに出現の順序でチェーンに各ヘッダの項目を追加することによって行われます。
Chains are defined for all headers compressed by ROHC-TCP, as listed below. Also listed are the names of the encoding methods used to encode each of these protocol headers.
以下に挙げるようなチェーンは、ROHC-TCPで圧縮されたすべてのヘッダーのために定義されています。また、これらのプロトコルヘッダの各々を符号化するために使用される符号化方法の名前がリストされています。
o TCP [RFC0793], encoding method: "tcp"
O TCP [RFC0793]、エンコード方法： "TCP"
o IPv4 [RFC0791], encoding method: "ipv4"
"IPv4の"：のIPv4 [RFC0791]、符号化方式O
o IPv6 [RFC2460], encoding method: "ipv6"
"IPv6" のIPv6 [RFC2460]、符号化方式O
o AH [RFC4302], encoding method: "ah"
AH O [RFC4302]、符号化方法： "ああ"
o GRE [RFC2784][RFC2890], encoding method: "gre"
GRE [RFC2784] [RFC2890]エンコード方法は、 "来て"
o MINE [RFC2004], encoding method: "mine"
O MINE [RFC2004]、符号化方法： "鉱山"
o NULL-encrypted ESP [RFC4303], encoding method: "esp_null"
O NULL暗号化ESP [RFC4303]、符号化方法： "ESP_NULL"
o IPv6 Destination Options header [RFC2460], encoding method: "ip_dest_opt"
OのIPv6宛先オプションヘッダ[RFC2460]、符号化方法： "ip_dest_opt"
o IPv6 Hop-by-Hop Options header [RFC2460], encoding method: "ip_hop_opt"
O IPv6のホップバイホップオプションヘッダ[RFC2460]、符号化方法：「ip_hop_opt」
o IPv6 Routing header [RFC2460], encoding method: "ip_rout_opt"
O IPv6ルーティングヘッダ[RFC2460]、符号化方法： "ip_rout_opt"
Static chain:
静的チェーン：
The static chain consists of one item for each header of the chain of protocol headers to be compressed, starting from the outermost IP header and ending with a TCP header. In the formal description of the packet formats, this static chain item for each header is a format whose name is suffixed by "_static". The static chain is only used in IR packets.
静的チェーンは、最も外側のIPヘッダから開始し、TCPヘッダで終わる、圧縮されるプロトコルヘッダの鎖の各ヘッダのための一つの項目から成ります。パケットフォーマットの形式的記述では、各ヘッダにこの静的チェーン項目は、名前が「_static」サフィックスされるフォーマットです。静的鎖のみIRパケットで使用されています。
Dynamic chain:
ダイナミックチェーン：
The dynamic chain consists of one item for each header of the chain of protocol headers to be compressed, starting from the outermost IP header and ending with a TCP header. The dynamic chain item for the TCP header also contains a compressed list of TCP options (see Section 6.3). In the formal description of the packet formats, the dynamic chain item for each header type is a format whose name is suffixed by "_dynamic". The dynamic chain is used in both IR and IR-DYN packets.
動的鎖は、最も外側のIPヘッダから開始し、TCPヘッダで終わる、圧縮されるプロトコルヘッダの鎖の各ヘッダのための一つの項目から成ります。 TCPヘッダの動的鎖アイテムはまた、TCPオプション（セクション6.3を参照）の圧縮されたリストを含みます。パケットフォーマットの形式的記述では、各ヘッダタイプのダイナミックチェーン項目は、名前が「_dynamic」サフィックスされるフォーマットです。動的鎖はIR及びIR-DYNパケットの両方で使用されています。
Replicate chain:
チェーンを複製：
The replicate chain consists of one item for each header in the chain of protocol headers to be compressed, starting from the outermost IP header and ending with a TCP header. The replicate chain item for the TCP header also contains a compressed list of TCP options (see Section 6.3). In the formal description of the packet formats, the replicate chain item for each header type is a format whose name is suffixed by "_replicate". Header fields that are not present in the replicate chain are replicated from the base context. The replicate chain is only used in the IR-CR packet.
複製鎖は、最も外側のIPヘッダから開始し、TCPヘッダで終わる、圧縮されるプロトコルヘッダのチェーン内の各ヘッダのために一つの項目から成ります。 TCPヘッダの複製鎖アイテムはまた、TCPオプション（セクション6.3を参照）の圧縮されたリストを含みます。パケットフォーマットの形式的記述では、各ヘッダタイプの複製鎖項目は、名前が「_replicate」サフィックスされるフォーマットです。複製鎖中に存在しないヘッダーフィールドは、ベースコンテキストから複製されます。複製鎖は、IR-CRパケットにのみ使用されます。
Irregular chain:
不規則なチェーン：
The structure of the irregular chain is analogous to the structure of the static chain. For each compressed packet, the irregular chain is appended at the specified location in the general format of the compressed packets as defined in Section 7.3. This chain also includes the irregular chain items for TCP options as defined in Section 6.3.6, which are placed directly after the irregular chain item of the TCP header, and in the same order as the options appear in the uncompressed packet. In the formal description of the packet formats, the irregular chain item for each header type is a format whose name is suffixed by "_irregular". The irregular chain is used only in CO packets.
不規則な鎖の構造は、静的鎖の構造に類似しています。各圧縮されたパケットのために、不規則な鎖はセクション7.3で定義されるように圧縮されたパケットの一般的なフォーマットで指定した場所に添付されています。 TCPヘッダの不規則なチェーン項目の後、およびオプションは、非圧縮パケットに現れるのと同じ順序に直接配置されているセクション6.3.6に定義されるように、この鎖はまた、TCPオプションの不規則なチェーン項目を含みます。パケットフォーマットの形式的記述では、各ヘッダタイプの不規則なチェーン項目は、名前が「_irregular」サフィックスされるフォーマットです。不規則な鎖のみCOパケットで使用されています。
The format of the irregular chain for the innermost IP header differs from the format of outer IP headers, since this header is part of the compressed base header.
このヘッダーは、圧縮ベースヘッダの一部であるので、最も内側のIPヘッダの不規則なチェーンの形式は、外側IPヘッダのフォーマットは異なります。
This section describes in detail how list compression is applied to the TCP options. In the definition of the packet formats for ROHC-TCP, the most frequent TCP options have one encoding method each, as listed in the table below.
このセクションでは、リストの圧縮がTCPオプションにどのように適用されるかを詳細に説明しています。 ROHC-TCPのパケットフォーマットの定義では、最も頻繁にTCPオプションは、以下の表に示すように、1つの符号化方式をそれぞれ有しています。
+-----------------+------------------------+
| Option name | Encoding method name |
+-----------------+------------------------+
| NOP | tcp_opt_nop |
| EOL | tcp_opt_eol |
| MSS | tcp_opt_mss |
| WINDOW SCALE | tcp_opt_wscale |
| TIMESTAMP | tcp_opt_ts |
| SACK-PERMITTED | tcp_opt_sack_permitted |
| SACK | tcp_opt_sack |
| Generic options | tcp_opt_generic |
+-----------------+------------------------+
Each of these encoding methods has an uncompressed format, a format suffixed by "_list_item" and a format suffixed by "_irregular". In some cases, a single encoding method may have multiple "_list_item" or "_irregular" formats, in which case bindings inside these formats determine what format is used. This is further described in the following sections.
これらの符号化方法の各々は、非圧縮形式、「_list_item」および「_irregular」サフィックス形式サフィックスフォーマットを有します。いくつかの場合において、単一の符号化方法は、これらのフォーマット内側ケースバインディングが使用されているどのような形式を決定する複数の「_list_item」または「_irregular」フォーマットを有することができます。これは、さらに以下のセクションで説明されています。
The TCP options in the uncompressed packet can be represented as an ordered list, whose order and presence are usually constant between packets. The generic structure of such a list is as follows:
非圧縮パケット内のTCPオプションは、その順序とプレゼンス通常パケット間一定である順序付きリスト、として表すことができます。次のようなリストの一般的な構造は次のとおりです。
+--------+--------+--...--+--------+
list: | item 1 | item 2 | | item n |
+--------+--------+--...--+--------+
To compress this list, ROHC-TCP uses a list compression scheme, which compresses each of these items individually and combines them into a compressed list.
このリストを圧縮するには、ROHC - TCPは、個別にこれらの項目のそれぞれを圧縮し、圧縮されたリストにそれらを組み合わせたリストの圧縮方式を、使用しています。
The basic principles of list-based compression are the following:
リストベースの圧縮の基本的な原則は次のとおりです。
1) When a context is being initialized, a complete representation of the compressed list of options is transmitted. All options that have any content are present in the compressed list of items sent by the compressor.
コンテキストが初期化されている場合1）、オプションの圧縮されたリストの完全な表現が送信されます。すべてのコンテンツを持っているすべてのオプションは、コンプレッサにより送信されたアイテムの圧縮されたリスト内に存在しています。
Then, once the context has been initialized:
次に、コンテキストが初期化された後：
2) When the structure AND the content of the list are unchanged, no information about the list is sent in compressed headers.
構造およびリストの内容が変化しない場合2）、リストに関する情報は、圧縮されたヘッダーで送信されません。
3) When the structure of the list is constant, and when only the content defined within the irregular format for one or more options is changed, no information about the list needs to be sent in compressed base headers; the irregular content is sent as part of the irregular chain, as described in Section 6.3.6.
3）リストの構造は一定であり、1つ以上のオプションのための不規則なフォーマット内に定義された内容が変更された場合にのみ、リストに関する情報は、圧縮されたベースヘッダーで送信する必要がない場合。セクション6.3.6に記載のように不規則なコンテンツは、不規則なチェーンの一部として送信されます。
4) When the structure of the list changes, a compressed list is sent in the compressed base header, including a representation of its structure and order. Content defined within the irregular format of an option can still be sent as part of the irregular chain (as described in Section 6.3.6), provided that the item content is not part of the compressed list.
4）リストの変更の構造は、圧縮されたリストは、その構造および順序の表現を含む、圧縮された基本ヘッダで送信されます。オプションの不規則なフォーマット内に定義されたコンテンツは、依然として不規則なチェーンの一部として送信することができる（セクション6.3.6で説明したように）、アイテムのコンテンツは圧縮されたリストの一部ではないことを条件とします。
The Table-based item compression compresses individual items sent in compressed lists. The compressor assigns a unique identifier, "Index", to each item, "Item", of a list.
表ベースの項目圧縮は、圧縮されたリストに送信された個々の項目を圧縮します。圧縮機は、リストの一意の識別子、「インデックス」、各項目に、「アイテム」を割り当てます。
Compressor Logic
コンプレッサーロジック
The compressor conceptually maintains an item table containing all items, indexed using "Index". The (Index, Item) pair is sent together in compressed lists until the compressor gains enough confidence that the decompressor has observed the mapping between items and their respective index. Confidence is obtained from the reception of an acknowledgment from the decompressor, or by sending (Index, Item) pairs using the optimistic approach. Once confidence is obtained, the index alone is sent in compressed lists to indicate the presence of the item corresponding to this index.
圧縮機は、概念的に「インデックス」を使用して索引付けすべての項目を含む項目テーブルを維持します。コンプレッサーが減圧装置がアイテムとそれぞれのインデックスとの間のマッピングを観察したことを十分に確信を得るまで（インデックス、項目）ペアは、圧縮リストに一緒に送信されます。自信が解凍装置から、または楽観的アプローチを使用して（インデックス、項目）のペアを送信することによって、確認応答の受信から得られます。自信が得られると、単独のインデックスは、このインデックスに対応するアイテムの存在を示すために、圧縮されたリストに送信されます。
The compressor may reassign an existing index to a new item, by re-establishing the mapping using the procedure described above.
圧縮機は、上記の手順を使用してマッピングを再確立することによって、新たなアイテムに既存のインデックスを再割り当てしてもよいです。
Decompressor Logic
デコンプレッサロジック
The decompressor conceptually maintains an item table that contains all (Index, Item) pairs received. The item table is updated whenever an (Index, Item) pair is received and decompression is successfully verified using the CRC. The decompressor retrieves the item from the table whenever an index without an accompanying item is received.
減圧装置は概念的に受信されたすべての（インデックス、項目）対を含む項目テーブルを維持します。 （インデックス、項目）組が受信されると、減圧が正常CRCを使用して検証されたときにアイテムテーブルが更新されます。デコンプレッサは、添付の項目なしでインデックスが受信されるたびに、テーブルから項目を検索します。
If an index without an accompanying item is received and the decompressor does not have any context for this index, the header MUST be discarded and a NACK SHOULD be sent.
添付項目無しインデックスが受信され、デコンプレッサは、このインデックスの任意のコンテキストを持っていない場合、ヘッダーは捨てなければならないとNACKが送信されるべきです。
Each item present in a compressed list is represented by:
圧縮されたリストに存在する各項目は、で表されます。
o an index into the table of items
Oアイテムのテーブルへのインデックス
o a presence bit indicating if a compressed representation of the item is present in the list
O項目の圧縮された表現がリストに存在するかどうかを示す存在ビット
o an item (if the presence bit is set)
項目O（プレゼンス・ビットが設定されている場合）
Decompression of an item will fail if the presence bit is not set and the decompressor has no entry in the context for that item.
プレゼンス・ビットが設定され、減圧装置がその項目のコンテキストにエントリを持っていないされていない場合、アイテムの復元に失敗します。
A compressed list of TCP options uses the following encoding:
TCPオプションの圧縮されたリストには、次のエンコーディングを使用しています：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Reserved |PS | m |
+---+---+---+---+---+---+---+---+
| XI_1, ..., XI_m | m octets, or m * 4 bits
/ --- --- --- ---/
| : Padding : if PS = 0 and m is odd
+---+---+---+---+---+---+---+---+
| |
/ item_1, ..., item_n / variable
| |
+---+---+---+---+---+---+---+---+
Reserved: MUST be set to zero; otherwise, the decompressor MUST discard the packet.
予約：ゼロに設定する必要があります。そうでない場合、デコンプレッサはパケットを捨てなければなりません。
PS: Indicates size of XI fields:
PS：XIフィールドの大きさを示します。
PS = 0 indicates 4-bit XI fields;
PS = 0は、4ビットのXIフィールドを示します。
PS = 1 indicates 8-bit XI fields.
PS = 1は、8ビットXIフィールドを示しています。
m: Number of XI item(s) in the compressed list.
M：圧縮されたリストにおけるXIアイテム（複数可）の数。
XI_1, ..., XI_m: m XI items. Each XI represents one TCP option in the uncompressed packet, in the same order as they appear in the uncompressed packet.
XI_1、...、XI_m：メートルのXIアイテム。各XIは、彼らが非圧縮パケットに現れるのと同じ順序で、非圧縮パケット内の1つのTCPオプションを表します。
The format of an XI item is as follows:
次のようにXI項目の形式は次のとおりです。
+---+---+---+---+
PS = 0: | X | Index |
+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
PS = 1: | X | Reserved | Index |
+---+---+---+---+---+---+---+---+
X: Indicates whether the item is present in the list:
X：項目がリストに存在するかどうかを示します。
X = 1 indicates that the item corresponding to the Index is sent in the item_1, ..., item_n list;
X = 1のインデックスに対応する項目がitem_1、...、item_nリストに送信されることを示します。
X = 0 indicates that the item corresponding to the Index is not sent and is instead included in the irregular chain.
X = 0のインデックスに対応する項目が送信されず、代わりに不規則なチェーンに含まれていることを示します。
Reserved: MUST be set to zero; otherwise, the decompressor MUST discard the packet.
予約：ゼロに設定する必要があります。そうでない場合、デコンプレッサはパケットを捨てなければなりません。
Index: An index into the item table. See Section 6.3.4.
インデックス：項目テーブルへのインデックス。 6.3.4項を参照してください。
When 4-bit XI items are used, the XI items are placed in octets in the following manner:
4ビットのXIのアイテムが使用される場合、XI項目は以下のようにオクテットに配置されています。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| XI_k | XI_k + 1 |
+---+---+---+---+---+---+---+---+
Padding: A 4-bit padding field is present when PS = 0 and the number of XIs is odd. The Padding field MUST be set to zero; otherwise, the decompressor MUST discard the packet.
パディング：PS = 0とXISの数が奇数である場合、4ビットのパディングフィールドが存在します。パディングフィールドをゼロに設定しなければなりません。そうでない場合、デコンプレッサはパケットを捨てなければなりません。
Item 1, ..., item n: Each item corresponds to an XI with X = 1 in XI 1, ..., XI m. The format of the entries in the item list is described in Section 6.2.
アイテム1、...、項目N：各項目は、XI 1においてX = 1とXIに対応...、XI mを。アイテムリスト内のエントリの形式は、セクション6.2に記載されています。
The item table for TCP options list compression is limited to 16 different items, since it is unlikely that any packet flow will contain a larger number of unique options.
任意のパケットフローがユニークなオプションの数が多く含まれることはほとんどありませんので、TCPオプションリスト圧縮のための項目テーブルは、16種類のアイテムに制限されています。
The mapping between the TCP option type and table indexes are listed in the table below:
TCPオプションの種類とテーブルのインデックスとの間のマッピングを以下の表に記載されています：
+-----------------+---------------+
| Option name | Table index |
+-----------------+---------------+
| NOP | 0 |
| EOL | 1 |
| MSS | 2 |
| WINDOW SCALE | 3 |
| TIMESTAMP | 4 |
| SACK-PERMITTED | 5 |
| SACK | 6 |
| Generic options | 7-15 |
+-----------------+---------------+
Some TCP options are used more frequently than others. To simplify their compression, a part of the item table is reserved for these option types, as shown on the table above. Both the compressor and the decompressor MUST use these mappings between item and indexes to (de)compress TCP options when using list compression.
いくつかのTCPオプションは、他の人よりも頻繁に使用されています。上記の表に示されるように、それらの圧縮を簡単にするために、項目テーブルの一部は、これらのオプションタイプのために確保されています。コンプレッサーと減圧の両方が（デ）の項目とインデックスとの間のこれらのマッピングを使用してリスト圧縮を使用するときにTCPオプションを圧縮しなければなりません。
It is expected that the option types for which an index is reserved in the item table will only appear once in a list. However, if an option type is detected twice in the same options list and if both options have a different content, the compressor should compress the second occurrence of the option type by mapping it to a generic compressed option. Otherwise, if the options have the exact same content, the compressor can still use the same table index for both.
インデックスが項目テーブルに予約されている種類れるオプションは、一度だけリストに表示されることが期待されます。しかし、オプションタイプは、同じオプションリストで2回検出され、両方のオプションが異なるコンテンツを有する場合、圧縮機は、一般的な圧縮オプションにそれをマッピングすることにより、オプションタイプの第二の発生を圧縮する必要がある場合。オプションはまったく同じ内容を持っている場合はそれ以外の場合は、コンプレッサーはまだ両方に同じテーブルインデックスを使用することができます。
The NOP option
NOPオプション
The NOP option can appear more than once in the list. However, since its value is always the same, no context information needs to be transmitted. Multiple NOP options can thus be mapped to the same index. Since the NOP option does not have any content when compressed as a "_list_item", it will never be present in the item list. For consistency, the compressor should still establish an entry in the list by setting the presence bit, as done for the other type of options.
NOPオプションは、一度、リスト内で複数表示されることがあります。その値は常に同じであるので、何のコンテキスト情報を送信する必要がありません。複数のNOPオプションは、このように同じインデックスにマッピングすることができます。 NOPオプションは「_list_item」として圧縮任意のコンテンツを持っていないので、項目リスト内に存在することはありません。一貫性を保つため、コンプレッサーはまだオプションの他のタイプのために行ったように、存在ビットを設定することにより、リスト内のエントリを確立すべきです。
List compression always preserves the original order of each item in the decompressed list, whether or not the item is present in the compressed "_list_item" or if multiple items of the same type can be mapped to the same index, as for the NOP option.
リスト圧縮は常にアイテムが圧縮「_list_item」または同じタイプの複数の項目は、NOPオプションのように、同じインデックスにマッピングすることができる場合が存在するか否か、解凍リスト内の各項目の元の順序を保存します。
The EOL option
EOLオプション
The size of the compressed format for the EOL option can be larger than one octet, and it is defined so that it includes the option padding. This is because the EOL should terminate the parsing of the options, but it can also be followed by padding octets that all have the value zero.
EOLオプションの圧縮形式の大きさは1つのオクテットよりも大きくすることができ、それはオプションのパディングを含むようにそれが定義されています。 EOLは、オプションの解析が終了しなければならないので、これはですが、それはまた、すべてがゼロの値を持つパディングオクテットが続くことができます。
The Generic option
一般的なオプション
The Generic option can be used to compress any type of TCP option that does not have a reserved index in the item table.
一般的なオプションは、項目テーブルに予約されたインデックスを持っていないTCPオプションのいずれかのタイプを圧縮するために使用することができます。
A compressed list for TCP options that is part of the dynamic chain (e.g., in IR or IR-DYN packets) must have all its list items present, i.e., all X-bits in the XI list MUST be set.
（IRまたはIR-DYNパケットで例えば、）動的鎖の一部であるTCPオプションの圧縮されたリストは、存在する全てのリスト項目を有していなければならない、即ち、XIリスト内のすべてのXビットを設定しなければなりません。
The "_list_item" represents the option inside the compressed item list, and the "_irregular" format is used for the option fields that are expected to change with each packet. When an item of the specified type is present in the current context, these irregular fields are present in each compressed packet, as part of the irregular chain. Since many of the TCP option types are not expected to change for the duration of a flow, many of the "_irregular" formats are empty.
「_list_itemは」圧縮項目リスト内のオプションを表し、そして「_irregular」フォーマットは、各パケットと共に変化することが予想されるオプションフィールドのために使用されます。指定されたタイプのアイテムが現在のコンテキスト内に存在する場合、これらの不規則なフィールドが不規則なチェーンの一部として、各圧縮パケット内に存在します。 TCPオプションの多くの種類がフローの期間中に変化することが予想されていないので、「_irregular」フォーマットの多くは空です。
The irregular chain for TCP options is structured analogously to the structure of the TCP options in the uncompressed packet. If a compressed list is present in the compressed packet, then the irregular chain for TCP options must not contain irregular items for the list items that are transmitted inside the compressed list (i.e., items in the list that have the X-bit set in its XI). The items that are not present in the compressed list, but are present in the uncompressed list, must have their respective irregular items present in the irregular chain.
TCPオプションの不規則な鎖は、非圧縮パケット内のTCPオプションの構造と同様に構成されています。圧縮されたリストには、圧縮されたパケット内に存在する場合、TCPオプションの不規則なチェーンが圧縮され、リスト内で送信されているリスト項目の不規則な項目を含めることはできません（すなわち、X-ビットを持っているリスト内の項目は、に設定されましたXI）。圧縮されたリストに存在しないが、非圧縮のリストに存在している項目は、不規則なチェーンに存在するそれぞれの不規則なアイテムを持っている必要があります。
The entire table of TCP options items is always replicated when using the IR-CR packet. In the IR-CR packet, the list of options for the new flow is also transmitted as a compressed list in the IR-CR packet.
IR-CRパケットを使用する場合、TCPオプションアイテムの全体のテーブルは常に複製されます。 IR-CRパケットに、新たなフローのためのオプションのリストは、IR-CRパケットで圧縮されたリストとして送信されます。
This section defines encoding methods that are specific to this profile. These methods are used in the formal definition of the packet formats in Section 8.
このセクションでは、このプロファイルに固有の符号化方式を定義します。これらの方法は、第8章のパケットフォーマットの形式的な定義で使用されています。
This encoding method compresses the Header Checksum field of the IPv4 header. This checksum is defined in [RFC0791] as follows:
この符号化方法は、IPv4ヘッダのヘッダチェックサムフィールドを圧縮します。次のようにこのチェックサムは、[RFC0791]で定義されています。
Header Checksum: 16 bits
ヘッダチェックサム：16ビット
A checksum on the header only. Since some header fields change (e.g., time to live), this is recomputed and verified at each point that the internet header is processed.
のみヘッダのチェックサム。いくつかのヘッダーフィールド（例えば、時間は、生きるために）変化するので、これを再計算し、インターネットヘッダが処理される各ポイントで検証されます。
The checksum algorithm is:
チェックサムアルゴリズムは次のようになります。
The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero.
チェックサムフィールドは、ヘッダ内のすべての16ビットワードの1の補数和の16ビットの1の補数です。チェックサムを計算する目的のために、チェックサムフィールドの値はゼロです。
As described above, the header checksum protects individual hops from processing a corrupted header. When almost all IP header information is compressed away, and when decompression is verified by a CRC computed over the original header for every compressed packet, there is no point in having this additional checksum; instead, it can be recomputed at the decompressor side.
上述したように、ヘッダチェックサムが破損ヘッダを処理することから、個々のホップを保護します。ほぼすべてのIPヘッダ情報が離れ圧縮され、減圧がすべて圧縮されたパケットの元のヘッダーの上に計算されたCRCにより確認されたときに、この追加のチェックサムを持つにはポイントが存在しない場合。その代わり、それは解凍器側で再計算することができます。
The "inferred_ip_v4_header_checksum" encoding method thus compresses the IPv4 header checksum down to a size of zero bits. Using this encoding method, the decompressor infers the value of this field using the computation above.
「inferred_ip_v4_header_checksum」符号化方法は、このようにゼロビットのサイズまでIPv4ヘッダチェックサムを圧縮します。この符号化方法を使用して、解凍装置は、上記の計算を使用して、このフィールドの値を推定します。
This encoding method implicitly assumes that the compressor will not process a corrupted header; otherwise, it cannot guarantee that the checksum as recomputed by the decompressor will be bitwise identical to its original value before compression.
この符号化方法は、暗黙的に、圧縮機が破損ヘッダを処理しないことを前提。それ以外の場合は、デコンプレッサによって再計算とチェックサムは、圧縮前の元の値と同じビット単位されることを保証することはできません。
This encoding method compresses the minimal encapsulation header checksum. This checksum is defined in [RFC2004] as follows:
この符号化方法は、最小限のカプセル化ヘッダチェックサムを圧縮します。次のようにこのチェックサムは、[RFC2004]で定義されています。
Header Checksum
ヘッダチェックサム
The 16-bit one's complement of the one's complement sum of all 16-bit words in the minimal forwarding header. For purposes of computing the checksum, the value of the checksum field is 0. The IP header and IP payload (after the minimal forwarding header) are not included in this checksum computation.
最小転送ヘッダ内の全ての16ビットワードの1の補数和の16ビットの1の補数。チェックサムを計算する目的のために、チェックサムフィールドの値は0（最小の転送ヘッダの後）IPヘッダとIPペイロードこのチェックサムの計算に含まれないのです。
The "inferred_mine_header_checksum" encoding method compresses the minimal encapsulation header checksum down to a size of zero bits, i.e., no bits are transmitted in compressed headers for this field. Using this encoding method, the decompressor infers the value of this field using the above computation.
「inferred_mine_header_checksum」符号化方法は、ダウンゼロビットのサイズに最小限のカプセル化ヘッダチェックサムを圧縮する、すなわち、何ビットがこのフィールドの圧縮ヘッダで送信されません。この符号化方法を使用して、解凍装置は、上記の計算を使用して、このフィールドの値を推定します。
The motivations and the assumptions for inferring this checksum are similar to the ones explained above in Section 6.4.1.
このチェックサムを推測するための動機と仮定は、セクション6.4.1において上で説明したものと似ています。
This encoding method compresses the Total Length field of the IPv4 header. The Total Length field of the IPv4 header is defined in [RFC0791] as follows:
この符号化方法は、IPv4ヘッダーの全長フィールドを圧縮します。次のようにIPv4ヘッダーの合計長フィールドは、[RFC0791]で定義されています。
Total Length: 16 bits
全長：16ビット
Total Length is the length of the datagram, measured in octets, including internet header and data. This field allows the length of a datagram to be up to 65,535 octets.
全長は、インターネットヘッダとデータを含むオクテットで測定され、データグラムの長さです。このフィールドは、データグラムの長さが65,535オクテットまでにすることができます。
The "inferred_ip_v4_length" encoding method compresses the IPv4 header checksum down to a size of zero bits. Using this encoding method, the decompressor infers the value of this field by counting in octets the length of the entire packet after decompression.
「inferred_ip_v4_length」符号化方法は、ゼロビットのサイズまでIPv4ヘッダチェックサムを圧縮します。この符号化方法を使用して、解凍器は、解凍後のオクテットでパケット全体の長さをカウントすることによって、このフィールドの値を推定します。
This encoding method compresses the Payload Length field of the IPv6 header. This length field is defined in [RFC2460] as follows:
この符号化方法は、IPv6ヘッダのペイロード長さフィールドを圧縮します。次のように、このlengthフィールドは、[RFC2460]で定義されています。
Payload Length: 16-bit unsigned integer
ペイロード長：16ビットの符号なし整数
Length of the IPv6 payload, i.e., the rest of the packet following this IPv6 header, in octets. (Note that any extension headers present are considered part of the payload, i.e., included in the length count.)
IPv6のペイロードの長さ、即ち、オクテットでこのIPv6ヘッダ、次のパケットの残りの部分。 （長カウントに含まれる、すなわち、存在する任意の拡張ヘッダはペイロードの一部とみなされることに注意してください。）
The "inferred_ip_v6_length" encoding method compresses the Payload Length field of the IPv6 header down to a size of zero bits. Using this encoding method, the decompressor infers the value of this field by counting in octets the length of the entire packet after decompression.
「inferred_ip_v6_length」符号化方法は、ゼロビットのサイズまでのIPv6ヘッダのペイロード長さフィールドを圧縮します。この符号化方法を使用して、解凍器は、解凍後のオクテットでパケット全体の長さをカウントすることによって、このフィールドの値を推定します。
This encoding method compresses the data offset field of the TCP header.
この符号化方式は、データはTCPヘッダのフィールドをオフセット圧縮します。
The "inferred_offset" encoding method is used on the Data Offset field of the TCP header. This field is defined in [RFC0793] as:
「inferred_offset」符号化方式は、TCPヘッダのフィールドオフセットデータ上で使用されます。このフィールドは、次のように[RFC0793]で定義されています。
Data Offset: 4 bits
データオフセット：4ビット
The number of 32 bit words in the TCP Header. This indicates where the data begins. The TCP header (even one including options) is an integral number of 32 bits long.
TCPヘッダの32ビットワードの数。データが始まるところで示しています。 TCPヘッダ（オプションを含む一つでも）は、32ビット長の整数です。
The "inferred_offset" encoding method compresses the Data Offset field of the TCP header down to a size of zero bits. Using this encoding method, the decompressor infers the value of this field by first decompressing the TCP options list, and by then setting:
「inferred_offset」符号化方法は、データがダウンゼロビットのサイズにTCPヘッダのフィールドオフセット圧縮します。この符号化方式を使用して、解凍器は、最初のTCPオプションリストを解凍することで、このフィールドの値を推測し、それまでに設定します：
data offset = (options length / 4) + 5
データは、（オプションの長さ/ 4）+ 5 =オフセット
The equation above uses integer arithmetic.
上記の式は、整数演算を使用します。
In CO packets (see Section 7.3), the innermost IP header and the TCP header are combined to create a compressed base header. In some cases, the IP header will have a number of extension headers between itself and the TCP header.
COパケット（セクション7.3を参照）において、最も内側のIPヘッダとTCPヘッダが圧縮されたベース・ヘッダを作成するために組み合わされます。いくつかの場合において、IPヘッダは、それ自体とTCPヘッダの間拡張ヘッダの数を有することになります。
To remain formally correct, the base header must define some representation of these extension headers, which is what this encoding method is used for. This encoding method skips over all the extension headers and does not encode any of the fields. Changed fields in these headers are encoded in the irregular chain.
正式に正しいままに、基本ヘッダは、この符号化方法がために使用されるものであり、これらの拡張ヘッダのいくつかの表現を定義しなければなりません。この符号化方法は、すべての拡張ヘッダーをスキップし、フィールドのいずれかをコードしません。これらのヘッダーに変更フィールドが不規則な鎖で符号化されます。
This encoding method, as well as the baseheader_extension_headers encoding method described above, is needed for the specification to remain formally correct. It is used in CO packets (see Section 7.3) to describe tunneling IP headers and their respective extension headers (i.e., all headers located before the innermost IP header).
この符号化方法、並びに上記baseheader_extension_headers符号化方法は、正式に正しいままに指定のために必要とされます。トンネルIPヘッダを記述するためにCOパケット（セクション7.3を参照）で使用され、それぞれの拡張ヘッダー（すなわち、最も内側のIPヘッダの前に位置するすべてのヘッダー）。
This encoding method skips over all the fields in these headers and does not perform any encoding. Changed fields in outer headers are instead handled by the irregular chain.
この符号化方式は、これらのヘッダのすべてのフィールドをスキップし、任意のエンコードを実行しません。外側のヘッダの変更フィールドは、代わりに不規則なチェーンによって処理されます。
Some header fields will exhibit a change pattern where the field increases by a constant value or by multiples of the same value.
いくつかのヘッダーフィールドは、フィールドが一定の値または同じ値の倍数ずつ増加変化パターンを示すであろう。
Examples of fields that may have this behavior are the TCP Sequence Number and the TCP Acknowledgment Number. For such fields, ROHC-TCP provides the means to downscale the field value before applying LSB encoding, which allows the compressor to transmit fewer bits.
この動作を有することができるフィールドの例としては、TCPシーケンス番号とTCP確認応答番号です。このようなフィールドの場合、ROHC-TCPは、圧縮機は、より少ないビットを送信することを可能にするLSB符号化を適用する前に、フィールドの値をダウンスケールするための手段を提供します。
To be able to use scaled encoding, the field is required to fulfill the following equation:
スケーリングされたエンコーディングを使用することができるように、フィールドは、以下の式を満たすことが要求されます。
unscaled_value = scaling_factor * scaled_value + residue
unscaled_value = scaling_factor * scaled_value +残留
To use the scaled encoding, the compressor must be confident that the decompressor has established values for the "residue" and the "scaling_factor", so that it can correctly decompress the field when only an LSB-encoded "scaled_value" is present in the compressed packet.
唯一LSB符号化された「scaled_value」は圧縮中に存在する場合、それが正しくフィールドを復元できるようにスケーリングされた符号化を使用する、圧縮機は、減圧装置が「残基」および「scaling_factor」の値を確立したことを確信しなければなりませんパケット。
Once the compressor is confident that the value of the scaling_factor and the value of the residue have been established in the decompressor, the compressor may send compressed packets using the scaled representation of the field. The compressor MUST NOT use scaled encoding with the value of the scaling_factor set to zero.
圧縮機はscaling_factor、残渣の値の値がデコンプレッサで確立されていることを確信すると、圧縮機は、フィールドのスケーリングされた表現を使用して圧縮されたパケットを送信することができます。圧縮機は、ゼロに設定scaling_factorの値でスケーリングされた符号化を使用してはいけません。
If the compressor detects that the value of the residue has changed, or if the compressor uses a different value for the scaling factor, it MUST NOT use scaled encoding until it is confident that the decompressor has received the new value(s) of these fields.
圧縮機は、残渣の値が変更された、または圧縮機がスケーリングファクタに異なる値を使用している場合、減圧装置がこれらのフィールドの新しい値（S）を受信したと確信するまで、それはスケーリングされたエンコーディングを使用してはならないことを検出した場合。
When the unscaled value of the field wraps around, the value of the residue is likely to change, even if the scaling_factor remains constant. In such a case, the compressor must act in the same way as for any other change in the residue.
フィールドのスケールなしの値がラップアラウンドするとき、残留の値はscaling_factorが一定であっても、変更する可能性があります。このような場合には、圧縮機は、残留物中の任意の他の変化の場合と同じように行動しなければなりません。
The following subsections describe how the scaled encoding is applied to specific fields in ROHC-TCP, in particular, how the scaling_factor and residue values are established for the different fields.
以下のサブセクションでは、スケーリングされた符号化がscaling_factorおよび剰余値が異なるフィールドのために確立された方法、特に、ROHC-TCPの特定のフィールドに適用する方法について説明します。
For some TCP flows, such as data transfers, the payload size will be constant over periods of time. For such flows, the TCP Sequence Number is bound to increase by multiples of the payload size between packets, which means that this field can be a suitable target for scaled encoding. When using this encoding, the payload size will be used as the scaling factor (i.e., as the value for scaling_factor) of this encoding. This means that the scaling factor does not need to be explicitly transmitted, but is instead inferred from the length of the payload in the compressed packet.
このようなデータ転送などのいくつかのTCPフローについては、ペイロードサイズは、時間の期間にわたって一定です。このような流れのために、TCPシーケンス番号は、このフィールドは、スケーリングされた符号化に適した標的であり得ることを意味するパケット間のペイロードサイズの倍数増加にバインドされます。このエンコーディングを使用する場合、ペイロードサイズは、この符号化のスケーリング因子（すなわち、scaling_factorの値として）として使用されます。これは、スケーリング係数を明示的に送信する必要はありませんが、代わりに圧縮されたパケット内のペイロードの長さから推測されることを意味します。
Establishing scaling_factor:
scaling_factorの確立：
The scaling factor is established by sending unscaled TCP Sequence Number bits, so that the decompressor can infer the scaling_factor from the payload size.
スケーリング係数は、デコンプレッサは、ペイロードサイズからscaling_factorを推測できるように、スケーリングされていないTCPシーケンス番号のビットを送信することによって確立されます。
Establishing residue:
残留物を確立します：
The residue is established identically as the scaling_factor, i.e., by sending unscaled TCP Sequence Number bits.
残渣を、スケーリングされていないTCPシーケンス番号のビットを送信することによって、すなわち、scaling_factorと同じように確立されています。
A detailed specification of how the TCP Sequence Number uses the scaled encoding can be found in the definitions of the packet formats, in Section 8.2.
TCPシーケンス番号は、スケーリングされた符号化を使用する方法の詳細な仕様は、セクション8.2で、パケットフォーマットの定義に記載されています。
Similar to the pattern exhibited by the TCP Sequence Number, the expected increase in the TCP Acknowledgment Number is often constant and is therefore suitable for scaled encoding.
TCPシーケンス番号、TCP確認応答番号の予想される増加によって示されるパターンと同様に、多くの場合、一定であり、したがって、スケーリングされた符号化に適しています。
For the TCP Acknowledgment Number, the scaling factor depends on the size of packets flowing in the opposite direction; this information might not be available to the compressor/decompressor pair. For this reason, ROHC-TCP uses an explicitly transmitted scaling factor to compress the TCP Acknowledgment Number.
TCP確認応答番号のため、スケーリング係数は、逆方向に流れるパケットのサイズに依存します。この情報は、圧縮/伸張のペアに使用できない場合があります。このため、ROHC - TCPは、TCP受信確認番号を圧縮するために明示的に送信されるスケーリング係数を使用しています。
Establishing scaling_factor:
scaling_factorの確立：
The scaling factor is established by explicitly transmitting the value of the scaling factor (called ack_stride in the formal notation in Section 8.2) to the decompressor, using one of the packet types that can carry this information.
スケーリング係数は、明示的にこの情報を運ぶことができるパケットタイプのいずれかを使用して、デコンプレッサに（セクション8.2における正式な表記ack_stride呼ばれる）スケーリングファクタの値を送信することによって確立されます。
Establishing residue:
残留物を確立します：
The scaling factor is established by sending unscaled TCP Acknowledgment Number bits, so that the decompressor can infer its value from the unscaled value and the scaling factor (ack_stride).
スケーリング係数は、デコンプレッサは、スケールなしの値とスケーリング係数（ack_stride）からその値を推測することができるように、スケーリングされていないTCP確認応答番号のビットを送信することによって確立されます。
A detailed specification of how the TCP Acknowledgment Number uses the scaled encoding can be found in the definitions of the packet formats, in Section 8.2.
TCP受信確認番号は、スケーリングされた符号化を使用する方法の詳細な仕様は、セクション8.2で、パケットフォーマットの定義に記載されています。
The compressor MAY use the scaled acknowledgment number encoding; what value it will use as the scaling factor is up to the compressor implementation. In the case where there is a co-located decompressor processing packets of the same TCP flow in the opposite direction, the scaling factor for the sequence number used for that flow can be used by the compressor to determine a suitable scaling factor for the TCP Acknowledgment number for this flow.
圧縮機は、スケーリングされた確認応答番号の符号化を使用することができます。どのような値では、スケーリング係数として使用するコンプレッサーの実装に任されています。反対方向に同一のTCPフローの同一位置の減圧装置処理パケットが存在する場合には、そのフローに使用されるシーケンス番号のスケーリング係数は、TCP確認応答を適切なスケーリング係数を決定するために、コンプレッサにより使用することができますこのフローの数。
A number of encoding methods in Section 8.2 have one or more arguments for which the derivation of the parameter's value is outside the scope of the ROHC-FN specification of the header formats. This section lists the encoding methods together with a definition of each of their parameters.
セクション8.2における符号化方式の数は、パラメータの値の導出は、ヘッダフォーマットのROHC-FN仕様の範囲外であるために1つ以上の引数を有します。このセクションでは、それらのパラメータのそれぞれの定義と一緒に符号化方式を示しています。
o esp_null(next_header_value):
O ESP_NULL（next_header_value）：
next_header_value: Set to the value of the Next Header field
located in the ESP trailer, usually 12 octets from the end of
the packet. Compression of null-encrypted ESP headers should
only be performed when the compressor has prior knowledge of
the exact location of the Next Header field.
o ipv6(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn):
OのIPv6の（is_innermost、ttl_irregular_chain_flag、ip_inner_ecn）：
is_innermost: This Boolean flag is set to true when processing
the innermost IP header; otherwise, it is set to false.
ttl_irregular_chain_flag: This parameter must be set to the value that was used for the corresponding "ttl_irregular_chain_flag" parameter of the "co_baseheader" encoding method (as defined below) when extracting the irregular chain for a compressed header; otherwise, it is set to zero and ignored for other types of chains.
ttl_irregular_chain_flag：このパラメータは、（以下に定義）「co_baseheader」符号化方式の対応する「ttl_irregular_chain_flag」パラメータのために使用された値に設定する必要があり、圧縮ヘッダの不規則な鎖を抽出します。それ以外の場合は、ゼロに設定し、チェーンの他のタイプでは無視されます。
ip_inner_ecn: This parameter is bound by the encoding method, and therefore it should be undefined when calling this encoding method. This value is then used to bind the corresponding parameter in the "tcp" encoding method, as its value is needed when processing the irregular chain for TCP. See the definition of the "ip_inner_ecn" parameter for the "tcp" encoding method below.
ip_inner_ecn：このパラメータは、符号化方式により拘束され、この符号化方法を呼び出すときに、したがって、それは未定義する必要があります。この値は、TCPのために不規則なチェーンを処理するときにその値が必要とされるように、「TCP」の符号化方式に対応するパラメータを結合するために使用されます。以下の「TCP」の符号化方式のため、「ip_inner_ecn」パラメータの定義を参照してください。
o ipv4(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn):
O専用IPv4（is_innermost、ttl_irregular_chain_flag、ip_inner_ecn）：
See definition of arguments for "ipv6" above.
上記の「IPv6」の引数の定義を参照してください。
o tcp_opt_eol(nbits):
tcp_opt_eol（NBITS）○：
nbits: This parameter is set to the length of the padding data
located after the EOL option type octet to the end of the TCP
options in the uncompressed header.
o tcp_opt_sack(ack_value):
O tcp_opt_sack（ack_value）：
ack_value: Set to the value of the Acknowledgment Number field
of the TCP header.
o tcp(payload_size, ack_stride_value, ip_inner_ecn):
OのTCP（payload_size、ack_stride_value、ip_inner_ecn）：
payload_size: Set to the length (in octets) of the payload
following the TCP header.
ack_stride_value: This parameter is the scaling factor used when scaling the TCP Acknowledgment Number. Its value is set by the compressor implementation. See Section 6.4.8.2 for recommendations on how to set this value.
ack_stride_value：このパラメータは、TCP受信確認番号をスケーリングするときに使用されるスケーリング係数です。その値は、圧縮機の実装によって設定されています。この値を設定する方法に関する推奨事項については、セクション6.4.8.2を参照してください。
ip_inner_ecn: This parameter binds with the value given to the corresponding "ip_inner_ecn" parameter by the "ipv4" or the "ipv6" encoding method when processing the innermost IP header of this packet. See also the definition of the "ip_inner_ecn" parameter to the "ipv6" and "ipv4" encoding method above.
ip_inner_ecn：このパラメータは、このパケットの最も内側のIPヘッダを処理するとき、「IPv4の」または「IPv6の」符号化方式で対応する「ip_inner_ecn」パラメータに与えられた値で結合します。 「IPv6の」と上記の「IPv4の」符号化方式にも「ip_inner_ecn」パラメータの定義を参照してください。
o co_baseheader(payload_size, ack_stride_value, ttl_irregular_chain_flag):
Oのco_baseheader（payload_size、ack_stride_value、ttl_irregular_chain_flag）：
payload_size: Set to the length (in octets) of the payload
following the TCP header.
ack_stride_value: This parameter is the scaling factor used when scaling the TCP Acknowledgment Number. Its value is set by the compressor implementation. See Section 6.4.8.2 for recommendations on how to set this value.
ack_stride_value：このパラメータは、TCP受信確認番号をスケーリングするときに使用されるスケーリング係数です。その値は、圧縮機の実装によって設定されています。この値を設定する方法に関する推奨事項については、セクション6.4.8.2を参照してください。
ttl_irregular_chain_flag: This parameter is set to one if the TTL/Hop Limit of an outer header has changed compared to its reference in the context; otherwise, it is set to zero. The value used for this parameter is also used for the "ttl_irregular_chain_flag" argument for the "ipv4" and "ipv6" encoding methods when processing the irregular chain, as defined above for the "ipv6" and "ipv4" encoding methods.
ttl_irregular_chain_flag：外部ヘッダのTTL /ホップリミット文脈におけるその基準と比較して変更された場合、このパラメータが1に設定されています。それ以外の場合はゼロに設定されています。不規則な鎖を処理する場合の「IPv6」と「IPv4の」符号化方式について上で定義したように、このパラメータに使用される値はまた、「IPv4の」および「IPv6の」符号化方式のための「ttl_irregular_chain_flag」引数のために使用されます。
ROHC-TCP uses three different packet types: the Initialization and Refresh (IR) packet type, the Context Replication (IR-CR) packet type, and the Compressed (CO) packet type.
初期化および更新（IR）パケットタイプ、コンテキストレプリケーション（IR-CR）パケットタイプ、および圧縮（CO）パケットタイプ：ROHC-TCPは、3つの異なるパケット・タイプを使用します。
Each packet type defines a number of packet formats: two packet formats are defined for the IR type, one packet format is defined for the IR-CR type, and two sets of eight base header formats are defined for the CO type with one additional format that is common to both sets.
各パケットタイプは、パケットフォーマットの数を定義：2つのパケットフォーマットは、IRタイプに対して定義され、1つのパケットフォーマットは、IR-CRタイプに対して定義され、8つの塩基ヘッダ・フォーマットの2組つの追加の形式でCOタイプのために定義されていますそれは両方のセットに共通です。
The profile identifier for ROHC-TCP is 0x0006.
ROHC-TCPのプロファイルIDは0x0006です。
ROHC-TCP uses the basic structure of the ROHC IR and IR-DYN packets as defined in [RFC4995] (Sections 5.2.2.1 and 5.2.2.2, respectively).
[RFC4995]（それぞれ、セクション5.2.2.1および5.2.2.2）で定義されるようにROHC-TCPは、ROHC IR及びIR-DYNパケットの基本構造を使用します。
Packet type: IR
パケットタイプ：IR
This packet type communicates the static part and the dynamic part of the context.
このパケットタイプは、静的部分とコンテキストの動的部分を通信します。
For the ROHC-TCP IR packet, the value of the x bit MUST be set to one. It has the following format, which corresponds to the
ROHC-TCP IRパケットは、Xビットの値を1に設定しなければなりません。これは、に対応し、次の形式を持っています
"Header" and "Payload" fields described in Section 5.2.1 of [RFC4995]:
「ヘッダ」と[RFC4995]のセクション5.2.1に記載された「ペイロード」フィールド：
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 1 | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile = 0x06 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Static chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Dynamic chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
CRC: 8-bit CRC, computed according to Section 5.3.1.1. of [RFC4995]. The CRC covers the entire IR header, thus excluding payload, padding, and feedback, if any.
CRC：8ビットCRCは、セクション5.3.1.1に従って計算します。 [RFC4995]の。 CRCは、もしあれば、したがって、ペイロード、パディング、及びフィードバックを除いて、全体のIRヘッダを覆います。
Static chain: See Section 6.2.
静的チェーン：セクション6.2を参照してください。
Dynamic chain: See Section 6.2.
ダイナミックチェーン：セクション6.2を参照してください。
Payload: The payload of the corresponding original packet, if any. The payload consists of all data after the last octet of the TCP header to end of the uncompressed packet. The presence of a payload is inferred from the packet length.
ペイロード：対応するオリジナルのパケットのペイロード（もしあれば）。ペイロードは、非圧縮パケットの末尾にTCPヘッダの最後のオクテットの後に、すべてのデータで構成されています。ペイロードの存在は、パケット長から推論されます。
Packet type: IR-DYN
パケットタイプ：IR-DYN
This packet type communicates the dynamic part of the context.
このパケットタイプは文脈のダイナミックな部分を伝えます。
The ROHC-TCP IR-DYN packet has the following format, which corresponds to the "Header" and "Payload" fields described in Section 5.2.1 of [RFC4995]:
ROHC-TCP IR-DYNパケットは、[RFC4995]のセクション5.2.1に記載された「ヘッダ」と「ペイロード」フィールドに対応し、次の形式を持っています。
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 0 0 | IR-DYN type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile = 0x06 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Dynamic chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
CRC: 8-bit CRC, computed according to Section 5.3.1.1 of [RFC4995]. The CRC covers the entire IR-DYN header, thus excluding payload, padding, and feedback, if any.
CRC：[RFC4995]のセクション5.3.1.1に従って計算8ビットCRC、。 CRCは、もしあれば、したがって、ペイロード、パディング、及びフィードバックを除いて、全体IR-DYNヘッダーを覆っています。
Dynamic chain: See Section 6.2.
ダイナミックチェーン：セクション6.2を参照してください。
Payload: The payload of the corresponding original packet, if any. The payload consists of all data after the last octet of the TCP header to end of the uncompressed packet. The presence of a payload is inferred from the packet length.
ペイロード：対応するオリジナルのパケットのペイロード（もしあれば）。ペイロードは、非圧縮パケットの末尾にTCPヘッダの最後のオクテットの後に、すべてのデータで構成されています。ペイロードの存在は、パケット長から推論されます。
Context replication requires a dedicated IR packet format that uniquely identifies the IR-CR packet for the ROHC-TCP profile. This section defines the profile-specific part of the IR-CR packet [RFC4164].
コンテキスト複製一意ROHC-TCPプロファイルのIR-CRパケットを識別する専用のIRパケットフォーマットを必要とします。このセクションでは、IR-CRパケット[RFC4164]のプロファイル固有の部分を定義します。
Packet type: IR-CR
パケットタイプ：IR-CR
This packet type communicates a reference to a base context along with the static and dynamic parts of the replicated context that differs from the base context.
このパケットタイプは、ベースコンテキストは異なる複製コンテキストの静的および動的部品と共にベースコンテキストへの参照を通信します。
The ROHC-TCP IR-CR packet follows the general format of the ROHC CR packet, as defined in [RFC4164], Section 3.5.2. With consideration to the extensibility of the IR packet type defined in [RFC4995], the ROHC-TCP profile supports context replication through the profile-specific part of the IR packet. This is achieved using the bit (x) left in the IR header for "Profile specific information". For ROHC-TCP, this bit is defined as a flag indicating whether this packet is an IR packet or an IR-CR packet. For the ROHC-TCP IR-CR packet, the value of the x bit MUST be set to zero.
[RFC4164]、セクション3.5.2で定義されるようにROHC-TCP IR - CRパケットは、ROHC CRパケットの一般的なフォーマットに従います。 [RFC4995]で定義されたIRパケットタイプの拡張性を考慮して、ROHC-TCPプロファイルはIRパケットのプロファイル固有の部分を介してコンテキストの複製を支持します。これは、「特定の情報をプロファイル」のIRヘッダに左ビット（X）を使用して達成されます。 ROHC-TCPの場合、このビットは、このパケットがIRパケットまたはIR-CRパケットであるか否かを示すフラグとして定義されます。 ROHC-TCP IR - CRパケットの、Xビットの値をゼロに設定しなければなりません。
The ROHC-TCP IR-CR has the following format, which corresponds to the "Header" and "Payload" fields described in Section 5.2.1 of [RFC4995]:
ROHC-TCP IR-CRは、[RFC4995]のセクション5.2.1に記載された「ヘッダ」と「ペイロード」フィールドに対応し、次の形式を持っています。
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 0 | IR-CR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile = 0x06 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| B | CRC7 | 1 octet
+---+---+---+---+---+---+---+---+
: Reserved | Base CID : 1 octet, for small CID, if B=1
+---+---+---+---+---+---+---+---+
: :
/ Base CID / 1-2 octets, for large CIDs,
: : if B=1
+---+---+---+---+---+---+---+---+
| |
/ Replicate chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
B: B = 1 indicates that the Base CID field is present.
B：B = 1基本CIDフィールドが存在することを示します。
CRC: This CRC covers the entire IR-CR header, thus excluding payload, padding, and feedback, if any. This 8-bit CRC is calculated according to Section 5.3.1.1 of [RFC4995].
CRCは、このCRCは、もしあれば、したがって、ペイロード、パディング、及びフィードバックを除いて、全体IR-CRヘッダを覆います。この8ビットCRCは、[RFC4995]のセクション5.3.1.1に従って計算されます。
CRC7: The CRC over the original, uncompressed, header. Calculated according to Section 3.5.1.1 of [RFC4164].
CRC7：オリジナルの、圧縮されていない、ヘッダ上CRC。 [RFC4164]のセクション3.5.1.1に従って計算。
Reserved: MUST be set to zero; otherwise, the decompressor MUST discard the packet.
予約：ゼロに設定する必要があります。そうでない場合、デコンプレッサはパケットを捨てなければなりません。
Base CID: CID of base context. Encoded according to [RFC4164], Section 3.5.3.
ベースCIDベースコンテキストのCID。 [RFC4164]、セクション3.5.3に従って符号化されました。
Replicate chain: See Section 6.2.
チェーンを複製：6.2節を参照してください。
Payload: The payload of the corresponding original packet, if any. The presence of a payload is inferred from the packet length.
ペイロード：対応するオリジナルのパケットのペイロード（もしあれば）。ペイロードの存在は、パケット長から推論されます。
The ROHC-TCP CO packets communicate irregularities in the packet header. All CO packets carry a CRC and can update the context.
ROHC-TCPのCOパケットは、パケットヘッダ内の不規則性を伝えます。すべてのCOパケットは、CRCを運ぶとコンテキストを更新することができます。
The general format for a compressed TCP header is as follows, which corresponds to the "Header" and "Payload" fields described in Section 5.2.1 of [RFC4995]:
「ヘッダ」と[RFC4995]のセクション5.2.1に記載された「ペイロード」フィールドに対応する、次のように圧縮されたTCPヘッダの一般的な形式は次のとおりです。
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and CID 1-15
+---+---+---+---+---+---+---+---+
| First octet of base header | (with type indication)
+---+---+---+---+---+---+---+---+
: :
/ 0, 1, or 2 octets of CID / 1-2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
/ Remainder of base header / variable number of octets
+---+---+---+---+---+---+---+---+
: Irregular chain :
/ (including irregular chain / variable
: items for TCP options) :
--- --- --- --- --- --- --- ---
| |
/ Payload / variable length
| |
- - - - - - - - - - - - - - - -
Base header: The complete set of base headers is defined in Section 8.
基本ヘッダ：ベースヘッダの完全なセットは、第8節で定義されています。
Irregular chain: See Section 6.2 and Section 6.3.6.
不規則なチェーン：セクション6.2および6.3.6項を参照してください。
Payload: The payload of the corresponding original packet, if any. The presence of a payload is inferred from the packet length.
ペイロード：対応するオリジナルのパケットのペイロード（もしあれば）。ペイロードの存在は、パケット長から推論されます。
This section describes the set of compressed TCP/IP packet formats. The normative description of the packet formats is given using the formal notation for ROHC profiles defined in [RFC4997]. The formal description of the packet formats specifies all of the information needed to compress and decompress a header relative to the context.
このセクションでは、圧縮されたTCP / IPパケットフォーマットのセットを記述する。パケットフォーマットの規範的な説明は[RFC4997]で定義されたROHCプロファイルの正式な表記法を用いて説明します。パケットフォーマットの形式的記述は、コンテキストに対してヘッダを圧縮し解凍するために必要なすべての情報を指定します。
In particular, the notation provides a list of all the fields present in the uncompressed and compressed TCP/IP headers, and defines how to map from each uncompressed packet to its compressed equivalent and vice versa.
具体的には、表記法は、非圧縮および圧縮されたTCP / IPヘッダ内に存在するすべてのフィールドのリストを提供し、その圧縮された同等の、またはその逆に各非圧縮パケットからマッピングする方法を定義します。
The compressed header formats are defined as two separate sets: one set for the packets where the innermost IP header contains a sequential IP-ID (either network byte order or byte swapped), and one set for the packets without sequential IP-ID (either random, zero, or no IP-ID).
最も内側のIPヘッダは順次IP-ID（ネットワークバイト順またはバイトのいずれかが交換）を含むパケットのための一組、およびパケットのための一組の順次IP-IDなしで（次のいずれか圧縮ヘッダフォーマットは、2つの別個のセットとして定義されますランダム、ゼロ、または全くIP-ID）。
These two sets of header formats are referred to as the "sequential" and the "random" set of header formats, respectively.
ヘッダ・フォーマットのこれらの二組は、それぞれ、「シーケンシャル」とヘッダフォーマットの「ランダム」セットと呼ばれます。
In addition, there is one compressed format that is common to both sets of header formats and that can thus be used regardless of the type of IP-ID behavior. This format can transmit rarely changing fields and also send the frequently changing fields coded in variable lengths. It can also change the value of control fields such as IP-ID behavior and ECN behavior.
また、ヘッダ・フォーマットの両方のセットに共通であり、それは、このようにIP-IDの挙動のタイプに関係なく使用することができる1つの圧縮形式があります。このフォーマットはほとんど変化しないフィールドを送信し、また、可変長で符号化され、頻繁に変化するフィールドを送信することができます。それはまた、IP-IDの行動やECNの動作と制御フィールドの値を変更することができます。
All compressed base headers contain a 3-bit CRC, unless they update control fields such as "ip_id_behavior" or "ecn_used" that affect the interpretation of subsequent headers. Headers that can modify these control fields carry a 7-bit CRC instead.
彼らは、「ip_id_behavior」又は「ecn_used」後続ヘッダの解釈に影響を与えるような制御フィールドを更新しない限り、全ての圧縮ベースヘッダーは、3ビットのCRCを含みます。これらの制御フィールドを変更することができますヘッダーが代わりに7ビットのCRCを運びます。
When discussing LSB-encoded fields below, "p" equals the "offset_param" and "k" equals the "num_lsbs_param" in [RFC4997]. The encoding methods used in the compressed base headers are based on the following design criteria:
以下LSB符号化されたフィールドを論じるとき、「P」は「offset_param」および「K」は、[RFC4997]に「num_lsbs_param」に等しい等しいです。圧縮されたベースヘッダーで使用される符号化方式は、次の設計基準に基づいています。
o MSN
お ＭＳん
Since the MSN is a number generated by the compressor, it only
needs to be large enough to ensure robust operation and to
accommodate a small amount of reordering [RFC4163]. Therefore,
each compressed base header has an MSN field that is LSB-
encoded with k=4 and p=4 to handle a reordering depth of up to
4 packets. Additional guidance to improve robustness when reordering is possible can be found in [RFC4224].
4つのパケット。 [RFC4224]で見つけることができる可能性ある並べ替えたときに、追加のガイダンスは、堅牢性を向上させます。
o TCP Sequence Number
TCPシーケンス番号O
ROHC-TCP has the capability to handle bulk data transfers
efficiently, for which the sequence number is expected to
increase by about 1460 octets (which can be represented by 11
bits). For the compressed base headers to handle
retransmissions (i.e., negative delta to the sequence number),
the LSB interpretation interval has to handle negative offsets
about as large as positive offsets, which means that one more
bit is needed.
Also, for ROHC-TCP to be robust to losses, two additional bits are added to the LSB encoding of the sequence number. This means that the base headers should contain at least 14 bits of LSB-encoded sequence number when present. According to the logic above, the LSB offset value is set to be as large as the positive offset, i.e., p = 2^(k-1)-1.
ROHC-TCPは損失に対してロバストであるためにも、2つの追加のビットは、シーケンス番号のLSB符号化に追加されます。これは、存在する場合、ベースヘッダーがLSB符号化されたシーケンス番号の少なくとも14ビットを含むべきであることを意味します。上記ロジックに従って、LSBオフセット値は正のオフセット、すなわち、P = 2 ^（K-1）と同じ大きさに設定されている-1。
o TCP Acknowledgment Number
TCP受信確認番号O
The design criterion for the acknowledgment number is similar
to that of the TCP Sequence Number. However, often only every
other data packet is acknowledged, which means that the
expected delta value is twice as large as for sequence numbers.
Therefore, at least 15 bits of acknowledgment number should be used in compressed base headers. Since the acknowledgment number is expected to constantly increase, and the only exception to this is packet reordering (either on the ROHC channel [RFC3759] or prior to the compression point), the negative offset for LSB encoding is set to be 1/4 of the total interval, i.e., p = 2^(k-2)-1.
したがって、確認応答番号の少なくとも15ビットは、圧縮されたベースヘッダーで使用されるべきです。確認応答番号は絶えず増加すると予想され、パケットは、この唯一の例外を並べ替えている（どちらかROHCチャンネル[RFC3759]または圧縮点の前に）LSB符号化を1/4に設定されているため、負のオフセット以来総間隔、すなわち、P = 2 ^（K-2）-1。
o TCP Window
TCPウィンドウO
The TCP Window field is expected to increase in increments of
similar size as the TCP Sequence Number, and therefore the
design criterion for the TCP window is to send at least 14 bits
when used.
o IP-ID
O IP-ID
For the "sequential" set of packet formats, all the compressed
base headers contain LSB-encoded IP-ID offset bits, where the
offset is the difference between the value of the MSN field and the value of the IP-ID field. The requirement is that at least
3 bits of IP-ID should always be present, but it is preferable
to use 4 to 7 bits. When k=3 then p=1, and if k>3 then p=3
since the offset is expected to increase most of the time.
Each set of header formats contains eight different compressed base headers. The reason for having this large number of header formats is that the TCP Sequence Number, TCP Acknowledgment Number, and TCP Window are frequently changing in a non-linear pattern.
ヘッダフォーマットの各セットは、8つの異なる圧縮されたベースヘッダーを含んでいます。ヘッダ・フォーマットのこの数が多い理由は、TCPシーケンス番号、TCP確認応答番号、およびTCPウィンドウが頻繁に非直線的なパターンで変化されることです。
The design of the header formats is derived from the field behavior analysis found in [RFC4413].
ヘッダフォーマットの設計は、[RFC4413]に見られるフィールド行動分析に由来します。
All of the compressed base headers transmit LSB-encoded MSN bits, the TCP Push flag, and a CRC, and in addition to this, all the base headers in the sequential packet format set contain LSB-encoded IP-ID bits.
圧縮されたベースヘッダーが送信LSB符号化されたMSNビット、TCPプッシュフラグ、及びCRCのすべて、およびこれに加えて、シーケンシャル・パケット・フォーマット・セット内のすべての基地ヘッダはLSB-符号化IP-IDのビットを含みます。
The following header formats exist in both the sequential and random packet format sets:
次のヘッダフォーマットは、シーケンシャルおよびランダムパケットフォーマットセットの両方に存在します。
o Format 1: This header format carries changes to the TCP Sequence Number and is expected to be used on the downstream of a data transfer.
Oフォーマット1：このヘッダー形式は、TCPシーケンス番号の変更を運び、データ転送の下流で使用されることが予想されます。
o Format 2: This header format carries the TCP Sequence Number in scaled form and is expected to be useful for the downstream of a data transfer where the payload size is constant for multiple packets.
Oフォーマット2：このヘッダーフォーマットはスケーリングされた形でTCPシーケンス番号を運ぶペイロードサイズが複数のパケットに対して一定であるデータ転送の下流に有用であることが期待されます。
o Format 3: This header format carries changes in the TCP Acknowledgment Number and is expected to be useful for the acknowledgment direction of a data transfer.
O形式3：このヘッダー形式は、TCP確認応答数の変化を運び、データ転送の確認応答の方向のために有用であると期待されます。
o Format 4: This header format is similar to format 3, but carries a scaled TCP Acknowledgment Number.
O形式4：このヘッダー形式は、形式3と同様であるが、スケーリングされたTCP確認応答番号を運びます。
o Format 5: This header format carries both the TCP Sequence Number and the TCP Acknowledgment Number and is expected to be useful for flows that send data in both directions.
O形式5：このヘッダー形式は、TCPシーケンス番号とTCP確認応答番号の両方を運び、両方向にデータを送信するフローのために有用であると期待されます。
o Format 6: This header format is similar to format 5, but carries the TCP Sequence Number in scaled form, when the payload size is static for certain intervals in a data flow.
O形式6：このヘッダーフォーマットは、フォーマット5と同様であるが、ペイロードサイズは、データフロー内の特定の間隔で静止している場合、スケーリングされた形でTCPシーケンス番号を運びます。
o Format 7: This header format carries changes to both the TCP Acknowledgment Number and the TCP Window and is expected to be useful for the acknowledgment flows of data connections.
O形式7：このヘッダー形式は、TCP確認応答番号とTCPウィンドウの両方に変更を運び、データ接続の確認応答フローのために有用であると期待されます。
o Format 8: This header format is used to convey changes to some of the more seldom changing fields in the TCP flow, such as ECN behavior, RST/SYN/FIN flags, the TTL/Hop Limit, and the TCP options list. This format carries a 7-bit CRC, since it can change the structure of the contents of the irregular chain for subsequent packets. Note that this can be seen as a reduced form of the common packet format.
O形式8：このヘッダーフォーマットは、ECNの動作としてTCPフローのよりほとんど変化しないフィールドの一部、RST / SYN / FINフラグ、TTL /ホップリミット、及びTCPオプションリストへの変更を伝えるために使用されます。それは後続のパケットのために不規則なチェーンの内容の構造を変更することができるので、このフォーマットは、7ビットのCRCを運びます。これは、共通のパケット・フォーマットの還元形態と見なすことができることに留意されたいです。
o Common header format: The common header format can be used for all kinds of IP-ID behavior and should be useful when some of the more rarely changing fields in the IP or TCP header change. Since this header format can update control fields that decide how the decompressor interprets packets, it carries a 7-bit CRC to reduce the probability of context corruption. This header can basically convey changes to any of the dynamic fields in the IP and TCP headers, and it uses a large set of flags to provide information about which fields are present in the header format.
O共通ヘッダー形式：共通ヘッダフォーマットは、IP-IDの行動のすべての種類のために使用することができ、IPやTCPヘッダの変更でよりめったに変更しないフィールドの際にいくつかの有用なはずです。このヘッダー形式は減圧装置がパケットをどのように解釈するかを決める制御フィールドを更新することができるので、コンテキスト破損の確率を低減するために7ビットのCRCを運びます。このヘッダは、基本的にはIPおよびTCPヘッダ内の動的フィールドのいずれかに変更を伝えることができ、それはフィールドがヘッダ形式で存在する情報を提供するためにフラグの大きなセットを使用します。
//////////////////////////////////////////// // Constants ////////////////////////////////////////////
//////////////////////////////////////////// //定数/// /////////////////////////////////////////
IP_ID_BEHAVIOR_SEQUENTIAL = 0;
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED = 1;
IP_ID_BEHAVIOR_RANDOM = 2;
IP_ID_BEHAVIOR_ZERO = 3;
//////////////////////////////////////////// // Global control fields ////////////////////////////////////////////
//////////////////////////////////////////// //グローバル制御フィールド/ ///////////////////////////////////////////
CONTROL {
ecn_used [ 1 ];
msn [ 16 ];
}
/////////////////////////////////////////////// // Encoding methods not specified in FN syntax ///////////////////////////////////////////////
/////////////////////////////////////////////// //エンコーディングFNの構文で指定されていない方法//////////////////////////////////////////// ///
list_tcp_options "defined in Section 6.3.3";
inferred_ip_v4_header_checksum "defined in Section 6.4.1";
inferred_mine_header_checksum "defined in Section 6.4.2";
inferred_ip_v4_length "defined in Section 6.4.3";
inferred_ip_v6_length "defined in Section 6.4.4";
inferred_offset "defined in Section 6.4.5";
baseheader_extension_headers "defined in Section 6.4.6";
baseheader_outer_headers "defined in Section 6.4.7";
//////////////////////////////////////////// // General encoding methods ////////////////////////////////////////////
//////////////////////////////////////////// //一般的な符号化方式/ ///////////////////////////////////////////
static_or_irreg(flag, width) { UNCOMPRESSED { field [ width ]; }
static_or_irreg（フラグ、幅）{UNCOMPRESSED {フィールド[幅]。 }
COMPRESSED irreg_enc {
field =:= irregular(width) [ width ];
ENFORCE(flag == 1);
}
COMPRESSED static_enc {
field =:= static [ 0 ];
ENFORCE(flag == 0);
}
}
zero_or_irreg(flag, width) { UNCOMPRESSED { field [ width ]; }
zero_or_irreg（フラグ、幅）{UNCOMPRESSED {フィールド[幅]。 }
COMPRESSED non_zero {
field =:= irregular(width) [ width ];
ENFORCE(flag == 0);
}
COMPRESSED zero {
field =:= uncompressed_value(width, 0) [ 0 ];
ENFORCE(flag == 1);
}
}
variable_length_32_enc(flag) { UNCOMPRESSED { field [ 32 ]; }
variable_length_32_enc（フラグ）{UNCOMPRESSED {フィールド[32]。 }
COMPRESSED not_present {
COMPRESSED NOT_PRESENT {
field =:= static [ 0 ];
ENFORCE(flag == 0);
}
COMPRESSED lsb_8_bit {
field =:= lsb(8, 63) [ 8 ];
ENFORCE(flag == 1);
}
COMPRESSED lsb_16_bit {
field =:= lsb(16, 16383) [ 16 ];
ENFORCE(flag == 2);
}
COMPRESSED irreg_32_bit {
field =:= irregular(32) [ 32 ];
ENFORCE(flag == 3);
}
}
optional32(flag) { UNCOMPRESSED { item [ 0, 32 ]; }
optional32（フラグ）{UNCOMPRESSED {アイテム[0、32]。 }
COMPRESSED present {
item =:= irregular(32) [ 32 ];
ENFORCE(flag == 1);
}
COMPRESSED not_present {
item =:= compressed_value(0, 0) [ 0 ];
ENFORCE(flag == 0);
}
}
lsb_7_or_31
{
UNCOMPRESSED {
item [ 32 ];
}
COMPRESSED lsb_7 {
discriminator =:= '0' [ 1 ];
item =:= lsb(7, 8) [ 7 ];
}
COMPRESSED lsb_31 {
COMPRESSED lsb_31 {
discriminator =:= '1' [ 1 ];
item =:= lsb(31, 256) [ 31 ];
}
}
opt_lsb_7_or_31(flag) { UNCOMPRESSED { item [ 0, 32 ]; }
opt_lsb_7_or_31（フラグ）{UNCOMPRESSED {アイテム[0、32]。 }
COMPRESSED present {
item =:= lsb_7_or_31 [ 8, 32 ];
ENFORCE(flag == 1);
}
COMPRESSED not_present {
item =:= compressed_value(0, 0) [ 0 ];
ENFORCE(flag == 0);
}
}
crc3(data_value, data_length) { UNCOMPRESSED { }
CRC3（DATA_VALUE、DATA_LENGTH）{UNCOMPRESSED {}
COMPRESSED { crc_value =:= crc(3, 0x06, 0x07, data_value, data_length) [ 3 ]; } }
COMPRESSED {crc_value =：= CRC（3、0x06で、0x07の、DATA_VALUE、DATA_LENGTH）[3]。 }}
crc7(data_value, data_length) { UNCOMPRESSED { }
CRC7（DATA_VALUE、DATA_LENGTH）{UNCOMPRESSED {}
COMPRESSED { crc_value =:= crc(7, 0x79, 0x7f, data_value, data_length) [ 7 ]; } }
COMPRESSED {crc_value =：= CRC（7、0x79、0x7Fの、DATA_VALUE、DATA_LENGTH）[7]。 }}
one_bit_choice { UNCOMPRESSED { field [ 1 ];
one_bit_choice {UNCOMPRESSED {フィールド[1]。
}
｝
COMPRESSED zero {
field [ 1 ];
ENFORCE(field.UVALUE == 0);
}
COMPRESSED nonzero {
field [ 1 ];
ENFORCE(field.UVALUE == 1);
}
}
// Encoding method for updating a scaled field and its associated // control fields. Should be used both when the value is scaled // or unscaled in a compressed format. field_scaling(stride_value, scaled_value, unscaled_value) { UNCOMPRESSED { residue_field [ 32 ]; }
スケールフィールドとそれに関連する//制御フィールドを更新するための//エンコーディング方法。値が圧縮形式で//スケーリングまたはスケーリングされていないれたときの両方に使用されるべきです。 field_scaling（stride_value、scaled_value、unscaled_value）{UNCOMPRESSED {residue_field [32]。 }
COMPRESSED no_scaling {
ENFORCE(stride_value == 0);
ENFORCE(residue_field.UVALUE == unscaled_value);
ENFORCE(scaled_value == 0);
}
COMPRESSED scaling_used {
ENFORCE(stride_value != 0);
ENFORCE(residue_field.UVALUE == (unscaled_value % stride_value));
ENFORCE(unscaled_value ==
scaled_value * stride_value + residue_field.UVALUE);
}
}
////////////////////////////////////////////
// IPv6 Destination options header
////////////////////////////////////////////
ip_dest_opt
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
value [ length.UVALUE * 64 + 48 ];
}
DEFAULT {
length =:= static;
next_header =:= static;
value =:= static;
}
COMPRESSED dest_opt_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
}
COMPRESSED dest_opt_dynamic { value =:= irregular(length.UVALUE * 64 + 48) [ length.UVALUE * 64 + 48 ]; }
COMPRESSED dest_opt_dynamic {値=：=不規則（length.UVALUE * 64 + 48）[length.UVALUE * 64 + 48]。 }
COMPRESSED dest_opt_0_replicate { discriminator =:= '00000000' [ 8 ]; }
COMPRESSED dest_opt_0_replicate {弁別=：= '00000000' [8]。 }
COMPRESSED dest_opt_1_replicate {
discriminator =:= '10000000' [ 8 ];
length =:= irregular(8) [ 8 ];
value =:=
irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
}
COMPRESSED dest_opt_irregular { } }
COMPRESSED dest_opt_irregular {}}
//////////////////////////////////////////// // IPv6 Hop-by-Hop options header ////////////////////////////////////////////
//////////////////////////////////////////// // IPv6のホップバイ-Hopオプションヘッダ////////////////////////////////////////////
ip_hop_opt
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
value [ length.UVALUE * 64 + 48 ];
}
DEFAULT {
length =:= static;
next_header =:= static;
value =:= static;
}
COMPRESSED hop_opt_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
}
COMPRESSED hop_opt_dynamic { value =:= irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; }
COMPRESSED hop_opt_dynamic {値=：=不規則（length.UVALUE * 64 + 48）[length.UVALUE * 64 + 48]。 }
COMPRESSED hop_opt_0_replicate { discriminator =:= '00000000' [ 8 ]; }
COMPRESSED hop_opt_0_replicate {弁別=：= '00000000' [8]。 }
COMPRESSED hop_opt_1_replicate {
discriminator =:= '10000000' [ 8 ];
length =:= irregular(8) [ 8 ];
value =:=
irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
}
COMPRESSED hop_opt_irregular { } }
COMPRESSED hop_opt_irregular {}}
//////////////////////////////////////////// // IPv6 Routing header ////////////////////////////////////////////
//////////////////////////////////////////// // IPv6ルーティングヘッダ/ ///////////////////////////////////////////
ip_rout_opt
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
value [ length.UVALUE * 64 + 48 ];
}
DEFAULT {
length =:= static;
next_header =:= static;
value =:= static;
}
COMPRESSED rout_opt_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
value =:=
irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
}
｝
COMPRESSED rout_opt_dynamic { }
COMPRESSED rout_opt_dynamic {}
COMPRESSED rout_opt_0_replicate { discriminator =:= '00000000' [ 8 ]; }
COMPRESSED rout_opt_0_replicate {弁別=：= '00000000' [8]。 }
COMPRESSED rout_opt_0_replicate {
discriminator =:= '10000000' [ 8 ];
length =:= irregular(8) [ 8 ];
value =:=
irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
}
COMPRESSED rout_opt_irregular { } }
COMPRESSED rout_opt_irregular {}}
//////////////////////////////////////////// // GRE Header ////////////////////////////////////////////
//////////////////////////////////////////// // GO //ヘッダー//////////////////////////////////////////
optional_checksum(flag_value)
{
UNCOMPRESSED {
value [ 0, 16 ];
reserved1 [ 0, 16 ];
}
COMPRESSED cs_present {
value =:= irregular(16) [ 16 ];
reserved1 =:= uncompressed_value(16, 0) [ 0 ];
ENFORCE(flag_value == 1);
}
COMPRESSED not_present {
value =:= compressed_value(0, 0) [ 0 ];
reserved1 =:= compressed_value(0, 0) [ 0 ];
ENFORCE(flag_value == 0);
}
}
gre_proto { UNCOMPRESSED { protocol [ 16 ];
gre_proto {UNCOMPRESSED {プロトコル[16]。
}
｝
COMPRESSED ether_v4 {
discriminator =:= compressed_value(1, 0) [ 1 ];
protocol =:= uncompressed_value(16, 0x0800) [ 0 ];
}
COMPRESSED ether_v6 {
discriminator =:= compressed_value(1, 1) [ 1 ];
protocol =:= uncompressed_value(16, 0x86DD) [ 0 ];
}
}
gre
{
UNCOMPRESSED {
c_flag [ 1 ];
r_flag =:= uncompressed_value(1, 0) [ 1 ];
k_flag [ 1 ];
s_flag [ 1 ];
reserved0 =:= uncompressed_value(9, 0) [ 9 ];
version =:= uncompressed_value(3, 0) [ 3 ];
protocol [ 16 ];
checksum_and_res [ 0, 32 ];
key [ 0, 32 ];
sequence_number [ 0, 32 ];
}
DEFAULT {
c_flag =:= static;
k_flag =:= static;
s_flag =:= static;
protocol =:= static;
key =:= static;
sequence_number =:= static;
}
COMPRESSED gre_static {
protocol =:= gre_proto [ 1 ];
c_flag =:= irregular(1) [ 1 ];
k_flag =:= irregular(1) [ 1 ];
s_flag =:= irregular(1) [ 1 ];
padding =:= compressed_value(4, 0) [ 4 ];
key =:= optional32(k_flag.UVALUE) [ 0, 32 ];
}
COMPRESSED gre_dynamic { checksum_and_res =:=
COMPRESSED gre_dynamic {checksum_and_res = =
optional_checksum(c_flag.UVALUE) [ 0, 16 ];
sequence_number =:= optional32(s_flag.UVALUE) [ 0, 32 ];
}
COMPRESSED gre_0_replicate {
discriminator =:= '00000000' [ 8 ];
checksum_and_res =:=
optional_checksum(c_flag.UVALUE) [ 0, 16 ];
sequence_number =:=
optional32(s_flag.UVALUE) [ 0, 8, 32 ];
}
COMPRESSED gre_1_replicate {
discriminator =:= '10000' [ 5 ];
c_flag =:= irregular(1) [ 1 ];
k_flag =:= irregular(1) [ 1 ];
s_flag =:= irregular(1) [ 1 ];
checksum_and_res =:=
optional_checksum(c_flag.UVALUE) [ 0, 16 ];
key =:= optional32(k_flag.UVALUE) [ 0, 32 ];
sequence_number =:= optional32(s_flag.UVALUE) [ 0, 32 ];
}
COMPRESSED gre_irregular {
checksum_and_res =:=
optional_checksum(c_flag.UVALUE) [ 0, 16 ];
sequence_number =:=
opt_lsb_7_or_31(s_flag.UVALUE) [ 0, 8, 32 ];
}
}
///////////////////////////////////////////// // MINE header /////////////////////////////////////////////
///////////////////////////////////////////// // MINEヘッダ/ ////////////////////////////////////////////
mine
{
UNCOMPRESSED {
next_header [ 8 ];
s_bit [ 1 ];
res_bits [ 7 ];
checksum [ 16 ];
orig_dest [ 32 ];
orig_src [ 0, 32 ];
}
DEFAULT { next_header =:= static;
DEFAULT {next_header =：=静的。
s_bit =:= static;
res_bits =:= static;
checksum =:= inferred_mine_header_checksum;
orig_dest =:= static;
orig_src =:= static;
}
COMPRESSED mine_static {
next_header =:= irregular(8) [ 8 ];
s_bit =:= irregular(1) [ 1 ];
// Reserved bits are included to achieve byte-alignment
res_bits =:= irregular(7) [ 7 ];
orig_dest =:= irregular(32) [ 32 ];
orig_src =:= optional32(s_bit.UVALUE) [ 0, 32 ];
}
COMPRESSED mine_dynamic { }
COMPRESSED mine_dynamic {}
COMPRESSED mine_0_replicate { discriminator =:= '00000000' [ 8 ]; }
COMPRESSED mine_0_replicate {弁別=：= '00000000' [8]。 }
COMPRESSED mine_1_replicate {
discriminator =:= '10000000' [ 8 ];
s_bit =:= irregular(1) [ 1 ];
res_bits =:= irregular(7) [ 7 ];
orig_dest =:= irregular(32) [ 32 ];
orig_src =:= optional32(s_bit.UVALUE) [ 0, 32 ];
}
COMPRESSED mine_irregular { } }
COMPRESSED mine_irregular {}}
///////////////////////////////////////////// // Authentication Header (AH) /////////////////////////////////////////////
///////////////////////////////////////////// //認証ヘッダー（ ）AH /////////////////////////////////////////////
ah
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
res_bits [ 16 ];
spi [ 32 ];
sequence_number [ 32 ];
auth_data [ length.UVALUE*32-32 ];
}
｝
DEFAULT {
next_header =:= static;
length =:= static;
res_bits =:= static;
spi =:= static;
sequence_number =:= static;
}
COMPRESSED ah_static {
next_header =:= irregular(8) [ 8 ];
length =:= irregular(8) [ 8 ];
spi =:= irregular(32) [ 32 ];
}
COMPRESSED ah_dynamic {
res_bits =:= irregular(16) [ 16 ];
sequence_number =:= irregular(32) [ 32 ];
auth_data =:=
irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ];
}
COMPRESSED ah_0_replicate {
discriminator =:= '00000000' [ 8 ];
sequence_number =:= irregular(32) [ 32 ];
auth_data =:=
irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ];
}
COMPRESSED ah_1_replicate {
discriminator =:= '10000000' [ 8 ];
length =:= irregular(8) [ 8 ];
res_bits =:= irregular(16) [ 16 ];
spi =:= irregular(32) [ 32 ];
sequence_number =:= irregular(32) [ 32 ];
auth_data =:=
irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ];
}
COMPRESSED ah_irregular {
sequence_number =:= lsb_7_or_31 [ 8, 32 ];
auth_data =:=
irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ];
}
}
/////////////////////////////////////////////
/////////////////////////////////////////////
// ESP header (NULL encrypted) /////////////////////////////////////////////
// ESPヘッダ（NULLは、暗号化された）////////////////////////////////////////// ///
// The value of the Next Header field from the trailer
// part of the packet is passed as a parameter.
esp_null(next_header_value)
{
UNCOMPRESSED {
spi [ 32 ];
sequence_number [ 32 ];
}
CONTROL { nh_field [ 8 ]; }
CONTROL {nh_field [8]。 }
DEFAULT {
spi =:= static;
sequence_number =:= static;
nh_field =:= static;
}
COMPRESSED esp_static {
nh_field =:= compressed_value(8, next_header_value) [ 8 ];
spi =:= irregular(32) [ 32 ];
}
COMPRESSED esp_dynamic { sequence_number =:= irregular(32) [ 32 ]; }
COMPRESSED esp_dynamic {SEQUENCE_NUMBER =：=不規則（32）[32]。 }
COMPRESSED esp_0_replicate {
discriminator =:= '00000000' [ 8 ];
sequence_number =:= irregular(32) [ 32 ];
}
COMPRESSED esp_1_replicate {
discriminator =:= '10000000' [ 8 ];
spi =:= irregular(32) [ 32 ];
sequence_number =:= irregular(32) [ 32 ];
}
COMPRESSED esp_irregular { sequence_number =:= lsb_7_or_31 [ 8, 32 ]; } }
COMPRESSED esp_irregular {SEQUENCE_NUMBER =：= lsb_7_or_31 [8、32]。 }}
///////////////////////////////////////////// // IPv6 Header
///////////////////////////////////////////// // IPv6のヘッダー
/////////////////////////////////////////////
/////////////////////////////////////////////
fl_enc { UNCOMPRESSED { flow_label [ 20 ]; }
fl_enc {UNCOMPRESSED {flow_label [20]。 }
COMPRESSED fl_zero {
discriminator =:= '0' [ 1 ];
flow_label =:= uncompressed_value(20, 0) [ 0 ];
reserved =:= '0000' [ 4 ];
}
COMPRESSED fl_non_zero {
discriminator =:= '1' [ 1 ];
flow_label =:= irregular(20) [ 20 ];
}
}
// The is_innermost flag is true if this is the innermost IP header
// If extracting the irregular chain for a compressed packet:
// - ttl_irregular_chain_flag must have the same value as it had when
// processing co_baseheader.
// - ip_inner_ecn is bound in this encoding method and the value that
// it gets bound to should be passed to the tcp encoding method
// For other formats than the irregular chain, these two are ignored
ipv6(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn)
{
UNCOMPRESSED {
version =:= uncompressed_value(4, 6) [ 4 ];
dscp [ 6 ];
ip_ecn_flags [ 2 ];
flow_label [ 20 ];
payload_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dst_addr [ 128 ];
}
DEFAULT {
dscp =:= static;
ip_ecn_flags =:= static;
flow_label =:= static;
payload_length =:= inferred_ip_v6_length;
next_header =:= static;
ttl_hopl =:= static;
src_addr =:= static;
dst_addr =:= static;
}
COMPRESSED ipv6_static {
version_flag =:= '1' [ 1 ];
reserved =:= '00' [ 2 ];
flow_label =:= fl_enc [ 5, 21 ];
next_header =:= irregular(8) [ 8 ];
src_addr =:= irregular(128) [ 128 ];
dst_addr =:= irregular(128) [ 128 ];
}
COMPRESSED ipv6_dynamic {
dscp =:= irregular(6) [ 6 ];
ip_ecn_flags =:= irregular(2) [ 2 ];
ttl_hopl =:= irregular(8) [ 8 ];
}
COMPRESSED ipv6_replicate {
dscp =:= irregular(6) [ 6 ];
ip_ecn_flags =:= irregular(2) [ 2 ];
reserved =:= '000' [ 3 ];
flow_label =:= fl_enc [ 5, 21 ];
}
COMPRESSED ipv6_outer_without_ttl_irregular {
dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ];
ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ];
ENFORCE(ttl_irregular_chain_flag == 0);
ENFORCE(is_innermost == false);
}
COMPRESSED ipv6_outer_with_ttl_irregular {
dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ];
ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ];
ttl_hopl =:= irregular(8) [ 8 ];
ENFORCE(ttl_irregular_chain_flag == 1);
ENFORCE(is_innermost == false);
}
COMPRESSED ipv6_innermost_irregular {
ENFORCE(ip_inner_ecn == ip_ecn_flags.UVALUE);
ENFORCE(is_innermost == true);
}
}
/////////////////////////////////////////////
/////////////////////////////////////////////
// IPv4 Header /////////////////////////////////////////////
// IPv4のヘッダ/////////////////////////////////////////////
ip_id_enc_dyn(behavior) { UNCOMPRESSED { ip_id [ 16 ]; }
ip_id_enc_dyn（挙動）{UNCOMPRESSED {ip_id [16]。 }
COMPRESSED ip_id_seq {
ip_id =:= irregular(16) [ 16 ];
ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED) ||
(behavior == IP_ID_BEHAVIOR_RANDOM));
}
COMPRESSED ip_id_zero {
ip_id =:= uncompressed_value(16, 0) [ 0 ];
ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO);
}
}
ip_id_enc_irreg(behavior) { UNCOMPRESSED { ip_id [ 16 ]; }
ip_id_enc_irreg（挙動）{UNCOMPRESSED {ip_id [16]。 }
COMPRESSED ip_id_seq { ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL); }
COMPRESSED ip_id_seq {（動作== IP_ID_BEHAVIOR_SEQUENTIAL）をENFORCE。 }
COMPRESSED ip_id_seq_swapped {
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED);
}
COMPRESSED ip_id_rand {
ip_id =:= irregular(16) [ 16 ];
ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM);
}
COMPRESSED ip_id_zero {
ip_id =:= uncompressed_value(16, 0) [ 0 ];
ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO);
}
}
ip_id_behavior_choice(is_inner) {
ip_id_behavior_choice（is_inner）{
UNCOMPRESSED { behavior [ 2 ]; }
UNCOMPRESSED {挙動[2]。 }
DEFAULT { behavior =:= irregular(2); }
DEFAULT {挙動=：=不規則（2）。 }
COMPRESSED sequential {
behavior [ 2 ];
ENFORCE(is_inner == true);
ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL);
}
COMPRESSED sequential_swapped {
behavior [ 2 ];
ENFORCE(is_inner == true);
ENFORCE(behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED);
}
COMPRESSED random {
behavior [ 2 ];
ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
}
COMPRESSED zero {
behavior [ 2 ];
ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_ZERO);
}
}
// The is_innermost flag is true if this is the innermost IP header
// If extracting the irregular chain for a compressed packet:
// - ttl_irregular_chain_flag must have the same value as it had when
// processing co_baseheader.
// - ip_inner_ecn is bound in this encoding method and the value that
// it gets bound to should be passed to the tcp encoding method
// For other formats than the irregular chain, these two are ignored
ipv4(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn)
{
UNCOMPRESSED {
version =:= uncompressed_value(4, 4) [ 4 ];
hdr_length =:= uncompressed_value(4, 5) [ 4 ];
dscp [ 6 ];
ip_ecn_flags [ 2 ];
length [ 16 ];
ip_id [ 16 ];
rf =:= uncompressed_value(1, 0) [ 1 ];
df [ 1 ];
mf =:= uncompressed_value(1, 0) [ 1 ];
frag_offset =:= uncompressed_value(13, 0) [ 13 ];
ttl_hopl [ 8 ];
protocol [ 8 ];
checksum [ 16 ];
src_addr [ 32 ];
dst_addr [ 32 ];
}
CONTROL { ip_id_behavior [ 2 ]; }
CONTROL {ip_id_behavior [2]。 }
DEFAULT {
dscp =:= static;
ip_ecn_flags =:= static;
length =:= inferred_ip_v4_length;
df =:= static;
ttl_hopl =:= static;
protocol =:= static;
checksum =:= inferred_ip_v4_header_checksum;
src_addr =:= static;
dst_addr =:= static;
ip_id_behavior =:= static;
}
COMPRESSED ipv4_static {
version_flag =:= '0' [ 1 ];
reserved =:= '0000000' [ 7 ];
protocol =:= irregular(8) [ 8 ];
src_addr =:= irregular(32) [ 32 ];
dst_addr =:= irregular(32) [ 32 ];
}
COMPRESSED ipv4_dynamic {
reserved =:= '00000' [ 5 ];
df =:= irregular(1) [ 1 ];
ip_id_behavior =:= ip_id_behavior_choice(is_innermost) [ 2 ];
dscp =:= irregular(6) [ 6 ];
ip_ecn_flags =:= irregular(2) [ 2 ];
ttl_hopl =:= irregular(8) [ 8 ];
ip_id =:=
ip_id_enc_dyn(ip_id_behavior.UVALUE) [ 0, 16 ];
}
COMPRESSED ipv4_replicate {
COMPRESSED ipv4_replicate {
reserved =:= '0000' [ 4 ];
ip_id_behavior =:= ip_id_behavior_choice(is_innermost) [ 2 ];
ttl_flag =:= irregular(1) [ 1 ];
df =:= irregular(1) [ 1 ];
dscp =:= irregular(6) [ 6 ];
ip_ecn_flags =:= irregular(2) [ 2 ];
ip_id =:=
ip_id_enc_dyn(ip_id_behavior.UVALUE) [ 0, 16 ];
ttl_hopl =:=
static_or_irreg(ttl_flag.UVALUE, 8) [ 0, 8 ];
}
COMPRESSED ipv4_outer_without_ttl_irregular {
ip_id =:=
ip_id_enc_irreg(ip_id_behavior.UVALUE) [ 0, 16 ];
dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ];
ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ];
ENFORCE(ttl_irregular_chain_flag == 0);
ENFORCE(is_innermost == false);
}
COMPRESSED ipv4_outer_with_ttl_irregular {
ip_id =:=
ip_id_enc_irreg(ip_id_behavior.UVALUE) [ 0, 16 ];
dscp =:= static_or_irreg(ecn_used.UVALUE, 6) [ 0, 6 ];
ip_ecn_flags =:= static_or_irreg(ecn_used.UVALUE, 2) [ 0, 2 ];
ttl_hopl =:= irregular(8) [ 8 ];
ENFORCE(is_innermost == false);
ENFORCE(ttl_irregular_chain_flag == 1);
}
COMPRESSED ipv4_innermost_irregular {
ip_id =:=
ip_id_enc_irreg(ip_id_behavior.UVALUE) [ 0, 16 ];
ENFORCE(ip_inner_ecn == ip_ecn_flags.UVALUE);
ENFORCE(is_innermost == true);
}
}
///////////////////////////////////////////// // TCP Options /////////////////////////////////////////////
///////////////////////////////////////////// // TCPオプション/ ////////////////////////////////////////////
// nbits is bound to the remaining length (in bits) of TCP // options, including the EOL type byte. tcp_opt_eol(nbits) { UNCOMPRESSED {
// NBITSはEOL型バイトを含むTCP //オプションの（ビットで）残りの長さにバインドされています。 tcp_opt_eol（NBITS）{UNCOMPRESSED {
type =:= uncompressed_value(8, 0) [ 8 ];
padding =:=
uncompressed_value(nbits-8, 0) [ nbits-8 ];
}
CONTROL { pad_len [ 8 ]; }
制御pad_len {[8]。 }
COMPRESSED eol_list_item { pad_len =:= compressed_value(8, nbits-8) [ 8 ]; }
COMPRESSED eol_list_item {pad_len =：= compressed_value（8、NBITS-8）[8]。 }
COMPRESSED eol_irregular {
pad_len =:= static;
ENFORCE(nbits-8 == pad_len.UVALUE);
}
}
tcp_opt_nop { UNCOMPRESSED { type =:= uncompressed_value(8, 1) [ 8 ]; }
tcp_opt_nop {UNCOMPRESSED {タイプ=：= uncompressed_value（8,1）[8]。 }
COMPRESSED nop_list_item { }
COMPRESSED nop_list_item {}
COMPRESSED nop_irregular { } }
COMPRESSED nop_irregular {}}
tcp_opt_mss
{
UNCOMPRESSED {
type =:= uncompressed_value(8, 2) [ 8 ];
length =:= uncompressed_value(8, 4) [ 8 ];
mss [ 16 ];
}
COMPRESSED mss_list_item { mss =:= irregular(16) [ 16 ]; }
COMPRESSED mss_list_item {MSS =：=不規則（16）[16]。 }
COMPRESSED mss_irregular {
mss =:= static;
}
} tcp_opt_wscale
{
UNCOMPRESSED {
type =:= uncompressed_value(8, 3) [ 8 ];
length =:= uncompressed_value(8, 3) [ 8 ];
wscale [ 8 ];
}
COMPRESSED wscale_list_item { wscale =:= irregular(8) [ 8 ]; }
COMPRESSED wscale_list_item {wscale =：=不規則（8）[8]。 }
COMPRESSED wscale_irregular { wscale =:= static; } }
COMPRESSED wscale不規則{スケール=：=静的。 }}
ts_lsb { UNCOMPRESSED { tsval [ 32 ]; }
ts_lsb {UNCOMPRESSED {tsval [32]。 }
COMPRESSED tsval_7 {
discriminator =:= '0' [ 1 ];
tsval =:= lsb(7, -1) [ 7 ];
}
COMPRESSED tsval_14 {
discriminator =:= '10' [ 2 ];
tsval =:= lsb(14, -1) [ 14 ];
}
COMPRESSED tsval_21 {
discriminator =:= '110' [ 3 ];
tsval =:= lsb(21, 0x00040000) [ 21 ];
}
COMPRESSED tsval_29 {
discriminator =:= '111' [ 3 ];
tsval =:= lsb(29, 0x04000000) [ 29 ];
}
}
tcp_opt_ts { UNCOMPRESSED { type =:= uncompressed_value(8, 8) [ 8 ];
tcp_opt_ts {UNCOMPRESSED {タイプ=：= uncompressed_value（8,8）[8]。
length =:= uncompressed_value(8, 10) [ 8 ];
tsval [ 32 ];
tsecho [ 32 ];
}
COMPRESSED tsopt_list_item {
tsval =:= irregular(32) [ 32 ];
tsecho =:= irregular(32) [ 32 ];
}
COMPRESSED tsopt_irregular {
tsval =:= ts_lsb [ 8, 16, 24, 32 ];
tsecho =:= ts_lsb [ 8, 16, 24, 32 ];
}
}
sack_var_length_enc(base) { UNCOMPRESSED { sack_field [ 32 ]; }
sack_var_length_enc（ベース）{UNCOMPRESSED {sack_field [32]。 }
CONTROL {
sack_offset [ 32 ];
ENFORCE(sack_offset.UVALUE == (sack_field.UVALUE - base));
}
COMPRESSED lsb_15 {
discriminator =:= '0' [ 1 ];
sack_offset =:= lsb(15, -1) [ 15 ];
}
COMPRESSED lsb_22 {
discriminator =:= '10' [ 2 ];
sack_offset =:= lsb(22, -1) [ 22 ];
}
COMPRESSED lsb_30 {
discriminator =:= '11' [ 2 ];
sack_offset =:= lsb(30, -1) [ 30 ];
}
}
sack_block(prev_block_end) { UNCOMPRESSED { block_start [ 32 ];
sack_block（prev_block_end）{UNCOMPRESSED {BLOCK_START [32]。
block_end [ 32 ]; }
BLOCK_END [32]。 }
COMPRESSED {
block_start =:=
sack_var_length_enc(prev_block_end) [ 16, 24, 32 ];
block_end =:=
sack_var_length_enc(block_start) [ 16, 24, 32 ];
}
}
// The value of the parameter is set to the ack_number value // of the TCP header tcp_opt_sack(ack_value) {
//パラメータの値を// TCPヘッダtcp_opt_sack（ack_value）{ack_numberの値に設定されています
UNCOMPRESSED {
type =:= uncompressed_value(8, 5) [ 8 ];
length [ 8 ];
block_1 [ 64 ];
block_2 [ 0, 64 ];
block_3 [ 0, 64 ];
block_4 [ 0, 64 ];
}
DEFAULT {
length =:= static;
block_2 =:= uncompressed_value(0, 0);
block_3 =:= uncompressed_value(0, 0);
block_4 =:= uncompressed_value(0, 0);
}
COMPRESSED sack1_list_item {
discriminator =:= '00000001';
block_1 =:= sack_block(ack_value);
ENFORCE(length.UVALUE == 10);
}
COMPRESSED sack2_list_item {
discriminator =:= '00000010';
block_1 =:= sack_block(ack_value);
block_2 =:= sack_block(block_1_end.UVALUE);
ENFORCE(length.UVALUE == 18);
}
COMPRESSED sack3_list_item {
discriminator =:= '00000011';
block_1 =:= sack_block(ack_value);
block_2 =:= sack_block(block_1_end.UVALUE);
block_3 =:= sack_block(block_2_end.UVALUE);
ENFORCE(length.UVALUE == 26);
}
COMPRESSED sack4_list_item {
discriminator =:= '00000100';
block_1 =:= sack_block(ack_value);
block_2 =:= sack_block(block_1_end.UVALUE);
block_3 =:= sack_block(block_2_end.UVALUE);
block_4 =:= sack_block(block_3_end.UVALUE);
ENFORCE(length.UVALUE == 34);
}
COMPRESSED sack_unchanged_irregular {
discriminator =:= '00000000';
block_1 =:= static;
block_2 =:= static;
block_3 =:= static;
block_4 =:= static;
}
COMPRESSED sack1_irregular {
discriminator =:= '00000001';
block_1 =:= sack_block(ack_value);
ENFORCE(length.UVALUE == 10);
}
COMPRESSED sack2_irregular {
discriminator =:= '00000010';
block_1 =:= sack_block(ack_value);
block_2 =:= sack_block(block_1_end.UVALUE);
ENFORCE(length.UVALUE == 18);
}
COMPRESSED sack3_irregular {
discriminator =:= '00000011';
block_1 =:= sack_block(ack_value);
block_2 =:= sack_block(block_1_end.UVALUE);
block_3 =:= sack_block(block_2_end.UVALUE);
ENFORCE(length.UVALUE == 26);
}
COMPRESSED sack4_irregular {
discriminator =:= '00000100';
block_1 =:= sack_block(ack_value);
block_2 =:= sack_block(block_1_end.UVALUE);
block_3 =:= sack_block(block_2_end.UVALUE);
block_4 =:= sack_block(block_3_end.UVALUE);
ENFORCE(length.UVALUE == 34);
}
}
tcp_opt_sack_permitted
{
UNCOMPRESSED {
type =:= uncompressed_value(8, 4) [ 8 ];
length =:= uncompressed_value(8, 2) [ 8 ];
}
COMPRESSED sack_permitted_list_item { }
COMPRESSED sack_permitted_list_item {}
COMPRESSED sack_permitted_irregular { } }
COMPRESSION袋が不規則許可{}}
tcp_opt_generic
{
UNCOMPRESSED {
type [ 8 ];
length_msb =:= uncompressed_value(1, 0) [ 1 ];
length_lsb [ 7 ];
contents [ length_len.UVALUE*8-16 ];
}
CONTROL { option_static [ 1 ]; }
CONTROL {option_static [1]。 }
DEFAULT {
type =:= static;
length_lsb =:= static;
contents =:= static;
}
COMPRESSED generic_list_item {
type =:= irregular(8) [ 8 ];
option_static =:= one_bit_choice [ 1 ];
length_lsb =:= irregular(7) [ 7 ];
contents =:=
irregular(length_lsb.UVALUE*8-16) [ length_len.UVALUE*8-16 ];
}
// Used when context of option has option_static set to one COMPRESSED generic_static_irregular {
//オプションのコンテキストが一つの圧縮generic_static_irregular {にoption_staticセットを持っている場合に使用します
ENFORCE(option_static.UVALUE == 1); }
ENFORCE（option_static.UVALUE == 1）。 }
// An item that can change, but currently is unchanged
COMPRESSED generic_stable_irregular {
discriminator =:= '11111111' [ 8 ];
ENFORCE(option_static.UVALUE == 0);
}
// An item that is assumed to change constantly.
// Length is not allowed to change here, since a length change is
// most likely to cause new NOPs or an EOL length change.
COMPRESSED generic_full_irregular {
discriminator =:= '00000000' [ 8 ];
contents =:=
irregular(length_lsb.UVALUE*8-16) [ length_lsb.UVALUE*8-16 ];
ENFORCE(option_static.UVALUE == 0);
}
}
tcp_list_presence_enc(presence) { UNCOMPRESSED { tcp_options; }
tcp_list_presence_enc（プレゼンス）{UNCOMPRESSED {tcp_options。 }
COMPRESSED list_not_present {
tcp_options =:= static [ 0 ];
ENFORCE(presence == 0);
}
COMPRESSED list_present {
tcp_options =:= list_tcp_options [ VARIABLE ];
ENFORCE(presence == 1);
}
}
///////////////////////////////////////////// // TCP Header /////////////////////////////////////////////
///////////////////////////////////////////// // TCPヘッダー/ ////////////////////////////////////////////
port_replicate(flags) { UNCOMPRESSED { port [ 16 ]; }
port_replicate（フラグ）{UNCOMPRESSED {ポート[16]。 }
COMPRESSED port_static_enc {
COMPRESSED port_static_enc {
port =:= static [ 0 ];
ENFORCE(flags == 0b00);
}
COMPRESSED port_lsb8 {
port =:= lsb(8, 64) [ 8 ];
ENFORCE(flags == 0b01);
}
COMPRESSED port_irr_enc {
port =:= irregular(16) [ 16 ];
ENFORCE(flags == 0b10);
}
}
tcp_irreg_ip_ecn(ip_inner_ecn) { UNCOMPRESSED { ip_ecn_flags [ 2 ]; }
tcp_irreg_ip_ecn（ip_inner_ecn）{{UNCOMPRESSED ip_ecn_flags [2]。 }
COMPRESSED ecn_present {
// This field does not exist in the uncompressed header
// and therefore cannot use uncompressed_value.
ip_ecn_flags =:=
compressed_value(2, ip_inner_ecn) [ 2 ];
ENFORCE(ecn_used.UVALUE == 1);
}
COMPRESSED ecn_not_present {
ip_ecn_flags =:= static [ 0 ];
ENFORCE(ecn_used.UVALUE == 0);
}
}
rsf_index_enc { UNCOMPRESSED { rsf_flag [ 3 ]; }
rsf_index_enc {UNCOMPRESSED {rsf_flag [3]。 }
COMPRESSED none {
rsf_idx =:= '00' [ 2 ];
rsf_flag =:= uncompressed_value(3, 0x00);
}
COMPRESSED rst_only { rsf_idx =:= '01' [ 2 ];
COMPRESSED rst_only {rsf_idx =：= '01' [2]。
rsf_flag =:= uncompressed_value(3, 0x04); }
rsf_flag =：= uncompressed_value（3、0×04）。 }
COMPRESSED syn_only {
rsf_idx =:= '10' [ 2 ];
rsf_flag =:= uncompressed_value(3, 0x02);
}
COMPRESSED fin_only {
rsf_idx =:= '11' [ 2 ];
rsf_flag =:= uncompressed_value(3, 0x01);
}
}
optional_2bit_padding(used_flag) { UNCOMPRESSED { }
optional_2bit_padding（used_flag）{UNCOMPRESSED {}
COMPRESSED used {
padding =:= compressed_value(2, 0x0) [ 2 ];
ENFORCE(used_flag == 1);
}
COMPRESSED unused {
padding =:= compressed_value(0, 0x0);
ENFORCE(used_flag == 0);
}
}
// ack_stride_value is the user-selected stride for scaling the
// TCP ack_number
// ip_inner_ecn is the value bound when processing the innermost
// IP header (ipv4 or ipv6 encoding method)
tcp(payload_size, ack_stride_value, ip_inner_ecn)
{
UNCOMPRESSED {
src_port [ 16 ];
dst_port [ 16 ];
seq_number [ 32 ];
ack_number [ 32 ];
data_offset [ 4 ];
tcp_res_flags [ 4 ];
tcp_ecn_flags [ 2 ];
urg_flag [ 1 ];
ack_flag [ 1 ];
psh_flag [ 1 ];
rsf_flags [ 3 ];
window [ 16 ];
checksum [ 16 ];
urg_ptr [ 16 ];
options [ (data_offset.UVALUE-5)*32 ];
}
CONTROL {
seq_number_scaled [ 32 ];
seq_number_residue =:=
field_scaling(payload_size, seq_number_scaled.UVALUE,
seq_number.UVALUE) [ 32 ];
ack_stride [ 16 ];
ack_number_scaled [ 32 ];
ack_number_residue =:=
field_scaling(ack_stride.UVALUE, ack_number_scaled.UVALUE,
ack_number.UVALUE) [ 32 ];
ENFORCE(ack_stride.UVALUE == ack_stride_value);
}
INITIAL { ack_stride =:= uncompressed_value(16, 0); }
INITIAL {ack_stride =：= uncompressed_value（16、0）; }
DEFAULT {
src_port =:= static;
dst_port =:= static;
seq_number =:= static;
ack_number =:= static;
data_offset =:= inferred_offset;
tcp_res_flags =:= static;
tcp_ecn_flags =:= static;
urg_flag =:= static;
ack_flag =:= uncompressed_value(1, 1);
rsf_flags =:= uncompressed_value(3, 0);
window =:= static;
urg_ptr =:= static;
}
COMPRESSED tcp_static {
src_port =:= irregular(16) [ 16 ];
dst_port =:= irregular(16) [ 16 ];
}
COMPRESSED tcp_dynamic {
ecn_used =:= one_bit_choice [ 1 ];
ack_stride_flag =:= irregular(1) [ 1 ];
ack_zero =:= irregular(1) [ 1 ];
urp_zero =:= irregular(1) [ 1 ];
tcp_res_flags =:= irregular(4) [ 4 ];
tcp_ecn_flags =:= irregular(2) [ 2 ];
urg_flag =:= irregular(1) [ 1 ];
ack_flag =:= irregular(1) [ 1 ];
psh_flag =:= irregular(1) [ 1 ];
rsf_flags =:= irregular(3) [ 3 ];
msn =:= irregular(16) [ 16 ];
seq_number =:= irregular(32) [ 32 ];
ack_number =:=
zero_or_irreg(ack_zero.CVALUE, 32) [ 0, 32 ];
window =:= irregular(16) [ 16 ];
checksum =:= irregular(16) [ 16 ];
urg_ptr =:=
zero_or_irreg(urp_zero.CVALUE, 16) [ 0, 16 ];
ack_stride =:=
static_or_irreg(ack_stride_flag.CVALUE, 16) [ 0, 16 ];
options =:= list_tcp_options [ VARIABLE ];
}
COMPRESSED tcp_replicate {
reserved =:= '0' [ 1 ];
window_presence =:= irregular(1) [ 1 ];
list_present =:= irregular(1) [ 1 ];
src_port_presence =:= irregular(2) [ 2 ];
dst_port_presence =:= irregular(2) [ 2 ];
ack_stride_flag =:= irregular(1) [ 1 ];
ack_presence =:= irregular(1) [ 1 ];
urp_presence =:= irregular(1) [ 1 ];
urg_flag =:= irregular(1) [ 1 ];
ack_flag =:= irregular(1) [ 1 ];
psh_flag =:= irregular(1) [ 1 ];
rsf_flags =:= rsf_index_enc [ 2 ];
ecn_used =:= one_bit_choice [ 1 ];
msn =:= irregular(16) [ 16 ];
seq_number =:= irregular(32) [ 32 ];
src_port =:=
port_replicate(src_port_presence) [ 0, 8, 16 ];
dst_port =:=
port_replicate(dst_port_presence) [ 0, 8, 16 ];
window =:=
static_or_irreg(window_presence, 16) [ 0, 16 ];
urg_point =:=
static_or_irreg(urp_presence, 16) [ 0, 16 ];
ack_number =:=
static_or_irreg(ack_presence, 32) [ 0, 32 ];
ecn_padding =:=
optional_2bit_padding(ecn_used.CVALUE) [ 0, 2 ];
tcp_res_flags =:=
static_or_irreg(ecn_used.CVALUE, 4) [ 0, 4 ];
tcp_ecn_flags =:=
static_or_irreg(ecn_used.CVALUE, 2) [ 0, 2 ];
checksum =:= irregular(16) [ 16 ];
ack_stride =:=
static_or_irreg(ack_stride_flag.CVALUE, 16) [ 0, 16 ];
options =:=
tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ];
}
COMPRESSED tcp_irregular {
ip_ecn_flags =:= tcp_irreg_ip_ecn(ip_inner_ecn) [ 0, 2 ];
tcp_res_flags =:=
static_or_irreg(ecn_used.CVALUE, 4) [ 0, 4 ];
tcp_ecn_flags =:=
static_or_irreg(ecn_used.CVALUE, 2) [ 0, 2 ];
checksum =:= irregular(16) [ 16 ];
}
}
/////////////////////////////////////////////////// // Encoding methods used in compressed base headers ///////////////////////////////////////////////////
//////////////////////////////////////////////////圧縮されたベースヘッダーで使用/ //符号化方法//////////////////////////////////////// ///////////
dscp_enc(flag) { UNCOMPRESSED { dscp [ 6 ]; }
dscp_enc（フラグ）{UNCOMPRESSED {DSCP [6]。 }
COMPRESSED static_enc {
dscp =:= static [ 0 ];
ENFORCE(flag == 0);
}
COMPRESSED irreg {
dscp =:= irregular(6) [ 6 ];
padding =:= compressed_value(2, 0) [ 2 ];
ENFORCE(flag == 1);
}
}
ip_id_lsb(behavior, k, p) { UNCOMPRESSED { ip_id [ 16 ]; }
ip_id_lsb（挙動、K、P）{UNCOMPRESSED {ip_id [16]。 }
CONTROL {
ip_id_offset [ 16 ];
ip_id_nbo [ 16 ];
}
COMPRESSED nbo {
ip_id_offset =:= lsb(k, p) [ k ];
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL);
ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE);
}
COMPRESSED non_nbo {
ip_id_offset =:= lsb(k, p) [ k ];
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED);
ENFORCE(ip_id_nbo.UVALUE ==
(ip_id.UVALUE / 256) + (ip_id.UVALUE % 256) * 256);
ENFORCE(ip_id_nbo.ULENGTH == 16);
ENFORCE(ip_id_offset.UVALUE == ip_id_nbo.UVALUE - msn.UVALUE);
}
}
optional_ip_id_lsb(behavior, indicator) { UNCOMPRESSED { ip_id [ 16 ]; }
optional_ip_id_lsb（挙動、インジケータ）{UNCOMPRESSEDは{ip_id [16]。 }
COMPRESSED short {
ip_id =:= ip_id_lsb(behavior, 8, 3) [ 8 ];
ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
ENFORCE(indicator == 0);
}
COMPRESSED long {
ip_id =:= irregular(16) [ 16 ];
ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
ENFORCE(indicator == 1);
}
COMPRESSED not_present { ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) || (behavior == IP_ID_BEHAVIOR_ZERO)); } }
COMPRESSED NOT_PRESENT {ENFORCE（（挙動== IP_ID_BEHAVIOR_RANDOM）||（動作== IP_ID_BEHAVIOR_ZERO））。 }}
dont_fragment(version)
dont_fragment（バージョン）
{ UNCOMPRESSED { df [ 1 ]; }
{UNCOMPRESSED {DF [1]。 }
COMPRESSED v4 {
df =:= irregular(1) [ 1 ];
ENFORCE(version == 4);
}
COMPRESSED v6 {
df =:= compressed_value(1, 0) [ 1 ];
ENFORCE(version == 6);
}
}
////////////////////////////////// // Actual start of compressed packet formats // Important note: // The base header is the compressed representation // of the innermost IP header AND the TCP header. //////////////////////////////////
圧縮されたパケットフォーマットの////////////////////////////////// //実際の開始//重要：//基本ヘッダは、最も内側のIPヘッダとTCPヘッダの圧縮表現//です。 //////////////////////////////////
// ttl_irregular_chain_flag is set by the user if the TTL/Hop Limit
// of an outer header has changed. The same value must be passed as
// an argument to the ipv4/ipv6 encoding methods when extracting
// the irregular chain items.
co_baseheader(payload_size, ack_stride_value,
ttl_irregular_chain_flag)
{
UNCOMPRESSED v4 {
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
dscp [ 6 ];
ip_ecn_flags [ 2 ];
length [ 16 ];
ip_id [ 16 ];
rf =:= uncompressed_value(1, 0) [ 1 ];
df [ 1 ];
mf =:= uncompressed_value(1, 0) [ 1 ];
frag_offset =:= uncompressed_value(13, 0) [ 13 ];
ttl_hopl [ 8 ];
next_header [ 8 ];
checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dest_port [ 16 ];
seq_number [ 32 ];
ack_number [ 32 ];
data_offset [ 4 ];
tcp_res_flags [ 4 ];
tcp_ecn_flags [ 2 ];
urg_flag [ 1 ];
ack_flag [ 1 ];
psh_flag [ 1 ];
rsf_flags [ 3 ];
window [ 16 ];
tcp_checksum [ 16 ];
urg_ptr [ 16 ];
options [ (data_offset.UVALUE-5)*32 ];
}
UNCOMPRESSED v6 {
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
version =:= uncompressed_value(4, 6) [ 4 ];
dscp [ 6 ];
ip_ecn_flags [ 2 ];
flow_label [ 20 ];
payload_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dest_addr [ 128 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dest_port [ 16 ];
seq_number [ 32 ];
ack_number [ 32 ];
data_offset [ 4 ];
tcp_res_flags [ 4 ];
tcp_ecn_flags [ 2 ];
urg_flag [ 1 ];
ack_flag [ 1 ];
psh_flag [ 1 ];
rsf_flags [ 3 ];
window [ 16 ];
tcp_checksum [ 16 ];
urg_ptr [ 16 ];
options [ (data_offset.UVALUE-5)*32 ];
ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
}
CONTROL {
コントロール {
ip_id_behavior [ 2 ];
seq_number_scaled [ 32 ];
seq_number_residue =:=
field_scaling(payload_size, seq_number_scaled.UVALUE,
seq_number.UVALUE) [ 32 ];
ack_stride [ 16 ];
ack_number_scaled [ 32 ];
ack_number_residue =:=
field_scaling(ack_stride.UVALUE, ack_number_scaled.UVALUE,
ack_number.UVALUE) [ 32 ];
ENFORCE(ack_stride_value == ack_stride.UVALUE);
}
INITIAL { ack_stride =:= uncompressed_value(16, 0); }
INITIAL {ack_stride =：= uncompressed_value（16、0）; }
DEFAULT {
tcp_ecn_flags =:= static;
data_offset =:= inferred_offset;
tcp_res_flags =:= static;
rsf_flags =:= uncompressed_value(3, 0);
dest_port =:= static;
dscp =:= static;
src_port =:= static;
urg_flag =:= uncompressed_value(1, 0);
window =:= static;
dest_addr =:= static;
version =:= static;
ttl_hopl =:= static;
src_addr =:= static;
df =:= static;
ack_number =:= static;
urg_ptr =:= static;
seq_number =:= static;
ack_flag =:= uncompressed_value(1, 1);
// The default for "options" is case 2) and 3) from
// the list in section 6.3.1 (i.e. nothing present in the
// baseheader itself).
payload_length =:= inferred_ip_v6_length;
checksum =:= inferred_ip_v4_header_checksum;
length =:= inferred_ip_v4_length;
flow_label =:= static;
next_header =:= static;
ip_ecn_flags =:= static;
// The tcp_checksum has no default,
// it is considered a part of tcp_irregular
ip_id_behavior =:= static;
ecn_used =:= static;
ecn_used =：=静的;
// Default is to have no TTL in irregular chain // Can only be nonzero if co_common is used ENFORCE(ttl_irregular_chain_flag == 0); }
co_commonがENFORCE使用される場合//デフォルトのみ非ゼロであることができ//不規則鎖にはTTLを有していないことである（ttl_irregular_chain_flag == 0）。 }
//////////////////////////////////////////// // Common compressed packet format ////////////////////////////////////////////
//////////////////////////////////////////// //一般的な圧縮されたパケット・フォーマット////////////////////////////////////////////
COMPRESSED co_common {
discriminator =:= '1111101' [ 7 ];
ttl_hopl_outer_flag =:=
compressed_value(1, ttl_irregular_chain_flag) [ 1 ];
ack_flag =:= irregular(1) [ 1 ];
psh_flag =:= irregular(1) [ 1 ];
rsf_flags =:= rsf_index_enc [ 2 ];
msn =:= lsb(4, 4) [ 4 ];
seq_indicator =:= irregular(2) [ 2 ];
ack_indicator =:= irregular(2) [ 2 ];
ack_stride_indicator =:= irregular(1) [ 1 ];
window_indicator =:= irregular(1) [ 1 ];
ip_id_indicator =:= irregular(1) [ 1 ];
urg_ptr_present =:= irregular(1) [ 1 ];
reserved =:= compressed_value(1, 0) [ 1 ];
ecn_used =:= one_bit_choice [ 1 ];
dscp_present =:= irregular(1) [ 1 ];
ttl_hopl_present =:= irregular(1) [ 1 ];
list_present =:= irregular(1) [ 1 ];
ip_id_behavior =:= ip_id_behavior_choice(true) [ 2 ];
urg_flag =:= irregular(1) [ 1 ];
df =:= dont_fragment(version.UVALUE) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
seq_number =:=
variable_length_32_enc(seq_indicator.CVALUE) [ 0, 8, 16, 32 ];
ack_number =:=
variable_length_32_enc(ack_indicator.CVALUE) [ 0, 8, 16, 32 ];
ack_stride =:=
static_or_irreg(ack_stride_indicator.CVALUE, 16) [ 0, 16 ];
window =:=
static_or_irreg(window_indicator.CVALUE, 16) [ 0, 16 ];
ip_id =:=
optional_ip_id_lsb(ip_id_behavior.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
urg_ptr =:=
static_or_irreg(urg_ptr_present.CVALUE, 16) [ 0, 16 ];
dscp =:=
dscp_enc(dscp_present.CVALUE) [ 0, 8 ];
ttl_hopl =:=
static_or_irreg(ttl_hopl_present.CVALUE, 8) [ 0, 8 ];
options =:=
tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ];
}
// Send LSBs of sequence number
COMPRESSED rnd_1 {
discriminator =:= '101110' [ 6 ];
seq_number =:= lsb(18, 65535) [ 18 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send scaled sequence number LSBs
COMPRESSED rnd_2 {
discriminator =:= '1100' [ 4 ];
seq_number_scaled =:= lsb(4, 7) [ 4 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE(payload_size != 0);
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send acknowledgment number LSBs
COMPRESSED rnd_3 {
discriminator =:= '0' [ 1 ];
ack_number =:= lsb(15, 8191) [ 15 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send acknowledgment number scaled
COMPRESSED rnd_4 {
discriminator =:= '1101' [ 4 ];
ack_number_scaled =:= lsb(4, 3) [ 4 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE(ack_stride.UVALUE != 0);
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send ACK and sequence number
COMPRESSED rnd_5 {
discriminator =:= '100' [ 3 ];
psh_flag =:= irregular(1) [ 1 ];
msn =:= lsb(4, 4) [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
seq_number =:= lsb(14, 8191) [ 14 ];
ack_number =:= lsb(15, 8191) [ 15 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send both ACK and scaled sequence number LSBs
COMPRESSED rnd_6 {
discriminator =:= '1010' [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
psh_flag =:= irregular(1) [ 1 ];
ack_number =:= lsb(16, 16383) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
seq_number_scaled =:= lsb(4, 7) [ 4 ];
ENFORCE(payload_size != 0);
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send ACK and window
COMPRESSED rnd_7 {
discriminator =:= '101111' [ 6 ];
ack_number =:= lsb(18, 65535) [ 18 ];
window =:= irregular(16) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// An extended packet type for seldom-changing fields
// Can send LSBs of TTL, RSF flags, change ECN behavior, and
// options list
COMPRESSED rnd_8 {
discriminator =:= '10110' [ 5 ];
rsf_flags =:= rsf_index_enc [ 2 ];
list_present =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
ttl_hopl =:= lsb(3, 3) [ 3 ];
ecn_used =:= one_bit_choice [ 1 ];
seq_number =:= lsb(16, 65535) [ 16 ];
ack_number =:= lsb(16, 16383) [ 16 ];
options =:=
tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send LSBs of sequence number
COMPRESSED seq_1 {
discriminator =:= '1010' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3) [ 4 ];
seq_number =:= lsb(16, 32767) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send scaled sequence number LSBs
COMPRESSED seq_2 {
discriminator =:= '11010' [ 5 ];
ip_id =:=
ip_id_lsb(ip_id_behavior.UVALUE, 7, 3) [ 7 ];
seq_number_scaled =:= lsb(4, 7) [ 4 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE(payload_size != 0);
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send acknowledgment number LSBs
COMPRESSED seq_3 {
discriminator =:= '1001' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3) [ 4 ];
ack_number =:= lsb(16, 16383) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send scaled acknowledgment number scaled
COMPRESSED seq_4 {
discriminator =:= '0' [ 1 ];
ack_number_scaled =:= lsb(4, 3) [ 4 ];
// Due to having very few ip_id bits, no negative offset
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 3, 1) [ 3 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE(ack_stride.UVALUE != 0);
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send ACK and sequence number
COMPRESSED seq_5 {
discriminator =:= '1000' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3) [ 4 ];
ack_number =:= lsb(16, 16383) [ 16 ];
seq_number =:= lsb(16, 32767) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send both ACK and scaled sequence number LSBs
COMPRESSED seq_6 {
discriminator =:= '11011' [ 5 ];
seq_number_scaled =:= lsb(4, 7) [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 7, 3) [ 7 ];
ack_number =:= lsb(16, 16383) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE(payload_size != 0);
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); }
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED））; }
// Send ACK and window
COMPRESSED seq_7 {
discriminator =:= '1100' [ 4 ];
window =:= lsb(15, 16383) [ 15 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5, 3) [ 5 ];
ack_number =:= lsb(16, 32767) [ 16 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// An extended packet type for seldom-changing fields
// Can send LSBs of TTL, RSF flags, change ECN behavior, and
// options list
COMPRESSED seq_8 {
discriminator =:= '1011' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3) [ 4 ];
list_present =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
ttl_hopl =:= lsb(3, 3) [ 3 ];
ecn_used =:= one_bit_choice [ 1 ];
ack_number =:= lsb(15, 8191) [ 15 ];
rsf_flags =:= rsf_index_enc [ 2 ];
seq_number =:= lsb(14, 8191) [ 14 ];
options =:=
tcp_list_presence_enc(list_present.CVALUE) [ VARIABLE ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
}
This section describes the feedback formats for the ROHC-TCP profile, following the general ROHC feedback format described in Section 5.2.3 of [RFC4995].
このセクションでは、[RFC4995]のセクション5.2.3に記載した一般的なROHCフィードバック形式以下、ROHC-TCPプロファイルのフィードバックフォーマットを記述する。
All feedback formats carry a field labeled MSN. The MSN field contains LSBs of the MSN control field described in Section 6.1.1. The sequence number to use is the MSN corresponding to the last header that was successfully CRC-8 validated or CRC verified.
すべてのフィードバック形式は、MSNラベルされたフィールドを運びます。 MSNフィールドは、6.1.1項で説明MSN制御フィールドのLSBが含まれています。使用するシーケンス番号MSNが正常CRC-8検証またはCRCが検証された最後のヘッダに対応しています。
FEEDBACK-1
FEEDBACK-1
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| MSN |
+---+---+---+---+---+---+---+---+
MSN: The LSB-encoded master sequence number.
MSN：LSB-エンコードされたマスターのシーケンス番号。
A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK, FEEDBACK-2 must be used.
FEEDBACK-1がACKです。 NACK又はSTATIC-NACKを送信するために、FEEDBACK-2を使用しなければなりません。
FEEDBACK-2
FEEDBACK-2
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| MSN |
+---+---+---+---+---+---+---+---+
| MSN |
+---+---+---+---+---+---+---+---+
| CRC |
+---+---+---+---+---+---+---+---+
/ Feedback options /
+---+---+---+---+---+---+---+---+
Acktype:
Acktype：
0 = ACK
ACK = 0
1 = NACK
1 =鼻
2 = STATIC-NACK
2 = STATIC-NACK
3 is reserved (MUST NOT be used for parsability)
3は予約されている（parsabilityために使用してはいけません）
MSN: The LSB-encoded master sequence number.
MSN：LSB-エンコードされたマスターのシーケンス番号。
CRC: 8-bit CRC computed over the entire feedback element (as defined in Section 5.3.1.1 of [RFC4995]). For the purpose of computing the CRC, the CRC field is zero. The CRC is calculated using the polynomial defined in [RFC4995].
CRC：全体フィードバック要素にわたって計算さ8ビットのCRC（[RFC4995]のセクション5.3.1.1で定義されるように）。 CRCを計算する目的のために、CRCフィールドはゼロです。 CRCは、[RFC4995]で定義された多項式を用いて計算されます。
Feedback options: A variable number of feedback options, see Section 8.3.2. Options may appear in any order.
フィードバックオプション：フィードバックオプションの可変数は、8.3.2項を参照してください。オプションは任意の順序で表示されることがあります。
A FEEDBACK-2 of type NACK or STATIC-NACK is always implicitly an acknowledgment for a successfully decompressed packet, which packet corresponds to the MSN of the feedback element, unless the MSN-NOT-VALID option (Section 8.3.2.2) appears in the feedback element.
に表示されますMSN-有効でないオプション（セクション8.3.2.2）しない限り、FEEDBACK-2タイプのNACKまたはSTATIC-NACKは、暗黙的に常にフィードバック要素のMSNに対応したパケットに成功解凍パケットのための承認でありますフィードバック要素。
The FEEDBACK-2 format always carries a CRC and is thus more robust than the FEEDBACK-1 format. When receiving FEEDBACK-2, the compressor MUST verify the information by computing the CRC and by comparing the result with the CRC carried in the feedback format. If the two are not identical, the feedback element MUST be discarded.
FEEDBACK-2フォーマットは、常にCRCを運び、したがって、より堅牢FEEDBACK-1フォーマットよりも長いです。 FEEDBACK-2を受信した場合、圧縮機は、CRCを計算することによって、帰還形式で運ばCRCとの結果を比較することにより、情報を検証しなければなりません。 2が同一でない場合は、フィードバック要素を捨てなければなりません。
A ROHC-TCP feedback option has variable length and the following general format:
ROHC - TCPのフィードバックオプションは、可変長と以下の一般的な形式になっています。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type | Opt Len |
+---+---+---+---+---+---+---+---+
/ option data / Opt Length (octets)
+---+---+---+---+---+---+---+---+
Each ROHC-TCP feedback option can appear at most once within a FEEDBACK-2.
各ROHC - TCPのフィードバックオプションはFEEDBACK-2の中で最も一度表示されます。
The REJECT option informs the compressor that the decompressor does not have sufficient resources to handle the flow.
REJECTオプションは、デコンプレッサは、フローを処理するのに十分なリソースを持っていないコンプレッサーを通知します。
+---+---+---+---+---+---+---+---+
| Opt Type = 2 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
When receiving a REJECT option, the compressor MUST stop compressing the packet flow, and SHOULD refrain from attempting to increase the number of compressed packet flows for some time. The REJECT option
REJECTオプションを受信すると、コンプレッサーは、パケットの流れを圧縮するのを止めなければなりませんし、圧縮されたパケットの数はいくつかの時間のためのフローを増加しようとするお控えください。 REJECTオプション
MUST NOT appear more than once in the FEEDBACK-2 format; otherwise, the compressor MUST discard the entire feedback element.
一度FEEDBACK-2形式でより多く見えてはいけません。そうでない場合は、コンプレッサは、全フィードバック要素を捨てなければなりません。
The MSN-NOT-VALID option indicates that the MSN of the feedback is not valid.
MSN-有効でないオプションは、フィードバックのMSNが有効でないことを示しています。
+---+---+---+---+---+---+---+---+
| Opt Type = 3 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
A compressor MUST ignore the MSN of the feedback element when this option is present. Consequently, a NACK or a STATIC-NACK feedback type sent with the MSN-NOT-VALID option is equivalent to a STATIC-NACK with respect to the semantics of the feedback message.
このオプションが存在する場合、圧縮機は、フィードバック素子のMSNを無視しなければなりません。したがって、NACKまたはMSN-VALID NOTオプションと共に送信STATIC-NACKフィードバックタイプは、フィードバックメッセージの意味論に対してSTATIC-NACKに相当します。
The MSN-NOT-VALID option MUST NOT appear more than once in the FEEDBACK-2 format and MUST NOT appear in the same feedback element as the MSN option; otherwise, the compressor MUST discard the entire feedback element.
MSN-有効でないオプションはFEEDBACK-2形式で複数回現れてはならないとMSNのオプションと同じフィードバック要素に現れてはいけません。そうでない場合は、コンプレッサは、全フィードバック要素を捨てなければなりません。
The MSN option provides 2 additional bits of MSN.
MSNオプションは、MSNの2つの追加ビットを提供します。
+---+---+---+---+---+---+---+---+
| Opt Type = 4 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| MSN | Reserved |
+---+---+---+---+---+---+---+---+
These 2 bits are the least significant bits of the MSN and are thus concatenated with the 14 bits already present in the FEEDBACK-2 format.
これらの2ビットは、MSNの最下位ビットであり、したがって、既に存在FEEDBACK-2形式の14ビットと連結されています。
The MSN option MUST NOT appear more than once in the FEEDBACK-2 format and MUST NOT appear in the same feedback element as the MSN-NOT-VALID option; otherwise, the compressor MUST discard the entire feedback element.
MSNオプションはFEEDBACK-2形式で複数回現れてはならないとMSN-無効オプションと同じフィードバック要素に現れてはいけません。そうでない場合は、コンプレッサは、全フィードバック要素を捨てなければなりません。
The CONTEXT_MEMORY option means that the decompressor does not have sufficient memory resources to handle the context of the packet flow, as the flow is currently compressed.
CONTEXT_MEMORYオプションは、フローが現在圧縮されているようデコンプレッサは、パケットフローの状況を処理するのに十分なメモリリソースを持っていないことを意味します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 9 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
When receiving a CONTEXT_MEMORY option, the compressor SHOULD take actions to compress the packet flow in a way that requires less decompressor memory resources, or stop compressing the packet flow.
CONTEXT_MEMORYオプションを受信すると、コンプレッサーは少ないデコンプレッサメモリリソースを必要とするように、パケットの流れを圧縮するために行動を取るか、パケットの流れを圧縮停止する必要があります。
The CONTEXT_MEMORY option MUST NOT appear more than once in the FEEDBACK-2 format; otherwise, the compressor MUST discard the entire feedback element.
CONTEXT_MEMORYオプションは一度FEEDBACK-2形式でより多く見えてはいけません。そうでない場合は、コンプレッサは、全フィードバック要素を捨てなければなりません。
If an option type unknown to the compressor is encountered, the compressor MUST continue parsing the rest of the FEEDBACK element, which is possible since the length of the option is explicit, but MUST otherwise ignore the unknown option.
圧縮機への未知のオプションタイプが検出された場合、コンプレッサーはオプションの長さが明示的であるので、可能であるフィードバック要素、の残りの部分を解析し続ける必要がありますが、そうでない場合は、未知のオプションを無視しなければなりません。
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 IP and TCP headers, and possibly also valid TCP checksums. Such corruption may be detected with end-to-end authentication and integrity mechanisms that will not be affected by the compression. Moreover, this header compression scheme uses an internal checksum for verification of reconstructed headers. This reduces the probability of producing decompressed headers not matching the original ones without this being noticed.
誤動作や悪意のあるヘッダ圧縮機は、おそらく、有効なTCPチェックサムを元のパケットに一致するが、まだ有効なIPおよびTCPヘッダを持って、そしてないパケットを再構成するヘッダ復元を引き起こす可能性があります。そのような破損は、圧縮によって影響されないエンドツーエンド認証および完全性機構を用いて検出することができます。また、このヘッダ圧縮方式は、再構成されたヘッダの検証のための内部のチェックサムを使用します。これは、これは気付かれずに元のものと一致しない解凍されたヘッダを生成する確率を低減します。
Denial-of-service attacks are possible if an intruder can introduce (for example) bogus IR, CO, 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、CO、またはフィードバックパケットを導入することにより、圧縮効率を低下させることができれば、サービス拒否攻撃が可能です。しかしながら、このように、リンク層で任意のパケットを注入する能力を有する侵入者は、ヘッダ圧縮の使用に関連するものを矮化追加のセキュリティ上の問題を提起します。
The ROHC profile identifier 0x0006 has been reserved by the IANA for the profile defined in this document.
ROHCプロファイル識別子0x0006は、この文書で定義されたプロファイルのIANAによって予約されています。
A ROHC profile identifier has been reserved by the IANA for the profile defined in this document. Profiles 0x0000-0x0005 have previously been reserved; this profile is 0x0006. As for previous
ROHCプロファイル識別子は、この文書で定義されたプロファイルのIANAによって予約されています。以前に予約されている0x0000-0x0005プロファイル。このプロファイルは0x0006です。以前について
ROHC profiles, profile numbers 0xnn06 have been reserved for future updates of this profile.
ROHCプロファイル、このプロファイルの将来のアップデートのために予約されています0xnn06プロファイル番号。
Profile Usage Document
identifier
0x0006 ROHC TCP [RFC4996] 0xnn06 Reserved
0x0006 ROHC TCP [RFC4996] 0xnn06は予約済み
The authors would like to thank Qian Zhang, Hong Bin Liao, Richard Price, and Fredrik Lindstroem for their work with early versions of this specification. Thanks also to Robert Finking and Carsten Bormann for valuable input.
著者は、この仕様の初期バージョンと自分の仕事のため銭張、香港ビン遼、リチャード価格、およびフレドリックLindstroemに感謝したいと思います。貴重な入力のためにも、ロバート・Finkingとカルステンボルマンに感謝します。
Additional thanks: this document was reviewed during working group last-call by committed reviewers Joe Touch and Ted Faber, as well as by Sally Floyd, who provided a review at the request of the Transport Area Directors.
追加の感謝：この文書は、コミット校閲ジョーTouchとテッドフェーバー、などにより、交通エリアの取締役の要求に応じて見直しを提供サリーフロイド、ことで、グループの最後のコールを作業中に検討しました。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2004]パーキンス、C.、 "IP内の最小カプセル化"、RFC 2004、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890] Dommety、G.、 "GREのキーと一連番号拡大"、RFC 2890、2000年9月。
[RFC4164] Pelletier, G., "RObust Header Compression (ROHC): Context Replication for ROHC Profiles", RFC 4164, August 2005.
[RFC4164]ペルティエ、G.、 "ロバストヘッダ圧縮（ROHC）：ROHCプロファイルのコンテキストの複製"、RFC 4164、2005年8月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust Header Compression (ROHC) Framework", RFC 4995, July 2007.
[RFC4995]ジョンソン、L-E。、ペルティエ、G.、及びK. Sandlund、 "ロバストヘッダ圧縮（ROHC）フレームワーク"、RFC 4995、2007年7月。
[RFC4997] Finking, R. and G. Pelletier, "Formal Notation for Robust Header Compression (ROHC-FN)", RFC 4997, July 2007.
[RFC4997] Finking、R.とG.ペルティエ、 "ロバストヘッダ圧縮（ROHC-FN）のための正式な表記法"、RFC 4997、2007年7月。
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[RFC1144]ジェーコブソン、V.、RFC 1144、1990年2月 "低速シリアルリンク用のTCP / IPヘッダの圧縮"。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、B.、およびD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018]マティス、M.、Mahdavi、J.、フロイド、S.、とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507] Degermark、M.、Nordgren、B.、およびS.ピンク、 "IPヘッダー圧縮"、RFC 2507、1999年2月。
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.、およびW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[RFC2883]フロイド、S.、Mahdavi、J.、マティス、M.、およびM.ポドルスキー、 "TCPのための選択的確認応答（SACK）オプションの拡張"、RFC 2883、2000年7月。
[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]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、 ESP、および非圧縮」、RFC 3095、2001年7月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004.
[RFC3759]ヨンソン、L-E、 "ロバストヘッダ圧縮（ROHC）：用語とチャンネルマッピングの例"。、RFC 3759、2004年4月。
[RFC4163] Jonsson, L-E., "RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression", RFC 4163, August 2005.
[RFC4163]ヨンソン、L-E、 "ロバストヘッダ圧縮（ROHC）：TCP / IPヘッダー圧縮の要件"、RFC 4163、2005年8月。
[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]ペルティエ、G.、ヨンソン、L-E、およびK. Sandlund、 "ロバストヘッダ圧縮（ROHC）：パケットの順序を変更できますチャンネル以上のROHC"。、RFC 4224、2006年1月。
[RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, March 2006.
[RFC4413]西、M.とS.マッキャン、 "TCP / IPフィールドの動作"、RFC 4413、2006年3月。
Authors' Addresses
著者のアドレス
Ghyslain Pelletier Ericsson Box 920 Lulea SE-971 28 Sweden
Ghyslainペルティエエリクソンボックス920 SE-971 28ルレオスウェーデン
Phone: +46 (0) 8 404 29 43 EMail: ghyslain.pelletier@ericsson.com
電話：+46（0）8 404 29 43 Eメール：ghyslain.pelletier@ericsson.com
Kristofer Sandlund Ericsson Box 920 Lulea SE-971 28 Sweden
クリストファーSandlundエリクソンボックス920ルーレオSE-971 28スウェーデン
Phone: +46 (0) 8 404 41 58 EMail: kristofer.sandlund@ericsson.com
電話：+46（0）8 404 41 58 Eメール：kristofer.sandlund@ericsson.com
Lars-Erik Jonsson Optand 737 Ostersund SE-831 92 Sweden
ラース・エリックジョンソンOptand 737エステルスンドSE-831 92スウェーデン
Phone: +46 70 365 20 58 EMail: lars-erik@lejonsson.com
電話：+46 70 365 20 58 Eメール：lars-erik@lejonsson.com
Mark A West Siemens/Roke Manor Roke Manor Research Ltd. Romsey, Hampshire SO51 0ZN UK
マーク・A西シーメンス/ RokeマナーRokeマナーリサーチ株式会社ロムジー、ハンプシャーSO51 0ZN英国
Phone: +44 1794 833311 EMail: mark.a.west@roke.co.uk URI: http://www.roke.co.uk
電話：+44 1794 833311 Eメール：mark.a.west@roke.co.uk URI：http://www.roke.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。