[要約] RFC 6846は、TCP/IPにおけるROHC（Robust Header Compression）のプロファイルであり、TCP/IPヘッダの圧縮を改善するためのガイドラインを提供します。その目的は、ネットワークの効率性を向上させ、帯域幅の節約と遅延の削減を実現することです。
Internet Engineering Task Force (IETF) G. Pelletier
Request for Comments: 6846 InterDigital Communications
Obsoletes: 4996 K. Sandlund
Category: Standards Track Ericsson
ISSN: 2070-1721 L-E. Jonsson
M. West Siemens/Roke Manor January 2013
Ｍ。 うぇｓｔ しえめんｓ／ろけ まのｒ じゃぬあｒｙ ２０１３
RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)
RObustヘッダー圧縮（ROHC）：TCP / IP（ROHC-TCP）のプロファイル
Abstract
概要
This document specifies a RObust Header Compression (ROHC) 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 selective acknowledgments (SACKs) and Timestamps.
このドキュメントでは、TCP / IPパケットを圧縮するためのRObust Header Compression（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は、エラー率が高く、ラウンドトリップ時間が長いリンクで使用するとうまく機能します。ヘッダーの圧縮が不可欠である多くの帯域幅が制限されたリンクでは、このような特性が一般的です。
This specification obsoletes RFC 4996. It fixes a technical issue with the SACK compression and clarifies other compression methods used.
この仕様はRFC 4996を廃止します。SACK圧縮の技術的な問題を修正し、使用される他の圧縮方法を明確にします。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6846.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6846で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................5
2. Terminology .....................................................5
3. Background ......................................................7
3.1. Existing TCP/IP Header Compression Schemes .................7
3.2. Classification of TCP/IP Header Fields .....................8
4. Overview of the TCP/IP Profile (Informative) ...................10
4.1. General Concepts ..........................................10
4.2. Compressor and Decompressor Interactions ..................10
4.2.1. Compressor Operation ...............................10
4.2.2. Decompressor Feedback ..............................11
4.3. Packet Formats and Encoding Methods .......................11
4.3.1. Compressing TCP Options ............................11
4.3.2. Compressing Extension Headers ......................11
4.4. Expected Compression Ratios with ROHC-TCP .................12
5. Compressor and Decompressor Logic (Normative) ..................13
5.1. Context Initialization ....................................13
5.2. Compressor Operation ......................................13
5.2.1. Compression Logic ..................................13
5.2.1.1. Optimistic Approach .......................14
5.2.1.2. Periodic Context Refreshes ................14
5.2.2. Feedback Logic .....................................14
5.2.2.1. Optional Acknowledgments (ACKs) ...........14
5.2.2.2. Negative Acknowledgments (NACKs) ..........15
5.2.3. Context Replication ................................15
5.3. Decompressor Operation ....................................16
5.3.1. Decompressor States and Logic ......................16
5.3.1.1. Reconstruction and Verification ...........16
5.3.1.2. Detecting Context Damage ..................17
5.3.1.3. No Context (NC) State .....................18
5.3.1.4. Static Context (SC) State .................18
5.3.1.5. Full Context (FC) State ...................19
5.3.2. Feedback Logic .....................................19
5.3.3. Context Replication ................................20
6. Encodings in ROHC-TCP (Normative) ..............................20
6.1. Control Fields in ROHC-TCP ................................20
6.1.1. Master Sequence Number (MSN) .......................20
6.1.2. IP-ID Behavior .....................................21
6.1.3. Explicit Congestion Notification (ECN) .............22
6.2. Compressed Header Chains ..................................22
6.3. Compressing TCP Options with List Compression .............24
6.3.1. List Compression ...................................25
6.3.2. Table-Based Item Compression .......................26
6.3.3. Encoding of Compressed Lists .......................26
6.3.4. Item Table Mappings ................................28
6.3.5. Compressed Lists in Dynamic Chain ..................30
6.3.6. Irregular Chain Items for TCP Options ..............30
6.3.7. Replication of TCP Options .........................30
6.4. Profile-Specific Encoding Methods .........................31
6.4.1. inferred_ip_v4_header_checksum .....................31
6.4.2. inferred_mine_header_checksum ......................31
6.4.3. inferred_ip_v4_length ..............................32
6.4.4. inferred_ip_v6_length ..............................32
6.4.5. inferred_offset ....................................33
6.4.6. baseheader_extension_headers .......................33
6.4.7. baseheader_outer_headers ...........................34
6.4.8. Scaled Encoding of Fields ..........................34
6.4.8.1. Scaled TCP Sequence Number Encoding .......35
6.4.8.2. Scaled Acknowledgment Number Encoding .....35
6.5. Encoding Methods with External Parameters .................36
7. Packet Types (Normative) .......................................38
7.1. Initialization and Refresh (IR) Packets ...................38
7.2. Context Replication (IR-CR) Packets .......................40
7.3. Compressed (CO) Packets ...................................42
8. Header Formats (Normative) .....................................43
8.1. Design Rationale for Compressed Base Headers ..............44
8.2. Formal Definition of Header Formats .......................47
8.3. Feedback Formats and Options ..............................88
8.3.1. Feedback Formats ...................................88
8.3.2. Feedback Options ...................................89
8.3.2.1. The REJECT Option .........................89
8.3.2.2. The MSN-NOT-VALID Option ..................90
8.3.2.3. The MSN Option ............................90
8.3.2.4. The CONTEXT_MEMORY Feedback Option ........91
8.3.2.5. Unknown Option Types ......................91
9. Changes from RFC 4996 ..........................................91
9.1. Functional Changes ........................................91
9.2. Non-functional Changes ....................................92
10. Security Considerations .......................................92
11. IANA Considerations ...........................................93
12. Acknowledgments ...............................................93
13. References ....................................................93
13.1. Normative References .....................................93
13.2. Informative References ...................................94
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]で説明されています。 [RFC4163]では、TCP [RFC0793]圧縮スキームの堅牢性を重要な目的とする追加の考慮事項が導入されています。最後に、既存のTCP / IPヘッダー圧縮スキーム（[RFC1144]、[RFC2507]）は、TCPオプションフィールドの処理に制限があり、ハンドシェイクパケット（SYNおよびFIN）のヘッダーを圧縮できません。
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 selective acknowledgments (SACK) ([RFC2018], [RFC2883]) and Timestamps ([RFC1323]). TCP options that may be less frequently used do not necessarily need to be compressed by the protocol, and instead can be passed transparently without reducing the overall compression efficiency of other parts of the TCP header.
したがって、ヘッダ圧縮スキームが、圧縮ポイントと解凍ポイントとの間のリンクの損失、および圧縮ポイントの前の損失を処理できることが望ましい。ヘッダー圧縮スキームでは、選択的確認応答（SACK）（[RFC2018]、[RFC2883]）やタイムスタンプ（[RFC1323]）などの短期間のTCP転送とTCPオプションを効率的に圧縮する方法も考慮する必要があります。使用頻度の低いTCPオプションは必ずしもプロトコルで圧縮する必要はなく、代わりにTCPヘッダーの他の部分の全体的な圧縮効率を低下させることなく透過的に渡すことができます。
The Robust Header Compression (ROHC) Working Group 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 [RFC5795], compliant with the requirements listed in [RFC4163].
Robust Header Compression（ROHC）ワーキンググループは、ヘッダー圧縮フレームワークを開発しました。その上に、さまざまなプロトコルセットまたはさまざまな圧縮戦略のためにさまざまなプロファイルを定義できます。このドキュメントは、[RFC4163]にリストされている要件に準拠するROHCフレームワーク[RFC5795]の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 / IPヘッダー圧縮（ROHC-TCP）のヘッダー圧縮スキームについて説明します。これは、パケット損失に対して堅牢であり、特に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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document reuses some of the terminology found in [RFC5795]. In addition, this document uses or defines the following terms: Base context
このドキュメントは、[RFC5795]にあるいくつかの用語を再利用します。さらに、このドキュメントでは次の用語を使用または定義しています。基本コンテキスト
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
ベースヘッダー
The Base header is a compressed representation of the innermost IP and TCP headers of the uncompressed packet.
Baseヘッダーは、非圧縮パケットの最も内側の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 [RFC5795]. 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ヘッダー圧縮に関する背景情報を提供します。一般的なヘッダー圧縮の基本は[RFC5795]にあります。次のサブセクションでは、まず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ヘッダーの圧縮に使用できる2つの異なる方式です。どちらの方式も、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 [RFC5681] 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高速再送信アルゴリズム[RFC5681]がトリガーされるのを効果的に防ぎます。このような場合、コンプレッサーは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.
IPHC [RFC2507]は、TCPを圧縮するときのコンプレッサーとデコンプレッサー間の不整合なコンテキストによるエラーを減らすために、TWICEと呼ばれるローカル修復メカニズムと否定応答に基づくリンク層メカニズムで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.
完全なヘッダー要求メカニズムには、状況によっては使用できないフィードバックチャネルが必要です。このチャネルは、次のパケットが非圧縮ヘッダーで送信され、TCPタイムアウトを待たずに再同期できるように明示的に要求するために使用されます。
In addition, this mechanism does not perform well on links with long round-trip times.
さらに、このメカニズムは、ラウンドトリップ時間が長いリンクではうまく機能しません。
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オプションフィールドの処理に制限があります。 IPHCの場合、（TimestampsやSACKなどが原因で）オプションフィールドを変更すると、フィールド全体が圧縮できなくなりますが、CTCPの場合、オプションフィールドを変更すると、TCP / IPヘッダー圧縮が完全に無効になります。
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およびFIN）のヘッダーを圧縮しません。これらのパケットを圧縮すると、多くの短期間の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) - 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
- IPv4識別（16ビット）-IP-ID-TCPシーケンス番号（32ビット）-SN-TCP確認番号（32ビット）-TCP予約済み（4ビット）-TCP ECNフラグ（2ビット）-ECN-TCPウィンドウ（16ビット）-TCPオプションo最大セグメントサイズ（32ビット）-MSS oウィンドウスケール（24ビット）-WSCALE o SACK許可（16ビット）o TCP SACK（80、144、208、または272ビット）-SACK o TCPタイムスタンプ（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値の割り当てはさまざまな方法で行うことができます。通常、順次、順次ジャンプ、ランダムのいずれかです。一部の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ヘッダーのもう1つの重要な動作は、シーケンス番号と確認応答番号の間の依存関係です。 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], Generic Routing Encapsulation (GRE) [RFC2784][RFC2890], and the Minimal Encapsulation (MINE) header [RFC2004].
ROHC-TCPは、次のヘッダーも圧縮します。IPv6宛先オプションヘッダー[RFC2460]、IPv6ルーティングヘッダー[RFC2460]、IPv6ホップバイホップオプションヘッダー[RFC2460]、認証ヘッダー（AH）[RFC4302]、汎用ルーティングカプセル化（GRE ）[RFC2784] [RFC2890]、およびMinimal Encapsulation（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].
[RFC3095]で説明されているのと同様の理由により、このドキュメントではモバイルIP（IPv4またはIPv6の場合）に固有のヘッダーは特別な扱いを受けません。
ROHC-TCP uses the ROHC protocol as described in [RFC5795]. ROHC-TCP supports context replication as defined in [RFC4164]. Context replication can be particularly useful for short-lived TCP flows [RFC4413].
ROHC-TCPは、[RFC5795]で説明されているROHCプロトコルを使用します。 ROHC-TCPは、[RFC4164]で定義されているコンテキスト複製をサポートしています。コンテキスト複製は、存続期間の短い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コンテキストのデコンプレッサによって少なくとも1回使用される場合、そのチャネルの圧縮操作全体でこのチャネルが使用されることを前提としています。フィードバックチャネルが消えた場合は、圧縮を再開する必要があります。
The reception of either positive acknowledgments (ACKs) or negative acknowledgments (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).
ROHC-TCPは、セクション3.2にリストされている拡張ヘッダーを圧縮します。これらのヘッダーは他のヘッダーとまったく同じように扱われるため、静的チェーン、動的チェーン、不規則なチェーン、およびコンテキストレプリケーション用のチェーンがあります（セクション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オプションには、パディングおよび/またはアラインメントのための適切な数のNo Operation（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)
(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オプションはヘッダーに表示されますが、前のパケットには存在しませんでした。 2つのSACKブロックが想定されています。 （3）SACKオプションはヘッダーに表示され、前のパケット（異なるSACKブロックを持つ）にも存在していました。 2つの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の一般的な初期圧縮率を示しています。この例のデータストリームはIPv4 + TCPで、IP-IDのシーケンシャルな動作を想定しています。次のオプションは、SYNパケットに存在すると想定されています：TS、MSS、およびWSCALE、および適切な数のNOPオプション。
Total Header Size (octets) Unc. ROHC-TCP IPHC 1st packet (SYN) 60 49 60 2nd packet 52 12 52
合計ヘッダーサイズ（オクテット）Unc。 ROHC-TCP IPHC 1番目のパケット（SYN）60 49 60 2番目のパケット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.
表の数値は、コンプレッサーが2番目のパケットを圧縮する前に圧縮解除プログラムから確認応答を受信したと想定しています。これは、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.
これは、最も一般的なケースでは、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.
1. セクション7.1のようにIRパケットを使用することにより、プロファイル番号は0x06であり、静的チェーンはTCPヘッダーの静的部分で終了します。
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.
2. [RFC4164]で定義されたメカニズムを使用して既存のコンテキストを複製する。これは、セクション7.2で定義されたIR-CRパケットを使用して行われます。プロファイル番号は0x06です。
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).
o 圧縮解除プログラムの状態に関する圧縮プログラムの信頼レベル。たとえば、ヘッダー形式を選択して、いくつかの連続するパケットについて同じタイプの情報を更新することにより、または圧縮解除プログラムのフィードバック（ACKおよび/またはNACK）の受信から。
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 packets 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が値を変更する場合、圧縮プログラムは、圧縮解除プログラムがXの新しい値を含む少なくとも1つのパケットを受信したという確信が得られるまで、フィールド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パケットを送信する必要があります（SHOULD）。これらの更新は、タイムアウト、フローに送信された圧縮パケットの数、または実装に固有のその他の戦略に基づくことができます。フィードバックチャネルが確立されると、デコンプレッサは定期的な更新の実行を停止する場合があります。
The semantics of feedback messages, acknowledgments (ACKs) and negative acknowledgments (NACKs or STATIC-NACKs), are defined in Section 5.2.4.1 of [RFC5795].
フィードバックメッセージのセマンティクス、確認応答（ACK）、否定応答（NACKまたはSTATIC-NACK）は、[RFC5795]のセクション5.2.4.1で定義されています。
The compressor MAY use acknowledgment feedback (ACKs) to move to a higher compression state.
コンプレッサーは、確認フィードバック（ACK）を使用して、より高い圧縮状態に移行できます（MAY）。
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パケットを使用してもよい（MAY）。
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]で定義されている追加の圧縮およびフィードバックロジックを実装することにより、コンテキストレプリケーションをサポートしてもよい（MAY）。
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 [RFC5795]. If validation fails, the packet MUST NOT be delivered to upper layers.
IRまたはIR-DYNパケットを圧縮解除するとき、圧縮解除プログラムはCRC-8検証[RFC5795]を使用して受信したヘッダーの整合性を検証する必要があります。検証が失敗した場合、パケットは上位層に配信されてはならない（MUST NOT）。
Upon receiving an IR-CR packet, the decompressor MUST perform the actions as specified in [RFC4164].
IR-CRパケットを受信すると、圧縮解除プログラムは、[RFC4164]で指定されているアクションを実行する必要があります。
When decompressing other packet types (e.g., CO packets), the decompressor MUST validate the outcome of the decompression attempt using CRC verification [RFC5795]. 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検証[RFC5795]を使用して解凍試行の結果を検証しなければなりません（MUST）。検証が失敗した場合、デコンプレッサの実装は、パケットの修正または修復手段を試行してもよい（MAY）。試行の結果は、CRC検証を使用して検証する必要があります。それ以外の場合、パケットは上位層に配信してはなりません（MUST NOT）。
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検証が成功した場合、圧縮解除プログラムは、現在のヘッダーで受信した情報でそのコンテキストを更新する必要があります（SHOULD）。次に、圧縮解除プログラムは、再構築されたパケットをシステムのネットワーク層に渡します。それ以外の場合、解凍コンテキストは更新してはなりません（MUST NOT）。
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ヘッダーの解凍を試みず、CR、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.
NC状態では、IR以外のタイプのパケットを受信した場合、またはIRパケットの圧縮解除に失敗した場合、セクション5.3.2で説明されているフィードバックレート制限に従って、圧縮解除プログラムはSTATIC-NACKを送信する必要があります。
Once a packet has been validated and decompressed correctly, the decompressor MUST transit to the FC state.
パケットが検証されて正しく解凍されると、解凍プログラムはFC状態に遷移する必要があります。
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状態では、8ビットCRCでカバーされる動的フィールド（IRやIR-DYNなど）または7ビットCRCでカバーされる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 / IR-DYN / IR-CRのCRC検証が失敗し、静的コンテキストの損傷が想定される場合、デコンプレッサはSTATIC-NACKを送信する必要があります。他のパケットタイプが受信された場合、デコンプレッサはNACKを送信する必要があります。上記のケースは両方とも、セクション5.3.2で説明されているようにフィードバックレート制限の対象となります。
Once a packet has been validated and decompressed correctly, the decompressor MUST transit to the FC state.
パケットが検証されて正しく解凍されると、解凍プログラムはFC状態に遷移する必要があります。
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.
FC状態では、セクション5.3.2で説明されているフィードバックレート制限に従い、パケットタイプの解凍が失敗し、コンテキストの損傷が想定される場合、解凍プログラムは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の送信を継続する必要があります。 .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を送信できます（MAY）。特に、重要なコンテキスト更新を運ぶパケットが正しく圧縮解除されるとき、圧縮解除プログラムはACKを送信してもよい（MAY）。
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]で定義されている追加の解凍器とフィードバックロジックを実装しなければなりません（MUST）。
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]のセクション5.6で説明されているように、TCPヘッダーには、TCP圧縮のマスターシーケンス番号として機能するフィールドはありません。
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の値を1つずつ増やします。
The MSN field has the following two functions:
MSNフィールドには、次の2つの機能があります。
1. Differentiating between packets when sending feedback data.
1. フィードバックデータを送信する際のパケットの区別。
2. Inferring the value of incrementing fields such as the IP-ID.
2. IP-IDなどの増分フィールドの値を推測します。
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はCOパケット内でLSBエンコードされ、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が初期化されるとき、ランダムな値に初期化される必要があります（SHOULD）。コンプレッサーは、このプロファイルにまだ関連付けられていないコンテキストに対応するCIDに送信される初期IRまたはIR-CRパケットの新しいMSNのみを初期化する必要があります。つまり、コンプレッサーが同じCIDを再利用して多数のTCPフローを次々に圧縮する場合、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.
コンテキストレプリケーションの場合、レプリケーションプロセスがベースコンテキストを上書きしない限り（つまり、ベースCID == CID）、コンプレッサーはIR-CRパケットを送信するときにベースコンテキストのMSNを使用しません。代わりに、新しいフロー（CID）に関連付けられているROHC-TCPコンテキストにMSNの値が既に存在する場合、コンプレッサーは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.
コンプレッサーは、いくつかのパケットの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は最も内側のIPヘッダーのIP-IDにのみ順次動作（NBOまたはバイトスワップ）を割り当てることができます。これは、このIP-IDだけがMSNと十分に密接な相関を持ち（セクション6.1.1も参照）、順次変化するフィールドとしてそれを圧縮できるためです。したがって、圧縮プログラムは、シーケンシャル（NBO）またはシーケンシャルバイトスワップ動作のいずれかをトンネリングヘッダーに割り当ててはなりません（MUST NOT）。
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]がフローで1回使用されると、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ヘッダーが1つしかない場合（つまり、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 trade-off when designing this profile.
制御フィールドが設定されているときにすべてのIPヘッダーのECNビットを圧縮パケットに含める理由は、プロファイルが[RFC3168]のセクション9.1の「全機能オプション」を使用してIPトンネルを含むフローを効率的に圧縮する必要があるためです。これらのフローでは、内部IPヘッダーのECNビットの変更が外部IPヘッダーに伝搬されます。したがって、「機能制限」オプションを使用すると、コンプレッサーはトンネルヘッダーごとに必要以上に1オクテットを送信することがありますが、これは、このプロファイルを設計する際の妥当なトレードオフと見なされています。
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"
o IPv4 [RFC0791]、エンコード方式： "ipv4"
o IPv6 [RFC2460], encoding method: "ipv6"
o IPv6 [RFC2460]、エンコード方式： "ipv6"
o AH [RFC4302], encoding method: "ah"
o AH [RFC4302]、エンコード方式： "ah"
o GRE [RFC2784][RFC2890], encoding method: "gre"
o GRE [RFC 2784] [RFC 2890]、エンコード方式： "gre"
o MINE [RFC2004], encoding method: "mine"
o MINE [RFC2004]、エンコード方式： "mine"
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ヘッダーで終わる、圧縮されるプロトコルヘッダーのチェーンのヘッダーごとに1つの項目で構成されます。パケット形式の正式な説明では、各ヘッダーのこの静的チェーン項目は、名前の末尾に「_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.
動的チェーンは、圧縮されるプロトコルヘッダーのチェーンの各ヘッダーに対して1つの項目で構成され、最も外側の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.
レプリケートチェーンは、圧縮されるプロトコルヘッダーのチェーンのヘッダーごとに1つの項目で構成され、最も外側の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で定義されているように、圧縮パケットごとに、不規則なチェーンが圧縮パケットの一般的な形式で指定された場所に追加されます。このチェーンには、セクション6.3.6で定義されているTCPオプションの不規則なチェーンアイテムも含まれます。これらは、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を送信する必要があります（SHOULD）。
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：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でXIの数が奇数の場合、4ビットのパディングフィールドが存在します。 Paddingフィールドはゼロに設定する必要があります。それ以外の場合、圧縮解除プログラムはパケットを破棄する必要があります。
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 the table in Section 6.3. The compressed format(s) suffixed by "_list_item" in the encoding methods defines the item inside the compressed item list.
アイテム1、...、アイテムn：各アイテムは、XI 1、...、XI mのX = 1のXIに対応します。アイテムリストのエントリの形式については、6.3項の表を参照してください。エンコード方式で「_list_item」の接尾辞が付いた圧縮形式は、圧縮アイテムリスト内のアイテムを定義します。
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回検出され、両方のオプションの内容が異なる場合、コンプレッサーは、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オプションを同じインデックスにマップできます。 「_list_item」として圧縮された場合、NOPオプションにはコンテンツがないため、アイテムリストには表示されません。一貫性を保つため、他のタイプのオプションの場合と同様に、圧縮プログラムはプレゼンスビットを設定して、リストにエントリを設定する必要があります。
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.
Genericオプションは、アイテムテーブルに予約済みインデックスを持たない、あらゆるタイプの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 zero. The IP header and IP payload (after the minimal forwarding header) are not included in this checksum computation.
最小転送ヘッダー内のすべての16ビットワードの1の補数の和の16ビットの1の補数。チェックサムを計算するために、チェックサムフィールドの値はゼロです。 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ヘッダーのTotal Lengthフィールドを圧縮します。 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 Total Length field 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ヘッダーのペイロード長フィールドを圧縮します。この長さフィールドは、[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
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エンコード方法と同様に、仕様が正式に正しいままであるのに必要です。 COパケット（セクション7.3を参照）で使用され、トンネリングIPヘッダーとそれぞれの拡張ヘッダー（つまり、最も内側の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
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」だけが圧縮された状態で存在する場合に、フィールドが正しく圧縮解除できるように、圧縮プログラムがデコンプレッサが「residue」と「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の値がゼロに設定されたスケーリングされたエンコードを使用してはなりません（MUST NOT）。
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.
残差の値が変更されたことをコンプレッサーが検出した場合、またはコンプレッサーがスケーリングファクターに別の値を使用する場合、コンプレッサーがこれらのフィールドの新しい値を受け取ったと確信できるまで、スケーリングされたエンコーディングを使用してはなりません。
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.
フィールドのスケーリングされていない値が折り返されると、scaleing_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.
次のサブセクションでは、スケーリングされたエンコーディングがROHC-TCPの特定のフィールドにどのように適用されるか、特に、さまざまなフィールドに対してscaling_factorと残留値がどのように確立されるかについて説明します。
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.
スケーリング係数は、スケーリングされていないTCPシーケンス番号ビットを送信することによって確立されるため、デコンプレッサはペイロードサイズからscaling_factorを推測できます。
Establishing residue:
残留物の確立：
The residue is established identically as the scaling_factor, i.e., by sending unscaled TCP Sequence Number bits.
残差は、scaling_factorと同じように、つまり、スケーリングされていないTCPシーケンス番号ビットを送信することによって確立されます。
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.
スケーリングファクターは、この情報を運ぶことができるパケットタイプの1つを使用して、スケーリングファクターの値（セクション8.2では正式な表記ではack_strideと呼ばれます）をデコンプレッサに明示的に送信することによって確立されます。
Establishing residue:
残留物の確立：
The scaling residue 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).
スケーリング残差は、スケーリングされていないTCP確認番号ビットを送信することによって確立されるため、デコンプレッサは、スケーリングされていない値とスケーリング係数（ack_stride）からその値を推測できます。
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.
コンプレッサーは、スケーリングされた確認応答番号エンコーディングを使用してもよい（MAY）。スケーリング係数として使用する値は、コンプレッサーの実装次第です。逆方向に同じ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 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.
is_innermost：このブールフラグは、最も内側のIPヘッダーを処理するときにtrueに設定されます。それ以外の場合は、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; 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, ip_id_behavior_value):
o ipv4（is_innermost、ttl_irregular_chain_flag、ip_inner_ecn、ip_id_behavior_value）：
See definition of arguments for "ipv6" above.
上記の「ipv6」の引数の定義を参照してください。
ip_id_behavior_value: Set to a 2-bit integer value, using one of the constants whose name begins with the prefix IP_ID_BEHAVIOR_ and as defined in Section 8.2.
ip_id_behavior_value：名前が接頭辞IP_ID_BEHAVIOR_で始まり、セクション8.2で定義されている定数の1つを使用して、2ビット整数値に設定します。
o tcp_opt_eol(nbits):
o 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.
nbits：このパラメーターは、EOLオプションタイプオクテットの後ろから非圧縮ヘッダーのTCPオプションの最後までのパディングデータの長さに設定されます。
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.
ack_value：TCPヘッダーの確認番号フィールドの値に設定します。
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.
payload_size：TCPヘッダーに続くペイロードの長さ（オクテット単位）に設定します。
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, ip_id_behavior_value):
o co_baseheader（payload_size、ack_stride_value、ttl_irregular_chain_flag、ip_id_behavior_value）：
payload_size: Set to the length (in octets) of the payload following the TCP header.
payload_size：TCPヘッダーに続くペイロードの長さ（オクテット単位）に設定します。
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」引数にも使用されます。
ip_id_behavior_value: Set to a 2-bit integer value, using one of the constants whose name begins with the prefix IP_ID_BEHAVIOR_ and as defined in Section 8.2.
ip_id_behavior_value：名前が接頭辞IP_ID_BEHAVIOR_で始まり、セクション8.2で定義されている定数の1つを使用して、2ビット整数値に設定します。
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.
ROHC-TCPは、3つの異なるパケットタイプを使用します。初期化およびリフレッシュ（IR）パケットタイプ、コンテキストレプリケーション（IR-CR）パケットタイプ、および圧縮（CO）パケットタイプです。
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.
各パケットタイプは、いくつかのパケットフォーマットを定義します。IRタイプには2つのパケットフォーマットが定義され、IR-CRタイプには1つのパケットフォーマットが定義され、追加のフォーマットが1つあるCOタイプには8つの基本ヘッダーフォーマットが2セット定義されます。それは両方のセットに共通です。
The profile identifier for ROHC-TCP is 0x0006.
ROHC-TCPのプロファイル識別子は0x0006です。
ROHC-TCP uses the basic structure of the ROHC IR and IR-DYN packets as defined in [RFC5795] (Sections 5.2.2.1 and 5.2.2.2, respectively).
ROHC-TCPは、[RFC5795]で定義されているROHC IRおよびIR-DYNパケットの基本構造を使用します（それぞれセクション5.2.2.1および5.2.2.2）。
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 "Header" and "Payload" fields described in Section 5.2.1 of [RFC5795]:
ROHC-TCP IRパケットの場合、xビットの値を1に設定する必要があります。 [RFC5795]のセクション5.2.1で説明されている「Header」フィールドと「Payload」フィールドに対応する次の形式があります。
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 [RFC5795]. The CRC covers the entire IR header, thus excluding payload, padding, and feedback, if any.
CRC：[RFC5795]のセクション5.3.1.1に従って計算された8ビットCRC。 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 the 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 [RFC5795]:
ROHC-TCP IR-DYNパケットの形式は次のとおりです。これは、[RFC5795]のセクション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 [RFC5795]. The CRC covers the entire IR-DYN header, thus excluding payload, padding, and feedback, if any.
CRC：[RFC5795]のセクション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 IR-CR packet, as defined in [RFC4164], Section 3.5.2. With consideration to the extensibility of the IR packet type defined in [RFC5795], 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.
ROHC-TCP IR-CRパケットは、[RFC4164]のセクション3.5.2で定義されているROHC IR-CRパケットの一般的な形式に従います。 [RFC5795]で定義されている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 [RFC5795]:
ROHC-TCP IR-CRの形式は次のとおりです。これは、[RFC5795]のセクション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は、Base 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 [RFC5795].
CRC：このCRCはIR-CRヘッダー全体をカバーするため、ペイロード、パディング、およびフィードバックがあればそれを除外します。この8ビットCRCは、[RFC5795]のセクション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 [RFC5795]:
圧縮されたTCPヘッダーの一般的な形式は次のとおりです。これは、[RFC5795]のセクション5.2.1で説明されている「Header」および「Payload」フィールドに対応します。
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 Sections 6.2 and 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).
圧縮ヘッダー形式は2つの別個のセットとして定義されます。1つは、最も内側のIPヘッダーに順次IP-ID（ネットワークバイトオーダーまたはバイトスワップ）が含まれるパケット用のセットと、順次IP-IDがないパケット用（いずれか）です。ランダム、ゼロ、またはIP-IDなし）。
These two sets of header formats are referred to as the "sequential" and the "random" set of header formats, respectively.
これら2つのヘッダー形式のセットは、それぞれ「シーケンシャル」および「ランダム」ヘッダー形式のセットと呼ばれます。
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].
以下のLSBエンコードフィールドについて説明する場合、[RFC4997]の「p」は「offset_param」に等しく、「k」は「num_lsbs_param」に等しくなります。
The encoding methods used in the compressed base headers are based on the following design criteria:
圧縮された基本ヘッダーで使用されるエンコード方式は、次の設計基準に基づいています。
o MSN
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].
MSNはコンプレッサーによって生成される数値であるため、堅牢な動作を保証し、少量の並べ替えに対応するのに十分な大きさである必要があります[RFC4163]。したがって、各圧縮ベースヘッダーには、最大4パケットの並べ替えの深さを処理するためにk = 4およびp = 4でLSBエンコードされたMSNフィールドがあります。並べ替えが可能な場合の堅牢性を向上させるための追加のガイダンスは、[RFC4224]にあります。
o TCP Sequence Number
o TCPシーケンス番号
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.
ROHC-TCPには、大量のデータ転送を効率的に処理する機能があり、シーケンス番号は約1460オクテット（11ビットで表すことができる）増加すると予想されます。圧縮されたベースヘッダーが再送信（つまり、シーケンス番号への負のデルタ）を処理するためには、LSB解釈間隔は、正のオフセットと同じくらい大きい負のオフセットを処理する必要があります。つまり、もう1ビットが必要です。
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が損失に強いために、シーケンス番号のLSBエンコーディングに2つのビットが追加されます。つまり、ベースヘッダーには、少なくとも14ビットのLSBエンコードされたシーケンス番号が含まれている必要があります。上記のロジックに従って、LSBオフセット値は正のオフセットと同じ大きさに設定されます。つまり、p = 2 ^（k-1）-1です。
o TCP Acknowledgment Number
o TCP確認番号
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.
確認応答番号の設計基準は、TCPシーケンス番号の設計基準と同様です。ただし、確認されるデータパケットは他のすべてのデータパケットのみであることがよくあります。これは、予想されるデルタ値がシーケンス番号の2倍であることを意味します。
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
o TCPウィンドウ
The TCP Window field is expected to increase in increments of similar size as the TCP Sequence Number; therefore, the design criterion for the TCP window is to send at least 14 bits when used.
TCPウィンドウフィールドは、TCPシーケンス番号と同様のサイズの増分で増加すると予想されます。したがって、TCPウィンドウの設計基準は、使用時に少なくとも14ビットを送信することです。
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.
パケット形式の「順次」セットの場合、すべての圧縮ベースヘッダーには、LSBエンコードされたIP-IDオフセットビットが含まれます。オフセットは、MSNフィールドの値とIP-IDフィールドの値の差です。少なくとも3ビットのIP-IDが常に存在している必要がありますが、4〜7ビットを使用することをお勧めします。 k = 3の場合はp = 1、k> 3の場合はp = 3です。これは、オフセットがほとんどの時間で増加すると予想されるためです。
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動作、RST / SYN / FINフラグ、TTL /ホップ制限、TCPオプションリストなど、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ヘッダーの動的フィールドのいずれかに変更を伝えることができ、大量のフラグを使用して、ヘッダーフィールドに存在するフィールドに関する情報を提供します。
// NOTE: The irregular, static, and dynamic chains (see Section 6.2)
// are defined across multiple encoding methods and are embodied
// in the correspondingly named formats within those encoding
// methods. In particular, note that the static and dynamic
// chains ordinarily go together. The uncompressed fields are
// defined across these two formats combined, rather than in one
// or the other of them. The irregular chain items are likewise
// combined with a baseheader format.
////////////////////////////////////////////
// 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 ];
// ip_id fields are for innermost IP header only
ip_id_offset [ 16 ];
ip_id_behavior_innermost [ 2 ];
// ACK-related
ack_stride [ 32 ];
ack_number_scaled [ 32 ];
ack_number_residue [ 32 ];
seq_number_scaled [ 32 ];
seq_number_residue [ 32 ];
}
///////////////////////////////////////////////
// Encoding methods not specified in FN syntax
///////////////////////////////////////////////
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 ];
}
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 ];
}
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 ];
}
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 ];
}
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
lsb_7_or_31
{
UNCOMPRESSED {
item [ 32 ];
}
COMPRESSED lsb_7 {
discriminator =:= '0' [ 1 ];
item =:= lsb(7, 8) [ 7 ];
}
COMPRESSED lsb_31 {
discriminator =:= '1' [ 1 ];
item =:= lsb(31, 256) [ 31 ];
}
}
opt_lsb_7_or_31(flag)
{
UNCOMPRESSED {
item [ 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 {
}
COMPRESSED {
crc_value =:=
crc(3, 0x06, 0x07, data_value, data_length) [ 3 ];
}
}
crc7(data_value, data_length)
{
UNCOMPRESSED {
}
COMPRESSED {
crc_value =:=
crc(7, 0x79, 0x7f, data_value, data_length) [ 7 ];
}
}
one_bit_choice
{
UNCOMPRESSED {
field [ 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.
// Does not have an uncompressed side.
field_scaling(stride_value, scaled_value, unscaled_value, residue_value)
{
UNCOMPRESSED {
// Nothing
}
COMPRESSED no_scaling {
ENFORCE(stride_value == 0);
ENFORCE(residue_value == unscaled_value);
ENFORCE(scaled_value == 0);
}
COMPRESSED scaling_used {
ENFORCE(stride_value != 0);
ENFORCE(residue_value == (unscaled_value % stride_value));
ENFORCE(unscaled_value ==
scaled_value * stride_value + residue_value);
}
}
////////////////////////////////////////////
// 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_0_replicate {
discriminator =:= '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 {
}
}
////////////////////////////////////////////
// IPv6 Hop-by-Hop options header
////////////////////////////////////////////
ip_hop_opt {
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_0_replicate {
discriminator =:= '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 {
}
}
////////////////////////////////////////////
// IPv6 Routing header
////////////////////////////////////////////
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_0_replicate {
discriminator =:= '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 {
}
}
////////////////////////////////////////////
// GRE Header
////////////////////////////////////////////
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 {
COMPRESSED not_present {
value =:= compressed_value(0, 0) [ 0 ];
reserved1 =:= compressed_value(0, 0) [ 0 ];
ENFORCE(flag_value == 0);
}
}
gre_proto
{
UNCOMPRESSED {
protocol [ 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 {
圧縮gre_static {
ENFORCE((c_flag.UVALUE == 1 && checksum_and_res.ULENGTH == 32)
|| checksum_and_res.ULENGTH == 0);
ENFORCE((s_flag.UVALUE == 1 && sequence_number.ULENGTH == 32)
|| sequence_number.ULENGTH == 0);
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 =:=
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
{
UNCOMPRESSED {
next_header [ 8 ];
s_bit [ 1 ];
res_bits [ 7 ];
checksum [ 16 ];
orig_dest [ 32 ];
orig_src [ 0, 32 ];
}
DEFAULT {
next_header =:= static;
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_0_replicate {
discriminator =:= '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 {
}
}
/////////////////////////////////////////////
// Authentication Header (AH)
/////////////////////////////////////////////
ah
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
res_bits [ 16 ];
spi [ 32 ];
sequence_number [ 32 ];
icv [ 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 ];
icv =:=
irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ];
}
COMPRESSED ah_0_replicate {
discriminator =:= '00000000' [ 8 ];
sequence_number =:= irregular(32) [ 32 ];
icv =:=
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 ];
icv =:=
irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ];
}
COMPRESSED ah_irregular {
sequence_number =:= lsb_7_or_31 [ 8, 32 ];
icv =:=
irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ];
}
}
/////////////////////////////////////////////
// IPv6 Header
/////////////////////////////////////////////
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 {
圧縮された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
/////////////////////////////////////////////
ip_id_enc_dyn(behavior)
{
UNCOMPRESSED {
ip_id [ 16 ];
}
COMPRESSED ip_id_seq {
ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE);
ip_id =:= irregular(16) [ 16 ];
}
COMPRESSED ip_id_random {
ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM);
ip_id =:= irregular(16) [ 16 ];
}
COMPRESSED ip_id_zero {
ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO);
ip_id =:= uncompressed_value(16, 0) [ 0 ];
}
}
ip_id_enc_irreg(behavior)
{
UNCOMPRESSED {
ip_id [ 16 ];
}
COMPRESSED ip_id_seq {
圧縮されたip_id_seq {
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL);
}
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);
}
}
// 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,
ip_id_behavior_value)
{
UNCOMPRESSED {
version =:= uncompressed_value(4, 4) [ 4 ];
hdr_length =:= uncompressed_value(4, 5) [ 4 ];
dscp [ 6 ];
ip_ecn_flags [ 2 ];
length =:= inferred_ip_v4_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 =:= inferred_ip_v4_header_checksum [ 16 ];
src_addr [ 32 ];
dst_addr [ 32 ];
}
CONTROL {
ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
ENFORCE(innermost_ip.UVALUE == is_innermost);
ip_id_behavior_outer [ 2 ];
innermost_ip [ 1 ];
}
DEFAULT {
dscp =:= static;
ip_ecn_flags =:= static;
df =:= static;
ttl_hopl =:= static;
protocol =:= static;
src_addr =:= static;
dst_addr =:= static;
ip_id_behavior_outer =:= 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_innermost_dynamic {
ENFORCE(is_innermost == 1);
ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
reserved =:= '00000' [ 5 ];
df =:= irregular(1) [ 1 ];
ip_id_behavior_innermost =:= irregular(2) [ 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_innermost.UVALUE) [ 0, 16 ];
}
COMPRESSED ipv4_outer_dynamic {
ENFORCE(is_innermost == 0);
ENFORCE(ip_id_behavior_outer.UVALUE == ip_id_behavior_value);
reserved =:= '00000' [ 5 ];
df =:= irregular(1) [ 1 ];
ip_id_behavior_outer =:= irregular(2) [ 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_outer.UVALUE) [ 0, 16 ];
}
｝
COMPRESSED ipv4_innermost_replicate {
ENFORCE(is_innermost == 1);
ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
reserved =:= '0000' [ 4 ];
ip_id_behavior_innermost =:= irregular(2) [ 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_innermost.UVALUE) [ 0, 16 ];
ttl_hopl =:=
static_or_irreg(ttl_flag.UVALUE, 8) [ 0, 8 ];
}
COMPRESSED ipv4_outer_replicate {
ENFORCE(is_innermost == 0);
ENFORCE(ip_id_behavior_outer.UVALUE == ip_id_behavior_value);
reserved =:= '0000' [ 4 ];
ip_id_behavior_outer =:= irregular(2) [ 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_outer.UVALUE) [ 0, 16 ];
ttl_hopl =:=
static_or_irreg(ttl_flag.UVALUE, 8) [ 0, 8 ];
}
COMPRESSED ipv4_outer_without_ttl_irregular {
ENFORCE(is_innermost == 0);
ip_id =:=
ip_id_enc_irreg(ip_id_behavior_outer.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);
}
COMPRESSED ipv4_outer_with_ttl_irregular {
ENFORCE(is_innermost == 0);
ip_id =:=
ip_id_enc_irreg(ip_id_behavior_outer.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(ttl_irregular_chain_flag == 1);
}
COMPRESSED ipv4_innermost_irregular {
ENFORCE(is_innermost == 1);
ip_id =:=
ip_id_enc_irreg(ip_id_behavior_innermost.UVALUE) [ 0, 16 ];
ENFORCE(ip_inner_ecn == ip_ecn_flags.UVALUE);
}
}
/////////////////////////////////////////////
// TCP Options
/////////////////////////////////////////////
// nbits is bound to the remaining length (in bits) of TCP
// options, including the EOL type byte.
tcp_opt_eol(nbits)
{
UNCOMPRESSED {
type =:= uncompressed_value(8, 0) [ 8 ];
padding =:=
uncompressed_value(nbits-8, 0) [ nbits-8 ];
}
CONTROL {
pad_len [ 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 ];
}
COMPRESSED nop_list_item {
}
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_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_irregular {
wscale =:= static;
}
}
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 ];
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_pure_lsb(base)
{
UNCOMPRESSED {
sack_field [ 32 ];
}
CONTROL {
ENFORCE(sack_field.CVALUE == (sack_field.UVALUE - base));
}
COMPRESSED lsb_15 {
ENFORCE(sack_field.CVALUE == sack_field.CVALUE <= 0x7fff);
discriminator =:= '0' [ 1 ];
sack_field [ 15 ];
}
｝
COMPRESSED lsb_22 {
ENFORCE(sack_field.CVALUE == sack_field.CVALUE <= 0x3fffff);
discriminator =:= '10' [ 2 ];
sack_field [ 22 ];
}
COMPRESSED lsb_29 {
ENFORCE(sack_field.CVALUE == sack_field.CVALUE <= 0x1fffffff);
discriminator =:= '110' [ 3 ];
sack_field [ 29 ];
}
COMPRESSED full_offset {
discriminator =:= '11111111' [ 8 ];
sack_field [ 32 ];
}
}
sack_block(reference)
{
UNCOMPRESSED {
block_start [ 32 ];
block_end [ 32 ];
}
COMPRESSED {
block_start =:=
sack_pure_lsb(reference) [ 16, 24, 32, 40 ];
block_end =:=
sack_pure_lsb(block_start.UVALUE) [ 16, 24, 32, 40 ];
}
}
// The value of the parameter is set to the ack_number value
// of the TCP header
tcp_opt_sack(ack_value)
{
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.UVALUE && 0xFFFFFFFF);
ENFORCE(length.UVALUE == 18);
}
COMPRESSED sack3_list_item {
discriminator =:= '00000011';
block_1 =:= sack_block(ack_value);
block_2 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
block_3 =:= sack_block(block_2.UVALUE && 0xFFFFFFFF);
ENFORCE(length.UVALUE == 26);
}
COMPRESSED sack4_list_item {
discriminator =:= '00000100';
block_1 =:= sack_block(ack_value);
block_2 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
block_3 =:= sack_block(block_2.UVALUE && 0xFFFFFFFF);
block_4 =:= sack_block(block_3.UVALUE && 0xFFFFFFFF);
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.UVALUE && 0xFFFFFFFF);
ENFORCE(length.UVALUE == 18);
}
COMPRESSED sack3_irregular {
discriminator =:= '00000011';
block_1 =:= sack_block(ack_value);
block_2 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
block_3 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
ENFORCE(length.UVALUE == 26);
}
COMPRESSED sack4_irregular {
discriminator =:= '00000100';
block_1 =:= sack_block(ack_value);
block_2 =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
block_3 =:= sack_block(block_2.UVALUE && 0xFFFFFFFF);
block_4 =:= sack_block(block_3.UVALUE && 0xFFFFFFFF);
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_irregular {
}
}
tcp_opt_generic
{
UNCOMPRESSED {
type [ 8 ];
length_msb =:= uncompressed_value(1, 0) [ 1 ];
length_lsb [ 7 ];
contents [ length_lsb.UVALUE*8-16 ];
}
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_lsb.UVALUE*8-16 ];
}
// Used when context of option has option_static set to one
COMPRESSED generic_static_irregular {
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;
}
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
/////////////////////////////////////////////
port_replicate(flags)
{
UNCOMPRESSED {
port [ 16 ];
}
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 ];
}
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 ];
}
COMPRESSED none {
rsf_idx =:= '00' [ 2 ];
rsf_flag =:= uncompressed_value(3, 0x00);
}
COMPRESSED rst_only {
rsf_idx =:= '01' [ 2 ];
rsf_flag =:= uncompressed_value(3, 0x04);
}
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 {
}
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 {
dummy_field_s =:= field_scaling(payload_size,
seq_number_scaled.UVALUE, seq_number.UVALUE,
seq_number_residue.UVALUE) [ 0 ];
dummy_field_a =:= field_scaling(ack_stride.UVALUE,
ack_number_scaled.UVALUE, ack_number.UVALUE,
ack_number_residue.UVALUE) [ 0 ];
ENFORCE(ack_stride.UVALUE == ack_stride_value);
}
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;
ack_stride =:= static;
ack_number_scaled =:= static;
seq_number_scaled =:= static;
ack_number_residue =:= static;
seq_number_residue =:= 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 ];
}
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 ];
}
CONTROL {
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 ];
}
｝
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);
ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE);
}
COMPRESSED not_present {
ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) ||
(behavior == IP_ID_BEHAVIOR_ZERO));
}
}
dont_fragment(version)
{
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.
//////////////////////////////////
// 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, ip_id_behavior_value)
{
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 {
ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM);
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 ];
df =:= uncompressed_value(0,0) [ 0 ];
ip_id =:= uncompressed_value(0,0) [ 0 ];
}
CONTROL {
dummy_field_s =:= field_scaling(payload_size,
seq_number_scaled.UVALUE, seq_number.UVALUE,
seq_number_residue.UVALUE) [ 0 ];
dummy_field_a =:= field_scaling(ack_stride.UVALUE,
ack_number_scaled.UVALUE, ack_number.UVALUE,
ack_number_residue.UVALUE) [ 0 ];
ENFORCE(ack_stride.UVALUE == ack_stride_value);
ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
}
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_innermost =:= static;
ecn_used =:= static;
ack_stride =:= static;
ack_number_scaled =:= static;
seq_number_scaled =:= static;
ack_number_residue =:= static;
seq_number_residue =:= static;
// Default is to have no TTL in irregular chain
// Can only be nonzero if co_common is used
ENFORCE(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_innermost =:= irregular(2) [ 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_innermost.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_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send scaled sequence number LSBs COMPRESSED rnd_2 {
//スケーリングされたシーケンス番号LSBを送信します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_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.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_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.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_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.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_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.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_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.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_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.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_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO));
}
// Send LSBs of sequence number
COMPRESSED seq_1 {
discriminator =:= '1010' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.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_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.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_innermost.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_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
}
// Send acknowledgment number LSBs
COMPRESSED seq_3 {
discriminator =:= '1001' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.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_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.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_innermost.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_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.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_innermost.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_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.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_innermost.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_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
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_innermost.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_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.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_innermost.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_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.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.4 of [RFC5795].
このセクションでは、[RFC5795]のセクション5.2.4で説明されている一般的な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が含まれています。使用するシーケンス番号は、CRC-8の検証またはCRCの検証に成功した最後のヘッダーに対応するMSNです。
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
フィードバック2
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| MSN |
+---+---+---+---+---+---+---+---+
| MSN |
+---+---+---+---+---+---+---+---+
| CRC |
+---+---+---+---+---+---+---+---+
/ Feedback options /
+---+---+---+---+---+---+---+---+
Acktype:
Acktype：
0 = ACK
1 = NACK
2 = STATIC-NACK
3 is reserved (MUST NOT be used for parsability)
3は予約されています（解析性のために使用してはいけません）
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 [RFC5795]). For the purpose of computing the CRC, the CRC field is zero. The CRC is calculated using the polynomial defined in [RFC5795].
CRC: 8-bit CRC computed over the entire feedback element (as defined in Section 5.3.1.1 of [RFC5795]). For the purpose of computing the CRC, the CRC field is zero. The CRC is calculated using the polynomial defined in [RFC5795].
Feedback options: A variable number of feedback options, see Section 8.3.2. Options may appear in any order.
Feedback options: A variable number of feedback options, see Section 8.3.2. Options may appear in any order.
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.
タイプNACKまたはSTATIC-NACKのFEEDBACK-2は、MSN-NOT-VALIDオプション（セクション8.3.2.2）がに表示されていない限り、常に正常に圧縮解除されたパケットの肯定応答です。このパケットは、フィードバック要素の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形式よりも堅牢です。フィードバック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.
Each ROHC-TCP feedback option can appear at most once within a 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 MUST NOT appear more than once in the FEEDBACK-2 format; otherwise, the compressor MUST discard the entire feedback element.
REJECTオプションを受信すると、圧縮プログラムはパケットフローの圧縮を停止する必要があり、しばらくの間、圧縮されたパケットフローの数を増加させないようにする必要があります（SHOULD）。 REJECTオプションは、FEEDBACK-2形式で複数回使用してはなりません（MUST NOT）。それ以外の場合、コンプレッサーはフィードバック要素全体を破棄する必要があります。
The MSN-NOT-VALID option indicates that the MSN of the feedback is not valid.
The MSN-NOT-VALID option indicates that the MSN of the feedback is not valid.
+---+---+---+---+---+---+---+---+
| 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.
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.
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-NOT-VALIDオプションは、FEEDBACK-2形式で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.
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.
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オプションを受信すると、コンプレッサーは、必要なデコンプレッサーメモリリソースを少なくする方法でパケットフローを圧縮するか、パケットフローの圧縮を停止するアクションを実行する必要があります（SHOULD）。
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.
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.
This RFC revises RFC 4996. It is mostly backwards-compatible with RFC 4996, except for two cases that did not interoperate as described below.
このRFCはRFC 4996を改訂します。以下に説明するように相互運用しなかった2つのケースを除いて、RFC 4996との後方互換性がほとんどあります。
o The SACK option compression in [RFC4996] assumed that multiple SACK blocks within the same option would be in sorted order so that the block starts were LSB-encoded from the end of the previous block. This meant that SACK blocks that are not in sorted order could be impossible to compress in some cases. Therefore, the SACK compression in the formal notation has changed and therefore also the bits-on-the-wire.
o [RFC4996]のSACKオプション圧縮は、同じオプション内の複数のSACKブロックがソートされた順序であり、ブロックの開始が前のブロックの終了からLSBエンコードされると想定していました。つまり、並べ替えられていないSACKブロックは、場合によっては圧縮できないことがあります。したがって、正式な表記でのSACK圧縮が変更され、ビットオンザワイヤーも変更されました。
o The ESP NULL header compression has been deprecated due to interoperability problems with needing to know information from the trailer. The ESP NULL compression was already removed from ROHCv2 [RFC5225] for the same reason and it was considered better to remove it from this profile rather than try to fix the interoperability issue.
o The ESP NULL header compression has been deprecated due to interoperability problems with needing to know information from the trailer. The ESP NULL compression was already removed from ROHCv2 [RFC5225] for the same reason and it was considered better to remove it from this profile rather than try to fix the interoperability issue.
o The way sequential IP-ID compression was described in the FN code was incorrect and the code used for ROHCv2 [RFC5225] has been imported into this specification (e.g., offset is made into a global control field). This does not change the bits-on-the-wire. The only change is how this encoding is described in the formal notation, not how the compression occurs.
o The way sequential IP-ID compression was described in the FN code was incorrect and the code used for ROHCv2 [RFC5225] has been imported into this specification (e.g., offset is made into a global control field). This does not change the bits-on-the-wire. The only change is how this encoding is described in the formal notation, not how the compression occurs.
o Default encoding for the 'df' and 'ip_id' fields have been added for IPv6 with 0-bit uncompressed format to clarify that these never appear in IPv6.
o Default encoding for the 'df' and 'ip_id' fields have been added for IPv6 with 0-bit uncompressed format to clarify that these never appear in IPv6.
o The scaled encoding of the Acknowledgment Number and Sequence Number were incorrectly described in the FN code in [RFC4996] and have been updated in the same style as in ROHCv2 [RFC5225]. This does not change the bits-on-the-wire, only the way the compression is described in the FN code.
o The scaled encoding of the Acknowledgment Number and Sequence Number were incorrectly described in the FN code in [RFC4996] and have been updated in the same style as in ROHCv2 [RFC5225]. This does not change the bits-on-the-wire, only the way the compression is described in the FN code.
o The external arguments to ipv4 and co_baseheader have been updated. This is again only a change for FN correctness and does not affect interoperability.
o The external arguments to ipv4 and co_baseheader have been updated. This is again only a change for FN correctness and does not affect interoperability.
o Errata for [RFC4996] related to minor errors in the FN and textual errors have also been corrected.
o Errata for [RFC4996] related to minor errors in the FN and textual errors have also been corrected.
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.
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.
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.
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.
The reference for the ROHC profile identifier 0x0006 has been updated to reference this document instead of RFC 4996.
The reference for the ROHC profile identifier 0x0006 has been updated to reference this document instead of RFC 4996.
A ROHC profile identifier has been reserved by IANA for the profile defined in this document. Profiles 0x0000-0x0005 have previously been reserved; this profile is 0x0006. As for previous ROHC profiles, profile numbers 0xnn06 have been reserved for future updates of this profile.
A ROHC profile identifier has been reserved by IANA for the profile defined in this document. Profiles 0x0000-0x0005 have previously been reserved; this profile is 0x0006. As for previous ROHC profiles, profile numbers 0xnn06 have been reserved for future updates of this profile.
Profile Usage Document identifier
Profile Usage Document identifier
0x0006 ROHC TCP [RFC6846] 0xnn06 Reserved
0x0006 ROHC TCP [RFC6846] 0xnn06 Reserved
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 and to Carl Knutsson and Gilbert Strom for suggestions and review of the updates made in this document.
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 and to Carl Knutsson and Gilbert Strom for suggestions and review of the updates made in this document.
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.
追記：このドキュメントは、作業部会の最終会議で、熱心なレビュアーのJoe TouchとTed Faber、およびTransport Area Directorsのリクエストでレビューを提供したSally Floydによってレビューされました。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC4164] Pelletier, G., "RObust Header Compression (ROHC): Context Replication for ROHC Profiles", RFC 4164, August 2005.
[RFC4164] Pelletier, G., "RObust Header Compression (ROHC): Context Replication for ROHC Profiles", RFC 4164, August 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust Header Compression (ROHC-FN)", RFC 4997, July 2007.
[RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust Header Compression (ROHC-FN)", RFC 4997, July 2007.
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, March 2010.
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, March 2010.
[RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[RFC1144] Jacobson、V。、「低速シリアルリンクのTCP / IPヘッダーの圧縮」、RFC 1144、1990年2月。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[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] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, 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.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004.
[RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004.
[RFC4163] Jonsson, L-E., "RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression", RFC 4163, August 2005.
[RFC4163] Jonsson, L-E., "RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression", RFC 4163, August 2005.
[RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets", RFC 4224, January 2006.
[RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets", RFC 4224, January 2006.
[RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, March 2006.
[RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, March 2006.
[RFC4996] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", RFC 4996, July 2007.
[RFC4996] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", RFC 4996, July 2007.
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008.
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
Authors' Addresses
Authors' Addresses
Ghyslain Pelletier InterDigital Communications 1000, Sherbrooke Street West, 10th floor Montreal, Quebec H3A 3G4 Canada
Ghyslain Pelletier InterDigital Communications 1000, Sherbrooke Street West, 10th floor Montreal, Quebec H3A 3G4 Canada
Phone: +46 (0) 70 609 27 73
EMail: ghyslain.pelletier@interdigital.com
Kristofer Sandlund Ericsson Box 920 Lulea SE-971 28 Sweden
Kristofer Sandlund Ericsson Box 920 Lulea SE-971 28 Sweden
Phone: +46 (0) 8 404 41 58
EMail: kristofer.sandlund@ericsson.com
Lars-Erik Jonsson Optand 737 Ostersund SE-831 92 Sweden
Lars-Erik Jonsson Optand 737エステルスンドSE-831 92スウェーデン
Phone: +46 70 365 20 58
EMail: lars-erik@lejonsson.com
Mark A West Siemens/Roke Manor Roke Manor Research Ltd. Romsey, Hampshire SO51 0ZN UK
Mark A West Siemens / Roke Manor Roke Manor Research Ltd. Romsey、Hampshire SO51 0ZN UK
Phone: +44 1794 833311
EMail: mark.a.west@roke.co.uk
URI: http://www.roke.co.uk