[要約] RFC 5225は、ROHCv2のプロファイルに関するものであり、RTP、UDP、IP、ESP、UDP-Liteに対応しています。その目的は、ネットワーク上でのデータ圧縮を改善し、効率的な通信を実現することです。
Network Working Group G. Pelletier
Request for Comments: 5225 K. Sandlund
Category: Standards Track Ericsson
April 2008
RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite
堅牢なヘッダー圧縮バージョン2（ROHCV2）：RTP、UDP、IP、ESP、UDP-Liteのプロファイル
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document specifies ROHC (Robust Header Compression) profiles that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP (Encapsulating Security Payload) headers.
このドキュメントは、RTP/UDP/IP（リアルタイムトランスポートプロトコル、ユーザーデータグラムプロトコル、インターネットプロトコル）、RTP/UDP-LITE/IP（ユーザーデータグラムプロトコルLITE）、UDP/IP/IP、UDP-Lite/IP、IPおよびESP/IP（セキュリティペイロードのカプセル化）ヘッダー。
This specification defines a second version of the profiles found in RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but does not obsolete them.
この仕様では、RFC 3095、RFC 3843、およびRFC 4019にあるプロファイルの2番目のバージョンを定義します。それは彼らの定義に取って代わりますが、それらを廃止することはありません。
The ROHCv2 profiles introduce a number of simplifications to the rules and algorithms that govern the behavior of the compression endpoints. It also defines robustness mechanisms that may be used by a compressor implementation to increase the probability of decompression success when packets can be lost and/or reordered on the ROHC channel. Finally, the ROHCv2 profiles define their own specific set of header formats, using the ROHC formal notation.
ROHCV2プロファイルは、圧縮エンドポイントの動作を支配するルールとアルゴリズムに多くの単純化を導入します。また、コンプレッサーの実装で使用される堅牢性メカニズムを定義して、ROHCチャネルでパケットを失ったり並べ替えたりすることができる場合の減圧成功の確率を高めることができます。最後に、ROHCV2プロファイルは、ROHCフォーマル表記を使用して、独自の特定のヘッダー形式のセットを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Background (Informative) . . . . . . . . . . . . . . . . . . 7
4.1. Classification of Header Fields . . . . . . . . . . . . . 7
4.2. Improvements of ROHCv2 over RFC 3095 Profiles . . . . . . 8
4.3. Operational Characteristics of ROHCv2 Profiles . . . . . 10
5. Overview of the ROHCv2 Profiles (Informative) . . . . . . . . 10
5.1. Compressor Concepts . . . . . . . . . . . . . . . . . . . 11
5.1.1. Optimistic Approach . . . . . . . . . . . . . . . . . 11
5.1.2. Tradeoff between Robustness to Losses and to
Reordering . . . . . . . . . . . . . . . . . . . . . 11
5.1.3. Interactions with the Decompressor Context . . . . . 13
5.2. Decompressor Concepts . . . . . . . . . . . . . . . . . . 14
5.2.1. Decompressor State Machine . . . . . . . . . . . . . 14
5.2.2. Decompressor Context Management . . . . . . . . . . . 17
5.2.3. Feedback Logic . . . . . . . . . . . . . . . . . . . 19
6. ROHCv2 Profiles (Normative) . . . . . . . . . . . . . . . . . 19
6.1. Channel Parameters, Segmentation, and Reordering . . . . 19
6.2. Profile Operation, Per-context . . . . . . . . . . . . . 20
6.3. Control Fields . . . . . . . . . . . . . . . . . . . . . 21
6.3.1. Master Sequence Number (MSN) . . . . . . . . . . . . 21
6.3.2. Reordering Ratio . . . . . . . . . . . . . . . . . . 21
6.3.3. IP-ID Behavior . . . . . . . . . . . . . . . . . . . 22
6.3.4. UDP-Lite Coverage Behavior . . . . . . . . . . . . . 22
6.3.5. Timestamp Stride . . . . . . . . . . . . . . . . . . 22
6.3.6. Time Stride . . . . . . . . . . . . . . . . . . . . . 22
6.3.7. CRC-3 for Control Fields . . . . . . . . . . . . . . 23
6.4. Reconstruction and Verification . . . . . . . . . . . . . 23
6.5. Compressed Header Chains . . . . . . . . . . . . . . . . 24
6.6. Header Formats and Encoding Methods . . . . . . . . . . . 25
6.6.1. baseheader_extension_headers . . . . . . . . . . . . 26
6.6.2. baseheader_outer_headers . . . . . . . . . . . . . . 26
6.6.3. inferred_udp_length . . . . . . . . . . . . . . . . . 26
6.6.4. inferred_ip_v4_header_checksum . . . . . . . . . . . 26
6.6.5. inferred_mine_header_checksum . . . . . . . . . . . . 27
6.6.6. inferred_ip_v4_length . . . . . . . . . . . . . . . . 28
6.6.7. inferred_ip_v6_length . . . . . . . . . . . . . . . . 28
6.6.8. Scaled RTP Timestamp Compression . . . . . . . . . . 29
6.6.9. timer_based_lsb . . . . . . . . . . . . . . . . . . . 30
6.6.10. inferred_scaled_field . . . . . . . . . . . . . . . . 31
6.6.11. control_crc3_encoding . . . . . . . . . . . . . . . . 32
6.6.12. inferred_sequential_ip_id . . . . . . . . . . . . . . 33
6.6.13. list_csrc(cc_value) . . . . . . . . . . . . . . . . . 34
6.7. Encoding Methods with External Parameters as Arguments . 38
6.8. Header Formats . . . . . . . . . . . . . . . . . . . . . 40
6.8.1. Initialization and Refresh Header Format (IR) . . . . 40
6.8.2. Compressed Header Formats (CO) . . . . . . . . . . . 41
6.9. Feedback Formats and Options . . . . . . . . . . . . . . 100
6.9.1. Feedback Formats . . . . . . . . . . . . . . . . . . 100
6.9.2. Feedback Options . . . . . . . . . . . . . . . . . . 102
7. Security Considerations . . . . . . . . . . . . . . . . . . . 104
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 106
10.1. Normative References . . . . . . . . . . . . . . . . . . 106
10.2. Informative References . . . . . . . . . . . . . . . . . 107
Appendix A. Detailed Classification of Header Fields . . . . . 108
A.1. IPv4 Header Fields . . . . . . . . . . . . . . . . . . . 109
A.2. IPv6 Header Fields . . . . . . . . . . . . . . . . . . . 112
A.3. UDP Header Fields . . . . . . . . . . . . . . . . . . . 113
A.4. UDP-Lite Header Fields . . . . . . . . . . . . . . . . . 114
A.5. RTP Header Fields . . . . . . . . . . . . . . . . . . . . 115
A.6. ESP Header Fields . . . . . . . . . . . . . . . . . . . . 117
A.7. IPv6 Extension Header Fields . . . . . . . . . . . . . . 117
A.8. GRE Header Fields . . . . . . . . . . . . . . . . . . . . 118
A.9. MINE Header Fields . . . . . . . . . . . . . . . . . . . 119
A.10. AH Header Fields . . . . . . . . . . . . . . . . . . . . 120
Appendix B. Compressor Implementation Guidelines . . . . . . . 121
B.1. Reference Management . . . . . . . . . . . . . . . . . . 121
B.2. Window-based LSB Encoding (W-LSB) . . . . . . . . . . . 121
B.3. W-LSB Encoding and Timer-based Compression . . . . . . . 122
The ROHC WG has developed a header compression framework on top of which various profiles can be defined for different protocol sets or compression requirements. The ROHC framework was first documented in [RFC3095], together with profiles for compression of RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, IP and ESP/IP (Encapsulating Security Payload) headers. Additional profiles for compression of IP headers [RFC3843] and UDP-Lite (User Datagram Protocol Lite) headers [RFC4019] were later specified to complete the initial set of ROHC profiles.
ROHC WGは、さまざまなプロトコルセットまたは圧縮要件に対してさまざまなプロファイルを定義できるヘッダー圧縮フレームワークを開発しました。ROHCフレームワークは、RTP/UDP/IP（リアルタイムトランスポートプロトコル、ユーザーデータグラムプロトコル、インターネットプロトコル）、UDP/IP、IP、およびESP/IPの圧縮のプロファイルとともに、[RFC3095]で最初に文書化されました。）ヘッダー。IPヘッダー[RFC3843]およびUDP-LITE（ユーザーデータグラムプロトコルLITE）ヘッダー[RFC4019]の圧縮の追加プロファイルが、ROHCプロファイルの初期セットを完了するように後で指定されました。
This document defines an updated version for each of the above mentioned profiles, and the definitions depend on the ROHC framework as found in [RFC4995]. The framework is required reading to understand the profile definitions, rules, and their role.
このドキュメントは、上記の各プロファイルの更新されたバージョンを定義し、[RFC4995]に見られるように、定義はROHCフレームワークに依存します。このフレームワークは、プロファイルの定義、ルール、およびその役割を理解するために読む必要があります。
Specifically, this document defines header compression schemes for:
具体的には、このドキュメントは次のようなヘッダー圧縮スキームを定義しています。
o RTP/UDP/IP : profile 0x0101 o UDP/IP : profile 0x0102 o ESP/IP : profile 0x0103 o IP : profile 0x0104 o RTP/UDP-Lite/IP : profile 0x0107 o UDP-Lite/IP : profile 0x0108
o
Each of the profiles above can compress the following type of extension headers:
上記の各プロファイルは、次のタイプの拡張ヘッダーを圧縮できます。
o AH [RFC4302]
o AH [RFC4302]
o GRE [RFC2784][RFC2890]
o GRE [RFC 2784] [RFC 2890]
o MINE [RFC2004]
o 鉱山[RFC2004]
o IPv6 Destination Options header[RFC2460]
o IPv6宛先オプションヘッダー[RFC2460]
o IPv6 Hop-by-hop Options header[RFC2460]
o IPv6ホップバイホップオプションヘッダー[RFC2460]
o IPv6 Routing header [RFC2460]
o IPv6ルーティングヘッダー[RFC2460]
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
This document is consistent with the terminology found in the ROHC framework [RFC4995] and in the formal notation for ROHC [RFC4997]. In addition, this document uses or defines the following terms:
このドキュメントは、ROHCフレームワーク[RFC4995]およびROHC [RFC4997]の正式な表記法に見られる用語と一致しています。さらに、このドキュメントは次の用語を使用または定義します。
Acknowledgment Number
謝辞番号
The Acknowledgment Number identifies what packet is being acknowledged in the RoHCv2 feedback element (See Section 6.9). The value of this field normally corresponds to the Master Sequence Number (MSN) of the header that was last successfully decompressed, for the compression context (CID) for which the feedback information applies.
確認番号は、ROHCV2フィードバック要素でどのパケットが認められているかを識別します（セクション6.9を参照）。このフィールドの値は通常、フィードバック情報が適用される圧縮コンテキスト（CID）について、最後に正常に減圧されたヘッダーのマスターシーケンス番号（MSN）に対応します。
Chaining of Items
アイテムのチェーン
A chain of items groups fields based on similar characteristics. ROHCv2 defines chain items for static, dynamic and irregular fields. Chaining is achieved by appending an item to the chain for each header in its 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 a ROHCv2 profile defines a compressed format.
アイテムのチェーンは、同様の特性に基づいてフィールドをグループ化します。ROHCV2は、静的、動的、不規則なフィールドのチェーンアイテムを定義します。チェーンは、非圧縮パケットに外観の順に、各ヘッダーにアイテムをチェーンに追加することで達成されます。チェーンは、ROHCV2プロファイルが圧縮形式を定義するプロトコルヘッダーの任意の数から圧縮ヘッダーを構築するのに役立ちます。
CRC-3 Control Fields Validation
CRC-3制御フィールドの検証
The CRC-3 control fields validation refers to the validation of the control fields. This validation is performed by the decompressor when it receives a Compressed (CO) header that contains a 3-bit Cyclic Redundancy Check (CRC) calculated over control fields. This 3-bit CRC covers controls fields carried in the CO header as well as specific control fields in the context. In the formal definition of the header formats, this 3-bit CRC is labeled "control_crc3" and uses the control_crc3_encoding (See also Section 6.6.11).
CRC-3制御フィールドの検証とは、制御フィールドの検証を指します。この検証は、制御フィールドで計算された3ビット環状冗長チェック（CRC）を含む圧縮（CO）ヘッダーを受信すると、減圧器によって実行されます。この3ビットCRCは、COヘッダーで運ばれたフィールドと、コンテキスト内の特定の制御フィールドをカバーしています。ヘッダー形式の正式な定義では、この3ビットCRCには「control_crc3」というラベルが付けられ、control_crc3_encodingを使用します（セクション6.6.11も参照）。
Delta
デルタ
The delta refers to the difference in the absolute value of a field between two consecutive packets being processed by the same compression endpoint.
デルタは、同じ圧縮エンドポイントによって処理される2つの連続したパケット間のフィールドの絶対値の違いを指します。
Reordering Depth
深さの並べ替え
The number of packets by which a packet is received late within its sequence due to reordering between the compressor and the decompressor, i.e., reordering between packets associated with the same context (CID). See the definition of sequentially late packet below.
コンプレッサーと減圧器間の並べ替えにより、つまり、同じコンテキストに関連付けられたパケット間の並べ替え（CID）の間の並べ替えにより、パケットがそのシーケンス内に遅れて受信されるパケットの数。以下の順次後期パケットの定義を参照してください。
ROHCv2 Header Types
ROHCV2ヘッダータイプ
ROHCv2 profiles use two different header types: the Initialization and Refresh (IR) header type, and the Compressed (CO) header type.
ROHCV2プロファイルは、初期化と更新（IR）ヘッダータイプ、および圧縮（CO）ヘッダータイプの2つの異なるヘッダータイプを使用します。
Sequentially Early Packet
順次初期のパケット
A packet that reaches the decompressor before one or several packets that were delayed over the channel, where all of the said packets belong to the same header-compressed flow and are associated to the same compression context (CID). At the time of the arrival of a sequentially early packet, the packet(s) delayed on the link cannot be differentiated from lost packet(s).
すべてのパケットが同じヘッダー圧縮フローに属し、同じ圧縮コンテキスト（CID）に関連付けられているチャネル上で1つまたは複数のパケットが遅れた1つまたは複数のパケットの前に分解器に到達するパケット。連続的に早期のパケットの到着時には、リンクで遅延したパケットを失われたパケットと区別することはできません。
Sequentially Late Packet
順次後期パケット
A packet is late within its sequence if it reaches the decompressor after one or several other packets belonging to the same CID have been received, although the sequentially late packet was sent from the compressor before the other packet(s). How the decompressor detects a sequentially late packet is outside the scope of this specification, but it can for example use the MSN for this purpose.
同じCIDに属する他の1つまたは複数のパケットが受信された後に減圧器に到達した場合、パケットはそのシーケンス内に遅れますが、他のパケットの前に順次後期パケットがコンプレッサーから送信されました。減圧器が連続的に遅いパケットを検出する方法は、この仕様の範囲外にありますが、たとえばこの目的にはMSNを使用できます。
Timestamp Stride (ts_stride)
タイムスタンプストライド（TS_STRIDE）
The timestamp stride (ts_stride) is the expected increase in the timestamp value between two RTP packets with consecutive sequence numbers. For example, for a media encoding with a sample rate of 8 kHz producing one frame every 20 ms, the RTP timestamp will typically increase by n * 160 (= 8000 * 0.02), for some integer n.
タイムスタンプストライド（TS_STRIDE）は、連続したシーケンス番号を持つ2つのRTPパケット間のタイムスタンプ値の予想される増加です。たとえば、20ミリ秒ごとに1つのフレームを生成する8 kHzのサンプルレートでエンコードするメディアの場合、RTPタイムスタンプは通常、一部の整数nでn * 160（= 8000 * 0.02）で増加します。
Time Stride (time_stride)
タイムストライド（time_stride）
The time stride (time_stride) is the time interval equivalent to one ts_stride, e.g., 20 ms in the example for the RTP timestamp increment above.
Time Stride（Time_Stride）は、1つのTS_STRIDEに相当する時間間隔です。たとえば、上記のRTPタイムスタンプ増分の例では20ミリ秒です。
This section lists most acronyms used for reference, in addition to those defined in [RFC4995].
このセクションには、[RFC4995]で定義されているものに加えて、参照に使用されるほとんどの頭字語をリストします。
AH Authentication Header. ESP Encapsulating Security Payload. GRE Generic Routing Encapsulation. FC Full Context state (decompressor). IP Internet Protocol. LSB Least Significant Bits. MINE Minimal Encapsulation in IP. MSB Most Significant Bits. MSN Master Sequence Number. NC No Context state (decompressor). OA Optimistic Approach. RC Repair Context state (decompressor). ROHC Header compression framework (RFC 4995). ROHCv2 Set of header compression profiles defined in this document. RTP Real-time Transport Protocol. SSRC Synchronization source. Field in RTP header. CSRC Contributing source. The RTP header contains an optional list of contributing sources. TC Traffic Class. Field in the IPv6 header. See also TOS. TOS Type Of Service. Field in the IPv4 header. See also TC. TS RTP Timestamp. TTL Time to Live. Field in the IPv4 header. UDP User Datagram Protocol. UDP-Lite User Datagram Protocol Lite.
AH認証ヘッダー。特にセキュリティペイロードをカプセル化します。GREジェネリックルーティングカプセル化。FCフルコンテキスト状態（減圧装置）。IPインターネットプロトコル。LSB最小有意ビット。IPでの最小限のカプセル化。MSB最も重要なビット。MSNマスターシーケンス番号。NCコンテキスト状態なし（減圧装置）。OA楽観的なアプローチ。RC修復コンテキスト状態（減圧装置）。ROHCヘッダー圧縮フレームワーク（RFC 4995）。このドキュメントで定義されているヘッダー圧縮プロファイルのROHCV2セット。RTPリアルタイムトランスポートプロトコル。SSRC同期ソース。RTPヘッダーのフィールド。CSRC寄与源。RTPヘッダーには、寄稿ソースのオプションのリストが含まれています。TCトラフィッククラス。IPv6ヘッダーのフィールド。TOSも参照してください。TOSタイプのサービス。IPv4ヘッダーのフィールド。TCも参照してください。TS RTPタイムスタンプ。TTLライブの時間。IPv4ヘッダーのフィールド。UDPユーザーデータグラムプロトコル。udp-liteユーザーデータグラムプロトコルライト。
This section provides background information on the compression profiles defined in this document. The fundamentals of general header compression and of the ROHC framework may be found in sections 3 and 4 of [RFC4995], respectively. The fundamentals of the formal notation for ROHC are defined in [RFC4997]. [RFC4224] describes the impacts of out-of-order delivery on profiles based on [RFC3095].
このセクションでは、このドキュメントで定義されている圧縮プロファイルに関する背景情報を提供します。一般的なヘッダー圧縮とROHCフレームワークの基礎は、それぞれ[RFC4995]のセクション3と4に記載されている場合があります。ROHCの正式な表記の基本は[RFC4997]で定義されています。[RFC4224]は、[RFC3095]に基づいたプロファイルに対する注文外配信の影響を説明しています。
Section 3.1 of [RFC4995] explains that header compression is possible due to the fact that there is much redundancy between field values within the headers of a packet, especially between the headers of consecutive packets.
[RFC4995]のセクション3.1は、パケットのヘッダー内のフィールド値の間に、特に連続したパケットのヘッダー間でフィールド値の間に多くの冗長性があるため、ヘッダー圧縮が可能であることを説明しています。
Appendix A lists and classifies in detail all the header fields relevant to this document. The appendix concludes with recommendations on how the various fields should be handled by header compression algorithms.
付録Aには、このドキュメントに関連するすべてのヘッダーフィールドを詳細にリストおよび分類します。付録は、ヘッダー圧縮アルゴリズムによってさまざまなフィールドをどのように処理するかについての推奨事項で終了します。
The main conclusion is that most of the header fields can easily be compressed away since they never or seldom change. A small number of fields however need more sophisticated mechanisms.
主な結論は、ほとんどのヘッダーフィールドは、決して変化しないかめったに変わらないため、簡単に圧縮できるということです。ただし、少数のフィールドには、より洗練されたメカニズムが必要です。
These fields are:
- IPv4 Identification (16 bits) - IP-ID - ESP Sequence Number (32 bits) - ESP SN - UDP Checksum (16 bits) - Checksum - UDP-Lite Checksum (16 bits) - Checksum - UDP-Lite Checksum Coverage (16 bits) - CCov - RTP Marker ( 1 bit ) - M-bit - RTP Sequence Number (16 bits) - RTP SN - RTP Timestamp (32 bits) - TS
- IPv4識別（16ビット） - IP -ID -ESPシーケンス番号（32ビット） - ESP SN -UDPチェックサム（16ビット） - チェックサム-UDP -LITEチェックサム - チェックサム-UDPライトチェックサムカバレッジ（16ビット）-CCOV -RTPマーカー（1ビット）-Mビット-RTPシーケンス番号（16ビット）-RTP SN -RTPタイムスタンプ（32ビット）-TS
In particular, for RTP, the analysis in Appendix A reveals that the values of the RTP Timestamp (TS) field usually have a strong correlation to the RTP Sequence Number (SN), which increments by one for each packet emitted by an RTP source. The RTP M-bit is expected to have the same value most of the time, but it needs to be communicated explicitly on occasion.
特に、RTPの場合、付録Aの分析では、RTPタイムスタンプ（TS）フィールドの値が通常、RTPシーケンス数（SN）と強い相関関係があることが明らかになりました。RTP M-Bitはほとんどの場合同じ値を持っていると予想されますが、時には明示的に通信する必要があります。
For UDP, the Checksum field cannot be inferred or recalculated at the receiving end without violating its end-to-end properties, and is thus sent as-is when enabled (mandatory with IPv6). The same applies to the UDP-Lite Checksum (mandatory with both IPv4 and IPv6), while the UDP-Lite Checksum Coverage may in some cases be compressible.
UDPの場合、チェックサムフィールドは、エンドツーエンドのプロパティに違反することなく受信側で推測または再計算できないため、有効になった場合に送信されます（IPv6で必須）。同じことがUDP-Liteチェックサム（IPv4とIPv6の両方で必須）にも当てはまりますが、UDP-Liteチェックサムのカバレッジは、場合によっては圧縮可能である場合があります。
For IPv4, a similar correlation as that of the RTP TS to the RTP SN is often observed between the Identifier field (IP-ID) and the master sequence number (MSN) used for compression (e.g., the RTP SN when compressing RTP headers).
IPv4の場合、RTP SNに対するRTP TSの相関と同様の相関は、識別子フィールド（IP-ID）と圧縮に使用されるマスターシーケンス番号（MSN）の間でしばしば観察されます（たとえば、RTPヘッダーを圧縮するときのRTP SN）。
The ROHCv2 profiles can achieve compression efficiency and robustness that are both at least equivalent to RFC 3095 profiles [RFC3095], when used under the same operating conditions. In particular, the size and bit layout of the smallest compressed header (i.e., PT-0 format U/O-0 in RFC 3095, and pt_0_crc3 in ROHCv2) are identical.
ROHCV2プロファイルは、同じ動作条件下で使用する場合、少なくともRFC 3095プロファイル[RFC3095]と少なくとも同等の圧縮効率と堅牢性を実現できます。特に、最小圧縮ヘッダーのサイズとビットレイアウト（つまり、RFC 3095のPT-0形式U/O-0、およびROHCV2のPT_0_CRC3）は同一です。
There are a number of differences and improvements between profiles defined in this document and their earlier version defined in RFC 3095. This section provides an overview of some of the most significant improvements: Tolerance to reordering
このドキュメントで定義されているプロファイルとRFC 3095で定義された以前のバージョンには、多くの違いと改善があります。このセクションでは、最も重要な改善点の概要を説明します。
Profiles defined in RFC 3095 require that the channel between compressor and decompressor provide in-order delivery between compression endpoints. ROHCv2 profiles, however, can handle robustly and efficiently a limited amount of reordering after the compression point as part of the compression algorithm itself. In addition, this improved support for reordering makes it possible for ROHCv2 profiles to handle prelink reordering more efficiently.
Operational logic
運用ロジック
Profiles in RFC 3095 define multiple operational modes, each with different updating logic and compressed header formats. ROHCv2 profiles operate in unidirectional operation until feedback is first received for a context (CID), at which point bidirectional operation is used; the formats are independent of what operational logic is used.
RFC 3095のプロファイルは、それぞれ異なる更新ロジックと圧縮ヘッダー形式を持つ複数の動作モードを定義します。ROHCV2プロファイルは、コンテキスト（CID）に対してフィードバックが最初に受信されるまで、単方向操作で動作し、その時点で双方向の動作が使用されます。この形式は、運用ロジックが使用されるものとは無関係です。
IP extension header
IP拡張ヘッダー
Profiles in RFC 3095 compress IP Extension headers using list compression. ROHCv2 profiles instead treat extension headers in the same manner as other protocol headers, i.e., using the chaining mechanism; it thus assumes that extension headers are not added or removed during the lifetime of a context (CID), otherwise compression has to be restarted for this flow.
RFC 3095のプロファイルは、リスト圧縮を使用してIP拡張ヘッダーを圧縮します。ROHCV2プロファイルは、代わりに、他のプロトコルヘッダーと同じ方法で拡張ヘッダーを扱います。つまり、チェーンメカニズムを使用します。したがって、コンテキストの寿命（CID）の間に拡張ヘッダーが追加または削除されないと想定しています。そうしないと、このフローのために圧縮を再起動する必要があります。
IP encapsulation
IPカプセル化
Profiles in RFC 3095 can compress at most two levels of IP headers. ROHCv2 profiles can compress an arbitrary number of IP headers.
RFC 3095のプロファイルは、最大2レベルのIPヘッダーで圧縮できます。ROHCV2プロファイルは、任意の数のIPヘッダーを圧縮できます。
List compression
リスト理解
ROHCv2 profiles do not support reference-based list compression.
ROHCV2プロファイルは、参照ベースのリスト圧縮をサポートしていません。
Robustness and repairs
堅牢性と修理
ROHCv2 profiles do not define a format for the IR-DYN packet; instead, each profile defines a compressed header that can be used to perform a more robust context repair using a 7-bit CRC verification. This also implies that only the IR header can change the association between a CID and the profile it uses.
ROHCV2プロファイルは、IR-Dynパケットの形式を定義していません。代わりに、各プロファイルは、7ビットCRC検証を使用して、より堅牢なコンテキスト修復を実行するために使用できる圧縮ヘッダーを定義します。これはまた、IRヘッダーのみがCIDと使用するプロファイルとの関連を変更できることを意味します。
Feedback
フィードバック
ROHCv2 profiles mandate a CRC in the format of the FEEDBACK-2, while this is optional in RFC 3095. A different set of feedback options is also used in ROHCv2 compared to RFC 3095.
ROHCV2プロファイルは、フィードバック-2の形式でCRCを命じますが、これはRFC 3095でオプションです。ROHCV2では、RFC 3095と比較して、ROHCV2のフィードバックオプションのセットも使用されます。
Robust header compression can be used over different link technologies. Section 4.4 of [RFC4995] lists the operational characteristics of the ROHC channel. The ROHCv2 profiles address a wide range of applications, and this section summarizes some of the operational characteristics that are specific to these profiles.
堅牢なヘッダー圧縮は、異なるリンクテクノロジーで使用できます。[RFC4995]のセクション4.4には、ROHCチャネルの運用特性を示します。ROHCV2プロファイルは幅広いアプリケーションに対応しており、このセクションでは、これらのプロファイルに固有の運用特性の一部をまとめます。
Packet length
パケット長
ROHCv2 profiles assume that the lower layer indicates the length of a compressed packet. ROHCv2 compressed headers do not contain length information for the payload.
ROHCV2プロファイルは、下層が圧縮パケットの長さを示していると想定しています。ROHCV2圧縮ヘッダーには、ペイロードの長さ情報が含まれていません。
Out-of-order delivery between compression endpoints
圧縮エンドポイント間のオーダー配信
The definition of the ROHCv2 profiles places no strict requirement on the delivery sequence between the compression endpoints, i.e., packets may be received in a different order than the compressor has sent them and still have a fair probability of being successfully decompressed.
ROHCV2プロファイルの定義は、圧縮エンドポイント間の配信シーケンスに厳密な要件を置きません。つまり、コンプレッサーが送信したものとは異なる順序でパケットを受信し、それでも正常に解凍される可能性が高いです。
However, frequent out-of-order delivery and/or significant reordering depth will negatively impact the compression efficiency. More specifically, if the compressor can operate using a proper estimate of the reordering characteristics of the path between the compression endpoints, larger headers can be sent more often to increase the robustness against decompression failures due to out-of-order delivery. Otherwise, the compression efficiency will be impaired from an increase in the frequency of decompression failures and recovery attempts.
ただし、頻繁な秩序外の配送や大幅な並べ替えの深さは、圧縮効率に悪影響を及ぼします。より具体的には、コンプレッサーが圧縮エンドポイント間のパスの並べ替え特性の適切な推定を使用して動作できる場合、より頻繁に送信して、秩序外配達による減圧障害に対する堅牢性を高めることができます。それ以外の場合、圧縮障害と回復の試みの頻度の増加により、圧縮効率が損なわれます。
This section provides an overview of concepts that are important and useful to the ROHCv2 profiles. These concepts may be used as guidelines for implementations but they are not part of the normative definition of the profiles, as these concepts relate to the compression efficiency of the protocol without impacting the interoperability characteristics of an implementation.
このセクションでは、ROHCV2プロファイルにとって重要かつ有用な概念の概要を説明します。これらの概念は、実装のガイドラインとして使用される場合がありますが、これらの概念は実装の相互運用性特性に影響を与えることなくプロトコルの圧縮効率に関連するため、プロファイルの規範的定義の一部ではありません。
Header compression can be conceptually characterized as the interaction of a compressor with a decompressor state machine, one per context. The responsibility of the compressor is to convey the information needed to successfully decompress a packet, based on a certain confidence regarding the state of the decompressor context.
ヘッダー圧縮は、コンプレッサーとコンプレッサー状態マシンとコンテキストごとに1つのコンプレッサーとの相互作用として概念的に特徴付けます。コンプレッサーの責任は、減圧器のコンテキストの状態に関する特定の信頼に基づいて、パケットを正常に解凍するために必要な情報を伝えることです。
This confidence is obtained from the frequency and the type of information the compressor sends when updating the decompressor context from the optimistic approach (Section 5.1.1), and optionally from feedback messages (See Section 6.9), received from the decompressor.
この信頼性は、楽観的なアプローチ（セクション5.1.1）から減圧器のコンテキストを更新するときにコンプレッサーが送信する頻度とタイプの情報から得られ、オプションでフィードバックメッセージ（セクション6.9を参照）から、減圧器から受け取ったフィードバックメッセージ（セクション6.9を参照）から得られます。
A compressor always uses the optimistic approach when it performs context updates. The compressor normally repeats the same type of update until it is fairly confident that the decompressor has successfully received the information. If the decompressor successfully receives any of the headers containing this update, the state will be available for the decompressor to process smaller compressed headers.
コンプレッサーは、コンテキストの更新を実行するときに常に楽観的なアプローチを使用します。コンプレッサーは通常、同じタイプのアップデートを繰り返します。減圧器が情報を正常に受信したと確信するまで。減圧器がこのアップデートを含むヘッダーのいずれかを正常に受信した場合、分解器がより小さな圧縮ヘッダーを処理するために状態が利用可能になります。
If field X in the uncompressed header changes value, the compressor uses a header type that contains an encoding of field X until it has gained confidence that the decompressor has received at least one packet containing the new value for X. The compressor normally selects a compressed format with the smallest header that can convey the changes needed to achieve confidence.
非圧縮ヘッダーのフィールドXが値を変更する場合、コンプレッサーは、分解器がXの新しい値を含む少なくとも1つのパケットを受信したという自信を得るまでフィールドXのエンコードを含むヘッダータイプを使用します。コンプレッサーは通常、圧縮を選択します。自信を達成するために必要な変更を伝えることができる最小のヘッダーとのフォーマット。
The number of repetitions that is needed to obtain this confidence is normally related to the packet loss and out-of-order delivery characteristics of the link where header compression is used; it is thus not defined in this document. It is outside the scope of this specification and is left to implementors to decide.
この信頼性を得るために必要な繰り返しの数は、通常、ヘッダー圧縮が使用されるリンクのパケット損失と秩序外の配信特性に関連しています。したがって、このドキュメントでは定義されていません。これはこの仕様の範囲外であり、決定するための実装者に任されています。
The ability of a header compression algorithm to handle sequentially late packets is mainly limited by two factors: the interpretation interval offset of the sliding window used for lsb encoded fields [RFC4997], and the optimistic approach (See Section 5.1.1) for seldom changing fields.
順次後期パケットを処理するヘッダー圧縮アルゴリズムの能力は、主に2つの要因によって制限されています。LSBエンコードフィールド[RFC4997]に使用されるスライディングウィンドウの解釈間隔[RFC4997]と、魅力的なアプローチ（セクション5.1.1を参照）は断リーを変えることはありません（セクション5.1.1を参照）田畑。
lsb encoded fields:
LSBエンコードフィールド：
The interpretation interval offset specifies an upper limit for the maximum reordering depth, by which is it possible for the decompressor to recover the original value of a dynamically changing (i.e., sequentially incrementing) field that is encoded using a window-based lsb encoding. Its value is typically bound to the number of lsb compressed bits in the compressed header format, and thus grows with the number of bits transmitted. However, the offset and the lsb encoding only provide robustness for the field that it compresses, and (implicitly) for other sequentially changing fields that are derived from that field.
解釈間隔のオフセットは、最大並べ替え深度の上限を指定します。これにより、分解器は、ウィンドウベースのLSBエンコーディングを使用してエンコードされる動的に変化する（つまり、連続的に増加する）フィールドの元の値を回復することができます。その値は通常、圧縮ヘッダー形式のLSB圧縮ビットの数に結合されるため、送信されるビット数とともに増加します。ただし、オフセットとLSBエンコードは、それが圧縮するフィールドにのみ堅牢性を提供し、そのフィールドから派生した他の順次変化するフィールドに（暗黙的に）提供します。
This is shown in the figure below:
これを以下の図に示します。
<--- interpretation interval (size is 2^k) ---->
|------------------+---------------------------|
v_ref-p v_ref v_ref + (2^k-1) - p
Lower Upper
Bound Bound
<--- reordering --> <--------- losses --------->
where p is the maximum negative delta, corresponding to the maximum reordering depth for which the lsb encoding can recover the original value of the field;
ここで、Pは最大負のデルタであり、LSBエンコーディングがフィールドの元の値を回復できる最大並べ替え深度に対応します。
where (2^k-1) - p is the maximum positive delta, corresponding to the maximum number of consecutive losses for which the lsb encoding can recover the original value of the field;
ここで、（2^k -1）-pは最大ポジティブデルタであり、LSBエンコーディングがフィールドの元の値を回復できる連続損失の最大数に対応しています。
where v_ref is the reference value, as defined in the lsb encoding method in [RFC4997].
ここで、[RFC4997]のLSBエンコード法で定義されているように、V_REFは基準値です。
There is thus a tradeoff between the robustness against reordering and the robustness against packet losses, with respect to the number of MSN bits needed and the distribution of the interpretation interval between negative and positive deltas in the MSN.
したがって、必要なMSNビットの数とMSNのネガティブとポジティブデルタの間の解釈間隔の分布に関して、並べ替えに対する堅牢性とパケット損失に対する堅牢性との間にはトレードオフがあります。
Seldom changing fields
めったにフィールドを変更しません
The optimistic approach (Section 5.1.1) provides the upper limit for the maximum reordering depth for seldom changing fields.
楽観的なアプローチ（セクション5.1.1）は、フィールドをめったに変えない最大並べ替え深度の上限を提供します。
There is thus a tradeoff between compression efficiency and robustness. When only information on the MSN needs to be conveyed to the decompressor, the tradeoff relates to the number of compressed MSN bits in the compressed header format. Otherwise, the tradeoff relates to the implementation of the optimistic approach.
したがって、圧縮効率と堅牢性の間にはトレードオフがあります。MSNに関する情報のみを分解器に伝える必要がある場合、トレードオフは圧縮ヘッダー形式の圧縮MSNビットの数に関連しています。それ以外の場合、トレードオフは楽観的なアプローチの実装に関連しています。
In particular, compressor implementations should adjust their optimistic approach strategy to match both packet loss and reordering characteristics of the link over which header compression is applied. For example, the number of repetitions for each update of a non-lsb encoded field can be increased. The compressor can ensure that each update is repeated until it is reasonably confident that at least one packet containing the change has reached the decompressor before the first packet sent after this sequence.
特に、コンプレッサーの実装は、ヘッダー圧縮が適用されるリンクのパケット損失と並べ替え特性の両方に合わせて、楽観的なアプローチ戦略を調整する必要があります。たとえば、非LSBエンコードされたフィールドの更新ごとに繰り返しの数を増やすことができます。コンプレッサーは、このシーケンスの後に送信される最初のパケットの前に、変更を含む少なくとも1つのパケットが減圧装置に到達したことが合理的に確信するまで、各更新を繰り返すことができます。
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.
コンプレッサーは通常、減圧器に新しいフローを処理する有用な情報がないという最初の仮定で圧縮を開始し、初期化と更新（IR）パケットを送信します。
Initially, when sending the first IR packet for a compressed flow, the compressor does not expect to receive feedback for that flow, until such feedback is first received. At this point, the compressor may then assume that the decompressor will continue to send feedback in order to repair its context when necessary. The former is referred to as unidirectional operation, while the latter is called bidirectional operation.
最初に、圧縮フローのために最初のIRパケットを送信するとき、コンプレッサーはそのようなフィードバックが最初に受信されるまで、そのフローのフィードバックを受け取ることを期待していません。この時点で、コンプレッサーは、必要に応じてコンテキストを修復するために、減圧器がフィードバックを送信し続けると想定する場合があります。前者は単方向操作と呼ばれ、後者は双方向操作と呼ばれます。
The compressor can then adjust the compression level (i.e., what header format it selects) based on its confidence that the decompressor has the necessary information to successfully process the compressed headers that it selects.
コンプレッサーは、減圧器が選択する圧縮ヘッダーを正常に処理するために必要な情報を持っているという自信に基づいて、圧縮レベル（つまり、選択するヘッダー形式）を調整できます。
In other words, the responsibilities of the compressor are to ensure that the decompressor operates with state information that is sufficient to successfully decompress the type of compressed header(s) it receives, and to allow the decompressor to successfully recover that state information as soon as possible otherwise. The compressor therefore selects the type of compressed header based on the following factors:
言い換えれば、コンプレッサーの責任は、圧縮機が受信する圧縮ヘッダーのタイプをうまく減圧するのに十分な状態情報で動作することを保証することであり、減圧器がその状態情報を正常に回復できるようにすることです。それ以外の場合は可能です。したがって、コンプレッサーは、次の要因に基づいて圧縮ヘッダーのタイプを選択します。
o the outcome of the encoding method applied to each field;
o 各フィールドに適用されるエンコーディング方法の結果。
o the optimistic approach, with respect to the characteristics of the channel;
o チャネルの特性に関して、楽観的なアプローチ。
o the type of operation (unidirectional or bidirectional), and if in bidirectional operation, feedback received from the decompressor (ACKs, NACKs, STATIC-NACK, and options).
o 操作の種類（単方向または双方向）、および双方向の動作中の場合、減圧装置（ACK、NACK、静的ナック、およびオプション）から受け取ったフィードバック。
Encoding methods normally use previous value(s) from a history of packets whose headers it has previously compressed. The optimistic approach is meant to ensure that at least one compressed header containing the information to update the state for a field is received. Finally, feedback indicates what actions the decompressor has taken with respect to its assumptions regarding the validity of its context (Section 5.2.2); it indicates what type of compressed header the decompressor can or cannot decompress.
エンコードメソッドは通常、以前に圧縮されたヘッダーのパケットの履歴から以前の値を使用します。楽観的なアプローチは、フィールドの状態を更新するための情報を含む少なくとも1つの圧縮ヘッダーを保証することを目的としています。最後に、フィードバックは、コンプレッサーがコンテキストの妥当性に関する仮定に関してどのアクションを行ったかを示します（セクション5.2.2）。これは、減圧装置がどのタイプの圧縮ヘッダーを減圧できないかを示します。
The decompressor has the means to detect decompression failures for any compressed (CO) header format, using the CRC verification. Depending on the frequency and/or on the type of the failure, it might send a negative acknowledgement (NACK) or an explicit request for a complete context update (STATIC-NACK). However, the decompressor does not have the means to identify the cause of the failure, and in particular the decompression of what field(s) is responsible for the failure. The compressor is thus always responsible for determining the most suitable response to a negative acknowledgement, using the confidence it has in the state of the decompressor context, when selecting the type of compressed header it will use when compressing a header.
減圧器には、CRC検証を使用して、圧縮（CO）ヘッダー形式の減圧障害を検出する手段があります。頻度および/または障害の種類に応じて、否定的な承認（NACK）または完全なコンテキストアップデート（静的ナック）の明示的な要求を送信する場合があります。ただし、減圧装置には、障害の原因を特定する手段、特に障害の原因となるフィールドの減圧がありません。したがって、コンプレッサーは、ヘッダーを圧縮するときに使用する圧縮ヘッダーのタイプを選択する際に、減圧器の状態で持っている信頼性を使用して、否定的な認識に対する最も適切な応答を決定する責任が常に責任を負います。
The decompressor normally uses the last received and successfully validated (IR packets) or verified (CO packets) header as the reference for future decompression.
減圧装置は通常、将来の減圧の参照として、最後に受信して正常に検証された（IRパケット）または検証（COパケット）ヘッダーを使用します。
The decompressor is responsible for verifying the outcome of every decompression attempt, to update its context when successful, and finally to request context repairs by making coherent usage of feedback once it has started using feedback.
減圧装置は、すべての減圧試行の結果を検証し、成功したときにコンテキストを更新し、最終的にフィードバックを使用し始めたら、フィードバックを一貫した使用してコンテキスト修理を要求する責任があります。
Specifically, the outcome of every decompression attempt is verified using the CRC present in the compressed header; the decompressor updates the context information when this outcome is successfully verified; finally, if the decompressor uses feedback once for a compressed flow, then it will continue to do so for as long as the corresponding context is associated with the same profile.
具体的には、すべての減圧試行の結果は、圧縮ヘッダーに存在するCRCを使用して検証されます。減圧器は、この結果が正常に検証されたときにコンテキスト情報を更新します。最後に、圧縮者が圧縮フローにフィードバックを1回使用する場合、対応するコンテキストが同じプロファイルに関連付けられている限り、それを続けます。
The decompressor operation may be represented as a state machine defining three states: No Context (NC), Repair Context (RC), and Full Context (FC).
減圧剤操作は、コンテキストなし（NC）、修復コンテキスト（RC）、および完全コンテキスト（FC）の3つの状態を定義する状態マシンとして表すことができます。
The decompressor starts without a valid context, the NC state. Upon receiving an IR packet, the decompressor validates the integrity of its header using the CRC-8 validation. If the IR header is successfully validated, the decompressor updates the context and uses this header as the reference header, and moves to the FC state. Once the decompressor state machine has entered the FC state, it does not normally leave; only repeated decompression failures will force the decompressor to transit downwards to a lower state. When context damage is detected, the decompressor moves to the repair context (RC) state, where it stays until it successfully verifies a decompression attempt for a compressed header with a 7-bit CRC or until it successfully validates an IR header. When static context damage is detected, the decompressor moves back to the NC state.
減圧器は、有効なコンテキストであるNC状態なしで開始します。IRパケットを受信すると、減圧器はCRC-8検証を使用してヘッダーの整合性を検証します。IRヘッダーが正常に検証されている場合、Decompressorはコンテキストを更新し、このヘッダーを参照ヘッダーとして使用し、FC状態に移動します。Decompressor StateマシンがFC状態に入ると、通常は離れません。繰り返される減圧の障害のみが、減圧装置が下方に下方に移動するように強制されます。コンテキストの損傷が検出されると、減圧器は修復コンテキスト（RC）状態に移動し、7ビットCRCを備えた圧縮ヘッダーの減圧試行を正常に検証するか、IRヘッダーを正常に検証するまで正常に検証するまで続きます。静的コンテキストの損傷が検出されると、減圧装置はNC状態に戻ります。
Below is the state machine for the decompressor. Details of the transitions between states and decompression logic are given in the sub-sections following the figure.
以下は、減圧器用の状態マシンです。状態と減圧ロジック間の遷移の詳細は、図に続くサブセクションに記載されています。
CRC-8(IR) Validation
+----->----->----->----->----->----->----->----->----->----->----+
| CRC-8(IR) |
| !CRC-8(IR) or CRC-7(CO) or or CRC-7(CO) |
| PT not allowed CRC-8(IR) or CRC-3(CO) |
| +--->---+ +--->----->----->----->---+ +--->---->---+ |
| | | | | | | |
| | v | v | v v
+-----------------+ +----------------------+ +--------------------+
| No Context (NC) | | Repair Context (RC) | | Full Context (FC) |
+-----------------+ +----------------------+ +--------------------+
^ ^ Static Context | ^ !CRC-7(CO) or | ^ Context Damage | |
| | Damage Detected | | PT not allowed | | Detected | |
| +--<-----<-----<--+ +----<------<----+ +--<-----<-----<--+ |
| |
| Static Context Damage Detected |
+--<-----<-----<-----<-----<-----<-----<-----<-----<---------+
where:
ただし：
CRC-8(IR) : Successful CRC-8 validation for the IR header. !CRC-8(IR) : Unsuccessful CRC-8 validation for the IR header. CRC-7(CO) and/or CRC-3(CO) : Successful CRC verification for the decompression of a CO header, based on the number of CRC bits carried in the CO header. !CRC-7(CO) : Failure to CRC verify the decompression of a CO header carrying a 7-bit CRC. PT not allowed : The decompressor has received a packet type (PT) for which the decompressor's current context does not provide enough valid state information to decompress the packet.
CRC-8（IR）：IRヘッダーのCRC-8検証の成功。！CRC-8（IR）：IRヘッダーのCRC-8検証の失敗。CRC-7（CO）および/またはCRC-3（CO）：COヘッダーに運ばれるCRCビットの数に基づいて、COヘッダーの減圧のためのCRC検証の成功。！CRC-7（CO）：CRCの失敗7ビットCRCを運ぶCOヘッダーの減圧を検証します。PT許可されていない：減圧装置は、packetsorの現在のコンテキストがパケットを解凍するのに十分な有効な状態情報を提供しないパケットタイプ（PT）を受け取りました。
Static Context Damage Detected: See definition in Section 5.2.2.
検出された静的コンテキストダメージ：セクション5.2.2の定義を参照してください。
Context Damage Detected: See definition in Section 5.2.2.
検出されたコンテキストダメージ：セクション5.2.2の定義を参照してください。
Initially, while working in the No Context (NC) state, the decompressor has not yet successfully validated an IR header.
当初、NOコンテキスト（NC）状態で作業している間、減圧装置はまだIRヘッダーの検証に成功していません。
Attempting decompression:
減圧の試み：
In the NC state, only packets carrying sufficient information on the static fields (i.e., IR packets) can be decompressed.
NC状態では、静的フィールド（つまり、IRパケット）に十分な情報を運ぶパケットのみを解凍できます。
Upward transition:
上向きの移行：
The decompressor can move to the Full Context (FC) state when the CRC validation of an 8-bit CRC in an IR header is successful.
減圧器は、IRヘッダーでの8ビットCRCのCRC検証が成功したときに、完全なコンテキスト（FC）状態に移動できます。
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 an IR header has failed the CRC-8 validation, subject to the feedback rate limitation as described in Section 5.2.3.
NC状態では、IR以外のタイプのパケットが受信された場合、またはIRヘッダーがCRC-8検証に失敗した場合、減圧器は静的ナックを送信する必要があります。3。
In the Repair Context (RC) state, the decompressor has successfully decompressed packets for this context, but does not have confidence that the entire context is valid.
修復コンテキスト（RC）状態では、減圧装置はこのコンテキストのためにパケットを首尾よく減圧しましたが、コンテキスト全体が有効であるという自信はありません。
Attempting decompression:
減圧の試み：
In the RC state, only headers covered by an 8-bit CRC (i.e., IR) or CO headers carrying a 7-bit CRC can be decompressed.
Upward transition:
上向きの移行：
The decompressor can move to the Full Context (FC) state when the CRC verification succeeds for a CO header carrying a 7-bit CRC or when validation of an 8-bit CRC in an IR header succeeds.
減圧器は、7ビットCRCを運ぶCOヘッダーのCRC検証が成功した場合、またはIRヘッダーでの8ビットCRCの検証が成功するときに、完全なコンテキスト（FC）状態に移動できます。
Downward transition:
下向きの移行：
The decompressor moves back to the NC state if it assumes static context damage.
減圧器は、静的なコンテキストダメージを想定している場合、NC状態に戻ります。
Feedback logic:
フィードバックロジック：
In the RC state, the decompressor should send a STATIC-NACK when CRC-8 validation of an IR header fails, or when a CO header carrying a 7-bit CRC fails and static context damage is assumed, subject to the feedback rate limitation as described in Section 5.2.3. If any other packet type is received, the decompressor should treat it as a CRC verification failure to determine if NACK is to be sent.
RC状態では、IRヘッダーのCRC-8検証が失敗した場合、または7ビットCRCを運ぶCOヘッダーが失敗し、フィードバックレートの制限を条件として、7ビットCRCを運ぶCOヘッダーが失敗し、静的コンテキストの損傷が想定される場合、減圧器は静的ナックを送信する必要があります。セクション5.2.3で説明されています。他のパケットタイプを受信した場合、減圧装置は、NACKを送信するかどうかを判断するためのCRC検証の失敗として扱う必要があります。
In the Full Context (FC) state, the decompressor assumes that its entire context is valid.
完全なコンテキスト（FC）状態では、減圧器はそのコンテキスト全体が有効であると想定しています。
Attempting decompression:
減圧の試み：
In the FC state, decompression can be attempted regardless of the type of packet received.
FC状態では、受信したパケットの種類に関係なく減圧を試みることができます。
Downward transition:
下向きの移行：
The decompressor moves back to the RC state if it assumes context damage. If the decompressor assumes static context damage, it moves directly to the NC state.
減圧器は、コンテキストの損傷を想定している場合、RC状態に戻ります。減圧器が静的コンテキストの損傷を想定している場合、NC状態に直接移動します。
Feedback logic:
フィードバックロジック：
In the FC state, the decompressor should send a NACK when CRC-8 validation or CRC verification of any header type fails and if context damage is assumed, or it should send a STATIC-NACK if static context damage is assumed; this is subject to the feedback rate limitation described in Section 5.2.3.
FC状態では、減圧器は、CRC-8検証またはヘッダータイプのCRC検証が失敗し、コンテキストの損傷が想定されている場合、または静的コンテキストのダメージが想定される場合は静的ナックを送信する必要があります。これは、セクション5.2.3で説明されているフィードバック率の制限の対象となります。
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 inferred from other fields).
すべてのヘッダー形式にはCRCがあり、コンテキストの更新です。CRCが成功するパケットは、すべてのヘッダーフィールドの参照値を更新します。
The decompressor may assume that some or the entire context is invalid, when it fails to validate or to verify one or more headers 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 specific part(s) of the context 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 decompression 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. Failure to validate the 3-bit CRC that protects control fields should be treated as a decompression failure when the decompressor asserts the validity of its context.
コンテキストの妥当性は、むしろ、コンテキストの問題の検出に関連しています。減圧装置は、最初に、障害を引き起こした可能性が最も高い情報のタイプが、通常、各パケットの変化、つまりコンテキストの動的部分のコンテキストダメージが変化する状態であることを前提としています。繰り返し減圧の障害と修理に失敗すると、減圧装置は、静的部分を含むコンテキスト全体を修復する必要があると想定しています。制御フィールドを保護する3ビットCRCを検証しないと、減圧装置がコンテキストの妥当性を主張する場合、減圧障害として扱われる必要があります。
Context Damage Detection
コンテキストダメージの検出
The assumption of context damage means that the decompressor will not attempt decompression of a CO header that carries only a 3-bit CRC, and will only attempt decompression of IR headers or CO headers protected by a CRC-7.
コンテキスト損傷の仮定は、減圧装置が3ビットCRCのみを搭載したCOヘッダーの減圧を試みず、CRC-7によって保護されたIRヘッダーまたは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 will attempt decompression. In other words, validity of the context refers to the ability of a decompressor to attempt (or not) decompression of specific packet types.
減圧器は、減圧を試みる圧縮ヘッダーのタイプを選択することにより、これらの仮定を実装します。言い換えれば、コンテキストの妥当性とは、特定のパケットタイプの減圧を試みる（またはしない）減圧装置の能力を指します。
When ROHCv2 profiles are used over a channel that cannot guarantee in-order delivery, the decompressor may refrain from updating its context with the content of a sequentially late packet that is successfully decompressed. This is to avoid updating the context with information that is older than what the decompressor already has in its context.
ROHCV2プロファイルが、順序の配信を保証できないチャネルで使用される場合、減圧装置は、うまく減圧された順次後期パケットのコンテンツとのコンテキストを更新することを控えることができます。これは、コンプレッサーがコンテキストに既に持っているものよりも古い情報でコンテキストを更新することを避けるためです。
ROHCv2 profiles may be used in environments with or without feedback capabilities from decompressor to compressor. ROHCv2 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 context, this channel will be used during the entire compression operation for that context (i.e., bidirectional operation).
ROHCV2プロファイルは、分解器からコンプレッサーへのフィードバック機能の有無にかかわらず環境で使用できます。ただし、ROHCV2は、ROHCフィードバックチャネルが利用可能であり、このチャネルが特定のコンテキストで減圧器によって少なくとも1回使用される場合、このコンテキストの圧縮操作全体（つまり、双方向操作）でこのチャネルが使用されると想定しています。
The ROHC framework defines 3 types of feedback messages: ACKs, NACKs, and STATIC-NACKs. The semantics of each message is defined in Section 5.2.4.1. of [RFC4995]. What feedback to send is coupled with the context management of the decompressor, i.e., with the implementation of the context damage detection algorithms as described in Section 5.2.2.
ROHCフレームワークは、ACK、NACK、および静的ナックの3種類のフィードバックメッセージを定義します。各メッセージのセマンティクスは、セクション5.2.4.1で定義されています。[RFC4995]。送信するフィードバックは、減圧器のコンテキスト管理、つまりセクション5.2.2で説明されているコンテキストダメージ検出アルゴリズムの実装と結びついています。
The decompressor should send a NACK when it assumes context damage, and it should send a STATIC-NACK when it assumes static context damage. The decompressor is not strictly expected to send ACK feedback upon successful decompression, other than for the purpose of improving compression efficiency.
減圧器は、コンテキストの損傷を想定したときにNACKを送信する必要があり、静的コンテキストのダメージを想定するときに静的ナックを送信する必要があります。減圧装置は、圧縮効率を改善する目的ではない場合、減圧の成功にACKフィードバックを送信すると厳密に期待されていません。
When ROHCv2 profiles are used over a channel that cannot guarantee in-order delivery, the decompressor may refrain from sending ACK feedback for a sequentially late packet that is successfully decompressed.
ROHCV2プロファイルが、注文の配信を保証できないチャネルで使用される場合、減圧装置は、正常に減圧された連続した遅いパケットのACKフィードバックを送信することを控えることができます。
The decompressor should limit the rate at which it sends feedback, for both ACKs and STATIC-NACK/NACKs, and should avoid sending unnecessary duplicates of the same type of feedback message that may be associated with the same event.
減圧装置は、ACKとStatic-Nack/Nackの両方に対してフィードバックを送信するレートを制限し、同じイベントに関連付けられる可能性のある同じタイプのフィードバックメッセージの不必要な複製を送信しないようにする必要があります。
The compressor MUST NOT use ROHC segmentation (see Section 5.2.5 of [RFC4995]), i.e., the Maximum Reconstructed Reception Unit (MRRU) MUST be set to 0, if the configuration of the ROHC channel contains at least one ROHCv2 profile in the list of supported profiles (i.e., the PROFILES parameter) and if the channel cannot guarantee in-order delivery of packets between compression endpoints.
コンプレッサーはROHCセグメンテーションを使用してはなりません（[RFC4995]のセクション5.2.5を参照）。つまり、ROHCチャネルの構成に少なくとも1つのROHCV2プロファイルが含まれている場合、最大再構築受信ユニット（MRRU）を0に設定する必要があります。サポートされているプロファイルのリスト（つまり、プロファイルパラメーター）と、チャネルが圧縮エンドポイント間のパケットの順序配信を保証できない場合。
ROHCv2 profiles operate differently, per context, depending on how the decompressor makes use of the feedback channel, if any. Once the decompressor uses the feedback channel for a context, it establishes the feedback channel for that CID.
ROHCV2プロファイルは、コンピューサーがフィードバックチャネルをどのように使用するかに応じて、コンテキストごとに異なる動作を行います。分解器がコンテキストにフィードバックチャネルを使用すると、そのCIDのフィードバックチャネルを確立します。
The compressor always starts with the assumption that the decompressor will not send feedback when it initializes a new context (see also the definition of a new context in Section 5.1.1. of [RFC4995], i.e., there is no established feedback channel for the new context. At this point, despite the use of the optimistic approach, decompression failure is still possible because the decompressor may not have received sufficient information to correctly decompress the packets; therefore, until the decompressor has established a feedback channel, the compressor SHOULD periodically send IR packets. The periodicity can be based on timeouts, on the number of compressed packets sent for the flow, or any other strategy the implementer chooses.
コンプレッサーは、新しいコンテキストを初期化するときに分解器がフィードバックを送信しないという仮定から常に始まります（[RFC4995]のセクション5.1.1。の新しいコンテキストの定義も参照してください。新しいコンテキスト。この時点で、楽観的なアプローチの使用にもかかわらず、減圧装置がパケットを正しく減圧するのに十分な情報を受け取っていない可能性があるため、減圧障害が依然として可能です。IRパケットを送信します。周期性は、フロー用に送信された圧縮パケットの数、または実装者が選択するその他の戦略に基づいて、タイムアウトに基づいています。
The reception of either positive feedback (ACKs) or negative feedback (NACKs or STATIC-NACKs) from the decompressor establishes the feedback channel for the context (CID) for which the feedback was received. Once there is an established feedback channel for a specific context, the compressor can make use of this feedback to estimate the current state of the decompressor. This helps to increase the compression efficiency by providing the information needed for the compressor to achieve the necessary confidence level. When the feedback channel is established, it becomes superfluous for the compressor to send periodic refreshes, and instead it can rely entirely on the optimistic approach and feedback from the decompressor.
分解器からの肯定的なフィードバック（ACK）またはネガティブフィードバック（NACKSまたは静的ナック）のいずれかを受信すると、フィードバックが受信されたコンテキスト（CID）のフィードバックチャネルが確立されます。特定のコンテキストのために確立されたフィードバックチャネルがあると、コンプレッサーはこのフィードバックを利用して、減圧器の現在の状態を推定できます。これにより、コンプレッサーが必要な信頼レベルを達成するために必要な情報を提供することにより、圧縮効率を向上させるのに役立ちます。フィードバックチャネルが確立されると、コンプレッサーが定期的なリフレッシュを送信することは余分になり、代わりに、偏光子からの楽観的なアプローチとフィードバックに完全に依存することができます。
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 or STATIC-NACKs) establishes this channel. Once it has established a feedback channel for a CID, the decompressor is REQUIRED to continue sending feedback for the lifetime of the context (i.e., until it receives an IR packet that associates the CID to a different profile), to send error recovery requests and (optionally) acknowledgments of significant context updates.
減圧装置は、特定のフローのフィードバックチャネルを最初に確立するために、肯定的なフィードバック（ACK）を送信する場合があります。正のフィードバック（ACK）またはネガティブフィードバック（NACKSまたは静的ナック）のいずれかがこのチャネルを確立します。CIDのフィードバックチャネルを確立したら、分解器はコンテキストの寿命のフィードバックを送信し続ける必要があります（つまり、CIDを別のプロファイルに関連付けるIRパケットを受信するまで）、エラー回復リクエストを送信し、（オプション）重要なコンテキスト更新の承認。
Compression without an established feedback channel will be less efficient, because of the periodic refreshes and the lack of feedback to trigger error recovery; there will also be a slightly higher probability of loss propagation compared to the case where the decompressor uses feedback.
確立されたフィードバックチャネルのない圧縮は、周期的な更新とエラー回復をトリガーするフィードバックの欠如のために、効率が低下します。また、減圧器がフィードバックを使用する場合と比較して、損失伝播の確率がわずかに高くなります。
ROHCv2 defines a number of control fields that are used by the decompressor in its interpretation of the header formats received from the compressor. The control fields listed in the following subsections are defined using the formal notation [RFC4997] in Section 6.8.2.4 of this document.
ROHCV2は、コンプレッサーから受信したヘッダー形式の解釈で減圧器が使用する多くの制御フィールドを定義します。次のサブセクションにリストされている制御フィールドは、このドキュメントのセクション6.8.2.4の正式な表記[RFC4997]を使用して定義されています。
The Master Sequence Number (MSN) field is either taken from a field that already exists in one of the headers of the protocol that the profile compresses (e.g., RTP SN), or alternatively it is created at the compressor. There is one MSN space per context.
マスターシーケンス番号（MSN）フィールドは、プロファイルが圧縮するプロトコルのヘッダーの1つに既に存在するフィールド（RTP SNなど）から取得されるか、またはコンプレッサーで作成されます。コンテキストごとに1つのMSNスペースがあります。
The MSN field has the following two functions:
MSNフィールドには、次の2つの機能があります。
o Differentiating between reference headers when receiving feedback data;
o フィードバックデータを受信するときの参照ヘッダーを区別します。
o Inferring the value of incrementing fields (e.g., IPv4 Identifier).
o インクリメントフィールドの値を推測します（例：IPv4識別子）。
There is one MSN field in every ROHCv2 header, i.e., the MSN is always present in each header type sent by the compressor. The MSN is sent in full in IR headers, while it can be lsb encoded within CO header formats. The decompressor always includes LSBs of the MSN in the Acknowledgment Number field in feedback (see Section 6.9). The compressor can later use this field to infer what packet the decompressor is acknowledging.
すべてのROHCV2ヘッダーに1つのMSNフィールドがあります。つまり、MSNは常にコンプレッサーによって送信された各ヘッダータイプに存在します。MSNはIRヘッダーで完全に送信されますが、COヘッダー形式内でLSBエンコードできます。減圧器には、フィードバックの確認番号フィールドにMSNのLSBが常に含まれます（セクション6.9を参照）。コンプレッサーは後でこのフィールドを使用して、分解器が認めているパケットを推測できます。
For profiles for which the MSN is created by the compressor (i.e., 0x0102, 0x0104, and 0x0108), the following applies:
MSNがコンプレッサーによって作成されるプロファイル（つまり、0x0102、0x0104、および0x0108）の場合、以下が適用されます。
o The compressor only initializes the MSN for a context when that context is first created or when the profile associated with a context changes;
o コンプレッサーは、そのコンテキストが最初に作成されたとき、またはコンテキストに関連付けられたプロファイルが変更されたときのコンテキストに対してのみMSNを初期化します。
o When the MSN is initialized, it is initialized to a random value;
o MSNが初期化されると、ランダム値に初期化されます。
o The value of the MSN SHOULD be incremented by one for each packet that the compressor sends for a specific CID.
o MSNの値は、コンプレッサーが特定のCIDに送信するパケットごとに1つずつ増加する必要があります。
The control field reorder_ratio specifies how much reordering is handled by the lsb encoding of the MSN. This is useful when header compression is performed over links with varying reordering characteristics. The reorder_ratio control field provides the means for the compressor to adjust the robustness characteristics of the lsb encoding method with respect to reordering and consecutive losses, as described in Section 5.1.2.
コントロールフィールドReorder_ratioは、MSNのLSBエンコードによって処理される並べ替えの量を指定します。これは、さまざまな並べ替え特性を備えたリンクでヘッダー圧縮が実行される場合に役立ちます。Reorder_ratioコントロールフィールドは、セクション5.1.2で説明されているように、コンプレッサーがLSBエンコーディング方法の堅牢性特性を再注文および連続した損失に関して調整する手段を提供します。
The IP-ID field of the IPv4 header can have different change patterns: sequential in network byte order, sequential byte-swapped, random or constant (a constant value of zero, although not conformant with [RFC0791], has been observed in practice). There is one IP-ID behavior control field per IP header. The control field for the IP-ID behavior of the innermost IP header determines which set of header formats is used. The IP-ID behavior control field is also used to determine the contents of the irregular chain item, for each IP header.
IPV4ヘッダーのIP-IDフィールドは、異なる変更パターンを持つことができます：ネットワークバイト順、シーケンシャルバイトスワップ、ランダムまたは定数（[RFC0791]に適合していないが、ゼロの一定値が実際に観察されています）が観察されています）。IPヘッダーごとに1つのIP-ID動作制御フィールドがあります。最も内側のIPヘッダーのIP-ID動作の制御フィールドは、どのヘッダー形式のセットが使用されるかを決定します。IP-IDの動作制御フィールドは、各IPヘッダーの不規則なチェーンアイテムの内容を決定するためにも使用されます。
ROHCv2 profiles MUST NOT assign a sequential behavior (network byte order or byte-swapped) to any IP-ID but the one in the innermost IP header when compressing more than one level of IP headers. This is because only the IP-ID of the innermost IP header is likely to have a sufficiently close correlation with the MSN to compress it as a sequentially changing field. Therefore, a compressor MUST assign either the constant zero IP-ID or the random IP-ID behavior to tunneling headers.
ROHCV2プロファイルは、複数のレベルのIPヘッダーを圧縮するときに、任意のIP-IDにシーケンシャル動作（ネットワークバイト順序またはバイトスワップ）を割り当ててはなりません。これは、最も内側のIPヘッダーのIP-IDのみが、MSNと十分に密接な相関があり、シーケンシャルに変化するフィールドとして圧縮する可能性が高いためです。したがって、コンプレッサーは、一定のゼロIP-IDまたはランダムIP-ID動作をトンネリングヘッダーに割り当てる必要があります。
The control field coverage_behavior specifies how the checksum coverage field of the UDP-Lite header is compressed with RoHCv2. It can indicate one of the following encoding methods: irregular, static, or inferred encoding.
制御フィールドカバレッジ_Behaviorは、UDP-LITEヘッダーのチェックサムカバレッジフィールドがROHCV2で圧縮される方法を指定します。次のエンコーディング方法のいずれかを示すことができます：不規則、静的、または推定されたエンコーディング。
The ts_stride control field is used in scaled RTP timestamp encoding (see Section 6.6.8). It defines the expected increase in the RTP timestamp between consecutive RTP sequence numbers.
TS_STRIDEコントロールフィールドは、スケーリングされたRTPタイムスタンプエンコードで使用されます（セクション6.6.8を参照）。連続したRTPシーケンス番号間のRTPタイムスタンプの予想される増加を定義します。
The time_stride control field is used in timer-based compression encoding (see Section 6.6.9). When timer-based compression is used, time_stride should be set to the expected difference in arrival time between consecutive RTP packets.
Time_Strideコントロールフィールドは、タイマーベースの圧縮エンコードで使用されます（セクション6.6.9を参照）。タイマーベースの圧縮を使用する場合、Time_Strideは、連続したRTPパケット間の到着時間の予想される差に設定する必要があります。
ROHCv2 profiles define a CRC-3 calculated over a number of control fields. This 3-bit CRC protecting the control fields is present in the header format for the co_common and co_repair header types.
ROHCV2プロファイルは、多くの制御フィールドで計算されたCRC-3を定義します。制御フィールドを保護するこの3ビットCRCは、CO_CommonおよびCO_Repairヘッダータイプのヘッダー形式に存在します。
The decompressor MUST always validate the integrity of the control fields covered by this 3-bit CRC when processing a co_common or a co_repair compressed header.
減圧器は、CO_CommonまたはCO_REPAIR圧縮ヘッダーを処理するときに、この3ビットCRCでカバーされている制御フィールドの整合性を常に検証する必要があります。
Failure to validate the control fields using this CRC should be considered as a decompression failure by the decompressor in the algorithm that assesses the validity of the context. However, if the decompression attempt can be verified using either the CRC-3 or the CRC-7 calculated over the uncompressed header, the decompressor MAY still forward the decompressed header to upper layers. This is because the protected control fields are not always used to decompress the header (i.e., co_common or co_repair) that updates their respective value.
このCRCを使用して制御フィールドを検証しないことは、コンテキストの妥当性を評価するアルゴリズムの減圧装置による減圧障害と見なす必要があります。ただし、非圧縮ヘッダーを介して計算されたCRC-3またはCRC-7のいずれかを使用して減圧試行を検証できる場合、減圧ヘッダーを上層層に転送する場合があります。これは、保護された制御フィールドが、それぞれの値を更新するヘッダー（つまり、CO_CommonまたはCo_repair）を減圧するために常に使用されているとは限らないためです。
The CRC polynomial and coverage of this CRC-3 is defined in Section 6.6.11.
このCRC-3のCRC多項式とカバレッジは、セクション6.6.11で定義されています。
Validation of the IR header (8-bit CRC)
IRヘッダーの検証（8ビットCRC）
The decompressor MUST always validate the integrity of the IR header using the 8-bit CRC carried within the IR header. When the header is validated, the decompressor updates the context with the information in the IR header. Otherwise, if the IR cannot be validated, the context MUST NOT be updated and the IR header MUST NOT be delivered to upper layers.
減圧器は、IRヘッダー内で運ばれる8ビットCRCを使用して、IRヘッダーの整合性を常に検証する必要があります。ヘッダーが検証されると、DecompressorはIRヘッダーの情報とコンテキストを更新します。それ以外の場合、IRを検証できない場合、コンテキストを更新する必要はなく、IRヘッダーを上層に配信してはなりません。
Verification of CO headers (3-bit CRC or 7-bit CRC)
COヘッダーの検証（3ビットCRCまたは7ビットCRC）
The decompressor MUST always verify the decompression of a CO header using the CRC carried within the compressed header. When the decompression is verified and successful, the decompressor updates the context with the information received in the CO header; otherwise, if the reconstructed header fails the CRC verification, these updates MUST NOT be performed.
減圧装置は、圧縮ヘッダー内で運ばれるCRCを使用して、COヘッダーの減圧を常に確認する必要があります。減圧が検証され成功すると、減圧装置はCOヘッダーで受け取った情報とコンテキストを更新します。それ以外の場合、再構築されたヘッダーがCRC検証に失敗した場合、これらの更新を実行する必要はありません。
A packet for which the decompression attempt cannot be verified using the CRC MUST NOT be delivered to upper layers.
CRCを使用して減圧試行を検証できないパケットを上層層に配信する必要はありません。
Decompressor implementations may attempt corrective or repair measures on CO headers prior to performing the above actions, and the result of any decompression attempt MUST be verified using the CRC.
減圧装置の実装は、上記のアクションを実行する前に、COヘッダーの是正または修復測定を試みる場合があり、減圧の試みの結果はCRCを使用して検証する必要があります。
Some header 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.
一部のヘッダータイプは、サブヘッダー情報を含む1つ以上のチェーンを使用します。チェーンの機能は、静的、動的、または不規則なフィールドなどの同様の特性に基づいてフィールドをグループ化することです。
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.
チェーンは、最も外側のヘッダーのフィールドから始まる、非圧縮パケットに外観の順に、各ヘッダーのアイテムをチェーンに追加することによって行われます。
In the text below, the term <protocol_name> is used to identify formal notation names corresponding to different protocol headers. The mapping between these is defined in the following table:
以下のテキストでは、<protocol_name>という用語を使用して、異なるプロトコルヘッダーに対応する正式な表記名を識別します。これらの間のマッピングは、次の表に定義されています。
+----------------------------------+---------------+
| Protocol | protocol_name |
+----------------------------------+---------------+
| IPv4 RFC 0791 | ipv4 |
| IPv6 RFC 2460 | ipv6 |
| UDP RFC 0768 | udp |
| RTP RFC 3550 | rtp |
| ESP RFC 4303 | esp |
| UDP-Lite RFC 3828 | udp_lite |
| AH RFC 4302 | ah |
| GRE RFC 2784, RFC 2890 | gre |
| MINE RFC 2004 | mine |
| IPv6 Destination Option RFC 2460 | dest_opt |
| IPv6 Hop-by-hop Options RFC 2460 | hop_opt |
| IPv6 Routing Header RFC 2460 | rout_opt |
+----------------------------------+---------------+
Static chain:
静的チェーン：
The static chain consists of one item for each header of the chain of protocol headers that is compressed, starting from the outermost IP header. In the formal description of the header formats, this static chain item for each header type is labeled <protocol_name>_static. The static chain is only used in the IR header format.
静的チェーンは、最も外側のIPヘッダーから始まる圧縮されたプロトコルヘッダーのチェーンの各ヘッダーの1つのアイテムで構成されています。ヘッダー形式の正式な説明では、各ヘッダータイプのこの静的チェーンアイテムには、<protocol_name> _staticというラベルが付けられています。静的チェーンは、IRヘッダー形式でのみ使用されます。
Dynamic chain:
ダイナミックチェーン：
The dynamic chain consists of one item for each header of the chain of protocol headers that is compressed, starting from the outermost IP header. In the formal description of the header formats, the dynamic chain item for each header type is labeled <protocol_name>_dynamic. The dynamic chain is only used in the IR and co_repair header formats.
動的チェーンは、最も外側のIPヘッダーから始まる圧縮されたプロトコルヘッダーのチェーンの各ヘッダーの1つのアイテムで構成されています。ヘッダー形式の正式な説明では、各ヘッダータイプの動的チェーンアイテムに<Protocol_Name> _Dynamicとラベル付けされています。動的チェーンは、IRおよびCO_REPAIRヘッダー形式でのみ使用されます。
Irregular chain:
不規則なチェーン：
The structure of the irregular chain is analogous to the structure of the static chain. For each compressed header that uses the general format of Section 6.8, the irregular chain is appended at a specific location in the general format of the compressed headers. In the formal description of the header formats, the irregular chain item for each header type is a format whose name is suffixed by "_irregular". The irregular chain is used in all CO headers, except for the co_repair format.
不規則な鎖の構造は、静的チェーンの構造に類似しています。セクション6.8の一般的な形式を使用する各圧縮ヘッダーについて、不規則なチェーンは、圧縮ヘッダーの一般的な形式の特定の場所に追加されます。ヘッダー形式の正式な説明では、各ヘッダータイプの不規則なチェーンアイテムは、「_ir Regular」によって名前が接尾辞される形式です。不規則なチェーンは、CO_REPAIR形式を除き、すべてのCOヘッダーで使用されます。
The format of the irregular chain for the innermost IP header differs from the format used for the outer IP headers, because the innermost IP header is part of the compressed base header. In the definition of the header formats using the formal notation, the argument "is_innermost", which is passed to the corresponding encoding method (ipv4 or ipv6), determines what irregular chain items to use. The format of the irregular chain item for the outer IP headers is also determined using one flag for TTL/Hop Limit and TOS/TC. This flag is defined in the format of some of the compressed base headers.
最も内側のIPヘッダーの最も内側のIPヘッダーの不規則なチェーンの形式は、最も内側のIPヘッダーが圧縮ベースヘッダーの一部であるため、外部IPヘッダーに使用される形式とは異なります。正式な表記を使用したヘッダー形式の定義では、対応するエンコード法（IPv4またはIPv6）に渡される引数「is_innermost」は、使用する不規則なチェーンアイテムを決定します。外側のIPヘッダーの不規則なチェーンアイテムの形式は、TTL/HOPリミットとTOS/TCの1つのフラグを使用して決定されます。このフラグは、圧縮ベースヘッダーの一部の形式で定義されています。
ROHCv2 profiles compress extension headers as other headers, and thus extension headers have a static chain, a dynamic chain, and an irregular chain.
ROHCV2プロファイルは、他のヘッダーとして拡張ヘッダーを圧縮するため、拡張ヘッダーには静的チェーン、動的チェーン、不規則なチェーンがあります。
ROHCv2 profiles define chains for all headers that can be compressed, i.e., RTP [RFC3550], UDP [RFC0768], ESP [RFC4303], UDP-Lite [RFC3828], IPv4 [RFC0791], IPv6 [RFC2460], AH [RFC4302], GRE [RFC2784][RFC2890], MINE [RFC2004], IPv6 Destination Options header [RFC2460], IPv6 Hop-by-hop Options header [RFC2460], and IPv6 Routing header [RFC2460].
ROHCV2プロファイルは、圧縮できるすべてのヘッダー、つまりRTP [RFC3550]、UDP [RFC0768]、ESP [RFC4303]、UDP-LITE [RFC3828]、IPV4 [RFC0791]、IPV6 [RFC2460]、、GRE [RFC2784] [RFC2890]、鉱山[RFC2004]、IPv6目的地オプションヘッダー[RFC2460]、IPv6ホップバイホップオプションヘッダー[RFC2460]、およびIPv6ルーティングヘッダー[RFC2460]。
The header formats are defined using the ROHC formal notation. Some of the encoding methods used in the header formats are defined in [RFC4997], while other methods are defined in this section.
ヘッダー形式は、ROHCフォーマル表記を使用して定義されます。ヘッダー形式で使用されるエンコードメソッドの一部は[RFC4997]で定義されていますが、このセクションでは他の方法が定義されています。
The baseheader_extension_headers encoding method skips over all fields of the extension headers of the innermost IP header, without encoding any of them. Fields in these extension headers are instead encoded in the irregular chain.
Baseheader_extension_headersエンコードメソッドは、それらのいずれをエンコードせずに、最も内側のIPヘッダーの拡張ヘッダーのすべてのフィールドをスキップします。これらの拡張ヘッダーのフィールドは、代わりに不規則なチェーンにエンコードされます。
This encoding is used in CO headers (see Section 6.8.2). The innermost IP header is combined with other header(s) (i.e., UDP, UDP-Lite, RTP) to create the compressed base header. In this case, there may be a number of extension headers between the IP headers and the other headers.
このエンコードは、COヘッダーで使用されます（セクション6.8.2を参照）。最も内側のIPヘッダーは、他のヘッダー（つまり、UDP、UDP-Lite、RTP）と組み合わされて、圧縮ベースヘッダーを作成します。この場合、IPヘッダーと他のヘッダーの間には多くの拡張ヘッダーがある場合があります。
The base header defines a representation of the extension headers, to comply with the syntax of the formal notation; this encoding method provides this representation.
ベースヘッダーは、正式な表記の構文を順守するために、拡張ヘッダーの表現を定義します。このエンコード方法は、この表現を提供します。
The baseheader_outer_headers encoding method skips over all the fields of the extension header(s) that do not belong to the innermost IP header, without encoding any of them. Changing fields in outer headers are instead handled by the irregular chain.
Baseheader_outer_headersエンコードメソッドは、それらのいずれもエンコードせずに、最も内側のIPヘッダーに属さない拡張ヘッダーのすべてのフィールドをスキップします。外側のヘッダーの変化するフィールドは、代わりに不規則なチェーンによって処理されます。
This encoding method, similarly to the baseheader_extension_headers encoding method above, is necessary to keep the definition of the header formats syntactically correct. It describes tunneling IP headers and their respective extension headers (i.e., all headers located before the innermost IP header) for CO headers (see Section 6.8.2).
このエンコードメソッドは、上記のBaseheader_extension_headersエンコードメソッドと同様に、ヘッダー形式の定義を構文的に正しく保つために必要です。COヘッダーのトンネルIPヘッダーとそれぞれの拡張ヘッダー（つまり、最も内側のIPヘッダーの前にあるすべてのヘッダー）について説明します（セクション6.8.2を参照）。
The decompressor infers the value of the UDP length field as being the sum of the UDP header length and the UDP payload length. The compressor must therefore ensure that the UDP length field is consistent with the length field(s) of preceding subheaders, i.e., there must not be any padding after the UDP payload that is covered by the IP Length.
減圧装置は、UDP長さフィールドの値をUDPヘッダー長とUDPペイロード長の合計として推測します。したがって、コンプレッサーは、UDPの長さフィールドが前のサブヘッダーの長さフィールドと一致することを確認する必要があります。つまり、UDPペイロード後にIPの長さでカバーされているパディングはありません。
This encoding method is also used for the UDP-Lite Checksum Coverage field when it behaves in the same manner as the UDP length field (i.e., when the checksum always covers the entire UDP-Lite payload).
このエンコード方法は、UDP長さのフィールドと同じ方法で動作する場合（つまり、チェックサムが常にUDP-Liteペイロード全体をカバーする場合）、UDP-Liteチェックサムカバレッジフィールドにも使用されます。
This encoding method compresses the header checksum field of the IPv4 header. This checksum is defined in RFC 791 [RFC0791] as follows:
このエンコードメソッドは、IPv4ヘッダーのヘッダーチェックサムフィールドを圧縮します。このチェックサムは、次のようにRFC 791 [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ビットすべての単語すべての補完合計の16ビットの補完です。チェックサムを計算するために、チェックサムフィールドの値はゼロです。
As described above, the header checksum protects individual hops from processing a corrupted header. As the data that this checksum protects is mostly compressed away and is instead taken from state stored in the context, this checksum becomes cumulative to the ROHC CRC. When using this encoding method, the checksum is recomputed by the decompressor.
上記のように、ヘッダーチェックサムは、個々のホップが破損したヘッダーの処理から保護します。このチェックサムが保護するデータはほとんど圧縮されており、代わりにコンテキストに保存されている状態から取られているため、このチェックサムはROHC CRCに累積的になります。このエンコード方法を使用する場合、チェックサムは減圧装置によって再計算されます。
The inferred_ip_v4_header_checksum encoding method thus compresses the header checksum field of the IPv4 header 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 computation above.
したがって、推測された_IP_VV4_HEADER_CHECKSUMエンコードメソッドは、IPv4ヘッダーのヘッダーチェックサムフィールドをゼロビットのサイズに圧縮します。つまり、このフィールドの圧縮ヘッダーにビットが送信されません。このエンコード方法を使用して、減圧器は上記の計算を使用してこのフィールドの値を推進します。
The compressor MAY use the header checksum to validate the correctness of the header before compressing it, to avoid processing a corrupted header.
コンプレッサーは、ヘッダーチェックサムを使用して、破損したヘッダーの処理を避けるために、圧縮する前にヘッダーの正しさを検証できます。
This encoding method compresses the minimal encapsulation header checksum. This checksum is defined in RFC 2004 [RFC2004] as follows:
このエンコードメソッドは、最小限のカプセル化ヘッダーチェックサムを圧縮します。このチェックサムは、次のようにRFC 2004 [RFC2004]で定義されています。
Header Checksum
ヘッダーチェックサム
The 16-bit one's complement of the one's complement sum of all 16-bit words in the minimal forwarding header. For purposes of computing the checksum, the value of the checksum field is 0. The IP header and IP payload (after the minimal forwarding header) are not included in this checksum computation.
最小転送ヘッダーのすべての16ビット語の補完合計を16ビットの補完。チェックサムを計算するために、チェックサムフィールドの値は0です。IPヘッダーとIPペイロード（最小転送ヘッダーの後）は、このチェックサム計算に含まれていません。
The inferred_mine_header_checksum encoding method compresses the minimal encapsulation header checksum down to a size of zero bits, i.e., no bits are transmitted in compressed headers for this field. Using this encoding method, the decompressor infers the value of this field using the above computation.
推測された_mine_header_checksumエンコードメソッドは、最小限のカプセル化ヘッダーチェックサムをゼロビットのサイズに圧縮します。つまり、このフィールドの圧縮ヘッダーにビットが送信されません。このエンコーディング方法を使用して、減圧器は上記の計算を使用してこのフィールドの値を推進します。
The motivations for inferring this checksum are similar to the ones explained above in Section 6.6.4.
The compressor MAY use the minimal encapsulation header checksum to validate the correctness of the header before compressing it, to avoid processing a corrupted header.
This encoding method compresses the total length field of the IPv4 header. The total length field of the IPv4 header is defined in RFC 791 [RFC0791] as follows:
このエンコードメソッドは、IPv4ヘッダーの総長さフィールドを圧縮します。IPv4ヘッダーの総長さフィールドは、次のようにRFC 791 [RFC0791]で定義されています。
Total Length: 16 bits
全長：16ビット
Total Length is the length of the datagram, measured in octets, including internet header and data. This field allows the length of a datagram to be up to 65,535 octets.
全長は、インターネットヘッダーやデータを含むオクテットで測定されたデータグラムの長さです。このフィールドにより、データグラムの長さを最大65,535オクテットにすることができます。
The inferred_ip_v4_length encoding method compresses the IPv4 header checksum down to a size of zero bits, i.e., no bits are transmitted in compressed headers for this field. Using this encoding method, the decompressor infers the value of this field by counting in octets the length of the entire packet after decompression.
推測された_IP_V4_Length Encodingメソッドは、IPv4ヘッダーチェックサムをゼロビットのサイズに圧縮します。つまり、このフィールドの圧縮ヘッダーにビットは送信されません。このエンコード方法を使用して、減圧装置は、減圧後のパケット全体の長さをオクテットでカウントすることにより、このフィールドの値を推進します。
This encoding method compresses the payload length field in the IPv6 header. This length field is defined in RFC 2460 [RFC2460] as follows:
このエンコードメソッドは、IPv6ヘッダーのペイロード長フィールドを圧縮します。この長さフィールドは、次のようにRFC 2460 [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, i.e., no bits are transmitted in compressed headers for this field. Using this encoding method, the decompressor infers the value of this field by counting in octets the length of the entire packet after decompression.
「amedred_ip_v6_length」エンコードメソッドは、IPv6ヘッダーのペイロード長フィールドをゼロビットのサイズに圧縮します。つまり、このフィールドの圧縮ヘッダーにビットは送信されません。このエンコード方法を使用して、減圧装置は、減圧後のパケット全体の長さをオクテットでカウントすることにより、このフィールドの値を推進します。
IPv6 headers using the jumbo payload option of RFC 2675 [RFC2675] will not be compressible with this encoding method since the value of the payload length field does not match the length of the packet.
RFC 2675 [RFC2675]のジャンボペイロードオプションを使用したIPv6ヘッダーは、ペイロード長さフィールドの値がパケットの長さと一致しないため、このエンコード方法で圧縮できません。
This section provides additional details on encodings used to scale the RTP timestamp, as defined in the formal notation in Section 6.8.2.4.
このセクションでは、セクション6.8.2.4の正式な表記で定義されているように、RTPタイムスタンプを拡大するために使用されるエンコーディングの追加の詳細を説明します。
The RTP timestamp (TS) usually increases by a multiple of the RTP Sequence Number's (SN's) increase and is therefore a suitable candidate for scaled encoding. This scaling factor is labeled ts_stride in the definition of the profile in the formal notation. The compressor sets the scaling factor based on the change in TS with respect to the change in the RTP SN.
RTPタイムスタンプ（TS）は通常、RTPシーケンス番号（SN）の増加の倍数によって増加するため、スケーリングされたエンコードに適した候補です。このスケーリング係数は、正式な表記のプロファイルの定義にTS_STRIDEとラベル付けされています。コンプレッサーは、RTP SNの変化に関するTSの変化に基づいてスケーリング係数を設定します。
The default value of the scaling factor ts_stride is 160, as defined in Section 6.8.2.4. To use a different value for ts_stride, the compressor explicitly updates the value of ts_stride to the decompressor using one of the header formats that can carry this information.
セクション6.8.2.4で定義されているように、スケーリング係数TS_STRIDEのデフォルト値は160です。TS_STRIDEに異なる値を使用するために、コンプレッサーは、この情報を運ぶことができるヘッダー形式のいずれかを使用して、TS_STRIDEの値をDecompressorに明示的に更新します。
When the compressor uses a scaling factor that is different than the default value of ts_stride, it can only use the new scaling factor once it has enough confidence that the decompressor has successfully calculated the residue (ts_offset) of the scaling function for the timestamp. The compressor achieves this by sending unscaled timestamp values, to allow the decompressor to establish the residue based on the current ts_stride. The compressor MAY send the unscaled timestamp in the same compressed header(s) used to establish the value of ts_stride.
コンプレッサーがTS_STRIDEのデフォルト値とは異なるスケーリング係数を使用する場合、減圧器がタイムスタンプのスケーリング関数の残基（TS_OFFSET）を正常に計算したことに十分な自信があると、新しいスケーリング係数を使用できます。コンプレッサーは、非衝撃的なタイムスタンプ値を送信することでこれを実現し、減圧器が現在のTS_STRIDEに基づいて残基を確立できるようにします。コンプレッサーは、TS_STRIDEの値を確立するために使用される同じ圧縮ヘッダーで、スケールのないタイムスタンプを送信する場合があります。
Once the compressor has gained enough confidence that both the value of the scaling factor and the value of the residue have been established in the decompressor, the compressor can start compressing packets using the new scaling factor.
コンプレッサーが、減圧器にスケーリング係数の値と残基の値の両方が確立されるという十分な信頼度を得ると、コンプレッサーは新しいスケーリング係数を使用してパケットを圧縮することができます。
When the compressor detects that the residue (ts_offset) value has changed, it MUST NOT select a compressed header format that uses the scaled timestamp encoding before it has re-established the residue as described above.
コンプレッサーが残基（TS_OFFSET）値が変更されたことを検出した場合、上記のように残基を再確立する前にスケーリングされたタイムスタンプエンコードを使用する圧縮ヘッダー形式を選択してはなりません。
When the value of the timestamp field wraps around, the value of the residue of the scaling function is likely to change. When this occurs, the compressor re-establishes the new residue value as described above.
タイムスタンプフィールドの値が包むと、スケーリング関数の残基の値が変化する可能性があります。これが発生すると、コンプレッサーは上記のように新しい残基値を再確立します。
If the decompressor receives a compressed header containing scaled timestamp bits while the ts_stride equals zero, it MUST NOT deliver the packet to upper layers and it SHOULD treat this as a CRC verification failure.
減圧器がスケーリングされたタイムスタンプビットを含む圧縮ヘッダーを受信している場合、TS_STRIDEがゼロに等しい場合、パケットを上層に配信してはなりません。これをCRC検証障害として扱う必要があります。
Whether or not the scaling is applied to the RTP TS field is up to the compressor implementation (i.e., the use of scaling is OPTIONAL), and is indicated by the tsc_indicator control field. In case scaling is applied to the RTP TS field, the value of ts_stride used by the compressor is up to the implementation. A value of ts_stride that is set to the expected increase in the RTP timestamp between consecutive unit increases of the RTP SN will provide the most gain for the scaled encoding. Other values may provide the same gain in some situations, but may reduce the gain in others.
スケーリングがRTP TSフィールドに適用されるかどうかは、コンプレッサーの実装（つまり、スケーリングの使用がオプション）に依存しており、TSC_indicatorコントロールフィールドによって示されます。スケーリングがRTP TSフィールドに適用される場合、コンプレッサーが使用するTS_STRIDEの値は実装次第です。RTP SNの連続したユニットの増加間のRTPタイムスタンプの予想される増加に設定されたTS_STRIDEの値は、スケーリングされたエンコードの最大のゲインを提供します。他の値は、一部の状況でも同じゲインを提供する場合がありますが、他の値では増加を減らす場合があります。
When scaled timestamp encoding is used for header formats that do not transmit any lsb-encoded timestamp bits at all, the inferred_scaled_field encoding of Section 6.6.10 is used for encoding the timestamp.
スケーリングされたタイムスタンプエンコーディングが、LSBエンコードされたタイムスタンプビットをまったく送信しないヘッダー形式に使用される場合、セクション6.6.10の推測_scaled_fieldエンコードは、タイムスタンプのエンコードに使用されます。
The timer-based compression encoding method, timer_based_lsb, compresses a field whose change pattern approximates a linear function of the time of day.
タイマーベースの圧縮エンコードメソッドであるTimer_based_lsbは、変更パターンが時刻の線形関数に近似するフィールドを圧縮します。
This encoding uses the local clock to obtain an approximation of the value that it encodes. The approximated value is then used as a reference value together with the num_lsbs_param least-significant bits received as the encoded value, where num_lsbs_param represents a number of bits that is sufficient to uniquely represent the encoded value in the presence of jitter between compression endpoints.
このエンコーディングは、ローカルクロックを使用して、エンコードする値の近似を取得します。近似値は、num_lsbs_paramがエンコードされた値として受信したnum_lsbs_paramの最小重要なビットとともに基準値として使用されます。ここで、num_lsbs_paramは、圧縮エンドポイント間のジッターの存在下でエンコードされた値を一意に表すのに十分な多くのビットを表します。
ts_scaled =:= timer_based_lsb(<time_stride_param>,
<num_lsbs_param>, <offset_param>)
The parameters "num_lsbs_param" and "offset_param" are the parameters to use for the lsb encoding, i.e., the number of least significant bits and the interpretation interval offset, respectively. The parameter "time_stride_param" represents the context value of the control field time_stride.
パラメーター「num_lsbs_param」と「offset_param」は、LSBエンコーディングに使用するパラメーター、つまり、それぞれ最も重要なビットの数と解釈間隔オフセットの数です。パラメーター「time_stride_param」は、制御フィールドtime_strideのコンテキスト値を表します。
This encoding method always uses a scaled version of the field it compresses.
このエンコードメソッドは、常に圧縮するフィールドのスケーリングバージョンを使用します。
The value of the field is decoded by calculating an approximation of the scaled value, using:
フィールドの値は、次のことを使用して、スケーリングされた値の近似を計算することによりデコードされます。
tsc_ref_advanced = tsc_ref + (a_n - a_ref) / time_stride.
tsc_ref_advanced = tsc_ref（a_n -a_ref） / time_stride。
where:
ただし：
- tsc_ref is a reference value of the scaled representation of the field. - a_n is the arrival time associated with the value to decode. - a_ref is the arrival time associated with the reference header. - tsc_ref_advanced is an approximation of the scaled value of the field.
- TSC_REFは、フィールドのスケーリングされた表現の基準値です。-A_Nは、デコードの値に関連付けられた到着時間です。-A_REFは、参照ヘッダーに関連付けられた到着時間です。-tsc_ref_advancedは、フィールドのスケーリング値の近似です。
The lsb encoding is then applied using the num_lsbs_param bits received in the compressed header and the tsc_ref_advanced as "ref_value" (as per Section 4.11.5 of [RFC4997]).
LSBエンコーディングは、圧縮ヘッダーで受信されたnum_lsbs_paramビットを使用して適用され、tsc_ref_advancedは「ref_value」として適用されます（[rfc4997]のセクション4.11.5に従って）。
Appendix B.3 provides an example of how the compressor can calculate jitter.
付録B.3は、コンプレッサーがジッターを計算する方法の例を示しています。
The control field time_stride controls whether or not the timer_based_lsb method is used in the CO header. The decompressor SHOULD send the CLOCK_RESOLUTION option with a zero value, if:
制御フィールドtime_strideは、COヘッダーでTimer_based_lsbメソッドが使用されているかどうかを制御します。Decompressorは、次の場合の場合、clock_resolutionオプションをゼロで送信する必要があります。
o it receives a non-zero time_stride value, and
o ゼロ以外のtime_stride値を受信します
o it has not previously sent a CLOCK_RESOLUTION feedback with a non-zero value.
o 以前にゼロ以外の値でClock_Resolutionフィードバックを送信したことはありません。
This is to allow compression to recover from the case where a compressor erroneously activates timer-based compression.
これは、コンプレッサーがタイマーベースの圧縮を誤ってアクティブにする場合から圧縮が回復できるようにするためです。
The support and usage of timer-based compression is OPTIONAL for both the compressor and the decompressor; the compressor is not required to set the time_stride control field to a non-zero value when it has received a non-zero value for the CLOCK_RESOLUTION option.
タイマーベースの圧縮のサポートと使用は、コンプレッサーと減圧器の両方でオプションです。コンプレッサーは、Clock_Resolutionオプションのゼロ以外の値を受信した場合、time_strideコントロールフィールドを非ゼロ値に設定する必要はありません。
The inferred_scaled_field encoding method encodes a field that is defined as changing in relation to the MSN, and for which the increase with respect to the MSN can be scaled by some scaling factor. This encoding method is used in compressed header formats that do not contain any bits for the scaled field. In this case, the decompressor infers the unscaled value of the scaled field from the MSN field. The unscaled value is calculated according to the following formula:
推測_Scaled_fieldエンコードメソッドは、MSNに関連して変更されると定義されるフィールドをエンコードし、MSNに対する増加はスケーリング係数によってスケーリングできます。このエンコード方法は、スケーリングされたフィールドのビットを含まない圧縮ヘッダー形式で使用されます。この場合、減圧装置はMSNフィールドからスケーリングされたフィールドの非衝突値を推進します。非衝突値は、次の式に従って計算されます。
unscaled_value = delta_msn * stride + reference_unscaled_value
where "delta_msn" is the difference in MSN between the reference value of the MSN in the context and the value of the MSN decompressed from this packet, "reference_unscaled_value" is the value of the field being scaled in the context, and "stride" is the scaling value for this field.
ここで、「delta_msn」は、コンテキストでのMSNの基準値とこのパケットから減圧されたMSNの値との間のMSNの違いです。このフィールドのスケーリング値。
For example, when this encoding method is applied to the RTP timestamp in the RTP profile, the calculation above becomes:
たとえば、このエンコード方法がRTPプロファイルのRTPタイムスタンプに適用されると、上記の計算は次のとおりです。
timestamp = delta_msn * ts_stride + reference_timestamp
The control_crc3_encoding method provides a CRC calculated over a number of control fields. The definition of this encoding method is the same as for the "crc" encoding method specified in Section 4.11.6 of [RFC4997], with the difference being that the data covered by the CRC is given by a concatenated list of control fields.
Control_CRC3_ENCODINGメソッドは、多くの制御フィールドで計算されたCRCを提供します。このエンコーディング方法の定義は、[RFC4997]のセクション4.11.6で指定された「CRC」エンコードメソッドと同じであり、違いは、CRCの対象となるデータが制御フィールドの連結リストで与えられることです。
In other words, the definition of the control_crc3_encoding method is equivalent to the following definition:
言い換えれば、control_crc3_encodingメソッドの定義は、次の定義と同等です。
control_crc_encoding(ctrl_data_value, ctrl_data_length)
{
UNCOMPRESSED {
}
COMPRESSED {
control_crc3 =:=
crc(3, 0x06, 0x07, ctrl_data_value, ctrl_data_length) [ 3 ];
}
}
where the parameter "ctrl_data_value" binds to the concatenated values of the following control fields, in the order listed below:
パラメーター「ctrl_data_value」が、以下の順序で、次の制御フィールドの連結値に結合します。
o reorder_ratio, 2 bits padded with 6 MSB of zeroes
o Reorder_ratio、6 MSBのゼロでパディングされた2ビット
o ts_stride, 32 bits (only for profiles 0x0101 and 0x0107)
o TS_STRIDE、32ビット（プロファイル0x0101および0x0107のみ）
o time_stride, 32 bits (only for profiles 0x0101 and 0x0107)
o time_stride、32ビット（プロファイル0x0101および0x0107のみ）
o msn, 16 bits (not applicable for profiles 0x0101, 0x0103, and 0x0107)
o MSN、16ビット（プロファイルに適用されない0x0101、0x0103、および0x0107）
o coverage_behavior, 2 bits padded with 6 MSB of zeroes (only for profiles 0x0107 and 0x0108)
o Coverage_Behavior、6 MSBのゼロでパディングされた2ビット（プロファイル0x0107および0x0108のみ）
o ip_id_behavior, one octet for each IP header in the compressible header chain starting from the outermost header. Each octet consists of 2 bits padded with 6 MSBs of zeroes.
o IP_ID_BEHAVIOR、最も外側のヘッダーから始まる圧縮性ヘッダーチェーンの各IPヘッダーに1つのオクテット。各オクテットは、6 MSBのゼロでパッド入りの2ビットで構成されています。
The "ctrl_data_length" binds to the sum of the length of the control field(s) that are applicable to the specific profile.
「ctrl_data_length」は、特定のプロファイルに適用可能な制御フィールドの長さの合計に結合します。
The decompressor uses the resulting 3-bit CRC to validate the control fields that are updated by the co_common and co_repair header formats; this CRC cannot be used to verify the outcome of a decompression attempt.
減圧装置は、結果の3ビットCRCを使用して、CO_CommonおよびCO_REPAIRヘッダー形式によって更新される制御フィールドを検証します。このCRCを使用して、減圧試行の結果を検証することはできません。
This CRC protects the update of control fields, as the updated values are not always used to decompress the header that carries them and thus are not protected by the CRC-7 verification. This prevents impairments that could occur if the decompression of a co_common or of a co_repair succeeds and the decompressor sends positive feedback, while for some reason the control fields are incorrectly updated.
このCRCは、更新された値が常にそれらを運ぶヘッダーを解凍するために使用されるとは限らないため、CRC-7検証によって保護されていないため、制御フィールドの更新を保護します。これにより、CO_COMMONまたはCO_REPAIRの減圧が成功し、減圧装置が肯定的なフィードバックを送信すると、何らかの理由で制御フィールドが誤って更新されます。
This encoding method is used with a sequential IP-ID behavior (sequential or sequential byte-swapped) and when there are no coded IP-ID bits in the compressed header. In this case, the IP-ID offset from the MSN is constant, and the IP-ID increases by the same amount as the MSN (similar to the inferred_scaled_field encoding method).
このエンコードメソッドは、シーケンシャルIP-IDの動作（シーケンシャルまたはシーケンシャルバイトスワップ）と、圧縮ヘッダーにコード化されたIP-IDビットがない場合に使用されます。この場合、MSNからのIP-IDオフセットは一定であり、IP-IDはMSNと同じ量だけ増加します（redred_scaled_fieldエンコードメソッドと同様）。
The decompressor calculates the value for the IP-ID according to the following formula:
減圧器は、次の式に従ってIP-IDの値を計算します。
IP-ID = delta_msn + reference_IP_ID_value
ip-id = delta_msn reference_ip_id_value
where "delta_msn" is the difference between the reference value of the MSN in the context and the uncompressed value of the MSN associated to the compressed header, and where "reference_IP_ID_value" is the value of the IP-ID in the context. For swapped IP-ID behavior (i.e., when ip_id_behavior_innermost is set to IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED), "reference_IP_ID_value" and "IP-ID" are byte-swapped with regard to the corresponding fields in the context.
ここで、「delta_msn」は、コンテキスト内のMSNの基準値と圧縮ヘッダーに関連付けられたMSNの非圧縮値の違いと、「参照_IP_ID_VALUE」はコンテキストのIP-IDの値です。交換されたIP-IDの動作（つまり、IP_ID_BEHAVIOR_INNERのMOSTがIP_ID_BEHAVIOR_SEQUESTINE_SWAPPIPTに設定されている場合）の場合、「参照_IP_ID_VALUE」と「IP-ID」は、コンテキストの対応するフィールドに関してバイトスワップされます。
If the IP-ID behavior is random or zero, this encoding method does not update any fields.
IP-IDの動作がランダムまたはゼロの場合、このエンコード方法はフィールドを更新しません。
This encoding method compresses the list of RTP CSRC identifiers using list compression. This encoding establishes a content for the different CSRC identifiers (items) and a list describing the order in which they appear.
このエンコードメソッドは、リスト圧縮を使用してRTP CSRC識別子のリストを圧縮します。このエンコードは、異なるCSRC識別子（アイテム）のコンテンツと、それらが表示される順序を説明するリストを確立します。
The compressor passes an argument (cc_value) to this encoding method: this is the value of the CC field taken from the RTP header. The decompressor is required to bind the value of this argument to the number of items in the list, which will allow the decompressor to correctly reconstruct the CC field.
コンプレッサーは、このエンコード方法に引数（CC_Value）を渡します。これは、RTPヘッダーから取得したCCフィールドの値です。減圧装置は、この引数の値をリスト内のアイテムの数にバインドする必要があります。これにより、DecompressorはCCフィールドを正しく再構築できます。
The CSRC identifiers 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:
非圧縮パケットのCSRC識別子は、順序付けリストとして表すことができ、その順序と存在は通常パケット間で一定です。このようなリストの一般的な構造は次のとおりです。
+--------+--------+--...--+--------+
list: | item 1 | item 2 | | item n |
+--------+--------+--...--+--------+
When performing list compression on a CSRC list, each item is the uncompressed value of one CSRC identifier.
CSRCリストでリスト圧縮を実行する場合、各アイテムは1つのCSRC識別子の非圧縮値です。
The basic principles of list-based compression are the following:
リストベースの圧縮の基本原則は次のとおりです。
When initializing the context:
コンテキストを初期化するとき：
1) The complete representation of the list of CSRC identifiers is transmitted.
1) CSRC識別子のリストの完全な表現が送信されます。
Then, once the context has been initialized:
次に、コンテキストが初期化されたら：
2) When the list is unchanged, a compressed header that does not contain information about the list can be used.
2) リストが変更されていない場合、リストに関する情報が含まれていない圧縮ヘッダーを使用できます。
3) When the list changes, a compressed list is sent in the compressed header, including a representation of its structure and order. Previously unknown items are sent uncompressed in the list, while previously known items are only represented by an index pointing to the item stored in the context.
3) リストが変更されると、その構造と順序の表現など、圧縮リストが圧縮ヘッダーに送信されます。以前は不明なアイテムはリストで圧縮されていませんが、以前は既知のアイテムは、コンテキストに保存されているアイテムを指すインデックスのみで表されます。
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 reset its item table upon receiving a negative acknowledgement.
コンプレッサーは、否定的な認識を受け取ったときにアイテムテーブルをリセットすることができます。
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 successful (CRC verification, or CRC-8 validation). The decompressor retrieves the item from the table whenever an Index is received without an accompanying Item.
Decompressorは、受信したすべての（インデックス、アイテム）ペアを含むアイテムテーブルを概念的に維持します。アイテムテーブルは、（インデックス、アイテム）ペアが受信され、減圧が成功するたびに更新されます（CRC検証、またはCRC-8検証）。減圧装置は、付随するアイテムなしでインデックスを受信するたびにテーブルからアイテムを取得します。
If an index is received without an accompanying Item and the decompressor does not have any context for this index, the decompressor MUST NOT deliver the packet to upper layers.
添付のアイテムなしでインデックスが受信され、減圧装置にこのインデックスのコンテキストがない場合、分解器はパケットを上層に配信してはなりません。
Each item present in a compressed list is represented by:
圧縮リストに存在する各アイテムは、次のように表されます。
o an Index into the table of items, and 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 アイテム（存在ビットが設定されている場合）。
If the presence bit is not set, the item must already be known by the decompressor.
存在ビットが設定されていない場合、アイテムは減圧装置によって既に既に既に知られている必要があります。
A compressed list of items uses the following encoding:
アイテムの圧縮リストは、次のエンコードを使用します。
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. Also, the value of the cc_value argument of the list_csrc encoding (see Section 6.6.13).
M：圧縮リストのXIアイテムの数。また、list_csrcエンコーディングのcc_value引数の値（セクション6.6.13を参照）。
XI_1, ..., XI_m: m XI items. Each XI represents one item in the list of items of the uncompressed header, in the same order as they appear in the uncompressed header.
xi_1、...、xi_m：m xiアイテム。各XIは、非圧縮ヘッダーのアイテムのリストにある1つのアイテムを、非圧縮ヘッダーに表示するのと同じ順序で表します。
The format of an XI item is as follows:
XIアイテムの形式は次のとおりです。
0 1 2 3
+---+---+---+---+
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 listで送信されることを示します。
X = 0 indicates that the item corresponding to the Index is not sent.
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.6.13.4
インデックス：アイテムテーブルへのインデックス。セクション6.6.13.4を参照してください
When 4-bit XI items are used, the XI items are placed in octets in the following manner:
4ビットXIアイテムを使用すると、XIアイテムは次の方法でオクテットに配置されます。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| XI_k | XI_k + 1 |
+---+---+---+---+---+---+---+---+
Padding: A 4-bit Padding field is present when PS = 0 and the number of XIs is odd. The Padding field MUST be set to zero; otherwise, the decompressor MUST discard the packet.
パディング：PS = 0で、XISの数が奇妙な場合、4ビットパディングフィールドが存在します。パディングフィールドはゼロに設定する必要があります。それ以外の場合、減圧器はパケットを破棄する必要があります。
Item 1, ..., item n: Each item corresponds to an XI with X = 1 in XI 1, ..., XI m. Each entry in the Item list is the uncompressed representation of one CSRC identifier.
項目1、...、アイテムN：各アイテムは、xi 1、...、xi mのx = 1のxiに対応します。アイテムリストの各エントリは、1つのCSRC識別子の非圧縮表現です。
The item table for list compression is limited to 16 different items, since the RTP header can only carry at most 15 simultaneous CSRC identifiers. The effect of having more than 16 items in the item table will only cause a slight overhead to the compressor when items are swapped in/out of the item table.
RTPヘッダーは最大15の同時CSRC識別子しか持ち運べないため、リスト圧縮のアイテムテーブルは16の異なるアイテムに制限されています。アイテムテーブルに16個以上のアイテムを持っていることの効果は、アイテムがアイテムテーブルに入れ込まれたり外に交換されたりしたときに、コンプレッサーのわずかなオーバーヘッドを引き起こすだけです。
A compressed list that is part of the dynamic chain must have all of its list items present, i.e., all X-bits in the XI list MUST be set. All items previously established in the item table that are not present in the list decompressed from this packet MUST also be retained in the decompressor context.
動的チェーンの一部である圧縮リストには、すべてのリスト項目が存在する必要があります。つまり、XIリスト内のすべてのXビットを設定する必要があります。このパケットから減圧されたリストに存在していなかったアイテムテーブルに以前に確立されたすべてのアイテムも、減圧器のコンテキストで保持する必要があります。
A number of encoding methods in Section 6.8.2.4 have one or more arguments for which the derivation of the parameter's value is outside the scope of the ROHC-FN [RFC4997] specification of the header formats.
セクション6.8.2.4の多くのエンコーディングメソッドには、パラメーターの値の導出がROHC-FN [RFC4997]の指定の範囲外である1つ以上の引数があります。
The following is a list of encoding methods with external parameters as arguments, from Section 6.8.2.4:
以下は、セクション6.8.2.4からの引数としての外部パラメーターを使用したエンコード方法のリストです。
o udp(profile_value, reorder_ratio_value)
o udp（profile_value、Reorder_ratio_value）
o udp_lite(profile_value, reorder_ratio_value, coverage_behavior_value)
o udp_lite（profile_value、redory_ratio_value、coverage_behavior_value）
o esp(profile_value, reorder_ratio_value)
o esp（profile_value、redoride_ratio_value）
o rtp(profile_value, ts_stride_value, time_stride_value, reorder_ratio_value)
o rtp（profile_value、ts_stride_value、time_stride_value、Reorder_ratio_value）
o ipv4(profile_value, is_innermost, outer_ip_flag, ip_id_behavior_value, reorder_ratio_value))
o ipv4（profile_value、is_innermost、outer_ip_flag、ip_id_behavior_value、reoder_ratio_value）））
o ipv6(profile_value, is_innermost, outer_ip_flag, reorder_ratio_value))
o ipv6（profile_value、is_innermost、outer_ip_flag、reoder_ratio_value）））
o iponly_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value, reorder_ratio_value)
o iponly_baseheader（profile_value、auter_ip_flag、ip_id_behavior_value、redord_ratio_value）
o udp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value, reorder_ratio_value)
o udp_baseheader（profile_value、auter_ip_flag、ip_id_behavior_value、redory_ratio_value）
o udplite_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value, reorder_ratio_value)
o udplite_baseheader（profile_value、auter_ip_flag、ip_id_behavior_value、redory_ratio_value）
o esp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value, reorder_ratio_value)
o esp_baseheader（profile_value、outer_ip_flag、ip_id_behavior_value、redor_ratio_value）
o rtp_baseheader(profile_value, ts_stride_value, time_stride_value, outer_ip_flag, ip_id_behavior_value, reorder_ratio_value)
o rtp_baseheader（profile_value、ts_stride_value、time_stride_value、outer_ip_flag、ip_id_behavior_value、reoder_ratio_value）
o udplite_rtp_baseheader(profile_value, ts_stride_value, time_stride_value, outer_ip_flag, ip_id_behavior_value, reorder_ratio_value, coverage_behavior_value)
o udplite_rtp_baseheader（profile_value、ts_stride_value、time_stride_value、outer_ip_flag、ip_id_behavior_value、remoord_ratio_value、coverage_behavior_value）
The following applies for all parameters listed below: At the compressor, the value of the parameter is set according to the recommendations for each parameter. At the decompressor, the value of the parameter is set to undefined and will get bound by encoding methods, except where otherwise noted.
以下は、以下のすべてのパラメーターに適用されます。コンプレッサーでは、各パラメーターの推奨事項に従ってパラメーターの値が設定されます。減圧器では、パラメーターの値は未定義に設定されており、特に明記している場合を除き、エンコードメソッドに拘束されます。
The following is a list of external arguments with their respective definition:
以下は、それぞれの定義を備えた外部引数のリストです。
o profile_value:
o profile_value：
Set to the 16-bit number that identifies the profile used to compress this packet. When processing the static chain at the decompressor, this parameter is set to the value of the profile field in the IR header (see Section 6.8.1).
このパケットを圧縮するために使用されるプロファイルを識別する16ビット番号に設定します。Decompressorで静的チェーンを処理する場合、このパラメーターはIRヘッダーのプロファイルフィールドの値に設定されます（セクション6.8.1を参照）。
o reorder_ratio_value:
o Reorder_ratio_value：
Set to a 2-bit integer value, using one of the constants whose name begins with the prefix REORDERING_ and as defined in Section 6.8.2.4.
2ビットの整数値に設定され、名前がプレフィックスReordering_で始まり、セクション6.8.2.4で定義されている定数の1つを使用します。
o ip_id_behavior_value:
o 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 6.8.2.4.
名前がプレフィックスIP_ID_BEHAVIOR_で始まり、セクション6.8.2.4で定義されている定数の1つを使用して、2ビット整数値に設定します。
o coverage_behavior_value:
o coverage_behavior_value：
Set to a 2-bit integer value, using one of the constants whose name begins with the prefix UDP_LITE_COVERAGE_ and as defined in Section 6.8.2.4.
2ビット整数値に設定され、名前がプレフィックスudp_lite_coverage_で始まり、セクション6.8.2.4で定義されている定数の1つを使用します。
o outer_ip_flag:
o outer_ip_flag：
This parameter is set to 1 if at least one of the TOS/TC or TTL/Hop Limit fields in outer IP headers has changed compared to their reference values in the context; otherwise, it is set to 0. This flag may only be set to 1 for the "co_common" header format in the different profiles.
このパラメーターは、外側IPヘッダーのTOS/TCまたはTTL/HOPリミットフィールドの少なくとも1つがコンテキストの参照値と比較して変更された場合、1に設定されています。それ以外の場合は、0に設定されています。このフラグは、さまざまなプロファイルの「Co_Common」ヘッダー形式でのみ1に設定できます。
o is_innermost:
o is_innermost：
This boolean flag is set to 1 when processing the innermost of the compressible IP headers; otherwise, it is set to 0.
このブールフラグは、圧縮性IPヘッダーの最も内側を処理するときに1に設定されています。それ以外の場合は、0に設定されています。
o ts_stride_value
o TS_STRIDE_VALUE
The value of this parameter should be set to the expected increase in the RTP Timestamp between consecutive RTP sequence numbers. The value selected is implementation-specific. See also Section 6.6.8.
このパラメーターの値は、連続したRTPシーケンス番号の間のRTPタイムスタンプの予想される増加に設定する必要があります。選択された値は実装固有です。セクション6.6.8も参照してください。
o time_stride_value
o time_stride_value
The value of this parameter should be set to the expected inter-arrival time between consecutive packets for the flow. The value selected is implementation-specific. This parameter MUST be set to zero, unless the compressor has received a feedback message with the CLOCK_RESOLUTION option set to a non-zero value. See also Section 6.6.9.
このパラメーターの値は、フローの連続パケット間の予想される到着間時間に設定する必要があります。選択された値は実装固有です。コンプレッサーがゼロ以外の値に設定されたClock_Resolutionオプションを使用してフィードバックメッセージを受信していない限り、このパラメーターをゼロに設定する必要があります。セクション6.6.9も参照してください。
ROHCv2 profiles use two different header types: the Initialization and Refresh (IR) header type, and the Compressed header type (CO).
ROHCV2プロファイルは、初期化と更新（IR）ヘッダータイプ、および圧縮ヘッダータイプ（CO）の2つの異なるヘッダータイプを使用します。
The CO header type defines a number of header formats: there are two sets of base header formats, with a few additional formats that are common to both sets.
COヘッダータイプは、多くのヘッダー形式を定義します。ベースヘッダー形式の2つのセットがあり、両方のセットに共通するいくつかの追加形式があります。
The IR header format uses the structure of the ROHC IR header as defined in Section 5.2.2.1 of [RFC4995].
IRヘッダー形式は、[RFC4995]のセクション5.2.2.1で定義されているROHC IRヘッダーの構造を使用します。
Header type: IR
ヘッダータイプ：IR
This header format communicates the static part and the dynamic part of the context.
このヘッダー形式は、コンテキストの静的部分と動的部分を伝えます。
The ROHCv2 IR header has the following format:
ROHCV2 IRヘッダーには次の形式があります。
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 1 | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Static chain / variable length
| |
- - - - - - - - - - - - - - - -
| |
/ Dynamic chain / variable length
| |
- - - - - - - - - - - - - - - -
CRC: 8-bit CRC over the entire IR-header, including any CID fields and up until the end of the dynamic chain, using the polynomial defined in [RFC4995]. For purposes of computing the CRC, the CRC field is zero.
CRC：[RFC4995]で定義された多項式を使用して、動的チェーンの終わりまで、CIDフィールドを含むIR-Header全体で8ビットCRC。CRCを計算するために、CRCフィールドはゼロです。
Static chain: See Section 6.5.
静的チェーン：セクション6.5を参照してください。
Dynamic chain: See Section 6.5.
動的チェーン：セクション6.5を参照してください。
The compressed header formats are defined as two separate sets for each profile: one set for the headers where the innermost IP header contains a sequential IP-ID (either network byte order or byte-swapped), and one set for the headers without sequential IP-ID (either random, zero, or no IP-ID). There are also a number of common header formats shared between both sets. In the description below, the naming convention used for header formats that belong to the sequential set is to include "seq" in the name of the format, while similarly "rnd" is used for those that belong to the non-sequential set.
圧縮ヘッダー形式は、各プロファイルの2つの個別のセットとして定義されます。最も内側のIPヘッダーにシーケンシャルIP-ID（ネットワークバイト順序またはバイトスワップ）が含まれるヘッダーの1つ、およびシーケンシャルIPなしのヘッダーの1つのセット-id（ランダム、ゼロ、またはIP-IDなし）。また、両方のセット間で共有される多くの一般的なヘッダー形式もあります。以下の説明では、シーケンシャルセットに属するヘッダー形式に使用される命名規則は、形式の名前に「seq」を含めることであり、同様に「rnd」は非シーケンシャルセットに属するものに使用されます。
The design of the header formats is derived from the field behavior analysis found in Appendix A.
ヘッダー形式の設計は、付録Aに見られるフィールドの動作分析から派生しています。
All of the compressed base headers transmit lsb-encoded MSN bits and a CRC.
すべての圧縮ベースヘッダーは、LSBエンコードされたMSNビットとCRCを送信します。
The following header formats exist for all profiles defined in this document, and are common to both the sequential and the random header format sets:
次のヘッダー形式は、このドキュメントで定義されているすべてのプロファイルに存在し、シーケンシャルとランダムヘッダー形式の両方のセットに共通しています。
o co_common: This format can be used to update the context when the established change pattern of a dynamic field changes, for any of the dynamic fields. However, not all dynamic fields are updated by conveying their uncompressed value; some fields can only be transmitted using a compressed representation. This format is especially useful when a rarely changing field needs to be updated. This format contains a set of flags to indicate what fields are present in the header, and its size can vary accordingly. This format is protected by a 7-bit CRC. It can update control fields, and it thus also carries a 3-bit CRC to protect those fields. This format is similar in purpose to the UOR-2-extension 3 format of [RFC3095].
o CO_Common：この形式は、動的フィールドの確立された変更パターンが動的フィールドを変更するときにコンテキストを更新するために使用できます。ただし、すべての動的フィールドが非圧縮値を伝えることで更新されるわけではありません。一部のフィールドは、圧縮表現を使用してのみ送信できます。この形式は、めったに変化するフィールドを更新する必要がある場合に特に役立ちます。この形式には、ヘッダーに存在するフィールドを示すフラグのセットが含まれており、そのサイズはそれに応じて異なる場合があります。この形式は、7ビットCRCによって保護されています。制御フィールドを更新できるため、これらのフィールドを保護するために3ビットCRCも搭載されています。この形式は、[RFC3095]のUOR-2-Extension 3形式に目的が類似しています。
o co_repair: This format can be used to update the context of all the dynamic fields by conveying their uncompressed value. This is especially useful when context damage is assumed (e.g., from the reception of a NACK) and a context repair is performed. This format is protected by a 7-bit CRC. It also carries a 3-bit CRC over the control fields that it can update. This format is similar in purpose to the IR-DYN format of [RFC3095] when performing context repairs.
o CO_REPAIR：この形式を使用して、非圧縮値を伝えることにより、すべての動的フィールドのコンテキストを更新できます。これは、コンテキストの損傷が想定されている場合（たとえば、NACKの受信から）、コンテキストの修復が実行される場合に特に役立ちます。この形式は、7ビットCRCによって保護されています。また、更新できる制御フィールド上に3ビットCRCを運びます。この形式は、コンテキスト修理を実行する際の[RFC3095]のIR-Dyn形式と目的が類似しています。
o pt_0_crc3: This format conveys only the MSN; it can therefore only update the MSN and fields that are derived from the MSN, such as IP-ID and the RTP Timestamp (for applicable profiles). It is protected by a 3-bit CRC. This format is equivalent to the UO-0 header format in [RFC3095].
o PT_0_CRC3：この形式はMSNのみを伝達します。したがって、IP-IDやRTPタイムスタンプ（該当するプロファイル用）など、MSNから派生したMSNおよびフィールドのみを更新できます。3ビットCRCによって保護されています。この形式は、[RFC3095]のUO-0ヘッダー形式に相当します。
o pt_0_crc7: This format has the same properties as pt_0_crc3, but is instead protected by a 7-bit CRC and contains a larger amount of lsb-encoded MSN bits. This format is useful in environments where a high amount of reordering or a high-residual error rate can occur.
o PT_0_CRC7：この形式はPT_0_CRC3と同じプロパティを持っていますが、代わりに7ビットCRCによって保護されており、LSBエンコードされたMSNビットが大量に含まれています。この形式は、大量の並べ替えまたは高抵抗性エラー率が発生する環境で有用です。
The following header format descriptions apply to profiles 0x0101 and 0x0107.
次のヘッダー形式の説明は、プロファイル0x0101および0x0107に適用されます。
o pt_1_rnd: This format can convey changes to the MSN and to the RTP Marker bit, and it can update the RTP timestamp using scaled timestamp encoding. It is protected by a 3-bit CRC. It is similar in purpose to the UO-1 format in [RFC3095].
o PT_1_RND：この形式は、変更をMSNおよびRTPマーカービットに伝えることができ、スケーリングされたタイムスタンプエンコードを使用してRTPタイムスタンプを更新できます。3ビットCRCによって保護されています。[RFC3095]のUO-1形式と目的が類似しています。
o pt_1_seq_id: This format can convey changes to the MSN and to the IP-ID. It is protected by a 3-bit CRC. It is similar in purpose to the UO-1-ID format in [RFC3095].
o PT_1_SEQ_ID：この形式は、MSNとIP-IDに変更を伝えることができます。3ビットCRCによって保護されています。[RFC3095]のUO-1-ID形式と目的が類似しています。
o pt_1_seq_ts: This format can convey changes to the MSN and to the RTP Marker bit, and it can update the RTP Timestamp using scaled timestamp encoding. It is protected by a 3-bit CRC. It is similar in purpose to the UO-1-TS format in [RFC3095].
o PT_1_SEQ_TS：この形式は、MSNおよびRTPマーカービットへの変更を伝達することができ、スケーリングされたタイムスタンプエンコードを使用してRTPタイムスタンプを更新できます。3ビットCRCによって保護されています。[RFC3095]のUO-1-TS形式と目的が類似しています。
o pt_2_rnd: This format can convey changes to the MSN, to the RTP Marker bit, and to the RTP Timestamp. It is protected by a 7-bit CRC. It is similar in purpose to the UOR-2 format in [RFC3095].
o PT_2_RND：この形式は、MSN、RTPマーカービット、およびRTPタイムスタンプに変更を伝えることができます。7ビットCRCによって保護されています。[RFC3095]のUOR-2形式と目的が類似しています。
o pt_2_seq_id: This format can convey changes to the MSN and to the IP-ID. It is protected by a 7-bit CRC. It is similar in purpose to the UO-2-ID format in [RFC3095].
o PT_2_SEQ_ID：この形式は、MSNとIP-IDに変更を伝えることができます。7ビットCRCによって保護されています。[RFC3095]のUO-2-ID形式と目的が類似しています。
o pt_2_seq_ts: This format can convey changes to the MSN, to the RTP Marker bit and it can update the RTP Timestamp using scaled timestamp encoding. It is protected by a 7-bit CRC. It is similar in purpose to the UO-2-TS format in [RFC3095].
o PT_2_SEQ_TS：この形式は、MSNの変更をRTPマーカービットに伝え、スケーリングされたタイムスタンプエンコードを使用してRTPタイムスタンプを更新できます。7ビットCRCによって保護されています。[RFC3095]のUO-2-TS形式と目的が類似しています。
o pt_2_seq_both: This format can convey changes to both the RTP Timestamp and the IP-ID, in addition to the MSN and to the Marker bit. It is protected by a 7-bit CRC. It is similar in purpose to the UOR-2-ID extension 1 format in [RFC3095].
o PT_2_SEQ_BOTH：この形式は、MSNとマーカービットに加えて、RTPタイムスタンプとIP-IDの両方に変更を伝えることができます。7ビットCRCによって保護されています。[RFC3095]のUOR-2-ID拡張1形式と目的が類似しています。
The following header format descriptions apply to profiles 0x0102, 0x0103, 0x0104, and 0x0108.
次のヘッダー形式の説明は、プロファイル0x0102、0x0103、0x0104、および0x0108に適用されます。
o pt_1_seq_id: This format can convey changes to the MSN and to the IP-ID. It is protected by a 7-bit CRC. It is similar in purpose to the UO-1-ID format in [RFC3095].
o PT_1_SEQ_ID：この形式は、MSNとIP-IDに変更を伝えることができます。7ビットCRCによって保護されています。[RFC3095]のUO-1-ID形式と目的が類似しています。
o pt_2_seq_id: This format can convey changes to the MSN and to the IP-ID. It is protected by a 7-bit CRC. It is similar in purpose to the UO-2-ID format in [RFC3095].
o PT_2_SEQ_ID：この形式は、MSNとIP-IDに変更を伝えることができます。7ビットCRCによって保護されています。[RFC3095]のUO-2-ID形式と目的が類似しています。
The ROHCv2 co_repair header has the following format:
ROHCV2 CO_REPAIRヘッダーには、次の形式があります。
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and CID 1-15
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 1 1 | discriminator
+---+---+---+---+---+---+---+---+
: :
/ 0, 1, or 2 octets of CID / 1-2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
|r1 | CRC-7 |
+---+---+---+---+---+---+---+---+
| r2 | CRC-3 |
+---+---+---+---+---+---+---+---+
| |
/ Dynamic chain / variable length
| |
- - - - - - - - - - - - - - - -
r1: MUST be set to zero; otherwise, the decompressor MUST discard the packet.
R1：ゼロに設定する必要があります。それ以外の場合、減圧器はパケットを破棄する必要があります。
CRC-7: A 7-bit CRC over the entire uncompressed header, computed using the crc7 (data_value, data_length) encoding method defined in Section 6.8.2.4, where data_value corresponds to the entire uncompressed header chain and where data_length corresponds to the length of this header chain.
CRC-7：CRC7（data_Value、data_length）エンコードメソッドを使用して計算された非圧縮ヘッダー全体にわたる7ビットCRC。このヘッダーチェーン。
r2: MUST be set to zero; otherwise, the decompressor MUST discard the packet.
R2：ゼロに設定する必要があります。それ以外の場合、減圧器はパケットを破棄する必要があります。
CRC-3: Encoded using the control_crc3_encoding method defined in Section 6.6.11.
CRC-3：セクション6.6.11で定義されたControl_CRC3_ENCODINGメソッドを使用してエンコードされています。
Dynamic chain: See Section 6.5.
動的チェーン：セクション6.5を参照してください。
The CO header format communicates irregularities in the packet header. All CO formats carry a CRC and can update the context. All CO header formats use the general format defined in this section, with the exception of the co_repair format, which is defined in Section 6.8.2.2.
COヘッダー形式は、パケットヘッダーの不規則性を伝えます。すべてのCO形式にはCRCがあり、コンテキストを更新できます。すべてのCOヘッダー形式は、セクション6.8.2.2で定義されているCo_repair形式を除き、このセクションで定義されている一般的な形式を使用します。
The general format for a compressed header is as follows:
圧縮ヘッダーの一般的な形式は次のとおりです。
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 length
+---+---+---+---+---+---+---+---+
: :
/ Irregular Chain / variable length
: :
--- --- --- --- --- --- --- ---
The base header in the figure above is the compressed representation of the innermost IP header and other header(s), if any, in the uncompressed packet. The base header formats are defined in Section 6.8.2.4. In the formal description of the header formats, the base header for each profile is labeled <profile_name>_baseheader, where <profile_name> is defined in the following table:
上の図のベースヘッダーは、非圧縮パケットにある場合、最も内側のIPヘッダーと他のヘッダーの圧縮表現です。ベースヘッダー形式は、セクション6.8.2.4で定義されています。ヘッダー形式の正式な説明では、各プロファイルのベースヘッダーに<profile_name> _baseheaderとラベル付けされています。
+------------------+----------------+
| Profile number | profile_name |
+------------------+----------------+
| 0x0101 | rtp |
| 0x0102 | udp |
| 0x0103 | esp |
| 0x0104 | ip |
| 0x0107 | udplite_rtp |
| 0x0108 | udplite |
+------------------+----------------+
This section defines the complete set of base header formats for ROHCv2 profiles. The base header formats are defined using the ROHC Formal Notation [RFC4997].
このセクションでは、ROHCV2プロファイルのベースヘッダー形式の完全なセットを定義します。ベースヘッダー形式は、ROHCフォーマル表記[RFC4997]を使用して定義されます。
// NOTE: The irregular, static, and dynamic chains (see Section 6.5)
// 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 constants
IP_ID_BEHAVIOR_SEQUENTIAL = 0;
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED = 1;
IP_ID_BEHAVIOR_RANDOM = 2;
IP_ID_BEHAVIOR_ZERO = 3;
// UDP-lite checksum coverage behavior constants
UDP_LITE_COVERAGE_INFERRED = 0;
UDP_LITE_COVERAGE_STATIC = 1;
UDP_LITE_COVERAGE_IRREGULAR = 2;
// The value 3 is reserved and cannot be used for coverage behavior
// Variable reordering offset
REORDERING_NONE = 0;
REORDERING_QUARTER = 1;
REORDERING_HALF = 2;
REORDERING_THREEQUARTERS = 3;
// Profile names and versions
PROFILE_RTP_0101 = 0x0101;
PROFILE_UDP_0102 = 0x0102;
PROFILE_ESP_0103 = 0x0103;
PROFILE_IP_0104 = 0x0104;
PROFILE_RTP_0107 = 0x0107; // With UDP-LITE
PROFILE_UDPLITE_0108 = 0x0108; // Without RTP
// Default values for RTP timestamp encoding TS_STRIDE_DEFAULT = 160; TIME_STRIDE_DEFAULT = 0;
// TS_STRIDE_DEFAULT = 160をエンコードするRTPタイムスタンプのデフォルト値。time_stride_default = 0;
////////////////////////////////////////////
// Global control fields
////////////////////////////////////////////
CONTROL {
コントロール {
profile [ 16 ];
msn [ 16 ];
reorder_ratio [ 2 ];
// ip_id fields are for innermost IP header only
ip_id_offset [ 16 ];
ip_id_behavior_innermost [ 2 ];
// The following are only used in RTP-based profiles
ts_stride [ 32 ];
time_stride [ 32 ];
ts_scaled [ 32 ];
ts_offset [ 32 ];
// UDP-lite-based profiles only
coverage_behavior [ 2 ];
}
///////////////////////////////////////////////
// Encoding methods not specified in FN syntax:
///////////////////////////////////////////////
baseheader_extension_headers "defined in Section 6.6.1";
baseheader_outer_headers "defined in Section 6.6.2";
control_crc3_encoding "defined in Section 6.6.11";
inferred_ip_v4_header_checksum "defined in Section 6.6.4";
inferred_ip_v4_length "defined in Section 6.6.6";
inferred_ip_v6_length "defined in Section 6.6.7";
inferred_mine_header_checksum "defined in Section 6.6.5";
inferred_scaled_field "defined in Section 6.6.10";
inferred_sequential_ip_id "defined in Section 6.6.12";
inferred_udp_length "defined in Section 6.6.3";
list_csrc(cc_value) "defined in Section 6.6.13";
timer_based_lsb(time_stride, k, p) "defined in Section 6.6.9";
////////////////////////////////////////////
// General encoding methods
////////////////////////////////////////////
static_or_irreg(flag, width)
{
UNCOMPRESSED {
field [ width ];
}
COMPRESSED irreg_enc {
ENFORCE(flag == 1);
field =:= irregular(width) [ width ];
}
COMPRESSED static_enc {
圧縮static_enc {
ENFORCE(flag == 0);
field =:= static [ 0 ];
}
}
optional_32(flag)
{
UNCOMPRESSED {
item [ 0, 32 ];
}
COMPRESSED present {
ENFORCE(flag == 1);
item =:= irregular(32) [ 32 ];
}
COMPRESSED not_present {
ENFORCE(flag == 0);
item =:= compressed_value(0, 0) [ 0 ];
}
}
// Send the entire value, or keep previous value
sdvl_or_static(flag)
{
UNCOMPRESSED {
field [ 32 ];
}
COMPRESSED present_7bit {
ENFORCE(flag == 1);
ENFORCE(field.UVALUE < 2^7);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '0' [ 1 ];
field [ 7 ];
}
COMPRESSED present_14bit {
ENFORCE(flag == 1);
ENFORCE(field.UVALUE < 2^14);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '10' [ 2 ];
field [ 14 ];
}
COMPRESSED present_21bit {
ENFORCE(flag == 1);
ENFORCE(field.UVALUE < 2^21);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '110' [ 3 ];
field [ 21 ];
}
COMPRESSED present_28bit {
ENFORCE(flag == 1);
ENFORCE(field.UVALUE < 2^28);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '1110' [ 4 ];
field [ 28 ];
}
COMPRESSED present_32bit {
ENFORCE(flag == 1);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '11111111' [ 8 ];
field [ 32 ];
}
COMPRESSED not_present {
ENFORCE(flag == 0);
field =:= static;
}
}
// Send the entire value, or revert to default value
sdvl_or_default(flag, default_value)
{
UNCOMPRESSED {
field [ 32 ];
}
COMPRESSED present_7bit {
ENFORCE(flag == 1);
ENFORCE(field.UVALUE < 2^7);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '0' [ 1 ];
field [ 7 ];
}
COMPRESSED present_14bit {
ENFORCE(flag == 1);
ENFORCE(field.UVALUE < 2^14);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '10' [ 2 ];
field [ 14 ];
}
COMPRESSED present_21bit {
ENFORCE(flag == 1);
ENFORCE(field.UVALUE < 2^21);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '110' [ 3 ];
field [ 21 ];
}
COMPRESSED present_28bit {
ENFORCE(flag == 1);
ENFORCE(field.UVALUE < 2^28);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '1110' [ 4 ];
field [ 28 ];
}
COMPRESSED present_32bit {
ENFORCE(flag == 1);
ENFORCE(field.CVALUE == field.UVALUE);
discriminator =:= '11111111' [ 8 ];
field [ 32 ];
}
COMPRESSED not_present {
ENFORCE(flag == 0);
field =:= uncompressed_value(32, default_value);
}
}
lsb_7_or_31
{
UNCOMPRESSED {
item [ 32 ];
}
COMPRESSED lsb_7 {
discriminator =:= '0' [ 1 ];
item =:= lsb(7, ((2^7) / 4) - 1) [ 7 ];
}
COMPRESSED lsb_31 {
discriminator =:= '1' [ 1 ];
item =:= lsb(31, ((2^31) / 4) - 1) [ 31 ];
}
}
crc3(data_value, data_length) {
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 ];
}
}
// 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_irregular {
}
}
}
////////////////////////////////////////////
// IPv6 Hop-by-Hop options header
////////////////////////////////////////////
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_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_irregular {
}
}
////////////////////////////////////////////
// GRE Header
////////////////////////////////////////////
optional_lsb_7_or_31(flag) {
optional_lsb_7_or_31（flag）{
UNCOMPRESSED {
item [ 0, 32 ];
}
COMPRESSED present {
ENFORCE(flag == 1);
item =:= lsb_7_or_31 [ 8, 32 ];
}
COMPRESSED not_present {
ENFORCE(flag == 0);
item =:= compressed_value(0, 0) [ 0 ];
}
}
optional_checksum(flag_value)
{
UNCOMPRESSED {
value [ 0, 16 ];
reserved1 [ 0, 16 ];
}
COMPRESSED cs_present {
ENFORCE(flag_value == 1);
value =:= irregular(16) [ 16 ];
reserved1 =:= uncompressed_value(16, 0) [ 0 ];
}
COMPRESSED not_present {
ENFORCE(flag_value == 0);
value =:= compressed_value(0, 0) [ 0 ];
reserved1 =:= compressed_value(0, 0) [ 0 ];
}
}
gre_proto
{
UNCOMPRESSED {
protocol [ 16 ];
}
COMPRESSED ether_v4 {
discriminator =:= '0' [ 1 ];
protocol =:= uncompressed_value(16, 0x0800) [ 0 ];
}
COMPRESSED ether_v6 {
discriminator =:= '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 {
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 =:= optional_32(k_flag.UVALUE) [ 0, 32 ];
}
COMPRESSED gre_dynamic {
checksum_and_res =:=
optional_checksum(c_flag.UVALUE) [ 0, 16 ];
sequence_number =:= optional_32(s_flag.UVALUE) [ 0, 32 ];
}
COMPRESSED gre_irregular {
圧縮gre_irレギュラー{
checksum_and_res =:= optional_checksum(c_flag.UVALUE) [ 0, 16 ];
sequence_number =:=
optional_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 =:= optional_32(s_bit.UVALUE) [ 0, 32 ];
}
COMPRESSED mine_dynamic {
}
COMPRESSED mine_irregular {
}
}
/////////////////////////////////////////////
//////////////////////////////////
// Authentication Header (AH) /////////////////////////////////////////////
//認証ヘッダー（AH）///////////////////////////////////////////////
ah
{
UNCOMPRESSED {
next_header [ 8 ];
length [ 8 ];
res_bits =:= uncompressed_value(16, 0) [ 16 ];
spi [ 32 ];
sequence_number [ 32 ];
icv [ length.UVALUE*32-32 ];
}
DEFAULT {
next_header =:= static;
length =:= 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 {
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 ]; }
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 ];
}
}
ipv6(profile_value, is_innermost, outer_ip_flag, reorder_ratio_value)
{
UNCOMPRESSED {
version =:= uncompressed_value(4, 6) [ 4 ];
tos_tc [ 8 ];
flow_label [ 20 ];
payload_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dst_addr [ 128 ];
}
CONTROL {
ENFORCE(profile == profile_value);
ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
ENFORCE(innermost_ip.UVALUE == is_innermost);
innermost_ip [ 1 ];
}
DEFAULT {
tos_tc =:= 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 ];
innermost_ip =:= irregular(1) [ 1 ];
reserved =:= '0' [ 1 ];
flow_label =:= fl_enc [ 5, 21 ];
next_header =:= irregular(8) [ 8 ];
src_addr =:= irregular(128) [ 128 ];
dst_addr =:= irregular(128) [ 128 ];
}
COMPRESSED ipv6_endpoint_dynamic {
ENFORCE((is_innermost == 1) &&
(profile_value == PROFILE_IP_0104));
tos_tc =:= irregular(8) [ 8 ];
ttl_hopl =:= irregular(8) [ 8 ];
reserved =:= compressed_value(6, 0) [ 6 ];
reorder_ratio =:= irregular(2) [ 2 ];
msn =:= irregular(16) [ 16 ];
}
COMPRESSED ipv6_regular_dynamic {
ENFORCE((is_innermost == 0) ||
(profile_value != PROFILE_IP_0104));
tos_tc =:= irregular(8) [ 8 ];
ttl_hopl =:= irregular(8) [ 8 ];
}
COMPRESSED ipv6_outer_irregular {
ENFORCE(is_innermost == 0);
tos_tc =:=
static_or_irreg(outer_ip_flag, 8) [ 0, 8 ];
ttl_hopl =:=
static_or_irreg(outer_ip_flag, 8) [ 0, 8 ];
}
COMPRESSED ipv6_innermost_irregular {
ENFORCE(is_innermost == 1);
}
}
}
/////////////////////////////////////////////
// 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 {
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL);
}
COMPRESSED ip_id_seq_swapped {
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED);
}
COMPRESSED ip_id_rand {
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 ];
}
}
ipv4(profile_value, is_innermost, outer_ip_flag, ip_id_behavior_value,
reorder_ratio_value)
{
UNCOMPRESSED {
version =:= uncompressed_value(4, 4) [ 4 ];
hdr_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 8 ];
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(profile == profile_value);
ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
ENFORCE(innermost_ip.UVALUE == is_innermost);
ip_id_behavior_outer [ 2 ];
innermost_ip [ 1 ];
}
DEFAULT {
tos_tc =:= 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 ];
innermost_ip =:= irregular(1) [ 1 ];
reserved =:= '000000' [ 6 ];
protocol =:= irregular(8) [ 8 ];
src_addr =:= irregular(32) [ 32 ];
dst_addr =:= irregular(32) [ 32 ];
}
COMPRESSED ipv4_endpoint_innermost_dynamic {
ENFORCE((is_innermost == 1) && (profile_value == PROFILE_IP_0104));
ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
reserved =:= '000' [ 3 ];
reorder_ratio =:= irregular(2) [ 2 ];
df =:= irregular(1) [ 1 ];
ip_id_behavior_innermost =:= irregular(2) [ 2 ];
tos_tc =:= irregular(8) [ 8 ];
ttl_hopl =:= irregular(8) [ 8 ];
ip_id =:= ip_id_enc_dyn(ip_id_behavior_innermost.UVALUE) [ 0, 16 ];
msn =:= irregular(16) [ 16 ];
}
COMPRESSED ipv4_regular_innermost_dynamic {
ENFORCE((is_innermost == 1) && (profile_value != PROFILE_IP_0104));
ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
reserved =:= '00000' [ 5 ];
df =:= irregular(1) [ 1 ];
ip_id_behavior_innermost =:= irregular(2) [ 2 ];
tos_tc =:= irregular(8) [ 8 ];
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 ];
tos_tc =:= irregular(8) [ 8 ];
ttl_hopl =:= irregular(8) [ 8 ];
ip_id =:= ip_id_enc_dyn(ip_id_behavior_outer.UVALUE) [ 0, 16 ];
}
COMPRESSED ipv4_outer_irregular {
ENFORCE(is_innermost == 0);
ip_id =:=
ip_id_enc_irreg(ip_id_behavior_outer.UVALUE) [ 0, 16 ];
tos_tc =:= static_or_irreg(outer_ip_flag, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(outer_ip_flag, 8) [ 0, 8 ];
}
COMPRESSED ipv4_innermost_irregular {
ENFORCE(is_innermost == 1);
ip_id =:=
ip_id_enc_irreg(ip_id_behavior_innermost.UVALUE) [ 0, 16 ];
}
}
}
/////////////////////////////////////////////
// UDP Header
/////////////////////////////////////////////
udp(profile_value, reorder_ratio_value)
{
UNCOMPRESSED {
ENFORCE((profile_value == PROFILE_RTP_0101) ||
(profile_value == PROFILE_UDP_0102));
src_port [ 16 ];
dst_port [ 16 ];
udp_length =:= inferred_udp_length [ 16 ];
checksum [ 16 ];
}
CONTROL {
ENFORCE(profile == profile_value);
ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
checksum_used [ 1 ];
}
DEFAULT {
src_port =:= static;
dst_port =:= static;
checksum_used =:= static;
}
COMPRESSED udp_static {
src_port =:= irregular(16) [ 16 ];
dst_port =:= irregular(16) [ 16 ];
}
COMPRESSED udp_endpoint_dynamic {
ENFORCE(profile_value == PROFILE_UDP_0102);
ENFORCE(profile == PROFILE_UDP_0102);
ENFORCE(checksum_used.UVALUE == (checksum.UVALUE != 0));
checksum =:= irregular(16) [ 16 ];
msn =:= irregular(16) [ 16 ];
reserved =:= compressed_value(6, 0) [ 6 ];
reorder_ratio =:= irregular(2) [ 2 ];
}
COMPRESSED udp_regular_dynamic {
ENFORCE(profile_value == PROFILE_RTP_0101);
ENFORCE(checksum_used.UVALUE == (checksum.UVALUE != 0));
checksum =:= irregular(16) [ 16 ];
}
COMPRESSED udp_zero_checksum_irregular {
ENFORCE(checksum_used.UVALUE == 0);
checksum =:= uncompressed_value(16, 0) [ 0 ];
}
COMPRESSED udp_with_checksum_irregular {
ENFORCE(checksum_used.UVALUE == 1);
checksum =:= irregular(16) [ 16 ];
}
}
}
/////////////////////////////////////////////
// RTP Header
/////////////////////////////////////////////
csrc_list_dynchain(presence, cc_value)
{
UNCOMPRESSED {
csrc_list;
}
COMPRESSED no_list {
ENFORCE(cc_value == 0);
ENFORCE(presence == 0);
csrc_list =:= uncompressed_value(0, 0) [ 0 ];
}
COMPRESSED list_present {
ENFORCE(presence == 1);
csrc_list =:= list_csrc(cc_value) [ VARIABLE ];
}
}
rtp(profile_value, ts_stride_value, time_stride_value,
reorder_ratio_value)
{
UNCOMPRESSED {
ENFORCE((profile_value == PROFILE_RTP_0101) ||
(profile_value == PROFILE_RTP_0107));
rtp_version =:= uncompressed_value(2, 0) [ 2 ];
pad_bit [ 1 ];
extension [ 1 ];
cc [ 4 ];
marker [ 1 ];
payload_type [ 7 ];
sequence_number [ 16 ];
timestamp [ 32 ];
ssrc [ 32 ];
csrc_list [ cc.UVALUE * 32 ];
}
CONTROL {
コントロール {
ENFORCE(profile == profile_value);
ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
ENFORCE(time_stride_value == time_stride.UVALUE);
ENFORCE(ts_stride_value == ts_stride.UVALUE);
dummy_field =:= field_scaling(ts_stride.UVALUE,
ts_scaled.UVALUE, timestamp.UVALUE, ts_offset.UVALUE) [ 0 ];
}
INITIAL {
ts_stride =:= uncompressed_value(32, TS_STRIDE_DEFAULT);
time_stride =:= uncompressed_value(32, TIME_STRIDE_DEFAULT);
}
DEFAULT {
ENFORCE(msn.UVALUE == sequence_number.UVALUE);
pad_bit =:= static;
extension =:= static;
cc =:= static;
marker =:= static;
payload_type =:= static;
sequence_number =:= static;
timestamp =:= static;
ssrc =:= static;
csrc_list =:= static;
ts_stride =:= static;
time_stride =:= static;
ts_scaled =:= static;
ts_offset =:= static;
}
COMPRESSED rtp_static {
ssrc =:= irregular(32) [ 32 ];
}
COMPRESSED rtp_dynamic {
reserved =:= compressed_value(1, 0) [ 1 ];
reorder_ratio =:= irregular(2) [ 2 ];
list_present =:= irregular(1) [ 1 ];
tss_indicator =:= irregular(1) [ 1 ];
tis_indicator =:= irregular(1) [ 1 ];
pad_bit =:= irregular(1) [ 1 ];
extension =:= irregular(1) [ 1 ];
marker =:= irregular(1) [ 1 ];
payload_type =:= irregular(7) [ 7 ];
sequence_number =:= irregular(16) [ 16 ];
timestamp =:= irregular(32) [ 32 ];
ts_stride =:= sdvl_or_default(tss_indicator.CVALUE,
TS_STRIDE_DEFAULT) [ VARIABLE ];
time_stride =:= sdvl_or_default(tis_indicator.CVALUE,
TIME_STRIDE_DEFAULT) [ VARIABLE ];
csrc_list =:= csrc_list_dynchain(list_present.CVALUE,
cc.UVALUE) [ VARIABLE ];
}
COMPRESSED rtp_irregular {
}
}
/////////////////////////////////////////////
// UDP-Lite Header
/////////////////////////////////////////////
checksum_coverage_dynchain(behavior)
{
UNCOMPRESSED {
checksum_coverage [ 16 ];
}
COMPRESSED inferred_coverage {
ENFORCE(behavior == UDP_LITE_COVERAGE_INFERRED);
checksum_coverage =:= inferred_udp_length [ 0 ];
}
COMPRESSED static_coverage {
ENFORCE(behavior == UDP_LITE_COVERAGE_STATIC);
checksum_coverage =:= irregular(16) [ 16 ];
}
COMPRESSED irregular_coverage {
ENFORCE(behavior == UDP_LITE_COVERAGE_IRREGULAR);
checksum_coverage =:= irregular(16) [ 16 ];
}
}
checksum_coverage_irregular(behavior)
{
UNCOMPRESSED {
checksum_coverage [ 16 ];
}
COMPRESSED inferred_coverage {
ENFORCE(behavior == UDP_LITE_COVERAGE_INFERRED);
checksum_coverage =:= inferred_udp_length [ 0 ];
}
COMPRESSED static_coverage {
圧縮static_coverage {
ENFORCE(behavior == UDP_LITE_COVERAGE_STATIC);
checksum_coverage =:= static [ 0 ];
}
COMPRESSED irregular_coverage {
ENFORCE(behavior == UDP_LITE_COVERAGE_IRREGULAR);
checksum_coverage =:= irregular(16) [ 16 ];
}
}
udp_lite(profile_value, reorder_ratio_value, coverage_behavior_value)
{
UNCOMPRESSED {
ENFORCE((profile_value == PROFILE_RTP_0107) ||
(profile_value == PROFILE_UDPLITE_0108));
src_port [ 16 ];
dst_port [ 16 ];
checksum_coverage [ 16 ];
checksum [ 16 ];
}
CONTROL {
ENFORCE(profile == profile_value);
ENFORCE(coverage_behavior.UVALUE == coverage_behavior_value);
ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
}
DEFAULT {
src_port =:= static;
dst_port =:= static;
coverage_behavior =:= static;
}
COMPRESSED udp_lite_static {
src_port =:= irregular(16) [ 16 ];
dst_port =:= irregular(16) [ 16 ];
}
COMPRESSED udp_lite_endpoint_dynamic {
ENFORCE(profile_value == PROFILE_UDPLITE_0108);
reserved =:= compressed_value(4, 0) [ 4 ];
coverage_behavior =:= irregular(2) [ 2 ];
reorder_ratio =:= irregular(2) [ 2 ];
checksum_coverage =:=
checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 16 ];
checksum =:= irregular(16) [ 16 ];
msn =:= irregular(16) [ 16 ];
}
COMPRESSED udp_lite_regular_dynamic {
ENFORCE(profile_value == PROFILE_RTP_0107);
coverage_behavior =:= irregular(2) [ 2 ];
reserved =:= compressed_value(6, 0) [ 6 ];
checksum_coverage =:=
checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 16 ];
checksum =:= irregular(16) [ 16 ];
}
COMPRESSED udp_lite_irregular {
checksum_coverage =:=
checksum_coverage_irregular(coverage_behavior.UVALUE) [ 0, 16 ];
checksum =:= irregular(16) [ 16 ];
}
}
/////////////////////////////////////////////
// ESP Header
/////////////////////////////////////////////
esp(profile_value, reorder_ratio_value)
{
UNCOMPRESSED {
ENFORCE(profile_value == PROFILE_ESP_0103);
ENFORCE(msn.UVALUE == sequence_number.UVALUE % 65536);
spi [ 32 ];
sequence_number [ 32 ];
}
CONTROL {
ENFORCE(profile == profile_value);
ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
}
DEFAULT {
spi =:= static;
sequence_number =:= static;
}
COMPRESSED esp_static {
spi =:= irregular(32) [ 32 ];
}
COMPRESSED esp_dynamic {
sequence_number =:= irregular(32) [ 32 ];
reserved =:= compressed_value(6, 0) [ 6 ];
reorder_ratio =:= irregular(2) [ 2 ];
}
COMPRESSED esp_irregular {
}
}
///////////////////////////////////////////////////
// Encoding methods used in the profiles' CO headers
///////////////////////////////////////////////////
// Variable reordering offset used for MSN
msn_lsb(k)
{
UNCOMPRESSED {
master [ VARIABLE ];
}
COMPRESSED none {
ENFORCE(reorder_ratio.UVALUE == REORDERING_NONE);
master =:= lsb(k, 1);
}
COMPRESSED quarter {
ENFORCE(reorder_ratio.UVALUE == REORDERING_QUARTER);
master =:= lsb(k, ((2^k) / 4) - 1);
}
COMPRESSED half {
ENFORCE(reorder_ratio.UVALUE == REORDERING_HALF);
master =:= lsb(k, ((2^k) / 2) - 1);
}
COMPRESSED threequarters {
ENFORCE(reorder_ratio.UVALUE == REORDERING_THREEQUARTERS);
master =:= lsb(k, (((2^k) * 3) / 4) - 1);
}
}
ip_id_lsb(behavior, k)
{
UNCOMPRESSED {
ip_id [ 16 ];
}
CONTROL {
ip_id_nbo [ 16 ];
}
COMPRESSED nbo {
ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL);
ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE);
ip_id_offset =:= lsb(k, ((2^k) / 4) - 1) [ k ];
}
COMPRESSED non_nbo {
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);
ip_id_offset =:= lsb(k, ((2^k) / 4) - 1) [ k ];
}
}
ip_id_sequential_variable(behavior, indicator)
{
UNCOMPRESSED {
ip_id [ 16 ];
}
COMPRESSED short {
ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
ENFORCE(indicator == 0);
ip_id =:= ip_id_lsb(behavior, 8) [ 8 ];
}
COMPRESSED long {
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);
ip_id =:= irregular(16) [ 16 ];
}
COMPRESSED not_present {
ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) ||
(behavior == IP_ID_BEHAVIOR_ZERO));
}
}
dont_fragment(version)
{
UNCOMPRESSED {
df [ 0, 1 ];
}
COMPRESSED v4 {
圧縮V4 {
ENFORCE(version == 4);
df =:= irregular(1) [ 1 ];
}
COMPRESSED v6 {
ENFORCE(version == 6);
unused =:= compressed_value(1, 0) [ 1 ];
}
}
pt_irr_or_static(flag)
{
UNCOMPRESSED {
payload_type [ 7 ];
}
COMPRESSED not_present {
ENFORCE(flag == 0);
payload_type =:= static [ 0 ];
}
COMPRESSED present {
ENFORCE(flag == 1);
reserved =:= compressed_value(1, 0) [ 1 ];
payload_type =:= irregular(7) [ 7 ];
}
}
csrc_list_presence(presence, cc_value)
{
UNCOMPRESSED {
csrc_list;
}
COMPRESSED no_list {
ENFORCE(presence == 0);
csrc_list =:= static [ 0 ];
}
COMPRESSED list_present {
ENFORCE(presence == 1);
csrc_list =:= list_csrc(cc_value) [ VARIABLE ];
}
}
scaled_ts_lsb(time_stride_value, k)
{
UNCOMPRESSED {
timestamp [ 32 ]; }
タイムスタンプ[32];}
COMPRESSED timerbased {
ENFORCE(time_stride_value != 0);
timestamp =:= timer_based_lsb(time_stride_value, k,
((2^k) / 2) - 1);
}
COMPRESSED regular {
ENFORCE(time_stride_value == 0);
timestamp =:= lsb(k, ((2^k) / 4) - 1);
}
}
// Self-describing variable length encoding with reordering offset
sdvl_sn_lsb(field_width)
{
UNCOMPRESSED {
field [ field_width ];
}
COMPRESSED lsb7 {
discriminator =:= '0' [ 1 ];
field =:= msn_lsb(7) [ 7 ];
}
COMPRESSED lsb14 {
discriminator =:= '10' [ 2 ];
field =:= msn_lsb(14) [ 14 ];
}
COMPRESSED lsb21 {
discriminator =:= '110' [ 3 ];
field =:= msn_lsb(21) [ 21 ];
}
COMPRESSED lsb28 {
discriminator =:= '1110' [ 4 ];
field =:= msn_lsb(28) [ 28 ];
}
COMPRESSED lsb32 {
discriminator =:= '11111111' [ 8 ];
field =:= irregular(field_width) [ field_width ];
}
}
// Self-describing variable length encoding
sdvl_lsb(field_width)
{
UNCOMPRESSED {
field [ field_width ];
}
COMPRESSED lsb7 {
discriminator =:= '0' [ 1 ];
field =:= lsb(7, ((2^7) / 4) - 1) [ 7 ];
}
COMPRESSED lsb14 {
discriminator =:= '10' [ 2 ];
field =:= lsb(14, ((2^14) / 4) - 1) [ 14 ];
}
COMPRESSED lsb21 {
discriminator =:= '110' [ 3 ];
field =:= lsb(21, ((2^21) / 4) - 1) [ 21 ];
}
COMPRESSED lsb28 {
discriminator =:= '1110' [ 4 ];
field =:= lsb(28, ((2^28) / 4) - 1) [ 28 ];
}
COMPRESSED lsb32 {
discriminator =:= '11111111' [ 8 ];
field =:= irregular(field_width) [ field_width ];
}
}
sdvl_scaled_ts_lsb(time_stride)
{
UNCOMPRESSED {
field [ 32 ];
}
COMPRESSED lsb7 {
discriminator =:= '0' [ 1 ];
field =:= scaled_ts_lsb(time_stride, 7) [ 7 ];
}
COMPRESSED lsb14 {
discriminator =:= '10' [ 2 ];
field =:= scaled_ts_lsb(time_stride, 14) [ 14 ];
}
COMPRESSED lsb21 {
discriminator =:= '110' [ 3 ];
field =:= scaled_ts_lsb(time_stride, 21) [ 21 ];
}
COMPRESSED lsb28 {
discriminator =:= '1110' [ 4 ];
field =:= scaled_ts_lsb(time_stride, 28) [ 28 ];
}
COMPRESSED lsb32 {
discriminator =:= '11111111' [ 8 ];
field =:= irregular(32) [ 32 ];
}
}
variable_scaled_timestamp(tss_flag, tsc_flag, ts_stride, time_stride)
{
UNCOMPRESSED {
scaled_value [ 32 ];
}
COMPRESSED present {
ENFORCE((tss_flag == 0) && (tsc_flag == 1));
ENFORCE(ts_stride != 0);
scaled_value =:= sdvl_scaled_ts_lsb(time_stride) [ VARIABLE ];
}
COMPRESSED not_present {
ENFORCE(((tss_flag == 1) && (tsc_flag == 0)) ||
((tss_flag == 0) && (tsc_flag == 0)));
}
}
variable_unscaled_timestamp(tss_flag, tsc_flag)
{
UNCOMPRESSED {
timestamp [ 32 ];
}
COMPRESSED present {
ENFORCE(((tss_flag == 1) && (tsc_flag == 0)) ||
((tss_flag == 0) && (tsc_flag == 0)));
timestamp =:= sdvl_lsb(32);
}
COMPRESSED not_present {
ENFORCE((tss_flag == 0) && (tsc_flag == 1));
}
}
profile_1_7_flags1_enc(flag, ip_version)
{
UNCOMPRESSED {
ip_outer_indicator [ 1 ];
ttl_hopl_indicator [ 1 ];
tos_tc_indicator [ 1 ];
df [ 0, 1 ];
ip_id_behavior [ 2 ];
reorder_ratio [ 2 ];
}
COMPRESSED not_present {
ENFORCE(flag == 0);
ENFORCE(ip_outer_indicator.CVALUE == 0);
ENFORCE(ttl_hopl_indicator.CVALUE == 0);
ENFORCE(tos_tc_indicator.CVALUE == 0);
df =:= static;
ip_id_behavior =:= static;
reorder_ratio =:= static;
}
COMPRESSED present {
ENFORCE(flag == 1);
ip_outer_indicator =:= irregular(1) [ 1 ];
ttl_hopl_indicator =:= irregular(1) [ 1 ];
tos_tc_indicator =:= irregular(1) [ 1 ];
df =:= dont_fragment(ip_version) [ 1 ];
ip_id_behavior =:= irregular(2) [ 2 ];
reorder_ratio =:= irregular(2) [ 2 ];
}
}
profile_1_flags2_enc(flag)
{
UNCOMPRESSED {
list_indicator [ 1 ];
pt_indicator [ 1 ];
time_stride_indicator [ 1 ];
pad_bit [ 1 ];
extension [ 1 ];
}
COMPRESSED not_present{
ENFORCE(flag == 0);
ENFORCE(list_indicator.UVALUE == 0);
ENFORCE(pt_indicator.UVALUE == 0);
ENFORCE(time_stride_indicator.UVALUE == 0);
pad_bit =:= static;
extension =:= static;
}
COMPRESSED present {
ENFORCE(flag == 1);
list_indicator =:= irregular(1) [ 1 ];
pt_indicator =:= irregular(1) [ 1 ];
time_stride_indicator =:= irregular(1) [ 1 ];
pad_bit =:= irregular(1) [ 1 ];
extension =:= irregular(1) [ 1 ];
reserved =:= compressed_value(3, 0) [ 3 ];
}
}
profile_2_3_4_flags_enc(flag, ip_version)
{
UNCOMPRESSED {
ip_outer_indicator [ 1 ];
df [ 0, 1 ];
ip_id_behavior [ 2 ];
}
COMPRESSED not_present {
ENFORCE(flag == 0);
ENFORCE(ip_outer_indicator.CVALUE == 0);
df =:= static;
ip_id_behavior =:= static;
}
COMPRESSED present {
ENFORCE(flag == 1);
ip_outer_indicator =:= irregular(1) [ 1 ];
df =:= dont_fragment(ip_version) [ 1 ];
ip_id_behavior =:= irregular(2) [ 2 ];
reserved =:= compressed_value(4, 0) [ 4 ];
}
}
profile_8_flags_enc(flag, ip_version)
{
UNCOMPRESSED {
ip_outer_indicator [ 1 ];
df [ 0, 1 ];
ip_id_behavior [ 2 ];
coverage_behavior [ 2 ];
}
}
COMPRESSED not_present {
ENFORCE(flag == 0);
ENFORCE(ip_outer_indicator.CVALUE == 0);
df =:= static;
ip_id_behavior =:= static;
coverage_behavior =:= static;
}
COMPRESSED present {
ENFORCE(flag == 1);
reserved =:= compressed_value(2, 0) [ 2 ];
ip_outer_indicator =:= irregular(1) [ 1 ];
df =:= dont_fragment(ip_version) [ 1 ];
ip_id_behavior =:= irregular(2) [ 2 ];
coverage_behavior =:= irregular(2) [ 2 ];
}
}
profile_7_flags2_enc(flag)
{
UNCOMPRESSED {
list_indicator [ 1 ];
pt_indicator [ 1 ];
time_stride_indicator [ 1 ];
pad_bit [ 1 ];
extension [ 1 ];
coverage_behavior [ 2 ];
}
COMPRESSED not_present{
ENFORCE(flag == 0);
ENFORCE(list_indicator.CVALUE == 0);
ENFORCE(pt_indicator.CVALUE == 0);
ENFORCE(time_stride_indicator.CVALUE == 0);
pad_bit =:= static;
extension =:= static;
coverage_behavior =:= static;
}
COMPRESSED present {
ENFORCE(flag == 1);
reserved =:= compressed_value(1, 0) [ 1 ];
list_indicator =:= irregular(1) [ 1 ];
pt_indicator =:= irregular(1) [ 1 ];
time_stride_indicator =:= irregular(1) [ 1 ];
pad_bit =:= irregular(1) [ 1 ];
extension =:= irregular(1) [ 1 ];
coverage_behavior =:= irregular(2) [ 2 ];
}
}
////////////////////////////////////////////
// RTP profile
////////////////////////////////////////////
rtp_baseheader(profile_value, ts_stride_value, time_stride_value,
outer_ip_flag, ip_id_behavior_value,
reorder_ratio_value)
{
UNCOMPRESSED v4 {
ENFORCE(msn.UVALUE == sequence_number.UVALUE);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 8 ];
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 ];
next_header [ 8 ];
ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
udp_length =:= inferred_udp_length [ 16 ];
udp_checksum [ 16 ];
rtp_version =:= uncompressed_value(2, 2) [ 2 ];
pad_bit [ 1 ];
extension [ 1 ];
cc [ 4 ];
marker [ 1 ];
payload_type [ 7 ];
sequence_number [ 16 ];
timestamp [ 32 ];
ssrc [ 32 ];
csrc_list [ VARIABLE ];
}
UNCOMPRESSED v6 {
圧縮されていないV6 {
ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM);
ENFORCE(msn.UVALUE == sequence_number.UVALUE);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 6) [ 4 ];
tos_tc [ 8 ];
flow_label [ 20 ];
payload_length =:= inferred_ip_v6_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dest_addr [ 128 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
udp_length =:= inferred_udp_length [ 16 ];
udp_checksum [ 16 ];
rtp_version =:= uncompressed_value(2, 2) [ 2 ];
pad_bit [ 1 ];
extension [ 1 ];
cc [ 4 ];
marker [ 1 ];
payload_type [ 7 ];
sequence_number [ 16 ];
timestamp [ 32 ];
ssrc [ 32 ];
csrc_list [ VARIABLE ];
df =:= uncompressed_value(0,0) [ 0 ];
ip_id =:= uncompressed_value(0,0) [ 0 ];
}
CONTROL {
ENFORCE(profile_value == PROFILE_RTP_0101);
ENFORCE(profile == profile_value);
ENFORCE(time_stride.UVALUE == time_stride_value);
ENFORCE(ts_stride.UVALUE == ts_stride_value);
ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
dummy_field =:= field_scaling(ts_stride.UVALUE,
ts_scaled.UVALUE, timestamp.UVALUE, ts_offset.UVALUE) [ 0 ];
}
INITIAL {
ts_stride =:= uncompressed_value(32, TS_STRIDE_DEFAULT);
time_stride =:= uncompressed_value(32, TIME_STRIDE_DEFAULT);
}
DEFAULT {
ENFORCE(outer_ip_flag == 0);
tos_tc =:= static;
dest_addr =:= static;
ttl_hopl =:= static;
src_addr =:= static;
df =:= static;
flow_label =:= static;
next_header =:= static;
src_port =:= static;
dst_port =:= static;
pad_bit =:= static;
extension =:= static;
cc =:= static;
// When marker not present in packets, it is assumed 0
marker =:= uncompressed_value(1, 0);
payload_type =:= static;
sequence_number =:= static;
timestamp =:= static;
ssrc =:= static;
csrc_list =:= static;
ts_stride =:= static;
time_stride =:= static;
ts_scaled =:= static;
ts_offset =:= static;
reorder_ratio =:= static;
ip_id_behavior_innermost =:= static;
}
// Replacement for UOR-2-ext3
COMPRESSED co_common {
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
discriminator =:= '11111010' [ 8 ];
marker =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags1_indicator =:= irregular(1) [ 1 ];
flags2_indicator =:= irregular(1) [ 1 ];
tsc_indicator =:= irregular(1) [ 1 ];
tss_indicator =:= irregular(1) [ 1 ];
ip_id_indicator =:= irregular(1) [ 1 ];
control_crc3 =:= control_crc3_encoding [ 3 ];
outer_ip_indicator : ttl_hopl_indicator :
tos_tc_indicator : df : ip_id_behavior_innermost : reorder_ratio
=:= profile_1_7_flags1_enc(flags1_indicator.CVALUE,
ip_version.UVALUE) [ 0, 8 ];
list_indicator : pt_indicator : tis_indicator : pad_bit :
extension =:= profile_1_flags2_enc(
flags2_indicator.CVALUE) [ 0, 8 ];
tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
ttl_hopl.ULENGTH) [ 0, 8 ];
payload_type =:= pt_irr_or_static(pt_indicator) [ 0, 8 ];
sequence_number =:=
sdvl_sn_lsb(sequence_number.ULENGTH) [ VARIABLE ];
ip_id =:= ip_id_sequential_variable(
ip_id_behavior_innermost.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
ts_scaled =:= variable_scaled_timestamp(tss_indicator.CVALUE,
tsc_indicator.CVALUE, ts_stride.UVALUE,
time_stride.UVALUE) [ VARIABLE ];
timestamp =:= variable_unscaled_timestamp(tss_indicator.CVALUE,
tsc_indicator.CVALUE) [ VARIABLE ];
ts_stride =:= sdvl_or_static(tss_indicator.CVALUE) [ VARIABLE ];
time_stride =:= sdvl_or_static(tis_indicator.CVALUE) [ VARIABLE ];
csrc_list =:= csrc_list_presence(list_indicator.CVALUE,
cc.UVALUE) [ VARIABLE ];
}
// UO-0
COMPRESSED pt_0_crc3 {
discriminator =:= '0' [ 1 ];
msn =:= msn_lsb(4) [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
timestamp =:= inferred_scaled_field [ 0 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// New format, Type 0 with strong CRC and more SN bits
COMPRESSED pt_0_crc7 {
discriminator =:= '1000' [ 4 ];
msn =:= msn_lsb(5) [ 5 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
timestamp =:= inferred_scaled_field [ 0 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// UO-1 replacement
COMPRESSED pt_1_rnd {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO));
discriminator =:= '101' [ 3 ];
marker =:= irregular(1) [ 1 ];
msn =:= msn_lsb(4) [ 4 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
}
}
// UO-1-ID replacement
COMPRESSED pt_1_seq_id {
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '1001' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4) [ 4 ];
msn =:= msn_lsb(5) [ 5 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
timestamp =:= inferred_scaled_field [ 0 ];
}
// UO-1-TS replacement
COMPRESSED pt_1_seq_ts {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '101' [ 3 ];
marker =:= irregular(1) [ 1 ];
msn =:= msn_lsb(4) [ 4 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// UOR-2 replacement
COMPRESSED pt_2_rnd {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO));
discriminator =:= '110' [ 3 ];
msn =:= msn_lsb(7) [ 7 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 6) [ 6 ];
marker =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
}
// UOR-2-ID replacement COMPRESSED pt_2_seq_id { ENFORCE((ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior_innermost.UVALUE ==
// UOR-2-IDの交換圧縮pt_2_seq_id {endforce（（（ip_id_behavior_innermost.uvalue == ip_id_behavior_ sequential）||（ip_id_behavior_innermmost.uvalue ========
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '11000' [ 5 ];
msn =:= msn_lsb(7) [ 7 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 5) [ 5 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
timestamp =:= inferred_scaled_field [ 0 ];
}
// UOR-2-ID-ext1 replacement (both TS and IP-ID)
COMPRESSED pt_2_seq_both {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '11001' [ 5 ];
msn =:= msn_lsb(7) [ 7 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 5) [ 5 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 7) [ 7 ];
marker =:= irregular(1) [ 1 ];
}
// UOR-2-TS replacement
COMPRESSED pt_2_seq_ts {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '1101' [ 4 ];
msn =:= msn_lsb(7) [ 7 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ];
marker =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
}
////////////////////////////////////////////
// UDP profile
////////////////////////////////////////////
udp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
reorder_ratio_value)
{
UNCOMPRESSED v4 {
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 8 ];
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 ];
next_header [ 8 ];
ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
udp_length =:= inferred_udp_length [ 16 ];
udp_checksum [ 16 ];
}
UNCOMPRESSED v6 {
ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 6) [ 4 ];
tos_tc [ 8 ];
flow_label [ 20 ];
payload_length =:= inferred_ip_v6_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dest_addr [ 128 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
udp_length =:= inferred_udp_length [ 16 ];
udp_checksum [ 16 ];
df =:= uncompressed_value(0,0) [ 0 ];
ip_id =:= uncompressed_value(0,0) [ 0 ];
}
CONTROL {
ENFORCE(profile_value == PROFILE_UDP_0102);
ENFORCE(profile == profile_value);
ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
}
DEFAULT {
ENFORCE(outer_ip_flag == 0);
tos_tc =:= static;
dest_addr =:= static;
ip_version =:= static;
ttl_hopl =:= static;
src_addr =:= static;
df =:= static;
flow_label =:= static;
next_header =:= static;
src_port =:= static;
dst_port =:= static;
reorder_ratio =:= static;
ip_id_behavior_innermost =:= static;
}
// Replacement for UOR-2-ext3
COMPRESSED co_common {
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
discriminator =:= '11111010' [ 8 ];
ip_id_indicator =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags_indicator =:= irregular(1) [ 1 ];
ttl_hopl_indicator =:= irregular(1) [ 1 ];
tos_tc_indicator =:= irregular(1) [ 1 ];
reorder_ratio =:= irregular(2) [ 2 ];
control_crc3 =:= control_crc3_encoding [ 3 ];
outer_ip_indicator : df : ip_id_behavior_innermost =:=
profile_2_3_4_flags_enc(
flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ];
tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
ttl_hopl.ULENGTH) [ 0, 8 ];
msn =:= msn_lsb(8) [ 8 ];
ip_id =:= ip_id_sequential_variable(ip_id_behavior_innermost.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
}
// UO-0
COMPRESSED pt_0_crc3 {
discriminator =:= '0' [ 1 ];
msn =:= msn_lsb(4) [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// New format, Type 0 with strong CRC and more SN bits COMPRESSED pt_0_crc7 {
//新しい形式、強力なCRCおよびより多くのSNビットを備えたタイプ0圧縮pt_0_crc7 {
discriminator =:= '100' [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// UO-1-ID replacement (PT-1 only used for sequential)
COMPRESSED pt_1_seq_id {
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '101' [ 3 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4) [ 4 ];
}
// UOR-2-ID replacement
COMPRESSED pt_2_seq_id {
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '110' [ 3 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
msn =:= msn_lsb(8) [ 8 ];
}
}
////////////////////////////////////////////
// ESP profile
////////////////////////////////////////////
esp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
reorder_ratio_value)
{
UNCOMPRESSED v4 {
ENFORCE(msn.UVALUE == sequence_number.UVALUE % 65536);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 8 ];
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 ];
next_header [ 8 ];
ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
spi [ 32 ];
sequence_number [ 32 ];
}
UNCOMPRESSED v6 {
ENFORCE(msn.UVALUE == (sequence_number.UVALUE % 65536));
ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 6) [ 4 ];
tos_tc [ 8 ];
flow_label [ 20 ];
payload_length =:= inferred_ip_v6_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dest_addr [ 128 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
spi [ 32 ];
sequence_number [ 32 ];
df =:= uncompressed_value(0,0) [ 0 ];
ip_id =:= uncompressed_value(0,0) [ 0 ];
}
CONTROL {
ENFORCE(profile_value == PROFILE_ESP_0103);
ENFORCE(profile == profile_value);
ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
}
DEFAULT {
ENFORCE(outer_ip_flag == 0);
tos_tc =:= static;
dest_addr =:= static;
ttl_hopl =:= static;
src_addr =:= static;
df =:= static;
flow_label =:= static;
next_header =:= static;
spi =:= static;
sequence_number =:= static;
reorder_ratio =:= static;
ip_id_behavior_innermost =:= static;
}
// Replacement for UOR-2-ext3
COMPRESSED co_common {
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
discriminator =:= '11111010' [ 8 ];
ip_id_indicator =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags_indicator =:= irregular(1) [ 1 ];
ttl_hopl_indicator =:= irregular(1) [ 1 ];
tos_tc_indicator =:= irregular(1) [ 1 ];
reorder_ratio =:= irregular(2) [ 2 ];
control_crc3 =:= control_crc3_encoding [ 3 ];
outer_ip_indicator : df : ip_id_behavior_innermost =:=
profile_2_3_4_flags_enc(
flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ];
tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
ttl_hopl.ULENGTH) [ 0, 8 ];
sequence_number =:=
sdvl_sn_lsb(sequence_number.ULENGTH) [ VARIABLE ];
ip_id =:= ip_id_sequential_variable(ip_id_behavior_innermost.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
}
// Sequence number sent instead of MSN due to field length
// UO-0
COMPRESSED pt_0_crc3 {
discriminator =:= '0' [ 1 ];
sequence_number =:= msn_lsb(4) [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// New format, Type 0 with strong CRC and more SN bits
COMPRESSED pt_0_crc7 {
discriminator =:= '100' [ 3 ];
sequence_number =:= msn_lsb(6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// UO-1-ID replacement (PT-1 only used for sequential) COMPRESSED pt_1_seq_id {
// UO-1-ID交換（PT-1シーケンシャルにのみ使用）圧縮PT_1_SEQ_ID {
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '101' [ 3 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
sequence_number =:= msn_lsb(6) [ 6 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4) [ 4 ];
}
// UOR-2-ID replacement
COMPRESSED pt_2_seq_id {
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '110' [ 3 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
sequence_number =:= msn_lsb(8) [ 8 ];
}
}
////////////////////////////////////////////
// IP-only profile
////////////////////////////////////////////
iponly_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
reorder_ratio_value)
{
UNCOMPRESSED v4 {
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 8 ];
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 ];
next_header [ 8 ];
ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
}
UNCOMPRESSED v6 {
ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 6) [ 4 ];
tos_tc [ 8 ];
flow_label [ 20 ];
payload_length =:= inferred_ip_v6_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dest_addr [ 128 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
df =:= uncompressed_value(0,0) [ 0 ];
ip_id =:= uncompressed_value(0,0) [ 0 ];
}
CONTROL {
ENFORCE(profile_value == PROFILE_IP_0104);
ENFORCE(profile == profile_value);
ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
}
DEFAULT {
ENFORCE(outer_ip_flag == 0);
tos_tc =:= static;
dest_addr =:= static;
ttl_hopl =:= static;
src_addr =:= static;
df =:= static;
flow_label =:= static;
next_header =:= static;
reorder_ratio =:= static;
ip_id_behavior_innermost =:= static;
}
// Replacement for UOR-2-ext3
COMPRESSED co_common {
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
discriminator =:= '11111010' [ 8 ];
ip_id_indicator =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags_indicator =:= irregular(1) [ 1 ];
ttl_hopl_indicator =:= irregular(1) [ 1 ];
tos_tc_indicator =:= irregular(1) [ 1 ];
reorder_ratio =:= irregular(2) [ 2 ];
control_crc3 =:= control_crc3_encoding [ 3 ];
outer_ip_indicator : df : ip_id_behavior_innermost =:=
profile_2_3_4_flags_enc(
flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ];
tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
ttl_hopl.ULENGTH) [ 0, 8 ];
msn =:= msn_lsb(8) [ 8 ];
ip_id =:= ip_id_sequential_variable(ip_id_behavior_innermost.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
}
// UO-0
COMPRESSED pt_0_crc3 {
discriminator =:= '0' [ 1 ];
msn =:= msn_lsb(4) [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// New format, Type 0 with strong CRC and more SN bits
COMPRESSED pt_0_crc7 {
discriminator =:= '100' [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// UO-1-ID replacement (PT-1 only used for sequential)
COMPRESSED pt_1_seq_id {
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '101' [ 3 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4) [ 4 ];
}
// UOR-2-ID replacement
COMPRESSED pt_2_seq_id {
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '110' [ 3 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
msn =:= msn_lsb(8) [ 8 ];
}
}
////////////////////////////////////////////
// UDP-lite/RTP profile
////////////////////////////////////////////
udplite_rtp_baseheader(profile_value, ts_stride_value,
time_stride_value, outer_ip_flag,
ip_id_behavior_value, reorder_ratio_value,
coverage_behavior_value)
{
UNCOMPRESSED v4 {
ENFORCE(msn.UVALUE == sequence_number.UVALUE);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 8 ];
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 ];
next_header [ 8 ];
ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
checksum_coverage [ 16 ];
udp_checksum [ 16 ];
rtp_version =:= uncompressed_value(2, 2) [ 2 ];
pad_bit [ 1 ];
extension [ 1 ];
cc [ 4 ];
marker [ 1 ];
payload_type [ 7 ];
sequence_number [ 16 ];
timestamp [ 32 ];
ssrc [ 32 ];
csrc_list [ VARIABLE ];
}
UNCOMPRESSED v6 {
ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 6) [ 4 ];
tos_tc [ 8 ];
flow_label [ 20 ];
payload_length =:= inferred_ip_v6_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dest_addr [ 128 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
checksum_coverage [ 16 ];
udp_checksum [ 16 ];
rtp_version =:= uncompressed_value(2, 2) [ 2 ];
pad_bit [ 1 ];
extension [ 1 ];
cc [ 4 ];
marker [ 1 ];
payload_type [ 7 ];
sequence_number [ 16 ];
timestamp [ 32 ];
ssrc [ 32 ];
csrc_list [ VARIABLE ];
df =:= uncompressed_value(0,0) [ 0 ];
ip_id =:= uncompressed_value(0,0) [ 0 ];
}
CONTROL {
ENFORCE(profile_value == PROFILE_RTP_0107);
ENFORCE(profile == profile_value);
ENFORCE(time_stride.UVALUE == time_stride_value);
ENFORCE(ts_stride.UVALUE == ts_stride_value);
ENFORCE(coverage_behavior.UVALUE == coverage_behavior_value);
ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
dummy_field =:= field_scaling(ts_stride.UVALUE,
ts_scaled.UVALUE, timestamp.UVALUE, ts_offset.UVALUE) [ 0 ];
}
INITIAL {
ts_stride =:= uncompressed_value(32, TS_STRIDE_DEFAULT);
time_stride =:= uncompressed_value(32, TIME_STRIDE_DEFAULT);
}
DEFAULT {
ENFORCE(outer_ip_flag == 0);
tos_tc =:= static;
dest_addr =:= static;
ttl_hopl =:= static;
src_addr =:= static;
df =:= static;
flow_label =:= static;
next_header =:= static;
src_port =:= static;
dst_port =:= static;
pad_bit =:= static;
extension =:= static;
cc =:= static;
// When marker not present in packets, it is assumed 0
marker =:= uncompressed_value(1, 0);
payload_type =:= static;
sequence_number =:= static;
timestamp =:= static;
ssrc =:= static;
csrc_list =:= static;
ts_stride =:= static;
time_stride =:= static;
ts_scaled =:= static;
ts_offset =:= static;
reorder_ratio =:= static;
ip_id_behavior_innermost =:= static;
}
// Replacement for UOR-2-ext3
COMPRESSED co_common {
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
discriminator =:= '11111010' [ 8 ];
marker =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags1_indicator =:= irregular(1) [ 1 ];
flags2_indicator =:= irregular(1) [ 1 ];
tsc_indicator =:= irregular(1) [ 1 ];
tss_indicator =:= irregular(1) [ 1 ];
ip_id_indicator =:= irregular(1) [ 1 ];
control_crc3 =:= control_crc3_encoding [ 3 ];
outer_ip_indicator : ttl_hopl_indicator :
tos_tc_indicator : df : ip_id_behavior_innermost : reorder_ratio
=:= profile_1_7_flags1_enc(flags1_indicator.CVALUE,
ip_version.UVALUE) [ 0, 8 ];
list_indicator : pt_indicator : tis_indicator : pad_bit :
extension : coverage_behavior =:=
profile_7_flags2_enc(flags2_indicator.CVALUE) [ 0, 8 ];
tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:=
static_or_irreg(ttl_hopl_indicator.CVALUE, 8) [ 0, 8 ];
payload_type =:= pt_irr_or_static(pt_indicator.CVALUE) [ 0, 8 ];
sequence_number =:=
sdvl_sn_lsb(sequence_number.ULENGTH) [ VARIABLE ];
ip_id =:= ip_id_sequential_variable(ip_id_behavior_innermost.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
ts_scaled =:= variable_scaled_timestamp(tss_indicator.CVALUE,
tsc_indicator.CVALUE, ts_stride.UVALUE,
time_stride.UVALUE) [ VARIABLE ];
timestamp =:= variable_unscaled_timestamp(tss_indicator.CVALUE,
tsc_indicator.CVALUE) [ VARIABLE ];
ts_stride =:= sdvl_or_static(tss_indicator.CVALUE) [ VARIABLE ];
time_stride =:= sdvl_or_static(tis_indicator.CVALUE) [ VARIABLE ];
csrc_list =:=
csrc_list_presence(list_indicator.CVALUE,
cc.UVALUE) [ VARIABLE ];
}
// UO-0
COMPRESSED pt_0_crc3 {
discriminator =:= '0' [ 1 ];
msn =:= msn_lsb(4) [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
timestamp =:= inferred_scaled_field [ 0 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// New format, Type 0 with strong CRC and more SN bits
COMPRESSED pt_0_crc7 {
discriminator =:= '1000' [ 4 ];
msn =:= msn_lsb(5) [ 5 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
timestamp =:= inferred_scaled_field [ 0 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// UO-1 replacement
COMPRESSED pt_1_rnd {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO));
discriminator =:= '101' [ 3 ];
marker =:= irregular(1) [ 1 ];
msn =:= msn_lsb(4) [ 4 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
}
// UO-1-ID replacement
COMPRESSED pt_1_seq_id {
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '1001' [ 4 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4) [ 4 ];
msn =:= msn_lsb(5) [ 5 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
timestamp =:= inferred_scaled_field [ 0 ];
}
// UO-1-TS replacement
COMPRESSED pt_1_seq_ts {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '101' [ 3 ];
marker =:= irregular(1) [ 1 ];
msn =:= msn_lsb(4) [ 4 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// UOR-2 replacement
COMPRESSED pt_2_rnd {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO));
discriminator =:= '110' [ 3 ];
msn =:= msn_lsb(7) [ 7 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 6) [ 6 ];
marker =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
}
// UOR-2-ID replacement
COMPRESSED pt_2_seq_id {
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '11000' [ 5 ];
msn =:= msn_lsb(7) [ 7 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 5) [ 5 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
timestamp =:= inferred_scaled_field [ 0 ];
}
// UOR-2-ID-ext1 replacement (both TS and IP-ID)
COMPRESSED pt_2_seq_both {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '11001' [ 5 ];
msn =:= msn_lsb(7) [ 7 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 5) [ 5 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 7) [ 7 ];
marker =:= irregular(1) [ 1 ];
}
// UOR-2-TS replacement
COMPRESSED pt_2_seq_ts {
ENFORCE(ts_stride.UVALUE != 0);
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '1101' [ 4 ];
msn =:= msn_lsb(7) [ 7 ];
ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ];
marker =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
}
////////////////////////////////////////////
// UDP-lite profile
////////////////////////////////////////////
udplite_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value,
reorder_ratio_value, coverage_behavior_value)
{
UNCOMPRESSED v4 {
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 4) [ 4 ];
header_length =:= uncompressed_value(4, 5) [ 4 ];
tos_tc [ 8 ];
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 ];
next_header [ 8 ];
ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
checksum_coverage [ 16 ];
udp_checksum [ 16 ];
}
UNCOMPRESSED v6 {
ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM);
outer_headers =:= baseheader_outer_headers [ VARIABLE ];
ip_version =:= uncompressed_value(4, 6) [ 4 ];
tos_tc [ 8 ];
flow_label [ 20 ];
payload_length =:= inferred_ip_v6_length [ 16 ];
next_header [ 8 ];
ttl_hopl [ 8 ];
src_addr [ 128 ];
dest_addr [ 128 ];
extension_headers =:= baseheader_extension_headers [ VARIABLE ];
src_port [ 16 ];
dst_port [ 16 ];
checksum_coverage [ 16 ];
udp_checksum [ 16 ];
df =:= uncompressed_value(0,0) [ 0 ];
ip_id =:= uncompressed_value(0,0) [ 0 ];
}
CONTROL {
ENFORCE(profile_value == PROFILE_UDPLITE_0108);
ENFORCE(profile == profile_value);
ENFORCE(coverage_behavior.UVALUE == coverage_behavior_value);
ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value);
ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value);
}
DEFAULT {
デフォルト {
ENFORCE(outer_ip_flag == 0);
tos_tc =:= static;
dest_addr =:= static;
ttl_hopl =:= static;
src_addr =:= static;
df =:= static;
flow_label =:= static;
next_header =:= static;
src_port =:= static;
dst_port =:= static;
reorder_ratio =:= static;
ip_id_behavior_innermost =:= static;
}
// Replacement for UOR-2-ext3
COMPRESSED co_common {
ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE);
discriminator =:= '11111010' [ 8 ];
ip_id_indicator =:= irregular(1) [ 1 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
flags_indicator =:= irregular(1) [ 1 ];
ttl_hopl_indicator =:= irregular(1) [ 1 ];
tos_tc_indicator =:= irregular(1) [ 1 ];
reorder_ratio =:= irregular(2) [ 2 ];
control_crc3 =:= control_crc3_encoding [ 3 ];
outer_ip_indicator : df : ip_id_behavior_innermost :
coverage_behavior =:=
profile_8_flags_enc(flags_indicator.CVALUE,
ip_version.UVALUE) [ 0, 8 ];
tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ];
ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE,
ttl_hopl.ULENGTH) [ 0, 8 ];
msn =:= msn_lsb(8) [ 8 ];
ip_id =:= ip_id_sequential_variable(ip_id_behavior_innermost.UVALUE,
ip_id_indicator.CVALUE) [ 0, 8, 16 ];
}
// UO-0
COMPRESSED pt_0_crc3 {
discriminator =:= '0' [ 1 ];
msn =:= msn_lsb(4) [ 4 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// New format, Type 0 with strong CRC and more SN bits
COMPRESSED pt_0_crc7 {
discriminator =:= '100' [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
ip_id =:= inferred_sequential_ip_id [ 0 ];
}
// UO-1-ID replacement (PT-1 only used for sequential)
COMPRESSED pt_1_seq_id {
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '101' [ 3 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
msn =:= msn_lsb(6) [ 6 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4) [ 4 ];
}
// UOR-2-ID replacement
COMPRESSED pt_2_seq_id {
ENFORCE((ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL) ||
(ip_id_behavior_innermost.UVALUE ==
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
discriminator =:= '110' [ 3 ];
ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 6) [ 6 ];
header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
msn =:= msn_lsb(8) [ 8 ];
}
}
This section describes the feedback format for ROHCv2 profiles, using the formats described in Section 5.2.3 of [RFC4995].
このセクションでは、[RFC4995]のセクション5.2.3で説明した形式を使用して、ROHCV2プロファイルのフィードバック形式について説明します。
The Acknowledgment Number field of the feedback formats contains the least significant bits of the MSN (see Section 6.3.1) that corresponds to the reference header that is being acknowledged. A reference header is a header that has been successfully CRC-8 validated or CRC verified. If there is no reference header available, the feedback MUST carry an ACKNUMBER-NOT-VALID option. FEEDBACK-1
フィードバックフォーマットの確認番号フィールドには、MSNの最小のビット（セクション6.3.1を参照）が含まれています。参照ヘッダーは、CRC-8検証またはCRC検証に正常に行われたヘッダーです。利用可能な参照ヘッダーがない場合、フィードバックはAcKnumber-Not-validオプションを搭載する必要があります。フィードバック-1
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Acknowledgment Number |
+---+---+---+---+---+---+---+---+
Acknowledgment Number: The eight least significant bits of the MSN.
謝辞番号：MSNの8つの最も重要なビット。
A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK, FEEDBACK-2 must be used.
フィードバック1はACKです。NACKまたは静的ナックを送信するには、フィードバック2を使用する必要があります。
FEEDBACK-2
フィードバック-2
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| Acknowledgment Number |
+---+---+---+---+---+---+---+---+
| Acknowledgment Number |
+---+---+---+---+---+---+---+---+
| CRC |
+---+---+---+---+---+---+---+---+
/ Feedback options /
+---+---+---+---+---+---+---+---+
Acktype:
acktype：
0 = ACK
1 = NACK
2 = STATIC-NACK
3 is reserved (MUST NOT be used for parsability)
3は予約されています（格差のために使用してはいけません）
Acknowledgment Number: The least significant bits of the MSN.
謝辞番号：MSNの最も重要なビット。
CRC: 8-bit CRC computed over the entire feedback payload including any CID fields but excluding the feedback type, the 'Size' field, and the 'Code' octet, using the polynomial defined in Section 5.3.1.1 of [RFC4995]. If the CID is given with an Add-CID octet, the Add-CID octet immediately precedes the FEEDBACK-1 or FEEDBACK-2 format. For purposes of computing the CRC, the CRC field is zero.
CRC：8ビットCRCは、CIDフィールドを含むフィードバックペイロード全体にわたって計算されましたが、[RFC4995]のセクション5.3.1.1で定義された多項式を使用して、フィードバックタイプ、「サイズ」フィールド、および「コード」オクテットを除外します。CIDがAdd-CIDオクテットで与えられている場合、Add-CIDオクテットはフィードバック1またはフィードバック-2形式の直前です。CRCを計算するために、CRCフィールドはゼロです。
Feedback options: A variable number of feedback options, see Section 6.9.2. Options may appear in any order.
フィードバックオプション：さまざまな数のフィードバックオプション、セクション6.9.2を参照してください。オプションは任意の順序で表示される場合があります。
A FEEDBACK-2 of type NACK or STATIC-NACK is always implicitly an acknowledgment for a successfully decompressed packet, which corresponds to a packet whose LSBs match the Acknowledgment Number of the feedback element, unless the ACKNUMBER-NOT-VALID option (see Section 6.9.2.2) appears in the feedback element.
タイプNACKまたは静的ナックのフィードバック-2は、AcKnumber-Not-validオプションを除き、LSBがフィードバック要素の確認番号と一致するパケットに対応する、順調に解凍されたパケットの常に暗黙的に確認されます（セクション6.9を参照してください。.2.2）フィードバック要素に表示されます。
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 comparing the result with the CRC carried in the feedback format. If the two are not identical, the feedback element MUST be discarded.
フィードバック-2形式は常にCRCを搭載するため、フィードバック1形式よりも堅牢です。フィードバック-2を受信するとき、コンプレッサーはCRCを計算し、結果をフィードバック形式で伝達したCRCと比較することにより、情報を検証する必要があります。2つが同一でない場合、フィードバック要素を破棄する必要があります。
A feedback option has variable length and the following general format:
フィードバックオプションには、長さが変動し、次の一般的な形式があります。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type | Opt Len |
+---+---+---+---+---+---+---+---+
/ Option Data / Opt Len (octets)
+---+---+---+---+---+---+---+---+
Opt Type: Unsigned integer that represents the type of the feedback option. Section 6.9.2.1 through Section 6.9.2.4 describes the ROHCv2 feedback options.
OPTタイプ：フィードバックオプションのタイプを表す符号なし整数。セクション6.9.2.1からセクション6.9.2.4では、ROHCV2フィードバックオプションについて説明します。
Opt Len: Unsigned integer that represents the length of the Option Data field, in octets.
Opt Len：オクテットのオプションデータフィールドの長さを表す符号なし整数。
Option Data: Feedback type specific data. Present if the value of the Opt Len field is set to a non-zero value.
オプションデータ：フィードバックタイプ特定のデータ。OPT LENフィールドの値がゼロ以外の値に設定されている場合は、現在。
The REJECT option informs the compressor that the decompressor does not have sufficient resources to handle the flow.
拒否オプションは、圧縮機にフローを処理するのに十分なリソースがないことをコンプレッサーに通知します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 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.
拒否オプションを受信する場合、コンプレッサーはパケットフローの圧縮を停止する必要があり、しばらくの間圧縮されたパケットフローの数を増やそうとすることを控える必要があります。拒否オプションは、フィードバック-2形式で複数回表示してはなりません。それ以外の場合、コンプレッサーはフィードバック要素全体を破棄する必要があります。
The ACKNUMBER-NOT-VALID option indicates that the Acknowledgment Number field of the feedback is not valid.
AcKnumber-Not-validオプションは、フィードバックの確認番号フィールドが無効であることを示します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 3 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
A compressor MUST NOT use the Acknowledgment Number of the feedback to find the corresponding sent header when this option is present. When this option is used, the Acknowledgment Number field of the FEEDBACK-2 format is set to zero. Consequently, a NACK or a STATIC-NACK feedback type sent with the ACKNUMBER-NOT-VALID option is equivalent to a STATIC-NACK with respect to the type of context repair requested by the decompressor.
コンプレッサーは、このオプションが存在するときに対応する送信ヘッダーを見つけるために、フィードバックの確認番号を使用してはなりません。このオプションを使用すると、フィードバック-2形式の確認番号フィールドがゼロに設定されます。したがって、AcKnumber-Not-validオプションで送信されたNACKまたは静的なナックフィードバックタイプは、減圧器が要求するコンテキスト修理のタイプに関して静的ナックに相当します。
The ACKNUMBER-NOT-VALID option MUST NOT appear more than once in the FEEDBACK-2 format; otherwise, the compressor MUST discard the entire feedback element.
AcKnumber-Not-Validオプションは、Feedback-2形式で複数回表示してはなりません。それ以外の場合、コンプレッサーはフィードバック要素全体を破棄する必要があります。
The CONTEXT_MEMORY option informs the compressor 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. 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オプションを受信する場合、コンプレッサーは、減圧器メモリリソースを減らす必要がある方法でパケットフローを圧縮するためのアクションを実行するか、パケットフローの圧縮を停止する必要があります。Context_memoryオプションは、フィードバック2形式で複数回表示してはなりません。それ以外の場合、コンプレッサーはフィードバック要素全体を破棄する必要があります。
The CLOCK_RESOLUTION option informs the compressor of the clock resolution of the decompressor. It also informs whether or not the decompressor supports timer-based compression of the RTP TS timestamp (see Section 6.6.9). The CLOCK_RESOLUTION option is applicable per channel, i.e., it applies to any context associated with a profile for which the option is relevant between a compressor and decompressor pair.
Clock_Resolutionオプションは、圧縮機のクロック解像度をコンプレッサーに通知します。また、減圧器がRTP TSタイムスタンプのタイマーベースの圧縮をサポートするかどうかを通知します（セクション6.6.9を参照）。Clock_Resolutionオプションはチャネルごとに適用されます。つまり、コンプレッサーペアとDecompressorペアの間にオプションが関連するプロファイルに関連付けられたコンテキストに適用されます。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 10 | Opt Len = 1 |
+---+---+---+---+---+---+---+---+
| Clock resolution (ms) |
+---+---+---+---+---+---+---+---+
Clock resolution: Unsigned integer that represents the clock resolution of the decompressor expressed in milliseconds.
クロック解像度：ミリ秒で発現する減圧器の時計解像度を表す署名のない整数。
The smallest clock resolution that can be indicated is 1 millisecond. The value zero has a special meaning: it indicates that the decompressor cannot do timer-based compression of the RTP Timestamp. The CLOCK_RESOLUTION option MUST NOT appear more than once in the FEEDBACK-2 format; otherwise, the compressor MUST discard the entire feedback element.
示される可能性のある最小のクロック解像度は1ミリ秒です。値ゼロには特別な意味があります。それは、減圧装置がRTPタイムスタンプのタイマーベースの圧縮を実行できないことを示します。Clock_Resolutionオプションは、フィードバック-2形式で1回以上表示してはなりません。それ以外の場合、コンプレッサーはフィードバック要素全体を破棄する必要があります。
If an option type other than those defined in this document is encountered, the compressor MUST discard the entire feedback element.
このドキュメントで定義されているもの以外のオプションタイプが発生した場合、コンプレッサーはフィードバック要素全体を破棄する必要があります。
Impairments such as bit errors on the received compressed headers, missing packets, and reordering between packets could cause the header decompressor to reconstitute erroneous packets, i.e., packets that do not match the original packet, but still have a valid IP, UDP (or UDP-Lite), and RTP headers, and possibly also valid UDP (or UDP-Lite) checksums.
受信した圧縮ヘッダーのビットエラー、パケットの不足、パケット間の並べ替えなどの障害により、ヘッダーの減圧装置が誤ったパケット、つまり元のパケットと一致しないが有効なIP、UDP（またはUDPを持っているパケットを再構成する可能性があります。-lite）、およびRTPヘッダー、およびおそらく有効なUDP（またはUDP-Lite）チェックサム。
The header compression profiles defined herein use an internal checksum for verification of reconstructed headers. This reduces the probability that a header decompressor delivers erroneous packets to upper layers without the error being noticed. In particular, the probability that consecutive erroneous packets are not detected by the internal checksum is close to zero.
本明細書で定義されているヘッダー圧縮プロファイルは、再構築されたヘッダーの検証に内部チェックサムを使用します。これにより、ヘッダーの減圧器が誤ったパケットを上層に配信する可能性が低下します。特に、連続した誤ったパケットが内部チェックサムによって検出されない確率はゼロに近いです。
This small but non-zero probability remains unchanged when integrity protection is applied after compression and verified before decompression, in the case where an attacker could discard or reorder packets between the compression endpoints.
攻撃者が圧縮エンドポイント間でパケットを廃棄または並べ替えることができる場合、この小さいがゼロ以外の確率は、圧縮後に整合性保護が適用され、減圧前に検証された場合、変更されません。
The impairments mentioned above could be caused by a malfunctioning or malicious header compressor. Such corruption may be detected with end-to-end integrity mechanisms that will not be affected by the compression. Moreover, the internal checksum can also be useful in the case of malfunctioning compressors.
上記の障害は、誤動作または悪意のあるヘッダーコンプレッサーによって引き起こされる可能性があります。このような腐敗は、圧縮の影響を受けないエンドツーエンドの完全性メカニズムで検出される場合があります。さらに、内部チェックサムは、誤動作コンプレッサーの場合にも役立ちます。
Denial-of-service attacks are possible if an intruder can introduce (for example) bogus IR or FEEDBACK packets onto the link and thereby cause compression efficiency to be reduced. However, an intruder having the ability to inject arbitrary packets at the link layer in this manner raises additional security issues that dwarf those related to the use of header compression.
侵入者が（たとえば）偽のIRまたはフィードバックパケットをリンクに導入し、それにより圧縮効率を低下させる場合、サービス拒否攻撃が可能です。ただし、この方法でリンクレイヤーに任意のパケットを注入する機能を持つ侵入者は、ヘッダー圧縮の使用に関連する追加のセキュリティ問題を提起します。
The following ROHC profile identifiers have been assigned by the IANA for the profiles defined in this document:
次のROHCプロファイル識別子は、このドキュメントで定義されているプロファイルに対してIANAによって割り当てられています。
Identifier Profile
---------- -------
0x0101 ROHCv2 RTP
0x0102 ROHCv2 UDP
0x0103 ROHCv2 ESP
0x0104 ROHCv2 IP
0x0107 ROHCv2 RTP/UDP-Lite
0x0108 ROHCv2 UDP-Lite
The authors would like to thank Mark West, Robert Finking, Haipeng Jin, and Rohit Kapoor for serving as committed document reviewers, and also for constructive discussions during the development of this document. Thanks to Carl Knutsson for his extensive contribution to this specification, as well as to Jani Juvan and Anders Edqvist for useful comments and feedback. Thanks also to Elwyn Davies for his review as the General Area Review Team (Gen-ART) reviewer, and to Stephen Kent for his review on behalf of the IETF security directorate, during IETF last-call. Finally, thanks to the many people who have contributed to previous ROHC specifications and supported this effort.
著者は、献身的な文書レビュー担当者として奉仕してくれたMark West、Robert Finking、Haipeng Jin、およびRohit Kapoorに感謝します。また、この文書の開発中の建設的な議論についても感謝します。この仕様に広範な貢献をしてくれたCarl Knutssonと、便利なコメントとフィードバックについてはJani JuvanとAnders Edqvistに感謝します。また、IETFラストコール中に、IETFセキュリティディレクターに代わってレビューをしてくれた一般エリアレビューチーム（Gen-Art）レビュアーとしてのレビューと、Stephen Kentにも感謝します。最後に、以前のROHC仕様に貢献し、この取り組みをサポートしてくれた多くの人々のおかげです。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2004] Perkins、C。、「IP内の最小カプセル化」、RFC 2004、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Cancapstulation（GRE）」、RFC 2784、2000年3月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890] Dommety、G。、「GREへのキーおよびシーケンス番号拡張」、RFC 2890、2000年9月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828] Larzon、L-A。、Degermark、M.、Pink、S.、Jonsson、L-E。、およびG. Fairhurst、「The Lightweight User Datagram Protocol（UDP-Lite）」、RFC 3828、2004年7月。
[RFC4019] Pelletier, G., "RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite", RFC 4019, April 2005.
[RFC4019] Pelletier、G。、 "Robust Header Compression（ROHC）：ユーザーデータグラムプロトコル（UDP）Liteのプロファイル"、RFC 4019、2005年4月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust Header Compression (ROHC) Framework", RFC 4995, July 2007.
[RFC4995] Jonsson、L-E。、Pelletier、G。、およびK. Sandlund、「The Robust Header Compression（ROHC）フレームワーク」、RFC 4995、2007年7月。
[RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust Header Compression (ROHC-FN)", RFC 4997, July 2007.
[RFC4997] Finking、R。およびG. Pelletier、「堅牢なヘッダー圧縮の正式な表記（ROHC-FN）」、RFC 4997、2007年7月。
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[RFC2675]ボーマン、D。、ディアリング、S。、およびR.ヒンデン、「IPv6ジャンボグラム」、RFC 2675、1999年8月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-e。、Hakenberg、R.、Koren、T.、Le、K.、Liu、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH. Zheng、 "堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮」、RFC 3095、2001年7月。
[RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[RFC3843] Jonsson、L-E。およびG. Pelletier、「堅牢なヘッダー圧縮（ROHC）：IPの圧縮プロファイル」、RFC 3843、2004年6月。
[RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets", RFC 4224, January 2006.
[RFC4224] Pelletier、G.、Jonsson、L-E。、およびK. Sandlund、「Robust Header Compression（ROHC）：Packetsを並べ替えることができるチャネル上のROHC」、RFC 4224、2006年1月。
Header compression is possible due to the fact that most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When designing a header compression scheme, it is of fundamental importance to understand the behavior of the fields in detail.
ほとんどのヘッダーフィールドがパケットからパケットまでランダムに変化しないという事実により、ヘッダー圧縮が可能です。フィールドの多くは、多かれ少なかれ予測可能な方法で静的な動作または変化を示します。ヘッダー圧縮スキームを設計するとき、フィールドの動作を詳細に理解することが根本的に重要です。
In this appendix, all fields in the headers compressible by these profiles are classified and analyzed. The analysis is based on behavior for the types of traffic that are expected to be the most frequently compressed (e.g., RTP field behavior is based on voice and/or video traffic behavior).
この付録では、これらのプロファイルによって圧縮可能なヘッダー内のすべてのフィールドが分類および分析されます。分析は、最も頻繁に圧縮されると予想されるトラフィックの種類の動作に基づいています（たとえば、RTPフィールドの動作は音声および/またはビデオトラフィックの動作に基づいています）。
Fields are classified as belonging to one of the following classes:
フィールドは、次のクラスのいずれかに属するものとして分類されます。
INFERRED - These fields contain values that can be inferred from other values, for example the size of the frame carrying the packet, and thus do not have to be included in compressed packets.
推測 - これらのフィールドには、他の値から推測できる値、たとえばパケットを運ぶフレームのサイズがあるため、圧縮パケットに含める必要はありません。
STATIC - These fields are expected to be constant throughout the lifetime of the flow; in general, it is sufficient to design a compressed format so that these fields are only updated by IR packets.
静的 - これらのフィールドは、流れの寿命を通して一定であると予想されます。一般に、これらのフィールドはIRパケットによってのみ更新されるように、圧縮形式を設計するだけで十分です。
STATIC-DEF - These fields are expected to be constant throughout the lifetime of the flow and their values can be used to define a flow. They are only sent in IR packets.
static -def-これらのフィールドは、流れの寿命を通じて一定であると予想され、その値を使用して流れを定義できます。それらはIRパケットでのみ送信されます。
STATIC-KNOWN - These fields are expected to have well-known values and therefore do not need to be communicated at all.
静的知ら - これらのフィールドにはよく知られている値があると予想されるため、まったく通信する必要はありません。
SEMISTATIC - These fields are unchanged most of the time. However, occasionally the value changes but will revert to its original value. For ROHCv2, the values of such fields do not need to be possible to change with the smallest compressed packet formats, but should be possible to change via slightly larger compressed packets.
半ゆがみ - これらのフィールドはほとんどの場合変更されていません。ただし、値が変更されますが、元の値に戻ります。ROHCV2の場合、そのようなフィールドの値は、最小の圧縮パケット形式で変更する必要はありませんが、わずかに大きな圧縮パケットを介して変更できるはずです。
RARELY CHANGING (RACH) - These are fields that change their values occasionally and then keep their new values. For ROHCv2, the values of such fields do not need to be possible to change with the smallest compressed packet formats, but should be possible to change via slightly larger compressed packets.
まれに変化することはありません（Rach） - これらは時々値を変更し、新しい値を保持するフィールドです。ROHCV2の場合、そのようなフィールドの値は、最小の圧縮パケット形式で変更する必要はありませんが、わずかに大きな圧縮パケットを介して変更できるはずです。
IRREGULAR - These are the fields for which no useful change pattern can be identified and should be transmitted uncompressed in all compressed packets.
不規則 - これらは、有用な変更パターンを特定できず、すべての圧縮パケットで非圧縮されている必要があるフィールドです。
PATTERN - These are fields that change between each packet, but change in a predictable pattern.
パターン - これらは各パケット間で変化するフィールドですが、予測可能なパターンで変化します。
+------------------------+----------------+
| Field | Class |
+------------------------+----------------+
| Version | STATIC-KNOWN |
| Header Length | STATIC-KNOWN |
| Type Of Service | RACH |
| Packet Length | INFERRED |
| Identification | |
| Sequential | PATTERN |
| Seq. swap | PATTERN |
| Random | IRREGULAR |
| Zero | STATIC |
| Reserved flag | STATIC-KNOWN |
| Don't Fragment flag | RACH |
| More Fragments flag | STATIC-KNOWN |
| Fragment Offset | STATIC-KNOWN |
| Time To Live | RACH |
| Protocol | STATIC-DEF |
| Header Checksum | INFERRED |
| Source Address | STATIC-DEF |
| Destination Address | STATIC-DEF |
+------------------------+----------------+
Version
バージョン
The version field states which IP version is used and is set to the value four.
バージョンフィールドには、どのIPバージョンが使用され、値4に設定されています。
Header Length
ヘッダー長
As long as no options are present in the IP header, the header length is constant with the value five. If there are options, the field could be RACH or STATIC-DEF, but only option-less headers are compressed by ROHCv2 profiles. The field is therefore classified as STATIC-KNOWN.
IPヘッダーにオプションが存在しない限り、ヘッダーの長さは値5で一定です。オプションがある場合、フィールドはrachまたはstatic-defである可能性がありますが、ROHCV2プロファイルによって圧縮されているのはオプションのないヘッダーのみです。したがって、このフィールドは静的な既知として分類されます。
Type Of Service
サービスの種類
For the type of flows compressed by the ROHCv2 profiles, the DSCP (Differentiated Services Code Point) and ECN (Explicit Congestion Notification) fields are expected to change relatively seldom.
ROHCV2プロファイルによって圧縮されたフローのタイプの場合、DSCP（差別化されたサービスコードポイント）とECN（明示的な輻輳通知）フィールドは、比較的めったに変化することはないと予想されます。
Packet Length
パケット長
Information about packet length is expected to be provided by the link layer. The field is therefore classified as INFERRED.
パケットの長さに関する情報は、リンクレイヤーによって提供されると予想されます。したがって、フィールドは推測されているように分類されます。
IPv4 Identification
IPv4識別
The Identification field (IP-ID) is used to identify what fragments constitute a datagram when reassembling fragmented datagrams. The IPv4 specification does not specify exactly how this field is to be assigned values, only that each packet should get an IP-ID that is unique for the source-destination pair and protocol for the time the datagram (or any of its fragments) could be alive in the network. This means that assignment of IP-ID values can be done in various ways, but the expected behaviors have been separated into four classes.
識別フィールド（IP-ID）を使用して、断片化されたデータグラムを再組み立てするときにデータグラムを構成するフラグメントを識別します。IPv4仕様は、このフィールドの割り当て方法を正確に指定するのではなく、各パケットがデータグラム（またはそのフラグメントのいずれか）が可能な時間のソース描写ペアとプロトコルに一意のIP-IDを取得する必要があることだけが、ネットワークで生きている。これは、IP-ID値の割り当てはさまざまな方法で実行できることを意味しますが、予想される動作は4つのクラスに分離されています。
Sequential
一連
In this behavior, the IP-ID is expected to increment by one for most packets, but may increment by a value larger than one, depending on the behavior of the transmitting IPv4 stack.
この動作では、IP-IDはほとんどのパケットで1つずつ増加すると予想されますが、送信するIPv4スタックの動作に応じて、1より大きい値で増加する場合があります。
Sequential Swapped
シーケンシャル交換
When using this behavior, the IP-ID behaves as in the Sequential behavior, but the two bytes of IP-ID are byte-swapped. Therefore, the IP-ID can be swapped before compression to make it behave exactly as the Sequential behavior.
この動作を使用する場合、IP-IDは順次動作のように動作しますが、IP-IDの2バイトはバイトスワップされています。したがって、IP-IDを圧縮前に交換して、順次動作とまったく同じように動作させることができます。
Random
ランダム
Some IP stacks assign IP-ID values using a pseudo-random number generator. There is thus no correlation between the ID values of subsequent datagrams, and therefore there is no way to predict the IP-ID value for the next datagram. For header compression purposes, this means that the IP-ID field needs to be sent uncompressed with each datagram, resulting in two extra octets of header.
一部のIPスタックは、擬似ランダム番号ジェネレーターを使用してIP-ID値を割り当てます。したがって、後続のデータグラムのID値の間に相関関係はないため、次のデータグラムのIP-ID値を予測する方法はありません。ヘッダー圧縮目的のために、これは、IP-IDフィールドを各データグラムで非圧縮せずに送信する必要があるため、2つの余分なオクテットのヘッダーが表示されることを意味します。
Zero
ゼロ
This behavior, although not a legal implementation of IPv4, is sometimes seen in existing IPv4 stacks. When this behavior is used, all IP packets have the IP-ID value set to zero.
この動作は、IPv4の法的実装ではありませんが、既存のIPv4スタックで見られることがあります。この動作を使用すると、すべてのIPパケットのIP-ID値がゼロに設定されています。
Flags
フラグ
The Reserved flag must be set to zero and is therefore classified as STATIC-KNOWN. The Don't Fragment (DF) flag changes rarely and is therefore classified as RACH. Finally, the More Fragments (MF) flag is expected to be zero because IP fragments will not be compressed by ROHC and is therefore classified as STATIC-KNOWN.
予約されたフラグはゼロに設定する必要があるため、静的な既知として分類されます。DONT FRAGMENT（DF）フラグの変更はめったにないため、Rachに分類されます。最後に、IPフラグメントはROHCによって圧縮されないため、静的な既知として分類されるため、より多くのフラグメント（MF）フラグはゼロになると予想されます。
Fragment Offset
フラグメントオフセット
Under the assumption that no fragmentation occurs, the fragment offset is always zero and is therefore classified as STATIC-KNOWN.
フラグメンテーションが発生しないという仮定の下では、フラグメントオフセットは常にゼロであるため、静的なものとして分類されます。
Time To Live
有効期間
The Time To Live field is expected to be constant during the lifetime of a flow or to alternate between a limited number of values due to route changes.
ライブフィールドへの時間は、フローの存続期間中に一定になるか、ルートの変更による限られた数の値を交互にすることが予想されます。
Protocol
プロトコル
This field will have the same value in all packets of a flow and is therefore classified as STATIC-DEF.
このフィールドは、フローのすべてのパケットで同じ値を持つため、静的DEFに分類されます。
Header Checksum
ヘッダーチェックサム
The header checksum protects individual hops from processing a corrupted header. When almost all IP header information is compressed away, there is no point in having this additional checksum; instead, it can be regenerated at the decompressor side. The field is therefore classified as INFERRED.
ヘッダーチェックサムは、個々のホップが破損したヘッダーの処理から保護します。ほとんどすべてのIPヘッダー情報が圧縮されている場合、この追加チェックサムを持つことには意味がありません。代わりに、減圧器側で再生できます。したがって、フィールドは推測されているように分類されます。
Source and Destination addresses
ソースおよび宛先アドレス
These fields are part of the definition of a flow and must thus be constant for all packets in the flow.
これらのフィールドは、フローの定義の一部であるため、フロー内のすべてのパケットに対して一定でなければなりません。
+----------------------+----------------+
| Field | Class |
+----------------------+----------------+
| Version | STATIC-KNOWN |
| Traffic Class | RACH |
| Flow Label | STATIC-DEF |
| Payload Length | INFERRED |
| Next Header | STATIC-DEF |
| Hop Limit | RACH |
| Source Address | STATIC-DEF |
| Destination Address | STATIC-DEF |
+----------------------+----------------+
Version
バージョン
The version field states which IP version is used and is set to the value six.
バージョンフィールドには、どのIPバージョンが使用され、値6に設定されています。
Traffic Class
トラフィッククラス
For the type of flows compressed by the ROHCv2 profiles, the DSCP and ECN fields are expected to change relatively seldom.
ROHCV2プロファイルによって圧縮されたフローのタイプの場合、DSCPおよびECNフィールドは比較的めったに変化することはないと予想されます。
Flow Label
フローラベル
This field may be used to identify packets belonging to a specific flow. If it is not used, the value should be set to zero. Otherwise, all packets belonging to the same flow must have the same value in this field. The field is therefore classified as STATIC-DEF.
このフィールドは、特定のフローに属するパケットを識別するために使用できます。使用されていない場合は、値をゼロに設定する必要があります。それ以外の場合、同じフローに属するすべてのパケットは、このフィールドで同じ値を持っている必要があります。したがって、フィールドはstatic-defに分類されます。
Payload Length
ペイロード長
Information about packet length (and, consequently, payload length) is expected to be provided by the link layer. The field is therefore classified as INFERRED.
パケットの長さに関する情報（およびその結果、ペイロード長）は、リンクレイヤーによって提供されると予想されます。したがって、フィールドは推測されているように分類されます。
Next Header
次のヘッダー
This field will have the same value in all packets of a flow and is therefore classified as STATIC-DEF.
このフィールドは、フローのすべてのパケットで同じ値を持つため、静的DEFに分類されます。
Hop Limit
ホップ制限
The Hop Limit field is expected to be constant during the lifetime of a flow or to alternate between a limited number of values due to route changes.
ホップ制限フィールドは、フローの寿命中に一定になるか、ルートの変更による限られた数の値を交互にすることが予想されます。
Source and Destination addresses
ソースおよび宛先アドレス
These fields are part of the definition of a flow and must thus be constant for all packets in the flow. The fields are therefore classified as STATIC-DEF.
これらのフィールドは、フローの定義の一部であるため、フロー内のすべてのパケットに対して一定でなければなりません。したがって、フィールドはstatic-defに分類されます。
+------------------+-------------+
| Field | Class |
+------------------+-------------+
| Source Port | STATIC-DEF |
| Destination Port | STATIC-DEF |
| Length | INFERRED |
| Checksum | |
| Disabled | STATIC |
| Enabled | IRREGULAR |
+------------------+-------------+
Source and Destination ports
ソースおよび宛先ポート
These fields are part of the definition of a flow and must thus be constant for all packets in the flow.
これらのフィールドは、フローの定義の一部であるため、フロー内のすべてのパケットに対して一定でなければなりません。
Length
長さ
Information about packet length is expected to be provided by the link layer. The field is therefore classified as INFERRED.
パケットの長さに関する情報は、リンクレイヤーによって提供されると予想されます。したがって、フィールドは推測されているように分類されます。
Checksum
チェックサム
The checksum can be optional. If disabled, its value is constantly zero and can be compressed away. If enabled, its value depends on the payload, which for compression purposes is equivalent to it changing randomly with every packet.
チェックサムはオプションです。無効にすると、その値は常にゼロであり、圧縮することができます。有効にすると、その値はペイロードに依存します。これは、圧縮目的では、すべてのパケットでランダムに変化することと同等です。
+--------------------+-------------+
| Field | Class |
+--------------------+-------------+
| Source Port | STATIC-DEF |
| Destination Port | STATIC-DEF |
| Checksum Coverage | |
| Zero | STATIC-DEF |
| Constant | INFERRED |
| Variable | IRREGULAR |
| Checksum | IRREGULAR |
+--------------------+-------------+
Source and Destination Port
ソースおよび宛先ポート
These fields are part of the definition of a flow and must thus be constant for all packets in the flow.
これらのフィールドは、フローの定義の一部であるため、フロー内のすべてのパケットに対して一定でなければなりません。
Checksum Coverage
チェックサムカバレッジ
The Checksum Coverage field may behave in different ways: it may have a value of zero, it may be equal to the datagram length, or it may have any value between eight octets and the length of the datagram. From a compression perspective, this field is expected to either be entirely predictable (for the cases where it follows the same behavior as the UDP Length field or where it takes on a constant value) or to change randomly for each packet (making the value unpredictable from a header-compression perspective). For all cases, the behavior itself is not expected to change for this field during the lifetime of a packet flow, or to change relatively seldom.
チェックサムカバレッジフィールドは、さまざまな方法で動作する場合があります。ゼロの値がある場合、データグラムの長さに等しい場合があります。または、8オクテットとデータグラムの長さの間の値がある場合があります。圧縮の観点から、このフィールドは完全に予測可能であると予想されます（UDP長さフィールドと同じ動作に従う場合、または一定の値を取る場合）、または各パケットのランダムに変更する（値を予測不可能にすることができますヘッダー圧縮の観点から）。すべての場合、動作自体は、パケットフローの寿命の間にこの分野の変化や、比較的めったに変化することはないと予想されます。
Checksum
チェックサム
The information used for the calculation of the UDP-Lite checksum is governed by the value of the checksum coverage and minimally includes the UDP-Lite header. The checksum is a changing field that must always be sent as-is.
UDP-Liteチェックサムの計算に使用される情報は、チェックサムカバレッジの価値によって支配されており、最小限のUDP-Liteヘッダーが含まれます。チェックサムは、常にそのまま送信する必要がある変化する分野です。
+----------------+----------------+
| Field | Class |
+----------------+----------------+
| Version | STATIC-KNOWN |
| Padding | RACH |
| Extension | RACH |
| CSRC Counter | RACH |
| Marker | SEMISTATIC |
| Payload Type | RACH |
| Sequence Number| PATTERN |
| Timestamp | PATTERN |
| SSRC | STATIC-DEF |
| CSRC | RACH |
+----------------+----------------+
Version
バージョン
This field is expected to have the value two and the field is therefore classified as STATIC-KNOWN.
したがって、このフィールドには値が2つあると予想されるため、フィールドは静的な既知として分類されます。
Padding
パディング
The use of this field is application-dependent, but when payload padding is used, it is likely to be present in most or all packets. The field is classified as RACH to allow for the case where the value of this field changes.
このフィールドの使用はアプリケーションに依存しますが、ペイロードパディングを使用すると、ほとんどまたはすべてのパケットに存在する可能性があります。このフィールドは、このフィールドの値が変化する場合を可能にするためにRACHとして分類されます。
Extension
拡大
If RTP extensions are used by the application, these extensions are often present in all packets, although the use of extensions is infrequent. To allow efficient compression of a flow using extensions in only a few packets, this field is classified as RACH.
RTP拡張機能がアプリケーションで使用されている場合、これらの拡張機能は多くの場合、すべてのパケットに存在しますが、拡張機能の使用はまれです。数個のパケットでのみ拡張機能を使用してフローの効率的な圧縮を可能にするために、このフィールドはRACHとして分類されます。
CSRC Count
CSRCカウント
This field indicates the number of CSRC items present in the CSRC list. This number is expected to be mostly constant on a packet-to-packet basis and when it changes, change by small amounts. As long as no RTP mixer is used, the value of this field will be zero.
このフィールドは、CSRCリストに存在するCSRCアイテムの数を示します。この数は、パケットからパケットごとにほとんど一定であると予想され、それが変化すると、少量変化します。RTPミキサーが使用されていない限り、このフィールドの値はゼロになります。
Marker
マーカー
For audio, the marker bit should be set only in the first packet of a talkspurt, while for video, it should be set in the last packet of every picture. This means that in both cases the RTP marker is classified as SEMISTATIC.
オーディオの場合、マーカービットはTalkspurtの最初のパケットでのみ設定する必要がありますが、ビデオではすべての画像の最後のパケットに設定する必要があります。これは、どちらの場合も、RTPマーカーが半骨として分類されることを意味します。
Payload Type
ペイロードタイプ
Applications could adapt to congestion by changing payload type and/or frame sizes, but that is not expected to happen frequently, so this field is classified as RACH.
アプリケーションは、ペイロードの種類やフレームサイズを変更することで混雑に適応する可能性がありますが、頻繁に発生するとは予想されていないため、このフィールドはRachに分類されます。
RTP Sequence Number
RTPシーケンス番号
The RTP Sequence Number will be incremented by one for each packet sent.
RTPシーケンス番号は、送信されるパケットごとに1つずつ増加します。
Timestamp
タイムスタンプ
In the audio case:
オーディオケースで：
As long as there are no pauses in the audio stream, the RTP Timestamp will be incremented by a constant value, which corresponds to the number of samples in the speech frame. It will thus mostly follow the RTP Sequence Number. When there has been a silent period and a new talkspurt begins, the timestamp will jump in proportion to the length of the silent period. However, the increment will probably be within a relatively limited range.
オーディオストリームに一時停止がない限り、RTPタイムスタンプは一定の値によって増加します。これは、音声フレーム内のサンプルの数に対応します。したがって、主にRTPシーケンス番号に従います。静かな期間があり、新しいTalkspurtが始まると、タイムスタンプは静かな期間の長さに比例してジャンプします。ただし、増分はおそらく比較的限られた範囲内にあります。
In the video case:
ビデオケース：
Between two consecutive packets, the timestamp will either be unchanged or increase by a multiple of a fixed value corresponding to the picture clock frequency. The timestamp can also decrease by a multiple of the fixed value for certain coding schemes. The change in timestamp value, expressed as a multiple of the picture clock frequency, is in most cases within a limited range.
2つの連続したパケットの間に、タイムスタンプは変更されず、画像クロック周波数に対応する固定値の倍数によって増加します。また、タイムスタンプは、特定のコーディングスキームの固定値の倍数によって減少する可能性があります。画像クロック周波数の倍数として表されるタイムスタンプ値の変化は、ほとんどの場合、限られた範囲内にあります。
SSRC
SSRC
This field is part of the definition of a flow and must thus be constant for all packets in the flow. The field is therefore classified as STATIC-DEF.
このフィールドは、フローの定義の一部であるため、フロー内のすべてのパケットに対して一定でなければなりません。したがって、フィールドはstatic-defに分類されます。
Contributing Sources (CSRC)
寄付源（CSRC）
The participants in a session, who are identified by the CSRC fields, are usually expected to be unchanged on a packet-to-packet basis, but will infrequently change by a few additions and/or removals.
CSRCフィールドによって特定されたセッションの参加者は、通常、パケットからパケットごとに変更されないと予想されますが、いくつかの追加および/または削除によってめったに変更されることがあります。
+------------------+-------------+
| Field | Class |
+------------------+-------------+
| SPI | STATIC-DEF |
| Sequence Number | PATTERN |
+------------------+-------------+
SPI
spi
This field is used to identify a distinct flow between two IPsec peers and it changes rarely; therefore, it is classified as STATIC-DEF.
このフィールドは、2つのIPSECピア間の明確なフローを識別するために使用され、めったに変化しません。したがって、static-defに分類されます。
ESP Sequence Number
ESPシーケンス番号
The ESP Sequence Number will be incremented by one for each packet sent.
ESPシーケンス番号は、送信されるパケットごとに1つずつ増加します。
+-----------------------+---------------+
| Field | Class |
+-----------------------+---------------+
| Next Header | STATIC-DEF |
| Ext Hdr Len | |
| Routing | STATIC-DEF |
| Hop-by-hop | STATIC |
| Destination | STATIC |
| Options | |
| Routing | STATIC-DEF |
| Hop-by-hop | RACH |
| Destination | RACH |
+-----------------------+---------------+
Next Header
次のヘッダー
This field will have the same value in all packets of a flow and is therefore classified as STATIC-DEF.
このフィールドは、フローのすべてのパケットで同じ値を持つため、静的DEFに分類されます。
Ext Hdr Len
ext hdr len
For the Routing header, it is expected that the length will remain constant for the duration of the flow, and that a change in the length should be classified as a new flow by the ROHC compressor. For Hop-by-hop and Destination options headers, the length is expected to remain static, but can be updated by an IR packet.
ルーティングヘッダーの場合、フローの期間中、長さは一定のままであり、長さの変化はROHCコンプレッサーによる新しいフローとして分類される必要があると予想されます。ホップバイホップおよび宛先オプションヘッダーの場合、長さは静的なままであると予想されますが、IRパケットで更新できます。
Options
オプション
For the Routing header, it is expected that the option content will remain constant for the duration of the flow, and that a change in the routing information should be classified as a new flow by the ROHC compressor. For Hop-by-hop and Destination options headers, the options are expected to remain static, but can be updated by an IR packet.
ルーティングヘッダーの場合、オプションコンテンツはフローの期間中は一定であり、ルーティング情報の変更はROHCコンプレッサーによる新しいフローとして分類する必要があると予想されます。ホップバイホップおよび宛先オプションヘッダーの場合、オプションは静的なままであると予想されますが、IRパケットで更新できます。
+--------------------+---------------+
| Field | Class |
+--------------------+---------------+
| C flag | STATIC |
| K flag | STATIC |
| S flag | STATIC |
| R flag | STATIC-KNOWN |
| Reserved0, Version | STATIC-KNOWN |
| Protocol | STATIC-DEF |
| Checksum | IRREGULAR |
| Reserved | STATIC-KNOWN |
| Sequence Number | PATTERN |
| Key | STATIC-DEF |
+--------------------+---------------+
Flags
フラグ
The four flag bits are not expected to change for the duration of the flow, and the R flag is expected to always be set to zero.
4つのフラグビットは、フローの期間中に変更されるとは予想されておらず、Rフラグは常にゼロに設定されると予想されます。
Reserved0, Version
予約された0、バージョン
Both of these fields are expected to be set to zero for the duration of any flow.
これらのフィールドは両方とも、流れの期間中はゼロに設定されると予想されます。
Protocol
プロトコル
This field will have the same value in all packets of a flow and is therefore classified as STATIC-DEF.
このフィールドは、フローのすべてのパケットで同じ値を持つため、静的DEFに分類されます。
Checksum
チェックサム
When the checksum field is present, it is expected to behave unpredictably.
チェックサムフィールドが存在する場合、予測的に動作することが期待されます。
Reserved
予約済み
When present, this field is expected to be set to zero.
存在する場合、このフィールドはゼロに設定されると予想されます。
Sequence Number
シーケンス番号
When present, the Sequence Number increases by one for each packet.
存在すると、シーケンス番号はパケットごとに1つ増加します。
Key
鍵
When present, the Key field is used to define the flow and does not change.
存在する場合、キーフィールドはフローを定義するために使用され、変化しません。
+---------------------+----------------+
| Field | Class |
+---------------------+----------------+
| Protocol | STATIC-DEF |
| S bit | STATIC-DEF |
| Reserved | STATIC-KNOWN |
| Checksum | INFERRED |
| Source Address | STATIC-DEF |
| Destination Address | STATIC-DEF |
+---------------------+----------------+
Protocol
プロトコル
This field will have the same value in all packets of a flow and is therefore classified as STATIC-DEF.
このフィールドは、フローのすべてのパケットで同じ値を持つため、静的DEFに分類されます。
S bit
sビット
The S bit is not expected to change during a flow.
Sビットは、フロー中に変更されるとは予想されません。
Reserved
予約済み
The reserved field is expected to be set to zero.
予約済みフィールドはゼロに設定されると予想されます。
Checksum
チェックサム
The header checksum protects individual routing hops from processing a corrupted header. Since all fields of this header are compressed away, there is no need to include this checksum in compressed packets and it can be regenerated at the decompressor side.
ヘッダーチェックサムは、個々のルーティングホップが破損したヘッダーの処理から保護します。このヘッダーのすべてのフィールドは圧縮されているため、このチェックサムを圧縮パケットに含める必要はなく、減圧器側で再生できます。
Source and Destination Addresses
ソースおよび宛先アドレス
These fields can be used to define the flow and are not expected to change.
これらのフィールドは、フローを定義するために使用でき、変化することは期待されていません。
+---------------------+----------------+
| Field | Class |
+---------------------+----------------+
| Next Header | STATIC-DEF |
| Payload Length | STATIC |
| Reserved | STATIC-KNOWN |
| SPI | STATIC-DEF |
| Sequence Number | PATTERN |
| ICV | IRREGULAR |
+---------------------+----------------+
Next Header
次のヘッダー
This field will have the same value in all packets of a flow and is therefore classified as STATIC-DEF.
このフィールドは、フローのすべてのパケットで同じ値を持つため、静的DEFに分類されます。
Payload Length
ペイロード長
It is expected that the length of the header is constant for the duration of the flow.
ヘッダーの長さは、フローの期間中に一定であると予想されます。
Reserved
予約済み
The value of this field will be set to zero.
このフィールドの値はゼロに設定されます。
SPI
spi
This field is used to identify a specific flow and only changes when the sequence number wraps around, and is therefore classified as STATIC-DEF.
このフィールドは、特定のフローを識別するために使用され、シーケンス番号が包まれた場合にのみ変化するため、静的DEFに分類されます。
Sequence Number
シーケンス番号
The Sequence Number will be incremented by one for each packet sent.
シーケンス番号は、送信されるパケットごとに1つずつ増加します。
ICV
ICV
The ICV is expected to behave unpredictably and is therefore classified as IRREGULAR.
ICVは予測不可能に動作すると予想されるため、不規則に分類されます。
This section describes some guiding principles for implementing a ROHCv2 compressor with focus on how to efficiently select appropriate packet formats. The text in this appendix should be considered guidelines; it does not define any normative requirement on how ROHCv2 profiles are implemented.
このセクションでは、適切なパケット形式を効率的に選択する方法に焦点を当てたROHCV2コンプレッサーを実装するためのいくつかのガイド原則について説明します。この付録のテキストは、ガイドラインと見なされる必要があります。ROHCV2プロファイルの実装方法に関する規範的要件を定義しません。
The compressor usually maintains a sliding window of reference headers, which contains as many references as needed for the optimistic approach. Each reference contains a description of which changes occurred in the flow between two consecutive headers in the flow, and a new reference is inserted into the window each time a packet is compressed by this context. A reference may for example be implemented as a stored copy of the uncompressed header being represented. When the compressor is confident that a specific reference is no longer used by the decompressor (for example by using the optimistic approach or feedback received), the reference is removed from the sliding window.
コンプレッサーは通常、参照ヘッダーのスライディングウィンドウを維持します。これには、楽観的なアプローチに必要な限り多くの参照が含まれています。各参照には、フロー内の2つの連続したヘッダー間のフローで変更が発生した説明が含まれており、このコンテキストによってパケットが圧縮されるたびに新しい参照がウィンドウに挿入されます。たとえば、表現されている非圧縮ヘッダーの保存されたコピーとして参照が実装される場合があります。コンプレッサーが特定の参照が減圧器によって使用されなくなったと確信している場合（たとえば、受け取った楽観的なアプローチやフィードバックを使用して）、参照はスライドウィンドウから削除されます。
Section 5.1.1 describes how the optimistic approach impacts the packet format selection for the compressor. Exactly how the compressor selects a packet format is up to the implementation to decide, but the following is an example of how this process can be performed for lsb-encoded fields through the use of Window-based LSB encoding (W-LSB).
セクション5.1.1では、楽観的なアプローチがコンプレッサーのパケット形式の選択にどのように影響するかについて説明します。コンプレッサーがパケット形式を選択する方法は、実装を決定するための実装までですが、ウィンドウベースのLSBエンコーディング（W-LSB）を使用して、LSBエンコードされたフィールドに対してこのプロセスを実行する方法の例です。
With W-LSB encoding, the compressor uses a number of references (a window) from its context. What references to use is determined by its optimistic approach. The compressor extracts the value of the field to be W-LSB encoded from each reference in the window, and finds the maximum and minimum values. Once it determines these values, the compressor uses the assumption that the decompressor has a value for this field within the range given by these boundaries (inclusively) as its reference. The compressor can then select a number of LSBs from the value to be compressed, so that the LSBs can be decompressed regardless of whether the decompressor uses the minimum value, the maximum value or any other value in the range of possible references.
W-LSBエンコードを使用すると、コンプレッサーはコンテキストから多くの参照（ウィンドウ）を使用します。使用する参照は、その楽観的なアプローチによって決定されます。コンプレッサーは、ウィンドウ内の各参照からエンコードされるW-LSBとなるフィールドの値を抽出し、最大値と最小値を見つけます。これらの値を決定すると、コンプレッサーは、減圧器がこれらの境界（包括的に）で与えられた範囲内のこのフィールドの値が参照として値を持つという仮定を使用します。コンプレッサーは、圧縮される値から多数のLSBを選択することができます。これにより、減圧器が最小値、最大値、または可能な参照の範囲のその他の値を使用するかどうかに関係なく、LSBを解凍できます。
Section 6.6.9 defines decompressor behavior for timer-based RTP timestamp compression. This section gives guidelines on how the compressor should determine the number of LSB bits it should send for the timestamp field. When using timer-based compression, this number depends on the sum of the jitter before the compressor and the jitter between the compressor and decompressor.
セクション6.6.9は、タイマーベースのRTPタイムスタンプ圧縮の減圧装置の動作を定義します。このセクションでは、コンプレッサーがタイムスタンプフィールドに送信すべきLSBビットの数をどのように決定するかについてのガイドラインを示します。タイマーベースの圧縮を使用する場合、この数値は、コンプレッサーとコンプレッサーと減圧器間のジッターの前のジッターの合計に依存します。
The jitter before the compressor can be estimated using the following computation:
コンプレッサーの前のジッターは、次の計算を使用して推定できます。
Max_Jitter_BC =
max {|(T_n - T_j) - ((a_n - a_j) / time_stride)|,
for all headers j in the sliding window}
where (T_n - T_j) is the difference in the timestamp between the currently compressed header and a reference header and (a_n - a_j) is the difference in arrival time between those same two headers.
ここで、（T_N -T_J）は、現在圧縮されたヘッダーと参照ヘッダーの間のタイムスタンプの違いであり、（A_N -A_J）は、同じ2つのヘッダー間の到着時間の違いです。
In addition to this, the compressor needs to estimate an upper bound for the jitter between the compressor and decompressor (Max_Jitter_CD). This information may for example come from lower layers.
これに加えて、コンプレッサーは、コンプレッサーと減圧器（MAX_JITTER_CD）の間のジッターの上限を推定する必要があります。この情報は、たとえば下層からのものである可能性があります。
A compressor implementation can determine whether the difference in clock resolution between the compressor and decompressor induces an error when performing integer arithmetics; it can then treat this error as additional jitter.
コンプレッサーの実装は、コンプレッサーと減圧器間のクロック解像度の違いが整数算術を実行するときにエラーを誘導するかどうかを判断できます。その後、このエラーを追加のジッターとして扱うことができます。
After obtaining estimates for the jitters, the number of bits needed to transmit is obtained using the following calculation:
ジッターの推定値を取得した後、送信に必要なビットの数は、次の計算を使用して取得されます。
ceiling(log2(2 * (Max_Jitter_BC + Max_Jitter_CD + 2) + 1))
This number is then used to select a packet format that contains at least this many scaled timestamp bits.
この番号は、少なくともこれほど多くのスケーリングされたタイムスタンプビットを含むパケット形式を選択するために使用されます。
Authors' Addresses
著者のアドレス
Ghyslain Pelletier Ericsson Box 920 Lulea SE-971 28 Sweden
Ghyslain Pelletier Ericsson Box 920 Lulea SE-971 28スウェーデン
Phone: +46 (0) 8 404 29 43
EMail: ghyslain.pelletier@ericsson.com
Kristofer Sandlund Ericsson Box 920 Lulea SE-971 28 Sweden
Kristofer Sandlund Ericsson Box 920 Lulea SE-971 28スウェーデン
Phone: +46 (0) 8 404 41 58
EMail: kristofer.sandlund@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。